On Mon, Feb 17, 2025 at 04:31:41PM -0600, Jacob Moody wrote: > Is this on a recent kernel?
Yes. I consulted the git log and saw that work had been done on xhci. So this is with the latest 2025-01-18 release. > Cinap did a bunch of work on USB this past December. > If you're using the latest release (either you or tlaronde) then that has > these changes. > If you're running in to issues, you can set usbdebug= in plan9.ini to get > diagnostic output on boot. > so something like: > > usbdsebug=-ddd > > will get you some pretty verbose output. > A log of what shows up with that would be a good first step to figuring out > what is going wrong. > > > Thanks, > moody > > On 2/17/25 16:02, adventures in9 wrote: > > The *nousbxhci= is exactly what I had to do to boot my AMD system > > without errors. > > > > I'm running mine as a headless cpu server. So I pxe boot, use a > > plan9.ini that uses nobootprompt=tls to automatically boot, and then > > compile a valid nvram file into the kernel to authenticate with the > > fileserver. > > > > bootfile=/amd64/9pc64n > > nvram=/boot/nvram > > nvroff=0 > > nvrlen=512 > > service=cpu > > nobootprompt=tls > > user=glenda > > auth=10.9.0.9 > > fs=10.9.0.9 > > mouseport=ps2 > > monitor=vesa > > vgasize=1280x1024x32 > > nora6= > > *acpi=1 > > *nousbxhci= > > > > If I don't run *nousbxhci= I end up with a couple cores pegged out > > running xhcirecover. > > > > > > On Mon, Feb 17, 2025 at 5:29?AM <tlaro...@kergis.com> wrote: > >> > >> Well, stating in plan9.ini: > >> > >> *nousbxhci= > >> > >> disable the xhci code and then the kernel boots. But, I can't use the > >> keyboard, since it is connected via USB and, apparently, there is > >> whether xhci or nothing. > >> > >> I can clean the plan9.ini (I have to correct the /dev/sdU1affc that is > >> incorrect: this is /dev/sdN0) and set things so that it doesn't ask > >> anything so I will be able to connect to it from remote. > >> > >> For Ori, here is a picture taken from what is displayed (note that > >> there are two esp because I have assigned a type of ESP to the Plan9 > >> slice under Windows in order to mount it to access the 9fat for > >> editing plan9.ini; this is why: the esp(1) is in fact the whole Plan9 > >> slice or wedge or whatever you name it---the portion in the GPT). > >> > >> On Mon, Feb 17, 2025 at 12:36:47AM +0100, tlaro...@kergis.com wrote: > >>> To see if the block size could be a problem, I have installed 9front > >>> on a HDD connected via USB. > >>> > >>> I created a GPT with the first partition an EFI one (esp for 9 front) > >>> and a second partition for 9front. > >>> > >>> At first, I selected to use the EFI as 9fat. This didn't work, so I > >>> secondly let the 9fat be at the very beginning of the Plan9 partition. > >>> > >>> Testing on a PC with both legacy/UEFI support: the UEFI cdrom install > >>> doesn't work; booting with UEFI a 9front installed on an USB disk, > >>> doesn't work. But running the UEFI shell and then executing, from the > >>> UEFI shell the 9front efi/boot/bootx64.efi succeeded (Note: on the PC, > >>> not the AM08Pro ACEMAGICIAN target). > >>> > >>> So I try on the AM08Pro. UEFI doesn't work; launching the UEFI Shell > >>> and executing efi/boot/bootx64.efi goes a little farer (with a > >>> filesystem with 512 bytes blocks) but fails: > >>> > >>> Same result, but it goes a little further that the USB thumb (with an > >>> ISO9660 filesystem): > >>> > >>> --8<-- > >>> > >>> *acpi=0x93209014 > >>> *bootscreen=1600x900x32 x8r8g8b8 0x7fe0000000 > >>> bootfile=9pc64 > >>> bootargs=local!/dev/sdU1affc/fscache > >>> mouseport=ps2 > >>> monitor=vesa > >>> vgasize=1024x768x16 > >>> tiltscreen=none > >>> i/o error > >>> -->8-- > >>> > >>> => There is one difference between the "classic" PC and the AM08Pro: > >>> on the PC, I have 9front installed on one internal disk. So, perhaps, > >>> the booting procedure, supposed to be launched from the USB connected > >>> disk, reaches a file (the kernel or the plan9.ini) not from the USB > >>> but from the internal disk and this is why it succeeds. On the > >>> AM08Pro, since there is not 9front installed, perhaps one of the files > >>> is not found. > >>> > >>> Another attempt: > >>> > >>> I made an USB key with NetBSD install image. It boots correctly under > >>> UEFI. > >>> > >>> I shrinked the Windows partition on the NVMe disk installed on the > >>> AM08Pro and then created, from the "classic" PC, on the USB connected > >>> disk, > >>> a 9front install with a slice of the same size. > >>> > >>> Then, booting the AM08Pro from the NetBSD USB thumb, I dd'ed the 9front > >>> slice (in the USB connected disk) in the NVMe slot created. > >>> > >>> I then rebooted the AM08Pro and run the UEFI shell that I have installed. > >>> > >>> >From the shell, I executed the 9front efi/boot/bootx64.efi > >>> > >>> The kernel boots, but then an infinite loop of messages appear, with > >>> addresses varying but with this pattern: > >>> > >>> usbxhci dc[0-5]0000: need recover USBSTD=4 er stopped=0 > >>> > >>> I will look for this in the sources tomorrow (Monday). But if someone > >>> has already clues about what is happening... > >>> > >>> On Sun, Feb 16, 2025 at 06:45:48PM +0100, Gorka Guardiola wrote: > >>>> 9front is probably using a completely diferent loading chain, but 2048 > >>>> could be correct if they use a similar or related approach. > >>>> > >>>> On Sun, Feb 16, 2025, 18:44 Gorka Guardiola <pau...@gmail.com> wrote: > >>>> > >>>>> I haven't used native plan 9 for a long time, but, in case it helps, > >>>>> 2048 > >>>>> used to be the blocksize in USB booting (from CDROMs, this was all > >>>>> using El > >>>>> Torito standard when I wrote the bootloader ages ago). I think USB > >>>>> didn't > >>>>> care but CDROMs did. > >>>>> > >>>>> On Sun, Feb 16, 2025, 16:51 <tlaro...@kergis.com> wrote: > >>>>> > >>>>>> As indicated in another message, I'm trying to install Plan9 (9front) > >>>>>> on an AM08Pro, that is a ACEMAGICIAN with an AMD Ryzen 9 8cores, 16 Gb > >>>>>> of memory, and a 512Gb NVMe disk (M.2). > >>>>>> > >>>>>> Before attempting to PXE boot (that should work) I'm trying to > >>>>>> understant why an USB thumb does not work. > >>>>>> > >>>>>> I have installed an UEFI Shell (that has to be called Shellx64.efi > >>>>>> despite the "Shell.efi" mentionned in the BIOS menu) in the Windows > >>>>>> EFI system partition. From the BIOS menu, I can select "try to run an > >>>>>> UEFI shell found in one of the filesystems" to explore the board. > >>>>>> > >>>>>> Concerning USB, there are 3.0, 3.1 and 3.1 USB-C ports (even Windows > >>>>>> fail to recognize some USB devices depending on where they are put, > >>>>>> and it seems that connecting a keyboard+touchpad combo, that uses one > >>>>>> connector, but two instances, invalidates the next USB connector; so > >>>>>> the whole USB stuff looks suspiciously fragile). > >>>>>> > >>>>>> Nonetheless, an USB thumb (as well as a CDROM connected via an USB > >>>>>> connector) is recognized as CDROM(0x1). > >>>>>> > >>>>>> I think this may be the problem: the firmware is using 2048 blocks > >>>>>> (ISO9660 FS) while the information in the MBR table relates to 512 > >>>>>> blocks. With BIOS allowing legacy compatibility, this may perhaps work > >>>>>> (MBR make the booting switch to 512 bytes blocks), but this will not > >>>>>> if the block size is fixed as 2048? > >>>>>> > >>>>>> I haven't look at the UEFI code, but does this ring a bell for someone? > >>>>>> -- > >>>>>> Thierry Laronde <tlaronde +AT+ kergis +dot+ com> > >>>>>> http://www.kergis.com/ > >>>>>> http://kertex.kergis.com/ > >>>>>> Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C > >>> > >>> -- > >>> Thierry Laronde <tlaronde +AT+ kergis +dot+ com> > >>> http://www.kergis.com/ > >>> http://kertex.kergis.com/ > >>> Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C > >> > >> -- > >> Thierry Laronde <tlaronde +AT+ kergis +dot+ com> > >> http://www.kergis.com/ > >> http://kertex.kergis.com/ > >> Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C -- Thierry Laronde <tlaronde +AT+ kergis +dot+ com> http://www.kergis.com/ http://kertex.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te2a9c6fe778e83f5-M272cedc0d958227ce9c68ccc Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
