Let's get started with a Pandora port

Awesome news! I think many of us have been following this thread carefully (I learned a lot!) Now a picture please :D

The video code is finally in CVS. A few notes:

• Firstly, the current video code will only work properly if RISC OS is booted via u-boot. This is due to u-boot doing something that RISC OS doesn’t, and I’m yet to track down what that is. With this in mind I’ve updated the wiki page with a load of new instructions on how to run ROM images. There are many ways of doing it, but the ‘easy way’ is probably the best.
• 1/2/4/8bpp modes have been tested. 16 and 24bpp modes haven’t, since it seems to be a bit hard to enter them without an MDF. Plus 16bpp modes would still be the wrong colour anyway.
• Multiple screen banks and scrolling seems to work as well (hardware scrolling isn’t feasible, but RISC OS looks like it’s already capable of coping with software scrolling)
• The hardware overlay for the mouse pointer works too. But if you try testing it yourself (e.g. using BASIC) just remember that you might have to define the pointer image first!
• The hardware has a second video overlay available, which supports YUV colourspace, which could be useful in the future for video playback. But if we want WIMP windows and other objects (apart from the mouse pointer) to obscure the overlay then it might take a bit of a rewrite of the current video code to get it working nicely due to the limitations of the OMAP overlay hardware.
• The code should be capable of programming the video hardware for arbitrary pixel rates, using the best available clock if no exact match is possible. This is a step up from all the Linux implementations I’ve seen which refuse to program pixel rates if the hardware isn’t capable of an exact match. The main reason for me including this feature is because many of RISC OS’s built in screen modes seem to use pixel rates that the beagleboard isn’t quite capable of producing. In reality the error seems to be fairly small, i.e. under 1kHz, so isn’t likely to cause any problems except for the most fussy of monitors, or for people wanting perfect VSync timing. Also the current code limits the maximum pixel rate to 65MHz, which is listed in the beagleboard reference manual as being the maximum frequency supported by the DVI framer chip. However I believe this limit is rather soft, and people have used pixel rates up to the OMAP maximum (86.5MHz) without any problems. So this limit will probably change in future.

Also after playing around with the BASIC assembler a bit, I think there’s a bug in the cache handling (particularly the IMB_Full cache op as used by OS_SyncrhoniseCodeAreas when BASIC reaches the end of an asembly block). Now that the video stuff is mostly out of the way I should have a fix for this in a day or two.

Now a picture please :D

Unfortunately the only thing I have to hand for taking pictures with is a far too cheap and crappy webcam. But I’m sure plenty of pictures will emerge from wakefield in a few days time :)

Just wanted to chip in and say I think the work you are doing is fantastic, if you guys succeed in porting RISC OS to existing hardware, particularly cheap netbooks, it’ll be the most important development for the platform since the collapse of Acorn. It’s very early days of course, but this is probably the thing which will actually grow the user base again.

All the very best

Garry

I’m not sure what I was smoking when I wrote those cache functions, but they should be fixed now. Certainly *cache off/on and BASIC assembler is working properly. Plus I gave the set/way/cache iteration code a run-through in a test app to make sure it runs through all the right combinations.

Today I started work on adding EHCI USB support (i.e. support for the USB host port on rev C beagleboards). I haven’t exactly done much yet (just set up the components file to build a ROM image containing the USB modules), but since it doesn’t look like there’s much coding needed it should only be a day or two before I’m in the debugging phase.

Once I’ve got EHCI working I should probably move on to adding USB OTG support so that owners of rev B boards don’t feel left out. That will probably take a lot longer to complete though, due to RISC OS’s lack of OTG support (and my lack of knowledge!)

Has anyone else been up to anything? Jan? Alex? Have you guys got your build environment set up now?

OK, I’ve added HAL support to the EHCI module, and the EHCI initialisation code to the HAL, and am into the debugging phase. Specifically, I’m currently stuck at one bug – the USB modules rely on PCI_RAMAlloc for some of their memory allocation. This is obviously a problem for the OMAP build because the PCI module isn’t in the ROM image.

What are people’s thoughts on a solution for this? Add a seperate SWI/module that provides PCI-like memory allocation? Add custom allocation code to the USB modules? (bad, since it will just result in more and more code duplication) Or include the PCI module in the OMAP ROM?

The reason for this is that the “production” versions of the USB stack have only ever been used on two chip families – the Iyonix, and a range of STB chips – both of which had PCI buses, and therefore the PCI Manager was present.

Obviously the problem you’ve hit is more general than just a PCI issue: how to efficiently allocate blocks of contiguous physical RAM for peripheral use. There are issues with fragmentation of the physical and logical address spaces to worry about – we already have to worry about the fact that the screen memory is allocated contiguously at the bottom of physical RAM, so the PCI manager uses the top end of physical RAM instead.

I think it’s still best to have one centralised allocator for this memory pool. One thing that occurs to me is that there might possibly be a future platform where both local and PCI devices need chunks of RAM allocating, so either (a) any new memory management module would need to be absent from all platforms that have a PCI bus and all drivers would have to try the PCI Manager SWI as well, or (b) we simply include a cut-down PCI Manager whose only function is to manage the pool.

I think I prefer (b) on grounds of simplicity. There is precedent in the form of the Portable module, which still provides the Portable_Idle SWI even on platforms where its battery management SWIs are not applicable. I would, however, suggest renaming the dynamic area from “PCI shared memory” in such build variants.

According to a comment in the PCI module source, the module should behave itself it it’s loaded on a machine without PCI. Of course in reality it currently crashes, but once it is working properly it’ll probably be a lot easier just to include the full PCI module in OMAP ROM builds than to add a second build config that strips out the ~4K of unwanted code.

Lots of stuff has happened to the code in CVS over the past day or two:

• The OMAP3 port is now using the new ‘CortexA8’ machine type, which means you no longer have to manually edit HdrSrc.hdr.Machine.Machine to get the kernel to use the right MMU code
• A load of extra modules, pretty much everything required for a full ROM build, have been added to the products file. This should help make sure that everyone’s working from the same module versions as they experiment with adding modules/code to the OMAP/Cortex port.
• USB EHCI support is now in CVS. The components file has been updated to build a ROM image with all the modules needed for USB keyboard, mouse and mass storage support (via SCSIFS/DOSFS – although presumably FileCore formatted devices should work, as formatted by !SCSIForm on RISC OS).
  • Obviously this USB support is only any good for owners of rev C beagleboards, but owners of rev B boards might find some of the extra modules included in the ROM useful.
  • Also, owners of rev C boards who want to use a USB keyboard, must make sure they disable DebugTerminal in Kernel.Hdr.Options to make sure RISC OS uses the keyboard buffer for input instead of the serial port.
  • If you’re using a USB cable to power your beagleboard, and the USB cable that’s powering the board is plugged into the same hub that the USB host port is connected to, then there will be a pause for a second or two during boot as RISC OS tries to communicate with the unresponsive USB OTG port. *usbdevices also won’t list the OTG port correctly (for me it shows as a duplicate of the entry for my hub). Presumably both of these problems will be fixed when/if someone writes a simple driver to allow the board to act as a USB gadget.

Sometime soon I’m hoping to build a ROM image that allows the desktop to be used. Although it’s unlikely to be a user-friendly experience, it will hopefully be useful for testing components until we have SD/NAND storage drivers available and are able to cleanly boot into the desktop.

After that I’ll move on to looking at adding USB OTG support – unless anyone wants to take that task from me ;)

Well done Jeff! Fantastic stuff, major step forward.

I did a CVS clone 2 days ago in an attempt to add modules that were missing from the scripted CVS grab and I see thats as current as mammoth soup.

Not that I’m complaining of course!

Jeffrey, Ben & co I have no idea most of the time what you guys are talking about, but I sure do like reading about it. It gets me pretty excited reading about all the changes and improvements that are being made to RISC OS.

Just remember to take a breath now and again.

Sterling work to everyone concerned.

• DebugTerminal is still turned on for the benefit of people without USB, so make sure you turn it off if you want to use the desktop
• ‘desktop’ at the CLI should be all that’s needed to enter the desktop. There is a pause of a few seconds before the desktop appears – I’m not sure why.
• USB insertion/removal detection seems a bit flakey; either that or my hub. I haven’t encountered any other USB problems yet.
• Remember that RISC OS uses paged scrolling, so if you’re in the command line and the screen fills with text it may appear that the machine has crashed, when in reality it’s just waiting for you to press shift. After only using the desktop for so long this is something that I’d forgotten! I’ve just checked and this does also affect people who are using the debug terminal, which will obviously be a problem for people with rev B boards – [edit] – is now fixed. Also I was getting confused during testing because paged scrolling gets temporarily enabled by *help, so sometimes scrolling would be paged, and sometimes it wouldn’t, seemingly irrespective of the VDU 14/15 state!
• Control-break and other forms of reset don’t work yet (probably the HAL debug code causing it to fail)
• After loading an MDF the display manager didn’t want to let me change into any other screen modes, I haven’t yet investigated why.
• Creating a RAM disc will cause an abort on data transfer from ADFSFiler. It’s an easy bug to fix (just make sure nfloppies is set to 0 if ADFS_Drives returns an error), but I’d rather work out how to convince the SCSIFiler to not rely on ADFSFiler for its templates, so that we can get rid of ADFSFiler from the ROM image completely.

Wow. That’s quite something. Fantastic work! :)

A million kudos points has been awarded to Jeffrey!

:)

Jeffrey, really well done. In response to your commend on Drobe about USB-LAN adapters: I don’t know if this will be of any use to you, but my EtherUSB module may save you some time.

It is written so that the module can support different backends, which only have to do the USB stuff. The rest of the module deals with all of the DCI and plugging/unplugging of USB devices. There is one backend at the moment, for an ASIX device, which should give an idea of how much work is required to add a new one.

It is stable and works OK but is unfinished, the DCI code is a ‘first cut’, but does the job. I’d be happy for it to go under the ROOL license if that helps.

http://homepage.ntlworld.com/j-peacock/download/etherusb.zip

Great work! Wow, it feels good to see some life in the cvs repository again (aside from the dribs and drabs we’ve done internally).

Ah, EtherUSB – I thought there was at least one USB ethernet driver for RISC OS around somewhere :)

That certainly looks like it would be useful, since I have no experience with writing DCI drivers (or USB drivers for that matter. Or any experience with porting drivers from Linux!) It would probably be a lot easier to examine the Linux drivers to see how my adaptor works and add support for it to EtherUSB than it would be for me to try and port the Linux driver to RISC OS as-is.

I don’t think there’s a requirement for the code to be licensed under the ROOL license – there are already a handful of modules in CVS and the ROM images that are under mixed licenses – but if you’re happy to place it under the ROOL license then I don’t think ROOL will complain about having a fully ROOL-licensed USB ethernet driver in their source tree. It might also help raise the modules profile a bit, since my earlier web searches for USB ethernet support on RISC OS didn’t find it!

If you post the product and vendor IDs of that USB-LAN device and I’ll have a look for some documentation and a suitable driver and see what is involved.

I don’t think there’s a requirement for the code to be licensed under the ROOL license

No, I don’t think so either. In fact, I would strongly discourage placing code units wholesale under the Castle License only, since it’s somewhat restrictive. If it’s appropriate and a standalone piece of code, then make it GPL or whatever as per some other stuff. Alternatively, dual license it to be CTL and whatever else. This ensures some degree of reusability. Bear in mind the possibility (even if it seems unlikely right now) that ROL might want to use it too.

In practice, probably most of what Jeffrey has done is extending existing CTL licenced code, so these comments would mostly not apply.

If you post the product and vendor IDs of that USB-LAN device and I’ll have a look for some documentation and a suitable driver and see what is involved.

Vendor ID 07A6, product ID 8515.

It’s handled by the Pegasus driver in linux (drivers/net/usb/pegasus.c), along with a load of other devices with the same or similar chipsets. So if support for those could be added to EtherUSB then we’d probably have USB networking support for the majority of cheap adaptors that are available (I basically just went for the cheapest thing on Amazon)

It also looks like the Linux ASIX driver supports lots of devices that are similar to the AX88172, so adding support for those shouldn’t be much trouble either.

I’ve ported network drivers from other platforms before (for my stalled A4 ethernet card project) If you can, I’d recommend porting from NetBSD not from Linux… their mbuf structure is more similar to RISC OS’ (after all, that’s where much of the internet stack was nicked from). It’s changed a bit in the time since the RISC OS code was taken, though. Linux used (in 2002) sk_bufs which are kind-of similar, but not similar enough to avoid having to do significant changes to the code.

However, at a basic level most drivers involve stuffing packets into device registers. So you’d just need to rewrite the bit that knows about the particular format of the packet being stuffed.

Maybe write a NetBSD or Linux layer to James’ DCI interface? And then you could plug in whichever NetBSD/Linux driver you wanted. (With some modifications, naturally). That was my attempt in the A4 code (http://www.markettos.org.uk/riscos/ethernet/ if you really must) but I never targeted more than one type of hardware.

3. Any modifications must be made publicly available, free of charge, in source and binary form.

That seems to imply I’m forced to provide a binary version of modifications. If such modifications mean it won’t compile, that means I’m in a rather tricky situation (especially for things like CVS repositories which distribute uncompiled code). Would you feel like amending the license to either be vanilla GPL or vanilla BSD, which have the effect I assume you’re aiming at? Generally licenses modified from the standard aren’t a good thing, because you have to employ a lawyer to be confident on how it may be applied.

Erm – not GPL, please. The Castle license and GPL don’t interact very well – which would be a problem for building a ROM!

Erm – not GPL, please. The Castle license and GPL don’t interact very well

Indeed, but read carefully what I said. GPL may be, and is already, appropriate for some RISC OS components (just look at the source). What I said was “GPL or similar” as a stand in for BSD/Apache/Others.

Certainly GPL interaction is a huge problem, although not insurmountable – as long as an independent module is GPL only, this should be ok legally. (IANAL, but do have lots of experience with this). And if not, again, dual licensing would definitely be ok.

Remember also that Linux drivers will be GPL, although as been pointed out, BSD drivers tend to be a technically better choice.

IMCO, CTL’s restrictive licensing gains nothing, and precludes much, such as wider take up of development, and adds confusing licensing by adding yet another variation, which is incompatible with both general OSS usage, and a considerable amount of code out there.

I know this is going to again fall on deaf ears, but I again urge CTL to put RO under a more open licence. They still retain ownership, and still have the option of licensing it to others under whatever license they want. It certainly doesn’t have to be GPL, in case people still think I’m implying that.

It is now under the standard three clause BSD license.

A bit of googling with the vendor and produce IDs suggests that the underlying chip is a ‘ADM8515X’, the datasheet appears to be available on line. The NetBSD driver is ‘sys/dev/usb/if_aue.c’, looks fairly readable.

The idea behind EtherUSB is that the core provides nice functions to handle all of the logging, callback, USB, MII, DCI, etc. The backend just has to sit in the middle and use those things. For the ASIX device, I found that the easiest way to do it was to work from the datasheet using the NetBSD source as a backup reference.

Thanks, James, for sorting that out.