Re: [PATCHv2] EFI - PXE - include details from proxy (altserviceboot) offer when available (resend)
В Tue, 11 Feb 2014 02:20:19 +
Mroczek, Joseph T joseph.t.mroc...@intel.com пишет:
Updated efi api.h with more of pxe mode structure. Definitions from uEFI
specification v2.4 errata A.
I had to update the typedef for grub_efi_ip_address_t, but it did not seem to
be used anywhere at this point.
There is a minor issue that it is still not capturing the file name. It is
beyond my skill level to track down exactly why and fix it safely.
Please let me know if there is anything more I can do.
~joe
diff -Naur grub-2.02~beta2/grub-core/net/drivers/efi/efinet.c
grub-2.02~beta2-bug41488-jtm/grub-core/net/drivers/efi/efinet.c
--- grub-2.02~beta2/grub-core/net/drivers/efi/efinet.c 2013-12-24
11:29:27.0 -0500
+++ grub-2.02~beta2-bug41488-jtm/grub-core/net/drivers/efi/efinet.c
2014-02-10 20:21:29.342895600 -0500
@@ -250,6 +250,12 @@
pxe_mode-dhcp_ack,
sizeof
(pxe_mode-dhcp_ack),
1, device,
path);
+ if (pxe_mode-proxy_offer_received)
+ grub_net_configure_by_dhcp_ack (card-name, card, 0,
+ (struct
grub_net_bootp_packet *)
+
pxe_mode-proxy_offer,
+ sizeof
(pxe_mode-proxy_offer),
+ 1, device,
path);
I think these two must be reverted. According to pxe spec, data
provided by DHCP server takes precedent over data provided by DHCP
Proxy and this patch does the opposite. This should hopefully give
client valid address again.
return;
}
}
diff -Naur grub-2.02~beta2/include/grub/efi/api.h
grub-2.02~beta2-bug41488-jtm/include/grub/efi/api.h
--- grub-2.02~beta2/include/grub/efi/api.h 2013-12-24
12:04:54.0 -0500
+++ grub-2.02~beta2-bug41488-jtm/include/grub/efi/api.h 2014-02-10
20:30:32.754895600 -0500
@@ -526,7 +526,7 @@
typedef grub_uint8_t grub_efi_mac_address_t[32];
typedef grub_uint8_t grub_efi_ipv4_address_t[4];
typedef grub_uint16_t grub_efi_ipv6_address_t[8];
-typedef grub_uint8_t grub_efi_ip_address_t[8] __attribute__ ((aligned(4)));
+typedef grub_uint8_t grub_efi_ip_address_t[16] __attribute__ ((aligned(4)));
typedef grub_efi_uint64_t grub_efi_physical_address_t;
typedef grub_efi_uint64_t grub_efi_virtual_address_t;
@@ -1342,12 +1342,33 @@
typedef struct grub_efi_pxe_mode
{
- grub_uint8_t unused[52];
+ grub_uint8_t started;
+ grub_uint8_t ipv6_available;
+ grub_uint8_t ipv6_supported;
+ grub_uint8_t using_ipv6;
+ grub_uint8_t bis_supported;
+ grub_uint8_t bis_detected;
+ grub_uint8_t auto_arp;
+ grub_uint8_t send_guid;
+ grub_uint8_t dhcp_discover_valid;
+ grub_uint8_t dhcp_ack_received;
+ grub_uint8_t proxy_offer_received;
+ grub_uint8_t pxe_discover_valid;
+ grub_uint8_t pxe_reply_received;
+ grub_uint8_t pxe_bis_reply_received;
+ grub_uint8_t icmp_error_received;
+ grub_uint8_t tftp_error_received;
+ grub_uint8_t make_callbacks;
+ grub_uint8_t ttl;
+ grub_uint8_t tos;
+ grub_efi_ip_address_t station_ip;
+ grub_efi_ip_address_t subnet_mask;
grub_efi_pxe_packet_t dhcp_discover;
grub_efi_pxe_packet_t dhcp_ack;
grub_efi_pxe_packet_t proxy_offer;
grub_efi_pxe_packet_t pxe_discover;
grub_efi_pxe_packet_t pxe_reply;
+ grub_efi_pxe_packet_t pxe_bis_reply;
} grub_efi_pxe_mode_t;
typedef struct grub_efi_pxe
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
RE: [PATCHv2] EFI - PXE - include details from proxy (altserviceboot) offer when available (resend)
From: Andrey Borzenkov [mailto:arvidj...@gmail.com] Sent: Wednesday, February 12, 2014 7:59 AM В Tue, 11 Feb 2014 02:20:19 + Mroczek, Joseph T joseph.t.mroc...@intel.com пишет: Updated efi api.h with more of pxe mode structure. Definitions from uEFI specification v2.4 errata A. I had to update the typedef for grub_efi_ip_address_t, but it did not seem to be used anywhere at this point. There is a minor issue that it is still not capturing the file name. It is beyond my skill level to track down exactly why and fix it safely. Please let me know if there is anything more I can do. ~joe diff -Naur grub-2.02~beta2/grub-core/net/drivers/efi/efinet.c grub-2.02~beta2-bug41488-jtm/grub-core/net/drivers/efi/efinet.c --- grub-2.02~beta2/grub-core/net/drivers/efi/efinet.c 2013-12-24 11:29:27.0 -0500 +++ grub-2.02~beta2-bug41488-jtm/grub- core/net/drivers/efi/efinet.c +++ 2014-02-10 20:21:29.342895600 -0500 @@ -250,6 +250,12 @@ pxe_mode-dhcp_ack, sizeof (pxe_mode-dhcp_ack), 1, device, path); + if (pxe_mode-proxy_offer_received) + grub_net_configure_by_dhcp_ack (card-name, card, 0, + +(struct grub_net_bootp_packet *) + +pxe_mode-proxy_offer, + +sizeof (pxe_mode-proxy_offer), + 1, +device, path); I think these two must be reverted. According to pxe spec, data provided by DHCP server takes precedent over data provided by DHCP Proxy and this patch does the opposite. This should hopefully give client valid address again. Ok. It is going to require some reworking of grub_net_configure_by_dhcp_ack. When I tested loading the proxy offer first, it did not work. If I recall correctly, the IP address got set to 0.0.0.0. ~joe ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Passing two arguments to `terminal_*` both fail to load if the first one fails
Dear GRUB folks, using coreboot with GRUB 2 as payload built with `make default_payload` and putting `grub.cfg` into CBFS containg the lines below […] serial --unit=0 --speed=115200 terminal_input console serial terminal_output console serial […] I do not get any serial output from GRUB. Using terminal_output serial serial works. Can it be that `console` is not available in my GRUB and that results in `serial` being lost? Is that by design? Thanks, Paul signature.asc Description: This is a digitally signed message part ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: troubleshooting boot hang
On Feb 12, 2014, at 7:13 PM, Chris Murphy li...@colorremedies.com wrote: On Feb 10, 2014, at 3:40 PM, Jordan Uggla jordan.ug...@gmail.com wrote: On Thu, Feb 6, 2014 at 7:56 AM, Chris Murphy li...@colorremedies.com wrote: GRUB 2.00-25 (Fedora 20) booting a 2011 MacbookPro in EFI mode. About 1 in 4 times, I get a boot hang with a particular kernel entry. I choose the entry in grub, press return, the grub menu goes away and is replaced with a black screen with a white _ and that's it. Nothing. If I add 'set debug=all' right before the linuxefi line Can you reproduce this problem using the linux and initrd commands rather than linuxefi and initrdefi? I haven't tried it. I'm fairly certain it was a bad kernel build or rpm download because it hasn't happened with any kernel before or since; yet it has the same transient occurrence even after reinstalling regardless of Btrfs compression options. If it's useful, I'll try to reproduce with linuxefi/initrdefi and if so, try to reproduce with linux/initrd. linuxefi is a nonstandard command I believe, added in by a downstream source. It’s always better to test with standard commands here. Chris Murphy ___ Help-grub mailing list help-g...@gnu.org https://lists.gnu.org/mailman/listinfo/help-grub signature.asc Description: Message signed with OpenPGP using GPGMail ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Drive not always detected with coreboot and GRUB 2 payload
I'll need your lspci -vvnnxxx On Feb 13, 2014 7:59 AM, Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com wrote: On 12.02.2014 23:45, Paul Menzel wrote: Dear GRUB folks, using the Asus M2V-MX SE with coreboot and GRUB 2 as payload, sometimes the attached hard drive is not detected. I was not able to figure out what the reason is, I just know that I did not experience that problem using SeaBIOS as a payload. From dmesg it looks like special driver (sata_via) is used for this. No idea why it wasn't a problem for SeaBIOS. The drive is connecting using the SATA interface but the board does not support AHCI. On the GRUB command line interface, entering `ls` the drive is not shown. Please find the coreboot log of a boot where the drive was not detected attached. Thanks, Paul ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
