Problem
The problem I'm having was caused by the following action: When I had BBB connected to my PC (using USB cable), I accidentally formatted the ~92 MB partion that contained the getting started files.
Because of this, each time I apply power to BBB, the USB LEDs do not light up. It only works when I have the Angstrom image on an external microSD card.
What I've tried
I thought that this was caused because the eMMC is corrupt and for some reason is not bootable. So, I tried to boot from the external microSD card (that has the newest image running) and to use dd command where if was equal to the current microSD card and of to the target microSD card (built in on the board).
When I restarted the BBB, I looks like dd was successful (when I executed it, it told me that everything was successful). Now, there is one partition with the GettingStarted files and another with the Linux kernel.
Question
Despite this, it's not possible to boot from the internal microSD card. Does anyone know how this can be solved? Is there something to do with the boot order?
To force a boot from SD you need to remove power from the board completely, hold down S2 and then re-apply power. Keep holding the button until the four leds start turning on. You have to do this at power on, and once you've done it the board will continue to boot from SD on a reboot or reset, only removing power will change the behaviour.
You could also move R68 to R93 if you want to make the board boot from SD by default.
Also note the boot sequence in the table on page 6 of the schematics, by default if MLO can't be found on the eMMC, it'll look for it on the SD card. So deleting MLO normally causes the board to boot from SD if the appropriate files are present.
According to the Beaglebone Black Cook Book,
the card boots from the SD if available.
This is also how it work with Debian 8.3 image for BBB
(note that I am using the version of the image that does NOT
flash...).
Related
on a raspberry pi running buster i create a backup image of a raspberry pi 32 Gb SD card with the command
dd if=/dev/mmcblk0 of=//NAS/backup.img bs=1M conv=sync,noerror iflag=fullblock
the result file is 29,7 GB (31.915.507.712 bytes)
when i try to use balena etcher to write this file back to the SAME SD card, etcher tells me the SD card is to small. i am told i need additional 512 mb.
how to resolve this?
any advice is welcome.
I don't think stackoverflow is the right place for this question, there is also Linux stackexchange which would be more suited for this question.
But from my experience I think dd does not create images in the same way that rasperry images are created (if that makes sense). So in short you can't use balena etcher to restore the image, a friend if mine tried the same and failed.
So I would advice you to just live boot a linux and from there run the dd command to restore the image onto the sdcard. Maybe even the windows subsytem would also work but I didn't try so live usb stick would be the best I think.
So, I have a Raspbian Lite booted from PINN, the bootloader, on my Raspberry Pi 2B v1.1. I have it all written on a 8.0GB micro SD Card. I just bought an upgrade - a 64.0GB micro SD. I have a lot of things on my original 8GB SD, so I don't want to have to manually re-install every little thing I have.
My question is this: Is there a way to clone my whole card, with every partition, using the terminal in Raspbian Lite to a new SD Card?
I have tried rpi-clone: it seems to only copy over two partitions.
I have the 64GB plugged in via a USB adapter, no problem there.
Here are my partitions on my 8.0GB card:
Thanks, Bobbay
It's best to duplicate your SD card on a computer where the operating system is not running from that SD card - mainly because the contents of the card could change while you are duplicating it in a live system.
So, I would boot a PC off a live distro, like Knoppix. Once booted, start a Terminal and check the names of the disk drives like this:
ls /dev/sd?
You'll probably just have /dev/sda, but check! Now attach your 8GB SD card, wait a couple of seconds and check what name that got allocated. It's likely to be /dev/sdb
ls /dev/sd?
If it's /dev/sdb save that as SRC (source), like this:
SRC=/dev/sdb
Now attach your 64GB SD card, wait a couple of seconds and check what name that got allocated. It's likely to be /dev/sdc
ls /dev/sd?
If it's /dev/sdc save that as DST (destination), like this:
DST=/dev/sdc
If, and only if, everything works as above, you can now clone SRC to DST with:
sudo dd if=$SRC of=$DST bs=65536
The command above will take a fair time to run. Once it is complete, you will have a clone of your original disk, as /dev/sdc However, this will have the same size partitions as your 8GB drive, so you will want to expand the partitions out to fill the available space. I don't know which one(s) you want to expand, or by how much, but you will want to use the resize2fs command on the new disk. You can get help on that with:
man resize2fs
I need to modify a Raspbian image for use with Raspberry Pi's in a commercial setting. This way I won't have to modify the defaults of every single pi afterwards. I want to set the default keyboard to U.S., disable auto-login and boot to command line rather than GUI. Is it possible to modify an image with these settings before flashing each card? If so, how?
The easiest approach would be to get one Raspi behaving the exact way you want (called a golden master), then shut it down, pull the card, and do something similar to the following in your PC's SD card reader (from which I assume you baked the first card):
sudo dd if=/dev/<sddevice> bs=1k | gzip -c > myProduct-1.0-master.bin.gz
Then just bake that image onto card #2, #3...#n using:
zcat myProduct-1.0-master.bin.gz | sudo dd of=/dev/<sddevice> bs=1k
NB about card sizes: Always make sure your golden master card is SIGNIFICANTLY SMALLER than your target cards (ideally 2x, like 8-vs-16 GB). The reasons for this are twofold:
If both cards are "8GB," the target might be slightly smaller than the source (in which case you'll end up with filesystem truncation and possibly weirdness in subtle and unpredictable ways).
SD card controllers have EXTREMELY PRIMITIVE wear leveling and dd'ing over a bunch of zeroes defeats it utterly (which means cards can die if you're doing e.g. a bunch of logging). Keeping a bunch of unused space means that you have fallow cells that can be used by wear leveling (note that modern SSDs have much more sophisticated wear leveling and don't suffer from this problem for the most part).
I created a product not too long ago that did just this--the master was an 8GB full-size card and the targets were all 16GB micros. We'd put the master in the mass duplicator, then the targets and hit the big duplicate button. Because the cards were different storage sizes, we had ~50% underprovisioning (giving us tons of wear-level room) and because the cards were different physical sizes, we never mixed them up :-)
(Yes, I'm ridiculously conservative about wear-leveling--nothing worse IMO than having an embedded card die in the field and having to crawl through God-knows-what to replace a $8 part that didn't have to fail in the first place...)
It's worth creating a VERSION file on your master, as well, so as you rev your product you know which version is installed (you can edit /etc/issue to display that at the login prompt, or just edit some other arbitrary text file).
It's possible to create from-scratch images for the RasPi that have a more-tightly-controlled OS distro, but if you're only adjusting a couple of files, the easiest way is as I describe.
Oh, and make sure to save these versioned images someplace safe, like git LFS (e.g. https://git-lfs.github.com/).
Make all the changes you want on a raspberry pi.
Figure out where sd cards get mounted on your computer. On linux it will be something like /dev/sdb, on mac it will be something like /dev/rdisk2
Take your pi image, stick it in a computer and make a disk image dd if=/dev/<sd_path> of=~/raspi.img bs=1m
Flash your other cards: dd if=~/raspi.img of=/dev/<sd_path> bs=1m
I'm studying boot steps on a Pandaboard. According to this how-to, they have multiple boot steps (Boot rom > X-loader or SPL > U-boot > Linux kernel). Actually, I do not understand why they have such steps inefficiently. Can't I just load u-boot instead of using file called "MLO"? What does "MLO" actually do? Are there any important reasons that they have to put "MLO" instead of loading u-boot directly?
From eLinux.org:
http://elinux.org/Panda_How_to_MLO_%26_u-boot
The first-stage bootloader runs directly on the board from power-up. I
don't know the name of this bootloader(From TI official wiki, it
called Boot Rom). This bootloader initializes a minimal amount of CPU
and board hardware, then accesses the first partition of the SD card
(which must be in FAT format), and loads a file called "MLO", and
executes it. "MLO" is the second-stage bootloader.
The second-stage bootloader can apparently be one of either the
X-loader or SPL. This bootloader apparently also just reads the first
partition of the SD card, and loads a file called "u-boot.bin", and
executes it. "u-boot.bin" is the third-stage bootloader.
The third-stage bootloader is U-boot, which is a popular bootloader
for many different embedded boards and products. This bootloader has
lots of different features, including an interactive shell, variables,
ability to access the SD card and show its contents, etc. What happens
next depends on the version of U-boot you have for the Panda board,
and how it is configured. In a very simple configuration, U-Boot will
look for the file "uImage" in the root of the first partition of the
SD card (which, again, must be formatted as a FAT partition), and
execute that. This is the Linux kernel. U-Boot passes the kernel a
command line argument. Depending on how the kernel is configured it
may accept the command line from U-Boot, or use one that was compiled
into it when it was built.
This is a "Panda Board thing", not necessarily true of Linux in general.
However, most all systems have some kind of "multi-stage" boot like the one above. For example, booting a PC running Windows, you see:
BIOS startup
Boot sector is loaded from disk or USB; or a PXE boot record is read from the network
The windows kernel starts (the stuff you see before/during the "splash screen")
Finally, "Windows" itself starts
So it's neither "inefficient", nor unusual.
PS:
This link also has a good description of the boot load sequence:
http://omappedia.org/wiki/Bootloader_Project
PPS:
"MLO" stands for "Mmc LOader"
When the board comes up, the Memory Management Unit (MMU) still needs to be setup before the CPU can start using the SDRAM. The SoC has 56KB of SRAM which can be used at that point, but it is too small for u-boot to run from. The extra step is code running from SRAM will load and start u-boot.
I am using a rockchip 3188 based system on board which has 8 gb NAND flash.
I want to test the reliability of the NAND flash.
At least , I want to identify boards with bad NAND flashes shipping from factory.
I am using Ubuntu 14.04.
The NAND flash is partitioned into two parts :
1. mtd0: contains bootloader, kernel and initrd
2. mtd1: contains RFS
I tried running mtd_stresstest by "modprobe mtd_stresstest dev=1" and it never says a word. If I run it for too long, my system is getting corrupted. The corruption is expected as it is playing with the same device / is mounted on.
But the command is not returning even if I use count=1.
Please let me know what is going wrong.
I tried the following too:
Flashed a USB stick with ubuntu rfs meant for arm and plugged it to SOB.
bind mounted /proc to /media//proc
bind mounted /sys to /media/
cd /media/
chroot .
init 1
modprobe mtd_stresstest dev=1 count=1 ----> never says a word
Could you please also suggest if there is any other way test the NAND flash device reliability.