sd card debian console image first sector

I downloaded the debian 7.9 console image (bone-debian-7.9-console-armhf-2015-11-03-2gb.img) and wrote it to a micro sd card using dd:

dd bs=4M if=bone-debian-7.9-console-armhf-2015-11-03-2gb.img of=/dev/sdb

I notice that after flashing, the sdb1 partition on the card begins at sector 2048. The original formatting of these cards have the data area beginning at sector 8192 and other sd card images that I’ve written (e.g. Raspbian Jessie) also start at sector 8192. I was under the impression that this was done to reduce the number of pages that have to be rewritten when data is saved to the card.

Am I wrong about that? Is there a reason why this debian image starts at 2048? Is there a way to control where the image is written to the sd card?

Feel free to play around with this setting yourself:

bone-debian-7.9-console-armhf-2015-11-03-2gb.img came from
debian-7.9-console-armhf-2015-11-03.tar.xz

So:

wget https://rcn-ee.net/rootfs/bb.org/release/2015-11-03/console/debian-7.9-console-armhf-2015-11-03.tar.xz
tar debian-7.9-console-armhf-2015-11-03.tar.xz
cd debian-7.9-console-armhf-2015-11-03

The "2048" = 1MB setting is hardcoded here:

https://github.com/RobertCNelson/omap-image-builder/blob/103aea2682053767c333a64586155dead9fbf7c2/tools/setup_sdcard.sh#L1466

So modify it to "4" = 8192...

Then run:

sudo ./setup_sdcard.sh \
--img-2gb bone-debian-7.9-console-armhf-2015-11-03 \
--dtb beaglebone --beagleboard.org-production \
--boot_label BEAGLEBONE --rootfs_label rootfs \
--bbb-old-bootloader-in-emmc --hostname beaglebone \
--enable-systemd

Regards,

BTW, 8192 is all mostly tied to fat, which we don't use anymore by default...

https://wiki.linaro.org/WorkingGroups/KernelArchived/Projects/FlashCardSurvey

under: "FAT optimization"

Regards,

BTW, 8192 is all mostly tied to fat, which we don’t use anymore by default…

https://wiki.linaro.org/WorkingGroups/KernelArchived/Projects/FlashCardSurvey

under: “FAT optimization”

Some people seem to think that 8192 sectors is where an sdcard needs to start in order to perform the best, and to keep from “destroying” the card. Something to do with where erase blocks start and all that but . . . I’ve been using 2048 now for 3 years with this hardware using the same sdcard, and have written at least 50 fresh images to it . . .

It’s not as though this hardwares sdcard controller is the fastest around either . . . because it’s not. From what I’ve read for performance specs of the rPI’s sdcard. This one is about half as fast. BUt the rPI also does not have an on board eMMC either.

Anyway, there seems to be a lot of concern about prematurely killing sdcard using wrong sector values, and perhaps that is true, but I’ve yet to see a card failure yet on our BBB’s . . .

Oh, and right . . . http://lwn.net/Articles/428584/

Read if you’re really worried that much.

One I forgot to mention that is fairly important. First, in units, MiB is NOT equivalent to MB. One is Mebi, the other is Mega. That is, 1024 versus 1000 bytes - per unit. So when you see people saying that the first erase block group should be at 4MiB on an sdcard. They are probably wrong. OEM venders in the consumer market typically do not use Mebibyte as a size measurement. They use Mega, giga kilo, etc.

Hmm … a lot to absorb. Thanks for your replies.

It’s not that I’m so worried about wearing out the uSD card. But I’ve only just started playing around with the BBB and the Pi and I’m already getting the impression that the BBB is noticeably slower than the Pi at capturing and processing webcam streams. I just didn’t want to do anything that would slow it down even more by creating an unnecessary bottleneck in writing images to the uSD.

It didn’t occur to me that running off the sd card would be much slower than the eMMC. So maybe a better strategy, when I want to use a different image, would be to save the eMMC to a backup image and flash a new one to the eMMC.

Hmm … a lot to absorb. Thanks for your replies.

It’s not that I’m so worried about wearing out the uSD card. But I’ve only just started playing around with the BBB and the Pi and I’m already getting the impression that the BBB is noticeably slower than the Pi at capturing and processing webcam streams. I just didn’t want to do anything that would slow it down even more by creating an unnecessary bottleneck in writing images to the uSD.

Nah… Depends on the USB camera and kernel version… The USB bus on the BBB is very picky…

It didn’t occur to me that running off the sd card would be much slower than the eMMC. So maybe a better strategy, when I want to use a different image, would be to save the eMMC to a backup image and flash a new one to the eMMC.

Yes/no… The emmc has an 8bit interface advantage over the 4bit microsd interface.

But for the price point, the onboard 4gb emmc, is on the cheap side NOT the fastest.

So you can definitely pay and get a faster microsd card… (Sandisk SDXC 64gb pro’s…)

Regards,

Robert, are you saying that read/write with a Sandisk uSD[XH]C Pro would be faster than the eMMC? How about the Sandisk uSD[XH]C Ultra Plus?

And another question: I’m curious as to why your BBB images are set up as a single partition as opposed to having a separate FAT16 boot partition which it seems used to be the norm?

Robert, are you saying that read/write with a Sandisk uSD[XH]C Pro would be
faster than the eMMC? How about the Sandisk uSD[XH]C Ultra Plus?

SanDisk Ultra SDHC
root@beaglebone:~# hdparm -tT /dev/mmcblk0

/dev/mmcblk0:
Timing cached reads: 436 MB in 2.00 seconds = 217.65 MB/sec
Timing buffered disk reads: 62 MB in 3.07 seconds = 20.21 MB/sec

BBG: Micron eMMC
root@beaglebone:~# hdparm -tT /dev/mmcblk1

/dev/mmcblk1:
Timing cached reads: 442 MB in 2.01 seconds = 220.37 MB/sec
Timing buffered disk reads: 102 MB in 3.00 seconds = 33.96 MB/sec

And another question: I'm curious as to why your BBB images are set up as a
single partition as opposed to having a separate FAT16 boot partition which
it seems used to be the norm?

There is no good reason to have that legacy partition.

bootloader -> mbr
u-boot can read extX, so the kernel files are in the rootfs
the beagleboard doc's are in an apt package that can be updated..

Regards,

My bash scripting ability is very limited, but after looking at that script I believe it’s intended to be run on the BB itself – booted from the eMMC and with the uSD card to be written inserted. Is that correct?

It needs to be run that way in order to copy the bootloader from the eMMC?

Do you have a script available to create a bootable image on a pc which can then be dd’d onto the SD card?

any recent debian/debian-clone..

no virtualization thou...

Regards,

???
I don’t understand. Was that the answer to the wrong question?

the bash "setup_sdcard.sh" script can be run on any recent
debian/debian-clone based distro, running x86/arm/etc..

It'll generate an *.img file you can dd to the microSD.

Regards,

OK, thanks.