[U-Boot] MPC8555CDS broken on TOT (commit 8fd4166c, ELDK 4.2)

[Bartlomiej Sieka]

Andy Fleming wrote:
> On Tue, Sep 23, 2008 at 5:05 AM, Bartlomiej Sieka <tur at semihalf.com> wrote:
>> Hello,
>>
>> TOT U-Boot (commit 8fd4166c, compiled with ELDK 4.2) for the MPC8555CDS
>> target is broken with the following symptoms:
>>
>>
>> [flash the 8fd4166c image and reset the board]
>>
>> U-Boot 2008.10-rc2-00018-g8fd4166 (Sep 23 2008 - 10:23:59)
>>
>> CPU:   8555E, Version: 1.1, (0x80790011)
>> Core:  E500, Version: 2.0, (0x80200020)
>> Clock Configuration:
>>        CPU: 825 MHz, CCB: 330 MHz,
>>        DDR: 165 MHz (330 MT/s data rate), LBC:  82 MHz
>> CPM:   330 Mhz
>> L1:    D-cache 32 kB enabled
>>        I-cache 32 kB enabled
>> Board: CDS Version 0x11, PCI Slot 1
>> CPU Board Revision 0.0 (0x0000)
>>     PCI1: 32 bit, 33 MHz, sync
>>     PCI2: 32 bit, 66 MHz, sync
>> I2C:   ready
>> DRAM:  Initializing
>>     SDRAM: 64 MB
>>     DDR: 256 MB
>>
>>
>> And the output stops here, console is dead. Can't give more details as
>> to what's going on the board -- don't have a HW debugger available.
>>
>> After a power-cycle, the board doesn't go as far as the first time after
>> reset:
>>
>> U-Boot 2008.10-rc2-00018-g8fd4166 (Sep 23 2008 - 10:23:59)
>>
>> CPU:   8555E, Version: 1.1, (0x80790011)
>> Core:  E500, Version: 2.0, (0x80200020)
>> Clock Configuration:
>>        CPU: 825 MHz, CCB: 330 MHz,
>>        DDR: 165 MHz (330 MT/s data rate), LBC:  82 MHz
>> CPM:   330 Mhz
>> L1:    D-cache 32 kB enabled
>>        I-cache 32 kB enabled
>>
>> Subsequent power-cycles result in the same output, i.e., the output dies
>> after the "I-cache 32 kB enabled" line.
>>
>> The U-Boot works fine as of commit 71074abb, but can't do a full
>> bisection at the moment (can't flash the board easily).
>>
>> Brief search of the ML archives didn't reveal any such issue reported,
>> so I'm posting this as a data point, and in the hopes that someone can
>> take further investigation from here. I'll be happy to provide more
>> details if needed, and might also be able to test a potential fix.
> 
> Did Rafal Czubak's patch solve your problem?

Yes, it did (actually this problem was the reason Rafal started the
work that lead to the patch you're mentioning).

Regards,
Bartlomiej Sieka