I'm running 188.8.131.52 on an apu1d4 and accidentally set the BIOS redirection to com2. I've tried clearing the CMOS by shorting J5 for over a minute with the power disconnected, but that doesn't seem to undo it. I also have an lpc.1a and can get to its BIOS menu with no problem, but it doesn't seem to have an option for resetting the onboard settings (at least not that I can find). What options do I have for getting the BIOS back onto com1, aside from hacking together a serial line to fit the com2 header?
Resetting CMOS won't work as these settings aren't saved there, they are written to flash memory. If you can boot into system you can re-flash the firmware, otherwise you can use external programmer (but connecting to COM2 header might be easier/cheaper). Flashing resets the configuration. Remember to change other options afterwards, if needed.
If you can boot into system you can re-flash the firmware
Thanks! The good news is that this worked (I had a viable OpenBSD 6.5 rootfs with flashrom already installed so was easy enough to try). Bad news is I'm pretty sure I had "BIOS write protect" enabled and wasn't hampered by it (what's it for if not preventing mainboard firmware reinstallation?).
does anybody have an idea what's going wrong here?
Bootloader for ESXi relocates itself and modules to make way for the kernel. Unfortunately, while the relocator is a PIC (position independent code), it later returns to the code that called it, using standard return statement. That code was relocated to a new location and original code was overwritten, so it returns to some garbage instead. Apparently, a couple of jumps later it lands somewhere in the firmware (not necessarily code), where it either hangs or reboots, depending on the firmware version.
We (3mdeb) have managed to boot the installer successfully by marking some memory as reserved, so the `mboot.c32` module is loaded in a place where it isn't overwritten during relocation. This is not a solution, more like a workaround, and not a pretty one. It wastes some RAM - not much, but in heavily demanded area, so it might break something else. We have yet to decide where to go from here. Ideally, it should be fixed by VMware in their bootloader...