It looks like the Oracle download page for this archive version is under
repairs (for who knows how long)
does anybody have a copy of jdk-8u191-linux-arm32-vfp-hflt.tar.gz ? Please?
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are
Thank you!
On Wednesday, December 16, 2020 at 12:34:50 PM UTC-8 jonn...@gmail.com
wrote:
> Can you ping google.com?
> Ex:
>ping google.com
>
> If this fails, then you have a network config issue.
>
> Cheers,
>
> Jon
>
> On Wed, Dec 16, 2020 at 12:1
# uname -a
Linux beaglebone 4.19.94-ti-r42 #1buster SMP PREEMPT Tue Mar 31 19:38:29
UTC 2020 armv7l GNU/Linux
# apt-get install pciutils
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
pciutils
0 upgraded,
CONFIG_PLATFORM_ARM_RTD299X = n
CONFIG_PLATFORM_ARM_SPREADTRUM_6820 = n
CONFIG_PLATFORM_ARM_SPREADTRUM_8810 = n
On Monday, December 14, 2020 at 10:26:13 AM UTC-8 maxmike wrote:
> uname:
> Linux beaglebone 4.19.94-ti-r42 #1buster SMP PREEMPT Tue Mar 31 19:38:29
> UTC 2020 armv7
> I installed driv
uname:
Linux beaglebone 4.19.94-ti-r42 #1buster SMP PREEMPT Tue Mar 31 19:38:29
UTC 2020 armv7
I installed driver per usual scripts, but have no .ko for it, only:
/usr/src/linux-headers-4.19.94-ti-r42/drivers/staging/rtl8188eu
/lib/modules/4.19.94-ti-r42/kernel/drivers/staging/rtl8188eu
I have
Thanks Robert - got 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
Then why is /sys/class/gpio unusable when it was useable in 2017? Just
wondering...
--
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
/sys/class/gpio in
root@beaglebone:~# uname -a
Linux beaglebone 4.19.94-ti-r42 #1buster SMP PREEMPT Tue Mar 31 19:38:29
UTC 2020 armv7l GNU/Linux
looks almost identical but is unusable
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are
It was using /sys/class/gpio for all gpio's
On Friday, May 8, 2020 at 10:28:24 AM UTC-7, maxmike wrote:
>
> root@niihau:~# uname -a
> Linux niihau 3.8.13-bone84 #1 SMP Sun Feb 12 02:54:13 UTC 2017 armv7l
> GNU/Linux
>
>
> On Friday, May 8, 2020 at 9:56:10 AM UTC-7
root@niihau:~# uname -a
Linux niihau 3.8.13-bone84 #1 SMP Sun Feb 12 02:54:13 UTC 2017 armv7l
GNU/Linux
On Friday, May 8, 2020 at 9:56:10 AM UTC-7, RobertCNelson wrote:
>
> On Fri, May 8, 2020 at 11:49 AM maxmike >
> wrote:
> >
> > Is that the right thing
Is that the right thing to do to freeze the code? Or is there a chance of a
mod at your end and I hold off?
--
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
Yes, now I know how to modify my code to verify this - the gpios are split
between those two directories in Debian10
--
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
I have a feeling (need to change a bunch of code to check) that gpio5 is at:
/sys/devices/platform/ocp/44e07000.gpio/gpiochip0/gpio/gpio5
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
There is a hangup when trying gpio 5 (p9.17) :
config-pin for it works, but
/sys/devices/platform/ocp/4804c000.gpio/gpiochip1/gpio/gpio5/
does not exist
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
This seems to do the trick:
/sys/devices/platform/ocp/4804c000.gpio/gpiochip1/gpio/
but I'm not 100% done.
--
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
I was hopeful to return here after weaving my system together and thank
@rcn for all his help,
but I'm not out of the woods yet.
All the pins initialize correctly (even 8.13 pwm, which is now in a new
file) but as soon
as I write the value 47 into /sys/class/gpio/export pin 8.15 disappears
Hm, gpioinfo was not listing p8.15, so just before throwing the board out
the window I decided to reboot, and now we seem to be good.
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
On Saturday, May 2, 2020 at 9:30:05 AM UTC-7, maxmike wrote:
>
> My image is : BeagleBoard.org Debian Buster IoT Image 2020-04-06
>
> On Saturday, May 2, 2020 at 9:20:30 AM UTC-7, maxmike wrote:
>>
>> I get this:
>>
>> root@beaglebone:/#
>> /opt/source/
My image is : BeagleBoard.org Debian Buster IoT Image 2020-04-06
On Saturday, May 2, 2020 at 9:20:30 AM UTC-7, maxmike wrote:
>
> I get this:
>
> root@beaglebone:/#
> /opt/source/bb.org-overlays/tools/beaglebone-universal-io/config-pin -q
> P8.15
> P8_15 Mode: gpio Direct
I get this:
root@beaglebone:/#
/opt/source/bb.org-overlays/tools/beaglebone-universal-io/config-pin -q
P8.15
P8_15 Mode: gpio Direction: pin_not_exported Value: pin_not_exported
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed
>
> I am using the version you had me install on Apr 23 (see above) .
That one fixed everything except it created this.
>
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To
Yes, it is listed, just can't use it for output:
config-pin -q 8.15
P8_15 Mode: gpio Direction: pin_not_exported Value: pin_not_exported
root@beaglebone# config-pin -l 8.15
default gpio gpio_pu gpio_pd gpio_input qep pru_ecap pruin
I thought of changing
/opt/scripts/tools/version.sh
git:/opt/scripts/:[b39ec679648a6be8f25f48bd1c9784c1fc5a0c46]
eeprom:[A335BNLTEIA03116BBBK06C2]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-04-06]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot
/opt/scripts/tools/version.sh
git:/opt/scripts/:[b39ec679648a6be8f25f48bd1c9784c1fc5a0c46]
eeprom:[A335BNLTEIA03116BBBK06C2]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-04-06]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot
> I may have one last issue: in comparing the old /boot/uEnv.txt
> for uname_r=4.4.68-ti-r110
with the new one for uname_r=4.19.94-ti-r42 the semantics are now
considerably different.
I am trying to find a way to enable GPIO47 (p8.15) aka GPIO1_15 which
should be free.
Config-pin says
> Without much longer belabouring the point, in my case gcc did not check
> my .h file; instead of checking it
for syntax (a semicolon missing in a function definition) it accepted it
and reported what the effect was of trusting it - totally incomprehensible
errors.
However, I have
Thank you Dennis.
I don't know if this is the right place to make a comment or express an
opinion, but be that as it may
I have to say that gcc needs a far better error reporting mechanism. In
java if the "compiler" encounters an
unterminated expression at end of file, it flags it
>
> I have serious problems with gcc 8.3.0:
root@beaglebone:~/evseclient/compilec# gcc -o gcctest gcctest.c
gcctest.c: In function ‘main’:
gcctest.c:15:3: warning: implicit declaration of function ‘close’; did you
mean ‘pclose’? [-Wimplicit-function-declaration]
close(memh);
^
My profuse and sincere apologies to everybody - a rotten RJ45 came off the
Internet router while I was working on the local subnet router.
Mike
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard"
root@beaglebone:/tmp# uname -a
Linux beaglebone 4.19.94-ti-r42 #1buster SMP PREEMPT Tue Mar 31 19:38:29
UTC 2020 armv7l GNU/Linux
root@beaglebone:/tmp# apt-get update
Err:1 http://deb.debian.org/debian buster InRelease
Temporary failure resolving 'deb.debian.org'
Err:2
Is there any way to get aptitude to access gdb in Buster? apt-get update
fails as does apt-get install gdb
--
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
Using BeagleBoard.org Debian Buster IoT Image 2020-04-06
On Thursday, April 23, 2020 at 4:26:03 PM UTC-7, maxmike wrote:
>
> Wow - it looks like the entire cape-universal software is now broken:
>
>
> One used to be able to do : config-pin p8.12 out
> and then test it by issuin
>
> Wow - it looks like the entire cape-universal software is now broken:
One used to be able to do : config-pin p8.12 out
and then test it by issuing config-pin p8.12 hi or lo
This is no longer possible, now the pin can only be set as pruout and hi/lo
don't work anymore.
--
For more
> OK - but here we go again with cape-universal:
root@beaglebone:~# config-pin -q p9.26
Current mode for P9_26 is: default
root@beaglebone:~# config-pin p9.26 in+
ERROR: write() to /sys/devices/platform/ocp/ocp:P9_26_pinmux/state failed,
No such device
--
For more options, visit
Rebooted and swapped routers (only one has the new network on it).
I'm getting the feeling that Debian lost control here and needs connman.
But I can't upgrade, so now I have to change
horses in midstream because the old images can't support a netmask other
than /24; not a problem if you are
I have been running BBB networking for some time using a netmask of
255.255.255.0; I now have to expand the network
to 500 hosts, so I changed the mask to 255.255.254.0 to give a network at
192.168.0.0/23. I edited /etc/network/interfaces,
but that seems to change nothing as per following;
You should be able to just connect a serial-to-usb debug cable to the six
seerial pins and watch the boot process on the screen attached to the usb.
On Tuesday, January 23, 2018 at 1:21:53 PM UTC-8, nik...@gmail.com wrote:
>
> Dear all
>
> i'd like to know if is possible to find some kind of
In 2017 Arrow sold a processor based on the AM3358BZCZA100 which is
industrial temperature, and we UL certified our product using that shipment
- now the NRTL needs us to have that processor
on there and lo-and-behold Arrow doesn't ship that anymore. We figured once
you start delivering
>
> I am in a similar situation - the red industrial boards undergo humidity
>> tests for a week, then work for about 10 minutes before failing - according
>> to the testers.
>
> I was wondering if in general it might be more reliable to run SD card
images rather than using eMMC. We don't
>
> OK, I managed to remove connman and set up wlan0 the old way. It works
> well even after reboots.
However, now: if I create a flasher image using the
tools/...//eMMC/beagleb* script and then reflash the unit
with that image i get a constant reboot cycle - machine will not come back.
I
Can't remove connman as the service will stop and ssh is dead. There might
be a way to do things after disabling connman service but I don't know what
to do.
On Friday, January 5, 2018 at 2:28:10 PM UTC-8, maxmike wrote:
>
> No - I'm trying to use wifi as wlan0; every load of a flash OS
No - I'm trying to use wifi as wlan0; every load of a flash OS image fails
to allow connects because the auto-generated connman service name on the
new machine is different.
The result is a different /var/lib/connman/* directory name.
Fortunately at least wlan0 is constant or I could never do
In Jessie we have connman - and it causes severe problems if you try to
build a number
of identical embedded systems, connman will assign a new service name to
each processor.
So the settings directory has to be handcrafted separately for each. Even
if you have a static
ip which is the same in
The file shows a line :* driver ecap already registered - aborting **what
is that please?*
On Thursday, January 4, 2018 at 5:40:29 PM UTC-8, maxmike wrote:
>
> The problem is here:
>
> wlan0 Link encap:Ethernet HWaddr 50:65:83:d1:aa:fa
> UP BROADCAST MULTICAST DY
The problem is here:
wlan0 Link encap:Ethernet HWaddr 50:65:83:d1:aa:fa
UP BROADCAST MULTICAST DYNAMIC MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0
I have a flasher image for a BBBW that loads just fine and works, but when
I reboot,
the network will no longer see the board. Comes back with "unreachable
host".
Can someone please point me at any particular file/setup I should look at?
I'm really in a bind on this one. Serial log attached.
/httpredir.debian.org_debian_dists_jessie_main_binary-armhf_Packages.gz
is not what the server reported 8864066 8864371
On Monday, December 25, 2017 at 3:09:56 PM UTC-8, maxmike wrote:
>
> I'm using cape-universal.
>
> On Monday, December 25, 2017 at 3:05:59 PM UTC-8, maxmike wrot
I'm using cape-universal.
On Monday, December 25, 2017 at 3:05:59 PM UTC-8, maxmike wrote:
>
> Nah, that doesn't work either AFAIK:
>
> I have kernel: *4.4.68-ti-r110 #1 SMP*
> I enable pwm as:* bash -c 'echo 1 > /sys/class/pwm/pwmchip4/export'*
> Then I set ttyO4 tx as:
Nah, that doesn't work either AFAIK:
I have kernel: *4.4.68-ti-r110 #1 SMP*
I enable pwm as:* bash -c 'echo 1 > /sys/class/pwm/pwmchip4/export'*
Then I set ttyO4 tx as: */usr/bin/config-pin P9_13 uart*
and when the app runs it gives me a file not found bleat. Indeed the pwm
files are not
Yes, Linux beaglebone 4.4.68-ti-r110 #1 SMP Wed Jun 21 04:31:35 UTC 2017
armv7l GNU/Linux has some unexpected problems with UART's
We have a bunch of pcb's coming in and all of a sudden TTYO4 (hardwired)
doesn't work. Cannot receive characters. Terminals were checked as active.
Program worked
We need to do something similar and I'm trying to find a way to reduce the eth0
/ wlan0 speed to 10 Mb, but it looks as though ethtool will not work in Debian
on the Beaglebone Black. Is this a shortcoming of drivers or the hardware?
--
For more options, visit http://beagleboard.org/discuss
I wanted to test removing all default iptable rules and replacing them with
my own, using ufw.
I have a very simple LAN that just needs 1/2 dozen ports, and iptable
defaults are causing major conflicts when I try blocking IP's.
So I created the ufw rule: *ufw allow 22/tcp* then I issued:
The boot script is among other things trying to use pin 8.13 for pwm.
--
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,
I have a working Linux beaglebone 4.4.68-ti-r110 #1 SMP Wed Jun 21 04:31:35
UTC 2017 armv7l GNU/Linux
that does not use connman (uses /etc/network/interfaces) and successfully
executes a boot script in init.d on a BBB.
When I try the same on a BBBW where connman is the only boot option, the
I cannot use the existing image because I have a need to allow users to
dynamically change the ip address of a
machine depending on installation parameters and this is really difficult
to script with connman, unlike the old network
manager. Replacing connman has not worked - some critical
Just got into infinite trouble - need to use industrial temp boards for
production and I thought I could
flash the bone80 production image onto these machines, but no joy.
They use Linux beaglebone 4.4.68-ti-r110 #1 SMP Wed Jun 21 04:31:35 UTC
2017 armv7l GNU/Linux
and the flashing process
I have to revert to bone84 to get these boards out to production and just
found a problem with cape-universal.
I'd like to know how to install it at boot time.
*uEnv.txt:*
#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0
uname_r=3.8.13-bone84
#uuid=
#dtb=
If you have another wired network connection when you boot the BBBW then
the wlan0 may not come up. Better to boot with just wifi, then plug in
cable.
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
If you want to deliver a product based on the BBBW the user (who is probably
busy or not technical) has to unpack the service as a hash cipher using
connmanctl, then they can set up a static IP. They can't just use the service
name. The result is that if you want to shield them from connman
I have cape-universal set up:
0: PF -1
1: PF -1
2: PF -1
3: PF -1
4: P-O-L- 0 Override Board Name,00A0,Override Manuf,univ-emmc
root@beaglebone:~# config-pin -q p8.13
P8_13 Mode: pwm
So I configure pwm for pwmchip4 :
sh -c "echo 0 > /sys/class/pwm/pwmchip4/export"
Thereis also the issue I have, where I allow unsophisticated users to
dynamically change the static IP address.
With ifconfig I can give them a script, but connmanctl doesn't make that as
simple.
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because
:46 AM, maxmike <maxmi...@gmail.com
> > wrote:
> > Thanks - I got the BBBW to run but why is it such a bear to get a root
> login
> > on Debian.
> > I can access the machine with a "debian" login, then I used su to login
> as
> > root, which
Thanks - I got the BBBW to run but why is it such a bear to get a root
login on Debian.
I can access the machine with a "debian" login, then I used su to login as
root, which works, but then,
when I try to login as user root with the same password I get "access
denied."
--
For more options,
Is it possible to get a stable RCN image for the BBBW that is headless? I'd
like to avoid the burden of graphics.
--
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
Thank you Alexander - how do you load them?
I just do a dd from my backup image on the USB stick onto /dev/mmcblk1,
running from a bone40 sd.
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard"
So we can't move a 2G quasi-production image from std BBB to the industrial
4G BBB? I have to build a whole new image?
And - "probably" work fine? Not exactly a smooth upgrade path. How do I
even go from Debian 3.8.13-bone50 to whatever
3/19 is without having to do a selective backup. Is that an
Since Robert isn't saying I assume he's talking to the factory - I'll ship
them back.
--
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
A serial log? Haven't done that in years - need to find/dust off the
hardware cables for that. Will try - thanks.
On Monday, March 20, 2017 at 10:55:25 AM UTC-7, RobertCNelson wrote:
>
> Can you share your serial boot log?
>
> My guess, it's the newer eMMC used on the board..
>
> around
On Tuesday, January 19, 2016 at 5:02:16 AM UTC-8, kgkyt...@gmail.com wrote:
>
>
>
>
>
>
> Hi, ALL
>
> I found some BeagleBoard.
>
> That is BeagleBone Black Industrial 4G provided by elemnt14 as below:
>
>
>
> -element14 BeagleBone Black Industrial 4G
>
>
>
I have now ordered extended temp. BBB's from two different sources and both
failed to work.
We use them by first loading Debian 3.8.13-bone50 via the USB stick.
In one case it failed to boot (just power light on), in the other it
sometimes power boots, sometimes not and
even if it boots, it
I don~t think Robert recompiled the kernel. I am using 3.8.13 Debian.
--
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,
Robert, when using rtc0, did you also use .../i2c-adapter/i2c-0... ?
--
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,
O
Well, the datasheet shows VO has a worse case voltage range from 250mv to
VCC-0.35v. Is this consistent with your measurements?
Yes - actually I'm seeing 3.3V to 0.
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to
On Tuesday, January 20, 2015 at 5:45:03 AM UTC-8, mickeyf wrote:
Being a software guy I tend to be quick to use a sledgehammer, but if push
came to shove would a buffer before the comparator screw things up?
Yeah, it's that or parallel the entire path from signal source. I have to
say,
On Tuesday, January 20, 2015 at 8:01:40 AM UTC-8, TJF wrote:
Hi software guy,
why don't you drop the hardware and use the sampled ADC value to trigger
the interrupt?
The interrupt has to occur waaay before the adc has a chance to measure
the value that caused it.
I.e. it has to be
I have the output of an op amp go directly to the BBB adc and the values
are read correctly.
But, the same wire is going to a comparator to generate interrupts.
It looks like the comparator is not firing all the way to ground because of
the adc drag.
I thought of placing a 1K resistor from the
I am powering a DC/DC converter on my cape with SYS_5V and just noticed
that on toggling the
power button the machine does turn off, but there's still about 2V on
SYS_5V - why?
Using a 2A regulated power supply to power the unit.
--
For more options, visit http://beagleboard.org/discuss
---
Can't figure out why people trash Java (my language is better than yours
thing;) the key driver of Java is its library - it has no peer!
On Thursday, July 31, 2014 9:15:04 AM UTC-7, William Hermans wrote:
Datenheld, My point was why use a language, when if key feature is taken
away . . .
Trying to make an embedded BBB into a product requires securing it. If it
enjoys physical security there are some standard procedures you can use
and quite a bit of material on the Web. However, there are 3 entry points
to a physically exposed machine: the USB client port, the SD port
and the
Forgot to add the ISP header; that may be tied to a tty port that can be
disabled. Still working on that.
--
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
be hijacked at boot time.
In order to secure these two devices, I think you'd have to do so from
within uboot.
On Mon, Aug 25, 2014 at 10:25 AM, John Syn john...@gmail.com
javascript: wrote:
From: maxmike maxmi...@gmail.com javascript:
Reply-To: beagl...@googlegroups.com javascript
OK - but where do we go from here? uEnv.txt is out, device tree is out and
everybody has to hack their own uboot to enable boot security?
I mean, when considering embedded Unix surely somebody that knows more
about this than your average app-oriented developer could
provide a modifiable boot
Aaah - thanks: a rational answer to an irrational question.
On Monday, August 25, 2014 12:57:32 PM UTC-7, RobertCNelson wrote:
On Mon, Aug 25, 2014 at 2:53 PM, maxmike maxmi...@gmail.com javascript:
wrote:
OK - but where do we go from here? uEnv.txt is out, device tree is out
Thanks to everybody that pitched in here - I see the error of my ways;
after looking at the TI boot pages I see we are indeed at the mercy of TI's
boot rom.
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
I'm setting up cape-universal on a production machine - minor item,
but I noticed the syntax *in+* works whereas the equivalent *in_pu* does
not.
On Saturday, May 3, 2014 3:01:51 PM UTC-7, Charles Steinkuehler wrote:
You beat me to the answer...use the config-pin utility! :)
Let me know if
, maxmike wrote:
No need to modify cape-universal. Since I'm on the clock what I'll do
is
remove the pwm pins I need from
cape-universal .dts and recompile; then load the perfectly good,
existing
/lib/firmware entries for pwm.
That will work, of course, but the whole reason
.
On 6/12/2014 2:12 PM, maxmike wrote:
Thank you - unfortunately the boot order of the pwm indexes as applied
to pins is random (i.e. pin P8_13 is 6 one day and something else
another.)
On Thursday, June 5, 2014 1:23:50 PM UTC-7, Charles Steinkuehler wrote:
On 6/5/2014 12:11 PM
Yes - same problem here; I just added the echo $SLOTS script to
/etc/profile to walk around all 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
No need to modify cape-universal. Since I'm on the clock what I'll do is
remove the pwm pins I need from
cape-universal .dts and recompile; then load the perfectly good, existing
/lib/firmware entries for pwm.
I assume the published cape-universal .dts is in fact valid:
On Thursday, June 5, 2014 10:12:01 AM UTC-7, Charles Steinkuehler wrote:
On 6/5/2014 11:52 AM, maxmike wrote:
No need to modify cape-universal. Since I'm on the clock what I'll do is
remove the pwm pins I need from
cape-universal .dts and recompile; then load the perfectly good
Jason, could you please let me know how you got cape-universal to let you
do pwm?
If I use the am33xx_pwm and bone_pwm_P9_21 dtbo's I can see
/sys/devices/ocp.3/pwm_test_
P9_21.11 period polarity and run files.
If I use the cape-universal instead and config-pin P9_21 as pwm
all I get is a
I loaded this on Debian 3.8.13 and I can use it for gpio, but when I change
P8_13 to use pwm
there are no duty or period or polarity files anywhere. Even after a reboot.
Could somebody please give me a hint.
--
For more options, visit http://beagleboard.org/discuss
---
You received this
finding
the period, polarity, run files.
On Sunday, June 1, 2014 1:12:22 PM UTC-7, maxmike wrote:
Charles, all seems to be as advertise with the cape-universal, but it
would be useful to get a hint
of where things like period and frequency files live for pwm so they
can be changed within
93 matches
Mail list logo
