April 28, 2008

Status update - USB on Sam440

I have thought that fixing OHCI driver for endianess will be painful, since the OHCI chip works internally only in LittleEndian mode. Fixing it was like a fight with armor in form of preprocessor macros... But one day the war was over. The USB chip was, at least in theory, expected to work flawlessly.

It was not.

I have plugged the USB mouse and watched the debug. Wooha! OHCI root hub detected the change on one of it's ports. Great! The base USB class wanted to get on of mouse' descriptors, but it failed. It turned out that a local copy of transfer descriptor was in the data cache of CPU. Well, whatever. It may happen since AMCC440 does not maintain cache coherency. So, I did proper CacheClearE() and continued....

Two days later I was still fighting... Everything should work perfectly. The USB mouse got configured, my USB HID class knew what device it is. It was even able to parse the incoming reports. But there were none. Why oh why there are no reports from mouse???

Well, due to one mistake the OHCI chip was told that it should commit 0% (zero) for periodic transfers. Once fixed, USB mouse started to work. USB Stack is as usable as on a x86 architecture: USB - mice, keyboards, tablets and hubs are supposed to work. Additionally, I have fixed all cache issues in USB stack and enabled copy-back caching again.

You may see the PCITool app on sam440 - one of the very first programs I've started as soon as I could move the mouse pointer. Other Sam440 and AROS related screenshots may be found here.

I'm going to test AROS a bit this evening. As soon as everything will work as expected I will attempt to write the network driver for samantha.

Labels: ,

April 21, 2008

Small status update

Hello there.

If you were wondering where the hell am I, here's the answer. My son, Oliver, was in a hospital recently. Twice within a month, once with nephritis, once with pneumonia. I have shared all my time between work, taking care of my daughters and visiting Oliver. There was very few time for AROS.

It does not mean that I did nothing, though. First of all I have been trying to make our ata.device work with Sam440's SiL3114 SATA chip. With a significant help of Tomasz Wiszkowski I made it work on Sam! There were few issues which were not ever seen on x86 architecture. I have had to implement cache flushing in exec.library (finally! I should have done it before ;)), I have added some endian swapping code and had to flush data cache after the setup of PRD entries for DMA transfer.

The next step was radeon.hidd. It simply wasn't working as expected. Initialization of any screen mode put my monitor into sleep mode. Not good. I had to add proper timing function to the driver (previously it used busy loops for all kinds of delays), then I have embedded a real BIOS into the sam440 variant of this driver - still no luck with displaying. I have added i2c support to the driver and now it even uses DDC bus and EDID information of the connected monitor. Still no luck. Finally, I have synced the video mode restore in my driver with xorg repository. That helped. It seems that the PLL setting on radeon is awfully fragile.

Having SATA and Radeon chips working, I have decided to give AROS a try. I have burned it on CD and booted on SAM. Ouch. Program exception. It turned out that I have had an outdated version of ELF LoadSeg, which was not flushing any caches. Another try brought me a bit further, but AROS hung on the following lines in startup-sequence:

    List ENV:SYS/Packages NOHEAD FILES TO T:P LFORMAT="If EXISTS $SYS/Packages/%s*NCD $SYS/Packages/%s*NIf EXISTS S/Package-Startup*NExecute S/Package-Startup*NEndif*NEndif*N"
    Execute T:P
    Delete T:P QUIET
    CD SYS:

Out of curiosity, I have deleted the SYS:Prefs/env-archive/SYS/Packages directory and tried once more. Moooo! Success. The wanderer screen showed up as you may see on the screenshot. BTW. Photographing display sucks. :-) I will investigate the issue with startup-sequence a bit later. Right now it's a bit to early for it.

Now I gave the OHCI driver a look. The code assumed to some degree that it works on little endian machines. Moreover, it did assumed, that the processor uses very nice feature called cache snooping, which is the case on x86 family of CPU's. Cache snooping means, that the CPU watches all transactions on the bus, and thus keeps it's all caches up to date. Since it is not the case on sam440, the OHCI code needs to be reorganized a bit - it requires tons of CacheClearE() calls and few CachePreDMA/CachePostDMA pairs. At the moment all caches on Sam440 are working in write-through modus and will stay so until I fix all cache-irrelevant issues in the USB stack. I hope to have the whole stack working within few weeks.

In the mean time, I have helped Kalamatee with ACPI code a bit. Together we have made all CPU's in x86_64 SMP system booting. At the very moment all Application Processors are switched into 64bit mode of operation and then put to sleep.