[PATCH 00/10] Updated ML300 & ML403 patches

[David H. Lynch Jr.]

Grant Likely wrote:
> Let's keep this conversation on the mailing list.
> 
> Peter Ryser wrote:
> 
>>Hi Grant and Andrei,
>>
>>I'm glad to see some activity on the linuxppc email alias for the MLxxx 
>>boards and appreciate the work put into moving the 2.4 support to 2.6.
>>
>>I just tried to boot the 2.6 kernel with Grant's patches applied to 
>>Linus' latest tree on both the ML300 and the ML403 and in both cases end 
>>up with the PLB Error LED lit up. Both boards print the messages from 
>>the bootloader, print "Now booting the kernel" and then nothing (but the 
>>error LED). Anything you can think of that is going wrong?

	I am getting the same problem when I use Grant's patches. In my
instance I have isolated the problem to hanging in
ppc_sys_get_pdata(VIRTEX_UART).
This appears to be a fairly trivial routing, so my current assumption is
that I either have VIRTEX_UART defined improperly or I have the ppc_sys
data structure created wrong.


>>Anyway, there is another issue that I would like to bring up and it has 
>>to do with xparameters.h. The xparameters.h file, or more exactly, the 
>>xparameters_* file, is automatically generated by EDK and is then used 
>>to configure the devices in the Linux kernel at compile time. While I 
>>understand the desire to get away from a static device definition to 
>>device enumeration at run-time, the current set of patches is a step 
>>backwards for users from a useability point of view. Users will now have 
>>to modify xparameters*.h by hand which is an error-prone process. 
> 
> 
> Actually, users should *never* modifiy generated files.  The intent is 
> that board specific fixups go directly into the top level xparameters.h 
> so that newly generated files don't have to be touched.  But yes, I 
> understand what you mean.
> 
> 

	It would be really nice if the was either some comments in
xparameters.h or in the Documents directory explaining what the Linux
xparameters values are so that it it would be easy to know what items
from xparameters_xxx.h have to be mapped or redefined.



> This really isn't a big deal anyway; most of this discussion will become 
> moot in short order.  Sometime in the next few releases, linuxppc will 
> flip over to using a flattened device tree to pass device information 
> from the boot loader to the kernel.  xparameters will drop out of the 
> kernel proper entirely except for the edk-generated device drivers 
> (which is another issue entirely).  All the xparam stuff will be 
> extracted into a device tree by u-boot or the zImage wrapper.  The 
> kernel just won't care.  :)
	Where can we get more information on what is happening here ?
I started the E12 port with most info in xparameters, but I have been
moving towards getting things passed in board_info. I am not using
u-boot as the E12 has a general purpose elf loader, and it was easier to
add a fee lines for Linux. Regardless I would like to be compatible with
whatever is coming - maybe even ahead fo the curve. The e12 is just the
first of a family of products - the e14 already exists. There maybe
revisions of each at different speeds with different memory.