[U-Boot-Users] U-boot to mpc8260

[Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com>]

Detlev Zundel wrote:
> Hi Xyyiezi,
> 
>>      I am in an IC design company.And there ia an object of my company it is
>> about mpc8260.We have the  circuit netlist of mpc8260,but we cann't guarantee
>> the circuit netlist to be correct.The circuit netlist was on a SUN server which
>> supported Linux and Cadence. We want to use the u-boot as a software
>> verification tool to verificate the netlist. We have write a platform which was
>> used as an hardware in the verification. And we want to load the u-boot code
>> mpc8260 to the RAM block of the circuit netlist.In this method,we could
>> verificate the circuit netlist by both u-boot and the platform.It will be a
>> mode of hardware and software co-verification.
>>      But the difficult is I don't kown how to load the u-boot.Now I have read
>> the source code of the mpc8260 in the u-boot,and I kown I could use the GCC to
>> translate them.I didn't kown how to configure the mpc8260.What material should
>> I read?In my opinion,the circuit netlist will be similar to the hardware
>> mpc8260 expect the speed while it is running.But the hardware mpc8260 has its
>> board ,for example mpc8260ads,which is not in the circuit netlist in the SUN
>> server.And I don't kown whether I could configure the u-boot take the board
>> information.
>>      I earnest hope to obtain your help!
>>      Thank you!
> 
> Gone are the days when hardware was something you could knock your
> head against :)
> 
> No honestly, I don't understand completely what "netlist" (what is
> that anyway?) you are simulating, but you either have to
> 
> a) simulate hardware supported by U-Boot or
> b) create a U-Boot port for your simulated hardware.
> 
> Considering the fact that you simply want to _use_ U-Boot, I guess a)
> would be the most viable option.  However it sounds that you simulate
> your own custom hardware, so very likely things will not turn out to
> work out of the box.  
> 
> Taking route b) will take some time and very likely defeat your
> original intention of verification.
> 
> Cheers
>   Detlev

Hi xyyiezi, Detlev,

My guess is that xyyiezi _does_ want to do b) - create a u-boot port for 
his simulated hardware which will be used to verify the simulated 
hardware before it becomes real hardware.  This requires him to port 
u-boot to his hardware.  Non-trivial, and not something we can help much 
via email.

Xyyiezi: You want to start with the README section on porting.  While 
you are loading into a "RAM" block in the simulation, you should 
configure/consider it to be flash, hooked to CS0.  I'm assuming your 
simulated hardware has simulated or physical SDRAM - if you are using a 
RAM block to represent SDRAM in your simulation, then your port is much 
simpler but won't be as realistic (a large percentage of hardware 
problems have SDRAM as part of the problem - including layout problems 
that won't show up in your simulation anyway :-( ).

FWIIW, I've been down this path before and had very limited results, 
especially compared to the level of effort involved.  If your simulated 
bus cycles are OK, and your real hardware layout is OK, your system will 
work OK.  The lack fidelity of simulation (e.g. not really running 
SDRAM, not really using a MPC8260, not really using your physical board 
layout, etc.) means that almost all of the real problem areas are not 
simulated accurately enough to say whether your real hardware will work 
or not.

The simulation will always predict "yes, your hardware works" but the 
confidence level with respect to that answer will be very low.

Just to emphasize, the answer of your simulation WILL ALWAYS BE "yes, 
your hardware works" but it is still a crap-shoot whether that answer 
applies to your real hardware.  Making sure the details are correct (bus 
cycle timing AND LAYOUT!!!) are a MUCH better predictor of success than 
running in a simulation.

Good luck,
gvb
P.S. Did I mention LAYOUT IS CRITICAL and you cannot simulate that?