[beagleboard] Invalid module format

[Paul Beam]

I'm trying to build a new driver for a Realtek 8821C for the PocketBeagle, 
and although I have managed to cross-compile the module, it fails to load 
with an "invalid format" error, which I think means it thinks I compiled 
with a different kernel version.  

My PB is still running "4.14-ti", and I downloaded Robert's "rt-4.14" 
branch onto my build machine thinking that "4.14" should be close enough.  
Is my problem the "ti" branch vs the "rt" branch?  I guess I can build it 
on the PB if I have to, but it is much faster to build on my desktop and, 
theoretically, easier to keep track of.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/7ec9b193-7c50-4ccb-8fd1-f9d3170d61fcn%40googlegroups.com.

Re: [beagleboard] Invalid module format

[Paul Beam]

Thanks, Robert.  That would work if I were compiling on the PB, but 
cross-compiling on my Debian VM was different.  There may be an easier way, 
but what I did was follow this: http://phwl.org/2021/building-bbg-kernel/  
 to checkout the exact kernel I have on my PB, compile it, and then point 
my driver Makefile to this directory.  This at least appears to work.

On Friday, June 4, 2021 at 5:22:23 PM UTC-4 RobertCNelson wrote:

> On Fri, Jun 4, 2021 at 4:20 PM Paul Beam  wrote:
> >
> > I'm trying to build a new driver for a Realtek 8821C for the 
> PocketBeagle, and although I have managed to cross-compile the module, it 
> fails to load with an "invalid format" error, which I think means it thinks 
> I compiled with a different kernel version.
> >
> > My PB is still running "4.14-ti", and I downloaded Robert's "rt-4.14" 
> branch onto my build machine thinking that "4.14" should be close enough. 
> Is my problem the "ti" branch vs the "rt" branch? I guess I can build it on 
> the PB if I have to, but it is much faster to build on my desktop and, 
> theoretically, easier to keep track of.
>
> sudo apt install linux-headers-`uname -r`
>
> Regards,
>
> -- 
> Robert Nelson
> https://rcn-ee.com/
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/466ada0a-99cc-48e3-b817-ca388e000918n%40googlegroups.com.

[beagleboard] What changed with config-pin in latest Debian?

[Paul Beam]

I'm using the PocketBeagle, and just installed the latest Debian image.  
Now, my script that sets I/O pins does not work.  I have already worked 
through the name change where, for example, P1_6 is now P1_06, but other 
config options such as in, out, hi, and low do not work.  Nor does 
config-pin display the status of the pin.

For example:

debian@beaglebone:~$ config-pin -q P2_33
Current mode for P2_33 is: gpio

 

debian@beaglebone:~$ config-pin P2_33 lo
ERROR: write() to /sys/devices/platform/ocp/ocp:P2_33_pinmux/state failed, 
No such device


Contrary to the error, ocp:P2_33_pinmux/state does exist, but it must not 
like the value.  I find a lot of things that used to work no longer work.  
What has changed, and what do I do about it?

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/ac03646f-a7e1-48f4-872d-2f4e2adc4470%40googlegroups.com.

Re: [beagleboard] Re: PocketBeagle Boot Time

[Paul Beam]

Thanks.  I had to go back to 4.14 since the newest distro broke some things 
which is taking me a while to figure out.  I did however, eliminate 
bonescript and I'm ~ 40 seconds which is almost tolerable.  

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/36598735-c70f-4501-ad28-935b0d087606%40googlegroups.com.

[beagleboard] PocketBeagle Power Problems

[Paul Beam]

I have been trying to work through some PocketBeagle power weirdness.  I 
have an external battery backed supply which outputs 5V.  If I route power 
into Vin (P1.1) I run into problems with glitches from my power supply when 
I plug or unplug a USB charger.  The worst problem seems to be that VBAT 
gets a charge on it so that PocketBeagble won't start until I temporarily 
short VBAT to ground.  The other problem I get is sometimes the 
PocketBeagle will reboot.  My PS may not be perfect, but I have not been 
able to find on the scope anything that explains this.

So, I moved my power input over to VBAT.  I no longer have rebooting issues 
nor any problems unplugging or plugging the charger.  But, all the 3.3V and 
Vout pins are still powered when the PocketBeagle is "Off."  VIN-USB (P1.7) 
seems to turn on and off with the PB power LED.  Vout (P1.14) stays at 5V 
regardless of whether the PB is on or off, which means my connected 
circuitry stays on and drains power when things should be off.

>From what I can tell, VIN seems to have a different brownout threshold than 
VBAT, but I have no explanation for VOUT being on continuously when VBAT is 
applied.  

Thoughts?

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/f4d25ff7-0aa1-4312-9133-bbd680cd6405%40googlegroups.com.

Re: [beagleboard] PocketBeagle Power Problems

[Paul Beam]

Very recent PB’s.  My power supply is a combo li ion battery and TI charge
boost converter which does glitch when switching from usb input to
battery.  The bigger problem is when it won’t power on till I bleed the
voltage from Vbat.  I have not seen this glitch mentioned anywhere.  I have
found it possible to get a voltage on an unconnected VBat and the PB will
not start.

On Tue, May 19, 2020 at 8:07 PM Stuart Longland 
wrote:

> On 20/5/20 10:00 am, Pablo Rodriguez wrote:
> > Vin on same pocket Beagle is bugged, havent seen any official statement
> but
> > all My pb( like 6) have the same random reset when powered by Vin. Not
> when
> > powered from vusb with the same power supply.
> > Good luck
>
> Are these recently purchased boards that are suffering glitches?  We've
> got a fleet of 6 which have been running fine from Vin.  Maybe some bulk
> capacitance might help?
> --
> Stuart Longland (aka Redhatter, VK4MSL)
>
> I haven't lost my mind...
>   ...it's backed up on a tape somewhere.
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/7306312b-a4d9-d50c-18f0-1c011f67d6ae%40longlandclan.id.au
> .
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAA_M65PsH8g2vyvKTkh57pMic%3DrpucXdUZLW_bbkw8wd8CTo8g%40mail.gmail.com.

Re: [beagleboard] PocketBeagle Power Problems

[Paul Beam]

There is something wonky with VIN_AC.  If you physically remove power, then 
things seem fine, but using PB for off and on can lead to a state where it 
won't turn on.  USB1_VIN works better for some reason.

Does anyone know how to read/change PMIC registers after Linux has loaded?  
i2ctools does not work since the kernel has the device.  

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/f9cc34e1-4b35-4734-a065-022c13bc1a09%40googlegroups.com.

[beagleboard] am335x-pru0-fw

[Paul Beam]

Can someone tell me where am335x-pru0-fw and am335x-pru1-fw come from or 
when they get loaded?  I'm trying to load my own firmware into the pru's on 
boot via systemd, and it's not working.  I can do it manually, but on boot 
it seems to load this default firmware from somewhere.  Or, is it better 
that I rename my pru firmware to these names and put it in some magical 
place so it is automatically loaded?

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/ec9d549e-8654-4239-9852-c38a99a1bfe9o%40googlegroups.com.

Re: [beagleboard] am335x-pru0-fw

[Paul Beam]

Robert,

My firmware for the PRUs is in /lib/firmware, but it has different names.  
It is unclear to me whether a mechanism exists in the PocketBeagle for it 
to automatically load firmware into the PRUs or whether I need to create my 
own service.  I have been, until today, loading them manually.  If my 
systemd service waits until generic-board-setup is complete, then it loads 
my firmware.  I can, of course, rename my firmware files.  When I do a 
search for am335x-pru0-fw I don't find anything.  To reduce boot time, I 
have deleted the initrd.  




On Monday, July 27, 2020 at 6:06:39 PM UTC-4, RobertCNelson wrote:
>
> On Mon, Jul 27, 2020 at 4:57 PM Paul Beam > 
> wrote: 
> > 
> > Can someone tell me where am335x-pru0-fw and am335x-pru1-fw come from or 
> when they get loaded?  I'm trying to load my own firmware into the pru's on 
> boot via systemd, and it's not working.  I can do it manually, but on boot 
> it seems to load this default firmware from somewhere.  Or, is it better 
> that I rename my pru firmware to these names and put it in some magical 
> place so it is automatically loaded? 
>
> I assume you have it copied under /lib/firmware/ ? 
>
> Also just run: 
>
> sudo /opt/scripts/tools/developers/update_initrd.sh 
>
> This will update the initramfs so your versions are included.. 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/defa14a0-b9ff-4720-a931-9e75fc5122ddo%40googlegroups.com.

[beagleboard] "Off" is not entirely off on PocketBeagle

[Paul Beam]

I have a little power problem with the PocketBeagle.  It seems that when 
you use PB to shut the system down, it is not entirely off like when you 
apply power but before you push PB.  All the LEDs on the PB are off, but 
Vout appears to still have voltage, and a number of I/O pins (like the one 
I use to externally show power is on) retain some voltage.  I'm not really 
sure how PB actually works.  What does the OS do vs firmware in the power 
control IC?  Is there a way to programmatically force the PB into the same 
state it is in when power is applied but before PB is pressed?

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/33d39851-047e-47e9-ad2b-0b327ae6503do%40googlegroups.com.

[beagleboard] Re: "Off" is not entirely off on PocketBeagle

[Paul Beam]

For posterity, apparently because of an external hardware problem, the 
shutdown script was not completing before turning the processor off.  I 
received no messages on the console, and I assumed when the BB Power LED 
was off everything was complete.  So, the LDOs and everything do turn off 
if the shutdown happens as it should.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/e86f5e4e-d307-4339-a439-eba65d2e8238o%40googlegroups.com.

Re: [beagleboard] PocketBeagle Power Problems

[Paul Beam]

I have fought this same problem, thought it was resolved, and found it 
again.  I think the authoritative answer is in this TI app note: 
https://www.ti.com/lit/an/slva901/slva901.pdf?ts=1597613555964&ref_url=https%253A%252F%252Fwww.google.com%252F

Cutting to the chase, either ground the BAT terminal with  1K-ish resistor 
or power your product exclusively through the BAT terminal.  In my case, I 
tried to use both Vin and VUSB with an external battery and charger, 
plugging and unplugging the charger would cause a brief brownout condition 
that would lock up the PMIC and require the power to be removed before you 
could turn it on again.  According to the TI doc, the PMIC was really 
designed for battery as the primary power source, so not having a battery 
plugged in leads to some imperfect results -- like not being able to turn 
the stupid thing on.  I'm now just using BAT and things appear to work.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/ea03ffab-1465-4961-a07a-7706911fbb2do%40googlegroups.com.

[beagleboard] SD duplication yields slow startup

[Paul Beam]

I have a PocketBeagle image I want to reproduce and put on other units.  I 
had the boot time down to about 35 seconds.  I used Win32DiskImager to make 
an image and then put it on another SD card.  When I put this in a new PB, 
the boot time is closer to 2 minutes!  It seems this may not the the right 
way to do things.  Do I need to run some initialization script on each 
unit, or is there a better way to duplicate things once you have them the 
way you want them?

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/82eeae0d-7d7e-4f1d-b2c8-3b1a47041db8o%40googlegroups.com.

Re: [beagleboard] SD duplication yields slow startup

[Paul Beam]

>
> It stays there.  Here is the latest:

 

 multi-user.target @1min 55.789s
└─ssh.service @1min 53.646s +2.132s
  └─network.target @1min 53.542s
└─networking.service @3.173s +1min 50.353s
  └─local-fs.target @3.093s
└─local-fs-pre.target @3.086s
  └─keyboard-setup.service @990ms +2.091s
└─system.slice @963ms
  └─-.slice @874ms
debian@beaglebone:/opt/scripts$ 


Since you are the master of all the startup scripts, your response implies 
duplicating the image is legitimate.  FYI, I have added a Realtek USB wifi 
adapter which is running hostapd, and I have disabled USB networking in 
/etc/default/bb-boot.  Sounds like I need to go get the original and swap 
things back and forth.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/c87ab995-6684-4248-8b6a-922242f41148o%40googlegroups.com.

Re: [beagleboard] SD duplication yields slow startup

[Paul Beam]

Also:

systemd-analyze: unrecognized option '--blame'
debian@beaglebone:/opt/scripts$ systemd-analyze blame
1min 50.353s networking.service
1min 49.479s generic-board-startup.service
 12.323s dev-mmcblk0p1.device
  2.679s systemd-udev-trigger.service
  2.149s hostapd.service
  2.132s ssh.service
  2.091s keyboard-setup.service
  1.537s udhcpd.service
  1.365s ti-ipc-dra7xx.service

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/73489a3b-7c0d-4896-9511-970fdd0f33dfo%40googlegroups.com.

[beagleboard] Re: SD duplication yields slow startup

[Paul Beam]

>
> Thanks, but I'm pretty sure the speed of the SD itself is not the issue.  
> It may have something to do with my networking.   The original image was 
> connected to my wifi network, and this one is not connected.  Looking at 
> the logs I can find I see this:

 

Aug 10 14:51:56 beaglebone sh[182]: am335x_evm: g_multi Created
Aug 10 14:51:56 beaglebone sh[182]: am335x_evm: Starting usb0 network
Aug 10 14:51:57 beaglebone sh[182]: am335x_evm: Starting usb1 network
Aug 10 14:51:58 beaglebone sh[182]: Stopping udhcpd (via systemctl): 
udhcpd.serv
Aug 10 14:51:58 beaglebone sh[182]: am335x_evm: dnsmasq: setting up for 
usb0/usb
Aug 10 14:53:46 beaglebone sh[182]: am335x_evm: LOG: dnsmasq is disabled in 
this
Aug 10 14:53:46 beaglebone sh[182]: /bin/chmod: changing permissions of 
'/sys/ke



It seems that setting dnsmasq is taking a long time (51:58 to 53:46) but I 
am unaware if there is anything else going on in between.   

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/2b66dcb8-ae80-48e2-aa53-060c4ec436e6o%40googlegroups.com.

[beagleboard] Re: SD duplication yields slow startup

[Paul Beam]

If I use connman to connect to wifi then boot is 37 seconds, so I need to 
figure out how to not wait for a wifi connection and dhcp address.  So 
imaging the SD works fine.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/a81c5917-4152-4c1b-9d1a-5c3aa9294271o%40googlegroups.com.

[beagleboard] PocketBeagle on battery input does not shut down completely

[Paul Beam]

I having a problem (again) with PocketBeagle power.  If I power from the 
battery input with 5V, it does not completely shut down all the power 
supplies -- Vout=5V, all the 3.3V outputs are 3.3V, etc.  I have installed 
the latest iot image: bone-debian-10.3-iot-armhf-2020-04-06-4gb.img.xz.  
The console log ends with this:

[  OK  ] Stopped File System Check on Root Device.
[  OK  ] Reached target Shutdown.
[  OK  ] Reached target Final Step.
[  OK  ] Started Power-Off.
[  OK  ] Reached target Power-Off.
[   44.807732] systemd-udevd[673]: Process '/bin/chgrp -R gpio 
'/sys/devices/pla  tform/ocp/ocp:P1_26_pinmux'' terminated by 
signal TERM.
[   44.829181] systemd-udevd[678]: Process '/bin/chmod -R g=u 
'/sys/devices/plat  form/ocp/ocp:P1_12_pinmux'' terminated by 
signal TERM.
[   44.845789] systemd-udevd[671]: Process '/bin/chgrp -R gpio 
'/sys/devices/pla  tform/ocp/ocp:P1_28_pinmux'' terminated by 
signal TERM.
[   44.859571] systemd-udevd[676]: Process '/bin/chmod -R g=u 
'/sys/devices/plat  form/ocp/ocp:P1_29_pinmux'' terminated by 
signal TERM.
[   44.876916] systemd-udevd[681]: Process '/bin/chmod -R g=u 
'/sys/devices/plat  form/ocp/ocp:P1_10_pinmux'' terminated by 
signal TERM.
[   44.889420] systemd-udevd[672]: Process '/bin/chgrp -R gpio 
'/sys/devices/pla  tform/ocp/ocp:P1_20_pinmux'' terminated by 
signal TERM.
[   44.911753] systemd-udevd[678]: Failed to wait for spawned command 
'/bin/chmo  d -R g=u 
'/sys/devices/platform/ocp/ocp:P1_12_pinmux'': Input/output error
[   44.926193] systemd-udevd[671]: Failed to wait for spawned command 
'/bin/chgr  p -R gpio 
'/sys/devices/platform/ocp/ocp:P1_28_pinmux'': Input/output error
[   44.941205] systemd-udevd[673]: Failed to wait for spawned command 
'/bin/chgr  p -R gpio 
'/sys/devices/platform/ocp/ocp:P1_26_pinmux'': Input/output error
[   44.955964] systemd-udevd[676]: Failed to wait for spawned command 
'/bin/chmo  d -R g=u 
'/sys/devices/platform/ocp/ocp:P1_29_pinmux'': Input/output error
[   44.970423] systemd-udevd[681]: Failed to wait for spawned command 
'/bin/chmo  d -R g=u 
'/sys/devices/platform/ocp/ocp:P1_10_pinmux'': Input/output error
[   44.984943] systemd-udevd[672]: Failed to wait for spawned command 
'/bin/chgr  p -R gpio 
'/sys/devices/platform/ocp/ocp:P1_20_pinmux'': Input/output error
[   45.211195] reboot: Power down

I'm using the battery input because it is more tolerant of brownouts, but I 
guess I need to know if this is supported and I can expect to get it to 
shut down properly before spending a lot of time trying.,  I read mixed 
things about whether battery power is supported.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/ea22d3a4-906e-44df-8b13-7b9e75cb54a4n%40googlegroups.com.

[beagleboard] I2C 8 bit address?

[Paul Beam]

Does the Beaglebone support 8 bit I2c addresses?  I'm using a TI bq28z610 
which has I2C address 0xAA, but I cannot access it via i2ctools.  I can 
connect a TI I2C interface to my Windows PC and access the part, and the 
Beaglebone can communicate with other devices on the same bus, I'm pretty 
sure the component is attached properly, but no joy in trying to access 
it.  

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/c6794d4c-cc50-453d-b52d-d61cc548573an%40googlegroups.com.

Re: [beagleboard] Re: I2C 8 bit address?

[Paul Beam]

Thanks.  This part is totally confusing me.  It is supposed to be an
"upgrade" of a part I have been using.  I guess my time is better spent
getting the TI driver to work instead of accessing the registers directly,
which is what I had been doing.

On Thu, Oct 29, 2020 at 3:08 PM Dennis Lee Bieber 
wrote:

> On Thu, 29 Oct 2020 10:23:39 -0700 (PDT), in
> gmane.comp.hardware.beagleboard.user Paul Beam
>  wrote:
>
> >Does the Beaglebone support 8 bit I2c addresses?  I'm using a TI bq28z610
>
> Which Beaglebone?
>
> >which has I2C address 0xAA, but I cannot access it via i2ctools.  I can
>
> Per the BBB TRM (TI SPRUH73P)
> """
> 21.1.1 I2C Features
> The general features of the I2C controller are:
> • Compliant with Philips I2C specification version 2.1
> • Supports standard mode (up to 100K bits/s) and fast mode (up to 400K
> bits/s).
> • Multimaster transmitter/slave receiver mode
> • Multimaster receiver/slave transmitter mode
> • Combined master transmit/receive and receive/transmit modes
> • 7-bit and 10-bit device addressing modes
> • Built-in 32-byte FIFO for buffered read or writes in each module
> • Programmable clock generation
> • Two DMA channels, one interrupt line
> """
>
> BB-AI TRM
> """
> The multimaster HS I2C controllers have the following features:
> • Compliant with Philips I2C specification version 2.1
> • Supports a standard mode (up to 100 kbps) and fast mode (up to 400 kbps)
> • Supports HS mode for transfer up to 3.4 Mbps (only for I2C3, I2C4 and
> I2C5)
> • 7-bit and 10-bit device addressing modes
> • General call
> • Start/Restart/Stop
> • Multimaster transmitter/slave receiver mode
> • Multimaster receiver/slave transmitter mode
> • Combined master transmit/receive and receive/transmit mode
> • Built-in FIFOs (16 bytes) for buffered read or write
> • Module enable/disable capability
> • Programmable multislave channel (responds to four separate addresses)
> """
>
> Per
>
> https://www.totalphase.com/support/articles/200349176-7-bit-8-bit-and-10-bit-I2C-Slave-Addressing#8bit
> 8-bit
> <https://www.totalphase.com/support/articles/200349176-7-bit-8-bit-and-10-bit-I2C-Slave-Addressing#8bit8-bit>
> addressing is not a proper I2C addressing mode.
>
> Your xAA is probably address x55 with read/write bit 0 (write)
>
>
>
> --
> Dennis L Bieber
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/o54mpf9itc7hbrl24v98h17cucfkvmjpn1%404ax.com
> .
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAA_M65N4%3DdHgSbVaOT%3D_Kfd7t_rr2PJNLjK2WNK8Jm6VnUfNnA%40mail.gmail.com.

Re: [beagleboard] Re: I2C 8 bit address?

[Paul Beam]

I want to close this out for posterity.  I'm not a fan of TI's 
documentation, and their using of the 8 bit address (0xAA) is quite 
confusing.  The bq28z610 uses standard 7 bit addressing with address of 
0x55.  The 8th bit is the Read/Write bit, which in my opinion, should not 
be linked in with the address.  The real rub is the bq28z610 by default 
does not work with an sck of 400 KHz, which is the default speed of the 
Beaglebone, so the fix for this is to set a bit in the I2C Configuration 
register to enable 400 KHz operation -- which, of course, you must do via a 
host running at 100 KHz.  

I suspect this will cause someone else frustration, so I post the solution 
here -- or, I might forget what I did in 6 months and need to come back and 
reference the solution!




On Thursday, October 29, 2020 at 3:42:28 PM UTC-4 H. Nikolaus Schaller 
wrote:

> It is much simpler than you think. Look into the bq chip technical 
> reference manual:
>
> the BQ28Z610 uses a series of 2-byte standard I2C commands with a 7-bit 
> device address of 0x55 (8 bits = 0xAA to write and 0xAB to read).
>
> You just have to know that Linux uses 7-bit addresses.
>
> I.e. use i2cget with 0x55.
> Or use i2cdetect to find out on which address the chip is really 
> responding.
>
>
> > Am 29.10.2020 um 20:33 schrieb Paul Beam :
> > 
> > Thanks. This part is totally confusing me. It is supposed to be an 
> "upgrade" of a part I have been using. I guess my time is better spent 
> getting the TI driver to work instead of accessing the registers directly, 
> which is what I had been doing.
> > 
> > On Thu, Oct 29, 2020 at 3:08 PM Dennis Lee Bieber  
> wrote:
> > On Thu, 29 Oct 2020 10:23:39 -0700 (PDT), in
> > gmane.comp.hardware.beagleboard.user Paul Beam
> >  wrote:
> > 
> > >Does the Beaglebone support 8 bit I2c addresses? I'm using a TI 
> bq28z610 
> > 
> > Which Beaglebone?
> > 
> > >which has I2C address 0xAA, but I cannot access it via i2ctools. I can 
> > 
> > Per the BBB TRM (TI SPRUH73P) 
> > """
> > 21.1.1 I2C Features
> > The general features of the I2C controller are:
> > • Compliant with Philips I2C specification version 2.1
> > • Supports standard mode (up to 100K bits/s) and fast mode (up to 400K
> > bits/s).
> > • Multimaster transmitter/slave receiver mode
> > • Multimaster receiver/slave transmitter mode
> > • Combined master transmit/receive and receive/transmit modes
> > • 7-bit and 10-bit device addressing modes
> > • Built-in 32-byte FIFO for buffered read or writes in each module
> > • Programmable clock generation
> > • Two DMA channels, one interrupt line
> > """
> > 
> > BB-AI TRM
> > """
> > The multimaster HS I2C controllers have the following features:
> > • Compliant with Philips I2C specification version 2.1
> > • Supports a standard mode (up to 100 kbps) and fast mode (up to 400 
> kbps)
> > • Supports HS mode for transfer up to 3.4 Mbps (only for I2C3, I2C4 and
> > I2C5)
> > • 7-bit and 10-bit device addressing modes
> > • General call
> > • Start/Restart/Stop
> > • Multimaster transmitter/slave receiver mode
> > • Multimaster receiver/slave transmitter mode
> > • Combined master transmit/receive and receive/transmit mode
> > • Built-in FIFOs (16 bytes) for buffered read or write
> > • Module enable/disable capability
> > • Programmable multislave channel (responds to four separate addresses)
> > """
> > 
>
> vvv here is the important info
>
> > Per
> > 
> https://www.totalphase.com/support/articles/200349176-7-bit-8-bit-and-10-bit-I2C-Slave-Addressing#8bit
> > 8-bit addressing is not a proper I2C addressing mode.
> > 
> > Your xAA is probably address x55 with read/write bit 0 (write)
>
> ^^^ here is the important info
>
> > 
> > 
> > 
> > -- 
> > Dennis L Bieber
> > 
> > -- 
> > For more options, visit http://beagleboard.org/discuss
> > --- 
> > You received this message because you are subscribed to the Google 
> Groups "BeagleBoard" group.
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to beagleboard...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/o54mpf9itc7hbrl24v98h17cucfkvmjpn1%404ax.com
> .
> > 
> > -- 
> > For more options, visit http://beagleboard.org/discuss
> > --- 
> > You received this message because you are subscribed to the Google 
> Groups "BeagleBoard" gr

[beagleboard] PocketBeagle fragile?

[Paul Beam]

I now have a stack of 5 PocketBeagles that I have managed to break one way 
or another over the past year -- usually, doing something stupid like 
probing with a scope and the probe slips and shorts something out.  The 
symptom is all the same -- just a brief flash of the power LED when you 
apply power or push the power button.   Does anyone know what fails?  My 
assumption is the Octavo SOC fails and I should just throw these away,  It 
does seem like there is something fragile.,

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/37803b1d-4747-441f-9a01-dcfc4ea78fe1o%40googlegroups.com.

[beagleboard] Console on USB-C

[Paul Beam]

I have a PocketBeagle sealed inside a headless product, and I find it would 
be convenient to  be able to access the serial console.  I am using USB-C 
to connect to the outside world, but really only using it as a USB-2, so 
that means there are plenty of pins on the connector that are unused.  My 
understanding is the "right" way is to use the SBU lines and a multiplexer, 
but that seems rather complicated for a simple task like this in a 
non-consumer oriented product where complete adherence to the standard is 
most important.  Anyone have an opinion on whether using the SBU and CC 
pins or one of the other high speed pairs is less of an abomination?  

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/99a5b056-29ec-42af-8a9b-939a7e2d35edn%40googlegroups.com.

[beagleboard] Image duplication

[Paul Beam]

Let's say I have tweaked an image for the PocketBeagle and want to 
duplicate it for additional units.  Is it valid to just duplicate my 
revised image, or is there something unique that has to be done for each 
one?  I seem to recall somewhere in a boot script is something that runs 
only the first time, but I currently can't find it and don't remember what 
it does.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/58b8b2dc-d776-4c35-aa4c-a62c1bbba119n%40googlegroups.com.

Re: [beagleboard] Image duplication

[Paul Beam]

That’s basically what I have been doing, but just wanted to make sure there
weren’t some one time operations that were being skipped.

On Tue, Feb 2, 2021 at 7:57 PM Robert Nelson 
wrote:

> On Tue, Feb 2, 2021 at 6:15 PM Paul Beam  wrote:
> >
> > Let's say I have tweaked an image for the PocketBeagle and want to
> duplicate it for additional units.  Is it valid to just duplicate my
> revised image, or is there something unique that has to be done for each
> one?  I seem to recall somewhere in a boot script is something that runs
> only the first time, but I currently can't find it and don't remember what
> it does.
>
> For the PocketBeagle, just dd the microSD to another microSD..
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/l7Clv4mdDFQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/CAOCHtYis9TTDd7DgtpJ18SJ0WyoKiJt7HRRwGnxgtcN9-7ERYQ%40mail.gmail.com
> .
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAA_M65P3iYc2Swu_Od-ceF_PMtTSQhTUxcP5VRk6oZCkN3%2Benw%40mail.gmail.com.

Re: [beagleboard] Re: Image duplication

[Paul Beam]

I could be networked so common host key or MAC address would be less than
optimal.  I will double check that.

On Tue, Feb 2, 2021 at 8:53 PM Tom Stepleton  wrote:

> I've never had trouble duplicating modified images --- it's how I
> distribute the software for my own project.
>
> This said, I suspect (but haven't checked) that all PocketBeagles running
> my images will have the same host key. It's not a big problem for me since
> my application is a standalone appliance for retrocomputing (so you seldom
> ever plug it into anything except the old computer and a power source).
>
> --Tom
> On Wednesday, February 3, 2021 at 12:15:01 AM UTC rpau...@gmail.com wrote:
>
>> Let's say I have tweaked an image for the PocketBeagle and want to
>> duplicate it for additional units.  Is it valid to just duplicate my
>> revised image, or is there something unique that has to be done for each
>> one?  I seem to recall somewhere in a boot script is something that runs
>> only the first time, but I currently can't find it and don't remember what
>> it does.
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/l7Clv4mdDFQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/f5795d8d-75fa-4208-a7d5-398f4ca82343n%40googlegroups.com
> 
> .
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAA_M65PUOXmDhChw_n4R7FM%3Drxb%3DQyPtDGTWd0u4LG7rWoFi4w%40mail.gmail.com.

Re: [beagleboard] Re: Image duplication

[Paul Beam]

Thanks!

On Tue, Feb 2, 2021 at 8:54 PM Robert Nelson 
wrote:

> On Tue, Feb 2, 2021 at 7:53 PM Tom Stepleton  wrote:
> >
> > I've never had trouble duplicating modified images --- it's how I
> distribute the software for my own project.
> >
> > This said, I suspect (but haven't checked) that all PocketBeagles
> running my images will have the same host key. It's not a big problem for
> me since my application is a standalone appliance for retrocomputing (so
> you seldom ever plug it into anything except the old computer and a power
> source).
>
> sudo touch /etc/ssh/ssh.regenerate
>
> and reboot, lots of things will get regenerated..
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/l7Clv4mdDFQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/CAOCHtYgrHFc2R6jUm%3D2vQGDWSZ%3D%2BzOs1Coe5qqmSNpTM%3DMg2Tw%40mail.gmail.com
> .
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAA_M65Mby4q%3DaoRcjduqoHqYjOah1NRi2FEuTLFgjDLoXsxjnQ%40mail.gmail.com.

[beagleboard] am335x_evm.sh

[Paul Beam]

Like others, I have sought to reduce boot time on the PocketBeagle, and I 
have run into a few questions that maybe only Robert can answer.

First of all, this line appears to be wrong:

echo CD > os_desc/b_vendor_code

It gives me this error:

  Feb 17 21:02:36 V2-2 sh[203]: sh: echo: I/O error

I added a bunch of echo statements to narrow down which line was generating 
this, and I'm pretty sure this is it.  It is the section that sets the 
Windows 10 attributes.

The bigger issue is the time this script takes to run.  I'm booting in a 
tad under 40 seconds, and this script is the bulk of it.  I have narrowed 
down the offending section to this line:

systemctl restart dnsmasq || true

The log with my additional comments looks like this:

Feb 17 21:02:38 V2-2 sh[203]: am335x_evm: Starting usb1 network
Feb 17 21:02:38 V2-2 sh[203]: am335x_evm: Setting up dnsmasq
Feb 17 21:02:39 V2-2 sh[203]: Stopping udhcpd (via systemctl): 
udhcpd.service.
Feb 17 21:02:39 V2-2 sh[203]: am335x_evm: dnsmasq: setting up for usb0/usb1
Feb 17 21:02:39 V2-2 sh[203]: am335x_evm: disable_connman_dnsproxy
Feb 17 21:02:39 V2-2 sh[203]: am335x_evm: finished disable_connman_dnsproxy
Feb 17 21:02:39 V2-2 sh[203]: am335x_evm: Restarting dnsmasq
Feb 17 21:03:06 V2-2 sh[203]: am335x_evm: LOG: dnsmasq is disabled in this 
scrip

Now, I have just been going through the script trying to eliminate most of 
the hardware tests since my board is fixed, and deleting what I don't think 
I need.  But there are some things that confuse me.  This script disables 
both udhcpd and dnsmasq.  Why not just not auto-start those services or set 
them to start when this script is complete?  This script also seems to 
touch some things that affect hostapd.

Is there any description on how this script interacts with other systemd 
services?  It clearly does some necessary things as disabling it does not 
improve my boot performance, and the combination clearly gives a brilliant 
"out of the box" experience for someone just starting out.  The 
combination, however, is a bit confusing when it comes to fine tuning.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/2b77b07a-40e7-4405-9ee7-a9cbd738174an%40googlegroups.com.

[beagleboard] PRU I/O max speed

[Paul Beam]

I am, unfortunately, bit-banging SPI with the PRU, and I seem to be running 
into a speed limit < 50 MHz I desire.  I can certainly create a clock that 
fast, but reading data seems to be delayed.  I can see on the logic 
analyzer a "0" clearly being read as a '1" so there is either a delay in my 
clock output or a delay in my input or both.  I would like to think that 
r30 and r31 are tied directly to the outside world, but now I am thinking 
there is something in between that is either clocked or just has 
significant output delays.  Anyone else encountered this?  

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/cad28722-32c5-4d82-ba49-325843aecb87n%40googlegroups.com.

[beagleboard] Re: PRU I/O max speed

[Paul Beam]

With a sample size of one, r31 appears to be 4 instructions behind the 
state of the pin.

On Thursday, February 25, 2021 at 12:26:16 PM UTC-5 Paul Beam wrote:

> I am, unfortunately, bit-banging SPI with the PRU, and I seem to be 
> running into a speed limit < 50 MHz I desire.  I can certainly create a 
> clock that fast, but reading data seems to be delayed.  I can see on the 
> logic analyzer a "0" clearly being read as a '1" so there is either a delay 
> in my clock output or a delay in my input or both.  I would like to think 
> that r30 and r31 are tied directly to the outside world, but now I am 
> thinking there is something in between that is either clocked or just has 
> significant output delays.  Anyone else encountered this?  

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/1781cc2e-8871-4312-bd1e-a312ab32ed3en%40googlegroups.com.

[beagleboard] Re: PocketBeagle not running PRU firmware on startup

[Paul Beam]

I'm trying to do something similar.  It would be better, at least in my 
case, if the PRU could be started at boot.  One thing I noticed in my case 
is the pruss doesn't show up until about 30 seconds into the boot cycle.  
Yours seems to be detected much faster.  Did you change something, or have 
any idea when the kernel decides to discover it?  I have tried to create a 
systemd unit to start them, but I find myself trying to start them before 
sysfs is populated.

On Monday, February 1, 2021 at 7:08:32 PM UTC-5 Tom Stepleton wrote:

> Oops, nevermind --- I see that it can't be done for now. On boot, or in 
> other words during startup or power-on, the Debian Linux kernel on your 
> PocketBeagle or BeagleBone Black can load rproc (aka remoteproc) PRU 
> firmware such as am335x-pru0-fw and am335x-pru1-fw from /lib/firmware, but 
> it will not start the firmware. (Yes, I am keyword-stuffing for maximum 
> searchability.)
>
>
> https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/remoteproc/pru_rproc.c?h=ti-android-linux-4.19.y#n1173
>
> I'll try to identify other means of getting the PRUs started quickly; 
> maybe something that systemd can run at boot time.
>
> Apologies for the distraction,
> --Tom
> On Monday, February 1, 2021 at 4:09:40 AM UTC Tom Stepleton wrote:
>
>> Hi again,
>>
>> I have some mature PRU firmware that I've been loading and starting by 
>> having a program 
>>  
>> manipulate the files
>>   /sys/class/remoteproc/remoteproc[12]/(state|firmware)
>> well after the system has booted.
>>
>> I'd like to speed that process up, so today I've finally copied my 
>> firmware files to /lib/firmware/am335x-pru0-fw and 
>> /lib/firmware/am335x-pru1-fw . Now, I did do
>>   sudo update-initramfs -uk `uname -r` ; sudo reboot
>> like you're supposed to. I can even do
>>   zcat /boot/initrd.img-4.19.50-ti-r20 | cpio -itv
>> and see my firmware files inside the file (albeit as 
>> /usr/lib/firmware/am335x-pru[01]-fw).
>>
>> When the PocketBeagle boots, the firmware is listed correctly within 
>> /sys/class/remoteproc/remoteproc?/firmware files, it's just that the 
>> neighbouring "state" files show that both PRUs are "offline". I can echo 
>> "start" into those files and things work fine, but as I'm trying to 
>> accelerate the time from boot to a running system, it would be really nice 
>> if the firmware could start automatically on boot, as quickly as possible.
>>
>> I'm using this firmware in concert with a new device tree overlay I've 
>> also been developing, which is the subject of another thread 
>> . 
>> If you like, you can view it at
>>
>> http://mg-1.uk:31132/pb-cameo-aphid.dts.txt
>>
>> Perhaps something is missing in there? I based some of its design off of 
>> information in https://groups.google.com/g/beagleboard/c/lS8QlNV8JCc , 
>> which to be fair is now a healthy 3.5 years old...
>>
>> Thanks for any help,
>> --Tom
>>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/6fe30871-0f63-4951-b201-66ac09a684acn%40googlegroups.com.

Re: [beagleboard] Re: PocketBeagle not running PRU firmware on startup

[Paul Beam]

Hmmm.  I have boot time to just under 14 seconds, but the PRUs are not
available until 30!  I have looked with interest at the device tree you
posted, and I may adapt to my application.  Until I trimmed the boot time,
I did not realize the PRUs were slow -- with a 45 second boot time, they
were always available.  Something seems to be going on, but so far it is
invisible.  Thanks.

On Thu, Mar 4, 2021 at 1:39 PM Tom Stepleton  wrote:

> I can't say for sure about why I'm enjoying faster load times now, but I
> have three guesses.
>
> One possibility is that I finally arranged some candles in a ring, sat in
> the middle, slipped into a hypnagogic torpor, and in an echoing
> dissociative void managed to utter yet another arcane device tree overlay
> ,
> this time for my own application. It seems possible to me that when the
> PocketBeagle loads this device tree overlay on boot, some more complicated
> and time-consuming facilities of its default hardware setup are disabled,
> allowing it to attend to other setup tasks faster. This is purely a guess;
> my memories of that time are hazy and indistinct and whenever I try to
> recall them my mouth tastes of metal.
>
> (just kidding it wasn't that bad at all, but even now I'm not really sure
> I got it "right")
>
> The second possibility is that I'm as ruthless as I know how to be about 
> disabling
> services I don't use in my application
> ,
> so that speeds things up.
>
> The third possibility is that on the good advice from someone on the
> Beagle IRC channel, I disable initramfs
> .
> This one really does seem to shave off quite a few seconds from boot time
> for me.
>
> I'm talking about boot time here---I haven't measured time-to-availability
> for the PRUs, but so far it hasn't been a problem and it's definitely much
> faster than it was. Either way, I'd be thrilled to collect yet further tips
> and tricks for making my gizmo start up even sooner! But for setup and
> installation of this magic, I do want people to be able to just run some
> shell scripts like the ones I've linked above --- recompiling the kernel
> would not be an option for me, for example.
>
> --Tom
> On Thursday, March 4, 2021 at 3:49:47 PM UTC rpau...@gmail.com wrote:
>
>> I'm trying to do something similar.  It would be better, at least in my
>> case, if the PRU could be started at boot.  One thing I noticed in my case
>> is the pruss doesn't show up until about 30 seconds into the boot cycle.
>> Yours seems to be detected much faster.  Did you change something, or have
>> any idea when the kernel decides to discover it?  I have tried to create a
>> systemd unit to start them, but I find myself trying to start them before
>> sysfs is populated.
>>
>> On Monday, February 1, 2021 at 7:08:32 PM UTC-5 Tom Stepleton wrote:
>>
>>> Oops, nevermind --- I see that it can't be done for now. On boot, or in
>>> other words during startup or power-on, the Debian Linux kernel on your
>>> PocketBeagle or BeagleBone Black can load rproc (aka remoteproc) PRU
>>> firmware such as am335x-pru0-fw and am335x-pru1-fw from /lib/firmware, but
>>> it will not start the firmware. (Yes, I am keyword-stuffing for maximum
>>> searchability.)
>>>
>>>
>>> https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/remoteproc/pru_rproc.c?h=ti-android-linux-4.19.y#n1173
>>>
>>> I'll try to identify other means of getting the PRUs started quickly;
>>> maybe something that systemd can run at boot time.
>>>
>>> Apologies for the distraction,
>>> --Tom
>>> On Monday, February 1, 2021 at 4:09:40 AM UTC Tom Stepleton wrote:
>>>
 Hi again,

 I have some mature PRU firmware that I've been loading and starting by
 having a program
 
 manipulate the files
   /sys/class/remoteproc/remoteproc[12]/(state|firmware)
 well after the system has booted.

 I'd like to speed that process up, so today I've finally copied my
 firmware files to /lib/firmware/am335x-pru0-fw and
 /lib/firmware/am335x-pru1-fw . Now, I did do
   sudo update-initramfs -uk `uname -r` ; sudo reboot
 like you're supposed to. I can even do
   zcat /boot/initrd.img-4.19.50-ti-r20 | cpio -itv
 and see my firmware files inside the file (albeit as
 /usr/lib/firmware/am335x-pru[01]-fw).

 When the PocketBeagle boots, the firmware is listed correctly within
 /sys/class/remoteproc/remoteproc?/firmware files, it's just that the
 neighbouring "state" files show that both PRUs are "offline". I can echo
 "start" into those files and things work fine, but as I'm trying to
 accelerate the time from boot to a running system, it would be really nice
 if the firmware could start au

Re: [beagleboard] Re: PocketBeagle not running PRU firmware on startup

[Paul Beam]

The big time waster for me appears to be networking.service.  I do not have
totally resolved what to do, so at the moment I start the interface
manually.  There seems to be something wonky with ifup and hotplug -- I
think it is related to "udevadm settle").  I was pretty draconian with the
generic-board-startup, but that only seemed to save a little outside
starting networking.

On Thu, Mar 4, 2021 at 2:04 PM Tom Stepleton  wrote:

> Nice! I'm at 21 seconds until all of my code is up and ready to serve, of
> which 1-3 are probably accounted to getting the ARM-side Python code
> running (so not relevant to booting). Are you doing anything to speed
> things up that hasn't been mentioned so far?
>
> I find that for me, the PRUs are ready to go with firmware loaded well
> before the Python code issues them the "start" command.
>
> --Tom
> On Thursday, March 4, 2021 at 6:53:00 PM UTC rpau...@gmail.com wrote:
>
>> Hmmm.  I have boot time to just under 14 seconds, but the PRUs are not
>> available until 30!  I have looked with interest at the device tree you
>> posted, and I may adapt to my application.  Until I trimmed the boot time,
>> I did not realize the PRUs were slow -- with a 45 second boot time, they
>> were always available.  Something seems to be going on, but so far it is
>> invisible.  Thanks.
>>
>> On Thu, Mar 4, 2021 at 1:39 PM Tom Stepleton  wrote:
>>
>>> I can't say for sure about why I'm enjoying faster load times now, but I
>>> have three guesses.
>>>
>>> One possibility is that I finally arranged some candles in a ring, sat
>>> in the middle, slipped into a hypnagogic torpor, and in an echoing
>>> dissociative void managed to utter yet another arcane device tree
>>> overlay
>>> ,
>>> this time for my own application. It seems possible to me that when the
>>> PocketBeagle loads this device tree overlay on boot, some more complicated
>>> and time-consuming facilities of its default hardware setup are disabled,
>>> allowing it to attend to other setup tasks faster. This is purely a guess;
>>> my memories of that time are hazy and indistinct and whenever I try to
>>> recall them my mouth tastes of metal.
>>>
>>> (just kidding it wasn't that bad at all, but even now I'm not really
>>> sure I got it "right")
>>>
>>> The second possibility is that I'm as ruthless as I know how to be about 
>>> disabling
>>> services I don't use in my application
>>> ,
>>> so that speeds things up.
>>>
>>> The third possibility is that on the good advice from someone on the
>>> Beagle IRC channel, I disable initramfs
>>> .
>>> This one really does seem to shave off quite a few seconds from boot time
>>> for me.
>>>
>>> I'm talking about boot time here---I haven't measured
>>> time-to-availability for the PRUs, but so far it hasn't been a problem and
>>> it's definitely much faster than it was. Either way, I'd be thrilled to
>>> collect yet further tips and tricks for making my gizmo start up even
>>> sooner! But for setup and installation of this magic, I do want people to
>>> be able to just run some shell scripts like the ones I've linked above ---
>>> recompiling the kernel would not be an option for me, for example.
>>>
>>> --Tom
>>> On Thursday, March 4, 2021 at 3:49:47 PM UTC rpau...@gmail.com wrote:
>>>
 I'm trying to do something similar.  It would be better, at least in my
 case, if the PRU could be started at boot.  One thing I noticed in my case
 is the pruss doesn't show up until about 30 seconds into the boot cycle.
 Yours seems to be detected much faster.  Did you change something, or have
 any idea when the kernel decides to discover it?  I have tried to create a
 systemd unit to start them, but I find myself trying to start them before
 sysfs is populated.

 On Monday, February 1, 2021 at 7:08:32 PM UTC-5 Tom Stepleton wrote:

> Oops, nevermind --- I see that it can't be done for now. On boot, or
> in other words during startup or power-on, the Debian Linux kernel on your
> PocketBeagle or BeagleBone Black can load rproc (aka remoteproc) PRU
> firmware such as am335x-pru0-fw and am335x-pru1-fw from /lib/firmware, but
> it will not start the firmware. (Yes, I am keyword-stuffing for maximum
> searchability.)
>
>
> https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/remoteproc/pru_rproc.c?h=ti-android-linux-4.19.y#n1173
>
> I'll try to identify other means of getting the PRUs started quickly;
> maybe something that systemd can run at boot time.
>
> Apologies for the distraction,
> --Tom
> On Monday, February 1, 2021 at 4:09:40 AM UTC Tom Stepleton wrote:
>
>> Hi again,
>>
>> I have some mature PRU firmware that I've been loading and starting

[beagleboard] Overlay -- set GPIO initial value

[Paul Beam]

I'm creating my first device tree overlay for the PocketBeagle intending to 
setup the I/O pins the way I need them without having to run an additional 
script to set things up.  I'm using this as a template:
https://github.com/jadonk/validation-scripts/blob/master/test-capemgr/pinctrl-test-0.dts

Is it possible in the device tree overlay to not only set the mux setting, 
but also set the pin initial value?  For example, if I set a GPIO as an 
output, can I also set that output hi?

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/12a67a06-1217-42a4-879a-7d1a546c811en%40googlegroups.com.

[beagleboard] Auto root login from serial console only

[Paul Beam]

Anyone know how to allow auto root login from the serial console without a 
password while still requiring a password for ssh?  This is really a worst 
case recovery type thing where someone changes the default password and 
forgets the new password.  Physical security should be adequate in this 
case.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/eb603c9b-6111-471d-b0e3-27b3e9a54800n%40googlegroups.com.

Re: [beagleboard] Auto root login from serial console only

[Paul Beam]

Thanks.  That makes sense.  I was barking up the wrong tree and just 
totally forgot about getty.

On Thursday, April 15, 2021 at 12:57:01 PM UTC-4 hel...@deepsoft.com wrote:

> At Thu, 15 Apr 2021 07:44:05 -0700 (PDT) beagl...@googlegroups.com wrote:
>
> > 
> > Anyone know how to allow auto root login from the serial console without 
> a 
> > password while still requiring a password for ssh? This is really a 
> worst 
> > case recovery type thing where someone changes the default password and 
> > forgets the new password. Physical security should be adequate in this 
> > case.
>
> man getty
>
> Specificly:
>
> -a, --autologin username
> Automatically log in the specified user without asking for a
> username or password. Using this option causes an -f username
> option and argument to be added to the /bin/login command line.
> See --login-options, which can be used to modify this option's
> behavior.
>
> Note that --autologin may affect the way how agetty initializes
> the serial line, because on auto-login agetty does not read from
> the line and it has no opportunity optimize the line setting.
>
> and also:
>
> -l, --login-program login_program
> Invoke the specified login_program instead of /bin/login. This
> allows the use of a non-standard login program. Such a program
> could, for example, ask for a dial-up password or use a differ†
> ent password file. See --login-options.
>
> -o, --login-options "login_options"
> Options and arguments that are passed to login(1). Where \u is
> replaced by the login name. For example:
>
> --login-options '-h darkstar -- \u'
>
> See --autologin, --login-program and --remote.
>
> Please read the SECURITY NOTICE below before using this option.
>
> -p, --login-pause
> Wait for any key before dropping to the login prompt. Can be
> combined with --autologin to save memory by lazily spawning
> shells.
>
>
> systemd files of interest:
>
> /etc/systemd/system/getty.target.wants/serial...@ttyGS0.service 
> /lib/systemd/system/serial-getty@.service
>
> The former is a symlink to the second, but you don't want to mess with the
> second, but instead copy the second to someplace
> (/usr/local/lib/systemd/system/ probably) and modify it (maybe rename it to
> /lib/systemd/system/serial-getty-root@.service) and then change the
> /etc/systemd/system/getty.target.wants/serial...@ttyGS0.service symlink.
>
> Robert Heller -- Cell: 413-658-7953 <(413)%20658-7953> GV: 978-633-5364 
> <(978)%20633-5364>
> Deepwoods Software -- Custom Software Services
> http://www.deepsoft.com/ -- Linux Administration Services
> hel...@deepsoft.com -- Webhosting Services
>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/6d0a6471-0ae6-4223-bbb9-5e9c42f11ff2n%40googlegroups.com.

Re: [beagleboard] Auto root login from serial console only

[Paul Beam]

This is a tad more sinister than it appears.  In 
/etc/systemd/system/getty.target.wants/ are 3 files: getty@tty1.service, 
serial-getty@.service, and serial-getty@ttyGS0.service.  I have changed 
them all, and none have had any impact.  A 'systemctl cat 
getty@ttyGS0.service' shows the unchanged unit file 
/lib/systemd/system/getty@.service.Although I did desire to not alter 
the original systemd unit file in /lib, I may need to do that and see if it 
makes a difference.

On Thursday, April 15, 2021 at 2:33:34 PM UTC-4 Paul Beam wrote:

> Thanks.  That makes sense.  I was barking up the wrong tree and just 
> totally forgot about getty.
>
> On Thursday, April 15, 2021 at 12:57:01 PM UTC-4 hel...@deepsoft.com 
> wrote:
>
>> At Thu, 15 Apr 2021 07:44:05 -0700 (PDT) beagl...@googlegroups.com 
>> wrote: 
>>
>> > 
>> > Anyone know how to allow auto root login from the serial console 
>> without a 
>> > password while still requiring a password for ssh? This is really a 
>> worst 
>> > case recovery type thing where someone changes the default password and 
>> > forgets the new password. Physical security should be adequate in this 
>> > case. 
>>
>> man getty 
>>
>> Specificly: 
>>
>> -a, --autologin username 
>> Automatically log in the specified user without asking for a 
>> username or password. Using this option causes an -f username 
>> option and argument to be added to the /bin/login command line. 
>> See --login-options, which can be used to modify this option's 
>> behavior. 
>>
>> Note that --autologin may affect the way how agetty initializes 
>> the serial line, because on auto-login agetty does not read from 
>> the line and it has no opportunity optimize the line setting. 
>>
>> and also: 
>>
>> -l, --login-program login_program 
>> Invoke the specified login_program instead of /bin/login. This 
>> allows the use of a non-standard login program. Such a program 
>> could, for example, ask for a dial-up password or use a differ†
>> ent password file. See --login-options. 
>>
>> -o, --login-options "login_options" 
>> Options and arguments that are passed to login(1). Where \u is 
>> replaced by the login name. For example: 
>>
>> --login-options '-h darkstar -- \u' 
>>
>> See --autologin, --login-program and --remote. 
>>
>> Please read the SECURITY NOTICE below before using this option. 
>>
>> -p, --login-pause 
>> Wait for any key before dropping to the login prompt. Can be 
>> combined with --autologin to save memory by lazily spawning 
>> shells. 
>>
>>
>> systemd files of interest: 
>>
>> /etc/systemd/system/getty.target.wants/serial...@ttyGS0.service 
>> /lib/systemd/system/serial-getty@.service 
>>
>> The former is a symlink to the second, but you don't want to mess with 
>> the 
>> second, but instead copy the second to someplace 
>> (/usr/local/lib/systemd/system/ probably) and modify it (maybe rename it 
>> to 
>> /lib/systemd/system/serial-getty-root@.service) and then change the 
>> /etc/systemd/system/getty.target.wants/serial...@ttyGS0.service symlink. 
>>
>> Robert Heller -- Cell: 413-658-7953 <(413)%20658-7953> GV: 978-633-5364 
>> <(978)%20633-5364> 
>> Deepwoods Software -- Custom Software Services 
>> http://www.deepsoft.com/ -- Linux Administration Services 
>> hel...@deepsoft.com -- Webhosting Services 
>>
>>
>>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/736b70f0-54a0-4d62-a0cc-33b94aac86d2n%40googlegroups.com.

Re: [beagleboard] Auto root login from serial console only

[Paul Beam]

The fix seems to be 
here:  
https://unix.stackexchange.com/questions/401759/automatically-login-on-debian-9-2-1-command-line

Midway through the page someone was working with a serial instead of a 
virtual terminal.  I'm not exactly sure of the impact of the edit in the 
logind.conf file, but the combination shown there works.  

On Thursday, April 15, 2021 at 4:54:06 PM UTC-4 Paul Beam wrote:

> This is a tad more sinister than it appears.  In 
> /etc/systemd/system/getty.target.wants/ are 3 files: ge...@tty1.service, 
> serial-getty@.service, and serial...@ttyGS0.service.  I have changed them 
> all, and none have had any impact.  A 'systemctl cat ge...@ttyGS0.service' 
> shows the unchanged unit file /lib/systemd/system/getty@.service.
> Although I did desire to not alter the original systemd unit file in /lib, 
> I may need to do that and see if it makes a difference.
>
> On Thursday, April 15, 2021 at 2:33:34 PM UTC-4 Paul Beam wrote:
>
>> Thanks.  That makes sense.  I was barking up the wrong tree and just 
>> totally forgot about getty.
>>
>> On Thursday, April 15, 2021 at 12:57:01 PM UTC-4 hel...@deepsoft.com 
>> wrote:
>>
>>> At Thu, 15 Apr 2021 07:44:05 -0700 (PDT) beagl...@googlegroups.com 
>>> wrote: 
>>>
>>> > 
>>> > Anyone know how to allow auto root login from the serial console 
>>> without a 
>>> > password while still requiring a password for ssh? This is really a 
>>> worst 
>>> > case recovery type thing where someone changes the default password 
>>> and 
>>> > forgets the new password. Physical security should be adequate in this 
>>> > case. 
>>>
>>> man getty 
>>>
>>> Specificly: 
>>>
>>> -a, --autologin username 
>>> Automatically log in the specified user without asking for a 
>>> username or password. Using this option causes an -f username 
>>> option and argument to be added to the /bin/login command line. 
>>> See --login-options, which can be used to modify this option's 
>>> behavior. 
>>>
>>> Note that --autologin may affect the way how agetty initializes 
>>> the serial line, because on auto-login agetty does not read from 
>>> the line and it has no opportunity optimize the line setting. 
>>>
>>> and also: 
>>>
>>> -l, --login-program login_program 
>>> Invoke the specified login_program instead of /bin/login. This 
>>> allows the use of a non-standard login program. Such a program 
>>> could, for example, ask for a dial-up password or use a differ†
>>> ent password file. See --login-options. 
>>>
>>> -o, --login-options "login_options" 
>>> Options and arguments that are passed to login(1). Where \u is 
>>> replaced by the login name. For example: 
>>>
>>> --login-options '-h darkstar -- \u' 
>>>
>>> See --autologin, --login-program and --remote. 
>>>
>>> Please read the SECURITY NOTICE below before using this option. 
>>>
>>> -p, --login-pause 
>>> Wait for any key before dropping to the login prompt. Can be 
>>> combined with --autologin to save memory by lazily spawning 
>>> shells. 
>>>
>>>
>>> systemd files of interest: 
>>>
>>> /etc/systemd/system/getty.target.wants/serial...@ttyGS0.service 
>>> /lib/systemd/system/serial-getty@.service 
>>>
>>> The former is a symlink to the second, but you don't want to mess with 
>>> the 
>>> second, but instead copy the second to someplace 
>>> (/usr/local/lib/systemd/system/ probably) and modify it (maybe rename it 
>>> to 
>>> /lib/systemd/system/serial-getty-root@.service) and then change the 
>>> /etc/systemd/system/getty.target.wants/serial...@ttyGS0.service symlink. 
>>>
>>> Robert Heller -- Cell: 413-658-7953 <(413)%20658-7953> GV: 978-633-5364 
>>> <(978)%20633-5364> 
>>> Deepwoods Software -- Custom Software Services 
>>> http://www.deepsoft.com/ -- Linux Administration Services 
>>> hel...@deepsoft.com -- Webhosting Services 
>>>
>>>
>>>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/9a8d09d4-9d66-403b-9e15-1a1bd8a26007n%40googlegroups.com.

[beagleboard] Re: PRU Communications: Beaglebone Black

[Paul Beam]

The PRUs do not support a traditional interrupt mechanism where code flow 
is diverted due to an event.  You must poll a flag to determine if the 
interrupt has occurred.  The PRUs latency in response will be dependent 
upon how often you poll.  I suggest you keep your main loop short and use 
state machines for all operations so that a poll is not delayed by a long 
function.  
 
You may need to add an additional processor if you need traditional 
interrupt operation.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/db23f6aa-17b9-4fb7-9d38-7ff47f5205e8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: PRU Communications: Beaglebone Black

[Paul Beam]

This is from the TI FAQ on the PRU:

Does the PRU-ICSS/ PRU_ICSSG Support Interrupts?

Yes,but not in the same way that most cores support interrupts.The 
PRU-ICSS/ PRU_ICSSG contains an interrupt controller that can map 64 system 
events down to two flags that are set in a PRU core register (bits 30 and 
31 in core register R31).The PRU core can then check each of these flags in 
a single cycle to see if an event has occurred.These flags can either be 
polled upon or checked periodically (dependent on what makes the most sense 
for the use case).The PRU-ICSS/ PRU_ICSSG interrupt controller does not 
support jumping the program counter of the PRU core to a pre-determined 
function when an event occurs.


The other PRU can be one of these 64 events that sets a bit.  Whether it 
makes more sense to use the bits in R31 or shared memory will depend upon 
your application.  Shared memory would allow you to queue up more data than 
just a single bit, but a larger message could take more time to process.  
This is a design decision you will have to make.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/5a29e2b2-dbb8-4819-b65b-8899c3a17324%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Tethering to Android

[Paul Beam]

My understanding is that Windows like RNDIS and Mac likes CDC-ECM.  Linux 
likes both.  For Android, what works best for me is to make the 
PocketBeagle a host, then if tethering is enabled on Android it will appear 
as a device that Linux likes -- not sure which protocol it uses.  I have 
had the PocketBeagle work as a device on a rooted Amazon Fire, but it took 
some scripting on the Android side to enable it, set the IP, etc.  On a 
non-rooted Walmart tablet, having the PocketBeagle be the host is pretty 
close to plug and play once you get the PocketBeagle networking configured.

I have moved on to getting WiFi and Bluetooth operational so I have choices 
between wired and wireless and connectivity.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/ade6615f-c27b-4248-a49d-bfd590bf4356%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: SPI0 Boot enabled

[Paul Beam]

I'm going to answer my own post.  The thing I can do is keep the ADC in 
reset until after boot, and that does at least allow the PocketBeagle to 
start up.  I never dreamed someone would actually want to boot from SPI 
much less that it would be the preferred boot device.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/92464269-3533-4773-ac49-e0fe0f378505%40googlegroups.com.

[beagleboard] PRU0 to PRU1 interrupt

[Paul Beam]

I'm having trouble getting PRU1 to recognize an event generated by PRU0.  
The examples I have found appear to be contradictory, so I hope someone can 
give me some help.  I am using RemoteProc in a recent TI kernel on a 
PocketBeagle, and I can load and execute firmware just fine.  PRU1 uses 
RPMSG, and I can generate and acknowledge events generated by the ARM to 
PRU1.  I try to generate events on PRU0, directed to PRU1, and PRU1 is 
oblivious.

First of all, I have seen somewhere that PRU0-PRU1 is event 21, but I don't 
understand where this is defined.  On PRU0, my understanding is that I 
write to r31 with bit 5 set and the event in the lower 4 bits, so "ldi r31, 
21+32" is what I am using on PRU0.

On PRU1, I want to map this event to host interrupt 0, so I can test bit 30 
of R31 to see if the interrupt has occurred.  In my resource table:

/* Mapping sysevts to a channel. Each pair contains a sysevt, channel. */
struct ch_map pru_intc_map[] = { {18, 3},
 {19, 1},
 {21, 0}
};

and

/* Channel-to-host mapping, 255 for unused */
0, 1, HOST_UNUSED, 3,  HOST_UNUSED,
HOST_UNUSED, HOST_UNUSED, HOST_UNUSED, HOST_UNUSED, HOST_UNUSED,


Is this right?  I have found one project where generating the interrupt 
involved subtracting 16 from the event written to R31.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/16644eee-b4d8-4be8-87d4-9184c005c52e%40googlegroups.com.

[beagleboard] Re: PRU0 to PRU1 interrupt

[Paul Beam]

Well, as often happens, a moment after I verbalize my problem I find the 
solution!  It appears that subtracting 16 is correct, but my scope probe 
was not.  Once I started probing the proper pin I was seeing PRU1 see 
events generated from PRU0.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/3750d98b-54cc-4fed-a804-acac479f54a3%40googlegroups.com.

[beagleboard] After build_kernel.sh

[Paul Beam]

So I am trying to build my own kernel for a Pocketbeagle, and I have 
cross-compiled in a Debian VM, and have the output in the deploy directory 
after executing build_kernel.sh on kernel version 4.19.94-ti-rt-r41.  My 
problem is getting it to boot properly on the target system.  I have moved 
the products to the target and put them, I think, in the proper places 
creating an appropriate /lib/modules/4.19.94-ti-rt-r41 and 
/boot/dtbs/4.19.94-ti-rt-r41 directories, renamed the zImage and updated 
uEnv.txt to version 4.19.94-ti-rt-r41.  Upon reboot, that kernel does come 
up but systemd-modules-load.service fails, so I think I must be missing 
something.  Is there another step?

root@beaglebone:~# systemctl --failed
  UNIT LOAD   ACTIVE SUBDESCRIPTION
● systemd-modules-load.service loaded failed failed Load Kernel Modules

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB= The low-level unit activation state, values depend on unit type.

1 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
root@beaglebone:~# [   83.036964] wkup_m3_ipc 44e11324.wkup_m3_ipc: could 
not get rproc handle
q
-bash: q: command not found
root@beaglebone:~# systemctl status systemd-modules-load.service
● systemd-modules-load.service - Load Kernel Modules
   Loaded: loaded (/lib/systemd/system/systemd-modules-load.service; 
static; ven
   Active: failed (Result: exit-code) since Tue 2020-03-24 21:30:41 UTC; 
7min ag
 Docs: man:systemd-modules-load.service(8)
   man:modules-load.d(5)
  Process: 153 ExecStart=/lib/systemd/systemd-modules-load (code=exited, 
status=
 Main PID: 153 (code=exited, status=1/FAILURE)

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d8e11e2c-ad66-49a6-889b-837df621f4a2%40googlegroups.com.

[beagleboard] Re: After build_kernel.sh

[Paul Beam]

I'm going to answer (mostly) my own question here for posterity.  At 
appears my process was mostly right, but I failed to update the reference 
to AM335X-PRU-RPROC-4-14-TI-00A0 in uEnv.txt, and that apparently does some 
weird things.  

Executing /lib/systemd/systemd-modules-load shows that the module 
pruss_intc is not found, so I need to investigate why this is since I 
selected all the pru options in the kernel config.  Perhaps, this module 
has changed names or combined with another?

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/665a0d5c-988c-4ec3-a621-9d3ec6fd9bf6%40googlegroups.com.

[beagleboard] PocketBeagle Boot Time

[Paul Beam]

Has anyone had success getting the PocketBeagle boot time to less than 30 
seconds?  

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/30119c30-33ad-4c09-9e96-d429e7e9203e%40googlegroups.com.

Re: [beagleboard] Re: PocketBeagle Boot Time

[Paul Beam]

Robert,

I have been working with the LTS 4.14 ti branch.  Is 4.19 better?  To be 
honest, I don't remember the image I started with, but I started 6+ months 
ago.  I'm in a position where I can basically start fresh if there are 
advantages.  


On Thursday, April 23, 2020 at 11:37:10 AM UTC-4, RobertCNelson wrote:
>
> >   2.649s loadcpufreq.service 
> >707ms cpufrequtils.service 
>
> It's safe to disable cpufrequtils, by default it's already running at 
> 1Ghz out of u-boot and with Performance enabled 
> with the default kernel.. 
>
> It's more for legacy.. 
>
> debian@beaglebone:~$ systemd-analyze 
> Startup finished in 1.357s (kernel) + 27.030s (userspace) = 28.387s 
> graphical.target reached after 26.727s in userspace 
>
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/ce0b4dac-64ec-4aac-a405-f53f8867320a%40googlegroups.com.

Re: [beagleboard] Re: PocketBeagle Boot Time

[Paul Beam]

>
> The newest image is certainly an improvement, but my results are not quite 
> what yours are.  Two quick questions:


1.  Is the dev-mmcblk0p1.device time affected by SD card speed?  I'm at a 
loss why mine is 8 seconds slower than yours.
2.  Is there a way to identify the time consuming parts 
generic-board-startup.service?

Here is where I stand:
 systemd-analyze blame
 36.337s generic-board-startup.service
 27.260s dev-mmcblk0p1.device
  3.565s nginx.service
  3.326s loadcpufreq.service
  3.247s systemd-udev-trigger.service
  2.083s networking.service
  1.979s ssh.service

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/8f55e7d6-c0c4-489f-929a-6f2dfab2f967%40googlegroups.com.