Let's get started with a Pandora port

I’ve uploaded a couple of fixes into CVS to make the display manager not crash when you drag an MDF to its icon, and to increase the max pixel rate from 65MHz to 75MHz (any higher than that and you’re likely to see signal breakdown when dragging windows).

Since Alex Aitken and now Simon Wilson/ksattic are now looking at the video code, I’ve done a brain dump to a new wiki page which we can use to keep track of what state the video driver is in and who’s working on what. Now that the desktop is mostly stable and I can run my beagle at its monitors native resolution I’ll be moving onto other stuff (e.g. the USB OTG driver), so you two can feel free to fight amongst yourselves over who gets to fix my horrible code :)

The wiki page also contains a useful note (use *vidcbandwidthlimit to unlock higher colour depths in the higher-res modes) and a repository for beagle-friendly MDF entries, so even people who aren’t working on the video driver should take a look.

Also, for Simon and any other new joiners, don’t forget to check the main wiki page for instructions on how to set everything up.

Just got my BeagleBoard set up with all connections and have started looking at some Linux distros.

Your wikis are great, cheers. :) Sadly though, I am stuck at step 1 – I don’t have Norcroft. Is this not free yet? If not, is this the right item on iyonix.com: “26/32bit Acorn C/C++ development suite”?

It’s a shame that the PowerVR drivers are closed source. We have great OpenGL ES 1.1/2.0 drivers on our SnapDragon products at work, and the kernel component is open.

ROOL have now taken over the development and sales of the C compiler – you can buy it from here. I’ll update the wiki to point to that page.

Also, I suspect it’s a bit late for you, but I’ve just spotted that rev C3 boards are now available (which have a holder for an RTC backup battery): http://elinux.org/BeagleBoard#Revision_C3

I’ve recently started work on the USB OTG drivers. Unfortunately the only documentation I can find for the Mentor controller is the not very descriptive documentation in the OMAP TRM, and it looks like the only driver that’s available is Mentor’s own GPL one as used by Linux. So unless we feel like including a load of GPL code in the ROM image (or loading the USB OTG driver from a storage device) it looks like I’ll have to make most of it up as I go along. Which I’m hoping won’t actually be that tricky once I understand how USB works!

I’ve done a brain dump to a new wiki page which we can use to keep track of what state the video driver is in and who’s working on what.

There’s nothing on there about the S-Video output. Is that unrelated?

It is there – it’s just listed as TV-out. The OMAP can do both Composite and S-Video output, but the beagleboard only supports S-Video.

Ah, I missed that, thanks.

C/C++ suite has been ordered, and I’m guessing it’ll be 1-2 weeks before it gets here. In the meantime I have signed up for access to the TI OMAP GLES 1.1/2.0 drivers. I’m hoping at some point they will open source the kernel module, since they are working with Google and I know G’s policy is to not use binary DLKMs. If they don’t open source the kernel module, that makes it exceedingly tricky to get GLES working with RISC OS. I’m hoping 2D will be easier.

I’m very impressed with Ubuntu on the BeagleBoard! The Trendnet USB 10/100 ethernet adapter is recommended for that (and it’s only $25). I must have missed this, but what’s the state of ethernet support in this port?

I’m hoping at some point they will open source the kernel module, since they are working with Google and I know G’s policy is to not use binary DLKMs.

As I understand it the kernel module is open-source, but all the interesting bits are in PowerVR’s closed-source user space binary (see here)

I’m hoping 2D will be easier.

The easiest way of getting 2D acceleration will be to use the OMAP DMA controller – it should be able to speed up most/all of the current slow bits. In theory it can even be used for transparent sprite plotting (although it uses colour key transparency instead of a seperate mask, and scaling support would be pretty much impossible). Once I’ve finished the USB OTG drivers I was thinking of going on to look at all things DMA (the DMA manager module, DMA-ing the RAM clear during boot, DMA for GraphicsV_RenderOp/HAL_Video_RenderOp, SoundDMA, USB DMA, etc.) A few of those tasks would probably be inter-related, but I don’t think there’s any reason why anyone can’t start looking at DMA for 2D acceleration now (or any of the other bits if they feel so inclined!)

The Trendnet USB 10/100 ethernet adapter is recommended for that (and it’s only $25). I must have missed this, but what’s the state of ethernet support in this port?

At the moment there isn’t any support. However the current consensus is to expand and develop James Peacock’s EtherUSB driver to support whatever hardware we require (see here). Feel free to start work on that if you want to get ethernet working.

As I understand it the kernel module is open-source, but all the interesting bits are in PowerVR’s closed-source user space binary (see here)

I couldn’t find the SGX driver at kernel.org (tmlind’s tree), so perhaps it is supplied as a kernel patch in the drop I got from TI. I’d like to see how similar it is to the kernel module for my own “Adreno” GLES 2.0 accelerator.

Edit: the drop I got from TI only contains a binary-only DLKM. No sources. So… time to do some more research.

Hi,

I just have received a beagleboard rev C3 and would like to test any recent RiscOS 5 ROM. Preferably with a working desktop :-)

Any hints and tips on how to get started?

The wiki page contains what’s probably the best getting started guide at the moment – http://www.riscosopen.org/wiki/documentation/pages/Cortex-A8+port

From your post earlier on in the thread I remember you saying you wanted to get involved with the programming side; to do that you would need to have a RISC OS machine (real or emulated) to compile the OS source. The current code in CVS should provide you with a working desktop (although obviously still very rough round the edges).

However if you’re just looking to try out/test prebuilt ROM images then you might be out of luck – the one on ROOL’s download page is rather out of date, and although it would be easy for them to update it I don’t think there’s much you’d be able to tell us that we don’t already know unless you’re able to actually recompile and debug the code.

But, on the bright side, you’re the first one of us I know of with a rev C3 board, so if you get your hands on a backup battery you’ll be in the right position to test the RTC code once that’s implemented.

Too bad that gcc still can’t be used to compile the roms.. Somehow that would have facilitated building the ROM for me. So unless people have ROM for me to betatest I will not be able to test RiscOS.

Best regards,

Jan Rinze.

I’ve updated the ROM on our site. It’s not the head cvs revision but it’s close enough.

Thanks!

any howto’s on how to boot it using uBoot are welcome. Did not find any here yet.

Too bad that gcc still can’t be used to compile the ROMs.

Well, perhaps it’s more the case that no one has really tried, apart from isolated stuff that JMB and myself have tried. No doubt there’s lots of finicky bits in the code where there are assumptions about Norcroft and objasm features that asasm doesn’t yet support, but those are generally minor.

The real problem is actually (especially for cross compiling) putting together a cohesive build system, that can tie together all the different bits of RISC OS to make a ROM.

What I don’t really know is what the minimum set up components might be to generate a ROM. Something very cut down that would boot to a command line would be good, for any system. That would be a practical statarting point.

Peter, I agree. Other modules can easily be loaded from a disk or other medium and those often are platform agnostic..

regards, Jan Rinze.

I managed to boot the ROM from Steve but the USB keyboard does not work with this ROM. Have you guys been testing with Rev B boards only? my board is Rev C3 and has the ‘extra’ USB host connector.

Ok. just found out that the keyboard is connected through the serial port. somehow i believe that a USB keyboard should be preferred though. Nice to se the desktop on the beagleboard!

Hmm.. once i had the desktop running the keyboard also works! Ok.. very nice indeed! Now we need access to storage so it is possible to use a boot and test some software :-)

SCSI::0 works too !! an old 256 MB memorystick seems to be readable by RiscOS :-) how does one format SCSI::0 as Riscos format and use it as a boot device?

What I don’t really know is what the minimum set up components might be to generate a ROM. Something very cut down that would boot to a command line would be good, for any system. That would be a practical statarting point.

Take a look at the products & components file from the first OMAP3 ROM builds. They contain all that you need to get to a supervisor prompt. Note that there are no USB modules; in order to build the USB modules you’ve got to include a whole lot of other stuff (mainly toolbox related). So if you’re building for a USB platform and want to be able to test the ROM properly then you’ll want to enable DebugTerminal in Kernel.Hdr.Options so that it uses the serial port for IO instead.

http://www.riscosopen.org/viewer/view/Products/OMAP3Dev/modules?rev=1.3;content-type=text%2Fplain http://www.riscosopen.org/viewer/view/castle/RiscOS/BuildSys/Components/ROOL/OMAP3?rev=1.1;content-type=text%2Fplain

I managed to boot the ROM from Steve but the USB keyboard does not work with this ROM. Have you guys been testing with Rev B boards only? my board is Rev C3 and has the ‘extra’ USB host connector.

At the moment the RISC OS port only supports the USB host connector, so if the ROM build options have been set properly then your keyboard should work straight away. However since some people are using rev B boards, on which there’s no USB host port, the default ROM build options are to enable the serial terminal for IO (which unfortunately stops any other attached keyboard from working – or at least until you enter the desktop as you’ve discovered).

SCSI::0 works too !! an old 256 MB memorystick seems to be readable by RiscOS :-) how does one format SCSI::0 as Riscos format and use it as a boot device?

To format it for use by RISC OS you’d need a copy of !SCSIForm. Which unfortunately isn’t included in the current ROM image :)

Even if you could format it you’d have trouble booting from it – the current code lacks any code to load/save the CMOS RAM settings, so you won’t be able to configure the boot options and will have to boot manually. You’d also have to find a suitable !Boot structure to use – which is something which doesn’t exist at the moment. A while after getting the desktop working I did have a go at building !Boot using the ROOL sources, but the sources are incomplete (no RO510Hook directory, which will cause !Boot to complain and fail to boot on RO 5.10+), and after copying over the relevant bits from my Iyonix !Boot it was clear that it was trying to do some things which are unrequired on the beagleboard (e.g. attempting to softload the USB 2 modules)

And even if you did have a working !Boot, and started trying to run all your favourite RISC OS apps, you’d probably find that most won’t work because of changes to how the CPU deals with unaligned loads/stores (although a workaround for that is currently being developed).

Have I put you off enough yet? ;)

Not in the least way Jeffrey :-)

so. can anyone here help me to format scsi::0 and to try and get a !boot on it? I don’t have an Iyonix so i cannot format the drive under RiscOS. any help appreciated.

Do you have a Linux box? Or a Linux live CD? If so, try grabbing this 50MB HD image: http://b-em.bbcmicro.com/arculator/hdboot.zip Unzip, and write to your USB stick:

dd if=hd4.hdf of=/dev/sdb

dd if=/dev/zero of=hd4.hdf bs=1M count=250

Hi Theo,

I had tried that already but that does not work. I think that RPCemu has some different format or something.

I will retry some different methods. It be nice if someone would put a copy online of their empty disk as a file and zipped for convenience. That would also allow the comparison with the ones from RPCemu and find the differences.