Re: [beagleboard] TI AM335x vs. Octavio OSD3358

[acheesehead]

FYI...my contact at Octavo informed me today that the industrial version of 
the cSIP currently has a lead time of 6 weeks. They are flying off the 
shelves.

On Sunday, January 31, 2021 at 4:40:14 PM UTC-7 d...@kulp.com wrote:

>
>
> On Jan 30, 2021, at 10:36 PM, Richard Sewell  wrote:
>
> Thanks Daniel, (cool site btw!) I have headers exactly the same on my 
> prototype board set up. Do you have any automation for soldering the female 
> headers or do you hand solder them? Someone has made an automatic header 
> soldering machine which is interesting, but quite a project 
> https://hackaday.com/2015/05/05/open-source-diy-soldering-robot/ . I have 
> also heard of 'pin in paste' headers,  which would require some kind of 
> reflow process only on the edge of the board. I'm trying to avoid as many 
> manual assembly processes as possible. 
>
>
> I’ve gone two different directions with this..
>
> When volume was lower, I actually paid my 13yo son to solder them.  He 
> wanted to save up for a new composite Baseball Bat so I paid him $3 for 
> each one that he soldered.   At one point, he got good enough to do about 8 
> an hour (I can do about 9/10) so he made out pretty well.However, you 
> could use this idea and maybe find a couple enterprising high school 
> students or something that would like a socially distant work from home job 
> that could be just a couple hours a day.   Give them $3 or $4 each and 
> they’d make out really well once they got good at it.  (Assuming they have 
> the soldering station or you could loan them one or something)
>
> With higher volume, I’m just having the cape manufacturer do it.   They 
> are more than happy to solder headers on and mount them onto the capes.   
> The trick here is getting them to the board manufacturer since the PB’s 
> aren’t available everywhere or is very expensive in some locations.  Thus, 
> it kind of depends on where you have your boards made.   I’ve had bunches 
> of PB’s shipped to me, I’ve ripped them out of the retail packaging (to 
> save weight/space) and then shipped them off to manufacture.   Anyway, talk 
> to your board manufacturer. 
>
> -- 
> Daniel Kulp
> d...@kulp.com - http://dankulp.com/blog 
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/4c08436a-c177-413f-85e8-57ab7181f180n%40googlegroups.com.

Re: [beagleboard] Re: Dual Ethernet

[acheesehead]

So, I got both phys to be recognized at boot:

debian@beaglebone:~$ dmesg | grep mdio
[1.323628] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6, bus 
freq 100
[1.323645] davinci_mdio 4a101000.mdio: detected phy mask ffcf
[1.360081] libphy: 4a101000.mdio: probed
[1.360113] davinci_mdio 4a101000.mdio: phy[4]: device 4a101000.mdio:04, 
driver Atheros 8035 ethernet
[1.360121] davinci_mdio 4a101000.mdio: phy[5]: device 4a101000.mdio:05, 
driver Atheros 8035 ethernet
[   20.193934] Atheros 8035 ethernet 4a101000.mdio:04: attached PHY driver 
[Atheros 8035 ethernet] (mii_bus:phy_addr=4a101000.mdio:04, irq=POLL)

The second phy was being held in reset. Fixed that. Now, I see that the 
RGMII2 pins on the processor are in the 'sleep' configuration (mode 7). 
Also, with the TI EVM I have, the last dmesg is repeated for the second phy 
at address 5 and the pins are muxed properly. I have scoured the Internet 
to no avail to figure out why not.

All help is greatly appreciated!

On Thursday, January 14, 2021 at 7:12:38 PM UTC-7, Raymond Willis wrote:
>
> Our schematic had one more line set for the address than we thought and 
> instead of unsoldering something, we just changed the address in the 
> devicetree, and then it showed up. For our prototype we were using two 
> dp83867 phys.
> I think the second phy came up as a undefined phy device even when it 
> wasn't set correctly. That's how we knew it was there, just not right. 
> If you are only seeing one phy, it leads me to believe it's not wired 
> correctly or the phy chip is defective. You could monitor the mdio bus with 
> an oscilloscope or bus analyzer to see if anything else responds when it 
> boots. I think the phy sends an alive message during bootup. If it's not 
> getting that... something is physically wrong. 
>
> Hardware blames software, software blames hardware... :)
>
> Ray.
>
>
> Sent from Yahoo Mail on Android 
> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>
> On Thu, Jan 14, 2021 at 5:54 PM, acheesehead
> > wrote:
> Ray,
>
> Thanks for the detailed response. Greatly appreciated!
>
> What was wrong with your schematic? And how did you get it to show up in 
> dmesg? I have triple checked our schematic, the board layout and the 
> resistors on the board itself. And, yes, the phy on address 4 is detected 
> and works find. The phy on address 5 is not detected and does not work when 
> connected to a switch. I am running debian 4.19. I am rebuilding the kernel 
> with the MDIO ALIVE register overriden by a hard-coded mask of 0xffcf 
> in davinci_mdio.c. That is the value I would expect. The mask is actually 
> the inverted value of the MDIO ALIVE register. I suspect this register is 
> populated by the boot ROM. I didn't get a chance to check if this 
> modification to the davinci_mdio driver actually works on the board. Won't 
> be until Mon.
>
> Todd
> On Thursday, January 14, 2021 at 10:22:29 AM UTC-7 r.wil...@yahoo.com 
> wrote:
>
> Correct me if I'm wrong, but what your saying is only one Ethernet PHY 
> works and the other one doesn't (based on seeing in your dmesg only 4 came 
> active)? Did you connect both to an unmanaged switch and still only seen 4? 
>
> If so, it sounds like one of two things:
> 1. The one designated as address 5 on the mdio bus is the wrong device 
> address. Interestingly, I had a similar thing happen and we thought we 
> identified the address according to the schematics but wasn't working. 
> After recounting the binary numbers for the address based what lines where 
> used to create the address in the schematic, we were off. It showed up in 
> dmesg after that with the corrected mdio bus address.
>
> 2. Whenever you have two PHYS you have to do three things to get it to 
> work better. 
>  A. Remove connmanctl ($ sudo apt remove connman) This is a network 
> manager that doesn't play well with two phys unless you really know what 
> you're doing (you have to give each phy a designator for it's MAC address 
> with connmanctl). I found it's just easier to remove it from the Kernel.
>
>  B. You should define two phys in the "interfaces" file located at 
> /etc/network
>   Change this:
> #auto eth0
> #iface eth0 inet dhcp
>
>To (dhcp only): 
> auto eth0
> iface eth0 inet dhcp
>
> auto eth1
> iface eth1 inet dhcp
>
>
>  or To (static ip address):
> auto eth0
> iface eth0 inet static
> address 192.168.50.1
>  

Re: [beagleboard] TI AM335x vs. Octavio OSD3358

[acheesehead]

The board is loosely based upon the Red board. Added a second Ethernet. The 
Red is a good starting point. I have a Red that we used to evaluate. I also 
have a Blue. Not a bad board, but uses funky connectors. I do not know of a 
dev board based upon the cSIP.

On Wednesday, January 27, 2021 at 7:38:24 AM UTC-7 acheesehead wrote:

> Sorry. Can't share our design. Proprietary. No thermal issues as of yet, 
> but we are not running intensive software. I do plan on inspecting using a 
> thermal camera in real time sometime soon.
>
> On Tuesday, January 26, 2021 at 3:56:29 PM UTC-7 frank@me.com wrote:
>
>> Hi
>>
>> Are you able to share the high level design of the board. How do you deal 
>> with the heat issue
>>
>> Cheers
>>
>> frank
>>
>> On Wednesday, January 27, 2021 at 1:47:39 AM UTC+11 acheesehead wrote:
>>
>>> We have designed a board based upon the Octavo Systems cSIP, which is a 
>>> step beyond the SIP. They added eMMC, EEPROM and a MEMS oscillator. Many 
>>> layout issues go away using their solution. I have worked extensively with 
>>> the Octavo folks. Very nice people. What I understand is that the company 
>>> was founded by ex-TI people. They provide free design review services that 
>>> uncovered problems with our design. They say they will manage obsolescence 
>>> of the components inside of the cSIP. 
>>>
>>> On Tuesday, January 26, 2021 at 6:18:24 AM UTC-7 hel...@deepsoft.com 
>>> wrote:
>>>
>>>> At Tue, 26 Jan 2021 05:07:26 -0800 (PST) beagl...@googlegroups.com 
>>>> wrote: 
>>>>
>>>> > 
>>>> > 
>>>> > Thank you Robert! 
>>>> > 
>>>> > I forgot to mention that I'm looking at the BBW, but I think your 
>>>> answer 
>>>> > refers to this one as well. 
>>>> > What about the availability between both solutions? My intended 
>>>> development 
>>>> > should be for industry, where they expect very very long product 
>>>> > availability. Would a SIP be better over single components, or does 
>>>> Octavio 
>>>> > face the same problems when any part gets end of life status? 
>>>>
>>>> I don't really know. You'll have to talk to the people at TI about 
>>>> that. 
>>>>
>>>> > 
>>>> > Is the image really completely the same? No diff config in uboot or 
>>>> > somewhere else? Not easy to compare, because the pinout for both ICs 
>>>> is 
>>>> > different. 
>>>>
>>>> The stock Beagle image works without mods on either. I don't know if 
>>>> there is 
>>>> a difference in the boot loader or if the uboot srcript in the chip 
>>>> EEPPROM is 
>>>> different. If there is, there is suitable firmware included on the 
>>>> image. 
>>>>
>>>> > 
>>>> > 
>>>> > hel...@deepsoft.com schrieb am Dienstag, 26. Januar 2021 um 13:54:41 
>>>> UTC+1: 
>>>> > 
>>>> > > At Mon, 25 Jan 2021 23:15:36 -0800 (PST) beagl...@googlegroups.com 
>>>> wrote: 
>>>> > > 
>>>> > > > 
>>>> > > > 
>>>> > > > 
>>>> > > > Hello everybody, 
>>>> > > > 
>>>> > > > I'm searching the right hardware for an embedded project. One of 
>>>> the 
>>>> > > Beagle 
>>>> > > > variants is likely to be the right base to start with. Some point 
>>>> I 
>>>> > > > couldn't figure out: 
>>>> > > > 
>>>> > > > Why are some boards using the TI AM335x like BBB and others use 
>>>> the same 
>>>> > > > core, but wrapped in a Octavio SIP. I know that it already 
>>>> contains a 
>>>> > > bunch 
>>>> > > > of components board designers place next to the AM335x. But what 
>>>> are the 
>>>> > > > main reasons to choose one or the other? Price? Design 
>>>> complexity? Is it 
>>>> > > > fully software compatible on image level? 
>>>> > > > 
>>>> > > 
>>>> > > The PocketBeagle uses the Octavio SIP and the Debian images for the 
>>>> BBB 
>>>> > > work 
>>>> > > just fine on the PocketBeagle, with no compatiblity issues. I think 
>&

Re: [beagleboard] TI AM335x vs. Octavio OSD3358

[acheesehead]

Sorry. Can't share our design. Proprietary. No thermal issues as of yet, 
but we are not running intensive software. I do plan on inspecting using a 
thermal camera in real time sometime soon.

On Tuesday, January 26, 2021 at 3:56:29 PM UTC-7 frank@me.com wrote:

> Hi
>
> Are you able to share the high level design of the board. How do you deal 
> with the heat issue
>
> Cheers
>
> frank
>
> On Wednesday, January 27, 2021 at 1:47:39 AM UTC+11 acheesehead wrote:
>
>> We have designed a board based upon the Octavo Systems cSIP, which is a 
>> step beyond the SIP. They added eMMC, EEPROM and a MEMS oscillator. Many 
>> layout issues go away using their solution. I have worked extensively with 
>> the Octavo folks. Very nice people. What I understand is that the company 
>> was founded by ex-TI people. They provide free design review services that 
>> uncovered problems with our design. They say they will manage obsolescence 
>> of the components inside of the cSIP. 
>>
>> On Tuesday, January 26, 2021 at 6:18:24 AM UTC-7 hel...@deepsoft.com 
>> wrote:
>>
>>> At Tue, 26 Jan 2021 05:07:26 -0800 (PST) beagl...@googlegroups.com 
>>> wrote: 
>>>
>>> > 
>>> > 
>>> > Thank you Robert! 
>>> > 
>>> > I forgot to mention that I'm looking at the BBW, but I think your 
>>> answer 
>>> > refers to this one as well. 
>>> > What about the availability between both solutions? My intended 
>>> development 
>>> > should be for industry, where they expect very very long product 
>>> > availability. Would a SIP be better over single components, or does 
>>> Octavio 
>>> > face the same problems when any part gets end of life status? 
>>>
>>> I don't really know. You'll have to talk to the people at TI about that. 
>>>
>>> > 
>>> > Is the image really completely the same? No diff config in uboot or 
>>> > somewhere else? Not easy to compare, because the pinout for both ICs 
>>> is 
>>> > different. 
>>>
>>> The stock Beagle image works without mods on either. I don't know if 
>>> there is 
>>> a difference in the boot loader or if the uboot srcript in the chip 
>>> EEPPROM is 
>>> different. If there is, there is suitable firmware included on the 
>>> image. 
>>>
>>> > 
>>> > 
>>> > hel...@deepsoft.com schrieb am Dienstag, 26. Januar 2021 um 13:54:41 
>>> UTC+1: 
>>> > 
>>> > > At Mon, 25 Jan 2021 23:15:36 -0800 (PST) beagl...@googlegroups.com 
>>> wrote: 
>>> > > 
>>> > > > 
>>> > > > 
>>> > > > 
>>> > > > Hello everybody, 
>>> > > > 
>>> > > > I'm searching the right hardware for an embedded project. One of 
>>> the 
>>> > > Beagle 
>>> > > > variants is likely to be the right base to start with. Some point 
>>> I 
>>> > > > couldn't figure out: 
>>> > > > 
>>> > > > Why are some boards using the TI AM335x like BBB and others use 
>>> the same 
>>> > > > core, but wrapped in a Octavio SIP. I know that it already 
>>> contains a 
>>> > > bunch 
>>> > > > of components board designers place next to the AM335x. But what 
>>> are the 
>>> > > > main reasons to choose one or the other? Price? Design complexity? 
>>> Is it 
>>> > > > fully software compatible on image level? 
>>> > > > 
>>> > > 
>>> > > The PocketBeagle uses the Octavio SIP and the Debian images for the 
>>> BBB 
>>> > > work 
>>> > > just fine on the PocketBeagle, with no compatiblity issues. I think 
>>> the 
>>> > > Octavio SIP allows for a more compact board because all of the 
>>> support 
>>> > > components are incorporated into a single package. This makes for a 
>>> > > smaller 
>>> > > (and cheaper) PCB. 
>>> > > 
>>> > > -- 
>>> > > Robert Heller -- Cell: 413-658-7953 <(413)%20658-7953> 
>>> <(413)%20658-7953> GV: 978-633-5364 <(978)%20633-5364> 
>>> > > <(978)%20633-5364> 
>>> > > Deepwoods Software -- Custom Software Services 
>>> > > http://www.deepsoft.com/ -- Linux Administration Services 
>>> > > hel...@deepsoft.com -- Webhosting Services 
>>> > > 
>>> > > 
>>> > 
>>>
>>> -- 
>>> Robert Heller -- Cell: 413-658-7953 <(413)%20658-7953> GV: 978-633-5364 
>>> <(978)%20633-5364> 
>>> Deepwoods Software -- Custom Software Services 
>>> http://www.deepsoft.com/ -- Linux Administration Services 
>>> hel...@deepsoft.com -- Webhosting Services 
>>>
>>>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/76e37b1d-3846-45eb-ad6d-f89e9d658197n%40googlegroups.com.

Re: [beagleboard] TI AM335x vs. Octavio OSD3358

[acheesehead]

We have designed a board based upon the Octavo Systems cSIP, which is a 
step beyond the SIP. They added eMMC, EEPROM and a MEMS oscillator. Many 
layout issues go away using their solution. I have worked extensively with 
the Octavo folks. Very nice people. What I understand is that the company 
was founded by ex-TI people. They provide free design review services that 
uncovered problems with our design. They say they will manage obsolescence 
of the components inside of the cSIP. 

On Tuesday, January 26, 2021 at 6:18:24 AM UTC-7 hel...@deepsoft.com wrote:

> At Tue, 26 Jan 2021 05:07:26 -0800 (PST) beagl...@googlegroups.com wrote:
>
> > 
> > 
> > Thank you Robert!
> > 
> > I forgot to mention that I'm looking at the BBW, but I think your answer 
> > refers to this one as well.
> > What about the availability between both solutions? My intended 
> development 
> > should be for industry, where they expect very very long product 
> > availability. Would a SIP be better over single components, or does 
> Octavio 
> > face the same problems when any part gets end of life status?
>
> I don't really know. You'll have to talk to the people at TI about that.
>
> > 
> > Is the image really completely the same? No diff config in uboot or 
> > somewhere else? Not easy to compare, because the pinout for both ICs is 
> > different. 
>
> The stock Beagle image works without mods on either. I don't know if there 
> is 
> a difference in the boot loader or if the uboot srcript in the chip 
> EEPPROM is 
> different. If there is, there is suitable firmware included on the image.
>
> > 
> > 
> > hel...@deepsoft.com schrieb am Dienstag, 26. Januar 2021 um 13:54:41 
> UTC+1:
> > 
> > > At Mon, 25 Jan 2021 23:15:36 -0800 (PST) beagl...@googlegroups.com 
> wrote:
> > >
> > > > 
> > > > 
> > > > 
> > > > Hello everybody,
> > > > 
> > > > I'm searching the right hardware for an embedded project. One of the 
> > > Beagle 
> > > > variants is likely to be the right base to start with. Some point I 
> > > > couldn't figure out:
> > > > 
> > > > Why are some boards using the TI AM335x like BBB and others use the 
> same 
> > > > core, but wrapped in a Octavio SIP. I know that it already contains 
> a 
> > > bunch 
> > > > of components board designers place next to the AM335x. But what are 
> the 
> > > > main reasons to choose one or the other? Price? Design complexity? 
> Is it 
> > > > fully software compatible on image level? 
> > > > 
> > >
> > > The PocketBeagle uses the Octavio SIP and the Debian images for the 
> BBB 
> > > work 
> > > just fine on the PocketBeagle, with no compatiblity issues. I think 
> the 
> > > Octavio SIP allows for a more compact board because all of the support 
> > > components are incorporated into a single package. This makes for a 
> > > smaller 
> > > (and cheaper) PCB.
> > >
> > > -- 
> > > Robert Heller -- Cell: 413-658-7953 <(413)%20658-7953> 
> <(413)%20658-7953> GV: 978-633-5364 <(978)%20633-5364> 
> > > <(978)%20633-5364>
> > > Deepwoods Software -- Custom Software Services
> > > http://www.deepsoft.com/ -- Linux Administration Services
> > > hel...@deepsoft.com -- Webhosting Services
> > >
> > >
> > 
>
> -- 
> Robert Heller -- Cell: 413-658-7953 <(413)%20658-7953> GV: 978-633-5364 
> <(978)%20633-5364>
> Deepwoods Software -- Custom Software Services
> http://www.deepsoft.com/ -- Linux Administration Services
> hel...@deepsoft.com -- Webhosting Services
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/009e11dd-402f-4b7c-881d-e0afe293772cn%40googlegroups.com.

Re: [beagleboard] Re: Dual Ethernet

[acheesehead]

Ray,

Thanks for the detailed response. Greatly appreciated!

What was wrong with your schematic? And how did you get it to show up in 
dmesg? I have triple checked our schematic, the board layout and the 
resistors on the board itself. And, yes, the phy on address 4 is detected 
and works find. The phy on address 5 is not detected and does not work when 
connected to a switch. I am running debian 4.19. I am rebuilding the kernel 
with the MDIO ALIVE register overriden by a hard-coded mask of 0xffcf 
in davinci_mdio.c. That is the value I would expect. The mask is actually 
the inverted value of the MDIO ALIVE register. I suspect this register is 
populated by the boot ROM. I didn't get a chance to check if this 
modification to the davinci_mdio driver actually works on the board. Won't 
be until Mon.

Todd
On Thursday, January 14, 2021 at 10:22:29 AM UTC-7 r.wil...@yahoo.com wrote:

> Correct me if I'm wrong, but what your saying is only one Ethernet PHY 
> works and the other one doesn't (based on seeing in your dmesg only 4 came 
> active)? Did you connect both to an unmanaged switch and still only seen 4? 
>
> If so, it sounds like one of two things:
> 1. The one designated as address 5 on the mdio bus is the wrong device 
> address. Interestingly, I had a similar thing happen and we thought we 
> identified the address according to the schematics but wasn't working. 
> After recounting the binary numbers for the address based what lines where 
> used to create the address in the schematic, we were off. It showed up in 
> dmesg after that with the corrected mdio bus address.
>
> 2. Whenever you have two PHYS you have to do three things to get it to 
> work better. 
>  A. Remove connmanctl ($ sudo apt remove connman) This is a network 
> manager that doesn't play well with two phys unless you really know what 
> you're doing (you have to give each phy a designator for it's MAC address 
> with connmanctl). I found it's just easier to remove it from the Kernel.
>
>  B. You should define two phys in the "interfaces" file located at 
> /etc/network
>   Change this:
> #auto eth0
> #iface eth0 inet dhcp
>
>To (dhcp only): 
> auto eth0
> iface eth0 inet dhcp
>
> auto eth1
> iface eth1 inet dhcp
>
>
>  or To (static ip address):
> auto eth0
> iface eth0 inet static
> address 192.168.50.1
> netmask 255.255.255.0
>
> auto eth1
> iface eth1 inet static
> address 192.168.100.1   
> netmask 255.255.255.0
>
> C. This one may be the biggest issue I seen with using two phys in 
> older kernels as it will rename the second one really strange or not use it 
> at all. If using an older Kernel, check for it to have 
> /etc/udev/rules.d/70-persistent-net.rulesIf it has that file, you will 
> need to edit it to remove the renaming and usage. The devleopment prototype 
> I was working on had two PHYs and did not work correclty until I edited 
> this file then both showed up after deisgnated in the interfaces file. If 
> you need to know more about what to edit... reply and I'll help.
>
>  Regards,
> Ray
>
>
>
>
>
>
>
>
> On Thursday, January 14, 2021, 9:02:48 AM CST, acheesehead <
> achee...@gmail.com> wrote: 
>
>
> We are using a supported phy. The Atheros, just like on the TI EVM. The 
> only differences between our board and the TI EVM are that we are using an 
> oscillator to clock both phys instead of a crystal per phy and we have them 
> wired to be MDIO addresses 4 & 5 instead of 0 & 1.
>
> I appreciate any help you can provide!
>
> On Wednesday, January 13, 2021 at 8:24:56 PM UTC-7 r.wil...@yahoo.com 
> wrote:
>
> I think I can help if interested. I just finished supporting a custom 
> project that used Bone Debian. The board used two ethernet PHYs. Setting 
> everything up can be a pain. I can share what I did, but the actual PHYs 
> just happened to have configuration stuff already installed so adding to a 
> custom devicw tree was a bit simpler. 
> If using an unsupported Ethernet Chip, you may have to see if they have a 
> header file in C that can be imported into a device tree. 
>
> Ray. 
>
> Sent from Yahoo Mail on Android 
> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>
> On Tue, Jan 12, 2021 at 11:52 AM, jeff@gmail.com
>  wrote:
>
> Also, we found that it was useful for custom board issues to consu

Re: [beagleboard] Re: Dual Ethernet

[acheesehead]

We are using a supported phy. The Atheros, just like on the TI EVM. The 
only differences between our board and the TI EVM are that we are using an 
oscillator to clock both phys instead of a crystal per phy and we have them 
wired to be MDIO addresses 4 & 5 instead of 0 & 1.

I appreciate any help you can provide!

On Wednesday, January 13, 2021 at 8:24:56 PM UTC-7 r.wil...@yahoo.com wrote:

> I think I can help if interested. I just finished supporting a custom 
> project that used Bone Debian. The board used two ethernet PHYs. Setting 
> everything up can be a pain. I can share what I did, but the actual PHYs 
> just happened to have configuration stuff already installed so adding to a 
> custom devicw tree was a bit simpler. 
> If using an unsupported Ethernet Chip, you may have to see if they have a 
> header file in C that can be imported into a device tree. 
>
> Ray. 
>
> Sent from Yahoo Mail on Android 
> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>
> On Tue, Jan 12, 2021 at 11:52 AM, jeff@gmail.com
>  wrote:
>
> Also, we found that it was useful for custom board issues to consult both 
> beagleboard.org and TI-E2E, but for the latter, it was necessary to 
> switch to the TI-SDK builds as TI didn't support beagleboard/Debian builds 
> at the time..
>
> FYI,
>
>  
> On Tuesday, January 12, 2021 at 12:43:08 PM UTC-5 jeff@gmail.com 
> wrote:
>
> I have a 3 year old BB-X15 with a dual PHY at home.  I haven't touched 
> Linux for a couple of years, but am trying to pick it back up on a hobby 
> basis. We were working on a custom board with a dual PHY, but that effort 
> was put on hold a couple of year's ago.   Message me if you need me to try 
> anything on the BB-X15 which could help with your custom board.  If 
> something useful flushes out then it should be posted in public forums.
>
> On my BB-X15, I just downloaded the latest image and did dmesg|grep mdio 
> (without anything plugged into the Ethernet ports):
>
> debian@beaglebone:~$ dmesg|grep mdio
> [1.112050] davinci_mdio 48485000.mdio: davinci mdio revision 1.6, bus 
> freq 100
> [1.112061] libphy: 48485000.mdio: probed
> [1.134048] davinci_mdio 48485000.mdio: phy[1]: device 
> 48485000.mdio:01, driver Micrel KSZ9031 Gigabit PHY
> [1.134059] davinci_mdio 48485000.mdio: phy[2]: device 
> 48485000.mdio:02, driver Micrel KSZ9031 Gigabit PHY
> [6.572870] Micrel KSZ9031 Gigabit PHY 48485000.mdio:01: attached PHY 
> driver [Micrel KSZ9031 Gigabit PHY] (mii_bus:phy_addr=48485000.mdio:01, 
> irq=POLL)
> [6.710705] Micrel KSZ9031 Gigabit PHY 48485000.mdio:02: attached PHY 
> driver [Micrel KSZ9031 Gigabit PHY] (mii_bus:phy_addr=48485000.mdio:02, 
> irq=POLL)
> [   24.576701] Micrel KSZ9031 Gigabit PHY 48485000.mdio:01: attached PHY 
> driver [Micrel KSZ9031 Gigabit PHY] (mii_bus:phy_addr=48485000.mdio:01, 
> irq=POLL)
> [   24.684787] Micrel KSZ9031 Gigabit PHY 48485000.mdio:02: attached PHY 
> driver [Micrel KSZ9031 Gigabit PHY] (mii_bus:phy_addr=48485000.mdio:02, 
> irq=POLL)
> debian@beaglebone:~$ 
>
> debian@beaglebone:~$ uname -a
> Linux beaglebone 4.14.108-ti-r131 #1buster SMP PREEMPT Tue Mar 24 19:18:36 
> UTC 2020 armv7l GNU/Linux
> debian@beaglebone:~$ cat /etc/debian_version
> 10.3
>
>
> uname -r
> cat /etc/debian_version: 
>
> Thanks!
>
>
> On Friday, January 8, 2021 at 2:13:17 PM UTC-5 acheesehead wrote:
>
> I meant dmesg | grep mdio. Here is output.
> beaglebone:~$ dmesg | grep mdio
> [1.319622] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6, bus 
> freq 100
> [1.319638] davinci_mdio 4a101000.mdio: detected phy mask ffef
> [1.338962] libphy: 4a101000.mdio: probed
> [1.338993] davinci_mdio 4a101000.mdio: phy[4]: device 
> 4a101000.mdio:04, driver Atheros 8035 ethernet
> [   19.657691] Atheros 8035 ethernet 4a101000.mdio:04: attached PHY driver 
> [Atheros 8035 ethernet] (mii_bus:phy_addr=4a101000.mdio:04, irq=POLL)
>
> Relevant portions of device tree:
>
> cpsw_default: cpsw-default {
> pinctrl-single,pins = <
> /* Slave 1 */
> AM33XX_PADCONF(AM335X_PIN_MII1_TX_EN, PIN_OUTPUT_PULLDOWN, MUX_MODE2) /* 
> mii1_txen.rgmii1_tctl */
> AM33XX_PADCONF(AM335X_PIN_MII1_RX_DV, PIN_INPUT_PULLDOWN, MUX_MODE2) /* 
> mii1_rxdv.rgmii1_rctl */
> AM33XX_PADCONF(AM335X_PIN_MII1_TXD3, PIN_OUTPUT_PULLDOWN, MUX_MODE2)
> AM33XX_PADCONF(AM335X_PIN_MII1_TXD2, PIN_OUTPUT_PULLDOWN, MUX_MODE2)
> AM33XX_PADCONF(AM335X_PIN_MII1_TXD1, PIN_OUTPUT_PULLDOWN, MUX_MODE2)
> AM33XX_PADCONF(AM335X_PIN_MII1_TXD0, PIN_OUTPUT_PULLDOWN, MUX_MODE2)
> AM33XX_PADCONF(AM335X_PIN_MII1_TX_CLK

[beagleboard] Re: Dual Ethernet

[acheesehead]

I meant dmesg | grep mdio. Here is output.
beaglebone:~$ dmesg | grep mdio
[1.319622] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6, bus 
freq 100
[1.319638] davinci_mdio 4a101000.mdio: detected phy mask ffef
[1.338962] libphy: 4a101000.mdio: probed
[1.338993] davinci_mdio 4a101000.mdio: phy[4]: device 4a101000.mdio:04, 
driver Atheros 8035 ethernet
[   19.657691] Atheros 8035 ethernet 4a101000.mdio:04: attached PHY driver 
[Atheros 8035 ethernet] (mii_bus:phy_addr=4a101000.mdio:04, irq=POLL)

Relevant portions of device tree:

cpsw_default: cpsw-default {
pinctrl-single,pins = <
/* Slave 1 */
AM33XX_PADCONF(AM335X_PIN_MII1_TX_EN, PIN_OUTPUT_PULLDOWN, MUX_MODE2) /* 
mii1_txen.rgmii1_tctl */
AM33XX_PADCONF(AM335X_PIN_MII1_RX_DV, PIN_INPUT_PULLDOWN, MUX_MODE2) /* 
mii1_rxdv.rgmii1_rctl */
AM33XX_PADCONF(AM335X_PIN_MII1_TXD3, PIN_OUTPUT_PULLDOWN, MUX_MODE2)
AM33XX_PADCONF(AM335X_PIN_MII1_TXD2, PIN_OUTPUT_PULLDOWN, MUX_MODE2)
AM33XX_PADCONF(AM335X_PIN_MII1_TXD1, PIN_OUTPUT_PULLDOWN, MUX_MODE2)
AM33XX_PADCONF(AM335X_PIN_MII1_TXD0, PIN_OUTPUT_PULLDOWN, MUX_MODE2)
AM33XX_PADCONF(AM335X_PIN_MII1_TX_CLK, PIN_OUTPUT_PULLDOWN, MUX_MODE2)
AM33XX_PADCONF(AM335X_PIN_MII1_RX_CLK, PIN_INPUT_PULLDOWN, MUX_MODE2)
AM33XX_PADCONF(AM335X_PIN_MII1_RXD3, PIN_INPUT_PULLDOWN, MUX_MODE2)
AM33XX_PADCONF(AM335X_PIN_MII1_RXD2, PIN_INPUT_PULLDOWN, MUX_MODE2)
AM33XX_PADCONF(AM335X_PIN_MII1_RXD1, PIN_INPUT_PULLDOWN, MUX_MODE2)
AM33XX_PADCONF(AM335X_PIN_MII1_RXD0, PIN_INPUT_PULLDOWN, MUX_MODE2)
/* Slave 2 */
AM33XX_PADCONF(AM335X_PIN_GPMC_A0, PIN_OUTPUT_PULLDOWN, MUX_MODE2) /* 
mii2_txen.rgmii1_tctl */
AM33XX_PADCONF(AM335X_PIN_GPMC_A1, PIN_INPUT_PULLDOWN, MUX_MODE2) /* 
mii2_rxdv.rgmii1_rctl */
AM33XX_PADCONF(AM335X_PIN_GPMC_A2, PIN_OUTPUT_PULLDOWN, MUX_MODE2)
AM33XX_PADCONF(AM335X_PIN_GPMC_A3, PIN_OUTPUT_PULLDOWN, MUX_MODE2)
AM33XX_PADCONF(AM335X_PIN_GPMC_A4, PIN_OUTPUT_PULLDOWN, MUX_MODE2)
AM33XX_PADCONF(AM335X_PIN_GPMC_A5, PIN_OUTPUT_PULLDOWN, MUX_MODE2)
AM33XX_PADCONF(AM335X_PIN_GPMC_A6, PIN_OUTPUT_PULLDOWN, MUX_MODE2)
AM33XX_PADCONF(AM335X_PIN_GPMC_A7, PIN_INPUT_PULLDOWN, MUX_MODE2)
AM33XX_PADCONF(AM335X_PIN_GPMC_A8, PIN_INPUT_PULLDOWN, MUX_MODE2)
AM33XX_PADCONF(AM335X_PIN_GPMC_A9, PIN_INPUT_PULLDOWN, MUX_MODE2)
AM33XX_PADCONF(AM335X_PIN_GPMC_A10, PIN_INPUT_PULLDOWN, MUX_MODE2)
AM33XX_PADCONF(AM335X_PIN_GPMC_A11, PIN_INPUT_PULLDOWN, MUX_MODE2)
AM33XX_PADCONF(AM335X_PIN_MII1_RX_ER, PIN_OUTPUT_PULLDOWN, MUX_MODE7) /* 
reset line */
>;
};

cpsw_sleep: cpsw-sleep {
pinctrl-single,pins = <
/* Slave 1 reset value */
AM33XX_PADCONF(AM335X_PIN_MII1_TX_EN, PIN_INPUT_PULLDOWN, MUX_MODE7)
AM33XX_PADCONF(AM335X_PIN_MII1_RX_DV, PIN_INPUT_PULLDOWN, MUX_MODE7)
AM33XX_PADCONF(AM335X_PIN_MII1_TXD3, PIN_INPUT_PULLDOWN, MUX_MODE7)
AM33XX_PADCONF(AM335X_PIN_MII1_TXD2, PIN_INPUT_PULLDOWN, MUX_MODE7)
AM33XX_PADCONF(AM335X_PIN_MII1_TXD1, PIN_INPUT_PULLDOWN, MUX_MODE7)
AM33XX_PADCONF(AM335X_PIN_MII1_TXD0, PIN_INPUT_PULLDOWN, MUX_MODE7)
AM33XX_PADCONF(AM335X_PIN_MII1_TX_CLK, PIN_INPUT_PULLDOWN, MUX_MODE7)
AM33XX_PADCONF(AM335X_PIN_MII1_RX_CLK, PIN_INPUT_PULLDOWN, MUX_MODE7)
AM33XX_PADCONF(AM335X_PIN_MII1_RXD3, PIN_INPUT_PULLDOWN, MUX_MODE7)
AM33XX_PADCONF(AM335X_PIN_MII1_RXD2, PIN_INPUT_PULLDOWN, MUX_MODE7)
AM33XX_PADCONF(AM335X_PIN_MII1_RXD1, PIN_INPUT_PULLDOWN, MUX_MODE7)
AM33XX_PADCONF(AM335X_PIN_MII1_RXD0, PIN_INPUT_PULLDOWN, MUX_MODE7)
/* Slave 2 */
AM33XX_PADCONF(AM335X_PIN_GPMC_A0, PIN_INPUT_PULLDOWN, MUX_MODE7) /* 
mii2_txen.rgmii1_tctl */
AM33XX_PADCONF(AM335X_PIN_GPMC_A1, PIN_INPUT_PULLDOWN, MUX_MODE7) /* 
mii2_rxdv.rgmii1_rctl */
AM33XX_PADCONF(AM335X_PIN_GPMC_A2, PIN_INPUT_PULLDOWN, MUX_MODE7)
AM33XX_PADCONF(AM335X_PIN_GPMC_A3, PIN_INPUT_PULLDOWN, MUX_MODE7)
AM33XX_PADCONF(AM335X_PIN_GPMC_A4, PIN_INPUT_PULLDOWN, MUX_MODE7)
AM33XX_PADCONF(AM335X_PIN_GPMC_A5, PIN_INPUT_PULLDOWN, MUX_MODE7)
AM33XX_PADCONF(AM335X_PIN_GPMC_A6, PIN_INPUT_PULLDOWN, MUX_MODE7)
AM33XX_PADCONF(AM335X_PIN_GPMC_A7, PIN_INPUT_PULLDOWN, MUX_MODE7)
AM33XX_PADCONF(AM335X_PIN_GPMC_A8, PIN_INPUT_PULLDOWN, MUX_MODE7)
AM33XX_PADCONF(AM335X_PIN_GPMC_A9, PIN_INPUT_PULLDOWN, MUX_MODE7)
AM33XX_PADCONF(AM335X_PIN_GPMC_A10, PIN_INPUT_PULLDOWN, MUX_MODE7)
AM33XX_PADCONF(AM335X_PIN_GPMC_A11, PIN_INPUT_PULLDOWN, MUX_MODE7)
>;
};

 {
pinctrl-names = "default", "sleep";
pinctrl-0 = <_default>;
pinctrl-1 = <_sleep>;
dual_emac = <1>;
status = "okay";
};

_mdio {
pinctrl-names = "default", "sleep";
pinctrl-0 = <_mdio_default>;
pinctrl-1 = <_mdio_sleep>;
status = "okay";
};

_emac0 {
phy_id = <_mdio>, <4>;
phy-mode = "rgmii-txid";
dual_emac_res_vlan = <1>;
};

_emac1 {
phy_id = <_mdio>, <5>;
phy-mode = "rgmii-txid";
dual_emac_res_vlan = <2>;
};

 


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

[beagleboard] Dual Ethernet

[acheesehead]

We have a custom board based upon the BBB. Added a second phy at MDIO 
address 5. Modified device tree to mux pins and set up phys. When the board 
boots I do a grep on dmesg for mdop/ I see a mask 0xffef, when I should 
see a mask of 0xffcf. I am having trouble understanding where this mask 
comes from. According to the AM335x datasheet, the mask should be from the 
Ethernet MDIO register alive register, inverted. When does this register 
get populated?
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/a2721f4a-cb17-4725-96ab-b49b066258e9n%40googlegroups.com.

[beagleboard] Re: 4G connection for BBB - dongle or other, recommendations?

[acheesehead]

Nimbelink makes a cape that works 
well. https://nimbelink.com/products/skywire-beaglebone-black-cape/


On Friday, January 1, 2021 at 7:48:35 AM UTC-7 Chris Green wrote:

> I want to get a 4G mobile data connection for my Beaglebone Black
> (which is on a boat in France).
>
> Has anyone done this with either a USB dongle or an external 4G router
> via ethernet? I need something which can be configured to work at
> power up with no user interaction. I'd also prefer something that can
> use an external aerial as the BBB is buried in the middle of my
> (steel) boat. Of course a USB dongle can be put on the end of a USB
> extension lead and an external router can go anywhere within reason.
>
> Are there any 4G capes for BBB?
>
> Any help and information would be very welcome.
>
> -- 
> Chris Green
> ·
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/aea28cd4-330d-4707-87ed-29d62d5a21a7n%40googlegroups.com.

[beagleboard] Re: BBB RTC synchronization with NTP

[acheesehead]

Look at gPTP.

On Wednesday, July 15, 2020 at 7:29:55 AM UTC-6, jaka.k...@gmail.com wrote:
>
> Current Beaglebone Black images offer support for high resolution timers 
> in Linux kernel. They are controlled by ktime.h library and depend on 
> system's clocks (CLOCK_MONOTONIC, CLOCK_REALTIME,...). The clocks can be 
> looked up from userspace programs with commands clock_gettime 
> , clock_settime and 
> clock_getres from time.h library.
> What I would like to do is make/write a protocol in c that would 
> synchronize realtime clocks between two boards over ethernet cable 
> connection or internet. My goal is testing how accurately two clocks can be 
> set to the same global time under different protocols. I'm planning to 
> start with ntp, would using an existing library or client make sense here? 
> I read BBB sometimes comes with daemons for ntp, in that case how would I 
> set one board to act as a server in protocol?
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/1c9e5ca6-d4c8-4e4b-a5c2-bf0eaff4fb48o%40googlegroups.com.

[beagleboard] RTL88x2 Wifi/USB Adaptor

[acheesehead]

I am trying to get an AC 1200 adapter working on a BBB running Debian 9.8 
(Linux 4.9.45-ti-r57). I tried the instructions referenced here:

https://askubuntu.com/questions/1018375/how-do-i-install-driver-for-rtl88x2bu

I get this error. Anybody know how to get this device working?

Kernel preparation unnecessary for this kernel.  Skipping...

Building module:
cleaning build area...
make -j1 KERNELRELEASE=4.9.45-ti-r57 KVER=4.9.45-ti-r57 
src=/usr/src/rtl88x2bu-5.3.1(bad exit status: 2)
Error! Bad return status for module build on kernel: 4.9.45-ti-r57 (armv7l)
Consult /var/lib/dkms/rtl88x2bu/5.3.1/build/make.log for more information.
$ less 
/var/lib/dkms/rtl88x2bu/5.3.1/build/make.log78.20180430_COEX20180427-5959$
DKMS make.log for rtl88x2bu-5.3.1 for kernel 4.9.45-ti-r57 (armv7l)
Tue Mar  5 00:06:13 UTC 2019
make ARCH=armv7l CROSS_COMPILE= -C /lib/modules/4.9.45-ti-r57/build 
M=/var/lib/dkms/rtl88x2bu/5.3.1/build  modules
make[1]: Entering directory '/usr/src/linux-headers-4.9.45-ti-r57'
Makefile:628: arch/armv7l/Makefile: No such file or directory
make[1]: *** No rule to make target 'arch/armv7l/Makefile'.  Stop.
make[1]: Leaving directory '/usr/src/linux-headers-4.9.45-ti-r57'
Makefile:1995: recipe for target 'modules' failed
make: *** [modules] Error 2

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/a1c90524-95b3-43ca-913e-8e8d39fa86e5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: No SPI output when using spidev with ioctl()

[acheesehead]

Please share your uEnv and code. An output of the console during boot would 
be helpful as well. I am struggling with the same problem on the Octavo Red 
development board (a PocketBeagle with more stuff). Oscilloscope hooked up 
to SPI_CS1. No pulses when doing a transfer and the signal is low...should 
be high with no activity. I don't believe the pins are mux'd correctly. Or, 
clocks are not being provided to the peripheral. I am used to working with 
QNX using register level operations to mux the pins, turn on the clocks and 
control the SPI bus. That works. Trying out Linux at the moment as an 
experiment.

On Tuesday, February 26, 2019 at 8:16:38 AM UTC-7, Lee wrote:
>
> Hello,
>
> I have been attempting to write C code for using SPI with the BBB. I am 
> manipulating spidev (in my case spidev1.0) with ioctl() however I am unable 
> to get SPI working. All of the libraries I have tried to use with a similar 
> method also don't seem to work (e.g. 
> https://github.com/deeplyembeddedWP/BeagleBone-SPI-Library, 
> https://github.com/photomankc/BeagleBone-Black-Robot-Library/blob/master/motors/l6470.h).
>  
> When I hook up the BBB SPI1 pins to the scope, there is no output.
>
> I have disabled the HDMI boot overlays (audio and video) and enabled the 
> SPI1 overlay. I am able to see signals on the scope with the 
> Python Adafruit_BBIO.SPI library but with this method I have been 
> unsuccessful. Is there something else to setup?
>
> uname -r:
> 4.14.71-ti-r80
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/a4d2d14e-a3f9-4b33-a399-2b6f1bf0d56a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Yet another BeagleBone to be launched into space tonight

[acheesehead]

That is cool!

On Wednesday, November 28, 2018 at 12:53:13 PM UTC-7, Jason Kridner wrote:
>
> Yeah, we don't exactly do the best job of getting the word out about 
> BeagleBones in space. It has been done several times now, including at 
> least one payload upon the ISS that I believe is still there.
>
> BeagleBones have been used as prototype test platforms for several years 
> by several space agencies and solution providers and it is only natural for 
> a few instances to actually end up making the journey.
>
> Tonight's launch of the Indian rocket (PSLV) around 10pm US Central time (
> http://www.newsbharati.com/Encyc/2018/11/28/India-to-launch-HysIS.html).
>
> The payload will include the "Centauri-1" satellite with BeagleBone Black 
> as the main flight computer running KubOS open source flight software by 
> Kubos Corporation (https://www.kubos.com). It was developed for Fleet 
> Space Technologies out of Australia (https://www.fleet.space/) by Kubos 
> and Pumpkin (https://www.pumpkinspace.com).
>
> I wasn't able to find out a lot else on-line...
> https://space.skyrocket.de/doc_sdat/centauri-1.htm 
>
> http://www.manmonthly.com.au/news/fleet-space-technologies-unveils-launch-partners-first-nanosatellite-launches/
>  
>
> I found a bit more about the flight controller computer at 
> https://www.pumpkinspace.com/store/p208/mbm2.html. 
>
> I'm going to try to do a better job at getting folks to talk about such 
> events on this list as I believe this is of general interest.
>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/39fe5dcd-761f-41b1-9ea5-2835e8e7c379%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: DDR initialisation on PocketBeagle

[acheesehead]

You could write a memory compare check in MLO to see that the file is 
indeed loaded correctly to help debug the problem. I wrote a routine to 
write the memory address to each cell in memory and then compare. Not 
totally comprehensive for stuck bits, but gave a warm fuzzy that memory was 
somewhat ok. Writing all 1's and then all 0's and compare would be another 
memory test.

On Wednesday, November 29, 2017 at 2:28:03 PM UTC-7, mike.ma...@gmail.com 
wrote:
>
> Hi,
>
> I'm currently trying to modify the (custom) MLO of my bare metal 
> application in order to work with the PocketBeagle. At the moment this MLO 
> works fine with BBB.
>
> According to the (incredibly small) manual of the Octavo SoC I changed the 
> initialisation of the DDR and EMIF registers - but this does not seem to be 
> everything which is necessary.
>
> Now with these register settings my MLO successfully loads the main 
> application into the DDR RAM but when the SoC jumps to the start adress of 
> it, it stalls. So it seems there is still a problem with the RAM 
> initialisation. Either writing the application to the RAM does not work or 
> execution of the loaded application is not possible.
>
> What I can see at the moment: the BBB initialisation of the RAM contains a 
> lot more than shown in the Octavo manual, there are a lot of idle and 
> shut-down states set which are not mentioned in Octavo manual.
>
> So...any idea what else is different in initialisation of BBB and 
> PocketBeagle? Are these additional idle/shut-down register settings needed 
> too?
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/89126aef-1c13-4a93-9607-10d8cedb7739%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Boot bare metal application - MLO no longer used?

[acheesehead]

Try reformatting SD card or use a new one. Copy MLO to the card *first*. 
Use a known good MLO. It is signed by a special TI utility.

On Sunday, November 26, 2017 at 11:44:50 AM UTC-7, mike.ma...@gmail.com 
wrote:
>
>
>> TI has not changes anything in StarterWare since BBB, so I don't expect a 
>> new MLO from this side - but it is not a problem since sources are included 
>> in StarterWare package and therefor can be build easily.
>
>  
> But this does not seem to be the problem, this ""-sequence means, 
> the SoC does not find the MLO anywhere! So although it is available on the 
> FatFS partition of the microSD card, it isn't loaded.
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/e2f27eb7-27ee-4c34-93c7-f926706df6f4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Boot bare metal application - MLO no longer used?

[acheesehead]

MLO looks for uboot.bin. MLO can be rewritten to look for your application 
or rename your application to uboot.bin. I chose to rewrite MLO, but forget 
why. Was many years ago on Beagleboard Xm.

On Saturday, November 25, 2017 at 4:44:51 AM UTC-7, mike.ma...@gmail.com 
wrote:
>
> Hi,
>
> I'm running a bare metal software on my BBB. It is started via a special 
> boot-application, a program named "MLO" located on eMMC card which then 
> itself starts my application from microSD card. This is one boot option of 
> the AM3358 and used by default.
>
> Now I tried do to the same with the PocketBeagle, in this case with MLO 
> and my application both on the microSD card - unfortunately it does not 
> work, the application is not started.
>
> My question: is there something fundamental different with the Octavo SoC? 
> And is there a serial debug interface available too, similar to the one 
> from the BBB where I can see some messages printed to serial console on 
> boot?
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/5bf31dcc-6704-4abb-800e-5aa884989ba1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: PocketBeagles are Unstable

[acheesehead]

A likely culprit is the power supply.

On Friday, November 24, 2017 at 7:55:56 AM UTC-7, Graham wrote:
>
> I have two PocketBeagles.
>
> Both are exhibiting random reboots, two to four times per day. No 
> indication in syslog as to any cause or problem. No pattern to 
> the reboots. Can happen while I an logged into the PB editing python 
> scripts with nano, or can happen in the middle of the night when 
> absolutely nothing is happening.
>
> Both are powered from Vin, running from a trusted lab bench supply 
> with plenty of reserve current. I have added extra bulk capacitance on 
> the Vin input, and also switched lab bench supplies to make sure it 
> was not a power supply problem.
>
> So, no USB-gadget interface running.
> No modifications to hardware or kernel. No modifications to the 
> system software.
>
> One is running the Oct 10 IoT release version
> bone-debian-9.2-iot-armhf-2017-10-10-4gb.img
> Linux PB1 4.4.91-ti-r133 #1 SMP Tue Oct 10 05:18:08 UTC 2017 armv7l
>
> The other is running the Stretch IoT weekly snapshot from 11-19
> bone-debian-9.2-iot-armhf-2017-11-19-4gb.img
> Linux beaglebone 4.9.61-ti-r76 #1 SMP PREEMPT Mon Nov 13 20:24:26 UTC 2017 
> armv7l
>
> Both are running USB2 to Ethernet dongles on USB Port1 so I can have 
> remote Ethernet access. To make sure it was not the USB-to-Ethernet 
> drivers, I ran one for a day, without the Ethernet interface, just 
> watched it on the UART0 Console Port, no programs running,
> and it still does the same thing.
>
> I think this should be easy to reproduce.
>
> Same/similar symptoms to the random reboots we were having on the BBB a 
> year or two ago.
>
> --- Graham
>
> ==
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/8f6da7ed-4957-43f1-8b3e-f22a5e878af8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: QNX image for BBB

[acheesehead]

I have installed on several versions of BBB.

On Friday, November 17, 2017 at 2:46:23 AM UTC-7, AVR wrote:
>
> Please can you tell me for what revision BBB your QNX image?
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/66727373-bd65-4680-890f-f9fb6cfc8b29%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Announcing $25 PocketBeagle

[acheesehead]

I had no issue ordering from Digikey as Robert suggested. USPS says it will 
be here Mon.

On Saturday, September 23, 2017 at 7:52:26 PM UTC-6, Eric Keller wrote:
>
> This happens at Mouser every time there is a new 'bone.  It gets sorted 
> eventually.
>
>
> On Sat, Sep 23, 2017 at 1:01 PM, Graham  
> wrote:
>
>> And this is just to get it shipped from Ft. Worth, Texas,  to a US 
>> Citizen in Austin, Texas.
>>
>> Just think what it will be like to get one outside of the U.S.
>>
>> --- Graham
>>
>> ==
>>
>>
>>
>>
>>
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/b36629ae-3c7a-4207-b3fe-2b481335ddab%40googlegroups.com
>>  
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/0c713225-be9c-402e-8487-7aca85093088%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Reading BBB ADC's using QNX

[acheesehead]

Sent you email with the files.

On Friday, July 14, 2017 at 1:20:54 PM UTC-6, set...@gmx.de wrote:
>
> Hey Acheesehead,
>
>  funny name :) I'm sitting here with the same problem and want to use the 
> adc of beaglebone black with qnx. But i cant figure out how it will work. 
> Can help me? I read you did it and it works.
>
> Best Regards
> Sethary
>
> Am Donnerstag, 12. März 2015 18:14:23 UTC+1 schrieb acheesehead:
>>
>> Got it!
>>
>> Steps 1 & 2 are not necessary. The rest is pretty straight-forward.
>>
>> On Wednesday, March 11, 2015 at 2:27:30 PM UTC-6, acheesehead wrote:
>>>
>>> I want to read the BBB ADC inputs using the QNX operating system. As no 
>>> driver is provided in the QNX BSP, I need to write low-level C code to do 
>>> this. I figure I need to do the following steps:
>>>
>>> 1. Put the pins in the right mux mode
>>> 2. Turn on the clock to the ADC
>>> 3. Set up the 'steps'
>>> 4. Start a conversion sequence
>>> 5. Wait for the sequence to end
>>> 6. Read the sampled values
>>>
>>> I have not found any low-level code that does this. It would be greatly 
>>> appreciated if anybody could provide example register-level code 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/f122c966-e6e4-49b0-a40e-c79ec3f907bd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: QNX image for BBB

[acheesehead]

Try this image, 
https://drive.google.com/file/d/0BzU1D_qKT1dfUFpfclBGMU1SeWc/view?usp=sharing. 
 If it boots, then you are in business. I can send you the source tree if 
this works. It will look for a file called rc.emmc located on the dos 
partition of the eMMC to run additional stuff.

On Tuesday, May 23, 2017 at 12:18:02 PM UTC-6, Adrian wrote:
>
> I am trying to boot a build QNX image obtained for 
> the bsp-nto650-ti-beaglebone-sp1-trunk-201209071340 using an SD, but I get 
> the message listed below. I want to mention that the prebuilt image 
> associated with BSP works fine.
>
> Does anybody knows how can I fix this ?
>
> Thank you  in advance!
>
> U-Boot# go 0x8100
>
> ## Starting application at 0x8100 ...
>
> DDR  DPLL in Lock mode:
>
>   DDR  clock 400 Mhz [400/1]
>
> Disp DPLL in Lock mode:
>
>   Disp clock 200 Mhz [200/1]
>
> MPU  DPLL in Lock mode:
>
>   MPU  clock 550 Mhz [550/1]
>
> PER  DPLL in Lock mode:
>
>   PER  clock 192 Mhz [960/5]
>
> CORE DPLL in Lock mode:
>
>   M4 CORE clock 100 Mhz [1000/10]
>
>   M5 CORE clock 125 Mhz [1000/8]
>
>   M6 CORE clock 250 Mhz [1000/4]
>
> Not a BeagleBone??
>
> MMU initializat...
>
> CPU0: L1 Icache: 512x64
>
> CPU0: L1 Dcache: 512x64 WB
>
> CPU0: L2 Dcache: 4096x64 WB
>
> CPU0: VFP-d32 FPSID=410330c3
>
> CPU0: NEON MVFR0=0222 MVFR1=0001
>
> CPU0: 413fc082: Cortex A8 rev 2 720MHz
>
> Loading IFS...done
>
> Jumping to QNX
>
>  
>
> System page at phys:80011000 user:fc404000 kern:fc404000
>
> Starting next program at vfe046604
>
> cpu_startnext: cpu0 -> fe046604
>
> VFPv3: fpsid=410330c3
>
> coproc_attach(10): replacing fe07601c with fe0758bc
>
> coproc_attach(11): replacing fe07601c with fe0758bc
>
> Welcome to QNX Neutrino 6.5.0 SP1 on the Texas Instruments BeagleBone 
> (ARMv7 Cortex-A8 core) - Board
>
>  
>
> Shutdown[0,0] S/C/F=11/1/11 C/D=fe01c68c/fe099ff4 state(c0)= now lock
>
> QNX Version 6.5.0 Release 2010/07/09-14:26:46EDT
>
> [0]PID-TID=1-6? P/T FL=00019001/0502 "proc/boot/procnto-instr"
>
> [0]ASPACE PID=2 PF=8012
>
> armle context[effe8f4c]:
>
> : 8ffb3000 8ffb3000 8ffb3c01 0181 effccbf8 0100  
> fc004000
>
> 0020: fc004000 effdf47c 01072fff 0008  effe8f90 fe046878 
> fe040e0c
>
> 0040: 6013
>
> instruction[fe040e0c]:
>
> 06 30 98 e7 1c 20 94 e5 11 00 12 e3 00 70 94 15 18 20 9d 15 07 70 82 11 0c 
> 00
>
> stack[effe8f90]:
>
> : effe8fbc e17ba000  efffb348 effca00c 003f 0a2e 
> e18a1fe0
>
> 0020: 8ffb3000 f000  0007 0040 effccbf8 fe099ff0 
> 0100
>
> 0040: 00ff efff0090 0073 008d effca6e8 fe044744 effccbf8 
> fe044ad0
>
> 0060: efffb348 fe069bac efffb348 fe071e30 effe9018   
> 
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/8caca63f-5f93-4bb7-bf5e-1bf32574512c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Realtek USB Wifi problems

[acheesehead]

I switched to Debian. 3.8.13+. Went through the same steps, with no luck. I 
have another USB Wifi device as well. It is a 148F:5370 Ralink 5370. Messed 
with that a bit and got it to work. Thanks all!

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/1b02f2d9-40c6-4b71-aa17-c88133855819%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Realtek USB Wifi problems

[acheesehead]

5V, 3A wall wart.

On Saturday, May 13, 2017 at 5:14:15 PM UTC-6, William Hermans wrote:
>
> Todd, how are you powering your board ? Hopefully not via USB . . .
>
> On Sat, May 13, 2017 at 4:10 PM, acheesehead <achee...@gmail.com 
> > wrote:
>
>> Yes, small dongle. It is plugged into a powered USB hub. Disabled HDMI in 
>> uEnv.txt. Rebooted and still no joy.
>>
>> I tried the Debian image on the Chipsee DVD earlier today and no luck 
>> there either, but could easily switch back to that. Other choices on the 
>> DVD include Linux-EZSDK and Android. I would welcome any suggestions for 
>> other OS's that support the Chipsee 7" display cape.
>>
>> On Saturday, May 13, 2017 at 3:29:19 PM UTC-6, RobertCNelson wrote:
>>>
>>>
>>>
>>> On May 13, 2017 2:02 PM, "Todd Peterson" <achee...@gmail.com> wrote:
>>>
>>> I have a BBB running Angstrom 3.8.13. I have a Realtek USB Wifi, lsusb 
>>> shows
>>> Bus 002 Device 004: ID 0bda:818b Realtek Semiconductor Corp.
>>> I put 8192cu.ko in /lib/modules/3.8.13-00720-g4202df2-dirty
>>> I did insmod 8192cu.ko
>>> lsmod shows 
>>> Module  Size  Used by
>>> 8192cu445685  0
>>>
>>> dmesg shows [6.699120] usbcore: registered new interface driver 
>>> rtl8192cu
>>>
>>> The interface does not show up with ifconfig
>>>
>>> What am I missing?
>>>
>>>
>>> It's that small miniature dongle right?
>>>
>>> Disable HDMI and suck a little USB extension cable.
>>>
>>> Your fighting the HDMI gnd plane that interferes with the wifi radio..
>>>
>>>
>>> Regards,
>>>
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/d9aba061-d22f-491b-9729-d3fbc235cc21%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/beagleboard/d9aba061-d22f-491b-9729-d3fbc235cc21%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/871ffa0c-f85f-4857-bd4b-fe1e8fdbfda5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Realtek USB Wifi problems

[acheesehead]

Yes, small dongle. It is plugged into a powered USB hub. Disabled HDMI in 
uEnv.txt. Rebooted and still no joy.

I tried the Debian image on the Chipsee DVD earlier today and no luck there 
either, but could easily switch back to that. Other choices on the DVD 
include Linux-EZSDK and Android. I would welcome any suggestions for other 
OS's that support the Chipsee 7" display cape.

On Saturday, May 13, 2017 at 3:29:19 PM UTC-6, RobertCNelson wrote:
>
>
>
> On May 13, 2017 2:02 PM, "Todd Peterson"  
> wrote:
>
> I have a BBB running Angstrom 3.8.13. I have a Realtek USB Wifi, lsusb 
> shows
> Bus 002 Device 004: ID 0bda:818b Realtek Semiconductor Corp.
> I put 8192cu.ko in /lib/modules/3.8.13-00720-g4202df2-dirty
> I did insmod 8192cu.ko
> lsmod shows 
> Module  Size  Used by
> 8192cu445685  0
>
> dmesg shows [6.699120] usbcore: registered new interface driver 
> rtl8192cu
>
> The interface does not show up with ifconfig
>
> What am I missing?
>
>
> It's that small miniature dongle right?
>
> Disable HDMI and suck a little USB extension cable.
>
> Your fighting the HDMI gnd plane that interferes with the wifi radio..
>
>
> Regards,
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d9aba061-d22f-491b-9729-d3fbc235cc21%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Realtek USB Wifi problems

[acheesehead]

Thanks for your help William. I will try to somehow upgrade the image.

On Saturday, May 13, 2017 at 1:55:25 PM UTC-6, William Hermans wrote:
>
>
>
> On Sat, May 13, 2017 at 12:53 PM, acheesehead <achee...@gmail.com 
> > wrote:
>
>> root@beaglebone-exp:~# opkg list-installed |grep ralink
>> linux-firmware-ralink - 
>> 1:0.0+r8-gitAUTOINC+c530a75c1e6a472b0eb9558310b518f0dfcd8860-r8.1
>>
>
> At this point, you're on your own with google. Unless someone else here 
> who is familiar with Angstrom knows what your problem is.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/3a192adf-8dbe-4891-ac72-547d8d6097fb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Realtek USB Wifi problems

[acheesehead]

root@beaglebone-exp:~# opkg list-installed |grep ralink
linux-firmware-ralink - 
1:0.0+r8-gitAUTOINC+c530a75c1e6a472b0eb9558310b518f0dfcd8860-r8.1


On Saturday, May 13, 2017 at 1:44:20 PM UTC-6, William Hermans wrote:
>
> Ok, so I do believe that Angstrom does use dpkg too, but it's modified, 
> But ah here we go:
>
> opkg list-installed |grep ralink
>
> If that does not show anything then opkg install linux-firmware-ralink, 
> reboot, reload your drivers if needed, then check ifconfig again.
>
> And you probably don't want to hear my alternative is that does not work 
> ;) It should work however.
>
> On Sat, May 13, 2017 at 12:33 PM, acheesehead <achee...@gmail.com 
> > wrote:
>
>> root@beaglebone-exp:~# opkg list | grep ralink
>> linux-firmware-ralink - 
>> 1:0.0+r8-gitAUTOINC+c530a75c1e6a472b0eb9558310b518f0dfcd8860-r8.1 - 
>> linux-firmware version 
>> 0.0+r8-gitAUTOINC+c530a75c1e6a472b0eb9558310b518f0dfcd8860-r8
>>
>>
>> On Saturday, May 13, 2017 at 1:31:30 PM UTC-6, William Hermans wrote:
>>>
>>> You have opkg . . .
>>>
>>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/7c0edfd3-09bb-45d2-b48d-04bd0cac8f06%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/beagleboard/7c0edfd3-09bb-45d2-b48d-04bd0cac8f06%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/e01d8756-3a76-45bc-9077-d2a527ac10b5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Realtek USB Wifi problems

[acheesehead]

root@beaglebone-exp:~# opkg list | grep ralink
linux-firmware-ralink - 
1:0.0+r8-gitAUTOINC+c530a75c1e6a472b0eb9558310b518f0dfcd8860-r8.1 - 
linux-firmware version 
0.0+r8-gitAUTOINC+c530a75c1e6a472b0eb9558310b518f0dfcd8860-r8


On Saturday, May 13, 2017 at 1:31:30 PM UTC-6, William Hermans wrote:
>
> You have opkg . . .
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/7c0edfd3-09bb-45d2-b48d-04bd0cac8f06%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Realtek USB Wifi problems

[acheesehead]

Neither command exists on my system. Nor is it connected to the Internet. I 
am connected directly to my laptop with an Ethernet cable. I have the 
Chipsee 7" display and installed the Angstrom image on the DVD that came 
with the display. I did reboot.

On Saturday, May 13, 2017 at 1:12:14 PM UTC-6, William Hermans wrote:
>
> What does this show for your system ?
> root@wgd:~# apt-cache search firmware-ralink
> firmware-ralink - Binary firmware for Ralink wireless cards
>
> And if that shows what does:
> root@wgd:~# dpkg -l | grep ralink
>
> Show for you ? It does not return anything for me, but I also do not have 
> a realtech wifi adapter installed either . . . Anyway, if you show that 
> package available through apt-cache search( run apt-get update first ), and 
> dpkg does not report it as install. Install that package *MAYBE* needs a 
> reboot, then run ifconfig again.
>
> On Sat, May 13, 2017 at 12:02 PM, Todd Peterson  > wrote:
>
>> I have a BBB running Angstrom 3.8.13. I have a Realtek USB Wifi, lsusb 
>> shows
>> Bus 002 Device 004: ID 0bda:818b Realtek Semiconductor Corp.
>> I put 8192cu.ko in /lib/modules/3.8.13-00720-g4202df2-dirty
>> I did insmod 8192cu.ko
>> lsmod shows 
>> Module  Size  Used by
>> 8192cu445685  0
>>
>> dmesg shows [6.699120] usbcore: registered new interface driver 
>> rtl8192cu
>>
>> The interface does not show up with ifconfig
>>
>> What am I missing?
>>
>> Thanks in advance,
>> Todd
>>
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/CAMSLvQzXLoBvLDVRrA17BmmKUPyWqzi0dzT3G6kwd4BwVraLmg%40mail.gmail.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/83fa9cc6-4c65-468e-bf64-9cdd59615421%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Kernel hangs when booting on BeagleBoard xM

[acheesehead]

Built the kernel according 
to https://eewiki.net/display/linuxonarm/BeagleBoard with v4.9.x-rt 
(Longterm 4.9.x + Real-Time Linux) and Root File System (small flash). It 
gets to Waiting for root device /dev/mmcblk0p2... and hangs there.

Any suggestions?

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/1ed6443e-f499-429c-a567-43c51208f17c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: RT Linux boot crash

[acheesehead]

More info, from disassembled image, abort occurs in enter_kernel at 9e4:

09e0 <__enter_kernel>:
 9e0: e3a0 mov r0, #0 ; 0x0
 9e4: e1a0f004 mov pc, r4


On Tuesday, February 21, 2017 at 12:14:10 PM UTC-7, acheesehead wrote:
>
> Using JTAG to trace the problem, I found that the code aborts at 
> 0x820009e4, after eventually running a bunch of code in the 0xc000 area 
> of memory. The DM3730 TRM shows this region as reserved, so I am a bit 
> confused as to what could be there. Any suggestions on how to debug this?
>
> Addresses relative to 0x8200
>  9b0: e320f000 nop {0}
>  9b4: e320f000 nop {0}
>  9b8: e320f000 nop {0}
>  9bc: e320f000 nop {0}
>  9c0: eafe b 9c0 <_binary_zImage_start+0x9c0>
>  9c4: eafe b 9c4 <_binary_zImage_start+0x9c4>
>  9c8: eafe b 9c8 <_binary_zImage_start+0x9c8>
>  9cc: eafe b 9cc <_binary_zImage_start+0x9cc>
>  9d0: eafe b 9d0 <_binary_zImage_start+0x9d0>
>  9d4: ea01 b 9e0 <_binary_zImage_start+0x9e0>
>  9d8: eafe b 9d8 <_binary_zImage_start+0x9d8>
>  9dc: eafe b 9dc <_binary_zImage_start+0x9dc>
>  9e0: e3a0 mov r0, #0
>  9e4: e1a0f004 mov pc, r4 jumps to 80008000, eventually gets to 
> 8000805C, then 80101878, then 800080B8
>  then 80008078 branches to 8012028C, then 8011f6a4, then 8011f69c, 
> then C149728C
>
> Regs after crash, the link register shows C0D6F77C:
> PC: (R15) = 000C, CPSR = A1D7 (ABORT mode, ARM FIQ dis. IRQ dis.)
> Current:
>  R0 =D2FFB254, R1 =5B4C, R2 =0001420C, R3 =00014254
>  R4 =D2FFB254, R5 =CFFE7000, R6 =5B3C, R7 =000B
>  R8 =0014, R9 =0014, R10=, R11=C127A4E8, R12=CFFECB84
>  R13=C1601DFC, R14=C1601E00, SPSR=C176218C
> USR: R8 =, R9 =C127A4E8, R10=CFFECB84, R11=C1601DFC, R12=C1601E00
>  R13=, R14=
> FIQ: R8 =756FDFF6, R9 =65F6, R10=F57DEBFF, R11=7FE73FFF, R12=78C3DFF7
>  R13=C17621A4, R14=C17621A4, SPSR=
> IRQ: R13=C1762180, R14=C1762180, SPSR=8173
> SVC: R13=C1601DF0, R14=C0D6F77C, SPSR=61D3
> ABT: R13=C176218C, R14=0010, SPSR=A1D7
> UND: R13=C1762198, R14=C1762198, SPSR=
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/fde55eda-2eca-41d7-b11b-b4a5eb7aefa8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] RT Linux boot crash

[acheesehead]

Using JTAG to trace the problem, I found that the code aborts at 
0x820009e4, after eventually running a bunch of code in the 0xc000 area 
of memory. The DM3730 TRM shows this region as reserved, so I am a bit 
confused as to what could be there. Any suggestions on how to debug this?

Addresses relative to 0x8200
 9b0: e320f000 nop {0}
 9b4: e320f000 nop {0}
 9b8: e320f000 nop {0}
 9bc: e320f000 nop {0}
 9c0: eafe b 9c0 <_binary_zImage_start+0x9c0>
 9c4: eafe b 9c4 <_binary_zImage_start+0x9c4>
 9c8: eafe b 9c8 <_binary_zImage_start+0x9c8>
 9cc: eafe b 9cc <_binary_zImage_start+0x9cc>
 9d0: eafe b 9d0 <_binary_zImage_start+0x9d0>
 9d4: ea01 b 9e0 <_binary_zImage_start+0x9e0>
 9d8: eafe b 9d8 <_binary_zImage_start+0x9d8>
 9dc: eafe b 9dc <_binary_zImage_start+0x9dc>
 9e0: e3a0 mov r0, #0
 9e4: e1a0f004 mov pc, r4 jumps to 80008000, eventually gets to 
8000805C, then 80101878, then 800080B8
 then 80008078 branches to 8012028C, then 8011f6a4, then 8011f69c, then 
C149728C

Regs after crash, the link register shows C0D6F77C:
PC: (R15) = 000C, CPSR = A1D7 (ABORT mode, ARM FIQ dis. IRQ dis.)
Current:
 R0 =D2FFB254, R1 =5B4C, R2 =0001420C, R3 =00014254
 R4 =D2FFB254, R5 =CFFE7000, R6 =5B3C, R7 =000B
 R8 =0014, R9 =0014, R10=, R11=C127A4E8, R12=CFFECB84
 R13=C1601DFC, R14=C1601E00, SPSR=C176218C
USR: R8 =, R9 =C127A4E8, R10=CFFECB84, R11=C1601DFC, R12=C1601E00
 R13=, R14=
FIQ: R8 =756FDFF6, R9 =65F6, R10=F57DEBFF, R11=7FE73FFF, R12=78C3DFF7
 R13=C17621A4, R14=C17621A4, SPSR=
IRQ: R13=C1762180, R14=C1762180, SPSR=8173
SVC: R13=C1601DF0, R14=C0D6F77C, SPSR=61D3
ABT: R13=C176218C, R14=0010, SPSR=A1D7
UND: R13=C1762198, R14=C1762198, SPSR=

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/6543088c-50aa-4bb6-b059-7b96034ff0e8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] RT Linux build for Beagleboard Configuration Screen

[acheesehead]

Thanks Robert. How do I get a disassembled listing of the kernel? I have a 
JTAG hooked up to the board and am getting an abort after the kernel starts 
executing at 0x8200.

On Thursday, February 16, 2017 at 12:42:59 PM UTC-7, RobertCNelson wrote:
>
> On Thu, Feb 16, 2017 at 1:34 PM, acheesehead <achee...@gmail.com 
> > wrote: 
> > Using these instructions: 
> > 
> > https://eewiki.net/display/linuxonarm/BeagleBoard 
> > 
> > On the ./build_kernel.sh step, the script runs for a while and then a 
> > configuration screen appears. I am not sure what to change at that 
> point. 
>
> Press  to exit and the build will move on with the 
> pre-setup-default configuration 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/a5395f05-5a7f-4c0b-a7b7-d70e7461a2d6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] RT Linux build for Beagleboard Configuration Screen

[acheesehead]

Using these instructions:

https://eewiki.net/display/linuxonarm/BeagleBoard

On the ./build_kernel.sh step, the script runs for a while and then a 
configuration screen appears. I am not sure what to change at that point.

 .config - Linux/arm 4.9.8 Kernel Configuration
 

  ┌ Linux/arm 4.9.8 Kernel 
Configuration ─┐
  │  Arrow keys navigate the menu.   selects submenus ---> (or empty 
submenus ).  Highlighted letters are  │
  │  hotkeys.  Pressing  includes,  excludes,  modularizes 
features.  Press  to exit,  for Help,│
  │   for Search.  Legend: [*] built-in  [ ] excluded   module  < > 
module capable  │
  │ 
  │
  │ 
┌───┐
 
│
  │ │  (8) Maximum PAGE_SIZE order of alignment for DMA 
IOMMU buffers   │ │ │ │ 
 -*- Patch physical to virtual translations at runtime 
   │ │
  │ │  General setup  ---> 
 │ │
  │ │  [*] Enable loadable module support  ---> 
│ │
  │ │  [*] Enable the block layer  ---> 
│ │
  │ │  System Type  --->   
 │ │
  │ │  Bus support  --->   
 │ │
  │ │  Kernel Features  --->   
 │ │
  │ │  Boot options  --->   
│ │
  │ │  CPU Power Management  --->   
│ │
  │ │  Floating point emulation  --->   
│ │
  │ │  Userspace binary formats  --->   
│ │
  │ │  Power management options  --->   
│ │
  │ │  [*] Networking support  ---> 
│ │
  │ │  Device Drivers  ---> 
│ │
  │ │  Firmware Drivers  --->   
│ │
  │ │  File systems  --->   
│ │
  │ │  Kernel hacking  ---> 
│ │
  │ │  Security options  --->   
│ │
  │ │  -*- Cryptographic API  ---> 
 │ │
  │ │  Library routines  --->   
│ │
  │ │  -*- Virtualization  ---> 
│ │
  │ │   
│ │
  │ │   
│ │
  │ │   
│ │
  │ │   
│ │
  │ │   
│ │
  │ │   
│ │
  │ │   
│ │
  │ │   
│ │
  │ │   
│ │
  │ 

[beagleboard] Re: Can I disable loading of device tree at boot?

[acheesehead]

Ok. Figured that out. Added dtb=null to uEnv.txt. That got me to the 
following output. It hangs at Starting kernel. I figure I need some minimal 
device tree to at least get the I2C for the power chip set up.

U-Boot 2017.03-rc1-dirty (Feb 13 2017 - 15:07:27 -0700)

OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 GHz
OMAP3 Beagle board + LPDDR/NAND
I2C:   ready
DRAM:  256 MiB
NAND:  0 MiB
MMC:   OMAP SD/MMC: 0
*** Warning - readenv() failed, using default environment

Beagle xM Rev C
No EEPROM on expansion board
No EEPROM on expansion board
OMAP die ID: 715e00029ff80156083e0501c01d
Net:   usb_ether
Error: usb_ether address not set.

Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
Checking for: /uEnv.txt ...
Checking for: /boot/uEnv.txt ...
62 bytes read in 7 ms (7.8 KiB/s)
Loaded environment from /boot/uEnv.txt
Using: dtb=null ...
Checking if uname_r is set in /boot/uEnv.txt...
Running uname_boot ...
loading /boot/vmlinuz-4.9.7-armv7-rt-x4 ...
6435000 bytes read in 499 ms (12.3 MiB/s)

unable to find null ...
booting legacy ...
debug: [console=ttyO2,115200n8 root=PARTUUID=-02 ro rootfstype=ext4 
rootwait] ...
debug: [bootz 0x8200] ...

Starting kernel ...


On Monday, February 13, 2017 at 11:33:26 AM UTC-7, acheesehead wrote:
>
> I am porting RT Linux 4.9.7 to a custom board. When u-boot tries to load 
> /boot/dtbs/4.9.7-armv7-rt-x4/ompam3-beagle-xm.dtb, it gets an error of 
> FDT_ERR_BADSTRUCTURE. I have looked at the .dts file and removed stuff that 
> are not on the board, like dvi and still get the error.
>
> I'm thinking that if I can disable the tree load in u-boot and get to a 
> Linux command line that I will be able to debug easier.
>
> Is there an easy way to do that?
>
> -- 
> John 3:16
> IN GOD WE TRUST!!!
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/8c6ab4a1-da55-42c7-b740-b604ac48f0c7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Invalid partition message during boot

[acheesehead]

Robert,

My u-boot mod somehow got wiped. Put it back in and recompiled. I'm still 
having a problem with the device tree (which I don't know enough about):

U-Boot 2017.03-rc1-dirty (Feb 08 2017 - 15:00:15 -0700)

OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 GHz
OMAP3 Beagle board + LPDDR/NAND
I2C:   ready
DRAM:  256 MiB
NAND:  0 MiB
MMC:   OMAP SD/MMC: 0
*** Warning - readenv() failed, using default environment

Beagle xM Rev C
No EEPROM on expansion board
No EEPROM on expansion board
OMAP die ID: 715e00029ff80156083e0501c01d
Net:   usb_ether
Error: usb_ether address not set.

Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
Checking for: /uEnv.txt ...
Checking for: /boot/uEnv.txt ...
53 bytes read in 7 ms (6.8 KiB/s)
Loaded environment from /boot/uEnv.txt
Checking if uname_r is set in /boot/uEnv.txt...
Running uname_boot ...
loading /boot/vmlinuz-4.9.7-armv7-rt-x4 ...
6435000 bytes read in 499 ms (12.3 MiB/s)
loading /boot/dtbs/4.9.7-armv7-rt-x4/omap3-beagle-xm.dtb ...
100032 bytes read in 233 ms (418.9 KiB/s)
debug: [console=ttyO2,115200n8 root=/dev/mmcblk0p2 ro rootfstype=ext4 
rootwait] ...
debug: [bootz 0x8200 - 0x8800] ...
## Flattened Device Tree blob at 8800
   Booting using the fdt blob at 0x8800
   Loading Device Tree to 8ffe4000, end 86bf ... OK
fdt_find_or_add_subnode: memory: FDT_ERR_BADSTRUCTURE
ERROR: arch-specific fdt fixup failed
 - must RESET the board to recover.

FDT creation failed! hanging...### ERROR ### Please RESET the board ###


On Wednesday, February 8, 2017 at 1:39:01 PM UTC-7, RobertCNelson wrote:
>
> On Wed, Feb 8, 2017 at 2:33 PM, acheesehead <achee...@gmail.com 
> > wrote: 
> > Boots ok on Beagleboard xM, but hangs on our custom board. 
> > 
> > U-Boot SPL 2017.03-rc1-dirty (Feb 04 2017 - 12:10:18) 
> > Trying to boot from MMC1 
> > SPL: Please implement spl_start_uboot() for your board 
> > SPL: Direct Linux boot not active! 
> > reading u-boot.img 
> > reading u-boot.img 
> > 
> > 
> > U-Boot 2017.03-rc1-dirty (Feb 04 2017 - 12:10:18 -0700) 
> > 
> > OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 GHz 
> > OMAP3 Beagle board + LPDDR/NAND 
>
> > Beagle Rev Ax/Bx 
>
> > loading /boot/dtbs/4.9.7-armv7-rt-x4/omap3-beagle.dtb ... 
>
> Why is your board going down the Beagle classic route? 
>
> Take a look at the gpio's used for id on the xM C, you messed those up 
> when you built your custom board.. 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/cefbf17e-aea8-4eff-b8fd-48aca613d1f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Invalid partition message during boot

[acheesehead]

Boots ok on Beagleboard xM, but hangs on our custom board.

U-Boot SPL 2017.03-rc1-dirty (Feb 04 2017 - 12:10:18)
Trying to boot from MMC1
SPL: Please implement spl_start_uboot() for your board
SPL: Direct Linux boot not active!
reading u-boot.img
reading u-boot.img


U-Boot 2017.03-rc1-dirty (Feb 04 2017 - 12:10:18 -0700)

OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 GHz
OMAP3 Beagle board + LPDDR/NAND
I2C:   ready
DRAM:  256 MiB
NAND:  0 MiB
MMC:   OMAP SD/MMC: 0
*** Warning - readenv() failed, using default environment

Beagle Rev Ax/Bx
No EEPROM on expansion board
No EEPROM on expansion board
OMAP die ID: 715e00029ff80156083e0501c01d
Net:   usb_ether
Error: usb_ether address not set.

Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
Checking for: /uEnv.txt ...
Checking for: /boot/uEnv.txt ...
26 bytes read in 7 ms (2.9 KiB/s)
Loaded environment from /boot/uEnv.txt
Checking if uname_r is set in /boot/uEnv.txt...
Running uname_boot ...
loading /boot/vmlinuz-4.9.7-armv7-rt-x4 ...
6435000 bytes read in 499 ms (12.3 MiB/s)
loading /boot/dtbs/4.9.7-armv7-rt-x4/omap3-beagle.dtb ...
98676 bytes read in 210 ms (458 KiB/s)
debug: [console=ttyO2,115200n8 root=/dev/mmcblk0p2 ro rootfstype=ext4 
rootwait musb_hdrc.fifo_mode=5] ...
debug: [bootz 0x8200 - 0x8800] ...
## Flattened Device Tree blob at 8800
   Booting using the fdt blob at 0x8800
   Loading Device Tree to 8ffe4000, end 8173 ... OK
fdt_find_or_add_subnode: memory: FDT_ERR_BADSTRUCTURE
ERROR: arch-specific fdt fixup failed
 - must RESET the board to recover.

FDT creation failed! hanging...### ERROR ### Please RESET the board ###


On Wednesday, February 8, 2017 at 1:10:20 PM UTC-7, acheesehead wrote:
>
> I built Linux RT for a custom board based upon Beagleboard xM exactly as 
> in Robert C. Nelson's page 
> https://eewiki.net/display/linuxonarm/BeagleBoard.
>
> Here is what I get during boot, tried on a real Beagleboard xM and get the 
> same behavior. The booting stops at a u-boot prompt.
>
> U-Boot SPL 2017.03-rc1-dirty (Feb 04 2017 - 12:10:18)
> Trying to boot from MMC1
> SPL: Please implement spl_start_uboot() for your board
> SPL: Direct Linux boot not active!
> reading u-boot.img
> reading u-boot.img
>
>
> U-Boot 2017.03-rc1-dirty (Feb 04 2017 - 12:10:18 -0700)
>
> OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 GHz
> OMAP3 Beagle board + LPDDR/NAND
> I2C:   ready
> DRAM:  512 MiB
> NAND:  0 MiB
> MMC:   OMAP SD/MMC: 0
> *** Warning - readenv() failed, using default environment
>
> Beagle xM Rev C
> No EEPROM on expansion board
> No EEPROM on expansion board
> OMAP die ID: 101000229ff8016830c319017022
> Net:   usb_ether
> Error: usb_ether address not set.
>
> Hit any key to stop autoboot:  0
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc 0:1...
> switch to partitions #0, OK
> mmc0 is current device
> SD/MMC found on device 0
> Checking for: /uEnv.txt ...
> Checking for: /boot/uEnv.txt ...
> 26 bytes read in 7 ms (2.9 KiB/s)
> Loaded environment from /boot/uEnv.txt
> Checking if uname_r is set in /boot/uEnv.txt...
> Running uname_boot ...
> ** Invalid partition 3 **
> ** Invalid partition 4 **
> ** Invalid partition 5 **
> ** Invalid partition 6 **
> ** Invalid partition 7 **
> =>
>
>

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

[beagleboard] Re: Invalid partition message during boot

[acheesehead]

Got around that problem. My uEnv.txt file was wrong.

On Wednesday, February 8, 2017 at 1:10:20 PM UTC-7, acheesehead wrote:
>
> I built Linux RT for a custom board based upon Beagleboard xM exactly as 
> in Robert C. Nelson's page 
> https://eewiki.net/display/linuxonarm/BeagleBoard.
>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/640d76a5-d182-46e2-808a-6f9aca1dc86d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Invalid partition message during boot

[acheesehead]

I built Linux RT for a custom board based upon Beagleboard xM exactly as in 
Robert C. Nelson's page https://eewiki.net/display/linuxonarm/BeagleBoard.

Here is what I get during boot, tried on a real Beagleboard xM and get the 
same behavior. The booting stops at a u-boot prompt.

U-Boot SPL 2017.03-rc1-dirty (Feb 04 2017 - 12:10:18)
Trying to boot from MMC1
SPL: Please implement spl_start_uboot() for your board
SPL: Direct Linux boot not active!
reading u-boot.img
reading u-boot.img


U-Boot 2017.03-rc1-dirty (Feb 04 2017 - 12:10:18 -0700)

OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 GHz
OMAP3 Beagle board + LPDDR/NAND
I2C:   ready
DRAM:  512 MiB
NAND:  0 MiB
MMC:   OMAP SD/MMC: 0
*** Warning - readenv() failed, using default environment

Beagle xM Rev C
No EEPROM on expansion board
No EEPROM on expansion board
OMAP die ID: 101000229ff8016830c319017022
Net:   usb_ether
Error: usb_ether address not set.

Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
Checking for: /uEnv.txt ...
Checking for: /boot/uEnv.txt ...
26 bytes read in 7 ms (2.9 KiB/s)
Loaded environment from /boot/uEnv.txt
Checking if uname_r is set in /boot/uEnv.txt...
Running uname_boot ...
** Invalid partition 3 **
** Invalid partition 4 **
** Invalid partition 5 **
** Invalid partition 6 **
** Invalid partition 7 **
=>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/c0b994fd-afff-4bbc-91dc-2c9a668d3531%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Building Linux for a custom board

[acheesehead]

Thanks Robert. That did the trick. I will see on Mon. if the image boots 
up. I have to deal with some other issues regarding pin muxing and an eMMC 
that was added on our board. I'm slightly familiar with device trees and 
think that I should be able to deal with this using them. The production 
Angstrom image for the xM does not have the pinmux mechanism, which was 
what prompted me to use the latest Linux version. Should keep me busy for a 
while.

On Friday, February 3, 2017 at 12:47:25 PM UTC-7, acheesehead wrote:
>
> We have a board based upon the Beagleboard xM rev. C. We have been running 
> QNX on it. We are trying to experiment with RT Linux by following the 
> instructions at https://eewiki.net/display/linuxonarm/BeagleBoard and the 
> kernel builds fine. We have a problem with the gpios that identify the 
> board revision, since we do not have these gpios wired. I modified 
> u-boot/board/ti/beagle/beagle.c to return revision=2 in get_board_revision. 
> But when I compile u-boot, I get an error of 
>
> /home/users/staff/tpeterson/work/epic2-rt-linux/gcc-linaro-5.3.1-2016.05-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-ld.bfd:
>  
> u-boot-spl section `.rodata' will not fit in region `.sram'
> /home/users/staff/tpeterson/work/epic2-rt-linux/gcc-linaro-5.3.1-2016.05-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-ld.bfd:
>  
> region `.sram' overflowed by 2848 bytes
> scripts/Makefile.spl:290: recipe for target 'spl/u-boot-spl' failed
>
> Not sure where to fix this.
>
> I also could not find anything in the kernel source that is the equivalent 
> get_board_revision call.
>
> Any help is greatly appreciated.
>
> -- 
> John 3:16
> IN GOD WE TRUST!!!
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/3716ce50-97ca-45ec-a4b9-85c549996b86%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: ds18b20 with BBGW

[acheesehead]

Thanks William. I'll try out your suggestions when I get to the office.

On Monday, December 5, 2016 at 8:51:37 PM UTC-7, William Hermans wrote:
>
> Nope, actually that persons overlay file is wrong. So yeah I don;t know 
> time to learn Linux and start troubleshooting your problems ;)
>
> On Mon, Dec 5, 2016 at 8:47 PM, William Hermans <yyr...@gmail.com 
> > wrote:
>
>> Actually the last bit probably wont work because:
>>
>> william@beaglebone:~$ ls /sys/devices/platform/ocp/*.gpio/gpio/
>> /sys/devices/platform/ocp/44e07000.gpio/gpio/:
>> gpiochip0
>>
>> /sys/devices/platform/ocp/4804c000.gpio/gpio/:
>> gpiochip32
>>
>> /sys/devices/platform/ocp/481ac000.gpio/gpio/:
>> gpiochip64
>>
>> /sys/devices/platform/ocp/481ae000.gpio/gpio/:
>> gpiochip96
>>
>> You wont get an actual gpio bank number. Just the bank offset. So going 
>> by this beaglebone blogpost: 
>> http://www.bonebrews.com/temperature-monitoring-with-the-ds18b20-on-a-beaglebone-black/
>>
>> gpios = < 13 0>;  /* P8.11*/
>>
>> I show P8.11 as gpio1_13 in my pinmux pdf file. So yes, 4.x versus 3.8.x, 
>> for gpio banks are definitely off by one. Looks like for 3.8.x kernel gpio 
>> banks start at gpio1, and I know for a fact that gpio banks in 4.x start at 
>> gpio0.
>>
>> Anyway, very good chance your overlay file is slightly wrong. Based on 
>> off by one gpio bank.
>>
>> On Mon, Dec 5, 2016 at 8:28 PM, William Hermans <yyr...@gmail.com 
>> > wrote:
>>
>>> On Mon, Dec 5, 2016 at 7:30 PM, acheesehead <achee...@gmail.com 
>>> > wrote:
>>>
>>>> Tried your workflow today without success. Everything is OK up to the 
>>>> lsmod | grep w1 step. I only get the w1_gpio entry. I am not a Linux 
>>>> kernel 
>>>> expert, so I don't know how to troubleshoot why the other entries aren't 
>>>> showing up.
>>>>
>>>> I didn't see any activity on the oscilloscope either.
>>>>
>>>  
>>> Then, you must be using a 3.8.x kernel. Right ? But here are the modules 
>>> needed at least on a 4.x kernel:
>>>
>>> william@beaglebone:~/dev/bb.org-overlays$ lsmod |grep w1
>>> w1_therm4886  0
>>> w1_gpio 3764  0
>>> wire   35398  2 w1_gpio,w1_therm
>>>
>>> All three of those need to be loaded in order for the DS18B20 to work. 
>>> So, try manually loading those via modprobe. SO let's take a look at a rPI 
>>> blogpost: 
>>> https://www.modmypi.com/blog/ds18b20-one-wire-digital-temperature-sensor-and-the-raspberry-pi
>>>
>>> Much of this blog post is going to be RaspberryPI centric. 
>>> *dtoverlay=w1-gpio, 
>>> */boot/config.txt, etc. However if you scroll down to the *"Programming" 
>>> *part of the blog post. This person talks about loading the required 
>>> kernel modules( also note that kernel version is 3.6.11 ) Using modprobe. 
>>> So if you run those two modprobe commands, and then list the contents of 
>>> /sys/bus/w1/devices:
>>>
>>> *william@beaglebone:~$* ls /sys/bus/w1/devices/
>>> 28-0647ddf6  w1_bus_master1
>>>
>>> And you get output like the above. 1-wire *is* working, and the 1-wire 
>>> master ( beaglebone ) has detected a 1-wire slave device. It's working. 
>>> However, if you load both the above 1-wire kernel modules, and there is 
>>> nothing in /sys/bus/w1/devices, then something is wrong. I'd have to say at 
>>> this point, if you do not get an error about a missing module, that you 
>>> have your pin muxed incorrectly, or not properly connected to the pin. 
>>>
>>> Now if you get an error on the command line from trying to load either 
>>> of those two 1-wire modules. Chances are pretty good you haven't compiled 
>>> in the given proper 1-wire support. In fact, I do believe there is a whole 
>>> section in menu-config for 1-wire devices. You may actually have to 
>>> recompile your kernel with support for the DS18B20 1-wire device . . .
>>>
>>> Another issues between 4.x, and 3.8.x kernels is that device enumeration 
>>> was different for some devices. So . . . It is entirely possible, in your 
>>> overlay, that the GPIO bank you're passing in as parameters is off by one. 
>>> How can be test for this ? On 4.x kernels . . .
>>>
>>> *william@beaglebone:~$* ls /sys/devices/platform/ocp
>>> 4030.ocmcram  48042000.

Re: [beagleboard] Re: ds18b20 with BBGW

[acheesehead]

Tried your workflow today without success. Everything is OK up to the lsmod 
| grep w1 step. I only get the w1_gpio entry. I am not a Linux kernel 
expert, so I don't know how to troubleshoot why the other entries aren't 
showing up.

I didn't see any activity on the oscilloscope either.

On Thursday, December 1, 2016 at 10:28:16 PM UTC-7, William Hermans wrote:
>
> *1-wire workflow:*
>
> *Hardware setup:*
>
> Everything is directly connected via jumper wires, with no additional 
> components.
>
> DS18B20 PIN1 connected to Beaglebone P9.1  (ground)
> DS18B20 PIN2 connected to Beaglebone P9.22 (1-wire data)
> DS18B20 PIN3 connected to Beaglebone P9.5  (Vdd 5v)
>
>
> Remove any currently loaded overlays that might be using P9_22, then 
> reboot.
>
> Install git if need be:
> william@beaglebone:~/dev$ sudo apt-get install git
>
> git clone the bb.org-overlays repo:
> william@beaglebone:~/dev$ git clone 
> https://github.com/beagleboard/bb.org-overlays
>
> Move into the source directory:
> william@beaglebone:~/dev$ cd ./bb.org-overlays/src/arm
>
> Find the file we're looking for:
> william@beaglebone:~/dev/bb.org-overlays/src/arm$ ls |grep W1
> BB-W1-P9.12-00A0.dts
>
> Make a copy of the file while renaming it in one go:
> william@beaglebone:~/dev/bb.org-overlays/src/arm$ cp BB-W1-P9.12-00A0.dts 
> BB-W1-P9.22-00A0.dts
>
>
> Edit copied 1-wire overlay source to suit our needs:
> william@beaglebone:~/dev/bb.org-overlays/src/arm$ diff 
> BB-W1-P9.12-00A0.dts BB-W1-P9.22-00A0.dts
> 4c4
> <  * Virtual cape for onewire on connector pin P9.12
> ---
> >  * Virtual cape for onewire on connector pin P9.22
> 21c21
> <   part-number = "BB-W1-P9.12";
> ---
> >   part-number = "BB-W1-P9.22";
> 27c27
> <   "P9.12";
> ---
> >   "P9.22";
> 35c35
> <   BONE_P9_12 0x37
> ---
> >   BONE_P9_22 0x37
> 51c51
> <   gpios = < 28 GPIO_ACTIVE_HIGH>;
> ---
> >   gpios = < 2 GPIO_ACTIVE_HIGH>;
>
> Backout to the base path:
> william@beaglebone:~/dev/bb.org-overlays/src/arm$ cd ../..
>
> Build our newly created overlay:
> william@beaglebone:~/dev/bb.org-overlays$ make 
> ./src/arm/BB-W1-P9.22-00A0.dtbo
>
> "Install" our overlay:
> william@beaglebone:~/dev/bb.org-overlays$ sudo cp 
> ./src/arm/BB-W1-P9.22-00A0.dtbo /lib/firmware/
>
> Load our overlay:
> william@beaglebone:~/dev/bb.org-overlays$ sudo sh -c "echo 'BB-W1-P9.22' > 
> /sys/devices/platform/bone_capemgr/slots"
>
> Check if the overlay loaded:
> william@beaglebone:~/dev/bb.org-overlays$ cat 
> /sys/devices/platform/bone_capemgr/slots
>  0: PF  -1
>  1: PF  -1
>  2: PF  -1
>  3: PF  -1
>  4: P-O-L-   0 Override Board Name,00A0,Override Manuf,BB-W1-P9.22
>
>  william@beaglebone:~/dev/bb.org-overlays$ dmesg |grep W1
> [ 2826.626795] bone_capemgr bone_capemgr: part_number 'BB-W1-P9.22', 
> version 'N/A'
> [ 2826.626871] bone_capemgr bone_capemgr: slot #4: 'Override Board 
> Name,00A0,Override Manuf,BB-W1-P9.22'
> [ 2826.641278] bone_capemgr bone_capemgr: slot #4: dtbo 
> 'BB-W1-P9.22-00A0.dtbo' loaded; overlay id #0
>
> Check to make sure kernel modules loaded or not:
> william@beaglebone:~/dev/bb.org-overlays$ lsmod |grep w1
> w1_therm4886  0
> w1_gpio 3764  0
> wire   35398  2 w1_gpio,w1_therm
>
> Check sysfs:
> william@beaglebone:~/dev/bb.org-overlays$ ls /sys/bus/w1/devices/
> 28-0647ddf6  w1_bus_master1
>
> Read from our sensor:
> william@beaglebone:~/dev/bb.org-overlays$ cat 
> /sys/bus/w1/devices/28-0647ddf6/w1_slave
> 16 01 4b 46 7f ff 0a 10 98 : crc=98 YES
> 16 01 4b 46 7f ff 0a 10 98 t=17375
>
> Pat self on back for job well done !
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/3529e32e-5edd-4e1f-add2-80832ac19715%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: ds18b20 with BBGW

[acheesehead]

Thanks William. I'll try out your instructions on Mon.

On Thursday, December 1, 2016 at 10:50:19 PM UTC-7, William Hermans wrote:
>
>
> On Thu, Dec 1, 2016 at 10:39 PM, acheesehead <achee...@gmail.com 
> > wrote:
>
>> In all of the examples that I have seen, the P9.x -> GPIO bank.port 
>> translates to GPIO (bank +1).port between lines in the overlay script.
>>
>
> That's incorrect if I understand what you're trying to say. the P8/P9 
> header values for the pins have absolutely no correlation to the kernel pin 
> values. These values can be gleaned from the schematics. But I typically 
> use something like the attached file( in pdf format ) that lists all the 
> important data I need.
>
> For example P9.22 has a kernel gpio value of gpio0_2. What this means is 
> that the pin is on gpio bank0 ( bank zero ), and is pin 2 of that gpio 
> bank. Note, that on the beaglebone there are 4 GPIO banks. gpio0-gpio3. Now 
> with this in mind. to figure out the sysfs gpio number you would . ..
>
> gpio_bank * 32 + pin number. So, for the sysfs file entry for the P9.22 
> pin. Our pin would be gpio2. But for example, and arguments sake. If this 
> pin were on gpio_bank 1, then the sysfs entry for this pin would be gpio34. 
> gpio_bank 1 * 32 + 2.
>
> Irregardless, I just gave you a step by step, exact steps recipe to 
> success. That I wrote as I figured it out for the first time myself. 
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/75641c91-5759-4515-9e74-9bb6e4540346%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: ds18b20 with BBGW

[acheesehead]

In all of the examples that I have seen, the P9.x -> GPIO bank.port 
translates to GPIO (bank +1).port between lines in the overlay script.

On Wednesday, November 30, 2016 at 8:58:19 PM UTC-7, Sebastián Sáez wrote:
>
> Hi!
>
> I'm trying to read temp with a ds18b20 sensor. I try with a few tutorial 
> without luck.
>
> Any tips for read this sensor?
> I'm using Debian 8.6 2016-11-06 4GB SD SeeedStudio IoT (kernel 
> 4.4.30-ti-r64)
>
>
> regards,
> Sebastián
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/f1d15dca-80ce-4476-9cb5-94e0899c4f17%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: ds18b20 with BBGW

[acheesehead]

I also am having no luck. I created an overlay:

root@beaglebone:~# cat w1-p9-13.dts
/dts-v1/;
/plugin/;

/ {
compatible = "ti,beaglebone", "ti,beaglebone-black", 
"ti,beaglebone-green";
part-number = "BB-W1";
version = "00A0";

/* state the resources this cape uses */
exclusive-use =
/* the pin header uses */
"P9.13",
/* the hardware IP uses */
"gpio0_31";


fragment@0 {
   target = <_pinmux>;
   __overlay__ {
dallas_w1_pins: pinmux_dallas_w1_pins {
pinctrl-single,pins = < 0x74 0x37 >;
};
   };
};

fragment@1 {
   target = <>;
   __overlay__ {
   onewire@0 {
   compatible  = "w1-gpio";
   pinctrl-names   = "default";
   pinctrl-0   = <_w1_pins>;
   status  = "okay";

   gpios = < 31 0>;
   };
 };
};
};

Compiled and then copied it to /lib/firmware as BB-W1-P9-13-00A0.dtbo. Did 
echo BB-W1-P9-13 > /sys/devices/platform/bone_capemgr/slots. 
root@beaglebone:~# cat /sys/devices/platform/bone_capemgr/slots
 0: PF  -1
 1: PF  -1
 2: PF  -1
 3: PF  -1
 4: P-O-L-   0 Override Board Name,00A0,Override Manuf,BB-W1-P9-13

tail of dmesg shows:
[  221.082070] bone_capemgr bone_capemgr: slot #6: 'Override Board 
Name,00A0,Override Manuf,BB-W1-P9-13'
[  221.108759] bone_capemgr bone_capemgr: slot #6: dtbo 
'BB-W1-P9-13-00A0.dtbo' loaded; overlay id #0
[  223.111781] w1_master_driver w1_bus_master1: w1_search: max_slave_count 
64 reached, will continue next search.

There is no activity on the oscilloscope for that pin.

root@beaglebone:~# ls /sys/devices/w1_bus_master1/
00-4000  w1_master_add  w1_master_remove
00-8000  w1_master_attempts w1_master_search
driver   w1_master_max_slave_count  w1_master_slave_count
powerw1_master_name w1_master_slaves
subsystemw1_master_pointer  w1_master_timeout
uevent   w1_master_pullup   w1_master_timeout_us

Have tried other overlays on different pins. No luck. The sensor is good, 
since I checked it out on a WiPy V2.0 board.

Am frustrated by this.

Board info:
root@beaglebone:~# uname -a
Linux beaglebone 4.4.29-bone-rt-r14 #1 PREEMPT RT Tue Nov 1 21:30:09 UTC 
2016 armv7l GNU/Linux

On Wednesday, November 30, 2016 at 8:58:19 PM UTC-7, Sebastián Sáez wrote:
>
> Hi!
>
> I'm trying to read temp with a ds18b20 sensor. I try with a few tutorial 
> without luck.
>
> Any tips for read this sensor?
> I'm using Debian 8.6 2016-11-06 4GB SD SeeedStudio IoT (kernel 
> 4.4.30-ti-r64)
>
>
> regards,
> Sebastián
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/9cea473e-5f02-46f9-aee2-3a77e04eb417%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Does anyone know why there are no new BeagleBone Black's available?

[acheesehead]

This site has no logo versions: https://specialcomp.com/beaglebone/index.htm
I have got several boards from them. Have never had a problem with them.

On Friday, April 15, 2016 at 8:12:56 AM UTC-6, Fred Patrick wrote:
>
> The price on Amazon has gone fro $55 to $85 in the last month. Element14 
> merely says that there are none in stock w/o an estimated availability 
> date. Is there a manufacturing problem with Rev C?
>

-- 
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: QNX on beaglebone black

[acheesehead]

I just downloaded and built the latest 'experimental' QNX 6.6 BSP for BBB. 
Got the same errors. Turns out that the permissions of files in 
install/sbin and install/bin needed to change. Once I changed their 
permissions, all goes well. The build script does not mount the SD card or 
the eMMC, so that must be done manually.

On Tuesday, March 1, 2016 at 3:00:18 PM UTC-7, Steven Hartmann wrote:
>
> I hope there is someone here successfully using QNX on the BBB.  I am 
> currently doing a QNX evaluation and am having trouble with the BBB BSP.  I 
> am using the BSP_ti-am335x-beaglebone_br-660_be-660_SVN797070_JBN574.zip 
> BSP.  The package comes with a pre-built image, which boots up fine.  I 
> have been able to do a few test programs with it, but now I need to modify 
> the BSP to change which features are used.  The first step in doing this 
> was to just recompile the BSP to make sure I can recreate the precompiled 
> version.  The build goes fine and creates an image.  I can boot off the 
> image, but it gives a lot of errors:
>
> U-Boot#  fatload mmc 0 8100 ifs-ti-am335x-beaglebone.bin
> reading ifs-ti-am335x-beaglebone.bin
> 5794620 bytes read in 657 ms (8.4 MiB/s)
> U-Boot# go 8100
> ## Starting application at 0x8100 ...
>
> __Board ID__
> header:  ee3355aa
> name:A335BNLT
> 
> BeagleBone Black detected
>
> VFPv3: fpsid=410330c3
> coproc_attach(10): attach fe08a3fc (fe08ad24)
> coproc_attach(11): attach fe08a3fc (fe08ad24)
> Welcome to QNX Neutrino 6.6.0 on the Texas Instruments AM335x BeagleBone 
> (ARMv7 Cortex-A8 core) - Board
> Unable to start "devc-seromap" (2)
> Unable to access "/dev/ser1" (2)
> Unable to access "/dev/ser1" (2)
> Starting MMC/SD driver...
> Unable to start "devb-sdmmc-j5_generic" (2)
> Unable to start "devb-sdmmc-j5_generic" (2)
> starting I2C driver...
> Unable to start "i2c-omap35xx-j5" (2)
> Unable to access "/dev/i2c0" (2)
> starting WDT reset utility...
> Unable to start "dm814x-wdtkick" (2)
> starting Board ID driver...
> Unable to start "am335x-boardid" (2)
> Unable to access "/dev/bdid" (2)
> Setting OS Clock from on-board RTC
> Unable to start "rtc" (2)
> Sat Jan 01 00:00:15 GMT 2000
> Starting USB OTG Host driver...
> Starting SPI driver...
> Unable to start "spi-master" (2)
> Starting network driver...
> starting leds driver...
> Unable to start "am335x-leds" (2)
> Unable to access "/dev/leds" (2)
> Setting environment variables...
> done.
> Starting Screen Graphics...
> done.
> Starting HDMI Audio driver...
> Unable to access /dev/snd/pcmC0D1p
> ksh: No controlling tty (open /dev/tty: No such device or address)
> ksh: warning: won't have full job control
>
>
> All of the software that reports "unable to start" does not have execute 
> permissions.  When I tried to add execute permissions by hand, it said the 
> file did not exist.
>
> My build host is linux mint.
>
> 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: QNX on beaglebone black

[acheesehead]

These lines in the .build file should start the SD and eMMC:
###
## MMC/SD driver
###
display_msg Starting MMC/SD driver...
# MMC 0 pio
# devb-sdmmc-j5_generic sdio 
addr=0x4806,irq=64,dma=25,dma=24,dma=128,dma=32,verbose=3,bs=nocd:nowp 
cam pio,cache,pnp,async blk cache=8M disk name=sd
# MMC 0 dma
devb-sdmmc-j5_generic sdio 
addr=0x4806,irq=64,dma=25,dma=24,dma=128,dma=32,verbose=3,bs=nocd:nowp 
cam cache,pnp,async blk cache=8M disk name=sd

# eMMC 0 dma
devb-sdmmc-j5_generic sdio 
addr=0x481D8000,irq=28,verbose=3,dma=3,dma=2,dma=160,dma=32,bs=emmc,bw=4 
cam quiet,cache blk rw,cache=2M disk name=emmc

They should show up as /dev/hd0 and /dev/hd1. I am using a different 
driver. That could be a QNX 6.5 thing. Try typing 'sloginfo' to see if that 
gives you any clues. Of course, if they didn't start, the devices won't 
show up as evidenced by your original post:

*Starting MMC/SD driver...*
*Unable to start "devb-sdmmc-j5_generic" (2)*
*Unable to start "devb-sdmmc-j5_generic" (2)*

The SD card is usually split into 2 partitions. A small bootable FAT32 
partition to hold MLO, u-boot.bin and the QNX image. The other partition is 
usually set to type 131 for the QNX filesystem. I am booting from the eMMC. 
Here is what fdisk shows for eMMC:

FDISK
Ignore Next Prev Change Delete Boot Unboot Restore Loader Save Quit

_OS_ Start  End __Number_Size   
 Boot
nametypeCylinder  Cylinder  Cylinders  Blocks

--> 1.  FAT32  ( 11)0   511 512 1048544511 MB  *
2.  Linux  (131)  512  7439692814188544   6928 MB
3.  __ (___)_   _   _   _  _
4.  __ (___)_   _   _   _  _


 Choose a partition by typing the partition number OR moving the pointer
 with the UP/DOWN arrows.
 Then, choose one of the actions on the top line of the screen.



Drive : /dev/hd0Config:64 Heads
Size  : 7440 Mbytes32 Sectors/track
Loader: Unknown  7440 Cylinders
Blocks: 15237120  512 Block Size

Last cylinder is 7439


On Tuesday, March 1, 2016 at 3:00:18 PM UTC-7, Steven Hartmann wrote:
>
> I hope there is someone here successfully using QNX on the BBB.  I am 
> currently doing a QNX evaluation and am having trouble with the BBB BSP.  I 
> am using the BSP_ti-am335x-beaglebone_br-660_be-660_SVN797070_JBN574.zip 
> BSP.  The package comes with a pre-built image, which boots up fine.  I 
> have been able to do a few test programs with it, but now I need to modify 
> the BSP to change which features are used.  The first step in doing this 
> was to just recompile the BSP to make sure I can recreate the precompiled 
> version.  The build goes fine and creates an image.  I can boot off the 
> image, but it gives a lot of errors:
>
> U-Boot#  fatload mmc 0 8100 ifs-ti-am335x-beaglebone.bin
> reading ifs-ti-am335x-beaglebone.bin
> 5794620 bytes read in 657 ms (8.4 MiB/s)
> U-Boot# go 8100
> ## Starting application at 0x8100 ...
>
> __Board ID__
> header:  ee3355aa
> name:A335BNLT
> 
> BeagleBone Black detected
>
> VFPv3: fpsid=410330c3
> coproc_attach(10): attach fe08a3fc (fe08ad24)
> coproc_attach(11): attach fe08a3fc (fe08ad24)
> Welcome to QNX Neutrino 6.6.0 on the Texas Instruments AM335x BeagleBone 
> (ARMv7 Cortex-A8 core) - Board
> Unable to start "devc-seromap" (2)
> Unable to access "/dev/ser1" (2)
> Unable to access "/dev/ser1" (2)
> Starting MMC/SD driver...
> Unable to start "devb-sdmmc-j5_generic" (2)
> Unable to start "devb-sdmmc-j5_generic" (2)
> starting I2C driver...
> Unable to start "i2c-omap35xx-j5" (2)
> Unable to access "/dev/i2c0" (2)
> starting WDT reset utility...
> Unable to start "dm814x-wdtkick" (2)
> starting Board ID driver...
> Unable to start "am335x-boardid" (2)
> Unable to access "/dev/bdid" (2)
> Setting OS Clock from on-board RTC
> Unable to start "rtc" (2)
> Sat Jan 01 00:00:15 GMT 2000
> Starting USB OTG Host driver...
> Starting SPI driver...
> Unable to start "spi-master" (2)
> Starting network driver...
> starting leds driver...
> Unable to start "am335x-leds" (2)
> Unable to access "/dev/leds" (2)
> Setting environment variables...
> done.
> Starting Screen Graphics...
> done.
> Starting HDMI Audio driver...
> Unable to access /dev/snd/pcmC0D1p
> ksh: No controlling tty (open /dev/tty: No such device or address)
> ksh: warning: won't have full job control
>
>
> All of the software that reports "unable to start" does not have execute 
> permissions.  When I tried to add execute permissions by hand, it said the 
> file did not exist.
>
> My build host is linux mint.
>
> Thanks!
>

-- 
For more 

[beagleboard] Re: QNX on beaglebone black

[acheesehead]

I am using QNX 6.50 on the BBB and have no problems.

Are the executables in question on a FAT32 partition? If so, execute 
permissions can't be set. Are you booting from SD card or eMMC? What do 
your partition tables look like on your boot device (fdisk view)? What is 
the output of the mkifs command in the images directory? Post your .build 
file.

On Tuesday, March 1, 2016 at 3:00:18 PM UTC-7, Steven Hartmann wrote:
>
> I hope there is someone here successfully using QNX on the BBB.  I am 
> currently doing a QNX evaluation and am having trouble with the BBB BSP.  I 
> am using the BSP_ti-am335x-beaglebone_br-660_be-660_SVN797070_JBN574.zip 
> BSP.  The package comes with a pre-built image, which boots up fine.  I 
> have been able to do a few test programs with it, but now I need to modify 
> the BSP to change which features are used.  The first step in doing this 
> was to just recompile the BSP to make sure I can recreate the precompiled 
> version.  The build goes fine and creates an image.  I can boot off the 
> image, but it gives a lot of errors:
>
> U-Boot#  fatload mmc 0 8100 ifs-ti-am335x-beaglebone.bin
> reading ifs-ti-am335x-beaglebone.bin
> 5794620 bytes read in 657 ms (8.4 MiB/s)
> U-Boot# go 8100
> ## Starting application at 0x8100 ...
>
> __Board ID__
> header:  ee3355aa
> name:A335BNLT
> 
> BeagleBone Black detected
>
> VFPv3: fpsid=410330c3
> coproc_attach(10): attach fe08a3fc (fe08ad24)
> coproc_attach(11): attach fe08a3fc (fe08ad24)
> Welcome to QNX Neutrino 6.6.0 on the Texas Instruments AM335x BeagleBone 
> (ARMv7 Cortex-A8 core) - Board
> Unable to start "devc-seromap" (2)
> Unable to access "/dev/ser1" (2)
> Unable to access "/dev/ser1" (2)
> Starting MMC/SD driver...
> Unable to start "devb-sdmmc-j5_generic" (2)
> Unable to start "devb-sdmmc-j5_generic" (2)
> starting I2C driver...
> Unable to start "i2c-omap35xx-j5" (2)
> Unable to access "/dev/i2c0" (2)
> starting WDT reset utility...
> Unable to start "dm814x-wdtkick" (2)
> starting Board ID driver...
> Unable to start "am335x-boardid" (2)
> Unable to access "/dev/bdid" (2)
> Setting OS Clock from on-board RTC
> Unable to start "rtc" (2)
> Sat Jan 01 00:00:15 GMT 2000
> Starting USB OTG Host driver...
> Starting SPI driver...
> Unable to start "spi-master" (2)
> Starting network driver...
> starting leds driver...
> Unable to start "am335x-leds" (2)
> Unable to access "/dev/leds" (2)
> Setting environment variables...
> done.
> Starting Screen Graphics...
> done.
> Starting HDMI Audio driver...
> Unable to access /dev/snd/pcmC0D1p
> ksh: No controlling tty (open /dev/tty: No such device or address)
> ksh: warning: won't have full job control
>
>
> All of the software that reports "unable to start" does not have execute 
> permissions.  When I tried to add execute permissions by hand, it said the 
> file did not exist.
>
> My build host is linux mint.
>
> 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: how can i file transfer to PC (Window) from BBB

[acheesehead]

Use a flash drive or SD card.

On Sunday, October 4, 2015 at 5:18:34 AM UTC-6, 멘지 wrote:
>
> I'm using Putty 
>
> and i want to file transfer to my PC (window 7)
>
> I want to run only the C language, without a separate program.
>
> The file is 200kb bmp files.
>
> Is there any way ??
>
> BBB was installed Debian
>

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

[beagleboard] Re: how can i file transfer to PC (Window) from BBB

[acheesehead]

SCP the file.

On Sunday, October 4, 2015 at 5:18:34 AM UTC-6, 멘지 wrote:
>
> I'm using Putty 
>
> and i want to file transfer to my PC (window 7)
>
> I want to run only the C language, without a separate program.
>
> The file is 200kb bmp files.
>
> Is there any way ??
>
> BBB was installed Debian
>

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

Re: [beagleboard] Re: Can a beaglebone black go through a luggage X-ray machine?

[acheesehead]

It was packaged in a metallic enclosure with D38999 connectors with 
protective plastic caps. Should have been immune to ESD. Worked fine before 
the trip, but when I got to my destination, it had funny behavior. When I 
got back home, it was even worse. It was in my checked in luggage on the 
way back. Luckily, I have spares.

On Tuesday, September 22, 2015 at 7:43:36 PM UTC-6, Przemek Klosowski wrote:
>
> On Tue, Sep 22, 2015 at 10:39 AM, acheesehead <achee...@gmail.com 
> > wrote:
>
>> I went through security with one and TSA thought it was suspicious. They 
>> put it under the X-Ray machine and stared at it for about a minute. It has 
>> been confused since then. Sometimes boots, sometimes not. While a brief 
>> exposure is probably OK. A prolonged exposure might fry something.
>>
>> Well, normally, ionizing radiation can only change charge states in 
> internal electrical nodes, i.e. flip bits in memory and internal 
> CPU/chipset logic. In other words, it can't damage anything permanently. 
>
> Theoretically, very high energy Xrays could disrupt crystalline structure 
> within the chips, i.e. damage them permanently, but it requires energy and 
> intensity much larger than that of an airport Xray machine. Whatever your 
> problems are, it's not because of the Xray scan---did the TSA folk 
> touch/handle the BBB? if so, they could have zapped it with static 
> discharge, which is much deadlier than Xrays.
>

-- 
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: Can a beaglebone black go through a luggage X-ray machine?

[acheesehead]

I went through security with one and TSA thought it was suspicious. They 
put it under the X-Ray machine and stared at it for about a minute. It has 
been confused since then. Sometimes boots, sometimes not. While a brief 
exposure is probably OK. A prolonged exposure might fry something.

On Monday, September 21, 2015 at 4:00:13 PM UTC-6, tra...@ualberta.ca wrote:
>
> Can a beaglebone black survive going through a luggage X-Ray machine?

-- 
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] Building Angstrom for Beagleboard xM, ncurses build fails

[acheesehead]

I am stuck. I did the following commands on several different machines with 
different OSs.

git clone git://github.com/Angstrom-distribution/setup-scripts.git
cd setup-scripts
MACHINE=beaglebone ./oebb.sh config beaglebone MACHINE=beaglebone ./oebb.sh 
update MACHINE=beaglebone ./oebb.sh bitbake virtual/kernel

I am consistently getting an error when the build is compiling ncurses. I 
have read that adding CCFLAGS+=-P to the Makefile should fix the problem, 
but does not solve the problem.

Any suggestions?

Thanks in advance.
Todd

fc22 bitbake ncurses
NOTE: Started PRServer with DBfile: 
/home/users/staff/tpeterson/work/setup-scripts/cache/prserv.sqlite3, IP: 
127.0.0.1, PORT: 34760, PID: 9934
Loading cache: 100% 
||
 
ETA:  00:00:00
Loaded 3684 entries from dependency cache.
WARNING: No recipes available for:
  
/home/users/staff/tpeterson/work/setup-scripts/sources/meta-ros/recipes-support/boost/boost_%.bbappend
WARNING: No bb files matched BBFILE_PATTERN_meta-dominion 
'^/home/users/staff/tpeterson/work/setup-scripts/sources/meta-dominion/'
WARNING: No bb files matched BBFILE_PATTERN_meta-beagleboard-extras 
'^/home/users/staff/tpeterson/work/setup-scripts/sources/meta-beagleboard/meta-beagleboard-extras/'
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION= 1.20.0
BUILD_SYS = x86_64-linux
NATIVELSBSTRING   = Fedora-22
TARGET_SYS= arm-angstrom-linux-gnueabi
MACHINE   = beagleboard
DISTRO= angstrom
DISTRO_VERSION= v2013.12
TUNE_FEATURES = armv7a vfp thumb neon callconvention-hard
TARGET_FPU= vfp-neon
meta-angstrom = 
angstrom-v2013.12-yocto1.5:201c60dfb0389fd4c610ff42c268e44a55316142
meta-oe
meta-efl
meta-gpe
meta-gnome
meta-xfce
meta-initramfs
toolchain-layer
meta-multimedia
meta-networking
meta-webserver
meta-ruby
meta-filesystems
meta-perl = 
angstrom-staging-yocto1.5:c763a96b0686090a99a2810bdca3cdb8226c3b57
meta-kde4 = master:d31c8effb0e3f806db2d7eb40c59c5290639d762
meta-opie = master:b241408b31c2ffd941b8b38bd385136ef675a703
meta-java = dora:d031686fedd1f88fb628a8a87916477208377146
meta-browser  = master:fc3969f63bda343c38c40a23f746c560c4735f3e
meta-mono = master:ac286b1682e6bcc486ceb30ef90a936949bbfeab
meta-qt5  = dora:5b5616b63bdf163ea3eb2ca8857c56a393435fe3
meta-systemd  = 
angstrom-staging-yocto1.5:c763a96b0686090a99a2810bdca3cdb8226c3b57
meta-ros  = master:64c8b5edb221263e7fac7c03629c730ade422dff
meta-beagleboard-extras = dora:07fefaa86b118c1aa81f40d1658a17e41bbf1190
meta-uav  = master:6f663cc32532ae66dd6c06d3d79c0f3578975a6c
meta-telephony= master:f71f5ea031d96a5a84bde4531974542ae49f8bee
meta-qt5  = dora:5b5616b63bdf163ea3eb2ca8857c56a393435fe3
common-bsp= dora:07fefaa86b118c1aa81f40d1658a17e41bbf1190
meta-ti   = 
angstrom-staging-yocto1.5:a05532600ea769c0349e526e024304f50c1fdf8c
meta-fsl-arm  = 
angstrom-staging-yocto1.5:48b91b77e9e37eea88637fe403d0a6b0f35dbee9
meta-fsl-arm-extra = dora:375f89b70655be2a17bbde36de6adb4e4a5a6975
meta-nslu2= master:bdcb4297ddb22f4eecddd4d8436cf9b6c6111922
meta-htc
meta-nokia
meta-openmoko
meta-palm = master:537d0c2ab41284012e1ba79716b085a861a6812a
meta-handheld = master:5b5e68a93aae1016f5ac1d057a721b2dbf30b8d8
meta-intel
meta-sugarbay
meta-crownbay
meta-emenlow
meta-fri2
meta-jasperforest
meta-n450 = dora:2ba35c651e7380d399642f4c731c49cc7db4b240
meta-sunxi= master:f1e777d5526ea7c7a4f3a828b21d26c2c0650b83
meta-raspberrypi  = dora:1c696a95f16337e4168a045479a386194d32e18f
meta-minnow   = dora:9aa60d0eaf03fe30670acf581eaf7e57c76b5f99
meta-dominion = master:84c26a4cb3aab9c8eaf2041ac57d01ff547400fc
meta-atmel= 
angstromv2013.12-staging:43499c14ab5c9504fff4771a9024e0e88f8cb356
meta-exynos   = master:ac21b106ce5c4c928f62e8f72ebeac9b02d113e2
meta-linaro
meta-linaro-toolchain = dora:a6b3567c93dd49f74a7e71d8d34c16f8d132578c
meta-beagleboard-extras = dora:07fefaa86b118c1aa81f40d1658a17e41bbf1190
meta  = 
angstrom-staging-yocto1.5:24eaa39a2e25d9ec45ae1eac43485aa91b8c67e0

NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: Function failed: do_compile (log file is located at 
/home/users/staff/tpeterson/work/setup-scripts/build/tmp-angstrom_v2013_12-eglibc/work/x86_64-linux/ncurses-native/5.9-r15.1/temp/log.do_compile.10340)
ERROR: Logfile of failure stored in: 
/home/users/staff/tpeterson/work/setup-scripts/build/tmp-angstrom_v2013_12-eglibc/work/x86_64-linux/ncurses-native/5.9-r15.1/temp/log.do_compile.10340
Log data follows:
| DEBUG: Executing shell function do_compile
| NOTE: make -j2 -C narrowc libs
| make: Entering directory 
'/scratch/tpeterson/setup-scripts/build/tmp-angstrom_v2013_12-eglibc/work/x86_64-linux/ncurses-native/5.9-r15.1/ncurses-5.9/narrowc'
| cd include  

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 stdlib.h
#include stdio.h
#include stdint.h
#include signal.h
#include unistd.h
#include sys/mman.h
#include sys/time.h
#include time.h
#include hw/inout.h

#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 (13)
#define PAD_PU_UP 16

#define PAD_INPUTENABLE (18)

#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 (116)
#define ICLK_OFFSET 0x10
#define EN_GPT9 (110)
#define GPT9_CLKSEL_OFFSET 0x40
#define CLKSEL_GPT9 (17)
#define CM_CLK_BASE 0x48004000
#define FCLK_ENABLE_OFFSET 0xA00
#define ICLK_ENABLE_OFFSET 0xA10
#define GPT10_CLKSEL_OFFSET 0xa40
#define EN_GPT10 (111)
#define CLKSEL_GPT10 (16)
#define EN_GPT11 (112)
#define CLKSEL_GPT11 (17)

#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 (16)
#define TIMER_SCPWM (17)
#define TIMER_PT (112)
#define TIMER_TRG (210)
#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_MODE416) | PAD_INPUTENABLE | 
(PAD_INPUTENABLE16) | PAD_PU_EN | (PAD_PU_EN16); // for switch inputs
out32(padconf_ptr + PAD_CTRL_G130_131, tmp32);
out32(padconf_ptr + PAD_CTRL_G136_137, tmp32);
tmp32 = PAD_MODE4 | (PAD_MODE416) | PAD_INPUTENABLE | 
(PAD_INPUTENABLE16); // for photo sensor inputs
out32(padconf_ptr + PAD_CTRL_G132_133, tmp32);
tmp32 = PAD_MODE4 | (PAD_MODE416) | PAD_INPUTENABLE | 
(PAD_INPUTENABLE16) | (PAD_PU_EN16); // 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 + 

[beagleboard] Re: Reading BBB ADC's using QNX

[acheesehead]

Got it!

Steps 1  2 are not necessary. The rest is pretty straight-forward.

On Wednesday, March 11, 2015 at 2:27:30 PM UTC-6, acheesehead wrote:

 I want to read the BBB ADC inputs using the QNX operating system. As no 
 driver is provided in the QNX BSP, I need to write low-level C code to do 
 this. I figure I need to do the following steps:

 1. Put the pins in the right mux mode
 2. Turn on the clock to the ADC
 3. Set up the 'steps'
 4. Start a conversion sequence
 5. Wait for the sequence to end
 6. Read the sampled values

 I have not found any low-level code that does this. It would be greatly 
 appreciated if anybody could provide example register-level code 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.

[beagleboard] BeagleBoard xM assembly drawing

[acheesehead]

We are trying to change the boot order to support booting from MMC2 and 
MMC1, which requires swapping the boot resistors on the BOOT0 and BOOT1 
lines. We are having trouble finding R125. Is there an assembly drawing 
available for the BeagleBoard xM that would show us 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/groups/opt_out.