buzzmarshall has quit [Quit: Konversation terminated!]
ikarso has joined #beagle
charlie5 has quit [Quit: Leaving.]
charlie5 has joined #beagle
charlie5 has quit [Quit: Leaving.]
charlie5 has joined #beagle
LetoThe2nd has joined #beagle
Guest40 has joined #beagle
russ has quit [Remote host closed the connection]
argonautx has joined #beagle
florian has joined #beagle
Guest40 has quit [Quit: Client closed]
vd has quit [Quit: Client closed]
lucascastro has quit [Ping timeout: 244 seconds]
florian has quit [Remote host closed the connection]
florian has joined #beagle
lucascastro has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]
shoragan[m] has quit [Quit: Bridge terminating on SIGTERM]
RossSchulman[m] has quit [Quit: Bridge terminating on SIGTERM]
jduchniewicz has quit [Quit: Bridge terminating on SIGTERM]
mvaittin has quit [Quit: Bridge terminating on SIGTERM]
ArchismanDey[m] has quit [Quit: Bridge terminating on SIGTERM]
shoragan[m] has joined #beagle
Shadyman has quit [Quit: Leaving.]
mvaittin has joined #beagle
jduchniewicz has joined #beagle
RossSchulman[m] has joined #beagle
ArchismanDey[m] has joined #beagle
SymbioticFemale has joined #beagle
<SymbioticFemale>
anyone know how to do gpio based uart serial in openbsd?
<SymbioticFemale>
or how to fix whatever issue makes usb not work on the openbsd image?
<zmatt>
"gpio based uart" ?
<SymbioticFemale>
serial connection over the gpio pins
<SymbioticFemale>
the J pins 4/5 can do TX/RX but its not working for me. i think i need UART, aka, i need to use the TX/RX/CTS/RTS
<zmatt>
that's not really how you'd call that... "gpio" is a particular usage of a pin, meaning it's being manually controlled by software, so "gpio based uart" would imply a soft-uart or something (which is not really a thing in linux since it can't do stuff with the required timing accuracy, though pru can do it)
<zmatt>
normally a hardware uart is one of the very first drivers one would implement, since that's how you debug everything else
<zmatt>
so it sounds strange to me that that wouldn't be working on openbsd
<zmatt>
but I've also never used openbsd on a beaglebone and know nothing about it, so...
<SymbioticFemale>
hmm, ok, but for example, on the BBB debian image, only UART0 is configured by default and UART1-5 are to be enabled through modifications to uEnv.txt
<SymbioticFemale>
but on openbsd there is no uEnv.txt
<zmatt>
well, nowadays the debian images enable all uarts by default and allow you to configure pins at runtime using the config-pin utility
<zmatt>
by "modifications to uEnv.txt" I assume you mean enable an overlay
<SymbioticFemale>
ah ok. i never used the debian image because i don't like using unofficial images and the debian.org armhf image doesn't function on the beagle bone black
<zmatt>
these are basically patches applied to the Device Tree by u-boot (or in ancient times by the kernel), allowing for customizations of the DT without having to create an entirely custom base dtb
<SymbioticFemale>
yeah well given the history of beaglebone.org images implementing insecure-by-default settings, i tend to stay away from them, even though i do understand that practices have been changing
buzzmarshall has joined #beagle
<zmatt>
if you use a recent console image (it sounds like the IoT image wouldn't be for you) and change the password of the default account you should be fine
<zmatt>
the days of allowing passwordless root login are ancient history
<rcn-ee>
SymbioticFemale, it's a balance between "insecure" and "usable"... Currently everyone uses the same password for debian and root user... BUT SSH is disabled on root.. ssh keys are generated on first bootup.. so let me know how we can more secure..
<zmatt>
though the IoT images still aren't secure certainly
<zmatt>
rcn-ee: I mean, bonescript is still problematic I think?
<rcn-ee>
yeap nuke that... it's eol and not installed in bullseye..
<zmatt>
or like I said, grab the console image instead of IoT... I think anyone who's seriously trying to use openbsd will not need the stuff on the IoT image ;)
<rcn-ee>
yeap console is less crap then iot..
<zmatt>
SymbioticFemale: and at least when using a debian image stuff works... like, you know, the uarts ;)
<zmatt>
whereas I have a feeling that when using something like openbsd on a BBB you're pretty much volunteering to become a maintainer ;)
Guest8928 has joined #beagle
Guest8928 has quit [Ping timeout: 256 seconds]
lucascastro has quit [Ping timeout: 244 seconds]
vd has joined #beagle
buzzmarshall has quit [Read error: Connection reset by peer]
giort has joined #beagle
lucascastro has joined #beagle
giort has quit [Quit: giort]
buzzmarshall has joined #beagle
<mattb0ne>
Hi SymbioticFemale, I remember you from the debian channel
<zmatt>
SymbioticFemale: there is one person who knows a lot about openbsd on beaglebone, kremlin, but unfortunately I haven't seen him since #beagle moved from freenode to libera
russ has joined #beagle
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
florian has quit [Quit: Ex-Chat]
<vd>
hi zmatt -- for the USBMODEM_OC# line, you told me not to use the pwm 1 tripzone but rather keep it as a gpio. Should it be a simple gpio that userspace must export and read or should I maybe turn it into a input?
argonautx has quit [Quit: Leaving]
vagrantc has joined #beagle
<zmatt>
vd: it has nothing to do with pwm, I have no idea why the idea of configuring that pin as pwm 1 tripzone rather than gpio even entered your mind
<zmatt>
the purpose of pwm tripzone inputs are to disable pwm outputs based on a hardware signal, e.g. stop a motor when an emergency shutdown switch has been triggered
<vd>
I'm not talking about making it a pwm thing. I told you I wrongly associated pwm with power thingy and since OC stands for over current it seemed power related to me. But it'll be a gpio don't worry :)
<vd>
I'm now asking if a gpio-keys would be appropriate for this
<vd>
rather than a generic gpio
<zmatt>
you're using pwm 1 for the lcd backlight... what does that have to do with usb modem overcurrent?
<zmatt>
oh is that what you mean by "turn it into an input" .. I would not have guessed that you meant using gpio-keys
<zmatt>
gpio yes, gpio-keys no
<zmatt>
as for what you should do with it... no idea, that depends on your application
<vd>
yes the pin is configured with MUX_MODE7, but it doesn't seem convenient to check /sys/class/gpio/... for over current detection
<vd>
so I thought maybe an input event (like button) is appropriate?
<zmatt>
check the schematic what it's connected to, check the datasheet of the thing it's connected to to learn what the signal is used for, what it indicates, then figure out if there's some appropriate action that should be taken, then you can start figuring out how to best arrange for that
<zmatt>
until you have a concrete idea of what to do with it, just exporting it to userspace is probably the most sensible thing
<zmatt>
note that sysfs gpios support generating events, you don't need to poll it to know when an overcurrent happens
<vd>
it is connected to the OC2 pin of a TPS2062DR
<zmatt>
the corresponding power output of which presumably connects to your usb modem?
<vd>
ho sysfs gpio support events, true
<vd>
hum no, out1 and out2 are connected to the 5V_USB1/2
<zmatt>
which are?
<zmatt>
or rather, which connect to ?
starblue has quit [Ping timeout: 244 seconds]
starblue has joined #beagle
<vd>
the chained usb interface? erf hard to say. I'll keep it as a generic gpio...
<vd>
I'll finish configuring the gpio-hog for the usb pinmux and I'll get back to the final and more interesting topic: the LCD.
<vd>
zmatt I have this usb_pins pinmux config with 10 lines configured with MUX_MODE7 that I must hog. But there don't all belong to the same gpio chip (some are 2.05, 1.19, etc.). Would you split the pinmux config, or would you attach this single pinmux to something else (not a gpio chip node)?
Guest89 has joined #beagle
<vd>
s/there/they/
buzzmarshall has quit [Quit: Konversation terminated!]
starblue has quit [Quit: WeeChat 3.0]
buzzmarshall has joined #beagle
<zmatt>
vd: I already mentioned that I'd be using gpio-of-helper so this problem doesn't exist for me
<vd>
I didn't understand the implication for the pinmux at first, now I do
<vd>
I'll try to find out how to create a dummy node in mainline, otherwise I'll attach the pinmux to something else, like usb0 or usb1 :-s
LetoThe2nd has quit [Quit: Connection closed for inactivity]
<vd>
how the system knows about the usb interfaces though? I only see 5V lines connected from the soc
mgsb has quit [Ping timeout: 250 seconds]
mgsb has joined #beagle
<zmatt>
there's no such thing as a "dummy node"
<zmatt>
pinmux can only be attached to actual device nodes
<zmatt>
the system knows about usb the exact same way any other system knows about usb devices: via usb
<zmatt>
usb has discovery built-in
<zmatt>
it's weird that you have so many usb-related gpio... normally those signals would go to your usb hub chip, not the bbb
<zmatt>
i.e. normally the usb hub chip would control port power and monitor overcurrent
<zmatt>
and linux would be able to toggle port power and be notified of overcurrent events by communicating with the usb hub chip via usb
<zmatt>
assuming you have a hub chip, otherwise I'm even more confused
<vd>
but how does usb work in the first place, from the soc side? i.e. i2c or spi requires e.g. clk and sda lines, I don't see where my usb hubs go and how they are discovered
<zmatt>
ehm, the bbb has a usb host port
<zmatt>
you plug a usb device in
<zmatt>
usb has dedicated lines
<vd>
so I must have the usb hub hard wired into the soc usb host port?
<zmatt>
(since it's a rather high-speed interface with specialized transceivers)
<zmatt>
there's no usb on the expansion header pins if that's what you're asking
<zmatt>
so if your board is using usb, presumably there's a little cable from the bbb's usb host port to the board
<zmatt>
I'm puzzled by these questions... you have the schematic and presumably one of these boards right next to you, surely you're in a better position to determine how things are connected than me?
<vd>
well I'm just less skilled than you in this area for sure
<vd>
you were right
<vd>
little cable it is
* vd
is still learning a lot in this area
<zmatt>
for the task you're doing it would definitely be useful to have at least a basic understanding of electronics
<zmatt>
specifically digital electronics
<vd>
that's a void I'm trying to fill
<vd>
I was usually working on a slightly higher level (kernel, userspace), assuming dts are already written and functional
<zmatt>
or pair up with an electronics guy
<vd>
I wish
<zmatt>
who knows how to read the schematic, and how to determine things like "does this net have an external pull-up/down"
<zmatt>
and "what is this signal for? what am I supposed to do with it?"
<vd>
I'm kinda on my own unfortunately, so you're mostly that guy at the moment
<vd>
I definitely owe you a few beers
<zmatt>
a .dts is a description of your hardware... making that description (especially _accurately_) if you don't know hardware is... not efficient at least
<vd>
that's one reason why I would love to open source it in the near future, but that will be a internal battle for sure
<zmatt>
and yeah but you've been leaning a bit too heavily on me...
<vd>
sorry about that
SymbioticFemale has quit [Ping timeout: 276 seconds]
<zmatt>
is there noone in your organization that can help you with this?
<zmatt>
particularly the aspect of understanding the schematic, a task for which you evidently have no training
<vd>
it's a very small company unfortunately
<zmatt>
as in, there's noone with electronics knowledge?
<zmatt>
that sounds inconvenient when you're making electronics :P
<vd>
as in a company with a product designed a long time ago
<zmatt>
and let all electronics people go while still either manufacturing or maintaining a piece of custom electronics? :P
<vd>
it's like you're working in the ideal company, are you? ^^
<vd>
zmatt actually there's a guy with electronics knowledge who might help, I'm trying to book him
<zmatt>
sounds like a good idea
<zmatt>
like, the alternative is just becoming an electronics guy yourself... but this isn't the place for getting an electronics 101 tutor :P
<vd>
that's a knowledge I definitely want to get, so I'm learning how I can. Again, sorry for the inconvenience and poking you that much
<vd>
zmatt in the meantime, I think I can do something better for the rtc with the device tree. I'm doing this rtc bad hack to power cycle the board in case the ethernet link is down. The service actually does only this: `i2cset -f -y 0 0x24 0x0a 0x00 ; rtcwake -m off -s 10`. I know it's ugly and dangerous, but I think I could 1) avoid the i2cset call
<vd>
with a device tree setting 2) with the rtc configured in the device tree to power cycle, I could make the bootloader reset the system instead of waiting for a userspace service, a bit less risky I presume...
<zmatt>
1. you in fact shouldn't "avoid the i2cset call with a device tree setting", the register should not be set to zero except when you're doing this hack (in fact I'd first setup the rtc and only *then* set pmic register 0x0a to 0x00)
<zmatt>
2. doing it in the bootloader is probably safer, and if you do it there then device tree is unimportant since that's information for the kernel
<vd>
for 1. isn't there something to do to expose this pmic register to userspace rather than calling i2cset directly?
<vd>
2. the bootloader can and does read the device tree if I'm not mistaken
<zmatt>
no, i2cset (or the underlying syscalls) is the right tool for the ugly job
<vd>
ok
<zmatt>
2. yes I think recent u-boot versions can get some information from a DT (that's compiled into the bootloader I think, otherwise you have a chicken-and-egg problem) though I doubt it knows about this setting, but who knows
<zmatt>
not really important anyway, you shouldn't mess with this setting in DT
<vd>
ok
<zmatt>
the OFF-bit (bit 7 of pmic register 0x0a) should normally be set at all times to absolutely avoid unintentionally entering rtc-only mode
<zmatt>
the steps for this hacky power-cycle trick are basically: 1. ALARM2 (for poweroff) and ALARM (for poweron) in the RTC, e.g. 2 and 3 seconds in the future respectively 2. clear the OFF-bit in the pmic (to enter rtc-only mode instead of shutdown mode when the rtc deasserts power-enable to the pmic) 3. twiddle thumbs until the power cycle happens 4. pray your hardware isn't getting fried by what ...
<zmatt>
...you're doing
<vd>
zmatt you were saying that externally powered devices (including the SD card) might be fried by that, but from within the bootloader, would it make it safer to e.g. shutdown the mmc, do the check and power cycle eventually, and enable the device again if the check passes?
<zmatt>
no that's not what I said
<zmatt>
I said that depending on external hardware you may fry the beaglebone, the SoC itself rather
<vd>
ha ok
<zmatt>
nah just avoid having any command/transfer in progress to SD or eMMC, which should be a non-issue in u-boot since afaik it doesn't have a concept of doing transfers in the background while also doing something else
<vd>
is there a way to prevent this? or limit the probability while doing this ugly hack?
<zmatt>
depends on hardware
<vd>
ok
<zmatt>
the biggest risk factor is your custom stuff
<zmatt>
(and analyzing that risk is beyond your current skill set)
<vd>
might be simple to use i2cset to configure ALARM2 and ALARM from the bootloader rather than the rtc maybe
<zmatt>
ALARM/ALARM2 are rtc registers, not pmic registers, hence not on i2c
<zmatt>
(note that when I say "rtc" I mean the built-in rtc of the AM335x, not your external rtc)
<vd>
ha true
<vd>
i'll see how to access the rtc from barebox
Guest89 has quit [Ping timeout: 256 seconds]
set_ has quit [Ping timeout: 248 seconds]
buzzmarshall has quit [Quit: Konversation terminated!]
set_ has joined #beagle
buzzmarshall has joined #beagle
set_ has quit [Quit: I thought I saw a puddy-cat...]