Date: Wed, 11 Dec 2019 19:07:12 +0100 From: "Hartmann, O." <o.hartmann@walstatt.org> To: Gary Jennejohn <gljennjohn@gmail.com> Cc: "Hartmann, O." <ohartmann@walstatt.org>, FreeBSD CURRENT <freebsd-current@freebsd.org> Subject: Re: Supermicro X9SCV-Q: no boot options to define Message-ID: <20191211190712.30797459@hermann.fritz.box> In-Reply-To: <20191211104822.12abca40@ernst.home> References: <20191211082359.7f362310@hermann.fritz.box> <20191211104822.12abca40@ernst.home>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/tVJAy+w7ACzF_8yQFMGIOMW Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 11 Dec 2019 10:48:22 +0100 Gary Jennejohn <gljennjohn@gmail.com> wrote: > On Wed, 11 Dec 2019 08:23:59 +0100 > "Hartmann, O." <ohartmann@walstatt.org> wrote: >=20 > > Hello folks, > >=20 > > my apology for polluting this list with a non-FreeBSD specific > > problem, but since Supermicro is a veryy often used vendor in the > > FreeBSD user/developer community I might find help here much fast. > >=20 > > I got hands on onto an oldish Supermicro X9SCV-Q mainboard, equipted > > with an older i5-25XXM CPU running at 2,5 GHz). The AMI BIOS has > > version 2.10.1208 from 2012. > > The board does initially a longer beep and the it sounds like two > > or three very short beeps plus a last longer beep at a higher tune > > and then the system ALWAYS jumps into the firmware/BIOS screen, no > > matter whether I set a administrator password to protect the BIOS > > or not. Apart from the suspect of damaged RAM (three beeps indicate > > RAM problem above the first 64k block, two indicate PEI recovery or > > video memory problems if I interpret the manual correctly). > >=20 > > Sometimes the POST screen shows some message like "... in Recovery > > State", due to the off-phased HDMI attached monitor, I do not see > > the first characters. Maybe someone knows what that might indicate. > >=20 > > I already have changed the memory banks and the memory seems to be > > allright as the replacement memory has been checked thoroughly > > prior to the test in another well running box and I also checked > > the memory on another box with memtest tool without any suspicious > > indication. > >=20 > > The attempt to flash the latest firmware fails due to the fact that > > I can not even define a boot device - either this process is > > cryptic or it isn't documented and I'm too dull. A FreeDOS 1.1 > > prepared USB flashdrive isn't bootable as any other UEFI/non UEFI > > flashdrive: I can see the USB drive as being attached to PCI bus in > > the firmware menu, I also can define a symbolic name, but then I > > fail in defining the path to the loader as suggested in the example > > (fs0:\file\loader.efi or so). Any hint is welcome. > >=20 > > This board has been used successfully over the past years and was > > equipted with a TPM module at connector 23 (TMP1 header) - I'm > > unfamiliar with those technologies and my first guess apart from a > > hardware failure was that the hardware could have been protected > > anyway like it is done via secure boot. Unplugging that TPM header > > doesn' change anything. > >=20 > > Also the boot of XigmaNAS latest USB flashed image or any FreeBSD > > (11, 12 CURRENT) latest USB flashed image failed so far. > >=20 > > Thanks for some help in adavnce, > > =20 >=20 > Don't know whether this will help, but a user posted to a forum > that he had this mainboard and couldn't boot any USB device no > matter what the tried. >=20 > His final, working solution was: >=20 > <quote> > Further investigation found NOTHING would boot from USB. I > cleared CMOS, entered setup and loaded Optimized Defaults, > rebooted, and VOILA! Case closed. >=20 > *happy dance* > </quote> >=20 > BTW he was using VGA. >=20 Hello, thanks for the tip. I already tried and did a reset. It seems that one has to select first a propper boot option and there is the problem. Once a media has been inserted either as a bootable disk, bootable USB flash or (not tested) CDROM, the firmware offers at the option entry Boot the option new boot entry. I have first to give the option a name, then select from a (cryptic) list of definitions how the firmware addresses the controler/device/partition/bootimage et ceterum (Select File System) and then, the worst thing, Path for boot option. Leaving this empty renders any USB UEFI formated flash device unbootable. For FreeBSD booting, I had to issue "\efi\boot\bootx64.efi" - this worked also with a preinstalled Windows10 HOME hdd I "borrowed" to test, so I do not know the syntax of this option. Knowing this, I was able to boot Xubuntu 19.04 from USB flash, XigmaNAS 12.1 from USB flash, Windows10 HOME from a HDD and I was luckily able to boot one time XigmaNAS to install the software onto a SSD and even this worked - until a certain point where FreeBSD fails! Starting with FreeBSD 11.3-RELENG, FreeBSD 12.1-RELENG, FreeBSD 13-CURRENT, the box is bootimg and is then freezing at the point, where the console shows EFI framebuffer informations (see PR 209821,=20 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209821). CURRENT (r355406) is freezing while showing some ATA device details.=20 =20 The AMI BIOS is at 2.10.1208 from 4th Nov 2012. There is a newer firmware available, but I can't install the firmware: while being able to UEFI USB flahes, it is impossible to boot FreeDOS 1.1 from an USB flash drive, even having properly set Legacy Boot ROM in PCIe/PnP/etc options in the firmware. I never have had such a confusing BIOS/firmware. Thanks, oh --Sig_/tVJAy+w7ACzF_8yQFMGIOMW Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCXfEwUAAKCRA4N1ZZPba5 RzscAP9YSL2oliMEtkgxQZrhnMkt31agOA8Fckv0cUhVyP/HCQD+OseH9ft1RIG9 5OdZbcUS1MhWDrEkrOc3X7fzkPd02QQ= =hj+R -----END PGP SIGNATURE----- --Sig_/tVJAy+w7ACzF_8yQFMGIOMW--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20191211190712.30797459>