how to burn a uboot to board NAND flash
What i got from this link is that -- STx7111 Mboard - have some serial port which is capable to communicate with GDB. And from GDB we use to burn following file u-boot. Is this file burned in RAM or NAND flash by gdb ?
No, you did not read that article accurately.
GDB is merely used as the interface to the JTAG.
This first step is to load an executable (a copy of U-Boot) into RAM.
Do every controller have some serial port which is capable to communicate with GDB ?
Do every controller follow this approach to burn uboot bootloader into its NAND flash ?
You should avoid making (or trying to make) sweeping generalizations (in this and your other postings).
The features and capabilities of microcontrollers, microprocessors and SoCs ("controllers" is something else) is so broad that very few generalization can be made. Rarely is there only "one way" to perform these procedures.
In order the write a copy of U-Boot (or any file image) to NAND flash, there are two steps:
transfer the image file from the host PC (or some storage device) into local memory;
erase the NAND flash blocks, and then write the image file to NAND flash with ECC if required and cognizant of bad blocks.
These are not trivial steps, so a capable utility is needed. There are at least three approaches:
The microcontroller can be configured (via input pins) to a "receive and write an image file" mode on power-up. A hardcoded program in ROM will load the image and write it to the integrated flash.
The SoC ROM has a bootloader that has capabilities to communicate with a host PC over RS232 or USB, and can perform as the client side of a proprietary utility program. On the host PC you would run the server side of this utility program. This scheme would allow transferring files and reading & writing the target's memories. Atmel's SAM-BA utility fits into this category.
Use an open-source utility, such as U-Boot, that is configurable and extensible to support the external NAND flash and any other memory types on your board, and also has file transfer capabilities. The console for U-Boot is typically a UART/USART serial port, but can be configured to use a USB-to-RS232 adapter.
In the case of using a program like U-Boot to install programs in NAND, a chicken versus egg situation arises: how to get this program loaded in the first place? The two common approaches are:
a. Install the utility (i.e. U-Boot) on a SDcard with any required bootloader, and then boot the SoC from the SDcard. This assumes that the SoC has this booting capability, but this scheme requires the least operator skill.
b. Load the utility (i.e. U-Boot) using JTAG, such as Segger J-Link, which will allow you to transfer the image file to RAM (assuming that RAM has been properly initialized if necessary) and then start its execution. The J-Link can be interfaced using its own JLINK program or GDB.
Once U-Boot is resident and executing, you have all of its capabilities available. U-Boot cannot write itself to NAND flash, so you have to load another copy of U-Boot in order to write it to NAND (or any other type of) flash.
Understand U-Boot memory footprint
u-boot relocation on ARM architecture
Here is the whole sequence for two-stage boot process:
- ROM-code reads SPL (from
MLO
file on SD card) toCONFIG_SPL_TEXT_BASE
address. This address is usually in SRAM which doesn't need to be initialized to be functional (as opposed to RAM). ROM-code jumps to SPL code. - SPL configures RAM, then reads u-boot (from
u-boot.img
file on SD card) toCONFIG_SYS_TEXT_BASE
RAM address (which is usually in the begin of RAM) and run it - u-boot relocates itself to
gd->relocaddr
RAM address (which is usually in the end of RAM) and jumps to relocated code - Now we are ready to boot kernel
For single-stage boot you don't have SPL, usually only u-boot.bin
file is used. In that case you only have steps 3 and 4.
There are two cases regarding relocation (as described in doc/README.arm-relocation):
CONFIG_SYS_TEXT_BASE != gd->relocaddr
: relocation will be performedCONFIG_SYS_TEXT_BASE == gd->relocaddr
: relocation will not be performed
In your case you see that relocation was performed (as CONFIG_SYS_TEXT_BASE != gd->relocaddr
).
So, addressing your question:
Why U-Boot need those two offsets ?
The reason behind that relocation is described in u-boot ARM relocation task:
...we can measure the actual size of memory present on the board, and then relocate U-Boot to the very end of the RAM, leaving nearly the whole RAM usable as one big contiguous area for "applications" like loading Linux kernel, ramdisk, etc.
Indeed, if you look to code you can see that gd->relocaddr
is the end of RAM minus monitor code (U-Boot) size:
gd->relocaddr = gd->ram_top;
...
gd->relocaddr -= gd->mon_len;
Also some extra memory reserving can be performed. For example, on my platform (TI DRA7XX EVM), I can see next functions beeing called:
setup_dest_addr()
reserve_round_4k()
reserve_mmu()
reserve_uboot()
The actual relocation is done just after board_init_f()
call.
arch/arm/lib/crt0.S:
bl board_init_f
...
b relocate_code
arch/arm/lib/relocate.S:
ENTRY(relocate_code)
Now it's easy to answer your next question:
what is the real memory footprint of U-Boot ?
Before relocation U-Boot resides at CONFIG_SYS_TEXT_BASE
. After relocation U-Boot resides at gs->relocaddr
.
Regarding your last question:
where can I put my kernel to be sure that it will not overwrite something?
Since U-Boot was relocated to the end of RAM you can theoretically use any RAM address to put kernel to. But take a look at CONFIG_EXTRA_ENV_SETTINGS
definition in include/configs/zynq-common.h
:
"sdboot=if mmcinfo; then " \
"run uenvboot; " \
"echo Copying Linux from SD to RAM... && " \
"load mmc 0 ${kernel_load_address} ${kernel_image} && " \
"load mmc 0 ${devicetree_load_address} ${devicetree_image} && " \
"load mmc 0 ${ramdisk_load_address} ${ramdisk_image} && " \
"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}; " \
"fi\0" \
From there you can see that you should load kernel to ${kernel_load_address}
, which is 0x2080000
:
"kernel_load_address=0x2080000\0" \
See rest of that definition for other constants.
bdinfo command
You can find bdinfo
command useful: relocation address along with other useful information can be found using bdinfo
command from U-Boot shell. For example for DRA7XX EVM:
=> bdinfo
DRAM bank = 0x00000000
-> start = 0x80000000
-> size = 0x60000000
TLB addr = 0xDFFF0000
relocaddr = 0xDFF5D000
reloc off = 0x5F75D000
irq_sp = 0xDEF3CEE0
sp start = 0xDEF3CED0
From here you can see that:
- RAM starts at
0x80000000
- RAM size is
0x60000000
- ...so RAM end (
gd->ram_top
) is0x80000000 + 0x60000000 = 0xE0000000
- relocation address is
0xDFF5D000
- reserved memory for relocation is
0xE0000000 - 0xDFF5D000 = 652 KB
- monitor (U-Boot) size is approximately
TLB addr - relocaddr = 0xDFFF0000 - 0xDFF5D000 = 588 KB
See also:
[1] u-boot : Relocation
[2] what is the use of SPL (secondary program loader)
[3] commit that adds ARM relocation support to u-boot
SAMA5d31:The Uboot cannot be started
Modify the following
diff --git a/board/sama5d3xek/sama5d3xek.c b/board/sama5d3xek/sama5d3xek.c
index 57093b58..153749ce 100644
--- a/board/sama5d3xek/sama5d3xek.c
+++ b/board/sama5d3xek/sama5d3xek.c
@@ -75,12 +75,12 @@ static void ddramc_reg_config(struct ddramc_register *ddramc_config)
| AT91C_DDRC2_MD_DDR2_SDRAM);
ddramc_config->cr = (AT91C_DDRC2_NC_DDR10_SDR9
- | AT91C_DDRC2_NR_14
+ | AT91C_DDRC2_NR_13
| AT91C_DDRC2_CAS_3
| AT91C_DDRC2_DISABLE_RESET_DLL
| AT91C_DDRC2_ENABLE_DLL
| AT91C_DDRC2_ENRDM_ENABLE /* Phase error correction is enabled */
- | AT91C_DDRC2_NB_BANKS_8
+ | AT91C_DDRC2_NB_BANKS_4
| AT91C_DDRC2_NDQS_DISABLED /* NDQS disabled (check on schematics) */
| AT91C_DDRC2_DECOD_INTERLEAVED /* Interleaved decoding */
| AT91C_DDRC2_UNAL_SUPPORTED); /* Unaligned access is supported */
The begining and end adress of the Flash memory
You can determine the flash layout from the kernel boot command line. Either run the printenv
command in u-boot or boot into the existing kernel and look through the boot log. You need to find something like the following:
(There are plenty of guides on the internet, I took this one from https://finninday.net/wiki/index.php/Arduino_yun, your board may or may not be the same).
linino> printenv
bootargs=console=ttyATH0,115200 board=linino-yun mem=64M rootfstype=squashfs,jffs2 noinitrd mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,14656k(rootfs),1280k(kernel),64k(nvram),64k(art),15936k@0x50000(firmware)
bootcmd=bootm 0x9fea0000
This means there are the following partitions:
u-boot 0 to 256K (0x0 - 0x40000)
u-boot-env 256k to 320k (0x40000 - 0x50000)
rootfs (squashfs) 320k to 14976k (0x50000 - 0xea0000)
kernel 14976k to 16256k (0xea0000 - 0xfe0000)
nvram 16256k to 16320k (0xfe0000 - 0xff0000)
art 16320k to 16384k (0xff0000 - 0x1000000)
The rootfs partition is 14M, which is much larger than the rootfs image file (less than 8MB) so in theory you can move the kernel image at a lower address. For this you will need to modify the kernel boot line in the u-boot environment block (rootfs
aand kernel
partition sizes) and the bootcmd
parameter so the u-boot know where the new kernel is located.
Flash is mapped to 0x9f000000
so the value in the bootcmd
should be 0x9f000000
+ the offset of the kernel in bytes.
What I am not sure about is if there is an overlay filesystem for any persistent changes to the flash. Can you boot into the existing system and post the output of df -h
and cat /proc/mounts
?
Use U-boot to flash sd card image
Use TFTP to load the kernel image, and NFS to mount the root filesystem over the network.
Related Topics
Download Images from Google with Command Line
How to Check If Hadoop Daemons Are Running
Thread Utilization Profiling on Linux
What's the Difference Between Tempfile and Mktemp
How to Extract Characters Between the Delimiters Using Sed
Ubuntu - Run Command on Start-Up with "Sudo"
How to Clear the Line Number in Vim When Copying
What Does a Typical ./Configure Do in Linux
Why Does Zookeeper Not Use My Log4J.Properties File Log Directory
Help with Understanding a Very Basic Main() Disassembly in Gdb
Fast Concatenate Multiple Files on Linux
How to Get a List of All Valid Ip Addresses in a Local Network
Using Rsync Include and Exclude Options to Include Directory and File by Pattern
How to Automatically Start a Node.Js Application in Amazon Linux Ami on Aws