PocketBeagle boot attempts

glennsky

Just experimenting a bit with the PocketBeagle and tried to boot from the new v0.3.1 Bela - but nothing at all is output on the serial console, only the power LED is lit steady and no sign of life at all.

With the older image of Bela v0.2.x, I get the following message at least:

  U-Boot SPL 2013.10-00016-g6adb529 (Feb 06 2014 - 14:54:24)
  Unknown board, cannot configure pinmux.### ERROR ### Please RESET the board ###

The latest Debian releases on http://beagleboard.org/latest-images work fine obviously, and I get the following:

   U-Boot SPL 2017.09-00002-g0f3f1c7907 (Oct 09 2017 - 15:30:22)
   Trying to boot from MMC1
   U-Boot 2017.09-00002-g0f3f1c7907 (Oct 09 2017 - 15:30:22 -0500), Build: jenkins-github_Bootloader-Builder-607
   CPU  : AM335X-GP rev 2.1
   I2C:   ready
   DRAM:  512 MiB
   No match for driver 'omap_hsmmc'
   No match for driver 'omap_hsmmc'
   Some drivers were not found
   Reset Source: Power-on reset has occurred.
   MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
   Using default environment
   Model: BeagleBoard.org PocketBeagle

So just wondering what's preventing the newer v0.3.1 images from even trying to start U-boot? The PocketBeagle doesn't have eMMC - so if something is trying to access that at the very start it would probably hang.

Was thinking of wiring up a Bela cape to the PocketBeagle, but if it doesn't even want to boot from the Bela image, then it's a bit of a non-starter.

Thanks!

giuliomoro

This is most likely an issue with the bootloader. The one we use I believe dates back to March 2017, that is before the PocketBeagle was announced, so it is not supported. Our next release will come with an updated bootloader that should work. However, if you are experienced, you could try to give a stab at compiling a more recent uboot and the MLO for yourself, using as a starting point the build_bootloader.sh script in github.com/BelaPlatform/bela-image-builder .

You will need a Linux machine or virtual machine, possibly running kernel 4.4 (e.g.: Debian Stretch).
Then edit the remote and branch for uboot in scripts/downloads.sh and run sudo ./build_bela.sh. It will last a few hours the first time you run it (use --help to see options to make it faster next time).
In practice, this procedure is overkill for your case, so if you can get yourself a cross-gcc, put it in the CC environmental variable and manually clone a recent uboot repo, then running build_bootloader.sh will be very quick. Note that copying the newly compiled u-boot and MLO files on the board is not necessarily straightforward, as they need to be the first two files written on the boot partition. See, for reference on how to enforce such order, the script in misc/rootfs/opt/Bela/copy_bootloader.sh

glennsky

I decided to setup a virtual machine with the latest Debian image (debian-9.3.0-amd64-netinst.iso):

Linux stretch 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3+deb9u1 (2017-12-23) x86_64 GNU/Linux

However, build_bela.sh is complaining about some missing dependencies -- which Debian apt-get is unable to find:

sudo apt-get install debootstrap qemu-arm-static autoreconf libtool arm-linux-gnueabihf-ranlib kpartx setuidgid wget
Reading package lists... Done
Building dependency tree       
Reading state information... Done
E: Unable to locate package qemu-arm-static
E: Unable to locate package autoreconf
E: Unable to locate package arm-linux-gnueabihf-ranlib
E: Unable to locate package setuidgid

Is there somewhere to get these packages, or do I need an earlier Debian version that is running 4.4 kernel or some other flavour of Linux? Don't suppose you have a virtualbox image available that's setup for compiling Bela? Would be convenient!

Thanks.

giuliomoro

Hmm those package names are from ubuntu 16.04 I believe. You can find from the source of the script what files I am checking for and then use apt-file to find out which packages on your system provide them.

jarm

In case anyone is wondering about running build_bela.sh, here are some notes on how to do using an Ubuntu VM: