[U-Boot] Incorrect CONFIG_SYS_MONITOR_LEN on MPC85xx boards

[Felix Radensky]

Hi, Kumar
Kumar Gala wrote:
> Its defined differently on these boards (and all our future board 
> ports) since after relocation and such we have the FLASH @ 
> 0xe800_0000.  And thus the u-boot image is at @ 0xeff8_0000.

Thanks for the explanation. Out of curiosity, I've tried to set FLASH 
physical address on MPC8536DS
to 0xf800_0000 and modify TEXT_BASE to 0xfff8_0000. But that resulted in 
non-bootable system
(no u-boot messages at all).

What did I miss ?

Thanks.

Felix.
>
> - k
>
> On Aug 23, 2009, at 4:44 AM, Felix Radensky wrote:
>
>> Hi, Kumar
>>
>> I don't see any immediate problem with current FSL definitions
>> except they are confusing.
>>
>> I think my proposal will not work on platforms like MPC8572,
>> MPC8536, and P2020DS where  TEXT_BASE is defined as
>> 0xeff80000 instead of 0xfff80000. Can you please  explain the
>> reason why TEXT_BASE defined differently for these boards.
>>
>> Thanks.
>>
>> Felix.
>>
>> Kumar Gala wrote:
>>>
>>> On Aug 20, 2009, at 5:49 AM, Felix Radensky wrote:
>>>
>>>> Hi,
>>>>
>>>> All FSL MPC85xx boards define CONFIG_SYS_MONITOR_LEN as 256K
>>>> although actual size of u-boot binary is 512K. XES Xpedite boards 
>>>> seem to do
>>>> the right thing.
>>>>
>>>> I was wandering whether CONFIG_SYS_MONITOR_LEN for 85xx boards
>>>> can be defined in terms of CONFIG_SYS_MONITOR_BASE, similar to AMCC
>>>> boards ?
>>>>
>>>> #define CONFIG_SYS_MONITOR_LEN    (0xFFFFFFFF - 
>>>> CONFIG_SYS_MONITOR_BASE + 1)
>>>
>>> I don't have any issue w/such a fix but would like to know what the 
>>> implication is of having thing set the way we do on the FSL boards.  
>>> Is there some bug we'd hit?
>> I don't think there's some bug
>>>
>>> - k
>