<Trinath>
Now i restarted my Root complex board (LS1043ARDB), then the LTSSM_EN bit of register PCIECTRL_TI_CONF_DEVICE_CMD is being cleared. When i re-enabled it again, BARs are not being assigned properly.
<Trinath>
Some of the registers (which are cleared by fundamental reset) are also being cleared on root complex restart
<Trinath>
How may i reconfigure again
<Trinath>
when link fails
<Trinath>
Note : LTSSM_EN bit of register PCIECTRL_TI_CONF_DEVICE_CMD in beagle board x15
rob_w has joined #beagle
otisolsen70 has joined #beagle
otisolsen70 has quit [Remote host closed the connection]
otisolsen70 has joined #beagle
ikarso has joined #beagle
SJFriedl has quit [Ping timeout: 240 seconds]
SJFriedl has joined #beagle
argonautx has joined #beagle
florian has joined #beagle
Shadyman has quit [Quit: Leaving.]
<set_>
Rise and shine!
<set_>
Does Native_SDK have a reasonable cross-compile idea or does native compiling suit it better?
<set_>
The reason I am asking is b/c of the sftp to the BBB or BBBW in this instance has naming concerns that are not solved easily.
<set_>
Anyway...I will keep trying. I even started a thread of a post on their forums regarding my ideas/errors and more.
<set_>
it seems wget does not work w/ that download. Hmm...off to try another resource.
rob_w has quit [Remote host closed the connection]
starblue1 has quit [Ping timeout: 256 seconds]
starblue1 has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]
Guest75 has joined #beagle
Guest75 has quit [Client Quit]
Guest49 has joined #beagle
<Guest49>
hi anyone here?
<Guest49>
just got beagle bone black, total noob on this, having issues with it connecting on hdmi got a philips curved monitor, tux logo appears in cornere then hdmi drops out any suggestions please
Guest49 has quit [Quit: Client closed]
Trinath has quit [Quit: Client closed]
<jkridner>
do you have a serial log?
<jkridner>
or maybe output of dmesg?
<zmatt>
set_: "wget does not work with that download" ?
<zmatt>
set_: if you're getting some sort of certificate error, it's a known issue caused by TLS libraries mishandling the expiration of a certain root certificate. two workarounds are given here: https://pastebin.com/uXrzuPTq
<zmatt>
wow, there are actually people using TLS-ALPN-01 challenge based validation? :D
<zmatt>
this sounds like it'll probably be a non-issue, and will at worst be a transient interruption for a small number of sites whose administrators don't read their email
hnv has quit [Ping timeout: 256 seconds]
<zmatt>
and at least some tools will automatically renew the certificate anyway
marcheu has quit [Read error: Connection reset by peer]
otisolsen70_ has joined #beagle
otisolsen70_ has quit [Remote host closed the connection]
<jfsimon1981>
I have a program running with PMW output, analog input read, etc...
russ has joined #beagle
<zmatt>
looks like the eqep kernel driver crashed
<zmatt>
which iirc is a non-mainline driver maintained out-of-tree, so my guess would be it's simply a driver bug
<zmatt>
presumably something to do with power management, i.e. it tried to access PWMSS while access to PWMSS was not enabled
<jfsimon1981>
that makes sense
<zmatt>
it actually looks like it interrupted some runtime power management code, so it's probably a race condition of sorts
<jfsimon1981>
I messed with analog read on this build and read a block device at iio:device0
<zmatt>
that's probably not related
<jfsimon1981>
ah
<zmatt>
are you using eqep ?
<zmatt>
I would assume so, given that it's evidently producing interrupts
<jfsimon1981>
not sure what this is
<zmatt>
although it's a bit weird that it would not be enabled.. generally it should be enabled continuously
<zmatt>
hmm
<jfsimon1981>
i'm not aware using it, the program makes use of ADC input an0 and pwm modules
<zmatt>
curious
<zmatt>
ohh, eqep seems to be constantly producing interrupts
<zmatt>
based on: grep eqep /proc/interrupts
<jfsimon1981>
ok
<zmatt>
hold on, but I have pwmss force-enabled right now... let's see if pwmss otherwise gets power-managed
<jfsimon1981>
i don't see it
<zmatt>
you're not seeing the counters increase? what if you enable a pwm output?
<jfsimon1981>
ah
<jfsimon1981>
i change the pwm duty cycle all the time on this program
<jfsimon1981>
only I thing I changed is i disable the pwm (0 > enable) when not in use
<zmatt>
you're seeing eqep's interrupt counters increase when you have a pwm output enabled?
<jfsimon1981>
how can i check this ?
<zmatt>
by enabling a pwm output and using the command I just gave, grep eqep /proc/interrupts
<zmatt>
and see if one or more of the counters in the second column are slowly increasing
<zmatt>
what exactly did you mean by "i don't see it" earlier?
<zmatt>
maybe I misinterpreted you
<zmatt>
if eqep's interrupt counters only increase if you have pwm outputs enabled then I understand what's going on
<SJFriedl>
I know I've been able to disable the BeagleBone bluetooth radio in the past but cannot for the life of me find it. Something about uEnv.txt maybe? Google has failed me.
<SJFriedl>
BBBW
<zmatt>
SJFriedl: you can disable individual functions using rfkill
<SJFriedl>
will that disable the actual radio emissions?
<zmatt>
yes, that's why rfkill is called rfkill
<SJFriedl>
excellent, thank you. This is new to me.
<jfsimon1981>
ok, well it does not seem to change
<jfsimon1981>
138: 0 INTC 79 Level eqep_interrupt
<jfsimon1981>
142: 0 INTC 89 Level eqep_interrupt
<jfsimon1981>
140: 6 INTC 88 Level eqep_interrupt
<zmatt>
jfsimon1981: regardless of whether any pwm outputs are enabled?
<zmatt>
(with non-zero duty cycle, just in case)
<jfsimon1981>
trying
<zmatt>
jfsimon1981: I just tested it here, if I enable a pwm output I see the interrupt counter of the eqep unit in the same pwmss slowly increase
<zmatt>
that's absolutely a bug in the eqep driver
<jfsimon1981>
ok i don't quite understand this at the moment
<zmatt>
so, the eqep driver is evidently not keeping the eqep device enabled, yet it does have an interrupt handler enabled which moreover gets periodic interrupts whenever the eqep module happens to be enabled anyway
<zmatt>
the three submodules (ecap, eqep, ehrpwm) of a pwmss module are however not individually power-managed, only the subsystem as a whole is
<zmatt>
so what's happening is that if the driver for any of the three submodules requests the module to be enabled, the whole pwmss is enabled and subsequently all three submodules
<zmatt>
e.g. enabling a pwm output causes the corresponding driver (ecap or ehrpwm, depending on what pwm output you're using) to enable the pwmss to be able to operate the pwm output
<zmatt>
and as a side-effect, the eqep module in the pwmss is also enabled, causing its periodic interrupts to resume
<zmatt>
that's showing that the eqep driver is receiving interrupts yes
<zmatt>
this is bogus since it's not keeping the eqep module enabled
<zmatt>
the eqep module is merely being enabled by accident as side-effect of the pwm output
<zmatt>
consequently, if the pwm output is disabled again, the eqep module also gets disabled again
<jfsimon1981>
it increases only when pwm is enabled.
<zmatt>
if the eqep interrupt by pure accident happens to trigger right at the moment eqep gets disabled by the kernel, the interrupt handler will try to access eqep while it's disabled, resulting in a bus error and kernel panic
<zmatt>
this is straight up a bug in the eqep kernel driver
<zmatt>
it looks like the eqep driver is compiled into the kernel rather than being built as module, so unfortunately you can't simply blacklist the driver
<SJFriedl>
how the heck have I missed rfkill all my life? Thanks zmatt
<zmatt>
SJFriedl: it *should* be persistent across reboot
<SJFriedl>
To my delight, it was. Thank you.
<zmatt>
jfsimon1981: however, the eqep modules can be easily disabled using an overlay
<jfsimon1981>
thanks Matt, either i'll be able to deal with this or i'll design the hardware externally to make use of PWM, which i definitely require for this purpoe.
<jfsimon1981>
Ah ah
<zmatt>
or you can force-enable pwmss manually
<zmatt>
or just never disable a pwm output when enabled
<zmatt>
jfsimon1981: https://pastebin.com/H7FiWVV1 this force-enables all three pwmss instances (you'll see all three eqep interrupt counters increase regardless of whether or not a pwm output is enabled)
<jfsimon1981>
thank you
<zmatt>
or you can disable the buggy eqep kernel driver by using the uio/eqep[0-2].dtbo overlays from my overlay-utils project
<zmatt>
(you could also combine them into one overlay to reduce the number of overlays enabled)
<zmatt>
jfsimon1981: pretty unlucky to get that kernel panic though! it looks like the interrupt only happens once per second, and to get the kernel panic requires that interrupt to happen within a time window that's probably a small fraction of a microsecond
<jfsimon1981>
this program works at about 150 Hz, not sure that's related, but it has a short loop
<jfsimon1981>
Ok running this pastbin instructions of yours, at the moment the kernel did'nt panic ...
<zmatt>
what would matter is how often you're disabling a pwm output
<jfsimon1981>
oddly the last code never disabled it but set the duty very low.
<jfsimon1981>
Seems to work
<jfsimon1981>
Thanks for this
<zmatt>
it's possible the pwm driver disables the output if the duty cycle is zero (when rounded to the resolution of the output)
<zmatt>
not sure, I'd need to check the driver
<jfsimon1981>
too complicated this beagle, has a lot features.
<jfsimon1981>
Works stable at the moment.
<zmatt>
oh as for what eqep does: it can do quadrature decoding and pulse frequency measurement, typically used for things like measuring motor speed
<jfsimon1981>
ok
<jfsimon1981>
back the full working code, see if it get running smooth now
<jfsimon1981>
i'd call that luck it triggered this bug, better sort it now than when the device is running in the field which it would be in a few weeks
<zmatt>
fair!
<zmatt>
if you're not using eqep, disabling it is probably better than the force-enable workaround... better if the buggy kernel driver doesn't get used at all
<zmatt>
"oddly the last code never disabled it but set the duty very low" => as far as I can tell this should not implicitly disable the pwm module hence should not be able to trigger the kernel panic
<jfsimon1981>
did you mean i should load in uEnv.txt
<jfsimon1981>
to enable
<zmatt>
those overlays would actually *enable* the eqep modules, which is pointless since you already have them enabled
<jfsimon1981>
ok
<zmatt>
I was specifically referring to overlays in my overlay-utils project that reconfigure the eqep modules for use via uio (which, if you don't use these, is effectively equivalent to disabling the eqep modules)
<jfsimon1981>
ok
<zmatt>
https://github.com/mvduin/overlay-utils ... if you clone this and run make, it'll build these (eqep0.dtbo, eqep1.dtbo, eqep2.dtbo) in the uio/ subdirectory
<jfsimon1981>
ok
shodan45 has quit [Ping timeout: 256 seconds]
sicelo has quit [Ping timeout: 256 seconds]
shodan45 has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]
<zmatt>
jfsimon1981: or you could save this as "disable-eqeps.dtsi": https://pastebin.com/1tKb9heD and then run "make disable-eqeps.dtbo"
<zmatt>
to create an overlay that truly disables the eqep modules (and does nothing else)
sicelo has joined #beagle
sicelo has joined #beagle
sicelo has quit [Changing host]
<jfsimon1981>
Cloned and built dtbo and dtsi
<jfsimon1981>
i'll be back in a moment
dinuxbg has quit [Ping timeout: 256 seconds]
dinuxbg has joined #beagle
argonautx has quit [Quit: Leaving]
<jfsimon1981>
Running on disable_eqeps.dtbo and commented out the workaround (48300000.epwmss ...).
<jfsimon1981>
cat /proc/interrupts | grep eqep
<jfsimon1981>
No results returned. Looks worked well.
vagrantc has quit [Ping timeout: 240 seconds]
vagrantc has joined #beagle
marcheu has joined #beagle
otisolsen70 has joined #beagle
<jfsimon1981>
Supply down 360 -> 240 mA throttling the frequency
<jfsimon1981>
sudo cpufreq-set -d 300 -u 1000
<jfsimon1981>
However cannot get it back up (will only work at 300 MHz from this point on)
<jfsimon1981>
Apparently the watchdog got turned on automatically by a cat on the device
<jfsimon1981>
Rebooted on me
<jfsimon1981>
Once you cat on :dev/watchdog0 it stars running and needs update. awesome
<zmatt>
jfsimon1981: fortunately only root can open the watchdog device
<zmatt>
normally I'd expect systemd to have opened it though
<zmatt>
hmm, maybe that's not enabled by default
<zmatt>
ah that requires e.g. RuntimeWatchdogSec or RebootWatchdogSec to be configured in /etc/systemd/system.conf
<hnv>
I was about to ask if it's enabled by default (and reset by systemd)... (Also I was initially thinking of cats and dogs)
<hnv>
(* not a Dog, a Cat triggering something...)
<zmatt>
jfsimon1981: what cpufreq governor are you using?
<jfsimon1981>
no idea
<zmatt>
then why are you setting the min/max frequency for that unknown governor to use? :D
<zmatt>
300-1000 is the default anyway
<zmatt>
if I select the ondemand or conservative governor I can see it's dynamically switching between frequencies
<jfsimon1981>
i set 300-1000 but it seems stuck at 300
<zmatt>
again, which governor? check with cpufreq-info
<jfsimon1981>
ok
<jfsimon1981>
i see
<zmatt>
powersave = always min frequency, performance = always max frequency
<jfsimon1981>
yep current policy 300-300 MHz
<jfsimon1981>
not sure how I set this but that's fixed 300 MHz now.
<zmatt>
ondemand seems to be min freq when idle, max freq when not idle... so cpufreq-info will always see it at 1 GHz (since running cpufreq-info means the cpu isn't idle) but you'll see the 300 MHz statistic increasing in between calls to cpufreq-info
<jfsimon1981>
indeed i'll set powersave something like this. That's a low consumption application i'm working on
<zmatt>
if you select the powersave governor then it'll be stuck at 300 MHz regardless of the max frequency configured
<jfsimon1981>
ok
<zmatt>
"conservative" may be the governor you're looking for
<zmatt>
and you're correct, "cpufreq-set -d 300 -u 1000" forces the system to lowest frequency, this is because you didn't include any units and the default unit is kHz
<jfsimon1981>
set in range 300-720 Mhz
<zmatt>
"cpufreq-set -d 300MHz -u 1GHz" would work ... though like I said
<zmatt>
the full range is already the default
<zmatt>
so the only reason to set the change is to set a lower max than 1GHz or higher min than 300MHz
<zmatt>
*to set the range
<jfsimon1981>
i set -u 720MHz
<jfsimon1981>
conservative
<jfsimon1981>
for the moment
<jfsimon1981>
good shape
<jfsimon1981>
watchdog enabled and solved the random crash, and added a kernel panic auto reboot.
<zmatt>
also keep in mind that setting a lower max frequency may not always work out to lower overall power consumption for a given workload, since lower frequency means that workload takes more time to execute, hence there's less cpu idle time. it'll depend on how much the power consumption varies between 720 MHz and 1 GHz, and how effective powersaving during cpuidle is
<jfsimon1981>
This device should do good
<jfsimon1981>
right, i did'nt measure it all
<zmatt>
like I said, for watchdog: set the RuntimeWatchdogSec parameter in /etc/systemd/system.conf
<zmatt>
to make systemd enable the hardware watchdog and periodically ping it
<jfsimon1981>
the application runs 1/3 which seems fine though i'll need test all of this
<jfsimon1981>
if you just cat the /dev/watchdog it starts
<jfsimon1981>
the default period is 60 sec
<zmatt>
I wouldn't suggest messing with the watchdog device directly
<zmatt>
leave it to systemd, or something like watchdogd on non-systemd systems
<zmatt>
if you want your application to be restarted when it crashes or freezes, you can arrange that in a systemd service for
<zmatt>
*service file
otisolsen70 has quit [Quit: Leaving]
<zmatt>
(you can even configure it so that if your application keeps crashing at startup, systemd will give up restarting your application after a few attempts and reboot the system instead)
<jfsimon1981>
ok
<jfsimon1981>
quite powerful
<zmatt>
yup, lots of options
<zmatt>
to detect services that are frozen (but not properly crashed) systemd supports "service watchdogs" .. which means your servics needs to periodically notify systemd that it's alive or systemd will restart the service after a timeout
<jfsimon1981>
ah ah
<jfsimon1981>
well the program seems to be working, so I can get back to work on the electronics quite soon