Re: [beagleboard] Kernel Panic with eMMC flasher

[William Hermans]

Jesus, do either of you do any independent reading on your own ?
 "guaranteed"  .  . do a bit of googling on your own . . .

On Tue, Nov 18, 2014 at 10:44 PM, Jason Lange  wrote:

> twou twou omwee tou twou. ;)
>
> On Tue, Nov 18, 2014 at 7:49 PM, Jason Lange  wrote:
>
>>
>>
>> On Tue, Nov 18, 2014 at 7:02 PM, William Hermans 
>> wrote:
>>
>>> What I am trying to convey to you is that "sync" is never guaranteed.
>>> Ever.
>>>
>>
>> garunteed?
>>
>
>  --
> 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] Kernel Panic with eMMC flasher

[Jason Lange]

twou twou omwee tou twou. ;)

On Tue, Nov 18, 2014 at 7:49 PM, Jason Lange  wrote:

>
>
> On Tue, Nov 18, 2014 at 7:02 PM, William Hermans 
> wrote:
>
>> What I am trying to convey to you is that "sync" is never guaranteed.
>> Ever.
>>
>
> garunteed?
>

-- 
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] Kernel Panic with eMMC flasher

[John Syn]

From:  William Hermans 
Reply-To:  "beagleboard@googlegroups.com" 
Date:  Tuesday, November 18, 2014 at 7:02 PM
To:  "beagleboard@googlegroups.com" 
Subject:  Re: [beagleboard] Kernel Panic with eMMC flasher

> What I am trying to convey to you is that "sync" is never guaranteed. Ever.
Where do you get this from. Reference?

Regards,
John
> 
> 
> On Tue, Nov 18, 2014 at 7:56 PM, Jason Lange  wrote:
>> 
>> 
>> On Tue, Nov 18, 2014 at 4:57 PM, William Hermans  wrote:
>>> 
>>> All you can do is:
>>> 
>>> write data
>>> remove media.
>>> sync.
>> 
>> write data
>> sync
>> and then remove media.
>> 
>> That's all I'm really trying to convey.  "dd" does not sync by default.
>> Unmounting from your gui should sync.  But might not if you've been sudo-ing
>> things behind it's back. Once "sync" has completed you can safely remove it
>> regardless of what some gui thinks is going on.
>> -- 
>> 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.


-- 
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] Kernel Panic with eMMC flasher

[Jason Lange]

On Tue, Nov 18, 2014 at 7:02 PM, William Hermans  wrote:

> What I am trying to convey to you is that "sync" is never guaranteed. Ever.
>

garunteed?

-- 
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: Hello and Getting Debian on an Older Model BBB/Seth

[Curt Carpenter]

Hello Mala

I have Debian running on both a BBB and a BBW.  The images are here:  
http://beagleboard.org/latest-images  .  With the BBB, you have the option 
of getting an image that will write Debian to the on-card emmc memory, or 
booting from a micro SD card.  I chose to install Debian by writing it to 
the emmc.  I followed the instructions provided for installing it, and had 
no problems.   The beaglebone white has no on-card emmc, so I boot it using 
the micro SD card, and that seems to work very well too.

I hope that is helpful.

-- 
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] Kernel Panic with eMMC flasher

[William Hermans]

What I am trying to convey to you is that "sync" is never guaranteed. Ever.

On Tue, Nov 18, 2014 at 7:56 PM, Jason Lange  wrote:

>
>
> On Tue, Nov 18, 2014 at 4:57 PM, William Hermans 
> wrote:
>
>>
>> All you can do is:
>>
>> write data
>> remove media.
>> sync.
>>
>
> write data
> sync
> and then remove media.
>
> That's all I'm really trying to convey.  "dd" does not sync by default.
> Unmounting from your gui should sync.  But might not if you've been
> sudo-ing things behind it's back. Once "sync" has completed you can safely
> remove it regardless of what some gui thinks is going on.
>
> --
> 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] GPIO Pin Numbering Confusion

[William Hermans]

Why do i feel like im becoming less intelligent by reading these posts ?

On Tue, Nov 18, 2014 at 6:32 PM, Charles Steinkuehler <
char...@steinkuehler.net> wrote:

> On 11/18/2014 7:24 PM, Jason Kridner wrote:
> > On Tuesday, November 18, 2014 1:42:37 PM UTC-5, Charles Steinkuehler
> wrote:
> >> On 11/18/2014 12:31 PM, Robert Nelson wrote:
> >>>
> >>> Double check against these:
> >>>
> >>> https://github.com/derekmolloy/boneDeviceTree/tree/master/docs
> >> <
> https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fderekmolloy%2FboneDeviceTree%2Ftree%2Fmaster%2Fdocs&sa=D&sntz=1&usg=AFQjCNFq9MtrmezYsjTeRLYl8A69a_nAJw
> >
> >>>
> >>> At one time i had the equation down, but derek's eye chart works
> better.
> >> ;)
> >>
> >> That shows the GPIO pin numbers to be 110-113, as I expected.  It looks
> >> like the 120-123 numbers on the Bone101 web page graphics are incorrect.
> >>
> >> ...who gets the bug report?
> >
> > That would be me. Better now?
>
> Yes Jason, that looks much better!
>
> Thanks for the quick fix!
>
> --
> Charles Steinkuehler
> char...@steinkuehler.net
>
> --
> 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] Kernel Panic with eMMC flasher

[Jason Lange]

On Tue, Nov 18, 2014 at 4:57 PM, William Hermans  wrote:

>
> All you can do is:
>
> write data
> remove media.
> sync.
>

write data
sync
and then remove media.

That's all I'm really trying to convey.  "dd" does not sync by default.
Unmounting from your gui should sync.  But might not if you've been
sudo-ing things behind it's back. Once "sync" has completed you can safely
remove it regardless of what some gui thinks is going on.

-- 
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] Kernel Panic with eMMC flasher

[William Hermans]

"prerecorded" ? I never wrote that
 . . . Preferred is what I wrote,

On Tue, Nov 18, 2014 at 7:53 PM, William Hermans  wrote:

> Advice ? Use Linux to flash Linux. I use windows on a daily basis, and
> honestly it is is my prerecorded OS. But when dealing with Linux, use
> Linux. . .
>
> On Tue, Nov 18, 2014 at 7:08 PM, Robert Nelson 
> wrote:
>
>> On Tue, Nov 18, 2014 at 7:24 PM, Joe Spanier 
>> wrote:
>> > Latest failure. This time I flashed from windows 7 just to try
>> something new, different PC and card reader, and used a wallwart. No dice.
>> Slightly different t error message with the panic though. Progress??
>>
>> Thanks for re-testing..  This looks to be evil v3.8.x, never saw it
>> fail on the eMMC, but i get that error alot of microSD cards..
>>
>> So here's a v3.14.x based kernel snapshot using jessie:
>>
>> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Jessie_Snapshot
>>
>> It's using a newer kernel (v3.14.x) vs the old v3.8.x
>>
>> Once the eMMC has been flashed, you can safely downgrade to the v3.8.x
>> based kernel via: (and get capemgr)
>>
>> sudo apt-get update
>> sudo apt-get install linux-image-3.8.13-bone67
>> sudo reboot
>>
>> Regards,
>>
>> --
>> Robert Nelson
>> http://www.rcn-ee.com/
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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] Kernel Panic with eMMC flasher

[William Hermans]

Advice ? Use Linux to flash Linux. I use windows on a daily basis, and
honestly it is is my prerecorded OS. But when dealing with Linux, use
Linux. . .

On Tue, Nov 18, 2014 at 7:08 PM, Robert Nelson 
wrote:

> On Tue, Nov 18, 2014 at 7:24 PM, Joe Spanier  wrote:
> > Latest failure. This time I flashed from windows 7 just to try something
> new, different PC and card reader, and used a wallwart. No dice. Slightly
> different t error message with the panic though. Progress??
>
> Thanks for re-testing..  This looks to be evil v3.8.x, never saw it
> fail on the eMMC, but i get that error alot of microSD cards..
>
> So here's a v3.14.x based kernel snapshot using jessie:
>
> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Jessie_Snapshot
>
> It's using a newer kernel (v3.14.x) vs the old v3.8.x
>
> Once the eMMC has been flashed, you can safely downgrade to the v3.8.x
> based kernel via: (and get capemgr)
>
> sudo apt-get update
> sudo apt-get install linux-image-3.8.13-bone67
> sudo reboot
>
> Regards,
>
> --
> Robert Nelson
> http://www.rcn-ee.com/
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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] Kernel Panic with eMMC flasher

[Robert Nelson]

On Tue, Nov 18, 2014 at 7:24 PM, Joe Spanier  wrote:
> Latest failure. This time I flashed from windows 7 just to try something new, 
> different PC and card reader, and used a wallwart. No dice. Slightly 
> different t error message with the panic though. Progress??

Thanks for re-testing..  This looks to be evil v3.8.x, never saw it
fail on the eMMC, but i get that error alot of microSD cards..

So here's a v3.14.x based kernel snapshot using jessie:

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Jessie_Snapshot

It's using a newer kernel (v3.14.x) vs the old v3.8.x

Once the eMMC has been flashed, you can safely downgrade to the v3.8.x
based kernel via: (and get capemgr)

sudo apt-get update
sudo apt-get install linux-image-3.8.13-bone67
sudo reboot

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/

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

Re: [beagleboard] Kernel Panic with eMMC flasher

[Joe Spanier]

On Tuesday, November 18, 2014 7:24:11 PM UTC-6, Joe Spanier wrote:
>
> Latest failure. This time I flashed from windows 7 just to try something 
> new, different PC and card reader, and used a wallwart. No dice. Slightly 
> different t error message with the panic though. Progress??

-- 
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] GPIO Pin Numbering Confusion

[Charles Steinkuehler]

On 11/18/2014 7:24 PM, Jason Kridner wrote:
> On Tuesday, November 18, 2014 1:42:37 PM UTC-5, Charles Steinkuehler wrote:
>> On 11/18/2014 12:31 PM, Robert Nelson wrote: 
>>>
>>> Double check against these: 
>>>
>>> https://github.com/derekmolloy/boneDeviceTree/tree/master/docs 
>> 
>>  
>>>
>>> At one time i had the equation down, but derek's eye chart works better. 
>> ;) 
>>
>> That shows the GPIO pin numbers to be 110-113, as I expected.  It looks 
>> like the 120-123 numbers on the Bone101 web page graphics are incorrect. 
>>
>> ...who gets the bug report? 
> 
> That would be me. Better now?

Yes Jason, that looks much better!

Thanks for the quick fix!

-- 
Charles Steinkuehler
char...@steinkuehler.net

-- 
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] GPIO Pin Numbering Confusion

[Jason Kridner]

On Tuesday, November 18, 2014 1:42:37 PM UTC-5, Charles Steinkuehler wrote:
>
> On 11/18/2014 12:31 PM, Robert Nelson wrote: 
> > On Tue, Nov 18, 2014 at 12:13 PM, Charles Steinkuehler 
> >  wrote: 
> >> I'm confused by the GPIO pin numbering shown on the Bone101 support 
> page: 
> >> 
> >> http://beagleboard.org/Support/bone101 
> >> 
> >> P9 pins 28-31 are listed as GPIO_120 through GPIO_123, which seems to 
> be 
> >> off by 10.  The schematic shows these as GPIO bank 3, pins 14-17, which 
> >> by my understanding should be: 
> >> 
> >>   ( 32 * 3 ) + 14 = 96 + 14 = 110 
> >>   ...to... 
> >>   ( 32 * 3 ) + 17 = 96 + 17 = 113 
> > 
> > Double check against these: 
> > 
> > https://github.com/derekmolloy/boneDeviceTree/tree/master/docs 
> 
>  
> > 
> > At one time i had the equation down, but derek's eye chart works better. 
> ;) 
>
> That shows the GPIO pin numbers to be 110-113, as I expected.  It looks 
> like the 120-123 numbers on the Bone101 web page graphics are incorrect. 
>
> ...who gets the bug report? 
>

That would be me. Better now?
 

>
> -- 
> Charles Steinkuehler 
> char...@steinkuehler.net 
>

-- 
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] Kernel Panic with eMMC flasher

[Joe Spanier]

Latest failure. This time I flashed from windows 7 just to try something new, 
different PC and card reader, and used a wallwart. No dice. Slightly different 
t error message with the panic though. Progress??

-- 
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] Beaglebone Black Rebooting Several Times Every Day

[Britton Kerin]

On Tue, Nov 18, 2014 at 1:06 PM, Robert Nelson  wrote:
> On Tue, Nov 18, 2014 at 3:58 PM, Greg Kelley  wrote:
>> Update to Reboot Issue:
>>
>> OK I did two things at once which from my old Beta Tester days is a no-no
>> since you can't figure out which change made a difference. But
>>
>> I updated the kernel to 3.14.23-ti-r34
>>
>> Then I did an apt-get update/upgrade and I noticed that dbus got upgraded in
>> the process.
>>
>> Now when I hot plug a USB stick into my external 7 port hub it comes right
>> up. Before, it wouldn't get recognized unless I had a 'constantly on' device
>> also plugged into the hub (like a printer), so dbus upgrade 'fixed'
>> something regarding that issue
>>
>> The really good news is I've been up for two days with no random reboots.
>> New kernel or dbus? Don't know, don't care, as long as the reboot monster
>> has been banished into the deep dark pit.
>
> We had a couple musb patches get rolled in from ti..
>
> https://github.com/beagleboard/linux/compare/3.14.23-ti-r33...3.14.23-ti-r34
>
> otherwise we are defaulting to peripheral mode for the slave connector.
>
> https://github.com/beagleboard/linux/commit/b30d918f1e9657d3a9b2eaf7fc6ea3f7ea545b5c

I just had a strange incident in which a USB-connected device entirely lost
power on the BBB rev.C.  Otherwise the BBB continued operating normally.
I'm on a 6A power supply, with the software that shipped with the BBB.

Might this be related to these fixes?  Is there anything else on the software
side that might shut down power to the USB port?

Britton

-- 
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] Kernel Panic with eMMC flasher

[William Hermans]

First of all, as far as the sdcard is concerned. sync has nothing to do
with it, UNLESS, you are trying to remount the same exact sdcard.

sync is not infallible, and as such will not always do what you think it
may do. sync can take a considerable amount of time to achieve what you
think it should achieve.

 What does a UI(Unity ) have to do with DD ? An application that has been
around for YEARS longer than Unity ?

All you can do is:

write data
remove media.
sync.

If the OS you're using screws this up, then it does not deserve to be used.
Otherwise, it is user error.

On Tue, Nov 18, 2014 at 2:08 PM, Jason Lange  wrote:

>
>
> On Mon, Nov 17, 2014 at 1:47 PM, Joe Spanier 
>
>> I am properly ejecting the card from my laptop after completing dd. Is
>> that what you mean by sync?
>>
>
>
>>
>> > Here are the steps Im using:
 > 1. Wget the image
 > 2. md5sum check
 > 3. xzcat BBB-eMMC-Flasher... ...img.xz | sudo dd bs=4096 of=/dev/sdc

>>>
> change step 3 to:
>
> . xzcat BBB-eMMC-Flasher... ...img.xz | sudo dd bs=4096 of=/dev/sdc; sync
>
> sync ensures that whatever is in the buffers actually gets written to the
> disk.  The sdcard shouldn't even be mounted on the desktop while you dd
> it.  At least with unity it will still dd properly but the desktop is not
> aware and shows it mounted in it's previous state.  A desktop unmount at
> this point is potentially harmful.
>
> I wish there was a simple way to verify the image after you've flashed it
> to the card -- does anyone know how to do this?
>
> Cheers.
>
>  --
> 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] Beaglebone Black Rebooting Several Times Every Day

[William Hermans]

@Greg Kelley

Welcome to the wonderful world of Linux. This is how it used to be for
*ANYTHING* new to Debian, back in the day. This is why ppl such as myself
will often tell you research your hardware before you install debian on it.
Or more correctly. By hardware that has known debian support.

Now days, this seems to be less of a problem, and you can very easily
exchange "debian" for "Linux" in general. But the general idea of
"researching" whatever you do, before you do it still stands. I even do
this with Windows in mind, and windows has far better driver support
compared to *ANY* OS out there. Period.

On Tue, Nov 18, 2014 at 3:06 PM, Robert Nelson 
wrote:

> On Tue, Nov 18, 2014 at 3:58 PM, Greg Kelley  wrote:
> > Update to Reboot Issue:
> >
> > OK I did two things at once which from my old Beta Tester days is a no-no
> > since you can't figure out which change made a difference. But
> >
> > I updated the kernel to 3.14.23-ti-r34
> >
> > Then I did an apt-get update/upgrade and I noticed that dbus got
> upgraded in
> > the process.
> >
> > Now when I hot plug a USB stick into my external 7 port hub it comes
> right
> > up. Before, it wouldn't get recognized unless I had a 'constantly on'
> device
> > also plugged into the hub (like a printer), so dbus upgrade 'fixed'
> > something regarding that issue
> >
> > The really good news is I've been up for two days with no random reboots.
> > New kernel or dbus? Don't know, don't care, as long as the reboot monster
> > has been banished into the deep dark pit.
>
> We had a couple musb patches get rolled in from ti..
>
>
> https://github.com/beagleboard/linux/compare/3.14.23-ti-r33...3.14.23-ti-r34
>
> otherwise we are defaulting to peripheral mode for the slave connector.
>
>
> https://github.com/beagleboard/linux/commit/b30d918f1e9657d3a9b2eaf7fc6ea3f7ea545b5c
>
> Thanks for testing!
>
> Regards,
>
> --
> Robert Nelson
> http://www.rcn-ee.com/
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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: beagleboard Pointers

[William Hermans]

Key point I might mention is that Linux is Linux, is Linux. Past that,
Debian, is Debian is Debian

The point here ? The point is you can often very easily adapt something
from lets say a rPI guide to work with a beagleboard, or beaglebone. It
really is that simple, and if you do not know how, then you need to
understand Linux better,

On Tue, Nov 18, 2014 at 4:10 PM, Graham  wrote:

> Puneet:
>
> I would recommend that you go to the website of Derek Molloy.
>
> There are many tutorials and videos about the BeagleBone Black,
> getting started, and how to program.
>
> http://derekmolloy.ie/beaglebone/
>
> Best regards,
> --- Graham
>
> ==
>
> On Tuesday, November 18, 2014 1:43:48 AM UTC-6, puneetw...@gmail.com
> wrote:
>>
>> Hi,
>>I am starting afresh on beagleboard black. i am getting confused with
>> so much information available on net. Can somebody point me to the best
>> documentation/Video to get quick started. My first aim is to exercise all
>> the Interface of the processor.
>>Thanks in Advance.
>> Thanks
>> Puneet
>>
>>  --
> 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.

[beagleboard] Re: beagleboard Pointers

[Graham]

Puneet:

I would recommend that you go to the website of Derek Molloy.

There are many tutorials and videos about the BeagleBone Black, 
getting started, and how to program.

http://derekmolloy.ie/beaglebone/

Best regards,
--- Graham

==

On Tuesday, November 18, 2014 1:43:48 AM UTC-6, puneetw...@gmail.com wrote:
>
> Hi,
>I am starting afresh on beagleboard black. i am getting confused with 
> so much information available on net. Can somebody point me to the best 
> documentation/Video to get quick started. My first aim is to exercise all 
> the Interface of the processor. 
>Thanks in Advance.
> Thanks
> Puneet
>
>

-- 
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] Beaglebone Black Rebooting Several Times Every Day

[Robert Nelson]

On Tue, Nov 18, 2014 at 3:58 PM, Greg Kelley  wrote:
> Update to Reboot Issue:
>
> OK I did two things at once which from my old Beta Tester days is a no-no
> since you can't figure out which change made a difference. But
>
> I updated the kernel to 3.14.23-ti-r34
>
> Then I did an apt-get update/upgrade and I noticed that dbus got upgraded in
> the process.
>
> Now when I hot plug a USB stick into my external 7 port hub it comes right
> up. Before, it wouldn't get recognized unless I had a 'constantly on' device
> also plugged into the hub (like a printer), so dbus upgrade 'fixed'
> something regarding that issue
>
> The really good news is I've been up for two days with no random reboots.
> New kernel or dbus? Don't know, don't care, as long as the reboot monster
> has been banished into the deep dark pit.

We had a couple musb patches get rolled in from ti..

https://github.com/beagleboard/linux/compare/3.14.23-ti-r33...3.14.23-ti-r34

otherwise we are defaulting to peripheral mode for the slave connector.

https://github.com/beagleboard/linux/commit/b30d918f1e9657d3a9b2eaf7fc6ea3f7ea545b5c

Thanks for testing!

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/

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

Re: [beagleboard] Beaglebone Black Rebooting Several Times Every Day

[Greg Kelley]

Update to Reboot Issue:

OK I did two things at once which from my old Beta Tester days is a no-no 
since you can't figure out which change made a difference. But

I updated the kernel to 3.14.23-ti-r34

Then I did an apt-get update/upgrade and I noticed that dbus got upgraded 
in the process.

Now when I hot plug a USB stick into my external 7 port hub it comes right 
up. Before, it wouldn't get recognized unless I had a 'constantly on' 
device also plugged into the hub (like a printer), so dbus upgrade 'fixed' 
something regarding that issue

The really good news is I've been up for two days with no random reboots. 
New kernel or dbus? Don't know, don't care, as long as the reboot monster 
has been banished into the deep dark pit.

-- 
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] Kernel Panic with eMMC flasher

[Jason Lange]

On Mon, Nov 17, 2014 at 1:47 PM, Joe Spanier 

> I am properly ejecting the card from my laptop after completing dd. Is
> that what you mean by sync?
>


>
> > Here are the steps Im using:
>>> > 1. Wget the image
>>> > 2. md5sum check
>>> > 3. xzcat BBB-eMMC-Flasher... ...img.xz | sudo dd bs=4096 of=/dev/sdc
>>>
>>
change step 3 to:

. xzcat BBB-eMMC-Flasher... ...img.xz | sudo dd bs=4096 of=/dev/sdc; sync

sync ensures that whatever is in the buffers actually gets written to the
disk.  The sdcard shouldn't even be mounted on the desktop while you dd
it.  At least with unity it will still dd properly but the desktop is not
aware and shows it mounted in it's previous state.  A desktop unmount at
this point is potentially harmful.

I wish there was a simple way to verify the image after you've flashed it
to the card -- does anyone know how to do this?

Cheers.

-- 
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: Controling Hardware Through Web Page problem

[John Mladenik]

After playing with it I did figure out why it did not work when I linked to 
it through the USB.  I linked through it with the :3000 in the which is the 
link that I get from Cloud9 when I preview the page.   The link was:

192.168.7.2:3000/preview/thermostat.html

I didn't know that the default/root directory for web pages was 
/var/lib/cloud9  , I had thought it was the root directory /root and I also 
didn't think it mattered where the HTML file was located or how it was 
linked to through the browser, I thought it would work from any directory 
through any route.Once I linked to the HTML through a direct route 
without the :3000 it worked fine.   

So when you point to the link given in Cloud9 the HTML/JS program won't 
work and I think this is why the Cloud9 preview doesn't actually run the 
javascript when you preview the file you create and edit.  

So once I linked directly as such 
USB
192.168.7.2/thermostat.html 

or
Ethernet
130.140.37.188/thermostat.html

Everything did work in both cases.  

Some things do work through the preview link in cloud9 and others do not.

Thanks Jason and everyone else for all the help.


John


On Tuesday, November 18, 2014 10:09:51 AM UTC-8, Jason Kridner wrote:
>
> On Tue, Nov 18, 2014 at 10:04 AM, John Mladenik  > wrote: 
> > Bottom line was that the socket IO functions did not quite work right 
> when 
> > the BBB was only connected through the USB.  Once I connected through an 
> > Ethernet connection it all started to work. 
>
> They work just fine over USB. The problem is you aren't documenting 
> enough of your steps for us to tell you where you are going wrong. 
>
> > 
> > 
> > On Saturday, November 15, 2014 10:27:53 PM UTC-8, John Mladenik wrote: 
> >> 
> >> I have tried at least 6 different tutorials to turn an LED on and off 
> >> through a web page.   None of them work and all get one error or 
> another. 
> >> 
> >> The most common one is right after the line 
> >> var socket = io.connect(); 
> >>  Uncaught ReferenceError: io is not defined. 
> >> 
> >> I followed the instruction to install socket.io 2 or 3 times and think 
> >> this worked successfully. 
> >> 
> >> I did have to change the src line with socket.io.js in it to stop that 
> >> from getting an error and I changed it to 
> >> 
> >>  >> src="
> 192.168.7.2:3000/preview/node_modules/socket.io/node_modules/socket.io-client/socket.io.js">
>  
>
> >>  
> >> 
> >> I have a new Rev C Beaglebone Black running Debian.  Any suggestion or 
> any 
> >> link or example I can try that can do something as simple as control a 
> GPIO 
> >> from a web page? 
> > 
> > -- 
> > For more options, visit http://beagleboard.org/discuss 
> > --- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "BeagleBoard" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to beagleboard...@googlegroups.com . 
> > 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] DTO pinmux settings are not applying

[Charles Steinkuehler]

On 11/18/2014 10:45 AM, matt.linabe...@we-ics.com wrote:
> 
> My questions are this:  Is there anything else that needs to be added to 
> this DTO to get the new pin mux settings applied correctly for these four 
> pins?  

I can't make sense of what you're doing, so I don't know.

> Am I missing in the SRM documentation somewhere these pins can't be muxed 
> to something different?  

All the pins except for some special purpose ones (like DRAM and analog
inputs) can be muxed.

> Apologies if something doesn't make sense in my post...  I'm still quite a 
> newbie to device tree overlays.

Almost nothing made any sense, and what bits did make sense seemed
contradicted by other things you mentioned.  Be as specific and exact as
possible in your questions, include what you tried, what you expected to
happen, what _actually_ happened, and someone might be able to help you.
 Also, obfuscating your situation by "helpfully" chopping out huge
chunks of your configuration files isn't a good way to get help.  If
your files are too big for an email, post a link to them on github,
dropbox, Google drive, or wherever.

-- 
Charles Steinkuehler
char...@steinkuehler.net

-- 
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] Beaglebone Black Rebooting Several Times Every Day

[Jason Lange]

Hello again,

Okay, (@Robert) I can confirm that it is not reliable when I am not
manually initiating the dhcp from my desktop.  Also (@David) the beagle
does not automatically remove the connection when I disconnect the
ethernet, and so I have to manually remove the no longer valid default
route.  This is probably where ifplugd would make life easier.

Cheers.

On Tue, Nov 18, 2014 at 12:03 PM, Jason Lange  wrote:

> @david
> I have tested this.  Try it, it works.
>
> On Tue, Nov 18, 2014 at 11:52 AM, David Goodenough <
> david.goodeno...@linkchoose.co.uk> wrote:
>
>> On Tuesday 18 November 2014 11:40:42 Jason Lange wrote:
>> > On Fri, Sep 12, 2014 at 9:35 AM, Robert Nelson > >
>> >
>> > wrote:
>> > > On Fri, Sep 12, 2014 at 11:27 AM, Greg Kelley 
>> > >
>> > > wrote:
>> > > > Robert,
>> > > >
>> > > > I think part of the reason ntp and dhcpclient aren't getting network
>> > > > connections at boot is because they are set at S03 in init and wicd
>> is
>> > >
>> > > set
>> > >
>> > > > at S06 and is last to get going. It appears that eth0 is not coming
>> up
>> > >
>> > > until
>> > >
>> > > > wicd loads?
>> > >
>> > > Correct, wicd set's up eth0, that's how we got the 11-12 second bootup
>> > > time. Otherwise if eth0 is handled by /etc/network/interfaces bootup
>> > > could last 2 minutes for users who don't connect eth0.  I should
>> > > atleast really move ntp from S03 to S06..
>> >
>> > @Robert
>> >
>> > There's no need to pull in wicd to solve this; all you need to do is to
>> > replace "auto eth0" with "allow-hotplug eth0" (not both) in
>> > "/etc/network/interfaces".  This gives you eth0 at boot if it's plugged
>> in
>> > but it doesn't wait if it's not, and if you plug it in later it comes
>> right
>> > up.  Oddly it doesn't even wait very long if it's plugged in at start-up
>> > and there is no dhcp being offered.  (all of this is assuming "iface
>> eth0
>> > inet dhcp" is in there too;  I imagine a static route comes up right
>> away
>> > regardless.)
>> >
>> > Cheers.
>> This is not what allow-hotplug means.  It refers to an ethernet interface
>> such
>> as a USB device being plugged in.  In order to get the behaviour you want
>> you need ifplugd.  To quote from the package description:-
>>
>> Description-en: configuration daemon for ethernet devices
>>  ifplugd is a daemon which will automatically configure your ethernet
>> device
>>  when a cable is plugged in and automatically de-configure it if the
>> cable is
>>  pulled out. This is useful on laptops with onboard network adapters,
>> since it
>>  will only configure the interface when a cable is really connected.
>>
>> David
>>
>> --
>> 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] Beaglebone Black Rebooting Several Times Every Day

[Jason Lange]

@david
I have tested this.  Try it, it works.

On Tue, Nov 18, 2014 at 11:52 AM, David Goodenough <
david.goodeno...@linkchoose.co.uk> wrote:

> On Tuesday 18 November 2014 11:40:42 Jason Lange wrote:
> > On Fri, Sep 12, 2014 at 9:35 AM, Robert Nelson 
> >
> > wrote:
> > > On Fri, Sep 12, 2014 at 11:27 AM, Greg Kelley 
> > >
> > > wrote:
> > > > Robert,
> > > >
> > > > I think part of the reason ntp and dhcpclient aren't getting network
> > > > connections at boot is because they are set at S03 in init and wicd
> is
> > >
> > > set
> > >
> > > > at S06 and is last to get going. It appears that eth0 is not coming
> up
> > >
> > > until
> > >
> > > > wicd loads?
> > >
> > > Correct, wicd set's up eth0, that's how we got the 11-12 second bootup
> > > time. Otherwise if eth0 is handled by /etc/network/interfaces bootup
> > > could last 2 minutes for users who don't connect eth0.  I should
> > > atleast really move ntp from S03 to S06..
> >
> > @Robert
> >
> > There's no need to pull in wicd to solve this; all you need to do is to
> > replace "auto eth0" with "allow-hotplug eth0" (not both) in
> > "/etc/network/interfaces".  This gives you eth0 at boot if it's plugged
> in
> > but it doesn't wait if it's not, and if you plug it in later it comes
> right
> > up.  Oddly it doesn't even wait very long if it's plugged in at start-up
> > and there is no dhcp being offered.  (all of this is assuming "iface eth0
> > inet dhcp" is in there too;  I imagine a static route comes up right away
> > regardless.)
> >
> > Cheers.
> This is not what allow-hotplug means.  It refers to an ethernet interface
> such
> as a USB device being plugged in.  In order to get the behaviour you want
> you need ifplugd.  To quote from the package description:-
>
> Description-en: configuration daemon for ethernet devices
>  ifplugd is a daemon which will automatically configure your ethernet
> device
>  when a cable is plugged in and automatically de-configure it if the cable
> is
>  pulled out. This is useful on laptops with onboard network adapters,
> since it
>  will only configure the interface when a cable is really connected.
>
> David
>
> --
> 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] Beaglebone Black Rebooting Several Times Every Day

[Jason Lange]

On Tue, Nov 18, 2014 at 11:43 AM, Robert Nelson 
wrote:

>
> Every time I've tried just "allow-hotplug eth0" i get random
> no-connections when the eth0 is plugged in..
>
> For jessie, I've been using connman + cmst (gui for wifi users) and so
> far it's been a lot smother then wicd in wheezy..
>
> Regards,
>

I just ripped connman and the desktop out of that image. :-) I haven't had
a problem with it failing to connect when plugging into my desktop (ubuntu
14.04) but maybe that's because I've set up my Network Manager to not
automatically connect, so as soon as I plug in the beagle I have to go to
the drop down menu (NM) and activate the connection.  I'll change that to
auto and see if I have 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.

Re: [beagleboard] Beaglebone Black Rebooting Several Times Every Day

[David Goodenough]

On Tuesday 18 November 2014 11:40:42 Jason Lange wrote:
> On Fri, Sep 12, 2014 at 9:35 AM, Robert Nelson 
> 
> wrote:
> > On Fri, Sep 12, 2014 at 11:27 AM, Greg Kelley 
> > 
> > wrote:
> > > Robert,
> > > 
> > > I think part of the reason ntp and dhcpclient aren't getting network
> > > connections at boot is because they are set at S03 in init and wicd is
> > 
> > set
> > 
> > > at S06 and is last to get going. It appears that eth0 is not coming up
> > 
> > until
> > 
> > > wicd loads?
> > 
> > Correct, wicd set's up eth0, that's how we got the 11-12 second bootup
> > time. Otherwise if eth0 is handled by /etc/network/interfaces bootup
> > could last 2 minutes for users who don't connect eth0.  I should
> > atleast really move ntp from S03 to S06..
> 
> @Robert
> 
> There's no need to pull in wicd to solve this; all you need to do is to
> replace "auto eth0" with "allow-hotplug eth0" (not both) in
> "/etc/network/interfaces".  This gives you eth0 at boot if it's plugged in
> but it doesn't wait if it's not, and if you plug it in later it comes right
> up.  Oddly it doesn't even wait very long if it's plugged in at start-up
> and there is no dhcp being offered.  (all of this is assuming "iface eth0
> inet dhcp" is in there too;  I imagine a static route comes up right away
> regardless.)
> 
> Cheers.
This is not what allow-hotplug means.  It refers to an ethernet interface such
as a USB device being plugged in.  In order to get the behaviour you want
you need ifplugd.  To quote from the package description:-

Description-en: configuration daemon for ethernet devices
 ifplugd is a daemon which will automatically configure your ethernet device
 when a cable is plugged in and automatically de-configure it if the cable is
 pulled out. This is useful on laptops with onboard network adapters, since it
 will only configure the interface when a cable is really connected.

David

-- 
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] Beaglebone Black Rebooting Several Times Every Day

[Robert Nelson]

> @Robert
>
> There's no need to pull in wicd to solve this; all you need to do is to
> replace "auto eth0" with "allow-hotplug eth0" (not both) in
> "/etc/network/interfaces".  This gives you eth0 at boot if it's plugged in
> but it doesn't wait if it's not, and if you plug it in later it comes right
> up.  Oddly it doesn't even wait very long if it's plugged in at start-up and
> there is no dhcp being offered.  (all of this is assuming "iface eth0 inet
> dhcp" is in there too;  I imagine a static route comes up right away
> regardless.)

Every time I've tried just "allow-hotplug eth0" i get random
no-connections when the eth0 is plugged in..

For jessie, I've been using connman + cmst (gui for wifi users) and so
far it's been a lot smother then wicd in wheezy..

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/

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

Re: [beagleboard] Beaglebone Black Rebooting Several Times Every Day

[Jason Lange]

On Fri, Sep 12, 2014 at 9:35 AM, Robert Nelson 
wrote:

> On Fri, Sep 12, 2014 at 11:27 AM, Greg Kelley 
> wrote:
> > Robert,
> >
> > I think part of the reason ntp and dhcpclient aren't getting network
> > connections at boot is because they are set at S03 in init and wicd is
> set
> > at S06 and is last to get going. It appears that eth0 is not coming up
> until
> > wicd loads?
>
> Correct, wicd set's up eth0, that's how we got the 11-12 second bootup
> time. Otherwise if eth0 is handled by /etc/network/interfaces bootup
> could last 2 minutes for users who don't connect eth0.  I should
> atleast really move ntp from S03 to S06..


@Robert

There's no need to pull in wicd to solve this; all you need to do is to
replace "auto eth0" with "allow-hotplug eth0" (not both) in
"/etc/network/interfaces".  This gives you eth0 at boot if it's plugged in
but it doesn't wait if it's not, and if you plug it in later it comes right
up.  Oddly it doesn't even wait very long if it's plugged in at start-up
and there is no dhcp being offered.  (all of this is assuming "iface eth0
inet dhcp" is in there too;  I imagine a static route comes up right away
regardless.)

Cheers.

-- 
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] DTO pinmux settings are not applying

[matt . linaberry]

Hi guys.

I need some help with my device tree overlay.  I'm trying to change the pin 
mux settings on pins 7 thru 10 on the P8 header to pull down so they can be 
used at outputs.  I'm putting these in a separate group in my DTO, but it's 
not showing up in /sys/kernel/debug/pinctrl/44e10800.pinmux/pingroups, nor 
do the settings show up differently in 
/sys/kernel/debug/pinctrl/44e10800.pinmux/pins. 
 

The relevant sections of the DTO:

/dts-v1/;
/plugin/;

/ {
compatible = "ti,beaglebone", "ti,beaglebone-black";

/* identification */
part-number = "BB-BONELT-WEICS";
version = "00A0";

/* state the resources this cape uses */
exclusive-use =
/* the pin header uses */
"P8.07",
"P8.08",
"P8.09",
"P8.10",
.
.
.

fragment@0 {
target = <&am33xx_pinmux>;
__overlay__ {
weics_override_pins: pinmux_weics_override_pins {
pinctrl-single,pins = <
0x090 0x27 /* P8_07 */
0x094 0x27 /* P8_08 */
0x09c 0x27 /* P8_09 */
0x098 0x27 /* P8_10 */
>;
}; 
.
.
.

fragment@3 {
target = <&ocp>;

__overlay__ {
/* avoid stupid warning */
#address-cells = <1>;
#size-cells = <1>;
 weics_override_helper: helper {
compatible = "weics-override-helper";
pinctrl-names="default"; 
pinctrl-0 = <&weics_override_pins>;
status="okay"; 
};
.
.
.

};

Two things to note:
1:  The rest of this DTO does work.  I have an LCD panel as part of the DTO 
which will adjust its viewable resolution to whatever is set in the panel's 
node of the DTO.

2:  We are not using the cape manager in order to optimize the BBB's boot 
time.  I'm working with an Angstrom build someone else compiled, so I'm not 
certain (yet) how this DTO is loaded.  

My questions are this:  Is there anything else that needs to be added to 
this DTO to get the new pin mux settings applied correctly for these four 
pins?  

Am I missing in the SRM documentation somewhere these pins can't be muxed 
to something different?  

Apologies if something doesn't make sense in my post...  I'm still quite a 
newbie to device tree overlays.

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.

Re: [beagleboard] BeagleBone Black powers down when AC adapter is removed while the USB is connected.

[Gerald Coley]

Then the SW needs to be changed to change that behavior.

Gerald


On Tue, Nov 18, 2014 at 10:37 AM, David Hirst  wrote:

> The fact that it powers down is a problem to me, if for instance a slight
> power interruption occurs ( lets say 5 seconds) during which time the CPU
> is powered by the battery backup I would like to carry on running, if its
> longer then I would like to make the decision when to shutdown.
> As it stands now I have no option but to have the system power down.
> With the current implementation In the event of a small interruption, the
> system will start to power down but if that the power has now returned
> prior to the shutdown occurring  the system needs intervention to power
> back up, by power cycling either the USB or AC. I want to smooth out short
> power cycles and let the long power outages re-power the board when the
> power returns
>
>
> On Monday, November 17, 2014 10:04:21 AM UTC-5, Gerald wrote:
>>
>> That should be bale to be fixed by changing the behavior of the SW. You
>> can look at the datasheet for the TPS65217C to see what registers to change.
>>
>> Gerald
>>
>> On Mon, Nov 17, 2014 at 8:58 AM, Michel Gerin  wrote:
>>
>>> Attn Gerald Coley,
>>>
>>> Hello,
>>> In order to avoid any misunderstanding, I wrote "I had a similar
>>> problem". But I didn't use the USB connection.
>>> Only 5V DC and battery were connected to the BBB.
>>> As soon as 5V DC PS was off, the Debian LXDE version was shutting down
>>> but a warning was appearing telling the user the system was shutting down
>>> within 60s if this procedure wasn't canceled.
>>> Maybe David Hirst's problem is related to the same software "mecanism".
>>>
>>> Kind regards
>>>
>>> Michel.
>>>
>>>
>>> 2014-11-17 12:31 GMT+01:00 Gerald Coley :
>>>
 Interesting. Sounds like something I need to get fixed.

 Gerald


 On Monday, November 17, 2014, Michel Gerin  wrote:

> Hello,
> I had a similar problem. David mentions perhaps this thread:
>
> https://mail.google.com/mail/u/0/?tab=wm#inbox/149198bbf7826f64
>
> Bremenpl suggested to use the debian console version instead of the
> LXDE version. It solved my problem.
>
> We just encontered a 2 hours mains power outage this saterday.The BBB
> went on running flawless with the battery backup.
>
> Michel
>
> 2014-11-17 1:09 GMT+01:00 David Funk :
>
>> There is a previous thread, several weeks ago about this same
>> behavior. That thread involved an application that ran off mains but had
>> battery backup and everytime mains failed, and 5V goes away, the BBB
>> shutdown.
>>
>> IIRC, this is a known software default behavior when the 5V goes
>> away, it is programmable and needs to be set accordingly to how the end
>> user whats it to behave.
>>
>>
>> -david
>> .
>>
>>
>> On Sun, Nov 16, 2014 at 5:52 PM, William Hermans 
>> wrote:
>>
>>> in /etc/inittab
>>>
>>>
>>>
>>>
>>>
>>> *# What to do when the power
>>> fails/returns.pf::powerwait:/etc/init.d/powerfail
>>> startpn::powerfailnow:/etc/init.d/powerfail
>>> nowpo::powerokwait:/etc/init.d/powerfail stop*
>>>
>>> You need to do some google "research" and see if this is a potential
>>> issue for you.
>>>
>>>
>>> On Sun, Nov 16, 2014 at 4:49 PM, William Hermans 
>>> wrote:
>>>
 Yeah, I doubt its the ethernet jack being plugged in and used. I
 have a TEMPER USB thermometer plugged in and running, plus ethernet, 
 and
 USB networking.

 There could be a service on these new images that monitors AC
 power, so that it issues a shutdown when this occurs. I know threre is 
 at
 least "CTRL + ALT + DEL" key press combo "event" in /etc/inittab, but 
 have
 not looked to see if there is anything else. There could also a a
 conditional systemd service potentially doing 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.
>>>
>>
>>  --
>> 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 bec

[beagleboard] Changing pinmux in DTO not working

[Matthew Linaberry]

Hi guys.
I am having problems getting pins 7 - 10 on the P8 header of the BBB to 
switch the mux settings to pull down, so I can use these pins as outputs. 
 I'm putting these pins in my device tree overlay as a separate group, but 
the new group is not showing up in 
/sys/kernel/debug/pinctrl/44e10800.pinmux/pingroups, and the mux setting is 
not changing in /sys/kernel/debug/pinctrl/44e10800.pinmux/pins. 

Here's the relevant parts of my DTO:
/dts-v1/;
/plugin/;

/ {
compatible = "ti,beaglebone", "ti,beaglebone-black";

/* identification */
part-number = "BB-BONELT-WEICS";
version = "00A0";

/* state the resources this cape uses */
exclusive-use =
/* the pin header uses */
"P8.07",
"P8.08",
"P8.09",
"P8.10",
.
.
.
fragment@0 {
target = <&am33xx_pinmux>;
__overlay__ {
weics_override_pins: pinmux_weics_override_pins {
pinctrl-single,pins = <
0x090 0x27 /* P8_07 */
0x094 0x27 /* P8_08 */
0x09c 0x27 /* P8_09 */
0x098 0x27 /* P8_10 */
>;
}; 
.
.
.
fragment@3 {
target = <&ocp>;

__overlay__ {
/* avoid stupid warning */
#address-cells = <1>;
#size-cells = <1>;
 weics_override_helper: helper {
compatible = "weics-override-helper";
pinctrl-names="default"; 
pinctrl-0 = <&weics_override_pins>;
status="okay"; 
};
.
.
.
};

Two things to note:
1:  I can confirm this DTO has configured two CAN channels and an LCD panel 
correctly, so it's indeed loading at boot time.
2:  Cape manager isn't being used in order to optimize boot time.  I didn't 
build this kernel, so I'm not sure if u-boot is configured to apply this 
particular overlay or what.

My questions is this:  Am I missing something else in my DTO to get the 
pinmux settings I want for these pins?  

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.

Re: [beagleboard] Re: Open Hardware start

[Gerald Coley]

Sounds sort of like the BeagleBone Black.

Gerald


On Tue, Nov 18, 2014 at 8:01 AM, mickeyf  wrote:

> This is not something I've looked at for many years, but I assume most
> manufactuers of microprocessors and other chips still typically publish a
> 'reference design' which is a basic board utilizing their chip, and with
> documentation explaining its features. This is a good place to start - you
> can take that design and add and subtract peripheral chips and features to
> meet your needs. They will also (hopefully) point out the quirks and
> gotchas you may need to know about that particular product.
>
> On Friday, November 14, 2014 2:12:16 PM UTC-8, fuenmayo...@gmail.com
> wrote:
>>
>> Hi, I have been working with micro-controllers for several years and I
>> have a basic knowledge on electronics, programming and computers. I want to
>> know what information (text books, whitepapers, articles) did you need to
>> design a board like Beaglebone Black from IC's? the process of designing
>> electronics boards for a SoC's like Sitara ARM Cortex-A8 processor is
>> similar to the process of designing boards for microcontrollers? How much
>> time takes to design such a 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.
>



-- 
Gerald

ger...@beagleboard.org
http://beagleboard.org/
http://circuitco.com/support/

-- 
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] GPIO Pin Numbering Confusion

[Charles Steinkuehler]

On 11/18/2014 12:31 PM, Robert Nelson wrote:
> On Tue, Nov 18, 2014 at 12:13 PM, Charles Steinkuehler
>  wrote:
>> I'm confused by the GPIO pin numbering shown on the Bone101 support page:
>>
>> http://beagleboard.org/Support/bone101
>>
>> P9 pins 28-31 are listed as GPIO_120 through GPIO_123, which seems to be
>> off by 10.  The schematic shows these as GPIO bank 3, pins 14-17, which
>> by my understanding should be:
>>
>>   ( 32 * 3 ) + 14 = 96 + 14 = 110
>>   ...to...
>>   ( 32 * 3 ) + 17 = 96 + 17 = 113
> 
> Double check against these:
> 
> https://github.com/derekmolloy/boneDeviceTree/tree/master/docs
> 
> At one time i had the equation down, but derek's eye chart works better. ;)

That shows the GPIO pin numbers to be 110-113, as I expected.  It looks
like the 120-123 numbers on the Bone101 web page graphics are incorrect.

...who gets the bug report?

-- 
Charles Steinkuehler
char...@steinkuehler.net

-- 
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] GPIO Pin Numbering Confusion

[Robert Nelson]

On Tue, Nov 18, 2014 at 12:13 PM, Charles Steinkuehler
 wrote:
> I'm confused by the GPIO pin numbering shown on the Bone101 support page:
>
> http://beagleboard.org/Support/bone101
>
> P9 pins 28-31 are listed as GPIO_120 through GPIO_123, which seems to be
> off by 10.  The schematic shows these as GPIO bank 3, pins 14-17, which
> by my understanding should be:
>
>   ( 32 * 3 ) + 14 = 96 + 14 = 110
>   ...to...
>   ( 32 * 3 ) + 17 = 96 + 17 = 113
>
> Other GPIO bank 3 pins (like P9 pin 27) are labeled as I would expect
> (GPIO3 pin 19 = GPIO_115).
>
> Is the documentation on the Bone101 page wrong, or am I confused about
> the kernel GPIO numbering scheme?
>
> Note: This all started with a bug report about pin numbers for the
> universal overlay:
>
> https://github.com/cdsteinkuehler/beaglebone-universal-io/issues/18

Double check against these:

https://github.com/derekmolloy/boneDeviceTree/tree/master/docs

At one time i had the equation down, but derek's eye chart works better. ;)

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/

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

Re: [beagleboard] Re: Controling Hardware Through Web Page problem

[Jason Kridner]

On Mon, Nov 17, 2014 at 9:23 PM, John Mladenik  wrote:
> OK I got this one, simpleLED.html to work
>
> https://gist.github.com/jadonk/f89a0f1f0ddef06777de
>
>
> once I got Ethernet connected.  But it ONLY works for USR0-USR3 and not for
> any other GPIO.  If I change the USR to p9_23 it will not toggle p9_23 does
> anyone know why?  I can toggle p9_23 using Python or js but not from the web
> page.

The current BoneScript library tries to load a device tree overlay to
enable the GPIO pin mode. That might cause it to have some delay or
not work the first time you try. The roadmap to fix this is to switch
to cape-universal. That'll be included in the next BoneScript release.

If it works directly with the BoneScript library, it should work the
same via the web interface. All the calls on the web interface are
asynchronous, however, so you might be calling them before the pinMode
completes.

>
>
> On Saturday, November 15, 2014 10:27:53 PM UTC-8, John Mladenik wrote:
>>
>> I have tried at least 6 different tutorials to turn an LED on and off
>> through a web page.   None of them work and all get one error or another.
>>
>> The most common one is right after the line
>> var socket = io.connect();
>>  Uncaught ReferenceError: io is not defined.
>>
>> I followed the instruction to install socket.io 2 or 3 times and think
>> this worked successfully.
>>
>> I did have to change the src line with socket.io.js in it to stop that
>> from getting an error and I changed it to
>>
>> > src="192.168.7.2:3000/preview/node_modules/socket.io/node_modules/socket.io-client/socket.io.js">
>> 
>>
>> I have a new Rev C Beaglebone Black running Debian.  Any suggestion or any
>> link or example I can try that can do something as simple as control a GPIO
>> from a web page?
>
> --
> 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.

[beagleboard] GPIO Pin Numbering Confusion

[Charles Steinkuehler]

I'm confused by the GPIO pin numbering shown on the Bone101 support page:

http://beagleboard.org/Support/bone101

P9 pins 28-31 are listed as GPIO_120 through GPIO_123, which seems to be
off by 10.  The schematic shows these as GPIO bank 3, pins 14-17, which
by my understanding should be:

  ( 32 * 3 ) + 14 = 96 + 14 = 110
  ...to...
  ( 32 * 3 ) + 17 = 96 + 17 = 113

Other GPIO bank 3 pins (like P9 pin 27) are labeled as I would expect
(GPIO3 pin 19 = GPIO_115).

Is the documentation on the Bone101 page wrong, or am I confused about
the kernel GPIO numbering scheme?

Note: This all started with a bug report about pin numbers for the
universal overlay:

https://github.com/cdsteinkuehler/beaglebone-universal-io/issues/18

-- 
Charles Steinkuehler
char...@steinkuehler.net

-- 
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: Controling Hardware Through Web Page problem

[Jason Kridner]

On Tue, Nov 18, 2014 at 10:04 AM, John Mladenik  wrote:
> Bottom line was that the socket IO functions did not quite work right when
> the BBB was only connected through the USB.  Once I connected through an
> Ethernet connection it all started to work.

They work just fine over USB. The problem is you aren't documenting
enough of your steps for us to tell you where you are going wrong.

>
>
> On Saturday, November 15, 2014 10:27:53 PM UTC-8, John Mladenik wrote:
>>
>> I have tried at least 6 different tutorials to turn an LED on and off
>> through a web page.   None of them work and all get one error or another.
>>
>> The most common one is right after the line
>> var socket = io.connect();
>>  Uncaught ReferenceError: io is not defined.
>>
>> I followed the instruction to install socket.io 2 or 3 times and think
>> this worked successfully.
>>
>> I did have to change the src line with socket.io.js in it to stop that
>> from getting an error and I changed it to
>>
>> > src="192.168.7.2:3000/preview/node_modules/socket.io/node_modules/socket.io-client/socket.io.js">
>> 
>>
>> I have a new Rev C Beaglebone Black running Debian.  Any suggestion or any
>> link or example I can try that can do something as simple as control a GPIO
>> from a web page?
>
> --
> 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: starterware emmc beaglebone black

[Jason Kridner]

On Tue, Nov 4, 2014 at 5:20 AM, Karl Karpfen  wrote:
> By the way: your own link contains the information that MMC is not
> supported:
> http://processors.wiki.ti.com/index.php/StarterWare_MMCSD_Driver#Features_not_supported
> ;-)

That has to do with MMC modes and support of the MMC standard. eMMC
devices are known to often support 4-bit SD mode, despite the name of
"eMMC". Honestly, I'm not just making crap up to try to attack you. I
think it sucks that StarterWare hasn't been updated for all the
features of BeagleBone Black as well, but that doesn't mean it should
be blown out of detail.

>
>
> Am Dienstag, 28. Oktober 2014 05:23:22 UTC+1 schrieb Jason Kridner:
>>
>> On Mon, Oct 27, 2014 at 5:16 AM,  wrote:
>>>
>>> Starterware does not support access to eMMC. To do that, you would have
>>> to implement MMC-support to their HSMMCSD-library in order to make MLO able
>>> to boot APPs from there.
>>
>>
>> Have you done anything to confirm what you are saying? It would be helpful
>> to say when you suspect something vs. when you know something.
>>
>> Neither the bootloader is in ROM nor the MLO app make any use of
>> Starterware, so if Starterware supports eMMC or not is irrelevant to if you
>> can boot a Starterware application from eMMC using the ROM and MLO. There's
>> no reason you couldn't skip MLO entirely unless your Staterware image is
>> particularly large. If you want to use MLO, again, there's no reason that
>> couldn't target a Starterware application.
>>
>> Also, as far as I know, MMC-support is not required to use an eMMC as it
>> should support one of the other modes.
>>
>> [1] http://processors.wiki.ti.com/index.php/StarterWare_MMCSD_Driver
>> [2] http://processors.wiki.ti.com/index.php/StarterWare_MMC
>>
>>>
>>>
>>> Am Donnerstag, 16. Oktober 2014 22:28:31 UTC+2 schrieb TheMdv18:

 Hi everybody,
 My question is, I can boot starterware examples in flash EMMC (MLO+app),
 I did this in uSD card, but  want to use the USB or Serial to flash EMMC 
 and
 boot my application.
 There is anyway to do this ?


 Thanks in advance.
>>>
>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to the Google Groups
>>> "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to beagleboard...@googlegroups.com.
>>> 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] Re: starterware emmc beaglebone black

[Jason Kridner]

On Tue, Oct 28, 2014 at 3:29 AM, Karl Karpfen  wrote:
>
> 2014-10-28 5:23 GMT+01:00 Jason Kridner :
>>
>> On Mon, Oct 27, 2014 at 5:16 AM,  wrote:
>>>
>>> Starterware does not support access to eMMC. To do that, you would have
>>> to implement MMC-support to their HSMMCSD-library in order to make MLO able
>>> to boot APPs from there.
>>
>>
>> Have you done anything to confirm what you are saying? It would be helpful
>> to say when you suspect something vs. when you know something.
>
>
> This is confirmed by TI in StarterWare support forum. Google or the search
> function at http://e2e.ti.com/support/embedded/starterware/f/790.aspx is
> your friend.

You don't need support in the library in order to BOOT. MLO can boot
applications out of eMMC just fine. How do you think we are loading
u-boot?

>
>>
>> Neither the bootloader is in ROM nor the MLO app make any use of
>> Starterware, so if Starterware supports eMMC or not is irrelevant to if you
>> can boot a Starterware application from eMMC using the ROM and MLO. There's
>> no reason you couldn't skip MLO entirely unless your Staterware image is
>> particularly large. If you want to use MLO, again, there's no reason that
>> couldn't target a Starterware application.
>>
>> Also, as far as I know, MMC-support is not required to use an eMMC as it
>> should support one of the other modes.
>
>
> No, that's not correct. The MLO that comes with Starterware

Probably better to use the MLO that is part of mainline u-boot than a
TI fork. The recent primary maintainer of u-boot works for TI and is
pretty good at bringing in support for TI devices.

> and normally is
> used to boot a Starterware-application itself bases on Starterware. So it
> depends on its (not existant) features. One of course can create an MLO as
> only application and try to put all its functionality into that MLO - then
> the CPU will be able to boot the MLO and eMMC support is not required.

Yes, that is part of what I was trying to assert. Sorry to not make
that more clear.

> But
> as soon as an separate APP is requied - e.g. because the available space for
> MLO is not enough - the MLO definitely needs to come with eMMC support.

Mainline MLO has eMMC support. It is only when the StarterWare
application ITSELF needs to access the eMMC that the StarterWare
library needs to include eMMC support.

With regards to accessing the eMMC using the StarterWare library, my
issue was with the term "MMC support". It is still my assertion that
other modes supported by the StarterWare library, like 4-bit SD mode,
should work well with eMMC devices[3], though I haven't confirmed with
the eMMC that is on BeagleBone Black.

The fix supplied in the attached diff (extracted from the forum post)
adds an 8-bit MMC mode, so it doesn't address my assertion.

>
>>
>>
>> [1] http://processors.wiki.ti.com/index.php/StarterWare_MMCSD_Driver
>> [2] http://processors.wiki.ti.com/index.php/StarterWare_MMC

[3] http://arasan.com/products/sd-emmc/emmc-4-5-device/
[4] https://www.linkedin.com/groups/SPI-mode-in-eMMC-Devices-37565.S.77338175

>>
>>>
>>>
>>> Am Donnerstag, 16. Oktober 2014 22:28:31 UTC+2 schrieb TheMdv18:

 Hi everybody,
 My question is, I can boot starterware examples in flash EMMC (MLO+app),
 I did this in uSD card, but  want to use the USB or Serial to flash EMMC 
 and
 boot my application.
 There is anyway to do this ?


 Thanks in advance.
>>>
>>> --
>>> 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 a topic in the
>> Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/beagleboard/CGxyNJFa_H8/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.co

[beagleboard] Re: Bus error on access to memory mapped GPIO[023]

[Igor Borges Tavares]

Luigi very good, I also had this problem, and your solution worked for me 
also.

But I still do not understand why it is necessary to export at least one 
pin on each port to be able to access the GPIO with mmap.
Someone can explain me?

Em terça-feira, 11 de junho de 2013 23h41min10s UTC-3, Jacek Radzikowski 
escreveu:
>
> Hello, 
>
> I'm getting bus errors whenever my program tries to access registers 
> controlling pins on GPIOs 0,2 or 3. I'm not trying to set pinmuxing, I 
> try to write to registers controlling the pins. 
> GPIO1 works fine and I can enable outputs by writing to the OE 
> register and change the values on the pins by writing to the OUT 
> register. 
>
> Here are some details of my simple test program: 
> The base addresses for the GPIO blocks are defined as follows: 
> const uint32_t gpioAddrs[] = 
> { 0x44E07000, 0x4804C000, 0x481AC000, 0x481AE000 }; 
>
> The memory blocks are mapped to process address space with the following 
> mmap: 
> gpios[i] = (uint32_t *) mmap(NULL, 0xfff, 
>  PROT_READ | PROT_WRITE, MAP_SHARED, gpioFd, 
> gpioAddrs[i]); 
>
> Printing values from OE, IN and OUT registers: 
> printf("i=%i\n",i); 
> printf("OUT[%i]=0x%08x\n",i,gpios[i][DATA_OUT_REG/4]); 
> printf("IN[%i]=0x%08x\n",i,gpios[i][DATA_IN_REG/4]); 
> printf("OE[%i]=0x%08x\n",i,gpios[i][GPIO_OE_REG/4]); 
>
> The full source is on gist: 
> https://gist.github.com/piranha32/4fd285cc8333eeb4ec39 
>
> Program works fine when 'i' is set to 1, crashes for 'i' set to 0,2 or 3. 
> Am I missing something obvious, or is this an overzealous memory 
> protection? 
>
> Board: BBBlack 
> Kernel: Linux beaglebone 3.8.13 #1 SMP Fri Jun 7 09:49:12 CEST 2013 
> armv7l GNU/Linux 
>
> thx, 
> j. 
>
>
> -- 
> Given a choice between two theories, take the one which is funnier 
>

-- 
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] BeagleBone Black powers down when AC adapter is removed while the USB is connected.

[David Hirst]

The fact that it powers down is a problem to me, if for instance a slight 
power interruption occurs ( lets say 5 seconds) during which time the CPU 
is powered by the battery backup I would like to carry on running, if its 
longer then I would like to make the decision when to shutdown. 
As it stands now I have no option but to have the system power down.
With the current implementation In the event of a small interruption, the 
system will start to power down but if that the power has now returned 
prior to the shutdown occurring  the system needs intervention to power 
back up, by power cycling either the USB or AC. I want to smooth out short 
power cycles and let the long power outages re-power the board when the 
power returns


On Monday, November 17, 2014 10:04:21 AM UTC-5, Gerald wrote:
>
> That should be bale to be fixed by changing the behavior of the SW. You 
> can look at the datasheet for the TPS65217C to see what registers to change.
>
> Gerald
>
> On Mon, Nov 17, 2014 at 8:58 AM, Michel Gerin  > wrote:
>
>> Attn Gerald Coley,
>>
>> Hello,
>> In order to avoid any misunderstanding, I wrote "I had a similar 
>> problem". But I didn't use the USB connection.
>> Only 5V DC and battery were connected to the BBB.
>> As soon as 5V DC PS was off, the Debian LXDE version was shutting down 
>> but a warning was appearing telling the user the system was shutting down 
>> within 60s if this procedure wasn't canceled.
>> Maybe David Hirst's problem is related to the same software "mecanism". 
>>
>> Kind regards
>>
>> Michel. 
>>   
>>
>> 2014-11-17 12:31 GMT+01:00 Gerald Coley > >:
>>
>>> Interesting. Sounds like something I need to get fixed.
>>>
>>> Gerald
>>>
>>>
>>> On Monday, November 17, 2014, Michel Gerin >> > wrote:
>>>
 Hello,
 I had a similar problem. David mentions perhaps this thread:

 https://mail.google.com/mail/u/0/?tab=wm#inbox/149198bbf7826f64

 Bremenpl suggested to use the debian console version instead of the 
 LXDE version. It solved my problem. 

 We just encontered a 2 hours mains power outage this saterday.The BBB 
 went on running flawless with the battery backup.

 Michel

 2014-11-17 1:09 GMT+01:00 David Funk :

> There is a previous thread, several weeks ago about this same 
> behavior. That thread involved an application that ran off mains but had 
> battery backup and everytime mains failed, and 5V goes away, the BBB 
> shutdown. 
>
> IIRC, this is a known software default behavior when the 5V goes away, 
> it is programmable and needs to be set accordingly to how the end user 
> whats it to behave.
>
>
> -david
> .
>
>
> On Sun, Nov 16, 2014 at 5:52 PM, William Hermans  
> wrote:
>
>> in /etc/inittab
>>
>>
>>
>>
>>
>> *# What to do when the power 
>> fails/returns.pf::powerwait:/etc/init.d/powerfail 
>> startpn::powerfailnow:/etc/init.d/powerfail 
>> nowpo::powerokwait:/etc/init.d/powerfail stop*
>>
>> You need to do some google "research" and see if this is a potential 
>> issue for you.
>>
>>
>> On Sun, Nov 16, 2014 at 4:49 PM, William Hermans  
>> wrote:
>>
>>> Yeah, I doubt its the ethernet jack being plugged in and used. I 
>>> have a TEMPER USB thermometer plugged in and running, plus ethernet, 
>>> and 
>>> USB networking.
>>>
>>> There could be a service on these new images that monitors AC power, 
>>> so that it issues a shutdown when this occurs. I know threre is at 
>>> least 
>>> "CTRL + ALT + DEL" key press combo "event" in /etc/inittab, but have 
>>> not 
>>> looked to see if there is anything else. There could also a a 
>>> conditional 
>>> systemd service potentially doing 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.
>>
>
>  -- 
> 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

Re: [beagleboard] Kernel Panic with eMMC flasher

[Robert Nelson]

On Tue, Nov 18, 2014 at 9:47 AM, Joe Spanier  wrote:

>
> https://rcn-ee.net/deb/testing/2014-11-11/lxde-4gb/BBB-eMMC-flasher-debian-7.7-lxde-4gb-armhf-2014-11-11-4gb.img.xz
> is the image. Im powering through USB plugged into a wall outlet. No Capes,
> just power, and HDMI.
>
> I was able to successfully flash
> https://rcn-ee.net/deb/testing/2014-11-11/console/BBB-eMMC-flasher-debian-7.7-console-armhf-2014-11-11-2gb.img.xz
> and pull up the console. There was some concern on the machinekit page that
> I was using an older boot loader but that should have fixed that I would
> think.
>
> I am for sure using a RevC with the 4g eMMC and I am pushing the boot
> button to boot from the SD.
>

Can you please retry with a 5volt DC jack. rsync really hits the
microSD/eMMC hard while flashing, thus it's fast, but any voltage ripples
can mess with the mmc devices.

Since the console image is so much smaller (200mb vs 1.7gb) we don't
normally see any mmc write errors during the flashing procedure.

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/

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

Re: [beagleboard] Kernel Panic with eMMC flasher

[evilwulfie]

Flashing while powered through USB is not recommended.


On 11/18/2014 8:47 AM, Joe Spanier wrote:
> https://rcn-ee.net/deb/testing/2014-11-11/lxde-4gb/BBB-eMMC-flasher-debian-7.7-lxde-4gb-armhf-2014-11-11-4gb.img.xz
> is the image. Im powering through USB plugged into a wall outlet. No
> Capes, just power, and HDMI. 
>
> I was able to successfully
> flash 
> https://rcn-ee.net/deb/testing/2014-11-11/console/BBB-eMMC-flasher-debian-7.7-console-armhf-2014-11-11-2gb.img.xz
> and pull up the console. There was some concern on the machinekit page
> that I was using an older boot loader but that should have fixed that
> I would think. 
>
> I am for sure using a RevC with the 4g eMMC and I am pushing the boot
> button to boot from the SD.
>
>
> On Tuesday, November 18, 2014 9:39:39 AM UTC-6, RobertCNelson wrote:
>
> Humm, that's 5 minutes into the flasher..
>
> What was the exact name of the image you flashed?
>
> How are you powering the board? any other capes attached?
>
>
>
> On Tue, Nov 18, 2014 at 9:37 AM, Joe Spanier  > wrote:
>
> 
> 
>
> 
> 
>
> Here is a screenshot of the panic 
>
> -- 
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from
> it, send an email to beagleboard...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout
> .
>
>
>
>
> -- 
> Robert Nelson
> http://www.rcn-ee.com/
>
> -- 
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google
> Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to beagleboard+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
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] Kernel Panic with eMMC flasher

[Robert Nelson]

Humm, that's 5 minutes into the flasher..

What was the exact name of the image you flashed?

How are you powering the board? any other capes attached?



On Tue, Nov 18, 2014 at 9:37 AM, Joe Spanier  wrote:

>
>> 
>>
>>
>> 
>>
>>> Here is a screenshot of the panic
>>
>>  --
> 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.
>



-- 
Robert Nelson
http://www.rcn-ee.com/

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

Re: [beagleboard] Kernel Panic with eMMC flasher

[Joe Spanier]

https://rcn-ee.net/deb/testing/2014-11-11/lxde-4gb/BBB-eMMC-flasher-debian-7.7-lxde-4gb-armhf-2014-11-11-4gb.img.xz
 
is the image. Im powering through USB plugged into a wall outlet. No Capes, 
just power, and HDMI. 

I was able to successfully 
flash 
https://rcn-ee.net/deb/testing/2014-11-11/console/BBB-eMMC-flasher-debian-7.7-console-armhf-2014-11-11-2gb.img.xz
 
and pull up the console. There was some concern on the machinekit page that 
I was using an older boot loader but that should have fixed that I would 
think. 

I am for sure using a RevC with the 4g eMMC and I am pushing the boot 
button to boot from the SD.


On Tuesday, November 18, 2014 9:39:39 AM UTC-6, RobertCNelson wrote:
>
> Humm, that's 5 minutes into the flasher..
>
> What was the exact name of the image you flashed?
>
> How are you powering the board? any other capes attached?
>
>
>
> On Tue, Nov 18, 2014 at 9:37 AM, Joe Spanier  > wrote:
>
>>
>>> 
>>>
>>>
>>> 
>>>
 Here is a screenshot of the panic 
>>>
>>>  -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Robert Nelson
> http://www.rcn-ee.com/
>  

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

Re: [beagleboard] Usb connection requirements for BeagleBone Black

[Bremenpl]

I have tested it actuially, for a proper USB enumeration the USB0_VBUS 
has to be applied.


W dniu 2014-11-18 o 15:00, bremenpl pisze:

Hello there,
I have a question regarding usb slave connection to BeagleBone Black. 
I have designed a system where I connect the D+ and D- wire from mini 
usb B connector of the BeagleBone Black to the shield board and from 
there it is put out on a USB B connector (GND too). The problem is the 
PC doesnt see BeagleBone Black when connecting through that USB. I was 
wondering- does BeagleBone Black need to see the VCC from USB to know 
that usb was connected? If yes, this is unconvinient for me, because I 
would like to prevent BeagleBone Black to be powered through USB. I am 
able to get a workaround for this using external components but I 
wonder if this is the case. I would aprichiate any help.



--
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/JVo8L6_A-N4/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.


--
Bremenpl

--
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] beagleboard Pointers

[puneetwadhawan]

Hi,
   I am starting afresh on beagleboard black. i am getting confused with so 
much information available on net. Can somebody point me to the best 
documentation/Video to get quick started. My first aim is to exercise all 
the Interface of the processor. 
   Thanks in Advance.
Thanks
Puneet

-- 
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] Size and name of FAT partition

[Robert Nelson]

On Tue, Nov 18, 2014 at 8:14 AM, Alexander Rössler
 wrote:
>
>
> Am Donnerstag, 13. November 2014 15:26:49 UTC+1 schrieb RobertCNelson:
>>
>> fat is hardcoded to 96Mb when "--beagleboard.org-production" is passed
>> to setup_sdcard.sh
>>
>>
>> https://github.com/RobertCNelson/omap-image-builder/blob/master/tools/setup_sdcard.sh#L463
>>
>> this value is copied (thru /boot/SOC.sh) and used by the flasher script:
>>
>>
>> https://github.com/RobertCNelson/boot-scripts/blob/master/tools/eMMC/init-eMMC-flasher-v3.sh#L399
>>
>> So we just need an override for boot size...
>
> I just tried changing conf_boot_endmb to 512 in the flasher script. However,
> it does not change the size of the partition when attached to a computer
> over USB. Is the value used anywhere else?

Hi Alexander,

I added the "boot/rootfs_label's" yeterday, so you have to do a git
pull on /opt/scripts/ to get those changes.

The flasher reads "/boot/SOC.sh" for partition info:

For a single partition:

boot_fstype=ext4
conf_boot_startmb=1
conf_boot_endmb=
sfdisk_fstype=0x83

For a dual partition: (fat boot, ext4 rootfs)

boot_fstype=fat
conf_boot_startmb=1
conf_boot_endmb=96
sfdisk_fstype=0xE

So for you:

boot_fstype=fat
conf_boot_startmb=1
conf_boot_endmb=512
sfdisk_fstype=0xE

boot_label=BOOTLABEL
rootfs_label=ROOTFSLABEL

I should also add an override for "ext4"... now that i think about it..

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/

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

[beagleboard] Re: Controling Hardware Through Web Page problem

[John Mladenik]

*Bottom line was that the socket IO functions did not quite work right when 
the BBB was only connected through the USB.  Once I connected through an 
Ethernet connection it all started to work.  *


On Saturday, November 15, 2014 10:27:53 PM UTC-8, John Mladenik wrote:
>
> I have tried at least 6 different tutorials to turn an LED on and off 
> through a web page.   None of them work and all get one error or another.   
>
> The most common one is right after the line
> var socket = io.connect();
>  Uncaught ReferenceError: io is not defined.   
>
> I followed the instruction to install socket.io 2 or 3 times and think 
> this worked successfully.  
>
> I did have to change the src line with socket.io.js in it to stop that 
> from getting an error and I changed it to
>
> 
>  
> 
>
> I have a new Rev C Beaglebone Black running Debian.  Any suggestion or any 
> link or example I can try that can do something as simple as control a GPIO 
> from a web page?   
>

-- 
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] installing a permanent cape

[rabelivan]

reboot=soft for a kernel parameter, *maybe*.

Hi William,
Thanks for your reply, but I am quit new to linux and I am not sure what do 
you mean by this.
would you please explain more? 

-Ramin

-- 
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] Size and name of FAT partition

[Alexander Rössler]

Am Donnerstag, 13. November 2014 15:26:49 UTC+1 schrieb RobertCNelson:
>
> fat is hardcoded to 96Mb when "--beagleboard.org-production" is passed 
> to setup_sdcard.sh 
>
>
> https://github.com/RobertCNelson/omap-image-builder/blob/master/tools/setup_sdcard.sh#L463
>  
>
> this value is copied (thru /boot/SOC.sh) and used by the flasher script: 
>
>
> https://github.com/RobertCNelson/boot-scripts/blob/master/tools/eMMC/init-eMMC-flasher-v3.sh#L399
>  
>
> So we just need an override for boot size... 
>
I just tried changing conf_boot_endmb to 512 in the flasher script. 
However,  it does not change the size of the partition when attached to a 
computer over USB. Is the value used anywhere else?

Regards
Alexander

-- 
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: Open Hardware start

[mickeyf]

This is not something I've looked at for many years, but I assume most 
manufactuers of microprocessors and other chips still typically publish a 
'reference design' which is a basic board utilizing their chip, and with 
documentation explaining its features. This is a good place to start - you 
can take that design and add and subtract peripheral chips and features to 
meet your needs. They will also (hopefully) point out the quirks and 
gotchas you may need to know about that particular product. 

On Friday, November 14, 2014 2:12:16 PM UTC-8, fuenmayo...@gmail.com wrote:
>
> Hi, I have been working with micro-controllers for several years and I 
> have a basic knowledge on electronics, programming and computers. I want to 
> know what information (text books, whitepapers, articles) did you need to 
> design a board like Beaglebone Black from IC's? the process of designing 
> electronics boards for a SoC's like Sitara ARM Cortex-A8 processor is 
> similar to the process of designing boards for microcontrollers? How much 
> time takes to design such a 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] Usb connection requirements for BeagleBone Black

[bremenpl]

Hello there,
I have a question regarding usb slave connection to BeagleBone Black. I 
have designed a system where I connect the D+ and D- wire from mini usb B 
connector of the BeagleBone Black to the shield board and from there it is 
put out on a USB B connector (GND too). The problem is the PC doesnt see 
BeagleBone Black when connecting through that USB. I was wondering- does 
BeagleBone Black need to see the VCC from USB to know that usb was 
connected? If yes, this is unconvinient for me, because I would like to 
prevent BeagleBone Black to be powered through USB. I am able to get a 
workaround for this using external components but I wonder if this is the 
case. I would aprichiate any help.


-- 
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: Leaking memory in kernel 3.8.13bone65 ?

[Micka]

Something is intriguing me,

Based on this website : http://www.tldp.org/LDP/sag/html/buffer-cache.html

In traditional UNIX systems, there is a program called *update* running in
the background which does a *sync* every 30 seconds, so it is usually not
necessary to use *sync*. Linux has an additional daemon, *bdflush*, which
does a more imperfect sync more frequently to avoid the sudden freeze due
to heavy disk I/O that *sync* sometimes causes.

Under Linux, *bdflush* is started by *update*. There is usually no reason
to worry about it, but if *bdflush* happens to die for some reason, the
kernel will warn about this, and you should start it by hand (*/sbin/update*
).
But I didn't find this program running.

pidof update => NULL
pidof bdflush => NULL

Does someone know why ? Is that normal ?

Micka,


Le Fri Nov 14 2014 at 20:10:15, William Hermans  a
écrit :

> ever == over
>
> On Fri, Nov 14, 2014 at 12:09 PM, William Hermans 
> wrote:
>
>> Yes . . . right now I have 25MB used, but if i use apt-get update &&
>> apt-get upgrade to update Debian. The system will show ever 100MB used by
>> the system, after done, and nothing else running.
>>
>> On Fri, Nov 14, 2014 at 6:48 AM, Micka  wrote:
>>
>>> I got my answer :
>>>
>>>
>>> "A running Linux system will quickly end up allocating all "free" memory
>>> to disk cache. This memory is still free because it can be reclaimed from
>>> cache and given to processes without any delay"
>>>
>>> Micka,
>>>
>>> Le Fri Nov 14 2014 at 14:04:34, Micka  a écrit :
>>>
>>> HI,


 I'm working on a beaglebone black kernel 3.8.13bone65 .


 My problem is that I don't have any program running, but the memory is
 almost full  :

 root@beaglebone:~# uname -a
 Linux beaglebone 3.8.13-bone65 #3 SMP Thu Sep 18 09:39:21 CEST 2014
 armv7l GNU/Linux


 root@beaglebone:~# free -m
  total   used   free sharedbuffers
 cached
 Mem:   496410 85  0 78
  184
 -/+ buffers/cache:146349
 Swap:0  0  0


 root@beaglebone:~# ps aux --sort -rss
 USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
 root  1094  0.2  1.4  14760  7576 ?SFeb24   7:48
 /usr/bin/python -O /usr/share/wicd/daemon/monitor.py
 root  1086  0.5  1.3  23880  6924 ?SFeb24  17:35
 /usr/bin/python -O /usr/share/wicd/daemon/wicd-daemon.py
 root   958  0.0  1.0  12484  5360 tty2 Ss+  Feb24   0:00 X
 root   680  0.0  0.6  25416  3300 ?Ssl  Feb24   0:00
 /usr/sbin/console-kit-daemon --no-daemon
 root   681  0.0  0.6  24548  3152 ?Ssl  Feb24   0:00
 /usr/lib/upower/upowerd
 root   868  0.0  0.5  21936  2744 ?Ssl  Feb24   0:00
 /usr/lib/policykit-1/polkitd --no-debug
 root 1  0.0  0.5   4496  2656 ?Ss   Feb24   0:01
 /lib/systemd/systemd
 root  4915  0.0  0.4   7860  2360 ?Ss   22:46   0:00 sshd:
 root@notty
 root  5478  0.0  0.4   7860  2360 ?Ss   23:32   0:00 sshd:
 root@notty
 root  5502  0.3  0.4   7720  2332 ?Ss   23:34   0:01 sshd:
 root@pts/0
 root   676  0.0  0.3   4600  1564 ?Ss   Feb24   0:00
 /sbin/wpa_supplicant -u -s -O /var/run/wpa_supplicant
 root   203  0.0  0.3   4404  1532 ?Ss   Feb24   0:10
 /lib/systemd/systemd-journald
 root   682  0.0  0.3  28392  1528 ?Ssl  Feb24   0:03
 /usr/sbin/rsyslogd -n -c5
 root  5505  0.0  0.2   2640  1520 pts/0Ss   23:34   0:00 -bash
 avahi  667  0.0  0.2   2760  1432 ?Ss   Feb24   0:00
 avahi-daemon: running [beaglebone.local]
 101673  0.2  0.2   2716  1424 ?Ss   Feb24   7:15
 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --sys
 root   225  0.0  0.2   2544  1416 ?Ss   Feb24   0:00
 /sbin/udevd
 root   677  0.0  0.2   2916  1264 ?Ss   Feb24   0:00
 /lib/systemd/systemd-logind
 root   978  0.0  0.2   2540  1084 ?SFeb24   0:00
 /sbin/udevd
 root   979  0.0  0.2   2540  1024 ?SFeb24   0:00
 /sbin/udevd
 root   884  0.0  0.1   5160   968 ?Ss   Feb24   0:00
 /usr/sbin/sshd
 root  5614  0.0  0.1   2484   916 pts/0R+   23:41   0:00 ps aux
 --sort -rss
 root  4918  0.0  0.1   1772   796 ?Ss   22:46   0:00
 /usr/lib/openssh/sftp-server -f LOCAL5 -l INFO
 root  5481  0.0  0.1   1772   796 ?Ss   23:32   0:00
 /usr/lib/openssh/sftp-server -f LOCAL5 -l INFO
 root   701  0.0  0.1   3344   716 tty1 Ss+  Feb24   0:00
 /sbin/agetty tty1 38400
 root   702  0.0  0.1   3164   712 ttyO0Ss+  Feb24   0:00
 /sbin/agetty -s ttyO0 115200 38400 9600
 root  

[beagleboard] Re: PRU R30 GPO mapping

[Karl Karpfen]

OK, found it...attached is a more complete pinmux-table containing the 
PRU-pins too.

Found this table in internet, I did not do all this work.

Am Dienstag, 18. November 2014 10:00:27 UTC+1 schrieb Karl Karpfen:
>
> Hi,
>
> from within the PRU it is possible to access GPOs in the normal way by 
> writing to their DATAOUT-registers in global address space.
>
> Beside of that there is a possibility to write GPOs via R30 of PRU. What I 
> do not understand: which GPOs do the R30's of PRU0 and PRU1 write to? These 
> 2x32 bit registers are less than available GPOs in the CPU, so they must be 
> mapped to a subset of GPOs somehow? So what output pins can I set this way?
>
> 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.


pru_pinmux.pdf
Description: Adobe PDF document

[beagleboard] PRU R30 GPO mapping

[Karl Karpfen]

Hi,

from within the PRU it is possible to access GPOs in the normal way by 
writing to their DATAOUT-registers in global address space.

Beside of that there is a possibility to write GPOs via R30 of PRU. What I 
do not understand: which GPOs do the R30's of PRU0 and PRU1 write to? These 
2x32 bit registers are less than available GPOs in the CPU, so they must be 
mapped to a subset of GPOs somehow? So what output pins can I set this way?

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: starterware emmc beaglebone black

[Karl Karpfen]

Please check 
out http://e2e.ti.com/support/embedded/starterware/f/790/t/272577.aspx#1344119

There somebody posted the missing MMC-code meanwhile.


Am Donnerstag, 16. Oktober 2014 22:28:31 UTC+2 schrieb TheMdv18:
>
> Hi everybody,
> My question is, I can boot starterware examples in flash EMMC (MLO+app), I 
> did this in uSD card, but  want to use the USB or Serial to flash EMMC and 
> boot my application.
> There is anyway to do this ?
>
>
> Thanks in advance.
>

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