Re: [PATCH] Probe Efika platform before CHRP.

Hi Syvain, Ben, and the others here on this list...

In the next 45-60 days we will offer new firmware for the EFIKA (and  
the Pegasos/ODW).  We will define a new hardware specification  
outside of CHRP.  In the meanwhile and afterwards, feel free to  
proceed as you determine best.  We appreciate the support we have  
received in the past and the effort made more recently on the EFIKA.

The long term objective for Genesi is to provide a low cost, low  
power, highly reliable computing platform that can be flexibly  
applied to many uses.  We hope to be selling the EFIKA at $99 by  
April (and sooner if possible).  The 5200B is to be followed by  
another SoC with integrated graphic support at the same price (for  
the SoC).  The new firmware will be inexorably linked to this new SoC  
in form and function.  The EFIKA is a development platform that  
targets the system we will offer with the new SoC.  We expect to be  
shipping the next version of the EFIKA before the end of 2007.  The  
first diagram shown in the link that follows (the second image is  
what we hope for after that):

http://bbrv.blogspot.com/2006/10/wanting-what-you-have.html

Thanks again.  Happy New Year. :)

Best regards,
R&B


On Jan 6, 2007, at 8:55 PM, Sylvain Munaut wrote:

quoted

quoted

What if NetBSD, FreeBSD, QNX and WindRiver disagree with you guys?

Note that the "compatible" modification we ask could simply be to add
the one
we require at the start of your compatible list, so linux will work  
and
the os using
the efika original will work as well.

quoted

quoted

Specifically for the "sound" and "ac97" discrepency, the "sound"  
device
type has some special implications for Open Firmware firmwares. It's
set to ac97 as it is NOT an OF or CHRP standard "sound" node and  
should
NOT be found as such in my personal opinion.

This "sound" <> "ac97" thing is not fixed in the patch I posted  
recently nor
in the nvramrc I sent to gentoo before that. The only visible thing  
was a
a small comment buried in a very experimental driver.
As soon as nicolas told me "sound" was the standard, I said OK so  
be it.

But for example the "memory" type you give to the SRAM node is imho
wrong. Because memory seems to be the standard type for "real" memory,
the one that's gonna be used for the system ...

quoted

There are two issues here:

I'd say you can even split a little more :

 * Compatible / Type of nodes :
   We need a naming schema that's coherent across nodes and will  
allow to
   support coherently different boards. Your naming scheme just  
doesn't
   provide that. The one proposed by Grant does. Now it's possible  
you can
   find even better and we're open to suggestion.

 * Missing bits :
  - The interrupts property of the ac97 node are just not there. This
interrupt
     exist, it's hw and you can't just decide the driver can do  
without
it ...

 * Bugs : I see three,
  -  The one dwmv2 mentionned
  -  I noticed the compatible properties had double \0 at the end  
instead
     of single ones.
  -  Incorrect init of the PSC2 for AC97 and in the tree since the  
"gpio"
     node is not present, the address for port config is not found  
in the
     device tree. The current work around is a ugly hardcoded stuff in
     the driver itself that will never be merged upstream.


Regards,

     Sylvain


PS: In the end, a long nvramrc will do the trick ... so I don't care
much for me,
I'll always know what I need to put in it.