Jump to content
cubeberg

BBB problems - possible OS recommendations?

Recommended Posts

So I've been playing with my BBB for a week now - I was able to get WIFI working, hot swaps of thumb drives, etc.  I started working on enabling SPI so that I could get some basic hardware working - a 4 digit 7 segment SPI display.  Despite the tutorials I've found - it's not exactly easy - everyone's dto files seem to contain errors, or it's a versioning issue.  After finally getting SPI set up - it disappeared after a reboot.  Also - after running an opkg upgrade - I'm starting to run into other problems - device won't boot attached to a USB hub, won't boot attached to my PC.  Last night - it wouldn't even boot with my WiFi dongle attached (all running on a 2.5A 5v supply). 

Last night I finally got fed up and flashed it with the clean 5.27 that I started with.

 

So - should I keep hacking at Angstrom to try to get it working, or look at getting another OS running?  I would like HDMI support as well as some sort of GUI other than just terminal (I know - I'm a windows guy :) ) - but something where enabling SPI isn't too difficult.  The idea of BoneScript looked nice - but I started playing with Python which seemed simple enough.

 

Would love to hear everyone's input.

Share this post


Link to post
Share on other sites

Hmm, Rick's SPI example for the WS2811 worked well for me.  The SPI configuration disappears after reboot because it's housed inside a device tree overlay that's added using the bone_capemgr -- i.e. you have to "add" the cape (echo blahblah-whatever > /sys/devices/bone_capemgr.*/slots) on bootup to make it load the .dtbo file.  There's nothing in the 'bone that tells it to auto-load or autodetect it.

Share this post


Link to post
Share on other sites

Hmm, Rick's SPI example for the WS2811 worked well for me.  The SPI configuration disappears after reboot because it's housed inside a device tree overlay that's added using the bone_capemgr -- i.e. you have to "add" the cape (echo blahblah-whatever > /sys/devices/bone_capemgr.*/slots) on bootup to make it load the .dtbo file.  There's nothing in the 'bone that tells it to auto-load or autodetect it.

Are you staying on angstrom for now then?  I know that the HDMI an Audio capes are virtual and auto-load - there must be a way to get the SPI to auto-load as well.  

BTW - thanks for the tip on the WS2811 code - found a dts file in the repository that looks like it'll work.  No errors on compile unlike the others I found.

Share this post


Link to post
Share on other sites

Are you staying on angstrom for now then?  I know that the HDMI an Audio capes are virtual and auto-load - there must be a way to get the SPI to auto-load as well.  

BTW - thanks for the tip on the WS2811 code - found a dts file in the repository that looks like it'll work.  No errors on compile unlike the others I found.

I am, yeah.  Right now I sort've think of the BBB as "uh, released but not quite there yet" due to the clusterf*** that is devicetrees and how the Bonescript stuff doesn't really work.  I sort've want to use the node.js/bonescript stuff for more serious time & effort so that the projects I do can be easily understood & hacked by others.  Relying on it as a platform in other words.  But for personal projects I might not care and just use C or bash instead :)

 

From what I gather (doing a top-level summary of what I know), the bone_capemgr's autoload feature rides on the presence of EEPROMs on one of the I2C busses.  This bus is exposed on the P9 header and the intention is that capes you add will have one of these EEPROMs onboard containing preprogrammed header info declaring what the model of cape is, which pins it uses, etc. and when bone_capemgr starts it queries the I2C bus to find these EEPROMs and enable their settings.  In the new 3.8+ stuff, this mainly comprises of reading the cape ID and searching for its .dtbo file in /lib/firmware.  So the canonical way to add autoloading of devtree overlays is to have an EEPROM on your cape reporting your cape's model ID.  I'm not sure if the HDMI and audio capes have an EEPROM onboard or if there's something else in software making it autoload though.  Would be nice if there was, since you can toss your own in there.

 

Beyond that, playing with the systemd init scripts you might be able to roll your SPI autoload feature into a system "service" that has to load on bootup.  I might look into that if there are no better ways to declare which virtual capes are "autoloaded" on bootup.

Share this post


Link to post
Share on other sites

I'm conflicted about which OS to use. New stuff is going to appear on the angstrom build first as CircuitCo is paying someone to do that. However Angstrom seems like a one man show.  That distro (dare I call it that ) uses what most in the embedded world seem to view as best practices, systemd instead of init scripts and syslogd, busybox instead of full featured standalone commands, eglibc instead of glibc, and conman instead of normal networking utils. If you are used to server or desktop linux you are going to spend a lot of time reading man pages and searching to find how angstrom does something that is normally done differently on ubuntu, debian, red hat, centos, or fedora.  I really dislike the bitbake thing.  I understand its intent and it does seem to work. However building a distro from source shouldn't run for 24 hours or take an hour to build a new kernel. (granted i have a crap desktop machine).

 

Ubuntu on the other hand is going to be a page behind and that is sort of a one man show too. However, it will feel like non embedded linux.

 

Debian, I haven't tried.

 

With any of these distros on the BBB you are going to be a pioneer. Stuff isn't going to work. Changes aren't going to be documented as quickly as they happen.  Documentation is going to be vague and assume you are a kernel developer as that has been the target audience so far.  I think it will all shake out and non CircuitCo people will fill the gap with blogs and examples.  Finding blogs and posts that have stuff that actually works, that is the real trick right now, is a chore. It will take a while before all that catches up and quality sites emerge.

 

For now I'm using angstrom as that seems to be where the fixes and new stuff appears first for the BeagleBone Black.  HDMI seems to work with a $3 hdmi->dvi-d dongle I bought and connected to a vga monitor.  I'm watching closely the state of Device Tree changes and just trying to understand how all that fits together with the linux kernel.  I'm going to let others pioneer the PRU examples and how that all fits together for realtime processing.  I think I'll just get SPI working and offload any real-time processing to a smaller mcu like an LPC1114 or STM32.

 

I'd install angstrom on the eMMC so you can always use it. Then i'd ignore that and get a stack of SD cards and load a bunch of different distros and run off the SD card exclusively. Setup NFS or use a usb hard drive so you can mount a home directory that will always be around no matter what OS you run.  Do development on your PC using eclipse and grab a cross compilers for angstrom and download the linaro cross compiler for arm linux that works with debian and ubuntu.

 

-rick

Share this post


Link to post
Share on other sites

FYI, the only vague reference I can find to how those virtual capes get loaded on bootup is the .dtb file in /boot for the boneblack ... /boot/am335x-boneblack.dtb has some references to the hdmi and emmc virtual capes inside but it's a binary file so I dunno how to regenerate it.

 

Probably best to just rely on the systemd or initscript system for starting that on bootup.  Also, remember Cloud9 IDE runs some node.js crap in its /var/lib/cloud9/autorun/ dir so if you could craft a bonescript (node.js) app that runs the echo to bone_capemgr, maybe it could be loaded there...

Share this post


Link to post
Share on other sites

FYI, the only vague reference I can find to how those virtual capes get loaded on bootup is the .dtb file in /boot for the boneblack ... /boot/am335x-boneblack.dtb has some references to the hdmi and emmc virtual capes inside but it's a binary file so I dunno how to regenerate it.

 

Probably best to just rely on the systemd or initscript system for starting that on bootup.  Also, remember Cloud9 IDE runs some node.js crap in its /var/lib/cloud9/autorun/ dir so if you could craft a bonescript (node.js) app that runs the echo to bone_capemgr, maybe it could be loaded there...

from http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/05/22/bbb--working-with-the-pru-icssprussv2

Working with the device tree means converting the existing binary .dtb file at /boot into a text source .dts file, making some changes and then converting back into the binary format, and then rebooting the BBB for the changes to take effect.

Here is the procedure to convert the binary file into a text file:

cd /boot

cp am335x-boneblack.dtb am335x-boneblack.dtb_orig

dtc -I dtb -O dts am335x-boneblack.dtb > am335x-boneblack.dts_orig

After any modifications have been made (maybe copy the file first so that you have a backup), it can be converted back into binary form using:

dtc -I dts -O dtb am335x-boneblack.dts_pru > am335x-boneblack.dtb_pru

cp am335x-boneblack.dtb_pru am335x-boneblack.dtb

These commands will be used for a couple of the steps below.

 

Share this post


Link to post
Share on other sites

Quick answer -> Do you need / want a desktop ? -> Ubuntu. Do you need a server like system, or one prefer to use CLI ? -> Debian.

 

Support as in drivers( device tree overlays), and what not will come in time. Plus people like Robert C Nelson will be around to help iron out some of the complication. So far I've yet to see one thing that works on Angstrom that doesnt work on Debian, and by extension, I am assuming Ubuntu too. The major differences, is pre-compiled modules for the kernel. In the case of Debian, I've had to compile in *some* support I wanted. But the source is all there, you just need to go into menuconfig, and make sure that option is selected. Then of course, recompile the kernel. @cubeburg I would recommend that if you're not familiar with compiling the Linux kernel that you take some time and learn how it is all done. You'll be glad you did !

 

For what it is worth guys, device tree overlays are software platform independent, What I mean by this is that for the beaglebone black one compiled device tree overlay will work on Angstrom, Debian, Ubuntu, etc.

 

The main issue is making sure the device tree compiler ( DTC ) is patched properly. Something about supporting the -@ attribute I think ? Either way, Robert C Nelson now has instructions for how to setup DTC now.

 

Also for what it is worth. Currently I am working on my blog, and familiarizing myself with WordPress, so I can roll out some blogs. Among these will be how to get a NFS /root/ so you can tinker to your hearts content, and not worry about burning out your SD card(s). Later, I will get NFS boot working too ( PXE / BOOTP boot ). So then you could compile the kernel countless time, and again not worry about burning out the MMC devices used with, and in the BBB.

 

Anyhow I have a lot of information to assimilate, Once done though, I will be doign a series of blogs that will guide anyone through setting up a good working environment. E.G. How to setup a Virtual machine ( or use another system ) to provide all support activities. Including, but not limited to cross compiling, network file systems ( NFS / iSCSI ) Compiler / IDE setup for Windows etc. Again, it is a lot of information to assimilate so It may take me a while to figure out the best way to go about writting about it.

Share this post


Link to post
Share on other sites

Hmm, Rick's SPI example for the WS2811 worked well for me.  The SPI configuration disappears after reboot because it's housed inside a device tree overlay that's added using the bone_capemgr -- i.e. you have to "add" the cape (echo blahblah-whatever > /sys/devices/bone_capemgr.*/slots) on bootup to make it load the .dtbo file.  There's nothing in the 'bone that tells it to auto-load or autodetect it.

I believe that is a uboot option. I have been privy to one of the kernel devs uEnv.txt file ( after talkign about NFS booting ), and notice he has a line in his config that loads a dtbo file directly. Also, if you take a Look at Robert C Nelsons instructions for building / install Debian / Ubuntu, you wil notice he loads the whole /dtbs/ directory from /boot/ path.

Share this post


Link to post
Share on other sites

By chance I noticed a new build for Debian on Robert C Nelson's site (thanks for these Robert!).  It's currently ticking away and I'm guessing it'll be done uploading soon.

 

Robert if you're out there, care to comment on what's in the new build?

**********************************************************************************************************************************************



> Robert if you're out there, care to comment on what's in the new build?


 

Just a couple urgent fixes, I dropped shellinabox, so normal ssh works again..

 

Original Panda: 2 Wifi fixes so the LSR module works again out of the

box, spidev pinmux fix..

BeagleBone: just a kernel bump, and was built with the proper patched

'dtc' so the @ stuff works..

Share this post


Link to post
Share on other sites

Thanks for all the info guys!  I flashed a clean BBB Angstron 06.06.2013 build onto my board and got SPI running - at least I think so.  A 595 lit up at least one LED - still have to make sure it's actually working right.  Couldn't get a 7 segment SPI display working right, but I haven't even tested it on my 430 - probably need to do that, and make sure the 595 is 100% working on the BBB before going further.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...