Re: FreeBSD on PowerVM LPARs (powerpc64le) — LibrePower PoC

On Aug 17, 2026, at 12:22 PM, LibrePower <[email protected]> wrote:
> 
> Le 2026-08-17T16:27:27.000+02:00, Calvin Buckley <[email protected]> a écrit :
>  It should work on PowerVM/phyp in both LE/BE, but there's some bugs that prevent it from working[1]. If you fix one, the other one should also be fixed (and FWIW, P5/P6/P7 hardware is cheap used and BE only).
>  
> [1]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279137
> 
> Thanks Calvin — that bug report is useful, and I had not seen it before.
> I encountered a failure at the same stage: boot1.chrp never reached the loader on real PAPR firmware. In my case, the problem seemed to be the entry convention. The firmware enters the client program in big-endian mode, while boot1.elf is a little-endian image whose entry point does not switch MSR[LE]. As a result, the first instruction is decoded using the wrong endianness and traps.
> This does not happen under QEMU because SLOF enters client programs in little-endian mode. The proposed fix is a short bi-endian preamble at _start, using the same approach as Linux’s FIXUP_ENDIAN:
> https://gitlab.com/librepower/freebsd-powervm/-/blob/main/patches/12-01-boot1-endianness.patch
> There is one important caveat regarding PR 279137: the preamble is compiled only for little-endian builds. Big-endian images already match the PAPR entry convention, so I think this shall not explain the BE failures described in that report. It may explain one part of the problem, but someone with an affected system should be able to confirm or rule it out quickly.
> Regarding older hardware, I understand the point. However, my target is a PowerVM partition on "current" systems (Power9/10/11) both on-premises and PowerVS.
> In any case, I will keep documenting and publishing everything in the repository, whether or not it eventually reaches upstream. If it helps someone investigate the remaining issues, test on other systems, or submit better patches, then this modest effort will already have been worthwhile.

FWIW, this still fails in an LPAR on an S824, same as the normal 15 release:

```
Detected bad memory access to address: fffffffffffffffe
Package path = /packages/boot-mgr
Loc-code = 
Last memory-queue entry @ 28472c0 
0000028472a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 :................:
0000028472b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 :................:
0000028472c0: 00 00 00 00 0a 70 37 80 ff ff ff ff ff ff ff ff :.....p7.........:
0000028472d0: 00 00 00 00 00 00 00 20 00 00 00 00 ba d1 b0 b0 :....... ........:
Return Stack Trace
------------------
@  - 2840530 
close-package  - 28641e0 
(poplocals)  - 283e9e8 
(init-program)  - 288e3c4 
boot  - 288ef4c 
evaluate  - 2850308 
invalid pointer - 29cb35d 
invalid pointer - f 
invalid pointer - f 
catch  - 283cff0 
bt-task-boot-on-this  - 298ef34 
(poplocals)  - 283e9e8 
catch  - 283cff0 
execute-device-method  - 2864cec 
(poplocals)  - 283e9e8 
(select-boot-seq)  - 2865c74 
(poplocals)  - 283e9e8 
evaluate  - 2850308 
invalid pointer - 0 
invalid pointer - 0 
```

As per the BZ issue, this looks like it's something with how the ELF is built, as I think it fails before it even executes. None of the patches touch on that.

I'm also a little concerned with the vscsi patch since it isn't tested.