Nboot writes Uboot to Kernel partition

Alex_H · Aug 30th 2013

It seems that Nboot stores Uboot in the Kernel partition and expects it to be there.

I had some odd behavior when updating the Kernel from Uboot so i did a little testing:

Code

U-Boot 2011.12 (Aug 28 2013 - 14:22:26)
CPU: Freescale VyBrid 600 family rev1.1 at 0 MHz
Board: Vybrid
DRAM: 256 MiB
WARNING: Caches not enabled
board_init: using internal PLL.
NAND: 128 MiB
MMC: FSL_SDHC: 0
Bad block table found at page 65472, version 0x01
Bad block table found at page 65408, version 0x01
In: serial
Out: serial
Err: serial
Net: FEC0, FEC1
Hit any key to stop autoboot: 0
Vybrid U-Boot > mtdparts
device nand0 <NAND>, # parts = 5
#: name size offset mask_flags
0: Nboot 0x00040000 0x00000000 1
1: Uboot 0x00080000 0x00040000 1
2: UbootEnv 0x00040000 0x000c0000 0
3: Kernel 0x00400000 0x00100000 0
4: TargetFS 0x07b00000 0x00500000 0
active partition: nand0,0 - (Nboot) 0x00040000 @ 0x00000000
defaults:
mtdids : nand0=NAND
mtdparts: mtdparts=NAND:256k(Nboot)ro,512k(Uboot)ro,256k(UbootEnv),4m(Kernel),-(TargetFS)

Display More

Erase the Uboot partition and everything is fine:

Code

Vybrid U-Boot > nand erase.part Uboot
NAND erase.part: device 0 offset 0x40000, size 0x80000
Erasing at 0xa0000 -- 100% complete.
OK
Vybrid U-Boot > reset
resetting ...
U-Boot 2011.12 (Aug 28 2013 - 14:22:26)
CPU: Freescale VyBrid 600 family rev1.1 at 0 MHz
Board: Vybrid
DRAM: 256 MiB
WARNING: Caches not enabled
board_init: using internal PLL.
NAND: 128 MiB
MMC: FSL_SDHC: 0
Bad block table found at page 65472, version 0x01
Bad block table found at page 65408, version 0x01
In: serial
Out: serial
Err: serial
Net: FEC0, FEC1
Hit any key to stop autoboot: 0

Display More

Erase the Kernel partition and Uboot is missing:

Code

Vybrid U-Boot > nand erase.part Kernel
NAND erase.part: device 0 offset 0x100000, size 0x400000
Erasing at 0x4e0000 -- 100% complete.
OK
Vybrid U-Boot > reset
resetting ...
No valid bootloader
F&S Nand Loader VN04 built Jul 17 2013 12:10:12
armStoneA5 Rev. 1.10
256MB RAM (1 chip) 128MB FLASH 396MHz no L2
booted primary image from page 0
Please select action
'd' -> Serial download of bootloader
'E' -> Erase flash
'B' -> Show bad blocks
Use NetDCUUsbLoader for USB download

Display More

As far as i can tell something is a little mixed up here or am i missing something?

A fast solution would probably be to cerate an additional partition for the Kernel.

Best regards
Alex

Alex_H · Sep 9th 2013

Just to give a little update here:

Obviously i had missed something. After reading the documentation again and again, i noticed it says VN01 for the NBoot version and mine is VN04. It seems the default partitioning in UBoot does not match with the VN04 NBoot configuration. Changing the partitioning had solved everything just fine.

Just wondering why those changes were made - it might be handy for my upcoming configuration.

fs-support_HK · Sep 9th 2013

Sorry for not answering earlier, but I was on vacation and today is my first day back.

Yes, the default flash layout has been changed. First we concentrated on the Cortex-A5 to get the main OS (Linux, WinCE) running. This was the state of pre-release V0.1 (with NBoot VN01). Later when we looked at the Cortex-M4, too, we noticed that we want to keep some space for a Cortex-M4 program that can directly be started from NBoot to have it up and running as quick as possible, before any OS is started. To keep it the same for WinCE and Linux, we want to store it directly behind NBoot itself. So U-Boot and all remaining partitions had to be moved to higher addresses. Unfortunately this required a visible change in NBoot, too (now VN04). So if you use the new NBoot together with the old U-Boot/Kernel from release V0.1, this will conflict. The version installed on the boards from the workshop in Leonberg already had the new layout, so there the new NBoot was already installed and also a newer U-Boot/Kernel/Rootfs than V0.1. But unfortunately we never put the sources of this workshop version of U-Boot/Kernel/Rootfs anywhere on our server, as we thought we'd manage the regular release earlier. But due to a necessary redesign of the PicoCOMA5, this took a little longer than expected. But there will be a regular fsvybrid release very soon, where U-Boot/Kernel and everything will match again correctly with the current NBoot. Sorry for the inconvenience.

This is the new default partition layout that we use in Linux right now.

Code

0x0000_0000 - 0x0001_FFFF: NBoot: NBoot image, primary copy (128KB)
0x0002_0000 - 0x0003_FFFF: NBoot: NBoot image, secondary copy (128KB)
0x0004_0000 - 0x000F_FFFF: Cortex-M4 image (768KB)
0x0010_0000 - 0x0017_FFFF: UBoot: U-Boot image (512KB)
0x0018_0000 - 0x001B_FFFF: UBootEnv: U-Boot environment (256KB)
0x001C_0000 - 0x003F_FFFF: UserDef: User defined data (2.25MB = 2304KB)
0x0040_0000 - 0x007F_FFFF: Kernel: Linux Kernel uImage (4MB)
0x0080_0000 - 0x07FF_FFFF: TargetFS: Root filesystem (120MB if 128MB)
0x0080_0000 - 0x3FFF_FFFF: TargetFS: Root filesystem (1016MB if 1GB)

Your F&S Support Team

fs-support_HK · Sep 30th 2013

Just as a quick note: The V1.0 release with the new flash layout is on our server for quite a few days now. Does this solve your problems?

Your F&S Support Team

Share