All times are UTC-06:00




Post new topic  Reply to topic  [ 11 posts ] 
Author Message
PostPosted: Sun Jan 20, 2008 2:29 am 
Offline

Joined: Tue Feb 14, 2006 2:01 pm
Posts: 75
Location: Germany
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


Top
   
PostPosted: Sun Jan 20, 2008 3:03 am 
Offline
Site Admin

Joined: Fri Sep 24, 2004 1:39 am
Posts: 1589
Location: Austin, TX
Quote:
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


Top
   
 Post subject:
PostPosted: Sun Jan 20, 2008 6:07 am 
Offline

Joined: Tue Feb 14, 2006 2:01 pm
Posts: 75
Location: Germany
thanks. will wait for it.


Top
   
 Post subject:
PostPosted: Sun Jan 20, 2008 12:02 pm 
Offline
Site Admin

Joined: Fri Sep 24, 2004 1:39 am
Posts: 1589
Location: Austin, TX
Quote:
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
Code:
1 1 = if
..
then
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


Top
   
 Post subject:
PostPosted: Mon Jan 21, 2008 1:40 pm 
Offline

Joined: Tue Feb 14, 2006 2:01 pm
Posts: 75
Location: Germany
will do!


Top
   
 Post subject:
PostPosted: Wed Jan 23, 2008 1:01 pm 
Offline

Joined: Tue Feb 14, 2006 2:01 pm
Posts: 75
Location: Germany
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:
Code:
# diff -ruN linux-2.6.23.9/drivers/usb/host/ohci-ppc-of.c linux-2.6.24-rc8/drivers/usb/host/ohci-ppc-of.c
--- linux-2.6.23.9/drivers/usb/host/ohci-ppc-of.c 2007-12-06 10:02:14.719826262 +0100
+++ linux-2.6.24-rc8/drivers/usb/host/ohci-ppc-of.c 2008-01-23 18:43:45.121097551 +0100
@@ -134,12 +134,15 @@
}

ohci = hcd_to_ohci(hcd);
- if (is_bigendian)
+ if (is_bigendian) {
ohci->flags |= OHCI_QUIRK_BE_MMIO | OHCI_QUIRK_BE_DESC;
+ if (of_device_is_compatible(dn, "mpc5200-ohci"))
+ ohci->flags |= OHCI_QUIRK_FRAME_NO;
+ }

ohci_hcd_init(ohci);

- rv = usb_add_hcd(hcd, irq, 0);
+ rv = usb_add_hcd(hcd, irq, IRQF_DISABLED);
if (rv == 0)
return 0;
Relevant part in efika.forth is the following by the way (original efika.forth, no changes done yet):
Code:
\ New USB binding - change one of the numbers here to disable it for older kernels
\ as this is a destructive change
1 1 = if
s" /builtin/usb" find-device
s" usb-ohci" device-type
s" " encode-string s" big-endian" property

s" mpc5200-ohci" encode-string
s" mpc5200-usb-ohci" encode-string encode+
s" compatible" property
device-end
then
.properties returns the following *before* efika.forth is being run (the original efika.forth):
Code:
ok .properties
name "usb"
.description "MPC52xx USB 1.1/OHCI controller"
interrupts [0xC bytes]
[000] 00000002 00000006 00000003

reg F0001000:5C
model "mpc5200-ohci"
compatible [0x31 bytes]
[000] 6F686369 2D626967 656E6469 616E006F
[010] 6863692D 6265006D 70633532 30302D6F
[020] 68636900 6D706335 3230302D 75736200
[030] 00

device_type "usb"
#address-cells 0x1 (1)
#size-cells 0x0 (0)
and this after efika.forth is run:
Code:
ok .properties
name "usb"
.description "MPC52xx USB 1.1/OHCI controller"
interrupts [0xC bytes]
[000] 00000002 00000006 00000003

reg F0001000:5C
model "mpc5200-ohci"
compatible [0x1E bytes]
[000] 6D706335 3230302D 6F686369 006D7063
[010] 35323030 2D757362 2D6F6863 6900

device_type "usb-ohci"
#address-cells 0x1 (1)
#size-cells 0x0 (0)
big-endian ""
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


Top
   
 Post subject:
PostPosted: Wed Jan 23, 2008 1:05 pm 
Offline

Joined: Tue Feb 14, 2006 2:01 pm
Posts: 75
Location: Germany
maybe this little fix?
Code:
$ diff -ruN efika.forth-20071114 efika.forth-corsair
--- efika.forth-20071114 2007-11-14 16:30:18.000000000 +0100
+++ efika.forth-corsair 2008-01-23 20:27:21.487348076 +0100
@@ -98,7 +98,7 @@
\ as this is a destructive change
1 1 = if
s" /builtin/usb" find-device
- s" usb-ohci" device-type
+ s" mpc5200-ohci" device-type
s" " encode-string s" big-endian" property

s" mpc5200-ohci" encode-string
will test now.

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


Top
   
 Post subject:
PostPosted: Fri Jan 25, 2008 10:40 am 
Offline
Site Admin

Joined: Fri Sep 24, 2004 1:39 am
Posts: 1589
Location: Austin, TX
Quote:
maybe this little fix?
Code:
$ diff -ruN efika.forth-20071114 efika.forth-corsair
--- efika.forth-20071114 2007-11-14 16:30:18.000000000 +0100
+++ efika.forth-corsair 2008-01-23 20:27:21.487348076 +0100
@@ -98,7 +98,7 @@
\ as this is a destructive change
1 1 = if
s" /builtin/usb" find-device
- s" usb-ohci" device-type
+ s" mpc5200-ohci" device-type
s" " encode-string s" big-endian" property

s" mpc5200-ohci" encode-string
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.
Code:
\ New USB binding
s" /builtin/usb" find-device
s" usb-ohci" device-type
s" " encode-string s" big-endian" property
s" fsl,mpc5200b" s" model" property
\ may I just say that Linux really, really sucks?
s" mpc5200-ohci" encode-string
s" mpc5200-usb-ohci" encode-string encode+
s" usb-ohci" encode-string encode+
s" ohci-bigendian" encode-string encode+
s" ohci-be" encode-string encode+
s" mpc5200-ohci" encode-string encode+
s" mpc5200b-ohci" encode-string encode+
s" mpc5200-usb-ohci" encode-string encode+
s" mpc5200b-usb-ohci" encode-string encode+
s" fsl,mpc5200b-usb-ohci" encode-string encode+
s" fsl,mpc5200b-usb-ohci" encode-string encode+
s" compatible" property
device-end
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


Top
   
 Post subject:
PostPosted: Sat Jan 26, 2008 1:49 am 
Offline

Joined: Tue Feb 14, 2006 2:01 pm
Posts: 75
Location: Germany
Thanks for the explanation. I was kind of lost in the source... ;-)
Quote:
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.
yes, I begin to understand.


Top
   
 Post subject:
PostPosted: Sun Jan 27, 2008 8:40 am 
Offline

Joined: Tue Feb 14, 2006 2:01 pm
Posts: 75
Location: Germany
yes, your new usb bindings fixed the problem, Neko.

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


Top
   
 Post subject:
PostPosted: Mon Jan 28, 2008 9:03 pm 
Offline
Site Admin

Joined: Fri Sep 24, 2004 1:39 am
Posts: 1589
Location: Austin, TX
Quote:
yes, your new usb bindings fixed the problem, Neko.
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 :)
Quote:
combine this efika.forth-20080127 with this efika_20080127.img ;-)
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;
Code:
." Efika 5200B Device Tree Supplement 20080128" cr
." (c) 2007-2008 Genesi USA, Inc." cr
." http://www.powerdeveloper.org/ for support" cr cr

\ headerless

s" /openprom" find-device
d# 20080128 encode-int s" built-on" property
device-end
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


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 11 posts ] 

All times are UTC-06:00


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
PowerDeveloper.org: Copyright © 2004-2012, Genesi USA, Inc. The Power Architecture and Power.org wordmarks and the Power and Power.org logos and related marks are trademarks and service marks licensed by Power.org.
All other names and trademarks used are property of their respective owners. Privacy Policy
Powered by phpBB® Forum Software © phpBB Group