sunxi uboot MTD NAND boot

[Qiang Yu]

Hi guys,

Good news! The uboot can boot up on MTD nand. The boot0 is replaced by uboot SPL, then load uboot directly. The SPL and uboot all use my MTD nand driver. Code is here:

https://github.com/yuq/u-boot-sunxi/commits/sunxi-current

Let uboot use MTD driver is straight forword. But let SPL replace boot0 is not. boot0 lays in the first 128 pages of the nand flash chip. The first 64 pages are the same as the following 64 pages. I can't find raw boot0 in this area, so guess it is encrypted which I can't crack.

My tmp strategy is: replace boot0.bin in the pack tool provided by Allwinner with uboot SPL. Pack a firmware and burn into flash using livesuit. Then read out first 128 pages. The SPL will load the uboot image from the 1M offset. So I burn the dumped SPL to the begginning of the new flash, the uboot image to the 1M offset.

Here attaches the dumped 1M SPL image which is for 8K page chips. Other page size (2K, 4K) can use attached shell script to convert it.

Regards,

Qiang

[Qiang Yu]

PS. the uboot config is:

make CROSS_COMPILE=arm-linux-gnueabihf- EM6000_config

[Jari Helaakoski]

2013/4/3 Qiang Yu <yuq...@gmail.com>

Great! Have you found out where and how we can read DRAM parameters? So we could get rid of per board u-boot build..

-Jari

[Qiang Yu]

Do you mean the DDR part of the boot0 header? I dump and parse it from the original boot0 image and add it to SPL in tools/mksunxiboot.c.

--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Oliver Schinagl]

On 03-04-13 10:14, Jari Helaakoski wrote:

2013/4/3 Qiang Yu <yuq...@gmail.com>

PS. the uboot config is:

make CROSS_COMPILE=arm-linux-gnueabihf- EM6000_config

On Wed, Apr 3, 2013 at 3:41 PM, Qiang Yu <yuq...@gmail.com> wrote:

Hi guys,

Good news! The uboot can boot up on MTD nand. The boot0 is replaced by uboot SPL, then load uboot directly. The SPL and uboot all use my MTD nand driver. Code is here:

https://github.com/yuq/u-boot-sunxi/commits/sunxi-current

Amazing work. I assume it's a read-only driver and performance limited (that is fine)?

Let uboot use MTD driver is straight forword. But let SPL replace boot0 is not. boot0 lays in the first 128 pages of the nand flash chip. The first 64 pages are the same as the following 64 pages. I can't find raw boot0 in this area, so guess it is encrypted which I can't crack.

I don't think this is the case.

boot0 is read from the BROM and BROM is limited by 20k filesize (for MMC, so I assume the same restriction is for NAND aswell, why use boot0 then). I haven't found any encrpytion/decryption/load-more reference in boot0. boot0 code is actually quite simple. Also BROM is only 32k in size, which doesn't leave a lot of room for decryption.

My tmp strategy is: replace boot0.bin in the pack tool provided by Allwinner with uboot SPL. Pack a firmware and burn into flash using livesuit. Then read out first 128 pages. The SPL will load the uboot image from the 1M offset. So I burn the dumped SPL to the begginning of the new flash, the uboot image to the 1M offset.

Nice hack :D  some people smarter then me should look into this and see if we can do this without the hack.

So to summarize, you swap boot0.bin (64 pages) in the livesuit image; flash that, read 128 pages to have u-boot-spl + 64 pages of extra data? Maybe livesuit flashes boot0.bin twice? (like script.bin and script0.bin)

Now what I find odd, is that boot0.bin is 512 kiB (64 * 8k). u-boot-spl/boot0.bin should not be larger then 28 kiB. (or not much, unless nand driver takes up 500 kiB more then the mmc driver).
We know from hno's research [1] that stock nand boot0.bin is 24 kiB and boot1.bin is 221 kiB. So 512 kiB is way way to big for either/or. I don't know if we have a way to write anything there at the moment however, my knowledge lacks herein.

Hereattaches the dumped 1M SPL image which is for 8K page chips. Other page size (2K, 4K) can use attached shell script to convert it.

I will try to examine and see if I recognize anything there, could you attach your 'original' stock 1M of flash to compare?

Regards,

Qiang

Great! Have you found out where and how we can read DRAM parameters? So we could get rid of per board u-boot build..

Don't think that will be possible anytime soon. I think what livesuit does, is run a program in felmode on the SoC to detect some parameters and based on that inject dram_para into script.bin.

on the upside, there are some people trying to get fat/ext* support into u-boot SPL so that we can read dram para either from a partition. Once that is in place, dram_para can be loaded runtime and no more 'per board' SPL is needed.

But that requires some hackers and time to work on ;)

-Jari

--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[1] https://github.com/hno/Allwinner-Info/tree/master/BOOT/ICS/nand

[Oliver Schinagl]

On 03-04-13 10:58, Qiang Yu wrote:

Do you mean the DDR part of the boot0 header? I dump and parse it from the original boot0 image and add it to SPL in tools/mksunxiboot.c.

yes he meant that :)

remember, we have a10-meminfo-static to also dump the memory info from the registers (IF you boot original firmware, since at that point, the memory is setup correctly, or should be). But this should hopefully all go away.

What board are you developing/testing on? I guess not a cubieboard? Remember to add your board (http://linux-sunxi.org/Submitting_Boards) to our repository. The wikipage isn't done yet (far from) it only explains how to obtain meminfo (which should be enough with script.fex) but with that meminfo, you can make a u-boot patch (dram.c patch) so you don't have to hack your way around using mksunxiboot.c

[Qiang Yu]

On Wed, Apr 3, 2013 at 3:41 PM, Qiang Yu <yuq...@gmail.com> wrote:

Hi guys,

Good news! The uboot can boot up on MTD nand. The boot0 is replaced by uboot SPL, then load uboot directly. The SPL and uboot all use my MTD nand driver. Code is here:

https://github.com/yuq/u-boot-sunxi/commits/sunxi-current

Amazing work. I assume it's a read-only driver and performance limited (that is fine)?

It can do both read and write. I write it referencing the allwinner block nand driver. So it should reach the same performance as it in theory.

 

Let uboot use MTD driver is straight forword. But let SPL replace boot0 is not. boot0 lays in the first 128 pages of the nand flash chip. The first 64 pages are the same as the following 64 pages. I can't find raw boot0 in this area, so guess it is encrypted which I can't crack.

I don't think this is the case.

boot0 is read from the BROM and BROM is limited by 20k filesize (for MMC, so I assume the same restriction is for NAND aswell, why use boot0 then). I haven't found any encrpytion/decryption/load-more reference in boot0. boot0 code is actually quite simple. Also BROM is only 32k in size, which doesn't leave a lot of room for decryption.

I'm afraid NAND is not the same as MMC. I can't find the raw boot0 image in the dumped image.

 

My tmp strategy is: replace boot0.bin in the pack tool provided by Allwinner with uboot SPL. Pack a firmware and burn into flash using livesuit. Then read out first 128 pages. The SPL will load the uboot image from the 1M offset. So I burn the dumped SPL to the begginning of the new flash, the uboot image to the 1M offset.

Nice hack :D  some people smarter then me should look into this and see if we can do this without the hack.

So to summarize, you swap boot0.bin (64 pages) in the livesuit image; flash that, read 128 pages to have u-boot-spl + 64 pages of extra data? Maybe livesuit flashes boot0.bin twice? (like script.bin and script0.bin) 

Now what I find odd, is that boot0.bin is 512 kiB (64 * 8k). u-boot-spl/boot0.bin should not be larger then 28 kiB. (or not much, unless nand driver takes up 500 kiB more then the mmc driver).
We know from hno's research [1] that stock nand boot0.bin is 24 kiB and boot1.bin is 221 kiB. So 512 kiB is way way to big for either/or. I don't know if we have a way to write anything there at the moment however, my knowledge lacks herein.

I swap the boot0.bin in allwinner's firmware image build tool (lichee/buildroot/tools/pack/eGon/storage_media/nand/boot0.bin). It will use the fake boot0.bin to build a new firmware (include boot0.bin, boot1.bin, linux kernel, rootfs into a single file). Then I flash the whole firmware using livesuit. The dumped image shows the first 64 pages are the same as the following 64 pages, so it must be a backup not extra data.

The dumped image also shows no matter how large the flash chip page is, only the first 1024+96 bytes have valide data. So the data size is 64 * 1K = 64K

 

Hereattaches the dumped 1M SPL image which is for 8K page chips. Other page size (2K, 4K) can use attached shell script to convert it.

I will try to examine and see if I recognize anything there, could you attach your 'original' stock 1M of flash to compare?

Do you mean my boot0.bin (sunxi-spl.bin) used to generate the firmware? Here it is.

[Oliver Schinagl]

On 03-04-13 12:19, Qiang Yu wrote:

On Wed, Apr 3, 2013 at 3:41 PM, Qiang Yu <yuq...@gmail.com> wrote:

Hi guys,

Good news! The uboot can boot up on MTD nand. The boot0 is replaced by uboot SPL, then load uboot directly. The SPL and uboot all use my MTD nand driver. Code is here:

https://github.com/yuq/u-boot-sunxi/commits/sunxi-current

Amazing work. I assume it's a read-only driver and performance limited (that is fine)?

It can do both read and write. I write it referencing the allwinner block nand driver. So it should reach the same performance as it in theory.

I don't know if other u-boot drivers actually do write (leaving it out would save space) and it would always only read anyway?

 

Let uboot use MTD driver is straight forword. But let SPL replace boot0 is not. boot0 lays in the first 128 pages of the nand flash chip. The first 64 pages are the same as the following 64 pages. I can't find raw boot0 in this area, so guess it is encrypted which I can't crack.

I don't think this is the case.

boot0 is read from the BROM and BROM is limited by 20k filesize (for MMC, so I assume the same restriction is for NAND aswell, why use boot0 then). I haven't found any encrpytion/decryption/load-more reference in boot0. boot0 code is actually quite simple. Also BROM is only 32k in size, which doesn't leave a lot of room for decryption.

I'm afraid NAND is not the same as MMC. I can't find the raw boot0 image in the dumped image.

Yes, but as we see from hno's allwinner-info repository, where he extracted boot0, boot0 isn't that big.

 

My tmp strategy is: replace boot0.bin in the pack tool provided by Allwinner with uboot SPL. Pack a firmware and burn into flash using livesuit. Then read out first 128 pages. The SPL will load the uboot image from the 1M offset. So I burn the dumped SPL to the begginning of the new flash, the uboot image to the 1M offset.

Nice hack :D  some people smarter then me should look into this and see if we can do this without the hack.

So to summarize, you swap boot0.bin (64 pages) in the livesuit image; flash that, read 128 pages to have u-boot-spl + 64 pages of extra data? Maybe livesuit flashes boot0.bin twice? (like script.bin and script0.bin) 

Now what I find odd, is that boot0.bin is 512 kiB (64 * 8k). u-boot-spl/boot0.bin should not be larger then 28 kiB. (or not much, unless nand driver takes up 500 kiB more then the mmc driver).
We know from hno's research [1] that stock nand boot0.bin is 24 kiB and boot1.bin is 221 kiB. So 512 kiB is way way to big for either/or. I don't know if we have a way to write anything there at the moment however, my knowledge lacks herein.

I swap the boot0.bin in allwinner's firmware image build tool (lichee/buildroot/tools/pack/eGon/storage_media/nand/boot0.bin). It will use the fake boot0.bin to build a new firmware (include boot0.bin, boot1.bin, linux kernel, rootfs into a single file). Then I flash the whole firmware using livesuit. The dumped image shows the first 64 pages are the same as the following 64 pages, so it must be a backup not extra data.

So 512 kiB x2 (for backup).

The dumped image also shows no matter how large the flash chip page is, only the first 1024+96 bytes have valide data. So the data size is 64 * 1K = 64K

Why * 1 k now? You said it was 8 k page chips and you where talking about pages.
64 bytes for the bootloader sounds still too big, but possible. I forgot what our max was, I think I mentioned a 20k restriction above, but I have to correct myself, I think we had an additional 20 available.

Anyway, still, great job; this is a good starting point in any case.

[Qiang Yu]

On Wed, Apr 3, 2013 at 7:07 PM, Oliver Schinagl <olive...@schinagl.nl> wrote:

On 03-04-13 12:19, Qiang Yu wrote:

On Wed, Apr 3, 2013 at 3:41 PM, Qiang Yu <yuq...@gmail.com> wrote:

Hi guys,

Good news! The uboot can boot up on MTD nand. The boot0 is replaced by uboot SPL, then load uboot directly. The SPL and uboot all use my MTD nand driver. Code is here:

https://github.com/yuq/u-boot-sunxi/commits/sunxi-current

Amazing work. I assume it's a read-only driver and performance limited (that is fine)?

It can do both read and write. I write it referencing the allwinner block nand driver. So it should reach the same performance as it in theory.

I don't know if other u-boot drivers actually do write (leaving it out would save space) and it would always only read anyway?

SPL only read, but uboot may save env and do other write thing. 

 

Let uboot use MTD driver is straight forword. But let SPL replace boot0 is not. boot0 lays in the first 128 pages of the nand flash chip. The first 64 pages are the same as the following 64 pages. I can't find raw boot0 in this area, so guess it is encrypted which I can't crack.

I don't think this is the case.

boot0 is read from the BROM and BROM is limited by 20k filesize (for MMC, so I assume the same restriction is for NAND aswell, why use boot0 then). I haven't found any encrpytion/decryption/load-more reference in boot0. boot0 code is actually quite simple. Also BROM is only 32k in size, which doesn't leave a lot of room for decryption.

I'm afraid NAND is not the same as MMC. I can't find the raw boot0 image in the dumped image.

Yes, but as we see from hno's allwinner-info repository, where he extracted boot0, boot0 isn't that big.

 

My tmp strategy is: replace boot0.bin in the pack tool provided by Allwinner with uboot SPL. Pack a firmware and burn into flash using livesuit. Then read out first 128 pages. The SPL will load the uboot image from the 1M offset. So I burn the dumped SPL to the begginning of the new flash, the uboot image to the 1M offset.

Nice hack :D  some people smarter then me should look into this and see if we can do this without the hack.

So to summarize, you swap boot0.bin (64 pages) in the livesuit image; flash that, read 128 pages to have u-boot-spl + 64 pages of extra data? Maybe livesuit flashes boot0.bin twice? (like script.bin and script0.bin) 

Now what I find odd, is that boot0.bin is 512 kiB (64 * 8k). u-boot-spl/boot0.bin should not be larger then 28 kiB. (or not much, unless nand driver takes up 500 kiB more then the mmc driver).
We know from hno's research [1] that stock nand boot0.bin is 24 kiB and boot1.bin is 221 kiB. So 512 kiB is way way to big for either/or. I don't know if we have a way to write anything there at the moment however, my knowledge lacks herein.

I swap the boot0.bin in allwinner's firmware image build tool (lichee/buildroot/tools/pack/eGon/storage_media/nand/boot0.bin). It will use the fake boot0.bin to build a new firmware (include boot0.bin, boot1.bin, linux kernel, rootfs into a single file). Then I flash the whole firmware using livesuit. The dumped image shows the first 64 pages are the same as the following 64 pages, so it must be a backup not extra data.

So 512 kiB x2 (for backup).

The dumped image also shows no matter how large the flash chip page is, only the first 1024+96 bytes have valide data. So the data size is 64 * 1K = 64K

Why * 1 k now? You said it was 8 k page chips and you where talking about pages.

Yes 8K page. But only the first 1K+96B in a page contains valide data, others are 0xff. So do 2K and 4K page chips.

[Oliver Schinagl]

On 03-04-13 13:50, Qiang Yu wrote:

On Wed, Apr 3, 2013 at 7:07 PM, Oliver Schinagl <olive...@schinagl.nl> wrote:

On 03-04-13 12:19, Qiang Yu wrote:

On Wed, Apr 3, 2013 at 3:41 PM, Qiang Yu <yuq...@gmail.com> wrote:

Hi guys,

Good news! The uboot can boot up on MTD nand. The boot0 is replaced by uboot SPL, then load uboot directly. The SPL and uboot all use my MTD nand driver. Code is here:

https://github.com/yuq/u-boot-sunxi/commits/sunxi-current

Amazing work. I assume it's a read-only driver and performance limited (that is fine)?

It can do both read and write. I write it referencing the allwinner block nand driver. So it should reach the same performance as it in theory.

I don't know if other u-boot drivers actually do write (leaving it out would save space) and it would always only read anyway?

SPL only read, but uboot may save env and do other write thing.

True, well u-boot can have the bigger driver, SPL is limited to size :)

 

Let uboot use MTD driver is straight forword. But let SPL replace boot0 is not. boot0 lays in the first 128 pages of the nand flash chip. The first 64 pages are the same as the following 64 pages. I can't find raw boot0 in this area, so guess it is encrypted which I can't crack.

I don't think this is the case.

boot0 is read from the BROM and BROM is limited by 20k filesize (for MMC, so I assume the same restriction is for NAND aswell, why use boot0 then). I haven't found any encrpytion/decryption/load-more reference in boot0. boot0 code is actually quite simple. Also BROM is only 32k in size, which doesn't leave a lot of room for decryption.

I'm afraid NAND is not the same as MMC. I can't find the raw boot0 image in the dumped image.

Yes, but as we see from hno's allwinner-info repository, where he extracted boot0, boot0 isn't that big.

 

My tmp strategy is: replace boot0.bin in the pack tool provided by Allwinner with uboot SPL. Pack a firmware and burn into flash using livesuit. Then read out first 128 pages. The SPL will load the uboot image from the 1M offset. So I burn the dumped SPL to the begginning of the new flash, the uboot image to the 1M offset.

Nice hack :D  some people smarter then me should look into this and see if we can do this without the hack.

So to summarize, you swap boot0.bin (64 pages) in the livesuit image; flash that, read 128 pages to have u-boot-spl + 64 pages of extra data? Maybe livesuit flashes boot0.bin twice? (like script.bin and script0.bin) 

Now what I find odd, is that boot0.bin is 512 kiB (64 * 8k). u-boot-spl/boot0.bin should not be larger then 28 kiB. (or not much, unless nand driver takes up 500 kiB more then the mmc driver).
We know from hno's research [1] that stock nand boot0.bin is 24 kiB and boot1.bin is 221 kiB. So 512 kiB is way way to big for either/or. I don't know if we have a way to write anything there at the moment however, my knowledge lacks herein.

I swap the boot0.bin in allwinner's firmware image build tool (lichee/buildroot/tools/pack/eGon/storage_media/nand/boot0.bin). It will use the fake boot0.bin to build a new firmware (include boot0.bin, boot1.bin, linux kernel, rootfs into a single file). Then I flash the whole firmware using livesuit. The dumped image shows the first 64 pages are the same as the following 64 pages, so it must be a backup not extra data.

So 512 kiB x2 (for backup).

The dumped image also shows no matter how large the flash chip page is, only the first 1024+96 bytes have valide data. So the data size is 64 * 1K = 64K

Why * 1 k now? You said it was 8 k page chips and you where talking about pages.

Yes 8K page. But only the first 1K+96B in a page contains valide data, others are 0xff. So do 2K and 4K page chips.

Ok, I have some more info for you, but I'm not more the middle man :) you should drop by IRC some time http://linux-sunxi.org/IRC has a link to a webchat client, or you can use your favorite client to connect to irc.freenode.org and join #linux-sunxi.

That said, you cannot write boot0, because you don't use the 'random seed' that the BROM needs. Pages on flash aren't  encrypted, per say, but 'seeded'. The key isn't secret, the nand flash controller has it included, the BROM has the first word different though, 0x4a80. Anyway your u-boot-spl image must be stored the same way. That's what livesuit does. It distributes the data over the first 512k and since it's only 28k to write or so, only the first few kb are filled.

Anyway, we have an irc log at http://irclog.whitequark.org/linux-sunxi/2013-04-03 for today where you can read what slapin and I talked about. To summarize (the above) u-boot-spl is being read from BROM, and BROM reads the data 'randomly'. u-boot-spl CAN tell the flash controller to read u-boot 'randomly' as well (if it is stored in such way) but that is NOT a hard requirement. (The flash controller has a randomizer in hardware, and you can also do it in software like jffs2 does for example) I don't know the details if this works or if AW even uses it right now.

I don't know if/when hno will be on IRC, but slapin might be around the next few days/weekend. They have done some heavy research into the flash layer, so you really should talk to them :)

[Qiang Yu]

Thanks, help a lot.

--

[wpc...@gmail.com]

Hello, do you succeed in writing u-boot-spl.bin to nand ? I tried but failed. I even erase the first 64MB space of nand, but the boot0 & boot1 still exists. Can you help me out? Thanks.

[Henrik Nordström]

You need a kernel with NAND boot block area support for this.

[pc W]

Can you give me a copy? Thank you very much.

--
You received this message because you are subscribed to a topic in the Google Groups "linux-sunxi" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/linux-sunxi/KJ4YL_NzhWw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to linux-sunxi...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[aneox...@gmail.com]

среда, 3 апреля 2013 г., 13:41:21 UTC+6 пользователь Qiang Yu написал:

Could you please sell this livesuit image for me? I very need it, please mail me aneox...@gmail.com