Nube - getting the most basic image running smoothly

[Omri Rotem]

Hi, First thing: hats off. great stitching of toolchain for short cycle embedded erlang dev. Thanks a lot.

Using FTDI cable, having burnt the buildroot image alone from the nerves SDK, I get this:

```

U-Boot SPL 2014.01 (May 02 2014 - 10:07:07)

reading args

spl: error reading image args, err - -1

reading u-boot.img

reading u-boot.img

U-Boot 2014.01 (May 02 2014 - 10:07:07)

I2C:   ready

DRAM:  512 MiB

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

104 bytes read in 4 ms (25.4 KiB/s)

Loaded environment from uEnv.txt

Importing environment from mmc ...

1964040 bytes read in 155 ms (12.1 MiB/s)

24884 bytes read in 27 ms (899.4 KiB/s)

Kernel image @ 0x80200000 [ 0x000000 - 0x1df808 ]

## Flattened Device Tree blob at 80f80000

   Booting using the fdt blob at 0x80f80000

   Using Device Tree in place at 80f80000, end 80f89133

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

omap2_mbox_probe: platform not supported

bone-capemgr bone_capemgr.9: slot #0: No cape found

bone-capemgr bone_capemgr.9: slot #1: No cape found

bone-capemgr bone_capemgr.9: slot #2: No cape found

bone-capemgr bone_capemgr.9: slot #3: No cape found

omap_hsmmc mmc.5: of_parse_phandle_with_args of 'reset' failed

pinctrl-single 44e10800.pinmux: pin 44e10854 already requested by 44e10800.pinmux; cannot claim for gpio-leds.8

pinctrl-single 44e10800.pinmux: pin-21 (gpio-leds.8) status -22

pinctrl-single 44e10800.pinmux: could not request pin 21 on device pinctrl-single

/sbin/init: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory

Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00

```

This is after closely following your youtube video, on a clean nerves-sdk clone. what I did was just this: 

`sudo dd bs=1M if=buildroot/output/images/nerves-bbb-base.img of=/dev/sdb`

where sdb is my sdcard, and after pushing it back in the computer I get two drives on it, the boot one and the linux one. so it all seems fine, but it appears my linux compilation is not as should to run on the beagle...

Any advice?

[Frank Hunleth]

Hi Omri,

You did everything right. I looked into it, and it appears that I've
introduced a regression on the Beaglebone. (This is what I get for
testing on the Raspberry Pi the past few weeks).

I verified that commit 70b980415f79f6b3739ffc663a9f9f7b4c850662 still
works. I can't investigate further right now, but I'll see what's up
this evening.

Thanks for reporting this!

Frank

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



--
Frank Hunleth
Troodon Software LLC
Embedded Software Development
http://troodon-software.com/

[Frank Hunleth]

Omri,

Thanks again for the report. I pushed up two fixes to nerves-sdk (see
the v0.2.2 tag in git or just try master) that should make the BBB
images work again (at least, they work for me).

One of the issues was mine since I had made a mistake with a change to
erlinit. The other issue was caused by pulling an update from the
Buildroot project that switched the default external compiler to
Linaro 2014.02. This changed something with shared libraries that
broke a lot of things, but only at runtime and only on the Nerves BBB
platform. I've forced the compiler used for the BBB to Linaro 2014.01,
and this works around the issue. I'm certain that I'll be revisiting
this, but hopefully someone else in the Buildroot community or Linaro
will fix it.

Also, for everyone on the list, I'm been distracted with several 3rd
party package update to Buildroot for a nerves project that I'm
working on. I'll be updating the Buildroot version used in Nerves
again hopefully in the next week. The intended changes involve
syslinux (for x86 builds) and hardware 3d acceleration. I'll certainly
be picking up many other Buildroot changes that I don't expect to
break Nerves, but I'll be more vigilant based on this issue.

Frank

Frank

[Omri Rotem]

Hi Frank,

Thanks a lot for being so responsive!

So let me see, if some changes were made in buildroot, it is not enough to `git pull`, one must run the whole pulling of buildroot again.

I say it because I get now 

```

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

omap2_mbox_probe: platform not supported

bone-capemgr bone_capemgr.9: slot #0: No cape found

bone-capemgr bone_capemgr.9: slot #1: No cape found

bone-capemgr bone_capemgr.9: slot #2: No cape found

bone-capemgr bone_capemgr.9: slot #3: No cape found

omap_hsmmc mmc.5: of_parse_phandle_with_args of 'reset' failed

pinctrl-single 44e10800.pinmux: pin 44e10854 already requested by 44e10800.pinmux; cannot claim for gpio-leds.8

pinctrl-single 44e10800.pinmux: pin-21 (gpio-leds.8) status -22

pinctrl-single 44e10800.pinmux: could not request pin 21 on device pinctrl-single

/sbin/init: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory

Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00

```

What is the recommended way to do so?

Thanks again for the help,

Omri.

[Frank Hunleth]

Sorry, you need to rebuild everything from scratch. Run:

make clean

make nerves_bbb_defconfig

make

The general rule with Buildroot is rebuild everything if anything changes. If you need to change the Buildroot configuration much, there are ways to avoid rebuilding everything and enabling the compiler cache (run make menuconfig and go to build options) helps.

Frank

[Omri Rotem]

And it works! Thanks again.