Let's get started with a Pandora port

I’ve just tried the passive ROM with the Touchbook script using AI’s MLO and u-boot. The Touchbook gives a blank/pulsating screen

That sounds like what I got when I first tried, but that SD card did not seem to boot at all – when I removed the RISC OS stuff from it then it wouldn’t boot the AI OS either! I’ve since created another SD card using the latest AI script and that seems happier.

but ironically the same SD card appears to boot on the Beagle

That’s interesting. I’m sure I read somewhere that the Beagleboard have more of the boot system flahed into the NAND on the chip, while the Touchbook has almost all of it on the SD card. Can anyone confirm this, and say what the implications for us might be?

I’m sure I read somewhere that the Beagleboard have more of the boot system flahed into the NAND on the chip, while the Touchbook has almost all of it on the SD card. Can anyone confirm this, and say what the implications for us might be?

The boot system is rather complex, since there are three bootloaders (the OMAP3 ROM, x-loader (the ‘mlo’ file), and u-boot), all of which can make different decisions about what device to load the next bootloader stage from. And of course things get more complicated when you realise that you can use custom versions of x-loader and u-boot that don’t follow the usual rules. So exactly what happens when you place an SD card containing x-loader, u-boot, a kernel and a filesystem into a beagleboard will vary depending on the setup. I think that recent-ish versions of x-loader will automatically load u-boot from an SD card if it exists, but I’m not sure whether that u-boot will use the settings stored in NAND or some default settings to decide what to do next (i.e. to load the kernel from NAND or from the SD card)

About the only thing I do know for certain is that if you boot a beagleboard with the user button held down it will invert the boot order that the ROM uses, causing x-loader to be loaded from the SD card instead of NAND (and then I think the boot sequence will continue to prefer the use of the SD card over anything in NAND). I’m not sure whether the touch book uses this ‘inverted’ behaviour by default (I’m assuming they would, otherwise if the copy of x-loader in NAND becomes corrupt you might not be able to do anything to repair it)

I have just built the latest source, and set my machine to call the correct entry point (Devkit). The ROM boots, but the USB system never seems to work. I looked through the new HAL code, and the Devkit structure has 255 as the USBGPIO. I changed this to 147, rebuilt and the ROM now seems to work. Is this used as an interupt pin ?

Also, what method would be best to try and add support for the inbuilt network controller. Normaly, OS_ClaimDeviceVector could be called to add an interupt routine. No claim method seems suitable, as its not on an expansion card nor is it a PCI device. I assume a new device number could be allocated.

The ROM boots, but the USB system never seems to work. I looked through the new HAL code, and the Devkit structure has 255 as the USBGPIO. I changed this to 147, rebuilt and the ROM now seems to work. Is this used as an interupt pin ?

It’s the pin that’s used to put the external USB PHY into/out of reset. I couldn’t find any documentation indicating which pin (if any) the DevKit used for that, so I just left it undefined. I’ll check in a change to make it use 147 like most of the other boards.

Also, what method would be best to try and add support for the inbuilt network controller. Normaly, OS_ClaimDeviceVector could be called to add an interupt routine. No claim method seems suitable, as its not on an expansion card nor is it a PCI device. I assume a new device number could be allocated.

All the device numbers in the OMAP3 port correspond to the IRQ/FIQ number used by the interrupt controller. Looking at the circuit diagram for the DevKit (see the DevKit8000.pdf that – I believe – gets shipped with the board), the interrupt line from the NIC is mapped to GPIO 25 on the OMAP. GPIO’s 0-31 are provided by the first GPIO controller, which uses the M_IRQ_29 interrupt line; i.e. RISC OS will see it as device 29. To get it to generate interrupts you’ll have to program the GPIO controller to treat GPIO 25 to be used as an interrupt pin (read through the relevant bit of the OMAP TRM – section 24.5.3.2 looks like the right place). Also note that the GPIO modules can generate interrupts for either the ARM core or the DSP core; the IRQENABLE1/IRQSTATUS1 registers are used for the ARM core while the IRQENABLE2/IRQSTATUS2 registers are used for the DSP.

Since the GPIO1 module may in future be used for receiving interrupts from more than one device, when calling OS_ClaimDeviceVector you’ll want to make sure that bit 31 of the device number is set to indicate that it’s a shared IRQ, and follow the appropriate behaviour (i.e. check the GPIO_IRQSTATUS1 register to make sure that it is pin 25 that’s the cause of the interrupt)

After claiming the vector you’ll also need to call HAL_IRQEnable to make sure the IRQ isn’t masked in the interrupt controller, and before you return from your interrupt routine (assuming the interrupt was from pin 25) you’ll have to call HAL_IRQClear (the IRQ controller in the OMAP needs to be explicitly told that an IRQ has been serviced before it will deassert the ARM IRQ line)

Thanks for the info Jeffry, I might have a go at doing something in assembler to see if I can make it work.

Some positive news frome me :-)

Jeffrey, Thanks for fixing the time and CMOS NVRAM issues on the Cortex A8 branch! Today i recompiled the ROM from the latest CVS and behold, the clock keeps running and tells correct time after a reboot! New issues of course were to be expected as the CMOS data now is really used. So i needed to reconfigure my keyboard using the configuration GUI. No big deal :-) Looking forward to being able to configure autoboot and saving the trouble of manually typing “scsi” and ”!boot” :-)

Again, Thanks!

Best regards, Jan Rinze.

CMOS NVRAM issues on the Cortex A8 branch!

I hate to break it to you, but that was for the IOMD HAL, not the OMAP one! The OMAP ROM should be the same as before – unless the fix for the kernel bug I found while working on the IOMD port has somehow broken the OMAP port. I guess I should check when I get home – I haven’t done a build in a few days, since I’ve been writing the framework for the new video driver.

The first version of the new video driver + related changes are now in CVS. Although the driver is far from complete, it provides the following improvements over the old HAL code:

• The screen tearing in high bandwidth modes has been fixed. All that was needed was for the proper FIFO settings to be used. The 57Hz 1280×1024 MDF from the video driver page now seems to be fully stable and usable (at 32bpp colour depth)
• Since I’ve fixed the screen tearing I’ve also increased the maximum pixel rate from 75MHz to 86.5MHz, which is the theoretical maximum the OMAP can provide (the 57Hz 1280×1024 MDF uses 86MHz). I may try increasing the limit further and see what happens.
• The ‘mouse cursor turns into a flickering second copy of the screen’ bug seems to be fixed. It looks like the bug is triggered whenever the hardware is unable to preload the FIFOs to the correct values before the start of the frame, and the workaround (as suggested in the TRM) is to reset the display controller. I need to do some more investigation to make sure that there’s no way to trigger the bug manually (I have a feeling it might trigger if the mouse is in a certain position – in which case the driver may get stuck in a loop of resetting the hardware)
• Hardware accelerated rectangle copies & fills are supported. Although it only provides decent support for 8, 16 or 32bpp modes, it will also attempt to provide acceleration in lower colour depth modes where possible, which Adrian’s original prototype code did not (e.g. byte aligned copies/fills in 1bpp modes). Further speed improvements may be possible in the future (e.g. of the right-to-left rectangle copy op, which is allegedly the slowest, although I haven’t done any profiling to verify that that’s the case with my code)
• Although there’s no display rotation/scaling yet, the code should limit itself to the correct mode timings when running on Pandoras or Touch Books – in essence it’s similar to how the old “passive video” code worked (or should have worked!)
• Debug builds of the module have working TV-out support, so I’m in a good position to work on the multi-head features of the new GraphicsV API.

Unfortunately, despite triggering it on many occasions, I’m so far unable to find a fix for the “no video on boot” bug. The code can detect that the video is broken (it manifests as a “synclost” interrupt, same as the flickering mouse bug), but the usual action of resetting the display controller doesn’t seem to fix it.

ROOL: Steve mentioned putting the u-boot scripts into CVS. After poking around for a bit, am I right in thinking that updating the autobuilder scripts to automatically put them in the ROM zip files is the right thing to do? If so, then although I could easily make the changes, I’m not sure if I have any way of testing the autobuilder on my machine to make sure it still works properly. Do I just need to run the RiscOS.Utilities.Autobuild.ABRelease.MkAuto script or is some other magic involved?

Hooray, can’t wait to check out a new auto built rom. Thank you for your great work!

. . . Something I’ve just spotted with regards to a Freescale i.MX515 port – although there’s no documentation publicly available like with the OMAP, they do have a fairly open looking developer’s program – http://projects.powerdeveloper.org/projects.php

For information, this article at element-14.com refers to iWave’s iW-RainboW-G8D SoM.

And this article at earthtimes.org refers to Digi’s ConnectCore Wi-i.MX51 SoM.

Minor update: I’ve just had a go at redoing the main status page to be more up-to-date, easier to read, and to list a load of little/not-so-little jobs that I/we want/need to get done. (The borders on the table are a bit ugly, but I couldn’t be bothered working out how to make them look good with this wiki!)

https://www.riscosopen.org/wiki/documentation/pages/Cortex-A8+port+status

That’s really useful – thanks Jeffrey. A quick ‘additional devices’ question… Does the OMAP3621 used in TI’s eBook development platform allow another potential piece of hardware? (linuxfordevices.com article for reference)

Edit: And the Sparrow Cortex-A9 devices?

This may be of interest regarding the ARM Cortex port: The extASM 2.00 assembler has just been released (as open source), and it includes all instructions in the latest ARM version, ARMv7 (as used in ARM Cortex A8 and A9), excluding the Thumbs instructions.

See the full announcement at the newsgroups

Excellent!

It must have taken you ages to add support for all the new instructions!

Hi Jeffrey.

Thanks. :)

Fortunately, there was some “method in the madness”: Say you have a group of 20 instructions, and for them it may be 4 or 5 major pieces of functionality, so that most of the work involves implementing those pieces, and once that is done, implementing the rest of the instructions in that group may involve variations in using those major pieces of functionality.

But, yes, it was quite a bit of work, and especially the “Advanced SIMD and VFP instructions” is a lot of instructions, with a lot of variability for each instruction…

Fortunately, by the time I started with this, ROOL’s Ben Avinson had recently completed updating the DecAOF disassembler to ARMv7, meaning I had something to test the assembler with, which was a great assistance.

Your (and ROOL’s) work on the BeagleBoard port was the direct inspiration for starting this work… :)

Also, if ROOL (or anybody) were to work on updating ObjAsm to ARMv7, as well, I know some about what they’ll be going through… :) If the work done on the extASM could help here, I don’t think there would be any licensing issues, on my part, at least, for that, but with extASM written in assembly, and ObjAsm written in C, I don’t know how practical that would be…

By the way, extASM turned out to have some 32-bit issues with its included modules, but I’ll correct that and upload an update tonight, which should then be completely 32-bit ready (I’ll run it through the ARMalyser, again, to see if there are any remaining issues).

A nice hardware news update for people.

• The BeagleBoard xM looks like it’s on track for release in the first week of June
• The Pandora is finally in production! (Although the first batch or two will just be for filling all the pre-orders, so there’s no telling how many weeks/months new customers will have to wait before they start accepting new orders)
• And finally, Always Innovating have been teasing a new product on their ordering page for the past couple of weeks. But no news on what it is and whether it will fix any of the big hardware issues that people have with their Touch Books.

Thanks for the update.

...Always Innovating have been teasing a new product…

They’ve also announced a (very) p/t vacancy in customer services . I find this encouraging, bearing in mind the not inconsiderable customer dissatisfaction – which may have led to them quitting things. This seems to demonstrate that such a decision isn’t on the agenda!

The BeagleBoard xM looks like it’s on track for release in the first week of June

Official details on beagleboard.org now available.

• And finally, Always Innovating have been teasing a new product on their ordering page for the past couple of weeks. But no news on what it is and whether it will fix any of the big hardware issues that people have with their Touch Books.

There’s now a current AI forum thread: If AI were to revise the Main board what should they change?

AI say the next Touch Book is "scheduled for release sometime in July."

Looks like that message confirms that they’ll be using the DM3730 as well. As I understand it the new AM/DM chips are designed to work with different power management ICs (in fact, seperate audio + power ICs instead of one combined one like previous OMAPs), so with any luck this new design will sort out all the battery charging issues.

For people waiting on Pandoras: It looks like they’ll start accepting orders for the 2nd batch soon. I got an email today asking me to place an order, but judging by the lack of announcement I don’t think they’ve opened up orders to the general public yet (I was on a waiting list for batch 2 since I asked about placing an order soon after the first batch started shipping). So if you’re interested, watch this space!

And finally, Always Innovating have been teasing a new product on their ordering page for the past couple of weeks. But no news on what it is and whether it will fix any of the big hardware issues that people have with their Touch Books.

From an email shared on the AI forum:

...The new Touch Book product launch should occur in September. The new Touch Book will have a new beagle board design, as well as other hardware and software upgrades.

...Pandoras: It looks like they’ll start accepting orders for the 2nd batch soon. I got an email today asking me to place an order…

I found some Pandora build info on this blog . It may possibly be of some use/interest.

Yes, I found my way to that blog a while ago. The main things of interest for porting RISC OS are the discussion on booting (we can just stick a ROM image + boot script onto an SD card), and the Pandora hacker’s manual (although IIRC that was first linked to from the forums)