On 06/11/12 15:21, Imre Kaloz wrote:
> Hi,
>
> On Tue, 06 Nov 2012 14:13:26 +0100, Daniel Golle <dgo...@allnet.de> wrote:
>
> <snip>
>
>> U-Boot default env:
>> mtdparts=mtdparts=orion_nand:0x80000@0x0(uboot),0x20000@0x80000(uboot_env),-@0xa0000(rootfs)
>> vs.
>> arch/arm/mach-kirkwood/iconnect-setup.c:
>> static struct mtd_partition iconnect_nand_parts[] = {
>
> IMHO u-boot shouldn't do anything with mtdparts...
Unless you want to use ubi/ubifs to load the kernel, which I do want to use,
especially on large NAND (like the one of the iConnect, which already got 3
bad-blocks when it left the factory -- a well-known common phenomena on big NAND
chips and the reason why we got UBI)
See the whole uboot-environment to illustrate what I mean:
iconnect => printenv
baudrate=115200
bootargs_root=noinitrd ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs
bootcmd=setenv bootargs ${console} ${mtdparts} ${bootargs_root}; ubi part
rootfs; ubifsmount rootfs; ubifsload 0x800000 ${kernel}; bootm 0x800000
bootdelay=3
console=console=ttyS0,115200
ethact=egiga0
kernel=/boot/uImage
mtdids=nand0=orion_nand
mtdparts=mtdparts=orion_nand:0x80000@0x0(uboot),0x20000@0x80000(uboot_env),-@0xa0000(rootfs)
stderr=serial
stdin=serial
stdout=serial
So the kernel uImage is loaded from inside the filesystem, similar to GRUB
loading vmlinuz from an ext3 partition on x86.
Besides that, given that one might want to update u-boot itself or use
fw_printenv from inside OpenWrt, it makes sense to have the uboot/uboot-env
partitions in-sync.
Maybe even the opposite is true:
The kernel shouldn't have mtd-partitions built-in but rather rely on the cmdline
(like the way it works now on ar71xx; you can still have a patched built-in
cmdline, if needed)
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
