[beagleboard] Debian 4.1.x (Jessie) Device Driver Update: Summary mostly working

[Bit Pusher]

Summary, mostly working with some gotchas; this posting is just help others 
doing a change to 4.1.x, if not, please just ignore.

1) I2C works but it appears the addresses have changed: sudo i2cdetect -y 
-r 2 shows I2C at address 2
2) Adafruit_BBIO.ADC: needs fixes 
from https://gist.github.com/grizmio/bc752dd070652f21266b#file-gistfile1-txt 
just due to $SLOTS location changing. Copy this to the source file of
git://github.com/adafruite/adafruit-beaglebone-io-python.git and do a git 
apply "patch-file" and then go to main directory and do a sudo make 
install. There are some warnings at patch
application, but they don't seem to cause problems (I checked the code - 
the warning have something to do with line end spaces; I also checked the 
ADC functionality with gdb)
I think I had to copy the ADC.so file in manually to 
/usr/local/lib/python2.7/dist-packages/Adafruit_BBIO; not sure why.
3) Adafruit_BBIO.SPI not working but not needed as spidev has been fixed 
for the RPi (by gadgetoid?) and seems to work fine fine for the BBB 4.1.x. 
It is
found at https://github.com/doceme/py-spidev (just download and sudo make 
install).
4) uio_pruss: recompiled to increase memory size (I may have used a 
4.1.13bone17 source due to laziness - no problems so far):
> cat /sys/class/uio/uio0/maps/map1/size 
0x0080
and copied uio_pruss.so to /lib/modules/4.1.15-bone17/kernel/drivers/uio/
As far as I can tell the uio_pruss all works fine. I recompiled my logic 
analyzer and it seems to run as before (this seems like almost the only 
thing that worked without changes)
5) Networking, and wireless, had real problems but now working fairly well 
with a custom network manager (yech!); I still get intermittent problems for
unknown reasons, but it generally comes up now irrespective of device and 
network subnet; I'm primarily using python with subprocess.Popen to call 
"ip" and a bit of pinging to
find subnetwork address; networking has never been well done (and maybe 
will never be well done) in linux. Total lines of python: 628 to date
If the usb0 gadget connection had not worked, I wouldn't of had a chance 
(thanks Robert).

Loading overlays: I had and have problems here; could be due to my 
mis-understanding.
1) in /boot/uEnv.txt using:
cape_enable=bone_capemgr.enable_partno=BB-BONE-PRU,BB-ADC,BB-SPIDEV1
doesn't work as the BB-SPIDEV1 seems to be from the main device tree, not 
from /lib/firmware. I added a
systemd service to add overlays at boot from /lib/firmware. When adding at 
boot, my self.spi.max_speed_hz was wrong; it was 24MHz; if I loaded
it later manually, it had its correct value of 100kHz (I'm running it slow 
to make using the logic analyzer easier). Note, the default in the main 
device tree is 16MHz.
Suggestion: specify self.spi.max_speed_hz in your code to be safe
Note also, the main device tree has spi-cpha; specified for channel 0. This 
has D1 changing on positive going clock edges; most SPI slaves sample on 
positive going edges,
so one wants D1 changing on negative going edges; this default should be 
commented out
Suggestion, specify self.spi.mode in your code to be safe (normally as 0, 
not the current 1)
2) I'm seeing unexpected (to me) behaviour when loading and removing SPI 
tree overlays. The first one comes at /dev/spidev1.0 and /dev/spidev1.1 
irrespective if whether it
is bus 0 or bus 1 (i.e. BB-SPIDEV0-00A0.dtbo or BB-SPIDEV1-00A0.dtbo), the 
next one comes in at /dev/spidev2.0 and /dev/spidev2.1 again irrespective 
of which bus it really is.
The spi overlays can be removed and the re-installed, but each time, they 
come in at one higher file number location. One's code needs to know the 
location to open the device
(one could check for it, but this seems overly complicated). I would have 
expected spi0 to come in at spi0 and spi1 to be at spi1. I lost at least a 
full week here. With these caveats,
and the fixed code from gadgetoid, the spi1 seems to be now working fine 
for me; for me the I2C's and SPI's are the most critical drivers.

Summary, some issues with the tree overlays, that need to be 
simplified/modified, but overall everything is mostly now working 
(somewhere around 7-8 weeks full-time from first flashing), Pyside, scite, 
and gtkwave
all work with no problems. I may not be the best at BBB's, but this will be 
the last time I reflash. The uio_pruss seemed to have no problems (after 
recompiling) which was real nice
(the PRUs are the only reason - well maybe lack of an eMMC as well - 
besides invested time, that I am not switching to RPis). I suggest just 
doing updates -with the correct flags- unless your full-time job is 
embedded linux.
I also suggest some simple shell scripts to automate backup (such as nc -l 
-p 19000|bzip2 -d|dd bs=16M of=$filNm on host and sudo dd bs=16M 
if=/dev/mmcblk0|bzip2 -c|nc $1 19000 to
back up often (also be careful not to get rid of eMMC in /boot/uEvt.txt if 
not running for sD card - as I accidentally did - this is dangerous). There 
were ma

Re: [beagleboard] can't turn off eth0

[evilwulfie]

systemd maybe ?


On 1/2/2016 11:56 AM, Pedro Peres wrote:
> edit: seems the ethernet port does disconnect with ifdown but only
> momentarily, something else is bringing it back up. How do I find out
> what it is?
>
>
> On Fri, Jan 1, 2016 at 11:42 PM, Pedro Peres <100ped...@gmail.com
> > wrote:
>
> I can't shut down eth0
> the /etc/network/interfaces file has the setup lines for eth0
> commented out, as shipped
> ifdown eth0  gives me : interface eth0 not configured
> ifconfig eth0 down gives me no response
> and in both cases the port stays connected.
> Any ideas on how to accomplish turning it off?
>
>
> -- 
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in
> the Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/B1aieu5HaLE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email
> to beagleboard+unsubscr...@googlegroups.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
> .
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] can't turn off eth0

[Pedro Peres]

edit: seems the ethernet port does disconnect with ifdown but only
momentarily, something else is bringing it back up. How do I find out what
it is?


On Fri, Jan 1, 2016 at 11:42 PM, Pedro Peres <100ped...@gmail.com> wrote:

> I can't shut down eth0
> the /etc/network/interfaces file has the setup lines for eth0 commented
> out, as shipped
> ifdown eth0  gives me : interface eth0 not configured
> ifconfig eth0 down gives me no response
> and in both cases the port stays connected.
> Any ideas on how to accomplish turning it off?
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/B1aieu5HaLE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Ubuntu snappy 15.04 image does not boot from SD card

[William Hermans]

Hilmar, I've no idea what Ninjablock is,I've just now looked, and there
seems to be many different things that could be related. However, since
Ubuntu is based on Debian there is a decent chance that porting it over
could be possible. The biggest hurdle might be which compiler(version) was
used on Ubuntu. Since Ubuntu's package's are typically ahead of
Debians(stable) packages in versions.

Anyway, the biggest reason to make the change would be for consistency. So
if you would prefer a more consistent experience, Debian might be the right
choice for you.

But really, what needs to be ported ? Drivers ? Or is it just some
executable from source that could be easily recompiled on Debian ? Now
might be the time to catalog what needs doing before you invest too much
time into Ubuntu - If you do not care to.



On Sat, Jan 2, 2016 at 9:59 AM, Hilmar Lapp  wrote:

>
> On Jan 2, 2016, at 3:22 AM, doog  wrote:
>
> FWIW, that elinux link I pointed to does boot and boots rather fast too.
> Also has apache pre-installed.
>
>
> I agree. I actually used the raw SD image further down the page for
> checking it out, and it worked perfectly well (albeit it is truly minimal -
> not even the man pages are installed).
>
> However, apparently Canonical decided to not support systemd yet in 14.04
> (it seems to the consternation of their own users). This is in contrast to
> Debian, which is hybrid already in Wheezy. While there’s nothing wrong with
> SysV, I’m not a Linux sysadmin, don’t have the ambition to learn both, and
> am getting used to systemd from Wheezy.  There isn’t a 14.10 (let alone
> 15.04) image build yet.
>
> The main reason I’m trying to get my hands on Ubuntu for BBB is that I
> have a Ninjablock - which at its heart is a BBB running Ubuntu 13.04 - that
> I’m trying to update to the latest version so I can have a more
> reproducible platform for testing out changes. But it seems to me that I
> may be better off porting it over to Debian, maybe Jessie.
>
>   -hilmar
> --
> Hilmar Lapp -:- lappland.io
>
>
>
> --
> 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.
>

-- 
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] Re: Ubuntu snappy 15.04 image does not boot from SD card

[Hilmar Lapp]

> On Jan 2, 2016, at 3:22 AM, doog  wrote:
> 
> FWIW, that elinux link I pointed to does boot and boots rather fast too. Also 
> has apache pre-installed.


I agree. I actually used the raw SD image further down the page for checking it 
out, and it worked perfectly well (albeit it is truly minimal - not even the 
man pages are installed).

However, apparently Canonical decided to not support systemd yet in 14.04 (it 
seems to the consternation of their own users). This is in contrast to Debian, 
which is hybrid already in Wheezy. While there’s nothing wrong with SysV, I’m 
not a Linux sysadmin, don’t have the ambition to learn both, and am getting 
used to systemd from Wheezy.  There isn’t a 14.10 (let alone 15.04) image build 
yet.

The main reason I’m trying to get my hands on Ubuntu for BBB is that I have a 
Ninjablock - which at its heart is a BBB running Ubuntu 13.04 - that I’m trying 
to update to the latest version so I can have a more reproducible platform for 
testing out changes. But it seems to me that I may be better off porting it 
over to Debian, maybe Jessie.

  -hilmar  
-- 
Hilmar Lapp -:- lappland.io



-- 
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: Python OpenCV code runnig on BBB interacting with the PRUs

[doog]

IIRC, the PRU's are memory mapped so you could "talk" to the PRU using that 
memory. If none of that makes sense to you then you have a learning curve 
ahead of you before you'll be even close to ready to write software for the 
PRU to control your servos.

Might I suggest you write your software to control the servo(s) in Python 
first and see how well it reacts with your OpenCV program. If that's not 
_fast_ enough then port the servo software to C++ and if that is not fast 
enough you would then have enough understanding of your project, software 
development in C and the BBB to start porting your servo code to the PRU(s).

On Saturday, January 2, 2016 at 5:04:22 AM UTC-8, Tinashe Mudavanhu wrote:
>
> Hi,
>
> I recently bought a BBB to run an eye tracking opencv code. I am a novice 
> in this area so please dont get frustrated if the question seems silly. How 
> do i make the opencv code interact with the PRUs on the BBB? The motive is 
> to use PRU controlled servo motors to move the camera (for faster realtime 
> operations), but since PRUs are just mere microcontrollers that cannot run 
> opencv (opencv running on the Debian OS on BBB), how do i link the code 
> running on the OS and the PRUs?
>
> I intend to use python for the opencv code. I'm open to further 
> clarification on my question just thought that this might be a starting 
> point.
>
> Kind Regards,
>
> Tinashe
>

-- 
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: Errors reading multiple Analog Inputs from Beaglebone Black using C++

[TJF]

Hi Sunny!

ADC over sysfs is buggy (at least in kernel versions 3.8.x). That's why I 
wrote libpruio . It provides full 
control over the ADC subsystem at full speed (200 kHz). Find a simple C 
example to scan ADC values at this links: Description 

 
and Source Code 

.

Some users told me that they compile against the library from C++ code.

BR

-- 
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] Errors reading multiple Analog Inputs from Beaglebone Black using C++

[William Hermans]

>
> *The ints and floats inside the loop are not a problem. Only one of each
> is allocated on the stack when the function is entered, and then they're
> assigned each time through the loop. Perfectly fine (and good practice for
> limiting the scope of variables).*


This would assume you know which compiler is being used, and you've
actually disassembled the executable to see what the compiler does.
Generally, it is a bad idea to assume you know what is happening. Because
of this ambiguity, it is considered bad form.

A while statement has no concept of scope. So main() has scope whether
inside the while statement, or not.


On Sat, Jan 2, 2016 at 3:45 AM, Rick Mann  wrote:

> What version of the kernel are you using? There's a problem with some of
> them.
>
> The ints and floats inside the loop are not a problem. Only one of each is
> allocated on the stack when the function is entered, and then they're
> assigned each time through the loop. Perfectly fine (and good practice for
> limiting the scope of variables).
>
> > On Jan 1, 2016, at 21:08 , William Hermans  wrote:
> >
> > It's been a while since I've written anything in C++, but I notice
> you're not doing any error checking on your filestream. For instance check
> out the very simply code listing I demonstrate here ( in C ).
> http://www.embeddedhobbyist.com/2015/10/beaglebone-black-adc/
> >
> > Notice that I'm checking if length is -1, and if so, moving code
> execution back up to the top of the loop. Using continue. You should be
> doing something similar( whatever filestream allows ). Also, I've not idea
> how filestream works in Linux, but if you're opening a new file descriptor
> every function call, you'll want to refactor that out. e.g. you get your
> file descriptor only once when the executable is first run, and then
> operate off that.
> >
> > Another thing that you have not really asked about but deserves mention.
> You're declaring 2 int's and two floats every program loop. You'll want to
> fix that . . .
> >
> > On Fri, Jan 1, 2016 at 9:26 PM, Sunny Sharma 
> wrote:
> > Hi friends,
> >
> > I am trying to voltage values from 2 analog sensors which are connected
> to pins AIN0 and AIN1 using C++. I have taken Derek Molloy's code for
> reading one voltage value and edited it to add a second pin to read values
> from. The code is as follows:
> >
> > #include
> > #include
> > #include
> > #include
> > #include
> > using namespace std;
> >
> > #define LDR_PATH "/sys/bus/iio/devices/iio:device0/in_voltage"
> >
> > int readAnalog(int number){
> >
> >stringstream ss;
> >
> >ss << LDR_PATH << number << "_raw";
> >
> >fstream fs;
> >
> >fs.open(ss.str().c_str(), fstream::in);
> >
> >fs >> number;
> >
> >fs.close();
> >
> >return number;
> >
> > }
> >
> > int main(int argc, char* argv[]){
> >
> >cout << "Starting the IR distance sensor program:" << endl;
> >
> >while(1) {
> >
> >   int value0 = readAnalog(0);
> >   int value1 = readAnalog(1);
> >   float V0 = ((float)value0 / 4096) * 1.8;
> >   float V1 = ((float)value1 / 4096) * 1.8;
> >
> >   cout << "Sensor0 is: " << V0 << " Sensor1 is: " << V1 << '\r' <<
> flush;
> >
> >   usleep(10);
> >
> >}
> >
> >return 0;
> > }
> >
> > However, when I run this code, after 10-15 successful iterations, I
> receive this error message:
> >
> > terminate called after throwing an instance of 'std::ios_base::failure'
> >   what():  basic_filebuf::underflow error reading the file
> > Aborted
> >
> > I am not sure as to why I am receiving this error, or really what this
> error message even means. My guess it is some access error when trying to
> read the pin value.
> >
> > The Adafruit BBIO python library actually found a work around this issue
> in C, but I'm not sure how I can extrapolate this to C++ (see:
> https://github.com/adafruit/adafruit-beaglebone-io-python/blob/master/source/c_adc.c
> )
> >
> > If anyone has any insight or help they could offer, that would be very
> helpful!
> >
> > 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.
> >
> >
> > --
> > 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.
>
>
> --
> Rick Mann
> rm...@latencyzero.com
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard

[beagleboard] Python OpenCV code runnig on BBB interacting with the PRUs

[Tinashe Mudavanhu]

Hi,

I recently bought a BBB to run an eye tracking opencv code. I am a novice 
in this area so please dont get frustrated if the question seems silly. How 
do i make the opencv code interact with the PRUs on the BBB? The motive is 
to use PRU controlled servo motors to move the camera (for faster realtime 
operations), but since PRUs are just mere microcontrollers that cannot run 
opencv (opencv running on the Debian OS on BBB), how do i link the code 
running on the OS and the PRUs?

I intend to use python for the opencv code. I'm open to further 
clarification on my question just thought that this might be a starting 
point.

Kind Regards,

Tinashe

-- 
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] Errors reading multiple Analog Inputs from Beaglebone Black using C++

[Rick Mann]

What version of the kernel are you using? There's a problem with some of them.

The ints and floats inside the loop are not a problem. Only one of each is 
allocated on the stack when the function is entered, and then they're assigned 
each time through the loop. Perfectly fine (and good practice for limiting the 
scope of variables).

> On Jan 1, 2016, at 21:08 , William Hermans  wrote:
> 
> It's been a while since I've written anything in C++, but I notice you're not 
> doing any error checking on your filestream. For instance check out the very 
> simply code listing I demonstrate here ( in C ). 
> http://www.embeddedhobbyist.com/2015/10/beaglebone-black-adc/
> 
> Notice that I'm checking if length is -1, and if so, moving code execution 
> back up to the top of the loop. Using continue. You should be doing something 
> similar( whatever filestream allows ). Also, I've not idea how filestream 
> works in Linux, but if you're opening a new file descriptor every function 
> call, you'll want to refactor that out. e.g. you get your file descriptor 
> only once when the executable is first run, and then operate off that.
> 
> Another thing that you have not really asked about but deserves mention. 
> You're declaring 2 int's and two floats every program loop. You'll want to 
> fix that . . .
> 
> On Fri, Jan 1, 2016 at 9:26 PM, Sunny Sharma  wrote:
> Hi friends,
> 
> I am trying to voltage values from 2 analog sensors which are connected to 
> pins AIN0 and AIN1 using C++. I have taken Derek Molloy's code for reading 
> one voltage value and edited it to add a second pin to read values from. The 
> code is as follows: 
> 
> #include
> #include
> #include
> #include
> #include
> using namespace std;
> 
> #define LDR_PATH "/sys/bus/iio/devices/iio:device0/in_voltage"
> 
> int readAnalog(int number){  
>
>stringstream ss; 
>
>ss << LDR_PATH << number << "_raw"; 
>
>fstream fs; 
>
>fs.open(ss.str().c_str(), fstream::in); 
>
>fs >> number; 
>
>fs.close(); 
>
>return number;
>
> }
> 
> int main(int argc, char* argv[]){
>
>cout << "Starting the IR distance sensor program:" << endl;
>
>while(1) {
>
>   int value0 = readAnalog(0);
>   int value1 = readAnalog(1);
>   float V0 = ((float)value0 / 4096) * 1.8;
>   float V1 = ((float)value1 / 4096) * 1.8; 
>   
>   cout << "Sensor0 is: " << V0 << " Sensor1 is: " << V1 << '\r' << flush;
>   
>   usleep(10); 
>   
>}
>
>return 0;
> }
> 
> However, when I run this code, after 10-15 successful iterations, I receive 
> this error message: 
> 
> terminate called after throwing an instance of 'std::ios_base::failure'
>   what():  basic_filebuf::underflow error reading the file
> Aborted 
> 
> I am not sure as to why I am receiving this error, or really what this error 
> message even means. My guess it is some access error when trying to read the 
> pin value. 
> 
> The Adafruit BBIO python library actually found a work around this issue in 
> C, but I'm not sure how I can extrapolate this to C++ (see: 
> https://github.com/adafruit/adafruit-beaglebone-io-python/blob/master/source/c_adc.c)
>  
> 
> If anyone has any insight or help they could offer, that would be very 
> helpful! 
> 
> 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.
> 
> 
> -- 
> 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.


-- 
Rick Mann
rm...@latencyzero.com


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

Re: [beagleboard] Re: Ubuntu snappy 15.04 image does not boot from SD card

[doog]

FWIW, that elinux link I pointed to does boot and boots rather fast too. 
Also has apache pre-installed.

Downloaded the tar.xz, extracted it, ran "sudo ./setup_sdcard.sh --mmc 
/dev/mmcblk0 --dtb beaglebone" to build and image the uSD 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.