ikarso has quit [Quit: Connection closed for inactivity]
calculus has quit [Ping timeout: 250 seconds]
Paul has joined #beagle
calculus has joined #beagle
<Paul>
Curious if anyone knows the max storage capacity that would work on a Beagle Bone Black in the USd slot?
<zmatt>
anything
<Paul>
so even 2Tb?
<zmatt>
there was a significant protocol change when SD cards went above 2 GB (from SDSC to SDHC), but from there up to and including 2 TB is all the same format (SDXC isn't a really new protocol, it's mostly just marketing)
<Paul>
awesome, thanks Matt!
<zmatt>
dunno if SDUC changes anything of substance, though even if it were to that just means software (i.e. the linux kernel) needs to support it, hardware doesn't care
<Paul>
I'm going to be running stock Beagle Bone Black- Debian Buster
<zmatt>
2TB isn't SDUC anyway
<zmatt>
and SDHC/SDXC is supported by anything that isn't from ancient prehistory
<Paul>
awesome, I'll most likely grab a 512Gb, but just wanted to make sure. Nice to know we can hit that high if need be.
<zmatt>
what are you doing that needs such immense amounts of storage?
<Paul>
Temporary Cache of file storage to circumnavigate USB thumb drive restrictions
<zmatt>
usb thumb drive restrictions?
calculus has quit [Ping timeout: 252 seconds]
calculus has joined #beagle
<Paul>
can not use usb thumb drive on corporate network
starblue3 has quit [Ping timeout: 250 seconds]
<zmatt>
ah you're the weird network file transfer thingy project
<zmatt>
with silly corporate network rules
starblue3 has joined #beagle
Paul has quit [Quit: Client closed]
Shadyman has joined #beagle
calculu5 has joined #beagle
calculus has quit [Ping timeout: 240 seconds]
calculu5 has quit [Ping timeout: 240 seconds]
calculus has joined #beagle
calculu5 has joined #beagle
calculus has quit [Ping timeout: 250 seconds]
paulbarker has quit [Read error: Connection reset by peer]
paulbarker has joined #beagle
mattb0ne has joined #beagle
mattb0ne has quit [Ping timeout: 248 seconds]
buzzmarshall has quit [Quit: Konversation terminated!]
_whitelogger has joined #beagle
kveremitz has quit [*.net *.split]
outrageous_ has quit [*.net *.split]
Patater has quit [*.net *.split]
noahm has quit [*.net *.split]
noahm has joined #beagle
noahm has quit [Changing host]
noahm has joined #beagle
outrageous has joined #beagle
Patater has joined #beagle
kveremitz has joined #beagle
outrageous has quit [Ping timeout: 240 seconds]
vagrantc has quit [Quit: leaving]
GenTooMan has quit [Ping timeout: 250 seconds]
LetoThe2nd has joined #beagle
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
markand has left #beagle [#beagle]
xet7 has quit [Remote host closed the connection]
florian has joined #beagle
xet7 has joined #beagle
xet7 has quit [Read error: Connection reset by peer]
xet7 has quit [Read error: Connection reset by peer]
<vd>
would you guys redefine all pinmux for your custom bbb daughter board or only the ones that aren't defined in the boneblack dts files?
xet7 has joined #beagle
<zmatt>
what do you mean by "redefine all pinmux"
<zmatt>
pinmux is defined and associated with devices you add (either by declaring them or by enabling a predeclared one)
<zmatt>
the boneblack dts doesn't define any pinmux other than for the devices it defines/enables
<vd>
I am currently rewritting my dts from scratch (#include'ing "am335x-boneblack.dts" for sure) and I am adding pinctrl-single,pins blocks into am33xx_pinmux for all pins used by the daughter board in my datasheet. But then I'm wondering if that's the good thing to do for pins like LCD_* which are already enabled (not an hdmi screen though)
<vd>
It can be hard to lookup if a given pin is already declared and where it is
<zmatt>
if you're using video but not hdmi you'll need to redefine a whole bunch of stuff anyway
<zmatt>
ideally you'd #include a dts which doesn't define the hdmi stuff in the first place, but I guess mainline linux doesn't offer one so you'll have cleaning up to do
<zmatt>
I mean, you're not using mainline, but same thing applies to the TI kernel no doubt... which kernel are you using exactly?
<vd>
yeah I recall 5.4 but this 5.10 is out in their layer, that's what must be built, I'll confirm that
<zmatt>
but yeah ok, I was confused by the "staging" (which I hadn't seen in a repo name), but that was just part of the recipe name for some reason, it's just the TI kernel
<vd>
I don't expect the boneblack dts to change though
<zmatt>
best not to guess or assume
<zmatt>
dt does change
<vd>
ok
<zmatt>
are you using 16-bit or 24-bit color depth?
<vd>
zmatt I don't know yet, didn't tackled the LCD yet
<vd>
so e.g. for i2c2, would you define your own pinmux to reflect the datasheet as close as possible or would you first lookup into the existing dts and skip this pinmux block if it's already correctly defined?
<zmatt>
should be easy enough to tell from the schematic, are any of P8.11-17 + P8.19 connected to the lcd?
<zmatt>
nothing is "already correctly defined", every device that uses pins should have a pinmux block. however, you're not the one setting up i2c2, this is done by am335x-bone-common.dtsi
<vd>
zmatt P8.13,14 are used (respectively LCD_POWER_EN and LCD_PEN_INT#)
<zmatt>
yeah okay but they're not used for video then, so 16-bit video, not 24-bit
<zmatt>
are you using audio?
<vd>
zmatt ok so you wouldn't (re)defined an i2c2_pinmux block because am335x-bone-common.dtsi already defines it. That answers my question. I guess the process is to grep the pin you're using to see if its related muxing can be used as is
<zmatt>
no
<zmatt>
that is not the process
<vd>
16-bit does ring a bell indeed. No audio
<zmatt>
when you add a new device to your tree, either by declaring it from scratch or by enabling (status="okay") an on-chip peripheral that was predeclared with status="disabled", that's where you also configure the device by supplying any mandatory configuration, including pinmux declaration if the device uses any of the configurable I/O pins of the SoC
<zmatt>
for i2c2 that is all being done by am335x-boneblack-common.dtsi
<zmatt>
it also sets up the hdmi transmitter, which is undesirable in your case so you'll need to actually undo that (I'm checking the required steps right now)
<zmatt>
an alternative would be to copy am335x-boneblack.dts instead of #including it, removing the #include "am335x-boneblack-common.dtsi" line, and adding the few parts from it that are actually applicable to your situation
<vd>
maybe that'd be better indeed. It feels really weird to me not to reuse the boneblack.dts since the board is literally a bbb with a custom daughter board on the expansion pins (what you guys call "capes")
<vd>
but maybe that's just a limitation of the current device trees :/
<zmatt>
it's not insufficiently modularized in TI's kernel
<zmatt>
*just insufficiently modularized
<vd>
I don't think the dts differ between mainline and TI's kernels, do they?
<vd>
it's hard to choose between both appoach because boneblack brings in some unncessary stuffs, but I would need to delete stuffs anyway even with bone-only dtsi (like the cape_eepromX nodes, unless I simply keep them)
<zmatt>
approach 2 would be something like this: https://pastebin.com/raw/E7KrT5WQ ... I added some comments since some stuff in here is kinda weird
<zmatt>
I omitted &rtc { system-power-controller; }; since that property is already configured in am335x-bone-common.dtsi (as it should be)
<vd>
hum thanks a lot for the comparison, I think approach 1 looks cleaner
<zmatt>
they're both ugly in different ways
<vd>
indeed
<zmatt>
"looks cleaner" is not quite the same as "is cleaner"
<zmatt>
but yeah, it would be nice if am335x-boneblack-common.dtsi didn't force HDMI on you but split that off into a separate .dtsi file
<vd>
but boneblack.dts still seems to declare necessary stuffs (I use both MMCs) so let's include it and delete what I don't use
<vd>
definitely. The boneblack upstream support is ironically not daughter board friendly
<zmatt>
my second example includes that
<zmatt>
both examples should be equivalent
<zmatt>
(I omitted the OPP hack in am335x-boneblack.dts since it was only needed for really early BBB prototypes)
<rcn-ee_>
zmatt, and all OSD3358's that didn't get the efuse written..
<vd>
I don't use the i2c2 eeprom for cape detection anyway, so it's cleaner to delete the cape_eeprom* nodes, add my own, and do the same for uncessary stuffs like hdmi
<zmatt>
as for setting up lcd, I have this example: https://pastebin.com/xnPyKNfi ... it's written for 4.x kernels, untested on 5.4 .. you may need to uncomment the port-declarations and perhaps change other things. also, I didn't define &lcd_pins and you'll need to modify many settings to suit your particular situation
<zmatt>
rcn-ee_: oh yeah, lol
<vd>
zmatt with approach one you would add your own compatible string as well in addition to ti,am335x-bone-black and others, correct?
<zmatt>
vd: setting a custom /model and /compatible is optional regardless, but may be nice
<vd>
approach one with custom compatible string added it is then
<zmatt>
I wish I could tell pastebin that the tab width for my pastes should be 8 spaces
<zmatt>
of course if you view the raw version everything looks fine, since the web browser understands that the One True Tab Width is 8
<vd>
I use 3 spaces for a tab
<zmatt>
heretic
* vd
is kidding
<vd>
vd found zmatt's weak spot
<zmatt>
lol
<zmatt>
afk, bbl
<vd>
Beagle Bone... Lavender?
mattb0ne has joined #beagle
<mattb0ne>
bash question
<mattb0ne>
does ls and cat both output to stdout
<mattb0ne>
i am trying to use ls to pipe frames to ffmpeg but it doesnt work
<mattb0ne>
for some reason cat does
<mattb0ne>
not sure why
GenTooMan has quit [Ping timeout: 250 seconds]
GenTooMan has joined #beagle
<vd>
zmatt how do I figure out the mux mode number for a given column in your spreadsheet?
<vd>
zmatt e.g. that is the mux mode for uart 4 rxd for P9.11?
<zmatt>
mattb0ne: "use ls to pipe frames to ffmpeg" doesn't make sense
<zmatt>
vd: the columns are labeled with the mux number
<zmatt>
F0..F6 (f for "function" i.e. mux mode)
<zmatt>
vd: and bbl = be back later
<vd>
beaglebone later would be preferred in the channel
<zmatt>
mattb0ne: ls writes names to stdout, cat writes _contents_ of files to stdout
<zmatt>
those are rather different things
<vd>
zmatt damn I was using custom filter which has set the column to X, Y, Z, ... thanks!
<zmatt>
vd: if you're using a filter view, don't apply it to the header rows :P
<zmatt>
(or use one of the filter views I already have)
<vd>
indeed
<vd>
for uart4, I just need to add a &uart4 { } block with its pinctrl? shouldn't it be inside the / { } block?
<vd>
ok I though the &node { } syntax was to edit *existing* nodes, not adding new ones
<zmatt>
correct
<vd>
but I don't see the uart4 node define anywhere?
<zmatt>
on-chip peripherals of the SoC are predefined in am33xx.dtsi
<zmatt>
(with status="disabled";)
<vd>
ha true, I wasn't greping in am33xx.dtsi...
<vd>
makes sense thanks!
<zmatt>
or am33xx-l4.dtsi actually in 5.x kernels it seems
<vd>
I have an output pin labeled WAKE_UP_A connected to uart4, not sure what's that for...
<zmatt>
uart4 what pin?
<vd>
hum, it goes to a jumper as well as other uart4 pins, I don't know why
<zmatt>
how did you end up in the situation of having to write a dts for hardware you're not actually familiar with? like, normally this is something that would be done while bringing up the first prototypes of a board
<zmatt>
and your description is not useful. "yeah I have this WAKE_UP_A net connected to some uart4 pin (not gonna tell you which) and also some other pins, what do you think that's all about?"
<vd>
I'm coming late to a project with an existing hardware which was using old kernel/build system for a long time. I'm the new embedded software guy
<zmatt>
and let me guess, the people who designed this are long gone?
<vd>
zmatt nevermind, I though "WAKE_UP_A" was a uart term somehow, but it seems to be totally custom.
<vd>
zmatt good guess
<zmatt>
it sounds uart-unrelated.. are you sure that pin is used in uart mode?
<zmatt>
unless its maybe uart rts/cts being used for something like bluetooth wakeup
<vd>
ha that could make sense!
* vd
asks around
rcn-ee_ has quit [Remote host closed the connection]
<zmatt>
in the end, the schematic has all answers
<vd>
switching from working full time in open source to a proprietary product company is ... quite an adventure
<zmatt>
I mean, it's kinda like reverse-engineering some proprietary shit to be able to run open source software on it ;)
<zmatt>
not the end result, but the process
<zmatt>
though at least you have schematics to work with
<vd>
yep
<vd>
zmatt so yeah, seems like a custom reset pin
<zmatt>
i.e. gpio, nothing to do with uart4
<vd>
indeed. A gpio that their software toggle to reset some device connected on the said uart
<zmatt>
I mean, based on the name I'd assume it wakes up a device rather than resetting one
<vd>
true
charlie5 has quit [Ping timeout: 248 seconds]
starblue3 has quit [Ping timeout: 250 seconds]
charlie5 has joined #beagle
GenTooMan has quit [Ping timeout: 240 seconds]
GenTooMan has joined #beagle
<vd>
LCD_PWM is connected to P9.14 and LCD_POWER_EN is connected to P8.13. Should I use some pwm driver are are they simple output GPIOs?
<vd>
s/are are/or are/
<zmatt>
LCD_POWER_EN sounds like the enable-gpio for your panel (see my lcd panel example I linked earlier)
<zmatt>
LCD_PWM sounds like it's a pwm output that should be declared as backlight device
<zmatt>
try grepping for "backlight" in am335x*.dts ... there's probably an example somewhere
<vd>
hooooo that makes a lot of sense, old software used to poke a GPIO 23...
<zmatt>
well it's always possible they're doing that for good reason, see your lcd panel's datasheet regarding details on how those signals are to be used exactly
<zmatt>
but it's equally possible they were doing that because they didn't know what they were doing
* vd
chooses option 2
<zmatt>
generally I'd recommend reading datasheets (and errata, if available) to see if there are weird constraints that need to be observed or whatever
<zmatt>
you're gonig to need to consult that datasheet for correct panel timings anyway
<vd>
even though it's named "pwm", it seems to be a single line. Should I be using the gpio-backlight driver and declare P9.14 as GPIO instead?
<zmatt>
??
<zmatt>
I don't understand your question... pwm *is* a single line
<vd>
ha (never played with pwm)
<vd>
I just noticed F6 is pwm 1 out A, but there are also gpio-backlight drivers for on/off backlifts
<vd>
backlights*
<zmatt>
I mean, a gpio is sort of a pwm output, just with reaaaaaaly poor resolution ;-)
<zmatt>
but given that your line is called PWM, it's connected to a pin with pwm functionality available, and being able to dim a backlight is generally regarded as desirable, you should probably declare it as a pwm-backlight :P
<vd>
will do!
rcn-ee has joined #beagle
<vd>
looks like I should name it "ehrpwm1a" what this stands for :)
<zmatt>
"it" ? what's "it" in this context?
<vd>
the pinmux for P9.14
<zmatt>
naming of pinmux nodes is mostly a matter of aesthetics (as long as they're unique within their parent) but I normally name them after the device they belong to
<zmatt>
in this case that's &ehrpwm1 so I'd just call it "ehrpwm1" and give it the label &ehrpwm1_pins
<zmatt>
(regardless of whether you need both pins of it or only the A output)
<vd>
ok
<vd>
pwm are simple device providing 2 power output lines?
<zmatt>
no
<zmatt>
gpios are not "power output lines", you cannot draw any significant amount of current from them (max recommended is about 4 mA)
charlie5 has quit [Read error: Connection reset by peer]
<zmatt>
used to indicate some sort of analog value, in this case the backlight intensity
<vd>
I asked "pwm are simple device ...", did you read "gpio are simple device ..."?
<zmatt>
I should have said "I/O pins" rather than "gpios"
<zmatt>
but no I did not misread what you said
<vd>
ok
<zmatt>
I just misspoke, but the rest of what I said still applies
<zmatt>
the electrical characteristics of an io (e.g. max current draw) does not depend on mux mode
<zmatt>
so selecting a different mode cannot magically turn an io into a "power output"
florian has quit [Quit: Ex-Chat]
<vd>
The LCD backlight brightness levels depends on the pwm or the panel?
<zmatt>
panel
<zmatt>
panel will also specify appropriate pwm frequency to use
<zmatt>
btw, one thing to be mindful of with ehrpwm devices: while the A and B outputs of one ehrpwm peripheral can be used independently, they must use the same pwm frequency. trying to enable both outputs at different frequencies will fail
<vd>
pwrbutton has a node, does the CPU reset (WARMRSTn) has one too?
<zmatt>
how do you imagine that would work, given that when the reset line is asserted, linux is instantly no longer running
<vd>
so it has no node
<zmatt>
the pwrbutton has a node because it's an input event device
<zmatt>
pressing it triggers an event that may be handled by systemd to trigger a shutdown (depending on configuration)
<zmatt>
or may be handled by something else I guess
<vd>
pwrbutton uses the gpio-keys driver? I see only status = "okay" in am335x-bone-common.dtsi
<zmatt>
pwrbutton is not a gpio, it's not even a processor pin... it's a pin of the pmic (&tps)
<vd>
ok
<zmatt>
it has no info besides the completely redundant status="okay"; (which is the default for any device) since the driver doesn't need any additional info, the pmic driver has a list of fixed sub-devices and knows what their corresponding driver is
<vd>
would you have one instance of gpio-keys for 3 distinct buttons or one instance each?
<zmatt>
there's generally no reason to have multiple gpio-keys devices
<zmatt>
each gpio-keys device becomes a separate input device, while each of the keys you define become separate events that input device can generate
<vd>
yep
<vd>
wondering what is better between having /dev/input/event0 for 3 buttons or /dev/input/event{0,1,2}
<zmatt>
generally the former... imagine if your keyboard added a separate device for each key
<vd>
but that's ok for a keyboard since it is the same physical device
<zmatt>
so is this presumably
<vd>
here these are multiple buttons on a daughter board
<zmatt>
it's all part of your device
<vd>
true
<zmatt>
a keyboard is also a collection of separate buttons on a board
<zmatt>
basically, the only reason I can think of for using separate devices is if you're doing so to be able to assign different permissions
<zmatt>
but the desire to do so seems very unlikely... generally input events can safely be considered "public"
<zmatt>
for random buttons certainly.. maybe not for an actual keyboard or keypad where a password or pin may be entered
<vd>
how would you name the gpio-keys node then, "buttons"? :)
<zmatt>
for example
<vd>
P9.16 (pwm 1 out B) seems to be used for usb power, while A was used for LCD. The two pins must be declared within the same ehrpwm1 node, right?
<zmatt>
sounds like P9.16 is used as gpio, not as pwm
<zmatt>
there is no conceivable way "usb power" could possibly be a pwm signal
<vd>
ha?
<zmatt>
why would you think it's a pwm signal? what is connected to it?
<vd>
its name on the datasheet is HUB_DP0_PU
<vd>
might stand for powerup
<zmatt>
no it stands for pullup on D+0
<zmatt>
i.e. it requests that the hub signals attachment to the host
<zmatt>
most likely
<zmatt>
sending a pwm signal to that would be like plugging and unplugging your usb hub thousands of times per second
<vd>
ok so a PIN_OUTPUT_PULLUP gpio it is then
<zmatt>
why pullup ?
<zmatt>
does it have external pullup?
<vd>
I'm not sure what to look at to give an answer
<zmatt>
that's not a great position to be in when having to write a dts for a piece of hardware
<zmatt>
have you considered pairing up with an electronics guy who knows how to read schematics?
<vd>
my knowledge is limited in electronics indeed. I plan to walk through all PIN_* macros with an electronics guy once I've written the base dts
* vd
dreams about AM335X_PIN_8_18 and similar macros
<vd>
nah the BONE_ prefix makes them totally unusable
<zmatt>
why?
<zmatt>
why does the name matter?
<zmatt>
they're just macro names
<zmatt>
it's not P8_18 of the AM335X, it's P8_18 of the beaglebone
<vd>
because no one would guess that BONE_P8_09 is P8.09, thus AM335X_PIN_GPMC_BEN0_CLE is waaaaaaaay more intuitve
<vd>
I was kidding btw
LetoThe2nd has quit [Quit: Connection closed for inactivity]
<zmatt>
apparently, though that wasn't really clear, it mostly just sounded like you were confused
<vd>
nah these bone macros are actually really nice
<vd>
that said, I could define a few macros like #define BBB_P8_09 AM335X_PIN_GPMC_BEN0_CLE for all pins I'm using...
<vd>
I'm wondering why upstream named the pins with their primary functions, sounds like a very stupid idea. It wouldn't hurt to define macros for each modes as well.
<zmatt>
I think TI is to blame, not "upstream"
<vd>
yet upstream applied the patches
<zmatt>
I *guess* it was an improvement over using magic hex values? possibly? maybe?
<vd>
there's an input line for USBMODEM_OC# (over current?) connected to pwm 1 tripzone. Should I use it in gpio mode as well instead of pwm? (i'm confused because it seems power related, but it might be a cohincidence)
<zmatt>
you still seem to have in your mind "pwm" is "power related", it isn't
* vd
slaps himself
<zmatt>
and unless it makes sense in your mind to trip the lcd panel backlight off as a way to indicate usb modem overcurrent (ignoring for a moment that the kernel driver doesn't support the tripzone inputs), I think you'll want to configure that pin as gpio ;)
<vd>
so these pins, as well as 7 USBx_5V_EN# pins and a USBMODEM_5V_EN# seems to need these gpio output for power only. Documentation/devicetree/bindings/gpio/gpio.txt seems to describe what you were referring to as "hog" gpio. Should I be using that?
<zmatt>
gpio hog just means the pin will be forced into a fixed configuration
<zmatt>
(I don't know if it still allows for userspace control by manual exporting, I use gpio-of-helper instead)
Partmedia has quit [Ping timeout: 252 seconds]
mattb0ne has quit [Remote host closed the connection]
mattb0ne has joined #beagle
Partmedia has joined #beagle
buzzmarshall has joined #beagle
mattb0ne has quit [Ping timeout: 244 seconds]
lucascastro has joined #beagle
starblue has joined #beagle
outrageous has joined #beagle
argonautx has quit [Quit: Leaving]
<vd>
one node block for each gpio-hog looks very verbose
<vd>
:w
<zmatt>
how many thousands of gpios do you have to configure? ;P
<vd>
there's 10 lines for the usb hubs
<vd>
If I have just the AM33XX_PADCONF configuration for the gpio lines, they will still be correctly configured, right? It only means that userspace may change their direction and values if they are not hog
<zmatt>
gpio-hogs aren't particular verbose... like, 5 lines per gpio, including the closing brace
<zmatt>
the gpio controllers on the left do not know or care about what's configured on the right side of this drawing nor vice versa
<vd>
hum I see. I'll do the gpio-hog thing anyway. To which node do I attach the pinctrl-0 property for these usb 5V output lines? A new "dummy" node for the usb devices, or the &gpioX nodes?
<zmatt>
dunno if there's a "right" solution for this, but attaching it to the &gpioX nodes would work
<zmatt>
setting up gpios in DT is really awkward in mainline, it's why gpio-of-helper was created but I think it wasn't accepted upstream
<zmatt>
(beagleboard.org kernels also have some misc enhancements to sysfs gpio that I contributed)
<vd>
I don't think so neither
<vd>
&gpioX it is
<vd>
Does AIN{0,1,2,3} need a pinmux configuration?
<zmatt>
in general I question whether linux kernel devs understand the needs of embedded users, they're really weird about things sometimes
<vd>
zmatt did you reach Linux Walleij about this?
<zmatt>
I probably should try, but I haven't summoned the time/energy/motivation
<vd>
I only talked to him once IRL but he's a really nice guy. It might totally understand since he started the pinctrl work back then because gpiolib wasn't sufficient to handle more complex designs
<zmatt>
well he also designed the gpio chardev, which is an obnoxious "replacement" for sysfs gpio
<zmatt>
and apparently suggested a debugfs mechanism as a mainline-acceptable alternative to pinmux-helper, which is also terrible
<zmatt>
so dunno
Guest89 has joined #beagle
lucascastro has quit [Ping timeout: 250 seconds]
GenTooMan has quit [Ping timeout: 252 seconds]
Guest89 has quit [Ping timeout: 256 seconds]
Shadyman has joined #beagle
zjason has quit [Read error: Connection reset by peer]