Let's get started with a Pandora port

All fixed now. It looks like there were a couple of issues at work – the first appeared to be that although the ‘register access ready’ interrupt had fired, it still wasn’t always safe to modify the I2C controller registers. This meant that sometimes the ‘send stop bit’ flag was being cleared before the stop bit had actually been sent, causing the bus to stay in the busy state and the code to get stuck waiting for it to become free.

There was also a bug in the interrupt handling that was causing interrupts to sometimes be left disabled, which would have resulted in the total lockup I was seeing; ironically this bug was introduced by some of the code I added to try and make the I2C more stable!

And also while adding the FIQ-based debug code I discovered that the FIQ handling in the HAL was broken, and instead of telling the interrupt controller to restart FIQ processing after each interrupt it was telling it to restart IRQ processing, so on the first FIQ the CPU would get stuck in a loop servicing the same interrupt over and over. Doh!

The RTC code is now in CVS (along with the I2C code, which was in CVS in a mostly-working state a few days ago). A not so brief rundown:

• The RTC code should work fine. Just be aware that the year may default to 1900 if the RTC isn’t running, instead of 1970 as it was before – this is mainly because RISC OS currently ignores any error codes returned by the RTC driver. I suspect I’ll fix this at some point, since it could cause problems with apps which try using 4-byte Unix times.
• Also, the bug where you’re unable to set the correct time seems to have vanished – I’m guessing this was just a case where the RTC code breaks down a bit if both RTC and CMOS RAM are absent (since both are required to store the full 4 digit year).
• I didn’t try running Linux, but as far as I can tell after having a brief look at the source code there shouldn’t be any incompatabilities with the way RISC OS sets the RTC (except I’ve made RISC OS treat any RTC year above 70 as being from 1970-1999, whereas Linux seemed to treat it as 2070-2099)
• The I2C code should be fairly robust at this point, but it will probably do the wrong thing if you try sending a transfer list that switches between read & write without sending a start bit (which is probably a protocol violation anyway). Also any unexpected errors encountered during transfers may result in the bus remaining locked in the busy state – I’ll probably fix this in due course.
• I’ve also implemented HAL_Video_IICOp (aka GraphicsV_IICOp). The error handling is messy (i.e. it won’t tell you about an error), but in my defense I only had the NVidia IICOp code to go by as reference (i.e. that code is equally bad!). But it does seem to work just as well for reading EDID data from an attached monitor. Just make sure it’s a DVI monitor, not an HDMI one – I haven’t checked the specs but I believe HDMI monitors use a different IIC bus address/protocl for their EDID data.
• Out of the 4 I2C busses provided by the OMAP:
  • I2C1, which is connected to the TWL/TPS, is what RISC OS sees as IIC bus 0.
  • I2C2, which is connected to the beagleboard expansion header, is what RISC OS sees as IIC bus 1. However RISC OS currently doesn’t install an interrupt handler for anything other than bus 0, so if you were to try using it for something you’d have to register your own interrupt handler (and get it to call HAL_IICMonitorTransfer) or just sit and call HAL_IICMonitorTransfer in a loop until it reports success/failure.
  • I2C3, which is connected to the HDMI connector, is currently only accessible to RISC OS via HAL_Video_IICOp/GraphicsV_IICOp.
  • I2C4 is a bus for which the ARM core has almost no direct access (it’s connected to the TWL/TPS and used for some power management tasks), so isn’t supported by any of the I2C driver code.
• My FIQ based debugging code is also in CVS, but it may be a bit broken now. Previously it was relying on HAL_InitDevices for activation, at which point it hijacks the FIQ exception vector. Except that something in RISC OS was claiming the FIQ handler during initialisation, so you’d have to manually call HAL_InitDevices after the machine starts up to re-enable the debug code. Which now means it may break a bit, since HAL_InitDevices now registers the HAL RTC with RISC OS - so if anyone gets desperate enough to need the debug code they’ll either have to find somewhere better to initialise it or disable the HAL RTC (or maybe RISC OS won’t mind the same device being reigstered twice – I haven’t checked!)

In a few days time, once I’ve got the HAL documentation (mainly the RTC docs) into the wiki, I should be able to get back onto the USB OTG driver and get host mode implemented.

Jeffrey, I’m following this thread with great interest. I would absolutely LOVE to be able to run RiscOS on my Pandora (when it arrives!)

Thanks for all your hard work so far.

Finally some good news – I’ve managed to find the magic steps needed to get VBUS working for the USB OTG controller. I’m not sure how I managed to miss it when I was first comparing register dumps for before & after loading Linux, but it looks like the problem was caused by the HFCLK_FREQ field of the CFG_BOOT register not being initialised. Naturally the manual only makes a couple of mentions of the dependency between HFCLK_FREQ and the USB module, and it isn’t mentioned at all in the USB section.

It looks like there might be a little bit of extra code I need to write to prompt the controller to wake up and enter host mode when an OTG cable is inserted, but if all goes to plan I should be ready to start implementing the host-mode functionality after just another hour or two of work.

Also, some news regarding the Touch Book – as I suspect a number of you are aware, the first batch is now well and truly in the hands of customers. But more importantly for us, Always Innovating have been adding lots of information to their wiki covering details of the machine – including the customisations they’ve made to u-boot and the Linux kernel. I haven’t looked into any of the real details yet (e.g. what changes will be required to the video driver), but judging by all the pics of the hardware I’ve seen it looks like there isn’t any serial port on the motherboard. Which means that before we try our first boot we’ll need either a working video driver, or a peripheral-mode USB driver that makes the machine look like a serial port device when plugged into a host PC.

Are there any GPIOs free on the Touch Book? Another option might be to bit-bang serial out of those… slow as anything and a bit painful to get the timing right, but it used to be common on microcontrollers before they gained builtin serial ports.

There are a couple of GPIO pins that are routed via the connector that connects the tablet to the keyboard. But hopefully we won’t have to resort to that if it’s going to be a pain to get working!

To be honest it probably won’t be that hard to get USB working and to hack the video driver so we can display something on the screen – but we may still run into problems later on when a serial port or some other debugging interface is required (e.g. while trying to get the real video driver working properly).

After spending about the last three hours determining that “debug_set_stamp_debug(TRUE)” in the USB driver source was causing interrupts to be briefly enabled during debug output (and thus causing a deadlock in tsleep() due to an interrupt handler flagging a USB transfer as completed before tsleep() began waiting on the semaphore), I can confirm that yes, the code I wrote three hours ago for handling USB control transactions does indeed work.

So assuming that I don’t have to spend a similar amount of time debugging similar deadlocks tomorrow, I should hopefully be able to get either bulk and/or interrupt transactions working, which will be enough for people to start using devices.

I’ve just checked in the first version of the MUSBDriver with working host-mode support. This means that owners of rev B boards can enjoy the full splendour of the RISC OS desktop!

The driver is still very rough around the edges, so here are a few notes:

• Make sure you’re using a powered hub! It took me a while to work out that some of the problems I was seeing were due to me not plugging in the hub (due to lack of plug sockets) and not due to a bug in my driver :)
• If you plug in too many devices (around 8 or more) then the driver will fail! The USB OTG controller has a limit to how many devices it can talk to at once, and my driver currently isn’t smart enough to work around that limit once it reaches it.
• The code that detects that the USB OTG cable is connected to the board is a bit unreliable. If you make sure the cable is connected at boot then everything should be OK.
• I’m not sure what will happen if you try connecting a device which has a max packet size that’s >512 bytes. At the moment the FIFO sizes are all set at 512, and none of the devices I have seem to require a size that’s larger than that, so I’m not quite sure if the driver handles it correctly (although I can easily decrease the FIFO size to check!) You can use *usbconfinfo to check the packet sizes that a particular device is using.
• Remember that there is a 4 second delay between inserting a USB storage device and it being registered with the SCSI module. I’m not sure why this delay exists (or why we can’t remove it with a configure option!), but it’s important to remember that it does exist because if you’re at the command line and you try to use the drive before it’s been registered then things seem to break a bit! You can use *devices to get a list of registered devices from the SCSI driver, then once it’s listed you should just be able to enter *scsi to switch to the device.
• I’ve checked in a change to disable the debug terminal by default, so future ROM images built by the autobuilder should have full USB keyboard/mouse support.

Now that USB is mostly working I’m planning on spending the next few weeks making the port easier to use – sorting out a !Boot sequence, fixing the horrible performance of the USB mass storage driver, getting networking working, etc. – so if there’s anything in particular anyone wants me to look at then please say so. I’ve also got a fairly long list of improvements to make to the USB OTG driver, so hopefully I’ll get around to doing a few of those as well :)

Later on today or tomorrow I’ll add a page to the wiki giving more details about the driver, and how to enable debugging so I/we can track down any bugs that are found.

Wiki page with instructions on how to enable debugging:

http://www.riscosopen.org/wiki/documentation/pages/MUSBDriver

Jeffrey, you’re a hero! God bless your bleary (they must be) eyeballs!

This is great stuff, I now have a build going on my revision B6 board.

OK have RISC OS booting on my rev C board (YIPEEE :-) <—and actually really easy in the end – it is all about making the card bootable…) – now how do I get it to understand the SD card as a drive?

If it’s plugged into the SD card slot, you won’t be able to use it from within RISC OS at the moment, as the drivers for the SD card slot are still a work in progress.

Instead you’ll have to use a USB stick/pen drive/SD card reader. You should be able to use !SCSIForm to format it for RISC OS. Just try not to make the partition too large – with the current USB drivers an 8GB filecore-formatted SD card literally takes over two minutes to mount :(

After that, the current procedure for booting RISC OS would be to make sure you’ve got the boot sequence installed on the device, connect it to the beagleboard, boot the board into RISC OS, then use ’*devices’ to check that the device has been detected, then ’*scsi’ and ’!Boot’ to start the boot sequence.

The ’*devices’ check is required because there’s a 4 second delay built into SCSISoftUSB before the device will appear (grr!), and a bug somewhere that’s stopping USB hub port change interrupts from working with the EHCI controller (so it could be anywhere up to around 10 seconds before RISC OS even knows you’ve connected a new USB device)

I don’t seem to have this problem!

This is my set up:

I am using a powered USB hub.

One of its outputs is powering the beagle board.

The input to the hub is connected to the host USB connector on the beagleboard.

Keyboard, Mouse and a 2GB USB pendrive are connected to other outputs on the hub.

On boot the pendrive is immediately there!

In fact I copied one of my awful Iyonix !Boots to it did a scsi then !boot and it tried to run boot! <—OK it threw up an error but it proves it could work :-)

NB I think the key here is that the pendrive works with my Iyonix <—never formatted it…

Now all I need is a clean friendly !Boot

hint hint

See our response to your other forum post. :)

On boot the pendrive is immediately there!

It’s usually there on boot for me as well – but that’s probably only because the machine pauses for a few seconds while enumerating the USB devices (which is probably another bug to look into – or perhaps a symptom of why the hub port change interrupts aren’t working. Hmm.)

Or maybe I’m just ‘lucky’ and it is a problem unique to my hub (I am reminded of the recent discussions relating to the configurable port reset delay – perhaps the hub doesn’t reset properly when connected to the beagleboard’s EHCI port, but due to slightly different timing/etc. manages to work fine on the MUSB port. And due to a different configured delay, manages to work fine on my Iyonix’s EHCI ports).

Anyway, leaving behind USB for the moment(ish) – I’ve just updated the product/compoent files to add the networking modules to the ROM image. To make use of the networking you’ll still need a working !Boot sequence (which as ROOL say is coming real soon now!), and of course a driver for a network adaptor – i.e. James Peacock’s EtherUSB.

I’ve been able to update my copy of EtherUSB to support my ‘Pegasus’-based USB->LAN adaptor, and will try to get the changes sent to James in the next few days. James says he’s happy for the code to be in CVS here, so once he has my code it’ll hopefully only be a few days before we’ll be able to build the driver into the ROM/disc image, making it easier for people to get their boards connected.

I’ve also checked in a small fix for the RTC code, so it should now default to 1970 again instead of 1900 when the RTC hasn’t been initialised or returns an error.

The RTC code seems to fail on my BeagleBoard. It is battery back-upped so it should retain the time setting after power down, right? Is there something that needs to be ‘selected’ or enabled in the ROM to get proper timekeeping?

The RTC seems to work fine for me. If I set the time from within RISC OS or Linux and then hit the reset button and boot into RISC OS then the machine will still have the correct time. However I only have a rev C2 board so I don’t have any way of checking that it works properly with the backup battery – it’s possible that there’s something that I’ve missed that needs doing to enable the battery, or I’m checking the wrong flags in the RTC register and it thinks the RTC is stopped when it really isn’t.

If you want to look into the issue yourself then you can grab a copy of the TPS65950 TRM from here, and there’s information about the HAL RTC protocol available here. Unfortunately it’s a bit tricky to add any debugging code to the RTC code in the HAL (it doesn’t get passed a HAL workspace pointer, so the DebugTX and DebugReg macros won’t work), but by placing some debug code in the relevant bits of the kernel or enabling the I2C debug code in the HAL it should be easy enough to see what RISC OS is doing.

The only other thing of note is that if the RTC is stopped, the current version of the driver will only attempt to start it when you try setting the time. This is a bit different to how the Linux driver does it (and how I think the original RISC OS RTC code does it), where it will detect the stopped clock on boot and start it straight away (even if the machine doesn’t yet know the correct time to program it with).

http://www.epistaxsis.co.uk/beagleboard/screen.jpg

So some stuff just works!

Martin W was most suprised at the show to see the Artworks viewer working – here is the full version working :-)

!Confix and !HiD too

Oh and Steve Revill there’s one of your programs running too :-)

And sorry Chris – there’s the !Themes Configure plug in working!

Although the windows setup plug in forgets setting an iconise button and fonts forgets the font for the desktop on boot <—bit like an A9…

Oh and the Screensetup configure plug in crashes…

Might be time for a what works and what doesn’t work list here?

Looks like the show went well for you then :)

Although the windows setup plug in forgets setting an iconise button and fonts forgets the font for the desktop on boot

That’ll be because there’s no code to load/save the CMOS RAM at the moment (Another thing that’s still on the todo list!)

Oh and the Screensetup configure plug in crashes…

Yeah, there are a couple of issues with that.

Might be time for a what works and what doesn’t work list here?

It’s probably getting to around that stage, yeah. Sometime tomorrow (i.e. when the server reboots and the wiki starts working again!) I’ll split the current wiki page into seperate pages so it’s easier to read. Then we can add a new page for listing app compatability, a page summarising known bugs, etc. And if someone at ROOL can add a new project to the bug tracker then people can start submitting bug reports via that.

Keith – Glad it’s working, though you have quite an old version of the plug-in, by the looks of that theme. The latest version is at www.lym.iconbar.com/themes, if you’re interested. :)

Which reminds me, I need to look into polishing off the Theme Manager at some point. There was one problem, IIRC, in that my manager sets some WimpVisualFlags settings after being run from PreDesk. However, in the Iyonix default !Boot sequence, another WimpVisualFlags script is run later in the process. The only way to get the Theme Manager to control the visual flags is to manually delete the second Obey script (I can’t remember the exact location of this – perhaps in Choices). Am I right in thinking the !Boot sequence is being worked on at the moment? Would there be any chance of fixing this? It would remove one slightly annoying glitch!

Secondly, does anyone at ROOL have a view on whether the Theme Manager is (a) desirable to have as an integral part of the OS distribution and (b) of sufficient code quality? If the answer to both is Yes, then I’d be happy to see it included in any future releases.

Chris,

As you know Paint nicks the input focus when you do a snapshot…

The WimpVisualFlags error I found was being caused by other programs / scripts not part of the normal Boot – there is certainly no issue with my beagleboard!

And if someone at ROOL can add a new project to the bug tracker then people can start submitting bug reports via that.

I had a pop at doing that and the bug tracker finally died completely. Hopefully, we can get Andrew to fix it from New Zealand.

Secondly, does anyone at ROOL have a view on whether the Theme Manager is (a) desirable to have as an integral part of the OS distribution and (b) of sufficient code quality? If the answer to both is Yes, then I’d be happy to see it included in any future releases.

I’ve never really played with it nor have I looked at the source code, but in principle I like the idea of having it integrated into the boot sequence. We are indeed working on having the RISC OS 5 disc image published (and buildable from published sources) on our web site.

There are lots of things which I think would be good to see added to the standard (boring) disc image which would make for a more useful out-of-the-box system than current suite. Maybe ROOL should speak with some third parties about adding useful bits and bobs – (like AWRender, for example).