U-boot fails to read my SD cards

[Stefan Monnier]

With my recent effort to move all my remaining 3.4 machines to
(almost)mainline, I saw a strange pattern:
Many of the SD cards I have can't be read by U-boot. Yet, they work
fine elsewhere.

More specifically, more than half of the SD cards I've tried show the
following behavior:
- I can put U-boot on them and the A20 boots fine.
- The U-boot code loaded from the card (mainline U-boot 2014-07) can
read the card's partition table, root directory, and load the
boot.scr script.
- Once booted, Linux can read all the files on the card via
/dev/mmcblk0p1.
- All 3 USB card readers I have can read&write to those cards without
any problem.
- But U-boot can't load the vmlinuz/uImage files (I get ext4 errors).

IIUC there's a general sentiments that most SD cards are crap (and
indeed mine are all old&cheap), but I find it striking that they work
"everywhere" *except* for U-boot reading a large file.

Of course, this problem pushed me to change my machines's setup so
U-boot reads the kernel&initrd directly from the hard-disk, so to some
extent I don't care that much about it any more, but still. I think the
MMC code used in our U-boot has a bug.


Stefan

[Hans de Goede]

Hi,

On 08/19/2015 09:42 PM, Stefan Monnier wrote:
> With my recent effort to move all my remaining 3.4 machines to
> (almost)mainline, I saw a strange pattern:
> Many of the SD cards I have can't be read by U-boot. Yet, they work
> fine elsewhere.
>
> More specifically, more than half of the SD cards I've tried show the
> following behavior:
> - I can put U-boot on them and the A20 boots fine.
> - The U-boot code loaded from the card (mainline U-boot 2014-07) can
> read the card's partition table, root directory, and load the
> boot.scr script.
> - Once booted, Linux can read all the files on the card via
> /dev/mmcblk0p1.
> - All 3 USB card readers I have can read&write to those cards without
> any problem.
> - But U-boot can't load the vmlinuz/uImage files (I get ext4 errors).
>
> IIUC there's a general sentiments that most SD cards are crap (and
> indeed mine are all old&cheap), but I find it striking that they work
> "everywhere" *except* for U-boot reading a large file.

What sunxi board(s) are you using ?

Regards,

Hans

[Stefan Monnier]

>> IIUC there's a general sentiments that most SD cards are crap (and
>> indeed mine are all old&cheap), but I find it striking that they work
>> "everywhere" *except* for U-boot reading a large file.
> What sunxi board(s) are you using ?

I have a Mele A2000, a pair of "cheap mini-x style a10s box",
a BananaPi, an OrangePi-mini, and a Cubietruck, but in this present
round of (involuntary) tests, I used the BananaPi and the OrangePi-mini.


Stefan

[Hans de Goede]

Hi,

So both A20 devices, I did a fix recently(ish) to properly set the sample
clock phase for the mmc clock in u-boot. Are you using a recent u-boot ?

Also I see in the fex files for these boards that they are using 1.3V
instead of 1.25V for dcdc3, something else you can test is to edit
board/sunxi/board.c and then change:

power_failed |= axp209_set_dcdc3(1250);

into:

power_failed |= axp209_set_dcdc3(1300);

Built u-boot that way and see if it helps.

Regards,

Hans

[Tapio Valli]

I was seeing probably the same issue with my ITEAD Core A20 board. The ITEAD image is able to read uImage successfully. The sunxi u-boot reads small files ok but fails on kernel/any other larger file.

I would be very interested to find a fix here. I'll try the solutions Hans suggested as I have time. Any additional help is highly valued.

Tapio

[Tapio Valli]

I tried both suggestions:

1) My u-boot was quite old, now it should be updated

2) Changed the axp209 power_failed voltages to match values in my script.fex

Re-compiled and re-build SD card. I still get the same issue with uImage loading failed, the log is below. I have tested the system through u-boot console after the kernel read failure. The MMC system seems to have lost the partition table somehow: you can see it already in the log with "** Can't read partition table on 0:0 **" towards the end. 

U-Boot SPL 2015.10-rc1-00432-gbd48c06 (Aug 09 2015 - 12:47:23)

DRAM: 2048 MiB

CPU: 912000000Hz, AXI/AHB/APB: 3/2/2

U-Boot 2015.10-rc1-00432-gbd48c06 (Aug 09 2015 - 12:47:23 +0000) Allwinner Technology

CPU:   Allwinner A20 (SUN7I)

I2C:   ready

DRAM:  2 GiB

MMC:   SUNXI SD/MMC: 0

*** Warning - bad CRC, using default environment

In:    serial

Out:   serial

Err:   serial

SCSI:  SUNXI SCSI INIT

SATA link 0 timeout.

AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode

flags: ncq stag pm led clo only pmp pio slum part ccc apst 

Net:   eth0: ethernet@01c50000

starting USB...

USB0:   USB EHCI 1.00

USB1:   USB OHCI 1.0

USB2:   USB EHCI 1.00

USB3:   USB OHCI 1.0

scanning bus 0 for devices... 3 USB Device(s) found

scanning bus 2 for devices... 1 USB Device(s) found

Hit any key to stop autoboot:  0 

switch to partitions #0, OK

mmc0 is current device

Scanning mmc 0:1...

Found U-Boot script /boot.scr

reading /boot.scr

327 bytes read in 22 ms (13.7 KiB/s)

## Executing script at 43100000

reading script.bin

48088 bytes read in 230 ms (204.1 KiB/s)

reading uImage

Error reading cluster

** Unable to read file uImage **

## Booting kernel from Legacy Image at 42000000 ...

   Image Name:   Linux-3.4.103-g9a1cd03

   Image Type:   ARM Linux Kernel Image (uncompressed)

   Data Size:    4551496 Bytes = 4.3 MiB

   Load Address: 40008000

   Entry Point:  40008000

   Verifying Checksum ... Bad Data CRC

ERROR: can't get kernel image!

SCRIPT FAILED: continuing...

** Can't read partition table on 0:0 **

** Invalid partition 1 **

** Can't read partition table on 0:0 **

** Invalid partition 1 **

** Can't read partition table on 0:0 **

** Invalid partition 1 **

scanning bus for devices...

Found 0 device(s).

... 

[Olliver Schinagl]

Hey all,

On 21-08-15 09:57, Hans de Goede wrote:
> Hi,
>
> On 20-08-15 15:14, Stefan Monnier wrote:
>>>> IIUC there's a general sentiments that most SD cards are crap (and
>>>> indeed mine are all old&cheap), but I find it striking that they work
>>>> "everywhere" *except* for U-boot reading a large file.
>>> What sunxi board(s) are you using ?
>>
>> I have a Mele A2000, a pair of "cheap mini-x style a10s box",
>> a BananaPi, an OrangePi-mini, and a Cubietruck, but in this present
>> round of (involuntary) tests, I used the BananaPi and the OrangePi-mini.

I've noticed this same behaviour on my Cubietruck (and I think my
lime2's) with nearly all my SD cards. On my CT I use a SSD and only have
the kernel + u-boot on the SD so used some old small (128mb) sd cards
and was surprised it wouldn't boot any more. Using some other 8 Gig UHS1
rated sd card it works as expected.

I see if I can build a new U-boot with those power changes to see if
that makes a difference.

Olliver

[Stefan Monnier]

I just tried with a U-boot built from the latest (as of this morning)
"master" branch, with the patch below applied (the part_dos.c part of
the patch shouldn't make any difference, tho), but I still get the same:

=> load mmc 0 0x44000000 uImage
** ext4fs_devread read error - block


-- Stefan


diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index f85e825..dfbc4c4 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -429,7 +429,7 @@ void sunxi_board_init(void)
#ifdef CONFIG_AXP209_POWER
power_failed |= axp209_init();
power_failed |= axp209_set_dcdc2(1400);
- power_failed |= axp209_set_dcdc3(1250);
+ power_failed |= axp209_set_dcdc3(1300);
power_failed |= axp209_set_ldo2(3000);
power_failed |= axp209_set_ldo3(2800);
power_failed |= axp209_set_ldo4(2800);
diff --git a/disk/part_dos.c b/disk/part_dos.c
index cf1a36e..f7134ae 100644
--- a/disk/part_dos.c
+++ b/disk/part_dos.c
@@ -25,7 +25,7 @@

/* Convert char[4] in little endian format to the host format integer
*/
-static inline int le32_to_int(unsigned char *le32)
+static inline unsigned int le32_to_int(unsigned char *le32)
{
return ((le32[3] << 24) +
(le32[2] << 16) +
@@ -46,13 +46,13 @@ static inline int is_bootable(dos_partition_t *p)
return p->boot_ind == 0x80;
}

-static void print_one_part(dos_partition_t *p, int ext_part_sector,
+static void print_one_part(dos_partition_t *p, lbaint_t ext_part_sector,
int part_num, unsigned int disksig)
{
- int lba_start = ext_part_sector + le32_to_int (p->start4);
- int lba_size = le32_to_int (p->size4);
+ lbaint_t lba_start = ext_part_sector + le32_to_int (p->start4);
+ lbaint_t lba_size = le32_to_int (p->size4);

- printf("%3d\t%-10d\t%-10d\t%08x-%02x\t%02x%s%s\n",
+ printf("%3d\t%-10lu\t%-10lu\t%08x-%02x\t%02x%s%s\n",
part_num, lba_start, lba_size, disksig, part_num, p->sys_ind,
(is_extended(p->sys_ind) ? " Extd" : ""),
(is_bootable(p) ? " Boot" : ""));
@@ -101,7 +101,8 @@ int test_part_dos (block_dev_desc_t *dev_desc)
/* Print a partition that is relative to its Extended partition table
*/
static void print_partition_extended(block_dev_desc_t *dev_desc,
- int ext_part_sector, int relative,
+ lbaint_t ext_part_sector,
+ lbaint_t relative,
int part_num, unsigned int disksig)
{
ALLOC_CACHE_ALIGN_BUFFER(unsigned char, buffer, dev_desc->blksz);
@@ -109,7 +110,7 @@ static void print_partition_extended(block_dev_desc_t *dev_desc,
int i;

if (dev_desc->block_read(dev_desc->dev, ext_part_sector, 1, (ulong *) buffer) != 1) {
- printf ("** Can't read partition table on %d:%d **\n",
+ printf ("** Can't read partition table on %d:%lu **\n",
dev_desc->dev, ext_part_sector);
return;
}
@@ -148,7 +149,8 @@ static void print_partition_extended(block_dev_desc_t *dev_desc,
pt = (dos_partition_t *) (buffer + DOS_PART_TBL_OFFSET);
for (i = 0; i < 4; i++, pt++) {
if (is_extended (pt->sys_ind)) {
- int lba_start = le32_to_int (pt->start4) + relative;
+ lbaint_t lba_start
+ = le32_to_int (pt->start4) + relative;

print_partition_extended(dev_desc, lba_start,
ext_part_sector == 0 ? lba_start : relative,
@@ -162,8 +164,9 @@ static void print_partition_extended(block_dev_desc_t *dev_desc,

/* Print a partition that is relative to its Extended partition table
*/
-static int get_partition_info_extended (block_dev_desc_t *dev_desc, int ext_part_sector,
- int relative, int part_num,
+static int get_partition_info_extended (block_dev_desc_t *dev_desc,
+ lbaint_t ext_part_sector,
+ lbaint_t relative, int part_num,
int which_part, disk_partition_t *info,
unsigned int disksig)
{
@@ -173,7 +176,7 @@ static int get_partition_info_extended (block_dev_desc_t *dev_desc, int ext_part
int dos_type;

if (dev_desc->block_read (dev_desc->dev, ext_part_sector, 1, (ulong *) buffer) != 1) {
- printf ("** Can't read partition table on %d:%d **\n",
+ printf ("** Can't read partition table on %d:%lu **\n",
dev_desc->dev, ext_part_sector);
return -1;
}
@@ -249,7 +252,8 @@ static int get_partition_info_extended (block_dev_desc_t *dev_desc, int ext_part
pt = (dos_partition_t *) (buffer + DOS_PART_TBL_OFFSET);
for (i = 0; i < 4; i++, pt++) {
if (is_extended (pt->sys_ind)) {
- int lba_start = le32_to_int (pt->start4) + relative;
+ lbaint_t lba_start
+ = le32_to_int (pt->start4) + relative;

return get_partition_info_extended (dev_desc, lba_start,
ext_part_sector == 0 ? lba_start : relative,

[Hans de Goede]

Hi,

On 24-08-15 21:05, Stefan Monnier wrote:
>>>>> IIUC there's a general sentiments that most SD cards are crap (and
>>>>> indeed mine are all old&cheap), but I find it striking that they work
>>>>> "everywhere" *except* for U-boot reading a large file.
>>>> What sunxi board(s) are you using ?
>>> I have a Mele A2000, a pair of "cheap mini-x style a10s box",
>>> a BananaPi, an OrangePi-mini, and a Cubietruck, but in this present
>>> round of (involuntary) tests, I used the BananaPi and the OrangePi-mini.
>> So both A20 devices, I did a fix recently(ish) to properly set the sample
>> clock phase for the mmc clock in u-boot. Are you using a recent u-boot ?
>> Also I see in the fex files for these boards that they are using 1.3V
>> instead of 1.25V for dcdc3, something else you can test is to edit
>> board/sunxi/board.c and then change:
>
>> power_failed |= axp209_set_dcdc3(1250);
>
>> into:
>
>> power_failed |= axp209_set_dcdc3(1300);
>
>> Built u-boot that way and see if it helps.
>
> I just tried with a U-boot built from the latest (as of this morning)
> "master" branch, with the patch below applied (the part_dos.c part of
> the patch shouldn't make any difference, tho), but I still get the same:
>
> => load mmc 0 0x44000000 uImage
> ** ext4fs_devread read error - block

Bummer, so can you read uImage from this card using the Linux kernel
once booted ?

Regards,

Hans

[Stefan Monnier]

>> => load mmc 0 0x44000000 uImage
>> ** ext4fs_devread read error - block
> Bummer, so can you read uImage from this card using the Linux kernel
> once booted ?

Yes,


Stefan

[Tapio Valli]

Ok, my problem with reading kernel was caused by bad SD card. Fixed by better quality SD card. 

 

[Hans de Goede]

Hi,

Can you try my sunxi-wip branch? This one has some fixes which
might fix this.

Regards,

Hans

[Stefan Monnier]

>>>> => load mmc 0 0x44000000 uImage
>>>> ** ext4fs_devread read error - block
>>> Bummer, so can you read uImage from this card using the Linux kernel
>>> once booted ?
>> Yes,
> Can you try my sunxi-wip branch? This one has some fixes which
> might fix this.

I'll try it as soon as I get back to the corresponding machines.


Stefan

[Stefan Monnier]

>>>> => load mmc 0 0x44000000 uImage
>>>> ** ext4fs_devread read error - block
>>> Bummer, so can you read uImage from this card using the Linux kernel
>>> once booted ?
>> Yes,
> Can you try my sunxi-wip branch? This one has some fixes which
> might fix this.

Indeed, I just tried it and it was able to read my "vmlinuz" file just
fine (tho only at 246kB/s, which is rather slow, even for an old 256MB
SD card).
Yay! Thanks!


Stefan

[tandre...@gmail.com]

Hi Hans,

can you give me some details which changes are this?
Do you know if they are already applied in mainline u-boot?

Regards

Tobias

[Hans de Goede]

Hi,

On 09/18/2015 02:07 PM, tandre...@gmail.com wrote:
> Hi Hans,
>
> can you give me some details which changes are this?

This fix:

http://git.denx.de/?p=u-boot.git;a=commitdiff;h=28f69b9a229108834af34da099949076d9fd4ff3

> Do you know if they are already applied in mainline u-boot?

Yes, as the above link shows this commit is already part of u-boot master.

Regards,

Hans

[tandre...@gmail.com]

Hi,

thanks.

Tobias