I am trying to get an original BeagleBoard (revC4) to boot a Angstrom OpenEmbedded image. Using instructions found here:
http://elinux.org/BeagleBoardAndOpenEmbeddedGit
and:
http://www.angstrom-distribution.org/building-angstrom
I have followed everything but the program freeze with message booting the kernel.
Output:
Texas Instruments X-Loader 1.4.2 (Feb 19 2009 - 12:01:24)
Reading boot sector
Loading u-boot.bin from mmc
U-Boot 2009.11 (Feb 23 2010 - 15:33:48)
OMAP3530-GP ES3.1, CPU-OPP2 L3-165MHz
OMAP3 Beagle board + LPDDR/NAND
I2C: ready
DRAM: 256 MB
NAND: 256 MiB
In: serial
Out: serial
Err: serial
Board revision C4
Die ID #40a8000400000000040365fa1301c014
Hit any key to stop autoboot: 0
mmc1 is available
reading boot.scr
** Unable to read "boot.scr" from mmc 0:1 **
reading uImage
4335440 bytes read
Booting from mmc ...
Booting kernel from Legacy Image at 82000000 ...
Image Name: Linux-3.2.28
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 4335376 Bytes = 4.1 MB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
I have tried both ttyS2 and ttyO2 in the bootargs without difference and have also upgraded both the xLoader and uBoot.
My end goal is to run a rudimentary ROS (Robot Operating System) and the BeagleBoard.
Any help would truly be appreciated.
I don't know if you ever got past this, but as I have recently been trying to get a Beagleboard up and running again, I'll put an answer here for the sake of anyone else trying to get things working.
TLDR version: Use Angstrom v2013.6 and hold the user button as you boot (or zero out the NAND flash) for the easiest solution that just works. See below for more details.
First of all, the place you're stuck at here is due to the u-boot flashed into NAND being out-of-date for a recent version of Angstrom. Simple fix is to hold down the user button when booting, which will bypass NAND and boot straight from the SD card, which presumably has the version of u-boot you just built. You can then stop the boot and either zero out the NAND or flash the current MLO and u-boot into it.
After that, you'll run into some more issues if you're using an image based on systemd. The meta-ti layer controls the basic parameters for the 'beagleboard' configuration and has its virtual/kernel provider set to linux-mainline, which is also in the meta-ti layer. At some point there was a new recipe version added for it which builds a 3.14 kernel, but the kernel configuration isn't suitable for systemd and the system will hang shortly after booting.
The good news is that Angstrom v2013.06 predates the 3.14 kernel change in meta-ti, and I was able to get that running just fine. I am trying to get a more recent Angstrom working with the 3.2 kernel that works with v2013.6, but I haven't had any luck yet.
Related
I'm trying to analyze and understand an embedded system that runs linux.
I'm pretty new to linux boot process, embedded linux etc, so I have to learn a lot but prefer learning by doing. So analyzing a system is the way I try to understand all this.
I already got some insight and learnt a lot in just looking at the bootmsg, checking some scripts and provided files (firmware) and trying to understand what's going on by just searching for answers here and elsewhere in the net. This might also be the reason for some wrong expressions I might use, I hope you can understand anyways. Atm I am not able to ask the creator of this system directly, so I hope you might help me out with some answers here.
So the System got a SOC (Marvell Armada-370 88F6707-A1) with some Flash (128 MiB - Hynix NAND (HY27U1G8F2BTR)) and DRAM (512 MB) and seems to load the bootload U-Boot from SPI flash (1MB).
As mentioned above as U-Boot is used as bootloader which then loads some Linux version 3.2.34. I think I already understand quite a bit of the general boot process here, but got some questions depending the provided bootargs.
Following is an excerpt of the printenv command (U-Boot environment)
image_name=uImage
mtdids=nand0=nand0
mtdparts=mtdparts=nand0:8m(kernel),6m(Initrd),-(rootfs)
select0=nand info
load0=nand read.e 0x02000000 0 360000
loadr0=nand read.e 0x04000000 800000 300000
boot=bootm 0x02000000 0x4000000
bootcmd=run beep select0 load0 loadr0 boot || run beep beep beep errled
bootargs=console=ttyS0,115200 root=ubi0:rootfs ubi.mtd=3,2048 initrd=0x12000000 rootfstype=ubifs
beep=beep
I see that they load the kernel and compressed ramdisk content into ram load0=nand read.e 0x02000000 0 360000 and loadr0=nand read.e 0x04000000 800000 300000. The kernel at start looks at 0x04000000 for the ramdisk_image and uncompresses to use the content for initial rootfs. Then the usual process with linuxrc / init begins... at the end the normal file system from nand (here rootfs partition of ubi device 0) is loaded as stated in kernel command line (root=ubi0:rootfs ubi.mtd=3,2048 rootfstype=ubifs). This is what I understood is happening here and might be pretty straight forward.
What I'm wondering now is the following bootargs part initrd=0x12000000. I don't quite get why they provide a different address here when we already let the kernel know about the real of the compressed ramdisk (as a second parameter of bootm).
I started the system with and without this parameter and it seems there are no differences.
As in my understanding of reading about that initrd= argument is that it seems to do the same as the second parameter that is already passed to bootm, it tells the kernel where to find an initrd to load the initial rootfs.
Could anyone explain why we here pass two different locations to an initrd to the kernel? Is this just some obsolete stuff that was forgotten to remove or is there a reason for?
Thanks in advance for your help.
I hope I haven't missed anything and the question wasn't already answered here somewhere, but I couldn't find anything.
edit-2:
Thanks to #sawdust in the comments I understood better what actually is going on here and saw the importance to add some more information to the question so an answer will be clearer to understand.
Here is a short excerpt of the bootmsg
> bootm 0x02000000 0x4000000
## Booting kernel from Legacy Image at 02000000 ...
Image Name: Linux-3.2.34
Created: 2013-08-15 4:18:54 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3464064 Bytes = 3.3 MB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 04000000 ...
Image Name:
Created: 2013-09-10 10:38:37 UTC
Image Type: ARM Linux RAMDisk Image (gzip compressed)
Data Size: 3030739 Bytes = 2.9 MB
Load Address: 12000000
Entry Point: 12000000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
I also always missed some information in this part of bootm that might have already gave a hint on what's happening here. And might have in correlation to the presence of same address should have lead to the path of answer.
edit-1: Added some more information about the hardware
edit-2: Added bootmsg for more information
I am trying to run linux on an Arduino Yun board. The Arduino board contains an Atheros AR9331 chipset
On U-Boot These are the steps I am doing:
1- Download the kernel :
ar7240> tftp 0x80060000 openwrt-ar71xx-generic-uImage-lzma.bin;
Load address: 0x80060000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
######################
done
Bytes transferred = 1441863 (160047 hex)
2- Erase Flash in order to copy the kernel:
ar7240> erase 0x9fEa0000 +0x160047
Error: end address (0xa0000046) not in flash!
Bad address format
This is the problem It seems that 0x9fEa0000 +0x160047 exceeds the total size of the flash.
So my questions are:
1- How can I figure the total amount of memory reserved for the flash in Uboot (From wich address it starts and ends), I am thinking about changing 0x9fEa0000 by a fewer address but i'am afraid i can harm other things
This is the output of the help:
ar7240> help
? - alias for 'help'
boot - boot default, i.e., run 'bootcmd'
bootd - boot default, i.e., run 'bootcmd'
bootm - boot application image from memory
cp - memory copy
erase - erase FLASH memory
help - print online help
md - memory display
mm - memory modify (auto-incrementing)
mtest - simple RAM test
mw - memory write (fill)
nm - memory modify (constant address)
ping - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
progmac - Set ethernet MAC addresses
reset - Perform RESET of the CPU
run - run commands in an environment variable
setenv - set environment variables
tftpboot- boot image via network using TFTP protocol
version - print monitor version
2- Is there someone experienced with Atheros AR9331 chipset who can help me find the Flash mapping (From where it starts and ends) from the datasheet
You can determine the flash layout from the kernel boot command line. Either run the printenv command in u-boot or boot into the existing kernel and look through the boot log. You need to find something like the following:
(There are plenty of guides on the internet, I took this one from https://finninday.net/wiki/index.php/Arduino_yun, your board may or may not be the same).
linino> printenv
bootargs=console=ttyATH0,115200 board=linino-yun mem=64M rootfstype=squashfs,jffs2 noinitrd mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,14656k(rootfs),1280k(kernel),64k(nvram),64k(art),15936k#0x50000(firmware)
bootcmd=bootm 0x9fea0000
This means there are the following partitions:
u-boot 0 to 256K (0x0 - 0x40000)
u-boot-env 256k to 320k (0x40000 - 0x50000)
rootfs (squashfs) 320k to 14976k (0x50000 - 0xea0000)
kernel 14976k to 16256k (0xea0000 - 0xfe0000)
nvram 16256k to 16320k (0xfe0000 - 0xff0000)
art 16320k to 16384k (0xff0000 - 0x1000000)
The rootfs partition is 14M, which is much larger than the rootfs image file (less than 8MB) so in theory you can move the kernel image at a lower address. For this you will need to modify the kernel boot line in the u-boot environment block (rootfs aand kernel partition sizes) and the bootcmd parameter so the u-boot know where the new kernel is located.
Flash is mapped to 0x9f000000 so the value in the bootcmd should be 0x9f000000 + the offset of the kernel in bytes.
What I am not sure about is if there is an overlay filesystem for any persistent changes to the flash. Can you boot into the existing system and post the output of df -h and cat /proc/mounts?
I have been working for a few days trying to get the UART1 port to work on a bbb. I flashed the prebuilt kernel from the elinux wiki (http://www.elinux.org/BeagleBoardUbuntu#Flasher), and the UART1 appears in the /dev folder (as /dev/ttyO1, with a capital "o" not a zero), but when I write to it, nothing comes out of the pins. I can use UART0 (on a separate little serial header, but not the one I need) without any trouble.
I see a lot of tutorials for enabling UART1 that deal with a folder called /sys/devices/bone_capemgr.* but I don't have one. I think it is because I have a newer kernel, and nearly all of those tutorials are exclusively for older kernels (<=3.8).
I read that the current 3.13 images from Robert C Nelson don't have a cape-manager (https://groups.google.com/forum/m/#!topic/beagleboard/ND3_w7_dn8Q), and you can use the "really simple cape manager" (https://github.com/RobertCNelson/rscm), but the build.sh script doesn't work on my 3.14 kernel. I tried to change a path in the script to fix it and now that bbb won't boot.
I also tried the beaglebone-universal-io script (
https://github.com/cdsteinkuehler/beaglebone-universal-io) but when I query the relevant pin:
sudo ./config-pin -q P8_26
I get the error:
P8_26 pinmux file not found!
Please verify your device tree file
Am I missing something really simple here?
I'm trying to understand embedded Linux principles and can't figure out addresses at u-boot output.
For example, I have UDOO board based on i.MX6 quad processor and I got following output from U-Boot:
U-Boot 2013.10-rc3 (Jan 20 2014 - 13:33:34)
CPU: Freescale i.MX6Q rev1.2 at 792 MHz
Reset cause: POR
Board: UDOO
DRAM: 1 GiB
MMC: FSL_SDHC: 0
No panel detected: default to LDB-WVGA
Display: LDB-WVGA (800x480)
In: serial
Out: serial
Err: serial
Net: using phy at 6
FEC [PRIME]
Warning: FEC MAC addresses don't match:
Address in SROM is 00:c0:08:88:a5:e6
Address in environment is 00:c0:08:88:9c:ce
Hit any key to stop autoboot: 0
Booting from mmc ...
4788388 bytes read in 303 ms (15.1 MiB/s)
## Booting kernel from Legacy Image at 12000000 ...
Image Name: Linux-3.0.35
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 4788324 Bytes = 4.6 MiB
Load Address: 10008000
Entry Point: 10008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
Starting kernel ...
I don't understand the value of Load address 0x10008000. According to documentation for this particular processor, at address zone 0x10000000 - 0xffffffff is mapped main memory. But what is 0x8000 offset? I can't figure out reason for this value.
I also don't understand address 0x12000000, where the kernel image is loaded from. Is there mapped memory region for SD card?
Please, can you give me some explanation for these addresses or even better, some references to resources about this topic. My goal is to learn how to port u-boot and Linux kernel to another boards.
Thank you!
If you check the environment variables of the u-boot, you will find that kernel image is copied from boot device to the RAM location(Here, 12000000) through command like fatload.
Now, This is not the LOADADDRESS. You give LOADADDRESS to command line while compiling the kernel, This address is mostly at 32K offset from start of the RAM in Physical address space of the processor.
Your RAM is mapped at 10000000 and kernel LOADADDRESS is 10008000(32K offset). bootm command uncompress the kernel image from 12000000 to 10008000 address and then calls the kernel entry point.
check out include/configs folder. It contains all the board definitions
i.MX uboot include/configs
To port uboot to another port, base on a very similar board and modify from there.
After having set-up and customized my "master" BeagleBone Black (BBB) with applications etc. on the on-board eMMC, I want to duplicate it on other BBB boards.
What is the best way to duplicate the BBB?
My understanding of options:
SD-Card: Programming each board by inserting a prepared SD card containing an image and pressing the "boot" switch while powering up.
How should I prepare that .img file or the SD card from my master BBB?
The image should copy to the on-board eMMC, so that the SD-card can be removed afterwards.
USB: Programming by connecting the board over USB to a (Win7) PC.
Is it possible to write the full on-board eMMC from the PC?
With which app to do the writing?
How to prepare the image which will be written, starting from the master BBB?
Ethernet: Programming over LAN after boot-up with default angstrom distro.
Is it even possible over LAN?
How to do the writing?
How to prepare the image which will be written, starting from the master BBB?
Which is possible/best?
Edit: My current solution is to flash with a standard image (from the BeagleBoe website) and then have a script do all modifications as expected. This includes disabling many services I don't need, installing applications and configuring stuff etc.
If there is an easier way for making a SD card with a full image on it, I'm still interested.
As noted at the bottom of the eLinux article, there is a much easier way if you are running the Debian distribution:
Boot master BBB with no SD card in
Insert SD card
Log in (e.g. with serial terminal, SSH etc.) and run sudo /opt/scripts/tools/eMMC/beaglebone-black-make-microSD-flasher-from-eMMC.sh. LEDs will flash in sequence whilst SD card is being written.
When the LEDs stop and the script terminates, remove the SD card.
Insert SD card into new BBB then power on.
eMMC will be flashed; LEDs on new BBB will flash in sequence until complete.
For anyone else that needs this, the best answer I've found to this is to do the following:
First setup your master Beaglebone Black the way you want it.
Backup the eMMC
FAT format a 4GB or larger SD card (must be a MBR/bootable formatted microSD card)
Download beagleboneblack-save-emmc.zip and extract the contents onto your SD card
Note: this is an image from Jason Krinder at his github https://github.com/jadonk/buildroot using the save-emmc-0.0.1 tag
Put the card into your powered off Beaglebone Black
Power on your Beaglebone Black while holding the S2 Button
The USR0 led will blink for about 10 minutes, when it's steady on you have an SD card with a copy of your eMMC in a .img file
Use the eMMC to flash a new Beaglebone Black
On the SD card edit autorun.sh
#!/bin/sh
echo timer > /sys/class/leds/beaglebone\:green\:usr0/trigger
dd if=/mnt/<image-file>.img of=/dev/mmcblk1 bs=10M
sync
echo default-on > /sys/class/leds/beaglebone\:green\:usr0/trigger
where <image-file> is the image file you got after copying backing up your eMMC
Insert the card into your powered off Beaglebone Black
Power on your Beaglebone Black while holding the S2 Button
The Beaglebone Black should go into rebuilding mode and within about 20 minutes you'll have a newly flashed Beaglebone Black (when all 4 USR LEDs are solid) with a copy of your original
eLinux reference used for this article - http://elinux.org/BeagleBone_Black_Extracting_eMMC_contents
I have the same need and am using dd and nc (NetCat) to save directly on my desktop without having to use an intermediary SD Card. You can do this over the USB connection, or ethernet connection, by changing the IP address in the steps below.
After setting up your BBB with the applications you want, the basic steps are:
On the desktop, run this command in a terminal:
nc -l 19000|bzip2 -d|dd bs=16M of=BBB.img
On the BeagleBone Black, run this command in a terminal (you can SSH into it, or do it directly from the BBB):
dd bs=16M if=/dev/mmcblk0|bzip2 -c|nc 192.168.7.1 19000
The 192.168.7.1 address is for the USB connection. (BBB is 192.168.7.2) If you're doing this over an ethernet connection, you should use your desktop's IP address.
This is taken from instructions here.
Finally, follow any method to install onto the next BBB. Here's an example of how to flash the emmc.
Copying your emmc Image back to a SD card is a bit tricky, since it will need to be formated in a certain way to get it to mount. Here are some tips to get that working: http://dev.gentoo.org/~armin76/arm/beagleboneblack/install_emmc.xml#expand
What might be easier is using an USB thumb drive, or USB SD card reader. Note, currently there are some issues hot-plugging USB devices, so boot with it plugged in.
You can copy your entire FS to the USB drive, then compress it. Create a new bootable linux sd image, and put your compressed FS on there and use one of the scripts Ottavio linked to to copy over the compressed image. you can make a systemd service to launch the script on startup.
We have noticed that on Beaglebones with the Jan 23rd 2015 release of Debian, the only way to successfully copy the image from SD is not to hold the boot button down when powering up.