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-Me9d12d1db0223c0e462f7cd0 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
