02:19 <set_> Well...

02:20 <set_> I fellow/lady from the forum(s) talked me into trying ArduPilot again. So...

02:20 <set_> Here I go...

02:20 <set_> Oh and GenTooMan: I will let you know if I can get it up this time!

02:20 <set_> Fly Blue, Fly!

02:21 <set_> I think I stuck the PRU pin input in the wrong connector pin. It has 'always' been P8_16 and not P8_15. Sheesh.

02:21 <set_> So...we shall see.

02:23 <set_> All and all, I think I fell victim to poor behavior and lying. So, this may be a lesson on how to ___ myself when online and also to test instead of believe.

02:27 <set_> and then...

02:27 <set_> On to PX4 again, hopefully.

09:32 <set_> poof

11:12 <set_> How can I turn a P8_16 PRU input into P8_15 PRU input w/ memory mapping in hexadecimal format on a .dts file, i.e. am335x-boneblue.dts?

11:12 <set_> I know it is early. So, I shall wait.

11:30 <zmatt> set_: your question is nonsensical, also haven't we already been over this?

11:31 <set_> Well @zmatt: Yes and no.

11:31 <zmatt> there's almost certainly no need for you to modify a dts

11:32 <set_> Well, why is P8_16 a pru in when the source does not call for P8_16. It calls for P8_15 to handle the PRU input.

11:32 <set_> @zmatt: I know you hate repetition.

11:33 <set_> I would really like to figure out what I do not understand (at times).

11:33 <zmatt> both pins are in pruin mode by default, and P8_15 can additionally be reconfigured (using config-pin) into other modes such as pru ecap mode (config-pin P8_15 pruecapin_pu)

11:33 <set_> Right.

11:33 <set_> Okay.

11:35 <set_> config-pin P8_15 pruecapin_pu <<< This is what I have in a .sh file to handle the P8_15 input. But...in the .dts/.dtb, the pin used is P9_16 and...

11:35 <set_> The Servo Headers are not turning on when using GPIO80 or GPIO54.

11:36 <set_> Is there a particular GPIO pin that handles the servo headers?

11:37 <zmatt> your words are an incoherent jumble of completely unrelated things

11:37 <set_> Okay.

11:38 <set_> Fine. No issue. I tried to understand something new and got turned down. No issue here.

11:38 <set_> Blah!

11:39 <zmatt> P9_16 is the pwm output (ehrpwm1b) used for M2, gpio80 (2.16) is the SERVO_EN signal that enables the regulator for the 6V servo supply, gpio54 (1.22) is the blue USR1 led which is controlled by the kernel for showing sd card activity, and none of these have anything to do with P8_15/16 or pru

11:40 <set_> Okay. Sorry. I just got what happened. I typed P9 instead of P8. Sorry.

11:40 <set_> And yes. GPIO80 handles the SERVO_EN signal that is supposed to turn on the 6v reg.

11:42 <set_> Okay so...

11:42 <zmatt> all external pins on the beaglebone blue have pinmux defined in the .dts, including "P8_16" and "P8_15" (which actually refer to pins 3 and 4 of the 4th encoder connector)

11:43 <set_> Where? What line if you are using github or vim?

11:43 <set_> I see P8_16.

11:43 <set_> Only.

11:43 <zmatt> is the search function broken in your browser / text editor?

11:43 <set_> No Sir.

11:44 <set_> I will go and look.

11:44 <zmatt> then search for P8_15 and you will find it

11:44 <set_> So, P8_15. Okay. Please hold or have tea or whatever. Sheesh. Let me go and check.

11:45 <zmatt> it has a "pinmux-helper", which is what allows it to be configured using config-pin

11:46 <zmatt> (P8_16 instead has hardcoded fixed configuration, though I don't know why, it seems very strange to me it doesn't also have a pinmux-helper, but I guess noone has yet had a desire to reconfigure that pin)

11:47 <set_> Oh yea. I saw that.

11:47 <set_> I forgot.

11:47 <set_> I am up and running now for some reason. I found a typo too (in my source of course).

11:48 <set_> Sheesh. Anyway...thank you as usual. I feel like I am being mad or something. I need to breathe.

13:22 <set_> Dang it!

13:22 <set_> break time!

16:45 <vd> what is mcasp0?

16:54 <zmatt> mcasp = multi-channel audio serial port

16:55 <zmatt> mcasp0 specifically is used to transmit audio to the hdmi framer, if hdmi audio is enabled

16:56 <zmatt> if hdmi audio is not used it may be used e.g. to interface with external audio codecs

16:58 <vd> ok. and tda19988@70?

16:58 <zmatt> that's the hdmi framer

16:58 <vd> thank you

17:00 <vd> zmatt: my device tree which #include "am335x-boneblack.dts" (mostly written thanks to you) works perfect in linux. I'm trying to port it to my bootloader (barebox) and for some reason, upstream am335x-boneblack.dts works fine but my device hangs after the ns16550_serial_driver_register+0x1/0xc initcall

17:01 <vd> I must come from something I've added/removed on top of am335x-boneblack.dts, but I have no clue what

17:02 <zmatt> maybe there's a barebox irc channel where you can get help

17:02 <zmatt> I don't know anything about it

17:03 <vd> I did ask there and it's where I'm stuck. I figure maybe this channel had experience with the boot hanging at this serial step

17:03 <zmatt> like, I'd expect most customizations you'd do to your dts to be completely irrelevant to a bootloader

17:03 <vd> I do too

17:04 <zmatt> so maybe a better question is: what information does barebox extract from the DT to begin with?

17:05 <zmatt> if it hangs after something serial-related, my first thought would be whether it somehow decided to use a different serial port as console, giving the appearance of hanging

17:07 <zmatt> then again, I assume the reason you know it hangs after "the ns16550_serial_driver_register+0x1/0xc initcall" is because of some kind of debug output to the serial console, and I'd assume that if it gets serial port config from DT it would be applicable from the start hence you'd have no debug output whatsoever... but these are all assumptions since I know nothing about barebox or whatever it might do ...

17:07 <zmatt> ...with dt

17:08 <zmatt> why are you using your custom dts in barebox anyway? is there any benefit to that?

17:08 <vd> it helps a lot already! Gives me clues.

17:09 <vd> zmatt: because having access to the framebuffer might be interesting (to display a splash screen) as well as the button (in order to change to boot order depending on a button hold or not for example)

17:10 <zmatt> does barebox have a driver for tilcdc ?

17:10 <vd> and it's also interesting (I love barebox)

17:10 <vd> let me see

17:11 <vd> zmatt: yes it does

17:12 <zmatt> you sure? "We don't have a framebuffer driver for am335x" -- email on barebox mailing list dated 2020-08-12

17:13 <zmatt> I'm not seeing any useful google results for barebox + tilcdc

17:13 <zmatt> besides that email

17:15 <zmatt> nah there's no lcdc driver in https://git.pengutronix.de/cgit/barebox/tree/drivers/video

17:17 <vd> ho indeed it doesn't... the occurences I found come from the upstream kernel device trees imported into barebox...

17:18 <zmatt> so the easy fix here is to just not stick your custom DT into barebox, it doesn't need to know or care about your DT customizations

17:19 <zmatt> it only needs to know how to initialize the board to the point of having a serial console and being able to load and execute the kernel

17:20 <zmatt> (which honestly is a job that shouldn't even require 2-stage loading like u-boot and barebox use)

17:22 <zmatt> (because they can't manage to fit their fat ass into 109 KB, which is the max size executable that can be directly loaded by bootrom)

17:23 <vd> the tilcdc driver may be relatively easily ported to barebox and with my device tree in the bootloader I could preconfigure things like gpio hogs instead of locking them in the kernel. But I could stick with the boneblack dts for sure, let's say it's interesting and helped me dig more into device tree and barebox.

17:25 <zmatt> using DT for the bootloader still seems weird to me, most info in DT is irrelevant for the bootloader and some of the most important board information the bootloader needs is not represented in DT at all

17:25 <zmatt> (like memory timings)

17:27 <vd> yeah you're right, it's part of the gray area around device tree definition... but bootloaders are not mostly a strip kernel... (way too featured IMO), but at the same time it allows to do cool things before the kernel boots (screen, buttons, complex boot sequence or recovery, testing, etc.)

17:29 <vd> I would definitely prefer the bootloaders to be very minimal (like MLOs) and booting a linux kernel which kexec the final kernel instead of porting drivers around to bootloaders. But the kexec support isn't complete everywhere.

17:34 <zmatt> fixing kexec seems like a more worthwhile endeavour then

19:27 <set_> That is it. Who did it? Who made the blue fly?

19:29 <set_> Not naming any names. GenTooMan.

19:30 <set_> Sir, was it you?

19:30 <set_> Did you make the BBBlue fly?

19:52 <set_> Come on, spill the beans. Who did it? Who knows?

19:54 <set_> Everything pans out. The source, 'said,' works, the BBBlue works, come on (I work), and still-STILL, this flight - the journey - is not happening. Send rations!

19:56 <set_> Boss to begger in three minutes flat. Dudes, ladies, please. I beg of flight.