RISC OS on IGEPv2

Nice.

Jeffrey, is there a machine serial or other UID on the OMAP34 machines? and if so is there a way I could get it via the HAL? I’d like to be able to generate a mac address thats machine unique but not different at every boot?

Yes, there’s the HAL_MachineID call. That returns a 64bit int, so if you’re calling it via the OS_Hardware SWI then it’ll be returned in R0 & R1.

At the moment the implementation in the OMAP HAL just returns the bottom 64 bits of the 128bit CONTROL_DIE_ID register, so I’m not sure how unique the value is in practice. Also it doesn’t place a CRC in the top 8 bits like the HAL spec says it should, which basically means that OS_ReadSysInfo 5 will ignore the value and return 0. (Some day I’ll get round to fixing the HAL so that the HAL dictates the size, format and validity of the machine ID, not the OS!)

Lovely,

I’ve managed to do quite a bit of refactoring today. I stripped out the last of the USB code and have taken out all of my GPMC hardware bashing stuff. With a little more tidying this could be a reference driver or for people wanting an example of using the HAL to get hardware base addresses and irq handling etc.

Its all pretty reliable now. I guess its obvious why its been unstable in hindsight. Oh well.

I’m curious about the Devkit stuff. I’d like to try writing the NIC driver for that. Where’s the best place to get them and how much are the boards?

I may do the wireless for IGEP next. If there is interest?

Does anyone know what the full list of NICs that appear on OMAP based boards is? I wonder if a standard module that has drivers for all the onboard NICs would be a plan. I had a look at the DM9000 and i believe if i had access to the board for a couple of days i could get the driver working in riscos.

I may do the wireless for IGEP next. If there is interest?

I don’t even own an IGEP, but I’m certainly interested in RISC OS getting wifi support.

Does anyone know what the full list of NICs that appear on OMAP based boards is? I wonder if a standard module that has drivers for all the onboard NICs would be a plan. I had a look at the DM9000 and i believe if i had access to the board for a couple of days i could get the driver working in riscos.

I don’t think there’s a full list anywhere. From looking at u-boot, it looks like TI’s OMAP3 EVM board uses the same NIC as the IGEP. For other boards it’s probably an idea to check the list on the elinux wiki. Also not all boards use memory-mapped NIC chips – the Zippy and Zippy2 are expansion boards that use SPI to talk to the NIC, so you’d need an SPI driver if you wanted to cover those, whereas the BeagleBoard-xM uses a USB hub + LAN combo chip, so will be something for EtherUSB to cover.

Aye anything USB i’d let EtherUSB cover.

I have a version of the driver ready that should work on any hardware that the HAL can pass the io address base to as Jeffrey described. Be nice if someone with the TI Eval board could get in touch so i could give them a module to test.

It would be nice if beagle owners could try the module to make sure it doesnt crash on the “device not found” codepath.

Non memory mapped NIC chips arent an issue although if they are “hot plugable” im going to let EtherUSB or another driver deal with them. My refactored driver model assumes that the HAL will be able to identify the presence and address on a channel of communication to a particular card. Mostly i just need to be able to test.

In the meantime, Jeffrey, could you add code to the HAL to identify the GPMC or otherwise the base address of the IGEPs wireless hardware?

The biggest issue with the wireless is uploading the firmware. Im guessing that this is something we might want to look at putting in the HAL?

Be nice if someone with the TI Eval board could get in touch so i could give them a module to test.

I don’t think anyone here owns one, and I haven’t set up the HAL to support it either. I suppose it might work with the IGEP configuration with a bit of luck!

In the meantime, Jeffrey, could you add code to the HAL to identify the GPMC or otherwise the base address of the IGEPs wireless hardware?

It looks like the IGEP wifi chip is connected to the OMAP via the MMC2 controller, and that they talk to each other using SDIO. It also looks like a few other bits need doing in order to get wifi working (see this patch – a couple of GPIOs are needed, as well as some fiddling with a voltage regulator), so it might be easier for you to work through everything yourself, especially since you’ll need to get very familiar with the MMC controller in order to get an SDIO driver working. Once you’ve worked out what code does/doesn’t need to go in the HAL I can easily submit it to CVS.

Jeffrey,

is there anything in the IGEPv2 Linux board setup (http://lxr.free-electrons.com/source/arch/arm/mach-omap2/board-igep0020.c ) that could potentially fix the problem we see with the screen?

Yes! It looks like they configure the VPLL2 voltage regulator in the TWL to generate power for something DVI related (presumably the framer chip). If that voltage regulator isn’t set right on boot then it could easily explain why the display issues seem to be heat related (and why the OMAP is seemingly unaware of the problems, since it’s got no way of getting feedback from the DVI framer).

That VPLL2 voltage regulator (along with the ones needed for MMC) should be pretty similar to the ones that I’ve already had to program for the CPU frequency utility. So when I get home tonight I should be able to knock up a quick BASIC program for you to try out.

I probably would have found that code ages ago if ISEE had made it easier to find their kernel source when I first went looking for it :(

I won’t be in until close to 8pm tonight but if you email me a basic file or post a link here I can try it.

Ok Jeffrey, on standby to try “destructo test”(tm). Also on IRC if you want to catch me there.

So the experiment didnt work. Seems the IGEPs VPLL2 is setup correct.

One thing i did notice is that the igep board config is modified from mach-omap2/board-generic.c, perhaps a diff between the two would show what the ISEE boys have added more clearly?

One thing i did notice is that the igep board config is modified from mach-omap2/board-generic.c, perhaps a diff between the two would show what the ISEE boys have added more clearly?

The beagleboard or EVM one might be a better choice; I think the generic board is a bit too generic.

I’m in the process of registering with the IGEP site so I can download their board schematics. I’ll check them against the beagleboard schematics, and what RISC OS currently does/expects, to make sure that everything’s OK. If I can’t spot anything wrong then I’ll probably move onto the plan of porting the Linux display driver to RISC OS and then see what happens.

If you want to do some investigation yourself then you could try getting a dump of the TWL/TPS registers, from within both Linux and RISC OS. We can then check the two to see if there’s anything obviously wrong (although the only thing that’s likely to affect the video would be the voltage regulators, which we’re now fairly certain that u-boot handles for us). The code I use to do this in RISC OS is here

There’s also an interesting register I spotted in the OMAP TRM, the CONTROL_DSS_DPLL_SPREADING register in the system control module. If you can get a dump of that register (and/or any other insteresting ones you spot) then that could be useful.

Hmm, the only thing ISEE provide a schematic for (apart from the little snippets in the HW manual) is the LCD connector. Not much to go by from that :(

No instances of CONTROL_DSS_DPLL_SPREADING in the kernel sources i have for the IGEP.

I’ll need to just write a C program to collect all the data on both linux and riscos and dump them into files that can be diff’d

One more thing: When you’re doing the register dumps, make sure you do a full power cycle when switching from RISC OS to Linunx and vice/versa. Not all of the hardware registers get reset when you press the reset button (or at least that’s the case with the reset button on the beagleboard).

Another way to rule out one-off fixes that the Linux kernel does at boot is to try booting RISC OS from within Linux using kexec – although I haven’t tried that on my beagleboard so I’ve got no idea whether it works with the current ROM image. If you try it yourself, make sure you use the ”-e 0×81000064” parameter with mkimage, as I explain in my post further down the page.

I think the “passive video” build switch in the HAL still works, so if kexec works you could try enabling the passive video driver and see if there are any display problems (although I suspect kexec shuts down the display driver before starting the new kernel, so that’s unlikely to work)

There isnt a reset button on the IGEP so not a problem.

I’ll give this a go later tonight. If i still see the issue after doing this then it means that either.

1. Its the display driver. 2. Its the smartreflex (less and less likely) 3. We are setting a register either to a value we shouldnt or one that should not be set at all.

when i try to kexec -l my uImage.bin (or even a copy of my running kernel) i get

unsupported machine type: armv71

tried it via poky… didnt work. Machine just hangs and nothing is printed on the debug console.

For anyone still following this thread. I’m awaiting the SWI base number from RiscOS and then i’ll be releasing “EtherGEP” properly as soon as i have those codes. The driver seems very stable and usable now.

For anyone still following this thread…

There must be quite a few of us who are following your efforts with interest.

...be releasing “EtherGEP”...

Great stuff – this is bound to be very welcome :-)

Any updates? You’ve got the SWI number… :)

Update due this weekend.

Jeffrey, How you getting on with graphics drivers etc?

I haven’t had a chance to look at it yet; hopefully I’ll be able to find some time next week.