Milton Miller wrote:
|load: entry = 0x80053c flags = 0
|nr_segments = 2
|segment[0].buf = 0x1002b8f0
|segment[0].bufsz = 80
|segment[0].mem = (nil)
|segment[0].memsz = 1000
|segment[1].buf = 0x4803f008
|segment[1].bufsz = 3a3138
|segment[1].mem = 0x800000
|segment[1].memsz = 3b0000
I would expect a third segment (kernel/zImage, dtb, and purgatory), but
its not clear that you are getting that far yet.
segment 0 looks like a small segment which should create "boot loader
environment". That one does nothing.
Segment 1 is my cuImage. What is purgatory?
Now. The entry address in image->start is valid and is the entrypoint of
the "custom" cuImage. Custom means that it does not depend any register
values passed from u-boot (the original one needs a pointer to bd_t).
The only requirement is a valid 1:1 memory mapping.
ok sounds good. does this have the dtb in it too?
Yes it does.
The branch above is taken, so I've found my current mapping
ok, but should you not be using PID0 explictly to say global only?
The kernel mapping should only be global and therefore that might be a
good idea.
obviously, a jtag or similar hardware debugger would be best. Second
I have here CodeWarrior usb tap but after more than one hour playing with
that thing I started to hack assembly char put. It helper more :) kexec
seems to work now :) I get "nobody cared irq X" from time to time so I
thing I have to fix here something.....
As a final note, it looks like you are currently replacing the code in
relocate_new_kernel with book-e code. Obviously this will need
refinement to select or move to heat_xx to merge.
Yep, this is next what is going to happen. I would prefer to have them
runtime switchable instead of build depend.
Again, I don't have any direct experience, but mauybe this gives you
some ideas.
Your hints helped. Thx for that.
milton
Sebastian
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
