Mac Mini with T2 chip

george1421

@TaTa Ah that is a 10G adapter. The last time I looked not all of the 10G adapters were enabled in FOS Linux

So for the network adapter I need Aquantia AQtion [1D6A:07B1]

For the video
05AC:1461 05ac Apple, Inc.

Off to search now

george1421

@TaTa For the network adapter, that driver has been in the linux kernel since 4.12. It is still in the current release and is enabled in the FOS Linux kernel. For the next steps I will need you to boot into debug mode on the usb stick and run a few commands.

ip addr show
Confirm that the network adapter doesn’t an ip address. Post the output here so I can see what it looks like, wait 30 seconds after booting then key in
/sbin/udhcpc -i $iface --now Now you will need to replace the variiable $iface with the kernel name of the network adapter. This kernel name will come from the ip addr show command.
again run the ip address show to see if time fixes the issue.
ip addr show

for the video, I’ll need you to run the lsusb command to see if the kernel sees the driver with the USB ID 05AC:1461

george1421

Patch linux kernel 5.4.6 (disregard my references to other series 5.x.x kernels in previous posts. I used and compiled against 5.4.6 and not what I thought I was building against 5.4.3 or what ever I said).

I started with the 5.4.6 base kernel and applied the FOG configurations from FOS Linux 1.5.7 config file. I enabled thunerbolt and usb type-c drivers in the code, plus a bunch of other things I can’t remember at the moment.

The config file used to build the bzImageT2b is here:
Config.T2Chip.txt

The diff from the 1.5.7 kernel loaded into the 5.4.6 kernel config space vs the bzImageT2b config file above is here:
apple_T2_diff.patch.txt

Basically these are the changes made from FOS Linux 1.5.7 after they were loaded into the 5.4.6 kernel builder tool and the changes I made enabling what I thought this apple hardware needed.

Here are the T2 kernel patches that were supplied via the github link https://github.com/MCMrARM/mbp2018-etc/tree/master/applesmc These patches must be applied to the linux 5.4.6 kernel in numeric order.

0001-applesmc-convert-static-structures-to-drvdata.patch.txt
0002-applesmc-make-io-port-base-addr-dynamic.patch.txt
0003-applesmc-switch-to-acpi_device-from-platform.patch.txt
0004-applesmc-key-interface-wrappers.patch.txt
0005-applesmc-basic-mmio-interface-implementation.patch.txt
0006-applesmc-fan-support-on-T2-Macs.patch.txt

TaTa

@george1421 ip addr show lists network adapters as enp126s0u2 (USB-c to ethernet adapter), enp1s0, and lo. enp1s0 MAC address is not the same as reported in Mac OS or BootCamp for Ethernet adapter nor it’s the same as Wifi MAC address.
lsusb does show ID for USB-C multimedia adapter: Bus 001 Device 004: ID 05ac:1461

george1421

@TaTa Well having an unknown nic is a bit strange.

If you plug a functioning network cable into both the onboard nic and the usb-c nic and then issue these commands can either get an IP address?

/sbin/udhcpc -i enp126s0u2 --now

/sbin/udhcpc -i enp1s0 --now

To understand a bit more about the enp1s0 nic (which sounds like an Intel nic) you can run the following command lspci -nn |grep -i net and it will display the kernel drivers used for both nics. I can tell you from experience if linux doesn’t have a driver for the network device it will not report or show up the nic in the ip addr show command. Now it may pic the wrong driver, but at least FOS Linux has the driver for both nics.

TaTa

@george1421 running /sbin/udhcpc -i enp126s0u2 --now shows correct assigned IP
/sbin/udhcpc -i enp1s0 --now has no IP assign (MAC address needs to be registered in our database for DHCP to assign an IP)

running lspci -nn |grep -i net shows

01:00.0 Ethernet controller [0200]: Device [1d6a:07b1] (rev 02)
03:00.0 Network controller [0280]: Broadcom Limited Device [14e4:4464] (rev 03)

@Sebastian-Roth said in Mac Mini with T2 chip:

Please download the latest inits (64 bit, 32 bit) and make sure you update your grub.conf file to use ramdisk_size=275000!!

I downloaded the new inits and set ramdisk_size to 275000. Then scheduled a new upload. It went to partclone screen and attempt to upload. it lasted for about 3 seconds and went to 100% and goes to update database (sorry I didn’t have a chance to take a picture) and trying to reboot the systems went to this screen Fixing recursive fault but reboot is needed! https://forums.fogproject.org/topic/14073/mac-mini-with-t2-chip/16#

george1421

@TaTa said in Mac Mini with T2 chip:

unning /sbin/udhcpc -i enp126s0u2 --now shows correct assigned IP
/sbin/udhcpc -i enp1s0 --now has no IP assign (MAC address needs to be registered in our database for DHCP to assign an IP)

So do we know which network adapter is the built in one? And which network adapter is getting the IP address? If we take the mac address for enp1s0 that is shown by FOS Linux and register it with your dhcp server, then reboot into option 6 with a network cable attached to both ethernet ports. Do both nics pick up IP addresses without manual intervention? (there is a known condition where they might not. The test is to see if time will resolve the issue by running the udhcpc command after 30 seconds). I think we might be chasing 2 issues with networking at the same time.

TaTa

@george1421 I took that MAC address and registered. Both nics picked up IP addresses correctly in FOS linux.
I happen to find another Mac Mini and FOS linux does report a different MAC address than from OS. Weird.

george1421

@TaTa Ok now that both pick up IP addresses, can you image using the built in nic now as you can with the older hardware?

On the case of why… I can’t think of a reason why the linux kernel would report a different mac address than the OS. That simply shouldn’t happen. I know windows has a “feature” for wifi that it can/will create a random IP address for security reasons, but that feature is a bit dumb for me.

I’m speaking out of ignorance here, but does the hardware have some kind of firmware (bios) setup where you can see the mac address the firmware is reporting. I’m thinking the equivalent to the Dell bios screens. Since its apple with a locked ecosystem it might not.

TaTa

@george1421 built-in nic can upload/download image just fine. I’m not sure of how to get MAC address from firmware bios on a Mac.

banbuduo*2020

![0_1595236889489_002.jpg](Uploading 100%) @Tom-Elliott ![0_1595236870799_001.jpg](Uploading 100%) Fog（Ver:1.5.8）,mac pro(2019) use USB net boot, But it say " attempting to register host…no viable macs to use
/tmp/hinfo.txt：line1：Invalid : command not found"

Tom Elliott

@banbuduo-2020 we need information. This might also work better as it’s own post, as this posting is quite old.

From what I can see of the pics you provided, you’re using a USB stick?

What version of FOG is your server running?

What instructions did you use for the USB?

banbuduo*2020

@Tom-Elliott Yes，I am using a USB stick,the version of FOG is 1.5.8 in the server of Centos 7, I set the USB stick refer to the URL(https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image/22?page=2), And download bzImageT2 from the url(https://github.com/FOGProject/fogproject/releases/download/1.5.9-RC1/bzImageT2), rename bzImage on the usb flash drive and then copy the bzImageT2 to the flash drive as bzImage, do I need upgrade the version of fog to 1.5.9-RC2.11 ? or I need the version of bzImageT2 for my fog version 1.5.8

george1421

@banbuduo-2020 said in Mac Mini with T2 chip:

bzImage on the usb flash drive and then copy the bzImageT2 to the flash drive as bzImage, do I need upgrade the version of fog to 1.5.9-RC2.11 ? or I need the version of bzImageT2 for my fog version 1.5.8

There are a few things we need feedback on.

On the FOG server change to /var/www/html/fog/service/ipxe directory then key in file bzImage and tell us the version of what was the bzImageT2 file. It will be 4.19.x or 5.x.x
The error about hinfo.txt is strange (in deleted post) since you are getting an IP address. The target computer should be reaching the FOG server to generate this file.
The kernel dump in the second picture doesn’t tell the entire story. What were you doing (imaging, registering, something else) when the kernel blew up?

I know this kernel works because it has solve other FOG Admins issues. So there is something different with your system (which is possible if its a newer model) that disagrees with this kernel.

banbuduo*2020

@george1421 hello，I am very happy because of your help, the version of what was the bzImageT2 file is 4.19.101,you can see the picture ,it happen the the second picture when i am doing registering… Maybe I need upgrade the version of fog to 1.5.9-RC2.11 if it is not difficulty

george1421

@banbuduo-2020 OK that kernel image is not one that I created. “jenkins” is on one of the FOG Developers servers. Here is the one from my one-off server: https://drive.google.com/file/d/10j8fZ3i3Y_uICxcMgX5lpiuQ2ci9bCJG/view?usp=sharing You should see a cartoon character name in the kernel definitions.

What I would do is download that as bzImageT2 and move it as is to the /var/www/html/fog/service/ipxe directory. Don’t change the name. Then in the host definiton for this apple, there is a field I think its just called kernel name enter bzImageT2 for that host and save it. Watch your case because linux is case sensitive. Then only the T2 image will be called when you pxe boot that computer. The risk of renaming bzImageT2 to bzImage is that every time you upgrade fog that T2 image will be overwritten with the latest FOG version of bzImage.

Don’t confuse FOS Linux’s kernel bzImage in the ipxe directory with the FOG server’s HOST os kernel. They are different.

banbuduo*2020

This post is deleted!

george1421

You can also redown load it from the github site and then run the files command on that file right away. You should also see what I discussed in my last post.

Mac Mini with T2 chip

304

11.7k

17.2k

154.7k