uboot: bread failed

Go To Last Post
6 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have been seeing intermitant sd-card boot failures. Somedays I just con't seem to amke a card that will boot.

Most seem to failed with a 'bread failed' message to the lcd , something like this...

..............mmc: bread failed, SR = 00400225, card status = 00000b00
 ** ext2fs_devread() read error - last part

I belive this is uboot failing to see the card so I have been exploring uboot via the command line.

I find that ext2ls often fails but not always...

> mmcint
mmcinit
Manufacturer ID:       1B
OEM/Application ID:    534D
Product name:          SMI
Product Revision:      1.0
Product Serial Number: 178926916
Manufacturing Date:    07/07
SD Card detected (RCA 45928)
CSD data: 005e0032 5f5983ca 6db7ff9f 96400055
CSD structure version:   1.0
MMC System Spec version: 0
Card command classes:    5f5
Read block length:       512
Supports partial reads
Write block length:      512
Does not support partial writes
Supports group WP:      32
Card capacity:          1017643008 bytes
File format:            0/0
Write protection:
> ext2ls mmc 0
........       4096 .
....       4096 ..
....       4096 bin
...mmc: bread failed, SR = 00400225, card status = 00000b00
 ** ext2fs_devread() read error - last part
> echo $?
0
> ext2ls mmc 0
........       4096 .
....       4096 ..
....       4096 bin
....       4096 boot
....       4096 config
....       4096 dev
....       4096 etc
....       4096 home
....       4096 lib
....         11 linuxrc
....       4096 lost+found
....       4096 media
....       4096 proc
....       4096 root
....       4096 sbin
....       4096 sys
....       4096 tmp
....       4096 usr
....       4096 var
....       4096 update
....               0 .bootme
> echo $?
0
>

Is there any reason why this might be happening?

ext2load has the same problem.

Once it works it seems to continue to work until I remove and re-insert the card (remembering to run mmcinit again of course). Thus I had hoped I could write a script to keep trying to load the kernel image until it works. Something like this perhaps...

until ext2load mmc 0:1 0x90400000 /boot/uImage; do ; done

However, ext2load always returns 1 (and ext2ls always returns 0) so there seems no way for the the script to know when the command was sussessful. I'd really like to know how to fix the origional pronlem, but knowing how to work round this little undocumented feature would help.

Uboot is version:
U-Boot 1.1.4-at0 (Mar 11 2008 - 15:17:53)

Steven

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Could you retry with the latest u-boot? ftp://ftp.denx.de/pub/u-boot

v1.3.3 is the latest stable.

There has been loads of changes to the MMC driver since 1.1.4-at0.

There is also some upgrade images you could try out at: http://www.atmel.no/buildroot/bu...

Instructions on usage here: http://avr32linux.org/twiki/bin/...

Hans-Christian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks, I'll try this.

Steven

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah, this bug has definitely been fixed quite a while ago. The data timeout is probably wrong.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hce wrote:
Could you retry with the latest u-boot? ftp://ftp.denx.de/pub/u-boot

v1.3.3 is the latest stable.

There has been loads of changes to the MMC driver since 1.1.4-at0.

There is also some upgrade images you could try out at: http://www.atmel.no/buildroot/bu...

Instructions on usage here: http://avr32linux.org/twiki/bin/...


Unfortunately those instructions don't work...

> ext2load mmc 0:1 0x10400000 /flash-upgrade-atstk1002-to-v1.3.3.uimg           
................................................................................
64903 bytes read                                                                
> bootm                                                                         
## Booting image at 10400000 ...                                                
   Image Name:   AVR32 Flash Upgrade Utility v0.2                               
   Image Type:   AVR32 Linux Kernel Image (gzip compressed)                     
   Data Size:    64839 Bytes = 63.3 kB                                          
   Load Address: 10000000                                                       
   Entry Point:  90000000                                                       
   Verifying Checksum ... OK                                                    
   Uncompressing Kernel Image ... OK                                            
                                                                                
Starting kernel at 90000000 (params at 10f80040)...                             
                                                                                
AVR32 Flash upgrade utility version 0.2                                         
                                                                                
HSMC configuration: 0x00030001 0x06030504 0x00090009 0x00001103                 
cfi: Unknown chip 0x001f:0x01d2                                                 
Panic: CFI flash identification failed 

Fortunately I have jtag MkII somewhere...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just to report back - this did fix my original problem. I need hush in u-boot so had to build from source.

I assume the later problem I had with the upload method was because I had such and old version of u-boot already installed. I was able to update using the jtag.

Thanks hce.