[U-Boot] [PATCH] 85xx: Fix mapping of 0xfffffxxx when CONFIG_MP

[Kumar Gala]

On Jul 22, 2009, at 10:47 AM, Peter Tyser wrote:

> Hi Kumar,
>
>>>>> I understand what the patch does.  It just removes the  
>>>>> capability of
>>>>> soft-resetting a core back into the boot translation code.  I
>>>>> understand your problem I'm just not keen on solving it by  
>>>>> completely
>>>>> disabling boot translation.
>>>>>
>>>>> We had a similar memory map and I moved away from it because of  
>>>>> the
>>>>> reset vector issues.  Additionally, things like >4G of memory also
>>>>> start creeping up.
>>>>
>>>> I'm not super familiar with how the MP support in U-Boot is used.
>>>> Would
>>>> you be resetting a secondary core for debug purposes?  Or is  
>>>> there an
>>>> example of when you'd reset one in normal operation?  I thought  
>>>> normal
>>>> operation was to use the "cpu release" command, or to let the OS
>>>> manually take the secondary cores out of their wait loops.
>>>>
>>>> What if I spruced up cpu_reset() to temporarily re-enable boot page
>>>> translation, then disabled it again?  (And maybe re-initialized the
>>>> cpus
>>>> MP table so that it could properly ack the primary core similar  
>>>> to in
>>>> pq3_mp_up().
>>>>
>>>> It seems somewhat dirty to me to constantly keep boot page  
>>>> translation
>>>> enabled, even when its not needed.  Especially since it would
>>>> require us
>>>> to change our memory map, environment variable scripts,  
>>>> documentation,
>>>> etc on all our boards:)
>>>>
>>>> I'd be happy to look into an alternate workaround if you have an  
>>>> idea
>>>> for a cleaner implementation.
>>>
>>> The idea is after u-boot if you soft-reset a core that it would go
>>> back into the spin table code.  U-boot is long gone at this point.
>>
>> Are there common scenarios where a core would be reset after its  
>> already
>> booted an OS?  If an OS did need to soft-reset a secondary core,
>> shouldn't the OS be responsible for ensuring boot page translation is
>> enabled, its translating to the proper location, etc?  For example, I
>> imagine non-Linux OSes bring up secondary cores in different  
>> manners and
>> some wouldn't re-utilize U-Boot's boot page code located in SDRAM at
>> all, thus they wouldn't want the boot page translation always  
>> enabled.
>>
>> It just seems less than ideal to have a chunk of memory space that
>> somewhat magically accesses a completely different, unintuitive  
>> address
>> space.  Someone else ran into the same issue already:
>> http://www.mail-archive.com/u-boot@lists.denx.de/msg08361.html
>>
>> I realize there's a tradeoff between keeping the translation  
>> enabled vs
>> disabled, I'm just not familiar with how OSes utilize the secondary
>> cores to know what the downsides of disabling translation are...
>
> Any feedback on my last email above, or is disabling boot page
> translation just a no-go?

It is at this point.

> Or is there an more ideal alternative?  I really don't want to  
> change up
> the memory map on all our Freescale boards, documentation, dts files,
> etc because of an optional 4KB chunk of memory space:)  I'm more than
> willing to implement a different workaround if it means we can keep  
> our
> current memory map...

I'd be fine if we want to add a CONFIG_ option to do the disable so  
board ports that need/want it can do it.

- k