Posts by dpapavas

  • Rock Pi 4B WiFi keeps changing MAC address on

    Ugh, this is not going to be easy to get to work properly. Using the latest (as in latest I've tried) Jul 6 2020 driver, the device seemed to work fine for more than 10 hours. Then I went to sleep and the next morning it still seemed to be reachable from the PC and my tablet, but it wasn't reachable from my phone. Usually the PC was that first to be unable to reach it, so I'm not sure if this is the same issue, or just something acting up on my phone's network, or what.

    The kernel log contained just these messages from the driver, printed at some point during the night:

    This makes me think the problem, might be related to powersaving. I've tried to disable it with

    Bash
    iw dev wlan0 set power_save off

    We'll see if that helps. If it does, I'll have to figure out a way to make this permanent.

    In the meantime, I've also tried contacting Radxa, to ask them about it.

    Edit: Forgot to say, that there seem to be other problems, as after a reboot, sometimes the WiFi doesn't come up at all. I have no idea why, as I can't log into the machine without WiFi and I don't know of a way to get to the kernel messages without SSH. I've tried enabling persistent logs, to see if I can find out anything about this, when it happens again.

  • Getting LibreELEC to work with RockPi 4B and a Hifiberry DAC+ Pro XLR

    I've had some contact with the (or at least one of the) developers of HifiBerry boards when I made that bugfix to the codec driver. (In fact, he was nice enough to give me the similar, in terms of drivers, board I'm using right now for my trouble.) At the time I, didn't have the Rock Pi yet, but was considering it and asked him whether the boards might work with it. In fact, reviewing this communication, I told him

    Quote

    I might give it a try when software support for the board
    matures a bit more. I'll let you know if I do.

    for which he thanked me, so I suppose he might well be interested in supporting the Rock Pi 4. I think I'll drop him a line as soon as I find some time.

  • Rock Pi 4B WiFi keeps changing MAC address on

    Quote from chewitt

    I'd test with/without the clm_blob as those are 100% implementation-specific and can cause issues on the wrong board;

    Copy that.

    Quote from chewitt

    It's all under "version control" but the process isn't what you wrongly assume it to be :)

    Copy that too. I suspected as much and hence am now operating on the assumption that "different version might work better", as opposed to "higher version might work better". I tried all versions in that pinebook related repo, without much success. The version I mentioned in my last message, did indeed work with the correct MAC address and no crashes, much like it did on my old Armbian setup. Unfortunately, it worked exactly the same, including a weird bug, where the board will suddenly be unreachable by some or all machines inside the LAN, while still being able to access the Internet just fine. I have no idea what may be causing that, but it seems to be related to the router as well, as it started only after the last time my ISP saddled me with a new router. Let me know if you suspect anything.

    In the meantime, I've found another firmware, dated Jul 6 2020, that seems to be working flawlessly for more than 5 hours now, allowing me to loosely keep my fingers crossed in disbelief. We'll hopefully know in a day or two, or sooner if I'm not lucky.

    Quote from chewitt

    NB: This has been lurking on our repo for a while https://github.com/LibreELEC/brcmfmac_sdio-firmware/pull/30

    I'll have a look once I'm done with the fimware currently under test.

  • Rock Pi 4B WiFi keeps changing MAC address on

    That firmware didn't work; it kept crashing. After looking around, for a newer firmware (since that one was from 2017) I found this, where the most recent working firware I found was inside lib-firmware-brcm-20200211. Now this seems to work fine so far (after close to 2 hours) and it also seems to not randomize my MAC address. Some kernel logs:

    Quote

    [ 17.267370] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43456-sdio for chip BCM4345/9
    [ 17.267853] usbcore: registered new interface driver brcmfmac
    [ 17.820526] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/9 wl0: Feb 11 2020 11:54:51 version 7.45.96.61 (be7af2d@shgit) (r745790) FWID 01-a41d86bd es7.c5.n4.a3
    [ 18.064531] Bluetooth: hci0: BCM4345C5 'brcm/BCM4345C5.hcd' Patch

    In fact, this gives me the same MAC address, as the one I had running Armbian, based on the 4.4 kernel, and sure enough, they are the same nvram and firmware files, only on my Armbian installation there was no cl_blob file (but I've installed that too).

    One funny thing is that I now see messages like the following now and again:

    As far as I can see, these are not related, as they seem to be communication errors between the chip and the CPU. I also didn't notice them on my first reboot after installing the new firmware. Functionally, the WiFi link seems to be fine, as far as I can see.

    I'll confirm that it's still working fine after a day or two, just to make sure. In the meantime, if there are any places I can look for more recent firmware, let me know.

  • Rock Pi 4B WiFi keeps changing MAC address on

    I've just installed a couple of firmware/nvram files from https://github.com/armbian/firmware.git. They are the same files as found in https://github.com/LibreELEC/brcmfmac_sdio-firmware, (where, somewhat confusingly, there seems to already be an nvram file for the Rock Pi 4B, named "brcmfmac43456-sdio.radxa,rockpi4b.txt", which is the same as "brcmfmac43456-sdio.txt", used for other boards, but there's no bin file for the 4B, although "brcmfmac43456-sdio.bin", which is the one I've installed, is used on otherboards).

    Anyway the files I've used ("brcmfmac43456-sdio.bin", "brcmfmac43456-sdio.txt", appropriately renamed) seem to be working although I'm still getting

    Quote

    brcmf_c_preinit_dcmds: Default MAC is used, replacing with random MAC to avoid conflicts

    and the MAC address was different upon reboot. When I say it's working, I mean it seems to be working fine so far. I'll let you know tomorrow, or after a couple of days if it is ok.

    Is there a tried and true way of getting the MAC to stay put?

  • Rock Pi 4B WiFi keeps changing MAC address on

    Thanks for the pointers, I'll have a look and report back.

    One question though:

    Quote from chewitt

    Otherwise it's not something I've seen before with Broadcom modules. It does happen with cheap Realtek USB dongles where the manufacturer was too lazy to get unique OID's for their devices or programmed everything with 00:00:00:00:00:00.

    Don't lines such as this

    Quote

    ieee80211 phy7: brcmf_c_preinit_dcmds: Default MAC is used, replacing with random MAC to avoid conflicts

    imply that this is also what is happening with this Broadcom chip?

  • Getting LibreELEC to work with RockPi 4B and a Hifiberry DAC+ Pro XLR

    I assume you're talking about the DAI link parameters in the platform driver ("hifiberry_dacplus.c"). I agree and it would have made my life a lot easier, but on the one hand, this is by its nature a Raspberry Pi-specific device, so I suppose it is not entirely unreasonable to claim that it belongs to the Pi's fork of the kernel (although whether there should be such a fork at all is another matter, one which I'm not qualified to judge).

    On the other hand from what I've seen, the various people writing drivers for similar devices aren't big on upstreaming changes to the mainline kernel in general. They apply locally (in the sense of at the Pi kernel level) changes to upstream code, such as the codec driver in this case, instead of attempting to push them upstream, which doesn't help in many ways.

    I've pushed a fix I did for the codec driver upstream a few years ago, but trying to push a driver for a commercial device that isn't mine would feel a little weird :)

  • Rock Pi 4B WiFi keeps changing MAC address on

    My Rock Pi 4B WiFi seems to keep changing its MAC address, not after every reboot, but while it's running. This causes all sorts of problems and it seems to be a firmware issue as, a) the kernel driver seems to try to load some firmware, but can't find it, b) the default firmware, or whatever ends up being used, crashes, causing a reload which also changes the MAC address.

    Here are some kernel messages:

    And there are more along those lines since boot. This seems to happen at irregular intervals, sometimes after 10', sometimes after close to an hour.

    So, is this a known issue? Is there a know fix for it?

  • Getting LibreELEC to work with RockPi 4B and a Hifiberry DAC+ Pro XLR

    Well, I did get it work! Can't believe it was only a matter of a couple of days work; I've been putting this off, staying with a heavily patched, mostly broken, Kodi 18 installation, running on the mostly broken 4.4 BSP kernel for a couple of years now. Thanks again for all your help. I have a bunch of things to sort out now and hence probably a bunch of questions, but I'll be starting new threads in more appropriate subsections as needed.

    For anyone looking into this, the general outline of the what needs to be done is this:

    1. Start with the appropriate kernel sources based on libreelec version.

    2. Apply patches from Raspberry Pi kernel repo, introducing support for HifiBerry devices. At the time of this writing this is a single commit (for the 6.1 kernel for instance, it is "f1b09af4656d (HEAD) Add support for all the downstream rpi sound card drivers") and you don't really need to apply all of it, just the changes relating to your device, e.g. "*hifiberry_dacplus*".

    3. Fix the DAI link in "hifiberry_dacplus.c", to reflect the correct RK3399 I2C and I2S channels.

    Quote

    SND_SOC_DAILINK_DEFS(rpi_hifiberry_dacplus,
    DAILINK_COMP_ARRAY(COMP_CPU("rk3399-i2s.1")),
    DAILINK_COMP_ARRAY(COMP_CODEC("pcm512x.7-004d", "pcm512x-hifi")),
    DAILINK_COMP_ARRAY(COMP_PLATFORM("rk3399-i2s.1")));

    4. Add the following to the Rock Pi 4B device tree, to enable I2C7 and connect it to the codec, enable I2S1 and add the platform device:

    5. Make a patch with "git format patch HEAD^" and move it into the correct LibreElec distribution directory.

    6. Add "CONFIG_SND_SOC_RK3399_HIFIBERRY_DACPLUS=m" to your device's kernel defconfig in the LibreElec sources.

    7. Make the image and install it.

  • Getting LibreELEC to work with RockPi 4B and a Hifiberry DAC+ Pro XLR

    Quote from chewitt

    Commit device-tree changes for the different audio setup to an upstream kernel git source (Linux 6.6 for RK boards) then use "git format-patch" to create a diff patch that can be imported to "projects/Rockchip/patches/linux" in the buildsystem.

    Just to be sure I get you correctly, you're suggesting I should just make my changes straight inside arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dts, right?

  • Getting LibreELEC to work with RockPi 4B and a Hifiberry DAC+ Pro XLR

    Thanks you for the pointers! I'm building a (stock) image as I type this and everything seems to be going smoothly. Regarding the kernel driver, I'll need to patch an existing kernel driver, not just enable it, but I suppose I can do that with another patch.

    The documentation you pointed me to, mentions editing "projects/Generic/linux/linux.x86_64.conf" in order to enable a module. That's the file I need to edit too, even though the PROJECT I'm using is "Rockchip", not "Generic", right?

  • Getting LibreELEC to work with RockPi 4B and a Hifiberry DAC+ Pro XLR

    Hi,

    I have a RockPi 4B coupled with a Hifiberry DAC+ Pro XLR. The Hifiberry wasn't designed for the RockPi, but it is in fact compatible with it. I know it, because I have got it working on Armbian, with the 4.4 BSP kernel for a while now. As far as I can remember, what is needed in order to get it to work, are compiling and installing a kernel module for the PCM5242 DAC chip and an overlay, in order to configure the RK3399's pins for the proper modes needed to talk to the DAC.

    1. Can someone point me to the easiest way of doing the above, i.e. compiling a custom module and loading a custom device overlay, in libreELEC? Note that the PCM5242 is not supported by the Linux kernel, but, from what I remeber, the driver for the PCM512X chips, which are supported, can be used with some trivial changes. I'm not asking for help on modifying the driver code, just on building and loading the result on libreELEC.

    2. I did write the overlay (.dtb) file for my current setup, but this is applicable to the 4.4 kernel and it needs substantial changes for newer kernels as far as I recall. (There was at least a substantial change in the relevant sound subsystem design in the 4.19 release of the kernel or somewhere around that time anyway.) Sadly (or perhaps mercifully, depending on how one looks at it) I don't remember anything about writing, compiling and loading device tree overlays any more. If someone has some experience with it and would be willing to help out, I'd be most grateful.

    Thanks in advance,
    Dimitris