luporl isn't in here at the moment, but I think the reason the call wasn't working was that it expects a c-ish syntax because it looks for parens call moea64_kextract(0xc.....) hmm, 0xfff9ff3e00000000 so yeah seeing the same assigned-addresses as luporl when booting from serial Bdragon: heh, 11 hours in, and poudriere has built 70 packages (packaging 71, cmake, which will take a while)... out of 1145 queued :P jhibbits: heh When booting from serial, it might be scrambling the BAR Because that address is impossible, and would yield a machine check if you try to access it it looks like the original BAR 0 is 0x600c280000000 in linux. Checking the device tree too I think it might be down to differences between Linux and FreeBSD address spaces in this case I'd wager that it simply resets the AST PCI bridge ah, yeah, that's a good point we need to avoid touching the bmc until we are doing the actual configuration It's also possible that one of the changes that snuck into 2.0 was not omitting the reset of the framebuffer accidentally, and nobody noticed because Linux can cope with this? No, I think the BMC is scrambling it when resetting the bridge Because that looks like it might be a 32-bit accessor space, for hitting the BMC PCI bridge configuration oh damn, I just realized looking at the vga dram clock, it's using the *bmc*'s ram which would make sense as that's the only way it would be able to do the remote kvm stuff I mean the device side view is using bmc ram to back the framebuffer at least if petitboot kernel can be trusted to report stuff properly. It says the dram clock is 800 Mhz which rings a bell to me as probably being the clockspeed of the 512M dram attached to the bmc yeah, MCLK=800 Mhz type=7 bus_width=16 size=01000000 * trasz has quit (Read error: Operation timed out) * trasz (~trasz@thyme.cl.cam.ac.uk) has joined #powerpc64 env boot_dtb=/tmp/fdt boot_console=fb0 /etc/petitboot/boot.d/30-dtb-updates hmm, interesting, smem_start is 0 ugh, it's dumping its calculations in u64 instead of hex because of some format type warnings that weren't converted properly but yeah, something seems wrong about the dtb updater it's spitting out crazy addresses (again, the https://github.com/open-power/petitboot/blob/master/utils/hooks/30-dtb-updates.c code) the *correct* assigned-addresses would be < 0x20000000 0x600c2 0x80000000 0x00 0x1000000 > I think jhibbits: I wonder if the math problem is due to the mmio space being mapped *before* the pci space jhibbits: nevermind, I was reading reg, not ranges pciex@600c3c50500000 ranges is < 0x20000000 0x00 0x80000000 0x600c2 0x80000000 0x00 0x7fff0000 > -> pci@0 is < 0x20000000 0x00 0x00 0x20000000 0x00 0x00 0xf0000000 0x00 > -> pci@0/pci@0 is the same, and vga@0 is reg < 0x20000 0x00 0x00 0x00 0x00 > so I guess the framebuffer is at the very beginning of the mmio heh fff9ff3e+600c2 = 100000000, that can't be a coincidence