Debian login problem after loading PRUCookbook

Ubuntu or Debian is the best way to go on the host. Pretty sure the others running Linux will work too.

@foxsquirrel ,

Seth here. I am using Debian on the host and target and cannot connect via ssh in any format, via the debug header, and/or in any other method.

I will try the ideas you gave me so far, i.e. localhost.

Seth

P.S. Please do not waste your time w/ me. I am a lost cause looking for electronical enjoyment. I will build!

@foxsquirrel ,

What are you doing w/ your BBBs these days? I am looking to make LibGPIOd-dev work well enough to create a bootable image w/ the Relay Cape that gets commands via the am335x and GPIOs.

Seth

P.S. It worked? Well, it used to work. I think I botched the system somehow and now things are getting eerie.

I will order a BBBW and get back with you on this.

Are you able to get the BBBW on a monitor and keyboard?

If so
Target board

$ ip route

That will give the correct IP to use.

on the host

$ssh <user>@192.168.x.x

post what you get.

@foxsquirrel ,

The board boots. Debian Linux can see the board via impromptu posts on the dev. desktop/host.

On the target, for whatever reason, my host is not allowing me to get to the point where I can ip route or ip a the target.

Oh! I got what you are saying now. I will try the ip route on my host. I have not tried w/ a Monitor or Keyboard.

Wait for answers…

Seth

I just reload the image if it gets broken, its much easier and faster than trying to track down what happened. That is were git is your best friend.

1 Like

@foxsquirrel ,

I got you. I just flashed this image to the SD Card. It is a d-bus issue I think.

Seth

P.S. Install d-bus? Who knows?

Hello,

So…when I run ip a, I get nothing back but my current config of IP Addresses. When I plug in the BeagleBone, this is how the host notices the SiP BBBW, I get w/ ip a an enx32453425 as output and an enx88854756 as output.

Seth

Another reply here…I can build an image and work w/ it. This is not my issue. I just wanted to try to build from what people already know, i.e. not what they think is neat or fresh/new.

No such thing…

I think repetitive loops are not a thing of the past. People love what works if they could just get to the point of making it work.

Seth

P.S. But… But… But…

Okay. So, off to build again!

Hello everyone. I am the original poster of the question/problem. First I do not know if the PRU Cookbook is causing my login problem on the BBB I just can’t think of anything I did around the time I added the Cookbook and when I saw the login problem. I am aware the HDMI uses some PRU pins but I would think if that were the problem the display would be goofy or not work at all however the display looks good. My problem is a login problem.
To remove the Cookbook and add the latest version I would use apt-get -remove is that correct? And would that restore the HDMI pins? Or would I have to do more to restore the pin configuration?

root@beaglebone:~# cat /etc/dogtag
BeagleBoard.org Debian Buster IoT Image 2020-04-06

Here is the code I ran from the cookbook, it only blinks the user LED every time you run make so I ran it several times to see it blink which it does:

root@beaglebone:/PRUCookbook/docs/02start/code# ls
ai.notes hello2.pru1_0.c hello2.pru1.c hello2.pru2_1.c hello.pru1_1.c setup2.sh
hello2.pru0.c hello2.pru1_1.c hello2.pru2_0.c hello.pru0.c Makefile setup.sh

root@beaglebone:/PRUCookbook/docs/02start/code# source setup.sh
TARGET=hello.pru0

root@beaglebone:/PRUCookbook/docs/02start/code# make
/var/lib/cloud9/common/Makefile:28: MODEL=TI_AM335x_BeagleBone_Black,TARGET=hello.pru0,COMMON=/var/lib/cloud9/common
/var/lib/cloud9/common/Makefile:147: GEN_DIR=/tmp/cloud9-examples,CHIP=am335x,PROC=pru,PRUN=0,PRU_DIR=/sys/class/remoteproc/remoteproc1,EXE=.out

  • Stopping PRU 0
    /bin/sh: 1: echo: echo: I/O error
    Cannot stop 0
    CC hello.pru0.c
    “/var/lib/cloud9/common/prugpio.h”, line 53: warning #1181-D: #warning directive: “Found am335x”
    LD /tmp/cloud9-examples/hello.pru0.o
  • copying firmware file /tmp/cloud9-examples/hello.pru0.out to /lib/firmware/am335x-pru0-fw
    write_init_pins.sh
    writing “none” to “/sys/class/leds/beaglebone:green:usr3/trigger”
  • Starting PRU 0
    MODEL = TI_AM335x_BeagleBone_Black
    PROC = pru
    PRUN = 0
    PRU_DIR = /sys/class/remoteproc/remoteproc1
    rm /tmp/cloud9-examples/hello.pru0.o

root@beaglebone:/PRUCookbook/docs/02start/code# make
/var/lib/cloud9/common/Makefile:28: MODEL=TI_AM335x_BeagleBone_Black,TARGET=hello.pru0,COMMON=/var/lib/cloud9/common
/var/lib/cloud9/common/Makefile:147: GEN_DIR=/tmp/cloud9-examples,CHIP=am335x,PROC=pru,PRUN=0,PRU_DIR=/sys/class/remoteproc/remoteproc1,EXE=.out

  • Stopping PRU 0
  • copying firmware file /tmp/cloud9-examples/hello.pru0.out to /lib/firmware/am335x-pru0-fw
    write_init_pins.sh
    writing “none” to “/sys/class/leds/beaglebone:green:usr3/trigger”
  • Starting PRU 0
    MODEL = TI_AM335x_BeagleBone_Black
    PROC = pru
    PRUN = 0
    PRU_DIR = /sys/class/remoteproc/remoteproc1

And:
root@beaglebone:~# journalctl -xe
Dec 09 10:06:32 beaglebone dnsmasq-dhcp[1138]: DHCPACK(usb0) 192.168.7.1 b4:10:7b:04:c3:98 z1
Dec 09 10:06:34 beaglebone dnsmasq-dhcp[1138]: DHCPREQUEST(usb1) 192.168.6.1 b4:10:7b:04:c3:9a
Dec 09 10:06:34 beaglebone dnsmasq-dhcp[1138]: DHCPACK(usb1) 192.168.6.1 b4:10:7b:04:c3:9a z1
Dec 09 10:07:21 beaglebone dnsmasq-dhcp[1138]: DHCPREQUEST(usb0) 192.168.7.1 b4:10:7b:04:c3:98
Dec 09 10:07:21 beaglebone dnsmasq-dhcp[1138]: DHCPACK(usb0) 192.168.7.1 b4:10:7b:04:c3:98 z1
Dec 09 10:07:27 beaglebone dnsmasq-dhcp[1138]: DHCPREQUEST(usb1) 192.168.6.1 b4:10:7b:04:c3:9a
Dec 09 10:07:27 beaglebone dnsmasq-dhcp[1138]: DHCPACK(usb1) 192.168.6.1 b4:10:7b:04:c3:9a z1
Dec 09 10:08:08 beaglebone dnsmasq-dhcp[1138]: DHCPREQUEST(usb0) 192.168.7.1 b4:10:7b:04:c3:98
Dec 09 10:08:08 beaglebone dnsmasq-dhcp[1138]: DHCPACK(usb0) 192.168.7.1 b4:10:7b:04:c3:98 z1
Dec 09 10:08:21 beaglebone dnsmasq-dhcp[1138]: DHCPREQUEST(usb1) 192.168.6.1 b4:10:7b:04:c3:9a
Dec 09 10:08:21 beaglebone dnsmasq-dhcp[1138]: DHCPACK(usb1) 192.168.6.1 b4:10:7b:04:c3:9a z1
Dec 09 10:08:56 beaglebone dnsmasq-dhcp[1138]: DHCPREQUEST(usb0) 192.168.7.1 b4:10:7b:04:c3:98
Dec 09 10:08:56 beaglebone dnsmasq-dhcp[1138]: DHCPACK(usb0) 192.168.7.1 b4:10:7b:04:c3:98 z1
Dec 09 10:09:02 beaglebone dnsmasq-dhcp[1138]: DHCPREQUEST(usb1) 192.168.6.1 b4:10:7b:04:c3:9a
Dec 09 10:09:02 beaglebone dnsmasq-dhcp[1138]: DHCPACK(usb1) 192.168.6.1 b4:10:7b:04:c3:9a z1
Dec 09 10:09:49 beaglebone dnsmasq-dhcp[1138]: DHCPREQUEST(usb0) 192.168.7.1 b4:10:7b:04:c3:98
Dec 09 10:09:49 beaglebone dnsmasq-dhcp[1138]: DHCPACK(usb0) 192.168.7.1 b4:10:7b:04:c3:98 z1
Dec 09 10:09:50 beaglebone dnsmasq-dhcp[1138]: DHCPREQUEST(usb1) 192.168.6.1 b4:10:7b:04:c3:9a
Dec 09 10:09:50 beaglebone dnsmasq-dhcp[1138]: DHCPACK(usb1) 192.168.6.1 b4:10:7b:04:c3:9a z1
Dec 09 10:10:31 beaglebone dnsmasq-dhcp[1138]: DHCPREQUEST(usb0) 192.168.7.1 b4:10:7b:04:c3:98
Dec 09 10:10:31 beaglebone dnsmasq-dhcp[1138]: DHCPACK(usb0) 192.168.7.1 b4:10:7b:04:c3:98 z1
Dec 09 10:10:36 beaglebone dnsmasq-dhcp[1138]: DHCPREQUEST(usb1) 192.168.6.1 b4:10:7b:04:c3:9a
Dec 09 10:10:36 beaglebone dnsmasq-dhcp[1138]: DHCPACK(usb1) 192.168.6.1 b4:10:7b:04:c3:9a z1
lines 3004-3026/3026 (END)

Thanks for all your help,
havea Blessed day!
Don

Also remember when I login ssh from my laptop and run startx the display works and Debian GUI is functional.

Have a Blessed day!
Don

1 Like

@DonTrustee ,

Sorry.

Seth

P.S. I will keep NOT posting b/c of random findings from outsourcing. I think I got confused midstream w/ the other fellow/lady posting in this thread. back to my corner... Oops.

@DonTrustee ,

I am turning redundant here. So, w/out further ado here, here!

https://docs.beagleboard.org/latest/books/pru-cookbook/02start/start.html#getting-example-code

W/ my lessons in etiquette and ideas in general, use git from the above link.

@DonTrustee ,

It is not easy to understand nor is it easy to do the work to handle such a task.

The reason I say the before stated sentence are these facts:

  1. If something is in the way, dual used pins at the same time, oddity ensues.
  2. Using the .dts and .dtsi files for a .dtbo may prove useful.
  3. But…if you are running source that calls a specific pin that is already in use, oddity ensues.

1 - 3 are basics, right. So, to get a further grip on these ideas, I say look to your .dts and already loaded .dtbo files.

I asked around about this idea before today and I will keep trying to make others understand the complexity of making this work.

If I have a GPIO, for instance, that I will use but it is already allocated to a specific function in the .dts/.dtbo I am currently using or that is currently loaded, when I call that GPIO in source, odd stuff happens.

I could be kicked out of my current terminal, the board may not boot, or other hilarity may ensue. I know you understand this fact now. Moving on…

cat /etc/dogtag
BeagleBoard.org Debian Buster IoT Image 2020-04-06

This, as it shows, is an older model image of what used to work then in 2020. It is almost three years old or older.

Now, I cannot promise the new images will work w/ the first version or even the current, unstable version (beta) of the PRU Cookbook.

It looks like the setup.sh works. This is good news. I think the updates from beagleboard.org may have stopped for that image and kernel combination. I am not sure about this fact but if things are not updated, then this could also cause error(s).

a. Have you tried to use config-pin?

b. Have you figured out what pins are already allocated before running the PRU source?

c. And… Cloud 9 is not going to get updated any longer from what I understand.

d. Cloud 9 is owned by AWS now and I do not know who is still developing the older model of the Cloud IDE.

Seth

P.S. It would be cool or nifty if the source would just work so we all could move on. Mostly, things transpire, from what I can tell, in a method and a 1 ~ infinity mechanism with building.

The kernel changes, BSPs change, and the way things are done basically changes too (every so often).

Speaking of the kernel, is it on 6.2.x already? Yikes. Things are movin!

Now, if it was me…

  1. I would change images b/c of the lack of updates/upgrades but that is me. Not everyone wants the latest/greatest.
  2. I would use the config-pin utility to test your pins in use.
    a. config-pin -l p9.24 or whatever pin you are going to be using.
    b. config-pin -q p9.24 will show you how it is currently, probably default which is GPIO, allocated.
  3. Now, use config-pin again or a .dts file to make sure your pins are muxed.
    a. config-pin p9.24 pruout and/or config-pin p9.24 pruin
To remove the Cookbook and add the latest version I would use apt-get -remove is that correct?
And would that restore the HDMI pins?
Or would I have to do more to restore the pin configuration?

rm -rf YourFile or YourDirectory if you used git or you can use git commands to remove everything.

I was unaware of someone using apt to install the PRU Cookbook.

Seth

P.S. I will research this idea in time. I did NOT think someone could use apt to handle installing the PRU Cookbook.


#include <stdint.h>
#include <pru_cfg.h>
#include "resource_table_empty.h"
#include "prugpio.h"

volatile register unsigned int __R30;
volatile register unsigned int __R31;

void main(void) {
	int i;

	uint32_t *gpio1 = (uint32_t *)GPIO1;
	
	/* Clear SYSCFG[STANDBY_INIT] to enable OCP master port */
	CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;

	for(i=0; i<10; i++) {
		gpio1[GPIO_SETDATAOUT]   = USR3;	// The the USR3 LED on

		__delay_cycles(500000000/5);    	// Wait 1/2 second

		gpio1[GPIO_CLEARDATAOUT] = USR3;

		__delay_cycles(500000000/5); 

	}
	__halt();
}

// Turns off triggers
#pragma DATA_SECTION(init_pins, ".init_pins")
#pragma RETAIN(init_pins)
const char init_pins[] =  
	"/sys/class/leds/beaglebone:green:usr3/trigger\0none\0" \
	"\0\0";

Is this the source you are referring to currently?

I have not looked in the Makefile yet. Off to research.

I will test it, too. Yep, so.

include /var/lib/cloud9/common/Makefile

That above line is the Makefile. So, whatever is in that file needs to be altered. On my machine, the BBB SBC, I no longer have /var/lib/cloud9/, i.e. as it has been obsoleted since some point.

I will research more in time.

The issue so far is this idea: I have no clue what is in /var/lib/cloud9/common/Makefile and thus I cannot manage it. If you post it, fine. I can work from that point forward.

Update!

Okay so, the PRU Cookbook does not make my BBGW SBC unbootable. I installed it via git. I tried a bunch of source but failed since the Makefile is no longer w/ me. So, we can cancel out git clone _________ being the reason.

Also…

  1. 5.10.145-ti-r55 is my kernel
  2. BeagleBoard.org Debian Bullseye Xfce Image 2022-05-01 is my image

Another Update

For some reason, the wireless of my BBGW is faltering the source.sh script in /06io/. So, I cannot move forward. Also…

ti-pru-cgt-installer is no longer installable. Since that is a fact and since the updated item(s) via apt are not installing, well only one of the two, I may not be able to test at all.