GAG-Meeting: BeagleBoard results

Hi altogether,

at the weekend, we held our annual GAG-Meeting (“German Archimedes Group”), and had two BeagleBoards available to do some testing.

• speed: for many tasks, the BeagleBoard is around two times faster than the IYONIX. These tasks included e.g. an Artworks redraw speed test and MPEG2 playback via KinoAMP (basically a straight recompile that Thomas Milius provided) – with TV MPEG2 streams (i.e. 720×576 with audio), the BeagleBoard achieved nearly 25fps with unoptimised code; a problem area remains that all I/O has to go via USB - with the current state of the drivers, this is a bit on the slow side if e.g. copying from network to disc or from disc to disc.
• video: there were problems configuring satisfying video modes. The only mode my BeagleBoard can provide that makes my screen happy was 1280×720. 1024×768 also worked. Was anyone successfull with 1280×1024? Or even higher? Would “FullHD” be possible, i.e. 1920×1080@24 Hz?
• compatibility: for maximum user acceptance, something like Aemulor is really needed. But a surprising amount of software already runs without problems. Once Jeffrey’s alignment exception handler works, compatibility problems should also occur less often.

My personal results were that my USB prototyping code successfully wrote a DVD-RAM, but is still a bit slow and does not handle stalled endpoints correctly. A CDFSSoftUSB is in development, but not-ready-yet, because I am really slow in developing assembler stuff. With Jeffrey’s latest ROM and CDFaker and CDVDBurn, at least a minimum CD/DVD reading solution is possible, and I will make relevant announcements in due course.

Generally, for the BeagleBoard to become the “next generation RISC OS box for the masses” (i.e. being a viable upgrade path for IYONIX and Risc PC and A9home owners), I think we really need the BeagleBoard xM – with the integrated network and the USB hub, it should be enough for most needs without connecting too much external stuff. Then, we will just need a clever casing solution, because the average user won’t be happy with the bare PCB lying somewhere ;-)

We had an interesting case solution available, with the BeagleBoard inside a 5.25” drive casing with an USB hub as front panel. For do-it-yourself-casing, I think this could be a “minimum fuss” case solution.

My personal wish list for a future BeagleBoard would of course include S-ATA and USB3.0, but I fear that I will have to wait a while for something like that to appear…

Steffen

Was anyone successfull with 1280×1024? Or even higher? Would “FullHD” be possible, i.e. 1920×1080@24 Hz?

Can’t know for certain, but I use a ProLite E2607WS with a BeagleBoard 1680×1050 at 43Hz which is well below its advertised 55Hz minimum v-sync.

We had an interesting case solution available, with the BeagleBoard inside a 5.25” drive casing with an USB hub as front panel. For do-it-yourself-casing, I think this could be a “minimum fuss” case solution.

With 5.25’’ you can add it to a PC or even place it inside a RiscPC while keeping the host alive as well – and maybe even OFF :-) – the cabling will not be optimal, but the difference for the power supply should not make much trouble.

My personal results were that my USB prototyping code successfully wrote a DVD-RAM, but is still a bit slow and does not handle stalled endpoints correctly.

Did you get enough testers as you requested for a while ago? (I replied direct from google groups, I assume either you had more than enough offers, or spam filters were being oversensitive.)

Hi Jess,

thanks for your offer and your “ping”. Indeed, I did not receive your offer for help, because Google Groups seems to ignore the reply-to set in my usenet postings. So I was now able to retrieve your EMail from the spamtrap and discovered one more offer for help – I was surprised how little interest there seemed to be, having received a grand total of one response…so I now have three, which is better, but not a lot ;-)

I am still ironing out the last few obvious bugs and shortcomings, and will contact you hopefully soon.

Hi Steffen,

could you enlighten me of what this testing is about? If possible/needed I could test on a revb6.

Google Groups seems to ignore the reply-to set in my usenet postings.

I guess it might be best to ask for offers of help to be sent to the newsgroup, which would also remove the possibility of assuming you have loads of help, so not offering.

Would “FullHD” be possible, i.e. 1920×1080@24 Hz?

Is the BeagleBoard like the RiscPC and A7000 in the ability to trade off colour depth for bigger screen modes? (ie pixel rate limits)

Is the BeagleBoard like the RiscPC and A7000 in the ability to trade off colour depth for bigger screen modes? (ie pixel rate limits)

Unfortunately not. With the RiscPC and A7000 the problems were down to limited memory bandwidth and limited memory size; pixel rate wasn’t so much of an issue. But with the beagleboard there’s plenty of bandwidth and plenty of memory, but unfortunately a rather low pixel rate limit, and there’s nothing you can really do to increase it. OK, that’s not entirely true – it would be easy to modify the driver to remove the limit, and I believe that at least one Linux user runs his board with a ~100MHz pixel rate, but removing/increasing the pixel rate limit isn’t something I really want to do just in case it does start damaging people’s boards.

1920×1080@24Hz (or 30Hz) is certainly possible, but I’ve never seen anyone report that they’ve found a monitor/HDTV that it’ll work with.

I had a look through the BeagleBoard manual and the eLinux Wiki and found the following:

• the limiting factor is the pixel rate
• officially, the pixel rate limit is 65 MHz
• in practice, 72 MHz seems to be reachable
• so 1280×1024@60Hz is not possible (would need 80 MHz)
• but “Full HD Blu-Ray style” is possible – 1920×1080@24Hz aka 1080p24

Thank god that we have LCDs and not CRTs, because 24Hz would definitiely be an eye-hurter…

I will try 1920×1080@24Hz with my large TV ASAP. Jeffrey, are there limits in the RISC OS video driver compared to the Linux stuff wrt video mode parameters? I noticed when experimenting with 1280×1024 modes that sometimes, the BeagleBoard (or RISC OS) just physically refuses to switch mode but pretends to have done the switch.

Uwe,

testing is about USB CD/DVD/Blu-Ray devices. Dave Higton already helped me testing, but unfortunately results were completely different to my own results, so I am now trying to get a broader testing base.

Jeffrey, are there limits in the RISC OS video driver compared to the Linux stuff wrt video mode parameters? I noticed when experimenting with 1280×1024 modes that sometimes, the BeagleBoard (or RISC OS) just physically refuses to switch mode but pretends to have done the switch.

Yes, there are a couple of places where limits are checked/applied. GraphicsV_VetMode is used by RISC OS to check that a mode is valid before switching to it; in the OMAP implementation the call will complain if any of the parameters are invalid. However there are situations in which GraphicsV_VetMode doesn’t get called (e.g. on boot before an MDF is loaded), so GraphicsV_SetMode will do additional checks and attempt to fix any bad parameters (e.g. if porch/sync timing values are too large). But SetMode doesn’t do a full range of checks (e.g. it won’t detect whether the porch/sync values are too small, and unless I’ve missed something it doesn’t look like it limits the pixel rate).

So depending on how well behaved RISC OS is you’ll get different results when you try switching to invalid modes. E.g. I’m not 100% sure that the display manager calls VetMode when it builds the list of available modes, but I’m fairly certain that it does call it before attempting to switch to a mode. There’s also some stuff that RISC OS does when you try switching to a numbered mode – it will often fall back to a 640×480 mode if it can’t find an MDF entry for the mode you wanted.

If you’ve got a serial cable connected then you should be able to see the mode timings that the video driver uses on each mode change, and any instances of SetMode attempting to fix the timings.

The full timing limits are as follows:

• At the moment the pixel rate limit is set to 86.5MHz (We’re using a clock generator that has a ‘maximum’ of 173MHz, but the display subsystem requires a minimum of 2 clocks per pixel).
• The maximum horizontal front/back porch limits are 256 for old OMAPs and 4096 for new OMAPs.
• For the vertical front/back porch the limits are 1 less than the above values.
• The maximum horizontal/vertical sync width values are 64 for old OMAPs and 256 for new ones.
• There’s also the requirement that the sum of the horizontal back porch, horizontal sync width, and horizontal front porch values must be greater than 4.
• Oddly enough there don’t seem to be any limits on the minimum vertical timings, but I have seen issues in both Linux and RISC OS where small vertical timings can result in the screen being offset by a couple of scanlines.
• The border width values are ignored by the video driver, so you should probably just set those to zero to ensure nothing gets confused (e.g. MakeModes).
• Maximum screen size is 2048×2048. Width must be a multiple of 8 pixels.
• “New OMAPs” are revision ES3.1 and above, “old OMAPs” are ES3.0 or below. “New OMAPs” have been around for about a year now; my rev C2 beagleboard is an old one, but I believe C3 and above all use new ones. At the moment there’s no easy way of checking which revision you have from within RISC OS, but you can check the u-boot output over the serial port or have a peek at the details of the L4_CONTROL_IDCODE register in the TRM.

Dave Higton already helped me testing

... and you can count on me to continue testing.

Btw I’m sure I read that CDVDBurn can create ISO images on the BeagleBoard, but the last version I have simply crashes out, with or without alignment exceptions on. Is there a later one I can try?

Hi Dave,

• creating an ISO image
• extracting an ISO image from CD/DVD/Blu-Ray devices
• using the CDVDBurn Extractor to give an FS-like pseudo filer access to CD/DVD content

Unfortunately, the version I gave to you was one of the “compiler created illegal code for ARMv7, and I only checked it on the IYONIX” executables. I think I have now a good idea of the situations where the compiler fails, so I will provide you with a working version ASAP.

However, a fully working CDVDBurn will only happen if I get that damned “clear stall” operation to work. Has anyone any experience with clearing the STALL condition on bulk endpoints? I tried DeviceFS_CallDevice, but this call always ends with “No valid endpoint” or something like that, the same for the “Check buffer space” call – can anyone help?

One additional limit: HDMI supports interlace, DVI doesn’t. Although the beagleboard has an HDMI connector it’s only using DVI signalling, so we can’t use interlaced modes like 1920×1080x60i :(

However, a fully working CDVDBurn will only happen if I get that damned “clear stall” operation to work. Has anyone any experience with clearing the STALL condition on bulk endpoints? I tried DeviceFS_CallDevice, but this call always ends with “No valid endpoint” or something like that, the same for the “Check buffer space” call – can anyone help?

I’m sure I’ve seen it used somewhere – try checking EtherUSB, or SCSISoftUSB.

I don’t think HDMI includes mandatory interlace support – it is just that if you want to call your display “HD ready”, you need to support the standardized video modes that include 480i, 576i and 1080i. So interlaced support is a device/display thing, not an interface thing.

So the problem is that the BeagleBoard’s video framer does not support interlace (or is it the graphics part of the OMAP itself? I don’t really know…). But I guess this is one of our smaller problems ;-)

I tried DeviceFS_CallDevice, but this call always ends with “No valid endpoint” or something like that, the same for the “Check buffer space” call – can anyone help?

I’ve not known the check buffer space call to fail like that. What are you passing to it?

If can also use EXT# or its OS_Args call to get the waiting bytes in an input buffer or, IIRC, the free bytes in an output buffer.

Hi James,

as a last resort, I was trying a simple line of BASIC to get the buffer space call to work – I looked at the list of open files, picked one device/file handle, and did:

SYS"DeviceFS_CallDevice",1<<31 + 2,"USB8",254 TO ,,,bytesAvailable%,bytesFree%

As I said, I am probably missing something very obvious…or is the “stream handle as returned by Fileswitch” not the filehandle?

Yes, R2 is the file handle returned from OS_Find.

I assume the above got mangled a bit. The following seems to work for me from a TaskWindow:

SYS"DeviceFS_CallDevice",&80000002,"USB8",252 TO ,,a%,f%
P. a%,f%

I did get the ‘Cannot find invalid endpoint’ when I first blindly followed the spec and typed 1<<31+2 instead of (1<<31)+2. The former evaluates to zero which is the initialise device call used internally by DeviceFS to communicate with its drivers.

Hi James,

many thanks for your hint – yes, I also blindly followed the spec…it is just too long ago that I did serious development in BBC BASIC to remember the finer details like operator precedence.

It is really amusing – I am using BBC BASIC to do the quick prototyping to find out how devices react without suffering from the long Ada compile times. But I would have never made that mistake in Ada in the first place…

Was anyone successfull with 1280×1024? Or even higher? Would “FullHD” be possible, i.e. 1920×1080@24 Hz?

Look here 8-) we visited our local dealer and tested this 27’’ LCD-TV with 1920×1080@30Hz with my revB6 Beagle…

...27” LCD-TV with 1920×1080@30Hz…

Top quality – anyone got access to a similarly high resolution projector for a test like this?

I am still waiting for my Sanyo Z3 to finally break (5 years old and still going strong, but unforunately only 120×720) to have a good reason to buy the Epson EH-TW5500…

Any plans for attending this Open HW SW Event in Munich at the beginning of December?