[beagleboard] Re: PRU_EVTOUT_1 sent from PRU0 does not clear with sysevent = PRU0_ARM_INTERRUPT

[Doug Lewis]

  writes:

> 
> 
> Hello all!I have been working on a code where in which I use the interrupt 
PRU_EVTOUT_1 as a heartbeat from the PRU to the host. Currently, however, I 
have not been able to clear the interrupt so that it can be sent again. A 
(partial) minimal example is found below. As it is, the code does not work 
(for me at least... maybe I'm doing something stupid). This code works when 
PRU_EVTOUT_1 is replaced by PRU_EVTOUT_0 or when PRU0_ARM_INTERRUPT is 
replaced by PRU1_ARM_INTERRUPT.I edited prussdrv.c to find out where the 
issue is coming from and it seems that the wrong bit is cleared in SECR1 
using the values below. That is:- when I send PRU0_R31_VEC_VALID | 
PRU_EVTOUT_0, I get SERC1 = 0x8, which is correctly cleared by 
PRU0_ARM_INTERRUPT = 19- when I send PRU0_R31_VEC_VALID | PRU_EVTOUT_1, I 
get SERC1 = 0x10, which is correctly cleared by PRU1_ARM_INTERRUPT = 
20That makes sense given that PRU0_R31_VEC_VALID | PRU_EVTOUT_1 = 
PRU1_ARM_INTERRUPT + 16. The second form is found in the example codes for 
prussdrv, whereas the first one is used in Derek Molloy's EBB (ultrasonic 
example, chapter 13).Is PRU_EVTOUT_1 from PRU0 the same as sending 
PRU_EVTOUT_0 from PRU1? That seems odd, but I wasn't able to figure it out 
from the reference guide. I must be doing something wrong, I just don't know 
what!Any help is appreciated! I am using the latest version of the 
am335x_pru_package (built directly from the repository).Cheers!prumain.p:
> .origin 0                        // start of program in PRU 
memory.entrypoint START                // program entry point#define 
PRU0_R31_VEC_VALID 32#define PRU_EVTOUT_0 3#define PRU_EVTOUT_1 4START:    
// Send interrupt to host    MOV R31.b0, PRU0_R31_VEC_VALID | PRU_EVTOUT_1  
  // Wait for 1 second    MOV r3, DELAY_MS    DELAY:        SUB r3, r3, 1    
    QBNE DELAY, r3, 0    // Send interrupt to host    MOV R31.b0, 
PRU0_R31_VEC_VALID | PRU_EVTOUT_1    // Halt    HALT
> 
> main.c:
> /* Wait for PRU_EVTOUT_1 */n = 
prussdrv_pru_wait_event(PRU_EVTOUT_1);printf("This is the PRU_EVTOUT_1 
number %d.\n", n);prussdrv_pru_clear_event(PRU_EVTOUT_1, 
PRU0_ARM_INTERRUPT);/* Wait for PRU_EVTOUT_0 (will go through this one 
instead of waiting for the delay in prumain.p */n = 
prussdrv_pru_wait_event(PRU_EVTOUT_1);printf("This is the PRU_EVTOUT_1 
number %d.\n", n);prussdrv_pru_clear_event(PRU_EVTOUT_1, 
PRU0_ARM_INTERRUPT);
> 
> 
> 
> 
> 
> 


-- 
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/loom.20160630T000530-436%40post.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Snappy Ubuntu Core on BBB--How do I enable serial ports?

[santacruz . doug]

I want to enable one or more of the available serial ports, in addition to 
UART0, but I've been unable to find any guidance on how to do this. Any 
help will be greatly appreciated.

-- 
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] New DTO & RSCM

[Doug Edey]

I still want to be able to understand how to enable the ports and use one wire 
in the newer kernels. I can see the one wire driver being loaded on startup. 
But I cannot see /sys/devices/w1_devices

-- 
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] New DTO & RSCM

[Doug Edey]

On Thursday, November 20, 2014 11:41:08 PM UTC-5, RobertCNelson wrote:
>
> > Surely, as a fellow software dev, if you have to explain yourself a lot, 
> > there's an issue (I've worked on a lot of massive projects down to the 
> low 
> > level, JVM -> network management product for ISPs/larger) 
>
> Simply, what was developed for v3.8.x was out-right rejected by 
> mainline.  The main author is still working on it, some low level 
> parts are now mainline, but we won't see anything till v3.19/20... 
>
> Regards, 
>
> -- 
> Robert Nelson 
> http://www.rcn-ee.com/ 
>

Oh, I thought the 3.8.x changes were FROM mainline. Sorry! 

-- 
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] New DTO & RSCM

[Doug Edey]

On Thursday, November 20, 2014 11:32:13 PM UTC-5, RobertCNelson wrote:
>
> On Thu, Nov 20, 2014 at 10:25 PM, Doug Edey  > wrote: 
> > The DTB doesn't match the hardware, it matches the kernel? That 
> seems 
> > odd... 
> > 
> > I ran those. commands, uEnv still points at am335-boneblack.dtb, but I 
> don;t 
> > see any one wire devices, even though there is one connected in the same 
> > configuration as the old kernel 3.8 that used the previous DTB I pasted 
> > which was exported to the capemgr. 
>
> Then just: 
>
> sudo apt-get update 
> sudo apt-get install linux-image-3.8.13-bone67 
> sudo reboot 


No, I want to support the changes you've made to kernel 3.13 running.  

-- 
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] New DTO & RSCM

[Doug Edey]

>
>
> Then just: 
>
> sudo apt-get update 
> sudo apt-get install linux-image-3.8.13-bone67 
> sudo reboot 
>
> Running
 

> > What was the reason for the change away from capemgr? capemgr seemed to 
> > "work" 
>
> Search the list, it's been explained too often. 
>
Surely, as a fellow software dev, if you have to explain yourself a lot, 
there's an issue (I've worked on a lot of massive projects down to the low 
level, JVM -> network management product for ISPs/larger) 

-- 
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] New DTO & RSCM

[Doug Edey]

The DTB doesn't match the hardware, it matches the kernel? That seems 
odd...

I ran those. commands, uEnv still points at am335-boneblack.dtb, but I 
don;t see any one wire devices, even though there is one connected in the 
same configuration as the old kernel 3.8 that used the previous DTB I 
pasted which was exported to the capemgr.

What was the reason for the change away from capemgr? capemgr seemed to 
"work"

-- 
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] New DTO & RSCM

[Doug Edey]

/am335x-boneblack-ttyO2.dtb'
'src/arm/am335x-boneblack-ttyO4.dtb' -> 
'/boot/dtbs/3.14.22-ti-r31/am335x-boneblack-ttyO4.dtb'
'src/arm/am335x-boneblack-ttyO5.dtb' -> 
'/boot/dtbs/3.14.22-ti-r31/am335x-boneblack-ttyO5.dtb'
'src/arm/am335x-boneblack.dtb' -> 
'/boot/dtbs/3.14.22-ti-r31/am335x-boneblack.dtb'
'src/arm/am335x-evm.dtb' -> '/boot/dtbs/3.14.22-ti-r31/am335x-evm.dtb'
'src/arm/am335x-evmsk.dtb' -> '/boot/dtbs/3.14.22-ti-r31/am335x-evmsk.dtb'
'src/arm/am335x-nano.dtb' -> '/boot/dtbs/3.14.22-ti-r31/am335x-nano.dtb'
'src/arm/am3517-craneboard.dtb' -> 
'/boot/dtbs/3.14.22-ti-r31/am3517-craneboard.dtb'
'src/arm/am3517-evm.dtb' -> '/boot/dtbs/3.14.22-ti-r31/am3517-evm.dtb'
'src/arm/am3517_mt_ventoux.dtb' -> 
'/boot/dtbs/3.14.22-ti-r31/am3517_mt_ventoux.dtb'
'src/arm/am437x-gp-evm-hdmi.dtb' -> 
'/boot/dtbs/3.14.22-ti-r31/am437x-gp-evm-hdmi.dtb'
'src/arm/am437x-gp-evm.dtb' -> '/boot/dtbs/3.14.22-ti-r31/am437x-gp-evm.dtb'
'src/arm/am437x-sk-evm.dtb' -> '/boot/dtbs/3.14.22-ti-r31/am437x-sk-evm.dtb'
'src/arm/am43x-epos-evm-hdmi.dtb' -> 
'/boot/dtbs/3.14.22-ti-r31/am43x-epos-evm-hdmi.dtb'
'src/arm/am43x-epos-evm.dtb' -> 
'/boot/dtbs/3.14.22-ti-r31/am43x-epos-evm.dtb'
'src/arm/am57xx-beagle-x15.dtb' -> 
'/boot/dtbs/3.14.22-ti-r31/am57xx-beagle-x15.dtb'
'src/arm/dra7-evm-lcd10.dtb' -> 
'/boot/dtbs/3.14.22-ti-r31/dra7-evm-lcd10.dtb'
'src/arm/dra7-evm-lcd7.dtb' -> '/boot/dtbs/3.14.22-ti-r31/dra7-evm-lcd7.dtb'
'src/arm/dra7-evm.dtb' -> '/boot/dtbs/3.14.22-ti-r31/dra7-evm.dtb'
'src/arm/dra72-evm-lcd10.dtb' -> 
'/boot/dtbs/3.14.22-ti-r31/dra72-evm-lcd10.dtb'
'src/arm/dra72-evm-lcd7.dtb' -> 
'/boot/dtbs/3.14.22-ti-r31/dra72-evm-lcd7.dtb'
'src/arm/dra72-evm.dtb' -> '/boot/dtbs/3.14.22-ti-r31/dra72-evm.dtb'
'src/arm/k2hk-evm.dtb' -> '/boot/dtbs/3.14.22-ti-r31/k2hk-evm.dtb'
'src/arm/omap3-beagle-xm.dtb' -> 
'/boot/dtbs/3.14.22-ti-r31/omap3-beagle-xm.dtb'
'src/arm/omap3-beagle.dtb' -> '/boot/dtbs/3.14.22-ti-r31/omap3-beagle.dtb'
'src/arm/omap3-cm-t3730.dtb' -> 
'/boot/dtbs/3.14.22-ti-r31/omap3-cm-t3730.dtb'
'src/arm/omap3-devkit8000.dtb' -> 
'/boot/dtbs/3.14.22-ti-r31/omap3-devkit8000.dtb'
'src/arm/omap3-evm-37xx.dtb' -> 
'/boot/dtbs/3.14.22-ti-r31/omap3-evm-37xx.dtb'
'src/arm/omap3-evm.dtb' -> '/boot/dtbs/3.14.22-ti-r31/omap3-evm.dtb'
'src/arm/omap3-gta04.dtb' -> '/boot/dtbs/3.14.22-ti-r31/omap3-gta04.dtb'
'src/arm/omap3-igep0020.dtb' -> 
'/boot/dtbs/3.14.22-ti-r31/omap3-igep0020.dtb'
'src/arm/omap3-igep0030.dtb' -> 
'/boot/dtbs/3.14.22-ti-r31/omap3-igep0030.dtb'
'src/arm/omap3-ldp.dtb' -> '/boot/dtbs/3.14.22-ti-r31/omap3-ldp.dtb'
'src/arm/omap3-n9.dtb' -> '/boot/dtbs/3.14.22-ti-r31/omap3-n9.dtb'
'src/arm/omap3-n900.dtb' -> '/boot/dtbs/3.14.22-ti-r31/omap3-n900.dtb'
'src/arm/omap3-n950.dtb' -> '/boot/dtbs/3.14.22-ti-r31/omap3-n950.dtb'
'src/arm/omap3-overo-storm-tobi.dtb' -> 
'/boot/dtbs/3.14.22-ti-r31/omap3-overo-storm-tobi.dtb'
'src/arm/omap3-overo-tobi.dtb' -> 
'/boot/dtbs/3.14.22-ti-r31/omap3-overo-tobi.dtb'
'src/arm/omap3-sbc-t3730.dtb' -> 
'/boot/dtbs/3.14.22-ti-r31/omap3-sbc-t3730.dtb'
'src/arm/omap3-zoom3.dtb' -> '/boot/dtbs/3.14.22-ti-r31/omap3-zoom3.dtb'
'src/arm/omap3430-sdp.dtb' -> '/boot/dtbs/3.14.22-ti-r31/omap3430-sdp.dtb'
'src/arm/omap4-panda-a4.dtb' -> 
'/boot/dtbs/3.14.22-ti-r31/omap4-panda-a4.dtb'
'src/arm/omap4-panda-es.dtb' -> 
'/boot/dtbs/3.14.22-ti-r31/omap4-panda-es.dtb'
'src/arm/omap4-panda.dtb' -> '/boot/dtbs/3.14.22-ti-r31/omap4-panda.dtb'
'src/arm/omap4-sdp-es23plus.dtb' -> 
'/boot/dtbs/3.14.22-ti-r31/omap4-sdp-es23plus.dtb'
'src/arm/omap4-sdp.dtb' -> '/boot/dtbs/3.14.22-ti-r31/omap4-sdp.dtb'
'src/arm/omap4-var-som.dtb' -> '/boot/dtbs/3.14.22-ti-r31/omap4-var-som.dtb'
'src/arm/omap5-uevm.dtb' -> '/boot/dtbs/3.14.22-ti-r31/omap5-uevm.dtb'


Edited my uEnv.txt to:

#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0

uname_r=3.14.22-ti-r31

dtb=am335x-boneblack.dtb

uuid=a9ecee33-898c-4ddb-a96c-461b113cc230

cmdline=quie

Re: [beagleboard] New DTO & RSCM

[Doug Edey]

OK, I'm still unclear as to how my old dts for one wire:

/*
* Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*
* Modified by Russell Senior from the weather cape's DTS file.
* Minor formatting by C W Rose.
*/
/dts-v1/;
/plugin/;
/ {
compatible = "ti,beaglebone", "ti,beaglebone-black";
part-number = "BB-W1";
version = "00A0";
exclusive-use = "P8.11";
fragment@0 {
target = <&am33xx_pinmux>;
__overlay__ {
bb_w1_pins: pinmux_bb_w1_pins {
pinctrl-single,pins = <
0x34 0x37 /* gpmc_ad13.gpio1_13, OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE7 - 
w1-gpio */
>;
};
};
};
fragment@1 {
target = <&ocp>;
__overlay__ {
onewire@0 {
status = "okay";
compatible = "w1-gpio";
pinctrl-names = "default";
pinctrl-0 = <&bb_w1_pins>;
gpios = <&gpio2 13 0>;
};
};
};
};


Would convert to the new dtsi, is there any documentation on the dtsi?

-- 
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] New DTO & RSCM

[Doug Edey]

So, I'm finding the "Really Simple Cape Manager" anything but simple... 

I made a Java DTO library that would use a JSON file 
(https://github.com/DougEdey/SB_Elsinore_Server/blob/master/extras/beaglebone.json)
 
to create Device Tree Overlays that could be applied easily.

This created files that could do basic GPIO exports, but I'm 
confused/concerned about how to do this for the new RSCM. There's no lines 
in the boneblack.dts 
(https://github.com/RobertCNelson/rscm/blob/master/3.13-bone/am335x-boneblack.dts)
 
that indicate which GPIO pins are which, and, much more concerningly to me, 
I have no idea how to enable OneWire like I used to, using this 
(https://github.com/DougEdey/SB_Elsinore_Server/blob/master/extras/w1.dts) 
source.

Am I missing something very fundamental? Like some documentation or 
instructions for how to use RSCM? I have a lot of users who want to use the 
BBB and I want to support the latest kernel images.

-- 
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: Archlinux 3.16 kernel no acpi

[Doug]

OK so my understanding is that this works with patches on 3.15 but not 
3.16???  I need stable USB which I think was fixed in 3.13 ??? Were there 
significant changes past 3.13 that effected the power down? What version 
works right but also includes the usb fixes?

-- 
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: Archlinux 3.16 kernel no acpi

[Doug]

Robert,

 Do you know who the point of contact is for the archlinux kernel on the 
Black? I am assuming this works fine in Debian? Have you used this kernel 
yet in Debian?

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Archlinux 3.16 kernel no acpi

[Doug]

It appears the 3.16 Archlinux kernel does not have acpi turned on and the 
power button is not working. Also a system shutdown does not turn off the 
power led as it did in prior kernels. Anyone have any info on this? Will 
this be supported in the future? I want to be able to gracefully power down 
with the power button. 

-- 
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] Boot failures with 2014-07-06 drops

[Doug Edey]

 Wait, the boot button has to be pressed every single time it powers off 
and on? This isn't good at all, I have a cape on my board.

>
>

-- 
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] Boot failures with 2014-07-06 drops

[Doug Edey]

I just tried the 2014-07-06 drops of Ubuntu (both 14.04 and Utopic) and I 
get 3 solid LEDs (0, 1, 2) on boot, and nothing else. This tells me the 
flash didn't work. But if I roll back to the 2014-06-05 drops, everything 
is fine.

Has anyone else seen this issue? Or is there something weird I'm doing 
differently?

For all the drops I've used: setup_sdcard.sh --mmc /dev/sdc --dtb beaglebone

-- 
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: Booting Archlinux from microSD (again)

[Doug]

Robert,

 I don't think you get my point or maybe I am not understanding the BBB 
evolution.  We have a large number of individuals who have already 
purchased rev B boards. They will not have any updated eMMC code. What is 
there is there. On the other hand some will be purchasing the Rev C which 
will be available in a few weeks.

If there is a fix we can do in Arch Linux that will universally fix our 
boot issue for any circumstance of eMMC state, Rev B, C  without touching 
eMMC then I am all for it. If not then getting eMMC out of the way is the 
best choice.

BTW we would be using Debian but it clearly does not work for our 
application. Besides periodic crashes we had problems with USB audio. 
Runnng Archlinux solved all those problems.  


-- 
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: Booting Archlinux from microSD (again)

[Doug]

>> Oh those days are coming! Trust me, you'll enjoy the way i setup the
>> bootloader flashed to the eMMC in the new default debian based image.
>> It'll make things for Arch and other distro's much easier to control
>> boot, without messing with the eMMC.

Robert,

  I am not sure what you are saying here. In one sentence you are saying 
something about flashing a bootloader to the eMMC and then in the last 
sentence saying not messing with the eMMC. Does the Debian uSD install 
change something on the eMMC?

I am trying to come up with the best approach in distributing an Archlinux 
image on uSD. that will boot without user intervention. We know that 
zeroing the first 1M of blk1 will permanently fix it.  Another less harmful 
and reversible method is to mount blk1p1 and rename  MLO to MLO.keep  or 
anything other than just MLO. You can rename it back and have it boot from 
eMMC if you desire.

I don't like the idea of configuring this to work (if we can) using the 
current blk1p1 (eMMC boot) because that could change in the future. Our 
application does not care about the eMMC at all. I wish there was no eMMC 
even there. It would be great if they could make a version without it at a 
cheaper or same price rather than the increase we are going to see with rev 
C. It would have been as simple as putting a jumper on the board to set the 
default boot.

I think the approach we will tak is the renaming of the eMMC MLO file. A 
couple of scripts distributed with our image would either turn it off or on 
so the user would have the option one way or the other.



-- 
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: Booting Archlinux from microSD (again)

[Doug]

William,

 I only made that statement because you were the one that emphatically said 
it does work with Archlinux. If you know that for a fact then you should 
have the boot code that works. It would not be any different for me.  

-- 
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: Booting Archlinux from microSD (again)

[Doug]

OK me again - the original poster. No new info but I wanted to comment on 
the later posts.

First of all if there is nothing on the eMMC it boots fine from the uSD. On 
one of my BBB's I zero'ed the eMMC and it just boots from the uSD. No 
buttons just boots.

Just to make it clear. I want to be able to boot at power up from the uSD 
running Archlinux without pushing modifying or changing anything on the 
stock BBB or its eMMC. If this can be achieved with changes to the uSD 
cards boot partition that would be great. Someone keeps saying it is 
working - well tell me what files you have on the Archlinux boot partition. 
Show me the dates? Also the contents of the uEnv.txt file on the uSD. 

The concern I have is thatin the future if changes are made on the eMMC 
boot record as shipped it might screw up the boot of the uSD. Perhaps the 
best way to do this is just to zap the eMMC. No one is going to need the 
Angstrom code anyway and if they ever do they can recreate.


-- 
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: Booting Archlinux from microSD (again)

[Doug]

Robert, yes, that is my conclusion and I will report back after we get more 
information. Thanks.


-- 
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: Booting Archlinux from microSD (again)

[Doug]

OK a couple of answers to those who responded.

Taking out initrd did not fix the problem. We are a little bit in the dark 
though until we get the serial port hooked up to see what is going on.

Thanks for the explanation of the boot sequence. 

It is becoming clear that there may not be a fix that does not involve 
changing something in the eMMC. If I finally determine that is the case 
then I think the option I will take is to include in my image a one time 
first boot script that zero's the first 1M of the eMMC. I know most that 
would read this are much more savvy then the users I would send this image 
to. I cannot expect a user to start mucking around with editing the eMMC. 
Hopefully there will be a better way.

Why the current Debian will boot to MicroSD with the stock eMMC and 
Archlinux will not is the question. I am assuming it has to have something 
to do with the boot partition of Archlinux vs. Debian on the SD card since 
the eMMC is the same.

My Archlinux stock boot looks like this -

 MLO  u-boot.img  uEnv.txt

[root@BBBdoug sbin]# cat /mnt/uEnv.txt
uenvcmd=run findmmc1; run findmmc0; if run loaduimage; then run loadfdt; 
run mmcboot; fi;
findmmc1=if test $board_name = A335BNLT; then setenv mmc1 1; else setenv 
mmc1 0; fi
findmmc0=setenv mmcdev 0; mmc dev ${mmcdev}; if mmc rescan; then setenv 
mmc0 1; else setenv mmc0 0; fi
mmcroot=/dev/mmcblk0p2 rw
loadfdt=ext4load mmc ${mmcdev}:2 ${fdtaddr} /boot/dtbs/${fdtfile}
loaduimage=if ext4load mmc 0:2 ${loadaddr} /boot/zImage; then setenv mmcdev 
0; else setenv mmcdev 1; if test $mmc0 = 1; then setenv mmcroot 
/dev/mmcblk1p2 rw; fi; ext4load mmc 1:2 ${loadaddr} /boot/zImage; fi
optargs=coherent_pool=1M

As you can see the Archlinux kernel is located in the root partition and 
referenced in  uEnv.txt


-- 
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: Booting Archlinux from microSD (again)

[Doug]

OK this does not work on Archlinux. Besides the fact Archlinux does not 
have initrd there must be some other issue holding it up. We are getting a 
serial connection hooked up to look at that.

The answer about the only way was to remove a resistor is NOT a good 
answer. First of all it is not something you would do when distributing and 
image to be written on an SD card to a user. Hack your board so it works! 
No way. 

I would like to get this fixed but an easy answer would be to have a script 
that does a one time run of zeroing the eMMC on first boot of ArchLinux on 
the SD card. We have no reason to use the eMMC card in our application. I 
wish there was a HW switch or jumper on the BBB to disable it. That would 
make things much easier.

So please don't go hacking your board, just nuke the code on the eMMC. It 
will then boot happily from the SD card.

Hopefully we will find a better way so we won't have to do that. I will 
report back in a few days with any progress.

On Sunday, April 27, 2014 10:15:04 PM UTC-4, Doug wrote:
>
> OK I asked this question before and I was never able to resolve it.
>
> I have an image (application) on microSD card that I want to distribute. 
> It uses Archlinux.  
>
> I don't want the user to have to play with boot directories pushing 
> buttons or anything like that. I just want it to boot at power up.
>
> As long as a distribution (stock) image is on the eMMC it will not boot 
> the SD card unless the boot button is held down at power up.
>
> I can get around this by wiping the eMMC but I do not want a user getting 
> an image on SD and having to do that.
>
> Is there anything I can do on the SD card (boot record) to cause it to 
> boot directly from SD regardless of what is on eMMC. 
>
> Debian apparently has no problem with this. It seems to be an Archlinux 
> issue.
>
> If therei s an answer please pass along the code or point me to it. 
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Booting Archlinux from microSD (again)

[Doug]

OK I asked this question before and I was never able to resolve it.

I have an image (application) on microSD card that I want to distribute. It 
uses Archlinux.  

I don't want the user to have to play with boot directories pushing buttons 
or anything like that. I just want it to boot at power up.

As long as a distribution (stock) image is on the eMMC it will not boot the 
SD card unless the boot button is held down at power up.

I can get around this by wiping the eMMC but I do not want a user getting 
an image on SD and having to do that.

Is there anything I can do on the SD card (boot record) to cause it to boot 
directly from SD regardless of what is on eMMC. 

Debian apparently has no problem with this. It seems to be an Archlinux 
issue.

If therei s an answer please pass along the code or point me to it. 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: ArchLinux SD card boot

[Doug]

Well the option I took was to nuke mmcblk1 which worked. I have no reason 
to have anything there anyhow. I am running a headless system in ArchLinux. 
I don't have time to fool around with why it isn't working when I am not 
going to use it. None of the options suggested worked other than dd'ing the 
eMMC. 

On Friday, April 18, 2014 10:47:57 AM UTC-4, Doug wrote:
>
> I have ArchLinux installed and it reboots fine - shutdown -r now - but if 
> I power down and restart it goes to four LED's and stops. If I hold down 
> the boot button and power it will then boot.
>
> How do I get it to boot at power up always from the SD card?  My boot 
> partition has the following files -
>
> 102 -rwxr-xr-x  1 root root 104212 Aug 10  2013 MLO
> 354 -rwxr-xr-x  1 root root 361488 Aug 10  2013 u-boot.img
>   2 -rwxr-xr-x  1 root root603 Oct 18  2013 uEnv.txt
>
> and uEnv.txt has -
>
> [root@BBBdoug mnt]# cat uEnv.txt
> uenvcmd=run findmmc1; run findmmc0; if run loaduimage; then run loadfdt; 
> run mmcboot; fi;
> findmmc1=if test $board_name = A335BNLT; then setenv mmc1 1; else setenv 
> mmc1 0; fi
> findmmc0=setenv mmcdev 0; mmc dev ${mmcdev}; if mmc rescan; then setenv 
> mmc0 1; else setenv mmc0 0; fi
> mmcroot=/dev/mmcblk0p2 rw
> loadfdt=ext4load mmc ${mmcdev}:2 ${fdtaddr} /boot/dtbs/${fdtfile}
> loaduimage=if ext4load mmc 0:2 ${loadaddr} /boot/zImage; then setenv 
> mmcdev 0; else setenv mmcdev 1; if test $mmc0 = 1; then setenv mmcroot 
> /dev/mmcblk1p2 rw; fi; ext4load mmc 1:2 ${loadaddr} /boot/zImage; fi
> optargs=coherent_pool=1M
>
> As far as I can tell this is the latest code.
>
> What do I need to do to get it to always boot without intervention from 
> the micoSD card?
>
>

-- 
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: ArchLinux SD card boot

[Doug]

BTW the thread you referenced is referring to booting from the emmc not the 
SD. The original author wanted to use the SD as just memory space.

Somewhere in there a number of people comment that -

"latest uboot has changed behaviors, and no longer requires the button 
press to boot from the SD"

So does this mean the uboot on the emmc or on the sd card. I have the 
latest on the sd card. The emmc has what came with it which was two weeks 
ago. Do I just need to update the emmc boot files?

This seems to be an oft asked question. I don't think it has anything to do 
with a specific OS but rather the uboot code on the emmc and/or SDcard. 
Isn't there one place where this is answered without a lot of argument as 
to how to do it?



On Friday, April 18, 2014 10:47:57 AM UTC-4, Doug wrote:
>
> I have ArchLinux installed and it reboots fine - shutdown -r now - but if 
> I power down and restart it goes to four LED's and stops. If I hold down 
> the boot button and power it will then boot.
>
> How do I get it to boot at power up always from the SD card?  My boot 
> partition has the following files -
>
> 102 -rwxr-xr-x  1 root root 104212 Aug 10  2013 MLO
> 354 -rwxr-xr-x  1 root root 361488 Aug 10  2013 u-boot.img
>   2 -rwxr-xr-x  1 root root603 Oct 18  2013 uEnv.txt
>
> and uEnv.txt has -
>
> [root@BBBdoug mnt]# cat uEnv.txt
> uenvcmd=run findmmc1; run findmmc0; if run loaduimage; then run loadfdt; 
> run mmcboot; fi;
> findmmc1=if test $board_name = A335BNLT; then setenv mmc1 1; else setenv 
> mmc1 0; fi
> findmmc0=setenv mmcdev 0; mmc dev ${mmcdev}; if mmc rescan; then setenv 
> mmc0 1; else setenv mmc0 0; fi
> mmcroot=/dev/mmcblk0p2 rw
> loadfdt=ext4load mmc ${mmcdev}:2 ${fdtaddr} /boot/dtbs/${fdtfile}
> loaduimage=if ext4load mmc 0:2 ${loadaddr} /boot/zImage; then setenv 
> mmcdev 0; else setenv mmcdev 1; if test $mmc0 = 1; then setenv mmcroot 
> /dev/mmcblk1p2 rw; fi; ext4load mmc 1:2 ${loadaddr} /boot/zImage; fi
> optargs=coherent_pool=1M
>
> As far as I can tell this is the latest code.
>
> What do I need to do to get it to always boot without intervention from 
> the micoSD card?
>
>

-- 
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: ArchLinux SD card boot

[Doug]

Robert,

 Thanks. I know you are a busy guy. I just wish there was a better FAQ. 
Maybe there is?

Anyhow next question..  is there a way to retain the fallback emmc boot 
and still boot right off from the microsd without any intervention?


-- 
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: ArchLinux SD card boot

[Doug]

I don't know why anyone can't just give a concise answer here instead of 
referring you to some other post where no real answer is given.

Here is my emmc - boot partition

[root@BBBdoug ~]# ls -als /mnt2
total 537
  1 drwxr-xr-x  5 root root   1024 Dec 31  1969 .
  4 drwxr-xr-x 18 root root   4096 Jan  1  2000 ..
  1 drwxr-xr-x  2 root root512 Mar 18  2013 App
  1 -rwxr-xr-x  1 root root223 Mar 18  2013 autorun.inf
  2 drwxr-xr-x  4 root root   2048 Mar 18  2013 Docs
  1 drwxr-xr-x  5 root root512 Mar 18  2013 Drivers
  1 -rwxr-xr-x  1 root root 30 Mar 18  2013 ID.txt
 41 -rwxr-xr-x  1 root root  41174 Mar 18  2013 LICENSE.txt
 98 -rwxr-xr-x  1 root root  99976 Mar 18  2013 MLO
  1 -rwxr-xr-x  1 root root 26 Jan  1  2000 old.uEnv.txt
  1 -rwxr-xr-x  1 root root292 Mar 18  2013 README.md
 17 -rwxr-xr-x  1 root root  16827 Mar 18  2013 START.htm
371 -rwxr-xr-x  1 root root 379428 Mar 18  2013 u-boot.img
  1 -rwxr-xr-x  1 root root603 Jan  1  2000 uEnv.txt

and my sd card boot partition -

 16 drwxr-xr-x  2 root root  16384 Dec 31  1969 .
  4 drwxr-xr-x 18 root root   4096 Jan  1  2000 ..
102 -rwxr-xr-x  1 root root 104212 Aug 10  2013 MLO
354 -rwxr-xr-x  1 root root 361488 Aug 10  2013 u-boot.img
  2 -rwxr-xr-x  1 root root603 Oct 18  2013 uEnv.txt

As you can see above I treid just copying uEnv.txt from the SD card to the 
emmc but it did the same thing. Do I have to wipe out the emmc boot 
partition and copy the sd boot to it?

I don't want to use the emmc. I want to boot from the microSD.  

-- 
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] ArchLinux SD card boot

[Doug]

I have ArchLinux installed and it reboots fine - shutdown -r now - but if I 
power down and restart it goes to four LED's and stops. If I hold down the 
boot button and power it will then boot.

How do I get it to boot at power up always from the SD card?  My boot 
partition has the following files -

102 -rwxr-xr-x  1 root root 104212 Aug 10  2013 MLO
354 -rwxr-xr-x  1 root root 361488 Aug 10  2013 u-boot.img
  2 -rwxr-xr-x  1 root root603 Oct 18  2013 uEnv.txt

and uEnv.txt has -

[root@BBBdoug mnt]# cat uEnv.txt
uenvcmd=run findmmc1; run findmmc0; if run loaduimage; then run loadfdt; 
run mmcboot; fi;
findmmc1=if test $board_name = A335BNLT; then setenv mmc1 1; else setenv 
mmc1 0; fi
findmmc0=setenv mmcdev 0; mmc dev ${mmcdev}; if mmc rescan; then setenv 
mmc0 1; else setenv mmc0 0; fi
mmcroot=/dev/mmcblk0p2 rw
loadfdt=ext4load mmc ${mmcdev}:2 ${fdtaddr} /boot/dtbs/${fdtfile}
loaduimage=if ext4load mmc 0:2 ${loadaddr} /boot/zImage; then setenv mmcdev 
0; else setenv mmcdev 1; if test $mmc0 = 1; then setenv mmcroot 
/dev/mmcblk1p2 rw; fi; ext4load mmc 1:2 ${loadaddr} /boot/zImage; fi
optargs=coherent_pool=1M

As far as I can tell this is the latest code.

What do I need to do to get it to always boot without intervention from the 
micoSD card?

-- 
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: BBB Debian compile problem

[Doug]

Well I am using the BBB headless so I suspect the gtk2 lockup bug would not 
be an issue???

So I guess you are saying I can be assured the kernels are the same (source 
and running kernel) and it would be a waste of time to try compiling the 
source kernel, installing it, and try again?

-- 
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] BBB Debian compile problem

[Doug]

Running Beagle Black with latest Debian release. I am trying to compile a 
couple of programs against kernel source and I am having a problem.

I used the bb-get-rcn-kernel-source.sh script to download the kernel 
headers, source and apply patches. The kernel is linux-3.8.13-bone43 which 
matches uname -r  = 3.8.13-bone43.

This all goes well. I am compiling dahdi 2.9.1.1  and asterisk.  Patches 
are applied successfully to dahdi before compile and the asterisk is 
custom. For this reason neither package can be download as a binary package 
they must be compiled from source. The compilations and installs go fine 
except in the case of dahdi it put the modules in  /lib/modules/3.8.13   
and not  3.8.13-bone43. where the rest of the kernel modules are. Dahdi 
does not work unless I move the modules to /lib/modules/3.8.13-bone43.and 
then do a depmod -a 3.8.13-bone43.

OK so far so good. Asterisk compiles and installs fine. When I run it 
crashes usually within about a half hour. Up until it crashes the 
application seems to work. All tests I have done show no messages and 
memory checks show nothing strange before the crash. The crash is 
immediate. It just stops working and heartbeat LED stops. I have been 
pulling my hair out as to what this is. This package does work. I have it 
working on the RPi and a Debian PC.

My questions is this, does using the bb-get-rcn-kernel-source.sh script 
accurately prepare the source and headers to match the current system? If 
so why does the dahdi compile insist on putting the modules in 3.8.13 
leaving the -bone43 off? Could this be a potential problem indicating I am 
not matching the running kernel in my compiles? I am trying to look at all 
possibilities.

Perhaps I should compile the kernel from the source I have downloaded, 
install it and then recompile against that.

Is there a written procedure for installing a compiled Debian kernel on the 
BBB?

Any insight on this would be appreciated.
.

-- 
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] Compile problem

[Doug]

I am trying to compile some code in the latest debian release. I got the 
latest source by using --

wget 
https://raw.github.com/gkaindl/beaglebone-ubuntu-scripts/master/bb-get-rcn-kernel-source.sh
 

chmod +x bb-get-rcn-kernel-source.sh 

./bb-get-rcn-kernel-source.sh 


uname-r  on my system returns   -   3.8.13-bone43

The compile and install goes without errors but the modules are placed in

/lib/modules/3.8.13   and not  /lib/modules/3.8.13-bone43 where all of the 
system modules reside.

When I try to start the application it tells me there are no modules.

What is wrong? The script does download the kernel and bone43 patches.   


-- 
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 boot - need a little help

[Doug]

OK I will answer my own question here at least partially.  Since I do not 
need HDMI and I want to go headless anyhow I logged in using USB. I then 
went into the /etc/network/interfaces file and found that the eth0 lines 
were commented out. So that is why I had no Ethernet connection. I added a 
static IP definition and rebooted. All is well now for Ethernet login on 
port 22.

Why is ethernet not supported at initial boot?




-- 
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] Debian boot - need a little help

[Doug]

I burned the debian 7.4 3-37 image to SD.  I am using a 5V supply and HDMI 
and wireless keyboard and mouse.

It boots. I see the penguin. I get the login prompt. seconds later all 
disappears. It looks like HDMI is still active but no video.

If I am quick I can type in a username so I know the keyboard is working.

Any ideas?

Does DEbian come up with an SSH port? I can't seem to find a DHCP entry in 
my router.

 

-- 
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: Souce code

[Doug]

OK so I understand the Black Debian install can still get packages using  
'apt-get install' ? I would need a number of packages to build my 
application.

Also if anyone is running the stock Debian install could you tell me if  
snd-pcm-oss modules is available?

 /sbin/modinfo snd-pcm-oss

I need to use /dev/dsp  /dev/mixer  etc.


-- 
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] Souce code

[Doug]

I need to compile a number of modules that depend on the kernel. Is kernel 
source or at the very least kernel headers available for the Debian Beagle 
Balck release? Is it part of the distribution or downloadable?  Is there a 
repository for additional packages for the Debian release?

-- 
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: Beagle Black Questions

[Doug]

Jason,

  Thanks for the reply and answers to my questions. 

On the emmc my understanding is that it had a more refined internal 
controller that did wear leveling a little better than SD or mSD cards. 
Whether or not this is the case when using the emmc with Linux it will 
eventually fail. How long is anyones guess and depends on the application 
and how you handle writes and where you store temporary data.

So I am curious how users are doing this in their applications? Internal, 
external? Are you worried about write life of the emmc?

Also are there speed differences when using the emmc vs external mSD?  



>
>
>

-- 
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] Beagle Black Questions

[Doug]

I just ordered my first Black today. I have been using RPi's for awhile but 
due to the lousy USB interface I wanted to try the Black. Anyhow I have a 
few questions.

I plan to run Debian and I see I have the option of running it in microSD 
or the internal EMMC. 

I am not clear on the advantage/disadvantage of one vs. the other. I know I 
want to be able to boot at power up without pushing buttons so I suspect 
the EMMC image is the best choice. When an OS is flashed to EMMC the data 
(writable) area is Where? In RAM or MicroSD?

I want to customize the OS and add my own code is this done on the microSD 
image and then flashed?

I am not clear on how this works. Of course on the RPi the SD card is the 
OS and and changes you make are stored there. Maybe there is a document 
that explains this?


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Windows android adb issues

[Doug Nappier]

I am working with Android Jelly bean and am having some adb issues when it 
comes to Windows 7. I can not get windows 7 to recognize the device as an 
Android device and can not find it with adb. When I boot into my linux host 
machine I can use adb to find the beagleboard.  

I ran lsusb on the device in my linux host and got the following output:
Bus 001 Device 011: ID 18d1:9018 Google Inc

I read in the TI ADB install 
guide that 
you need to add the following lines to you the .inf file:

%SingleAdbInterface% = USB_Install, USB\VID_18D1&PID_9018
%CompositeAdbInterface% = USB_Install, USB\VID_18D1&PID_9018&MI_01

When I go to my device manager, where the device is mistakenly being 
established as a mass storage device, and attempt to point Windows at this 
new .inf file it gives me the error "Windows could not find the driver 
software for your device"

Does anyone have any ideas how to fix this.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[beagleboard] Windows adb driver issue

[Doug Nappier]

I am working with Android Jelly bean and am having some adb issues when it 
comes to Windows 7. I can not get windows 7 to recognize the device as an 
Android device and can not find it with adb. When I boot into my linux host 
machine I can use adb to find the beagleboard.  

I ran lsusb on the device in my linux host and got the following output:
Bus 001 Device 011: ID 18d1:9018 Google Inc

I read in the TI ADB install 
guide that 
you need to add the following lines to you the .inf file:

%SingleAdbInterface% = USB_Install, USB\VID_18D1&PID_9018
%CompositeAdbInterface% = USB_Install, USB\VID_18D1&PID_9018&MI_01

When I go to my device manager, where the device is mistakenly being 
established as a mass storage device, and attempt to point Windows at this 
new .inf file it gives me the error "Windows could not find the driver 
software for your device"

Does anyone have any ideas how to fix this.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[beagleboard] Re: Cape IIO Kernel NULL Pointer derefence

[Doug Edey]

Ok, but how to I make the reading on the analogue inputs more reliable?

On Wednesday, December 4, 2013 2:32:06 AM UTC-5, Giuseppe Iellamo wrote:
>
> As others have noted here 
>
>
> https://groups.google.com/forum/#!category-topic/beagleboard/beaglebone-black/ZLSuKKM9Im4
>
> Unloading cape is a bit problematic... shortly don't expect it to work 
> reliably
>
> Il giorno mercoledì 4 dicembre 2013 01:41:47 UTC+1, Doug Edey ha scritto:
>>
>> Using Ubuntu 13.04 3.8.13-bone31
>>
>> After approximately five minutes AIN* values go to "Resource Temporarily 
>> Unavailable"
>>
>> elsinore@brewery:~$ cat /sys/devices/ocp.2/helper.13/AIN*
>> cat: /sys/devices/ocp.2/helper.13/AIN0: Resource temporarily unavailable
>> cat: /sys/devices/ocp.2/helper.13/AIN1: Resource temporarily unavailable
>> cat: /sys/devices/ocp.2/helper.13/AIN2: Resource temporarily unavailable
>> cat: /sys/devices/ocp.2/helper.13/AIN3: Resource temporarily unavailable
>> cat: /sys/devices/ocp.2/helper.13/AIN4: Resource temporarily unavailable
>> cat: /sys/devices/ocp.2/helper.13/AIN5: Resource temporarily unavailable
>> cat: /sys/devices/ocp.2/helper.13/AIN6: Resource temporarily unavailable
>> cat: /sys/devices/ocp.2/helper.13/AIN7: Resource temporarily unavailable
>>
>> When I unload the cape:
>>
>> Dec  3 19:38:04 brewery kernel: [  873.063510] Unable to handle kernel 
>> NULL pointer dereference at virtual address 001b
>> Dec  3 19:38:04 brewery kernel: [  873.072312] pgd = df308000
>> Dec  3 19:38:04 brewery kernel: [  873.075179] [001b] *pgd=9f475831, 
>> *pte=, *ppte=
>> Dec  3 19:38:04 brewery kernel: [  873.081805] Internal error: Oops: 17 
>> [#1] SMP ARM
>> Dec  3 19:38:04 brewery kernel: [  873.086721] Modules linked in: g_multi 
>> libcomposite r8712u(C) hid_ntrig
>> Dec  3 19:38:04 brewery kernel: [  873.093665] CPU: 0Tainted: G   
>>   C(3.8.13-bone31 #1)
>> Dec  3 19:38:04 brewery kernel: [  873.099955] PC is at 
>> omap_device_idle+0x10/0x54
>> Dec  3 19:38:04 brewery kernel: [  873.104689] LR is at 
>> _od_runtime_suspend+0x1c/0x24
>> Dec  3 19:38:04 brewery kernel: [  873.109697] pc : []lr : 
>> []psr: a013
>> Dec  3 19:38:04 brewery kernel: [  873.109697] sp : de5bbd68  ip : 
>> df0484cc  fp : de155c18
>> Dec  3 19:38:04 brewery kernel: [  873.121695] r10: de5bbda0  r9 : 
>> c0059db0  r8 : 
>> Dec  3 19:38:04 brewery kernel: [  873.127155] r7 : 6013  r6 : 
>>   r5 : df28f410  r4 : 
>> Dec  3 19:38:04 brewery kernel: [  873.133976] r3 :   r2 : 
>> 000c000b  r1 : df28f480  r0 : df28f400
>> Dec  3 19:38:04 brewery kernel: [  873.140800] Flags: NzCv  IRQs on  FIQs 
>> on  Mode SVC_32  ISA ARM  Segment user
>> Dec  3 19:38:04 brewery kernel: [  873.148256] Control: 10c5387d  Table: 
>> 9f308019  DAC: 0015
>> Dec  3 19:38:04 brewery kernel: [  873.154260] Process bash (pid: 1491, 
>> stack limit = 0xde5ba240)
>> Dec  3 19:38:04 brewery kernel: [  873.160356] Stack: (0xde5bbd68 to 
>> 0xde5bc000)
>> Dec  3 19:38:04 brewery kernel: [  873.182260] bd60:   
>>  c0028540  df28f410 c0028524 c038e278
>> Dec  3 19:38:04 brewery kernel: [  873.199820] bd80: c094f4d8 df28f410 
>>  c038e7d8 6013 0001 0003 
>> Dec  3 19:38:04 brewery kernel: [  873.215648] bda0: de664e00 fdf4 
>> de5ba000 df28f410  df28f480 6013 00200200
>> Dec  3 19:38:04 brewery kernel: [  873.227851] bdc0: c066a264 de623df8 
>> de155c18 c038f684  df28f410 c0027984 0004
>> Dec  3 19:38:04 brewery kernel: [  873.236519] bde0: 6013 c038ae38 
>> df28f410 c038e278 c094f4d8 df28f410  c038ebb8
>> Dec  3 19:38:04 brewery kernel: [  873.252565] be00: df28f51c df28f410 
>> 0004 df28f480 6013 c038ed10 c03943f4 df28f410
>> Dec  3 19:38:04 brewery kernel: [  873.272087] be20: df7f9b10 c099be08 
>>  c039fbe8 c039fbbc df28f410 c099d194 c03878e0
>> Dec  3 19:38:04 brewery kernel: [  873.287712] be40: c03878cc c03862d8 
>> df578580 df28f444 df28f410 c038633c  df28f410
>> Dec  3 19:38:04 brewery kernel: [  873.304292] be60: df04843c c0385e70 
>> df28f410 df0b7200 df0b7210 c03840e8 df28f400 df0b7200
>> Dec  3 19:38:04 brewery kernel: [  873.312980] be80:  c0387c58 
>> df28f400 c0387e74 df47d680 c04d1bf8 002b df47d680
>> Dec  3 19:38:04 brewery kernel: [  873.338590] bea0: de623dc0 de623df8 
>> 00100100 c04d1cc4 df578580  ffb0 de623dc8
>> Dec  3 19:38:04 brewery kernel: [  873.361964

[beagleboard] Re: (Resource temporarily unavailable)Error while reading ADC pins

[Doug Edey]

Is there a reason why "overreading" causes the issue? I've noticed I can 
cause it by running a:

find /sys/devices -iname ain*

Which is really annoying!

On Friday, December 6, 2013 1:27:13 AM UTC-5, nax...@gmail.com wrote:
>
> The problem seems to arise when I am trying to access ADC continuously 
> without delay.
> When I tried to access ADC continuously, the "Resource temporarily 
> unavailable" error remained constant and I was not able to read ADC 
> unless I rebooted the system.
>
> If I give a delay after reading each ADC value,
> Occassionally I do get "Resource temporarily unavailable" error but it 
> just remains for a few seconds and I am able to read ADC again normally.
>
> On Monday, December 2, 2013 6:26:11 PM UTC+5:30, nax...@gmail.com wrote:
>>
>> I am getting resource temporary unavailable when I tried to read ADC pins 
>> from BeagleBone Black
>>
>> root@beaglebone:~# cat /sys/devices/ocp.2/helper.11/AIN*
>> cat: /sys/devices/ocp.2/helper.11/AIN0: Resource temporarily unavailable
>> cat: /sys/devices/ocp.2/helper.11/AIN1: Resource temporarily unavailable
>> cat: /sys/devices/ocp.2/helper.11/AIN2: Resource temporarily unavailable
>> cat: /sys/devices/ocp.2/helper.11/AIN3: Resource temporarily unavailable
>> cat: /sys/devices/ocp.2/helper.11/AIN4: Resource temporarily unavailable
>> cat: /sys/devices/ocp.2/helper.11/AIN5: Resource temporarily unavailable
>> cat: /sys/devices/ocp.2/helper.11/AIN6: Resource temporarily unavailable
>> cat: /sys/devices/ocp.2/helper.11/AIN7: Resource temporarily unavailable
>>
>> What might be the reason for the error ?
>> The ADC pins AIN0 to AIN5 are connected to thermistors and the actual 
>> voltage at the ADC pins is around 0.77 volt
>>
>

-- 
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/groups/opt_out.

[beagleboard] Re: Any nice solution ot power 10x BeagleBone Black boards?

[Doug Edey]

You'd be better off using the DC Plugs to power the Beagleboards, get a 
nice big brick and split the power out.

On Wednesday, December 4, 2013 6:32:11 AM UTC-5, ara...@gmail.com wrote:
>
>
> Hello,
>
> I have 10 beaglebone black boards and would like to put them nicely in 
> stack... I am looking for a PSU or a solution to power these boards. I 
> didn't found anything nice though. 
>
> I'm looking for a solution/recommendation now...
> 1. Are there any kind of PowerPlug with adapter where I can put 10 wires 
> and feed it to boards?
> 2. Or may be just to buy a USB Hub with 10 ports that has external power 
> supply and use it just to power the boards?
>
>
> I hope you've got what I'm looking for... :-) Let me know if it's still 
> unclear.
>
> thanks,
> Anton.
>

-- 
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/groups/opt_out.

[beagleboard] Re: Dallas 1-Wire BeagleBone Black

[Doug Edey]

I've got 3 DS18B20 sensors on my bus at the moment, providing you've got 
the sensors running in non-parasitic mode, I think you'll be fine.

On Tuesday, December 3, 2013 8:13:31 PM UTC-5, lorena...@gmail.com wrote:
>
> Thinking of replacing the dedicated microcontroller that runs my house 
> with a BBB. Being able to read the existing 1-Wire network will be 
> critical. Currently have 12 18B20 sensors on one bus, need more. Can the 
> kernel module described here actually address and read multiple sensors on 
> the same bus? Can it search and retrieve addresses from unknown sensors? 
>
> I see people selling 8-port capes, as if maybe this is a simple one device 
> per bus routine...  Wouldn't help me! 
>
> As for the "considerations" of long buses, yes there was a learning curve. 
> I have both active pull-up and active pull-down, with careful source-end 
> termination. All cable is CAT-5, and all sensors are within 1m of a single 
> linear topology installation. In several cases the bus goes out one pair of 
> the CAT-5 to a distant sensor and comes back on another pair of the same 
> cable to continue to the next destination. Branching.in a star fashion is 
> death to 1-Wire. My current system works, reliably controlling serious 
> solar hot water and outdoor wood boiler operation that could blow off 
> expensive antifreeze fluid (a huge hassle to recharge) if anything 
> overheated. 
>
> Great long-bus reference:
> http://www.1wire.org/Files/Articles/1-Wire-Design%20Guide%20v1.0.pdf
>

-- 
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/groups/opt_out.

[beagleboard] Re: (Resource temporarily unavailable)Error while reading ADC pins

[Doug Edey]

/0x50) from [] 
(__rpm_callback+0x30/0x58)
Dec  3 19:38:05 brewery kernel: [  873.565084] [] 
(__rpm_callback+0x30/0x58) from [] (rpm_idle+0x180/0x228)
Dec  3 19:38:05 brewery kernel: [  873.573948] [] 
(rpm_idle+0x180/0x228) from [] (__pm_runtime_idle+0x48/0x90)
Dec  3 19:38:05 brewery kernel: [  873.583100] [] 
(__pm_runtime_idle+0x48/0x90) from [] (ti_tscadc_remove+0x2c/0x48)
Dec  3 19:38:05 brewery kernel: [  873.592795] [] 
(ti_tscadc_remove+0x2c/0x48) from [] 
(platform_drv_remove+0x14/0x18)
Dec  3 19:38:05 brewery kernel: [  873.602663] [] 
(platform_drv_remove+0x14/0x18) from [] 
(__device_release_driver+0x7c/0xc4)
Dec  3 19:38:05 brewery kernel: [  873.613168] [] 
(__device_release_driver+0x7c/0xc4) from [] 
(device_release_driver+0x1c/0x28)
Dec  3 19:38:05 brewery kernel: [  873.623852] [] 
(device_release_driver+0x1c/0x28) from [] 
(bus_remove_device+0xc8/0xd8)
Dec  3 19:38:05 brewery kernel: [  873.633988] [] 
(bus_remove_device+0xc8/0xd8) from [] (device_del+0x108/0x16c)
Dec  3 19:38:05 brewery kernel: [  873.643308] [] 
(device_del+0x108/0x16c) from [] (platform_device_del+0x14/0x44)
Dec  3 19:38:05 brewery kernel: [  873.652810] [] 
(platform_device_del+0x14/0x44) from [] 
(platform_device_unregister+0xc/0x18)
Dec  3 19:38:05 brewery kernel: [  873.663510] [] 
(platform_device_unregister+0xc/0x18) from [] 
(of_overlay_device_entry_change.isra.0+0xe8/0x16c)
Dec  3 19:38:05 brewery kernel: [  873.675928] [] 
(of_overlay_device_entry_change.isra.0+0xe8/0x16c) from [] 
(of_overlay_revert_one+0x48/0x1e8)
Dec  3 19:38:05 brewery kernel: [  873.688069] [] 
(of_overlay_revert_one+0x48/0x1e8) from [] 
(of_overlay_revert+0x3c/0x60)
Dec  3 19:38:05 brewery kernel: [  873.698298] [] 
(of_overlay_revert+0x3c/0x60) from [] 
(bone_capemgr_remove_slot_no_lock+0x40/0xc8)
Dec  3 19:38:05 brewery kernel: [  873.709436] [] 
(bone_capemgr_remove_slot_no_lock+0x40/0xc8) from [] 
(slots_store+0x78/0x3b0)
Dec  3 19:38:05 brewery kernel: [  873.720118] [] 
(slots_store+0x78/0x3b0) from [] (dev_attr_store+0x18/0x24)
Dec  3 19:38:05 brewery kernel: [  873.729170] [] 
(dev_attr_store+0x18/0x24) from [] (sysfs_write_file+0x100/0x148)
Dec  3 19:38:05 brewery kernel: [  873.738751] [] 
(sysfs_write_file+0x100/0x148) from [] (vfs_write+0xa8/0x178)
Dec  3 19:38:05 brewery kernel: [  873.747963] [] 
(vfs_write+0xa8/0x178) from [] (sys_write+0x38/0x64)
Dec  3 19:38:05 brewery kernel: [  873.756362] [] 
(sys_write+0x38/0x64) from [] (ret_fast_syscall+0x0/0x30)
Dec  3 19:38:05 brewery kernel: [  873.770224] Code: e350 e92d4010 
01a04000 159041c8 (e5d4301b)
Dec  3 19:38:05 brewery kernel: [  873.776680] ---[ end trace 
11c5dfaa4d81386f ]---

On Tuesday, December 3, 2013 7:24:54 PM UTC-5, Doug Edey wrote:
>
> Does anyone have any help on this? I'm getting this too, using Ubuntu on 
> the Beaglebone Black. I've upgrade to 3.8.13-bone31 (the only higher 
> version is 3.12 but I can't get the cape to load)
>
> I get some valid readings (for maybe a few minutes after I load the cape) 
> then I get the resource temporarily unavailable, and there's nothing in the 
> dmesg output to indicate an error :(
>
>
> On Monday, December 2, 2013 7:56:11 AM UTC-5, nax...@gmail.com wrote:
>>
>> I am getting resource temporary unavailable when I tried to read ADC pins 
>> from BeagleBone Black
>>
>> root@beaglebone:~# cat /sys/devices/ocp.2/helper.11/AIN*
>> cat: /sys/devices/ocp.2/helper.11/AIN0: Resource temporarily unavailable
>> cat: /sys/devices/ocp.2/helper.11/AIN1: Resource temporarily unavailable
>> cat: /sys/devices/ocp.2/helper.11/AIN2: Resource temporarily unavailable
>> cat: /sys/devices/ocp.2/helper.11/AIN3: Resource temporarily unavailable
>> cat: /sys/devices/ocp.2/helper.11/AIN4: Resource temporarily unavailable
>> cat: /sys/devices/ocp.2/helper.11/AIN5: Resource temporarily unavailable
>> cat: /sys/devices/ocp.2/helper.11/AIN6: Resource temporarily unavailable
>> cat: /sys/devices/ocp.2/helper.11/AIN7: Resource temporarily unavailable
>>
>> What might be the reason for the error ?
>> The ADC pins AIN0 to AIN5 are connected to thermistors and the actual 
>> voltage at the ADC pins is around 0.77 volt
>>
>

-- 
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/groups/opt_out.

[beagleboard] Cape IIO Kernel NULL Pointer derefence

[doug . edey]

Using Ubuntu 13.04 3.8.13-bone31

After approximately five minutes AIN* values go to "Resource Temporarily 
Unavailable"

elsinore@brewery:~$ cat /sys/devices/ocp.2/helper.13/AIN*
cat: /sys/devices/ocp.2/helper.13/AIN0: Resource temporarily unavailable
cat: /sys/devices/ocp.2/helper.13/AIN1: Resource temporarily unavailable
cat: /sys/devices/ocp.2/helper.13/AIN2: Resource temporarily unavailable
cat: /sys/devices/ocp.2/helper.13/AIN3: Resource temporarily unavailable
cat: /sys/devices/ocp.2/helper.13/AIN4: Resource temporarily unavailable
cat: /sys/devices/ocp.2/helper.13/AIN5: Resource temporarily unavailable
cat: /sys/devices/ocp.2/helper.13/AIN6: Resource temporarily unavailable
cat: /sys/devices/ocp.2/helper.13/AIN7: Resource temporarily unavailable

When I unload the cape:

Dec  3 19:38:04 brewery kernel: [  873.063510] Unable to handle kernel NULL 
pointer dereference at virtual address 001b
Dec  3 19:38:04 brewery kernel: [  873.072312] pgd = df308000
Dec  3 19:38:04 brewery kernel: [  873.075179] [001b] *pgd=9f475831, 
*pte=, *ppte=
Dec  3 19:38:04 brewery kernel: [  873.081805] Internal error: Oops: 17 
[#1] SMP ARM
Dec  3 19:38:04 brewery kernel: [  873.086721] Modules linked in: g_multi 
libcomposite r8712u(C) hid_ntrig
Dec  3 19:38:04 brewery kernel: [  873.093665] CPU: 0Tainted: G 
C(3.8.13-bone31 #1)
Dec  3 19:38:04 brewery kernel: [  873.099955] PC is at 
omap_device_idle+0x10/0x54
Dec  3 19:38:04 brewery kernel: [  873.104689] LR is at 
_od_runtime_suspend+0x1c/0x24
Dec  3 19:38:04 brewery kernel: [  873.109697] pc : []lr : 
[]psr: a013
Dec  3 19:38:04 brewery kernel: [  873.109697] sp : de5bbd68  ip : df0484cc 
 fp : de155c18
Dec  3 19:38:04 brewery kernel: [  873.121695] r10: de5bbda0  r9 : c0059db0 
 r8 : 
Dec  3 19:38:04 brewery kernel: [  873.127155] r7 : 6013  r6 :  
 r5 : df28f410  r4 : 
Dec  3 19:38:04 brewery kernel: [  873.133976] r3 :   r2 : 000c000b 
 r1 : df28f480  r0 : df28f400
Dec  3 19:38:04 brewery kernel: [  873.140800] Flags: NzCv  IRQs on  FIQs 
on  Mode SVC_32  ISA ARM  Segment user
Dec  3 19:38:04 brewery kernel: [  873.148256] Control: 10c5387d  Table: 
9f308019  DAC: 0015
Dec  3 19:38:04 brewery kernel: [  873.154260] Process bash (pid: 1491, 
stack limit = 0xde5ba240)
Dec  3 19:38:04 brewery kernel: [  873.160356] Stack: (0xde5bbd68 to 
0xde5bc000)
Dec  3 19:38:04 brewery kernel: [  873.182260] bd60:   
 c0028540  df28f410 c0028524 c038e278
Dec  3 19:38:04 brewery kernel: [  873.199820] bd80: c094f4d8 df28f410 
 c038e7d8 6013 0001 0003 
Dec  3 19:38:04 brewery kernel: [  873.215648] bda0: de664e00 fdf4 
de5ba000 df28f410  df28f480 6013 00200200
Dec  3 19:38:04 brewery kernel: [  873.227851] bdc0: c066a264 de623df8 
de155c18 c038f684  df28f410 c0027984 0004
Dec  3 19:38:04 brewery kernel: [  873.236519] bde0: 6013 c038ae38 
df28f410 c038e278 c094f4d8 df28f410  c038ebb8
Dec  3 19:38:04 brewery kernel: [  873.252565] be00: df28f51c df28f410 
0004 df28f480 6013 c038ed10 c03943f4 df28f410
Dec  3 19:38:04 brewery kernel: [  873.272087] be20: df7f9b10 c099be08 
 c039fbe8 c039fbbc df28f410 c099d194 c03878e0
Dec  3 19:38:04 brewery kernel: [  873.287712] be40: c03878cc c03862d8 
df578580 df28f444 df28f410 c038633c  df28f410
Dec  3 19:38:04 brewery kernel: [  873.304292] be60: df04843c c0385e70 
df28f410 df0b7200 df0b7210 c03840e8 df28f400 df0b7200
Dec  3 19:38:04 brewery kernel: [  873.312980] be80:  c0387c58 
df28f400 c0387e74 df47d680 c04d1bf8 002b df47d680
Dec  3 19:38:04 brewery kernel: [  873.338590] bea0: de623dc0 de623df8 
00100100 c04d1cc4 df578580  ffb0 de623dc8
Dec  3 19:38:04 brewery kernel: [  873.361964] bec0: de623dc0 de623e10 
db25f000 c04d2498 de39e410  df0d7c10 de00da58
Dec  3 19:38:04 brewery kernel: [  873.381545] bee0: df0d7c10 c039c69c 
0007 de155c20 0003 c039dca8  de00da58
Dec  3 19:38:04 brewery kernel: [  873.394988] bf00: c09c05c0 c061992c 
   de157f48 de00da40 0003
Dec  3 19:38:04 brewery kernel: [  873.404766] bf20: de00da58 de5bbf80 
c066a264 df0d7c18  c0382ed0 0003 c014e684
Dec  3 19:38:04 brewery kernel: [  873.424443] bf40: de333bc0 000ac408 
0003 de5bbf80 000ac408 de5ba000 0003 c00f5474
Dec  3 19:38:04 brewery kernel: [  873.440066] bf60: de333bc0 000ac408 
  de333bc0  000ac408 c00f5754
Dec  3 19:38:04 brewery kernel: [  873.461551] bf80:   
0003 0003 000ac408 b6f55a78 0004 c000da04
Dec  3 19:38:04 brewery kernel: [  873.477265] bfa0:  c000d880 
0003 000ac408 0001 000ac408 0003 
Dec  3 19:38:04 brewery kernel: [  873.487589] bfc0: 0003 000ac408 
b6f55a78 0004 0003  000a6094 
Dec  3 19:38:05 brewery kernel: [  873.497337] bfe0: 

[beagleboard] Re: (Resource temporarily unavailable)Error while reading ADC pins

[doug . edey]

Does anyone have any help on this? I'm getting this too, using Ubuntu on 
the Beaglebone Black. I've upgrade to 3.8.13-bone31 (the only higher 
version is 3.12 but I can't get the cape to load)

I get some valid readings (for maybe a few minutes after I load the cape) 
then I get the resource temporarily unavailable, and there's nothing in the 
dmesg output to indicate an error :(


On Monday, December 2, 2013 7:56:11 AM UTC-5, nax...@gmail.com wrote:
>
> I am getting resource temporary unavailable when I tried to read ADC pins 
> from BeagleBone Black
>
> root@beaglebone:~# cat /sys/devices/ocp.2/helper.11/AIN*
> cat: /sys/devices/ocp.2/helper.11/AIN0: Resource temporarily unavailable
> cat: /sys/devices/ocp.2/helper.11/AIN1: Resource temporarily unavailable
> cat: /sys/devices/ocp.2/helper.11/AIN2: Resource temporarily unavailable
> cat: /sys/devices/ocp.2/helper.11/AIN3: Resource temporarily unavailable
> cat: /sys/devices/ocp.2/helper.11/AIN4: Resource temporarily unavailable
> cat: /sys/devices/ocp.2/helper.11/AIN5: Resource temporarily unavailable
> cat: /sys/devices/ocp.2/helper.11/AIN6: Resource temporarily unavailable
> cat: /sys/devices/ocp.2/helper.11/AIN7: Resource temporarily unavailable
>
> What might be the reason for the error ?
> The ADC pins AIN0 to AIN5 are connected to thermistors and the actual 
> voltage at the ADC pins is around 0.77 volt
>

-- 
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/groups/opt_out.