<vd>
none, just trying to understand the purpose of this driver, which is generic, but TI specific at the same time
<rcn-ee>
generic, since lcd's are the same..
<rcn-ee>
but specific to the TI controller in the soc..
<vd>
I guess the best thing I could do is to compare rs800480t-7x0gp with my rs800480t-7x0wq-a to check if the timing are the same (and thus I could simply use compatible = "okaya,rs800480t-7x0gp")
<rcn-ee>
you didn't try that yet? ;)
<vd>
maybe that's where my confusion comes from. I thought lcdc was the (TI) controller, and the panel was, well, a panel. i.e. an Okaya or whatever brand
<rcn-ee>
when i looked at the datasheet, almost everything was there for the panel driver, the rest you just got too play with ..
<zmatt>
vd: no, providing hardware parameters to the kernel is _exactly_ what DT is for. your argument would work equally well against DT entirely: just hardcode all board info into the kernel (which is what was done before DT)
<zmatt>
the problem is the same: there's too many, there's too much variation, having to modify the kernel for every new instance sucks
<rcn-ee>
every "panel" model is different, you need to share all those numbers to the ti LCD controller..
<zmatt>
and it's even quite possible that you may want to tweak timings in your specific product, e.g. to avoid interference
<vd>
zmatt true. Device tree isn't perfect, there's still this gray area where you shouldn't have user configuration in device tree, but defining stuffs like the default LED trigger is convenient. What remains true is that you should repeat yourself. So having a precise compatible string for the exact hardware, or a generic compatible with additional
<vd>
settings in device tree both sound good.
<rcn-ee>
"wire" length... ;)
<rcn-ee>
FCC radiation..
calculus has quit [Ping timeout: 256 seconds]
calculus has joined #beagle
<vd>
you shouldn't* repeat yourself
<zmatt>
anyway, zZ
lucas_ has quit [Quit: Leaving]
<vd>
rcn-ee but the ti LCD controller is the lcdc node, isn't it?
<vd>
I mean the lcdc node, i.e. the controller, is an instance of ti,am33xx-tilcdc
<rcn-ee>
compatible = "ti,am33xx-tilcdc";
<vd>
the ti,tilcdc,panel compatible is a ... generic panel driver ... for TI ... :-/
<rcn-ee>
"panel" is the driver, "ti,tilcdc,panel"; is one of the compabiable options..
<vd>
rcn-ee we used to have an old device tree for it so I'm testing its panel-info/timings first: http://ix.io/3xNf (panel_pins contains only the LCD_POWER_EN gpio and the LCD pinmux is attached to &lcdc at the moment)
<rcn-ee>
cool, looks good..
<vd>
but there's no explicit link between &panel and &lcdc though. Is that normal?
<rcn-ee>
there a link, haven't got it to work.. it actualy breaks it for me..
<vd>
yeah the commented port thing
<vd>
anyway that something handled within the SoC so no need to link anything I guess
<vd>
if these settings work, the only last thing to do is the touchscreen connected on &spi1!
<rcn-ee>
cool
<vd>
you gave me a link as an example to configure this right?
<rcn-ee>
not for spi, just i2c..
<rcn-ee>
problaly similar..
<vd>
rcn-ee have you been running a web browser on a bbb with a touchscreen?
<rcn-ee>
it takes a lot of cpu power todo a web browser..
<vd>
I have like a PoC to do to show case that's it's feasible
<rcn-ee>
chrome is too big... firefox was the last one that worked, try any minimnal browser..
<vd>
maybe a lighter web browser directly hitting the framebuffer would be lighter?
<vd>
rcn-ee what does it take to have a daughter board recognized as a bb.org cape? Only a specific ID (and a corresponding overlay in the bb.org kernel) in the i2c2 EEPROM?
<rcn-ee>
yeap just a readable eeprom on the i2c bus..
<vd>
and in terms of device tree? I'd love to have mine upstream in mainline kernel, but id
<vd>
it'd be nice to have it work with your dt overlays
<vd>
(I personally don't use dt overlay and u-boot, I'm using barebox)
<rcn-ee>
there really isn't any requirements... find a value not used, and take it..
<vd>
but the device tree must be a separate file, right? Mine currently #include "am335x-boneblack.dts"
<rcn-ee>
lots do..
<vd>
ho ok so the overlay may have duplicated nodes? It doesn't have to separate them in another file
<rcn-ee>
what ever you submit will probally be tweaked to make it more generic.
<vd>
hooo no I think I understand. The bootloader (currently only u-boot) reads the eeprom and load the dts corresponding to the ID found there. There's no overlay applied to the boneblack dts, is it?
<rcn-ee>
the boneblack has a main *.dtb that get's loaded based on another eeprom value.
<vd>
damn sometimes yocto takes years to recompile...
mattb0ne has quit [Ping timeout: 240 seconds]
mattb0ne has joined #beagle
mattb0ne has quit [Remote host closed the connection]
mattb0ne has joined #beagle
buzzmarshall has quit [Quit: Konversation terminated!]
mattb0ne has quit [Ping timeout: 244 seconds]
GenTooMan has quit [Read error: Connection reset by peer]
GenTooMan has joined #beagle
calculus has quit [Ping timeout: 240 seconds]
calculus has joined #beagle
vd97 has joined #beagle
calculus has quit [Ping timeout: 252 seconds]
vd has quit [Ping timeout: 256 seconds]
calculus has joined #beagle
sicelo has quit [Quit: Bye!]
sicelo has joined #beagle
sicelo has joined #beagle
sicelo has quit [Changing host]
florian has joined #beagle
RossSchulman[m] has quit [Ping timeout: 250 seconds]
RossSchulman[m] has joined #beagle
jduchniewicz has quit [Ping timeout: 250 seconds]
jduchniewicz has joined #beagle
mapache has joined #beagle
<mapache>
Hi, I’m looking for help to run UART on BeagleBone AI Rev C. I saw many similar questions but without any working answer. Can someone help me step by step? I’ve tried many things like modifying .dts files, enabling UART in uEnv.txt, but nothing works. The UART doesn’t appear on ttyO*or sometimes the BB doesn't boot if I modify the uEnv.txt.
<mapache>
Also, config-pin doesn't work, because /sys/devices/platform/ocp is empty.
mturquette has quit []
mturquette has joined #beagle
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
notserpe has quit []
notserpe has joined #beagle
pbrobinson has quit []
pbrobinson has joined #beagle
mapache has quit [Quit: Client closed]
mapache has joined #beagle
Shadyman has quit [Remote host closed the connection]
mapache has quit [Quit: Client closed]
lucascastro has joined #beagle
ikarso has joined #beagle
<zmatt>
vd97: dividing DT source code up into files is purely for convenience, it means nothing to the DT compiler... #include is literally equivalent to copying the contents of that file and pasting it at the site of the #include
<zmatt>
vd97: and I'm not sure what you mean by "duplicated nodes" ... you can't do such a thing since each node declaration means "create (if non-existing) or modify (if existing)"
<vd>
hi all -- LCD almost there, but I have these messages in dmesg:
<vd>
pwm-backlight backlight: backlight supply power not found, using dummy regulator
<vd>
OF: graph: no port node found in /ocp/interconnect@48000000/segment@300000/target-module@e000/lcdc@0
<vd>
tilcdc 4830e000.lcdc: no encoders/connectors found
<vd>
(thanks zmatt for the DT notes)
<zmatt>
I mentioned the "no port" thing in my example for lcdc
<zmatt>
I also had that warning, but it worked fine despite the warning and _didn't_ work when I added the missing port declaration
<zmatt>
but maybe that's been fixed, I left those declarations in the example but commented-out
<zmatt>
the backlight thing doesn't sound like a problem
<vd>
so I must uncomment the remote_endpoint nodes on the panel and lcdc? I didn't quite understand the problem there
<zmatt>
yeah the port { .. }; blocks
<vd>
ho it was commented out because you must add them, but it didn't work on your machine, is that right?
mattb0ne has quit [Ping timeout: 245 seconds]
lucascastro has quit [Ping timeout: 252 seconds]
<zmatt>
yeah it complained about them being missing but worked fine despite the warning, and if I added them the complaint disappeared but it didn't work anymore
<zmatt>
but this was a while ago and you're using a much newer kernel, so that may very well have been fixed
<zmatt>
the reason it works without it is because the panel uses an lcdc-specific panel driver, therefore the kernel can infer that it's obviously connected to lcdc
<zmatt>
but such an implicit connection is of course kinda gross compared to an explicit declaration that these devices are connected on your board
<vd>
and we can imagine a board with multiple controler/panel pairs I suppose
<zmatt>
yep, plenty of SoCs support that
<vd>
would the kernel explicitly complain if a pin is already muxed by another node?
florian has quit [Quit: Ex-Chat]
<zmatt>
yes, the pinmux node will fail to activate and the driver to which the pinmux node is attached will fail to probe as a result
<vd>
perfect (I was wondering it is was possible to forget to delete boneblack not and thus get silent errors)
lucascastro has joined #beagle
<vd>
hum, I have this error but I don't think there's a gpio for the backlight: of_get_named_gpiod_flags: can't parse 'enable-gpios' property of node '/backlight[0]'
<vd>
I mean, there's GPMC_A2 for the LCD_PWM and GPMC_AD9 for the LCD_POWER_EN (panel)
<zmatt>
the dt binding for pwm-backlight says enable-gpios is optional
<vd>
that might not be an error but just a note them
<vd>
the LCD still doesn't work
<zmatt>
check with my show-pins utility whether all pins seem to be muxed correctly
<zmatt>
check sysfs to confirm whether all relevant devices exist
<vd>
zmatt btw the pwm-backlight bindings doc does say that power-supply is required
<zmatt>
stupid
<vd>
I'm not that stupid
* vd
winks
<zmatt>
ah, yep, indeed I used power-supply = <&dummy_supply>; which, as the name suggests, is a dummy supply I declared for use by any devices that obnoxiously require a supply declaration
<zmatt>
no not you, stupid that it forces you to declare a power-supply
* vd
was kidding
<vd>
arch/arm/boot/dts/am335x-sl50.dts has power-supply = <&vdd_sys_reg> for its backlights
<zmatt>
of course if you can identify what's actually supplying your lcd's backlight, and if that supply is represented by a device tree node, then use that
<zmatt>
but informing the kernel about the power supply topology really only matters in cases where the kernel actually has control over these supplies
<vd>
zmatt that LCD_PWM line goes into a NC7SZ125M5X
<zmatt>
supply != pwm line
<zmatt>
LCD_PWM carries information (the desired backlight intensity), not power
<vd>
isn't the nc7s thing a supply?
<vd>
it has a pin connecting to 3V3_LCD
<zmatt>
it's a buffer
<zmatt>
probably used as isolator or level translator
<vd>
ha
<zmatt>
many ICs do not tolerate their I/Os being exposed to voltages significantly above the relevant supply voltage
<zmatt>
the fact that there's a 3V3_LCD probably means the LCD panel has its own 3.3V supply separate from that of the beaglebone
<vd>
zmatt that's possible (the daughter board is actually the one powering the bbb, not the other way around)
<zmatt>
so if the beaglebone were to send a pwm signal while the 3V3_LCD is unpowered it could damage the LCD, so to ensure that can't happen you can add a buffer between them (which just repeats its input to its output), powered by the supply voltage of the destination (3V3_LCD).. provided of course you use a buffer that does tolerate overvoltage on its input, but many do (this one tolerates up to 5.5V on ...
<zmatt>
...its input regardless of its supply voltage)
<vd>
ha interesting!
<zmatt>
it's probably a good idea to have a good overview of what supplies exist on your board and what they supply
<zmatt>
especially ones that can be software-controlled (e.g. via an enable-gpio)
<vd>
what happens if you set "straight" instead of "crossed" on the red/blue wiring property?
<zmatt>
it determines which pixelformats are supported for the framebuffer, which I list in the comments
* vd
recompiles
<vd>
zmatt btw I was thinking about porting the unsafe pmic/rtc power cycle fix in the barebox bootloader. They were wondering if you *have to* go through the RTC, or if there's a gpio line or something we could use directly instead
<zmatt>
which is relevant since RGB565 and RGB888/XRGB8888 are widely supported, while BGR565 and BGR888/XBGR8888 are not
<zmatt>
so that means you can generally only use 16-bit color when the lcd is wired "straight" and 24-bit color when it's wired "crossed"
<zmatt>
so you'll typically want to use straight wiring if you're only using lcd_data0-15 and want to use a 16-bit framebuffer (since a 24-bit framebuffer would be pointless and use more ram and more ram bandwidth)
<vd>
that's a very good argument for "straight", using it then thanks.
<zmatt>
or crossed wiring if you want to use a 24-bit framebuffer, either because you've hooked up some or all of lcd_data16-23 or because you want to use software that obnoxiously only supports 24-bit framebuffers (like older versions of qt5's eglfs_kms backend) and you can't be bothered to fix it (it turned out to be easy to fix)
<zmatt>
note: I'm talking about the actual wiring, the way the lcd is connected to lcdc
<vd>
erf still no screen :(
<zmatt>
if the DT declaration of the wiring doesn't match the reality of your schematic then all of the supported pixel formats will have the red and blue color channels swapped
<zmatt>
compare the "Direct 16-bit" and "Direct 24-bit" columns in the LCDC tab of my pins spreadsheet: https://goo.gl/Jkcg0w#gid=1280625524
<zmatt>
did you follow my earlier suggestions? check using my show-pins utility ( https://github.com/mvduin/bbb-pin-utils/#show-pins ) that all relevant pins are muxed correctly (and you should also be able to see the state of relevant gpios), check in sysfs whether all devices that you're expected to exist actually exist
<zmatt>
*you're expecting
mattb0ne has joined #beagle
<zmatt>
does /dev/fb0 exist?
<vd>
no
* vd
downloads show-pins
<mattb0ne>
zmatt: if I want the PRU to toggle a GPIO pin how do I do that
<zmatt>
so, missing /dev/fb0 won't be a pinmux issue
<zmatt>
it means lcdc either failed to probed or it hasn't setup the video output, e.g. because it hasn't detected what's attached to it (for example when HDMI is used /dev/fb0 won't show up until a hdmi monitor is plugged in)
<zmatt>
missing /dev/fb0 is also the problem I had when I added the port declarations
vagrantc has joined #beagle
<zmatt>
make sure your lcd-panel device has shown up, since it was declared in the root of the DT it should show up as /sys/devices/platform/lcd-panel
ikarso has quit [Quit: Connection closed for inactivity]
<zmatt>
and also have a symlink at /sys/bus/platform/devices/lcd-panel
<vd>
zmatt can I use power-supply = <&dummy_supply>; as well for the panel or do I have to create a new dummy node?
<zmatt>
vd: I gave a pastebin with a suitable declaration didn't I?
<vd>
I'm asking if I can use the dummy node for the backlight *and* the panel (panel-simple requires a power-supply property as well)
<zmatt>
ah is that what you meant
<zmatt>
you can use &dummy_supply for all your dummy supply needs
<vd>
great, I'm adding it just in case and add utf8.pm for show-pins
<zmatt>
why would you need separate supplies? it's not like every device has its own supply, most of the time many devices share one supply
<zmatt>
"add utf8.pm for show-pins" ?
<zmatt>
what do you mean?
<vd>
yeah I wget show-pins but it fails because the perl UTF8 module is missing
<zmatt>
can you pastebin the exact error? since utf8.pm is part of perl itself
<zmatt>
it being missing would mean that your perl installation is broken
<zmatt>
it's not a separately installable module
<vd>
it might be a lighter perl alternative or something, I'll installing it explicitly.
<zmatt>
there's no such thing as a "perl alternative"
<vd>
I think the build system splits the perl binary and its module by default.
<zmatt>
so does debian, but utf8.pm is part of perl-base which contains the binary and critical core modules
<zmatt>
note btw that you should probably prioritize checking that your devices exist, since until /dev/fb0 has shown up your pinmux is basically irrelevant
<vd>
zmatt doing both
<vd>
I don't have /dev/fb0 but I do have /sys/devices/platform/panel/
<zmatt>
does lcdc exist? it should have a symlink in /sys/bus/platform/drivers/tilcdc/
<vd>
zmatt I have a /sys/bus/platform/drivers/tilcdc/ directory
<vd>
just bind/unbind/uevent in it though.
<zmatt>
so tilcdc failed to probe
<zmatt>
check kernel log?
<zmatt>
(the directory existing merely means the driver is loaded (as a module or by being built-in) and you can just ignore the bind/unbind/uevent attribues)
nerdboy has quit [Ping timeout: 250 seconds]
<vd>
that might have something to do with starting from #include "am335x-boneblack.dts", maybe there's more node cleanup to do
<zmatt>
I'm pretty sure I caught everything in the cleanup I suggested
<zmatt>
what evidence do you have that this is the case? have you checked the kernel logs yet?
<vd>
looking at it
<vd>
no occurence of tilcdc or even lcd
<vd>
(expect the LCD_BUFFER_OE# line that I hogged)
<zmatt>
well, good luck :P could be DT, could be kernel config, who knows
nerdboy has joined #beagle
nerdboy has quit [Changing host]
nerdboy has joined #beagle
<zmatt>
I got stuff to do, but I wish you good luck with the hunt
<zmatt>
did hdmi output work with the default dt ?
<vd>
i will try the default dt.
<zmatt>
(don't forget that /dev/fb0 won't show up unless a hdmi monitor is actually plugged in, though the lcdc device obviously should show up right away with or without monitor)
vd has quit [Quit: Client closed]
busterswt has joined #beagle
<busterswt>
Does anyone know offhand if the PocketBeagle is being discontinued or just a victim of supply chain issues?
vd has joined #beagle
<zmatt>
digikey has 'em in stock, farnell seems to be waiting on supply but allows back-ordering... I see nothing suggesting discontinuation
<zmatt>
mouser also has plenty of stock
<busterswt>
Thanks - I only mention it because Arrow is at 0 and Newark/Element mentioned discontinuation
<zmatt>
I mean, I've not heard of anything about it being discontinued, it sounds implausible
<zmatt>
jkridner: are there any available issues with the pocketbeagle, or just delays due to shortages?
<zmatt>
*availability issues
<rcn-ee>
zmatt, i heard Seeed was getting a shipment of Ocatvo SIP's..
<mattb0ne>
sooo PRU to GPIO communication
<zmatt>
mattb0ne: oh yeah.. yes PRU can control normal gpios too, albeit with higher (and potentially variable) latency compared to using pruin/pruout signals
marina48 has joined #beagle
<mattb0ne>
so rather than nano second its more like milliseconds
<mattb0ne>
I can live with that
<mattb0ne>
you have a snipit ?
<zmatt>
lol no, a fraction of a microsecond
busterswt has quit [Quit: Ping timeout (120 seconds)]
<ABD>
I couldn't not able to install pyserial or serial library in my BBB revC board
<ABD>
will anybody please help me?
<ABD>
I connected it to wifi too
<ABD>
but, I am not able to do update or upgrade too
<mattb0ne>
well if you cannot update and upgrade you may have bigger problems
<mattb0ne>
can you ping google.com
Patel has joined #beagle
<Patel>
I am not able to install pyserial library on my BBB revC
<Patel>
It is already connect to the WiFi while I go to install the package using puTTY I get an error saying 'Unable to detect package'
<mattb0ne>
well ABD aka Patel can you connect to the internet
<Patel>
I have connected it to wifi
<ABD>
yes
<ABD>
we are able to ping google
<mattb0ne>
and sudo apt update does nothing
ABD has quit [Quit: Client closed]
lucascastro has quit [Ping timeout: 244 seconds]
lucascastro has joined #beagle
lucascastro has quit [Client Quit]
Patel has quit [Quit: Client closed]
zjason` has joined #beagle
zjason has quit [Ping timeout: 252 seconds]
<zmatt>
mattb0ne: here's a sys_gpio.h header that properly declares the gpio controllers and also provides convenience wrappers for readability: https://pastebin.com/anqLbyav
<zmatt>
mattb0ne: untested apart from checking it compiles
<zmatt>
(you can ignore the warning at the top if you stick to the wrapper functions)
<mattb0ne>
ok I will be the test dummy
<zmatt>
lol, clpru generates really dumb code for the gpio_set_one* functions when the 'gpio' argument is not a compile-time constant
<zmatt>
wtf, it inexplicably applies 8-to-32-bit sign extension to the shift amount of left-shifts ... but not for right-shifts
<zmatt>
clpru... are you drunk?
<set_>
Yes, well no. But. still. It would be nice.
<set_>
I do not drink.
<set_>
@zmatt: Have you ever cross-compiled the OpenCV libs. and did anything w/ them?
<set_>
On the BBAI?
<set_>
I have done it but it seems that their idea of vfpN is only 3. Luckily, they use make (gnu make). So, I tried to use NEON and vfp4.
<set_>
I am askin' b/c the tensorflow lies span decades...they do not cross compile or compile at all.
<set_>
I tried some armnn libs. and they too are lies. Notta so far.
<set_>
Yea. I will go there. That is a good idea. Thank you for almost knowing something of my concerns for now.
<GenTooMan>
sounds like the compiler possibly ran out of memory you are building on a humble BBB
<set_>
No. I built on WSL2 so far. I think that is it but when I research the ideas, the Interwebs (like you say) is out to get me.
<set_>
Dang.
<set_>
Debian w/ 500GB! Here I come!
<set_>
I may need more.
<set_>
Let me borrow 250GB?
<set_>
Just kiddin'. Okay, that is all for now. Thank you for your time, kind sir.
<set_>
You did it. You proved me correct finally. I am right but WSL2 used to have commands to 'upgrade' their memories. Now, it is an elongated 'issue.'
<set_>
Thank you.
<GenTooMan>
set_, I would suggest you find a way to build on a USB HD attached to the BBB possibly?
<set_>
I know you said that before. I am not too familiar w/ /dev/ttyUSB0 on the BBB or however that works.
<set_>
I guess I can look it up.
<set_>
I would like to port one lib. before I start w/ older projects again. I am in the gear shifting mood and nothing works b/c of my lacking disk space, ram, and my knees are killin' me.
<set_>
myknees!
<set_>
I should go to Debian again. Soon. I will be on Ubuntu and dancing the dance.
<set_>
This is why places exist. Web, storefront, whatever. People need to vent, be heard, and then seek attention to prevail. GenTooMan: No matter how jumbled my words got during our talk today, or any other time for that matter, you helped.
<set_>
That is all I needed. I was in disbelief that I could be right.
<set_>
gcc-arm-gnueabihf- to the rescue!
<set_>
linux goes in there somewhere.
<set_>
Jokes? "Speaking of my knees, I bought a BBB sleeve made of iron!"
<set_>
Did you guys see that fellow on Tindie?
<set_>
i had to add it to my collection.
<set_>
Hopefully, it does not turn the entire sink into an electrical surprise.
<set_>
bzzt, bzzt.
<set_>
Anyway...off to try w/ Ubuntu while in alone time. Wish me luck?