01:44 <chewitt> rdorsch LE10b1 is numbered 9.95.1 .. nightlies tell you the base release (which is 10) plus githash stuff

01:45 <chewitt> I prefer to keep numbering fixed/simple as I use some scripts to 'automate' initial setup (and update) of a test device

01:45 <chewitt> https://github.com/chewitt/LibreELEC.tv/commits/imx6 has changes

01:46 <chewitt> not much apart from the kernel and firmware that's missing for the v1.5 version of Cubox-i

07:35 <rdorsch> Will the debug shell produce kernel log messages on an usb console? I saw with the images from yesterday 2-3 kernel hangs (i.e. screen frozen, not reachable by ssh anymore).

07:36 <rdorsch> What is an "nxp" kernel: https://github.com/chewitt/LibreELEC.tv/commit/ae491e66fc70c7f98654624e2c37381aed09ba32 ?

07:37 <rdorsch> What do you think of adding from_file() as well as potential overwrite, if the file exists (as you shared it)?

08:11 <chewitt> debug shell should provide a local console over USB .. but not tested since I don't have the USB cable needed (only normal UART cables)

08:15 <chewitt> we are building NXP project hence 'nxp' kernel name; it's default 5.11.11 kernel + a handful of patches that should be in 5.12

08:15 <chewitt> and I would ignore the file method

08:16 <chewitt> IMHO things should "just work" and the machineid is a really good method for that

08:16 <chewitt> it will be persistent unless the machineid is deleted or the user reinstalls

08:18 <chewitt> it will inconvenience existing users .. but since there are only 11x active installs of iMX6 images newer than LE 8.2.5, I think we can live with that :)

08:20 <chewitt> 8/11 installs are Cubox devices that presumably suffer the same issue

08:20 <chewitt> re. file .. users see endless configuration options as a brilliant invention

08:21 <chewitt> the people who support the users see anything requiring human input as an opportunity to break something and cause forum posts

09:27 <rdorsch> I fully understand your reasoning. The downside of the random mac with every new install (I assume there will be a few in front of us:-) ) is that I have to update the DHCP server and I have to check if I can keep the MAC with the old BSP image in sync as well. If that does not work, basically for every switch of the SD card between BSP image and LE10, I need to update the DHCP server.

09:27 <rdorsch> Do you know if I can control the machine ID?

09:28 <rdorsch> But let me check first if I got a different one with the update.

09:30 <rdorsch> Hmm...could I simply overwrite .cache/systemd-machine-id once, to get rid of the randomness?

09:51 <vpeter> How come reading soc serial number and using this for mac address doesn't work?

09:52 <vpeter> Also cubox devices has correct mac address.

09:52 <vpeter> Only unfused soms doesn't have it.

09:55 <rdorsch> The current machine id has apparently randomness. I.e. with every new image, a new mac is produced.

09:56 <rdorsch> I just checked, it seems that the last 8 nibbles remain constant between boots. I.e. if the mac address is derived from the last 8 bytes, at least the randomness woudl be gone.

09:58 <rdorsch> I cannot tell if a cubox-i has an unfused som.

09:59 <vpeter> It doesn't have - you can read mac at bottom of device.

10:10 <rdorsch> Ok, in this case, I agree using the mac address is the right solution.

10:11 <vpeter> Seems in this case we got to mainline problem: it just lacks of features for this device. In u-boot or kernel.

10:11 <rdorsch> in the current nightly builds this doesn't seem to work though and there is a random generated mac used with every boot.

10:12 <rdorsch> Which is the worst thing, since even network settings done in kodi are not persistent.

10:13 <rdorsch> Might be, but it worked in mainline longtime back at least.

10:14 <rdorsch> I have a Debian 4.19 kernel which seems to be able to read the mac from the SOC.

10:18 <vpeter> Maybe Debian had some extra patches.

10:19 <vpeter> But maybe this 4.19 was not really mainline.

10:23 <rdorsch> It is the standard Debian kernel, so yes it has patches, but it is not the BSP kernel.

10:30 <rdorsch> I just realized that since ethmactool-config sets the local assignment bit I cannot even set the correct MAC of the SOM using ethmactool-config :-/

10:58 <rdorsch> I found a way to set the mac address to the one with the local assignment bit on my old BSP image, so at least the two SD cards come up with the same and constant MAC address now.

10:59 <rdorsch> There the correct mac was in the ethaddr environment variable of u-boot (which I could modify).

11:07 <rdorsch> chewitt: I would help me if you could commit your current ethmactool-config patch to master as workaround until the correct MAC can be read. I think a constant mac should have no negative side effects.

16:32 <chewitt> rdorsch the machineid is randomly generated from uuidgen on first boot

16:32 <chewitt> so it's nothing special, just unique

16:34 <chewitt> if you want to persist a MAC over many installs .. just make a note of it, then overwrite it (and reboot) when you need to

16:35 <chewitt> but I think something is missing to pass the MAC correctly to the kernel

16:37 <chewitt> because as vpeter says .. I have the MAC on a label on the underside of the Cubox that SR sent me

18:20 <rdorsch> yes, that is how I do it right now, works well :-)

18:22 <rdorsch> I suspect, u-boot has access to it, since I saw it in ethaddr of u-boot before and from there it is propagated. I can ask on debian-arm, if they do something special or if that is supposed to work with mainline kernel and u-boot.