Date: Mon, 19 Apr 2021 21:56:36 -0400 From: Mehul Sanghvi <mehul.sanghvi@gmail.com> To: Brandon Bergren <bdragon@FreeBSD.org> Cc: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: PowerMac G4 booting from memstick image Message-ID: <FB82C26C-B7A8-4548-BCA3-BE923DA41792@gmail.com> In-Reply-To: <e8df0188-9cde-4c41-964e-af7d1e0fdc39@www.fastmail.com> References: <A0937215-7A85-4250-B387-4175E10591C8@gmail.com> <CAOpTx7Fe%2BYMy=W%2Bs2-qz9V0803xPeqk19qptyG4fwdE5GUY7SQ@mail.gmail.com> <0E36A05F-017F-4B81-80E9-BC27D10E64FD@gmail.com> <800807B2-83C1-40CB-B5D3-67B5A6AED2C7@yahoo.com> <6F45C842-2520-46AF-8818-B1E18107C706@gmail.com> <e8df0188-9cde-4c41-964e-af7d1e0fdc39@www.fastmail.com>
index | next in thread | previous in thread | raw e-mail
> On Apr 19, 2021, at 21:42 , Brandon Bergren <bdragon@FreeBSD.org> wrote: > > On Mon, Apr 19, 2021, at 8:05 PM, Mehul Sanghvi wrote: >> >> Thank you for the explanation. I had seen something regarding SMP on >> the mailing list back in March >> and so thought that it might be part of the 13.0 release. > > SMP timebase fixes for G4s are a WIP still currently. I will MFC them to stable/13 once I have finished them though. > > https://reviews.freebsd.org/D29136 > > (IIRC I need to do another rebase because of some recent changes. Will try to get back to it soon.) > > I am looking for someone who has a "newer" (i.e. Quicksilver) SMP G4 to assist with submitting the platform function so I can analyze it, as I only have an ancient Graphite model that uses hardcoded timebase controls. > I have a PowerMac G4 450 DP (Gigabit), but I don’t think that qualifies as newer than Quicksilver. > In the meantime, on SMP G4 I recommend continuing to boot with SMP disabled until I can get all cases sorted out. > >> >> I have made USB flash drive using the 13.0 memstick image, but am >> unable to boot from there consistently. > > G4s (especially the powerbooks) can be *really* picky about which stick you're using. Of the stack of USB sticks that I own, exactly *1* consistently works. I started looking into the OpenFirmware ROM to see if I could figure out what is going on there, but so far I haven't had any ideas. > > Assuming you have a stick that works, the boot command I generally use (with the iso version!) is: > > boot usb1/disk@1:2,\ppc\loader usb1/disk@1:0 How do I burn the ISO to USB flash ? Do I write it the same was as the memstick, using dd ? I have some pictures I took of the screen, since that is all I had the ability to do.. I’ll see if I can get them put up onto a website for people to see if interested. > >> >> The first time, I got to the dialog box asking to choose Live CD, Shell >> or Install. I had waited >> A while to get to that stage, having gone through several minutes of: >> >> Root mount waiting for: CAM >> >> and also >> >> aprobe1:ata1:0:1:0 CAM status: Command timeout >> >> >> type of messages scrolling by on the screen. > > This may be caused by a descynced timebase. At the loader prompt, do "boot kern.smp.disabled=1" (or set it in the loader environment) and see if that fixes it. > >> >> Having gotten to the point of selecting Install, the keyboard wouldn’t >> work. An Apple keyboard, hooked up via KVM switch, which was working >> just fine upto that moment. > > I've seen this for some reason on ADB. I can usually work around it by using a USB keyboard. But it could be due to screwed up timers (due to timebase desync) > >> I attached the keyboard directly and tried again and now I’ve got the >> >> mountroot> >> >> prompt as it couldn’t mount /dev/da0s3 the second time around. > > My guess is that the timebase problems caused the controller interrupt threads to go comatose or something similar. >> >> >> Making a third attempt now, so lets see what happens. I might look at >> what Alfredo suggested and write the ISO to the USB stick and see if >> that works rather than the memstick.img > > Only the iso gets tested. memstick.img is likely going away soon, it doesn't work very well and the iso works everywhere. > >> >> >> Otherwise will just keep running NetBSD till 13.1 comes out. >> >> >> cheers, >> >> mehul >> >> >> >>> On Apr 19, 2021, at 20:46 , Mark Millard <marklmi@yahoo.com> wrote: >>> >>> >>> >>> On 2021-Apr-19, at 16:34, Mehul Sanghvi <mehul.sanghvi at gmail.com> wrote: >>> >>>> . . . >>>> >>>> I’ll go ahead and create an image with 13.0 and see if that works. >>> >>> 13.0-RELEASE was a major change, in that 32-bit PowrePC is finally using >>> modern llvm/clang-based toochain instead of a gcc 4.2.1 based toolchain. >>> Effectively, pre-13.0 is not as well unsupported at this point, if I >>> understand right. > > Right. > >>> >>> In other words, it is unlikely that you would want to use a 12.x >>> version at all unless you have reasons to be using the old toolchain. >>> >>>> As I understand it 13.0 handles SMP on the G4 better, and since I have a G$ with 2 CPUs, that would be better anyway. >>> >>> 13.0-RELEASE does not contain code changes to deal with FreeBSD's >>> PowerPC problems in that area as far as I know. There is work >>> going on in/for main in the area but some of it has not been >>> checked into main yet, if I understand right. The range of 32-bit >>> PowerMacs covered and if your hardware is (would be) I do not know. >>> >>> There are other issues as well. For example: >>> >>> Unfortunately, the FreeBSD 32-bit kernel that covers PowerMacs (G3/G4) >>> slowly zeros out pages of user processes that it should not touch. >>> This ends up causing some processes to crash and probably other, less >>> obvious, issues. It is not a reliable environment. To my knowledge, >>> this area is not under active development currently but the basic >>> issue of what type of thing is missing was identified some time back. >>> (The 64-bit kernel that covers G5s does not have this problem.) > > I still haven't been able to reproduce this on G3/G4, but definitely concur that there is a page zeroing issue when attempting to use the 32 bit kernel on a G5 (which has a different MMU -- the kernel interacts with it via bridge mode compatibility. I've tried several times to figure out what the heck is going on but failed every time.) > > By the way, I *FINALLY* figured out what is going on with moused freaking out. It ended up being an oversight in forking that lead to floating point registers getting out of sync. > My current in-testing patch is http://drop.rtk0.net/fork_rework_3.patch -- will be submitting it soon once I finish my local testing. > > This issue actually affects ppc64 as well and has probably been the source of some mystery crashes when forking. > >>> There is more, but the above two are fairly major items out of the >>> overall list. >>> >>> These issues are not unique to 13.0+ as far as I know. Using 12.x >>> likely would not avoid them. > > IMO 13 is in better shape than 12.x. I am currently dogfooding it on a G4 PowerBook on a daily basis and will be continuing to fix issues here and there that have been cropping up. > >>>>> On Apr 19, 2021, at 19:10 , Alfredo Dal'Ava Júnior <alfredo at freebsd.org> wrote: > [snip] > > -- > Brandon Bergren > bdragon@FreeBSD.org > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org” cheers, mehulhelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FB82C26C-B7A8-4548-BCA3-BE923DA41792>