Re: [PATCHv2 2/3] ep8248e: Reference SMC parameter RAM base in the device tree.

[Laurent Pinchart <laurentp@cse-semaphore.com>]

[-- Attachment #1: Type: text/plain, Size: 1693 bytes --]

On Thursday 27 March 2008 16:39, Scott Wood wrote:
> On Thu, Mar 27, 2008 at 10:10:33AM +0100, Laurent Pinchart wrote:
> > On Wednesday 26 March 2008 17:59, Scott Wood wrote:
> > > This breaks the bootwrapper console.
> > 
> > And of course I forgot about that :-)
> > 
> > The boot wrapper code doesn't have any dpram allocator. Any objection
> > against using a chunk of dpram at a fixed location ? What about at the
> > beginning of the dpram ? The DTS muram node would then exclude a chunk of
> > dpram at offset 0x0000 instead of 0x1100.
> 
> I'm not entirely comfortable with using a chunk outside of what's in the
> muram node, and assuming that it's for the SMC pram -- what if there's
> microcode or something there?
> 
> Since udbg is only for debugging, and is marked as potentially dangerous,
> how about just using the end of muram (as described in the device tree)? 
> If the muram is fully allocated, it won't happen until after the real
> serial console is initialized.

Locating the end of the muram isn't as straightforward as it could be. As the 
current code already uses the beginning of the muram to store the BDs and 
data buffers, should I really bother locating the end or can I store the SMC 
parameter ram at the beginning as well ?

If I'm not mistaken, once the SMC parameter ram gets relocated to the 
beginning/end of the muram, the boot loader preallocated space can be 
reclaimed and can be added to the muram in the device tree like I did in my 
previous patch. Is that correct ?

-- 
Laurent Pinchart
CSE Semaphore Belgium

Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]