| 08:08 | jnettlet[m]> | hurrah booting the F28 server image on the mcbin from u-boot |
| 08:08 | jnettlet[m]> | now to get the rest of the patches merged so mainline u-boot isn't so useless |
| 08:08 | Ke> | jnettlet[m]: with grub? |
| 08:09 | jnettlet[m]> | yes |
| 08:09 | Ke> | jnettlet[m]: do you have patchset/tree against upstream, so I can try? |
| 08:09 | Ke> | assuming my mcbin survived the relocation |
| 08:10 | jnettlet[m]> | well you are using Debian right? The patches will be a bit different. Which image are you using and I will test. |
| 08:11 | Ke> | how different, I just want to load grub, I am fine with doing it manually from the command line using e4load and bootefi |
| 08:12 | Ke> | anyway no image just debian buster packages mostly latest versions |
| 08:12 | Ke> | I created my system using the installer or debootstrap, don't remember which |
| 08:13 | Ke> | 1 EFI system partition with grub-install --removable and root partition and more partitions that are not needed for boot |
| 08:14 | jnettlet[m]> | so grub and efi and dtbs are all on the first partition? |
| 08:15 | jnettlet[m]> | then I don't believe you shouldn't need any other patches with the latest mainline uboot |
| 08:16 | Ke> | EFI is now on separate SD card, grub in EFI system partition and kernel/dtb/initrd on rootfs |
| 08:16 | Ke> | and I perhaps would replace EFI step with u-boot |
| 08:17 | Ke> | jnettlet[m]: as un mainline should work? |
| 08:17 | Ke> | jnettlet[m]: with the defconfig? |
| 08:17 | Ke> | as in mcbin_whatever_defconfig |
| 08:19 | jnettlet[m]> | Ke: ah okay so you actually need a different variation of the Fedora loading patch since EFI and dtbs are on a different disk |
| 08:20 | jnettlet[m]> | hmmm, I see the problem now, let me see what I can come up with, want to get this sorted out finally |
| 08:26 | jnettlet[m]> | I also would need to see what patches fedora has for their grub efi app. I know they do a lot in their shim |
| 08:30 | KBme> | hi. I've just noticed that the hummingboards we receive have a bogus MAC address for the integrated wifi chip. Is there a way to obtain it's original MAC address? |
| 08:36 | jnettlet[m]> | KBme: what MAC do they have? We don't flash the MACs for the TI chips, they are provided by TI |
| 08:37 | KBme> | DE:AD:BE:EF:00:00 lol |
| 08:37 | KBme> | I'm guessing they are not provided by ti then :D |
| 08:38 | KBme> | either that or I need to update our kernel... |
| 08:41 | jnettlet[m]> | KBme: most likely the firmware files are doing that. |
| 08:41 | KBme> | jnettlet[m], ok, so do you think it's a kernel issue? |
| 08:42 | KBme> | I mean, is it the firmware that is in the kernel or linux-firmware? |
| 08:42 | jnettlet[m]> | no linux-firmware |
| 08:43 | jnettlet[m]> | try and grab the firmware from our packaging repo. https://github.com/mxOBS/deb-pkg_cuboxi-firmware-wireless |
| 08:45 | jnettlet[m]> | hmmm okay not everything is perfect in fedora mcbin world. it did not bring up all the cores. |
| 08:48 | KBme> | jnettlet[m], oh, this looks new. is there a new kernel supported by the binary graphics drivers as well? I'm at 3.14. is the official solidrun kernel still at github.com/solidrun/linux-fslc ? |
| 08:49 | jnettlet[m]> | KBme: if you are 3.14 then I would recommend you switch to our 4.9 kernel |
| 08:50 | KBme> | jnettlet[m], is it supported by graphics drivers? can you please confirm the official source for the kernel? |
| 08:50 | jnettlet[m]> | yes linux-fslc you will see a branch there for 4.9 |
| 08:50 | jnettlet[m]> | yes it is supported by graphics drivers. |
| 08:50 | KBme> | ok, good. I'll look into it. thanks. |
| 08:52 | KBme> | jnettlet[m], do you think there is a way to figure out the MAC a machine will get once it uses the new firmware/kernel? I have shipped some machines already and I'll need to update them, at a location where they use MAC address filtering for the wifi. |
| 08:52 | Humpelstilzchen> | Does solid-run currently has problems with the production of i.MX6 SoCs? |
| 08:52 | Humpelstilzchen> | uhm SoMss |
| 08:56 | jnettlet[m]> | Humpelstilzchen: how do you mean? We are currently shipping all our SOMs |
| 08:56 | jnettlet[m]> | There is a longer lead time on Industrial grade based SOMs |
| 08:57 | Humpelstilzchen> | jnettlet[m]: ok thanks, guess I have to talk to my reseller again.. |
| 08:58 | jnettlet[m]> | Humpelstilzchen: let us know if there are specific things you want to know the status of. I can check, or email sales. |
| 09:17 | KBme> | jnettlet[m], ? |
| 09:18 | jnettlet[m]> | KBme: whats up? |
| 09:18 | KBme> | ah, maybe my message didn't go through |
| 09:18 | KBme> | jnettlet[m], do you think there is a way to figure out the MAC a machine will get once it uses the new firmware/kernel? I have shipped some machines already and I'll need to update them, at a location where they use MAC address filtering for the wifi. |
| 09:19 | jnettlet[m]> | KBme: not without having some other form of connectivity to them. |
| 09:20 | KBme> | jnettlet[m], well, I do have connectivity to them now |
| 09:20 | KBme> | but if I update the kernel and the wifi interfaces get different macs I will not have connectivity to them :D |
| 09:21 | KBme> | is there no way I can find out the mac ahead of time, on my current kernel? |
| 09:22 | jnettlet[m]> | not that I know of. You can check how the driver accesses the MAC from the firmware, but I doubt the kernel would know the chip firmware since the ti blobs have overridden it. |
| 09:35 | KBme> | that sucks |
| 09:36 | KBme> | ok i'll have to try and make a deal with the wifi operator. |
| 10:11 | vpeter> | What about some temporary startup script which would identify new mac address, save it in some file and then change it back to old one so you can connect to a device? |
| 10:33 | KBme> | vpeter, yeah, I thought about that. i'll have to test whether it works for wifi cards |