a
risk (greater than the upgrade)?
On Thursday, December 10, 2020 at 11:39:37 AM UTC-7, RobertCNelson wrote:
>
> On Thu, Dec 10, 2020 at 12:29 PM ags >
> wrote:
> >
> > Posted the results of the script, curious as to what "the different
> issue" is. I
lson wrote:
>
> On Mon, Dec 7, 2020 at 2:43 PM ags >
> wrote:
> >
> > @RobertCNelson are there any plans to provide this update as part of a
> BBBW package? (any reason to believe it addresses the issue cited above?)
> >
>
> ps you have a different issue:
All
On Monday, December 7, 2020 at 1:53:24 PM UTC-7, RobertCNelson wrote:
>
> On Mon, Dec 7, 2020 at 2:43 PM ags >
> wrote:
> >
> > @RobertCNelson are there any plans to provide this update as part of a
> BBBW package? (any reason to bel
;
> https://github.com/beagleboard/Latest-Images/issues/73
>
> A segunda-feira, 7 de dezembro de 2020 à(s) 11:12:52 UTC, ags escreveu:
>
>> Has there been any progress in understanding the cause, and cure, for the
>> warning message being written to the system log every sec
Has there been any progress in understanding the cause, and cure, for the
warning message being written to the system log every second (BBBW)?
kernel: *wlcore: WARNING no fw rx ba on tid *
>
Is there a firmware/driver update available? I just re-flashed my eMMC on a
uname -a
Linux beaglebone
re.beagleboard.user ags
>
>
> >The device was purchased in Dec 2018, and just now put into service; it
> is
> >a year (at least) out of date.
>
> Based on the u-boot version -- much further out of date
>
> >I was holding the boot-select button, and i
t; resend}
>
> On Sun, 15 Dec 2019 23:00:05 -0800 (PST), in
> gmane.comp.hardware.beagleboard.user ags wrote:
>
> >
> >bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot
> >2019.04-2-gbb4af0f50f]:[location: dd MBR]
> >
> >bootloader:[eMMC-(def
ctivity.
On Monday, December 16, 2019 at 2:27:17 PM UTC-8, RobertCNelson wrote:
>
> On Mon, Dec 16, 2019 at 3:58 PM ags >
> wrote:
> >
> > My next question was going to be "what should the EEPROM ID be... or
> what form should it take"?
>
> An even
s dtb would also work, without changing the EEPROM? (My thinking was
to try that first, then if it worked it would validate the idea the the
EEPROM was bad and *then* reflash the EEPROM).
Thanks for your help, Robert.
On Monday, December 16, 2019 at 1:07:04 PM UTC-8, RobertCNelson wrote:
>
>
, ags wrote:
>
> I've had a BBBW for 1+ years. Just booted, and can't get WiFi working.
>
> using connmanctl:
>
> connmanctl> enable wifi
> Error wifi: Method "SetProperty" with signature "sv" on interface
> "net.connman.Technology" doesn't
I've had a BBBW for 1+ years. Just booted, and can't get WiFi working.
using connmanctl:
connmanctl> enable wifi
Error wifi: Method "SetProperty" with signature "sv" on interface
"net.connman.Technology" doesn't exist
Researched and saw convo about "corrupt EEPROM"; tried using
I have struggled with the PRU scratchpad, persisting because it seems that
it could be a very powerful feature. In particular, the XCHG instruction
(pseudo-op) has caused me hours of frustration to identify and diagnose a
problem. It seems that XCHG (swapping current PRU register values for
).
On Monday, April 16, 2018 at 12:48:58 PM UTC-7, RobertCNelson wrote:
>
> On Mon, Apr 16, 2018 at 2:41 PM, ags <alfred.g...@gmail.com >
> wrote:
> > @RobertCNelson thanks for that info. IMO it is preferable to use a
> built-in
> > (guaranteed unique and immutable
reestablish the
IP/MAC binding.
On Monday, April 16, 2018 at 11:44:41 AM UTC-7, RobertCNelson wrote:
>
> On Mon, Apr 16, 2018 at 1:12 PM, ags <alfred.g...@gmail.com >
> wrote:
> >
> > Update: I realized that the MAC address for wlan0 had changed - didn't
>
Update: I realized that the MAC address for wlan0 had changed - didn't
expect that. Will it remain the same until another firmware upgrade?
debian@BBB:~$ connmanctl
connmanctl> tether wifi disable
connmanctl> enable wifi
connmanctl> scan wifi
connmanctl> services
connmanctl> agent on
I updated wl18xx firmware/packages in an attempt to reduce the high
frequency of dropped WiFi connections. That didn't go smoothly and I had to
take a few passes at it.
I now have no (WiFi) connectivity at all. I rebooted after the troublesome
package upgrade and the wlan0 interface worked -
looks like I have a lot of partially installed packages...
debian@BBB:/$ apt-get -f install --dry-run
NOTE: This is only a simulation!
apt-get needs root privileges for real execution.
Keep also in mind that locking is deactivated,
so don't depend on the relevance to the
ggestions on how to *just* upgrade what I need for improved wireless
connectivity (this OP)?
On Wednesday, March 28, 2018 at 3:51:13 PM UTC-7, ags wrote:
>
> More specifics: I see lots of stuff (~450MiB) in /var/cache/apt/archives.
> Only two are dated today. One is bb-wl18xx-firmware...
>
2018 at 3:42:01 PM UTC-7, ags wrote:
>
> This is turning into an "apt" tutorial - but searches haven't helped me
> find what I'm looking for.
>
> I have killed the upgrade mis-stream. I think it successfully downloaded
> all the upgradable packages, and ran out of "
ided in a later post
On Wednesday, March 28, 2018 at 2:44:06 PM UTC-7, RobertCNelson wrote:
>
> On Wed, Mar 28, 2018 at 4:34 PM, ags <alfred.g...@gmail.com >
> wrote:
> > Sorry if this is obvious. The current situation is that I have no "disk"
> > space left and
--purge" each of the 200+ packages that were
(apparently) pulled in?
Still, how do I perform the upgrade to get the possible fix for my
connectivity problem within available disk space? (is it impossible?)
On Wednesday, March 28, 2018 at 2:19:40 PM UTC-7, RobertCNelson wrote:
>
> On
were being
done.
On Wednesday, March 28, 2018 at 1:28:18 PM UTC-7, ags wrote:
>
> Uh oh...
>
> debian@BBB:~$ sudo apt upgrade bb-wl18xx-firmware firmware-ti-connectivity
>
> Reading package lists... Done
>
> Building dependency tree
>
> Reading state infor
On Wed, Mar 28, 2018 at 9:40 AM, ags <alfred.g...@gmail.com >
> wrote:
> > git:/opt/scripts/:[9d965a5f40ae00774c81164f87a450a678ab79f6]
> >
> > eeprom:[A335BNLTBWA51650BBWG0378]
> >
> > model:[TI_AM335x_BeagleBone_Black_Wireless]
> >
] gpio-of-helper ocp:cape-universal: Allocated GPIO id=37
[1.220639] gpio-of-helper ocp:cape-universal: Allocated GPIO id=38
[1.220650] gpio-of-helper ocp:cape-universal: ready
END
On Tuesday, March 27, 2018 at 5:06:29 PM UTC-7, RobertCNelson wrote:
>
> On Tue, Mar 27, 2018 at 5:22 P
I’m experiencing random drops of wirelesss connectivity with BBBW. I have
several other wired & wireless SBCs BBB, RPi, etc. and don’t see this with
them. This is my only BBBW though. I believe I’ve experienced it since first
installing - but am not certain.
Symptoms are simply not being able
at 6:12:11 PM UTC-7, RobertCNelson wrote:
>
> On Fri, Mar 23, 2018 at 7:59 PM, ags <alfred.g...@gmail.com >
> wrote:
> > That *seems* to have fixed it. Will need to run a test to be sure. It
> does
> > allow me to configure the audio pin as pruout, and
he directive
itself
uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo # u-boot
even knows about prus?
enable_uboot_cape_universal=1
# ... and cape_universal?
Thank you for the response.
On Friday, March 23, 2018 at 3:44:56 PM UTC-7, a
I gave up trying to figure out how to get config-pins, overlays, uboot, etc
all in-sync to allow access to all the available pru pins, so I followed
previous instructions to update.
What I did:
debian@BBBWl:~$ cd /opt/scripts/tools
debian@BBBWl:~$ sudo ./update_kernel.sh
edited /boot/uEnv.txt
load it that fails.
It seems my system is incorrectly configured...
Note that I am using uio_pruss drivers and a workable solution must be
compatible with this.
On Wednesday, December 20, 2017 at 2:34:48 PM UTC-8, RobertCNelson wrote:
>
> On Wed, Dec 20, 2017 at 4:29 PM, ags <alfred
wrote:
>
> ags:
> Here it is.
> --- Graham
>
> ==
>
>
> **
> *Making the Audio Cape Work
UTC-8, RobertCNelson wrote:
>
> On Thu, Dec 21, 2017 at 11:06 AM, ags <alfred.g...@gmail.com >
> wrote:
> > How can I see which dtb file is being loaded? I've looked at
> /boot/uEnv.txt
> > but nothing is specified there - all lines are commented o
How can I see which dtb file is being loaded? I've looked at /boot/uEnv.txt
but nothing is specified there - all lines are commented other than
uname=..., uuid=... and:
cmdline=coherent_pool=1M quiet cape_universal=enable
I believe I'm using an older uboot. Where/how is the dtb file
direct user
> space access to the device.
>
> In fact one way to make sure the device tree loaded correctly is that the
> "UU" symbol
> appears at the devices' I2C address.
>
> --- Graham
>
> ==
>
> On Tuesday, May 16, 2017 at 10:51:19 AM UTC-5, ags wr
per/config/overlay items also being
synced without disrupting uio_pruss?
I presume this:
cd /opt/scripts/tools/
git pull
sudo ./update_kernel.sh
sudo reboot
will result in the latest kernel version (4.9.x??) which is not what I
want...
On Wednesday, December 20, 2017 at 1:33:46 PM UTC-8,
I've been building a prototype using the uio_pruss driver and one "test"
pin (P9_27) which was easily allocated using config-pin.
I'm now trying to complete the prototype and need to enable a total of 8
PRU pins (pr1_pru0_pru_r30_[0-7]). I am unable to enable most of these pins:
debian@BBB:~$
I've searched and found nothing. I thought it would be easy to find Eagle
(or other) PCB files for a cape with the "standard" board size/shape and
the expansion headers.
I'm using DesignSpark PCB, but can convert from Eagle, OrCAD, maybe others.
--
For more options, visit
gt; If it is unique, then you will have to write your own Linux driver and
> recompile the kernel.
>
> If you just want audio, it is a lot easier to just use a USB CODEC.
>
> --- Graham
>
> ==
>
> On Monday, May 15, 2017 at 6:11:11 PM UTC-5, ags wrote:
>>
&g
I am building an interface to mpg123 from another application using the
Remote command interface. I have observed that if the FORMAT command is
issued to get the audio sample rate (e.g. 44100) after a file is loaded but
before starting playback, the mpg123 process will crash when playback is
tween registers, scratch and PRU DRAM. So I've
sidestepped the problem of unpredictable latency waiting for data from the
ARM host.
I hope this might help someone else with similar requirements.
On Thursday, March 23, 2017 at 12:32:28 PM UTC-7, William Hermans wrote:
>
>
>
> On Thu, Mar
, William Hermans wrote:
>
>
>
> On Wed, Mar 22, 2017 at 10:13 PM, ags <alfred.g...@gmail.com
> > wrote:
>
>> I thought using select() to wait for notification of an event (by
>> "listening" to the fsys uio files) would free the ARM cpu to do other
You've hit the nail on the head. The issue (IMO) is Linux "wandering off
into the weeds". It comes back, eventually... but while gone, bad things
happen.
1) I am using a handshake approach between PRU and ARM, using interrupts.
When the PRU wants more data, it generates an ARM interrupt. The
I have an application running on the ARM host that writes to the PRU shared
memory. The PRU core then manipulates that data and sends it out the EGPIO
pins with exact timing.
For this to work, I need to have a steady supply of data bursts available
to the PRU core - about 32 KiB each burst.
Would someone kindly decode what VBUS and VBUSP are? Searched but could not
find other relevant references. Thanks.
On Tuesday, May 26, 2015 at 6:39:38 AM UTC-7, marcelo...@gmail.com wrote:
>
> Sorry, just saw that you actually mentioned that the shared memory has the
> same performance as the
//github.com/dinuxbg/pru-gcc-examples/blob/master/ov7670-cam/host-uio/pload.c#L207>
>.
>
>
> Regards,
> Dimitar
>
> On Tuesday, March 7, 2017 at 10:07:31 PM UTC+2, ags wrote:
>>
>> I have been able to load/start/run/stop a PRU core from 4.4.30-ti-r64
>&
t;>> Address 0x800h is actually the start of Linux's virtual memory map. But
>>> I'm not 100% sure.
>>> I'm doing my own research for a paying project, so can't really dive
>>> into documentation for something else right now . . .
>>>
>>> On Fri, Mar 10,
arch 8, 2017 at 4:14:56 PM UTC-8, William Hermans wrote:
>
>
>
> On Wed, Mar 8, 2017 at 4:34 PM, ags <alfred.g...@gmail.com >
> wrote:
>
>> Correct - to preserve deterministic execution, the PRU cannot be
>> asynchronously interrupted. Polling (of some
18:48 AM UTC-8, William Hermans wrote:
>>
>>
>>
>> On Wed, Mar 8, 2017 at 9:04 AM, William Hermans <yyr...@gmail.com> wrote:
>>
>>> For the purpose of this discussion with ags, I do not think the actual
>>> definition of what an interrupt
mans wrote:
>
>
>
> On Tue, Mar 7, 2017 at 9:45 PM, ags <alfred.g...@gmail.com >
> wrote:
>
>> The mechanism for generating an interrupt from a PRU to the A8 (host) is
>> well-documented. Is there a way to send an interrupt (one of the 64 system
>> interrup
The mechanism for generating an interrupt from a PRU to the A8 (host) is
well-documented. Is there a way to send an interrupt (one of the 64 system
interrupt events documented in the PRU-ICSS literature) from userspace?
>From reading the TI documentation, the only two that seem to be candidates
I have been able to load/start/run/stop a PRU core from 4.4.30-ti-r64 using
just the uio_pruss (& uio) drivers, without any of the prussdrv code. Big
milestone in my project.
A long time ago I asked a question about the examples in the pru here:
o the bone kernel but stayed wit the ti kernel. Not
sure what the differences are between them.
On Thursday, March 2, 2017 at 9:04:52 AM UTC-8, RobertCNelson wrote:
>
> On Wed, Mar 1, 2017 at 11:42 PM, ags <alfred.g...@gmail.com >
> wrote:
> > uname -a
> >
> > Lin
On Saturday, March 4, 2017 at 5:56:04 AM UTC-8, Charles Steinkuehler wrote:
>
> On 3/3/2017 10:04 PM, ags wrote:
> ...
> > *I haven't tried it (don't want to damage hardware) but does this mean
> that
> > directly poking at the GPIO registers from userspace
ages seems to
indicate the problem is that the PRUSS clock needs to be enabled. (I
think). I suspect this is part of what the uio_pruss driver does?
Thanks.
On Thursday, March 2, 2017 at 9:04:52 AM UTC-8, RobertCNelson wrote:
>
> On Wed, Mar 1, 2017 at 11:42 PM, ags <alfred.g...@gmail.com >
someone else.
On Thursday, March 2, 2017 at 5:02:47 AM UTC-8, Charles Steinkuehler wrote:
>
> On 3/1/2017 11:00 PM, ags wrote:
> > This may be a rudimentary linux/dt question, but doesn't the
> pinctrl-single
> > driver already support this? Couldn't one change the pin conf
hence that is why pinmux-helper is necessary.
>
> Regards,
> John
>
>
>
>
> On Feb 28, 2017, at 9:32 PM, ags <alfred.g...@gmail.com >
> wrote:
>
> If there is a better place for this post please move - after all, pinmux
> is for more than GPIO, right?
&g
If there is a better place for this post please move - after all, pinmux is
for more than GPIO, right?
I've been trying to figure out why pinmux-helper is needed. I've searched
and found initial RFC and followup in the early years (by Charles
Steinkuehler) and I understand the motivation (I
tl;dr
Is it correct that whenever the PRU cores access any resource through the
32-bit system but, it is subject to varying delay since the other PRU core
and even the ARM core (through the OCP slave, for instance if the ARM is
pushing data to the PRU 8k or 12k DRAM) may also be contending for
I have a project down the road that will require fast writes from PRU to
ARM/system DRAM. But I'm not there yet.
For this project, my focus is on reading data (from SD card, eMMC, USB
stick, network, etc) into DDR and then pushing it to the PRUs and then
bit-bang out precise timing (using
So I'm thinking that the problem is due to the upgrade to the newer Debian
release. Any pointers to information that may be available pointing out
potential differences in the releases in xrdp and how it authenticates?
--
For more options, visit http://beagleboard.org/discuss
---
You received
On Tuesday, February 14, 2017 at 1:55:16 PM UTC-8, RobertCNelson wrote:
>
> > I was able to mount the card without knowing the type, apparently mount
> is
> > smart enough to determine on its own. Does this mean that despite this
> > capability, each /etc/fstab entry requires full type
>
On Tuesday, February 14, 2017 at 10:31:46 AM UTC-8, RobertCNelson wrote:
>
> ...
> 1) Is there a reason that the SD card isn't in /etc/fstab to make
> mounting
> > simple for beginners - or auto-mounted? In other words, is that a bad
> idea
> > to be avoided? Perhaps an issue with trying
client. Is there any way to mount that for access from the bone
directly?
Thanks for the earlier response.
On Monday, February 13, 2017 at 11:05:33 AM UTC-8, RobertCNelson wrote:
>
> On Mon, Feb 13, 2017 at 1:02 PM, ags <alfred.g...@gmail.com >
> wrote:
> > I downloaded a new
I have a BBB A6A (2GB eMMC) running 3.8 kernel:
uname -a
Linux BBB-A6A-1 3.8.13-bone50 #1 SMP Tue May 13 13:24:52 UTC 2014 armv7l
GNU/Linux
I now also have a BBB 0C0 (4GB eMMC) and BBBWireless, both running the 4.4.
kernel:
uname -a
Linux BBB-WA5-1 4.4.30-ti-r64 #1 SMP Fri Nov 4 21:23:33
Continued review of documentation has caused me to wonder if I've missed a
fundamental error in my thinking about what is and isn't deterministic when
using the PRUs. The PRU-local 32-bit interconnect bus is itself a shared
resource. If one PRU writes to its own DRAM, and the other PRU writes
to be conflicting.
On Tuesday, February 7, 2017 at 8:12:08 PM UTC-8, Charles Steinkuehler
wrote:
>
> On 2/7/2017 8:04 PM, ags wrote:
> > I'm working on using the PRU for critical signal timing, paired with
> userland
> > code that loads data into the PRU local memory.
> >
>
I'm working on using the PRU for critical signal timing, paired with
userland code that loads data into the PRU local memory.
I've done a lot of research learning about latency wrt local and system
resources, L3/4 fabric delays, etc. In each case, I haven't seen any
difference in the
, 2014 at 6:50 PM, John Syn john...@gmail.com javascript:
wrote:
On 6/24/14, 2:52 PM, Robert Nelson robert...@gmail.com javascript:
wrote:
On Tue, Jun 24, 2014 at 4:51 PM, ags alfred.g...@gmail.com
javascript: wrote:
I will verify on my BBB.
What is the expected difference
I will verify on my BBB.
What is the expected difference between a momentary button press and an
8-second press?
On Friday, June 13, 2014 6:11:03 PM UTC-7, ags wrote:
I've read what documentation I could find about powering down the BBB.
Clearly shutdown -now in a ssh session is safe
I've read what documentation I could find about powering down the BBB.
Clearly shutdown -now in a ssh session is safe. Clearly pulling the power
is not.
Pushing the power button momentarily does nothing. Documentation says that
software is needed to sense and respond to this action. I presume
So perhaps all I'll need is a small battery (recharged when DC power is
available) attached to the pads on the BBB, and some software. I am looking
for an orderly shutdown when DC power is removed - the sole purpose of the
battery is to provide power just until the BBB can be shutdown properly.
A shortened version of this question, which I really want to understand for
this specific project and as general learning for use of Linux in embedded
systems:
What is the correct way to correctly use memory in userspace to access
registers and memory used by device drivers (specifically the
Yes, I did find those. From what I read, it seems that both aim at allowing
the BBB to run when there is no mains power. In my application, I don't
have a need for the BBB to maintain functionality when there is no power
(other than battery). I'm simply interested in ensuring a safe shutdown
Is anyone aware of someone having already done this? I haven't found
anything by searching.
On Wednesday, May 7, 2014 1:05:24 PM UTC-7, Gerald wrote:
Yes it is possible.
Gerald
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are
I've read about capes that offer batteries to operate the BBB during power
interruptions. I've read that there is a RTC in the SoC, but software does
not support powering with a button cell. I see there is a PMIC onboard, as
well as solder pads to allow attachment of a battery. I've also read
Thanks for the reply. I mostly wanted to verify that my understanding of dt
is correct, and this was confusing. I was also hoping to learn something
new (why was the specification in the .dtb file no consistent with the
actual memory being used) - which you've helped with by pointing out the
Can anyone explain how/why the dtc specification of memory size is not
being used, and/or where the actual size is coming from?
On Friday, April 25, 2014 10:02:40 PM UTC-7, ags wrote:
Not necessarily an issue. Originally I was wondering if only half of
available physical memory was being
UTC-7, RobertCNelson wrote:
On Thu, Apr 24, 2014 at 9:13 AM, ags alfred.g...@gmail.com javascript:
wrote:
Any suggestions on where to look next to figure out what's going on
here?
Seems that either something other than the device tree in file
/boot/am335x-boneblack.dts is being read
Any suggestions on where to look next to figure out what's going on here?
Seems that either something other than the device tree in file
/boot/am335x-boneblack.dts is being read at boot, or there is something
else that is overriding later on, or a boot parameter... or the memory
I don't see a dtsi in /boot. I did dtc -I dtb -O dts -o test.dts
/boot/am335x-boneblack.dtb. Looking at test.dts I still see memory {...
reg = 0x8000 0x1000 };
However, cat /proc/meminfo returns a first line of MemTotal: 510600 kB
which seems OK - I suppose. It looks like
On Sunday, April 20, 2014 1:05:03 PM UTC-7, robert.berger wrote:
Which kernel version do you use?
The original installed on flash (shipped in Jan/Feb this year):
I have BBB A6A running Angstrom distro:
Linux beaglebone 3.8.13 #1 SMP Wed Sep 4 09:09:32 CEST 2013 armv7l
GNU/Linux
--
For
Really hard to categorize this.
I have BBB A6A running Angstrom distro:
Linux beaglebone 3.8.13 #1 SMP Wed Sep 4 09:09:32 CEST 2013 armv7l GNU/Linux
I'm working on using DDR to pass information back and forth to PRU, so
looking at dts and memory assignment.
Either the dts (actually, dtb
I'm learning how to use the PRUSS, have most of it under control (or at
least not stuck). I've followed the examples posted at
github.com/beagleboard/am335x_pru_package.
Problem is understanding how to pass data in DDR. PRUSS data (shared or pru
data) makes sense - just look at
82 matches
Mail list logo
