<zmatt>
there was a change of manufacturer and annoyingly this resulted in distributors showing the part produced by the old manufacturer as "no longer available"
<zmatt>
no idea what this "starter kit" is, never heard of it
<Guest94>
Thank you
<Guest94>
ok
<Guest94>
Much appreciated for your help
<Guest94>
You are great!
<Guest94>
Have a nice day!
<Guest94>
Bye :)
Guest94 has quit [Quit: Client closed]
calrama has joined #beagle
<zmatt>
... what
<zmatt>
ah nm
<calrama>
Hm, since the above does not seem doable: How do I configure pinmuxing on kernel 4.14? I know how to do it on 4.19+ with config-pin, but on 4.14 that doesn't work, because the /sys interfaces are missing.
<zmatt>
there's no theoretical objection for cape-universal to work on 4.14 on bbai, but it's possible the necessary changes simply haven't been made
<zmatt>
the alternative is a customized DT, which is a bit more annoying
<calrama>
Specifically, I need to configure (on BeagleBone AI) P8.07 to mode pruout. On kernel 4.19+ this can be done via /sys/devices/platform/*ocp/*ocp:P8_07_pinmux, but on 4.14 that file (and all the others for the other pins) are missing.
<zmatt>
it used to be an overlay on the bbb, on the bbai I think it's part of the base dt but I haven't checked
<zmatt>
but it's just referring to the general idea of enabling everything and the kitchen sink and creating a bone-pinmux-helper device per pin to allow runtime configuration of pinmux
<zmatt>
(instead of the way DT is spposed to work, enabling the peripherals you use and attaching pinmux nodes to those devices to configure the pins for that specific device)
<calrama>
Ok, would writing a custom dt overlay work, as well?
<calrama>
I'm kinda hesitant to just copy paste and start editing the whole dt.
<zmatt>
you don't "copy paste" it, you #include it, like my example showed
<zmatt>
the rest of the file is essentially the same as writing an overlay
<zmatt>
you could probably also do it using an overlay, though the main benefit of using overlays, which is their modularity, is basically broken by &cape_pins_default ... so there's no much reason to use an overlay rather than a custom DT, but either option should work I think as long as your u-boot is new enough for overlays
<calrama>
I see. And assuming I just wanted to try out the DT example you pastes as-is. How would I do that? I can only find information on compiling dto's not custom dt's.
<calrama>
And if you're including the main dt, I assume I have to download some dependencies?
<zmatt>
save the dts (and any custom dependencies listed at the top) in src/arm/
<zmatt>
build it with "make src/arm/name-of-your-file.dtbo"
<zmatt>
eh
<zmatt>
build it with "make src/arm/name-of-your-file.dtb"
<zmatt>
put the dtb file in /boot/dtbs/ or /boot/dtbs/KERNEL-VERSION/
<zmatt>
and configure it using the dtb= option in /boot/uEnv.txt
<zmatt>
but like I said, you could also use an overlay instead I guess
<zmatt>
the source would be mostly unchanged, except you don't #include the main dts and instead have /dts-v1/; /plugin/; (and any / {..} fragment should use &{/} {..} instead, though my example doesn't have any)
<zmatt>
and you probably need additional #includes for macros that are defined in headers that would otherwise already be indirectly included by the main dts
<calrama>
Alright, ty. I'm rebooting the bbai with your example custom dt rn to see if it works.
<calrama>
(as in that I have correctly understood how to do it)
vagrantc has joined #beagle
<calrama>
Hm, too bad. It simply doesn't boot.
<zmatt>
oof
<calrama>
(I used the 4.14 ti branch of the repo, same as my kernel)
<zmatt>
that should be right
<zmatt>
weird
<calrama>
Is there a way to get a serial console via usb?
<calrama>
(other boards often present something like /dev/ttyUSB, but the bbai doesn't)
<zmatt>
that console is created by linux, it's not a true serial console
<zmatt>
the original beaglebone white had an integrated usb-serial converter, but none of the later boards do
xet7 has quit [Remote host closed the connection]
<zmatt>
they do still have a serial console, but you need to bring your own usb-serial converter (3.3v ttl, not rs232)
<zmatt>
yeah, although annoyingly the bbai doesn't use the standard 6-pin header but a weird 3-pin one
<zmatt>
so I'm not sure where to get an appropriate cable, I don't have one myself
<calrama>
It seems to be a jst zh 3 pin.
mag has quit [Remote host closed the connection]
Guest6486 has joined #beagle
Guest6486 has quit [Client Quit]
mag has joined #beagle
buzzmarshall has joined #beagle
calrama has quit [Quit: Client closed]
lucascastro has quit [Ping timeout: 246 seconds]
xet7 has joined #beagle
xet7 has quit [Read error: Connection reset by peer]
xet7 has joined #beagle
lucascastro has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
Guest4771 has joined #beagle
lucas_ has joined #beagle
lucascastro has quit [Ping timeout: 260 seconds]
Guest5961 has joined #beagle
set_ has joined #beagle
<vvn>
you need to hold the S2 button down on every power cycle if you want to boot from the SD card, right?
Guest5961 has quit [Quit: Client closed]
<hays>
emulating with qemu, is there a profile thats best for the bblack
<rcn-ee>
hays: qemu doesn't have a BBB profile, just use cortex-a8..
<hays>
realview-pb-a8
<rcn-ee>
hays: what is your actual end goal, or what are you actually trying to do?
<hays>
honestly just playing around. but it might be nice to be able to test userspace stuff with an emulator.
<rcn-ee>
test what userspace stuff? For the BeagleBone Black, just get a board... ;)
<vvn>
I'd be interested as our main product is on a beaglebone black, thus emulating our software stack with Jenkins and all might be neat
<rcn-ee>
but it's linux... Jenkins runs on java... Just run Jenkins on another sbc.. doesn't really matter if it's on arm..
<hays>
the concept of "spinning up" a BBB would be useful for certain kinds of tests
<hays>
abstractly at least
<rcn-ee>
side note, java can be fun on Single Core non-smp, it's not really tested so the java developers have broken the AM335x a few times over the last year..
<hays>
i think i ran into that a while back
<hays>
some java8 was not working. cant remember though. I just remembered things were finicky
<rcn-ee>
hays: not really anymore.. There was a few patches 10 years ago.. but the omap3/am335x peripherals never went mainline in qemu..
<rcn-ee>
thus, you'd emulate "arm"... but not the AM335x...