bootloader & head.S weirdness

bootloader & head.S weirdness

[Benjamin Herrenschmidt]

Hi !

I've almost finished a fist version of my new OF-based bootloader (for
newworld only) and I'm struggling with a few issues:

It appears that depending on where I load the kernel (and other various
manipulation with OF mappings), the kernel will sometimes boot or simply
cause various exceptions in head.S, mostly in the relocation code.

I've tried to figure out what's going on and finally decided (am I wrong
?) that what head.S does is fundamentally broken:

The kernel enters from OF, with the MMU in whatever state OF set it and
the guarantee that at least it's mapped 1:1 with some memory (1Mb) also
mapped just after it so that it can expand itself. This guarantees are
the responsibility of the bootloader.

At this point, it hacks a BAT to map the first 16Mb of memory to
KERNELBASE. That I don't like since it means playing with mapping of
potentially running code with MMU enabled (and you don't know if OF
didn't use a BAT itself for mappping the RAM you are running from, future
OF versions may do). It will then do all sort of weird guesses depending
on the bootloader to know if it must translate or not the source address,
do the copy and flush (which will usually default catch to OF with my
bootloader, depending on where I loaded the kernel, etc...)

Quik tries to load the kernel at 0, which avoids most of those head.S
issues, but the way it does is broken, since OF won't allow to CLAIM
memory from 0 (at least not on my machine), that means potentially
overriding bits of OF (I know OF tends to use high memory, but OF low
memory vectors are still needed, at least on 603 for prom_entry to work).

Also, the bootloader can't turn MMU off and clean TLB & BATs since
prom_entry must have the correct OF mappings in order to work.

Instead of trying to find out the magical address to load the kernel,
potentially breaking with future OF versions, and hacks like that, I
finally decided to give a try at fixing head.S (I'm still using 2.2.x
kernels, I beleive head.S did change with 2.3.x, I'll look into this later).

Basically, what I'm doing is, after bl prom_entry, and before filling the
BAT, I turn the MMU off, clear all bats (in a 601-compatible way unlike
the current kernel source tree), flush TLBs, and then continue to the
code that sets up the BAT and moves down the kernel to 0. I also had to
comment out the code that translates the source address on CHRP.

I'll post a patch later today, but I wanted to know if my way of doing
things is broken or will break CHRP machines or not. Basically, I feel
the "good way" is to shut down the MMU upon exit from prom_entry, and
then play with BATs, copy&flush, etc...

Any comments ?


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bootloader & head.S weirdness

[Cort Dougan]

Not always.  Keep in mind we have several machine types that follow the
same patch there.  We don't always enter with OF and OF doesn't always give
1:1 mappings, either.

} The kernel enters from OF, with the MMU in whatever state OF set it and
} the guarantee that at least it's mapped 1:1 with some memory (1Mb) also
} mapped just after it so that it can expand itself. This guarantees are
} the responsibility of the bootloader.

I don't care for it much but it gives us a foothold and OF doesn't seem to
use bat1 ever...

} At this point, it hacks a BAT to map the first 16Mb of memory to
} KERNELBASE. That I don't like since it means playing with mapping of
} potentially running code with MMU enabled (and you don't know if OF
} didn't use a BAT itself for mappping the RAM you are running from, future

Not dependent on the bootloader, just dependent on the current running
address and whether MSR_DR is set in the MSR or not.

} OF versions may do). It will then do all sort of weird guesses depending
} on the bootloader to know if it must translate or not the source address,
} do the copy and flush (which will usually default catch to OF with my
} bootloader, depending on where I loaded the kernel, etc...)

at 0x10000 on chrp when running quik.

} Quik tries to load the kernel at 0, which avoids most of those head.S
} issues, but the way it does is broken, since OF won't allow to CLAIM
} memory from 0 (at least not on my machine), that means potentially
} overriding bits of OF (I know OF tends to use high memory, but OF low
} memory vectors are still needed, at least on 603 for prom_entry to work).

We only do that after we've called prom_entry() for the last time, though.

} Also, the bootloader can't turn MMU off and clean TLB & BATs since
} prom_entry must have the correct OF mappings in order to work.
} 
} Instead of trying to find out the magical address to load the kernel,
} potentially breaking with future OF versions, and hacks like that, I
} finally decided to give a try at fixing head.S (I'm still using 2.2.x
} kernels, I beleive head.S did change with 2.3.x, I'll look into this later).
} 
} Basically, what I'm doing is, after bl prom_entry, and before filling the
} BAT, I turn the MMU off, clear all bats (in a 601-compatible way unlike
} the current kernel source tree), flush TLBs, and then continue to the
} code that sets up the BAT and moves down the kernel to 0. I also had to
} comment out the code that translates the source address on CHRP.

That's a good way to do it but shutting it down isn't always that easy.  On
some PReP's (the IBM 830 I think) we come into the kernel with MSR_IR on
and MSR_DR off and we're running with some odd I mappings (not D mappings, though).

} I'll post a patch later today, but I wanted to know if my way of doing
} things is broken or will break CHRP machines or not. Basically, I feel
} the "good way" is to shut down the MMU upon exit from prom_entry, and
} then play with BATs, copy&flush, etc...

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bootloader & head.S weirdness & restructuring

[Christian Zankel]

Hi,

It seems to me that on almost every machine linuxppc is running on
depends on having a bootloader to load the kernel. Would it be possible
to redesign all bootloaders to load the kernel to position 0, initialize
the OF path where necessary and jump to the kernel with the MMU switched
off? Then we could possibly remove all the conditional code (#if ...
#else .. #endif) in head.S mm/init.c, etc.

Right now, it is painfull to add a new machine that doesn't follow the
full PReP,CHRP specification, i.e. has no OF nor Residual Data
structures, etc.

I started to restructure the arch/ppc tree. However, I would like to
hear about your thoughts and recommendation. The goals I want to
achieve, are:

1. The bootloader gets a more active part, i.e. does some
pre-initiaization, esp. to get rid of the 'bl prom_init' and the variaty
of copying the kernel back and forth.
2. It should be possible to setup the kernel so that the same kernel
runs on all those machine that it is setup for. Of course, the more
machines you add the more overhead you get.
3. Each machine/architecture should get its own directory (pmac, prep,
chrp, apus, geminit, etc.)
4. To add a new machine, only a new directory has to be added and only a
few files have to be changed (mainly: Config.in and Makefile).
5. The _machine-ID is seperated into to fields, Vendor and Board.



Thanks,
Christian

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bootloader & head.S weirdness & restructuring

[Cort Dougan]

Not all machines.  The gemini and yellowknife don't have a bootloader.

I don't think this would work in all cases, although it would be great if
we could do it.  We can't stomp on the interrupt vectors at physical 0
because chrp/pmac need them to do the early OF calls to setup things and
copy the device tree before we can safely stomp on physical 0.  If the
bootloader did that, there wouldn't be a problem.  Then we have to pass all
the OF info we need that the bootloader has gathered to the kernel.  The
bootloaders would have to duplicate a lot of common code to do that, though
(quik, bootx, chrpboot, arch/ppc/boot/, coffboot and so on).  We could have
a common lib for them to use, though.

I'm all for doing something along these lines, though.  I'm just not sure
how to do it.  Any suggestions one how to get around the above problem?

It would be ideal to have the kernel start at physical 0, with the bootinfo
info passed along with the necessary data the bootloader has gathered.  If
there's no bootloader then the arch specific calls can gather what they
need.

} It seems to me that on almost every machine linuxppc is running on
} depends on having a bootloader to load the kernel. Would it be possible
} to redesign all bootloaders to load the kernel to position 0, initialize
} the OF path where necessary and jump to the kernel with the MMU switched
} off? Then we could possibly remove all the conditional code (#if ...
} #else .. #endif) in head.S mm/init.c, etc.

I don't agree.  It takes some manipulation in head.S or a clever
bootloader, though.  If you have suggestions for a simpler/cleaner system I
would be happy to add them, though!

} Right now, it is painfull to add a new machine that doesn't follow the
} full PReP,CHRP specification, i.e. has no OF nor Residual Data
} structures, etc.

If you're doing the 82xx work we should talk before you do that too much.
I'd like to find something that makes 8xx,6-7xx and 4xx happy before I
start merging in large tree-changes.

} I started to restructure the arch/ppc tree. However, I would like to
} hear about your thoughts and recommendation. The goals I want to
} achieve, are:
} 
} 1. The bootloader gets a more active part, i.e. does some
} pre-initiaization, esp. to get rid of the 'bl prom_init' and the variaty
} of copying the kernel back and forth.

Do you mean something like the common build?  Right now that works on
chrp/prep/pmac but the embedded systems would really hurt if we allowed
them to bloat.  It think they're still not lean enough (they have to
include a lot of non-board/processor specific code as it is).

} 2. It should be possible to setup the kernel so that the same kernel
} runs on all those machine that it is setup for. Of course, the more
} machines you add the more overhead you get.

We have something very close to that now.  What specific problems are you
having?  I'm not disagreeing that it's a problem, I just don't see where
the problem is.

} 3. Each machine/architecture should get its own directory (pmac, prep,
} chrp, apus, geminit, etc.)
} 4. To add a new machine, only a new directory has to be added and only a
} few files have to be changed (mainly: Config.in and Makefile).
} 5. The _machine-ID is seperated into to fields, Vendor and Board.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bootloader & head.S weirdness & restructuring

[Christian Zankel]

Cort Dougan wrote:
> Not all machines.  The gemini and yellowknife don't have a bootloader.
Well, but it wouldn't hurt if it had one(?) The only scenario a
bootloader would not work is if the kernel actually runs in ROM. 

 [...lot's of descriptions how a bootloader must be designed deleted..]
> It would be ideal to have the kernel start at physical 0, with the bootinfo
> info passed along with the necessary data the bootloader has gathered.  If
> there's no bootloader then the arch specific calls can gather what they
> need.
That was exactly what I meant.

> I don't agree.  It takes some manipulation in head.S or a clever
> bootloader, though.  If you have suggestions for a simpler/cleaner system I
> would be happy to add them, though!
And of course you need to edit mm/init.c. But if you try to exclude any
code related to OF and/or residual data there are many more than just
head.S. (Try to walk along the 'path' of the 8xx implementation). I
would like to see some kind of an implementation like the m68k tree. 

> If you're doing the 82xx work we should talk before you do that too much.
> I'd like to find something that makes 8xx,6-7xx and 4xx happy before I
> start merging in large tree-changes.
I thought that Dan Mallek is working on the 82xx port. Actually, I'm
working on a custom designed board based on a 750, and it looks like
that there are two or more to come in the forseeable future. (I guess
the ports will be much like the port for the gemini board, i.e. without
OpenFirmware, and maybe other 'pecularities').

> We have something very close to that now.  What specific problems are you
> having?  I'm not disagreeing that it's a problem, I just don't see where
> the problem is.
I'm sorry. I only wanted to have mentioned that, because that seemed to
be a requirement from you, at least it was a couple of month ago.

Thanks,
Christian

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: bootloader & head.S weirdness & restructuring

[Cort Dougan]

If bootx/quik could gather the necessary info from the OF tree then stick
it in physical ram somewhere we could pass a pointer to anything with
something like the common bootinfo struct I've been playing with.

Ben, how much work would it take to get bootx to do that?  I know quik
isn't quite there but we could add some code to do something along those
lines.

} That was exactly what I meant.

Yes, I do walk along that path quite often :)  I'm happy to merge in
patches to do that job or talk about ideas.  Do you have anything specific
in mind?

} And of course you need to edit mm/init.c. But if you try to exclude any
} code related to OF and/or residual data there are many more than just
} head.S. (Try to walk along the 'path' of the 8xx implementation). I
} would like to see some kind of an implementation like the m68k tree. 

OF is pretty firmly entrenched in the kernel, that's true.  It could be
pulled out so it's more modular.

} I thought that Dan Mallek is working on the 82xx port. Actually, I'm
} working on a custom designed board based on a 750, and it looks like
} that there are two or more to come in the forseeable future. (I guess
} the ports will be much like the port for the gemini board, i.e. without
} OpenFirmware, and maybe other 'pecularities').

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: bootloader & head.S weirdness & restructuring

[Dan Malek]

Cort Dougan wrote:

> Yes, I do walk along that path quite often :)

> } head.S. (Try to walk along the 'path' of the 8xx implementation).


OK, I am a little clueless at this hour.  As it appears you are
making fun of the way I wrote that code, perhaps you should
provide a suggestion.  I have more, the 82xx looks just like
that :-)......I am off to look at the m68k tree......


> } I thought that Dan Mallek is working on the 82xx port.


Yes, I am.  Although it is not really 82xx.  The 8240 is a 603
with a diluted MPC106 without OF.  When attached to the Sandpoint,
it looks somewhat like the Gemini port.  The 8260 is a 603 with
a hot rod CPM, so it looks more like the current 8xx port.
Both of these use the "board information" structure in place of
the OF residual like I did on the 8xx.



	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: bootloader & head.S weirdness & restructuring

[Christian Zankel]

Hi Dan,

Dan Malek wrote:
> Cort Dougan wrote:
> > Yes, I do walk along that path quite often :)

> > } head.S. (Try to walk along the 'path' of the 8xx implementation).
> 
> OK, I am a little clueless at this hour.  As it appears you are
> making fun of the way I wrote that code, perhaps you should
> provide a suggestion.  I have more, the 82xx looks just like
> that :-)......I am off to look at the m68k tree......

I'm sorry, I didn't want to make fun or criticize any of you. In fact, I
think you did a very good job. And I don't want to touch most of the
code at all. I just would like to rearrange them slightly. So, what I
wanted to say is, that when I first brought up linux on that board I
went through several files and whenever I found a #if(n)def CONFIG_8xx I
knew that I had to add another condition. That was what I meant with
'walking along the patch of the 8xx implementation'. However, that might
end up in having very long lines like this one
#if (CONFIG_8xx = 1) || (CONFIG_BOARDA = 1) || CONFIG_BOARD_C = 1) [...]
at several positions in several files.

So, basically, what I wanted to ask you about, is, what you think about
rearranging some small part of the sources into dedicated machine
dependent files and if it is doable and if you know of any constraints
about the way to do it. Or, if you would suggest just to add another
machine into the current code.


Thanks,
Christian

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bootloader & head.S weirdness & restructuring

[Dan Malek]

Christian Zankel wrote:


> I'm sorry, I didn't want to make fun or criticize any of you.


I was just kidding.  Some of that is pretty messy, and everytime
I am in there I think I should do something different....tomorrow.


> So, basically, what I wanted to ask you about, is, what you think about
> rearranging some small part of the sources


I have mixed feelings about it, and if you look at past messages
you will have seen me type this before.  I really want to separate
the dependent parts, but you have to consider there are still
"generic PPC" components that often get carried into these
dependent areas.  For people that are very focused on a
specific processor/board combination (and newbies) this is often
easier to understand.  However, for people that are making more
generic PPC changes, every time you update one machine type you
have to track down all of the others and make similar changes.
This not only increases the workload, but also the potential
for making mistakes and requires you test many more configurations
to ensure you haven't broken something on another platform.

The head.S is kind of bad, and we recently split off the 8xx
into its own.  I am not sure that was the right thing to do,
but we will live with it for a while.

There are already "machine" dependent files at the lowest
levels, just not in separate directories.  The complexity of
the "#ifdefs" at the PPC level is mostly to ensure we get to
the proper lower level dependent files.

Further, because of the integrated nature of some PPC processors,
the line between processor and machine is a little fuzzy.  For
example, the 8240 is a 603/MPC106/CHRP...but not exactly.  You
can leverage lots of existing code, but need to twist it just
a little in a couple of places.  It doesn't fit the processor
and machine model very well.

Someone just can't wake up some afternoon and declare major changes
for the "better".  This code has evolved over many years and there
are some subtle things that can't be upset or we take many steps
in the wrong direction.  We should try a few new things here and
there let the evolution continue.


> ........ Or, if you would suggest just to add another
> machine into the current code.

Well, since you asked :-).   I really like the machine
dependent structures with indirect function calls that was added
a little while back.  I would like to see that change into
something that really cleans up the current "setup.c" file.
So, yes, just add the new machine into the current code.

Second, because of my interest in the embedded software on any
of the PPC processors, I would like to see the assumptions about
OF, keyboards, video, or 8259s always present be broken.  These
assumptions aren't unique to the PPC port, they exist in other
generic Linux software.

Now, back to the subject line about bootloaders.  The "embedded"
Linux images seldom rely on any hardware initialization because
often there is nothing done.  This has grown a little out of
control, as each board has its own functions that run to set
up the hardware (including PCI mapping in some cases) before
the Linux kernel is started.  I am considering adopting the
machine descriptor for this as well to assist when adding new
board (machine) types.  Since the 8xx and 82xx environments
are quite programmable, another option I am considering is
programming all of the address spaces to a "Linux/8xx" space.
This would eliminate some code in mm/init.c and several
board specific include files.


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bootloader & head.S weirdness & restructuring

[Geert Uytterhoeven]

On Tue, 23 Nov 1999, Dan Malek wrote:
> There are already "machine" dependent files at the lowest
> levels, just not in separate directories.  The complexity of
> the "#ifdefs" at the PPC level is mostly to ensure we get to
> the proper lower level dependent files.
> 
> Further, because of the integrated nature of some PPC processors,
> the line between processor and machine is a little fuzzy.  For
> example, the 8240 is a 603/MPC106/CHRP...but not exactly.  You
> can leverage lots of existing code, but need to twist it just
> a little in a couple of places.  It doesn't fit the processor
> and machine model very well.

Alternatively, you can base your decisions on specific features that are shared
among different machine types, and say

    if (has_feature_a) {
	...
    }

instead of

    #if defined(CONFIG_x) || defined(CONFIG_y) || defined(CONFIG_z)
    ...
    #endif

This way you can also easily create common kernel images that run on various
types of machines, since has_feature_a is just a variable that's set up
dynamically on kernel startup.

If you want to create an optimized kernel for a specific machine type, say

    #if defined(CONFIG_x) || defined(CONFIG_y) || defined(CONFIG_z)
    #define has_feature_a	1
    #else
    #define has_feature_a	0
    #endif

and gcc will optimize away the unused parts.

Gr{oetje,eeting}s,
--
Geert Uytterhoeven -- Linux/{m68k~Amiga,PPC~CHRP} -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bootloader & head.S weirdness & restructuring

[Dan Malek]

Geert Uytterhoeven wrote:


> Alternatively, you can base your decisions on specific features that are shared
> among different machine types, and say
> 
>     if (has_feature_a) {
>         ...
>     }
> 
> instead of
> 
>     #if defined(CONFIG_x) || defined(CONFIG_y) || defined(CONFIG_z)
>     ...
>     #endif


Yes, but one of the things I am trying to do is reduce the
code size and instructions to execute.  On a 500 MHz G4 with
a Gigabyte of memory, a few extra instructions is no big deal.
On a 33 MHz 8xx with 8 Mbytes of memory, you watch all of this
pretty closely :-).


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bootloader & head.S weirdness & restructuring

[Geert Uytterhoeven]

On Thu, 25 Nov 1999, Dan Malek wrote:
> Geert Uytterhoeven wrote:
> > Alternatively, you can base your decisions on specific features that are shared
> > among different machine types, and say
> > 
> >     if (has_feature_a) {
> >         ...
> >     }
> > 
> > instead of
> > 
> >     #if defined(CONFIG_x) || defined(CONFIG_y) || defined(CONFIG_z)
> >     ...
> >     #endif
> 
> Yes, but one of the things I am trying to do is reduce the
> code size and instructions to execute.  On a 500 MHz G4 with
> a Gigabyte of memory, a few extra instructions is no big deal.
> On a 33 MHz 8xx with 8 Mbytes of memory, you watch all of this
> pretty closely :-).

So what's wrong with the approach above? All unused code will be optimized away
by the compiler. There's no difference between the first and the second
version, except that the first one is more readable.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven ----------------- Sony Suprastructure Center Europe (SUPC-E)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248632 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bootloader & head.S weirdness & restructuring

[Michael Schmitz]

> > >     if (has_feature_a) {
> > >         ...
> > >     }
> > > 
> > > instead of
> > > 
> > >     #if defined(CONFIG_x) || defined(CONFIG_y) || defined(CONFIG_z)
> > >     ...
> > >     #endif
> > 
> > Yes, but one of the things I am trying to do is reduce the
> > code size and instructions to execute.  On a 500 MHz G4 with
> > a Gigabyte of memory, a few extra instructions is no big deal.
> > On a 33 MHz 8xx with 8 Mbytes of memory, you watch all of this
> > pretty closely :-).
> 
> So what's wrong with the approach above? All unused code will be optimized away
> by the compiler. There's no difference between the first and the second
> version, except that the first one is more readable.

Plus it has the added benefit that you can still build kernels that
support a range of hardware (by making has_feature_a not const 0 or 1 but
something like feature_present(a) :-) If you don't need this, both are
equivalent though. 

Worried about wasting a few cycles on the branch? I've never noticed a
difference between m68k kernels supporting one, two or three machine types
(m68k uses the method proposed by Geert). That's been with 16 MHz 030. 
Even code size didn't increase that much compared to the generic Linux
kernel feature bloat between 2.0 and now :-)  

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bootloader & head.S weirdness & restructuring

[Wolfgang Denk]

In message <Pine.LNX.4.10.9911261032590.22448-100000@opal.biophys.uni-duesseldorf.de>
Michael Schmitz wrote:

> > > >     #if defined(CONFIG_x) || defined(CONFIG_y) || defined(CONFIG_z)
> > > >     ...
> > > >     #endif
...
> Plus it has the added benefit that you can still build kernels that
> support a range of hardware (by making has_feature_a not const 0 or 1 but
> something like feature_present(a) :-) If you don't need this, both are
> equivalent though. 

This depends if the compiler has a chance to  decide  which  code  is
needed and which not. Otherwise it cannot optimize away dead code.

> Worried about wasting a few cycles on the branch? I've never noticed a

No, it's the code size that matters on  many  embedded  systems.  The
target  is  a minimal kernel code size. And improved performance is a
most welcome add-on.

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"...one of the main causes of the fall of the Roman Empire was  that,
lacking  zero,  they had no way to indicate successful termination of
their C programs."                                     - Robert Firth

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bootloader & head.S weirdness & restructuring

[Dan Malek]

Geert Uytterhoeven wrote:

> So what's wrong with the approach above?


Nothing....

> ...... All unused code will be optimized away
> by the compiler.


Maybe.  I haven't seen much dead code elimination by
the compiler.  I guess one of the bazillion compiler switch
combinations would do it.  I haven't found a good one yet.

> .... There's no difference between the first and the second
> version, except that the first one is more readable.

Well, OK.  Just to provide some history.  When I did the
first 8xx ports, I used #ifdefs to remove large portions of
PMac, Prep, and CHRP nested case statements instead of
trying to rewrite something that I had no ability to test.
By using the #ifdefs, I could almost guarantee I didn't
break something that already exists.  Although in some of
the files that contain the #ifdefs only a few lines of code
are conditional compiled, the big win was elimination of
function calls into other machine dependent files that
simply didn't have to be compiled.  I think the Makefiles
look worse than the C code.......It may be nice to dynamically
generate the Makefiles for the configuration rather than have
the "if" statements in those.

It has now become a little more difficult to handle, although
I have noticed others are starting to use more #ifdefs around
other machine dependent code.  If you want to support multiple
machines in one binary, define them and the code will support
it.  I don't think the code will ever support a single binary
to run on an 8xx (or 82xx) and a PMac.

I have seen some pretty bad code over the past 20 years of my
career, and this stuff isn't even close to bad.  That doesn't
mean I am not going to try to make it better, we just have
to do it carefully because any changes in these files affect
lots of people (and other files).  Just remember that one of
my goals is to build small as possible embedded software that
reduces Flash ROM requirements.  Carrying along stuff like
keyboard and ADB drivers just to resolve some symbols doesn't
help us do this.


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bootloader & head.S weirdness & restructuring

[Geert Uytterhoeven]

On Sun, 28 Nov 1999, Dan Malek wrote:
> Geert Uytterhoeven wrote:
> > ...... All unused code will be optimized away
> > by the compiler.
> 
> Maybe.  I haven't seen much dead code elimination by
> the compiler.  I guess one of the bazillion compiler switch
> combinations would do it.  I haven't found a good one yet.

Gcc does since ages, at least for simple cases. Just compile

    extern void f(int);
    extern void g(int);

    void h(int x)
    {
	if (0)
	    g(x);
	else
	    h(x);
    }

with gcc. If you compile with at least -O, the only thing left is the call to
h(). On m68k, we've been using `if (MACH_xxx)' clauses (and also `switch
(MACH_TYPE)' since ages. Remember, the m68k port was the first port and it
started with support for multiple machines nearly in the beginning. In those
times, gcc was not that good yet, but this worked. Take a look at
include/asm-m68k/setup.h to see how we did it.

> I have seen some pretty bad code over the past 20 years of my
> career, and this stuff isn't even close to bad.  That doesn't
> mean I am not going to try to make it better, we just have
> to do it carefully because any changes in these files affect
> lots of people (and other files).  Just remember that one of
> my goals is to build small as possible embedded software that
> reduces Flash ROM requirements.  Carrying along stuff like
> keyboard and ADB drivers just to resolve some symbols doesn't
> help us do this.

Exactly my point. I don't want any ADB stuff compiled in in my kernel neither
:-)

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven ----------------- Sony Suprastructure Center Europe (SUPC-E)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248632 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bootloader & head.S weirdness & restructuring

[Michael Schmitz]

> I don't think this would work in all cases, although it would be great if
> we could do it.  We can't stomp on the interrupt vectors at physical 0
> because chrp/pmac need them to do the early OF calls to setup things and
> copy the device tree before we can safely stomp on physical 0.  If the

How much of space at physical 0 do you need to leave alone? I'm thinking
about leaving a gap of some k between _start and _stext for that, and
making all boot loaders load the kernel to physical 0 (skipping the part
up to _stext), and jump to _stext. 

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bootloader & head.S weirdness & restructuring

[David Edelsohn]

	Why not have the kernel define, or at least reserve space for, the
interrupt vectors?  If one specifies the correct padding and/or alignment,
the interrupt vector code will appear at the correct offsets when the
kernel is loaded at 0.  The kernel can start at 0, not its entry point or
normal code.

David

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bootloader & head.S weirdness & restructuring

[Cort Dougan]

That's what we do, in fact.  The problem is not stomping on the OF vectors
stored at physical 0 on chrp (on pmac they're at the high vector table not
the low one) so we load above that, do our prom calls then relocate to phys 0.

} 	Why not have the kernel define, or at least reserve space for, the
} interrupt vectors?  If one specifies the correct padding and/or alignment,
} the interrupt vector code will appear at the correct offsets when the
} kernel is loaded at 0.  The kernel can start at 0, not its entry point or
} normal code.
} 
} David

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bootloader & head.S weirdness & restructuring

[Gabriel Paubert]

On Mon, 22 Nov 1999, Christian Zankel wrote:

> 
> Hi,
> 
> It seems to me that on almost every machine linuxppc is running on
> depends on having a bootloader to load the kernel. Would it be possible
> to redesign all bootloaders to load the kernel to position 0, initialize
> the OF path where necessary and jump to the kernel with the MMU switched
> off? Then we could possibly remove all the conditional code (#if ...
> #else .. #endif) in head.S mm/init.c, etc.
> 
> Right now, it is painfull to add a new machine that doesn't follow the
> full PReP,CHRP specification, i.e. has no OF nor Residual Data
> structures, etc.

If you are able find a single machine which correctly follows the specs...

> 
> I started to restructure the arch/ppc tree. However, I would like to

Good luck, I would like to do this too. Note that I haave specific code
for MVME boards which is fairly clean (but nobody seems interested). It
requires residual data for now, if only I could get my hands on a machine
with an OF which at least gets configuratioon space device numbers
right... 

> hear about your thoughts and recommendation. The goals I want to
> achieve, are:
> 
> 1. The bootloader gets a more active part, i.e. does some
> pre-initiaization, esp. to get rid of the 'bl prom_init' and the variaty
> of copying the kernel back and forth.

Mine does a lot of this things for machine with residual data: it has its
own simple memory management and a few other things: 

- the braindead PCI I/O space allocation on PreP is completely redone 
(current kernel PreP code can cause collisions).
- an x86 emulator for ROM BIOSes

> 2. It should be possible to setup the kernel so that the same kernel
> runs on all those machine that it is setup for. Of course, the more
> machines you add the more overhead you get.

I don't care very much for 6xx/7xx machines... Embedded may want the
smallest footprint however. My bootloader is already something like 50kb
of code (ok, including the emulator), and I try to fight bloat...

> 3. Each machine/architecture should get its own directory (pmac, prep,
> chrp, apus, geminit, etc.)

Not exactly, rather a boot directory IMHO so that you find the right image
in the right place.... But then pmacs have several image formats depending
on their age...

> 4. To add a new machine, only a new directory has to be added and only a
> few files have to be changed (mainly: Config.in and Makefile).


> 5. The _machine-ID is seperated into to fields, Vendor and Board.

Maybe... But also all the PCI resource management has to be cleaned up at
least for PreP...

	Gabriel.

P.S: my bootloader is available on vlab1.iram.es:/pub/linux-2.2, I'm
trying to boot 2.3.28 now...

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bootloader & head.S weirdness & restructuring

[Marcus Sundberg]

Gabriel Paubert <paubert@iram.es> writes:

> > 2. It should be possible to setup the kernel so that the same kernel
> > runs on all those machine that it is setup for. Of course, the more
> > machines you add the more overhead you get.
> 
> I don't care very much for 6xx/7xx machines... Embedded may want the
> smallest footprint however.

Yes, the more code you can loose in embedded kernels the better.
But note that embedded does not necessarily imply 8xx/82xx/4xx.
There are embedded boards with 6xx/7xx processors too.

//Marcus
-- 
-------------------------------+------------------------------------
        Marcus Sundberg        | http://www.stacken.kth.se/~mackan/
 Royal Institute of Technology |       Phone: +46 707 295404
       Stockholm, Sweden       |   E-Mail: mackan@stacken.kth.se

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bootloader & head.S weirdness & restructuring

[Gabriel Paubert]

On 23 Nov 1999, Marcus Sundberg wrote:

> Gabriel Paubert <paubert@iram.es> writes:
> 
> > > 2. It should be possible to setup the kernel so that the same kernel
> > > runs on all those machine that it is setup for. Of course, the more
> > > machines you add the more overhead you get.
> > 
> > I don't care very much for 6xx/7xx machines... Embedded may want the
> > smallest footprint however.
> 
> Yes, the more code you can loose in embedded kernels the better.
> But note that embedded does not necessarily imply 8xx/82xx/4xx.
> There are embedded boards with 6xx/7xx processors too.

Yes, but often they have at least 8Mb of RAM (which was the minimal spec
for PreP). In this case a few more kB in the bootloader to make it more
generic do not hurt as long as you can make the run time kernel as small
as possible. Why not dynamically link the kernel to remove useless code,
for example have a kernel plus modules and link them selectively at boot
time depending on the network or SCSI chip, we are a far way from this
but it should be possible.

	Gabriel.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bootloader & head.S weirdness & restructuring

[Cort Dougan]

That's more of a task for the end users, not the kernel.  Configuring the
system and building a ramdisk isn't really part of the build I don't think.

} Yes, but often they have at least 8Mb of RAM (which was the minimal spec
} for PreP). In this case a few more kB in the bootloader to make it more
} generic do not hurt as long as you can make the run time kernel as small
} as possible. Why not dynamically link the kernel to remove useless code,
} for example have a kernel plus modules and link them selectively at boot
} time depending on the network or SCSI chip, we are a far way from this
} but it should be possible.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bootloader & head.S weirdness

[Benjamin Herrenschmidt]

On Mon, Nov 22, 1999, Cort Dougan <cort@fsmlabs.com> wrote:

>CC: linuxppc-dev@lists.linuxppc.org, linuxppc-dev@lists.linuxppc.org
>----------
>Not always.  Keep in mind we have several machine types that follow the
>same patch there.  We don't always enter with OF and OF doesn't always give
>1:1 mappings, either.

Yes, I agree. but I beleive the piece of bootloader appended to the head
of the kernel image or the early bootloader used (quik ?) should take
care of those very weird case and of mapping the kernel 1:1 before
entering it.

>} The kernel enters from OF, with the MMU in whatever state OF set it and
>} the guarantee that at least it's mapped 1:1 with some memory (1Mb) also
>} mapped just after it so that it can expand itself. This guarantees are
>} the responsibility of the bootloader.
>
>I don't care for it much but it gives us a foothold and OF doesn't seem to
>use bat1 ever...

There is no guarantee. I'll check what OF does on my machine, but I
really sounds risky to assume that. I did experience _lots_ of weird
crashes during boot and kernel relocation until I added the code to turn
the MMU off. Also, the range mapped with this BAT may overlap with
whatever OF has mapped previously.
The 1:1 mapping requirement I wrote about is just to make sure we get the
correct physical address when turning the MMU off. This could eventually
be replaced by a real boot params structure in one register (r3 ?) and
the kernel's entry physical address in another (r4 ?). Basically, if we
don't require 1:1 mapping, then we need to be given our own physical
address. I really don't like the idea of playing with this BAT with MMU
ON, and as I wrote you, I did experience various bad behaviour. Also, I
can't turn MMU off from the bootloader since the prom_init stuff needs
the MMU to be kept in it's original OF setup until we finish initialising.

>Not dependent on the bootloader, just dependent on the current running
>address and whether MSR_DR is set in the MSR or not.

You are right, but there is this CHRP address translation I didn't fully
catch.

>at 0x10000 on chrp when running quik.

Isn't there a risk here in the copy&flush code ? When copying the kernel
down, won't the copy&flush code override itself ? (We are lucky, it's in
the cache... but we have no guarantee neither that the cache is enabled
at this point).

>We only do that after we've called prom_entry() for the last time, though.

Hum... quik loads the kernel at 0, which _will_ override whatever vectors
where here way before we stop using OF. I think most OF implementations
use ROM based vectors at FFxxxxxx but this is still, I think, a dangerous
assumption. On the iBook, OF won't let you claim a range of memory
including the low mem vectors.

>That's a good way to do it but shutting it down isn't always that easy.  On
>some PReP's (the IBM 830 I think) we come into the kernel with MSR_IR on
>and MSR_DR off and we're running with some odd I mappings (not D mappings,
>though).

Ouch. I think this should be taken care by the small bootstrap appended
to the kernel (but that's only my opinion). In any way, if we could at
least differenciate those case clearly (let's say with some kind of
explicit machine number in a register on the kernel entry, not a
structure since at this point we don't want to access memory at all I
beleive).

Will those machine boot from OF ? I mean, is it OF who is setting up this
weird mapping ? In this case, wouldn't it be possible to fix this from
the bootloader using the OF "map" method ? If it's not OF, then I could
be fixed from the head bootloader.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: bootloader & head.S weirdness

[Momchil Velikov]

Benjamin Herrenschmidt wrote:
> 
> On Mon, Nov 22, 1999, Cort Dougan <cort@fsmlabs.com> wrote:
> 
> >CC: linuxppc-dev@lists.linuxppc.org, linuxppc-dev@lists.linuxppc.org
> >----------
> >Not always.  Keep in mind we have several machine types that follow the
> >same patch there.  We don't always enter with OF and OF doesn't always give
> >1:1 mappings, either.
> 
> Yes, I agree. but I beleive the piece of bootloader appended to the head
> of the kernel image or the early bootloader used (quik ?) should take
> care of those very weird case and of mapping the kernel 1:1 before
> entering it.

Please, excuse my ignorance, but why not just set real-mode OF variable
to true (maybe in the ELF .note section) ?

Regards,
-velco

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/