search for: 2560p

Hi there, I have experienced problems on HP Elitebook 2560p and 8460p latest firmware installed: 2560p 68SSU ver. F50. 08/04/2014 8460p 68SCF ver. F50. 08/04/2014 PXE boot, syslinux.efi gets perfectly TFTP transferred, it nevers asks for ldlinux.e64, and immediately gives up. I have traced the problem to: /syslinux-6.03/efi/udp.c\core_udp_open() /sysl...

> > Hi there, > I have experienced problems on HP Elitebook 2560p and 8460p > latest firmware installed: > 2560p 68SSU ver. F50. 08/04/2014 > 8460p 68SCF ver. F50. 08/04/2014 > > > PXE boot, syslinux.efi gets perfectly TFTP transferred, it nevers asks for ldlinux.e64, and immediately gives up. > > I have traced the problem to: > &...

...>>> For absolute hilarity, Google "8460p firmware EFI". Your forum post was on top for me. <<< Yes; I know... HP silence says it all; they know they're guilty ;-) http://h30434.www3.hp.com/t5/Notebook-Operating-Systems-and-Software/EFI-firmware-bug-on-HP-EliteBook-2560p-8460p/td-p/4931486 >>> > I thought of it but I do not know if there's really much to get here; > i.e. in a 4 NIC PC the parsing only involves 4 UDPv4Sb (or TCPv4Sb) handles. > Anyway it can definitely be done if necessary. It's also a question of how fast the firm...

> > Not being able to boot should probably qualify > > as good reason for HP to update the > > firmware, IMHO. > > > I agree but considering the problem appears when > PXE booting an EFI image requiring the Binding Services > of the NIC well I'm not really sure if they would pay any attention. > BTW the same failing hardware has not problem booting > MS

> Not being able to boot should probably qualify > as good reason for HP to update the > firmware, IMHO. > I agree but considering the problem appears when PXE booting an EFI image requiring the Binding Services of the NIC well I'm not really sure if they would pay any attention. BTW the same failing hardware has not problem booting MS bootmgr.efi but analyzing its code I see

> > >_ If similar newer HW can boot correctly, > >perhaps requesting from HP to > >release updated firmware versions for those systems that > >are failing might help? > > > I think we are aiming in the right direction here, > unfortunately HP (and other vendors) only update firmware bugs > when either heavily impacting functionality or security. Not

> > Today there are certain PCs i.e Elitebook 2560p, Elitebook 8460p that with > updated FW ""to the last known version"" cannot PXE boot syslinux for the > above mentioned reasons. > > We have already talked about this with Gene an there's an strategy for making > syslinux able to deal with these "weir...

>_ There >have been some patches already merged after 6.03. >Unfortunately, currently there is no _official_ >git repository *publicly* available / > accessible that would contain such patches. > So bad; Any chance to get access to an updated git repository? it takes long time debugging this kind of things. > _ The official Syslinux 6.03 uses a one-year-old (ATM) gnu-efi

...> > HP (and the rest) should just check their firmware against the "UEFI standard". > Plus FW new versions should fix more than just only critical and security issues. > Today is like this: You say you want better firmware? OK, then buy our new line of PC. > i.e. Elitebooks 2560p/8460p fail while the newer Elitebooks 2570p/8470p work > like a charm :-/ As stated before, it is my understanding that the Elitebook 2560p/8460p devices _are_compliant_ with UEFI-2.0 which stated to use an SNP directly under PXEBC while UEFI-2.1 stated to use a MNP directly under the PXEBC. P...

...m packet level transactions." >>>> > > Could this be the reason why in the past Pxebc and the SBs where attached to different handles?? mmhhh > I have to admit; UEFI development is a bit messy... I'd suspect possibly. I also have yet to see evidence your HP EliteBook 2560p is not UEFI-2.0 compliant. It's safe to assume the 2560p and 2570p are not 2.1 compliant as the Pxebc appears backed by a Net not an MNPSb. -- -Gene

Im having problems connecting to Hidden WIFI networks on my RHEL 7 beta. I have an HP Elitebook 2560p. But if I make the Wireless Access Point visible, im able to connect to it, and NM is able to save the connection script under "/sysconfig/network-scripts". I tried on 3 different Hidden Networks, The solution was to manually create the connection script in "/sysconfig/network-s...

> Hi All, > > My PXE configurations works fine for a bios PXE (the server in legacy > mode) but hangs in an EUFI mode. Look like it can transfer the bootx64.efi > but not the next one ldlinux.e64 > > > Any ideas? > > Thanks > Latest updates (including firmware) for the HP ML350 Gen9 were released on 2014DEC19 (v1.21); I would suggest double-checking

..._BINDING) that provides UDPv4Sb across the same interface.? Presumably it should also provide TCPv4Sb (rather than being on a separate handle). -- -Gene <<< What I've found: (from older to newer hardware) 1) There's not "any" SB protocol present (Elitebook 8460p/2560p) 2) SB protocols are loaded under a different that LoadeImage's DeviceHandle, while Pxebc is loaded under the LoadeImage's DeviceHandle. (Elitebook 8470p/2570p) 3) SB protocols and Pxebc are loaded under the LoadeImage's DeviceHandle (VMware Workstation 10). About MNPSb; even when it...

...#39;s e1000e NIC (never saw ANYTHING good from it until now). git://github.com/geneC/syslinux.git https://github.com/geneC/syslinux.git -- -Gene <<< Hi there I think in the case of a particular driver that implements Pxebc but it does not implement UDPv4Sb/TCPv4Sb (HP Elitebook 2560p/8460p) your patch crashes; In that case the following for(;;) structure will never have a MAC match, then the BS->OpenProtocol will never fail returning the needed "status != EFI_SUCCESS" to avoid de-referencing an undefined pointer (sbp->CreateChild) in the next code line. ... fo...

...>>>> > > > > Could this be the reason why in the past Pxebc and the SBs where > attached to different handles?? mmhhh > > I have to admit; UEFI development is a bit messy... > > I'd suspect possibly. I also have yet to see evidence your HP > EliteBook 2560p is not UEFI-2.0 compliant. It's safe to assume the > 2560p and 2570p are not 2.1 compliant as the Pxebc appears backed by a > Net not an MNPSb. > > -- > -Gene > _______________________________________________ > Syslinux mailing list > Submissions to Syslinux at zytor.co...

>>> > 1) There's not "any" SB protocol present (Elitebook 8460p/2560p) The only solution for these is to use our own stack (likely full TCP/IP like lwIP) and connect to the Net GUID (EFI_SIMPLE_NETWORK_PROTOCOL).? Does the handle for Pxebc contain a Net?? >>> It does contain a Net but there are 2 issues with SNP: 1) The interface is different than UDPv...

> What about to your HP mail? I'd definitely advise the latest as I merged > some commits this weekend. > > --Gene Hmm... Shamelessly, and off-topic, but not _that_ much... :) For several months we have seen reports (of different matters) here in the Syslinux Mailing List in which some HP model(s) have been having problems network-booting (in UEFI mode; I don't recall

Hi All, My PXE configurations works fine for a bios PXE (the server in legacy mode) but hangs in an EUFI mode. Look like it can transfer the bootx64.efi but not the next one ldlinux.e64 Any ideas? Thanks Software> syslinux ver 6.3 atftp 7.1 Log server side >> Booting Embedded LOM 1 Port 1 : HP Ethernet 1Gb 4-port 331i Adapter - NIC (PXE IPv4) >> Booting PXE over

On Mon, Jul 6, 2015 at 6:04 AM, Patrick Masotta <masottaus at yahoo.com> wrote: > > What I've found: > (from older to newer hardware) > > 1) There's not "any" SB protocol present (Elitebook 8460p/2560p) The only solution for these is to use our own stack (likely full TCP/IP like lwIP) and connect to the Net GUID (EFI_SIMPLE_NETWORK_PROTOCOL). Does the handle for Pxebc contain a Net? I found out that my EFI shell on VMware VMs can also handle output redirection like: guid > fs0:\efi-guid.tx...

...t until now). > > git://github.com/geneC/syslinux.git > https://github.com/geneC/syslinux.git > > -- > -Gene > <<< > > Hi there > I think in the case of a particular driver that implements Pxebc but it does not implement UDPv4Sb/TCPv4Sb > (HP Elitebook 2560p/8460p) your patch crashes; > > In that case the following for(;;) structure will never have a MAC match, then the > BS->OpenProtocol will never fail returning the needed "status != EFI_SUCCESS" > to avoid de-referencing an undefined pointer (sbp->CreateChild) in the next...