Re: [beagleboard] Re: Wiznet W5500 ethernet module driver can't install

[santosh aiwale]

On Wednesday, 17 January 2018 22:35:57 UTC+5:30, RobertCNelson wrote:
>
> On Wed, Jan 17, 2018 at 1:37 AM, santosh aiwale  > wrote: 
> > 
> > 
> > On Tuesday, 16 January 2018 22:21:39 UTC+5:30, santosh aiwale wrote: 
> >> 
> >> The Wiznet W5500 is working on SPI with BBB. 
> >> I am working on pocket beagle bone using Linux beaglebone 
> 4.4.91-ti-r133. 
> >> here is the driver link https://github.com/borg42/w5x00. 
> >> also kernel module build not available. 
> >> 
> > Making Connection with SPI0 
> > and adding uEnv file with 
> > uboot_overlay_addr0=/lib/firmware/PB-SPI0-ETH-WIZ-CLICK.dtbo and then 
> reboot 
> > but not getting boot up with this if remove the module then getting 
> bootup 
>
> Please provide more information about your board, using this tool: 
>
> sudo /opt/scripts/tools/version.sh 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>
git:/opt/scripts/:[d36fe9a7be9ebfc872b10a470e904ab4c61c4516]
eeprom:[A335PBGL00A21741GPB43347]
dogtag:[BeagleBoard.org Debian Image 2017-10-10]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
2017.09-2-g0f3f1c7907]
kernel:[4.4.91-ti-r133]
nodejs:[v6.11.4]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_addr0=/lib/firmware/PB-SPI1-ETH-WIZ-CLICK.dtbo]
uboot_overlay_options:[uboot_overlay_addr1=/lib/firmware/PB-SPI0-ETH-WIZ-CLICK.dtbo]
uboot_overlay_options:[disable_uboot_overlay_emmc=1]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[disable_uboot_overlay_audio=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg:[bb-cape-overlays]:[4.4.20180114.0-0rcnee1~stretch+20180115]
pkg:[bb-wl18xx-firmware]:[1.20170829-0rcnee2~stretch+20180104]
pkg:[firmware-ti-connectivity]:[20170823-1rcnee0~stretch+20170830]

*** when connecting SPI0 then not geting bootup beagle board
and connecting with SPI1 not communicating 
ifconfig result shown

eth0: flags=-28605  mtu 1500
inet 169.254.136.246  netmask 255.255.0.0  broadcast 169.254.255.255
inet6 fe80::34ad:5dff:fe89:940  prefixlen 64  scopeid 0x20
ether de:ad:be:ef:ca:fe  txqueuelen 1000  (Ethernet)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 40  bytes 9097 (8.8 KiB)
TX errors 39  dropped 0 overruns 0  carrier 0  collisions 0

 

-- 
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/f6cac405-bf29-44d0-b55d-2d87ff84dc27%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Enabling I2C1 on Beaglebone black

[Madhu K]

Hello,

Yes

On Tue, Jan 16, 2018 at 7:56 PM, inisider  wrote:
> Hello.
>
> Did U solve this issue?
>
>
> среда, 28 декабря 2016 г., 9:09:55 UTC+2 пользователь Madhu K написал:
>>
>> Hi All,
>>
>> I am trying to enable the I2C1 on beaglebone black board. I have written
>> overlay to enable the i2c1, please verify below snippet and correct me if
>> anything wrong in that.
>>
>> i2c2: i2c@4819c000 {
>> pinctrl-names = "default";
>> pinctrl-0 = <&i2c2_pins>;
>> status = "okay";
>> clock-frequency = <10>;
>>
>> nintend : nintend@ {
>>
>>compatible = "nunchuk";
>>reg = ;
>>  };
>>  };
>>
>> i2c2_pins: pinmux_i2c2_pins {
>> pinctrl-single,pins = <
>> 0x158 0x72
>> 0x15c 0x72
>> >;
>> };
>>
>>
>> I am trying to add this snippet to am335x-customboneblack.dts.
>>
>> Thanks & regards,
>> Madhu
>
> --
> 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/7b34e987-e5c8-49e9-9f06-62e1254eee43%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/CAA2oCOkoNxDcYa1ECgEGQE4q3u%3Dg5s%2B-U9MHdeXKjv%3DjTg2b4Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Wiznet W5500 ethernet module driver can't install

[santosh aiwale]

On Wednesday, 17 January 2018 22:35:57 UTC+5:30, RobertCNelson wrote:
>
> On Wed, Jan 17, 2018 at 1:37 AM, santosh aiwale  > wrote: 
> > 
> > 
> > On Tuesday, 16 January 2018 22:21:39 UTC+5:30, santosh aiwale wrote: 
> >> 
> >> The Wiznet W5500 is working on SPI with BBB. 
> >> I am working on pocket beagle bone using Linux beaglebone 
> 4.4.91-ti-r133. 
> >> here is the driver link https://github.com/borg42/w5x00. 
> >> also kernel module build not available. 
> >> 
> > Making Connection with SPI0 
> > and adding uEnv file with 
> > uboot_overlay_addr0=/lib/firmware/PB-SPI0-ETH-WIZ-CLICK.dtbo and then 
> reboot 
> > but not getting boot up with this if remove the module then getting 
> bootup 
>
> Please provide more information about your board, using this tool: 
>
> sudo /opt/scripts/tools/version.sh 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>



git:/opt/scripts/:[d36fe9a7be9ebfc872b10a470e904ab4c61c4516]
eeprom:[A335BNLT000C1739BBBG1930]
dogtag:[BeagleBoard.org Debian Image 2017-10-10]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
2017.09-2-g0f3f1c7907]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2016.03-1-gd12d09f]
kernel:[4.4.91-ti-r133]
nodejs:[v6.11.4]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_addr0=/lib/firmware/PB-SPI1-ETH-WIZ-CLICK.dtbo]
uboot_overlay_options:[uboot_overlay_addr1=/lib/firmware/PB-SPI0-ETH-WIZ-CLICK.dtbo]
uboot_overlay_options:[disable_uboot_overlay_emmc=1]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[disable_uboot_overlay_audio=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
WARNING:pkg:[bb-cape-overlays]:[NOT_INSTALLED]
WARNING:pkg:[bb-wl18xx-firmware]:[NOT_INSTALLED]
WARNING:pkg:[firmware-ti-connectivity]:[NOT_INSTALLED] 

-- 
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/b526412c-2b11-4428-8532-f1edf3f7f18b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] IoT variants?

['Luther Goh Lu Feng' via BeagleBoard]

I like console as it is very minimal and allows me to just add on stuff I 
need. So I skip any "bloat"


--Luther

On Thursday, January 18, 2018 at 5:54:52 AM UTC+8, Rick M wrote:
>
> Thanks. What’s “console” then? 
>
> -- 
> Rick Mann 
> rm...@latencyzero.com  
>
> > On Jan 17, 2018, at 13:49, Robert Nelson  > wrote: 
> > 
> >> On Wed, Jan 17, 2018 at 3:33 PM, Rick Mann  > wrote: 
> >> Is there something that describes what's different about IoT OS image 
> variants? 
> > 
> > IOT = LXQT - Xorg 
> > 
> > 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/29bbf161-8f59-4a24-a559-c2acf736ca15%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Which kernel is better for stretch? 4.4.x or 4.9.x?

['Luther Goh Lu Feng' via BeagleBoard]

I see. I am actually more inclined to use 4.4.x-ti as it is listed as being 
supported till Feb 2022

On Thursday, January 18, 2018 at 1:07:16 AM UTC+8, RobertCNelson wrote:
>
> On Wed, Jan 17, 2018 at 12:38 AM, 'Luther Goh Lu Feng' via BeagleBoard 
> > wrote: 
> > Downloading the Stretch IoT (non-GUI) from beagleboard.org[1] yields an 
> > image with kernel 4.4.91-ti-r133. A Stretch IOT image from Robert 
> Nelson[2] 
> > has kernel 4.9.74-ti-r90. My question specifically is: why the 
> difference, 
> > and is one preferable over the other? Thanks 
> > 
> > [1] https://beagleboard.org/latest-images 
> > [2] 
> > 
> https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Stretch_Snapshot_iot 
>
> Well, we are migrating to v4.9.x-ti and then v4.14.x-ti.. 
>
> Feel free to still use v4.4.x-ti, as it's still being tested.. 
>
> 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/927a622c-069b-4a51-9787-693b695e5a28%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: [beagle-alpha] Building a device tree overlay for your new PocketCape design

[Robert Nelson]

On Wed, Jan 17, 2018 at 5:57 PM, Joshua Datko  wrote:
> Hey Jason,
>
> First of all thanks for all the work (and from many others on this) for the
> BeagleBone et. al.!
>
> This is just my 2c and it's probably worth that much.
>
> What I would say is that it shouldn't matter that the board uses device tree
> or . What designers of capes want, I think, is the
> ability to configure the beaglebone (or pocket beagle) as they like. With
> the device tree, as you've shown, this is how one accomplishes that task.
>
> But I'm stumbled through building device tree fragments before and it's a
> bit painful.
>
> What I would suggest is a tool that makes device tree generation easier.
> This probably should be a GUI (with scripting option). But as a HW designer
> for a cape, if I could click pins on a GUI, set modes, defaults, etc... and
> out spit a device tree fragment, I would think that'd be cool.

Wasn't there a GSOC nodejs "todo" this in the 3.8.x era?

There is also a QT5 gui for cape-universal:

https://github.com/machinekoder/BBIOConfig

We pretty much setup cape-universal by default on all boards today...

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/CAOCHtYgw6o_G%3DXNPZm556r2gtcZPRhnB9wLAvkafia%3DzhmYRJQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: [beagle-alpha] Building a device tree overlay for your new PocketCape design

[Jason Kridner]

For pinmux only, existing tools could be reimplemented or modified, but the
real challenge is in the hundreds of possible drivers and their
configurations. It would be interesting to see if those could automatically
be extracted from a running kernel with symbols.
On Wed, Jan 17, 2018 at 6:58 PM Joshua Datko  wrote:

> Hey Jason,
>
> First of all thanks for all the work (and from many others on this) for
> the BeagleBone et. al.!
>
> This is just my 2c and it's probably worth that much.
>
> What I would say is that it shouldn't matter that the board uses device
> tree or . What designers of capes want, I think, is
> the ability to configure the beaglebone (or pocket beagle) as they like.
> With the device tree, as you've shown, this is how one accomplishes that
> task.
>
> But I'm stumbled through building device tree fragments before and it's a
> bit painful.
>
> What I would suggest is a tool that makes device tree generation easier.
> This probably should be a GUI (with scripting option). But as a HW designer
> for a cape, if I could click pins on a GUI, set modes, defaults, etc... and
> out spit a device tree fragment, I would think that'd be cool.
>
> I'm also not volunteering to build this :) But if the device tree fragment
> is the output, clearly a nicer frontend can be made to produce this. And I
> realize there's all sorts of complexity here, I'm just suggest the idea of
> a tool to more easily produce device tree fragments.
>
> Josh
>
-- 
https://beagleboard.org/about

-- 
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/CA%2BT6QPmO-Bt9S9mM48zP6fDcpKRvMAnZdKrsdpEbosA-6QJrrg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: [beagle-alpha] Building a device tree overlay for your new PocketCape design

[Joshua Datko]

Hey Jason,

First of all thanks for all the work (and from many others on this) for the
BeagleBone et. al.!

This is just my 2c and it's probably worth that much.

What I would say is that it shouldn't matter that the board uses device
tree or . What designers of capes want, I think, is
the ability to configure the beaglebone (or pocket beagle) as they like.
With the device tree, as you've shown, this is how one accomplishes that
task.

But I'm stumbled through building device tree fragments before and it's a
bit painful.

What I would suggest is a tool that makes device tree generation easier.
This probably should be a GUI (with scripting option). But as a HW designer
for a cape, if I could click pins on a GUI, set modes, defaults, etc... and
out spit a device tree fragment, I would think that'd be cool.

I'm also not volunteering to build this :) But if the device tree fragment
is the output, clearly a nicer frontend can be made to produce this. And I
realize there's all sorts of complexity here, I'm just suggest the idea of
a tool to more easily produce device tree fragments.

Josh

-- 
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/CAC7jEXcOt_PqDwG8qSStvwUQfOgKHfrqi-3MicmUUxSQHBd8PA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Kernel and uboot source code for Beagle bone green wireless

[rockwall13]

Hi

I spoke with Jason Krinder at a BeagleBone workshop at Texas A&M University 
over the winter holiday break.

After the  workshop I talked with him regarding about my Capstone project.

For my project, my team needs to use Wi-Fi mesh functionality. So we 
decided to use the BBGW.

However, we have run into issues where BBGW does not fully install the 
functional Wi-link 8 driver.

I have had trouble with installing the latest Wi-link 8 driver. So Jason 
Krinder suggested we contact you because, you were able to successfully 
install the Wi-link 8 driver on Beaglebone. 

If you could please contact me at rlarltn...@tamu.edu my team would greatly 
appreciate any help you could provide regarding our issue.



Thank you in advance for any assistance you can provide, 

Gi-Soo Kim 

On Tuesday, November 14, 2017 at 8:32:50 AM UTC-6, drhun...@gmail.com wrote:
>
> Hi Trinadh,
> This is not actually an ERROR, it should be a warning as the WL18xx driver 
> will create a default configuration and use it instead. So it is probably 
> not the cause of your failure to boot.
>
> Having said that using the wl18xx-conf.bin that Robert pointed you to in 
> your filesystem is the best solution. 
> Iain 
>
> On Monday, 13 November 2017 17:51:58 UTC, Trinadh Morla wrote:
>>
>> Hi,
>>
>> While porting Linux kernel into beagle bone green wireless board i am 
>> getting error "wlcore: ERROR could not get configuration binary 
>> ti-connectivity/wl18xx-conf.bin: -2" and then board was not booting up. Can 
>> you please help to this issue?
>>
>> Thanks,
>> Trinadh.
>>
>>
>> On Mon, Nov 13, 2017 at 8:16 PM, Robert Nelson  
>> wrote:
>>
>>> On Mon, Nov 13, 2017 at 12:55 AM,   wrote:
>>> > Hi,
>>> >
>>> > Could you please help me where can i get u boot and Linux kernel 
>>> source code
>>> > to support beagle-bone green wireless board?
>>>
>>> Both are mainline:
>>>
>>> https://eewiki.net/display/linuxonarm/BeagleBone+Black
>>>
>>> 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/2bc051f0-9a85-4313-aa1a-7efc808fe86e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] IoT variants?

[Robert Nelson]

On Wed, Jan 17, 2018 at 3:54 PM, Rick Mann  wrote:
> Thanks. What’s “console” then?

Enough tools to flash the "eMMC".. ;)

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/CAOCHtYiXe_b6ZaTek4s6vRUL7apv4QQQ_9SBi%3DXe-4TrXrCEtw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Pulsing Power Up

[Graham Haddock]

I'l look at it with both a Voltmeter and an oscilloscope.

I have a B&K bench supply that when you turn it on, with a BBB already
attached, did an overshoot up to around 5.7 Volts before settling back to
5.0 Volts.
It would trip the self protect on the PMIC almost every time you tried to
start the BBB.

--- Graham

==

On Wed, Jan 17, 2018 at 3:10 PM, Chip Wachob  wrote:

> I have a static 1.5A resistive load on the supply which has a 1A minimum
> load.  That would leave me with 10.5 A of wiggle room.  Out of which I need
> just less than 2A.
>
> I'll revisit the supply level, but I'm fairly certain that I am well
> within those ranges.
>
>
>
> On Wed, Jan 17, 2018 at 4:06 PM, Graham  wrote:
>
>> Still sounds like a power problem.
>>
>> A lot of 12 Amp supplies might go out of regulation at almost no load.
>> They typically need to be loaded to ten percent of max rated output load
>> to be within Voltage spec.
>>
>> The Beagle supply needs to stay between 4.5 and 5.5 Volts under all load
>> conditions.
>>
>> I recommend you stay between 4.75 and 5.25 to have noise margin against
>> the PMIC going into self-protect.
>>
>> --- Graham
>>
>> ==
>>
>> On Wednesday, January 17, 2018 at 2:03:32 PM UTC-6, epar...@gmail.com
>> wrote:
>>>
>>> Hello,
>>>
>>> I just finished reading a lot of posts on the topic of starting up the
>>> BBB and various issues that folks have had.  I didn't see anything that
>>> reflected my situation, so I'm going to reach out in hopes that someone in
>>> the group can cast some light on this.
>>>
>>> I have a BBB with a custom Cape.  The Cape is designed to interface the
>>> BBB to a cap-touch color screen.  The Cape contains the backlight power
>>> supply for the display and the obligatory EEPROM for ID, addressing pins,
>>> etc.  Very similar to the BB-CAPE-DISP-CT43
>>>  available for purchase.
>>>
>>> What is different in my case is that I'm supplying power to the Cape
>>> (5V).  The power then goes to the Cape connector on P9, pins 5 & 6.  This
>>> would be equivalent to supplying power to the BBB via the barrel connector.
>>>
>>> The BBB is internally booting (no SD, etc) with custom code.  I have
>>> written the shipping code image into the board and I get the same results.
>>>
>>> I've made several dozen of these assemblies now, and so far I have two
>>> that exhibit this odd behavior.
>>>
>>> The symptom:  The BBB will attempt to start, will shut down, and will
>>> try to start once more at a rate of about once per second.  Sometimes this
>>> only happens a couple of times, other times I simply give up after 60 of
>>> these failed boot cycles.  There is no consistency to the number of tries a
>>> board will go through.
>>>
>>> I'm using a very robust power supply that meets or exceeds the PMIC slew
>>> rate requirements.  The supply is capable of supplying 12A @ 5VDC.
>>>
>>> When the BBB is attempting to boot, the blue LED adjacent to the barrel
>>> connector (commonly referred to as the Power LED) will flash briefly.
>>>
>>> There are occasions when a 'bad' assembly will boot without issue, but
>>> most frequently it comes up in this flashing state.
>>>
>>> I've checked for the usual suspects, bad solder joints, interconnects,
>>> etc, without finding anything.  I know that my inrush current is on the
>>> order of 1.7 to 1.8 A at the initial startup, but that drops off
>>> significantly after the caps are charged up.
>>>
>>> Has anyone out there experienced this pulsing behavior and found a root
>>> cause and possibly a fix?
>>>
>>> One thought that I had was to monitor the bebug  port (X1), but is there
>>> even enough up time to have this be useful?
>>>
>>> Thank you to everyone in advance for your insight.
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>> pic/beagleboard/IbYlM9n9DIY/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> beagleboard+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/beagleboard/ffe872d5-cadb-460f-8f1f-709727d1d7a1%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 a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/beagleboard/IbYlM9n9DIY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https:

[beagleboard] Re: Default debian image not booting

[Jens N]

Update: It seems to boot and be stable when booting without the hdmi cable 
attached.

-- 
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/aa452244-a227-47ed-a4dd-ada6e2c23ccb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] IoT variants?

[Rick Mann]

Thanks. What’s “console” then?

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

> On Jan 17, 2018, at 13:49, Robert Nelson  wrote:
> 
>> On Wed, Jan 17, 2018 at 3:33 PM, Rick Mann  wrote:
>> Is there something that describes what's different about IoT OS image 
>> variants?
> 
> IOT = LXQT - Xorg
> 
> 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/C7620E05-DA4F-4B7A-8FE5-225C848EA838%40latencyzero.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] IoT variants?

[Robert Nelson]

On Wed, Jan 17, 2018 at 3:33 PM, Rick Mann  wrote:
> Is there something that describes what's different about IoT OS image 
> variants?

IOT = LXQT - Xorg

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/CAOCHtYhFwnmK8U-FSJPCqFj54%3Dz5Jnfd30x1R1qLVcN0kuH-%2BA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] IoT variants?

[Rick Mann]

Is there something that describes what's different about IoT OS image variants?

TIA,

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


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/678A747B-30EC-4A91-B813-83DD715F37FB%40latencyzero.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Pulsing Power Up

[Chip Wachob]

I have a static 1.5A resistive load on the supply which has a 1A minimum
load.  That would leave me with 10.5 A of wiggle room.  Out of which I need
just less than 2A.

I'll revisit the supply level, but I'm fairly certain that I am well within
those ranges.



On Wed, Jan 17, 2018 at 4:06 PM, Graham  wrote:

> Still sounds like a power problem.
>
> A lot of 12 Amp supplies might go out of regulation at almost no load.
> They typically need to be loaded to ten percent of max rated output load
> to be within Voltage spec.
>
> The Beagle supply needs to stay between 4.5 and 5.5 Volts under all load
> conditions.
>
> I recommend you stay between 4.75 and 5.25 to have noise margin against
> the PMIC going into self-protect.
>
> --- Graham
>
> ==
>
> On Wednesday, January 17, 2018 at 2:03:32 PM UTC-6, epar...@gmail.com
> wrote:
>>
>> Hello,
>>
>> I just finished reading a lot of posts on the topic of starting up the
>> BBB and various issues that folks have had.  I didn't see anything that
>> reflected my situation, so I'm going to reach out in hopes that someone in
>> the group can cast some light on this.
>>
>> I have a BBB with a custom Cape.  The Cape is designed to interface the
>> BBB to a cap-touch color screen.  The Cape contains the backlight power
>> supply for the display and the obligatory EEPROM for ID, addressing pins,
>> etc.  Very similar to the BB-CAPE-DISP-CT43 
>> available for purchase.
>>
>> What is different in my case is that I'm supplying power to the Cape
>> (5V).  The power then goes to the Cape connector on P9, pins 5 & 6.  This
>> would be equivalent to supplying power to the BBB via the barrel connector.
>>
>> The BBB is internally booting (no SD, etc) with custom code.  I have
>> written the shipping code image into the board and I get the same results.
>>
>> I've made several dozen of these assemblies now, and so far I have two
>> that exhibit this odd behavior.
>>
>> The symptom:  The BBB will attempt to start, will shut down, and will try
>> to start once more at a rate of about once per second.  Sometimes this only
>> happens a couple of times, other times I simply give up after 60 of these
>> failed boot cycles.  There is no consistency to the number of tries a board
>> will go through.
>>
>> I'm using a very robust power supply that meets or exceeds the PMIC slew
>> rate requirements.  The supply is capable of supplying 12A @ 5VDC.
>>
>> When the BBB is attempting to boot, the blue LED adjacent to the barrel
>> connector (commonly referred to as the Power LED) will flash briefly.
>>
>> There are occasions when a 'bad' assembly will boot without issue, but
>> most frequently it comes up in this flashing state.
>>
>> I've checked for the usual suspects, bad solder joints, interconnects,
>> etc, without finding anything.  I know that my inrush current is on the
>> order of 1.7 to 1.8 A at the initial startup, but that drops off
>> significantly after the caps are charged up.
>>
>> Has anyone out there experienced this pulsing behavior and found a root
>> cause and possibly a fix?
>>
>> One thought that I had was to monitor the bebug  port (X1), but is there
>> even enough up time to have this be useful?
>>
>> Thank you to everyone in advance for your insight.
>>
>>
>>
>>
>>
>>
>> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/beagleboard/IbYlM9n9DIY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/ffe872d5-cadb-460f-8f1f-709727d1d7a1%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/CAEaoV1TQTrsM-0D%2BubMX028Mcz9ZKNVQvuff9U2EHpAanatsgA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Pulsing Power Up

[Graham]

Still sounds like a power problem.

A lot of 12 Amp supplies might go out of regulation at almost no load.
They typically need to be loaded to ten percent of max rated output load to 
be within Voltage spec.

The Beagle supply needs to stay between 4.5 and 5.5 Volts under all load 
conditions.

I recommend you stay between 4.75 and 5.25 to have noise margin against the 
PMIC going into self-protect.

--- Graham

==

On Wednesday, January 17, 2018 at 2:03:32 PM UTC-6, epar...@gmail.com wrote:
>
> Hello,
>
> I just finished reading a lot of posts on the topic of starting up the BBB 
> and various issues that folks have had.  I didn't see anything that 
> reflected my situation, so I'm going to reach out in hopes that someone in 
> the group can cast some light on this.
>
> I have a BBB with a custom Cape.  The Cape is designed to interface the 
> BBB to a cap-touch color screen.  The Cape contains the backlight power 
> supply for the display and the obligatory EEPROM for ID, addressing pins, 
> etc.  Very similar to the BB-CAPE-DISP-CT43  
> available for purchase. 
>
> What is different in my case is that I'm supplying power to the Cape 
> (5V).  The power then goes to the Cape connector on P9, pins 5 & 6.  This 
> would be equivalent to supplying power to the BBB via the barrel connector.
>
> The BBB is internally booting (no SD, etc) with custom code.  I have 
> written the shipping code image into the board and I get the same results.
>
> I've made several dozen of these assemblies now, and so far I have two 
> that exhibit this odd behavior.
>
> The symptom:  The BBB will attempt to start, will shut down, and will try 
> to start once more at a rate of about once per second.  Sometimes this only 
> happens a couple of times, other times I simply give up after 60 of these 
> failed boot cycles.  There is no consistency to the number of tries a board 
> will go through.
>
> I'm using a very robust power supply that meets or exceeds the PMIC slew 
> rate requirements.  The supply is capable of supplying 12A @ 5VDC.
>
> When the BBB is attempting to boot, the blue LED adjacent to the barrel 
> connector (commonly referred to as the Power LED) will flash briefly.
>
> There are occasions when a 'bad' assembly will boot without issue, but 
> most frequently it comes up in this flashing state.
>
> I've checked for the usual suspects, bad solder joints, interconnects, 
> etc, without finding anything.  I know that my inrush current is on the 
> order of 1.7 to 1.8 A at the initial startup, but that drops off 
> significantly after the caps are charged up.  
>
> Has anyone out there experienced this pulsing behavior and found a root 
> cause and possibly a fix?
>
> One thought that I had was to monitor the bebug  port (X1), but is there 
> even enough up time to have this be useful?
>
> Thank you to everyone in advance for your insight.
>
>
>
>
>
>
>

-- 
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/ffe872d5-cadb-460f-8f1f-709727d1d7a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Pulsing Power Up

[epartsman]

Hello,

I just finished reading a lot of posts on the topic of starting up the BBB 
and various issues that folks have had.  I didn't see anything that 
reflected my situation, so I'm going to reach out in hopes that someone in 
the group can cast some light on this.

I have a BBB with a custom Cape.  The Cape is designed to interface the BBB 
to a cap-touch color screen.  The Cape contains the backlight power supply 
for the display and the obligatory EEPROM for ID, addressing pins, etc.  
Very similar to the BB-CAPE-DISP-CT43  
available for purchase. 

What is different in my case is that I'm supplying power to the Cape (5V).  
The power then goes to the Cape connector on P9, pins 5 & 6.  This would be 
equivalent to supplying power to the BBB via the barrel connector.

The BBB is internally booting (no SD, etc) with custom code.  I have 
written the shipping code image into the board and I get the same results.

I've made several dozen of these assemblies now, and so far I have two that 
exhibit this odd behavior.

The symptom:  The BBB will attempt to start, will shut down, and will try 
to start once more at a rate of about once per second.  Sometimes this only 
happens a couple of times, other times I simply give up after 60 of these 
failed boot cycles.  There is no consistency to the number of tries a board 
will go through.

I'm using a very robust power supply that meets or exceeds the PMIC slew 
rate requirements.  The supply is capable of supplying 12A @ 5VDC.

When the BBB is attempting to boot, the blue LED adjacent to the barrel 
connector (commonly referred to as the Power LED) will flash briefly.

There are occasions when a 'bad' assembly will boot without issue, but most 
frequently it comes up in this flashing state.

I've checked for the usual suspects, bad solder joints, interconnects, etc, 
without finding anything.  I know that my inrush current is on the order of 
1.7 to 1.8 A at the initial startup, but that drops off significantly after 
the caps are charged up.  

Has anyone out there experienced this pulsing behavior and found a root 
cause and possibly a fix?

One thought that I had was to monitor the bebug  port (X1), but is there 
even enough up time to have this be useful?

Thank you to everyone in advance for your insight.






-- 
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/8f22dd81-53cd-4a1d-b619-7b382fe9ee92%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] chromium issue with latest Debian download

[Hartley Sweeten]

On Monday, January 15, 2018 at 3:09:00 PM UTC-7, Hartley Sweeten wrote:
>
> On Monday, January 15, 2018 at 12:44:25 PM UTC-7, RobertCNelson wrote:
>>
>> On Mon, Jan 15, 2018 at 2:13 AM,   wrote: 
>> > I downloaded the latest version of Debian(Stretch) today.  When I try 
>> to do 
>> > apt-get, I get a message that chromium-common is needing to be fixed 
>> and 
>> > recommends either auto remove or apt --fix-broken install.  fix-broken 
>>  says 
>>
>> run: 
>>
>> sudo apt --fix-broken install 
>>
>> and chromium will properly update.. 
>>
>
> That doesn't seem to work. It still returns the error message. Following 
> is the full output: 
>
>  debian@beaglebone:~$ sudo apt --fix-broken install
> [sudo] password for debian: 
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Correcting dependencies... Done
> The following packages were automatically installed and are no longer 
> required:
>   chromium-common libllvm4.0 libtxc-dxtn-s2tc
> Use 'sudo apt autoremove' to remove them.
> The following additional packages will be installed:
>   chromium
> Suggested packages:
>   chromium-l10n chromium-shell chromium-driver chromium-widevine
> The following packages will be upgraded:
>   chromium
> 1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> Need to get 38.3 MB of archives.
> After this operation, 1,739 kB of additional disk space will be used.
> Do you want to continue? [Y/n] 
> Get:1 http://repos.rcn-ee.com/debian stretch/main armhf chromium armhf 
> 63.0.3239.84-1~deb9u1rcnee0~stretch+20171227 [38.3 MB]
> Fetched 38.3 MB in 8s (4,596 kB/s)
> 
>
> (Reading database ... 73888 files and directories currently installed.)
> Preparing to unpack 
> .../chromium_63.0.3239.84-1~deb9u1rcnee0~stretch+20171227_armhf.deb ...
> Unpacking chromium (63.0.3239.84-1~deb9u1rcnee0~stretch+20171227) over 
> (60.0.3112.78-1rcnee0~stretch+20170806) ...
> dpkg: error processing archive 
> /var/cache/apt/archives/chromium_63.0.3239.84-1~deb9u1rcnee0~stretch+20171227_armhf.deb
>  
> (--unpack):
>  trying to overwrite '/usr/lib/chromium/natives_blob.bin', which is also 
> in package chromium-common 61.0.3163.100-2rcnee0~stretch+20170927
> dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
> Errors were encountered while processing:
>
>  
> /var/cache/apt/archives/chromium_63.0.3239.84-1~deb9u1rcnee0~stretch+20171227_armhf.deb
> E: Sub-process /usr/bin/dpkg returned an error code (1)
>

Any update on how to upgrade chromium?

With a clean install of  bone-debian-9.1-lxqt-armhf-2017-08-31-4gb.img.xz I 
tried the 'apt update' apt upgrade' and still get the:

Unpacking chromium (63.0.3239.84-1~deb9u1rcnee0~stretch+20171227) over 
(60.0.3112.78-1rcnee0~stretch+20170806) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-Wl1Vqv/035-chromium_63.0.3239.84-1~deb9u1rcnee0~stretch+20171227_armhf.deb
 
(--unpack):
 trying to overwrite '/usr/lib/chromium/natives_blob.bin', which is also in 
package chromium-common 60.0.3112.78-1rcnee0~stretch+20170806
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)

A 'apt --fix-broken install' then gives:

Reading package lists... Done
Building dependency tree
Reading state information... Done
Correcting dependencies... Done
The following packages were automatically installed and are no longer 
required:
  chromium-common libllvm4.0 libtxc-dxtn-s2tc
Use 'sudo apt autoremove' to remove them.
The following additional packages will be installed:
  chromium
Suggested packages:
  chromium-l10n chromium-shell chromium-driver chromium-widevine
The following packages will be upgraded:
  chromium
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
145 not fully installed or removed.
Need to get 38.3 MB of archives.
After this operation, 1,739 kB of additional disk space will be used.
Do you want to continue? [Y/n] 
Get:1 http://repos.rcn-ee.com/debian stretch/main armhf chromium armhf 
63.0.3239.84-1~deb9u1rcnee0~stretch+20171227 [38.3 MB]
Fetched 38.3 MB in 6s (5,570 kB/s)  

 
(Reading database ... 76754 files and directories currently installed.)
Preparing to unpack 
.../chromium_63.0.3239.84-1~deb9u1rcnee0~stretch+20171227_armhf.deb ...
Unpacking chromium (63.0.3239.84-1~deb9u1rcnee0~stretch+20171227) over 
(60.0.3112.78-1rcnee0~stretch+20170806) ...
dpkg: error processing archive 
/var/cache/apt/archives/chromium_63.0.3239.84-1~deb9u1rcnee0~stretch+20171227_armhf.deb
 
(--unpack):
 trying to overwrite '/usr/lib/chromium/natives_blob.bin', which is also in 
package chromium-common 61.0.3163.100-2rcnee0~stretch+20170927
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Er

Re: [beagleboard] sysfs: cannot create duplicate filename '/bus/platform/devices/4a300000.pruss'

[Robert Nelson]

On Wed, Jan 17, 2018 at 1:31 PM, Hartley Sweeten  wrote:
> Hello all,
>
> I was trying the bone-debian-9.1-lxqt-armhf-2017-08-31-4gb.img.xz with a
> Newhaven NHD-7.0CTP-CAPE-N. It boots up fine and the screen and capacitive
> touchscreen work great. But I noticed this WARNING in the dmesg:
>

> This warning shows up with the 4.9.45-ti-r57 kernel from the image and with
> the 4.9.76-ti-r91 kernel after doing a sudo
> /opt/scripts/tools/update_kernel.sh.
>
> Is this a known issue in the kernel or do I have something setup
> incorrectly?
>
> This is the output from the versions.sh script:
>
> $ sudo /opt/scripts/tools/version.sh
> git:/opt/scripts/:[714e162ba98cf3d2897e7fc95e951c6df15a7d0a]
> eeprom:[A335BNLT00C05014BBBK0A84]
> model:[TI_AM335x_BeagleBone_Black]
> dogtag:[BeagleBoard.org Debian Image 2017-08-31]
> bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot
> 2018.01-2-gcc9c2d1992]
> kernel:[4.9.76-ti-r91]
> nodejs:[v6.11.2]
> uboot_overlay_options:[enable_uboot_overlays=1]
> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo]

In /boot/uEnv.txt comment out:

from:
uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo

to:
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo

v4.9.x-ti uses remoteproc_pruss and you can't switch to the other
"uio_pruss" option..

> uboot_overlay_options:[enable_uboot_cape_universal=1]
> pkg:[bb-cape-overlays]:[4.4.20170728.0-0rcnee1~stretch+20170728]
> pkg:[bb-wl18xx-firmware]:[1.20170829-0rcnee1~stretch+20170829]
> pkg:[firmware-ti-connectivity]:[20170823-1rcnee0~stretch+20170830]
> dmesg | grep pinctrl-single
> [1.362988] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size
> 568
> [1.750855] pinctrl-single 44e10800.pinmux: pin PIN95 already requested
> by ocp:P9_19_pinmux; cannot claim for 4819c000.i2c
> [1.762096] pinctrl-single 44e10800.pinmux: pin-95 (4819c000.i2c) status
> -22
> [1.769223] pinctrl-single 44e10800.pinmux: could not request pin 95
> (PIN95) from group pinmux_bb_i2c2_pins  on device pinctrl-single
> END

^ this is caused by :
pkg:[bb-cape-overlays]:[4.4.20170728.0-0rcnee1~stretch+20170728] (it's
too old)

run:

sudo apt update ; sudo apt upgrade bb-cape-overlay

and reboot:

> I also notices this on the serial console when the board boots:
>
> Starting kernel ...
>
> [0.000925] clocksource_probe: no matching clocksources found
> [1.369280] wkup_m3_ipc 44e11324.wkup_m3_ipc: could not get rproc handle
> [1.648806] omap_voltage_late_init: Voltage driver support not added
> [1.656162] PM: Cannot get wkup_m3_ipc handle
> [1.750855] pinctrl-single 44e10800.pinmux: pin PIN95 already requested
> by ocp:P9_19_pinmux; cannot claim for 4819c000.i2c
> [1.762096] pinctrl-single 44e10800.pinmux: pin-95 (4819c000.i2c) status
> -22
> [1.769223] pinctrl-single 44e10800.pinmux: could not request pin 95
> (PIN95) from group pinmux_bb_i2c2_pins  on device pinctrl-single
> [1.781311] omap_i2c 4819c000.i2c: Error applying setting, reverse things
> back
> [1.792167] PM: Cannot get wkup_m3_ipc handle
>
> Do I need to change something?
>
> Also, is there any documentation on what packages can be safely removed from
> this image for the BeagleBone Black? The image is pretty bloated:
>
> $ df | grep /dev/mmc
> /dev/mmcblk1p1   3704040 2927544568624  84% /

If you want "x11 and the lcd screen" you can use the "2gb" lxqt image:

https://rcn-ee.net/rootfs/bb.org/testing/2018-01-14/stretch-lxqt-2gb/

If you don't care about x11, and just using the fb on the lcd screen,
grab the iot or console variant:

https://rcn-ee.net/rootfs/bb.org/testing/2018-01-14/stretch-iot/

https://rcn-ee.net/rootfs/bb.org/testing/2018-01-14/stretch-console/

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/CAOCHtYhk_jjpJXGnEZsm3Y1yub0NG7Zu61PWVjk_LW2XtdNaPA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] sysfs: cannot create duplicate filename '/bus/platform/devices/4a300000.pruss'

[Hartley Sweeten]

Hello all,

I was trying the bone-debian-9.1-lxqt-armhf-2017-08-31-4gb.img.xz with a 
Newhaven NHD-7.0CTP-CAPE-N. It boots up fine and the screen and capacitive 
touchscreen work great. But I noticed this WARNING in the dmesg:

[   31.517455] [ cut here ]
[   31.517513] WARNING: CPU: 0 PID: 347 at fs/sysfs/dir.c:31 
sysfs_warn_dup+0x78/0x88
[   31.517520] sysfs: cannot create duplicate filename 
'/bus/platform/devices/4a30.pruss'
[   31.517526] Modules linked in: pruss_soc_bus(+) joydev evdev 
uio_pdrv_genirq uio usb_f_mass_storage 8021q garp mrp stp llc usb_f_acm 
u_serial usb_f_ecm usb_f_rndis u_ether libcomposite iptable_nat 
nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack 
iptable_mangle iptable_filter spidev pru_rproc pruss_intc pruss tieqep 
ip_tables x_tables
[   31.517659] CPU: 0 PID: 347 Comm: systemd-udevd Not tainted 
4.9.76-ti-r91 #1
[   31.517665] Hardware name: Generic AM33XX (Flattened Device Tree)
[   31.517705] [] (unwind_backtrace) from [] 
(show_stack+0x20/0x24)
[   31.517731] [] (show_stack) from [] 
(dump_stack+0x80/0x94)
[   31.517747] [] (dump_stack) from [] 
(__warn+0xf8/0x110)
[   31.517760] [] (__warn) from [] 
(warn_slowpath_fmt+0x58/0x74)
[   31.517772] [] (warn_slowpath_fmt) from [] 
(sysfs_warn_dup+0x78/0x88)
[   31.517788] [] (sysfs_warn_dup) from [] 
(sysfs_do_create_link_sd+0xc4/0xcc)
[   31.517802] [] (sysfs_do_create_link_sd) from [] 
(sysfs_create_link+0x38/0x44)
[   31.517820] [] (sysfs_create_link) from [] 
(bus_add_device+0x130/0x1b8)
[   31.517834] [] (bus_add_device) from [] 
(device_add+0x298/0x5d0)
[   31.517852] [] (device_add) from [] 
(of_device_add+0x44/0x4c)
[   31.517867] [] (of_device_add) from [] 
(of_platform_device_create_pdata+0x94/0xcc)
[   31.517879] [] (of_platform_device_create_pdata) from 
[] (of_platform_bus_create+0x174/0x30c)
[   31.517891] [] (of_platform_bus_create) from [] 
(of_platform_populate+0x84/0x120)
[   31.517924] [] (of_platform_populate) from [] 
(pruss_soc_bus_probe+0x12c/0x290 [pruss_soc_bus])
[   31.517973] [] (pruss_soc_bus_probe [pruss_soc_bus]) from 
[] (platform_drv_probe+0x60/0xc0)
[   31.517987] [] (platform_drv_probe) from [] 
(driver_probe_device+0x2b4/0x440)
[   31.517999] [] (driver_probe_device) from [] 
(__driver_attach+0x100/0x10c)
[   31.518009] [] (__driver_attach) from [] 
(bus_for_each_dev+0x8c/0xd0)
[   31.518020] [] (bus_for_each_dev) from [] 
(driver_attach+0x2c/0x30)
[   31.518031] [] (driver_attach) from [] 
(bus_add_driver+0x16c/0x26c)
[   31.518043] [] (bus_add_driver) from [] 
(driver_register+0x88/0x104)
[   31.518054] [] (driver_register) from [] 
(__platform_driver_register+0x50/0x58)
[   31.518071] [] (__platform_driver_register) from [] 
(pruss_soc_bus_driver_init+0x20/0xc0 [pruss_soc_bus])
[   31.518093] [] (pruss_soc_bus_driver_init [pruss_soc_bus]) 
from [] (do_one_initcall+0x64/0x1a0)
[   31.518117] [] (do_one_initcall) from [] 
(do_init_module+0x74/0x3d0)
[   31.518136] [] (do_init_module) from [] 
(load_module+0x1f40/0x2614)
[   31.518149] [] (load_module) from [] 
(SyS_finit_module+0xdc/0x110)
[   31.518167] [] (SyS_finit_module) from [] 
(__sys_trace_return+0x0/0x10)
[   31.518175] ---[ end trace 714a7bf4a57d0f0d ]---

This warning shows up with the 4.9.45-ti-r57 kernel from the image and with 
the 4.9.76-ti-r91 kernel after doing a sudo 
/opt/scripts/tools/update_kernel.sh.

Is this a known issue in the kernel or do I have something setup 
incorrectly?

This is the output from the versions.sh script:

$ sudo /opt/scripts/tools/version.sh 
git:/opt/scripts/:[714e162ba98cf3d2897e7fc95e951c6df15a7d0a]
eeprom:[A335BNLT00C05014BBBK0A84]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[BeagleBoard.org Debian Image 2017-08-31]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
2018.01-2-gcc9c2d1992]
kernel:[4.9.76-ti-r91]
nodejs:[v6.11.2]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg:[bb-cape-overlays]:[4.4.20170728.0-0rcnee1~stretch+20170728]
pkg:[bb-wl18xx-firmware]:[1.20170829-0rcnee1~stretch+20170829]
pkg:[firmware-ti-connectivity]:[20170823-1rcnee0~stretch+20170830]
dmesg | grep pinctrl-single
[1.362988] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 
568
[1.750855] pinctrl-single 44e10800.pinmux: pin PIN95 already requested 
by ocp:P9_19_pinmux; cannot claim for 4819c000.i2c
[1.762096] pinctrl-single 44e10800.pinmux: pin-95 (4819c000.i2c) status 
-22
[1.769223] pinctrl-single 44e10800.pinmux: could not request pin 95 
(PIN95) from group pinmux_bb_i2c2_pins  on device pinctrl-single
END

I also notices this on the serial console when the board boots:

Starting kernel ...

[0.000925] clocksource_probe: no matching clocksources found
[1.369280] wkup_m3_ipc 44e11324.wkup_m3_ipc: could not get rproc handle
[1.648806] omap_voltage_late_init: Voltage driver support not added
[

Re: [beagleboard] Connection to Android tablet

[Przemek Klosowski]

On Tue, Jan 16, 2018 at 3:10 PM, M Pitman  wrote:

> I am collecting data from an ADC chip and saving the data to a file on the
> Beaglebone Black.  Currently the commands are sent through PuTTY on a PC
> using ssh and then sftp sends the file back which is manually loaded and
> displayed in a Qt program.  My desire is to be able to send a command to
> the Beaglebone directly from the Qt program on an Android tablet and have
> the Beaglebone send the resulting file back to the tablet.
>
> I ran Xserver on the tablet and did a remote display from the beaglebone
over the USB networking. The same USB network connection can remotely mount
file shares.

-- 
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/CAC%3D1GgF28Bwb0nRWoT30vfhK7rD%3D08FYkt63xeG0PL6g80bSuA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Building a device tree overlay for your new PocketCape design

[Jason Kridner]

Published at:
https://jkridner.wordpress.com/2018/01/17/building-a-device-tree-overlay-for-your-new-pocketcape-design/

Much has been made of the complexities of the Linux device tree
configuration mechanism–it is both a savior and a curse. It saves us from
needing to maintain custom kernel logic for every possible board and
daughterboard (Cape  or PocketCape) setup and
curses us with a new syntax to configure all of the specifics of any given
chunk of hardware. While the ultimate goal really should be to hide end
users from the complexities of this new syntax and the data structures of
any given device, even casual users should build up some basic
understanding. To that end, please take a look at some of my thoughts
below, but don’t feel like you have to understand every word. That is,
unless you’ve just developed a new PocketCape and are about to punish
reward the world with your amazing new hardware. For those folks, lets work
together to make sure users of this rapidly expanding ecosystem have an
amazing experience.

First, a bit of a history lesson… From the launch of BeagleBone, we defined
in the System Reference Manual

a strategy of including I2C-based EEPROMs on all Capes such that those
boards could be automatically discovered and appropriate pin configurations
could be made. The software implemented by the BeagleBoard.org
community, Pantelis
Antoniou in particular , to handle Capes
ended up not using all of the individual pin configuration details out of
the EEPROM, but instead relied on just the board name and version fields
identifying a particular set of modifications to the running device tree.
The CapeMgr module in the kernel would search for valid EEPROMs and pull
the appropriate overlay out of /lib/firmware.

For many hardware developers, the complexity of creating a device tree
overlay for their hardware felt too intimidating. To help those developers,
the BeagleBoard.org community, Charles Steinkuehler in particular
,
introduced a concept of a universal Cape that enabled as many drivers as
possible and utilized Pantelis’ pinmux helpers to dynamically select which
function was routed out to the pins by running some command-line scripts or
writing to some sysfs entries. This was eventually merged into the default
base board configuration such that no overlay actually needed to be loaded
for the dynamic pin configuration and the beaglebone-universal-io
config-pin utility is now maintained in a BeagleBoard.org github repo
.
While this doesn’t automatically configure the hardware for Capes, simple
command-line instructions can be used at run-time to talk to the hardware
on many Capes or prototype wiring configurations.

Note: One issue with the universal Cape approach is that it locks up some
peripherals needed by some other drivers, so we still need to update the
device tree.

Another notable change in how BeagleBoard.org Debian images now handle
Capes is that device tree overlays are now handled in u-boot
.
The CapeMgr kernel module has some great benefits for debugging things at
run-time and even loading overlays for hardware whose interface isn’t
configure until run-time, such as FPGAs or the PRUs. Still, loading the
overlays in the u-boot bootloader before the kernel is loaded provides us
with the ability to configure LCDs at boot and, perhaps more critically,
prevent some drivers from ever even being loaded. While drivers should
typically handle the case of being disable, some driver authors simply
never handle that case. Besides, loading and then unloading drivers would
simply waste time.

For better or worse, not all Capes include the configuration EEPROMs. Even
the BeagleBoard.org Robotics Cape, one of our official BeagleBoard.org Capes
, is currently without this EEPROM. A
configuration file, /boot/uEnv.txt, must therefore be edited to notify the
bootloader that a particular overlay needs to be loaded. The potential here
is that editing the text file in error can result in your board not
booting. Recovering from that error will require you to boot your board by
another means, such as via the SD card, USB, or serial. Once booted, you
can then mount and re-edit this file to fix your error. I personally do not
see many drawbacks of including the Cape configuration EEPROMs on all
boards, but cost has been cited as one concern as many of these boards face
pricing pressures to make them as affordable as possible.

As of today, the PocketBeagle System Reference Manual

Re: [beagleboard] uart performance flaky with BB 9.1 OS, works great with 7.11 version, same HW

[Robert Nelson]

On Tue, Jan 16, 2018 at 9:33 PM,   wrote:
> I am connecting 2 bb blacks via serial uart, /dev/ttyO1. or /dev/ttyS1. they
> are symlinked. I need to use them at the fastest speeds, i.e. B300 or
> more. When i use the older 7.11 image (straight off beagleboard downloads
> site), the BB's communicate rock solid, no losses. When i upgrade the image
> to the current 9.1, the non-IoT image, and use the same code and the same
> HW, i can't get reliable data xfer'd across the serial link. A lot of errors
> in comparison to the almost none using the old image. It finally was working
> reliably at B50.
>
> My dilemma is i don't want to remain with effectively an obsolete image
> (i.e.. debian 7.11). It makes everything else harder to keep up. I've played
> with uEnv.txt options. Nothing seems to matter.
>
> I didn't find any thread in the forum discussing this kind of problem.
> Clearly something is different about 9.1 and the serial subsystem from the
> earlier 7.11 version. I was having same problem with latest version 8 as
> well.
>
> has anyone experienced this, and better, found a fix. Driver, device tree
> configuration, whatever.

You can install the old "3.8.x" based kernel in 9.x or 8.x via:

cd /opt/scripts/tools/
git pull
sudo ./update_kernel.sh --bone-channel --stable
sudo reboot

BTW, newer images us U-Boot Overlays, so remember to double check
/boot/uEnv.txt and "disable it":

from:
enable_uboot_overlays=1

to:
#enable_uboot_overlays=1


Then you can verify if it's a kernel or new lib issue..

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/CAOCHtYjFoU8wbJC2o%2B58N3yXNTXhtgRgV6RuYuEUnRxfE2DqQA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Which kernel is better for stretch? 4.4.x or 4.9.x?

[Robert Nelson]

On Wed, Jan 17, 2018 at 12:38 AM, 'Luther Goh Lu Feng' via BeagleBoard
 wrote:
> Downloading the Stretch IoT (non-GUI) from beagleboard.org[1] yields an
> image with kernel 4.4.91-ti-r133. A Stretch IOT image from Robert Nelson[2]
> has kernel 4.9.74-ti-r90. My question specifically is: why the difference,
> and is one preferable over the other? Thanks
>
> [1] https://beagleboard.org/latest-images
> [2]
> https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Stretch_Snapshot_iot

Well, we are migrating to v4.9.x-ti and then v4.14.x-ti..

Feel free to still use v4.4.x-ti, as it's still being tested..

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/CAOCHtYjXNJWAp_eoqvBTQqu%3DDKycrVcvJFNw3KrAgmpPA4qbnA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Wiznet W5500 ethernet module driver can't install

[Robert Nelson]

On Wed, Jan 17, 2018 at 1:37 AM, santosh aiwale  wrote:
>
>
> On Tuesday, 16 January 2018 22:21:39 UTC+5:30, santosh aiwale wrote:
>>
>> The Wiznet W5500 is working on SPI with BBB.
>> I am working on pocket beagle bone using Linux beaglebone 4.4.91-ti-r133.
>> here is the driver link https://github.com/borg42/w5x00.
>> also kernel module build not available.
>>
> Making Connection with SPI0
> and adding uEnv file with
> uboot_overlay_addr0=/lib/firmware/PB-SPI0-ETH-WIZ-CLICK.dtbo and then reboot
> but not getting boot up with this if remove the module then getting bootup

Please provide more information about your board, using this tool:

sudo /opt/scripts/tools/version.sh

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/CAOCHtYjrfz4Wqi%3D9oE9gwoQk6PGUH81TMS3S2hbdBw%3Dk6S3aUA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Problem enabling SPI and UARTs (4.5 kernel)

[Robert Nelson]

On Wed, Jan 17, 2018 at 7:20 AM,   wrote:
> Thomas,
>
> I'm seeing same issue on my beaglebone black.
>
> i.e.
> [2.247383] bone_capemgr bone_capemgr: Baseboard:
> 'A335BNLT,,O �d\djhnff� bone_cap4
> [2.300255] bone_capemgr bone_capemgr: slot #0: No cape found
> [2.344247] bone_capemgr bone_capemgr: slot #1: No cape found
> [2.388246] bone_capemgr bone_capemgr: slot #2: No cape found
> [2.432246] bone_capemgr bone_capemgr: slot #3: No cape found
> [2.438073] bone_capemgr bone_capemgr: enabled_partno PARTNO 'BB-SPI0-01'
> VER 'N/A' PR '0'
> [2.446394] bone_capemgr bone_capemgr: slot #4: override
> [2.451750] bone_capemgr bone_capemgr: Using override eeprom data at slot
> 4
> [2.458764] bone_capemgr bone_capemgr: slot #4: 'Override Board
> Name,00A0,Override Manuf,BB-SPI0-01'
> [2.468045] bone_capemgr bone_capemgr: enabled_partno PARTNO 'BB-SPI1-01'
> VER 'N/A' PR '0'
> [2.476375] bone_capemgr bone_capemgr: slot #5: override
> [2.481728] bone_capemgr bone_capemgr: Using override eeprom data at slot
> 5
> [2.488741] bone_capemgr bone_capemgr: slot #5: 'Override Board
> Name,00A0,Override Manuf,BB-SPI1-01'
> [2.498376] bone_capemgr bone_capemgr: initialized OK.
> .
> .
> .
> [3.514779] __of_adjust_tree_phandle_references: Could not find target
> property 'fixup' @/__local_fixu_
> [3.524628] bone_capemgr bone_capemgr: slot #5: Failed to resolve tree
> [3.532412] bone_capemgr bone_capemgr: loader: failed to load slot-5
> BB-SPI1-01:00A0 (prio 0)
> [3.541557] __of_adjust_tree_phandle_references: Could not find target
> property 'fixup' @/__local_fixu_
> [3.551362] bone_capemgr bone_capemgr: slot #4: Failed to resolve tree
>
> Can you help me how did you fix this issue?

Please add more information about your system:

sudo /opt/scripts/tools/version.sh

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/CAOCHtYgJqmOugFx0b00_Lio%2BGq2VZhiNfjQxaOVON4-YJywnQg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Ubuntu image for BBGW

[Robert Nelson]

On Wed, Jan 17, 2018 at 6:58 AM, Boixos Noi  wrote:
>
> Hello everyone,
>
> is there any available Ubuntu image for BeagleBone Green Wireless with
> preconfigured Wireless/Bluetooth drivers
> (bb-wl18xx-wlan0/bb-wl18xx-bluetooth)? I've flashed my BBGW with Ubuntu
> 16.04.3 which I've download from this link. Flashing process went without
> any issues. When I tried to access my BBGW via SSH, I've noticed that
> connection trough BBGW eth interface is not established. While with
> different Debian images everything works like a charm.

Ubuntu 16.04.3 needs connman to work like debian does out of the box.

I have things setup in "18.04" to work like our debian images do..

I'm tempted to just nuke the 16.04.3 image and use the beta bionic version..

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/CAOCHtYjYzpu-nRYJkrj0SqzyU5P0GRgxHwY5Mx7OXXhm%3DLcHfw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] beagleboard-x15:eMMC boot

[awhitebear6]

hi,


can you please provide a link to a document for flashing the Bootloaders 
and root file sys on to the eMMC. 

-- 
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/2666c203-e33e-4231-add6-bc84c0631d5e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Ubuntu image for BBGW

[Boixos Noi]

Hello everyone,

is there any available Ubuntu image for BeagleBone Green Wireless with 
preconfigured Wireless/Bluetooth drivers 
(bb-wl18xx-wlan0/bb-wl18xx-bluetooth)? I've flashed my BBGW with Ubuntu 
16.04.3 which I've download from this link 
.
 
Flashing process went without any issues. When I tried to access my BBGW 
via SSH, I've noticed that connection trough BBGW eth interface is not 
established. While with different Debian images everything works like a 
charm.

-- 
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/b8c3da9b-68ec-4a79-b408-72687b5724a7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] BBB doesn't work without SD-Card after update

[jamessabirov]

Hi,

I'm newbie in this stuff. I got my BBB couple days ago and ran it. 
Everything worked fine, but I couldn't  connect my BBB with internet, so I 
thought I should update my system. So I made everything, what I should to. 
Edited uEnv.txt etc. Pressed S2 Button long enough. So in 30-40 minutes I 
checked my BBB and it had Debian 9.1. I shut it down then booted without SD 
Card. But it didn't start. USR 0 and 2 light up for couple seconds and 
after that no USR light at all. With SD Card it boots, but only with 
Read-Only System. What did I wrong? And what should I do to fix it? Thank 
you

Reagrds,
Jamshid

-- 
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/a2a9e234-05a1-4ee3-b654-6f36f8963490%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Beaglebone black SPI0 transfer issue

[kaar . kuzhali16]

I am working with a beaglebone black and I want to transfer data to my 
potentiometer (AD 8403). BBB is the master and pot is the slave.

My beaglebone settings:

1) *uname -a *
Linux beaglebone 4.9.59-ti-r74 #1 SMP PREEMPT Thu Nov 2 06:20:31 UTC 2017 
armv7l GNU/Linux

2)* cat /etc/dogtag*
BeagleBoard.org Debian Image 2017-11-05

3) *cat /etc/debian_version *
9.2

4) *cat /sys/devices/platform/bone_capemgr/slots* 
cat: /sys/devices/platform/bone_capemgr/slots: No such file or directory

5) *ls -al /dev/spi**
crw-rw 1 root spi 153, 1 Nov  3  2016 /dev/spidev1.0
crw-rw 1 root spi 153, 0 Nov  3  2016 /dev/spidev1.1
crw-rw 1 root spi 153, 3 Nov  3  2016 /dev/spidev2.0
crw-rw 1 root spi 153, 2 Nov  3  2016 /dev/spidev2.1

6) Pins are configured through config pin

config-pin P9_17 spi_cs
config-pin P9_18 spi   
config-pin P9_21 spi
config-pin P9_22 spi_sclk

7) *cat /etc/default/capemgr* 
# Default settings for capemgr. This file is sourced by /bin/sh from
# /etc/init.d/capemgr.sh

# Options to pass to capemgr
CAPE=BB-SPIDEV0


Loopback test is working fine but when I try to transfer any data to my 
pot, I am receiving [255] as the result. How to solve this issue?
*Loopback test example:*

spi = SPI(0, 0)
print spi.xfer2([0, 0])
[0, 0]
spi.close()

*When connected to pot:*

spi = SPI(0, 0)
print spi.xfer2([0, 0])
[255, 255]  --> This is where the issue is.
spi.close()



Thanks in advance.

-Regards,
Kaarkuzhali Murugan. 

-- 
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/06509ee0-6d44-428d-8607-0f9b4304571b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Problem enabling SPI and UARTs (4.5 kernel)

[nagaraju . lakkaraju]

Thomas,

I'm seeing same issue on my beaglebone black. 

i.e.
[2.247383] bone_capemgr bone_capemgr: Baseboard: 
'A335BNLT,,O �d\djhnff� bone_cap4
[2.300255] bone_capemgr bone_capemgr: slot #0: No cape 
found  
[2.344247] bone_capemgr bone_capemgr: slot #1: No cape 
found  
[2.388246] bone_capemgr bone_capemgr: slot #2: No cape 
found  
[2.432246] bone_capemgr bone_capemgr: slot #3: No cape 
found  
[2.438073] bone_capemgr bone_capemgr: enabled_partno PARTNO 
'BB-SPI0-01' VER 'N/A' PR '0' 
[2.446394] bone_capemgr bone_capemgr: slot #4: 
override   
[2.451750] bone_capemgr bone_capemgr: Using override eeprom data at 
slot 4
[2.458764] bone_capemgr bone_capemgr: slot #4: 'Override Board 
Name,00A0,Override Manuf,BB-SPI0-01'   
[2.468045] bone_capemgr bone_capemgr: enabled_partno PARTNO 
'BB-SPI1-01' VER 'N/A' PR '0' 
[2.476375] bone_capemgr bone_capemgr: slot #5: 
override   
[2.481728] bone_capemgr bone_capemgr: Using override eeprom data at 
slot 5
[2.488741] bone_capemgr bone_capemgr: slot #5: 'Override Board 
Name,00A0,Override Manuf,BB-SPI1-01'   
[2.498376] bone_capemgr bone_capemgr: initialized 
OK. 
.
.
.
[3.514779] __of_adjust_tree_phandle_references: Could not find target 
property 'fixup' @/__local_fixu_
[3.524628] bone_capemgr bone_capemgr: slot #5: Failed to resolve 
tree 
[3.532412] bone_capemgr bone_capemgr: loader: failed to load slot-5 
BB-SPI1-01:00A0 (prio 0)  
[3.541557] __of_adjust_tree_phandle_references: Could not find target 
property 'fixup' @/__local_fixu_
[3.551362] bone_capemgr bone_capemgr: slot #4: Failed to resolve 
tree 

Can you help me how did you fix this issue?

Thanks,
Raju


On Thursday, February 25, 2016 at 5:49:36 PM UTC+5:30, Thomas Andrews wrote:
>
> On 02/25/2016 12:40 PM, DLF wrote:
>
> $ git clone https://github.com/beagleboard/bb.org-overlays
> $ cd bb.org-overlays/
> $ ./dtc-overlay.sh
> $ sudo ./install.sh
>
>
> Thanks DLF and William, I followed this procedure (with some minor 
> modifications to use my (already existing) dtc that came with the kernel), 
> and it is working now.
>
> Thanks again,
> Thomas
>

-- 
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/6a918771-514d-41fe-9169-aef92e92af63%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: eQEP1 setup problems with latest debian iOT

[Hugh Frater]

On Wednesday, 17 January 2018 12:37:03 UTC, Hugh Frater wrote:
>
>
>
> On Thursday, 11 May 2017 10:18:08 UTC+1, Hugh Frater wrote:
>>
>> It looks like we are good-to-go. Thanks for sorting this out guys :)
>>
>> Hugh
>>
>> On Wednesday, 10 May 2017 17:16:50 UTC+1, RobertCNelson wrote:
>>>
>>> On Wed, May 10, 2017 at 10:20 AM, Hugh Frater  
>>> wrote: 
>>> > Thanks guys, I'll keep an eye on the repository and grab a copy once 
>>> things 
>>> > are finalised. 
>>>
>>> Okay all pushed out.. 
>>>
>>> run: 
>>>
>>> sudo apt update ; sudo apt upgrade 
>>>
>>> and it should show an upgrade for bb-cape-overlays 
>>> bb-cape-overlays_4.4.20170510.0 
>>>
>>> reboot and it should work, let us know.. 
>>>
>>> Regards, 
>>>
>>> -- 
>>> Robert Nelson 
>>> https://rcn-ee.com/ 
>>>
>>
> Just to add to this again - this fix is still required if you use the 8.7 
> IoT image but is not required if you use the 9.1 image. Also note that the 
> pru_ecap mode for P9_42 is now called PWM when you call config-pin 
>

OK, looks like pru_ecap mode was removed from the .dtbo as an option for 
this pin - PWM is not what you want if you want to use the pru1 ecap device 
as a PWM generator - you need mode 3, which is no longer a valid option. 
Time to downgrade again to 8.6 :( Why can't these options stay when the 
universal overlays get updated?

-- 
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/76dcedb2-8543-4555-8f04-807187200ffa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: eQEP1 setup problems with latest debian iOT

[Hugh Frater]

On Thursday, 11 May 2017 10:18:08 UTC+1, Hugh Frater wrote:
>
> It looks like we are good-to-go. Thanks for sorting this out guys :)
>
> Hugh
>
> On Wednesday, 10 May 2017 17:16:50 UTC+1, RobertCNelson wrote:
>>
>> On Wed, May 10, 2017 at 10:20 AM, Hugh Frater  
>> wrote: 
>> > Thanks guys, I'll keep an eye on the repository and grab a copy once 
>> things 
>> > are finalised. 
>>
>> Okay all pushed out.. 
>>
>> run: 
>>
>> sudo apt update ; sudo apt upgrade 
>>
>> and it should show an upgrade for bb-cape-overlays 
>> bb-cape-overlays_4.4.20170510.0 
>>
>> reboot and it should work, let us know.. 
>>
>> Regards, 
>>
>> -- 
>> Robert Nelson 
>> https://rcn-ee.com/ 
>>
>
Just to add to this again - this fix is still required if you use the 8.7 
IoT image but is not required if you use the 9.1 image. Also note that the 
pru_ecap mode for P9_42 is now called PWM when you call config-pin 

-- 
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/6c463427-2340-4882-b3d6-a4a79f9f5e67%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] pru_rproc on latest Stretch IoT image

[Hugh Frater]

>
>
>>>
>>  Robert, thanks for the input so far. I had just come across this post
>>
>> *https://groups.google.com/forum/#!category-topic/beagleboard/boot/lS8QlNV8JCc
>>  
>> *
>>
>> And tried the steps you outlined in there but with no joy. I've tried 
>> running the script 
>>
>> sudo /opt/scripts/tools/developers/update_initrd.sh
>>
>> but again, not luck. I'm not actually getting any reference to pru_rproc 
>> at all from within the dmesg log, apart from in relation to the PM 
>> peripheral (whatever that is) - very odd.
>>
>
> I'm going to try again today with the 8.7 image from March '17
>

An update - a clean install of 8.7 with the stock uEnv.txt results in the 
usual pru-rproc stuff in dmesg. Edit the file to enable u-boot overlays and 
the pru-rproc subsystem doesn't load at boot time. 

-- 
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/e42df4c8-7c04-4e16-9752-24fac841ff43%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] pru_rproc on latest Stretch IoT image

[Hugh Frater]

On Tuesday, 16 January 2018 16:00:33 UTC, Hugh Frater wrote:
>
>
>
> On Tuesday, 16 January 2018 15:52:23 UTC, RobertCNelson wrote:
>>
>> > Gotcha - here is the output after correcting /boot/uEnv.txt: 
>> > 
>> > debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh 
>> > [sudo] password for debian: 
>> > git:/opt/scripts/:[d36fe9a7be9ebfc872b10a470e904ab4c61c4516] 
>> > eeprom:[A335BNLT00C03816BBBK190D] 
>> > dogtag:[BeagleBoard.org Debian Image 2017-10-10] 
>> > bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
>> > 2017.09-2-g0f3f1c7907] 
>> > kernel:[4.4.91-ti-r133] 
>> > nodejs:[v6.11.4] 
>> > uboot_overlay_options:[enable_uboot_overlays=1] 
>> > uboot_overlay_options:[disable_uboot_overlay_emmc=1] 
>> > uboot_overlay_options:[disable_uboot_overlay_video=1] 
>> > uboot_overlay_options:[disable_uboot_overlay_audio=1] 
>> > uboot_overlay_options:[disable_uboot_overlay_wireless=1] 
>> > uboot_overlay_options:[disable_uboot_overlay_adc=1] 
>> > 
>> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo]
>>  
>>
>> > uboot_overlay_options:[enable_uboot_cape_universal=1] 
>> > pkg:[bb-cape-overlays]:[4.4.20171009.0-0rcnee1~stretch+20171009] 
>> > pkg:[bb-wl18xx-firmware]:[1.20170829-0rcnee1~stretch+20170829] 
>>
>>
>> Okay perfect! 
>>
>> Next for the pru firmware, the symlink might not work, but you'll need to 
>> run: 
>>
>> sudo /opt/scripts/tools/developers/update_initrd.sh 
>>
>> the initrd hook: 
>>
>> /usr/share/initramfs-tools/hooks/ti_pru_firmware 
>>
>> will copy the /lib/firmware/am335x-pru0-fw to the initrd so that the 
>> pru will loaded early on bootup.. 
>>
>> Regards, 
>>
>>
>> -- 
>> Robert Nelson 
>> https://rcn-ee.com/ 
>>
>
>  Robert, thanks for the input so far. I had just come across this post
>
> *https://groups.google.com/forum/#!category-topic/beagleboard/boot/lS8QlNV8JCc
>  
> *
>
> And tried the steps you outlined in there but with no joy. I've tried 
> running the script 
>
> sudo /opt/scripts/tools/developers/update_initrd.sh
>
> but again, not luck. I'm not actually getting any reference to pru_rproc 
> at all from within the dmesg log, apart from in relation to the PM 
> peripheral (whatever that is) - very odd.
>

I'm going to try again today with the 8.7 image from March '17

-- 
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/cc945957-71fa-48e1-9005-61d80586827d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.