Usually, in embedded systems the NAND flash is partitioned in four parts:--

  1. A partition for the bootloader (here goes uboot.bin)
  2. A small partition where uboot saves its environment variables
  3. A partition for the kernel (here goes uImage.bin)
  4. A partition for the rootfs

Now i have few questions from my side :--

1> 32 bit ARM MCU have many external memory interfaces like DRAM & NAND or NOR flash connected to it. How wil our 32 bit ARM MCU will know from which address place on NAND to fetch the Uboot from ? And on which address in RAM to load the Uboot ?

2> In 8-bit MCU like AVR RESET vector address is 0x0000 and is in the inbuild FLASH memory. How the RESET vector is specified for 32 bit ARM MCU as it have many diffrent type of external memory interfaces connected to it.

3> In case of 32 bit ARM MCU, first Uboot will get inside RAM then it will load the compressed uimage in RAM then uboot will decompress the uIMage to LOADADDR. So to defining LOADADDR (uncompressed image address) do we have to take into consideration the space for (uboot itself + compressed uImage to be loaded into RAM) ? FOr uImage how we use to define the LOADADDR ?

4> Do linux uImage have rootfs embedded inside it or it is an seprate entity ? If rootfs is an seprate entity lying on NAND then how will kernel come to know from which address on NAND the rootfs is lying ?

  • Any one who can suggest on this ? – user6363 Sep 5 '15 at 1:49
  • Please post only one question at a time. But questions 1 and 2 are off-topic here. For question 1, it entirely depends on what's in the device ROM, so it's unanswerable anyway. For 2, the reset vector address can be set by any software running in kernel mode. – Gilles 'SO- stop being evil' Sep 5 '15 at 14:03

1) typically there will be an offset for each bootable interface defined in the reference manual. For example, you might be able to boot from memory mapped NOR, NAND, etc. NOR might be 0x1000, NAND 0x4000 for example. The reference manual chapter on booting will tell you.

2) see 1

3) Often, uboot cannot just "get inside RAM." This has to be done with a first stage bootloader. U-boot has it's SPL (secondary program loader) feature to do this. The job of this SPL is execute out of processor SRAM and to initialize the system DRAM so it is then usable to load the full U-boot executable. U-boot then will need the proper LOADADDR for the board/chip you are working with. U-boot does not decompress the kernel as its is booting. This is typically a job of the kernel itself for legacy reasons. Obviously your kernel should be able to fit into your memory, and you may need to make sure you are not overwriting other components (rootfs, device tree) when the kernel decompresses itself.

4) Either option exists and is valid. If the rootfs is separate, you'll need to know what type of filesystem it is. If it is an initramfs, you get to define where it is stored in raw NAND. If it is a persistant filesystem (ext4) then U-boot needs to know how to process the partition map. Once that is done, you actually pass the device path, not an Address into the kernel.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.