kiwi.bin fails on PMUX check

SV3EXPSV3EXP
in KiwiSDR Discussion
After some recent power failulers I ended up with a non functional board.
It seems that kiwi.bin is complaining about some EEPROM stored values that are not as expected.
For instance "PMUX 0_30 got 0x37 != want 0x2f" and then it paniced.
In my desperate attemps to bring back the SDR live again, I commented the panic at line 101 of platform/beaglebone_black/peri.cpp and it worked!
However it doesn't seem so normal to have some bad values stored at EEPROM, even though I am not aware of their use. Is there a way to re-flash the EEPROM remotely, or alter those bad values to the defaults?
Now everytime an update comes, I have to manually insert a comment and recompile in order to be on air!

73's de SV3EXP

Comments

  • jksjks
    Well, that's very strange.
    Despite what the code looks like it has nothing to do with the EEPROM (Beagle or Kiwi). That EEPROM data structure is only used by the factory.

    1) Have you done anything to update or change Linux or the Debian distribution (e.g. run "apt-get upgrade").
    2) Can you show me all the PMUX messages now that you have the panic commented out?

    Thanks

  • SV3EXPSV3EXP
    Here they are attached :)




    Attachments:
    https://forum.kiwisdr.com/uploads/Uploader/86/dcd0dc676a7a2e29dfffc663037008.txt
  • SV3EXPSV3EXP
    As for apt-get update/upgrade, yes I've run it a couple of times but I can't correlate it with the issue.
    When this happened, I was trying a new low noise power supply for my KiwiSDR and there were multiple reboots, and multiple failed boots due to insufficient power.
  • jksjks
    If you login to the Beagle and type "dog" what do you get? Does it look like this?


    root@kiwisdr:~# dog

    BeagleBoard.org Debian Image 2016-05-13

    Linux kiwisdr 4.4.9-ti-r25 #1 SMP Thu May 5 23:08:13 UTC 2016 armv7l GNU/Linux


  • SV3EXPSV3EXP
    exactly like that.
  • jksjks
    Okay, so it looks like they changed the cape overlays in a recent apt-get upgrade. But when I upgraded mine it didn't trigger the panic. Have you loaded any device packages or done any other non-standard customization to your Kiwi Beagle? (I'm guessing not).

    I don't understand why the PMUX values would have changed for the unused GPIOs but since the Kiwi seems to work with the panic commented out I will do the same for the next release (v1.30) going out in a few hours.

    This whole PMUX management business is one of the biggest failures of the whole Beagle BSP architecture IMHO. I can't tell you how many hours I've wasted chasing problems. It doesn't help that it seems to be a moving target.

  • SV3EXPSV3EXP
    No, I haven't installed any additional software, the beagle is dedicated to kiwiSDR.
    Everything seems normal now with version 1.30!

  • jksjks
    In case anyone is interested I'll explain: For various reasons a user program (one with privileges) cannot directly change the pin mux (PMUX) that determines which device functions and attributes are assigned to the I/O pins of the Sitara processor used on the Beagle. This is specified by device (cape) overlay files used by the kernel and by some other mechanisms. So there is some checking code to make sure the pins are in the state the Kiwi server expects. The panic you saw occurred when one of the unused expansion pins on the P8 connector was detected to have been set as an input with a pull-up rather than a plain input with no pull-up or pull-down. More pins were in unexpected states as shown in the file you attached.

    Now this by itself is not a problem. But the real question is why is this different all of a sudden when there are hundreds of other units out there running without an issue? This is one of the reasons why the Kiwi is shipped with a fixed, known-working Debian distribution. To try and eliminate the side-effects of dependancies like these.


    KA7U
Sign In or Register to comment.