1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
|
README.txt
==========
This README file discusses the port of NuttX to the WaveShare Open1788 board:
See http://wvshare.com/product/Open1788-Standard.htm. This board features the
NXP LPC1788 MCU
CONTENTS
========
o LEDs
o Buttons
o FPU
o Serial Console
o Using OpenOCD with the Olimex ARM-USB-OCD
o Loading Code with the ISP Board
o Configuration
LEDs
====
The Open1788 base board has four user LEDs
LED1 : Connected to P1[14]
LED2 : Connected to P0[16]
LED3 : Connected to P1[13]
LED4 : Connected to P4[27]
If CONFIG_ARCH_LEDS is not defined, then the user can control the LEDs in
any way using the defitions provided in the board.h header file.
If CONFIG_ARCH_LEDs is defined, then NuttX will control the 3 LEDs on the
WaveShare Open1788K. The following definitions describe how NuttX controls
the LEDs:
LED1 LED2 LED3 LED4
LED_STARTED OFF OFF OFF OFF
LED_HEAPALLOCATE ON OFF OFF OFF
LED_IRQSENABLED OFF ON OFF OFF
LED_STACKCREATED ON ON OFF OFF
LED_INIRQ LED3 glows, on while in interupt
LED_SIGNAL LED3 glows, on while in signal handler
LED_ASSERTION LED3 glows, on while in assertion
LED_PANIC LED3 Flashes at 2Hz
LED_IDLE LED glows: ON while active; OFF while sleeping
Buttons
=======
The Open1788K supports several buttons:
USER1 : Connected to P4[26]
USER2 : Connected to P2[22]
USER3 : Connected to P0[10]
And a Joystick
JOY_A : Connected to P2[25]
JOY_B : Connected to P2[26]
JOY_C : Connected to P2[23]
JOY_D : Connected to P2[19]
JOY_CTR : Connected to P0[14]
These can be accessed using the definitions and interfaces defined in the
board.h header file.
FPU
===
FPU Configuration Options
-------------------------
There are two version of the FPU support built into the LPC17xx port.
1. Lazy Floating Point Register Save.
This is an untested implementation that saves and restores FPU registers
only on context switches. This means: (1) floating point registers are
not stored on each context switch and, hence, possibly better interrupt
performance. But, (2) since floating point registers are not saved,
you cannot use floating point operations within interrupt handlers.
This logic can be enabled by simply adding the following to your .config
file:
CONFIG_ARCH_FPU=y
2. Non-Lazy Floating Point Register Save
Mike Smith has contributed an extensive re-write of the ARMv7-M exception
handling logic. This includes verified support for the FPU. These changes
have not yet been incorporated into the mainline and are still considered
experimental. These FPU logic can be enabled with:
CONFIG_ARCH_FPU=y
CONFIG_ARMV7M_CMNVECTOR=y
You will probably also changes to the ld.script in if this option is selected.
This should work:
-ENTRY(_stext)
+ENTRY(__start) /* Treat __start as the anchor for dead code stripping */
+EXTERN(_vectors) /* Force the vectors to be included in the output */
CFLAGS
------
Only the Atollic toolchain has built-in support for the Cortex-M4 FPU. You will see
the following lines in each Make.defs file:
ifeq ($(CONFIG_STM32_ATOLLIC_LITE),y)
# Atollic toolchain under Windows
...
ifeq ($(CONFIG_ARCH_FPU),y)
ARCHCPUFLAGS = -mcpu=cortex-m4 -mthumb -march=armv7e-m -mfpu=fpv4-sp-d16 -mfloat-abi=hard
else
ARCHCPUFLAGS = -mcpu=cortex-m3 -mthumb -mfloat-abi=soft
endif
endif
If you are using a toolchain other than the Atollic toolchain, then to use the FPU
you will also have to modify the CFLAGS to enable compiler support for the ARMv7-M
FPU. As of this writing, there are not many GCC toolchains that will support the
ARMv7-M FPU.
As a minimum you will need to add CFLAG options to (1) enable hardware floating point
code generation, and to (2) select the FPU implementation. You might try the same
options as used with the Atollic toolchain in the Make.defs file:
ARCHCPUFLAGS = -mcpu=cortex-m4 -mthumb -march=armv7e-m -mfpu=fpv4-sp-d16 -mfloat-abi=hard
Configuration Changes
---------------------
Below are all of the configuration changes that I had to make to configs/stm3240g-eval/nsh2
in order to successfully build NuttX using the Atollic toolchain WITH FPU support:
-CONFIG_ARCH_FPU=n : Enable FPU support
+CONFIG_ARCH_FPU=y
-CONFIG_STM32_CODESOURCERYW=y : Disable the CodeSourcery toolchain
+CONFIG_STM32_CODESOURCERYW=n
-CONFIG_STM32_ATOLLIC_LITE=n : Enable *one* the Atollic toolchains
CONFIG_STM32_ATOLLIC_PRO=n
-CONFIG_STM32_ATOLLIC_LITE=y : The "Lite" version
CONFIG_STM32_ATOLLIC_PRO=n : The "Pro" version
-CONFIG_INTELHEX_BINARY=y : Suppress generation FLASH download formats
+CONFIG_INTELHEX_BINARY=n : (Only necessary with the "Lite" version)
-CONFIG_HAVE_CXX=y : Suppress generation of C++ code
+CONFIG_HAVE_CXX=n : (Only necessary with the "Lite" version)
See the section above on Toolchains, NOTE 2, for explanations for some of
the configuration settings. Some of the usual settings are just not supported
by the "Lite" version of the Atollic toolchain.
Serial Console
==============
By Default, UART0 is used as the serial console in all configurations. This
may be connected to your computer via an external RS-232 driver or via the
WaveShare USB ISP/VCOM module.
As an option, UART1 can also be used for the serial console. You might want,
to do this, for example, if you use UART0 for the ISP function and you want
to use a different UART for console output. UART1 can be configured as the
serial console by changing the configuration as follows:
System Type:
CONFIG_LPC17_UART0=n : Disable UART0 if it is no longer used
CONFIG_LPC17_UART1=y : Enable UART1
Drivers:
CONFIG_UART1_SERIAL_CONSOLE=y : Setup up the UART1 configuration
CONFIG_UART1_RXBUFSIZE=256
CONFIG_UART1_TXBUFSIZE=256
CONFIG_UART1_BAUD=115200
CONFIG_UART1_BITS=8
CONFIG_UART1_PARITY=0
CONFIG_UART1_2STOP=0
In this configuration using UART1, it is necessary to disable LED support
on the board. That is because UART1 RXD is set for pin p0.16, but so is
LED2. If you do not disable LED support then no incoming serial data will
be recevied.
Common Board Options
CONFIG_ARCH_LEDS=n : Disable LED support
You should also remove the LED2 jumper so that the RXD input does not
attempt to drive LED2 as well (However, this does not seem to interfere with
data receipt).
NOTE: If you intend to use LEDs with UART1, then you might want to
redesign some ofthe LED logic in the src/ subdirectory so that it does not
attempt to use LED2.
Using OpenOCD with the Olimex ARM-USB-OCD
=========================================
Building OpenOCD under Cygwin:
Refer to configs/olimex-lpc1766stk/README.txt
Installing OpenOCD in Ubuntu Linux:
sudo apt-get install openocd
Helper Scripts.
I have been using the Olimex ARM-USB-OCD debugger. OpenOCD
requires a configuration file. I keep the one I used last here:
configs/open1788/tools/open1788.cfg
However, the "correct" configuration script to use with OpenOCD may
change as the features of OpenOCD evolve. So you should at least
compare that open1788.cfg file with configuration files in
/usr/share/openocd/scripts. As of this writing, the configuration
files of interest were:
/usr/local/share/openocd/scripts/interface/openocd-usb.cfg
This is the configuration file for the Olimex ARM-USB-OCD
debugger. Select a different file if you are using some
other debugger supported by OpenOCD.
/usr/local/share/openocd/scripts/board/?
I don't see a board configuration file for the WaveShare
Open1788 board.
/usr/local/share/openocd/scripts/target/lpc1788.cfg
This is the configuration file for the the LPC1788 target.
It just sets up a few parameters then sources lpc17xx.cfg
/usr/local/share/openocd/scripts/target/lpc17xx.cfg
This is the generic LPC configuration for the LPC17xx
family. It is included by lpc1788.cfg.
NOTE: These files could also be located under /usr/share in some
installations. They could be most anywhwere if you are using a
windows version of OpenOCD.
configs/open1788/tools/open1788.cfg
This is simply openocd-usb.cfg, lpc1788.cfg, and lpc17xx.cfg
concatenated into one file for convenience. Don't use it
unless you have to.
There is also a script on the tools/ directory that I use to start
the OpenOCD daemon on my system called oocd.sh. That script will
probably require some modifications to work in another environment:
- Possibly the value of OPENOCD_PATH and TARGET_PATH
- It assumes that the correct script to use is the one at
configs/open1788/tools/open1788.cfg
Starting OpenOCD
Then you should be able to start the OpenOCD daemon as follows. This
assumes that you have already CD'ed to the NuttX build directory:
. ./setenv.sh
oocd.sh $PWD
The setenv.sh script is a convenience script that you may choose to
use or not. It simply sets up the PATH variable so that you can
automatically find oocd.sh. You could also do:
configs/open1788/tools/oocd.sh $PWD
Connecting GDB
Once the OpenOCD daemon has been started, you can connect to it via
GDB using the following GDB command:
arm-nuttx-elf-gdb
(gdb) target remote localhost:3333
NOTE: The name of your GDB program may differ. For example, with the
CodeSourcery toolchain, the ARM GDB would be called arm-none-eabi-gdb.
OpenOCD will support several special 'monitor' sub-commands. You can
use the 'monitor' (or simply 'mon') command to invoke these sub-
commands. These GDB commands will send comments to the OpenOCD monitor.
Here are a couple that you will need to use:
(gdb) monitor reset
(gdb) monitor halt
NOTES:
1. The MCU must be halted using 'monitor halt' prior to loading code.
2. 'monitor reset' will restart the processor after loading code.
3. The 'monitor' command can be abbreviated as just 'mon'.
After starting GDB, you can load the NuttX ELF file like this:
(gdb) mon halt
(gdb) load nuttx
NOTES:
1. NuttX should have been built so that it has debugging symbols
(by setting CONFIG_DEBUG_SYMBOLS=y in the .config file).
2. The MCU must be halted prior to loading code.
3. I find that there are often undetected write failures when using
the Olimex ARM-USB-OCD debugber and that if you start the program
with a bad FLASH failure, it will lock up OpenOCD. I usually
oad nuttx twice, restarting OpenOCD in between in order to assure
good FLASH contents:
(gdb) mon halt
(gdb) load nuttx
(gdb) mon reset
Exit GDB, kill the OpenOCD server, recycle power on the board,
restart the OpenOCD server and GDB, then:
(gdb) mon halt
(gdb) load nuttx
(gdb) mon reset
Other debuggers may not have these issues and such drastic steps may
not be necessary.
Loading Code with the ISP Board
===============================
Use can also load code onto the board using the WaveShare and the UART0
ISP/VCOM board. I use the FlashMagic program for Windows available here:
http://www.flashmagictool.com/ . It is so easy to use that no further
explanation should be necessary: Just select the LPC1788, the ISP COM
port, and the NuttX .hex file and program it.
CONFIGURATION
=============
ostest
------
This configuration directory, performs a simple OS test using
apps/examples/ostest.
NOTES:
1. This configuration uses the mconf-based configuration tool. To
change this configuration using that tool, you should:
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
and misc/tools/
b. Execute 'make menuconfig' in nuttx/ in order to start the
reconfiguration process.
2. Uses the older, OABI, buildroot toolchain. But that is easily
reconfigured:
CONFIG_ARMV7M_TOOLCHAIN_BUILDROOT=y : Buildroot toolchain
CONFIG_ARMV7M_OABI_TOOLCHAIN=y : Older, OABI toolchain
knsh
----
This is identical to the nsh configuration below except that NuttX
is built as a kernel-mode, monolithic module and the user applications
are built separately. Is is recommened to use a special make command;
not just 'make' but make with the following two arguments:
make pass1 pass2
In the normal case (just 'make'), make will attempt to build both user-
and kernel-mode blobs more or less interleaved. This actual works!
However, for me it is very confusing so I prefer the above make command:
Make the user-space binaries first (pass1), then make the the kernel-space
binaries (pass2)
NOTES:
1. This configuration uses the mconf-based configuration tool. To
change this configuration using that tool, you should:
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
and misc/tools/
b. Execute 'make menuconfig' in nuttx/ in order to start the
reconfiguration process.
2. Uses the older, OABI, buildroot toolchain. But that is easily
reconfigured:
CONFIG_ARMV7M_TOOLCHAIN_BUILDROOT=y : Buildroot toolchain
CONFIG_ARMV7M_OABI_TOOLCHAIN=y : Older, OABI toolchain
3. This configuration has DMA-based SD card support enabled by
default. That support can be disabled as follow:
CONFIG_LPC17_GPDMA=n : No DMA
CONFIG_ARCH_DMA=n
CONFIG_LPC17_SDCARD=n : No SD card driver
CONFIG_SDIO_DMA=n : No SD card DMA
CONFIG_MMCSD=n : No MMC/SD driver support
CONFIG_FS_FAT=n : No FAT file system support
4. At the end of the build, there will be several files in the top-level
NuttX build directory:
PASS1:
nuttx_user.elf - The pass1 user-space ELF file
nuttx_user.hex - The pass1 Intel HEX format file (selected in defconfig)
User.map - Symbols in the user-space ELF file
PASS2:
nuttx - The pass2 kernel-space ELF file
nuttx.hex - The pass2 Intel HEX file (selected in defconfig)
System.map - Symbols in the kernel-space ELF file
Loading these .elf files with OpenOCD is tricky. It appears to me
that when nuttx_user.elf is loaded, it destroys the the nuttx image
in FLASH. But loading the nuttx ELF does not harm the nuttx_user.elf
in FLASH. Conclusion: Always load nuttx_user.elf before nuttx.
Just to complicate matters, it is sometimes the case that you need
load objects twice to account for write failures. I have not yet
found a simple foolproof way to reliably get the code into FLASH.
5. Combining .hex files. If you plan to use the .hex files with your
debugger or FLASH utility, then you may need to combine the two hex
files into a single .hex file. Here is how you can do that.
a. The 'tail' of the nuttx.hex file should look something like this
(with my comments added):
$ tail nuttx.hex
# 00, data records
...
:10 9DC0 00 01000000000800006400020100001F0004
:10 9DD0 00 3B005A0078009700B500D400F300110151
:08 9DE0 00 30014E016D0100008D
# 05, Start Linear Address Record
:04 0000 05 0800 0419 D2
# 01, End Of File record
:00 0000 01 FF
Use an editor such as vi to remove the 05 and 01 records.
b. The 'head' of the nuttx_user.hex file should look something like
this (again with my comments added):
$ head nuttx_user.hex
# 04, Extended Linear Address Record
:02 0000 04 0801 F1
# 00, data records
:10 8000 00 BD89 01084C800108C8110208D01102087E
:10 8010 00 0010 00201C1000201C1000203C16002026
:10 8020 00 4D80 01085D80010869800108ED83010829
...
Nothing needs to be done here. The nuttx_user.hex file should
be fine.
c. Combine the edited nuttx.hex and un-edited nuttx_user.hex
file to produce a single combined hex file:
$ cat nuttx.hex nuttx_user.hex >combined.hex
Then use the combined.hex file with the to write the FLASH image.
If you do this a lot, you will probably want to invest a little time
to develop a tool to automate these steps.
nsh
---
Configures the NuttShell (nsh) located at examples/nsh. The
Configuration enables only the serial NSH interface.
NOTES:
1. This configuration uses the mconf-based configuration tool. To
change this configuration using that tool, you should:
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
and misc/tools//README.txt.
b. Execute 'make menuconfig' in nuttx/ in order to start the
reconfiguration process.
2. Uses the older, OABI, buildroot toolchain. But that is easily
reconfigured:
CONFIG_ARMV7M_TOOLCHAIN_BUILDROOT=y : Buildroot toolchain
CONFIG_ARMV7M_OABI_TOOLCHAIN=y : Older, OABI toolchain
3. This NSH has support for built-in applications enabled, however,
no built-in configurations are built in the defulat configuration.
4. This configuration has DMA-based SD card support enabled by
default. That support can be disabled as follow:
CONFIG_LPC17_GPDMA=n : No DMA
CONFIG_ARCH_DMA=n
CONFIG_LPC17_SDCARD=n : No SD card driver
CONFIG_SDIO_DMA=n : No SD card DMA
CONFIG_MMCSD=n : No MMC/SD driver support
CONFIG_FS_FAT=n : No FAT file system support
5. This configuration has been used for verifying SDRAM by modifying
the configuration in the following ways:
CONFIG_LPC17_EMC=y : Enable the EMC
CONFIG_LPC17_EXTDRAM=y : Configure external DRAM
CONFIG_LPC17_EXTDRAMSIZE=67108864 : DRAM size 2x256/8 = 64MB
CONFIG_SYSTEM_RAMTEST=y : Enable the RAM test built-in
In this configuration, the SDRAM is not added to heap and so is
not excessible to the applications. So the RAM test can be
freely executed against the SRAM memory beginning at address
0xa000:0000 (CS0).
6. This configuration has been used for verifying the touchscreen on
on the 4.3" LCD module.
a) As of this writing, this touchscreen is still not functional.
Rommel Marcelo has tracked this problem down to noise on the
PENIRQ interrupt. There are so many false interrupts that
the NuttX interrupt-driven touchscreen driver cannot be used.
Other compatible LCDs, however, may not have this issue.
b) You can enable the touchscreen by modifying the configuration
in the following ways:
Drivers:
CONFIG_INPUT=y : Enable support for input devices
CONFIG_INPUT_ADS7843E=y : Enable support for the XPT2048
CONFIG_ADS7843E_SPIDEV=1 : Use SSP1 for communication
CONFIG_SPI=y : Enable SPI support
CONFIG_SPI_EXCHANGE=n : exchange() method is not supported
System Type:
CONFIG_GPIO_IRQ=y : GPIO interrupt support
CONFIG_LPC17_SSP1=y : Enable support for SSP1
RTOS Features:
CONFIG_DISABLE_SIGNALS=n : Signals are required
Library Support:
CONFIG_SCHED_WORKQUEUE=y : Work queue support required
Applicaton Configuration:
CONFIG_EXAMPLES_TOUCHSCREEN=y : Enable the touchscreen built-int test
Defaults should be okay for related touchscreen settings. Touchscreen
debug output can be enabled with:
Build Setup:
CONFIG_DEBUG=y : Enable debug features
CONFIG_DEBUG_VERBOSE=y : Enable verbose debug output
CONFIG_DEBUG_INPUT=y : Enable debug output from input devices
c) You will also have to disable SD card support to use this test. The
SD card detect (CD) signal is on P0[13]. This signal is shared. It
is also used for MOSI1 and USB_UP_LED. The CD pin may be disconnected.
There is a jumper on board that enables the CD pin. OR, you can simply
remove the SD module so that it does not drive the CD pin.
Drivers:
CONFIG_MMCSD=n : No MMC/SD driver support
System Type:
CONFIG_LPC17_GPDMA=n : No DMA
CONFIG_LPC17_SDCARD=n : No SD card driver
CONFIG_SDIO_DMA=n : No SD card DMA
CONFIG_ARCH_DMA=n
File Systems:
CONFIG_FS_FAT=n : No FAT file system support
For touchscreen debug output:
Build Setup:
CONFIG_DEBUG=y
CONFIG_DEBUG_VERBOSE=y
CONFIG_DEBUG_INPUT=y
7. The button test (apps/examples/buttons) can be built-in by adding
the following options. See apps/examples/README.txt for further
information about the button test.
System Type:
CONFIG_GPIO_IRQ=y
Board Selection:
CONFIG_ARCH_BUTTONS=y
CONFIG_ARCH_IRQBUTTONS=y
Application Configuration:
CONFIG_EXAMPLES_BUTTONS=y
CONFIG_EXAMPLES_BUTTONS_MIN=0
CONFIG_EXAMPLES_BUTTONS_MAX=7
CONFIG_EXAMPLES_IRQBUTTONS_MIN=1
CONFIG_EXAMPLES_IRQBUTTONS_MAX=7
CONFIG_EXAMPLES_BUTTONS_NAME0="USER1"
CONFIG_EXAMPLES_BUTTONS_NAME1="USER2"
CONFIG_EXAMPLES_BUTTONS_NAME2="USER3"
CONFIG_EXAMPLES_BUTTONS_NAME3="JOYSTICK_A"
CONFIG_EXAMPLES_BUTTONS_NAME4="JOYSTICK_B"
CONFIG_EXAMPLES_BUTTONS_NAME5="JOYSTICK_C"
CONFIG_EXAMPLES_BUTTONS_NAME6="JOYSTICK_D"
CONFIG_EXAMPLES_BUTTONS_NAME7="JOYSTICK_CTR"
nxlines
-------
Configures the graphics example located at examples/nsh. This
configuration enables SDRAM to hold the LCD framebuffer and enables
the LPC178x LCD driver in order to support the WaveShare 4.3 inch TFT
panel.
NOTES:
1. This configuration uses the mconf-based configuration tool. To
change this configuration using that tool, you should:
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
and misc/tools//README.txt.
b. Execute 'make menuconfig' in nuttx/ in order to start the
reconfiguration process.
2. Uses the older, OABI, buildroot toolchain. But that is easily
reconfigured:
CONFIG_ARMV7M_TOOLCHAIN_BUILDROOT=y : Buildroot toolchain
CONFIG_ARMV7M_OABI_TOOLCHAIN=y : Older, OABI toolchain
3. In this configuration, the SDRAM is not added to heap but is
dedicated to supporting an LCD frame buffer at address 0xa0010000.
|