It has been a while since I have posted last time but don't worry. I am alive and working. I have had a long battle with our FAT filesystem on AROS as it seems to be the very reason of quite strange behavior of big-endian AROS, at least on ARM. First of all, our FAT deals badly with write protected media. When running on RasPi with read only SD card this filesystem goes really mad and, for example, partially allows to write files. It does this by creating the entries in the cache and refuses to delete/open such "created" files later on. Further, it somehow fails to e.g. copy all files form ENVARC: (on FAT partition) to ENV: (in RAM disk) during boot, which results in lack of preferences.
The screenshot you see above is most likely a consequence of this. Here, the Trident (USB preferences app) crashes on startup during an attempt to read settings from the hard drive.
I will try to debug this issues ASAP, because otherwise it would not make any sense to release beta image for you. I mean, I can do that, sure, but you would be rather surprised seeing even simple things crashing. Such image would be rather contra productive and could be regarded as quite bad advertisement. If it cannot be fixed, then I will prepare demo image using some other filesystem, maybe AFFS or SFS?
On the USB front I have nice progress and regression at the same time. I have removed the busy loops from control transfers, which has very positive impact on responsibility of AROS. Until now I was using interrupts only at the last stage of an USB control transfer, with all previous ones waiting in a tight CPU loop. Not good, but this way I was able to mimic a real non-OTG USB controller, where I would set up entire transfer in a chain of descriptors and would just let it go. This is a song of the past now. When control transfer is issued, the first packet is set up and the rest follows automatically being driven by subsequent interrupts. This gives a nice boost because control transfer on OTG may consists of following steps:
1. Send SETUP packet,
2. Send or receive DATA packet(s) (if any),
3. Receive or send ACK packet.
Not so complicated, only three interrupts, where 2 and 3 are issued from interrupt handler. But look what happens when communicating with USB1.1 device:
1. Send SETUP packet as Start-Split transaction,
2. When ACK received from hub, send Complete-Split.
3. Send or receive DATA packet as Start-Split transaction,
4. For each DATA packet issue Complete-Split before proceeding to next DATA,
5. Receive or send ACK packet as Start-Split transaction,
6. Finish ACK by issuing Complete-Split.
Having done this in one function, with busy waiting, was quick and dirty, but interrupt driven solution is definitely better. By the way, the same interrupt mechanism is used for bulk transfers.
Although it is now, in principle better, it got worse at the same time. For some reason the USB 1.1 low sped mode compliant devices, such as my USB mouse, refused to work properly now. They seem to work at very beginning, but at some point, the control transfers end with STALL error.
Well, I guess I will just look how others did it :-D Most likely it's just a stupid mistake on my side. Should be fixed very soon.