[OpenBIOS] usb driver to support usb keyboard

[Mark Cave-Ayland]

On 03/05/14 10:56, BALATON Zoltan wrote:

> On Fri, 3 May 2014, Tarl Neustaedter wrote:
>> I'm not volunteering to do the work (lest I hear my boss scream in
>> agony), but I suspect this is a case that it just drops in and works.
>> Lillian wrote it for the OneLaptop project, and I understand that
>> implementation and OpenBios haven't diverged all that much.
>
> Problem is I don't know where to drop it to try if it works and if it
> doesn't I don't know how to debug Forth so I could only shoot in the
> dark. I don't even know where to start with this Forth driver.

Sadly the PCI code in OpenBIOS is still written in C so there would be 
some interface work required there.

In terms of testing the code, Forth is an interpreted language so you 
can literally copy/paste from the source files into a serial console and 
see what happens ;)  I suspect that the reality will be slightly 
different though, for example we know that OpenFirmware has behaviours 
which aren't implemented in OpenBIOS.

I should also point out that given that the original OpenFirmware was 
written almost completely in Forth, a lot of the semantics are so 
tightly tied in that it would make sense to start looking at bits of 
Forth as you come across them, and even better you can use the Forth 
debugger (see README.debugger) to step through words one at a time.

 From the time I've spent working on OpenBIOS, I would say that the 2 
things that have cost me the most time have been excessive use of C and 
premature forking of individual architectures. Historically OpenBIOS has 
a lot of C drivers borrowed from other projects which is great for 
getting something going but causes more headaches further down the line. 
Maybe the original aim was to convert the C drivers over to Forth as 
time allows? I don't know as that was prior to my involvement in the 
project.

As an example, last summer I ended up rewriting the majority of the 
display layer and I would say that most of the bugs were caused by C 
structs and Forth structs not being in sync, plus there was massive code 
duplication between C and Forth. Currently the C code uses pointers into 
the Forth dictionary where required so that the values are always 
consistent, and now C is only used for low-level primitives e.g. 
blitting that can be used across all architectures.

Similarly I spent time creating the common libopenbios since there was a 
lot of code duplicated between PPC, SPARC32 and SPARC64 which required 
multiple fixes and testing for minor fixes. But to go back to my 
original point: the more cross architecture work we do, the less 
maintenance is required and all architectures get bugfixes for free. And 
if we need cross architecture, then Forth is a better choice since it 
provides the greatest compatibility with clients and the IEEE1275 
specification, and you get to debug and develop live systems 
step-by-step without having to rebuild/redeploy.


ATB,

Mark.