[beagleboard] low cost BBB

[evilwulfie]

http://berryelec.net/element-14-beaglebone-black-development-board/

39$ BBB

-- 
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] Cloud9 Blank White Screen

[bisschoprick]

Sorry to reboor this thread, but the same problem occured on my Bone. I 
have been working on it locally last week and since then I can't access it 
from my laptop anymore. I'm kind of at a loss here, because I do need the 
rmote connection every once in a while. It seems that it is indeed a 
problem on the Bone itself.

I'm using a BeagleBone Black rev C, with stock Debian and cloud9. Before 
last week I had no problem what so ever... 
For the record... I do see the Cloud9 logo popping up in my (remote) 
browser for a few secs and afterwards the screen goed blank. The tab does 
show Cloud9 with the logo. Owh... and I can still access it via PuTTY, so 
it's not the connection itself.

Any idea's???

Op zaterdag 16 februari 2013 16:56:59 UTC+1 schreef William Pretty Security:
>
> I just tried with my version of Firefox and it worked fine.
>
>  
>
> My version is: 18.0.2
>
>  
>
> Hope this helps 
>
>  
>
>  
>
> *From:* beagl...@googlegroups.com  [mailto:
> beagl...@googlegroups.com ] *On Behalf Of *ahunt...@gmail.com 
> 
> *Sent:* Friday, February 15, 2013 10:34 PM
> *To:* beagl...@googlegroups.com 
> *Subject:* [beagleboard] Cloud9 Blank White Screen
>
>  
>
> Hi all,
>
> First of all, go easy on me; I am about as green to the world of 
> electronics as one can get. I am a Mechanical engineer looking to expand my 
> horizons with an imbedded robot control project. I figured I would start by 
> going through some of the BeagleBone tutorials. I've gotten the bone up and 
> running. It talks to my laptop over USB and ethernet via Putty. When I 
> navigate to 192.168.7.2, the BeagleBone 101 page loads, but when I navigate 
> to 192.168.7.2:3000, a blank white screen loads. It does, however, label 
> the tab as cloud9. 
>
> I'm pretty sure it is a problem on my PC, since I do not get the same 
> blank screen on my CAD station at work; Cloud9 loads just fine. On my 
> laptop, I get the same white screen on both FireFox and Chrome. Anybody 
> have any ideas what is causing this?
>
> Thanks,
>
> Aaron
>
> -- 
> 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/groups/opt_out.
>  
>  
>
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2013.0.2899 / Virus Database: 2639/6101 - Release Date: 02/13/13
> --
>
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2013.0.2899 / Virus Database: 2639/6101 - Release Date: 02/13/13
>

-- 
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: no acces to UART* anymore after flashing new Debian version

[glslang]

You need to edit the file to uncomment the includes for the serial devices 
(ttyO1 and so on). git status should then give you the difference of your 
edits against the repository.

On Friday, May 22, 2015 at 11:49:49 AM UTC+1, Harke Smits wrote:
>
> Thanks a lot for the pointer! Yes, I'm afraid, I need that. As a newbie I 
> was not aware that upgrading the OS was so invasive
> I followed the recipe and after:
> git status,  I get: (something like) nothing to commit.
> I could find the file am335x-boneblack.dts but then I get lost.
>
> Can someone clear me up in newbie language?
> Thanks a lot in advance! (I need serial data for my project)
> Harke
>
>
>
>  
>
> On Wed, May 20, 2015 at 11:57 PM, > wrote:
>
>> I may have misunderstood but have a look here on how to enable UARTs for 
>> Jessie.
>>
>> https://theunemployablekoder.wordpress.com/
>>
>>
>> On Wednesday, May 20, 2015 at 1:10:00 PM UTC+1, Harke Smits wrote:
>>>
>>> I recently had to re-install Debian. After some trials it flashed 
>>> correctly. But now I have no access to the UARTs anymore. Not via uEnv.txt 
>>> (located in /boot and not in /boot/uboot, for this version), nor via 
>>> Python. Both have worked fine before. Do I also need a newer version of 
>>> Adafruit, maybe? Or something else I have overlooked?
>>>
>>> I hope one of you can help me out.
>>>
>>> Cheers,
>>> Harke
>>>
>>>  -- 
>> 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/JBVNPDCavlc/unsubscribe.
>> To unsubscribe from this group and all its topics, 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] Re: Debug Linux kernel module on beagle bone

[William Hermans]

>
> *Oh that's kexec!*


Thats it ! thanks ;)

Anyway, I did want to mention perhaps this would be another option, but
basically do not know if it could be used to debug modules as well ? I
think so, but am not sure.

Anyway, some say the most effective way to debug a kernel module is by
using printk() . . . but this is something I have no personal hands on
experience with to date.

On Fri, May 22, 2015 at 1:05 PM, William Hermans  wrote:

> Anyway, this will drive me nuts ( short trip ) until I figure it out /
> remember. As it seemed like a really cool / useful / just-the-sort-of-thing
> I'd love to toy with.
>
> On Fri, May 22, 2015 at 12:53 PM, William Hermans 
> wrote:
>
>> *kdb? it's also enabled by default...  never personally used it thou..*
>>
>>
>> I do not think so, no. Someone on these groups posted about something I
>> had never heard about before, so I spent a couple hours googling and
>> reading on the subject.
>>
>> Basically, in make I believe it is an "ARCH" option, that builds the
>> kernel as a standalone executable. Which can then be run *somehow* (
>> perhaps chroot env  ) on an already running Linux. Something akin perhaps
>> to a virtual machine, without the virtual machine.
>>
>> The idea anyway, is that you could debug a misbehaving kernel, withotu
>> completely crashing the system it was running on. Also alleviating the need
>> for a remote debug system.
>>
>> On Fri, May 22, 2015 at 12:38 PM, Robert Nelson 
>> wrote:
>>
>>> On Fri, May 22, 2015 at 2:35 PM, William Hermans 
>>> wrote:
>>> > Isn't there some new fandangled way to debug the kernel by running it
>>> as an
>>> > executable. As in Linux running it's self ? For the life of me, I can
>>> not
>>> > recall the correct term . . .
>>>
>>> kdb? it's also enabled by default...  never personally used it thou..
>>>
>>> Regards,
>>>
>>> --
>>> Robert Nelson
>>> https://rcn-ee.com/
>>>
>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to beagleboard+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>

-- 
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: Bone VDD_3V3EXP Disable Issues

[Matthijs van Duin]

On 20 May 2015 at 13:55, Maximiliano O. Sonnaillon 
wrote:

> I was considering that one because it's a 3.3V logic signal. PGOOD is a
> 1.8V signal and the EN pin of U4 has a minimum of 2V to consider it high.


Ick, I completely overlooked that. So it seems there's no single simple
solution...

my cape (it's actually more like a motherboard).


Same here, that's actually why we can get away with removing U4 and tying
3v3a and 3v3b together: power-hungry stuff on our board is supplied
separately anyway. Perhaps the same could work in your case?

LDO4 is rated for 400 mA, about half of which can be consumed by eMMC +
ethernet, which leaves about 200 mA for basically just communication
between the BBB and the cape. This is really a quick back-of-envelope
estimate which will need more careful analysis of course.

Having a unified 3.3V supply on the BBB really does make things a lot
easier. If your cape uses the same supply (or one that tracks its voltage)
for its IO drivers towards the BBB, the problem of current flowing through
protection diodes due to uneven 3.3V supplies during power-up/down should
be solved entirely. You can ignore PGOOD and reset signals in that case.

The reason I'm investigating these PMIC details is that I'm using a custom
> BBB for am industrial application, and we had a couple boards (BBB and
> custom one) fail. I recently found warnings in new BBBs to avoid "damage in
> the board".https://groups.google.com/forum/#!topic/beaglebone/CKuTbHepHYE


I'm investigating the PMIC details basically to avoid similar things
happening to us ;-)  Especially since there's no way in hell our end-users
are going to perform clean shutdowns.

The quirky PMIC and the power supply structure of the BBB are both
headache-inducing material.

When I find a moment I'll be sure to post some observations on shutdown
behaviour in that thread.

-- 
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: Debug Linux kernel module on beagle bone

[William Hermans]

Anyway, this will drive me nuts ( short trip ) until I figure it out /
remember. As it seemed like a really cool / useful / just-the-sort-of-thing
I'd love to toy with.

On Fri, May 22, 2015 at 12:53 PM, William Hermans  wrote:

> *kdb? it's also enabled by default...  never personally used it thou..*
>
>
> I do not think so, no. Someone on these groups posted about something I
> had never heard about before, so I spent a couple hours googling and
> reading on the subject.
>
> Basically, in make I believe it is an "ARCH" option, that builds the
> kernel as a standalone executable. Which can then be run *somehow* (
> perhaps chroot env  ) on an already running Linux. Something akin perhaps
> to a virtual machine, without the virtual machine.
>
> The idea anyway, is that you could debug a misbehaving kernel, withotu
> completely crashing the system it was running on. Also alleviating the need
> for a remote debug system.
>
> On Fri, May 22, 2015 at 12:38 PM, Robert Nelson 
> wrote:
>
>> On Fri, May 22, 2015 at 2:35 PM, William Hermans 
>> wrote:
>> > Isn't there some new fandangled way to debug the kernel by running it
>> as an
>> > executable. As in Linux running it's self ? For the life of me, I can
>> not
>> > recall the correct term . . .
>>
>> kdb? it's also enabled by default...  never personally used it thou..
>>
>> Regards,
>>
>> --
>> Robert Nelson
>> https://rcn-ee.com/
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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: Debug Linux kernel module on beagle bone

[Robert Nelson]

On Fri, May 22, 2015 at 2:53 PM, William Hermans  wrote:

> *kdb? it's also enabled by default...  never personally used it thou..*
>
>
> I do not think so, no. Someone on these groups posted about something I
> had never heard about before, so I spent a couple hours googling and
> reading on the subject.
>
> Basically, in make I believe it is an "ARCH" option, that builds the
> kernel as a standalone executable. Which can then be run *somehow* (
> perhaps chroot env  ) on an already running Linux. Something akin perhaps
> to a virtual machine, without the virtual machine.
>
> The idea anyway, is that you could debug a misbehaving kernel, withotu
> completely crashing the system it was running on. Also alleviating the need
> for a remote debug system.
>

Oh that's kexec!

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

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

Re: [beagleboard] Re: Debug Linux kernel module on beagle bone

[William Hermans]

>
> *kdb? it's also enabled by default...  never personally used it thou..*


I do not think so, no. Someone on these groups posted about something I had
never heard about before, so I spent a couple hours googling and reading on
the subject.

Basically, in make I believe it is an "ARCH" option, that builds the kernel
as a standalone executable. Which can then be run *somehow* ( perhaps
chroot env  ) on an already running Linux. Something akin perhaps to a
virtual machine, without the virtual machine.

The idea anyway, is that you could debug a misbehaving kernel, withotu
completely crashing the system it was running on. Also alleviating the need
for a remote debug system.

On Fri, May 22, 2015 at 12:38 PM, Robert Nelson 
wrote:

> On Fri, May 22, 2015 at 2:35 PM, William Hermans 
> wrote:
> > Isn't there some new fandangled way to debug the kernel by running it as
> an
> > executable. As in Linux running it's self ? For the life of me, I can not
> > recall the correct term . . .
>
> kdb? it's also enabled by default...  never personally used it thou..
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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: Debug Linux kernel module on beagle bone

[Robert Nelson]

On Fri, May 22, 2015 at 2:35 PM, William Hermans  wrote:
> Isn't there some new fandangled way to debug the kernel by running it as an
> executable. As in Linux running it's self ? For the life of me, I can not
> recall the correct term . . .

kdb? it's also enabled by default...  never personally used it thou..

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

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

Re: [beagleboard] Re: Debug Linux kernel module on beagle bone

[William Hermans]

Isn't there some new fandangled way to debug the kernel by running it as an
executable. As in Linux running it's self ? For the life of me, I can not
recall the correct term . . .

On Fri, May 22, 2015 at 11:48 AM, Robert Nelson 
wrote:

> On Fri, May 22, 2015 at 1:36 PM, rh_  wrote:
> > On Fri, 22 May 2015 08:49:31 -0500
> > Gerald Coley  wrote:
> >
> >> http://www.elinux.org/Beagleboard:BeagleBoneBlack#Optional_JTAG
> >>
> >> Gerald
> >
> > Here is a link to the part:
> > https://www.samtec.com/ftppub/cpdf/FTR-1XX-XX-XX-D-X-XX-MKT.pdf
> >
> > My soldering skills might not be up to this task. If I try it I
> > will have to convince myself that I have nothing to lose somehow.
> >
> > Oh I know, the BBB is a learning tool. Must pay my dues.
> >
> > I guess with 6 layers it would be impossible to have made the
> > locking clip option for this part work. But I wonder how stout
> > this connector will be if I am able to get it soldered on.
>
> It just wouldn't fit properly in an Altoids Tin..
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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: Debug Linux kernel module on beagle bone

[Robert Nelson]

On Fri, May 22, 2015 at 1:36 PM, rh_  wrote:
> On Fri, 22 May 2015 08:49:31 -0500
> Gerald Coley  wrote:
>
>> http://www.elinux.org/Beagleboard:BeagleBoneBlack#Optional_JTAG
>>
>> Gerald
>
> Here is a link to the part:
> https://www.samtec.com/ftppub/cpdf/FTR-1XX-XX-XX-D-X-XX-MKT.pdf
>
> My soldering skills might not be up to this task. If I try it I
> will have to convince myself that I have nothing to lose somehow.
>
> Oh I know, the BBB is a learning tool. Must pay my dues.
>
> I guess with 6 layers it would be impossible to have made the
> locking clip option for this part work. But I wonder how stout
> this connector will be if I am able to get it soldered on.

It just wouldn't fit properly in an Altoids Tin..

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

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

[beagleboard] Measure +/-10V signal with Beaglebone Black ADC inputs. IC for Voltage Translation?

[maxjaritz]

Hi,
I want to measure a signal with the range of -10V...+10V with a BeagleBone 
Black ADC input. Therefore I designed a unidirectional voltage translator 
with an op amp to bring down the voltage to the 0...1.8V input range of the 
ADC input.

Now, the thing is, that I also want to be able to switch the input range by 
software to -5V...+5V and that I want to have this kind of signal 
conditioning for all of the 7 analog input channels of the BeagleBone 
Black. Before I am designing the whole PCB, I wanted to ask if there was an 
IC that does exactly this. Unfortunately I haven't found anything on the 
web yet.

-- 
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: linux kernel as SPL or load from 1st stage

[Robert Nelson]

On Fri, May 22, 2015 at 12:58 PM, rh_  wrote:
> On Thu, 21 May 2015 14:05:01 -0500
> Robert Nelson  wrote:
>
>>
>> u-boot has mode called "falcon mode"..
>>
>> SPL -> Kernel (thus skipping u-boot.img)
>>
>> http://git.denx.de/?p=u-boot.git;a=blob;f=doc/README.falcon;hb=HEAD
>
> That is interesting. For me though there are too many landmines I
> think.
>
> I do see some other things in u-boot that may replace this but I
> might be wrong. Read about it on the u-boot list.
>
> Falcon requires uImage also.

That's not a show stopper.. (just an annoyance)

> Has anyone made it work? I can't find an instance of someone
> making it work. Maybe I haven't looked hard enough.

the am335x was one of the targets falcon mode was designed with in mind..

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

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

Re: [beagleboard] BeagleBone Black PWM on QNX OS

[acheesehead]

Here is some code from a Beagleboard (not Beaglebone) the register bases 
and pin configs will be different, but it should give you an idea of how to 
control a PWM using QNX. It is *not* a driver in the QNX sense, but a 
low-level approach.

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define PG_SZ 0x1000
#define PAD_CONF_BASE 0x48002000
#define PAD_CTRL_G130_131 0x158 /* 131U 130L */
#define PAD_CTRL_G132_133 0x15c /* 133U 132L */
#define PAD_CTRL_G134_135 0x160 /* 135U 134L */
#define PAD_CTRL_G136_137 0x164 /* 137U 136L */
#define PAD_CTRL_G138_139 0x168 /* 139U 138L */
#define PWM_PAD_9 0x174 /* lwr */
#define PWM_PAD_10 0x174 /* upr */
#define PWM_PAD_11 0x178 /* lwr */

#define PAD_MODE1 1
#define PAD_MODE2 2
#define PAD_MODE4 4
#define PAD_PU_EN (1<<3)
#define PAD_PU_UP 16

#define PAD_INPUTENABLE (1<<8)

#define GPIO5_BASE 0x49056000
#define GPIO_DATAIN 0x038
#define GPIO_OE 0x034
#define GPIO_CLEARDATAOUT 0x90
#define GPIO_SETDATAOUT 0x94

#define PER_CLK_BASE 0x48005000
#define GPIO_CLK_EN_GPIO5 (1<<16)
#define ICLK_OFFSET 0x10
#define EN_GPT9 (1<<10)
#define GPT9_CLKSEL_OFFSET 0x40
#define CLKSEL_GPT9 (1<<7)
#define CM_CLK_BASE 0x48004000
#define FCLK_ENABLE_OFFSET 0xA00
#define ICLK_ENABLE_OFFSET 0xA10
#define GPT10_CLKSEL_OFFSET 0xa40
#define EN_GPT10 (1<<11)
#define CLKSEL_GPT10 (1<<6)
#define EN_GPT11 (1<<12)
#define CLKSEL_GPT11 (1<<7)

#define TIMER_9_BASE 0x4904
#define TIMER_10_BASE 0x48086000
#define TIMER_11_BASE 0x48088000
#define TIMER_TCLR 0x24
#define TIMER_START 1
#define TIMER_AUTORELOAD 2
#define TIMER_CE (1<<6)
#define TIMER_SCPWM (1<<7)
#define TIMER_PT (1<<12)
#define TIMER_TRG (2<<10)
#define TIMER_TCCR 0x28
#define TIMER_TLDR 0x2c
#define TIMER_TMAR 0x38
#define SERVO_TLDR 0xfffc0857UL
#define SYS_CLK 1300UL
#define SERVO_STOP 0xfffc5483UL
#define SERVO_FWD  (SERVO_TLDR + SYS_CLK*0.0018)
#define SERVO_REV  (SERVO_TLDR + SYS_CLK*0.0008)
#define LEFT_SERVO_TRIM -488

#define LEFT_MOTOR 0
#define RIGHT_MOTOR 1
#define DUMP_MOTOR 2

#define MOTOR_REV -1
#define MOTOR_STOP 0
#define MOTOR_FWD 1


/* GPIO's are all mode 4
PIN Function PAD_CONF
4   GPT9_PWMEVT (left servo PWM) 0x48002174 L
10  GPT10_PWMEVT (right servo PWM) 0x48002174 U
6   GPT11_PWMEVT (dump servo PWM) 0x48002178 L
21  GPIO_130 (bucket sensor 1) 0x48002158 L
19  GPIO_131 (bucket sensor 2) 0x48002158 U
17  GPIO_132 (sensor 0) 0x4800215C L
15  GPIO_133 (sensor 1) 0x4800215C U
13  GPIO_134 (sensor 2) 0x48002160 L
11  GPIO_135 (start switch) 0x48002160 U
9   GPIO_136 (program switch 1) 0x48002164 L
7   GPIO_137 (program switch 2) 0x48002164 U
5   GPIO_138 (boot LED) 0x48002168 L
*/

/* GPIO5 starts at 128 */
#define BUCKET_SENSOR_1 2
#define BUCKET_SENSOR_2 3
#define SENSOR_GPIO(x) (x+4)
#define START_SWITCH 7
#define PROGRAM_SWITCH_1 8
#define PROGRAM_SWITCH_2 9

static uintptr_t gpio_ptr;
static uintptr_t left_servo_pwm;
static uintptr_t right_servo_pwm;
static uintptr_t dump_servo_pwm;

void init()
{
uintptr_t padconf_ptr, clk_ptr;
uint32_t tmp32;

// turn on clks to GPIO5 and PWM9
clk_ptr = mmap_device_io(PG_SZ, PER_CLK_BASE);
tmp32 = in32(clk_ptr);
out32(clk_ptr, tmp32 | GPIO_CLK_EN_GPIO5 | EN_GPT9); // fclk
tmp32 = in32(clk_ptr + ICLK_OFFSET);
out32(clk_ptr + ICLK_OFFSET, tmp32 | GPIO_CLK_EN_GPIO5 | EN_GPT9); // iclk
tmp32 = in32(clk_ptr + GPT9_CLKSEL_OFFSET);
tmp32 |= CLKSEL_GPT9;
out32(clk_ptr + GPT9_CLKSEL_OFFSET, tmp32);
munmap_device_io(clk_ptr, PG_SZ);

// turn on clks to PWM10 and PWM11
clk_ptr = mmap_device_io(PG_SZ, CM_CLK_BASE);
tmp32 = in32(clk_ptr + FCLK_ENABLE_OFFSET);
tmp32 |= EN_GPT10 | EN_GPT11;
out32(clk_ptr + FCLK_ENABLE_OFFSET, tmp32);
tmp32 = in32(clk_ptr + ICLK_ENABLE_OFFSET);
tmp32 |= EN_GPT10 | EN_GPT11;
out32(clk_ptr + ICLK_ENABLE_OFFSET, tmp32);
tmp32 = in32(clk_ptr + GPT10_CLKSEL_OFFSET);
tmp32 |= CLKSEL_GPT10 | CLKSEL_GPT11;
out32(clk_ptr + GPT10_CLKSEL_OFFSET, tmp32); // select 13 MHz clock
munmap_device_io(clk_ptr, PG_SZ);

// program the input GPIO pins
padconf_ptr = mmap_device_io(PG_SZ, PAD_CONF_BASE);
tmp32 = PAD_MODE4 | (PAD_MODE4<<16) | PAD_INPUTENABLE | 
(PAD_INPUTENABLE<<16) | PAD_PU_EN | (PAD_PU_EN<<16); // for switch inputs
out32(padconf_ptr + PAD_CTRL_G130_131, tmp32);
out32(padconf_ptr + PAD_CTRL_G136_137, tmp32);
tmp32 = PAD_MODE4 | (PAD_MODE4<<16) | PAD_INPUTENABLE | 
(PAD_INPUTENABLE<<16); // for photo sensor inputs
out32(padconf_ptr + PAD_CTRL_G132_133, tmp32);
tmp32 = PAD_MODE4 | (PAD_MODE4<<16) | PAD_INPUTENABLE | 
(PAD_INPUTENABLE<<16) | (PAD_PU_EN<<16); // for photo sensor input and run 
switch input
out32(padconf_ptr + PAD_CTRL_G134_135, tmp32);
// output BOOT LED
tmp32 = in32(padconf_ptr + PAD_CTRL_G138_139);
tmp32 &= 0x;
tmp32 |= PAD_MODE4;
out32(padconf_ptr + PAD_CTRL_G138_139, tmp32);
// PWM pins
tmp32 = PAD_MODE2 | (PAD_MODE2 << 16);
out32(padconf_ptr + PWM_PAD_9, tmp32);
tmp32 = in32(padconf_ptr + PWM_PAD_11);
tmp32 &= 0x;
tmp

[beagleboard] device tree: enable gpio in kernel 3.18

[Maxim Podbereznyy]

Hey guys!

Can anybody share a simple example how to enable any of gpio pins available
at BBB? I use kernel 3.18 and want to ass own dtsi file to the main
am335x-bone.dts file to have a few gpio pins configured as GPIO In or Out
imediately after the system boots.Tried a number of options but I don't
find files like these in /sys:

/sys/class/gpio/gpio53/value

-- 
LinkedIn - http://www.linkedin.com/in/maximpodbereznyy
Company - http://www.linkedin.com/company/mentorel
Facebook - https://www.facebook.com/mentorel.company

-- 
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] g_multi not loading at boot

[Robert Nelson]

On Fri, May 22, 2015 at 11:34 AM, Iñigo Martínez
 wrote:
>
> Thank you Robert for your fast answer,
>
> And how does the official scripts manage to avoid the race condition ?
>
> I have been looking at generic-boot-script.sh that is loaded at init and to
> am335x_evm.sh (after loading SOC.sh). I tried to replicate the same
> behaviour but just writing a replacemente service file for
> generic-boot-script,calling directly to the beaglebone-black-g-ether-load.sh
> script. I'm using the same ti kernel from your repository.
>
> I tried adding musb_hdrc on the initramfs, but i'm no sure if it's the
> correct way to go. I'm still trying to learn how all the boot process works.

Easy...

https://github.com/RobertCNelson/ti-linux-kernel-dev/commit/91b44dd618b6a4f0d44aa00a18e6195292fd4c0d

moved CONFIG_USB_MUSB_HDRC to be built-in..

Regards,


-- 
Robert Nelson
https://rcn-ee.com/

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

Re: [beagleboard] g_multi not loading at boot

[Iñigo Martínez]

Thank you Robert for your fast answer,

And how does the official scripts manage to avoid the race condition ?

I have been looking at generic-boot-script.sh that is loaded at init and to 
am335x_evm.sh (after loading SOC.sh). I tried to replicate the same 
behaviour but just writing a replacemente service file for 
generic-boot-script,calling directly to the beaglebone-black-g-ether-load.sh 
script. I'm using the same ti kernel from your repository.

I tried adding musb_hdrc on the initramfs, but i'm no sure if it's the 
correct way to go. I'm still trying to learn how all the boot process works.

Best regards,

On Friday, May 22, 2015 at 2:54:43 PM UTC+2, RobertCNelson wrote:
>
> On Fri, May 22, 2015 at 6:01 AM, Iñigo Martínez  > wrote: 
> > 
> > Hi, 
> > 
> > I have installed a custom Debian using the steps on eewiki. I have 
> > downloaded the beaglebone-black-g-ether-load.sh script to load g_ether, 
> and 
> > finally I have created a systemd service to load it as follows: 
> > 
> > [Unit] 
> > Description=Generic BeagleBone Black at boot time 
> > Requires=systemd-journald.socket basic.target 
> > After=local-fs.target systemd-journald.socket basic.target 
> > 
> > [Service] 
> > Type=simple 
> > ExecStart=/opt/scripts/beaglebone-black-g-ether-load.sh 
> > StandardOutput=journal 
> > Restart=no 
> > 
> > [Install] 
> > WantedBy=multi-user.target 
> > 
> > When booting the service outputs an error when loading the g_multi 
> module: 
> > 
> > may 22 12:54:57 beaglebone beaglebone-black-g-ether-load.sh[185]: 
> cpsw.0: 
> > 7C:66:9D:46:4B:43 
> > may 22 12:54:57 beaglebone beaglebone-black-g-ether-load.sh[185]: 
> cpsw.1: 
> > 7C:66:9D:46:4B:45 
> > may 22 12:54:57 beaglebone beaglebone-black-g-ether-load.sh[185]: 
> modprobe: 
> > ERROR: could not insert 'g_multi': No such device 
> > 
> > I have seen that there is another discussion related to this problem, 
> but 
> > the difference in this case is that it load after login in the system 
> and 
> > executing the script by hand. 
> > 
> > I can't figure out what is the difference between both cases and why it 
> > doesn't work on boot. 
> > 
> > More information: 
> > 
> > root@beaglebone:~# printenv 
> > XDG_SESSION_ID=1 
> > TERM=xterm 
> > SHELL=/bin/bash 
> > USER=root 
> > MAIL=/var/mail/root 
> > PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin 
> > PWD=/root 
> > LANG=en_US.UTF-8 
> > SHLVL=1 
> > HOME=/root 
> > LOGNAME=root 
> > XDG_RUNTIME_DIR=/run/user/0 
> > _=/usr/bin/printenv 
> > 
> > Modules before loading: 
> > 
> > root@beaglebone:~# lsmod 
> > Module  Size  Used by 
> > musb_dsps   8465  0 
> > musb_hdrc  76896  1 musb_dsps 
> > pruss_remoteproc   12702  0 
> > ti_am335x_adc   4766  0 
> > kfifo_buf   1941  1 ti_am335x_adc 
> > industrialio   34965  2 ti_am335x_adc,kfifo_buf 
> > musb_am335x 1075  0 
> > uio_pdrv_genirq 2824  0 
> > uio 7008  1 uio_pdrv_genirq 
> > usb_f_mass_storage 34731  0 
> > usb_f_rndis17807  0 
> > u_ether 9436  1 usb_f_rndis 
> > libcomposite   38883  2 usb_f_rndis,usb_f_mass_storage 
> > 
> > And after loading: 
> > 
> > root@beaglebone:/opt/scripts# lsmod 
> > Module  Size  Used by 
> > usb_f_acm   5695  1 
> > u_serial9655  1 usb_f_acm 
> > usb_f_ecm   7901  1 
> > g_multi 3226  0 
> > musb_dsps   8465  0 
> > musb_hdrc  76896  1 musb_dsps 
> > pruss_remoteproc   12702  0 
> > ti_am335x_adc   4766  0 
> > kfifo_buf   1941  1 ti_am335x_adc 
> > industrialio   34965  2 ti_am335x_adc,kfifo_buf 
> > musb_am335x 1075  0 
> > uio_pdrv_genirq 2824  0 
> > uio 7008  1 uio_pdrv_genirq 
> > usb_f_mass_storage 34731  2 g_multi 
> > usb_f_rndis17807  2 g_multi 
> > u_ether 9436  3 usb_f_ecm,usb_f_rndis,g_multi 
> > libcomposite   38883  5 
> > usb_f_acm,usb_f_ecm,usb_f_rndis,g_multi,usb_f_mass_storage 
> > 
> > Any idea why this is happening ? 
>
> Yeap, you have a race condition between: 
>
> musb_hdrc & g_multi 
>
> The easy fix is to build-in musb_hdrc. 
>
> Otherwise verify musb_hdrc has been loaded before you modprobe g_multi 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

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

Re: [beagleboard] Future of BeagleBone (Black)?

[William Hermans]

>
> *OK but it is capable to be used for commercial/industrial purposes - so
> why should't it be used for that? Farnell, RS and I think Specialcomp too
> sell them by thousands - all to commercial customers. So I don't see a good
> reason why it should not be used for that - just because _initially_ it was
> planned to be used for hobbyists only?*


I think you're missing a key point here. No one as far as I know is saying
the beaglebone black can not be used in a commercial product. Once someone
buys a board it is theirs to do with as they wish.

What I've been saying is that whoever does use the beagelbone black in a
product assumes full responsibility for doing so. Support ? Availability? -
Everything. All their problem from that point forward. As it should be.

Does this mean no one would try to help at all ? I would think if someone
could help - they would. Out of good will. But legally, or even morally
there is no obligation. As the board is not sold as, or priced as a
commercial product.

One thing I am a little unclear on: Is *if* the board is even allowed to
bear the beaglebone logo at this point. I think not, but maybe I'm wrong?

On Fri, May 22, 2015 at 5:22 AM, Gerald Coley 
wrote:

> Blame does happen. Not sure why, but it does.
>
> Gerald
>
>
> On Fri, May 22, 2015 at 2:06 AM, Karl Karpfen 
> wrote:
>
>>
>> Am Freitag, 22. Mai 2015 07:25:40 UTC+2 schrieb Mickae1:
>>>
>>> As everyone said, use the beaglebone black as you want ! But don't blame
>>> the community if there is problems of availability or compatibility in the
>>> future !
>>>


>> TI states the AM335X will be available for >9 years, Gerald states the
>> BBB will be available for >5 years, the hardware is open so that everyone
>> is able to manufacture an own board - so why should someone be blamed for
>> something?
>>
>>
>>  --
>> 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/
>
> --
> 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] What is a good tool to capture flash chip R/W requests in Debain?

[mlotfi13]

Hi
I need to make some trace file that captures the the flash chip access in 
BBB. Is there any appropriate tool for this job?

-- 
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] Debug Linux kernel module on beagle bone

[Gerald Coley]

http://www.elinux.org/Beagleboard:BeagleBoneBlack#Optional_JTAG

Gerald


On Fri, May 22, 2015 at 8:48 AM, Yash Jain  wrote:

> I am a beaglebone new bee,
> I wanted to debug a kernel module on beagle bone,
> I assume we can use CCS to debug code on beaglebone, I would like to know
> tools and interface required to debug kernel module on beagle bone.
>
> Regards,
> Yash.
>
> --
> 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/

-- 
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] Debug Linux kernel module on beagle bone

[Yash Jain]

I am a beaglebone new bee,
I wanted to debug a kernel module on beagle bone, 
I assume we can use CCS to debug code on beaglebone, I would like to know 
tools and interface required to debug kernel module on beagle bone.

Regards,
Yash.

-- 
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] Putty, PSCP

[p . c . s . laurie . 58]

I'm just starting with a Beaglebone Black Rev C, Cortex A8

I've got Putty working over the USB cable to my desktop XP machine, and I'm 
trying to upload files from DOS using PSCP

According to Putty, I have a working directory

root@beaglebone:~/dsp

I'd have thought this should do it:
>
> pscp %1 root@192.168.7.2/dsp
>
> but I get:: 'local to local copy not supported'
>
> If I try
>
> pscp %1 root@http://192.168.7.2/dsp 


>
> I get  'ssh_int: Host does not exist'
>
> Any clues?


Ah! Got it:

pscp  root@192.168.7.2:dsp/

I'll post this because it would have helped me.



 






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

[beagleboard] Re: beaglebone black not being detected when plugged in through USB cable

[Peter]

Have you got a 5V power supply? I found that although a USB connection lit 
up all the lights, it didn't work properly until I connected the 5V power 
supply.

On Friday, 15 May 2015 12:12:08 UTC+1, Mehreen wrote:
>
> I have Windows 7 and Ubuntu 14.04 on VM installed on my computer. I have 
> successfully established a ssh communication between my Beaglebone Black 
> Element 14 Rev C and computer. I was recently trying to install Python 
> library from adafruit's website from their tutorials. The library was to 
> help the user to access the GIOPs and generate PWM. 
>
> Today when I plug my beaglebone into my computer using USB cable, the 
> beagle is not recognized/detected by the computer. I tried different 
> computers and different cables. The current cable is working fine. The 
> Beaglebone Black is even powered up and flashes its LEDS in the normal 
> progression like it should but it is just not being detected by the 
> computer. 
>
> Is it something to do with the hardware? Can this issue be solved? 
>
> I will appreciate your 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] g_multi not loading at boot

[Robert Nelson]

On Fri, May 22, 2015 at 6:01 AM, Iñigo Martínez  wrote:
>
> Hi,
>
> I have installed a custom Debian using the steps on eewiki. I have
> downloaded the beaglebone-black-g-ether-load.sh script to load g_ether, and
> finally I have created a systemd service to load it as follows:
>
> [Unit]
> Description=Generic BeagleBone Black at boot time
> Requires=systemd-journald.socket basic.target
> After=local-fs.target systemd-journald.socket basic.target
>
> [Service]
> Type=simple
> ExecStart=/opt/scripts/beaglebone-black-g-ether-load.sh
> StandardOutput=journal
> Restart=no
>
> [Install]
> WantedBy=multi-user.target
>
> When booting the service outputs an error when loading the g_multi module:
>
> may 22 12:54:57 beaglebone beaglebone-black-g-ether-load.sh[185]: cpsw.0:
> 7C:66:9D:46:4B:43
> may 22 12:54:57 beaglebone beaglebone-black-g-ether-load.sh[185]: cpsw.1:
> 7C:66:9D:46:4B:45
> may 22 12:54:57 beaglebone beaglebone-black-g-ether-load.sh[185]: modprobe:
> ERROR: could not insert 'g_multi': No such device
>
> I have seen that there is another discussion related to this problem, but
> the difference in this case is that it load after login in the system and
> executing the script by hand.
>
> I can't figure out what is the difference between both cases and why it
> doesn't work on boot.
>
> More information:
>
> root@beaglebone:~# printenv
> XDG_SESSION_ID=1
> TERM=xterm
> SHELL=/bin/bash
> USER=root
> MAIL=/var/mail/root
> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
> PWD=/root
> LANG=en_US.UTF-8
> SHLVL=1
> HOME=/root
> LOGNAME=root
> XDG_RUNTIME_DIR=/run/user/0
> _=/usr/bin/printenv
>
> Modules before loading:
>
> root@beaglebone:~# lsmod
> Module  Size  Used by
> musb_dsps   8465  0
> musb_hdrc  76896  1 musb_dsps
> pruss_remoteproc   12702  0
> ti_am335x_adc   4766  0
> kfifo_buf   1941  1 ti_am335x_adc
> industrialio   34965  2 ti_am335x_adc,kfifo_buf
> musb_am335x 1075  0
> uio_pdrv_genirq 2824  0
> uio 7008  1 uio_pdrv_genirq
> usb_f_mass_storage 34731  0
> usb_f_rndis17807  0
> u_ether 9436  1 usb_f_rndis
> libcomposite   38883  2 usb_f_rndis,usb_f_mass_storage
>
> And after loading:
>
> root@beaglebone:/opt/scripts# lsmod
> Module  Size  Used by
> usb_f_acm   5695  1
> u_serial9655  1 usb_f_acm
> usb_f_ecm   7901  1
> g_multi 3226  0
> musb_dsps   8465  0
> musb_hdrc  76896  1 musb_dsps
> pruss_remoteproc   12702  0
> ti_am335x_adc   4766  0
> kfifo_buf   1941  1 ti_am335x_adc
> industrialio   34965  2 ti_am335x_adc,kfifo_buf
> musb_am335x 1075  0
> uio_pdrv_genirq 2824  0
> uio 7008  1 uio_pdrv_genirq
> usb_f_mass_storage 34731  2 g_multi
> usb_f_rndis17807  2 g_multi
> u_ether 9436  3 usb_f_ecm,usb_f_rndis,g_multi
> libcomposite   38883  5
> usb_f_acm,usb_f_ecm,usb_f_rndis,g_multi,usb_f_mass_storage
>
> Any idea why this is happening ?

Yeap, you have a race condition between:

musb_hdrc & g_multi

The easy fix is to build-in musb_hdrc.

Otherwise verify musb_hdrc has been loaded before you modprobe g_multi

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

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

Re: [beagleboard] Future of BeagleBone (Black)?

[Gerald Coley]

Blame does happen. Not sure why, but it does.

Gerald


On Fri, May 22, 2015 at 2:06 AM, Karl Karpfen 
wrote:

>
> Am Freitag, 22. Mai 2015 07:25:40 UTC+2 schrieb Mickae1:
>>
>> As everyone said, use the beaglebone black as you want ! But don't blame
>> the community if there is problems of availability or compatibility in the
>> future !
>>
>>>
>>>
> TI states the AM335X will be available for >9 years, Gerald states the BBB
> will be available for >5 years, the hardware is open so that everyone is
> able to manufacture an own board - so why should someone be blamed for
> something?
>
>
>  --
> 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/

-- 
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] g_multi not loading at boot

[Iñigo Martínez]

Hi,

I have installed a custom Debian using the steps on eewiki 
. I have downloaded 
the beaglebone-black-g-ether-load.sh 

 
script to load g_ether, and finally I have created a systemd service to 
load it as follows:

[Unit]
Description=Generic BeagleBone Black at boot time
Requires=systemd-journald.socket basic.target
After=local-fs.target systemd-journald.socket basic.target

[Service]
Type=simple
ExecStart=/opt/scripts/beaglebone-black-g-ether-load.sh
StandardOutput=journal
Restart=no

[Install]
WantedBy=multi-user.target

When booting the service outputs an error when loading the g_multi module:

may 22 12:54:57 beaglebone beaglebone-black-g-ether-load.sh[185]: cpsw.0: 
7C:66:9D:46:4B:43
may 22 12:54:57 beaglebone beaglebone-black-g-ether-load.sh[185]: cpsw.1: 
7C:66:9D:46:4B:45
may 22 12:54:57 beaglebone beaglebone-black-g-ether-load.sh[185]: modprobe: 
ERROR: could not insert 'g_multi': No such device

I have seen that there is another discussion 

 
related to this problem, but the difference in this case is that it load 
after login in the system and executing the script by hand.

I can't figure out what is the difference between both cases and why it 
doesn't work on boot.

More information:

root@beaglebone:~# printenv 
XDG_SESSION_ID=1
TERM=xterm
SHELL=/bin/bash
USER=root
MAIL=/var/mail/root
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/root
LANG=en_US.UTF-8
SHLVL=1
HOME=/root
LOGNAME=root
XDG_RUNTIME_DIR=/run/user/0
_=/usr/bin/printenv

Modules before loading:

root@beaglebone:~# lsmod
Module  Size  Used by
musb_dsps   8465  0 
musb_hdrc  76896  1 musb_dsps
pruss_remoteproc   12702  0 
ti_am335x_adc   4766  0 
kfifo_buf   1941  1 ti_am335x_adc
industrialio   34965  2 ti_am335x_adc,kfifo_buf
musb_am335x 1075  0 
uio_pdrv_genirq 2824  0 
uio 7008  1 uio_pdrv_genirq
usb_f_mass_storage 34731  0 
usb_f_rndis17807  0 
u_ether 9436  1 usb_f_rndis
libcomposite   38883  2 usb_f_rndis,usb_f_mass_storage

And after loading:

root@beaglebone:/opt/scripts# lsmod
Module  Size  Used by
usb_f_acm   5695  1 
u_serial9655  1 usb_f_acm
usb_f_ecm   7901  1 
g_multi 3226  0 
musb_dsps   8465  0 
musb_hdrc  76896  1 musb_dsps
pruss_remoteproc   12702  0 
ti_am335x_adc   4766  0 
kfifo_buf   1941  1 ti_am335x_adc
industrialio   34965  2 ti_am335x_adc,kfifo_buf
musb_am335x 1075  0 
uio_pdrv_genirq 2824  0 
uio 7008  1 uio_pdrv_genirq
usb_f_mass_storage 34731  2 g_multi
usb_f_rndis17807  2 g_multi
u_ether 9436  3 usb_f_ecm,usb_f_rndis,g_multi
libcomposite   38883  5 
usb_f_acm,usb_f_ecm,usb_f_rndis,g_multi,usb_f_mass_storage

Any idea why this is happening ?

-- 
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: no acces to UART* anymore after flashing new Debian version

[Harke Smits]

Thanks a lot for the pointer! Yes, I'm afraid, I need that. As a newbie I
was not aware that upgrading the OS was so invasive
I followed the recipe and after:
git status,  I get: (something like) nothing to commit.
I could find the file am335x-boneblack.dts but then I get lost.

Can someone clear me up in newbie language?
Thanks a lot in advance! (I need serial data for my project)
Harke





On Wed, May 20, 2015 at 11:57 PM,  wrote:

> I may have misunderstood but have a look here on how to enable UARTs for
> Jessie.
>
> https://theunemployablekoder.wordpress.com/
>
>
> On Wednesday, May 20, 2015 at 1:10:00 PM UTC+1, Harke Smits wrote:
>>
>> I recently had to re-install Debian. After some trials it flashed
>> correctly. But now I have no access to the UARTs anymore. Not via uEnv.txt
>> (located in /boot and not in /boot/uboot, for this version), nor via
>> Python. Both have worked fine before. Do I also need a newer version of
>> Adafruit, maybe? Or something else I have overlooked?
>>
>> I hope one of you can help me out.
>>
>> Cheers,
>> Harke
>>
>>  --
> 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/JBVNPDCavlc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [beagleboard] Future of BeagleBone (Black)?

[Karl Karpfen]

Am Freitag, 22. Mai 2015 07:25:40 UTC+2 schrieb Mickae1:
>
> As everyone said, use the beaglebone black as you want ! But don't blame 
> the community if there is problems of availability or compatibility in the 
> future !
>
>>
>>
TI states the AM335X will be available for >9 years, Gerald states the BBB 
will be available for >5 years, the hardware is open so that everyone is 
able to manufacture an own board - so why should someone be blamed for 
something?


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