- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
im currently discussing the following problem with SuSE and HP:
We can use AMT SOL and our HP 800 G5 and Fujitsy P758 with SuSE Linux Enterprise installed for kernel redirection or remote shell login (using the amtterm tool). When installing in legacy mode SOL also works in grub2. We do find a "serial_poprt4088" when listing available intputs/output in grub2 console, which matches the ttyS4 port as port 0x4088.
However, when installing in EFI mode, AMT SOL only works as soon as the kernel loads, but not in grub2. All input devices we see in the grub console there are "serial_* serial at_keyboard", so we can't set the input/output to the S4 port and don't get any output from grub2 over amtterm.
SuSE told that the kernel initializes the ports itself, but grub2 relies on the bios to activate e.g. serial ports. Now, the HP and the Fujitsu host have totally different bioses (HPs own-written vs. Fujitsus American Megatrend), so I guess it's unlikely that both independently forgot to init the AMT serial port. It might be a bug in grub2, but at least on the Fujitsu we can redirect to com0 (which doesn't have a physical outlet, but does exist on the mainboard) and see serial_efi0 as available input/output then. So it's not grub2 totally failing to use serial ports with EFI, it is only the AMT serial port.
So I wonder if it might be a problem in the ME firmware because that's identical on both machines, HP and Fujitsu. Is someone around here with enough knowledge about the AMT implementation to give a statement about that?
Is the PC bios or the ME firmware responsible for initializing the AMT serial port in POST/before the OS loads?
Is it possible that the ME firmware initializes the AMT serial port in legacy mode but not in EFI mode? Does the ME firmware make a difference for EFI or legacy mode at all?
Any hint could be helpful because at the moment we don't know the source of the problem. BIOS, ME firmware or grub2...
cu,
Frank
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello FStei11,
Thank you for joining the community
I seems like your question goes really deep into the ME firmware programing. I found the following related to SOL:
6.15 Unconfiguring Intel AMT Systems
Command Unconfigure
Description
Unconfigures Intel AMT.
• Partial – Removes the configuration settings from the system and
disables the Intel AMT features on the system. Note that
if the manufacturer defined the SOL and IDE interfaces to be closed by
default, then a partial configuration operation will close them and they
cannot be reopened without physical access to the Intel MEBX. This is a
known Firmware limitation.
• Full – Deletes all the Intel AMT settings from the system and disables the
Intel AMT features on the system.
So it tell us that SOL and IDE needs to be physically enabled on MEBx and that is a firmware limitation
Then in the AMT reference guide it explains how to enable SOL
So based on that, its difficult to tell how deep access has grup2 in legacy mode, and what changes in EFI mode that it requires the kernel to load.
Regards
Jose A.
Intel Customer Support
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Jose,
thanks for caring! You state that "So it tell us that SOL and IDE needs to be physically enabled on MEBx and that is a firmware limitation". I did enable SOL and IDE in the MBEx menu, so when I get you right, it means that it should stay enabled. grub2 does nothing to enable SOL, there is no such code inside. It just enumerates the serial ports it finds and provides them as far as I understand the code.
So given that it finds the AMT port in legacy we can assume that SOL is activated all the time and should also be when booting in EFI. A question remains: Does "SOL is enabled" automatically mean that the serial port (com4) is activated? Usually the BIOS must activate all kinds of devices that you e.g. need for booting. And it initializes physical serial ports, too.
But com4 port ist not physical, it's just a software serial port provided by AMT. At some point during POST some firmware must initialize this "fake" serial port so that it can be found by boot managers like grub. But should the ME firmware activate it or the PC BIOS? Both could be possible, e.g. the ME firmware telling the BIOS "here is a serial port" and BIOS activating it (or not in EFI mode).
But would it make a difference for AMT if system is booting in legacy or EFI mode? Is it possible that there are different code blocks in ME firmware for providing the serial port in legacy and EFI? I would guess "no" because a serial port is not a boot device, so why would it be handled differently in legacy or EFI?
If ME firmware wouldn't make a difference between EFI and legacy it would be clear that either the BIOS makes a mistake in EFI mode or grub2-efi fails to find the port although it's there.
Is it possible to figure out if ME firmware handles the serial port and/or SOL activation different depending on the boot mode?
cu,
Frank
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is probably due to the BIOS not exposing the AMT serial port via a UEFI driver. UEFI grub will only use UEFI serial devices for I/O (i.e. devices which have a UEFI device driver bound to them, and provide a `SerialIo` interface. You should be able to get a list of drivers, and bindings. You should be able to use the EFI shell to view a list of devices which have UEFI serial drivers attached to them with:
dh -p SerialIo
... that is to say that it's probably a BIOS bug in both cases, but one that you might be able to workaround by loading a UEFI device driver which binds to and exposes PCI UARTs. Two Dells which I checked (Optiplex 7040 and Optiplex 7070) both failed to automatically attach a serial device driver to the AMT UART.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello FStei11,
Thanks for your comprehensive reply. I will proceed to ask our engineering team for this specific question. I will let you know as soon as we have updates from them.
Regards
Jose A.
Intel Customer Support
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page