[beagleboard] unable to boot beaglebone black from sdcard

[Madhu K]

Hi All,

I am trying to boot the beaglebone black from sd card, but boot process 
stops with below error.

I have taken u-boot and rootfs from the below link

wget http://s3.armhf.com/dist/bone/bone-uboot.tar.xzuE

wget 
http://s3.armhf.com/dist/bone/ubuntu-trusty-14.04-rootfs-3.14.4.1-bone-armhf.com.tar.xz

I have attached the uEnv.txt file,pleas everify. 


U-Boot SPL 2013.04-dirty (Jul 10 2013 - 14:02:53)
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, 
SoftConn)
musb-hdrc: MHDRC RTL version 2.0 
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, 
SoftConn)
musb-hdrc: MHDRC RTL version 2.0 
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
OMAP SD/MMC: 0
mmc_send_cmd : timeout: No status update
reading u-boot.img
reading u-boot.img


U-Boot 2013.04-dirty (Jul 10 2013 - 14:02:53)

I2C:   ready
DRAM:  512 MiB
WARNING: Caches not enabled
NAND:  No NAND device found!!!
0 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Warning - readenv() failed, using default environment

musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, 
SoftConn)
musb-hdrc: MHDRC RTL version 2.0 
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, 
SoftConn)
musb-hdrc: MHDRC RTL version 2.0 
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
Net:not set. Validating first E-fuse MAC
cpsw, usb_ether
Hit any key to stop autoboot:  0 
gpio: pin 53 (gpio 53) value is 1
mmc0 is current device
micro SD card found
mmc0 is current device
gpio: pin 54 (gpio 54) value is 1
SD/MMC found on device 0
reading uEnv.txt
557 bytes read in 4 ms (135.7 KiB/s)
Loaded environment from uEnv.txt
Importing environment from mmc ...
Running uenvcmd ...
syntax error
mmc_send_cmd : timeout: No status update
24808 bytes read in 35 ms (691.4 KiB/s)
Bad Linux ARM zImage magic!
gpio: pin 55 (gpio 55) value is 1
** File not found /boot/uImage **
U-Boot# 

what could be the possible mistakes for this error, please help me to 
resolve this issue.

Thanks and regards,
Madhu

-- 
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/367b44a5-26d5-4f30-8563-7f1a92d9bbbe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
loadloadaddr=0x8200
fdtaddr=0x8800
kernel_file=zImage
fdtfile=am335x-boneblack.dtb
bootdir=/boot
mmcdev=1
mmcpart=2
loadzimage=load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${bootdir}/${kernel_file} 
loadfdt=load mmc ${mmcdev}:${mmcpart} ${fdtaddr} ${bootdir}/${fdtfile} 
console=ttyO0,115200n8
mmcroot=/dev/mmcblk0p2 rw
mmcrootfstype=ext4 rootwait 
mmcargs=setenv bootargs console=${console} root=${mmcroot} 
rootfstype=${mmcrootfstype} ${optargs}
uenvcmd=run loadzimage; run loadfdt; run mmcargs; bootz ${loadaddr} - ${fdtaddr}

[beagleboard] Re: UAV Drone out of a BBBW

['woody stanford' via BeagleBoard]

Let us look at these motors again. A lot of you are doing (well, thinking 
of) drone projects so let's talk a little about my little Beagle and 
thick-conductored "hot" motors, How we get them making sweet electric love 
with each other.

Ok what you do is you feed off of one of your PWM or GPIO lines of your 
favorite beagle. Both have their downsides. Hardware PWM is lacking a 
certain jeun-se-quoi, its just a little too digital (those that have worked 
with it before know what I'm talking about). However software-based PWM 
(how motor speed control is done) via GPIO I would surprised is good on a 
multitasking OS environment like UN*X. Maybe with interrupts...idk.

Of course my solution is elegant. I went out and saw how fast I could get a 
UART to go, apparently 128K baud...this is acceptable. What you do is you 
use a slave PIC16Fx (the F means flash btw) and I run a 5V zone next to my 
Beagle's 3.3V one. The beauty of this approach is I've decided that I'm 
going to drive these motors DIRECTLY off of my Nickle-Metal Hydrides, no 
caps just spread my error over an inductive domain than a capacitive one 
(***knowing look***).

Can see my new buddy, Graham, wondering if he should whip out the old 
complex numbers on this assertion.

Can you do ESC direct from GPIO or PWM off of your Beagle? I suppose. And 
you might try it. Just pull directly off of a PWM line and feed it to the 
SSR at the front-end of what I'm talking about. I am not adverse to it 
other than the whole getting UN*X to do it. Maybe one of Lidia's sitaras (I 
mock) and that PRU to do it. In fact, I would suspect, that that's the 
whole point of the PRU issue.

So you get your PIC to accept on its hardware UART a byte of which motor 
speed you want to control (I need to control 8). Then I send it an int (2 
bytes) with how long on it is, and then an int of how long off it is. And 
just implement it in a software loop completely bypassing the PIC's 
hardware PWM as well. It just drives 8 GPIO's leading to nice multi-stage 
ESC. We feed this nice PWM signal to the SSR's which drive directly to 
MOSFET, and accept for the blowback rectifier, we are going to run this 
bare-metal as they put it (semiconduction aside).

"You can do it this way?" Its me, dear, I wouldn't steer you wrong. 

OK so let's look at the power train. We have 1.2V NmH's strung in series to 
give us about seven volts of beefy power (and we have the same number of 
cells as our motors) so I'm just going to say 2.5 Amp hours of juice (the 
rating of one cell). We use our stock BBBW to communicate with the PIC 
(that's actually doing the speed control) via probably 
optoisolator-step-up, to custom programmed 5V PIC and then we just pull of 
its GPIO to cheap SSR direct to cheap MOSFET direct to beefy motor. I so 
know this will work. Somewhat improper I'll admit, however life isn't 
perfect. I can just tell this has the characteristics I likey. :D

I'll put up a schematic, maybe even a PCB, of what I'm talking about here 
(tested) so you can use these little drone motors easily.

Theory: you'll find these ones come in 2.2KV and 1.0 KV. I'm hoping my 
advisors have instructed me correctly that with the battery type I'm using, 
connection, propellers bought that it will transfer my battery power to 
nice upward force linearly and predictably. I got a grip of 1.0KV ones. the 
KV rating pertains to the RPM per volt. So a lower value would mean less 
RPM's per volt, a higher higher RPM's. From an engineering perspective what 
you want to do is look at the whole power subsystem seeing that you get a 
tight linkage between your power source and actual FORCE generated by the 
propellers. You can't just say the 2.2KV ones are "better" or "more 
powerful" or you might end up with a system that's electrically perfect but 
just doesn't transfer power right.

Anyways...in conclusion...(UART to external MCU) to SSR to MOSFET direct to 
motor. Or PRU to SSR in previous description.

On Monday, January 30, 2017 at 6:19:30 PM UTC-7, woody stanford wrote:
>
> I posted the remote control for this in Software, but I put a bunch of 
> hardware in it so I thought I'd post it here.
>
>
> https://groups.google.com/forum/#!category-topic/beagleboard/software/evSIUcuWfUY
>

-- 
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/8c24059d-7c0a-4942-bcb6-56fcf181ffe1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: UAV Drone out of a BBBW

['woody stanford' via BeagleBoard]

To continue the brag, I had a small sum set aside to do some 3D 
printing...however I have seen the real quotation numbers on it. Noy much 
like the next inkjet like how they say.

So I was out a connection system for rod, but got a little intuition and 
got a big bag (a literal big bag) of 1/2" dowel end caps. But what makes 
them special is this little protrusion with a 1/8" hole through them that 
is the key to success here I think. I've looked at it geometrically and I 
think I have a winner.

I'm thinking of doing a trick I used to do back in the day where I mix up 
some chips of ABS plastic (of of an old pipe or something) and mix in 
acetone and mix until its a nice thick paste. Then I solvent weld the hell 
out of whatever plastic I'm using (crossing my fingers these little jobbies 
I have secured for my own use are of a compatible plastic) but I am SURE 
that it will lead to the intended effect and a practical drone prototype.

But I have been looking at the forces and loads and realize that I might 
have to put a kind of mast right in the center of the base board that 
doesn't have me pleased (though it does it make it some what look like a 
ship, I understand there are some people into that). However I wouldn't say 
its typically my aesthetic.

If it works half as perfectly as I'm anticipating I will post more of this 
technique here because it seems the WAY to realistically produce 
prototyping geodesics because of the flexible approach. We will see.

On Monday, January 30, 2017 at 6:19:30 PM UTC-7, woody stanford wrote:
>
> I posted the remote control for this in Software, but I put a bunch of 
> hardware in it so I thought I'd post it here.
>
>
> https://groups.google.com/forum/#!category-topic/beagleboard/software/evSIUcuWfUY
>

-- 
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/f65a047c-8663-4360-871f-ef1a0ac3dd52%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: UAV Drone out of a BBBW

['woody stanford' via BeagleBoard]

Ok want to brag. And just remember envy is ugly.

I was expecting to pay $14 for some angel motors out of hong kong, but I 
found some nice $5 ones with the same specs. Read them and weep:

http://www.ebay.com/itm/A2212-1000Kv-Brushless-Drone-Outrunner-Motor-For-Aircraft-Helicopter-Quadcopter/191938683737?_trksid=p2054502.c100227.m3827&_trkparms=aid%3D111001%26algo%3DREC.SEED%26ao%3D1%26asc%3D20160908103841%26meid%3D6362b7ea03604d51bd5c0ddce240102b%26pid%3D100227%26rk%3D2%26rkt%3D8%26sd%3D261614123484

They are even gold colored. Hopefully they work well, but all of the stuff 
I've gotten so far out of Hong Kong is nice. Even comes in the nice little 
anti-stat bags. But I have a confession to make, that I'm liking this whole 
spree I'm on...I have some lead/tin solder coming in. I've looked at the 
natural consequences and realizing that my prototyping (no matter how 
prolific) wouldn't affect the lead content of things one iota, so I'll save 
myself the aggravation of silver (oh god, the aggravation of working with 
that metal, anyways).

I even have an absolutely barbaric 30W iron from Chicago Electric (I think 
it even sings opera)...a real board-destroyer in any but expert hands. I 
need to feed it right.

On Monday, January 30, 2017 at 6:19:30 PM UTC-7, woody stanford wrote:
>
> I posted the remote control for this in Software, but I put a bunch of 
> hardware in it so I thought I'd post it here.
>
>
> https://groups.google.com/forum/#!category-topic/beagleboard/software/evSIUcuWfUY
>

-- 
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/b48a0e73-03f0-49b2-848c-5a59bfd442a7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Is there a web server on the BBB

['woody stanford' via BeagleBoard]

I notice something comes back on my port 80.

Is there a real web sever serving that page thats coming back, and if so, 
where is its htdocs directory (the filespec I mean)?

-- 
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/8c857912-3d8c-4641-a06b-5cbee381305c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Failed to flash eMMC from SD card...Using BBB-blank-debian-8.7-lxqt-4gb-armhf-2017-01-22-4gb.img

[Robert Nelson]

On Fri, Feb 3, 2017 at 7:39 PM, Dennis Lee Bieber  wrote:
> On Fri, 3 Feb 2017 12:17:07 -0600, Robert Nelson
>  declaimed the
> following:
>
>>On Fri, Feb 3, 2017 at 11:29 AM, Ankit Mishra  wrote:
>
>>> ==> Formatting rootfs: /dev/mmcblk1p1 complete
>>> ==> Creating temporary rootfs directory (/tmp/rootfs)
>>> ==> Mounting /dev/mmcblk1p1 to /tmp/rootfs
> 
>>> 
>>> [   76.424892] EXT4-fs error (device mmcblk0p1): ext4_lookup:1583: inode
>>> #48103: comm rsync: deleted inode referenced: 57566
>>
>>Are you using a 5Volt DC power supply???
>>
>>in /opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh
>>
>
> Pardon my jumping in, but based on the device names, those (to me --
> admittedly I'm not well up on Linux device/file systems) look like
> corruption on the source SD card, not the destination eMMC.

Good Catch, yes you are right.  Looks like the initial microSD flash failed..

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/CAOCHtYhkC3oV%2BvKPaJ0xn%3DpVo0EqadyrGVWCFx7bew1iSYKF%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: eQEP on 4.4.19-ti-r41

[woody.lois via BeagleBoard]

On Fri, 2/3/17, Drew Fustini  wrote:

 Subject: Re: [beagleboard] Re: eQEP on 4.4.19-ti-r41
 To: "Beagle Board" 
 Date: Friday, February 3, 2017, 11:18 PM
 
 On Fri, Feb 3, 2017 at
 6:02 AM, Hugh Frater 
 wrote:
 > Did you ever get any further
 with this? I'm struggling with eQEP on 4.4.36 -
 > but for different reasons
 
 Are you getting an error?
 
 I am able to use eQEP ok with
 a rotary encoder on 4.4 kernel:
 
 # uname -a
 Linux beaglebone
 4.4.44-ti-r85 #1 SMP Fri Jan 27 22:16:52
 
 # config-pin p8.11 qep
 #
 config-pin p8.12 qep
 
 # cat
 /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/position
 -2
 
 # cat
 /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/position
 18
 
 Here are
 results with 4.1, 4.4 and 4.9:
 https://gist.github.com/pdp7/1db356e758e9ff0c1e570e6ee362c673
 
 
 -drew
 
 -- 
 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/CAEf4M_CgQ-B0qmtLa1XtNSLcnyvY0ewK47vC%3DCt%2Bejndna91sQ%40mail.gmail.com.
 For
 more options, visit https://groups.google.com/d/optout.
 i in celelaltare provincii romanesti aflate sub opresiunea straina au avut   
mari adunari plebiscitare. La 20 mai 1848  la Cernauti  in prezenta unor 
prezentanti de frunte ai clerului  boierimii  si fruntasilor taranimii  dupa 
izbateri sustinute  au fost adoptate 12 dorinte  intre care  la loc de frunte  
se Iau separarea Bucovinei de Galitia  conservarea nationalitatii romane si 
earea de scoli nationale  autonomia provinciala  defiintarea clacii si a dijmei 
 isfacerea de Mitropolia Ortodoxa de la Karlowitz si alegerea episcopului de 
atre un Congres bisericesc alcatuit din clerici si mireni. La 15 27 iunie 1848  
la jgoj  in Banat  sub presedintia lui Eftimie Murgu  o Adunare de 12 000 de 
ameni a decretat  intre altele  respectarea nationalitatii romanesti  
oficializarea nbii romane  inarmarea poporului dupa putinta in rastimp de 6 
zile cu sfensive  iar dupa ce se va arma de catre stat  atunci sa paseasca 
ofensive .

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

Re: [beagleboard] Re: eQEP on 4.4.19-ti-r41

[Drew Fustini]

On Fri, Feb 3, 2017 at 6:02 AM, Hugh Frater  wrote:
> Did you ever get any further with this? I'm struggling with eQEP on 4.4.36 -
> but for different reasons

Are you getting an error?

I am able to use eQEP ok with a rotary encoder on 4.4 kernel:

# uname -a
Linux beaglebone 4.4.44-ti-r85 #1 SMP Fri Jan 27 22:16:52

# config-pin p8.11 qep
# config-pin p8.12 qep

# cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/position
-2

# cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/position
18

Here are results with 4.1, 4.4 and 4.9:
https://gist.github.com/pdp7/1db356e758e9ff0c1e570e6ee362c673


-drew

-- 
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/CAEf4M_CgQ-B0qmtLa1XtNSLcnyvY0ewK47vC%3DCt%2Bejndna91sQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Building Linux for a custom board

[Robert Nelson]

On Fri, Feb 3, 2017 at 1:47 PM, Todd Peterson  wrote:
> We have a board based upon the Beagleboard xM rev. C. We have been running
> QNX on it. We are trying to experiment with RT Linux by following the
> instructions at https://eewiki.net/display/linuxonarm/BeagleBoard and the
> kernel builds fine. We have a problem with the gpios that identify the board
> revision, since we do not have these gpios wired. I modified
> u-boot/board/ti/beagle/beagle.c to return revision=2 in get_board_revision.
> But when I compile u-boot, I get an error of
>
> /home/users/staff/tpeterson/work/epic2-rt-linux/gcc-linaro-5.3.1-2016.05-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-ld.bfd:
> u-boot-spl section `.rodata' will not fit in region `.sram'
> /home/users/staff/tpeterson/work/epic2-rt-linux/gcc-linaro-5.3.1-2016.05-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-ld.bfd:
> region `.sram' overflowed by 2848 bytes
> scripts/Makefile.spl:290: recipe for target 'spl/u-boot-spl' failed

As long as you are using "just the xM" (not the older boards)..
re-add this line i removed:

#define CONFIG_SYS_THUMB_BUILD

https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2017.01/0001-omap3_beagle-uEnv.txt-bootz-n-fixes.patch#L475

It'll get you a smaller build..

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/CAOCHtYgJVbuR%3DoLJJkf-UYUdH_rCiUk5rvoNoMqSKsQJ%3D-0j7g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Building Linux for a custom board

[Todd Peterson]

We have a board based upon the Beagleboard xM rev. C. We have been running
QNX on it. We are trying to experiment with RT Linux by following the
instructions at https://eewiki.net/display/linuxonarm/BeagleBoard and the
kernel builds fine. We have a problem with the gpios that identify the
board revision, since we do not have these gpios wired. I modified
u-boot/board/ti/beagle/beagle.c to return revision=2 in get_board_revision.
But when I compile u-boot, I get an error of

/home/users/staff/tpeterson/work/epic2-rt-linux/gcc-linaro-5.3.1-2016.05-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-ld.bfd:
u-boot-spl section `.rodata' will not fit in region `.sram'
/home/users/staff/tpeterson/work/epic2-rt-linux/gcc-linaro-5.3.1-2016.05-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-ld.bfd:
region `.sram' overflowed by 2848 bytes
scripts/Makefile.spl:290: recipe for target 'spl/u-boot-spl' failed

Not sure where to fix this.

I also could not find anything in the kernel source that is the equivalent
get_board_revision call.

Any help is greatly appreciated.

-- 
John 3:16
IN GOD WE TRUST!!!

-- 
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/CAMSLvQy2_XuABhVJHm_Hb2HRA%3DKctwJXH_YO%3D_Hs%2BNHQdd0rwQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Failed to flash eMMC from SD card...Using BBB-blank-debian-8.7-lxqt-4gb-armhf-2017-01-22-4gb.img

[Robert Nelson]

On Fri, Feb 3, 2017 at 11:29 AM, Ankit Mishra  wrote:
> Failed with the signature-
> llocating group tables: done
> Writing inode tables: done
> Creating journal (16384 blocks): done
> Writing superblocks and filesystem accounting information: done
>
> 
> ==> Formatting rootfs: /dev/mmcblk1p1 complete
> ==> Creating temporary rootfs directory (/tmp/rootfs)
> ==> Mounting /dev/mmcblk1p1 to /tmp/rootfs
> [   60.322709] EXT4-fs (mmcblk1p1): mounted filesystem with ordered data
> mode. Opts: (null)
>
> 
>
> 
> Copying: Current rootfs to /dev/mmcblk1p1
> 
> ==> rsync: / -> /tmp/rootfs
> 
> [   76.424892] EXT4-fs error (device mmcblk0p1): ext4_lookup:1583: inode
> #48103: comm rsync: deleted inode referenced: 57566
> rsync:
> readlink_stat("/opt/cloud9/build/standalonebuild/node_modules/connect/node_modules/resolv.conf")
> failed: Structure needs cleaning (117)
> [   87.915872] EXT4-fs error (device mmcblk0p1): ext4_lookup:1583: inode
> #50890: comm rsync: deleted inode referenced: 57574
> rsync:
> readlink_stat("/opt/source/adafruit-beaglebone-io-python/.git/objects/d0/tmp")
> failed: Structure needs cleaning (117)
>
> rsync error: some files/attrs were not transferred (see previous errors)
> (code 23) at main.c(1183) [sender=3.1.1]

Are you using a 5Volt DC power supply???

in /opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh

Enable the [mkfs_options="-c"] option and try again:

https://github.com/RobertCNelson/boot-scripts/blob/master/tools/eMMC/init-eMMC-flasher-v3.sh#L29-L36

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

[beagleboard] Unable To Flash BBB eMMC from SD card ..Using BBB-blank-debian-8.7-lxqt-4gb-armhf-2017-01-22-4gb.img

[Ankit Mishra]

llocating group tables: done
Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done


==> Formatting rootfs: /dev/mmcblk1p1 complete
==> Creating temporary rootfs directory (/tmp/rootfs)
==> Mounting /dev/mmcblk1p1 to /tmp/rootfs
[   60.322709] EXT4-fs (mmcblk1p1): mounted filesystem with ordered data 
mode. Opts: (null)




Copying: Current rootfs to /dev/mmcblk1p1

==> rsync: / -> /tmp/rootfs

[   76.424892] EXT4-fs error (device mmcblk0p1): ext4_lookup:1583: inode 
#48103: comm rsync: deleted inode referenced: 57566
rsync: 
readlink_stat("/opt/cloud9/build/standalonebuild/node_modules/connect/node_modules/resolv.conf")
 
failed: Structure needs cleaning (117)
[   87.915872] EXT4-fs error (device mmcblk0p1): ext4_lookup:1583: inode 
#50890: comm rsync: deleted inode referenced: 57574
rsync: 
readlink_stat("/opt/source/adafruit-beaglebone-io-python/.git/objects/d0/tmp") 
failed: Structure needs cleaning (117)

rsync error: some files/attrs were not transferred (see previous errors) 
(code 23) at main.c(1183) [sender=3.1.1]
writing to [/dev/mmcblk1] failed...
==> Stopping Cylon LEDs ...
==> Setting LEDs to
/opt/scripts/tools/eMMC/functions.sh: line 385:   617 Terminated   
   cylon_leds

-- 
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/f88af7c6-163f-425b-bf87-3c74d8abaf7f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Failed to flash eMMC from SD card...Using BBB-blank-debian-8.7-lxqt-4gb-armhf-2017-01-22-4gb.img

[Ankit Mishra]

Failed with the signature-
llocating group tables: done
Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done


==> Formatting rootfs: /dev/mmcblk1p1 complete
==> Creating temporary rootfs directory (/tmp/rootfs)
==> Mounting /dev/mmcblk1p1 to /tmp/rootfs
[   60.322709] EXT4-fs (mmcblk1p1): mounted filesystem with ordered data 
mode. Opts: (null)




Copying: Current rootfs to /dev/mmcblk1p1

==> rsync: / -> /tmp/rootfs

[   76.424892] EXT4-fs error (device mmcblk0p1): ext4_lookup:1583: inode 
#48103: comm rsync: deleted inode referenced: 57566
rsync: 
readlink_stat("/opt/cloud9/build/standalonebuild/node_modules/connect/node_modules/resolv.conf")
 
failed: Structure needs cleaning (117)
[   87.915872] EXT4-fs error (device mmcblk0p1): ext4_lookup:1583: inode 
#50890: comm rsync: deleted inode referenced: 57574
rsync: 
readlink_stat("/opt/source/adafruit-beaglebone-io-python/.git/objects/d0/tmp") 
failed: Structure needs cleaning (117)

rsync error: some files/attrs were not transferred (see previous errors) 
(code 23) at main.c(1183) [sender=3.1.1]
writing to [/dev/mmcblk1] failed...
==> Stopping Cylon LEDs ...
==> Setting LEDs to
/opt/scripts/tools/eMMC/functions.sh: line 385:   617 Terminated   
   cylon_leds

-- 
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/63f13114-e786-42c5-a8bd-3c7335a39924%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
U-Boot SPL 2017.01-6-gb2bbabfe41 (Jan 19 2017 - 17:01:49)
Trying to boot from MMC2

U-Boot 2017.01-6-gb2bbabfe41 (Jan 19 2017 - 17:01:49 -0600), Build: 
jenkins-github_Bootloader-Builder-505

CPU  : AM335X-GP rev 2.1
I2C:   ready
DRAM:  512 MiB
Reset Source: Power-on reset has occurred.
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment

 not set. Validating first E-fuse MAC
BeagleBone Black:
BeagleBone: cape eeprom: i2c_probe: 0x54:
BeagleBone: cape eeprom: i2c_probe: 0x55:
BeagleBone: cape eeprom: i2c_probe: 0x56:
BeagleBone: cape eeprom: i2c_probe: 0x57:
Net:   eth0: MII MODE
cpsw
Press SPACE to abort autoboot in 2 seconds
board_name=[A335BNLT] ...
board_rev=[00C0] ...
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
** Bad device 0:2 0x8200 **
** Bad device 0:2 0x8200 **
switch to partitions #0, OK
mmc0 is current device
bad MBR sector signature 0x01d4
bad MBR sector signature 0x01d5
Scanning mmc 0:1...
gpio: pin 56 (gpio 56) value is 0
gpio: pin 55 (gpio 55) value is 0
gpio: pin 54 (gpio 54) value is 0
gpio: pin 53 (gpio 53) value is 1
switch to partitions #0, OK
mmc0 is current device
gpio: pin 54 (gpio 54) value is 1
Checking for: /uEnv.txt ...
1179 bytes read in 7 ms (164.1 KiB/s)
gpio: pin 55 (gpio 55) value is 1
Loaded environment from /uEnv.txt
Importing environment from mmc ...
Checking if uenvcmd is set ...
gpio: pin 56 (gpio 56) value is 1
Running uenvcmd ...
1327 bytes read in 38 ms (33.2 KiB/s)
debug: [/boot/vmlinuz-4.4.43-ti-r84] ...
8651176 bytes read in 587 ms (14.1 MiB/s)
debug: [/boot/initrd.img-4.4.43-ti-r84] ...
5163228 bytes read in 361 ms (13.6 MiB/s)
debug: [/boot/dtbs/4.4.43-ti-r84/am335x-boneblack.dtb] ...
55541 bytes read in 113 ms (479.5 KiB/s)
debug: [console=tty0 console=ttyO0,115200n8 root=/dev/mmcblk0p1 rootfstype=ext4 
rootwait init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh] ...
debug: [bootz 0x8200 0x8808:4ec8dc 0x8800] ...
## Flattened Device Tree blob at 8800
   Booting using the fdt blob at 0x8800
   Using Device Tree in place at 8800, end 880108f4

Starting kernel ...

[0.00] Booting Linux on physical CPU 0x0
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 4.4.43-ti-r84 (root@a3-imx6q-wandboard-2gb) (gcc 
version 4.9.2 (Debian 4.9.2-10) ) #1 SMP Fri Jan 20 16:28:53 UTC 2017
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] Machine model: TI AM335x BeagleBone Black
[0.00] cma: Reserved 48 MiB at 0x9c80
[0.00] Memory policy: Data cache writeback
[0.00] CPU: All CPU(s) started in SVC mode.
[0.00] 

Re: [beagleboard] eQEP not reading meaningful values

[abhilash h]

For sure it will work.
On Fri, 3 Feb 2017 at 9:33 PM, Hugh Frater  wrote:

> I'll give 7.9 a go and let you know my findings, thanks.
>
>
> On Friday, 3 February 2017 13:40:05 UTC, abhilash h wrote:
>
> I had used debian 7.9
>
> On Fri, 3 Feb 2017 at 7:05 PM, Hugh Frater  wrote:
>
> Thanks, I'm currently trying to downgrade to a 3.8 revision, 1st attempt
> resulted in a 'won't boot, all the LEDs are on' so I guess I missed a step.
>
>
> On Friday, 3 February 2017 13:31:00 UTC, abhilash h wrote:
>
> I had used debian . And it worked with busybox rfs and 3.8 kernel also .
>
> On Fri, 3 Feb 2017 at 6:20 PM, Hugh Frater  wrote:
>
> Hi Abhilash,
>
> That's interesting, I will try and downgrade. May I ask what image you are
> using now (Angstrom, Debian etc)?
>
> Hugh
>
>
> On Friday, 3 February 2017 12:36:34 UTC, abhilash h wrote:
>
> Hi hugh,
>
> It never worked for me in 4.x kernel. I used to get same values. So i
> swutched back to 3.8 kernel .
>
> On Fri, 3 Feb 2017 at 5:47 PM, Hugh Frater  wrote:
>
> Hi, I'm getting started on a control system that needs to read 2x
> quadrature encoders. One is a 1000 line, the other a 2000 line, but that is
> really immaterial. I have the physical interface sorted (one needs a 26lv32
> to glue it to the BBB, the other is open collector), and the traces look
> good on the scope.
>
> I'm running Jessie IOT with 4.4.36, I have disabled hdmi and universal
> cape. I can load Nathaniel Lewis' overlays (supplied with the clean install
> of Jessie) just fine with no errors in dmesg.
>
> However when I 'cat position' in each of the relevant sys entries (having
> moved my encoder A/B lines to the relevant pins each time), I get a
> changing value but it isn't meaningful. Am I missing something, or is it
> more likely that I've blown up the inputs? I did power on the servo drive
> (that was connected to the 26lv32 breakout board) by accident when the BBB
> wasn't powered up.
>
> I've tested with a simple 24ppr 'audio style' encoder and again don't get
> meaningful results.
>
> Do I have to mess about with config-pin for each of the eQEP inputs, or
> should loading the relevant dtbo file for the eQEP module (0, 1 2 etc) set
> up the pins for me?
>
> There's so much old documentation floating about it's hard to identify
> what is current and what is no longer relevant now that the universal-cape
> is in existence.
>
> Regards, Hugh
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
>
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard...@googlegroups.com.
>
>
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/c28fc73b-b2f4-4e73-8318-fd37599ef3b6%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard...@googlegroups.com.
>
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/3e6b19d3-1c4a-4fea-9833-0d20fa29071a%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard...@googlegroups.com.
>
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/39682a43-a9ad-42a6-9906-751c77e102bd%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
> --
> 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/7502f82c-ed74-4b74--ebcd51bb91e4%40googlegroups.com
> 
> .
> For 

[beagleboard] the-iot-beaglebone-beagle-treat-feeder

[William Hermans]

The link is not to anything I've done. I only saw the material, and though 
others might enjoy the link as well.

http://www.allaboutcircuits.com/projects/the-iot-beaglebone-beagle-treat-feeder/?utm_source=All+About+Circuits+Members_campaign=c35ae9f1c3-EMAIL_CAMPAIGN_2017_02_01_medium=email_term=0_2565529c4b-c35ae9f1c3-265615941/

-- 
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/f4a7718b-e753-4b91-86a8-65dd7738a16c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] i2c read block

[William Hermans]

On Fri, Feb 3, 2017 at 3:06 AM, Francis  wrote:

> Hi,
>
> I am trying to create an application on top/based on the i2c tools.
> Everything was working well, except the i2c_smbus_block_process_call(),
> which returns an error when called.
>
> Below is the output of i2cdetect -F:
>
> Functionalities implemented by /dev/i2c-2:
> I2C  yes
> SMBus Quick Command  no
> SMBus Send Byte  yes
> SMBus Receive Byte   yes
> SMBus Write Byte yes
> SMBus Read Byte  yes
> SMBus Write Word yes
> SMBus Read Word  yes
> SMBus Process Call   yes
> SMBus Block Writeyes
> SMBus Block Read no
> SMBus Block Process Call no
> SMBus PECyes
> I2C Block Write  yes
> I2C Block Read   yes
>
> -
>
> Based from it, I could tell that SMBus Process Call is not supported.
> could anyone suggests an alternative or give directions on how to make a
> process call?
>
> Thanks in advance!
>
>
Well the reason why the functionality you mention is not supported should
be obvious from your output above. Block read isn't supported either.
Honestly though, I'm not even sure how the block process call functionality
is even useful. What's the point of writing up to 31 bytes into ONE
register, and reading it back again ?

As far as answering your question goes. Technically you can not duplicate
this functionality. Realistically, you could attempt to use the standard
I2C block read listed above, or just use i2c_smbus_read_byte_data(), and
loop over the whole register set ? Again, I honestly do not get the point
of such a "feature".

-- 
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/CALHSORrsE_qdUB4GC5iQje%3DhojpP7OQ%2BnK7z6Nzxp8KVtPsYAw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Actually building something

['woody stanford' via BeagleBoard]

The Importance of Datasheets

One of the things I really learned doing this kind of stuff was the 
importance of datasheets. As far as I'm concerned, if a part doesn't have a 
datasheet, I don't use it. And I would go so far as to even say a datasheet 
in PDF format. They are important to use, to download to a specific 
directory on your computer, and important to actually use.

Datasheets can give you the dimensions of the part (like how they should be 
laid out on a PCB) as well as critical information as to their voltage 
rating, current carrying capabilities, as well as their function. Good 
datasheets also include any discrete networks that are important to 
operating the component well (you shouldn't have to go hunting for related 
circuit designs that are needed to successfully use the component...though 
this is basically accepted culturally that you must).

For me datasheets are a must in that there is always some piece of 
information I need but can't find. Datasheets help you avoid that long 
waiting time that it takes to go find the missing information and getting 
back to designing.

Make a directory called datasheets, maybe even in your downloads directory 
so that when you see a component you like or already have, you have every 
possible piece of information on it. This is key to any kind of serious 
hobbyist work IMO.

On Thursday, February 2, 2017 at 2:09:39 PM UTC-7, woody stanford wrote:
>
> OK, here is a short primer on how the good guys build things in a serious 
> hobbyist setting.
>
> The development is done in 2 main stages. Breadboarding, and PCB 
> construction (with presensitized board).
>
> The reason why the breadboarding phase is because the Inet is great, but 
> you can't believe everything you read on it. What you want to do is look on 
> the WWW for ideas and then breadboard them out. Once you get them reliable 
> and you undersand their operation, you can use the technique in your 
> personal projects.
>
> How you do this on a budget (as it is the Great Recesion) is you get cheap 
> Chinese breadboards on ebay for $5 a piece free shipping. Like here,
>
>
> http://www.ebay.com/itm/830-Tie-Points-Solderless-PCB-Breadboard-MB102-65Pcs-Jumper-cable-wires-/231412564779?hash=item35e143832b:m:mlV4jkc4DpzzqjQsn-zO0-w
>
> The latest and greatest idea, the only downside is that it takes longer 
> than a week to get your stuff in but the price is right. You can also get 
> broken out sensors and the like for dirt cheap (basically mounted great 
> stuff the big guys use in smart phones and tablets). $5 per component is 
> typical if you know where to go.
>
> What you do is peal the backs off them an mount them to a 2' x 2' piece of 
> plywood you can get at Home Depot. And you are ready to rock. next step is 
> to find inexpensive, reliable power. A cool thing I've been playing with is 
> tablet bricks because they are reliable, ubiquitous and a lot of them 
> deliver a strong 1.0 Amp or 5VDC. Take your soldering iron, figure out the 
> GND and the +5VDC and you have comfortable power on the 1 amp range. As 
> always, PC switching power supplies are great too (just get a $5 DMM from 
> Harbour Freight and sacrifice its leads so you have a constant digital 
> power monitorsolder it on and wrap with electrical tape).
>
> What you do is you mount everything on your plywood. You take your 
> Fiscar's drill (with $2 high-speed steel Harbour Freight drill bits) and 
> you get a nice selection of dollar-store machine screws (and nuts) that 
> you've "tackle-box-ized". Shop the 99 Cent Store for these cheap tackle 
> boxes and pick up about a dozen of them to keep your stuff in (resisters, 
> relays, diods and voltage regulators). The trick with this is: mouser, but 
> listen...you can get premade kits for around $70 but they have less than $5 
> worth of parts in them. What you want to do is put them together yourself 
> and when you get low on standard parts (like certain resistor values) you 
> just restock. All it takes is time to build these part kits, you put 
> together generic BOM (bill of materials) for your tackle box kits so you 
> have a nice selection of standard caps, diodes, transistors, MOSFETS, tiny 
> relays, optoisolators, MCU's like PIC's and of cource exotics like NEO6M's, 
> preprogrammed MCU's, and MCU6050's.
>
> Modern hacking requires attention to ESD (electrostatic discharge) because 
> a lot of your stuff has sensitive digital logic in it. The fix is basic. 
> Take a piece of silver solder and stick it in your ground power rail so 
> about an inch of its hanging out. Every time you get up to walk around 
> (where you accumulate chip-killing static) when you sit back down, just run 
> your finger unconsciously across the solder tail. You are now grounded. 
> Formal ESC with a wrist strap is ok too. But don't wire yourself to ground 
> btw as this can lead to you doing an impression of a light-emitting 
> resistor (an old joke but a good one); think about it 

[beagleboard] Re: i2c read block

[Graham]

Francis:

Referring to:
https://www.kernel.org/doc/Documentation/i2c/smbus-protocol

SMBus Process Call:
===

This command selects a device register (through the Comm byte), sends
16 bits of data to it, and reads 16 bits of data in return.


So, write 16 bits to a specific register, followed by a 16 bit read.

It seems you could synthesize this by using a "SMBus Write Word" followed 
by a "SMBus Read Word"

Or synthesize it out of single byte primitives, or ... .

You just need to make sure that if you stack up multiple commands to do the 
same thing, that in a multi-threaded environment, that the OS does not let 
other threads share/grab the device in between your commands.

--- Graham

==

On Friday, February 3, 2017 at 5:24:02 AM UTC-6, Francis wrote:
>
> Hi,
>
> I am trying to create an application on top/based on the i2c tools.
> Everything was working well, except the i2c_smbus_block_process_call(), 
> which returns an error when called.
>
> Below is the output of i2cdetect -F:
>
> Functionalities implemented by /dev/i2c-2:
> I2C  yes
> SMBus Quick Command  no
> SMBus Send Byte  yes
> SMBus Receive Byte   yes
> SMBus Write Byte yes
> SMBus Read Byte  yes
> SMBus Write Word yes
> SMBus Read Word  yes
> SMBus Process Call   yes
> SMBus Block Writeyes
> SMBus Block Read no
> SMBus Block Process Call no
> SMBus PECyes
> I2C Block Write  yes
> I2C Block Read   yes
>
> -
>
> Based from it, I could tell that SMBus Process Call is not supported.
> could anyone suggests an alternative or give directions on how to make a 
> process call?
>
> Thanks in advance!
>
> Francis
>

-- 
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/9f1be03b-fa7e-45f7-b831-acd09794cb52%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] eQEP not reading meaningful values

[Hugh Frater]

I'll give 7.9 a go and let you know my findings, thanks.

On Friday, 3 February 2017 13:40:05 UTC, abhilash h wrote:
>
> I had used debian 7.9 
> On Fri, 3 Feb 2017 at 7:05 PM, Hugh Frater  > wrote:
>
>> Thanks, I'm currently trying to downgrade to a 3.8 revision, 1st attempt 
>> resulted in a 'won't boot, all the LEDs are on' so I guess I missed a step.
>>
>>
>> On Friday, 3 February 2017 13:31:00 UTC, abhilash h wrote:
>>
>>> I had used debian . And it worked with busybox rfs and 3.8 kernel also .
>>>
>> On Fri, 3 Feb 2017 at 6:20 PM, Hugh Frater  wrote:
>>>
>> Hi Abhilash, 

 That's interesting, I will try and downgrade. May I ask what image you 
 are using now (Angstrom, Debian etc)?

 Hugh


 On Friday, 3 February 2017 12:36:34 UTC, abhilash h wrote:

> Hi hugh,  
>
> It never worked for me in 4.x kernel. I used to get same values. So i 
> swutched back to 3.8 kernel . 
>
 On Fri, 3 Feb 2017 at 5:47 PM, Hugh Frater  wrote:
>
 Hi, I'm getting started on a control system that needs to read 2x 
>> quadrature encoders. One is a 1000 line, the other a 2000 line, but that 
>> is 
>> really immaterial. I have the physical interface sorted (one needs a 
>> 26lv32 
>> to glue it to the BBB, the other is open collector), and the traces look 
>> good on the scope.
>>
>> I'm running Jessie IOT with 4.4.36, I have disabled hdmi and 
>> universal cape. I can load Nathaniel Lewis' overlays (supplied with the 
>> clean install of Jessie) just fine with no errors in dmesg.
>>
>> However when I 'cat position' in each of the relevant sys entries 
>> (having moved my encoder A/B lines to the relevant pins each time), I 
>> get a 
>> changing value but it isn't meaningful. Am I missing something, or is it 
>> more likely that I've blown up the inputs? I did power on the servo 
>> drive 
>> (that was connected to the 26lv32 breakout board) by accident when the 
>> BBB 
>> wasn't powered up.
>>
>> I've tested with a simple 24ppr 'audio style' encoder and again don't 
>> get meaningful results.
>>
>> Do I have to mess about with config-pin for each of the eQEP inputs, 
>> or should loading the relevant dtbo file for the eQEP module (0, 1 2 
>> etc) 
>> set up the pins for me?
>>
>> There's so much old documentation floating about it's hard to 
>> identify what is current and what is no longer relevant now that the 
>> universal-cape is in existence.
>>
>> Regards, Hugh
>>
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to the Google 
>> Groups "BeagleBoard" group.
>>
> To unsubscribe from this group and stop receiving emails from it, send 
>> an email to beagleboard...@googlegroups.com.
>
>
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/c28fc73b-b2f4-4e73-8318-fd37599ef3b6%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> -- 
 For more options, visit http://beagleboard.org/discuss
 --- 
 You received this message because you are subscribed to the Google 
 Groups "BeagleBoard" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to beagleboard...@googlegroups.com.

>>> To view this discussion on the web visit 
 https://groups.google.com/d/msgid/beagleboard/3e6b19d3-1c4a-4fea-9833-0d20fa29071a%40googlegroups.com
  
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/39682a43-a9ad-42a6-9906-751c77e102bd%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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 

[beagleboard] Re: Howto disable HDMI audio only with Debian Jessie on BBB

[Tarmo Kuuse]

I'd like to bump this topic. Any pointers on how to disable HDMI audio only?

I'd like to mux some audio pins (P9.25) to GPIO, but they are snatched by 
the mcasp driver on boot and it won't give them back. Doing something like 
"cape_disable=bone_capemgr.disable_partno=BB-BONELT-HDMIN" doesn't seem to 
release the audio pins. 

At the same I would also need to use the (super useful) on-board eMMC and 
HDMI video output.

If there's no pre-made solution, I'd probably have to figure out how to 
hack the boot-time device tree, and that looks like a rather daunting task.

--
Kind regards,
Tarmo Kuuse

On Thursday, December 1, 2016 at 3:31:46 PM UTC+2, kritzel...@gmx.de wrote:
>
> Just upgraded my BBB from factory image to Debian Jessie: 
> https://debian.beagleboard.org/images/bone-debian-8.6-lxqt-4gb-armhf-2016-11-06-4gb.img.xz
>
> With the old Wheezy image and the concept of virtual HDMI capes it was 
> possible to disable *HDMI audio* while keeping *HDMI video* alive 
> (uENv.txt: cape_disable=capemgr.disable_partno=BB-BONELT-HDMI). This step 
> released all preallocated mcasp0-pins for other applications, e.g. for PRU0 
> access, while still having an HDMI display attached and running.
>
> Now with Jessie (no more virtual capes) I have difficulties to realize 
> such a scenario. Apparently there is no preconfigured DTB with capemgr, 
> eMMC and HDMI enabled, but Audio disabled (see 
> http://elinux.org/BeagleBone_DTBs). Also the last table at this page (
> http://elinux.org/Beagleboard:BeagleBone_Debian_Image_Migration) shows 
> nothing more than a question mark for that particular case.
>
> Does anyone have a suitable DTB (or *.dts) at hand or can point me to 
> information how to generate such a file from existing device tree source 
> files?
>
> Thanks,
> KK
>

-- 
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/03ae67be-984f-4551-9725-9ddc52016264%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] eQEP not reading meaningful values

[abhilash h]

I had used debian 7.9
On Fri, 3 Feb 2017 at 7:05 PM, Hugh Frater  wrote:

> Thanks, I'm currently trying to downgrade to a 3.8 revision, 1st attempt
> resulted in a 'won't boot, all the LEDs are on' so I guess I missed a step.
>
>
> On Friday, 3 February 2017 13:31:00 UTC, abhilash h wrote:
>
> I had used debian . And it worked with busybox rfs and 3.8 kernel also .
>
> On Fri, 3 Feb 2017 at 6:20 PM, Hugh Frater  wrote:
>
> Hi Abhilash,
>
> That's interesting, I will try and downgrade. May I ask what image you are
> using now (Angstrom, Debian etc)?
>
> Hugh
>
>
> On Friday, 3 February 2017 12:36:34 UTC, abhilash h wrote:
>
> Hi hugh,
>
> It never worked for me in 4.x kernel. I used to get same values. So i
> swutched back to 3.8 kernel .
>
> On Fri, 3 Feb 2017 at 5:47 PM, Hugh Frater  wrote:
>
> Hi, I'm getting started on a control system that needs to read 2x
> quadrature encoders. One is a 1000 line, the other a 2000 line, but that is
> really immaterial. I have the physical interface sorted (one needs a 26lv32
> to glue it to the BBB, the other is open collector), and the traces look
> good on the scope.
>
> I'm running Jessie IOT with 4.4.36, I have disabled hdmi and universal
> cape. I can load Nathaniel Lewis' overlays (supplied with the clean install
> of Jessie) just fine with no errors in dmesg.
>
> However when I 'cat position' in each of the relevant sys entries (having
> moved my encoder A/B lines to the relevant pins each time), I get a
> changing value but it isn't meaningful. Am I missing something, or is it
> more likely that I've blown up the inputs? I did power on the servo drive
> (that was connected to the 26lv32 breakout board) by accident when the BBB
> wasn't powered up.
>
> I've tested with a simple 24ppr 'audio style' encoder and again don't get
> meaningful results.
>
> Do I have to mess about with config-pin for each of the eQEP inputs, or
> should loading the relevant dtbo file for the eQEP module (0, 1 2 etc) set
> up the pins for me?
>
> There's so much old documentation floating about it's hard to identify
> what is current and what is no longer relevant now that the universal-cape
> is in existence.
>
> Regards, Hugh
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
>
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard...@googlegroups.com.
>
>
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/c28fc73b-b2f4-4e73-8318-fd37599ef3b6%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard...@googlegroups.com.
>
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/3e6b19d3-1c4a-4fea-9833-0d20fa29071a%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
> --
> 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/39682a43-a9ad-42a6-9906-751c77e102bd%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CA%2B-ZLitzTBsMAdXenQP3U9AJBN8LuRfq%2B56cM-bxkMuvOgWf_g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] eQEP not reading meaningful values

[Hugh Frater]

Thanks, I'm currently trying to downgrade to a 3.8 revision, 1st attempt 
resulted in a 'won't boot, all the LEDs are on' so I guess I missed a step.

On Friday, 3 February 2017 13:31:00 UTC, abhilash h wrote:
>
> I had used debian . And it worked with busybox rfs and 3.8 kernel also .
> On Fri, 3 Feb 2017 at 6:20 PM, Hugh Frater  > wrote:
>
>> Hi Abhilash, 
>>
>> That's interesting, I will try and downgrade. May I ask what image you 
>> are using now (Angstrom, Debian etc)?
>>
>> Hugh
>>
>>
>> On Friday, 3 February 2017 12:36:34 UTC, abhilash h wrote:
>>
>>> Hi hugh,  
>>>
>>> It never worked for me in 4.x kernel. I used to get same values. So i 
>>> swutched back to 3.8 kernel . 
>>>
>> On Fri, 3 Feb 2017 at 5:47 PM, Hugh Frater  wrote:
>>>
>> Hi, I'm getting started on a control system that needs to read 2x 
 quadrature encoders. One is a 1000 line, the other a 2000 line, but that 
 is 
 really immaterial. I have the physical interface sorted (one needs a 
 26lv32 
 to glue it to the BBB, the other is open collector), and the traces look 
 good on the scope.

 I'm running Jessie IOT with 4.4.36, I have disabled hdmi and universal 
 cape. I can load Nathaniel Lewis' overlays (supplied with the clean 
 install 
 of Jessie) just fine with no errors in dmesg.

 However when I 'cat position' in each of the relevant sys entries 
 (having moved my encoder A/B lines to the relevant pins each time), I get 
 a 
 changing value but it isn't meaningful. Am I missing something, or is it 
 more likely that I've blown up the inputs? I did power on the servo drive 
 (that was connected to the 26lv32 breakout board) by accident when the BBB 
 wasn't powered up.

 I've tested with a simple 24ppr 'audio style' encoder and again don't 
 get meaningful results.

 Do I have to mess about with config-pin for each of the eQEP inputs, or 
 should loading the relevant dtbo file for the eQEP module (0, 1 2 etc) set 
 up the pins for me?

 There's so much old documentation floating about it's hard to identify 
 what is current and what is no longer relevant now that the universal-cape 
 is in existence.

 Regards, Hugh

 -- 
 For more options, visit http://beagleboard.org/discuss
 --- 
 You received this message because you are subscribed to the Google 
 Groups "BeagleBoard" group.

>>> To unsubscribe from this group and stop receiving emails from it, send 
 an email to beagleboard...@googlegroups.com.
>>>
>>>
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/beagleboard/c28fc73b-b2f4-4e73-8318-fd37599ef3b6%40googlegroups.com
  
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/3e6b19d3-1c4a-4fea-9833-0d20fa29071a%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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/39682a43-a9ad-42a6-9906-751c77e102bd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] eQEP not reading meaningful values

[abhilash h]

I had used debian . And it worked with busybox rfs and 3.8 kernel also .
On Fri, 3 Feb 2017 at 6:20 PM, Hugh Frater  wrote:

> Hi Abhilash,
>
> That's interesting, I will try and downgrade. May I ask what image you are
> using now (Angstrom, Debian etc)?
>
> Hugh
>
>
> On Friday, 3 February 2017 12:36:34 UTC, abhilash h wrote:
>
> Hi hugh,
>
> It never worked for me in 4.x kernel. I used to get same values. So i
> swutched back to 3.8 kernel .
>
> On Fri, 3 Feb 2017 at 5:47 PM, Hugh Frater  wrote:
>
> Hi, I'm getting started on a control system that needs to read 2x
> quadrature encoders. One is a 1000 line, the other a 2000 line, but that is
> really immaterial. I have the physical interface sorted (one needs a 26lv32
> to glue it to the BBB, the other is open collector), and the traces look
> good on the scope.
>
> I'm running Jessie IOT with 4.4.36, I have disabled hdmi and universal
> cape. I can load Nathaniel Lewis' overlays (supplied with the clean install
> of Jessie) just fine with no errors in dmesg.
>
> However when I 'cat position' in each of the relevant sys entries (having
> moved my encoder A/B lines to the relevant pins each time), I get a
> changing value but it isn't meaningful. Am I missing something, or is it
> more likely that I've blown up the inputs? I did power on the servo drive
> (that was connected to the 26lv32 breakout board) by accident when the BBB
> wasn't powered up.
>
> I've tested with a simple 24ppr 'audio style' encoder and again don't get
> meaningful results.
>
> Do I have to mess about with config-pin for each of the eQEP inputs, or
> should loading the relevant dtbo file for the eQEP module (0, 1 2 etc) set
> up the pins for me?
>
> There's so much old documentation floating about it's hard to identify
> what is current and what is no longer relevant now that the universal-cape
> is in existence.
>
> Regards, Hugh
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
>
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard...@googlegroups.com.
>
>
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/c28fc73b-b2f4-4e73-8318-fd37599ef3b6%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
> --
> 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/3e6b19d3-1c4a-4fea-9833-0d20fa29071a%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CA%2B-ZLitGgWCcB3r_H9DGYft8-6V%2BcD3nUjmqP3sJbcQ3akc7Pg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] eQEP not reading meaningful values

[Hugh Frater]

Hi Abhilash, 

That's interesting, I will try and downgrade. May I ask what image you are 
using now (Angstrom, Debian etc)?

Hugh

On Friday, 3 February 2017 12:36:34 UTC, abhilash h wrote:
>
> Hi hugh,  
>
> It never worked for me in 4.x kernel. I used to get same values. So i 
> swutched back to 3.8 kernel . 
>
> On Fri, 3 Feb 2017 at 5:47 PM, Hugh Frater  > wrote:
>
>> Hi, I'm getting started on a control system that needs to read 2x 
>> quadrature encoders. One is a 1000 line, the other a 2000 line, but that is 
>> really immaterial. I have the physical interface sorted (one needs a 26lv32 
>> to glue it to the BBB, the other is open collector), and the traces look 
>> good on the scope.
>>
>> I'm running Jessie IOT with 4.4.36, I have disabled hdmi and universal 
>> cape. I can load Nathaniel Lewis' overlays (supplied with the clean install 
>> of Jessie) just fine with no errors in dmesg.
>>
>> However when I 'cat position' in each of the relevant sys entries (having 
>> moved my encoder A/B lines to the relevant pins each time), I get a 
>> changing value but it isn't meaningful. Am I missing something, or is it 
>> more likely that I've blown up the inputs? I did power on the servo drive 
>> (that was connected to the 26lv32 breakout board) by accident when the BBB 
>> wasn't powered up.
>>
>> I've tested with a simple 24ppr 'audio style' encoder and again don't get 
>> meaningful results.
>>
>> Do I have to mess about with config-pin for each of the eQEP inputs, or 
>> should loading the relevant dtbo file for the eQEP module (0, 1 2 etc) set 
>> up the pins for me?
>>
>> There's so much old documentation floating about it's hard to identify 
>> what is current and what is no longer relevant now that the universal-cape 
>> is in existence.
>>
>> Regards, Hugh
>>
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/c28fc73b-b2f4-4e73-8318-fd37599ef3b6%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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/3e6b19d3-1c4a-4fea-9833-0d20fa29071a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] eQEP not reading meaningful values

[abhilash h]

Hi hugh,

It never worked for me in 4.x kernel. I used to get same values. So i
swutched back to 3.8 kernel .

On Fri, 3 Feb 2017 at 5:47 PM, Hugh Frater  wrote:

> Hi, I'm getting started on a control system that needs to read 2x
> quadrature encoders. One is a 1000 line, the other a 2000 line, but that is
> really immaterial. I have the physical interface sorted (one needs a 26lv32
> to glue it to the BBB, the other is open collector), and the traces look
> good on the scope.
>
> I'm running Jessie IOT with 4.4.36, I have disabled hdmi and universal
> cape. I can load Nathaniel Lewis' overlays (supplied with the clean install
> of Jessie) just fine with no errors in dmesg.
>
> However when I 'cat position' in each of the relevant sys entries (having
> moved my encoder A/B lines to the relevant pins each time), I get a
> changing value but it isn't meaningful. Am I missing something, or is it
> more likely that I've blown up the inputs? I did power on the servo drive
> (that was connected to the 26lv32 breakout board) by accident when the BBB
> wasn't powered up.
>
> I've tested with a simple 24ppr 'audio style' encoder and again don't get
> meaningful results.
>
> Do I have to mess about with config-pin for each of the eQEP inputs, or
> should loading the relevant dtbo file for the eQEP module (0, 1 2 etc) set
> up the pins for me?
>
> There's so much old documentation floating about it's hard to identify
> what is current and what is no longer relevant now that the universal-cape
> is in existence.
>
> Regards, Hugh
>
> --
> 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/c28fc73b-b2f4-4e73-8318-fd37599ef3b6%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CA%2B-ZLiuE5W_ATODEU2N3Liv7eu8yx-T1Ljg4CirocdmqU6aFgA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] eQEP not reading meaningful values

[Hugh Frater]

Hi, I'm getting started on a control system that needs to read 2x 
quadrature encoders. One is a 1000 line, the other a 2000 line, but that is 
really immaterial. I have the physical interface sorted (one needs a 26lv32 
to glue it to the BBB, the other is open collector), and the traces look 
good on the scope.

I'm running Jessie IOT with 4.4.36, I have disabled hdmi and universal 
cape. I can load Nathaniel Lewis' overlays (supplied with the clean install 
of Jessie) just fine with no errors in dmesg.

However when I 'cat position' in each of the relevant sys entries (having 
moved my encoder A/B lines to the relevant pins each time), I get a 
changing value but it isn't meaningful. Am I missing something, or is it 
more likely that I've blown up the inputs? I did power on the servo drive 
(that was connected to the 26lv32 breakout board) by accident when the BBB 
wasn't powered up.

I've tested with a simple 24ppr 'audio style' encoder and again don't get 
meaningful results.

Do I have to mess about with config-pin for each of the eQEP inputs, or 
should loading the relevant dtbo file for the eQEP module (0, 1 2 etc) set 
up the pins for me?

There's so much old documentation floating about it's hard to identify what 
is current and what is no longer relevant now that the universal-cape is in 
existence.

Regards, Hugh

-- 
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/c28fc73b-b2f4-4e73-8318-fd37599ef3b6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: can't load device tree on Debian jessie 8.6 with kernel version 4.4.43-ti-r84

[Greg]

The am33xx-pruss-rproc.dtsi file has to included to activate the RemoteProc 
framework.
I don't have any good links to the details, however, there are two 
frameworks for working with the PRUs that I know of:
UIO
RemoteProc

UIO is far more mature, and from reading various postings here it seems to 
have some performance advantages.
There are kernel space drivers, and RemoteProc is an example.
There are user-space drivers, and the UIO framework is an example.
You have to start drilling into operating system details, but don't ask me 
as I am going up the learning curve on this stuff slowly.
If you do some searching there is tons of material to read.
This is good stuff, but there are thousands of details.

Anyway, since some are using UIO, and some are using RemoteProc, it is left 
to the user to select the active PRU driver framework.
So that is why you have to edit the dts file and re-compile.

Be cautious when loading overlays.  There is lots of obsolete info out 
there.  You should edit uEnv.txt in the boot directory to accomplish this.
Don't try to use config-pin or the echo slot method which you will find all 
over the web.
It might work, or it might not, but it is not worth messing with it.  Just 
edit uEnv.txt and you will get the job done.

Greg

-- 
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/a90be576-70d9-474c-aadf-a97d3d1d5a44%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: eQEP on 4.4.19-ti-r41

[Hugh Frater]

Did you ever get any further with this? I'm struggling with eQEP on 4.4.36 
- but for different reasons

Hugh

On Wednesday, 14 September 2016 21:22:06 UTC+1, Mark A. Yoder wrote:
>
> Hi:
>   I'm running BeagleBoard.org Debian Image 2016-08-28 which is running 
> the 4.4.19-ti-r41 kernel.  I've disabled the HDMI (audio and video) and 
> want to use the eQEPs.
>
> *ls /lib/firmware/ | grep -i eqep*
> bone_eqep0-00A0.dtbo
> bone_eqep1-00A0.dtbo
> bone_eqep2-00A0.dtbo
> bone_eqep2b-00A0.dtbo
> PyBBIO-eqep0-00A0.dtbo
> PyBBIO-eqep1-00A0.dtbo
> PyBBIO-eqep2-00A0.dtbo
> PyBBIO-eqep2b-00A0.dtbo
>
> shows I have several options.  However none seem to work.
>
> *echo bone_eqep1 > $SLOTS* 
> -bash: echo: write error: File exists
> *dmesg*
> [Sep14 16:15] bone_capemgr bone_capemgr: part_number 'bone_eqep1', version 
> 'N/A'
> [  +0.75] bone_capemgr bone_capemgr: slot #9: override
> [  +0.45] bone_capemgr bone_capemgr: Using override eeprom data at 
> slot 9
> [  +0.46] bone_capemgr bone_capemgr: slot #9: 'Override Board 
> Name,00A0,Override Manuf,bone_eqep1'
> [  +0.012094] bone_capemgr bone_capemgr: slot #9: bone_eqep1 conflict 
> P8.35 (#4:univ-emmc)
> [  +0.008573] bone_capemgr bone_capemgr: slot #9: Failed verification
>
> So it looking like the emmc overlay is controlling the pin.
>
> What's the correct way to get emmc overlay to let me use the pin?
>
> Do I have to get dtb-4.4-ti and edit am335x-boneblack-emmc-overlay.dtb? 
>  If so, what do I edit?
>
> I'm looking for a general approach that I can apply to other pins I want 
> to control.
>
> Thanks...
>
> --Mark
>

-- 
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/e972eae7-97c1-4eef-b63a-1cdcd3d3dcba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] i2c read block

[Francis]

Hi,

I am trying to create an application on top/based on the i2c tools.
Everything was working well, except the i2c_smbus_block_process_call(), 
which returns an error when called.

Below is the output of i2cdetect -F:

Functionalities implemented by /dev/i2c-2:
I2C  yes
SMBus Quick Command  no
SMBus Send Byte  yes
SMBus Receive Byte   yes
SMBus Write Byte yes
SMBus Read Byte  yes
SMBus Write Word yes
SMBus Read Word  yes
SMBus Process Call   yes
SMBus Block Writeyes
SMBus Block Read no
SMBus Block Process Call no
SMBus PECyes
I2C Block Write  yes
I2C Block Read   yes

-

Based from it, I could tell that SMBus Process Call is not supported.
could anyone suggests an alternative or give directions on how to make a 
process call?

Thanks in advance!

Francis

-- 
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/161adc80-973f-4cc2-8a3c-2d4015186288%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: can't load device tree on Debian jessie 8.6 with kernel version 4.4.43-ti-r84

[Ashwini Bhat]

I did the Echo Lab 5 and everything seemed to go fine. I ran prumsg and all 
I saw was a quick squarewave and then the pin would stay high.
Ok, I played with it some more and I am trying to get 
/home/debian/pru-software-support-package/examples/am335x/PRU_gpioToggle 
example to work.  And as you guessed I am not seeing anything toggle for 
P8_11 under PRU0.  I see that P8_11 is on pruout (when doing config-pin 
P8_11) as is defined by 
https://www.cs.sfu.ca/CourseCentral/433/bfraser/other/2016-student-howtos/PRU_GPIO_guide.pdf
  
I am not using P8_27 due to having to load in a new overlay and I don't 
know if its going to load cape-universala is going to boot of the SD card 
or not, so I didn't want to risk it.  Anyways, everything goes and I hit no 
errors.  I copied the out file into am335x-pru0-fw.  So I am confused 
here.  I don't know where the issue is coming from, why I can't see the 
GPIO pin being toggled on the scope.  I was also going through your 
directions and had some questions, 
Why include am33xx-pruss-rproc.dtsi? Does this mean I have to include some 
other files for the 
Why did you have blacklist certain files? Do I have to blacklist certain 
files too?
As I am reading through you previous emails maybe I will give my hand at 
Lab 6 and see if I can see anything toggle in the meantime.  Let me know 
your thoughts.  This is really helpful, but there is so much going on I am 
having a hard time wrapping my head around everything that is happening, I 
don't know if its just me thats having such a hard time...
Thanks again for you time and your patience.
-Ashwini

On Thursday, February 2, 2017 at 1:51:51 AM UTC-8, Ashwini Bhat wrote:
>
> Sweet! Thanks a lot man! Let me play with this for a day or 2. I am 
> definitely going to have questions but just need to get my thoughts in 
> order!
>
> On Wednesday, February 1, 2017 at 4:23:22 AM UTC-8, Greg wrote:
>>
>> OK, great!
>>
>> So exactly which firmware are you using?  In my docs, for set-up purposes 
>> I suggest the PRUmsg Echo Lab 5.
>>
>> So this example does not intentionally toggle any GPIO.  The idea is that 
>> if you can get this lab to work, the PRU RemoteProc kernel drivers are 
>> completely functional.
>>
>> The final thing to do with this example is to compile the user-space C 
>> program and run it.
>> I think the Makefile handles this, but compiling any C program for 
>> user-space is easy:
>>
>> gcc main.c -o pru_msg_test
>>
>> or something like that.
>> Running the user-space test program does a simple exercise of the 
>> RemoteProc messaging character devices.
>> Lab 6 toggles an LED using the PRU and uses the same character device 
>> mechanism to control the PRU.
>> Let me know if you have any more questions.  I think you have gained a 
>> lot of capability to experiment with the PRUs.
>>
>> Greg
>>
>

-- 
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/7d500eb3-b203-426a-a87c-692d08777bcc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] [RFC] XMEGA PDI programming with a AM335x processor

[Enric Balletbo Serra]

Dear all,

This is a request for comments/testers/reviewers :)

Avrdude is a known tool to flash firmware on amount of AVR devices,
I've been working on add XMEGA PDI programming support using the
Programmable Realtime Unit (PRUSS) available on AM335x based boards
like Beaglebone Black. With this you can program an XMEGA in-circuit
without requiring any external hardware. The programmer needs a custom
firmware that needs to be loaded to the PRU [1], avrdude loads the
firmware and communicates with it to be able to program the firmware
on XMEGA, the code is available here [2] and the specific commit that
adds support for it is here [3]. It works doing

 avrdude -p atxmega16d4 -c pruss -e -U flash:w:my-firmware.hex

But there is still an issue that I need to solve, though I have a
workaround to make it work. I'm pretty sure that the problem is in the
PRU firmware side so not a problem with avrdude. Nevermind if you want
to help test, review or give me your comments all are welcome. Do not
hesitate to contact me if you are interested on this, either by email
or in the irc (nickname eballetbo). I hope have a stable version soon
but meanwhile, I repeat, if anyone would like to test all feedback is
welcome.

Best regards,

 Enric


[1] https://github.com/eballetbo/pdi-pruss
[2] https://github.com/eballetbo/avrdude
[3] 
https://github.com/eballetbo/avrdude/commit/ba3cb893cf3931033faeb4ebe0c296842f168cc7

-- 
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/CAFqH_52tekQ4WxT79%2BG%3D8O6xgmBKtJ%3DHCt-D2vjRjC-SgR0GPw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.