From: Sebastian Siewior <bigeasy@linutronix.de>
To: Milton Miller <miltonm@bga.com>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [RFC] powerpc/boot: add kernel,end node to the cuboot target
Date: Tue, 30 Sep 2008 19:21:41 +0200 [thread overview]
Message-ID: <48E26025.9030208@linutronix.de> (raw)
In-Reply-To: <5162f4985b6fa3ced7fe8670cdae926a@bga.com>
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
next prev parent reply other threads:[~2008-09-30 17:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-23 19:54 [RFC] powerpc/boot: add kernel,end node to the cuboot target Sebastian Siewior
2008-09-23 22:28 ` Kumar Gala
2008-09-25 8:50 ` Sebastian Siewior
2008-09-24 1:24 ` Milton Miller
2008-09-25 9:43 ` Sebastian Siewior
2008-09-29 20:04 ` Sebastian Siewior
2008-09-30 7:44 ` Milton Miller
2008-09-30 17:21 ` Sebastian Siewior [this message]
2008-10-01 5:33 ` Milton Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48E26025.9030208@linutronix.de \
--to=bigeasy@linutronix.de \
--cc=linuxppc-dev@ozlabs.org \
--cc=miltonm@bga.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).