**** BEGIN LOGGING AT Sat Sep 18 03:00:04 2021 Sep 18 03:19:39 Well... Sep 18 03:20:02 I fellow/lady from the forum(s) talked me into trying ArduPilot again. So... Sep 18 03:20:12 Here I go... Sep 18 03:20:24 Oh and GenTooMan: I will let you know if I can get it up this time! Sep 18 03:20:35 Fly Blue, Fly! Sep 18 03:21:23 I think I stuck the PRU pin input in the wrong connector pin. It has 'always' been P8_16 and not P8_15. Sheesh. Sep 18 03:21:36 So...we shall see. Sep 18 03:23:43 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. Sep 18 03:27:07 and then... Sep 18 03:27:17 On to PX4 again, hopefully. Sep 18 10:32:35 poof Sep 18 12:12:07 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? Sep 18 12:12:28 I know it is early. So, I shall wait. Sep 18 12:30:47 set_: your question is nonsensical, also haven't we already been over this? Sep 18 12:31:08 Well @zmatt: Yes and no. Sep 18 12:31:18 there's almost certainly no need for you to modify a dts Sep 18 12:32:00 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. Sep 18 12:32:54 @zmatt: I know you hate repetition. Sep 18 12:33:17 I would really like to figure out what I do not understand (at times). Sep 18 12:33:17 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) Sep 18 12:33:33 Right. Sep 18 12:33:35 Okay. Sep 18 12:35:14 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... Sep 18 12:35:54 The Servo Headers are not turning on when using GPIO80 or GPIO54. Sep 18 12:36:15 Is there a particular GPIO pin that handles the servo headers? Sep 18 12:37:08 your words are an incoherent jumble of completely unrelated things Sep 18 12:37:25 Okay. Sep 18 12:38:04 Fine. No issue. I tried to understand something new and got turned down. No issue here. Sep 18 12:38:07 Blah! Sep 18 12:39:36 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 Sep 18 12:40:18 Okay. Sorry. I just got what happened. I typed P9 instead of P8. Sorry. Sep 18 12:40:49 And yes. GPIO80 handles the SERVO_EN signal that is supposed to turn on the 6v reg. Sep 18 12:42:56 Okay so... Sep 18 12:42:57 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) Sep 18 12:43:21 Where? What line if you are using github or vim? Sep 18 12:43:30 I see P8_16. Sep 18 12:43:31 Only. Sep 18 12:43:53 is the search function broken in your browser / text editor? Sep 18 12:43:58 No Sir. Sep 18 12:44:03 I will go and look. Sep 18 12:44:08 then search for P8_15 and you will find it Sep 18 12:44:35 So, P8_15. Okay. Please hold or have tea or whatever. Sheesh. Let me go and check. Sep 18 12:45:08 it has a "pinmux-helper", which is what allows it to be configured using config-pin Sep 18 12:46:54 (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) Sep 18 12:47:08 Oh yea. I saw that. Sep 18 12:47:11 I forgot. Sep 18 12:47:43 I am up and running now for some reason. I found a typo too (in my source of course). Sep 18 12:48:17 Sheesh. Anyway...thank you as usual. I feel like I am being mad or something. I need to breathe. Sep 18 14:22:54 Dang it! Sep 18 14:22:59 break time! Sep 18 17:45:08 what is mcasp0? Sep 18 17:54:48 mcasp = multi-channel audio serial port Sep 18 17:55:38 mcasp0 specifically is used to transmit audio to the hdmi framer, if hdmi audio is enabled Sep 18 17:56:21 if hdmi audio is not used it may be used e.g. to interface with external audio codecs Sep 18 17:58:28 ok. and tda19988@70? Sep 18 17:58:35 that's the hdmi framer Sep 18 17:58:46 thank you Sep 18 18:00:51 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 Sep 18 18:01:24 I must come from something I've added/removed on top of am335x-boneblack.dts, but I have no clue what Sep 18 18:02:01 maybe there's a barebox irc channel where you can get help Sep 18 18:02:13 I don't know anything about it Sep 18 18:03:13 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 Sep 18 18:03:24 like, I'd expect most customizations you'd do to your dts to be completely irrelevant to a bootloader Sep 18 18:03:38 I do too Sep 18 18:04:06 so maybe a better question is: what information does barebox extract from the DT to begin with? Sep 18 18:05:36 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 Sep 18 18:07:20 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 ... Sep 18 18:07:26 ...with dt Sep 18 18:08:20 why are you using your custom dts in barebox anyway? is there any benefit to that? Sep 18 18:08:49 it helps a lot already! Gives me clues. Sep 18 18:09:55 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) Sep 18 18:10:23 does barebox have a driver for tilcdc ? Sep 18 18:10:53 and it's also interesting (I love barebox) Sep 18 18:10:55 let me see Sep 18 18:11:16 zmatt: yes it does Sep 18 18:12:28 you sure? "We don't have a framebuffer driver for am335x" -- email on barebox mailing list dated 2020-08-12 Sep 18 18:13:39 I'm not seeing any useful google results for barebox + tilcdc Sep 18 18:13:45 besides that email Sep 18 18:15:31 nah there's no lcdc driver in https://git.pengutronix.de/cgit/barebox/tree/drivers/video Sep 18 18:17:29 ho indeed it doesn't... the occurences I found come from the upstream kernel device trees imported into barebox... Sep 18 18:18:02 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 Sep 18 18:19:25 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 Sep 18 18:20:17 (which honestly is a job that shouldn't even require 2-stage loading like u-boot and barebox use) Sep 18 18:22:14 (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) Sep 18 18:23:46 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. Sep 18 18:25:24 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 Sep 18 18:25:59 (like memory timings) Sep 18 18:27:36 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.) Sep 18 18:29:06 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. Sep 18 18:34:45 fixing kexec seems like a more worthwhile endeavour then Sep 18 20:27:29 That is it. Who did it? Who made the blue fly? Sep 18 20:29:57 Not naming any names. GenTooMan. Sep 18 20:30:23 Sir, was it you? Sep 18 20:30:36 Did you make the BBBlue fly? Sep 18 20:52:43 Come on, spill the beans. Who did it? Who knows? Sep 18 20:54:42 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! Sep 18 20:56:00 Boss to begger in three minutes flat. Dudes, ladies, please. I beg of flight. Sep 19 01:53:25 Heh? Sep 19 01:54:00 No one? Not a soul, heh. Sep 19 02:01:50 Fine...off to keep trying. **** ENDING LOGGING AT Sun Sep 19 02:59:56 2021