Beagle - potential Cortex A8 target.

The Beagle is a board based on the TI OMAP3530 chip being put together by TI engineers as building blocks for linux projects.

The good,

$150 USD. 600MHz Cortex A8. 430MHz DSP. USB OTG High Speed. DVI-D.

The bad (subjective). No Ethernet port (will need a USB dongle). The Rev B boards USB OTG port works but the EHCI host port does not, this is a hardware issue that will be fixed in Rev C, November at the earliest. The OTG port can be used as host, but noone has tried this yet. There was an unplanned mass announcement at http://linuxdevices.com/news/NS5852740920.html earlier today so the boards may be scarse for a while – this has prompted me to post now. The distributer doesn’t have stock yet.

The mixed.

The chip has been tested at 1600×1200 at 16bit and 24Hz progressive. The pixelclock is currently lower than expected in a gfew screen modes and noone is sure why, it ought to go to 65MHz. Probably a driver glich. The board consumes about 1.8W at a command prompt, this may go down as power management has not been added to the kernel (not that this really affects a potential RISCOS port).

I’ve kept an eye on this for a few months, almost as long as I’ve known about the open riscos effort and it’s the cheapest A8 development board I’ve found by a long way. More details at,

http://beagleboard.org/

This seems like a neerly ideal Desktop A8 target using the flagship OMAP35xx product and there seems no real disadvantage to developing for hardware this cheap and then moving onto something with better connectivity as and when it comes along.

Any thoughts/obvious problems/alternatives?

I’m unsure why this is an interesting target for RISC OS over any others beyond some enthusiast wanting to do it for the sake of it. To make a “complete” computer you need to add a case, PSU, and as you say, some kind of network connectivity and is not even complete. Yes, it’ll probably be a bit faster than Iyonix (better memory speeds I suspect). It also doesn’t have IDE, although the need for that is arguable, with that being an aging technology.

There are numerous ARM boards out there, all with many variations on this, and some which are actually complete ;-) I named the Jornada earlier, because it’s a complete portable system (for the same price as the board you named alone and widely available), and fits an obvious niche for RISC OS portability.

The point here is that there needs to be a (near) complete solution for a RISC OS port, not just something that runs ARM.

The Cortex A8 is dual issue superscalar so it has the potential to run code twice as fast as the XScale in the Iyonix, and at a tenth the cost it sounds promising to me. Probably more important though is that the A8 is at the very start of its life, with nothing being available 5 or 6 months ago, developer grade projects and kits like the Beagle, Pandora, Zoom just coming on line and with consumer products some way off the effort in porting to the OMAP3 chipset certainly wouldn’t be wasted.

Intel has abandoned the ARM, noone other than TI seems to have picked up the A8 yet, the OMAP3 series is looking to be the top tier of ARM chip for some time. 800MHz products have been annouced for STB applications and we may see the top design speed of 1GHz.

I don’t like USB and the Beagle is far from ideal for putting together a complete system. It could be done, even an IDE hard disk can be plugged into a USB port with a suitable adaptor. I think a flash hard disk using the SD slot is pretty workable and I can think of a lot of uses for a low power, totally silent system. I don’t own a beagle, but I am considering it and I certainly would if there was a porting effort.

The Jornada technology is 10 years old and second user – I wouldn’t blink twice at it if it didn’t have an ARM in it. Cortex A8 in the form of the TI OMAP3 chips are happening right now and I would like to see RISC OS part of that. I’d go furthur, RISC OS needs to be running, and to be seen to be running on the Cortex A8 and I don’t think this is a big point of contention, the question for me would be if there is a better target than the Beagle.

Clearly you have some obsession with this core, but you haven’t really answered my questions. What makes this system so compelling versus any other – have you done any research into other/better platforms for RISC OS?

The Cortex A8 is dual issue superscalar so it has the potential to run code twice as fast as the XScale in the Iyonix

Not with RISC OS, if your wording means it is dual core (I don’t know) – since RISC OS has zero support for that. Clearly it’s going to be faster than the 6 year old IOP321, there’s no question about that. But that’s not very useful by itself.

and at a tenth the cost it sounds promising to me

Where did you get this pricing from? Do a complete parts list and see what you come up with. Yes, of course it’s going to be cheaper than the Iyonix, that’s not exactly hard, but a 10th, that’s pushing it.

The Jornada technology is 10 years old and second user – I wouldn’t blink twice at it if it didn’t have an ARM in it

But who are you arguing the case for – your own enthusiasm and interest in this core, or a more widespread audience who do in fact, want mobile RISC OS computing. I pointed out the Jornada because of various reasons I already named in detail. Is it likely there are similar platforms which have similar features – yes. That it’s 10 years old, I don’t see as particularly relevant – it has similar performance to the many RiscPCs still in use.

RISC OS needs to be running, and to be seen to be running on the Cortex A8

Why? Who do you need to convince? And in any case, it can’t be done for reasons you’ve named – this hardware isn’t available. If the argument’s that RISC OS ought to run on OMAP processors, then that might be convincing, but there’s plenty of (older generation) OMAP hardware about that’s available right now.

As an end user of RISC OS, I would dearly love to see it run on many of the ARM devices out there, however, as soon as you bring reality into the equation, then it paints a rather different picture. For a start I believe that there is an order of work that needs to be done before we can start to port RISC OS to other platforms.

1) Make Changes to RISC OS codebase so that it can compile with free C/C++ compilers

2) Produce a free installation RISC OS emulation disc/binary file so developers outside of the current community can ‘play’ and see if they are interested in improving the OS

3) Start to produce detailed documentation to aid developers (porting or otherwise)

4) Start work on porting RISC OS (assuming any developers exist / are interested)

These are just my thoughts on this matter, and given that I am not developer, I may well be off the mark, but rather than trying to take big steps towards the goal of porting RISC OS, I think small steps is the way forward.

Anyway, hope I don’t sound too pessimistic. As is I said, these are just my thoughts on the matter. Others more close to this, will I am sure have different ideas.

Surely the Pandora (http://www.openpandora.org/) would be a better target as it’s a complete system.

Yes, the screen is a little on the small side, and it’s not available (yet) but it has the requisite interfaces (I think I saw it had LAN, but certainly has wireless) – no HD but you can fit an awful lot of RISC OS applications on some fairly meaty SDHC cards. It’s all Linux based so I would assume there are relevant drivers out there (unless they’re all binary blobs).

The projected price is £199 which all sounds pretty reasonable too.

Surely the Pandora (http://www.openpandora.org/) would be a better target as it’s a complete system.

Yes, I think so. The “perfect” RISC OS hardware will probably never exist, but this is pretty convincing target. I note that we’re really discussing two different platforms here (although arguably rapidly converging) – a replacement for Iyonix/A9 and a RISC OS portable.

Any new platform is going to require a huge amount of effort for specific CPU support, and drivers, and allowing for any device quirks, etc. Sometimes getting fully polished Linux support on these things can take a year or so.

I don’t know that we’ll ever see again an Iyonix-style RISC OS product again (unless it’s an x86-based emulation solution) – that is a large box with mostly unused expansion capabilities (few people ever used podules in them), and most expansion now apart from CDROM (and even that in the case of the A9) is USB. More likely would perhaps be some compact existing ARM board with IDE and integrated graphics (I don’t know of anything off the top of my head which would fit this bill), boxed in something like the size of a MacMini. But even that presupposes that development effort on drivers and such I named earlier could take place.

In support of the OP’s idea, I do think that a £75 board is quite an different prospect compared to a £200 subnotebook, and possibly attractive to a different market. The subnotebook is probably more attractive to the end-user, while the board might be to developers.

However I do think we need to be realistic about USB. Compared to old-fashioned chips-on-a-system-bus, USB is a lot more work. We’ve seen how existing RISC OS USB implementations fail to deal with the variability of USB devices out there, and using random USB devices may face the same problems as we currently have with mass storage devices. It may be possible to ship a handpicked device with the board as a package, but you still have to watch in case the manufacturer redesigns it underneath you.

Let’s face it, RISC OS hasn’t been ported to too many systems. If I were doing the porting work (which I won’t be) I think having USB for I/O would be a pain I could really do without for a first port. Unless there was enough effort put into dropping all the work done on NetBSD/etc’s USB support straight into the USB modules and have it work cleanly. Though at least such device drivers could be tested on existing hardware (Iyonix) first.

A positive reason to go for a Cortex A8 is that it provides ETM – ARM’s embedded trace macrocell. That should be particularly useful for OS porting.

Unfortunately it seems Beagle and OpenPandora provide JTAG but no access to the ETM port. (According to the Pandora forum and Beagle manual). But JTAG may still be useful and perhaps ETM debuggers are too expensive anyway.

Let’s face it, RISC OS hasn’t been ported to too many systems. If I were doing the porting work (which I won’t be) I think having USB for I/O would be a pain I could really do without for a first port

Certainly. I haven’t dug too much in the Pandora hardware, but I suspect that basic I/O – keyboard, touchscreen, ethernet is not USB at all, just boring old hardware access. There’s most likely a regular serial port on board (possibly TTL level) if it’s anything at all like most ARM boards. USB only comes into play for expansion and the wireless.

Unless there was enough effort put into dropping all the work done on NetBSD/etc’s USB support straight into the USB modules and have it work cleanly.

That’s a probably a good idea, irrespective or this, and perhaps not too much work. Similarly for the TCP/IP stack.

Superscalar means the CPU is capable of executing more than one instruction per clock cycle. The Cortex-A9 is slated to be the first multi core ARM IIRC.

Pandora is 480 visible line, NTSC output, more expensive and the schematic isn’t public. I’ve drawn a 13cm line on a bit of paper and I can’t imagine myself being able to use a condensed keyboard that small for any length of time. It has wifi and now bluetooth but not ethernet. That said the core hardware is very similar and so we still get the benefits from a port to that architecture.

I really don’t like a USB solution, but it does solve the problem. It is my understanding that by implimenting the Human Interface Device spec, we get support for keyboards and mice by almost any manufacturer, and by implimenting the mass storage spec USB memory sticks, hard disks and so on work. With hardware on the CPU bus you don’t have these levels of abstraction.

The most useful debug functions are avialable through JTAG, ETM port is for the owners of very very serious hardware.

I am new in RiscPC… But I like idea to port RiscOS to Beagle board. For example this one.

http://www.ebv.com/index.php?id=102&no_cache=1&tx_ebvproductfe_pi1[uid]=456

And from another forum -> “Do yourself a favor and wait a month or two until the C-series comes out. The current Beagleboard still runs engineering-sample Omap-Chips and has some nasty bugs. The new revision will have twice as much memory, working high-speed USB and hopefully the core bugs will be fixed as well.”

-SD-CARD as HDD /prices of 4GB-16GB are good today/ -USB is cool (flashdisks ,hdd ,printers ,gamepads…) -for networking I have PC /so I dont need to have RiscPC for surfing internet/ -Cheap price for begle board -I can make acrylic case manufacturing documentation for it…

http://www.ebv.com/fileadmin/products/Press_Print/Brochures/Product_Brochures/Beagle_Board.pdf

http://www.ebv.com/fileadmin/products/Press_Print/Brochures/Product_Brochures/Beagle_Board.pdf

Matej – are you still around on this forum? (Or anyone else who can please advise with the EBVBeagle ?)

EBVBeagle (rev.C4)    CHECK
(Working) DVI monitor CHECK
USB kb+mouse          CHECK
7-port USB hub        CHECK

When I follow The easy way the board gets to the No keyboard present – autobooting point. The included Linux BSP (ARM EABI Ubuntu) boots fine with kb+mouse, so I thought I’d better try a Hard way .

No luck, so prehaps it’s the FAT32 formatting (although I don’t understand why, as I can get to the Supervisor prompt OK). The suggested FAT32 Windows-only formatter utility doesn’t seem to like Vista… but I should be able to format on the EBVBeagle under linux. Anyway, I should probably make a copy of the dual partition boot card first (just to be safe) using an SD card reader. So far, so good except I don’t have mkfs.msdos! To further complicate matters my Windows laptop doesn’t have a DB9 connector so TeraTerm isn’t much use (although I can perhaps use my RiscPC instead for this). Additionally, unless I can format ADFS under linux (or Windows!) I’ll either have to buy a Unipod or enlist the help of a friendly Iyonix owner (or owner of RiscPC with Unipod, I suppose).

I’ve not yet followed these MMC Boot Format instructions – does anyone think that’ll help? I could also go back to basics and install a new linux distribution which includes mkfs.msdos. Something else I can investigate is approaching a couple of linux-savvy acquaintances who live nearby… which is probably what I’ll end up doing.

To round it all off, I only bought the EBV because it was a packaged solution made by an EU company and they claimed (but did not fulfil) quicker delivery than Digikey. I’m now slightly regretting not cancelling the order and going for a non-clone board!

On re-reading all of the above, perhaps it’s simply U-Boot or X-Loader which need upgrading! Apologies for posting what’s probably a very basic problem.

TIA.

When I follow The easy way the board gets to the No keyboard present – autobooting point.

Did you actually check that the keyboard was(n’t) working? The “No keyboard present” message is there just because the HAL doesn’t implement the code needed for scanning for the R/Delete/shift/etc. keys at boot. So just because it says there’s no keyboard it doesn’t necessarily mean that the USB drivers weren’t working.

However having said that I do know there were some changes made to the rev C4 boards to fix the intermittent USB EHCI failures – I haven’t yet checked if those changes affect RISC OS. AFAIK the EBV is an exact clone of the beagleboard and uses the same U-Boot versions, so if I make sure everything is compliant with the latest Beagleboard hardware manual then everything should be OK.

Did you actually check that the keyboard was(n’t) working?

Thanks for the pointer. I don’t normally suffer from OCD but I now need to double check next time I get a chance! Pretty sure the answer’s yes, though.

I do know there were some changes made to the rev C4 boards to fix the intermittent USB EHCI failures…

Is anyone else here using a rev C4 board successfully?

AFAIK the EBV is an exact clone of the beagleboard

"And, it is manufactured on the exact same production line as the Beagle."

Is anyone else here using a rev C4 board successfully?

Yes. How can I help?

Thought you might be, Dave – so I guess it’s not down to changes on the rev C4.

Therefore I must’ve missed something. Will post when I’ve tried again. Thanks, both of you.

If you can both connect serial cables and check the U-Boot version numbers then that would probably be a big help. I’m not sure offhand where to get a version of U-Boot that works with the C4; for the beagleboard the one supplied in NAND will work, and I’d assume EBV would make sure the one in their NAND is fine, but if for some reason the versions your both using are different then it might explain why Trevor is (potentially!) having problems.

Also asking you both to report your version numbers should allow me to update the wiki to point people to the correct U-Boot version to use for BB/EBV :)

If you can both connect serial cables and check the U-Boot version numbers then that would probably be a big help.

OK, I’ll try this when I can. Am I right in thinking I use Nettle , FreeTerm or similar for connecting to the RiscPC ? (Or I could try with a Netwinder if I can find it in the loft!)

EDIT: I overlooked the USB-RS232 cable option, which would mean I could connect it to the Windows laptop and retain the EBV’s display (which I understand is optional for a serial connection).

(OT: Did anyone ever hear of the LART, which I just found while searching for Netwinder RS232?)

Thanks again for the advice – I’ll post the U-Boot version number when I’ve done this.

It’s at about this point that we realise that most of the world has moved on and left serial behind. However, as a minimalist interface, it does have this niche in testing.

Are we dealing with 9600-8-N-1 here?

Can the u-boot version be read from the flash or from a file? It makes me realise that I don’t even know where u-boot is – is it in the OMAP’s flash or is it in the boot script file?

It would work for me as the BB does boot and run. It’s no help for someone whose BB doesn’t run at all, of course.

OK, I’ll try this when I can. Am I right in thinking I use Nettle or similar for connecting to the RiscPC ? (Or I could try with a Netwinder if I can find it in the loft!)

Nettle isn’t any good; it only deals with TCP connections and ANSI tasks, not serial ports. You’ll probably want to use Connector instead (although I can’t remember where I downloaded my copy from, and for reasons I can’t recall I gave up trying to use it with my Iyoninx and just hacked together my own BASIC program instead). If needed I can upload my BASIC program when I get home tonight (it’s basically just a modified version of one of the sample programs that comes with the serial block drivers).

Are we dealing with 9600-8-N-1 here?

115200 baud, 8 bit data, no parity, 1 bit stop, no flow control (taken from beagle reference manual)

Can the u-boot version be read from the flash or from a file? It makes me realise that I don’t even know where u-boot is – is it in the OMAP’s flash or is it in the boot script file?

If your using a blank SD card containing just the ROM image & boot script then the board will be using the copy of U-Boot in its flash (NAND). It might be possible to read the binary from NAND using Linux and then search inside it for the version number, but I’m not sure how easy that option is!

Thinking about it further, I’m fairly certain that all modern versions of U-Boot support serial-over-USB. So if you’ve got the right driver installed on your Windows/Linux PC (although I don’t know offhand which driver that is) then you should be able to connect the board to your PC using a standard USB A -> mini B cable and get U-Boot’s TTY output that way (of course this is useless for getting RISC OS’s TTY output; I’d need to improve the MUSBDriver for that to work). If you search around a bit you should be able to find a guide for getting it to work. This could be a solution for if you don’t have a suitable serial cable lying around (although not that suitable for Dave since I want him to take a look at the video driver’s debug output!)

You’ll probably want to use Connector instead…

Now that rings a bell. Thanks. I should have it, as I used it in the mid ‘90s to access PINE and IRC at uni. I’ll check.

you should be able to connect the board to your PC using a standard USB A -> mini B cable…

Thanks again – ISTR this being mentioned in a wiki somewhere.

Trevor: i have some Netwinders over here, are you looking at porting RISC OS to a Netwinder??