"latest" 2015-11-12 seems fine with BBG but has problems with BBB A5A

I’ve downloaded bone-debian-7.9-lxde-4gb-armhf-2015-11-12-4gb.img.xz from beagleboard.org/latest and made an SD card. I then installed the stuff I thought my newbie friend should start with – node-red, mosquitto, etc. Its current with apt-get update apt-get upgrade through today. There are a few “bogus” capemgr and bonescript error messages when starting node-red with node-red-pi or running the bonescript example blinkled.js but things seem to otherwise work as expected.

If anyone knows how to feedback corrections to the beaglebone node-red installation instructions ( http://nodered.org/docs/hardware/beagleboneblack.html ) I’d like to point out that they are clear except for one key step:

cd ~/.node-red
npm install node-red-node-beaglebone

The .node-red directory doesn’t exist until the node-red-pi script is run. So you have to start none-red and then stop it with Ctrl-C before you can npm install the beaglebone specific bits. This threw me, I suspect it would be a showstopper for someone who buys a board and stumbles around the “top level” beaglboard.org links to get started.

Booting this SD card on the BBG, the USB gadget and webserver seems to work fine when its plugged into Windows 7 or Ubuntu 15.10. However moving this SD card to my A5A BBB, it doesn’t work on Windows7 because of a device driver error, even though the Windows drivers were installed when the BBG was plugged it. The A5A BBB does seem to work correctly when plugged into my Ubuntu 15.10 system. Is this a problem specific to the A5A revision? Is my BBB hardware “flaky”? or something else? Since the BBB fat partition doesn’t mount, things are DOA on WIndows 7. OTOH, the old Angstrom that came in the 2GB eMMC of my A5A BBB seems to still work as well as ever on Windows 7 if I remove the SD card and boot it over the USB connection.

In the interest of improving Beaglebone newbie out of the box experience, I’d like to suggest making node-red, the beaglebone extensions, and mosquitto part of the “latest” images. My only complaint about node-red in terms of getting a non-programmer started with their IOT ideas is there seems to be no way to stop a buggy runaway “deploy” short of Ctrl-C in the root terminal that launched node-red (via node-red-pi). This does play OK with using the Cloud9 root terminal to start node-red and then doing node-red in another browser window or tab. But some “top level” documentation and examples linked from beaglebone.org would sure help a lot.

While having the OS in the eMMC is convenient, the version that came pre-installed on my BBG would be IMHO a disservice to a rank beginner.

I’ve downloaded bone-debian-7.9-lxde-4gb-armhf-2015-11-12-4gb.img.xz from beagleboard.org/latest and made an SD card. I then installed the stuff I thought my newbie friend should start with – node-red, mosquitto, etc. Its current with apt-get update apt-get upgrade through today. There are a few “bogus” capemgr and bonescript error messages when starting node-red with node-red-pi or running the bonescript example blinkled.js but things seem to otherwise work as expected.

If anyone knows how to feedback corrections to the beaglebone node-red installation instructions ( http://nodered.org/docs/hardware/beagleboneblack.html ) I’d like to point out that they are clear except for one key step:

cd ~/.node-red
npm install node-red-node-beaglebone

The .node-red directory doesn’t exist until the node-red-pi script is run. So you have to start none-red and then stop it with Ctrl-C before you can npm install the beaglebone specific bits. This threw me, I suspect it would be a showstopper for someone who buys a board and stumbles around the “top level” beaglboard.org links to get started.

Booting this SD card on the BBG, the USB gadget and webserver seems to work fine when its plugged into Windows 7 or Ubuntu 15.10. However moving this SD card to my A5A BBB, it doesn’t work on Windows7 because of a device driver error, even though the Windows drivers were installed when the BBG was plugged it. The A5A BBB does seem to work correctly when plugged into my Ubuntu 15.10 system. Is this a problem specific to the A5A revision? Is my BBB hardware “flaky”? or something else? Since the BBB fat partition doesn’t mount, things are DOA on WIndows 7. OTOH, the old Angstrom that came in the 2GB eMMC of my A5A BBB seems to still work as well as ever on Windows 7 if I remove the SD card and boot it over the USB connection.

Did you reflash this a5a? As even with the new image, it’s still booting with the old u-boot…

If course I also have a few a5a’s where the USB slave port no longer works…

In the interest of improving Beaglebone newbie out of the box experience, I’d like to suggest making node-red, the beaglebone extensions, and mosquitto part of the “latest” images. My only complaint about node-red in terms of getting a non-programmer started with their IOT ideas is there seems to be no way to stop a buggy runaway “deploy” short of Ctrl-C in the root terminal that launched node-red (via node-red-pi). This does play OK with using the Cloud9 root terminal to start node-red and then doing node-red in another browser window or tab. But some “top level” documentation and examples linked from beaglebone.org would sure help a lot.

While having the OS in the eMMC is convenient, the version that came pre-installed on my BBG would be IMHO a disservice to a rank beginner.

Once an OEM ships an image, is nearly impossible to get them to update it… At least every image has a link where they can get the latest…

Most things can be updated via apt now too…

Regards,

First, you’ve already ruled out a hardware problem.

A) BBG boots fine with Image.

B) Angstrom on the A5A boots, and works fine too.

So what’s left, is this is somehow a software issue in conjunction with the A5A. What I can say is that we have 2 A5A’s here, and have never had a problem with either. But with these I use a custom image with custom g_ether setup if at all.

Second, as Robert mentions above, your A5A has Angstrom on it, and by implication it also probably has the original 1st, and second stage boot loaders on it - MLO, and uboot.img. How the boot process works, is that unless you force loading the bootloader from the sdcard by using the boot button on the board, the OLD bootloaders will load from the eMMC, and then continue to load Linux from the sdcard. In some cases, the BBB will refuse to boot, but in your case it seems as though you’ve run into some other failure.

Thirdly, you should never create an image for one type of Beagle, and expect it to work 100% on another. Especially considering there have been minor hardware changes between A5A to RevC, not to mention the BBG is a one step further out, off the RevC “branch”. With even more changes in it’s own right.

Lastly, no one here has any control which Linux image, kernel, or even OS is installed on the BBG. I think at most Robert perhaps works with seeed to ensure various kernels and images work on the BBG. With that said however, I’ve noticed that all the stock images produced by Robert lately for Beagle hardware also has “support” for the BBG as well. But in the end, I do not yet own a BBG, so . . . not personal hands on.

Thanks for the reply, you are always concise and helpful.

No I’ve never flashed the A5A 2GB eMMC, keeping the original Angstrom as a “fallback”, but I did do a lot of opkg stuff in an attempt to actually use it, but kept getting tripped up by differences between Angstrom and Ubuntu/Debian and the dearth up to date Angstrom docs and information – if an Adafruit tutorial didn’t address it, I was pretty much stuck. I was quick to try the BBB Debian images.

So are you suggesting I download the latest 2GB Debian “flasher” image, flash it, and then boot my SD card?

Easy enough to do but, how does this explain the working on Ubuntu 15.10 but not Windows 7 aspect of it?

If I burn the image to an SD card, how can it tell if I boot it in a BBG or BBB Rev C or A5A initially? Does the very first boot modify the init scripts? I though all the differences were supposed to be handled in the device tree overlays.

I’ve been “cloning” Ubuntu systems for a long time (since 2006) and other than grub UUID issues and some binary video drivers not matching the video card variant, its just not been a problem.

If the “clone” didn’t work on either Ubuntu or Windows I would have assumed the initial boot was “self-modifying”, and tried to figure out the dpkg dselect stuff to create a “master list” to apt-get install all my bits and pieces instead of setting up a master system and cloning it. But I actually thought I was clever and done until I tried the BBB on Windows 7.

In any event, the BBG makes more sense to for me for the future, as I find the BBB HDMI to be pretty lame, claims a lot of GPIO pins, and ssh -X on the Green seems to run GUI apps better that the BBB HDMI keyboard/mouse does natively – expected since my desktop is doing all the graphics heavy lifting.

So are you suggesting I download the latest 2GB Debian “flasher” image, flash it, and then boot my SD card?

I suggest you do what you feel most comfortable with. Both our A5A’s here still have the original Angstrom on them, and I just suck it up and hold down the boot button at power up. Well actually lately I’ve been using our Element14 RevC’s exclusively.

Easy enough to do but, how does this explain the working on Ubuntu 15.10 but not Windows 7 aspect of it?

So this is the reason ( most likely ) for this observation. Windows, even Win7 really, really sucks at device driver management. That is to say, you installed an older driver that works for the Angstrom image, which is different from the newer image in Windows eyes. In fact, I do believe they both use different drivers in Windows. The original being an “Elmo GAS LTD” gadget driver or some such.

Linux on the other hand, just recognizes the “different” newer driver as “just the same thing as before”, and is able to deal with it better.

So, dealing with this issue in Windows is a huge pain in the rear. I’m personally very experience with Windows in general, and had a hard time dealing with it. That is to say, at one point I was a paid systems consultant . . . where I dealt largely with Windows. My recommendation would be to use only Linux systems when dealing with the Beaglebones. Sure, you can use Windows, but honestly it is more of a hassle than it is worth . . .

I’m thinking the old u-boot leaves the USB bus in a bad state, and we don’t properly re-init it from that state.

Side note, I haven’t tested the old angstrom u-boot with our now default Debian image in probably 2 years…

Regards,

You always boot the bootloader off the eMMC unless:

A) bootloaders do not exist on the eMMC

or

B) You press and hold the boot button at power up

f the “clone” didn’t work on either Ubuntu or Windows I would have assumed the initial boot was “self-modifying”, and tried to figure out the dpkg dselect stuff to create a “master list” to apt-get install all my bits and pieces instead of setting up a master system and cloning it. But I actually thought I was clever and done until I tried the BBB on Windows 7.

What you did probably was clever. As mentioned above, the problem is Windows ability to deal with similar, but different drivers. We both know the hardware is the same, but Windows does not because they hardware is presented differently though software.

To be clearer on how you have to deal with this situation. First, you may, or may not have to boot into safe mode in order to remove the existing driver. Passed that, if the Beaglebone is not plugged in, you will have to force hardware manager to show hidden( inactive ) devices, and then remove it.

Once fully removed, you may even be required to install the drivers from beagleboard.org, and THEN also visit MS updates, and install their “special sauce” before the driver will work. Whatever happens, the whole process is very inconsistent, and largely Microsoft’s fault, that could possibly be mitigated by keeping the drivers as consistent as well.

So, this is why I say it is just easier to deal with this hardware from Linux. Because . . it really is. And yes, I do realize that some people can be really stubborn and refuse to use anything other than x.y.z. Be it OSX, Windows, or some flavor of Unix.