linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Milton Miller <miltonm@bga.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: ppcdev <linuxppc-dev@ozlabs.org>
Subject: Re: [PATCH 3/3] First cut at PReP support for arch/powerpc
Date: Wed, 27 Jun 2007 06:22:27 -0500	[thread overview]
Message-ID: <d8960a6c86859c19b84dc9fd41446fbd@bga.com> (raw)
In-Reply-To: <20070627071008.GA30648@localhost.localdomain>

On Wed Jun 27 17:10:08 EST 2007, David Gibson wrote:
> Here is an implementation to allow PReP systems to boot under the
> arch/powerpc codebase, one of the few remaining platforms supported in
> arch/ppc but not so far in arch/powerpc.
>
> This support is still fairly incomplete - it needs to obtain a lot
> more device information from the residual data and put it into the
> device tree, rather than relying on hardcoded values (both in the code
> and in prep.dts).  Likewise many peripherals will not be supported -
> in particular the RTC is not yet supported, so the time will generally
> be wrong.


Hi David.

A few things I noticed:

(1) Your cleaned up mkprep.c seems to always put on a floppy header, 
where as before that was optional with the -php flag.  Is that header 
right for a hard disk partition?  Or would that just have the 1-sector 
header?  The comments in the old mkprep impiled the raw elf contents 
are used for netboot.  What if the zImage does't fit on the 1.44MB disk 
given in the header?

(2) Uour wrapper rule can leave behind zImage.dts.prep.elf, but there 
is no clean rule for that

(3) Is this the right platform to create the device tree from scratch 
by traversing fw data?  A significiant number of the properties are to 
be filled in or say IBM, which is incorrect.

(4) Adding a 5th udbg_putc method that calls a byte read to 
udbg_comport->lsr masked with THRE until 0 and performs a byte write to 
->thr shows we have the wrong abstraction.   Please make the inb/outb a 
method with the comport.  It would seem the actual init_xx could be in 
the platforms, passing inb, outb, and comport to a helper in 
udbg_16550.c.   I'm fine with declaring all the early inits in udbg.h

(5) the printk PReP architecture is in the middle of prep_find_bridges?

(6) #if 0 prep_request_io will need platform check

(7) do you expect both the kernel and the boot code will continue to 
need residual.h?  If so, can we have the boot dir make a copy like the 
zlib headers?  Or is this only temporary, the kernel only needs a copy 
of the raw blob to export to userspace in the same spot and the 
include/asm-powerpc copy will go away?

milton

  reply	other threads:[~2007-06-27 11:22 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-27  6:53 [PATCH 0/3] PReP support David Gibson
2007-06-27  6:54 ` [PATCH 2/3] Make more OF-related bootwrapper functions available to non-OF platforms David Gibson
2007-06-28  8:44   ` Segher Boessenkool
2007-06-27  6:54 ` [PATCH 1/3] Abolish unused ucBoardRev variables David Gibson
2007-06-27  7:10 ` [PATCH 3/3] First cut at PReP support for arch/powerpc David Gibson
2007-06-27 11:22   ` Milton Miller [this message]
2007-06-27 11:29     ` udbg_16550.c and legacy_serial.c Milton Miller
2007-06-28  0:38     ` [PATCH 3/3] First cut at PReP support for arch/powerpc David Gibson
2007-06-28  8:59   ` Segher Boessenkool
2007-06-28 10:00     ` Gabriel Paubert
2007-07-02 11:51       ` Segher Boessenkool
2007-07-03  9:51         ` Gabriel Paubert
2007-07-03 12:49           ` Segher Boessenkool
2007-07-03  2:26       ` Tom Gall
2007-07-03  6:50         ` Ulrich Teichert
2007-08-03  6:35       ` David Gibson
2007-08-03 15:24         ` Jon Loeliger
2007-08-06 19:43           ` Segher Boessenkool
2007-08-06 19:42         ` Segher Boessenkool
2007-07-18  1:31     ` David Gibson
2007-07-18 15:55       ` Segher Boessenkool
2007-08-03  6:43         ` David Gibson
2007-08-06 19:37           ` Segher Boessenkool
  -- strict thread matches above, loose matches on Subject: below --
2007-08-03 21:55 Yoder Stuart-B08248
2007-08-06  4:02 ` David Gibson
2007-08-06 19:45   ` Segher Boessenkool

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=d8960a6c86859c19b84dc9fd41446fbd@bga.com \
    --to=miltonm@bga.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=linuxppc-dev@ozlabs.org \
    /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).