(2017-01-18 21:13)NiKiZe Wrote:  The driver says the link is down.
To debug this you could try and build ipxe from current git master with

Code:

make bin-x86_64-efi/ipxe.efi DEBUG=tg3

this should give you some status information that will be a start for us to help you figure out what the issue is and hopefully fix it.

Quote:one other thing to test is to try and use snp.efi instead, which will default to the snp or nii driver provided by the firmware, this is in no way a fix but rather a possible debug step to ensure everything else is working as expected.

(2017-02-02 22:43)NiKiZe Wrote:  please test with the official ipxe git master. (so not the fog sources)
go in to the shell, enter dhcp, and then ifstat and post the result of the whole process.

(2017-02-02 22:43)NiKiZe Wrote:  since this is a tg3 only issue test this with: make bin-x86_64-efi/tg3.efi DEBUG=tg3,tg3_hw,tg3_phy
that will also eliminate the possible issue of wireless.

Quote:Broadcom Corporation BCM43602 802.11ac Wireless LAN SoC [14e4:43ba]

(2017-02-04 00:34)NiKiZe Wrote:  in your video it detects net1
in that image there is only net0 - but twice (no net1)

Again please give the output of dhcp followed by ifstat from official ipxe git sources, without any configuration modifications at all.

Just to limit this down to just the tg3 driver use make bin-x86_64-efi/tg3.efi

so steps I really want you to do so we have a common, minimal, reproducable, understanable testcase:
git clone git.ipxe.org/ipxe.git
cd ipxe/src
make bin-x86_64-efi/tg3.efi
(note that there should not be any configuration changes at all)
cp make bin-x86_64-efi/tg3.efi -> boot device

Quote:press ctrl-b when booting
type dhcp
type ifstat
take a picture and upload

(2017-02-13 17:05)marcolefo Wrote:  

(2017-02-04 00:34)NiKiZe Wrote:  Again please give the output of dhcp followed by ifstat

Ok, I've done that :

(2017-02-13 17:05)marcolefo Wrote:  

(2017-02-04 00:34)NiKiZe Wrote:  press ctrl-b when booting
type dhcp
type ifstat
take a picture and upload

I can't do that. When asked, I have pressed ctrl-b and I didn't go to the shell but the iMac boot to OS.

(2017-02-13 18:35)NiKiZe Wrote:  Might be a notorious EFI bug, you can press ESC followed by b to emulate ctrl-b

(2017-02-13 18:35)NiKiZe Wrote:  Also note that you can't have a embeded script, since that disables the default prompt, if it still does not work you can add a embedded script with just shell to get into the shell.

So for this case lets go with: testscript.ipxe

Code:

#!ipxe
dhcp
ifstat
shell

build with

Code:

make bin-x86_64-efi/tg3.efi EMBED=testscript.ipxe

and test the resulting bin-x86_64-efi/tg3.efi

(2017-02-13 18:35)NiKiZe Wrote:  After uploading an image of running with the above embeded script without debug, please also build and do the same with

Code:

make bin-x86_64-efi/tg3.efi DEBUG=tg3,tg3_hw,tg3_phy EMBED=testscript.ipxe

(2017-03-07 11:45)marcolefo Wrote:  So, dhcp followed by ifstat :

(2017-03-07 11:45)marcolefo Wrote:  Here is the video of the boot :
https://youtu.be/dZJCd0R7ZG8

(2017-03-07 22:41)NiKiZe Wrote:  my bad, since dhcp fails it exits use the double pipe (||) at the end of dhcp:

Code:

#!ipxe
dhcp ||
ifstat
shell

(2017-03-07 22:41)NiKiZe Wrote:  Interesting that the link goes up, can we identify exactly when and how that link up message is shown? Is it when ipxe exits?

(2017-03-07 22:41)NiKiZe Wrote:  I think we need to dig much further into the driver then this but maybe full debug enabled could give us something more:

Code:

make bin-x86_64-efi/tg3.efi DEBUG=tg3:7,tg3_hw:7,tg3_phy:7 EMBED=testscript.ipxe

(2017-03-09 17:22)speleo14 Wrote:  iMac 27'' Retina 5K Late 2015, bought in May 2016 (iMac17,1):
Boot ROM: IM171.0105.B05
SMC Version: 2.33f10

Boot ROM: IM171.0105.B15
SMC Version: 2.34f2

(2017-03-09 18:01)NiKiZe Wrote:  In that case I only think that boot ROM might be relevant.

(2017-03-09 18:01)NiKiZe Wrote:  Does any of these work with snponly.efi?

(2017-03-10 09:12)speleo14 Wrote:  

(2017-03-09 18:01)NiKiZe Wrote:  In that case I only think that boot ROM might be relevant.

I agree. I have now tested 2 iMacs, both were bought at the same time (spring 2016). One was upgraded to Sierra (10.12), the other is still on Capitan (10.11).
The 10.12 iMac has Boot-ROM IM171.0105.B15, and doesn't PXE boot ("link down").
The 10.11 iMac has Boot-ROM IM171.0105.B05, and PXE booting does work.
So the Sierra upgrade does also upgrade the Boot-ROM, and this breaks booting with iPXE.
The SMC version does not seem to be relevant, both have 2.33f10.

Currently checking if the Boot-ROM can be downgraded... but not much hope.

(2017-03-09 18:01)NiKiZe Wrote:  Does any of these work with snponly.efi?

Will try and post back.

---

OK, built snponly.efi with "make bin-x86_64-efi/snponly.efi".

Trying to boot with that results in "No more network devices" on all machines, that is, no NICs were even recognized (neither internal nor external).

(2017-03-13 13:19)mastacontrola Wrote:  This, to me, (This is the "Tom" referred to above about the developer of FOG.) sounds exactly like a firmware issue.

Maybe we need to go to Apple and somehow file a Firmware issue? While I'm not sure how Apple feels about PXE Booting machines, the fact remains, from what I can tell here, that they pushed an update and that update broke something unexpectedly. These Mac's aren't going away anytime soon, and updating firmware to limit potential areas of boot seems like a rather large 'exploitation' of customer's own rights when purchasing machines.

I don't know who we would talk to, but I really doubt this is a problem from FOG or iPXE, but rather some "fix" Apple added to the ROM information on the NIC. Whether this was intentional or not I don't know.

One of the problems I've had with Apple is they tend not to care about the consumer and treat the customers as if they're temporary borrowers of their equipment. They're typically helpful if you do have an issue and are in their support terms, but the moment your warranty or "apple care" expires, they're really quick to try to make you go out and buy new equipment. I'm still not sure how to report a bug like this with Apple, though I'm certain somebody knows how somewhere.

Sorry about the vent there. Supporting Mac's should not be this difficult and it seems anytime a new update comes out for "Apple" devices, a new issue is broken and rarely does there seem to be a fix implemented.

(2017-03-15 10:06)speleo14 Wrote:  

(2017-03-13 13:19)mastacontrola Wrote:  This, to me, (This is the "Tom" referred to above about the developer of FOG.) sounds exactly like a firmware issue.

Maybe we need to go to Apple and somehow file a Firmware issue? While I'm not sure how Apple feels about PXE Booting machines, the fact remains, from what I can tell here, that they pushed an update and that update broke something unexpectedly. These Mac's aren't going away anytime soon, and updating firmware to limit potential areas of boot seems like a rather large 'exploitation' of customer's own rights when purchasing machines.

I don't know who we would talk to, but I really doubt this is a problem from FOG or iPXE, but rather some "fix" Apple added to the ROM information on the NIC. Whether this was intentional or not I don't know.

One of the problems I've had with Apple is they tend not to care about the consumer and treat the customers as if they're temporary borrowers of their equipment. They're typically helpful if you do have an issue and are in their support terms, but the moment your warranty or "apple care" expires, they're really quick to try to make you go out and buy new equipment. I'm still not sure how to report a bug like this with Apple, though I'm certain somebody knows how somewhere.

Sorry about the vent there. Supporting Mac's should not be this difficult and it seems anytime a new update comes out for "Apple" devices, a new issue is broken and rarely does there seem to be a fix implemented.

I agree completely!

I have an Apple developer account, so I can file a bug report; in fact, I have already been thinking about doing so, just wanted to wait until we are sure that it is indeed the firmware.
So, since we all agree that this is an issue with Apple's firmware, I will do so - however, it's not unlikely that they will more or less ignore it.
Maybe it would be a good idea if somebody else also reports this to Apple.

(2017-03-15 14:43)mastacontrola Wrote:  I don't have an account, though creating one shouldn't be too problematic.

(2017-03-15 14:43)mastacontrola Wrote:  That said, as this does appear to be a firmware issue, if we can't hold our breaths that a fix will come to place, might it be easier to find out a "change log" of what was changed between firmware B05 vs. B15? Even if it means something was added/adjusted that might be able to be corrected for in the iPXE BCM driver handling? Of course this would lead down a road that would essentially make the Mac's only usable on an 'ipxe' created driver system (Leaving out SNP/SNPONLY I suppse?)

Just thoughts in my head. I don't expect we'll see Apple pushing out a fix for this because of iPXE not working, but maybe we can get what was changed so the Opensource community might be able to provide a work around.