new uboot version 3.4.25

[odoll]

Came to the strange idea that the issue might be caused by an offset, but at least it's not as simple as

Marvell>>  ext2load mmc 0 0x8000000 /uImage

2861324 bytes read
Marvell>> bootm 0x8000001
## Booting image at 08000001 ...
Bad Magic Number
Marvell>> bootm 0x7ffffff
## Booting image at 07ffffff ...
Bad Magic Number
Marvell>> bootm 0x8000000
## Booting image at 08000000 ...
   Image Name:   Linux-2.6.32.2
   Created:      2009-12-19   5:54:34 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2861260 Bytes =  2.7 MB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... Bad Data CRC
Marvell>> ext2load mmc 0:1 0x8000000 /uImage

2861324 bytes read
Marvell>> bootm 0x8000000
## Booting image at 08000000 ...
   Image Name:   Linux-2.6.32.2
   Created:      2009-12-19   5:54:34 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2861260 Bytes =  2.7 MB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... Bad Data CRC

Though FAT from an USB-Pen works

Marvell>> usb start
(Re)start USB...
USB:   scanning bus for devices... 2 USB Device(s) found
Waiting for storage device(s) to settle before scanning...
1 Storage Device(s) found
Marvell>> fatload usb 0 0x8000000 /uimage.bin
reading /uimage.bin
...

2861324 bytes read
Marvell>> bootm 0x8000000
## Booting image at 08000000 ...
   Image Name:   Linux-2.6.32.2
   Created:      2009-12-19   5:54:34 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2861260 Bytes =  2.7 MB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
[...]
Debian GNU/Linux 5.0 debian ttyS0

debian login:

[odoll]

In .27 I first loaded the same kernel image once from usb (booting) and once from SD to the same memory location (having the strange idea that the ext2load in .27 might not fully load the image). Hence "CRC" error:

Marvell>> usb start
(Re)start USB...
USB:   scanning bus for devices... 2 USB Device(s) found
Waiting for storage device(s) to settle before scanning...
1 Storage Device(s) found
Marvell>> fatload usb 0:1 0x8000000 /uimage.bin
reading /uimage.bin
...

2861324 bytes read
Marvell>> mmcinit
Error! cmd : 8, err : 0201
SD found. Card desciption is:
Manufacturer:       0x1c, OEM "SV"
Product name:       "SDM  ", revision 1.0
Serial number:      2415946749
Manufacturing date: 3/2007
CRC:                0x00, b0 = 0
Marvell>> ext2load mmc 0:1 0x8000000 /uImage

2861324 bytes read
Marvell>> bootm 0x8000000
## Booting image at 08000000 ...
   Image Name:   Linux-2.6.32.2
   Created:      2009-12-19   5:54:34 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2861260 Bytes =  2.7 MB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... Bad Data CRC

BTW0: why does USB START report 2 and then just 1 USB device to be found? Is there another internal device connected by usb?!
BTW1: someone an idea, why the MMCINIT has the error message with SDs. As far as I can tell I don't get that message if I use SDHC!? And what does that message mean?

Another test .23 vs .27. I loaded the same kernel image once from usb (booting) and once from SD to different memory locations and did a memory comparison (cmp.b). When using .23 the loaded image in RAM is identical, if loaded with .27 they aren't (see attached files).

[superpat]

Hi,

I just thought I would see if v.27 uboot fixed my troubles. 

Unfortunately it gives a new  (to me)  error:-

U-Boot 1.1.4 (Dec 23 2009 - 13:32:43) Marvell version: 3.4.27



U-Boot code: 00600000 -> 0067FFF0  BSS: -> 006CFB00

USB 0: host mode

PEX 0: interface detected no Link.

Net:   egiga0 [PRIME]

Hit any key to stop autoboot:  3  0

Marvell>>   mmcinit


SDHC found. Card desciption is:

Manufacturer:       0x27, OEM "PH"

Product name:       "SD8GB", revision 2.0

Serial number:      2953847158

Manufacturing date: 8/2009

CRC:                0x00, b0 = 0

Marvell>> ext2load mmc 0 0x800000 /boot/uImage


 ** ext2fs_devread() read outside partition sector 15718056



** Unable to read "/boot/uImage" from mmc 0:1 **

Marvell>>

This is using a 8GB Kingston SDHC card, 

uboot v.23  also fails but in a different way,  it does not return  ANYTHING after a ext2load, except for the next Marvell>>> prompt but performing a ext2ls command returns the / structure and also the uImage file.  (command >>>  ext2ls mmc 0:1 /boot  returns uImage)

just my 2c's worth

I am going to fdisk and mk2fs the card again, put a deb rfs on it and a uImage and try again.


EDIT

Re tried above with same card no change same error on 3.4.27

Found an old copy of 3.4.19 uboot, installed using bubt.

Did same test again, using same card and same rfs and uImage  ..... uImage now loads OK and runs OK !

regards

Patrick

[pingtoo]

Hi,

I found the problem for why ext2load having problem (for me at least) it is because in the do_ext2load(...) the return value should be "0" when success, but the routine return loaded file length which cause the run_command() stop run next command.

Also base on superpat report, I dig out a patch may have address the problem. Apparently this bug will not surface unless you have ext2/3 file system on a very large partition (I imagine it at least over 2GB) because the mke2fs format differently for large file system then small file system.  however for this I will need your test since in my test it never happen so I don't know if I fix the problem or I am just being lucky

Finally, about odall reported error

Code:

Error! cmd : 8, err : 0201

base on research from SD Association's Simplified Specification once this error code come out it is game over for the SD card. because the command "8" is the SD host controller sending information to SD card asking which voltage will the SD card accept, if error was return then it mean the SD card does not accept any voltage proposed by host. And in the mmcinit it does not cause the routine to abort, it simply continue issue next SD command so the result is unpredictable.

Anyway I attach my patched version of 3.4.27. If you successfully flush to NAND, at Marvell prompt your type in command ver you should see some like this

Marvell>> ver

U-Boot 1.1.4 (Dec 27 2009 - 22:03:21) Marvell version: 3.4.27 - pingtoo patch.01

Good luck

[superpat]

@pingtoo


Result of quick test (only one off, we have visitors and my wife is giving me stick to turn this lot off now!!!!)

WONDERFUL!!!!!!!!!!


I dl'd your patched uboot and  burnt it to nand.

Using the 8GB Kingston SDHC card and exactly the same RFS and uImage as before, and the same  bootargs and ext2load command as before,

uImage loads correctly  and boots OK. I need to set the mainline stuff in the env, but thats not what we were testing!


I will do more exhaustive testing once our visitors have gone

Thanks for your work   (AND everybody else who has grafted on this!!!!!

Wish you all a Happy and Prosperous New Year

regards

Patrick


 

[rooster]

Hey pingtoo,

Can you please upload the patch you applied to 3.4.27?
I want it integrated into Marvell`s next uboot version.

-rooster

[pingtoo]

Hey pingtoo,

Can you please upload the patch you applied to 3.4.27?
I want it integrated into Marvell`s next uboot version.

-rooster

Sure, let me try to figure how to generate the patch file. Shouldn't we wait for a bit more report before we call it a success?

[rooster]

I would like our uboot developer and SD guys to look into this patch, if it does fix the bug and does not introduce any other issue I would like our QA to start processing it, meanwhile anyone on the forum can use it.

I have reproduced the issue reported of mismatch when reading from EXT2 partition from SD (2G) and also got the ext2fs_devread, I have not been able to reproduce the

Error! cmd : 8, err : 0201

error on mmcinit though.

[pingtoo]

patch

[odoll]

Hey pingtoo,

I found the problem for why ext2load having problem ...

superb - works like a charm, now! :-) To you and all working a this a big thanx!

Error! cmd : 8, err : 0201

As far as I recall all of my SD cards show this error message, but none of my SDHC. Would this mean that it will be more save to use SDHC rather than SD as the plug ignores the message or can not offer the right voltage level?

And maybe two other notes while fixing the version. There are some little blemish in the "help" output
 IMO all command explanations should be aligned (if allowed by the command
 word lenght) starting with a dash and just start with a lower capital character and the
 sentences should end without a dot "."
 On command "map": change "Diasplay" to "display"

And I noticed this strange? behavior: while I made the update of the uboot I didn't reset the environment variables.

since then it came up with

[...]
Addresses 8M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (8M - 7M): Done
NAND:512 MB
Flash:  0 kB
[...]
Marvell>> resetenv
Erase Env parameters offset 0xa0000... done
Warning: Default Environment Variables will take effect Only after RESET
Marvell>> reset
[...]
Mem malloc Initialization (8M - 7M): Done
NAND:512 MB
*** Warning - bad CRC or NAND, using default environment

Flash:  0 kB
[...]


I was upset when I first read it, because I thought I screwed something now.

Is "bad" really the right word here!? Shouldn't we better use "empty"?

Without modifying any environment variable I just did a
Marvell>> saveenv
Saving Environment to NAND...
Erasing Nand...Writing to Nand... done
Marvell>> reset
[...]
Marvell>> saveenv
Saving Environment to NAND...
Erasing Nand...Writing to Nand... done
Marvell>> reset
[...]

and the error is gone again. (just my 2 cent)

[oreo]

Hello pingtoo,
Thanks for the patch. I have flashed the compiled uboot you provided and it works.

However, i have tried to build uboot myself with your patch, and the produced uboot gives the "bad crc" error message for some reason.

The steps i followed were:
- extract uboot 1.1.4 source
- extract uboot 3.4.27 source on top of the directory of v1.1.4

- apply your patch:
    while inside the directory of the extracted source code : patch -p1 < /path/to/your/patch
- build the source with :
    make mrproper
    make rd88f6281Sheevaplug_config NBOOT=1 LE=1
    make all

I am using the cross compiler from http://plugcomputer.org/index.php/us/resources/downloads?func=fileinfo&id=43

Any ideas?

[pingtoo]

Hello pingtoo,
Thanks for the patch. I have flashed the compiled uboot you provided and it works.

However, i have tried to build uboot myself with your patch, and the produced uboot gives the "bad crc" error message for some reason.

The steps i followed were:
- extract uboot 1.1.4 source
- extract uboot 3.4.27 source on top of the directory of v1.1.4

- apply your patch:
    while inside the directory of the extracted source code : patch -p1 < /path/to/your/patch
- build the source with :
    make mrproper
    make rd88f6281Sheevaplug_config NBOOT=1 LE=1
    make all

I am using the cross compiler from http://plugcomputer.org/index.php/us/resources/downloads?func=fileinfo&id=43

Any ideas?

Are you refer loading kernel give you crc error or compile give you crc error?
my gcc is armv5tel-softfloat-linux-gnueabi-gcc (Gentoo 4.3.3-r2 p1.2, pie-10.1.5) 4.3.3 I am not familiar the one you refer to. (I know nothing about compiler to be honest) what I did notice is that the  code seems to be very sensitive what compile is used or toolchain. for example the one posted in this fourms does not work for me, I always get error during loading kernel in both FAT and EXT2 case, however I use the source compile myself it begin work for FAT (as EXT2 have bug in code so it does not work for me) I also notice the produced code is exactly same size. so to be honest I have no idea where to begin, my only advice is try it same version of toolchain as mine.

Code:

gcc -> armv5tel-softfloat-linux-gnueabi-gcc (Gentoo 4.3.3-r2 p1.2, pie-10.1.5) 4.3.3
binutils -> binutils-2.18
glibc -> glibc-2.9_p20081201
linuxheader -> linux-headers-2.6.27

I hope this can help point you to some where.

BTW, I did almost exactly compile sequence except at last step I use make -s which I found in the create_all_imageKW.sh

I learn on trick during my research on this topic, it came from pogoplug forum (I don't have the url handy) basically it allow you test u-boot without affect your current installed version. so your can try this.

• Setup tftp loading process,
• in u-boot source directory
• make mrproper
• make rd88f6281Sheevaplug_config LE=1 NBOOT=1
  
• edit board/mv_feroceon/config_kw/config.mk
      chage TEXT_PASE = 0x00600000
      to read: TEXT_BASE = 0x01600000
      save and exit
  
  • make -s
    
  use the result u-boot.bin discard the u-boot-rd88f6281Sheevaplug_400db_nand.bin
  transfer the u-boot.bin to your tftp server.
  in Marvell prmpt do
  Code:
  Marvell>> tftp 0x01600000 /path/to/u-boot.bin
  Marvell>> go 0x01600000
  
  this will boot you newly build u-boot.bin without request you flush it in to NAND.
  
  Good luck

[oreo]

Hey pingtoo thanks for the response.

Are you refer loading kernel give you crc error or compile give you crc error?

Loding the uboot i compile gives me the crc error. The uboot you compiled with your toolchain works fine.
 

what I did notice is that the  code seems to be very sensitive what compile is used or toolchain.

I thought of this too, but i wanted to be sure first before compiling a new toolchain I will try another toolchain and see
what i get.

Code:

gcc -> armv5tel-softfloat-linux-gnueabi-gcc (Gentoo 4.3.3-r2 p1.2, pie-10.1.5) 4.3.3
binutils -> binutils-2.18
glibc -> glibc-2.9_p20081201
linuxheader -> linux-headers-2.6.27

I hope this can help point you to some where.

BTW, I did almost exactly compile sequence except at last step I use make -s which I found in the create_all_imageKW.sh

I learn on trick during my research on this topic, it came from pogoplug forum (I don't have the url handy) basically it allow you test u-boot without affect your current installed version. so your can try this.

• Setup tftp loading process,
• in u-boot source directory
• make mrproper
• make rd88f6281Sheevaplug_config LE=1 NBOOT=1
  
• edit board/mv_feroceon/config_kw/config.mk
      chage TEXT_PASE = 0x00600000
      to read: TEXT_BASE = 0x01600000
      save and exit
  
  • make -s
    
  use the result u-boot.bin discard the u-boot-rd88f6281Sheevaplug_400db_nand.bin
  transfer the u-boot.bin to your tftp server.
  in Marvell prmpt do

Code:

Marvell>> tftp 0x01600000 /path/to/u-boot.bin
Marvell>> go 0x01600000

this will boot you newly build u-boot.bin without request you flush it in to NAND.

Good luck

Hey thanks! I will try this as soon as the new toolchain is ready

[oreo]

Ok, i have built uboot with another toolchain and the kernel loads fine from the sd card.

It seems that this was a problem of the cross compiler.

Again, thanks pingtoo !

[pingtoo]

Ok, i have built uboot with another toolchain and the kernel loads fine from the sd card.

It seems that this was a problem of the cross compiler.

Again, thanks pingtoo !

No problem. I was afraid I made mistake during the patch generate process.