Questions: uboot kernel address for f9k1115v2

For Developers
1

Hi,

A while ago I posted about lede stop producing firmware for f9k1115v2 for master head builds. It was found that the kernel image since 4.9.X had become too big to fit in the 1408kb kernel partition.

While there is a PR against openwrt master that reduces kernel size by moving f9k1115v2 to tiny flash profile found here:

, I was trying to see if a regular firmware flash also refresh uboot boot argument (specifically the kernel address).

The flash layout is this:

f9k1115v2_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env),14464k(rootfs),1408k(kernel),64k(nvram)ro,64k(envram)ro,64k(art)ro,15872k@0x50000(firmware)

while that from belkin source code is this

boot\u-boot\include\configs\board955x.h:178:# define MTDPARTS_DEFAULT “mtdparts=ath-nor0:256k(u-boot),64k(u-boot-env),14464k(rootfs),1536k(uImage),64k(ART),16320k@0x0(all)”

So it seemed like openwrt created two separate partition stolen from the kernel partition ->
1408+64+64 = 1536kb

1)So here comes my first question - what are these two partitions doing here?

64k(nvram)ro,64k(envram)ro

If they are not neccesary we can get rid of them and have normal build until kernel size > 1536kb.

Looking at the bootlog:

Booting image at 9fe70000 ...

And the mtd partition layout for a device flashed with openwrt:

[ 0.790000] 0x0000002d0000-0x000000e70000 : "rootfs_data"
[ 0.800000] 0x000000e70000-0x000000fd0000 : "kernel"
[ 0.810000] 0x000000fd0000-0x000000fe0000 : "nvram"

So the kernel partition starts at 0xe70000 if 0x0 is the start of the flash, but uboot was booting from 0x9fe70000 which comes my second question:

2) Why is there a 0x9f000000 offset added to uboot's kernel address in boot argument?

This seems to suggest that flash actually starts at 0x9f000000 instead of 0x0 as seen from the cpu, is this interpretation correct? If so, what is the space before 0x9f000000?

Thanks!

2

I'm not an expert, but I'm also trying to understand uboot more and I think what you're experiencing is an 'offset'.

The way I see it, uboot sits at the top and see's all the addresses/buses available, and to it, it all starts at 0x00. Then it puts other things in at 0x01 etc all the way up to (in your case) 0x9f. At 0x9f, the flash addresses start, but uboot doesn't let the cpu see the rest of the memory space, so it makes it look to the cpu like the flash starts at 0x00.

Be very careful though - I think I got it wrong a few weeks ago and I think I managed to overwrite uboot by mistake and hard-bricked my device.

Tim

1 Like
3

I will build a new image removing read only flag for ubootenv partition, and include fw_ tools and check what it looks like there.