**** BEGIN LOGGING AT Sun Jan 08 02:59:56 2023 Jan 08 07:29:17 Hi,  Actually u-boot and kernel source code are available. But primary boot loader i.e. firmware source code is not identifiable ? Can anybody help me by sharing the source of same ? For complete boot analysis , it is highly desirable. Jan 09 01:40:08 Is it possible to use P8_7 and P8_9 as regular gpio pins?  If so, to make this happen do I need to create a custom device tree overlay file? Jan 09 01:54:36 Hello Guest4494: Have you tried config-pin yet? Jan 09 01:55:04 I just plugged in. i will attempt config-pin. Jan 09 01:55:55 Hi set_, no I haven't but I'm not using the stock debian.  I'm building my own buildroot image, so I don't have config-pin. Jan 09 01:56:08 Oh. Jan 09 01:56:39 Um, I just tried via config-pin on the BBB. p8.7/9 does not configure correctly on my board. Hmm. I wonder what is going on? Jan 09 01:57:44 Though the pinout diagram I have for the BBB shows 7 & 9 as gpios, I think their default mode is something else (timer?). Jan 09 01:58:05 Dang it. I have a Cape on my board. Let me test another board. Jan 09 01:59:06 Hmm. Maybe. That is one of the ways someone can use that pin. Jan 09 02:00:39 i.e. for p8.7, timer is one use of that pin. Jan 09 02:04:02 https://github.com/mvduin/overlay-utils/blob/master/gpio-demo.dtsi, which I think zmatt gave to me a few months ago, indicates that cape-universal has some sort of conflict on P8_7/8/9/10 Jan 09 02:04:54 Oh. Jan 09 02:05:20 Hmm. Maybe so. @zmatt will probably need to direct you then if you are using his ideas and use cases. Jan 09 02:05:43 W/ Buildroot, have you installed Cape-Universal somehow? Jan 09 02:06:51 If so, okay. If not, okay. It is probably more complicated than just writing an overlay for those specific pins. Jan 09 02:07:14 I do not know what beagleboard.org peoples have done for handling those pins. I will go and search. Jan 09 02:07:33 No, but it does use am335x-boneblack.dts as part of its default for the DTB it builds, so most of the things one gets with Debian on BBB are the same. Jan 09 02:08:22 I meant, no, I don't have cape-universal in my buildroot image. Jan 09 02:08:34 Oh. I see in am335x-bone-common-universal.dtsi, there are calls to the node. Jan 09 02:08:57 Currently, I cannot help b/c I have no clue as to what they are doing right now w/ those pins. Jan 09 02:09:49 Oh! Do you have a uEnv.txt file or are you just building w/out it? Jan 09 02:10:30 That's interesting, because I've got the #include am335xx-bone-common.dtsi commented out.  But that's not the same as am33x-bone.common-universal.dtsi. Jan 09 02:11:11 Buildroot does create a uEnv.txt but I'm not using it. Jan 09 02:11:48 Oh. Let me go and search the am335x-bone-common.dtsi file. And okay about the uEnv.txt file. Jan 09 02:12:42 Perhaps I should.  Currently, I just create a fat partition, put MLO, kernel, DTB, rootfs, and u-boot.img file on it, and create a extlinux/extlinux.conf file there, too. Jan 09 02:14:18 Nice. Jan 09 02:14:31 I used to do more than not but that was a while back. Jan 09 02:15:01 I was unaware of uEnv.txt being built. That makes me what to build again. Jan 09 02:16:55 I also saw there is a am335x-bone-common-univ.dtsi that calls am335x-bone-pins. I think w/ *** bone *** in /dev/, people now want specific things to work for now. I am not quite sure, i.e. as I am not a full-fledged member or anything like that idea. Jan 09 02:17:50 The am335x-bone-pins file is a .h file. This file may provide some support. Jan 09 02:22:35 I tried using https://kilobaser.com/beaglebone-black-device-tree-overlay-generator/ which will generate a dts file for a pin to be gpio or whatever one wants.  I generated a dts file for 7 & 9, put them into my custom dts file, and buildroot seems to successfully build a new dtb file from it.  But when I tried to boot, the kernel, rootfs, and dtb Jan 09 02:22:35 are all loaded, but when the kernel then tries to execute, it crashes after several seconds, triggering a reboot. Jan 09 02:23:08 That web page is fairly old I think.  May not be accurate anymore (?). Jan 09 02:23:54 Odd. I tried it a long time ago. I never got it to work well enough b/c of what goes on currently w/ the beagleboard.org persons and their community. Jan 09 02:24:27 I think the BONE ideas are ways to simplify the execution of specific source w/ said peripherals. Jan 09 02:24:37 I'm not familiar enough with dts files to know if what it produces is currently valid. Jan 09 02:25:06 Me neither...really. It is not easy, i.e. esp. w/ so many files out there currently. Jan 09 02:25:49 Tracking down the current file and its directives gets time consuming. It works in the end but one would have to have a good memory and lots of notes. Jan 09 02:26:29 Guest4494: Try the USB to TTL converter cable for seeing what is going on in your kernel build when it breaks... Jan 09 02:26:36 This is a good idea too. Jan 09 02:27:12 Do you mean for a serial console? Jan 09 02:27:19 There are some smart people who enjoy assisting in kernel panic or kernel _____ ideas. Jan 09 02:27:41 Sort of...but it is a way to view your u-boot and kernel starting instantiation. Jan 09 02:28:13 Those, UART0, headers on the BBB for exactly that... Jan 09 02:29:31 I've got a usb-to-ftdi cable plugged into header (6-pin).  So, I see the u-boot messages, I can see the kernel et al being loaded into memory, and then the kernel being started.  But there's no dump when it fails. Jan 09 02:30:14 Right. Keep the terminal open. C & P it to pastebin.com or another paste service. Jan 09 02:31:02 Someone may provide some support. I do not know everything you are going through right now but it may, the output, provide some ideas to me so I can further assist. Jan 09 02:31:42 Also... Jan 09 02:32:04 Guest4494: Try line by line searching to learn about what exactly is taking place in your output. Jan 09 02:32:16 That is an awesome way to learn more about what exactly is taking place. Jan 09 02:34:03 brb Jan 09 02:43:04 Guest4494: Are you willing to try to give the output of the boot log? Jan 09 02:44:05 I can, but there's not really any output once the kernel starts executing.  Hang on, I'll pastebin it... Jan 09 02:45:47 Okay... Jan 09 02:46:07 https://pastebin.com/xXx9vq0B Jan 09 02:46:41 It will sit for about 20 seconds at that last line, and then it will just start over again.  So, no real output indicating what is wrong. Jan 09 02:48:23 This file.../rootfs.cpio.uboot is labeled like this idea or is it labeled like /rootfs.cpio ? Jan 09 02:49:08 or does it even matter? Have you tried to stop u-boot to prompt specific commands? Jan 09 02:50:27 Guest4494: "cape-universal has some sort of conflict on P8_7/8/9/10" ... cape-universal conflicts with literally everything you do in a device-tree that uses pins, since it makes all unused pins runtime-configurable. that presumably doesn't matter if you're using buildroot since you don't have cape-universal Jan 09 02:51:35 there's nothing special about P8.07-10, they're normal pins Jan 09 02:52:36 Oh, hi zmatt.  Ok, that would seem to simplify things a bit. Jan 09 02:53:29 Here's one of the sections I added to my dts file to try to make P8_7 act as a regular gpio: https://pastebin.com/Kf23mVbW Jan 09 02:54:42 Guest4494: this is source code for an overlay, I hope you didn't just paste that into a main device tree because that would be pretty bad Jan 09 02:54:43 As mentioned above, buildroot builds it, but when I try to boot with it and the new kernel BR generates with it, it hangs for about 20 seconds when the kernel begins executing, but then just restarts Jan 09 02:55:39 I did.  I'm not good enough with dts files to be know how they would be different. Jan 09 02:56:16 I did suspect that might be part of the problem, but was uncertain (and thus why I'm here. ;-)) Jan 09 02:57:19 this is what the equivapent snippet in normal device-tree syntax would be: https://pastebin.com/6em6mpej Jan 09 02:57:37 this still won't work for you, but at least it shouldn't completely break your DT Jan 09 02:58:11 bone-pinmux-helper is an out-of-tree driver that's presumably not part of your kernel. Jan 09 02:58:43 however, what this snippet does isn't really needed anyway since these pins (indeed almost all pins) default to gpio mode Jan 09 02:59:33 Including P8_7 and P_9? **** ENDING LOGGING AT Mon Jan 09 02:59:56 2023