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

Hi again,

Thanks for testing this on your POWER8. The trace settles it: the
failure occurs inside (init-program), before the client program gains
control, so my boot1 change at _start cannot address it.

Your ELF-branding lead from the BZ is worth trying: brandelf -t SVR4
on both boot1.elf and loader. I’ll test it once I have access to an
on-premises Power system and report back.

You’re also right about the vSCSI patch. My PowerVS partitions boot
over virtual Fibre Channel, while the vSCSI bus never completes the
SRP login, so I cannot exercise that path yet. It still needs further
testing and improvement.

Thanks again for the feedback. I’m sure we’ll get it all working
:)

Le 2026-08-17T22:40:48.000+02:00, Calvin Buckley <[email protected]> a
écrit :

> 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.

 
		 

		[LibrePower]

		LIBREPOWER

 

		✉  [email protected]

		🌐  librepower.org [https://librepower.org]

		GitLab [https://gitlab.com/librepower]

		Newsletter [https://librepower.substack.com]

		AIX · IBM i · Linux ppc64le

		Open Source for IBM Power