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 altho
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
, 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 hav
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
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
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
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
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
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
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
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
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
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:
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
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
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 t
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
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.
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
; 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 par
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 0x
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
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
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
>
> 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
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
>
> 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
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
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_url=https%253A%252F%252Fwww.google.com%252F
Cutting to the chase, either ground the BAT terminal
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
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
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
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
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
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
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
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
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
>
> 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
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,
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
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
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
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
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
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,
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
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
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
49 matches
Mail list logo
