Hello,

I do have a problem with kernel 2.6.24-rc8, efika.forth and the kernel patch, which comes with efika-dts-20071114.zip.

If I apply the patch for the kernel and execute the efika.forth script while booting, then my usb keyboard is not being recognised in linux. neither is a standart usb stick.

if I do not apply the patch for the kernel and also omit the efika.fort script, then everything is working - even the network works.

now my question is: does the kernel patch or the efika.forth script need adoption for kernel 2.6.24?

regards,

-markus

Efika.forth needs a tweak. Networking works because they approved Olaf's patch against my recommendation and against LinuxPPC development policy as dictated to us when we released the Efika. That is the situation.

_________________
Matt Sealey

thanks. will wait for it.

I hardly think that's fair. I don't have time to go into this right now. Why don't you check it out and fix it and submit the patch? Since it's quick, I will explain what to do;

The code that changed is in drivers/usb/usb-ohci.c - look for strings such as 'mpc5200' and you will see the compatibility property entry check has been changed. Simply make sure this property is in the list for efika.forth. You may also remove the
wrapper around the USB section, as I only put it there because this change was in flux at the time I released efika.forth.

I would also encourage using Grant Likely's latest (RFC) patch which wraps the entire Linux Efika Fixups inside some checks which mean it will not perform them if efika.forth is run. It has some work to go but I would like everybody to test it!

_________________
Matt Sealey

will do!

ok, after half an hour with this simple forth tutorial I begin to understand the forth programming language.

I even found the part that seems to cause this:
Relevant part in efika.forth is the following by the way (original efika.forth, no changes done yet):
.properties returns the following *before* efika.forth is being run (the original efika.forth):
and this after efika.forth is run:
I don't yet understand the s" word yet, so I don't see how efika.forth sets the compatible property.

Gimme some more reading in the howto and I should get it patched correctly.

-corsair

maybe this little fix?
will test now.

EDIT: No, it doesn't work. Let's take a closer look at the code in ohci-ppc-of.c...

Okay, two hints.

ohci-ppc-of.c has two parts which detect the controller. One is the main compatibility list at the bottom of the file.

"ohci-bigendian" or "ohci-be" is what you want to look for here.

Then there is the quirks list, which determines if the frame number quirk is needed. "mpc5200-ohci" is what is checked here.

So, the compatibility property should include both of those. In fact, I am fairly sure both of these are already in the compatibility property for the Efika anyway.

What has happened here is 2.6.24 has not included the work in the patchset that I intended to support;

http://patchwork.ozlabs.org/linuxppc/pa ... f&id=14380

The addition of the big-endian property or the rationalisation of ohci to usb-ohci (since FireWire also calls it's controllers ohci, it's confusing). Then there is the rationalisation of properties proposed by Jon Smirl (which I sort of agree with) so just in case we should include those, and of course Linux developers think the "device_type" property is an irrelevance these days, so we should duplicate the expected value in "compatible" just to make sure we are REALLY future proof.

I guess, the recommended property list would be:

usb-ohci, ohci-bigendian, ohci-be, mpc5200-ohci, mpc5200b-ohci, mpc5200-usb-ohci, mpc5200b-usb-ohci, fsl,mpc5200b-usb-ohci and fsl,mpc5200-usb-ohci.

And the big-endian property. That'll fix everything, including any future patches.
Best practise and non-moronic driver design should really be checking for "compatible" of usb-ohci, the "big-endian" property, and selecting the mpc5200 quirk based on a "model" property if present. However, Linux developers usually don't consider the greater ramifications of their choices beyond the scope of the patch they submit, and simply code what they like and what works for now, then patches are accepted without much review, boards are designed around these device trees and we are stuck with property lists that go on forever even though subsequent code audits reveal that the ideas were unsound.

This is what you get for playing the Linux game. Do you understand now why we do not release firmware updates too often? Things have to settle down or we run the risk of some patch we missed, or some decision by a developer 30 days after firmware release, breaking our Linux support.

As for the Forth query, s" is a synonym for " - it begins the definition of a string. I consider the single quote rather weird and makes the code less readable, so I use s" simply so that it is more evident that this is the start of a string.

_________________
Matt Sealey

Thanks for the explanation. I was kind of lost in the source... ;-)
yes, I begin to understand.

yes, your new usb bindings fixed the problem, Neko.

combine this efika.forth-20080127 with this efika_20080127.img ;-)

The amount of extraneous crap that's in it, of course it works, it's total overkill for the needs, but it'll never.. ever.. fail. Ever. It has every possible combination and a few nobody would be dumb enough to use :)
Works :)

The problem now is that there is probably a limitation on nvramrc size, and the efika.forth needs to be rationalised and squashed down to be loaded in effectively, so we're going to have to take a lot of it out and work out what it's REALLY after.

The only thing I'd change is this;
I had a change of heart about a new property, since it makes it a git to check for in Linux and makes Linux dependant on the functionality of the script and not the underlying firmware, I mean more than it really should. built-on is a better idea.. and I have a cuter way to display built-on in the version line etc. but I just didn't integrate that yet, but I will, with the CAN and I2C bus switch. Later this week..

_________________
Matt Sealey