Ticket #1815 (closed defect: fixed)

Opened 9 years ago

Last modified 8 years ago

u-boot fails to detect sandisk 8gb microsdhc correctly

Reported by: x Owned by: openmoko-kernel
Priority: normal Milestone:
Component: kernel Version: GTA02v5
Severity: normal Keywords: u-boot sdhc sandisk
Cc: Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: no PatchReviewResult:


tested with u-boot from daily 20080809 (gitr54).
on mmcinit u-boot detects:

GTA02v5 # mmcinit
Card Type: SD 2.0 SDHC

iManufacturer: 0x03, OEM "SD"

Product name: "SU08G", revision 8.0
Serial number: 1091827341
Manufacturing date: 6/2009
MMC/SD size: 3MiB
GTA02v5 #

and booting from it fails.
the packaging of the card says:

Mobile Premier
High Performance + TrustedFlash?
8GB microSDHC Card with Reader

the card works fine/correctly with linux.

Change History

comment:1 Changed 9 years ago by dolfje

This may be a duplicate of #1719 or #1768,

comment:2 Changed 9 years ago by x

if i understand them correctly, both #1719 and #1768 describe problems with sdhc cards under linux.
i didn't have any problems using the card under linux (i.e., after booting the os) - at least until now.
the problem described above occurs before booting linux (i.e. the os), the bootloader u-boot - or more precisely the mmcinit command in it - seems not to recognize the card (or more precisely: its capacity) correctly, and consequently booting from it fails.

comment:3 Changed 9 years ago by zecke

  • Owner changed from openmoko-devel to openmoko-kernel
  • Status changed from new to assigned
  • Component changed from unknown to System Software

Changing Component to System Software as this is an u-boot problem.

comment:4 Changed 9 years ago by Sascha

I had the same problem with a "SanDisk?® Mobile Ultra™ microSDHC™ 8GB Card" - only the "Serial number" and the "Manufacturing date" strings differ.
First I partitioned/formated the card with GNU Parted and I could not boot from it.
Then with fdisk and mkfs.ext2 and I can boot debian without problems now.

Disk /dev/mmcblk0: 8168 MB, 8168931328 bytes
39 heads, 5 sectors/track, 81820 cylinders
Units = cylinders of 195 * 512 = 99840 bytes
Disk identifier: 0x000d8e91

        Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk0p1               1       81820     7977447+  83  Linux

although mmcinit still says

MMC/SD size: 3MiB



comment:5 Changed 9 years ago by x

I repartitioned the card, and now booting from it works.
I find it very hard to believe that it has anything to do with the partitioning-tool used (and i didn't use gparted in the first place). Obviously it's also not the case that booting works if the kernel happens to reside in the first 3mb (i can boot from the 2nd partition now, which is behind the first 2gb partition).
So the mmcinit reporting 3mb as capacity in the end seems to be just a cosmetic problem. Though there are still cases left where booting doesn't work (plus, i had spurious problems mounting the rootfs by a kernel that was loaded from the very same fs, which might be a related problem)

comment:6 Changed 9 years ago by olberger

I just experienced the same problem as initially reported, but for a 2Gb card.

The card is a sandisk 2GB SDSDQ-2048-E11MK microSD, but mmcinit reports the following with U-Boot 1.3.2-moko12 (Aug 26 2008 - 08:24:58) :
GTA02v5 # mmcinit
Card Type: SD 2.0
Manufacturer: 0x03, OEM "SD"
Product name: "SU02G", revision 8.0
Serial number: 24786483
Manufacturing date: 3/2008
MMC/SD size: 511MiB

Hope this helps (and doesn't mess, as the initial report was about 8Gb cards).

comment:7 Changed 9 years ago by x

regarding the cases where booting doesn't work, i found a reproducible one: i can boot from partitions 1 and 2 (both 2gb, starting at 0 and 2gb respectively) but i can't boot from partition 3 (which starts at 4gb and has a size of 2gb). using ext2load to load the kernel doesn't work. with ext2ls i can see the directory (/boot), but no contents (it appears empty). after booting linux, accessing partition 3 works fine. i also did an fsck.ext2, reporting everything is fine.

comment:8 Changed 8 years ago by nomeata


what’s the state of this bug? It seems at least Qi works fine with one partition on a large microSD-card...


comment:9 Changed 8 years ago by andy

  • HasPatchForReview unset

Qi has a bunch of improvements around ext2 / 3 parsing and SHDC code that aren't planned to get backported. U-Boot code will have trouble touching stuff after 4GB, and can't figure out the size correctly for 4GB and more either. Qi shouldn't have that problem... and Qi should be faster at processing ext2 / 3 content.

comment:10 Changed 8 years ago by andy

  • Status changed from assigned to closed
  • Resolution set to fixed

Closing this as "fixed in Qi".

Note: See TracTickets for help on using tickets.