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
next prev parent 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).