new uboot version 3.4.25

[pingtoo]

BTW: whether bootm 0x00800000 or bootm 0x008000000 makes no difference

I'm really getting confused: I find various versions in the Wikis, e.g.

http://www.plugcomputer.org/plugwiki/index.php/U-Boot_Quick_Reference
http://www.plugcomputer.org/plugwiki/index.php/External_Hard_Drives
http://computingplugs.com/index.php/Booting_entirely_off_an_external_USB_device
http://www.cyrius.com/debian/kirkwood/sheevaplug/unpack.html

Or does it depend on whether it's NAND, USB or SD?

However, either a get a "Bad Magic Number" error (bootm 0x00800000)
ot the "Bad Data CRC" error (bootm 0x008000000)

Unless uboot interpreter miss interpret the hex code they are different, because they refer to different memory regions. hence difference error messages, the "Bad Magic Number" is refer at header of the region when starter can not find the exact right sequence of hex code of uboot image wrapper. The "Bad Data CRC" refer to at memory region have correct header however in the header there is recorded CRC checksum from build time which differ from run time checksum so the starter report this error and refuse to start it.
The linux kernel need to be load into memory completely before it can be started so the ext2load read from storage (SD,NAND,USB) into main memory then the bootm try to start it.

[rooster]

hi ccp,

try to load two different images consecutively see if you will get any error

You mean perform the ext2load twice in a row? if so I had no problem with this.

Regarding the SD partition format, did you have problems with EXT2 or FAT16, I am still questioning what FS types give you error, I want to have the same setup as you have (though I do not have the same SD).

[odoll]

The linux kernel need to be load into memory completely before it can be started so the ext2load read from storage (SD,NAND,USB) into main memory then the bootm try to start it.

But isn't that exactly what confuses me!?! I again made a small test with 4 ext2load / bootm combinations, both for uboot 3.4.23 and 3.4.27 (nothing changed else!). I call them x:y where x stands for the number of trailing "0"s in ext2load command and y for the number of trailing zeros in bootm statement.

With 3.4.23 all combinations except for the first (6:5) boot the Debian from SD
With 3.4.27 all combinations except for the first (6:5) give a "Bad Data CRC".

For both uboot 3.4.23 and 3.4.27 the combination 6:5 gives a Bad Magic Number (see txt-files attached).

[pingtoo]

hi ccp,

try to load two different images consecutively see if you will get any error

You mean perform the ext2load twice in a row? if so I had no problem with this.

Regarding the SD partition format, did you have problems with EXT2 or FAT16, I am still questioning what FS types give you error, I want to have the same setup as you have (though I do not have the same SD).

Yes, I mean do ext2load twice but be sure with two different image may be load it to two different location too.

As of partition format, I having problem with both EXT2 and FAT (type "c" which is "WIN95 ..." reported by fdisk) except the symptoms are different, with EXT2 the ext2load does not report any error, however the subsequent command in a run macro will not be executed example

Code:

###
##### Note made up code.
###
Mavell>> printenv my_two_command_macro
my_two_command_macro=run load_kernel load_initrd
Marvell>> printenv load_kernel
load_kernel=ext2load mmc 0 0x02000000 /uImage
Marvell>> printenv load_initrd
load_initrd=ext2load mmc 0 0x01100000 /uInitramfs

now in 3.4.23 it will show

Code:

Marvell>> run my_two_command_macro

xxxxxxx bytes read

xxxxxxx bytes read

However when the same setup in 3.4.27 it will show

Code:

Marvell>> run my_two_command_macro

xxxxxxx bytes read

That's it, it will not run the load_initrd and if I run them seperately both will report the "xxxxxx bytes read" messages but when bootm it report "BAD CRC".

Now if I reformat the SD to FAT in 3.4.27 the error become

Code:

reading /uImage
curclust: 0x00000000 fatsize=16
Invalid FAT entry
696320 bytes read
reading /uInitramfs
curclust: 0x00000000 fatsize=16
Invalid FAT entry

598016 bytes read

So it will be pretty interest to me to find out why the changes bring out this problem.

Regards,

ccp.

[pingtoo]

The linux kernel need to be load into memory completely before it can be started so the ext2load read from storage (SD,NAND,USB) into main memory then the bootm try to start it.

But isn't that exactly what confuses me!?! I again made a small test with 4 ext2load / bootm combinations, both for uboot 3.4.23 and 3.4.27 (nothing changed else!). I call them x:y where x stands for the number of trailing "0"s in ext2load command and y for the number of trailing zeros in bootm statement.

With 3.4.23 all combinations except for the first (6:5) boot the Debian from SD
With 3.4.27 all combinations except for the first (6:5) give a "Bad Data CRC".

For both uboot 3.4.23 and 3.4.27 the combination 6:5 gives a Bad Magic Number (see txt-files attached).

Your experiment is very interesting. it appear linux did not touch where it load initially so the memory content was same. this also lead to a interest observation, in the bootm command the 0x00800000(5 zeros) and 0x08000000(6 zeros) seems to go to same real memory address This could be several reason, the u-boot interpreter have bug, it miss interpret the number or u-boot re-remap the memory or it could be some kind of hardware decoding scheme. Anyway I am not a hardware person so that could be just a wild guess. I will have the look at uboot source code to see if it was a bug.

You also help me prove that in 3.4.23 using SD is better then in 3.4.27. since all of you 3.4.27 test report "BAD CRC".

Thanks for the feedback!

Regards,

ccp

[rooster]

odol,

Have you noticed that bot uboot versions the mmcinit gives some error?
Have you tried another SD card?

[pingtoo]

The linux kernel need to be load into memory completely before it can be started so the ext2load read from storage (SD,NAND,USB) into main memory then the bootm try to start it.

But isn't that exactly what confuses me!?! I again made a small test with 4 ext2load / bootm combinations, both for uboot 3.4.23 and 3.4.27 (nothing changed else!). I call them x:y where x stands for the number of trailing "0"s in ext2load command and y for the number of trailing zeros in bootm statement.

With 3.4.23 all combinations except for the first (6:5) boot the Debian from SD
With 3.4.27 all combinations except for the first (6:5) give a "Bad Data CRC".

For both uboot 3.4.23 and 3.4.27 the combination 6:5 gives a Bad Magic Number (see txt-files attached).

Hi,

After some investigate in source code I just realize what happen in your test in purely coincidental. Here is what happen, first you must agree/understand how linux kernel work during the boot process. the uboot loader place kernel at some memory location, then the bootm command try to start the kernel. the started kernel first thing is decompress/relocate itself to address 0x8000 and start running from there.

OK, now in your test (.23 or .27 is irrelevant since you use same sequence) your first did the "6:5" test which mean you load kernel image at 0x08000000 but try to start at 0x00800000 which failed with "Bad magic" which is understandable since you did not load kernel image at the 0x00800000 location. Next test "5:5" you load kernel image at 0x00800000 then bootm which successfully verify a kernel image did located at 0x00800000 since this time you did loaded it at right location. Now the Interested part begin the third "5:6" test, since you request load to 0x00800000 but try to boot on 0x08000000 this success is because your first "6:5" already load a copy at 0x08000000 I believe this is the reason why it work. So apparently the plug and/or linux did not scrub the loaded region after each reboot/reset.

If you still games, we can try this, do the same test sequence(6:5,5:5,5:6,6:6), only in between test you insert this

Code:

Marvell>> mw.b 0x08000000 0 0x400000
Marvell>> mw.b 0x00800000 0 0x400000

I think this will show you why your load command and bootm command must match.

ccp

[rooster]

Hi cpp,

I placed to files on my SD ext2 partition and read both of them to different addresses with no problems.
How did you burn the uboot? via installer?

From your uboot command I assume you have no partition on the SD and it is formatted to EXT, if you access a partition on the SD you would do the following:

ext2load mmc 0:1 0x1100000 /libc-2.7.so

[odoll]

If you still games, we can try this, do the same test sequence(6:5,5:5,5:6,6:6), only in between test you insert this

@ccp: Planning to do some more testing as advised, but I spent this morning to prepare some SD-Cards for another test:

Have you noticed that bot uboot versions the mmcinit gives some error?
Have you tried another SD card?

@rooster: yes, I noted the error, however as I get it either with 2.4.23 and 2.4.27 I didn't paid it too much attention, so far.

I hoped that the issue might be related to SD vs SDHC cards, but I tested a few this morning, which makes me think it doesn't.

I just noted that the error message doesn't show up if I use an SDHC (alike) card.

Summary: I cloned my working Debian RFS used on my test plug to a couple of other SDs (see attached jpg; only one still had a copy of the Ubuntu FS from my primary plug).

As with uboot 2.4.23 all work, as with uboot 2.4.27 all get a "Bad Data CRC" and they fall back to the kernel in NAND (see attached txt-files).

If you want to play around with my image: I made one a couple of days ago for a friend and put onto a network share. I can send you details if just like, just contact me.

Would it be possible to build and send me some (four) 2.3.24 flavors, each just adding one of the four fixes you made from .23 -> .24?

  U-boot 3.4.24
  =============
  -) Fixed in mv_main.c the initialization of nandEnvBase from "" assignment of the env variable which caused wrong display of "" in the mmcinit command to strcpy.
  -) Fixed nand mark bad function in nand_base.c to support non sector aligned addresses.
  -) Changed device number 1155 to 6282
  -) Fixed in nand_base.c the string assignments to nandEcc parameter which caused it to overflow into other strings.

 Thus I could at least identify with fix introduces the behavior I see.

[pingtoo]

Hi cpp,

I placed to files on my SD ext2 partition and read both of them to different addresses with no problems.
How did you burn the uboot? via installer?

From your uboot command I assume you have no partition on the SD and it is formatted to EXT, if you access a partition on the SD you would do the following:

ext2load mmc 0:1 0x1100000 /libc-2.7.so

Actually all my SD card are partitioned. I will give it a try on .27 with your suggestion to see if that make any difference. It is my understanding that the device number specification when missing the colon portion it will always assume partition 1 anyway.

Funny you ask the question about how the .27 get transfer to plug. I was a bit surprise it seems to be making different, I know I tried one time using bubt, the error condition was different I think, in this case it will load both kernel and initramfs but it just fail to boot (not remember what was the error any more) then subsequently I just use installer method.

[rooster]

pingtoo,

There is a big difference between installing uboot via bubt and the installer.
Installer burns predefined uboot env which might have changed since the installer was released, I suggest you perform bubt and make sure to erase old env (save them aside and set them afterward).

Another way could be to use the installer and after you finish perform resetenv.

I have not performed diff between the default env of both versions but it could be that there are some changes that might shed some light regarding some issues people are having with the new version.

[odoll]

If you still games, we can try this, do the same test sequence(6:5,5:5,5:6,6:6), only in between test you insert this

Code:

Marvell>> mw.b 0x08000000 0 0x400000
Marvell>> mw.b 0x00800000 0 0x400000

I think this will show you why your load command and bootm command must match.

yep, you're right - unfortunately my sequence wasn't the best one to go with. I'll cleared the ram as advised between the tests now and the result is as you expected.

[pingtoo]

If you still games, we can try this, do the same test sequence(6:5,5:5,5:6,6:6), only in between test you insert this

Code:

Marvell>> mw.b 0x08000000 0 0x400000
Marvell>> mw.b 0x00800000 0 0x400000

I think this will show you why your load command and bootm command must match.

yep, you're right - unfortunately my sequence wasn't the best one to go with. I'll cleared the ram as advised between the tests now and the result is as you expected.

Hi odoll,
I hope your did not take it offense, I don't mean to go out to prove your are wrong. I was just puzzled by that some how 0x0080000 and 0x08000000 work same way which totally against my understanding of the command argument so I thought we found a bug of some sort. anyway I hope you now have a working system.

Happy Holiday

BTW, I posted  my uboot env. setup you may found it interest for testing/development.

pingtoo

[odoll]

I hope your did not take it offense ...

no, sure, np. Just happy to understand what I'm doing.

BTW: did another test with 3.4.23 vs. 3.4.27 and an SD formatted with FAT. With this .27 also has an issue though it looks a bit different. The fatload command goes wrong with .27 already (see attached file).

Saw you posted a startup script, but I didn't had time to look at it, yet. However will do for sure. Anyway I think the script won't work around the issue some of use are facing booting from SD since uboot 3.4.24!?

[pingtoo]

My test in .23/.27

Hi rootster, odoll

In summary for booting from SD best use vfat, it work in all condition.

My test include downloaded .23 and .27 also my own compiled version of .23 and .27 the result is intrigued (I hope I am using right word). The downloaded version have some problems it just not working for my SD card at all. however my compiled version will work when file system is vfat. in .23 case my compiled version and downloaded work same way.

There is a very interested note. in both .23 and .27 case, my compiled version and downloaded version have exact same size. you would think different compiler will produce different size code (check sum are different. My compiler is armv5tel-softfloat-linux-gnueabi-gcc (Gentoo 4.3.3-r2 p1.2, pie-10.1.5) 4.3.3.

Code:

test:
  my .27, sdhc 4G, ext2 fs, only load kernel, not continue, loaded kernel pass CRC check.
  my .27, sdhc 4G, vfat fs, both kernel and initrd work

  my .27, sd   2G, ext2 fs, only load kernel, not continue, loaded kernel pass CRC check.
  my .27, sd   2G, vfat fs, both kernel and initrd work
----------------------------------------------------
  posted .27 sdhc 4G, ext2 fs, only kernel load, not continue, kernel NOT pass CRC CHECK.
  posted .27 sdhc 4G, vfat fs, both kernel and initrd load failed, both NOT pass CRC CHECK

  posted .27 sd   2G, ext2 fs, only kernel load, not continue, kernel NOT pass CRC CHECK.
  posted .27 sd   2G, vfat fs, both kernel and initrd load failed both NOT pass CRC CHECK.
-------------------------------------------------------
  my .23, sdhc 4G, ext2 fs, only load kernel, not continue, loaded kernel pass CRC check.
  my .23, sdhc 4G, vfat fs, both kernel and initrd work
Marvell>> mmcinit
SDa0000 found. Card desciption is:
Manufacturer:       0x02, OEM "TM"
Product name:       "SD02G", revision 3.8
Serial number:      2903002420
Manufacturing date: 1/2009
CRC:                0x00, b0 = 0
  my .23 sd   2G, ext2 fs, only load kernel, not continue, loaded kernel pass CRC check.
  my .23 sd   2G, vfat fs, both kernel and initrd work
---------------------------------------------------------
  posted .23 sdhc 4G, ext2 fs, only load kernel, not continue, loaded kernel pass CRC check.
  posted .23 sdhc 4G, vfat fs, both kernel and initrd work
Marvell>> mmcinit
SDa0000 found. Card desciption is:
Manufacturer:       0x02, OEM "TM"
Product name:       "SD02G", revision 3.8
Serial number:      2903002420
Manufacturing date: 1/2009
CRC:                0x00, b0 = 0
  posted .23 sd   2G, ext2 fs, only load kernel, not continue, loaded kernel pass CRC check.
  posted .23 sd   2G, vfat fs, both kernel and initrd work