On Friday 28 March 2008 18:11, Scott Wood wrote:

Laurent Pinchart wrote:

quoted

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 ?

Maybe, but the end would be safer.  What's the problem with finding the 
end?

That requires manual parsing of all the cells in the reg property. The 
device-tree API doesn't provide a way to get the length of a property, so 
I'll have to use a big enough pre-allocated buffer. I'm also not sure if 
resources are guaranteed to be sorted in increasing order.

This doesn't make finding the end of the muram really difficult. I was just 
wondering if the increased code complexity was worth it, especially seeing 
how the cpm_serial code in the boot wrapper seem quite unstable.

I'm not familiar with the boot wrapper code so I'm sometimes not very 
confident in my assumptions, but isn't the handling of the virtual-reg 
property in cpm_console_init broken ?

        void *reg_virt[2];

	...

        n = getprop(devp, "virtual-reg", reg_virt, sizeof(reg_virt));
        if (n < (int)sizeof(reg_virt)) {
                for (n = 0; n < 2; n++) {
                        if (!dt_xlate_reg(devp, n, &reg_phys, NULL))
                                return -1;

                        reg_virt[n] = (void *)reg_phys;
                }
        }

        if (is_smc)
                smc = reg_virt[0];
        else
                scc = reg_virt[0];

        param = reg_virt[1];

If I'm not mistaken, getprop will return the address and size of the first 
resource and not the addresses of the first two resources. What is 
virtual-reg used for ? To report the virtual address without requiring a 
device tree walk ? Does it provide any information that dt_xlate_reg can't 
find ?

Even the end of the first reg resource would be OK. 

If I use the end of the first resource, can I assume it spans 0x0000 - 0x8000 
to set the default tx BD address in Kconfig ?

quoted

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 ?

Yes.

-- 
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