sd card debian console image first sector

[joelk]

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?

[Robert Nelson]

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,

--
Robert Nelson
https://rcn-ee.com/

[Robert Nelson]

On Sun, Feb 14, 2016 at 6:43 PM, Robert Nelson <robert...@gmail.com> wrote:
> On Sun, Feb 14, 2016 at 6:26 PM, joelk <nikst...@gmail.com> wrote:
>>
>> 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.

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"

[William Hermans]

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  . . .

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[William Hermans]

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

Read if you're really worried *that* much.

[William Hermans]

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.

[joelk]

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.

[Robert Nelson]

On Feb 14, 2016 11:26 PM, "joelk" <nikst...@gmail.com> wrote:
>
> 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,

[joelk]

On Monday, February 15, 2016 at 12:42:28 AM UTC-5, RobertCNelson wrote:

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 Nelson]

> 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..

[joelk]

On Sunday, February 14, 2016 at 7:43:46 PM UTC-5, RobertCNelson wrote:

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,

--
Robert Nelson
https://rcn-ee.com/

 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?

[Robert Nelson]

any recent debian/debian-clone..

no virtualization thou...

[joelk]

On Monday, February 15, 2016 at 7:33:57 PM UTC-5, RobertCNelson wrote:

any recent debian/debian-clone..

no virtualization thou...

Regards,

--
Robert Nelson
https://rcn-ee.com/

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

[Robert Nelson]

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.

[joelk]

OK, thanks.