Skip to main content
added 14 characters in body
Source Link
user6363
  • 191
  • 2
  • 6

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

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

  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 ?

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

A partition for the bootloader (here goes uboot.bin) A small partition where uboot saves its environment variables A partition for the kernel (here goes uImage.bin) 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 ?

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 ?

Source Link
user6363
  • 191
  • 2
  • 6

uboot & uImage & linux boot process

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

A partition for the bootloader (here goes uboot.bin) A small partition where uboot saves its environment variables A partition for the kernel (here goes uImage.bin) 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 ?