from:"Johan Henselmans"

Re: [beagleboard] Damaged eMMC, does not boot from SD-Card automagically

2019-12-04 Thread Johan Henselmans

Thanks for the reply. 

I looked at the schematics pdf that you referred to and understood that r93 
and r68 have to do with the boot-order, and that setting r68 low (as is 
actually done by pressing the uSD boot button)  would make the bootorder 
different. 

Is that possible in software, or do I have to do that by settting up some 
kind of wiring?

On Tuesday, November 26, 2019 at 6:38:32 AM UTC+1, Jim F wrote:
>
> Should be easy to do. Change the boot configuration so that you don't try 
> to boot from mmc1.
>
> I think if it's a black, it should be r68 out, r93 in. Look up that 
> platform manual to see the boot options. Chip is Am3358.
>
> Here a handy chunk of schematic to help with that. 
> https://e2e.ti.com/support/processors/f/791/t/661109?AM3358-SYSBOOT-configuration
>
> J
>
> On Mon, Nov 25, 2019, 10:16 PM Johan Henselmans  > wrote:
>
>>
>> I have a BeagleBone Wireless with a damaged eMMC card.
>>
>> I got mmcutils from 
>> https://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc-utils.git, and 
>> mmc extcsd read /dev/mmcblk1
>> gives me this for the lifetime estimation:
>> eMMC Life Time Estimation A [EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_A]: 0x0b
>> eMMC Life Time Estimation B [EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_B]: 0x08
>> Not good, should be something like 0x01 (less that 10 percent), according 
>> to
>> https://www.cnx-software.com/2019/08/16/wear-estimation-emmc-flash-memory/
>>
>> Also, looking at the devices I do not see a mmcbl1p1.
>> root@beaglebone:~# lsblk
>> NAME MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
>> mmcblk0  179:00 14.9G  0 disk 
>> └─mmcblk0p1  179:10  3.5G  0 part /
>> mmcblk1  179:80  3.6G  0 disk 
>> mmcblk1boot0 179:16   02M  1 disk 
>> mmcblk1boot1 179:24   02M  1 disk 
>> mmcblk1rpmb  179:32   0  512K  0 disk 
>>
>> I am trying to boot the beaglebone from SD-card for the moment, until i 
>> get another one, but it will only boot when i use press the power and the 
>> boot button next to the sd-card.
>>
>> I tried to get rid of the boot flag on /dev/mmcblk1, as per instructions 
>> on
>> https://www.erdahl.io/2016/12/beaglebone-black-booting-from-sd-by.html
>> but I get errors getting to the eMMC: 
>> fdisk: cannot open /dev/mmcblk1: Input/output error
>>
>> Is there any way I can disable the eMMC somehow, so that it does not 
>> interfere with the booting of the sd-card and automatically boots the 
>> sd-card?
>>
>> Kind Regards,
>> Johan Henselmans
>>
>> -- 
>> 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 beagl...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/42459d9f-02f0-494c-b0d7-f2778098dae0%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/beagleboard/42459d9f-02f0-494c-b0d7-f2778098dae0%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/cc21d80d-0037-48e9-9483-3fd331935984%40googlegroups.com.

Re: [beagleboard] Damaged eMMC, does not boot from SD-Card automagically

2019-12-04 Thread Johan Henselmans

The eMMC is definitely borked. I tried several times to get the eMMC to do 
anything with it. 
mmc gives the following result
mmc extcsd read /dev/mmcblk1 | grep "Life"  | awk '{print $6,$7}'
[EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_A]: 0x0b
[EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_B]: 0x08

As far as I understood, 0x01 means dead cell is between 0 and 10 percent. 
In that understanding 0x0b means that between 100 and 110 percent is dead, 
and 0x08 means between 70 and 80 percent is dead. 

Thanks for bootloadertip, I did 
sudo dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=1
After that the machine booted off the sdcard without having to press the 
boot button, as the Beaglebone could not find a bootloader on the eMMC. 



On Tuesday, November 26, 2019 at 2:54:25 PM UTC+1, Graham Haddock wrote:
>
> It might not be an eMMC failure.
> Could just be an old bootloader.
> Did you update the bootpoader in the eMMC?
>
>
> https://elinux.org/EBC_Exercise_07_Updating_an_Old_U-Boot#Fixing_the_Problem.2C_Blow_Away_Old_Boot_Loader
>
> --- Graham
>
> ==
>
> On Monday, November 25, 2019 at 11:38:32 PM UTC-6, Jim F wrote:
>>
>> Should be easy to do. Change the boot configuration so that you don't try 
>> to boot from mmc1.
>>
>> I think if it's a black, it should be r68 out, r93 in. Look up that 
>> platform manual to see the boot options. Chip is Am3358.
>>
>> Here a handy chunk of schematic to help with that. 
>> https://e2e.ti.com/support/processors/f/791/t/661109?AM3358-SYSBOOT-configuration
>>
>> J
>>
>> On Mon, Nov 25, 2019, 10:16 PM Johan Henselmans  
>> wrote:
>>
>>>
>>> I have a BeagleBone Wireless with a damaged eMMC card.
>>>
>>> I got mmcutils from 
>>> https://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc-utils.git, and 
>>> mmc extcsd read /dev/mmcblk1
>>> gives me this for the lifetime estimation:
>>> eMMC Life Time Estimation A [EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_A]: 0x0b
>>> eMMC Life Time Estimation B [EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_B]: 0x08
>>> Not good, should be something like 0x01 (less that 10 percent), 
>>> according to
>>>
>>> https://www.cnx-software.com/2019/08/16/wear-estimation-emmc-flash-memory/
>>>
>>> Also, looking at the devices I do not see a mmcbl1p1.
>>> root@beaglebone:~# lsblk
>>> NAME MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
>>> mmcblk0  179:00 14.9G  0 disk 
>>> └─mmcblk0p1  179:10  3.5G  0 part /
>>> mmcblk1  179:80  3.6G  0 disk 
>>> mmcblk1boot0 179:16   02M  1 disk 
>>> mmcblk1boot1 179:24   02M  1 disk 
>>> mmcblk1rpmb  179:32   0  512K  0 disk 
>>>
>>> I am trying to boot the beaglebone from SD-card for the moment, until i 
>>> get another one, but it will only boot when i use press the power and the 
>>> boot button next to the sd-card.
>>>
>>> I tried to get rid of the boot flag on /dev/mmcblk1, as per instructions 
>>> on
>>> https://www.erdahl.io/2016/12/beaglebone-black-booting-from-sd-by.html
>>> but I get errors getting to the eMMC: 
>>> fdisk: cannot open /dev/mmcblk1: Input/output error
>>>
>>> Is there any way I can disable the eMMC somehow, so that it does not 
>>> interfere with the booting of the sd-card and automatically boots the 
>>> sd-card?
>>>
>>> Kind Regards,
>>> Johan Henselmans
>>>
>>> -- 
>>> 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 beagl...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/beagleboard/42459d9f-02f0-494c-b0d7-f2778098dae0%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/beagleboard/42459d9f-02f0-494c-b0d7-f2778098dae0%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>

-- 
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/7572e507-b07a-45b6-bc83-7f8bf4c5bbdf%40googlegroups.com.

[beagleboard] Damaged eMMC, does not boot from SD-Card automagically

2019-11-25 Thread Johan Henselmans


I have a BeagleBone Wireless with a damaged eMMC card.

I got mmcutils from 
https://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc-utils.git, and 
mmc extcsd read /dev/mmcblk1
gives me this for the lifetime estimation:
eMMC Life Time Estimation A [EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_A]: 0x0b
eMMC Life Time Estimation B [EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_B]: 0x08
Not good, should be something like 0x01 (less that 10 percent), according to
https://www.cnx-software.com/2019/08/16/wear-estimation-emmc-flash-memory/

Also, looking at the devices I do not see a mmcbl1p1.
root@beaglebone:~# lsblk
NAME MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
mmcblk0  179:00 14.9G  0 disk 
└─mmcblk0p1  179:10  3.5G  0 part /
mmcblk1  179:80  3.6G  0 disk 
mmcblk1boot0 179:16   02M  1 disk 
mmcblk1boot1 179:24   02M  1 disk 
mmcblk1rpmb  179:32   0  512K  0 disk 

I am trying to boot the beaglebone from SD-card for the moment, until i get 
another one, but it will only boot when i use press the power and the boot 
button next to the sd-card.

I tried to get rid of the boot flag on /dev/mmcblk1, as per instructions on
https://www.erdahl.io/2016/12/beaglebone-black-booting-from-sd-by.html
but I get errors getting to the eMMC: 
fdisk: cannot open /dev/mmcblk1: Input/output error

Is there any way I can disable the eMMC somehow, so that it does not 
interfere with the booting of the sd-card and automatically boots the 
sd-card?

Kind Regards,
Johan Henselmans

-- 
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/42459d9f-02f0-494c-b0d7-f2778098dae0%40googlegroups.com.

Re: [beagleboard] Beaglebone Green/Black Java for Linux ARM

2018-01-23 Thread Johan Henselmans

Robert, there is a new oracle jvm in town:


http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

http://download.oracle.com/otn-pub/java/jdk/8u162-b12/0da788060d494f5095bf8624735fa2f1/jdk-8u162-linux-arm32-vfp-hflt.tar.gz?AuthParam=1516697271_80e178dcd68ec5b82f12bd7c88eb3c25


On Wednesday, December 27, 2017 at 7:29:34 PM UTC+1, RobertCNelson wrote:
>
> On Wed, Dec 27, 2017 at 6:32 AM, Johan Henselmans 
> <johan.he...@gmail.com > wrote: 
> > Robert, do you still follow the Oracle java updates? 
>
> Not really.. only if people ask.. 
>
> > They have not been updated in a while. 
> > 
> > I am using these to run OpenHab on a Beaglebone, as the openjdk version 
> > seems to be a lot slower. 
> > 
> > Anyone else experiences with speed differences between openjdk and 
> oracle 
> > jdk? 
>
> Well i updated Java 8 for you: 
>
>
> https://github.com/rcn-ee/repos/commit/20dac792c418534741f5a515eba68674bfa37a35
>  
>
> Just "sudo apt update ; sudo apt upgrade" to get it.. 
>
> Otherwise it looks like Java 9 is now a no go for ARM: 
>
>
> http://www.oracle.com/technetwork/java/javase/downloads/jdk9-downloads-3848520.html
>  
>
> 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/2b11a1a7-36b3-479e-a847-14a04fef222c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Trouble getting bluetooth runnning (kernel 4.14, or kernel 4.4) on BBW

2018-01-15 Thread Johan Henselmans

Manufacturer: Cambridge Silicon Radio (10)
=



on 4.14:
=
hci0:Type: Primary  Bus: USB
BD Address: 00:15:83:6A:2F:C3  ACL MTU: 310:10  SCO MTU: 64:8
UP RUNNING 
RX bytes:658 acl:0 sco:0 events:44 errors:0
TX bytes:2664 acl:0 sco:0 commands:43 errors:0
Features: 0xff 0xff 0x8f 0xfe 0xdb 0xff 0x5b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
Link policy: RSWITCH HOLD SNIFF PARK 
Link mode: SLAVE ACCEPT 
Name: 'woodyamsterdam0'
Class: 0x00
Service Classes: Unspecified
Device Class: Miscellaneous, 
HCI Version: 4.0 (0x6)  Revision: 0x1d86
LMP Version: 4.0 (0x6)  Subversion: 0x1d86
Manufacturer: Cambridge Silicon Radio (10)
=

on 4.4:
=
hci0:Type: Primary  Bus: USB
BD Address: 00:15:83:6A:2F:C3  ACL MTU: 310:10  SCO MTU: 64:8
UP RUNNING 
RX bytes:1232 acl:0 sco:0 events:74 errors:0
TX bytes:2858 acl:0 sco:0 commands:74 errors:0
Features: 0xff 0xff 0x8f 0xfe 0xdb 0xff 0x5b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
Link policy: RSWITCH HOLD SNIFF PARK 
Link mode: SLAVE ACCEPT 
Name: 'woodyamsterdam0 #1'
Class: 0x00
Service Classes: Unspecified
Device Class: Miscellaneous, 
HCI Version: 4.0 (0x6)  Revision: 0x1d86
LMP Version: 4.0 (0x6)  Subversion: 0x1d86
Manufacturer: Cambridge Silicon Radio (10)
=


Kind Regards, 
Johan Henselmans

-- 
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/d63ebff3-e0e2-49d5-ac36-b3a9fb448877%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Beaglebone Green/Black Java for Linux ARM

2017-12-28 Thread Johan Henselmans

Thanks!

The missing java 9 distribution is odd, I am sure I saw a version 9 arm 
version a few days ago. 

Kind Regards, 
Johan

On Wednesday, December 27, 2017 at 7:29:34 PM UTC+1, RobertCNelson wrote:
>
> On Wed, Dec 27, 2017 at 6:32 AM, Johan Henselmans 
> <johan.he...@gmail.com > wrote: 
> > Robert, do you still follow the Oracle java updates? 
>
> Not really.. only if people ask.. 
>
> > They have not been updated in a while. 
> > 
> > I am using these to run OpenHab on a Beaglebone, as the openjdk version 
> > seems to be a lot slower. 
> > 
> > Anyone else experiences with speed differences between openjdk and 
> oracle 
> > jdk? 
>
> Well i updated Java 8 for you: 
>
>
> https://github.com/rcn-ee/repos/commit/20dac792c418534741f5a515eba68674bfa37a35
>  
>
> Just "sudo apt update ; sudo apt upgrade" to get it.. 
>
> Otherwise it looks like Java 9 is now a no go for ARM: 
>
>
> http://www.oracle.com/technetwork/java/javase/downloads/jdk9-downloads-3848520.html
>  
>
> 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/b497d23e-988c-4f91-81d7-7a039ab7eb7f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Threading for Beagle Bone

2017-12-27 Thread Johan Henselmans

There is gpio-watch from https://github.com/larsks/gpio-watch. Is uses 
EPoll, only runs on Linux, not on *BSD (which is using kqueue), have a look.

Kind Regards, 
Johan Henselmans

On Monday, December 25, 2017 at 1:34:31 PM UTC+1, Rohit Karkala wrote:
>
> Hello everyone, 
>
> I want to implement the threading function for GPIO Interrupt in C 
> Program. 
>
> Can anyone help with the code or reference . 
>
>
>
>

-- 
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/5c6028e9-10c8-40d0-8973-f66a9e023281%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Beaglebone Green/Black Java for Linux ARM

2017-12-27 Thread Johan Henselmans

Robert, do you still follow the Oracle java updates?

They have not been updated in a while.

I am using these to run OpenHab on a Beaglebone, as the openjdk version 
seems to be a lot slower. 

Anyone else experiences with speed differences between openjdk and oracle 
jdk?

Kind Regards, 
Johan 


On Wednesday, September 23, 2015 at 10:48:11 PM UTC+2, RobertCNelson wrote:
>
> On Wed, Sep 23, 2015 at 3:30 PM, Jason Kridner  > wrote: 
> > What steps did you use to install Java? I think there are multiple 
> > builds/packages for Java 8 update 60 for ARM. 
> > 
> > On Wed, Sep 16, 2015 at 12:52 AM, Adam Vadala-Roth 
> >  wrote: 
> >> 
> >> Hello, 
> >> 
> >> I'm new to using the Beaglebone. I decided to use it on one of my 
> current 
> >> projects. When I heard about the Beaglebone Green I decided that would 
> be 
> >> the one I get since I have no need for HDMI in my application. Anyways 
> the 
> >> BBG for me is functioning as a way to deploy a java application that 
> >> communicates with the cloud and custom electrical hardware via 
> USB/WiFi. 
> >> 
> >> So anyways I need Java to run my application as a packaged .JAR 
> >> executable, so I installed the Linux ARM Java manually, by downloading 
> it on 
> >> my local machine and transfering it to the /temp folder, I unpacked it 
> into 
> >> the correct directory and set the PATH variable to make it available 
> for 
> >> use. I checked the Java version to make sure I installed it correctly. 
> Next 
> >> off I installed Maven and Gradle, I tested them by checking their 
> version 
> >> and confirmed they installed successfully. The reason I need all this 
> stuff 
> >> is because a piece of software called BowlerStudio I'm using in my main 
> >> application runs off Java 8 and requires Maven and Gradle to build. 
> When I 
> >> attempt to build the application from source its seems to have an issue 
> >> locating the JavaFX Libraries that are supposed to be included in the 
> latest 
> >> version of Java for ARM, the latest version and the version I intalled 
> was 
> >> Java 8 update 60 for ARM. Any idea why its unable to find JavaFX ? 
> >> 
>
> I've been slacking on java.. 
>
> Oracle Java 8 update 33 was the version i had packaged for 
> "oracle-java8-installer" 
>
> Right now i'm building the install for Oracle Java 8 update 60.. 
>
> I've noticed Oracle Java 9 Beta 81 is now out, does anyone want that 
> packaged? 
>
> 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/a270718f-ab2a-48a1-96ea-f8e6a91a6f36%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Stretch pwm difference

2017-12-08 Thread Johan Henselmans

OK, found out. Note to future self:

If you want /sys/clas/pwm/pwm-6:0, do an 
echo  0 > /sys/class/pwm/pwmchip6/export

I misunderstood that echo 0> /sys/class/pwm/pwmchip3/export was an unexport 
to reset things. 

To remove that channel, of course do a 
echo 0> /sys/class/pwm/pwmchip6/unexport
and
echo 1> /sys/class/pwm/pwmchip6/unexport

After that, first do some pwm settings, eg:
echo 500 > /sys/class/pwm/pwmchip6/pwm-6\:0/period
echo 500 > /sys/class/pwm/pwmchip6/pwm-6\:0/duty_cycle
echo 500 > /sys/class/pwm/pwmchip6/pwm-6\:1/period
echo 500 > /sys/class/pwm/pwmchip6/pwm-6\:1/duty_cycle

and after that you can do 

echo -n "1" > /sys/class/pwm/pwmchip6/pwm-6\:0/enable
echo -n "1" > /sys/class/pwm/pwmchip6/pwm-6\:1/enable

to have an effect. 

If you first enable the stuff before doing any setttings on period or 
duty_cycle, the kernel will not allow it.



On Thursday, December 7, 2017 at 10:35:08 AM UTC+1, Johan Henselmans wrote:
>
> I am trying to get p8_45 and p8_49 to run PWM2A and PWM2B signals. I am 
> running 4.14.3-ti-r14 with 
> enable_uboot_overlays=1
> enable_uboot_cape_universal=1
> disable_uboot_overlay_video=1
>
>
> According to the SRM that is possible, When I do an export to 
> echo 1 > /sys/class/pwm/pwmchip6/export
> , I only get /sys/clas/pwm/pwm-6:1
> With 
> echo 1 > /sys/class/pwm/pwmchip3/export
> , I get /sys/clas/pwm/pwm-3:0 and /sys/clas/pwm/pwm-3:1. 
>
> Why is that? Should I do anything else?
>
>
>
> On Friday, September 29, 2017 at 11:18:26 PM UTC+2, RobertCNelson wrote:
>>
>> On Fri, Sep 29, 2017 at 3:19 PM, William Hermans <yyr...@gmail.com> 
>> wrote: 
>> > Robert, 
>> > 
>> > Ok I think I see what you mean now( fully ). With universal IO and the 
>> > generic startup script enabled. I did see something similar to what you 
>> were 
>> > saying. However, if one disables both universal IO, and the generic 
>> startup 
>> > script, then writes their own custom overlay for all 3 of the PWM chips 
>> that 
>> > are dual channel. You get a structure like this: 
>> > 
>> > root@wgd:~# ls /sys/class/pwm/pwmchip*/ |grep pwm 
>> > /sys/class/pwm/pwmchip0/: 
>> > npwm 
>> > /sys/class/pwm/pwmchip2/: 
>> > npwm 
>> > /sys/class/pwm/pwmchip4/: 
>> > npwm 
>> > 
>> > This is consistent across multiple images on the same board. In this 
>> case a 
>> > 4G beaglebone black( rev C ). But at the same time as you can see from 
>> the 
>> > output above. The two PWM channels for each PWM chip are not enabled. 
>> In 
>> > Jessie, these are populated automatically at boot. How can I make that 
>> > happen in stretch ? I could write a script, but I think that is done 
>> > automatically through cape_manager in Jessie ? 
>>
>> What's happening in v4.4.x, the pwm's are now in the correct order, if 
>> you look at v4.4.x: (pwm came before ecap) 
>>
>> #4.4.88-ti-r129 
>> pwmchip0 -> 
>> ../../devices/platform/ocp/4830.epwmss/48300200.pwm/pwm/pwmchip0 
>> pwmchip2 -> 
>> ../../devices/platform/ocp/48302000.epwmss/48302200.pwm/pwm/pwmchip2 
>> pwmchip4 -> 
>> ../../devices/platform/ocp/48304000.epwmss/48304200.pwm/pwm/pwmchip4 
>> pwmchip6 -> 
>> ../../devices/platform/ocp/4830.epwmss/48300100.ecap/pwm/pwmchip6 
>> pwmchip7 -> 
>> ../../devices/platform/ocp/48304000.epwmss/48304100.ecap/pwm/pwmchip7 
>>
>> In v4.9.x: (since ecap are considered pwm's) they are now in the order 
>> of the register address: 
>>
>> pwmchip0 -> 
>> ../../devices/platform/ocp/4830.epwmss/48300100.ecap/pwm/pwmchip0 
>> pwmchip1 -> 
>> ../../devices/platform/ocp/4830.epwmss/48300200.pwm/pwm/pwmchip1 
>> pwmchip3 -> 
>> ../../devices/platform/ocp/48302000.epwmss/48302200.pwm/pwm/pwmchip3 
>> pwmchip5 -> 
>> ../../devices/platform/ocp/48304000.epwmss/48304100.ecap/pwm/pwmchip5 
>> pwmchip6 -> 
>> ../../devices/platform/ocp/48304000.epwmss/48304200.pwm/pwm/pwmchip6 
>>
>> In your case, you only want the dual mode "pwm", (48300200.pwm, 
>> 48302200.pwm, 48304200.pwm), you shouldn't blindly enable the 
>> "pwmchip0,2,4" as they are dynamic.  You should grep the symlink 
>> first. 
>>
>> Ps, watch out for v4.11.x too: 
>>
>> #v4.4.x/v4.9.x 
>> /sys/class/pwm/pwmchip1/: 
>> drwxr-xr-x 3 root root0 Sep 29 21:06 pwm0 
>> drwxr-xr-x 3 root root0 Sep 29 21:06 pwm1 
>>
>> #v4.11.x+ 
>>
>> /sys/class/pwm/pwm

Re: [beagleboard] Stretch pwm difference

2017-12-07 Thread Johan Henselmans

I am trying to get p8_45 and p8_49 to run PWM2A and PWM2B signals. I am 
running 4.14.3-ti-r14 with 
enable_uboot_overlays=1
enable_uboot_cape_universal=1
disable_uboot_overlay_video=1


According to the SRM that is possible, When I do an export to 
echo 1 > /sys/class/pwm/pwmchip6/export
, I only get /sys/clas/pwm/pwm-6:1
With 
echo 1 > /sys/class/pwm/pwmchip3/export
, I get /sys/clas/pwm/pwm-3:0 and /sys/clas/pwm/pwm-3:1. 

Why is that? Should I do anything else?



On Friday, September 29, 2017 at 11:18:26 PM UTC+2, RobertCNelson wrote:
>
> On Fri, Sep 29, 2017 at 3:19 PM, William Hermans  > wrote: 
> > Robert, 
> > 
> > Ok I think I see what you mean now( fully ). With universal IO and the 
> > generic startup script enabled. I did see something similar to what you 
> were 
> > saying. However, if one disables both universal IO, and the generic 
> startup 
> > script, then writes their own custom overlay for all 3 of the PWM chips 
> that 
> > are dual channel. You get a structure like this: 
> > 
> > root@wgd:~# ls /sys/class/pwm/pwmchip*/ |grep pwm 
> > /sys/class/pwm/pwmchip0/: 
> > npwm 
> > /sys/class/pwm/pwmchip2/: 
> > npwm 
> > /sys/class/pwm/pwmchip4/: 
> > npwm 
> > 
> > This is consistent across multiple images on the same board. In this 
> case a 
> > 4G beaglebone black( rev C ). But at the same time as you can see from 
> the 
> > output above. The two PWM channels for each PWM chip are not enabled. In 
> > Jessie, these are populated automatically at boot. How can I make that 
> > happen in stretch ? I could write a script, but I think that is done 
> > automatically through cape_manager in Jessie ? 
>
> What's happening in v4.4.x, the pwm's are now in the correct order, if 
> you look at v4.4.x: (pwm came before ecap) 
>
> #4.4.88-ti-r129 
> pwmchip0 -> 
> ../../devices/platform/ocp/4830.epwmss/48300200.pwm/pwm/pwmchip0 
> pwmchip2 -> 
> ../../devices/platform/ocp/48302000.epwmss/48302200.pwm/pwm/pwmchip2 
> pwmchip4 -> 
> ../../devices/platform/ocp/48304000.epwmss/48304200.pwm/pwm/pwmchip4 
> pwmchip6 -> 
> ../../devices/platform/ocp/4830.epwmss/48300100.ecap/pwm/pwmchip6 
> pwmchip7 -> 
> ../../devices/platform/ocp/48304000.epwmss/48304100.ecap/pwm/pwmchip7 
>
> In v4.9.x: (since ecap are considered pwm's) they are now in the order 
> of the register address: 
>
> pwmchip0 -> 
> ../../devices/platform/ocp/4830.epwmss/48300100.ecap/pwm/pwmchip0 
> pwmchip1 -> 
> ../../devices/platform/ocp/4830.epwmss/48300200.pwm/pwm/pwmchip1 
> pwmchip3 -> 
> ../../devices/platform/ocp/48302000.epwmss/48302200.pwm/pwm/pwmchip3 
> pwmchip5 -> 
> ../../devices/platform/ocp/48304000.epwmss/48304100.ecap/pwm/pwmchip5 
> pwmchip6 -> 
> ../../devices/platform/ocp/48304000.epwmss/48304200.pwm/pwm/pwmchip6 
>
> In your case, you only want the dual mode "pwm", (48300200.pwm, 
> 48302200.pwm, 48304200.pwm), you shouldn't blindly enable the 
> "pwmchip0,2,4" as they are dynamic.  You should grep the symlink 
> first. 
>
> Ps, watch out for v4.11.x too: 
>
> #v4.4.x/v4.9.x 
> /sys/class/pwm/pwmchip1/: 
> drwxr-xr-x 3 root root0 Sep 29 21:06 pwm0 
> drwxr-xr-x 3 root root0 Sep 29 21:06 pwm1 
>
> #v4.11.x+ 
>
> /sys/class/pwm/pwmchip1/: 
> drwxrwxr-x 3 root pwm 0 Sep 29 21:10 pwm-1:0 
> drwxrwxr-x 3 root pwm 0 Sep 29 21:10 pwm-1:1 
>
> (ps, this last change is good thing, notice that udev correctly added 
> the "root:pwm" rule.. ;) ) 
>
> 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/f352bae1-24f1-4172-9136-259ef870ee63%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Is cape manager obsolete? What about device tree overlays?

2017-11-30 Thread Johan Henselmans

Thanks for the explanation, but could you elaborate a bit more on it? 

As far as I understand the world as it is now works  this way:

0- If you are running anything beyond kernel 4.1 you should be using uboot 
overlays. Be careful to load the latest bb-cape overlays and be sure that 
uboot is the latest version, check via /opt/script/tools/version.sh, 
look for 
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2015.01-1-gb2412df]
this is 
wrong:  
^^
Should be something like:
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
2017.09-2-g0f3f1c7907]

If not, do 
/opt/scripts/tools/developers/update_bootloader.sh 
This should put an updated bootloader in the boot block of your Beaglebone. 
Careful: you should have booted from the internal flash, not from an 
external flash-card.

1-Overlays are now loaded in /boot/uEnv.txt at boot time. 
Cape-universal or the other universal capes make it possible to use 
config-pin to configure the pins that you want to use, 
example:
config-pin -l p9-21
gives all the possible settings
config-pin -q p9-21
gives the current setting 
config-pin -a p9-21 i2c
makes the pin respond to i2c signals.

2-if another overlay is loaded in /bootuEnv.txt which is not of the 
universal type, config-pin does not work anymore

3-To find out which overlay is loaded if config-pin does not run, use 
command ?? to find out which overlay(s) is/are currently running

4-If you want to make a combination of some of the universal settings plus 
an overlay, ??

I am pretty sure it's all wrong, but I am struggling with the info too. I 
am trying to modernize gobot to the latest uboot overlay stufff (it is 
still looking for cape_mgr slots file), but it is not exactly clear how I 
can find out if an overlay is set, or if I am able to set a specific pin 
after some overlay has been loaded.

On Tuesday, November 28, 2017 at 6:33:35 PM UTC+1, RobertCNelson wrote:
>
> On Tue, Nov 28, 2017 at 12:45 AM, Ken Shirriff  > wrote: 
> > I'm trying to understand the current state of device tree overlays. Is 
> it 
> > correct that the cape manager is now obsolete, and device tree overlays 
> > should be set up through /boot/uEnv.txt? What about config-pin? Is that 
> an 
> > alternative to device tree overlays, or something orthogonal? 
> > 
> > The system I'm using is a PocketBeagle with 4.4.91-ti-r133. Before that 
> I 
> > was using the 3.8 kernel on a BeagleBone and everything seems to have 
> > changed. (Is there a summary somewhere of the new world?) 
>
> Kernel Overlays is obsolete. 
>
> We now use U-Boot Overlays: 
>
> https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays 
>
> config-pin is enabled by default, it allows you to easily change pin's 
> to different functions. 
>
> 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/a5ea1ae5-db41-41dd-839e-0cceee13fd34%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: debian testing: 2015-06-17 (4.1 with capemgr)

2015-06-19 Thread Johan Henselmans

Downloaded the image. So where do I find the capes? For instance I want to 
enable BB--UART1. Where do I find this in the Image? Or should I git the 
overlay repository and 
compile  
https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-UART1-00A0.dts
(after getting the dtc compiler 
via /opt/scripts/tools/developers/dtc-overlay.sh)?



On Thursday, June 18, 2015 at 3:43:19 PM UTC+2, RobertCNelson wrote:

 So, for everyone's who emailed me over the years, asking where is 
 capemanager, well it's time to test... 

 http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2015-06-17 

 Notes: 
 echo xyz  /sys/devices/platform/bone_capemgr/slots 
 DOES NOT work.. 

 Readme: 
 https://github.com/beagleboard/bb.org-overlays/blob/master/readme.md 

 Please take a look at /boot/uEnv.txt for configurations... 

 For ANYTHING that uses the eMMC/HDMI black pins on your cape, use: 

 dtb=am335x-boneblack-overlay.dtb 

 Current list of capes: 

 https://github.com/beagleboard/bb.org-overlays/tree/master/src/arm 

 If you don't see your cape, please create a pull request against, 

 https://github.com/beagleboard/bb.org-overlays 

 Hints for cape porting from v3.8.x 

 3.8: gpio[X] = 4.1: gpio[X-1] 
 3.8: usart[X] = 4.1: usart[X-1] 

 Go Test! 

 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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: debian testing: 2015-06-17 (4.1 with capemgr)

2015-06-19 Thread Johan Henselmans

Sorry, forgot to mention: the image I am using is 
bone-debian-console-armhf. 

Apparently in these images the overlays are not available in /lib/firmware. 
I have to 
do the stuff in https://github.com/beagleboard/bb.org-overlays,
so:
=
cd ~
git pull https://github.com/beagleboard/bb.org-overlays
cd /opt/scripts/tools
git pull
sudo ./update_kernel.sh --beta-kernel
cd ~/bb.org-overlays
./dtc-overlay.sh
./install.sh
===
Now I could add the BB-UART1 to uEnv.txt:
cape_enable=bone_capemgr.enable_partno=BB-UART1
and reboot.

Is there any way to enable an overlay while running?

On Thursday, June 18, 2015 at 3:43:19 PM UTC+2, RobertCNelson wrote:

 So, for everyone's who emailed me over the years, asking where is 
 capemanager, well it's time to test... 

 http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2015-06-17 

 Notes: 
 echo xyz  /sys/devices/platform/bone_capemgr/slots 
 DOES NOT work.. 

 Readme: 
 https://github.com/beagleboard/bb.org-overlays/blob/master/readme.md 

 Please take a look at /boot/uEnv.txt for configurations... 

 For ANYTHING that uses the eMMC/HDMI black pins on your cape, use: 

 dtb=am335x-boneblack-overlay.dtb 

 Current list of capes: 

 https://github.com/beagleboard/bb.org-overlays/tree/master/src/arm 

 If you don't see your cape, please create a pull request against, 

 https://github.com/beagleboard/bb.org-overlays 

 Hints for cape porting from v3.8.x 

 3.8: gpio[X] = 4.1: gpio[X-1] 
 3.8: usart[X] = 4.1: usart[X-1] 

 Go Test! 

 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Damaged eMMC, does not boot from SD-Card automagically

Re: [beagleboard] Damaged eMMC, does not boot from SD-Card automagically

[beagleboard] Damaged eMMC, does not boot from SD-Card automagically

Re: [beagleboard] Beaglebone Green/Black Java for Linux ARM

[beagleboard] Trouble getting bluetooth runnning (kernel 4.14, or kernel 4.4) on BBW

Re: [beagleboard] Beaglebone Green/Black Java for Linux ARM

[beagleboard] Re: Threading for Beagle Bone

Re: [beagleboard] Beaglebone Green/Black Java for Linux ARM

Re: [beagleboard] Stretch pwm difference

Re: [beagleboard] Stretch pwm difference

Re: [beagleboard] Is cape manager obsolete? What about device tree overlays?

[beagleboard] Re: debian testing: 2015-06-17 (4.1 with capemgr)

[beagleboard] Re: debian testing: 2015-06-17 (4.1 with capemgr)

13 matches

Site Navigation

Mail list logo

Footer information