799303 - Industrial Class SDCard Fails to run android OS on panda

Status: RESOLVED WONTFIX

(Testing :: General, defect)

Description

[cmtalbert]

Attachment: The industrial card's logcat

Yeah, I didn't believe it either.

I took my working panda image from a 16gb consumer grade sdcard via:
dd if=/dev/sdb of=android16gbos.img

And I also tried another image of the same card via:
cat /dev/sdb > android16gbos2.img

And I put it on the industrial sdcard, also 16gb:
dd if=<image> of=/dev/sdb

And when the panda boots with the industrial card, it only lasts about a minute, and it fails to get a DHCP request automatically (but it succeeds if you run it manually). And after about a minute, the entire system crashes.  I've attached a logcat from boot to the crash. 

Anyone have any ideas as to what could be wrong here?

Comment 1

[cmtalbert]

Ok, so after more investigation today, it looks like a problem with the card itself. This is going to be hand-wavvy because the card is in the system right now and I am trying one last image to burn onto it.  If this fails, I'll try pulling the linaro image directly but I don't hold out much hope.

I think what's happening here is that these high end cards do not like self-journaling partition types. I have read that the sdcards use an internal journal to ensure that the device wears properly and what separates the "industrial" card from the "consumer" card is exactly that technology. When I imaged the industrial card, it gets the two vfat partitions (the /sdcard and the /boot partition) and so the card will boot. However the /system partition is the first of the ext4 partitions to be written and it is only half written on the card and its structure is actually invalid. So, when I plug it in I get a bunch of errors in my dmesg about that partition. Changing the partition type to ext2 (no journaling) made these errors disappear when it was plugged into the linux box. However, that also blew away the system code and that won't make android super happy. 

So, the last thing I can think of is to try to use the linaro toolchain and edit their code so that it writes out ext2 partitions where it would normally use ext4 partitions.

Comment 2

[cmtalbert]

Attachment: booting, seeming infinite loop

ok, using the linaro build tools I downloaded an image and changed the linaro tools to write ext2 partitions instead of ext4 partitions. This seemed to make things much happier. I now have an sdcard that boots into android.

However, it doesn't come up all the way. I followed the instructions here: https://wiki.mozilla.org/Auto-tools/Projects/Pandaboard_Setup#Using_Linaro_Pre-Built_Images_.28WHAT_WE_ARE_USING.29

And while the UI loaded on the first boot, it kept saying "launcher has stopped" and "system UI has stopped".

On subsequent boots, it appears to get into some kind of hang state and I'm not seeing any UI come up at all (it stays at the "android" loading screen).

The logcat seems to be repeating itself, not sure if that is a real problem or just how android roles.

Set of next steps to try:
1. Run linaro tools unmodified and see if proper partitions are created on this sdcard with ext4 partitions (worth a shot)
2. Compare logcat of industrial card boot with normal card boot.
3. Decide how much farther down this rabbit hole we want to go.

Comment 3

[cmtalbert]

Ok, tried again for grins with the linaro media creation but using ext4 partitions. The linaro tool crapped all over itself but did manage to create the semblance of a proper partition structure. When I attempted to boot using this image, it failed to boot at all.

I think we can get this working. But I think it's going to take some android OS hacking in order to ensure the OS doesn't expect ext4 partitions and when it sees the ext2 partitions it mounts them appropriately.  So, out of the box, this card (Transcend Industrial Strength 16Gb, class 10) is a non-starter. 

I think we should just go with the cards we know will work, and we can work on this in the meantime and as the consumer cards die off we can perhaps be ready to replace them with industrial cards. 

Initial speed tests don't show these cards to be any faster, really. So I think the only thing we'll gain from using these is reliability, which is a good thing, but it's not going to significantly improve test turnaround times, which is what Brad had been hoping for.

Let's order the 400 of the cards that we verified in the smoketest and we can work on getting industrial cards stood up as a longer term side project.

Comment 4

[cmtalbert]

Another idea I had walking to the train: I could try modifiying the linaro tools to write out ext4 partitions with their journaling disabled. That would enable us to verify that it is indeed the journaling that is causing us issues, and it might get us a working system.

However, I won't be back in MV until friday so I won't be trying this until then. The sentiment of comment 3 stands. We can continue chasing these rabbits but let's go ahead with our normal sdcard order in the meantime.

Comment 5

[(not currently active) Ted Mielczarek]

I don't *think* this will be a showstopper for us. The boot image we're using to image the SD cards isn't going to flash a whole image on there, it's going to take tarballs and extract them onto each partition, so we can probably just partition the cards properly in the first place.

Basically, try changing the partition filesystems and just copying over the files wholesale from the original card for each partition and see how that works.

Comment 6

[cmtalbert]

The card won't mount an ext4 partition at all.

So, I can't partition it properly and copy files over.

Comment 7

[(not currently active) Ted Mielczarek]

Okay, that sucks. Can you put it onto a normal SD card, modify the partition table there (copying the contents of the partitions you're modifying off and then back on if that blows away the data) and then copy the whole image off with dd and back onto the industrial card?

Comment 8

[Mark Côté [:mcote]]

No activity; closing out.