<mattb0ne>
i am going to read up how __R30 maps to the pins
<mattb0ne>
in the manual I think there is something on it there.
mattb0ne has quit [Ping timeout: 240 seconds]
Guest22 has joined #beagle
Guest22 has quit [Client Quit]
<zmatt>
what errors? it compiled for me. note that I'm declaring __R30 myself which is probably a rude thing to do, it's no doubt in some header but I was too lazy to check which
<zmatt>
also I have no idea what this stddev.h include is that you added
<zmatt>
e.g. "pru 0 out 7" means it's bit 7 of R30 for pru core 0, provided the pin (P9.25) is configured into pruout mode
<zmatt>
be advised that R30 (like other pru registers) does not seem to have a reset and therefore has random content at power-on, so I'd suggest initializing R30 before changing the pin mode to pruout since the moment you do so it would drive these random values onto the pins
<zmatt>
calling .initialize() on the subsystem using py-uio will call .full_reset() on both cores, which resets their R0-R30 registers to zero
<zmatt>
(it also resets the programmable bits of the constant registers to zero)
CrazyEddy has quit [Ping timeout: 250 seconds]
CrazyEddy has joined #beagle
Ador has joined #beagle
<Ador>
hi we are facing issue with restart beaglebone black v3 automatically reboot after sometime.
<Ador>
how we can check reboot logs or why restarted?
<zmatt>
Ador: if it was a clean reboot then it should have logged what happened to eMMC... either in journal (if persistent journal has been enabled, i.e. if /var/log/journal/ exists) or in some legacy logfiles in /var/log/ (if rsyslogd is installed)
<zmatt>
if it's a kernel panic or other unclean reset then you may need to monitor the serial console (via the 6-pin console header) to know what happened
<zmatt>
(I don't exclude the possibility there's ways to ensure some logs survive in memory across a reset, but I have no experience with any)
ikarso has joined #beagle
Shadyman has quit [Quit: Leaving.]
<Ador>
root@beaglebone:/# last --systemrunlevel (to lvl 5) 4.19.94-ti-r36 Thu May 18 18:52 still running
<Ador>
reboot system boot 4.19.94-ti-r36 Sat Jan 1 05:30 still running
<Ador>
reboot system boot 4.19.94-ti-r36 Sat Jan 1 05:30 still running
<Ador>
Not seen any specify in journal about reboot. this happened after every 3 days/
<zmatt>
please don't copy-paste multi-line stuff into chat, it's spammy. to share multi-line text snippets use a paste service like pastebin.com
<zmatt>
anyway, I'm not really familiar with "last --system", given that it's talking about runlevels (which are a legacy concept that no longer applies) I'm guessing it's something ancient, but it doesn't seem to be logging anything about the shutdown/reboot, just about the boot itself, suggesting they're some form of unclean reboot (e.g. kernel panic)
<zmatt>
and maybe make the console more verbose by removing the "quiet" option from the "cmdline" variable in /boot/uEnv.txt .. this increases the amount of information logged to the serial console
<zmatt>
(though if a kernel panic happens, that will get logged to the console regardless)
mattb0ne has joined #beagle
<mattb0ne>
zmatt would I run into a problem if two PRU are accessing the same spot in shared memory
<mattb0ne>
one writing one reading
<zmatt>
uhh no, why? you've been doing that exact thing with the encoder
buckket has quit [Quit: buckket]
buckket has joined #beagle
<mattb0ne>
true
<mattb0ne>
can you have a race condition with the PRUs
<zmatt>
I mean, obviously?
<zmatt>
anything that involves doing multiple things at the same time, especially using multiple cores (but even without) has the potential to have race conditions
<zmatt>
however, individual reads and writes of an integer variable in PRU memory by a PRU core (or, for properly aligned variables, the ARM core) are atomic
<zmatt>
so if a variable only gets written by one particular core (and the other only reads) then there's not much to worry about, as long as the other core's program is written with understanding that the variable may change at any time (be sure to declare it as "volatile" for that reason)
mattb0ne has quit [Ping timeout: 240 seconds]
ki-ng has joined #beagle
<ki-ng>
How are?
<ki-ng>
Good hot wheels
<ki-ng>
Does some use commercial ki?
<ki-ng>
Sticker crowll to next gen party
<ki-ng>
See you tomorrow…
ki-ng has left #beagle [#beagle]
Ador has quit [Quit: Client closed]
mattb0ne has joined #beagle
Guest6 has joined #beagle
Guest6 has quit [Client Quit]
<mattb0ne>
so what does atomic mean in this case
<mattb0ne>
and if I am reading your paste bin correctly you are using pins P9.31 and P9.29 becaause of bits 0 and 1 on __R30
<mattb0ne>
if I wanted to use P9.27 I could just change to the following for example #define CW (1u << 5)
mattb0ne has quit [Ping timeout: 240 seconds]
mattb0ne has joined #beagle
<zmatt>
mattb0ne: atomic means indivisible, i.e. any other operations by other cores are (or can be interpreted as being) either before it or after it, but they'll never witness the operation being only partially completed.
<zmatt>
e.g. if an uint32_t variable is 0 and you write 0xffffffff to it then another core that reads the variable will read either 0 (if it's just before it) or 0xffffffff (if it's just after it)
<zmatt>
but not, like, 0x00ffffff
<zmatt>
and yes you're obviously free to choose whatever output pins you want
<mattb0ne>
thanks for the explanation
<mattb0ne>
on the __R30
<mattb0ne>
how do I map the pins to bits in the __R30 output register
<mattb0ne>
i just updated my overlay to use P9.31 and P9.29
<mattb0ne>
that would be bits 0 and 1 on your sheet
<mattb0ne>
but if I wanted to use P9.41 and P9.42 I would use bits 4 and 6
Stat_headcrabed has quit [Quit: Stat_headcrabed]
mattb0ne has quit [Ping timeout: 246 seconds]
buzzmarshall has joined #beagle
<zmatt>
note that instead of using the overlay you may actually want to use cape-universal for this because of the initialization issue I've mentioned previously... if the pins are configured to pruout mode by your overlay then you don't have an opportunity to initialize R30 before muxing the pins
<zmatt>
and do you still have a question about the pins/bits? because it looks to me like you answered your own question
mattb0ne has joined #beagle
mattb0ne has quit [Ping timeout: 268 seconds]
mattb0ne has joined #beagle
<mattb0ne>
but wont turning on the cape universal mess up my other overlays I need them for the UART
<mattb0ne>
i actually have never performed any pin muxing outside of an overlay
<mattb0ne>
I would use the adafruit library or something for that?
<zmatt>
I don't think I've ever seen any adafruit code I'd want to use :P
<mattb0ne>
lol
<zmatt>
if your overlays appropriately disable conflicting pins (like the examples in overlay-utils do) and you have a sufficiently recent kernel ( https://pastebin.com/2w2XtJBP ) then there should be no problem with enabling cape-universal... I suppose you could alternatively make a custom pinmux helper in your own overlay
ikarso has quit [Quit: Connection closed for inactivity]
<mattb0ne>
ok I will give this a shot
<mattb0ne>
but in your mind cape universal should work
<mattb0ne>
would making the BBB ip address static make it easier for me to connect over ethernet
<mattb0ne>
right now I connect to beaglebone local
<mattb0ne>
but sometimes it does not resolve the IP and I have to restart the BBB, the computer or both for it to connect
<mattb0ne>
wondering if there is a way to make that process more optimal
<zmatt>
I mean, that depends on what's going on with your network.. generally speaking I see no reason for configuring a static ip
<zmatt>
but it's possible you may be running into a long-standing avahi bug that causes it to sometimes mistakenly collide with itself, resulting in a hostname change to deconflict itself from this imaginary conflict... so next time this happens try connecting to beaglebone-2.local to see if that works
<zmatt>
and yeah cape-universal should also work, though perhaps it's more elegant to use the custom pinmux helper instead of a mix of overlay-based config and cape-universal-based config
<zmatt>
mattb0ne: also, you should always be able to reach the beaglebone via its link-local ipv6 address
Guest4494 has joined #beagle
<zmatt>
further removing any need to configure a static ipv4 address
<Guest4494>
I've booted a BBB from a microSD card. In /dev/, I see mmcblk0 but no mmcblk1. dmesg also mentions only mmcblk0.
<Guest4494>
This board was working a couple months ago, but I don't recall if I used an SD card or the on-board flash then.
<Guest4494>
But even if it were an SD card, I got no indication then that anything was wrong.
<Guest4494>
I've got a serial console on it; when I power it up without an SD card, I just get a repeating C across the terminal, about one per second.
<Guest4494>
Any ideas as to how to further debug this problem? Or should I just mark it as having no on-board flash and move on?
mattb0ne has quit [Ping timeout: 240 seconds]
<zmatt>
Guest4494: I don't suppose the system on sd card might be disabling eMMC via /boot/uEnv.txt ?
<zmatt>
maybe check the kernel log for messages regarding mmc1 or mmcblk1 ?
<Guest4494>
zmatt, I don't think so, but I'll check it out.
<zmatt>
does /sys/class/mmc_host/mmc1/ exist?
<Guest4494>
Yes, /sys/class/mmc_host/mmc1 is there.
<zmatt>
okay so the mmc controller is enabled in DT, so then there's almost certainly messages in the kernel log about this
<zmatt>
journalctl -k | grep -P 'mmc1|mmcblk1'
<zmatt>
(don't paste results into chat, use a paste service like pastebin.com to share multi-line text snippets)
Guest4494 has quit [Quit: Client closed]
Guest4494 has joined #beagle
<Guest4494>
Got disconnected. Not sure if my previous messages came through or not, but now the board won't boot even from the SD card. Pressing S2 or not makes no difference.
<Guest4494>
Just get the CCCCC... on the console.
<Guest4494>
I think it's dying.
<zmatt>
Guest4494: I once had a damaged board where something (pretty sure it was the eMMC) was loading the 3.3V supply so heavily that it was sagging to the point of not being able to boot from SD card
mattb0ne has joined #beagle
<Guest4494>
I re-did the SD card (wiped out partitions, made new one, new FS, etc.) and now the board will boot from it. But still no /dev/mmcblk1 device.
<Guest4494>
Another oddity: I've got another BBB that's fine. It's got a cape that powers an ATTiny85, an LED strip, and monitors a PV cell. It's pulling about 500mA.
<Guest4494>
The troublesome board has no cape and isn't doing anything, it's just sitting there. But it's pulling 700mA.
<Guest4494>
I think that one's going to go in the bin. I'll just never be able to trust it any time there's any sort of problem.
mattb0ne has quit [Ping timeout: 256 seconds]
Stat_headcrabed has joined #beagle
Stat_headcrabed has quit [Quit: Stat_headcrabed]
<zmatt>
sounds like a good idea
Guest78 has joined #beagle
Guest78 has quit [Client Quit]
PhotoJim has quit [Ping timeout: 264 seconds]
PhotoJim has joined #beagle
mattb0ne has joined #beagle
<mattb0ne>
grrrr
<mattb0ne>
dumb beagle
<mattb0ne>
if you are unable to determin any DNS servers should that matter with a local network
Guest4494 has quit [Quit: Client closed]
<mattb0ne>
so I used nmap and the beagle is not joining my network
<zmatt>
mattb0ne: ???
<zmatt>
what do you mean by "join" your network?
<mattb0ne>
for some reason I cannot connect
<zmatt>
and just don't mess with network settings. especially don't do any manual configuration of ethernet unless you're the network administrator of the network to which you're connected
<mattb0ne>
I was tweaking the overlay
<mattb0ne>
and now I cannot logon
<mattb0ne>
i was trying to see if I could see it on my local network
<mattb0ne>
with nmap
<mattb0ne>
nothing is coming up
<mattb0ne>
sometimes this would give me trouble but never this much
<zmatt>
I mean, is it booting? because there's no plausible reason for tweaking an overlay to cause network problems, but it's plenty plausible for it to cause boot failures
<mattb0ne>
i am using my serial corde
<mattb0ne>
initramfs is never a good sign
<zmatt>
it drops you into initramfs? that sounds very odd
<zmatt>
did you mess with pins belonging to eMMC or something?
<zmatt>
it looks like it's failing to boot from sd and instead falls back to booting from eMMC, except a bunch of settings from the /boot/uEnv.txt it loaded from SD didn't get reset to their defaults including the disable_uboot_overlay_emmc=1, so now the linux booting from eMMC has no access to its root filesystem hence drops you into initramfs
<mattb0ne>
how do I fix something like that
<zmatt>
well, if you remove the sd card it should boot normally from eMMC, and then you can use that to fix your sd card
<mattb0ne>
is it just my uEnv.txt file?
<zmatt>
I don't know yet why it's failing, I'm still staring at this output
<zmatt>
but logically speaking, the problem is with whatever you changed between the last successful boot and now :P
<mattb0ne>
right but as you said there is only so mutch damage I could do with a bad overlay
<zmatt>
well unfortunately a bad overlay does tend to cause boot failure, u-boot's error handling is not very graceful
<zmatt>
the main problem is that a failure to apply the overlay causes the entire dtb to be discarded, which is just some braindead u-boot code
<zmatt>
so all of the FDT_ERR_BADMAGIC stuff is just a consequence of that: the dtb has already been discarded at that point due to a previous error
<zmatt>
it loaded /lib/firmware/shutter_steppers.dtbo but is unable to apply is because something is "not found" .. that something will almost certainly be a reference to a node in the base dtb, e.g. &label_with_typo
<zmatt>
I've tested the stepper overlay I pastebinned though, so my guess is you changed something?
<zmatt>
it would be nice to have a tool that verifies an overlay applies cleanly to a base dtb.. and I don't think that would even be particularly difficult
<zmatt>
so you can check an overlay *before* booting with it
<mattb0ne>
yeah
<mattb0ne>
that would be nice
<mattb0ne>
booting now
<mattb0ne>
I disabled all the overlay
<mattb0ne>
checking one by one
<mattb0ne>
though
<mattb0ne>
per your last comment
<mattb0ne>
I may not use what I made since it borks the board anyway
<zmatt>
if you want me to double-check you can pastebin your overlay source
<zmatt>
simply invoke it with the name of the compiled overlay(s) to check
<zmatt>
path of overlays rather
<zmatt>
I see the mistake in that overlay source btw, but try using the utility since that'll help you more in the long run then me just pointing out the mistake
<mattb0ne>
ok
<mattb0ne>
thanks
<mattb0ne>
I will pull the update
<mattb0ne>
does near map to 0x10100
<mattb0ne>
trying to map from the python side
<zmatt>
uhh, almost certainly "no" but clarify your question
<mattb0ne>
shared values on the PRU are going to cregister "LOCAL",near
<mattb0ne>
i am loading this on PRU0
<mattb0ne>
for the interface variables
<zmatt>
oh right that was the version I had uncommented... like I said I was still struggling with how the fuck you're supposed to convince the compiler to place stuff at a known location *and* generate efficient access
<mattb0ne>
on the python side I am calling core_0.map(SharedVars, 0x10100)
<zmatt>
a cregister-near access is efficient, a location attribute forces a fixed location, but clpru refuses to accept both at the same time
<zmatt>
which is the linker script used by the C/C++ firmware examples of py-uio
<mattb0ne>
how do I invoke the linker
<mattb0ne>
also not getting a handle node warning how would i fix that
<mattb0ne>
phandle node
<zmatt>
mattb0ne: oh, those are bogus warnings from dtc, I've pushed a fix to suppress those
<zmatt>
what do you mean 'invoke the linker" .. the makefile you're using to build your pru firmware takes care of that
<mattb0ne>
do I have to save it as something so the makefile sees it
<zmatt>
again, it's a modification to your existing linker script, which is generally called am335x.cmd and located in the same dir as your source code and your makefile
<mattb0ne>
I see it should replace that
<mattb0ne>
got it
<mattb0ne>
let me fix that
<zmatt>
bbl
<mattb0ne>
ok
<mattb0ne>
when you get back I get a compile error
<mattb0ne>
with the new script
<mattb0ne>
might be me but let me check
<mattb0ne>
unrefined symbol
<zmatt>
mattb0ne: first, with check-overlay updated to suppress spurious warnings from dtc, is the output now clear to you? did it enable you to find the problem in your overlay?
<zmatt>
second, ffs if you want help with an error can you PLEASE give the complete error (pastebin if more than one line) together with sufficient context about what you're doing. like what the fuck do you think I'm going to do with "<mattb0ne> unrefined symbol" (which I assume is a typo for undefined symbol)... how on earth do you think anyone is going to be able to give useful feedback on that?
<zmatt>
I feel like all evening I've been forced to ask you to clarify or expand on whatever problem you're having because you're not giving enough info to actually go on
<zmatt>
and it's getting tiresome
<static_rocket>
@zmatt:libera.chat: haha i want "<mattb0ne> unrefined symbol" to become the new generic error code for some tool now
<bryanb>
haha any time you mess up trying to pack a structure... it's unrefined ;)