Subject: Re: Latest deal on -current?
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
From: Bill Studenmund <wrstuden@netbsd.org>
List: port-macppc
Date: 03/05/2004 23:52:21
--RnlQjJ0d97Da+TV1
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Feb 01, 2004 at 07:35:39PM +0900, Izumi Tsutsui wrote:

Sorry for not getting back sooner on this.

> In article <20040126174105.GC20602@netbsd.org>
> wrstuden@netbsd.org wrote:
>=20
> > On Sat, Jan 24, 2004 at 01:34:33PM +0900, Izumi Tsutsui wrote:
> > > In article <20040123220357.GE15514@netbsd.org>
> > > wrstuden@netbsd.org wrote:
> > > > Yes. Well, we don't worry for a while. The change moves ofwboot.xcf=
's load=20
> > > > to E00000 or so (as I recall).
> > > Anyone committed the change?
> > Looks like not. You want to do it?
>=20
> Well, I don't have enough time to work on NetBSD recently,
> and I only tested the patch on my Apus (which had OF 2.0).
> Does anyone test ofwboot.xcf on OF 3.x machines?
> I'm a bit confused since some people say load-base or real-base
> should also be changed.

load-base and real-base should NOT be changed on OF 3.x machines. Their=20
default settings work well, and on some models changing them will result=20
in WIPING OUT THE ROM. You will then need a new motherboard. Yes, you will=
=20
need a new motherboard if you mess up OFW settings. The problem is that=20
when OFW goes to save he settings, it tries to also update the ROM image.=
=20
But it doesn't have a copy of the ROM to do the update with, so it botches=
=20
the update. Since said ROM is what boots the box, well....

> > While we're at it, I think we can colapse RELOC and RELOC_FLATFILE into
> > just RELOC.
>=20
> I have no idea about this because I don't know the reason
> why RELOC_FLATFILE was introduced...

cvs annotate.

You'll find that it was introduced by me in revision 1.26, with the=20
comment of:

Check in machinery to make ofwboot load at 600000, while ofwboot.elf
and ofwboot.xcf will load at 640000. The idea is that we can now
leave load-base at 600000, and it will work right for all three methods.

The problem is that the file loader and the net loader use load-base
as a scratch area, so if the executable really wants to load there,
the load fails.



I thought the driver-based load needed to load at load-base (which is=20
wrong). Thus RELOC_FLATFILE was just for it.

Take care,

Bill

--RnlQjJ0d97Da+TV1
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFASYM1Wz+3JHUci9cRAvU+AJ95YRI7s/1snYBVrJhX7ClWiz9HOACfYlis
hFaoejSmDRtiZ4lEBnxYXiE=
=aPIB
-----END PGP SIGNATURE-----

--RnlQjJ0d97Da+TV1--