[U-Boot-Users] U-boot to mpc8260
Jerry Van Baren
gerald.vanbaren at smiths-aerospace.com
Wed Jul 18 15:03:27 CEST 2007
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?
More information about the U-Boot
mailing list