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. And the preliminary results are…
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 |
|
I run the Board with 1280×1024 at ~50Hz. The monitor is a cheap HannsG 19’’ (it also worked with an older Belinea). I remember someone reported a low Hz 1920×1080 mode some weeks ago and tried it myself but without success as the frequency was to low for the monitor I tested with. I found it: it was this – so no 1920×1080 but the frequency is not that bad:
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. |
|
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. |
|
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.
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:
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. |
|
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:
|
|
... 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, yes, there is a CDVDBurn version that is capable of reliably
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 :( |
|
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’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, 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 |
|
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… |
|
Look here 8-) we visited our local dealer and tested this 27’’ LCD-TV with 1920×1080@30Hz with my revB6 Beagle… |
|
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? |