[U-Boot] UBI / UBIFS booting from NAND support

[U-Boot] UBI / UBIFS booting from NAND support

[Jose Miguel Sanchez Sanabria]

Hi everyone.

I was testing the booting process from NAND using an UBI/UBIFS image in an
igepv2 board.
However MLO tries to boot first kernel (falcon mode activated) and then
falls back to u-boot (as expected anyway I just wanted to load u-boot from
ubi) trying to load volume 0, but fails.

U-Boot SPL 2017.11-dirty (Nov 24 2017 - 14:29:26)
Trying to boot from NAND
UBI warning: LEB 0 of 1 is missing
UBI warning: Failed to load volume 3
UBI warning: LEB 0 of 1 is missing
UBI warning: Failed to load volume 3
UBI warning: Failed
Loading Linux failed, falling back to U-Boot.
UBI warning: LEB 0 of 1 is missing
UBI warning: Failed to load volume 0
UBI warning: LEB 0 of 1 is missing
UBI warning: Failed to load volume 0
UBI warning: Failed
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

I can however mount the ubi image but suspicious log appear:

u-boot:> ubifsmount ubi0:ubirootfs
UBIFS assert failed in ubifs_change_lp at 540
UBIFS assert failed in ubifs_release_lprops at 278
UBIFS assert failed in ubifs_change_lp at 540
UBIFS assert failed in ubifs_release_lprops at 278

This has to do with the discussion about ubifs null deference so I suppose
it should not affect much to write operation.

I would finally like to know if the ubi/ubifs support is functional; which
would mean I did not use the ubi tools correctly to create the ubi image.

[U-Boot] UBI / UBIFS booting from NAND support

[Ladislav Michl]

Dear Jose Miguel,

On Mon, Nov 27, 2017 at 11:45:11AM +0100, Jose Miguel Sanchez Sanabria wrote:
> Hi everyone.
> 
> I was testing the booting process from NAND using an UBI/UBIFS image in an
> igepv2 board.

I'm happy to see someone from ISEE being interested in mainline support
for their own product.

> However MLO tries to boot first kernel (falcon mode activated) and then
> falls back to u-boot (as expected anyway I just wanted to load u-boot from
> ubi) trying to load volume 0, but fails.

Due to size restrictions, MLO does contain only limited UBI functionality,
just enough to load image from static UBI volume.

> U-Boot SPL 2017.11-dirty (Nov 24 2017 - 14:29:26)
> Trying to boot from NAND
> UBI warning: LEB 0 of 1 is missing
> UBI warning: Failed to load volume 3
> UBI warning: LEB 0 of 1 is missing
> UBI warning: Failed to load volume 3
> UBI warning: Failed
> Loading Linux failed, falling back to U-Boot.
> UBI warning: LEB 0 of 1 is missing
> UBI warning: Failed to load volume 0
> UBI warning: LEB 0 of 1 is missing
> UBI warning: Failed to load volume 0
> UBI warning: Failed
> SPL: failed to boot from all boot devices
> ### ERROR ### Please RESET the board ###

As noted above, ubispl loader is rather limited and identifies volumes
by volume id. u-boot.img is expected to be found in vol_id=0, while linux
zImage in vol_id=3. Log above indicates there are no such volumes.
What does u-boot's command 'ubi info l' show?

> I can however mount the ubi image but suspicious log appear:
> 
> u-boot:> ubifsmount ubi0:ubirootfs

Now you are in u-boot, where different UBI implementation is used, so
you can identify volumes also by name.

> UBIFS assert failed in ubifs_change_lp at 540
> UBIFS assert failed in ubifs_release_lprops at 278
> UBIFS assert failed in ubifs_change_lp at 540
> UBIFS assert failed in ubifs_release_lprops at 278
> 
> This has to do with the discussion about ubifs null deference so I suppose
> it should not affect much to write operation.

Well, I do not use UBIFS in U-Boot at all. Just UBI to read and write volumes.

> I would finally like to know if the ubi/ubifs support is functional; which
> would mean I did not use the ubi tools correctly to create the ubi image.

You will find script I'm using to bring board up at the end of this mail.
But note, that 'fdt memory' is hacked a bit and proper implementaion is welcome:
https://lists.denx.de/pipermail/u-boot/2017-January/279823.html

Also note 'setenv fdtfile "${soc_family}-${board_name}.dtb"' line. That's also
not in mainline as it needs also board revision too and the way it is currently
done, we cannot distinguish rev B. and rev F. Unfortunately this article
http://labs.isee.biz/index.php/IGEP_Technology_devices_revisions#IGEP0020_revisions
does not explain, how all those numbers map to board revisions ISEE is using
in vendor code.

That said, I enabled UBIFS for IGEPv2 only localy to verify my ubifs_finddir
reimplementation, but as I was even unable to mount ubifs, original reporter
did not confirm that at least mount works for him and I run out of the time,
ubifs issue is still unresolved.

Best regards,
	ladis

echo "*** starting u-boot instalation script ***"
nandecc hw hamming
setenv has_onenand $?
# MLO ...
fatload mmc 0:1 $loadaddr MLO
if test $has_onenand -eq 0
then
	nand erase.part SPL
	nand write $fileaddr 0 $filesize
	nand write $fileaddr 20000 $filesize
	nand write $fileaddr 40000 $filesize
	nand write $fileaddr 60000 $filesize
	nandecc sw bch8
	nand read $loadaddr UBI 20000
	if test $? != 0
	then
		ubi detach
		nand erase.part UBI
	fi
else
	ubi part UBI
	ubi check loader
	if test $? != 0
	then
		ubi detach
		onenand erase
	else
		onenand erase 0 80000
	fi
	onenand write $fileaddr 0 20000
	onenand write $fileaddr 20000 20000
	onenand write $fileaddr 40000 20000
	onenand write $fileaddr 60000 20000
fi

# UBI volumes
ubi part UBI

echo "Creating UBI volumes..."
ubi check loader
if test $? != 0
then
	ubi createvol loader 100000 static 0
fi
ubi check config
if test $? != 0
then
	ubi createvol config 8000 static 1
fi
ubi check config_r
if test $? != 0
then
	ubi createvol config_r 8000 static 2
fi
ubi check kernel
if test $? != 0
then
	ubi createvol kernel 400000 static 3
fi
ubi check dtb
if test $? != 0
then
	ubi createvol dtb 40000 static 4
fi
ubi check rootfs
if test $? != 0
then
	ubi createvol rootfs
fi

setenv fdtfile "${soc_family}-${board_name}.dtb"

# U-Boot ...
fatload mmc 0:1 $loadaddr u-boot.img
ubi write $fileaddr loader $filesize
# ... and root filesystem first
fatload mmc 0:1 $loadaddr root.ubifs
ubi write $fileaddr rootfs $filesize
# now load FDT blob ...
fatload mmc 0:1 $fdtaddr $fdtfile
# and fix it...
setenv bootargs "console=ttyO2,115200n8 root=ubi0:rootfs ubi.mtd=1 rootfstype=ubifs rw quiet"
fdt addr $fdtaddr
fdt resize 1000
fdt memory
fdt boardsetup
fdt chosen
fdt set /chosen bootargs "${bootargs}"
# store FDT blob
ubi write $fileaddr dtb 40000
# ... and finaly kernel image
fatload mmc 0:1 $loadaddr zImage
ubi write $fileaddr kernel $filesize
# boot into shinny new system
bootz $loadaddr - $fdtaddr

[U-Boot] UBI / UBIFS booting from NAND support

[jsanabria]

El 27/11/17 a las 12:31, Ladislav Michl escribió:
> Dear Jose Miguel,
>
> On Mon, Nov 27, 2017 at 11:45:11AM +0100, Jose Miguel Sanchez Sanabria wrote:
>> Hi everyone.
>>
>> I was testing the booting process from NAND using an UBI/UBIFS image in an
>> igepv2 board.
> I'm happy to see someone from ISEE being interested in mainline support
> for their own product.
>
>> However MLO tries to boot first kernel (falcon mode activated) and then
>> falls back to u-boot (as expected anyway I just wanted to load u-boot from
>> ubi) trying to load volume 0, but fails.
> Due to size restrictions, MLO does contain only limited UBI functionality,
> just enough to load image from static UBI volume.
>
>> U-Boot SPL 2017.11-dirty (Nov 24 2017 - 14:29:26)
>> Trying to boot from NAND
>> UBI warning: LEB 0 of 1 is missing
>> UBI warning: Failed to load volume 3
>> UBI warning: LEB 0 of 1 is missing
>> UBI warning: Failed to load volume 3
>> UBI warning: Failed
>> Loading Linux failed, falling back to U-Boot.
>> UBI warning: LEB 0 of 1 is missing
>> UBI warning: Failed to load volume 0
>> UBI warning: LEB 0 of 1 is missing
>> UBI warning: Failed to load volume 0
>> UBI warning: Failed
>> SPL: failed to boot from all boot devices
>> ### ERROR ### Please RESET the board ###
> As noted above, ubispl loader is rather limited and identifies volumes
> by volume id. u-boot.img is expected to be found in vol_id=0, while linux
> zImage in vol_id=3. Log above indicates there are no such volumes.
> What does u-boot's command 'ubi info l' show?
>
Heres the log of ubi info :

Volume information dump:
         vol_id          0
         reserved_pebs   82
         alignment       1
         data_pad        0
         vol_type        4
         name_len        9
         usable_leb_size 129024
         used_ebs        5
         used_bytes      539424
         last_eb_bytes   23328
         corrupted       0
         upd_marker      0
         name            ubirootfs
Volume information dump:
         vol_id          2147479551
         reserved_pebs   2
         alignment       1
         data_pad        0
         vol_type        3
         name_len        13
         usable_leb_size 129024
         used_ebs        2
         used_bytes      258048
         last_eb_bytes   2
         corrupted       0
         upd_marker      0
         name            layout volume


I created with:

ubi create ubirootfs 0xA00000 static 0

I just wanted a volume of 10 MiB (as I only pretend to load u-boot from it for now) so that went pretty good.

>> I can however mount the ubi image but suspicious log appear:
>>
>> u-boot:> ubifsmount ubi0:ubirootfs
> Now you are in u-boot, where different UBI implementation is used, so
> you can identify volumes also by name.

I was mounting only to see the correct files were there (u-boot.img and 
uEnv.txt)

>> UBIFS assert failed in ubifs_change_lp at 540
>> UBIFS assert failed in ubifs_release_lprops at 278
>> UBIFS assert failed in ubifs_change_lp at 540
>> UBIFS assert failed in ubifs_release_lprops at 278
>>
>> This has to do with the discussion about ubifs null deference so I suppose
>> it should not affect much to write operation.
> Well, I do not use UBIFS in U-Boot at all. Just UBI to read and write volumes.
>
Ahh I see I was trying to "ubi write" onto volume the ubifs image which 
contained the (u-boot.img and uEnv.txt), but if I do like on your script 
(writing directly the u-boot.img and uEnv.txt) onto the volume it works 
perfectly.
>> I would finally like to know if the ubi/ubifs support is functional; which
>> would mean I did not use the ubi tools correctly to create the ubi image.
> You will find script I'm using to bring board up at the end of this mail.
> But note, that 'fdt memory' is hacked a bit and proper implementaion is welcome:
> https://lists.denx.de/pipermail/u-boot/2017-January/279823.html
>
> Also note 'setenv fdtfile "${soc_family}-${board_name}.dtb"' line. That's also
> not in mainline as it needs also board revision too and the way it is currently
> done, we cannot distinguish rev B. and rev F. Unfortunately this article
> http://labs.isee.biz/index.php/IGEP_Technology_devices_revisions#IGEP0020_revisions
> does not explain, how all those numbers map to board revisions ISEE is using
> in vendor code.
thanks for reporting I'll keep and eye on this later.
> That said, I enabled UBIFS for IGEPv2 only localy to verify my ubifs_finddir
> reimplementation, but as I was even unable to mount ubifs, original reporter
> did not confirm that at least mount works for him and I run out of the time,
> ubifs issue is still unresolved.
>
> Best regards,
> 	ladis
I could mount ubifs using ubifsmount command but there were a bit of 
warnings and then after trying to boot the spl did not find volume at all.

Thank you for your time.
>
> echo "*** starting u-boot instalation script ***"
> nandecc hw hamming
> setenv has_onenand $?
> # MLO ...
> fatload mmc 0:1 $loadaddr MLO
> if test $has_onenand -eq 0
> then
> 	nand erase.part SPL
> 	nand write $fileaddr 0 $filesize
> 	nand write $fileaddr 20000 $filesize
> 	nand write $fileaddr 40000 $filesize
> 	nand write $fileaddr 60000 $filesize
> 	nandecc sw bch8
> 	nand read $loadaddr UBI 20000
> 	if test $? != 0
> 	then
> 		ubi detach
> 		nand erase.part UBI
> 	fi
> else
> 	ubi part UBI
> 	ubi check loader
> 	if test $? != 0
> 	then
> 		ubi detach
> 		onenand erase
> 	else
> 		onenand erase 0 80000
> 	fi
> 	onenand write $fileaddr 0 20000
> 	onenand write $fileaddr 20000 20000
> 	onenand write $fileaddr 40000 20000
> 	onenand write $fileaddr 60000 20000
> fi
>
> # UBI volumes
> ubi part UBI
>
> echo "Creating UBI volumes..."
> ubi check loader
> if test $? != 0
> then
> 	ubi createvol loader 100000 static 0
> fi
> ubi check config
> if test $? != 0
> then
> 	ubi createvol config 8000 static 1
> fi
> ubi check config_r
> if test $? != 0
> then
> 	ubi createvol   8000 static 2
> fi
> ubi check kernel
> if test $? != 0
> then
> 	ubi createvol kernel 400000 static 3
> fi
> ubi check dtb
> if test $? != 0
> then
> 	ubi createvol dtb 40000 static 4
> fi
> ubi check rootfs
> if test $? != 0
> then
> 	ubi createvol rootfs
> fi
>
> setenv fdtfile "${soc_family}-${board_name}.dtb"
>
> # U-Boot ...
> fatload mmc 0:1 $loadaddr u-boot.img
> ubi write $fileaddr loader $filesize
> # ... and root filesystem first
> fatload mmc 0:1 $loadaddr root.ubifs
> ubi write $fileaddr rootfs $filesize
> # now load FDT blob ...
> fatload mmc 0:1 $fdtaddr $fdtfile
> # and fix it...
> setenv bootargs "console=ttyO2,115200n8 root=ubi0:rootfs ubi.mtd=1 rootfstype=ubifs rw quiet"
> fdt addr $fdtaddr
> fdt resize 1000
> fdt memory
> fdt boardsetup
> fdt chosen
> fdt set /chosen bootargs "${bootargs}"
> # store FDT blob
> ubi write $fileaddr dtb 40000
> # ... and finaly kernel image
> fatload mmc 0:1 $loadaddr zImage
> ubi write $fileaddr kernel $filesize
> # boot into shinny new system
> bootz $loadaddr - $fdtaddr

[U-Boot] UBI / UBIFS booting from NAND support

[Heiko Schocher]

Hello Jose,

Am 27.11.2017 um 11:45 schrieb Jose Miguel Sanchez Sanabria:
> Hi everyone.
> 
> I was testing the booting process from NAND using an UBI/UBIFS image in an
> igepv2 board.
> However MLO tries to boot first kernel (falcon mode activated) and then
> falls back to u-boot (as expected anyway I just wanted to load u-boot from
> ubi) trying to load volume 0, but fails.
> 
> U-Boot SPL 2017.11-dirty (Nov 24 2017 - 14:29:26)
> Trying to boot from NAND
> UBI warning: LEB 0 of 1 is missing
> UBI warning: Failed to load volume 3
> UBI warning: LEB 0 of 1 is missing
> UBI warning: Failed to load volume 3
> UBI warning: Failed
> Loading Linux failed, falling back to U-Boot.
> UBI warning: LEB 0 of 1 is missing
> UBI warning: Failed to load volume 0
> UBI warning: LEB 0 of 1 is missing
> UBI warning: Failed to load volume 0
> UBI warning: Failed
> SPL: failed to boot from all boot devices
> ### ERROR ### Please RESET the board ###
> 
> I can however mount the ubi image but suspicious log appear:
> 
> u-boot:> ubifsmount ubi0:ubirootfs
> UBIFS assert failed in ubifs_change_lp at 540
> UBIFS assert failed in ubifs_release_lprops at 278
> UBIFS assert failed in ubifs_change_lp at 540
> UBIFS assert failed in ubifs_release_lprops at 278
> 
> This has to do with the discussion about ubifs null deference so I suppose
> it should not affect much to write operation.
> 
> I would finally like to know if the ubi/ubifs support is functional; which
> would mean I did not use the ubi tools correctly to create the ubi image.

I must admit, I have currently no working testsetup. I try to
reactivate my automated tbot tests [1] at the end of the week.

bye,
Heiko
[1] http://xeidos.ddns.net/buildbot/builders/ari_ubi
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: hs at denx.de

[U-Boot] UBI / UBIFS booting from NAND support

[Ladislav Michl]

On Mon, Nov 27, 2017 at 03:53:27PM +0100, jsanabria wrote:
> I could mount ubifs using ubifsmount command but there were a bit of
> warnings and then after trying to boot the spl did not find volume at all.

SPL is not supposed to load kernel from UBIFS (filesystem), but directly from
UBI volume. On IGEPs U-Boot expects these volumes (shrinked):
=> ubi info l
Volume information dump:
        vol_id          0
        name            loader
Volume information dump:
        vol_id          1
        name            config
Volume information dump:
        vol_id          2
        name            config_r
Volume information dump:
        vol_id          3
        name            kernel
Volume information dump:
        vol_id          4
        name            dtb
Volume information dump:
        vol_id          5
        name            rootfs

In falcon mode SPL tries to load kernel and dtb, both identified by vol_id,
hence those have to be 3 and 4. If that fails, it loads u-boot image from
vol_id 0. Volumes 1 and 2 are used to store u-boot environment [*].
While there's also vol_id 5, u-boot is not concerned here, it just pass
information about rootfs to kernel.

Speaking about this, it would be nice to have it documented somewhere...

[*] There's bug in UBI env code. It just hangs, if you boot from MMC and flash
still contains vendor instalation (1bit hamming ecc and jffs2). I'll fix that
one day, but if you have time, any help welcome.

Best regards,
	ladis