Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

iPXE on Synology NAS ds1515+ - serial consol is not able to receive keyboard keystrokes. #1189

Open
hetii opened this issue Apr 8, 2024 · 13 comments

Comments

@hetii
Copy link

hetii commented Apr 8, 2024

Hi.
As I test ipxe on Synology NAS ds1515+ I notice serial console issue.

I compile my ipxe by:
make bin-x86_64-efi/ipxe.efi DEBUG=intel,intelx,netdevice EMBED=SynoBootLoader.ipxe

Changes in the ipxe files:

git diff:

diff --git a/src/config/console.h b/src/config/console.h
index 9f770d09..6ef49505 100644
--- a/src/config/console.h
+++ b/src/config/console.h
@@ -24,7 +24,7 @@ FILE_LICENCE ( GPL2_OR_LATER_OR_UBDL );
 
 //#undef       CONSOLE_PCBIOS          /* Default BIOS console */
 //#undef       CONSOLE_EFI             /* Default EFI console */
-//#undef       CONSOLE_LINUX           /* Default Linux console */
+#undef CONSOLE_LINUX           /* Default Linux console */
 
 /*
  * Additional console types
@@ -34,7 +34,7 @@ FILE_LICENCE ( GPL2_OR_LATER_OR_UBDL );
  *
  */
 
-//#define      CONSOLE_SERIAL          /* Serial port console */
+#define        CONSOLE_SERIAL                  /* Serial port console */
 //#define      CONSOLE_FRAMEBUFFER     /* Graphical framebuffer console */
 //#define      CONSOLE_SYSLOG          /* Syslog console */
 //#define      CONSOLE_SYSLOGS         /* Encrypted syslog console */
@@ -59,7 +59,8 @@ FILE_LICENCE ( GPL2_OR_LATER_OR_UBDL );
  *
  * Note that this is not related in any way to CONSOLE_SYSLOG.
  */
-#define        LOG_LEVEL       LOG_NONE
+//#define      LOG_LEVEL       LOG_NONE
+#define LOG_LEVEL       LOG_ALL
 
 #include <config/named.h>
 #include NAMED_CONFIG(console.h)
diff --git a/src/drivers/net/intelx.c b/src/drivers/net/intelx.c
index 343d0137..5fd0b4a0 100644
--- a/src/drivers/net/intelx.c
+++ b/src/drivers/net/intelx.c
@@ -333,6 +333,9 @@ static void intelx_poll ( struct net_device *netdev ) {
        if ( eicr & INTELX_EIRQ_LSC )
                intelx_check_link ( netdev );
 
+        // always recheck link state
+        // intelx_check_link ( netdev );
+
        /* Refill RX ring */
        intel_refill_rx ( intel );
 }

My menu looks like:

#!ipxe
# OUI: https://hwaddress.com/mac-address-range/00-A0-C9-00-00-00/00-A0-C9-FF-FF-FF/

set menu-timeout 5000
isset ${menu-default} || set menu-default shell

:start
menu iPXE boot menu for ${initiator-iqn}
item --gap --             ------------------------- Operating systems ------------------------------
item synology-1           Boot Synology from first usb partition.
item synology-2           Boot Synology from second usb partition.
item --gap --             ------------------------- Tools and utilities ----------------------------
item memtest              Memtest86
item --gap --             ------------------------- Advanced options -------------------------------
item shell                Drop to iPXE shell
item reboot               Reboot computer
item exit                 Exit iPXE and continue BIOS boot
item --gap --             --------------------------------------------------------------------------
choose --timeout ${menu-timeout} --default ${menu-default} selected || goto cancel
set menu-timeout 0
goto ${selected}

:cancel
echo You cancelled the menu, dropping you to a shell

:shell
echo Type 'exit' to get the back to the menu
shell
set menu-timeout 0
goto start

:failed
echo Booting failed, dropping to shell!
goto shell

:reboot
reboot

:exit
exit

## TODO what about vender file?
# vender /vender show

:synology_1
echo Booting synology from first partition on first disk aka hd0,0
kernel /zImage 
initrd /rd.gz
imgargs zImage root=/dev/md0 ihd_num=0 netif_num=4 pwrctl_pin=N0754N0850 DiskIdxMap=020006 syno_hw_version=DS1515+
boot || goto failed
goto start

:synology_2
echo Booting synology from first partition on first disk aka hd0,1
kernel /zImage 
initrd /rd.gz
imgargs zImage root=/dev/md0 ihd_num=0 netif_num=4 pwrctl_pin=N0754N0850 DiskIdxMap=020006 syno_hw_version=DS1515+
boot || goto failed
goto start

I'm able to see ipxe output over serial console as this device has no vga output, but somehow it ingore my keyboard keystrokes.

The only way of navigating over my menu is by connecting second keyboard over USB hub and use it instead console channel.

Orginal grub or linux bootstrap with console=ttyS0,115200 works fine in both way, so it's not hardware issue.

B.R.

@NiKiZe
Copy link
Contributor

NiKiZe commented Apr 8, 2024

CONSOLE_LINUX is afaik only available on builds running on Linux, don't enable this for any other builds.

Did you have any serial output before building with serial enabled?

Consider using discussions, not issues, until it is known that it is a bug in iPXE, and not just a missconfigurayion or other issue.

@hetii
Copy link
Author

hetii commented Apr 8, 2024

@NiKiZe

I check my build with CONSOLE_LINUX enabled and disabled as well.

As I wrote in the ticket the output from NAS works, but the input is only possible via usb keyboard and not via serial console.

I assume by having #define CONSOLE_SERIAL it should handle both input and output for serial console,
moreover as linux or orginal grub works fine with this serial console I decide to raise a bug.

Without #define CONSOLE_SERIAL i don't get any output from NAS.

B.R

@NiKiZe
Copy link
Contributor

NiKiZe commented Apr 8, 2024

Ok I wanted to verify that the serial in iPXE was actually used, and not some other firmware redirection.

Could you try forcing a shell and test character input? I guess you have use up/down arrows so far?

Maybe go as long as enabling serial debug?
We know for a fact that serial in iPXE works, so most likely it is something in your setup, but let's try to figure out what ;)

@hetii
Copy link
Author

hetii commented Apr 8, 2024

@NiKiZe
The shell works only with usb keyboard, but not with serial.

In addition I add in include/ipxe/uart.h a dbg_printf for uart_data_ready and uart_receive

/**
 * Check if received data is ready
 *
 * @v uart              UART
 * @ret ready           Data is ready
 */
static inline int uart_data_ready ( struct uart *uart ) {
        uint8_t lsr;
        lsr = uart_read ( uart, UART_LSR );
        dbg_printf ( "\nuart_data_ready: %c - %c\n", lsr,  ( lsr & UART_LSR_DR ));
        return ( lsr & UART_LSR_DR );
}

/**
 * Receive data
 *
 * @v uart              UART
 * @ret data            Data
 */
static inline uint8_t uart_receive ( struct uart *uart ) {
        dbg_printf ( "\nuart_receive 1:\n");
        uint8_t ret = uart_read ( uart, UART_RBR );
        dbg_printf ( "\nuart_receive 2: %c \n", ret);
        return ret;
}

And from below picture you can see that uart_receive is not even called when I press keys, only uart_data_ready.

obraz

Also when I compile ipxe with #undef CONSOLE_EFI then usb keyboard lost ability to type characters in shell.
Nothing change with #undef CONSOLE_PCBIOS or #undef CONSOLE_LINUX

@NiKiZe Edit:
Oh gosh seams that I found something after hours of tests ;/

In the file include/ipxe/uart.h there is a function called uart_data_ready this function return ( lsr & UART_LSR_DR )
when it's true then function serial_iskey() from core/serial.c report that we have a character in console code from core/console.c to be ready for processing.

In my case from some reason uart_data_ready() always return false.

When I change parity to odd then it often return true and sometimes even I get some character but wrong one.

When I lower baudrate to 57600 and set odd to none then each of my keystroke produce such characters:
obraz

It seams that from some reason uart in this hardware is not configured properly when I use iPXE, what is extremely odd as grub works fine with 115200 8n1 settings.

@hetii
Copy link
Author

hetii commented Apr 9, 2024

Hi.
I don't know what I can do more as I port entire uart implementation from grub4dos code into ipxe.

As I notice for 115200 baudrate my uart return most of the time 0xFF.

For original ipxe implementation I get only proper output in 115200 other baudrates produce garbage or nothing.

I double check the hardware, replace uart->ttl converter and test it with PL2303 and cp210x chip.

I really wonder where is the difference, as the uart issue only happen with ipxe bootloader :/

Maybe some registers are not set, or set wrong...

Let me know if I can test anything else.

B.R.

@hetii
Copy link
Author

hetii commented Apr 10, 2024

Many unbearable hours later...

After intensive tests and writing even own uefi bootloader where I checked successfully just the uart functionality I discovered that adding below while loop for serial_iskey function solve more or less my issue and ipxe is very responsive in receiving keystrokes.

I added timeout to give rest of the part of ipxe ability to execute other tasks, otherwise it seams to restart itself after some period of time.

Unfortunate, it's more an ugly workaround then a real fix, as I assume the intention of serial_iskey is to return as fast as possible and do blocking call in serial_getchar instead.

 * Check for character ready to read from serial console
 *
 * @ret True            Character available to read
 * @ret False           No character available to read
 */
static int serial_iskey ( void ) {

        /* Do nothing if we have no UART */
        if ( ! serial_console.base )
                return 0;

        // Wait a bit for keystroke, but not forever.
        int timeout = 500000;
        while (! uart_data_ready ( &serial_console )) {
            // Still no data, so give up, maybe next time.
            if (--timeout == 0) {
                break;
            }
        }

        /* Check UART */
        return uart_data_ready ( &serial_console );
}

Regards.

@mcb30
Copy link
Member

mcb30 commented Apr 15, 2024

Unfortunate, it's more an ugly workaround then a real fix, as I assume the intention of serial_iskey is to return as fast as possible and do blocking call in serial_getchar instead.

Yes, this is correct. The console .iskey() methods must be non-blocking.

 * Check for character ready to read from serial console
 *
 * @ret True            Character available to read
 * @ret False           No character available to read
 */
static int serial_iskey ( void ) {

        /* Do nothing if we have no UART */
        if ( ! serial_console.base )
                return 0;

        // Wait a bit for keystroke, but not forever.
        int timeout = 500000;
        while (! uart_data_ready ( &serial_console )) {
            // Still no data, so give up, maybe next time.
            if (--timeout == 0) {
                break;
            }
        }

        /* Check UART */
        return uart_data_ready ( &serial_console );
}

My guess is that the UEFI firmware is already driving the serial port, and so when you have CONSOLE_SERIAL also enabled you are effectively causing two pieces of code to compete with each other to see who can read the available byte first. By adding your tight loop in serial_iskey(), you increase iPXE's chances of winning that race.

Usually when UEFI drives the serial port, it acts as an extra console port. It's possible that your firmware is not doing this, and that Synology has built their firmware to treat the serial port as e.g. a debugger port.

Once Linux starts up, the UEFI firmware will stop driving the serial port, which explains why everything is fine once you start up Linux.

It's not sensible to have two bits of code competing over the serial port. You could try vetoing the UEFI firmware's serial port driver (via the mechanism in efi_veto.c) to see if everything starts working once you've forcibly unloaded (or disconnected) the UEFI firmware from the serial port.

@hetii
Copy link
Author

hetii commented Apr 15, 2024

@mcb30 Hmm...
ok, your explanation makes sense, but from below logs I don't see any terminal or serial type of efi driver that can be unload:

<0-Y>EFI PciRoot(0x0)/Pci(0x16,0x0)/USB(0x0,0x0)/USB(0x0,0x0)/USB(0x3,0x0)/HD(1,MBR,0x5532333D,0x3F,0x7D43) has no SNP instance: Error 0x7f53e083 (https://ipxe.org/7f53e083)
IMAGE SynoBootLoader.ipxe at [799a0e2c,799a156b) registered
EFIIMAGE SynoBootLoader.ipxe could not load: Error 0x7f048183 (https://ipxe.org/7f048183)
IMAGE SynoBootLoader.ipxe is not EFI: Error 0x7f048183 (https://ipxe.org/7f048183)
EFIIMAGE SynoBootLoader.ipxe missing MZ signature
IMAGE SynoBootLoader.ipxe is not EFIPE: Exec format error (https://ipxe.org/2e048081)
IMAGE SynoBootLoader.ipxe is script
iPXE initialising devices...INIT startup efi_tick...
EFI timer started at 32 ticks per second
INIT startup devices...
Adding 3c509 root bus
Adding EFI root bus
EFIDRV connecting our drivers
EFIPCI 0000:00:00.0 (8086:1f0c class 060000) has no driver
EFIPCI 0000:00:01.0 type 01 is not type 00
EFIPCI 0000:00:02.0 type 01 is not type 00
EFIPCI 0000:02:00.0 (1095:3132 class 010600) has no driver
EFIPCI 0000:00:03.0 type 01 is not type 00
EFIPCI 0000:00:04.0 type 01 is not type 00
EFIPCI 0000:04:00.0 (1b6f:7052 class 0c0330) has no driver
EFIPCI 0000:00:0e.0 (8086:1f14 class 060000) has no driver
EFIPCI 0000:00:0f.0 (8086:1f16 class 080600) has no driver
EFIPCI 0000:00:13.0 (8086:1f15 class 088000) has no driver
EFIPCI 0000:00:14.0 (8086:1f41 class 020000) has driver "i354"
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x0) has driver "PCI"
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x0) before disconnecting:
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x0) PciIo at 0x7c6dc3a8
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x0) PciIo opened 9x (H)<0><1><2><3-[Empty debug directory entry]N><4><5-Y> by DxeCore(?) for <NULL>
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x0) PciIo opened 2x (G)<0><1-Y> by Storage Security Command Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x0) PciIo opened 2x (T)<0><1-Y> by ISA Bus Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x0) PciIo opened 2x (G)<0><1-Y> by AHCI Bus Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x0) DevicePath at 0x7c6e3518
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x0) DevicePath opened 48x (H)<0><1><2><3-[Empty debug directory entry]N><4><5-Y> by DxeCore(?) for <NULL>
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x0) DevicePath opened 2x (T)<0><1-Y> by Platform Console Management Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x0) DevicePath opened 2x (T)<0><1-Y> by Platform Console Management Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x0) DevicePath opened 2x (T)<0><1><2-Y> by Simple Network Protocol Driver
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x0) disconnecting existing drivers
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x0) after disconnecting:
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x0) PciIo at 0x7c6dc3a8
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x0) PciIo opened 10x (H)<0><1><2><3-[Empty debug directory entry]N><4><5-Y> by DxeCore(?) for <NULL>
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x0) PciIo opened 2x (G)<0><1-Y> by Storage Security Command Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x0) PciIo opened 2x (T)<0><1-Y> by ISA Bus Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x0) PciIo opened 2x (G)<0><1-Y> by AHCI Bus Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x0) DevicePath at 0x7c6e3518
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x0) DevicePath opened 49x (H)<0><1><2><3-[Empty debug directory entry]N><4><5-Y> by DxeCore(?) for <NULL>
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x0) DevicePath opened 2x (T)<0><1-Y> by Platform Console Management Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x0) DevicePath opened 2x (T)<0><1-Y> by Platform Console Management Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x0) DevicePath opened 2x (T)<0><1><2-Y> by Simple Network Protocol Driver
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x0) connecting new drivers
EFIPCI 0000:00:14.0 (8086:1f41 class 020000) has driver "i354"
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x0) has driver "PCI"
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x0) DRIVER_START
EFIPCI 0000:00:14.0 (8086:1f41 class 020000) has driver "i354"
0000:00:14.0 (8086:1f41) has driver "i354"
0000:00:14.0 has mem 80280000 io 20c0 irq 255
0000:00:14.0 latency timer is unreasonably low at 0. Setting to 32.
INTEL 0x79a05d18 MAC+PHY reset (08100241/80382780 was 08100241/80382780)
INTEL 0x79a05d18 has autoloaded MAC address 00:a0:c9:00:00:00
NETDEV net0 registered (phys 0000:00:14.0 hwaddr 00:a0:c9:00:00:00)
<0-Y>EFIDEV PciRoot(0x0)/Pci(0x14,0x0) added child<0-Y> PciRoot(0x0)/Pci(0x14,0x0)/MAC(00A0C9000000,0x1)
<0-Y>EFIDEV PciRoot(0x0)/Pci(0x14,0x0)/MAC(00A0C9000000,0x1) added child<0-Y> PciRoot(0x0)/Pci(0x14,0x0)/MAC(00A0C9000000,0x1)/VenHw(850DA5CB-5C6D-F244-97D7-6B1F4041BD97)
INTEL 0x79a05d18 link status is 80382780
NETDEV net0 link is down: Down (https://ipxe.org/38086193)
EFIPCI 0000:00:14.0 using driver "i354"
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x0) using driver "PCI"
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x0) after connecting:
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x0) PciIo at 0x7c6dc3a8
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x0) PciIo opened 11x (H)<0><1><2><3-[Empty debug directory entry]N><4><5-Y> by DxeCore(?) for <NULL>
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x0) PciIo opened 3x (G)<0><1-Y> by Storage Security Command Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x0) PciIo opened 3x (T)<0><1-Y> by ISA Bus Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x0) PciIo opened 3x (G)<0><1-Y> by AHCI Bus Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x0) PciIo opened 1x (DX)<0><1-Y> by ipxe.efi
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x0) DevicePath at 0x7c6e3518
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x0) DevicePath opened 53x (H)<0><1><2><3-[Empty debug directory entry]N><4><5-Y> by DxeCore(?) for <NULL>
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x0) DevicePath opened 3x (T)<0><1-Y> by Platform Console Management Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x0) DevicePath opened 3x (T)<0><1-Y> by Platform Console Management Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x0) DevicePath opened 3x (T)<0><1><2-Y> by Simple Network Protocol Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x0) DevicePath opened 1x (C)<0><1-Y> by ipxe.efi<0-Y> for PciRoot(0x0)/Pci(0x14,0x0)/MAC(00A0C9000000,0x1)
EFIPCI 0000:00:14.1 (8086:1f41 class 020000) has driver "i354"
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x1) has driver "PCI"
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x1) before disconnecting:
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x1) PciIo at 0x7c6dc028
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x1) PciIo opened 9x (H)<0><1><2><3-[Empty debug directory entry]N><4><5-Y> by DxeCore(?) for <NULL>
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x1) PciIo opened 2x (G)<0><1-Y> by Storage Security Command Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x1) PciIo opened 2x (T)<0><1-Y> by ISA Bus Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x1) PciIo opened 2x (G)<0><1-Y> by AHCI Bus Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x1) DevicePath at 0x7c6e3618
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x1) DevicePath opened 49x (H)<0><1><2><3-[Empty debug directory entry]N><4><5-Y> by DxeCore(?) for <NULL>
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x1) DevicePath opened 2x (T)<0><1-Y> by Platform Console Management Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x1) DevicePath opened 2x (T)<0><1-Y> by Platform Console Management Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x1) DevicePath opened 2x (T)<0><1><2-Y> by Simple Network Protocol Driver
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x1) disconnecting existing drivers
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x1) after disconnecting:
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x1) PciIo at 0x7c6dc028
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x1) PciIo opened 10x (H)<0><1><2><3-[Empty debug directory entry]N><4><5-Y> by DxeCore(?) for <NULL>
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x1) PciIo opened 2x (G)<0><1-Y> by Storage Security Command Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x1) PciIo opened 2x (T)<0><1-Y> by ISA Bus Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x1) PciIo opened 2x (G)<0><1-Y> by AHCI Bus Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x1) DevicePath at 0x7c6e3618
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x1) DevicePath opened 50x (H)<0><1><2><3-[Empty debug directory entry]N><4><5-Y> by DxeCore(?) for <NULL>
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x1) DevicePath opened 2x (T)<0><1-Y> by Platform Console Management Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x1) DevicePath opened 2x (T)<0><1-Y> by Platform Console Management Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x1) DevicePath opened 2x (T)<0><1><2-Y> by Simple Network Protocol Driver
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x1) connecting new drivers
EFIPCI 0000:00:14.1 (8086:1f41 class 020000) has driver "i354"
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x1) has driver "PCI"
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x1) DRIVER_START
EFIPCI 0000:00:14.1 (8086:1f41 class 020000) has driver "i354"
0000:00:14.1 (8086:1f41) has driver "i354"
0000:00:14.1 has mem 802a0000 io 20a0 irq 255
0000:00:14.1 latency timer is unreasonably low at 0. Setting to 32.
INTEL 0x79a06a78 MAC+PHY reset (08100241/80382784 was 08100241/80382784)
INTEL 0x79a06a78 has autoloaded MAC address 00:a0:c9:00:00:01
NETDEV net1 registered (phys 0000:00:14.1 hwaddr 00:a0:c9:00:00:01)
<0-Y>EFIDEV PciRoot(0x0)/Pci(0x14,0x1) added child<0-Y> PciRoot(0x0)/Pci(0x14,0x1)/MAC(00A0C9000001,0x1)
<0-Y>EFIDEV PciRoot(0x0)/Pci(0x14,0x1)/MAC(00A0C9000001,0x1) added child<0-Y> PciRoot(0x0)/Pci(0x14,0x1)/MAC(00A0C9000001,0x1)/VenHw(07454A6A-FF11-51DD-27CD-AD2522E4B35F)
INTEL 0x79a06a78 link status is 80382784
NETDEV net1 link is down: Down (https://ipxe.org/38086193)
EFIPCI 0000:00:14.1 using driver "i354"
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x1) using driver "PCI"
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x1) after connecting:
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x1) PciIo at 0x7c6dc028
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x1) PciIo opened 11x (H)<0><1><2><3-[Empty debug directory entry]N><4><5-Y> by DxeCore(?) for <NULL>
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x1) PciIo opened 3x (G)<0><1-Y> by Storage Security Command Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x1) PciIo opened 3x (T)<0><1-Y> by ISA Bus Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x1) PciIo opened 3x (G)<0><1-Y> by AHCI Bus Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x1) PciIo opened 1x (DX)<0><1-Y> by ipxe.efi
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x1) DevicePath at 0x7c6e3618
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x1) DevicePath opened 54x (H)<0><1><2><3-[Empty debug directory entry]N><4><5-Y> by DxeCore(?) for <NULL>
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x1) DevicePath opened 3x (T)<0><1-Y> by Platform Console Management Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x1) DevicePath opened 3x (T)<0><1-Y> by Platform Console Management Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x1) DevicePath opened 3x (T)<0><1><2-Y> by Simple Network Protocol Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x1) DevicePath opened 1x (C)<0><1-Y> by ipxe.efi<0-Y> for PciRoot(0x0)/Pci(0x14,0x1)/MAC(00A0C9000001,0x1)
EFIPCI 0000:00:14.2 (8086:1f41 class 020000) has driver "i354"
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x2) has driver "PCI"
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x2) before disconnecting:
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x2) PciIo at 0x7c6dbaa8
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x2) PciIo opened 9x (H)<0><1><2><3-[Empty debug directory entry]N><4><5-Y> by DxeCore(?) for <NULL>
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x2) PciIo opened 2x (G)<0><1-Y> by Storage Security Command Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x2) PciIo opened 2x (T)<0><1-Y> by ISA Bus Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x2) PciIo opened 2x (G)<0><1-Y> by AHCI Bus Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x2) DevicePath at 0x7c6e3698
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x2) DevicePath opened 50x (H)<0><1><2><3-[Empty debug directory entry]N><4><5-Y> by DxeCore(?) for <NULL>
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x2) DevicePath opened 2x (T)<0><1-Y> by Platform Console Management Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x2) DevicePath opened 2x (T)<0><1-Y> by Platform Console Management Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x2) DevicePath opened 2x (T)<0><1><2-Y> by Simple Network Protocol Driver
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x2) disconnecting existing drivers
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x2) after disconnecting:
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x2) PciIo at 0x7c6dbaa8
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x2) PciIo opened 10x (H)<0><1><2><3-[Empty debug directory entry]N><4><5-Y> by DxeCore(?) for <NULL>
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x2) PciIo opened 2x (G)<0><1-Y> by Storage Security Command Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x2) PciIo opened 2x (T)<0><1-Y> by ISA Bus Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x2) PciIo opened 2x (G)<0><1-Y> by AHCI Bus Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x2) DevicePath at 0x7c6e3698
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x2) DevicePath opened 51x (H)<0><1><2><3-[Empty debug directory entry]N><4><5-Y> by DxeCore(?) for <NULL>
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x2) DevicePath opened 2x (T)<0><1-Y> by Platform Console Management Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x2) DevicePath opened 2x (T)<0><1-Y> by Platform Console Management Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x2) DevicePath opened 2x (T)<0><1><2-Y> by Simple Network Protocol Driver
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x2) connecting new drivers
EFIPCI 0000:00:14.2 (8086:1f41 class 020000) has driver "i354"
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x2) has driver "PCI"
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x2) DRIVER_START
EFIPCI 0000:00:14.2 (8086:1f41 class 020000) has driver "i354"
0000:00:14.2 (8086:1f41) has driver "i354"
0000:00:14.2 has mem 802c0000 io 2080 irq 255
0000:00:14.2 latency timer is unreasonably low at 0. Setting to 32.
INTEL 0x79a08858 MAC+PHY reset (08100241/80382788 was 08100241/80382788)
INTEL 0x79a08858 has autoloaded MAC address 00:a0:c9:00:00:02
NETDEV net2 registered (phys 0000:00:14.2 hwaddr 00:a0:c9:00:00:02)
<0-Y>EFIDEV PciRoot(0x0)/Pci(0x14,0x2) added child<0-Y> PciRoot(0x0)/Pci(0x14,0x2)/MAC(00A0C9000002,0x1)
<0-Y>EFIDEV PciRoot(0x0)/Pci(0x14,0x2)/MAC(00A0C9000002,0x1) added child<0-Y> PciRoot(0x0)/Pci(0x14,0x2)/MAC(00A0C9000002,0x1)/VenHw(0B34DBA7-74D7-7D9E-F59C-A4D8E5F595F6)
INTEL 0x79a08858 link status is 80382788
NETDEV net2 link is down: Down (https://ipxe.org/38086193)
EFIPCI 0000:00:14.2 using driver "i354"
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x2) using driver "PCI"
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x2) after connecting:
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x2) PciIo at 0x7c6dbaa8
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x2) PciIo opened 11x (H)<0><1><2><3-[Empty debug directory entry]N><4><5-Y> by DxeCore(?) for <NULL>
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x2) PciIo opened 3x (G)<0><1-Y> by Storage Security Command Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x2) PciIo opened 3x (T)<0><1-Y> by ISA Bus Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x2) PciIo opened 3x (G)<0><1-Y> by AHCI Bus Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x2) PciIo opened 1x (DX)<0><1-Y> by ipxe.efi
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x2) DevicePath at 0x7c6e3698
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x2) DevicePath opened 55x (H)<0><1><2><3-[Empty debug directory entry]N><4><5-Y> by DxeCore(?) for <NULL>
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x2) DevicePath opened 3x (T)<0><1-Y> by Platform Console Management Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x2) DevicePath opened 3x (T)<0><1-Y> by Platform Console Management Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x2) DevicePath opened 3x (T)<0><1><2-Y> by Simple Network Protocol Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x2) DevicePath opened 1x (C)<0><1-Y> by ipxe.efi<0-Y> for PciRoot(0x0)/Pci(0x14,0x2)/MAC(00A0C9000002,0x1)
EFIPCI 0000:00:14.3 (8086:1f41 class 020000) has driver "i354"
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x3) has driver "PCI"
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x3) before disconnecting:
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x3) PciIo at 0x7c6db728
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x3) PciIo opened 9x (H)<0><1><2><3-[Empty debug directory entry]N><4><5-Y> by DxeCore(?) for <NULL>
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x3) PciIo opened 2x (G)<0><1-Y> by Storage Security Command Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x3) PciIo opened 2x (T)<0><1-Y> by ISA Bus Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x3) PciIo opened 2x (G)<0><1-Y> by AHCI Bus Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x3) DevicePath at 0x7c6e3718
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x3) DevicePath opened 51x (H)<0><1><2><3-[Empty debug directory entry]N><4><5-Y> by DxeCore(?) for <NULL>
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x3) DevicePath opened 2x (T)<0><1-Y> by Platform Console Management Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x3) DevicePath opened 2x (T)<0><1-Y> by Platform Console Management Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x3) DevicePath opened 2x (T)<0><1><2-Y> by Simple Network Protocol Driver
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x3) disconnecting existing drivers
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x3) after disconnecting:
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x3) PciIo at 0x7c6db728
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x3) PciIo opened 10x (H)<0><1><2><3-[Empty debug directory entry]N><4><5-Y> by DxeCore(?) for <NULL>
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x3) PciIo opened 2x (G)<0><1-Y> by Storage Security Command Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x3) PciIo opened 2x (T)<0><1-Y> by ISA Bus Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x3) PciIo opened 2x (G)<0><1-Y> by AHCI Bus Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x3) DevicePath at 0x7c6e3718
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x3) DevicePath opened 52x (H)<0><1><2><3-[Empty debug directory entry]N><4><5-Y> by DxeCore(?) for <NULL>
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x3) DevicePath opened 2x (T)<0><1-Y> by Platform Console Management Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x3) DevicePath opened 2x (T)<0><1-Y> by Platform Console Management Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x3) DevicePath opened 2x (T)<0><1><2-Y> by Simple Network Protocol Driver
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x3) connecting new drivers
EFIPCI 0000:00:14.3 (8086:1f41 class 020000) has driver "i354"
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x3) has driver "PCI"
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x3) DRIVER_START
EFIPCI 0000:00:14.3 (8086:1f41 class 020000) has driver "i354"
0000:00:14.3 (8086:1f41) has driver "i354"
0000:00:14.3 has mem 802e0000 io 2060 irq 255
0000:00:14.3 latency timer is unreasonably low at 0. Setting to 32.
INTEL 0x79a0a6d8 MAC+PHY reset (08100241/8038278c was 08100241/8038278c)
INTEL 0x79a0a6d8 has autoloaded MAC address 00:a0:c9:00:00:03
NETDEV net3 registered (phys 0000:00:14.3 hwaddr 00:a0:c9:00:00:03)
<0-Y>EFIDEV PciRoot(0x0)/Pci(0x14,0x3) added child<0-Y> PciRoot(0x0)/Pci(0x14,0x3)/MAC(00A0C9000003,0x1)
<0-Y>EFIDEV PciRoot(0x0)/Pci(0x14,0x3)/MAC(00A0C9000003,0x1) added child<0-Y> PciRoot(0x0)/Pci(0x14,0x3)/MAC(00A0C9000003,0x1)/VenHw(04B68345-5171-7A6E-C982-804DBA1AD71D)
INTEL 0x79a0a6d8 link status is 8038278c
NETDEV net3 link is down: Down (https://ipxe.org/38086193)
EFIPCI 0000:00:14.3 using driver "i354"
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x3) using driver "PCI"
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x3) after connecting:
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x3) PciIo at 0x7c6db728
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x3) PciIo opened 11x (H)<0><1><2><3-[Empty debug directory entry]N><4><5-Y> by DxeCore(?) for <NULL>
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x3) PciIo opened 3x (G)<0><1-Y> by Storage Security Command Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x3) PciIo opened 3x (T)<0><1-Y> by ISA Bus Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x3) PciIo opened 3x (G)<0><1-Y> by AHCI Bus Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x3) PciIo opened 1x (DX)<0><1-Y> by ipxe.efi
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x3) DevicePath at 0x7c6e3718
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x3) DevicePath opened 56x (H)<0><1><2><3-[Empty debug directory entry]N><4><5-Y> by DxeCore(?) for <NULL>
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x3) DevicePath opened 3x (T)<0><1-Y> by Platform Console Management Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x3) DevicePath opened 3x (T)<0><1-Y> by Platform Console Management Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x3) DevicePath opened 3x (T)<0><1><2-Y> by Simple Network Protocol Driver
<0-Y>HANDLE PciRoot(0x0)/Pci(0x14,0x3) DevicePath opened 1x (C)<0><1-Y> by ipxe.efi<0-Y> for PciRoot(0x0)/Pci(0x14,0x3)/MAC(00A0C9000003,0x1)
EFIPCI 0000:00:16.0 (8086:1f2c class 0c0320) has no driver
EFIPCI 0000:00:17.0 (8086:1f22 class 010601) has no driver
EFIPCI 0000:00:18.0 (8086:1f32 class 010601) has no driver
EFIPCI 0000:00:1f.0 (8086:1f38 class 060100) has no driver
EFIPCI 0000:00:1f.3 (8086:1f3c class 0c0500) has no driver
Adding EISA root bus
Failed to add EISA root bus: No such device (https://ipxe.org/2c004087)
Adding Hyper-V root bus
Failed to add Hyper-V root bus: No such device (https://ipxe.org/2c834087)
Adding ISA root bus
Adding ISAPnP root bus
Adding MCA root bus
Adding PCI root bus
INIT startup efi_autoexec...
INIT startup efi_cmdline...
INIT startup rbg...
INIT startup cachedhcp...
INIT startup complete
ok



iPXE 1.21.1+ (g390bc) -- Open Source Network Boot Firmware -- https://ipxe.org
Features: DNS HTTP iSCSI TFTP VLAN SRP AoE EFI Menu
IMAGE SynoBootLoader.ipxe unregistered

And unload part after exit:


 IMAGE SynoBootLoader.ipxe at [799a0e2c,799a156b) registered
INIT shutdown cachedhcp...
INIT shutdown tcp...
INIT shutdown rbg...
INIT shutdown devices...
Removed PCI root bus
Removed MCA root bus
Removed ISAPnP root bus
Removed ISA root bus
EFIDRV disconnecting our drivers
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x0) DRIVER_STOP<0-Y> child PciRoot(0x0)/Pci(0x14,0x0)/MAC(00A0C9000000,0x1)
<0-Y>EFIDEV PciRoot(0x0)/Pci(0x14,0x0)/MAC(00A0C9000000,0x1) removed child<0-Y> PciRoot(0x0)/Pci(0x14,0x0)/MAC(00A0C9000000,0x1)/VenHw(04B772C2-F3E9-8D51-15F6-F0D12ADD7163)
<0-Y>EFIDEV PciRoot(0x0)/Pci(0x14,0x0) removed child<0-Y> PciRoot(0x0)/Pci(0x14,0x0)/MAC(00A0C9000000,0x1)
NETDEV net0 unregistered
INTEL 0x79a05d18 MAC+PHY reset (08100241/80382780 was 08100241/80382780)
0000:00:14.0 removed
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x0) DRIVER_STOP
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x1) DRIVER_STOP<0-Y> child PciRoot(0x0)/Pci(0x14,0x1)/MAC(00A0C9000001,0x1)
<0-Y>EFIDEV PciRoot(0x0)/Pci(0x14,0x1)/MAC(00A0C9000001,0x1) removed child<0-Y> PciRoot(0x0)/Pci(0x14,0x1)/MAC(00A0C9000001,0x1)/VenHw(E7D38C44-8C9A-E00A-9444-CC17034A50DD)
<0-Y>EFIDEV PciRoot(0x0)/Pci(0x14,0x1) removed child<0-Y> PciRoot(0x0)/Pci(0x14,0x1)/MAC(00A0C9000001,0x1)
NETDEV net1 unregistered
INTEL 0x79a06a78 MAC+PHY reset (08100241/80382784 was 08100241/80382784)
0000:00:14.1 removed
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x1) DRIVER_STOP
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x2) DRIVER_STOP<0-Y> child PciRoot(0x0)/Pci(0x14,0x2)/MAC(00A0C9000002,0x1)
<0-Y>EFIDEV PciRoot(0x0)/Pci(0x14,0x2)/MAC(00A0C9000002,0x1) removed child<0-Y> PciRoot(0x0)/Pci(0x14,0x2)/MAC(00A0C9000002,0x1)/VenHw(5BCCBD39-27AB-7A59-AF26-CE687419D371)
<0-Y>EFIDEV PciRoot(0x0)/Pci(0x14,0x2) removed child<0-Y> PciRoot(0x0)/Pci(0x14,0x2)/MAC(00A0C9000002,0x1)
NETDEV net2 unregistered
INTEL 0x79a08858 MAC+PHY reset (08100241/80382788 was 08100241/80382788)
0000:00:14.2 removed
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x2) DRIVER_STOP
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x3) DRIVER_STOP<0-Y> child PciRoot(0x0)/Pci(0x14,0x3)/MAC(00A0C9000003,0x1)
<0-Y>EFIDEV PciRoot(0x0)/Pci(0x14,0x3)/MAC(00A0C9000003,0x1) removed child<0-Y> PciRoot(0x0)/Pci(0x14,0x3)/MAC(00A0C9000003,0x1)/VenHw(23459B41-3C71-4CC7-C8B2-FDCF8C481847)
<0-Y>EFIDEV PciRoot(0x0)/Pci(0x14,0x3) removed child<0-Y> PciRoot(0x0)/Pci(0x14,0x3)/MAC(00A0C9000003,0x1)
NETDEV net3 unregistered
INTEL 0x79a0a6d8 MAC+PHY reset (08100241/8038278c was 08100241/8038278c)
0000:00:14.3 removed
<0-Y>EFIDRV PciRoot(0x0)/Pci(0x14,0x3) DRIVER_STOP
Removed EFI root bus
Removed 3c509 root bus
INIT shutdown efi_tick...
EFI timer stopped
INIT shutdown serial...
INIT shutdown heap...
INIT shutdown efi_watchdog...
INIT shutdown complete
EFI image unloading
EFIDRV disconnecting our drivers
EFI image unloaded
EFIDRV reconnecting old drivers

Can I veto somehow all drivers and keep just serial console to check your theory?

Moreover, just remind you in the orginal grub loader the console works fine for output and input, so before even loading linux kernel, where it's fine too.

B.R.

@mcb30
Copy link
Member

mcb30 commented Apr 15, 2024

@mcb30 Hmm... ok, your explanation makes sense, but from below logs I don't see any terminal or serial type of efi driver that can be unload:

Build with DEBUG=efi_veto:3 and you'll see a list of existent drivers (using the same names that you'd see in the UEFI shell using the drivers command).

Moreover, just remind you in the orginal grub loader the console works fine for output and input, so before even loading linux kernel, where it's fine too.

As a sanity check: is this using a BIOS version of GRUB? You mentioned grub4dos, which suggests that you were booting the NAS in "legacy" BIOS mode.

@hetii
Copy link
Author

hetii commented Apr 16, 2024

@mcb30 BINGO!

Below I had such driver list where I vetoed Serial Terminal Driver driver.
After this step uart issue gone, pull request is here #1193.

I wonder also about Graphics Console Driver or Console Splitter Driver but not sure if they are somehow related to Serial Terminal Driver driver.

EFIVETO manufacturer is "Insyde"
<0><1-Y>EFIVETO checking ipxe.efi
<0><1-Y>EFIVETO checking UEFI Usb OHCI Driver
<0><1-Y>EFIVETO checking Usb Mouse Driver
<0><1-Y>EFIVETO checking Usb Keyboard Driver
<0><1-Y>EFIVETO checking Usb Bus Driver
<0><1-Y>EFIVETO checking UEFI Usb EHCI Driver
<0><1-Y>EFIVETO checking PCI Bus Driver
<0><1-Y>EFIVETO checking Pch Smbus 2.0 Driver
<0><1-Y>EFIVETO checking PCH Serial ATA Controller Initialization Driver
<0><1-Y>EFIVETO checking BIOS[INT16] Keyboard Driver
<0><1><2-Y>EFIVETO checking UEFI PXE Base Code Driver
<0><1><2-Y>EFIVETO checking UEFI PXE Base Code Driver
<0><1><2-Y>EFIVETO checking MTFTP6 Network Service Driver
<0><1><2-Y>EFIVETO checking DHCP6 Protocol Driver
<0><1><2-Y>EFIVETO checking UDP6 Network Service Driver
<0><1><2-Y>EFIVETO checking IP6 Network Service Driver
<0><1><2-Y>EFIVETO checking ARP Network Service Driver
<0><1><2-Y>EFIVETO checking MTFTP4 Network Service
<0><1><2-Y>EFIVETO checking DHCP Protocol Driver
<0><1><2-Y>EFIVETO checking UDP Network Service Driver
<0><1><2-Y>EFIVETO checking IP4 CONFIG Network Service Driver
<0><1><2-Y>EFIVETO checking IP4 Network Service Driver
<0><1><2-Y>EFIVETO checking MNP Network Service Driver
<0><1><2-Y>EFIVETO checking Simple Network Protocol Driver
<0><1-Y>EFIVETO checking Partition Driver(MBR/GPT/El Torito)
<0><1-Y>EFIVETO checking Vga Driver Policy
<0><1-Y>EFIVETO checking Graphics Console Driver
<0><1-Y>EFIVETO checking Console Splitter Driver
<0><1-Y>EFIVETO checking Console Splitter Driver
<0><1-Y>EFIVETO checking Console Splitter Driver
<0><1-Y>EFIVETO checking Console Splitter Driver
<0><1-Y>EFIVETO checking Console Splitter Driver
<0><1-Y>EFIVETO checking Usb Mass Storage Driver
<0><1-Y>EFIVETO checking PS/2 Mouse Driver
<0><1-Y>EFIVETO checking PS/2 Keyboard Driver
<0><1-Y>EFIVETO checking ISA Serial Driver
<0><1-Y>EFIVETO checking FAT File System Driver
<0><1-Y>EFIVETO checking VGA Class Driver
<0><1-Y>EFIVETO checking ISA Bus Driver
<0><1-Y>EFIVETO checking Generic Disk I/O Driver
<0><1-Y>EFIVETO checking Platform Console Management Driver
<0><1-Y>EFIVETO checking Platform Console Management Driver
<0><1-Y>EFIVETO checking PCI IDE/ATAPI Bus Driver
<0><1><2><3-[Empty debug directory entry]N><4-Y>EFIVETO checking MemoryMapped(0xB,0x78C2F000,0x7924DFFF)/FvFile(38A0EC22-FBE7-4911-8BC1-176E0D6C1DBD)
<0><1-Y>EFIVETO checking PCI Serial Driver
<0><1-Y>EFIVETO checking Serial Terminal Driver
<0><1-Y>EFIVETO Serial Terminal Driver is vetoed (Insyde Serial Terminal Driver)
<0><1-Y>EFIVETO Serial Terminal Driver could not unload<0><1-Y> Serial Terminal Driver: Error 0x7f52e083 (https://ipxe.org/7f52e083)
<0><1-Y>EFIVETO Serial Terminal Driver disconnected all handles
<0><1-Y>EFIVETO Serial Terminal Driver uninstalled driver binding protocol
<0><1-Y>EFIVETO Serial Terminal Driver closed all remaining handles
<0><1-Y>EFIVETO Serial Terminal Driver forcibly removed
<0><1-Y>EFIVETO checking AHCI Bus Driver
<0><1-Y>EFIVETO checking Storage Security Command Driver

I mention about grub4dos as a source for uart implementation, but in fact the Synology NAS use bootloader from path EFI/boot/SynoBootLoader.efi and it's a modified version of grub 0.97.

BTW as I end up with such long debug arguments list:
make bin-x86_64-efi/ipxe.efi DEBUG=efi_wrap:3,efi_veto:3,efi_debug:3,efi_timer:3,efi_autoboot:3,image:3,image_cmd:3,efi_watchdog:3,init:3,runtime:3,device:3,efi_image:3,intel:3,intelx:3,netdevice:3,serial:3,console:3,efi_utils:3,snp:3,nii:3,snponly:3,snpnet:3,efi_driver:3,efi_init:3,efi_pci:3,pci:3,ice:3 EMBED=SynoBootLoader.ipxe -j 32

Is there any shortcut method to enable all in given verbosity?

I think also that the documentation in https://ipxe.org/docs should be updated regarding all that efi vetoed functionality and settings about deep debugging aspect as I burned a lot of time before I get this knowledge.

Thank you very much for helping me out.

@mcb30
Copy link
Member

mcb30 commented Apr 16, 2024

@mcb30 BINGO!

Below I had such driver list where I vetoed Serial Terminal Driver driver. After this step uart issue gone, pull request is here #1193.

Great! Will continue discussion on the PR.

BTW as I end up with such long debug arguments list: make bin-x86_64-efi/ipxe.efi DEBUG=efi_wrap:3,efi_veto:3,efi_debug:3,efi_timer:3,efi_autoboot:3,image:3,image_cmd:3,efi_watchdog:3,init:3,runtime:3,device:3,efi_image:3,intel:3,intelx:3,netdevice:3,serial:3,console:3,efi_utils:3,snp:3,nii:3,snponly:3,snpnet:3,efi_driver:3,efi_init:3,efi_pci:3,pci:3,ice:3 EMBED=SynoBootLoader.ipxe -j 32

Is there any shortcut method to enable all in given verbosity?

No, and there are some objects for which you'll typically get so much output at level 3 that it makes everything unusable (e.g. one log message per packet, for some parts of the network stack, which is unusable if you have to first download a large file in order to reach the issue of interest).

I think also that the documentation in https://ipxe.org/docs should be updated regarding all that efi vetoed functionality and settings about deep debugging aspect as I burned a lot of time before I get this knowledge.

Those are quite obscure details that will be irrelevant to the vast majority of people, so it's difficult to justify spending the time to write up the documentation (and it's definitely not the sort of thing that should appear on the front page).

@hetii
Copy link
Author

hetii commented Apr 16, 2024

@mcb30
I see your point and I'm aware that most majority of people don't need such information but maybe, a new section for contributors with such detailed tricks & tips somehow help to contribute the project, it's just open idea.

@mcb30
Copy link
Member

mcb30 commented Apr 16, 2024

@mcb30 I see your point and I'm aware that most majority of people don't need such information but maybe, a new section for contributors with such detailed tricks & tips somehow help to contribute the project, it's just open idea.

Feel free to register an account and contribute a page such as https://ipxe.org/appnote/efiveto - other people have contributed detailed internal documents such as https://ipxe.org/appnote/interfaces 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants