qemu-system-arm hangs with Raspberry Pi 2 image - raspberry-pi

I'm trying to run a Yocto Raspberry Pi 2 build on qemu-system-arm.
I got this far:
$ qemu-system-arm -version
QEMU emulator version 2.10.1(Debian 1:2.10+dfsg-0ubuntu3.5)
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
$ qemu-system-arm \
-M raspi2 \
-cpu arm1176 \
-dtb ./tmp/deploy/images/raspberrypi2/bcm2709-rpi-2-b.dtb \
-sd ./tmp/deploy/images/raspberrypi2/berrynux-image-raspberrypi2.rootfs.rpi-sdimg \
-m 1G \
-smp 1 \
-nographic \
-kernel ./kernel-qemu \
-append "rw earlyprintk loglevel=8 console=ttyS0 dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2" \
-serial mon:stdio
Execution hangs with:
WARNING:
Image format was not specified for
'./tmp/deploy/images/raspberrypi2/berrynux-image-raspberrypi2.rootfs.rpi-sdimg' and probing guessed raw.
Automatically detecting the format is dangerous for
raw images, write operations on block 0 will be restricted.
Specify the 'raw' format explicitly to remove the restrictions.
The kernel produced by meta-raspberrypi (kernel7.img) immediately breaks qemu with:
qemu-system-arm: Trying to execute code outside RAM or ROM at 0xe0833006
so i'm using kernel-qemu-4.4.34-jessie instead (tried stretch and wheezy, same result - hang)
Not ever sure where to start debugging here, is this even attempting to boot? Can i hammer it to give me some useful output? Do i need a specially baked kernel, and if so, where do i get it from?
strace didn't get me anywhere (or i don't know how to interpret the output):
...
openat(AT_FDCWD, "./kernel-qemu-4.4.34-jessie", O_RDONLY) = 11
lseek(11, 0, SEEK_END) = 3024048
mmap(NULL, 3026944, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f4ed8106000
lseek(11, 0, SEEK_SET) = 0
read(11, "\0\0\240\341\0\0\240\341\0\0\240\341\0\0\240\341\0\0\240\341\0\0\240\341\0\0\240\341\0\0\240\341"..., 3024048) = 3024048
close(11) = 0
access("./tmp/deploy/images/raspberrypi2/bcm2709-rpi-2-b.dtb", R_OK) = 0
openat(AT_FDCWD, "./tmp/deploy/images/raspberrypi2/bcm2709-rpi-2-b.dtb", O_RDONLY) = 11
lseek(11, 0, SEEK_END) = 16693
close(11) = 0
openat(AT_FDCWD, "./tmp/deploy/images/raspberrypi2/bcm2709-rpi-2-b.dtb", O_RDONLY) = 11
lseek(11, 0, SEEK_END) = 16693
lseek(11, 0, SEEK_SET) = 0
read(11, "\320\r\376\355\0\0A5\0\0\0H\0\0;0\0\0\0(\0\0\0\21\0\0\0\20\0\0\0\0"..., 16693) = 16693
close(11) = 0
futex(0x563f38608c3c, FUTEX_WAKE_PRIVATE, 2147483647) = 1
futex(0x563f383d040c, FUTEX_WAKE_PRIVATE, 2147483647) = 1
futex(0x563f384305cc, FUTEX_WAKE_PRIVATE, 2147483647) = 1
ppoll([{fd=0, events=POLLIN}, {fd=3, events=POLLIN}, {fd=5, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5, {tv_sec=0, tv_nsec=0}, NULL, 8) = 0 (Timeout)
futex(0x563f372cac00, FUTEX_WAKE_PRIVATE, 1) = 1
ppoll([{fd=0, events=POLLIN}, {fd=3, events=POLLIN}, {fd=5, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5, {tv_sec=1, tv_nsec=0}, NULL, 8) = 0 (Timeout)
ppoll([{fd=0, events=POLLIN}, {fd=3, events=POLLIN}, {fd=5, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5, {tv_sec=1, tv_nsec=0}, NULL, 8) = 0 (Timeout)
The POLLIN event repeats indefinitely every second.
The SD card image boots just fine on real hardware Pi2.
EDIT
I copied over kernel7.img and bcm2709-rpi-2-b.dtb from the latest Raspbian Stretch image and i'm stil getting the same exact hang. I'm starting to think there's something screwy with my QEMU build - it's the stock Ubuntu 17.10 .deb package.
EDIT #2
Compiled qemu-2.12.0-rc2 from source, same deal. I must be doing something terribly wrong.

"Nothing happens" and "tried to execute from a bogus address" are often the result of either:
misconfigured kernel (is this kernel definitely intended to boot on the raspi2 board, and not on something else?)
something goes wrong in early boot before the kernel manages to produce output (though usually this causes a hang rather than a bad-address output)
For the latter, assuming this really is a raspi2 kernel, you might try using
earlycon=pl011,0x3f201000
in your kernel append arguments. (The Linux kernel can produce earlycon output for the PL011 UART, but not for the raspi-specific 'mini UART'.)
I would suggest also dropping "-nographic" and "-serial mon:stdio" for the moment. Then you can use the graphical UI to check both UART outputs. (You can do this without using the GUI by redirecting them both correctly using two lots of -serial command line options, but then you have to figure out sensible places to send them; the GUI's simpler.) The first serial port will be the PL011, and the second the mini-UART, so if you only tell QEMU where to send the first serial port output and the guest is writing to the second, you'll never see it.

When it comes to QEMU on arm Yocto is tested for versatilepb machine. Therefore, there might be issues for other configs. It is recommended to look into runqemu script for all the options on how qemu is configured to run.

Related

Different behavior of mpiexec in Windows and in Ubuntu

I have a code in Fortran (program.f) and I have compiled it with Eclipse in \ubuntu 16 and in Windows 7.
The Eclipse configuration for Ubuntu is the follow:
GNU Fortran Compiler: gfortran
Include paths(-l) : /usr/lib/openmpi/include
GNU Fortran Linker : mpif90
Tool Chain Editor : GCC Fortran
The Eclipse configuration for Windows is the follow:
GNU Fortran Compiler: gfortran
Include paths(-l) : C:\cygwin64\usr\include
GNU Fortran Linker : mpif90
Tool Chain Editor : GCC Fortran
When I execute the program in Ubuntu, the program works how it is expected.
In Ubuntu the program is executed with 2 processors by doing
$ mpiexec -np 2 myprogram
And the behavior is the follow
$ mpiexec -np 2 myprogram
There are 2 processors running this job.
Rank# 1 d1= 65 d2= 128
Rank# 0 d1= 1 d2= 64
Where d1 and d2 are pieces of the problem domain assigned to each processors. In this example the total domain is 128. The domain was assigned from 1 to 64 to processor 0, and from 65 to 128 to processor 1. This is the expected behavior: the model of 128 are divided in 2, from 1 to 64 to processor 0, and from 65 to 128 for the processor 1.
For the other hand, in Windows, after compile the code using the mentioned specifications, I execute the program by doing:
$ mpiexec.exe -n 2 myprogram.exe
And the behavior is the follow
$ mpiexec -np 2 myprogram
There are 1 processors running this job.
Rank# 0 d1= 1 d2= 128
Rank# 0 d1= 1 d2= 128
We can see that the behavior is different: the program executed in Windows is not running in parallel as it is expected. In the terminal we can see that 1 processor is running the program, and the domain is assigned as follow: from 1 to 128 (whole domain) to processor 0 and, from 1 to 128 (whole domain again?) to processor 0. This is the problem that I am trying to solve. I am trying to have the same behavior that I have in Ubuntu.
The mpiexec.exe program for Windows was obtained from the official installer MS-MPI.
The gfortran and the OpenMPI libs for Windows were obtained by using cygwin
I tried to change the GNU linker and the compiler in Eclipse for Windows and does not work. I tried to run the code in others machines with Windows 10 and problem is the same.
Any suggestions on how to try solve this issue?
As mentioned by #jcgiret there are a consistency problem: the program is compiled using OpenMPI and it is executed with MS-MPI.
To solve this issue the code was executed using the equivalent to mpiexec defined in the openmpi package:
usr/bin/mpiexec -> orterun.exe
The program is executed in windows by
$ orterun.exe -n 2 myprogram.exe
Then the results is the same that obtained in Ubuntu:
$ orterun.exe -n 2 myprogram.exe
There are 2 processors running this job.
Rank# 1 d1= 65 d2= 128
Rank# 0 d1= 1 d2= 64

fzn2smt solver answers with `unknown` on tested formulas

The fzn2smt tool allows one to solve flatzinc formulas via Yices.
When I try to run it, the solver answers with UNKNOWN to every formula I test. e.g.:
~$ java -Xmx4096M fzn2smt -ce "./yices-2.5.2/bin/yices -f" -i 2DPacking.fzn
Time1:170
=====UNKNOWN=====
However, on the given example, it seems to correctly create the 2DPacking.fzn.smt instance in the same directory of the 2DPacking.fzn file:
~$ ls
2DPacking.fzn.smt 2DPacking.fzn 2DPacking.mzn 2DPacking.ozn
If I manually run Yices over the smt formula, I get a positive result:
~$ yices-smt -f 2DPacking.fzn.smt
sat
(= x____00002_6_ 0)
...
IMPLICANT:
(>= x____00003_4_ 0)
...
Q: Does anyone else have experience with fzn2smt and know how to fix this issue?
Just to be sure that the issue I am experiencing is not due to the installation part, I will share it here:
main_dir
main_dir/fzn2smt-2-0-02 # unpacked fzn2smt files
main_dir/antlr # unpacked antlr-runtime-3.5 files
main_dir/yices-2.5.2 # unpacked yices files
I also modified the environment variables as requested by the tool instructions:
PATH=${main_dir}/yices-2.5.2/bin/:${PATH}
PATH=${main_dir}/fzn2smt-2-0-02/:${PATH}
CLASSPATH=${main_dir}:${CLASSPATH}
CLASSPATH=${main_dir}/antlr:${CLASSPATH}
CLASSPATH=${main_dir}/fzn2smt-2-0-02:${CLASSPATH}
As #Dekker suggested in the comments, the issue is due to fzn2smt seemingly not being updated in a while.
After some trials and errors, I found out that the most recent version of Yices that appears to be compatible with fzn2smt is version 2.2.1.
It can be executed as follows:
~$ java -Xmx4096M fzn2smt -ce "./yices-2.2.1/bin/yices-smt -f" -i 2DPacking.fzn
Time1:162
Time: 207
Pos: 0
item = array2d(1..2, 1..4, [0, 0, 0, 0, 1, 1, 1, 1]);
obj = 1;
----------
Time: 223
Pos: 0
item = array2d(1..2, 1..4, [0, 0, 0, 0, 1, 1, 1, 1]);
obj = 1;
----------
==========
Time2:228
Originally, fzn2smt was coupled with version 2 of Yices presented at the SMT-COMP 2009. To use that version, the command-line instruction to use the tool is slightly different:
~$ java -Xmx4096M fzn2smt -ce "./yices2smt09/bin/yices -f" -i 2DPacking.fzn
Time1:160
Time: 208
Pos: 0
item = array2d(1..2, 1..4, [0, 0, 0, 0, 1, 1, 1, 1]);
obj = 1;
----------
==========
Time2:223
Notice that
the executable is named yices here, rather than yices-smt
the output is slightly different, for some reasons the solution is printed more than once when using the newer version of the tool
Old versions of Yices can be downloaded from here.

cannot boot-up openwrt for beagle bone black(BB-black)

I am trying porting openwrt to BBB. And as shown in title, I cannot boot-up openwrt on BeagleBone Black.
If someone have tried to do something on BeagleBone Black(BBB), you must know there are two partitions in its flash or SD card.
The first partition is FAT32 as a boot partition, the second partition is Ext4 as linux root file system.
When I use original files and BINs of Angstrom for BBB, I can start up system.
My work is related to http://wiki.openwrt.org/toh/beaglebone/black#installation
I have done many experiments:
Use BINs and other files, rootfs etc. on snapshot of OPENWRT to replace all the original files. When I power on BBB, I cannot see any log from UART. I think the MLO file on snapshot is wrong.
I modified uEvn.txt only. I can see the log as shown below.
gpio: pin 53 (gpio 53) value is 1
mmc0 is current device
micro SD card found
mmc0 is current device
gpio: pin 54 (gpio 54) value is 1
SD/MMC found on device 0
reading uEnv.txt
438 bytes read in 3 ms (142.6 KiB/s)
Loaded environment from uEnv.txt
Importing environment from mmc ...
Running uenvcmd ...
reading zImage
2051400 bytes read in 238 ms (8.2 MiB/s)
reading am335x-boneblack.dtb
** Unable to read file am335x-boneblack.dtb **
ERROR: Did not find a cmdline Flattened Device Tree
Could not find a valid device tree
gpio: pin 55 (gpio 55) value is 1
** File not found /boot/uImage **
I only replace zImage which on snapshot to my flash.
The log from UART shows that, boot-up flow stopped at
Starting kernel ...
Log shown as below.
U-Boot SPL 2014.01-rc1-00172-ge7e17b0 (Dec 12 2013 - 15:20:09)
reading args
spl: error reading image args, err - -1
reading u-boot.img
reading u-boot.img
U-Boot 2014.01-rc1-00172-ge7e17b0 (Dec 12 2013 - 15:20:09)
I2C: ready
DRAM: 512 MiB
WARNING: Caches not enabled
NAND: 0 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Warning - readenv() failed, using default environment
Net: <ethaddr> not set. Validating first E-fuse MAC
cpsw, usb_ether
Hit any key to stop autoboot: 0
mmc0 is current device
SD/MMC found on device 0
reading uEnv.txt
494 bytes read in 5 ms (95.7 KiB/s)
Loaded environment from uEnv.txt
Importing environment from mmc ...
Running uenvcmd ...
reading zImage
2187584 bytes read in 214 ms (9.7 MiB/s)
reading am335x-boneblack.dtb
25172 bytes read in 11 ms (2.2 MiB/s)
Kernel image # 0x80200000 [ 0x000000 - 0x216140 ]
Starting kernel ...
To this step, I found that the files on snapshot may not suit for BBB.
And after that, I compile my own version of openwrt for BBB. And replace zImage. The issue is still block in starting kernel.
So Is there anybody have some experience for porting openwrt to BBB?
Can you show me what I should do for porting. Or did I do something wrong?
If someone have compiled your own openwrt version for BBB, could you please share your config file to me?
Thanks so much.
Post my uEvn.txtx first:
cat /mnt/p1/uEnv.txt
kernel_file=zImage
fdtfile=am335x-boneblack.dtb
loadzimage=load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${kernel_file}
loadfdt=load mmc ${mmcdev}:${mmcpart} ${fdtaddr} ${fdtfile}
console=ttyO0,115200n8
mmcroot=/dev/mmcblk0p2 ro
mmcrootfstype=ext4 rootwait
mmcargs=setenv bootargs console=${console} root=${mmcroot} rootfstype=${mmcrootfstype} ${optargs}
uenvcmd=run loadzimage; run loadfdt; run mmcargs; bootz ${loadaddr} - ${fdtaddr}
optargs="debug init=/etc/preinit"
OUTPUT from printenv:
arch=arm
baudrate=115200
board=am335x
board_name=A335BNLT
board_rev=00A5
boot_fdt=try
bootcmd=i2c mw 0x24 1 0x3e; run findfdt; run mmcboot;setenv mmcdev 1; setenv bootpart 1:2; run mmcboot;run nandboot;
bootcount=1
bootdelay=1
bootdir=/boot
bootenv=uEnv.txt
bootfile=zImage
bootpart=0:2
console=ttyO0,115200n8
cpu=armv7
dfu_alt_info_emmc=rawemmc mmc 0 3751936
dfu_alt_info_mmc=boot part 0 1;rootfs part 0 2;MLO fat 0 1;MLO.raw mmc 100 100;u-boot.img.raw mmc 300 400;spl-os-args.raw mmc 80 80;spl-os-image.raw mmc 900 2000;spl-os-args fat 0 1;spl-os-image fat 0 1;u-boot.img fat 0 1;uEnv.txt fat 0 1
dfu_alt_info_nand=SPL part 0 1;SPL.backup1 part 0 2;SPL.backup2 part 0 3;SPL.backup3 part 0 4;u-boot part 0 5;u-boot-spl-os part 0 6;kernel part 0 8;rootfs part 0 9
dfu_alt_info_ram=kernel ram 0x80200000 0xD80000;fdt ram 0x80F80000 0x80000;ramdisk ram 0x81000000 0x4000000
ethact=cpsw
ethaddr=7c:66:9d:53:6f:07
fdt_high=0xffffffff
fdtaddr=0x80F80000
fdtfile=am335x-boneblack.dtb
filesize=1f8
findfdt=if test $board_name = A335BONE; then setenv fdtfile am335x-bone.dtb; fi; if test $board_name = A335BNLT; then setenv fdtfile am335x-boneblack.dtb; fi; if test $board_name = A33515BB; then setenv fdtfile am335x-evm.dtb; fi; if test $board_name = A335X_SK; then setenv fdtfile am335x-evmsk.dtb; fi; if test $fdtfile = undefined; then echo WARNING: Could not determine device tree to use; fi;
importbootenv=echo Importing environment from mmc ...; env import -t $loadaddr $filesize
kernel_file=zImage
loadaddr=0x80200000
loadbootenv=load mmc ${mmcdev} ${loadaddr} ${bootenv}
loadfdt=load mmc ${mmcdev}:${mmcpart} ${fdtaddr} ${fdtfile}
loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}
loadramdisk=load mmc ${mmcdev} ${rdaddr} ramdisk.gz
loadzimage=load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${kernel_file}
mmcargs=setenv bootargs console=${console} root=${mmcroot}
mmcboot=mmc dev ${mmcdev}; if mmc rescan; then echo SD/MMC found on device ${mmcdev};if run loadbootenv; then echo Loaded environment from ${bootenv};run importbootenv;fi;if test -n $uenvcmd; then echo Running uenvcmd ...;run uenvcmd;fi;if run loadimage; then run mmcloados;fi;fi;
mmcdev=0
mmcloados=run mmcargs; if test ${boot_fdt} = yes || test ${boot_fdt} = try; then if run loadfdt; then bootz ${loadaddr} - ${fdtaddr}; else if test ${boot_fdt} = try; then bootz; else echo WARN: Cannot load the DT; fi; fi; else bootz; fi;
mmcroot=/dev/mmcblk0p2 ro
mmcrootfstype=ext4 rootwait
mtdids=nand0=omap2-nand.0
mtdparts=mtdparts=omap2-nand.0:128k(SPL),128k(SPL.backup1),128k(SPL.backup2),128k(SPL.backup3),1792k(u-boot),128k(u-boot-spl-os),128k(u-boot-env),5m(kernel),-(rootfs)
nandargs=setenv bootargs console=${console} ${optargs} root=${nandroot} rootfstype=${nandrootfstype}
nandboot=echo Booting from nand ...; run nandargs; nand read ${fdtaddr} u-boot-spl-os; nand read ${loadaddr} kernel; bootz ${loadaddr} - ${fdtaddr}
nandroot=ubi0:rootfs rw ubi.mtd=7,2048
nandrootfstype=ubifs rootwait=1
netargs=setenv bootargs console=${console} ${optargs} root=/dev/nfs nfsroot=${serverip}:${rootpath},${nfsopts} rw ip=dhcp
netboot=echo Booting from network ...; setenv autoload no; dhcp; tftp ${loadaddr} ${bootfile}; tftp ${fdtaddr} ${fdtfile}; run netargs; bootz ${loadaddr} - ${fdtaddr}
nfsopts=nolock
optargs="debug init=/etc/preinit"
ramargs=setenv bootargs console=${console} ${optargs} root=${ramroot} rootfstype=${ramrootfstype}
ramboot=echo Booting from ramdisk ...; run ramargs; bootz ${loadaddr} ${rdaddr} ${fdtaddr}
ramroot=/dev/ram0 rw ramdisk_size=65536 initrd=${rdaddr},64M
ramrootfstype=ext2
rdaddr=0x81000000
rootfstype=${mmcrootfstype} ${optargs}
rootpath=/export/rootfs
soc=am33xx
spiargs=setenv bootargs console=${console} ${optargs} root=${spiroot} rootfstype=${spirootfstype}
spiboot=echo Booting from spi ...; run spiargs; sf probe ${spibusno}:0; sf read ${loadaddr} ${spisrcaddr} ${spiimgsize}; bootz ${loadaddr}
spibusno=0
spiimgsize=0x362000
spiroot=/dev/mtdblock4 rw
spirootfstype=jffs2
spisrcaddr=0xe0000
static_ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off
stderr=serial
stdin=serial
stdout=serial
uenvcmd=printenv; run loadzimage; run loadfdt; run mmcargs; bootz ${loadaddr} -
usbnet_devaddr=7c:66:9d:53:6f:07
vendor=ti
ver=U-Boot 2014.01-rc1-00172-ge7e17b0 (Dec 12 2013 - 15:20:09)
Environment size: 4451/131068 bytes
Your output clearly indicates that uBoot was unable to read the device tree binary (am335x-boneblack.dtb). Make sure you have that file in the root of your FAT partition as well. It can be found in the build output: openwrt/bin/omap/dtbs after you make OpenWRT.

raspberry u-boot load image and run image from sd card

I have compiled and installed u-boot from https://github.com/gonzoua/u-boot-pi/tree/rpi on the Raspberry PI. Works great. It boots fine and works great (see http://arrizza.org/wiki/index.php/RPI_U-boot). I can load the example apps using the s-rec version of the executable.
Now I'd like to create an image, put it on the sd card (the same sd card the u-boot image is on) and then load and execute that image. That is the same as the s-rec process: load the image via s-rec and then use "go" to execute, but instead of loading across the serial port just get the image off the sd card.
I have tried using:
load mmc 0 0x0100000 hello_world.bin
and then
go 0x0100000
it loads ok:
U-Boot> fatload mmc 0 0x01000000 hello_world.bin
reading hello_world.bin
594 bytes read in 27222 ms (0 Bytes/s)
U-Boot> go 0x01000000
## Starting application at 0x01000000 ...
but the rPI self-reboots.
I also tried fatload with the same results
I tried creating an image using ./imagetool-uncompressed.py and then using load or fatload and go but no joy
I tried load/fatload with bootm and still no go
Anything else available for me to try?
John
Update: #microMolvi pointed out I used the wrong address. I re-ran it:
U-Boot> load mmc 0 0x01001000 hello_world.bin
reading hello_world.bin
594 bytes read in 27200 ms (0 Bytes/s)
U-Boot> go 0x01001000
## Starting application at 0x01001000 ...
<snip>about 100 garbage characters<snip>
<I pressed Enter here>
## Application terminated, rc = 0x0
U-Boot>
And here's the output of printenv:
U-Boot> printenv
arch=arm
baudrate=115200
board=rpi_b
board_name=rpi_b
bootargs=dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708.boardrev=0xe bcm2708.serial=0x4e82105a smsc95xx.macaddr=B8:27:EB:82:10:5A sdhci-bcm2708.emmc_clock_freq=100000000 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000 dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
bootcmd=if mmc rescan ${mmcdev}; then if run loadbootenv; then run importbootenv; fi; if run loadbootscript; then run bootscript; fi; fi
bootenv=uEnv.txt
bootscript=echo Running bootscript from mmc${mmcdev} ...; source ${loadaddr}
cpu=arm1176
filesize=0x252
importbootenv=echo Importing environment from mmc ...; env import -t $loadaddr $filesize
loadaddr=0x00200000
loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenv}
loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr
mmcdev=0
soc=bcm2835
stderr=serial,lcd
stdin=serial
stdout=serial,lcd
usbethaddr=B8:27:EB:82:10:5A
vendor=raspberrypi
Environment size: 1092/16380 bytes
U-Boot>
Ok, it looks like you can't just load the bin files just anywhere.
Here's what I did:
1) I reloaded the s-rec version
U-Boot> loads
## Ready for S-Record download ...
## First Load Addr = 0x0C100000
## Last Load Addr = 0x0C100251
## Total Size = 0x00000252 = 594 Bytes
## Start Addr = 0x0C100000
U-Boot>
Note the "Start Addr", it's 0x0C10-00000
2) I reset the rPI and then loaded the bin at 0x0C10-0000
U-Boot> load mmc 0 0x0C100000 hello_world.bin
reading hello_world.bin
594 bytes read in 15644 ms (0 Bytes/s)
3) and run it from the same addr:
U-Boot> go 0x0C100000
## Starting application at 0x0C100000 ...
Example expects ABI version 6
Actual U-Boot ABI version 6
Hello World
argc = 1
argv[0] = "0x0C100000"
argv[1] = "<NULL>"
Hit any key to exit ...
## Application terminated, rc = 0x0
U-Boot>
I'm not sure where the default address 0x0C10-0000 comes from, so at this point I don't know how to change it during the compilation/link yet, but it is documented here:
u-boot-pi-rpi/doc/README.standalone
This says that ARM based boards like the rPI are loaded and started at 0x0C10-0000:
The default load and start addresses of the applications are as follows:
Load address Start address
x86 0x00040000 0x00040000
PowerPC 0x00040000 0x00040004
ARM 0x0c100000 0x0c100000
MIPS 0x80200000 0x80200000
Blackfin 0x00001000 0x00001000
NDS32 0x00300000 0x00300000
Nios II 0x02000000 0x02000000
In arch/arm/config.mk there is:
CONFIG_STANDALONE_LOAD_ADDR = 0xc100000
In file examples/standalone/.hello_world.cmd
cmd_examples/standalone/hello_world := arm-linux-gnueabi-ld.bfd -g -Ttext 0xc100000 -o examples/standalone/hello_world -e hello_world examples/standalone/hello_world.o examples/standalone/libstubs.o -L /usr/lib/gcc-cross/arm-linux-gnueabi/4.7 -lgcc
Here the -Ttext is 0xc100000. That means hello_world entry address is 0xc100000. So the hello.bin must be loaded to memory address 0xc100000.

Permission denied starting Eclipse on Ubuntu

I just installed Indigo (Eclipse) on my ubuntu 11.10 machine and received a permission denied error when attempting to start Eclipse from the terminal.
ls -l /usr/lib/ | grep eclipse
yields
drwxr-sr-x 9 root ben 4096 2011-10-13 12:10 eclipse_indigo
I tried to sudo chmod 755 eclipse_indigo to no avail.
Any other suggestions would be greatly appreciated.
strace /usr/lib/eclipse_indigo
yields
execve("/usr/lib/eclipse_indigo/", ["/usr/lib/eclipse_indigo/"], [/* 74 vars */]) = -1 EACCES (Permission denied)
dup(2) = 3
fcntl(3, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE)
fstat(3, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fcabfef8000
lseek(3, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
write(3, "strace: exec: Permission denied\n", 32strace: exec: Permission denied
) = 32
close(3) = 0
munmap(0x7fcabfef8000, 4096) = 0
exit_group(1) = ?
It's better if you just extract the tar.gz file from http://www.eclipse.org/downloads/?osType=linux in your home directory and use it from there...
I did the same... just wait till you need to install plugins for it. Even if you manage to start it you'll have other issues, so extract the archive and save yourself from some headaches...
Why not to install using your user instead of root?
Try sudo chown ben:ben eclipse_indigo to set yourself as the owner as well as the group-owner. I think your problem is related to that r-s in the group perms field of eclipse_indigo, unless that's a typo.
I had a similar problem on a linux machine, where eclipse was unpacked as root and started by a regular user.
Be careful, not to start eclipse as root, as it does an initialization of the so-called confguration directory inside your installation.
You may find my answer to that question useful (includes steps to fix it up):
Unable to open Eclipse (configuration area .. error)