Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 Apr 2019 13:12:43 -0700
From:      Mark Millard <marklmi@yahoo.com>
To:        Dennis Clarke <dclarke@blastwave.org>
Cc:        freebsd-ppc@freebsd.org
Subject:   Re: Patches to allow usefdt mode that works on a 2 socket PowerMac3,  6 example too --and makes more work on 2-socket/1-core-each PowerMac11, 2
Message-ID:  <73E2F588-848D-4844-9D86-B1164B465300@yahoo.com>
In-Reply-To: <11433EF4-5A8B-48FF-BA41-F11AF4873647@yahoo.com>
References:  <988F644F-D5E7-4FB4-AAB3-A72E9DA88CE6@yahoo.com> <af38e008-d9f9-9364-56c5-56387cbcf95d@blastwave.org> <465DBF40-EEF5-4D4A-95F6-DF17EB5B130B@yahoo.com> <5aecd21e-e53c-f14c-0bdc-8732fa88fed6@blastwave.org> <A4E361A0-4C6C-4E37-BB04-AB52094F4206@yahoo.com> <55E83F50-197D-43C7-B4D6-E69A5AEC2630@yahoo.com> <1B999D64-036F-4553-B024-93D0150FD60D@yahoo.com> <433A1839-8232-4785-91AD-1EF5EAF31294@yahoo.com> <11433EF4-5A8B-48FF-BA41-F11AF4873647@yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help
[The patches are updated to span the iMac G3 example.]

On 2019-Apr-20, at 19:27, Mark Millard <marklmi@yahoo.com> wrote:

> To my knowledge, the investigatory patches to head
> -r345758 that are now in:
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233863
> 
> are sufficient for both non-usefdt mode and usefdt mode
> for booting and using the old PowerMac's that I can test,
> both G5 and G4. I'm hoping that other Apple ppc's that used
> to work before various changes again work for non-usefdt
> mode. Ones with even longer term problems probably still
> have such.
> 
> One requirement for usefdt mode is: kern.vty=vt
> Using sc hangs after the "Kernel entry at" message
> before even clearing the screen. (This is so early
> I may never figure out a way to isolate the problem
> for sc: no serial console context.)
> 
> So, unlike before, I now expect that testing on whatever
> variety of Apple G5 types that you have access to would
> be very useful to you and make evidence about the patches
> beyond what I can do with what I have access to. (It
> also cross checks if I've forgotten to post something.)
> This applies to both non-usefdt mode and usefdt mode.
> 
> Similarly for any variety of Apple G4's, if you have
> access to some.
> 
> The only powerpc64 and 32-bit-powerpc systems that I
> have access to are old PowerMacs. So I can not check
> the status of any other types of ppc systems with my
> patches involved.
> 
> One thing I'm not sure of for usefdt mode is what
> the consequences of small memory machines might be.
> /usr/src/stand/powerpc/ofw/ofwfdt.c has:
> 
> int
> fdt_platform_load_dtb(void)
> {
>        void *buffer;
>        size_t buflen = 409600;
> 
>        buffer = malloc(buflen);
>        fdt_create_empty_tree(buffer, buflen);
>        add_node_to_fdt(buffer, OF_peer(0), fdt_path_offset(buffer, "/"));
>        ofwfdt_fixups(buffer);
>        fdt_pack(buffer);
> 
>        fdt_load_dtb_addr(buffer);
>        free(buffer);
> 
>        return (0);
> }
> 
> On a 1 GiByte machine, with some other overhead
> use of RAM, that 409600 could be around half the
> available memory --or more. Even though
> fdt_load_dtb_addr will make a smaller copy, and
> then the bigger one will be freed, the copy's
> address range is constrained by the existing big
> allocation at the time.
> 
> On a sufficiently small memory machine the 409600
> would just not be possible. (That might even be
> true for a 1 GiByte machine.) Note the lack of
> any check on the malloc(409600)'s success vs.
> failure status. (By contrast, fdt_load_dtb_addr
> does check for a NULL return, even though
> fdt_platform_load_dtb ignores the fdt_load_dtb_addr
> return value.)
> 
> So if any of your testing contexts are "small" memory
> ones, it may be for those that only non-usefdt mode
> is the only effective option.
> 
> 
> Some patches only matter for usefdt mode, because they are
> about the conversion to fdt in the loader or use of
> the phandle nodes that the conversion adds to record
> openfirmware's original node-ids (xrefs vs. node refs).
> (Presumes no typing of commands like "fdt header" or such
> in the loader before the non-usefdt boot. Otherwise the
> fdt command itself does do a conversion at the time and so
> the conversion code would be involved.)
> 
> So, for just testing non-usefdt mode, fewer of the patches
> are needed.
> 
> No longer should any of my usefdt mode pure-hacks be
> required. (I now use my hacks to see if they report
> ever having anything special to do vs. not. This is
> more complete of a check than just watching overall
> normal-use behavior for usefdt mode.) I've not posted
> the current versions of my pure-hacks anywhere and I'd
> avoid any old postings about old versions. I hope to
> back out the hacks in my context as well.
> 
> 
> 
> (Note: I have access to one old PowerMac G4 that no version
> of FreeBSD that I've ever tried over the years could complete
> the boot. OS X had no problem with it, nor did the Linux that
> I tried. Until/unless I isolate the low level spot were
> FreeBSD fails on it, I ignore this old PowerMac in my wording
> for my testing.)

I have updated the patches and now the MPC750 iMac G3
PowerPC4,1 example also boots and operates for *BOTH*
non-usefdt mode and usefdt mode.

That is the last of the old PowerMac's that I
can test with.

It is still based on -r345758 and some of it would
not apply cleanly to sufficiently more recent
vintages of head.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?73E2F588-848D-4844-9D86-B1164B465300>