just verifying one way to test an SD image for the xM

this note is not to pick on a particular SD card image for the xM,
it's to share one way to check on an image's validity and make sure
i'm not doing anything silly.

  from yesterday, i was suggesting that the SD card image you get from
the 4_25 zip file here:

  http://circuitco.com/support/index.php?title=BeagleBoard-xM

seems corrupt in some way. after unzipping, one gets the alleged
image file:

-rw-rw-r-- 1 rpjday rpjday 3948134400 2012-01-17 23:38 xMc_4_25.img

(is that the same size others are getting for the image file?)

  i still get an unzipping error:

$ unzip xMc_4_25.zip
Archive: xMc_4_25.zip
  inflating: xMc_4_25.img bad CRC 13edfed2 (should be 729c69cf)
$

so i thought i'd take a look inside the image file at the component
filesystems.

$ fdisk -l xMc_4_25.img

Disk xMc_4_25.img: 3948 MB, 3948134400 bytes
255 heads, 63 sectors/track, 480 cylinders, total 7711200 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

       Device Boot Start End Blocks Id System
xMc_4_25.img1 * 63 240974 120456 c W95 FAT32 (LBA)
xMc_4_25.img2 240975 7132859 3445942+ 83 Linux
$

  that looks reasonable, and it's what i would expect. now i can use
the mount "loop" option and offset to mount, say, the first
filesystem.

  from "bc", i get that 63 sectors * 512 bytes = 32256, so i should be
able to mount that FAT filesystem thusly (at some temporary directory
"m"):

$ sudo mount -o loop,offset=32256 xMc*img m

and, sure enough, the mount works and i can see the contents of that
filesystem:

$ ls -l m
total 3421
-rwxr-xr-x 1 root root 22232 2011-04-19 17:24 MLO
-rwxr-xr-x 1 root root 284788 2011-04-19 17:24 U-BOOT.BIN
-rwxr-xr-x 1 root root 134 2011-04-19 15:31 uEnv.txt
-rwxr-xr-x 1 root root 3194256 2011-04-19 17:24 UIMAGE
$

  now i *should* be able to unmount that filesystem and do the same
with the second one (offset = 512 * 240975 = 123379200):

$ sudo mount -o loop,offset=123379200 xMc*img m
mount: /dev/loop0: can't read superblock
$

  ok, that doesn't look good. is there any reason that shouldn't
work? if i do the same thing with the older 3_30 zip file and image
from that same page, the mount works just fine (same offsets in that
older image):

$ ls -l m
total 72
drwxr-xr-x 2 www-data www-data 4096 1969-12-31 20:01 bin
drwxr-xr-x 2 www-data www-data 4096 2011-03-29 09:31 boot
drwxr-xr-x 2 www-data www-data 4096 2011-03-29 09:29 dev
drwxr-xr-x 54 www-data www-data 4096 2011-03-29 10:31 etc
drwxr-xr-x 3 www-data www-data 4096 2011-03-29 09:26 home
drwxr-xr-x 5 www-data www-data 4096 1969-12-31 20:53 lib
drwx------ 2 root root 16384 2011-03-29 09:36 lost+found
drwxr-xr-x 12 www-data www-data 4096 1969-12-31 19:00 media
drwxr-xr-x 2 root root 4096 2011-03-29 15:55 mmc
drwxr-xr-x 2 www-data www-data 4096 2011-03-29 09:26 mnt
-rw-r--r-- 1 www-data www-data 0 2011-03-29 09:37 narcissus-was-here
drwxr-xr-x 2 www-data www-data 4096 2011-02-20 14:13 proc
drwxr-xr-x 2 www-data www-data 4096 1969-12-31 20:01 sbin
drwxr-xr-x 2 www-data www-data 4096 2011-02-20 14:13 sys
lrwxrwxrwx 1 root root 8 1969-12-31 22:22 tmp -> /var/tmp
drwxr-xr-x 12 www-data www-data 4096 2010-11-05 10:38 usr
drwxr-xr-x 9 www-data www-data 4096 2011-02-09 06:18 var
$

  at this point, unless someone can suggest something i've done
stupidly, i'm fairly convinced that that 4_25 image is damaged with
respect to the linux filesystem. and, besides, i really want the 4_26
image that's shipping with current xMs anyway.

rday

Why not use kpartx?

well, ok, there's that, too. :slight_smile:

rday

We just checked the image and it is fine, sort of. An image is just that. An image of an existing SD card. We tried it on a SanDisk card and it was fine. If we tired it on another card, it got 98% and it failed to write. We have seen this issue many times in that not all SD cards are the same and they are never actually 4G in size. We are going to find re-post the image from a smaller size card so that it will have a better shot at fitting a smaller card.

Gerald

crap, i'm embarrassed to admit i didn't think of that. just another
one of those little glitches i'm adding to my cheat sheet of things to
watch for as i rewrite my course.

  also, i just tried the "dd" with an *allegedly* 4G micro SD card and
got "No space left on device" at the end of the write so, at the risk
of embarrassing myself further, is there a way to check the *actual*
size of an SD card, short of, say, just trying to "dd" *from* it and
seeing how much i get? obviously, at this point, there's no way to
trust what's in the partition table, is there?

rday

hang on, i'm not sure i buy that. even if i were to have trouble
copying to an SD card, i should still be able to use mount to mount
the linux filesystem inside that SD card image, yes?

  what do you have as an md5sum for the img? i have:

93218e3a9e3f7031b41e84d915f809d2 xMc_4_25.img

if yours matches, then i'm still confused.

rday

Let me check.

Gerald

With the dl copy i have, I'm seeing:

~/ti$ md5sum xMc_4_25.*
7d47a6e44ff31b9a138aba7d47dd0bdf xMc_4_25.img
05efd118510e68737f2667d9a7052bab xMc_4_25.zip

Regards,

I downloaded a fresh copy of the file and checked it.

05efd118510e68737f2667d9a7052bab *xMc_4_25.zip

7d47a6e44ff31b9a138aba7d47dd0bdf *xMc_4_25.img

Gerald

Hello every body,

I plan to buy the Beaglebone but I need to know if I can have the following pin availability

I need :

25 output bits

19 input bits with 6 interrupts

2 I2C port bits for ds1307 RTC chip

Can I have this configuration with such a card ?

And how can I do to change a GPIO fonctionnality.

Thank’s a lot from France four your answers

Italo

on my ubuntu 11.10 system:

$ md5sum xMc_4_25.zip
05efd118510e68737f2667d9a7052bab xMc_4_25.zip
$

  good, good. and now ...

$ unzip xMc_4_25.zip
Archive: xMc_4_25.zip
  inflating: xMc_4_25.img bad CRC 13edfed2 (should be 729c69cf)
$

  that does *not* look good, especially since:

$ md5sum xMc_4_25.img
bf52e3702a1c208b07984b5ecb8fdca4 xMc_4_25.img
$

  ??? how is that possible? my zip file matches but the
extracted img file doesn't? are you doing something other than a
plain "unzip"?

rday

might be a bug in unzip (32bit maybe?)

I'm using (on x86_64)

voodoo@voodoo-e6400:~/ti$ unzip -v
UnZip 6.00 of 20 April 2009, by Debian. Original by Info-ZIP.

Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip/ ;
see ftp://ftp.info-zip.org/pub/infozip/UnZip.html for other sites.

Compiled with gcc 4.5.2 for Unix (Linux ELF) on Jan 28 2011.

Regards,

I use 7-zip.

Gerald

... snip ...

might be a bug in unzip (32bit maybe?)

I'm using (on x86_64)

voodoo@voodoo-e6400:~/ti$ unzip -v
UnZip 6.00 of 20 April 2009, by Debian. Original by Info-ZIP.

Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip/ ;
see ftp://ftp.info-zip.org/pub/infozip/UnZip.html for other sites.

Compiled with gcc 4.5.2 for Unix (Linux ELF) on Jan 28 2011.

  exactly the same for me on this 64-bit ubuntu 11.10 system:

===== start =====

UnZip 6.00 of 20 April 2009, by Debian. Original by Info-ZIP.

Latest sources and executables are at
ftp://ftp.info-zip.org/pub/infozip/ ;
see ftp://ftp.info-zip.org/pub/infozip/UnZip.html for other sites.

Compiled with gcc 4.5.2 for Unix (Linux ELF) on Jan 28 2011.

UnZip special compilation options:
        ACORN_FTYPE_NFS
        COPYRIGHT_CLEAN (PKZIP 0.9x unreducing method not supported)
        SET_DIR_ATTRIB
        SYMLINKS (symbolic links supported, if RTL and file system permit)
        TIMESTAMP
        UNIXBACKUP
        USE_EF_UT_TIME
        USE_UNSHRINK (PKZIP/Zip 1.x unshrinking method supported)
        USE_DEFLATE64 (PKZIP 4.x Deflate64(tm) supported)
        UNICODE_SUPPORT [wide-chars, char coding: UTF-8] (handle UTF-8 paths)
        LARGE_FILE_SUPPORT (large files over 2 GiB supported)
        ZIP64_SUPPORT (archives using Zip64 for large files supported)
        USE_BZIP2 (PKZIP 4.6+, using bzip2 lib version 1.0.5, 10-Dec-2007)
        VMS_TEXT_CONV
        WILD_STOP_AT_DIR
        [decryption, version 2.11 of 05 Jan 2007]

UnZip and ZipInfo environment options:
           UNZIP: [none]
        UNZIPOPT: [none]
         ZIPINFO: [none]
      ZIPINFOOPT: [none]
$

===== end =====

  i'm baffled. how can something as trivial as unzip be doing strange
things? and there's this:

$ unzip -t xMc_4_25.zip
Archive: xMc_4_25.zip
    testing: xMc_4_25.img bad CRC 13edfed2 (should be 729c69cf)
At least one error was detected in xMc_4_25.zip.
$

  is it too early to start drinking?

rday

ok, so i installed p7zip-full, and now:

$ 7z t xMc_4_25.zip

7-Zip [64] 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18
p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,8 CPUs)

Processing archive: xMc_4_25.zip

Testing xMc_4_25.img

Everything is Ok

Size: 3948134400
Compressed: 228082726
$

  and ...

$ 7z x xMc_4_25.zip

7-Zip [64] 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18
p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,8 CPUs)

Processing archive: xMc_4_25.zip

Extracting xMc_4_25.img

Everything is Ok

Size: 3948134400
Compressed: 228082726
$

  and *now* my md5sum matches yours. at the risk of appearing
clueless, what the heck just happened there? unzip fails, but 7z
works? why?

rday

You got me surrounded!!!

Gerald

Ubuntu has had serious problem with unzip in the past. Another reason to stay away from it.

hardware issues, random software bugs, etc.. :wink:

Sounds like the md5sum's should be atleast published on:
http://circuitco.com/support/index.php?title=BeagleBoard-xM

with a warning linux "unzip" may fail use "7z t"

Regards,

ok, i'm good with that. but i think people are starting to see my
rationale for wanting to start from ground zero and document, command
by command, this sort of stuff. if i'd tried this in a classroom
setting with a client who was paying serious $$$ for a course in
embedded linux, getting hung up on "unzip" would have been
disastrously embarrassing.

rday

Ubuntu has had serious problem with unzip in the past. Another reason to stay away from it.

It also fails on Fedora 13 and higher :frowning: