linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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

  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).