BeagleBone Black

Far more powerful than the “..Bone” name suggests…

BeagleBone Black

Farnell/Element14 have it at £27.87 so it would be a faster alternative to the RPi if it is fully compatible with the Beagleboard-xm.

if it is fully compatible with the Beagleboard-xm.

It is similar but not compatible.

The Beaglebone Black’s SoC says:

Cortex-A8 up to 1GHz
32K/32K L1 cache, 256K L2 cache
Datasheet says 16bit data bus? 16 ?
Also, can address up to 1GB; in 1×16 or 2×8 configuration.
NEON
SGX53 graphics; claims 20M poly/sec
LCD controller up to 2048×2048
RTC
12 bit ADC (200K samples/sec)
10/100/1000 ethernet (!)
Crypto hardware (AES/SHA/PKA/RNG)

http://www.ti.com/lit/ds/symlink/am3359.pdf

Beagle xM’s SoC data says:

Cortex-A8 up to 1GHz
CPU cache: 32K/32K L1 cache, 256K L2 cache
16/32 bit memory controller, can address up to 1GB
16 bit general memory controller (this is for Flash, etc)
NEON, VFP?
VLIW 320C64x DSP core
DSP cache: 32K/80K L1 cache, 64K L2 cache
PowerVR graphics (claims 20M poly/sec)
IVA2.2 video/audio accelerator
LCD controller (parallel) with analogue video output
Wikipedia claims maximum display size is 1400×1050? Doesn’t sound right.

No RTC (is via helper chip), no ethernet (is via USB bridge).

http://www.ti.com/lit/ds/symlink/dm3730.pdf

This is no Beagle xM. I’m worried that if it is correct in supporting only a 16 bit memory world, how much of an impact that will make on fetching 32 bit instructions.

However, at this price point, it’ll certainly give the Pi a run for its money for those who want to use it for development. For media playback purposes, it will barely be a blip – the Pi marries an underpowered processor to a rather powerful GPU (the VideoCore 4 claims FullHD 1080p); while the OMAP3 range puts a reasonably competent CPU and a bunch of hardware assist alongside a reasonably competent but not overly exciting GPU (while the OMAP3 can display a Full HD screen, it would seem to struggle to decode anything over 720p in realtime).

So – which you pick depends upon what you want to use it for. However since RISC OS just plain doesn’t have fancy GPU stuff, this isn’t a question for us. ;-) I can forsee a desire to port RISC OS as it is quite a nicely specified microcontroller for when people want a big more oomph than would be offered by an Arduino but don’t necessarily want a complete computer system running a complete oversized OS. In this respect, we could probably do with a decent VNC/RDP server!

I’m sitting outside in the sun (just don’t read the weather forecast) so E&OE. ;-)

It seems that it’s not a good candidate for a port of RISC OS.
Though we will stock accessories for the BeagleBone Black as some bits like microHDMI cables will not be available on every high street!

It seems that it’snot a good candidate for a port of RISC OS.

Oh, I don’t know. With the I/O and the price, it could be interesting for embedded devices.
I think the deciding factor would be how difficult it would be to port to it. If it is close enough to OMAP that a lot of the code can be recycled, that’s one thing. If it is very different, that’s something else.
I take comfort from the fact that the processor and GPU are the same, so porting might not be that difficult… But then, I don’t really know! :-)

I think the lower end is already covered with Raspberry Pi and BeagleBoard – the only “high end feature”, Gigabit Ethernet, seems to be not supported by the board (although it seems to be supported by the SoC). Similar boards to the BeagleBone Black would be the CubieBoard and the

Since we have good ports for the low end (RPi) and the mid end (Beagle XM, PandaBoard), I think we (i.e. not me, but some motivated individual(s), and I would be delighted to sponsor hardware/software for) should concentrate on the high end:

• something with Cortex-A15 (e.g. Samsung Exynos 5 – the Arndale board, the Chromebook)
• something with at least Cortex-A9 and not-via-USB Gigabit ethernet and not-via-USB S-ATA (CuBox, SABRE)

There are all kind of cool ARM based boards around, like the CubieBoard or the OLinuXino, or the Tegra-based offerings, which all have significant challenges for a port (like getting enough information about the SoC). But do we have the manpower to cater for all of them?

Since we have good ports for the low end (RPi) and the mid end (Beagle XM, PandaBoard), I think we (i.e. not me, but some motivated individual(s), and I would be delighted to sponsor hardware/software for) should concentrate on the high end:

There’s a definite gap for a high end RISC OS machine. A possible candidate is available here. It seems very similar to the Pandaboard but using an OMAP5432.
There’s a hint here that the OMAP5 TRM will be available soon. The system reference manual is already available here

It seems the best candidate from a available documentation point of view. Crucially it has a dedicated SATA port which can be used as the boot drive.

Nice one, Chris. Could it be worth proposing a bounty to purchase the hardware, assuming a port is feasible and that there’s developer time/interest in looking at this in more detail?

Well that’s an interesting board.

Here are the issues:

The OMAP5 uses a pair of A15 cores for processing and a pair of M4 cores for graphics <— neither of which RISC OS has been ported to.

There is no straight DVI output so we would be reliant on the HDMI output which is straight off the OMAP5 chip and therefore will be subject to the OMAP5 NDA.

The other helper chips (the TWL6040 (audio) and the TWL6038 (power) are also under NDA. The PandaBoard ES uses the TWL6040 so we’ll be in the same nightmare with regards to audio…

The 10/100 Ethernet connection is…
…USB again!

Here are the good bits:

The 10/100 Ethernet connection is on a separate USB controller so it will be a bit faster.

There is SATA.

There is onboard 4GB NVRAM.

There are 3 USB2.0 ports.

There is 1 USB3.0 OTG port.

So to conclude it will be an improvement over the PandaBoard ES if certain parts of it (I am thinking the video output mostly) are not strictly covered by the usual Ti NDAs. Yet again it is almost, but not quite, there…

:-(

I suppose that the only hope is for some sort of community thing like the BeagleBoard for OMAP3 and PandaBoard for OMAP4 happens.

P.S. forget the BeagleBone Black – it is time we left the OMAP3 behind.

I’d like one of these – an Odroid-X2. It has a 1.7GHz quad core Cortex-A9 with 2GB RAM, WiFi, eMMC support, 100Mb ethernet onboard plus six USB2 sockets and a micro-USB to-host too. Ubuntu and Android already running. HDMI does 1920×1080 but has been demonstrated running dual-headed by some magic.

There’s a cheaper ODROID-U2 too, which doesn’t seem to lack much (missing four USB sockets and the audio input… is that all?)

Very nice but there’d be the current issue with the ethernet as it is using the same SMSC chips that the Beagleboard / PandaBoard / Pi use.

Steffen said:

I think the lower end is already covered with Raspberry Pi and BeagleBoard

Which is one of the reasons I asked about the technical feasibility of porting to the Black. It might not seem all shiny-whizzy to you, but the opportunity of near-Beagle number crunching at near-Pi prices might appeal to some, for use in embedded systems. Why? It offers more GPIO than the Pi, there’s an RTC built in (no need for add-ons), ADC onboard, 2Gb Flash storage onboard, UART access (3.3V), interfacing at the narrow ends or up (not all over the place as on the Pi), SIXTY FIVE GPIO PINS, faster processor. ¹

Some people might want to use RISC OS for developing “gadgets” because RISC OS is good at not getting in the way. Indeed, the ability to legitimately hijack the system (EnterOS, IntOff, etc) means that I/O-driven things can have good response times.

Not everybody wants a really fast computer for playing ancient games.

¹ In fairness, the cons: lower HDMI, less capable realtime video decode, only the one USB port, no composite video, audio only over HDMI.

Since we have good ports for the low end (RPi) and the mid end (Beagle XM, PandaBoard),

It is certainly of interest to have mid-end power at low-end prices. I think it is worth considering supporting this board IF (and only if) it is similar enough to the Beagle to consider that most of the work has already been done, it is more a matter of supporting specific differences than writing a port to an entirely different SoC/GPU.

I think we […snip…] should concentrate on the high end:

I would like to agree, but I would ask, quite seriously:
What is the point of a dual-core processor with lesser capable Thumb-style co-processors along for the ride…. when RISC OS is able to use exactly none of these extras and there is no clear roadmap for future support of such features?
In essense, multiple cores are useless to us. We’d get more joy from a faster clocked main processor.

Or, perhaps to put it another way: I am concerned that the higher and higher end hardware that may be supported, the more our limitations will be stark.

Keith added:

P.S. forget the BeagleBone Black – it is time we left the OMAP3 behind.

That’s a bit rich considering that not only is it a contemporary part (it might not be new but it is still selling (and, I might add, supported by Ubuntu unlike the Pi’s older ARM11)), but RISC OS itself has legacy gunk that’s like a quarter century old that is still a consideration both in coding and in the API itself.

Case in point? Look at the graphics system.

Case in point? Why does BASIC call OS_Word to make a SOUND? First look at BASIC (look for “SOUNDFOUR”); then look at the OS_Word handler (look for “OsWord07 ROUT”) and note that BASIC calls OS_Word which enters the OS which then calls XSound_ControlPacked which is, arguably, what BASIC should have done in the first place.

Case in point? Look deeper at the graphics system; especially all that farting around with VDU queues and streams and stuff that makes no sense these days. It might have been logical back in the days of the BBC MOS, but this can’t be said to apply so much now. Press F12, enter *Spool TempFile, press Return twice (goes back to the Desktop, notice it is a lot slower), press F12, then type *Spool to close the spool file. Then look at the contents of the spool file and ask yourself what on earth is going on “under the hood”.

I apologise if I sound grumpy. I just think it is churlish to suggest to stop supporting the OMAP3 when, as a (small-time) developer, I still factor RISC OS 3.7 (and if possible, 3.1) into my code.

Frankly, there’s a lot of stuff I’d drop in RISC OS that I see as being a noose around its neck. I don’t need to describe, I’m sure most people here have the same sort of ideas, though I’m quite aware that everything lost would risk losing users. It might be possible to make a really jaw-droppingly awesome multi-core version of RISC OS with so many bells and whistles that even Gerph would be impressed…but at what cost? I shall remind you that a system with no users is no system at all.

Now, don’t think I’m pushing for a Beaglebone Black ‘cos I want to run RISC OS on it. That gizmo is currently of no use to me (I have nothing that works with HD signals). What it is, is, more simply, thinking to be where the users are. Yes, the BBB is some sort of OMAP3 clone (I think it is called “Sitara” or something?) but it risks stealing some of the thunder from the Pi for people who want more serious/grownup applications from a dirt-cheap board. This is like the big ARM version of the Arduino. It isn’t really intended to be a desktop computer, my God there’s only one USB port. This will have applications in robots, gizmos that go into space on weather balloons, model railways, self-piloting quadricopters, etc etc. With that sort of GPIO it would lend itself to all sorts of cool interfacing projects. I expect a fair number to turn up on HackADay. Want to DIY your own pen plotter to which you can download drawings and let it get on with it independently of the host? It ought to be doable with that sort of specification!

Does RISC OS want a piece of this action?
Is a port to this board going to be complicated? Will the ends justify the means?
Those are the only questions that need to be asked. It is laudable indeed to want to see RISC OS on high-end hardware; though I would rather believe that it is logical indeed to see RISC OS on hardware that people are going to buy a lot of.

Rick, I think that the Pi is a platform that is good enough for the typical hardware hacker that might be otherwise interested in the BBB. There are already incredible numbers of projects around the Pi, there are any numbers of add-on boards and stuff – I am not sure if the BBB has a chance in this segment. And when running RISC OS, the Pi has the additional advantage of being compatible with ARMv5. And if the BBB is as poor at supplying video than Beagle and Beagle XM, it is one more disadvantage compared to the Pi, which can be connected to any old monitor with digital input.

What is more, there are many competitors for the BBB. Things like the CubieBoard. It is unclear if the BBB will reach a relevant number of users at all. The nice thing about the Pi was and is that many people have one, so providing RISC OS for these people is attractive to find a few new users. Even more so as the Linux experience is not very good, while RISC OS performs extremely well on the Pi.

Talking about “we can’t use all the cores” – one of the reasons to go for a Cortex-A15 is that single core performance is so much better. Both the Exynos 5 and the upcoming OMAP5 SoCs will run at 1.4 to 1.9 GHz, and they do a lot more per cycle than Cortex-A9. If RISC OS is ported to a board with A15 and proper Ethernet and S-ATA, the speedup compared to even a Pandaboard ES will be massive. Even if three cores are idling away.

There are already incredible numbers of projects around the Pi, there are any numbers of add-on boards and stuff

I would imagine that there will be a fair few for the BBB too. Again, it depends upon your level of hackery as to how much GPIO you want.

Think of the BBC micro. User port, 1MHz bus, Tube, Analogue… Compared to that, the Pi has the I/O of a Spectrum. ;-)

RISC OS, the Pi has the additional advantage of being compatible with ARMv5.

Fair enough, but again this is just a holdover from the past.

[And for the life of me I don’t understand why unaligned loads were ever used given it takes two instructions (a load and a rotate) which is exactly how many it would take to perform an aligned load (a load and a rotate or a mask). It seems like trying to be clever for the sake of being clever has come back to bite.]

And if the BBB is as poor at supplying video than Beagle and Beagle XM, it is one more disadvantage compared to the Pi, which can be connected to any old monitor with digital input.

No – the GPU has a lower level of capability to the Pi and the same as the Beagle (it’s the same PowerVR core). What it is missing, compared to the others, is analogue output. This means it must be connected to a digital input monitor (not a TV or such). I expect it to perform akin to a regular Beagle.

What is more, there are many competitors for the BBB. Things like the CubieBoard.

<looks>

WHOA! 1GB? SATA? More I/O than you can keep track of? VGA?!? And it’s about 65 euros? [http://embeddedcomputer.nl/cubieboard/cubieboard.html]

Actually, that sounds very interesting. There’s a datasheet (it claims to be capable of HD 2160p (WTF?!)). It is, however, a Cortex-A8.

Question is – can the BBB be easily supported with existing code? The A10 would be a whole new port…

and proper Ethernet and S-ATA,

How high level is the USB ethernet chip? I first thought that having ethernet via USB was a pretty poor idea – what with the amount of data passing and the need to be in continuous dialogue with the host to get this to work. But then it struck me – maybe these ethernet gateways have a little processor inside so they are capable of running semi-autonomously and actually taking a load from the host?

SATA, on the other hand, would be nice, to allow fast interfacing to traditional harddiscs (since we don’t have USB3 around these things yet).

The A10 would be a whole new port…

and if the comments elsewhere (Linux land) are any giude the job would be near impossible due to the lack of technical information. Just check the various forums/blogs and the amount of “grumbling”¹ about the lack of information about a supposedly open product.

All in all the development boards like the Arndale have more data and likely to produce a working outcome.

¹ Some might user stronger terms

Rick’s right: A lot of IO and an OS that does not get in the way is really a big advantage especially combined with a very low price. Breaking a BB does hurt much more than braking a BBB. It’s ideal for tinkering on a very high level of processing power.

There’s a hint here that the OMAP5 TRM will be available soon. The system reference manual is already available here

The OMAP5 TRM has just been released. It can be downloaded from here.

:-))
It downloaded for me so quickly I thought it couldn’t be the full data sheet. But at 6181 pages I think it might be complete!
I’m still waiting for my contact to get me the full data sheets for the TWL6040 & TWL6038

Edit: No wonder they couldn’t find TWL6038 it is TWL6037

BeagleBone Black is now shipping. One has just arrived here!

I too feel it might have potential as a little RISC OS machine, but I guess the question is “lack of interest” or “lack of time”? I mean, it isn’t as if Jeffrey hasn’t done anything for a while – it is actually rather the opposite, he’s taken on a pretty big project with the whole GraphicsV stuff.
The next question is, does anybody at ROOL have a BBB? If not, is anybody (else) willing to chip in to get one if there is interest in a port? That said, how is the level of documentation of the hardware on the board? Will a port be able to be kicked off by recycling a lot of the Beagle code? Or will it require blood sacrifices?

The issue is never as simple as it might seem…

Oh, and as for the lack of comment, take your pick:

• Been really busy.
• Wasn’t this discussed already, like in April?
• Sorry, what? Got distracted by pictures of kittens.
• All of the above.

(^_^)

The AM335x is from a different family of SoCs to the OMAP35xx/DM37xx family that’s used on the BB/BB-xM. So although many of the sub-modules may be compatible, the physical memory map is very different, and I suspect IRQ assignment is very different also. So if someone were to start a port it would probably best to create a new HAL (or start with a copy of the OMAP3 one) rather than try and add AM335x support to the OMAP3 HAL.

For an example of one of the bigger differences, the AM335x doesn’t seem to use the same display controller as OMAP3/OMAP4 – instead it looks like it’s using a much simpler LCD controller. So it won’t be possible to reuse the OMAPVideo module. The TRM claims the maximum pixel clock is 100MHz, which isn’t fantastic, although it might be possible to use slightly higher frequencies without any problems (e.g. BB max is supposedly 86.5MHz, but we’re currently allowing up to 100MHz)

From a brief look at the BBB website it looks like the only serial port available is a header providing 3.3V TTL signals (same as the R-Pi IIRC?) – so you’ll need your own RS232 or USB converter (the wiki has a list of suitable USB cables)

Also the TRM confirms that the CPU has VFP support, so there’s no need to worry about the fact the website & datasheet only mentions NEON.

Personally I’m not really interested in the BBB, as it isn’t a step forward from what we’ve got currently, and the R-Pi has already filled the “dirt cheap” category (although I’d argue that the BeagleBoard and PandaBoard were dirt cheap to begin with, when compared to Acorn/Castle kit). I don’t really need another dev board sitting around gathering dust!

I have argued before that the BBB is really a case of “very special interest”. The Raspberry Pi caters well for the low-end-tinkering category, and the BBB is not that much cheaper than the BB if you really want a Cortex-A8 to play with. The BBB also still has the BBs “cannot do Full HD@60 Hz” problem.

Investing in a port to OMAP5 or another high-end platform would be much more valuable.

Personally I think efforts on the BeagleBone would be a waste of time and thus counter-productive. The Raspberry Pi covers the low price end (with excellent performance for the price) and the Pandaboard ES covers the medium/high end performance – both of these have not yet got a stable RISC OS release and this must be the priority.

Higher end boards need to be considered so that one offering high storage speeds (SDFS can reach 20Mbytes/s and so SATA or similar offering 50Mbytes/s or more is a prerequisite for attracting attention) can be considered as a candidate.

I am only suggesting that some one that has neither and has the time and skill take a look at porting RISC OS to the BBB. Even if the BBB port ends up sith out a stable release for a few years after an alpha release is available.

I would suggest that if anyone feels strongly enough about porting RO to a new platform, including one rather close to a current platform (BB <→ BBB) then the first thing to do is to register an interest in doing a port,
Second establish with a dialog with previous port authors details of major hurdles/problems.
Third, follow the guidance and try a primitive port and record the results. People here might comment and help.

There’s a phrase I have in mind for the next bit – however, being from Yorkshire I shall remain quiet for a while.