Is this on a recent kernel? 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 ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te2a9c6fe778e83f5-Mad67839317926940cfe62a25 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
