I've updated the generator based on the below feedback. I'll also send around the updated patch for this section briefly. Comments below.
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Grant Likely > Sent: Monday, December 17, 2007 7:20 AM > To: Stephen Neuendorffer > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; linuxppc- > [EMAIL PROTECTED]; David Gibson > Subject: Re: [PATCH 7/7] [POWERPC] Xilinx: Update booting-without-of. > > > - (name)@(base-address) { > > + (name): (ip-core-name)@(base-address) { > > (name): (generic-name)@(base-address) { In most cases it now does this. In the default case for ip which is not recognized, it falls back to the ip-core-name. > > - [EMAIL PROTECTED] { > > + opb_ps2_dual_ref_0: [EMAIL PROTECTED] { > > + #address-cells = <1>; > > + #size-cells = <1>; > > + compatible = "xlnx,compound"; > > ranges = <0 a9000000 2000>; > > // If this device had extra parameters, then they would > > // go here. > > - [EMAIL PROTECTED] { > > + [EMAIL PROTECTED] { > > According to the generic names recommendation, this should be either > "[EMAIL PROTECTED]" or "[EMAIL PROTECTED]", but of course the two interfaces > are > identical and EDK doesn't have any information about how they are > used. Perhaps the node name should be: "[EMAIL PROTECTED]". David, thoughts? I don't think keyboard or mouse really makes sense here. Went with ps2. > > - plb-v34-0 { > > + plb_v34 { > > Steve, when I wrote this I was lazy and I didn't add the bus address. > However, if we don't have the base address I think we'll end up with > name collisions (especially in the MPMC case). So, based on generic > names convention, this should probably simply be "plb@<baseaddr>". I wondered at one point if this would be a problem... in any event, you now get the baseaddress. > > #address-cells = <1>; > > #size-cells = <1>; > > + compatible = "xlnx,plb-v34-1.02.a"; > > device_type = "ibm,plb"; > > ranges; // 1:1 translation > > > > - [EMAIL PROTECTED] { > > + plb_bram_if_cntrl_0: [EMAIL PROTECTED] { > > Node name should probably just be "[EMAIL PROTECTED]" here. What actually gets generated is a memory node at the toplevel, which is currently suppressed, since it appears that having disjoint memory locations doesn't work. If you have more than one 'real' memory controller, such as an plb_emc connected to flash, then you currently get the warning: "Warning!: More than one memory found. Note that most platforms don't support non-contiguous memory maps!" So, there is some divergence here, but I'm not too concerned about it since the way that such memory might get used is still up for discussion. Also note that memory nodes which are not at the toplevel don't appear to be detected. Is this by intention or omission? Obviously there is room for improvement here. Having a some way to leverage brams, in particular the dummy bram that you have to have at high memory in order to get the ppc to boot would be nice! Steve _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
