brook has joined #beagle
johanhenselmans has joined #beagle
<Guest44> zmatt, with your python iio code, how does one specify which pin is being used?
<Guest44> Hmm, looks like it's the first argument to the class, right?
<k-man> i read somewhere that you can configure GPIOs in the uEnv.txt so you can set an output to a known state as early as possible
<k-man> where can i get more info on how to do that?
starblue has quit [Ping timeout: 256 seconds]
thinkfat has joined #beagle
thinkfat_ has quit [Ping timeout: 268 seconds]
starblue has joined #beagle
akaWolf has quit [Ping timeout: 248 seconds]
Guest44 has quit [Quit: Client closed]
akaWolf has joined #beagle
brook has quit [Remote host closed the connection]
brook has joined #beagle
brook has quit [Ping timeout: 268 seconds]
vagrantc has quit [Quit: leaving]
buzzmarshall has quit [Quit: Konversation terminated!]
zmatt46 has joined #beagle
zmatt46 has quit [Client Quit]
<zmatt> k-man: a more typical way would be using an overlay to have the kernel configure gpios for you
<zmatt> I guess what that article suggests might also work, but it would be highly dependent on u-boot's boot script hence be prone to break if you ever update u-boot
<k-man> ah ok
<k-man> thanks for the pointer
<zmatt> doesn't seem worth it just to get gpios set 1 or 2 seconds earlier or so
<zmatt> my overlay-utils has an example for how to configure gpios: https://github.com/mvduin/overlay-utils/blob/master/gpio-demo.dtsi
<k-man> i have made an LED clock, and when it powers up it blasts the LEDs at full brightness for a few seconds. i just would like to hold the output enable low until i actually am ready to set the display
<zmatt> that sounds like a hardware design issue :P
<k-man> well - i have designed around it. i put in a little circuit to hold !OE high until i put it low
<k-man> bit something isn't quite right and it still lights up at boot time
<k-man> I'll dig into it oneday
<zmatt> all of the beaglebone's I/O are high-impedance with either weak default pull-up or weak default pull-down (varies per pin)
<k-man> thanks for the link to your code. I'll study it later
<zmatt> you can override that default pull with a stronger pull, e.g. 1 kΩ
<k-man> yes that's what I have done
<k-man> probably an issue with my setup/code rather than the hardware design
<zmatt> well if it happens immediately after power-on for a few seconds then it's a hardware issue, not a software one
<k-man> no i think it happens later. i'll have to double check later
<zmatt> if it happens later then that means there's software setting your pin (either userspace, or the kernel at the request of DT)
<zmatt> hence setting a default in u-boot would be pointless since it would get overriden by whatever is setting your gpio
<zmatt> by default u-boot will not touch any expansion header pins other than P9.19/20 (i2c bus for cape autodetection)
<k-man> right, good point
<zmatt> and the eMMC pins of course
<zmatt> the P8/P9 tabs of my pins spreadsheet give an overview of default usage of pins as well as default pull direction: https://goo.gl/Jkcg0w#gid=1775283126
<k-man> nice
<zmatt> hmm, I should add a README to overlay-utils
<k-man> how does your gpio 2.02 (for example) naming format translate to the the gpio numbers?
akaWolf has quit [Ping timeout: 268 seconds]
<zmatt> gpio numbers are dynamically assigned by the kernel whenever it discovers gpio controllers... so technically one ought not rely on them, though in practice it will always discover the four platform gpio controllers (&gpio0 .. &gpio3) in that order and before any external (bus-attached) gpio controllers so in practice it seems fairly safe to assume that global gpio number = 32 * (gpio controller ...
<zmatt> ...number) + (controller-specific gpio number)
<zmatt> i.e. 2.02 -> 2*32+2
akaWolf has joined #beagle
<k-man> ah i see
<zmatt> however I'd generally encourage using udev to create symlinks for gpios in /dev/gpio/ based on their DT-declared name so that programs can find them by name and don't need to know or care about gpio numbers
<k-man> i've been using gpio20 for my !OE. so what would that be?
<k-man> ah, good idea regarding the udev
<k-man> thank you
<zmatt> i.e. P9.41 ... or rather, one of the two cpu pins connected to P9.41
<zmatt> this shows what the udev rule creates on a beaglebone in default config, where the gpios are setup by cape-universal: https://pastebin.com/raw/jvfMYqQQ
<zmatt> this shows the result of the gpio-demo overlay from my overlay-utils (with cape-universal disabled to reduce clutter): https://pastebin.com/YKW7Wcqu
<k-man> very handy tips, thanks
<k-man> one thing I've been trying to work out is how to test (in my c program) if the gpio is already exported or not, and not export it if it is
<k-man> as that seems to unexport it
<zmatt> there's never any reason to export from userspace
<k-man> ok so i should exprot using the overlay and just assume in userspace it's there?
<k-man> or rather test for it but if its not there give an error or whatever
<zmatt> and yes there's a bug (caused by a kernel patch) that causes an attempt to export an already-exported gpio to (permanently) unexport that gpio
<zmatt> gpios meant for userspace should be exported by DT yes... either by cape-universal (which is enabled by default) or by a custom overlay
<zmatt> so generally you'd just open the gpio's value attribute (/dev/gpio/NAME/value if using the udev rule or /sys/class/gpioNUMBER/value otherwise) and complain if it gives an error
<zmatt> and for outputs or bidirectional pins check the 'direction' attribute and write 'in', 'low', or 'high' as appropriate for initial setup... this step would be skipped for outputs that are setup as such using a custom DT overlay (for which the direction attribute isn't writable unless the gpio was explicitly declared as bidirectional)
<k-man> right nice. I developed my LED clock on BBB circa 2014 i think
<k-man> I think a lot has changed since then with the kernel and BBB
<zmatt> yeah I'm assuming a recent image here, quite a bit has happened
<k-man> zmatt: i'm in the process of trying to update it to a new debian version
<k-man> hence all my questions
<k-man> and thank you for your very helpful suggestions and answers
<zmatt> having said that, I'm pretty sure gpio-of-helper worked largely the same in ancient times
<k-man> and as you rightly pointed out, after boot gpio20 is there on the new image
<zmatt> yep, cape-universal exports everything
<k-man> zmatt: i don't recall but i seem to have written something to export the gpio20 at boot time. maybe i just didn't understand or maybe it wasn't exported by default. i don't recall
<zmatt> if your code predates cape-universal and you didn't make a DT overlay for your gpios then you would have needed to do that yes
<k-man> in case you want to have a look
<k-man> probably not the best way
<zmatt> btw, while it's quite possible to use both overlays *and* cape-universal, this requires the overlay to disable cape-universal for any pins it uses (for which overlay-utils has its USES_PIN macro) and using gpios requires a recent enough kernel patchlevel as mentioned at the top of gpio-demo.dtsi
<zmatt> yeah, like I said that's how you'd need to do it when using neither cape-universal nor a DT overlay
<k-man> righto
<k-man> looks like i can use cape universal now
<k-man> i added your udev rules too, so I'll modify my code to use the /dev/gpio paths instead
<zmatt> btw, writing "out" to direction is deprecated, you can't configure a pin as output without specifying what level it's supposed to output, i.e. you should write either "low" or "high" ... writing "out" is a deprecated synonym for "low"
<k-man> oh good tup
<k-man> tip rather
<zmatt> when using DT you similarly have three choices: input; init-low; and init-high;
<zmatt> (a slightly confusing detail is that if the gpio is configured as active-low then "high/low" as written to direction still refer to the physical level while the value attribute is inverted to match the semantics (0 = inactive = high, 1 = active = low))
<k-man> oh
<k-man> heh
<k-man> tricky
<zmatt> of course that only matters if you choose to configure a pin as active-low
Guest2329 has joined #beagle
<zmatt> ...which would generally be done in DT, and in that case you also initialize the output (if it's an output) in DT hence userspace doesn't need to know anything about this
<Guest2329> hi, SSH port 22 not working, it was, but, stopped working when I tried to setup gateway...any help pls on BBB
<zmatt> sounds like you successfully messed up the network settings? :P
<Guest2329> :-)
<k-man> do you have serial port access?
<Guest2329> yes
<zmatt> typically you'd still be able to reach it via the usb serial console, and then just... undo whatever you did
<zmatt> what do you mean by "setup gateway" ? were you trying to share internet access to it via usb?
<Guest2329> i had done    route add default gw 192.168.7.2
<Guest2329> i tried route del
<Guest2329> still not ok
<Guest2329> yes it is USB share internet
<Guest2329> not able to undo
<Guest2329> i want to get back the SSH working and then tell my BBB to use my laptop as gateway for shared internet access via USB, how do I ?
<zmatt> dunno what the impact of that is (especially since "route" is an obsolete utility), typically manually messing with networking will just upset connman which is responsible for managing network interfaces and will generally fight you
<zmatt> sharing internet to the bbb via usb is tricky... I know how to do it with systemd-networkd (as used on bullseye testing images) but not sure if it can be done reliably in the old setup with connman (since the usb interfaces aren't managed by connman but the system default route is)
<Guest2329> # This file describes the network interfaces available on your system
<Guest2329> # and how to activate them. For more information, see interfaces(5).
<zmatt> I'd generally recommend using ethernet to share internet access to the BBB is that's an option at all. e.g. if you have a laptop on wifi that also has an ethernet port, just share the laptop's internet access to its ethernet port and connect the BBB to that
<Guest2329> # The loopback network interface
<Guest2329> auto lo
<Guest2329> iface lo inet loopback
<Guest2329> # The primary network interface
<Guest2329> #auto eth0
<Guest2329> #iface eth0 inet dhcp
<Guest2329> # Example to keep MAC address between reboots
<Guest2329> #hwaddress ether DE:AD:BE:EF:CA:FE
<Guest2329> ##connman: ethX static config
<Guest2329> #connmanctl services
<Guest2329> #Using the appropriate ethernet service, tell connman to setup a static IP address for that service:
<Guest2329> #sudo connmanctl config <service> --ipv4 manual <ip_addr> <netmask> <gateway> --nameservers <dns_server>
<Guest2329> ##connman: WiFi
<Guest2329> #
<Guest2329> #connmanctl
<Guest2329> "/etc/network/interfaces" 28L, 819C 14,1 Top
<zmatt> please never do that again
<zmatt> don't paste multi-line stuff in chat
<Guest2329> ok sorry
<zmatt> /etc/network/interfaces is not relevant
<zmatt> it's the config file for another network manager (ifupdown) which is not used on the BBB
<Guest2329> yes, i have USB to ethernet adapter and using it between my windows laptop and BBB
<zmatt> uhh okay then no setup is needed on the BBB, it will just work
<Guest2329> also using USB to TTL for serial console
<Guest2329> but not working :-)
<Guest2329> i think i messed it
<Guest2329> can I just reflash the eMMC image?
<zmatt> if the bbb doesn't have internet access when connected like that then your laptop isn't sharing internet (or you seriously messed up the bbb)
<zmatt> btw the "route" command has no permanent effects, i.e. if it is the cause of your problems then a reboot would fix it
<zmatt> conversely if a reboot doesn't fix it, the route command isn't the cause of your problems
<Guest2329> i tried couple of reboots and shutdown now.....restarted...still problem
<zmatt> and yes you can always reflash eMMC to have a fresh start
<Guest2329> what if I reflash eMMC ??     any instructions please, how to do reflash ?
<zmatt> easiest way is by downloading a "Flasher" image from the "Flasher Debian images" section of https://beagleboard.org/latest-images
<zmatt> for the BBB you want the "AM3358 Debian 10.3 2020-04-06 4GB eMMC IoT Flasher"
<zmatt> (make sure you click on a link that explicitly says "Flasher" .. the ones that don't are simply bootable images rather than flashers)
<zmatt> write the image to SD card using Etcher (etcher.io)
<zmatt> boot the BBB from the SD card and it'll automatically proceed to reflash eMMC and will power off when done
<zmatt> in rare cases, if there's a really ancient/weird/broken bootloader on eMMC it may fail to boot successfully from SD card, in that case the bootloader on eMMC can be bypassed by holding the S2 button (the button closest to the SD card slot) when powering on the BBB (you can let go of the button when any led turns on)
<Guest2329> yeah ok, i got that etcher io installed and have 64GB SD card too ready...thanks for that link...matt...will try reflashing..thank u n bye now
AKN has joined #beagle
<AKN> Hi everyone, Anyone worked on brcmfmac43430 chipset?
<AKN> 5.649444] of_get_named_gpiod_flags: parsed 'reset-gpios' property of node '/brcmf_pwrseq[1]' - status (0)
<AKN> [ 11.296356] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1
<AKN> [ 12.445831] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl 0x50
<AKN> [ 13.485778] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl 0x50
<AKN> I tried most of the nvram files available on internet still getting the same error.
<AKN> Linux bbai 5.10.120-gd5f4ca50bb #1 SMP PREEMPT Mon Jun 29 03:06:40 UTC 2020 armv7l armv7l armv7l GNU/Linux
<zmatt> you're using a custom kernel of some sort that's not based on rcn's ti kernel series?
<AKN> based on ti-linux-kernel-5.10.y
<zmatt> as in, the original one from TI or with rcn's patchset?
<AKN> original TI
<AKN> meta-ti repo
<zmatt> rcn's kernel (which is what's used on the official beagleboard.org images) seems to have a giant pile of brcmfmac-related patches: https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/ti-linux-5.10.y/patch.sh#L680-L779
<zmatt> so I'm guessing the upstream version of the driver has.... issues
<AKN> Thank you, I try implementing the patches.
set_ has quit [Remote host closed the connection]
Guest2329 has quit [Ping timeout: 252 seconds]
rob_w has joined #beagle
azarubkin has joined #beagle
florian has joined #beagle
azarubkin has quit [Quit: Client closed]
otisolsen70 has joined #beagle
indigaz8 has joined #beagle
indigaz has quit [Ping timeout: 276 seconds]
indigaz8 is now known as indigaz
Shadyman has quit [Quit: Leaving.]
akaWolf has quit [Ping timeout: 272 seconds]
Guest13 has joined #beagle
Guest13 has quit [Client Quit]
akaWolf has joined #beagle
Guest58 has joined #beagle
Guest58 has quit [Client Quit]
SteveMarple has joined #beagle
jfsimon1981_c has joined #beagle
starblue has quit [Ping timeout: 248 seconds]
jfsimon1981_b has quit [Ping timeout: 264 seconds]
starblue has joined #beagle
SteveMarple has quit [Remote host closed the connection]
starblue has quit [Ping timeout: 240 seconds]
starblue has joined #beagle
SteveMarple has joined #beagle
azarubkin has joined #beagle
<SteveMarple> I'm using mmap'd access to the BB GPIO ports to use it as an OpenOCD JTAG/SWD programmer. I want to be able to control the internal pull-ups on the GPIO pins.
<SteveMarple> The technical reference manual states "For writing to the control module registers, the MPU will need to be in privileged mode of operation and writes will not work from user mode."
<SteveMarple> How can this be done from user code?
<SteveMarple> The TRM isn't clear on the pad control registers either. Only 124 are listed, not the 128 as I expected. I haven't worked out which 4 are missing. Based on the difference in address offset it seems the first 3 ports are fully documented.
<zmatt> there's a hacky way to get the kernel to do a privileged write to an mmapped region, but since that requires a syscall you could then just as well change the pullup state using the pinmux helder instead of mucking with /dev/mem
<zmatt> *pinmux helper
<zmatt> not sure what you mean with the second bit but you can find the index into the pinctrl array for all expansion header pins of the BBB here: https://github.com/mvduin/overlay-utils/blob/master/include/bone/black.h or in my spreadsheet: https://goo.gl/Jkcg0w#gid=698174264
<zmatt> there are 211 pad control registers total, not 128, though not all of them are useful and a few don't even correspond to physical pins
<SteveMarple> zmatt: thanks. It seems using some external program to set pull-ups before starting OpenOCD is the way to go.
otisolsen70 has quit [Read error: Connection reset by peer]
<azarubkin> Hi everyone, could you please confirm that USB3 (USB-C connector) on the Beaglebone AI is usable or not? Because I tried to connect a USB hub to it, and USB-C flash drive, they weren't listed in **lsusb** output.
<SteveMarple> gpioset from linuxgpiod ought to do the job - but it doesn't have the options for pull-ups and drive mode.
azarubkin has quit [Quit: Client closed]
otisolsen70 has joined #beagle
nparafe has quit [Ping timeout: 240 seconds]
argonautx has joined #beagle
nparafe has joined #beagle
brook has joined #beagle
azarubkin has joined #beagle
aussetg has joined #beagle
<aussetg> Hi, I've just received my Beaglebone AI 64 and I don't see 4Gb of RAM at all in linux. Is an amount reserved to other cores etc ? ( I see 2.09G)
<aussetg> I imagine the ram is split between the various R5 cores, PRUs, 2xC66 and C71x... but I can't find a corresponding DTS / doc. Anyway. What a weird and cumbersome system, I' sure it will provide endless fun :)
<rcn-ee> aussetg: by default those 2gb are used up by the remoteproc cores... I've built a special dtb if you want the full 4GB for just the a72's..
<aussetg> I've found the mapping in /opt/source/dtb-5.10-ti-arm64/src/arm64/k3-j721e-rtos-memory-map.dtsi . I imagine your file is /opt/source/dtb-5.10-ti-arm64/src/arm64/k3-j721e-beagleboneai64-no-shared-mem.dts ? And it's fine, without the added stuff it's not a very fun board :)
<rcn-ee> azarubkin: usb3 type c by default is really setup to be a device. Use it to provide power to the am57xx, and it'll show up as a USB gadget.. any other mode and you really need to rebuild the device tree..
<rcn-ee> aussetg: correct! Someone would always ask, so I enabled it..
aussetg has quit [Quit: Client closed]
rob_w has quit [Quit: Leaving]
vagrantc has joined #beagle
otisolsen70 has quit [Quit: Leaving]
Guest35 has joined #beagle
<Guest35> Does anyone know what size the barrel jack on the BeagleBone AI-64 is going to be / is?
AKN has quit [Read error: Connection reset by peer]
<azarubkin> rcn-ee so simply running "sudo /opt/scripts/boot/bbai_usb_host.sh" won't work? A device tree rebuild is necessary?
Guest35 has quit [Quit: Client closed]
brook has quit [Quit: Leaving...]
florian has quit [Quit: Ex-Chat]
brook has joined #beagle
jfsimon1981 has joined #beagle
jfsimon1981_c has quit [Ping timeout: 240 seconds]
jfsimon1981 has quit [Read error: Connection reset by peer]
jfsimon1981 has joined #beagle
brook has quit [Remote host closed the connection]
brook has joined #beagle
brook has quit [Ping timeout: 248 seconds]
kveremitz has quit [Ping timeout: 260 seconds]
PhotoJim has quit [Ping timeout: 248 seconds]
<rcn-ee> azarubkin: forgot about that . Maybe
<azarubkin> rcn-ee: could you please direct me to some information about device tree rebuild? what exactly do I need to change?
<azarubkin> to enable USB3 host mode on Beaglebone AI, I mean
brook has joined #beagle
azarubkin has quit [Quit: Client closed]
Guest44 has joined #beagle
PhotoJim has joined #beagle
<Guest44> I notice in /boot/dtbs/ there are many device tree files.  Why so many?  I thought only one was loaded, at boot time, but it appears I'm misinformed.
<vagrantc> different platforms need different .dtb files
<Guest44> vagrantc platforms==different beaglebones?  or platforms==different capes?  or something else?
<vagrantc> I'll pick option D, all of the above
<Guest44> What I'm really trying to understand is if multiple dtb files are used.  Perhaps some are just fragments?
<Guest44> I see there is a am335x-icev2.dtb.  Is that one used/required for /sys/bus/iio?
<Guest44> vagrantc, BTW, are you coming to LTSP By The Sea in November?  I think it's the 20th anniversary.
* vagrantc blinks
<vagrantc> hadn't planned on it, nor did i expect to be nudged about it in #beagle :)
<vagrantc> nor did i know about it
* vagrantc 's curiosity is piqued
<jkridner> arubkin: that script should have the magic on its own. no dt changes
<Guest44> contact jamcq.  He's expecting a big turnout this year.  Nov 4-12.
Guest44 has quit [Quit: Client closed]
kveremitz has joined #beagle
Guest44 has joined #beagle
<Guest44> I see that beagle debian has the TI_AM335X_ADC driver built into the kernel, whereas on my buildroot image it's a loadable module.  Might that have any role as to why I have no /sys/bus/iio on my buildroot image for my BBB?
Guest44 has quit [Quit: Client closed]
Guest44 has joined #beagle
akaWolf has quit [Ping timeout: 272 seconds]
<Guest44> (My session in the web chat keeps dropping for some reason.)
<Guest44> So, how does one make use of all those other DTB files in /boot/dtbs, or see if they're being used?
<Guest44> Is there some mechanism that detects what kind of board is being booted and chooses the appropriate DTB file?
<Guest44> If so, that sounds like u-boot territory.
lucascastro has joined #beagle
akaWolf has joined #beagle
brook has quit [Remote host closed the connection]
brook has joined #beagle
lucascastro has quit [Remote host closed the connection]
brook has quit [Remote host closed the connection]
brook has joined #beagle
brook has quit [Remote host closed the connection]
argonautx has quit [Quit: Leaving]
brook has joined #beagle
brook has quit [Ping timeout: 256 seconds]
brook has joined #beagle
azarubkin has joined #beagle
<zmatt> Guest44: there is such a mechanism yes.
<zmatt> Guest44: iio being missing sounds more like a kernel config issue, whether a driver is compiled-in or loadable shouldn't matter
<azarubkin> jkridner: I thought so too, but like I said, my USB hub with USB-B to USB-C cable and USB-C flash drive are not visible even if I run "sudo /opt/scripts/boot/bbai_usb_host.sh". Are you sure it works with the image from "latest images" webpage at beagleboard.org? Specifically,
<azarubkin> Another possibility, of course, if that my Beaglebone AI has broken USB-C. On another hand, it works in USB gadget mode when connected to the PC...
<zmatt> azarubkin: the BBAI's type-C port does not technically support host role
<zmatt> forcing it into host role can sometimes work with some hubs but it'll be hit-or-miss... I think the hubs with which it *does* work are technically non-spec-compliant
<azarubkin> zmatt: I saw such mentions on the forums and was afraid of that. So, it's not guaranteed, I see. Any chance of a list of hubs known to work with BBAI?
<zmatt> azarubkin: technical details: https://github.com/beagleboard/beaglebone-ai/issues/56
<zmatt> dunno if there's such a list
<azarubkin> Thank you
ft has quit [Ping timeout: 248 seconds]
<Guest44> zmatt: Yes, I think I just found (part of) the problem: The ti_am335x_adc module depends on kfifo_buf and industrialio modules, none of which are being automatically loaded.
ft has joined #beagle
<zmatt> Guest44: that sounds more like the kernel just didn't try to load the adc's driver... is it enabled in DT ?
<zmatt> the adc I mean
<Guest44> zmatt: I think it was set to "disabled" in the DT, so I changed it to "okay" and then recompiled it and booted with that.  But it was after that that I discovered those modules were not being loaded.
<zmatt> that's probably not sufficient for the adc though, it also requires config in DT
brook has quit [Remote host closed the connection]
<Guest44> zmatt: I noticed yesterday in the am335-boneblack.dtb (dts) that it's also disabled, so figured that wasn't the source of the problem.
<zmatt> on normal beagleboard.org images it's enabled by an overlay that's loaded by default
<Guest44> Sorry: I noticed that in the amd335-boneblack.dtb that came with my BBB 10.3 image.
<Guest44> Ah, is that why there are several DTB files in /boot/dtbs/?
<zmatt> that dtb isn't used on normal beagleboard.org images anyway, it's only used when u-boot overlays are not enabled
<zmatt> /boot/dtbs/ only contains base DTB files, not overlays
<zmatt> and overlays won't be supported on buildroot anyway
<zmatt> by default u-boot will pick which base DTB file to loade based on the board that was detected
<zmatt> this allows a single image to work on different AM335x-based boards without having to change anything
<Guest44> zmatt: So can I fix that by adding whatever is in that overlay file to a rebuilt am335x_boneblack.dtb?
<zmatt> to use the adc, you need to configure it to your custom .dts file (which you'll need to have to setup peripherals and pins anyway if you're using buildroot)
<zmatt> *in your custom .dts file
<Guest44> I think it must be partly working because I'm already using some of the other pins (digital ones).
<Guest44> Where do I find the overlay file with the adc config?
<zmatt> you can get gpio to work without any DT config since pins are muxed to gpio by default on the AM335x, and without the (non-mainline) gpio-of-helper driver there isn't really a good way to set those up in DT anyhow
<zmatt> 22:39 <@zmatt> example config with comments: https://github.com/mvduin/overlay-utils/blob/master/adc.dtsi
<zmatt> btw I think I've seen you mention decompiling .dtb files... so just to be sure: decompiling is rarely a good idea since a lot of semantic information is lost compared to the original source, and in particular one should never attempt to modify and recompile a decompiled dtb since this is almost guaranteed to yield a corrupt device tree
<Guest44> Oh!  Good to know.
<Guest44> I read somewhere about how one can decompile dtb files, but it was probably meant more for inspection than "reuse".
<zmatt> I'd generally also advise to use a custom name for one's custom dts/dtb and leave the original alone (you can #include the original .dts into your custom .dts and then add your customizations below that), though that requires explicitly telling u-boot the name of your dtb file and I don't know how to do that when using buildroot
<Guest44> Currently, I just specify the dtb in extlinux.conf.
<zmatt> ah ok
Guest5 has joined #beagle
<zmatt> so yeah, then just make a .dts file with a custom name alongside the original am335x_boneblack.dts, start it with '#include "am335x_boneblack.dts"' and then add blocks of DT customization below that (such as the contents of https://github.com/mvduin/overlay-utils/blob/master/adc.dtsi ) and compile the dts into dtb using the makefile
starblue has quit [Ping timeout: 240 seconds]
Guest5 has quit [Client Quit]
<zmatt> I recommend reading the comments in that adc.dtsi file to understand what it is you're configuring
starblue has joined #beagle
<zmatt> if you don't need all 8 channels, reducing the number of channels configured will increase the max sample rate
<Guest44> I only need one channel right now, although I expect that will change down the road.  But that's a ways off, so I'll go for simplicity now.
<zmatt> well, going for simplicity would be using the file as-is (which configures all 8 channels)
<Guest44> zmatt: True, and I would have started with that. ;-)
<zmatt> like I said, the main reason to modify it would be to be able to achieve a higher sample rate (see comments in adc.dtsi regarding how the config determines the sample rate)
<Guest44> Thanks a bunch.  You've given me the answer I've been looking for (on and off) for the past month.  I was pretty sure it was something awry in the dtb but didn't know how to sniff it out.
<zmatt> for some very basic explanation of how device tree and its source code works: https://pastebin.com/XC8vB33d
<Guest44> My sample rate will be relatively low; human scale.
<Guest44> Ah, good, thanks for the example.  I usually need a lot of those.
<zmatt> there's also some settings that may need tuning if whatever you're measuring has a relatively high source impedance (> 5.5 kΩ)
set_ has joined #beagle
<Guest44> Just measure the voltage on some tiny photovoltaic cells.
<Guest44> measuring
<zmatt> I have no idea what the output impedance is of those
<Guest44> Nor do I but most of my colleagues are EEs so I can ask them.
<Guest44> thanks for the highlighting
zjason` has quit [Read error: Connection reset by peer]
zjason` has joined #beagle
Guest7992 has joined #beagle
<Guest7992> I need to find an ISO9001 cert from whoever manufactures the BegalBone Black
Guest44 has quit [Ping timeout: 252 seconds]
Guest7992 has quit [Client Quit]
brook has joined #beagle
brook has quit [Remote host closed the connection]
brook has joined #beagle
javaJake has quit [Remote host closed the connection]
Guest44 has joined #beagle
<azarubkin> I'd like to build custom Linux kernel for the BBB. The currently installed kernel is 4.19.94-ti-r73. Which repository contains the exact source the kernel was built from?
brook_ has joined #beagle
brook has quit [Ping timeout: 272 seconds]
<zmatt> azarubkin: here's some notes on customizing the kernel: https://pastebin.com/eLhrp1Hg
<zmatt> for the kernel you mentioned you'd want the ti-linux-4.19.y branch of https://github.com/RobertCNelson/ti-linux-kernel-dev/
<azarubkin> Thanks zmatt, this is useful.
<azarubkin> I wonder, so I clone the repo, checkout the branch, then I run build_deb.sh or build_kernel.sh, it will clone the Linux kernel sources from Torvalds' repo and apply some patches? That is, if I understand the scripts correctly.
<zmatt> yep, it will check your host system and download a toolchain the first time, it checks out the appropriate upstream kernel branch, applies patches and kernel config, gives you an opportunity to customize the kernel config, builds the kernel (+ modules and dtbs), and (in case of build_deb.sh) builds debian packages from it
Shadyman has joined #beagle
<azarubkin> Looking through the scripts, it pulls mainline Linux, checks out the appropriate tag (4.19.94), then pulls Linux kernel source tree with TI patches, then applies local patches, etc etc etc. Wow.
behanw has joined #beagle
<zmatt> it probably pulls mainline first to reduce the amount of data that needs to be pulled from TI's slow git server ;)
<azarubkin> TI code is hosted in Github too, in RobertCNelson account, as far as I understand (https://github.com/RobertCNelson/ti-linux-kernel)
<zmatt> ah
<zmatt> right, he mirrored it.. probably because he got tired of pulling from TI's slow git server directly :D
<azarubkin> :-D
<azarubkin> Ok, I've built a deb, how do I supply it to image-builder (https://github.com/beagleboard/image-builder)?
<zmatt> no idea I've never used image-builder
<azarubkin> I see. What do you do in order to replace the kernel? Install deb on a live system?
<zmatt> I mean, in what context? on development systems we obviously just install packages via apt, for production systems we have a template system from which we build our images
nparafe has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
nparafe has joined #beagle
<azarubkin> I have the following task. I've created a software for the Beaglebone Black as a prototype, the real boards are custom, they are in SODIMM form factor. The manufacturer said he replaced the PMIC chip with another one because the original had its price skyrocketed. He also removed EEPROM chip from the board because it is used to switch between
<azarubkin> different Beaglebone boards while we have only one. These changes obviously require some patches to the stock u-boot and kernel.
<azarubkin> They offer to provide patches for the u-boot and kernel, but in order to apply them, I need to understand how the image for the BBB is built.
<azarubkin> I guess I need to use the template system like you do to build the image
<zmatt> you'll also need a custom device tree, or is that what you meant by kernel patches?
<azarubkin> probably yes
<zmatt> the eeprom removal is a dumb choice imho, an eeprom costs nothing and now you can't have the same image work on both beaglebone and your custom hardware
<azarubkin> don't get me started :)
<azarubkin> the management staff was also surprised at their solution
<zmatt> eeprom should have been programmed with custom identification to allow for board autodetection
<zmatt> what replacement pmic did they use?
<azarubkin> TPS65910A3A1
<zmatt> A3A1 ? not A31A1 ?
<azarubkin> mmm that's how it's stated in their email
renrelkha has quit [Quit: bye]
<azarubkin> such a pain out of nothing, ugh
renrelkha has joined #beagle
<azarubkin> ok, I'll continue tomorrow. Bye and thanks for all your help!
<azarubkin> btw, what's the difference between A3A1 and A31A1 chips?
azarubkin has quit [Quit: Client closed]
<zmatt> a small OTP fix that makes the VRTC regulator supply enough current to supply the VDDS_RTC supply of the AM335x avoiding the need for a separate regulator for that, see Figure 1 vs Figure 2 in https://www.ti.com/lit/ug/swcu093f/swcu093f.pdf
vagrantc has quit [Quit: leaving]
akaWolf has quit [Ping timeout: 240 seconds]