Re: [beagleboard] Re: bbgw wlan0 users

[imjohncable]

Robert,
I tried that build and also the last one from yesterday (1/1) but I cannot 
make the wlan0 work on any of those builds.
When I do a ifconfig I get this:

root@beaglebone:~# ifconfig wlan0 up
SIOCSIFFLAGS: No such file or directory

And this is the dmesg:

[   29.792544] wl18xx_driver wl18xx.2.auto: Direct firmware load for 
ti-connectivity/wl1271-nvs.bin failed with error -2
[   30.147603] wlcore: wl18xx HW: 183x or 180x, PG 2.2 (ROM 0x11)
[   30.243578] wlcore: loaded
[  188.343428] wl18xx_driver wl18xx.2.auto: Direct firmware load for 
ti-connectivity/wl18xx-fw-4.bin failed with error -2
[  188.343465] wlcore: ERROR could not get firmware 
ti-connectivity/wl18xx-fw-4.bin: -2
[  188.711351] wl18xx_driver wl18xx.2.auto: Direct firmware load for 
ti-connectivity/wl18xx-fw-4.bin failed with error -2
[  188.711388] wlcore: ERROR could not get firmware 
ti-connectivity/wl18xx-fw-4.bin: -2
[  189.075369] wl18xx_driver wl18xx.2.auto: Direct firmware load for 
ti-connectivity/wl18xx-fw-4.bin failed with error -2
[  189.075406] wlcore: ERROR could not get firmware 
ti-connectivity/wl18xx-fw-4.bin: -2
[  189.086887] wlcore: ERROR firmware boot failed despite 3 retries


What do you think could be the problem here? Is this a problem with the 
ti-connectivity version?
Thanks for your help and time!
Regards,
J

On Friday, December 30, 2016 at 6:44:55 AM UTC-8, RobertCNelson wrote:
>
> On Fri, Dec 30, 2016 at 2:37 AM, Linq John  > wrote: 
> > 
> > I brought a Beaglebone Green Wireless. 
> > At the first day, its wifi worked, so I did some apt-get 
> > update/upgrade/dis-upgrade. 
> > My main purpose is to use it to do some python work. UART/I2C/GPIO etc. 
> > So I didn't discover that the wifi no longer working after the apt-get 
> > upgrade. 
> > I spent two working days trying to make its wifi working again, but no 
> > success. 
> > I didn't record the version info of the original working Debian. 
> > And I can't find the pre-load image from 
> > https://debian.beagleboard.org/images/ 
> > What I can find are: 
> > bone-debian-8.5-seeed-gcp-iot-armhf-2016-08-26-4gb.img.xz - failed to 
> boot 
> > bone-debian-8.6-iot-armhf-2016-12-09-4gb.img.xz - failed to boot 
> > bone-debian-8.6-seeed-iot-armhf-2016-11-06-4gb.img.xz - wifi doesn't 
> work 
> > I also tried to use the kernel in *-iot-armhf-2016-12-09-* with 
> > *seeed-iot-armhf-2016-11-06*, but no success. 
> > (By changing uname_r of uEnv.txt, and even by renaming the files.) 
> > After all these I found a thread in TI E2E: 
> > 
> https://e2e.ti.com/support/wireless_connectivity/wilink_wifi_bluetooth/f/307/p/541235/1978301
>  
> > So I guess it's a hardware problem, but without wifi, there is no 
> internet 
> > connection on BBGW, 
> > then I am not able to install python packages, my BBGW becomes useless. 
> > 
> > And I guess the below images are not for BBGW. 
> > https://rcn-ee.net/rootfs/2016-11-10/microsd/ 
> > 
> > Is there any work-around available for a general user? 
>
> Use this build: 
>
> https://rcn-ee.net/rootfs/bb.org/testing/2016-12-27/ 
>
> 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/0f0e7b9b-3b9a-43b7-b658-66eccc71fdd0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: BBGW - Boot 3.8 kernel ?

[Robert Nelson]

On Mon, Jan 2, 2017 at 3:53 PM, Oliv'  wrote:
> Small update, I tried to use the script "./update_kernel.sh --bone-channel
> --stable".
> It starts to boot but give an error I am not able to understand, if somebody
> can help : "Unhandled fault: external abort on non-linefetch (0x1008) at
> 0xe0858000"
>
> Full error log: http://pastebin.com/RQU0Ku10

Yeah, on 3.8.13 it would help if i actually disabled the cpsw node,
instead of just copying the device tree as is..

I'll boot test it tomorrow..

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

Re: [beagleboard] hdmi audio stops at 10 minutes after boot --- always.

[William Hermans]

So this is not guaranteed to work, but worth exploring. Give the following
a shot:
$ sudo alsa force-reload

But if that does not work. Try running:

$ sudo apt-get update
$ sudo apt-get install --fix-missing
$ sudo alsa force-reload
$ sudo reboot

I've seen mention of this multiple times, but always for Ubuntu it seems.
So maybe it'll cure your problems, maybe it won't.

On Mon, Jan 2, 2017 at 3:24 PM, William Hermans  wrote:

> Ok, my bad, I completely missed the part where you said it still output,
> just no sound from speakers . . .
>
> Well then, that will be problematic to troubleshoot.
>
> With that said, which kernel version are you running ? Ok, 4.4.30-ti-r64
>
> Have you tried different kernels ? newer, and older.
>
> On Mon, Jan 2, 2017 at 3:04 PM, William Hermans  wrote:
>
>> More to the point. Try running the command I gave above *AFTER* the audio
>> already stops. That'll at least tell you where, and why it fails. After
>> that you can investigate these reason why. Perhaps providing a fruitful
>> google search, or at minimum giving you something to report.
>>
>> On Mon, Jan 2, 2017 at 2:57 PM, William Hermans 
>> wrote:
>>
>>> $ strace -o /path/file speaker-test
>>>
>>>
>>> It'll at least tell you where it stops, and most likely why.
>>>
>>> On Mon, Jan 2, 2017 at 2:54 PM, John Franey  wrote:
>>>
 William,

 Thanks.

 If your suggestion is that the speaker-test program itself is silencing
 the hdmi output with some driver callI'm really doubtful.  I hope you
 don't mind me saying so.  For a couple of reasons, but mainly: The audio
 stops 10 minutes after boot time even if there is no audio process running
 at the time.  For example, I can run speaker-test before 10min mark to
 prove audio comes out right after boot.  Then turn off speaker-test before
 the 10min mark, and run it after.  There is no audio.

 Do I understand you correctly? That is, strace speaker-test?

 ...or maybe I should strace another process that maybe disabling
 sound.  Guessing which one is the root question anyway.


 John


 On Monday, January 2, 2017 at 3:05:14 PM UTC-5, William Hermans wrote:
>
>
>
> On Mon, Jan 2, 2017 at 12:28 PM, John Franey 
> wrote:
>
>> What do you think strace would show?
>>
>> I used strace a long time ago.  Back then, it traced the system calls
>> of an application process.   What should I look for in that output?
>>
>> Thanks,
>> John
>>
>
> Ok so then you know what strace is then I suppose. In your case, I
> would *imagine* strace would make things really easy to understand what is
> happening at that 10 minute mark. Since in your shoes, I'd run everything
> normally, but through strace. There is very likely going to be a lot of
> output. So you'd want to output that to a file, using the -o option( dash
> oh, as in Oscar ). Passed that I then( I would think ) becomes a matter of
> reading the file in reverse, until you find a potential culprit. That is:
> start of the end of the output file reading towards the beginning.
>
> Quite honestly, I have no idea what you should be looking for, But I
> suspect you'll know it when you see it. But if you do not, You could paste
> the last 10 lines of output here, or so. Then see if any one else here can
> spot a potential problem. I think that it could be very likely you will 
> not
> see an exact cause, but instead see something that should give a very good
> indication as to what the 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/ms
 gid/beagleboard/49e4bbaa-0b7d-4e52-8b75-09f402c7db9d%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/CALHSORrN0V6i9%2BH2LwAuuJ%2BUR-UAgmAXD5ryLctcw%3DF1s78Knw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] hdmi audio stops at 10 minutes after boot --- always.

[William Hermans]

Ok, my bad, I completely missed the part where you said it still output,
just no sound from speakers . . .

Well then, that will be problematic to troubleshoot.

With that said, which kernel version are you running ? Ok, 4.4.30-ti-r64

Have you tried different kernels ? newer, and older.

On Mon, Jan 2, 2017 at 3:04 PM, William Hermans  wrote:

> More to the point. Try running the command I gave above *AFTER* the audio
> already stops. That'll at least tell you where, and why it fails. After
> that you can investigate these reason why. Perhaps providing a fruitful
> google search, or at minimum giving you something to report.
>
> On Mon, Jan 2, 2017 at 2:57 PM, William Hermans  wrote:
>
>> $ strace -o /path/file speaker-test
>>
>>
>> It'll at least tell you where it stops, and most likely why.
>>
>> On Mon, Jan 2, 2017 at 2:54 PM, John Franey  wrote:
>>
>>> William,
>>>
>>> Thanks.
>>>
>>> If your suggestion is that the speaker-test program itself is silencing
>>> the hdmi output with some driver callI'm really doubtful.  I hope you
>>> don't mind me saying so.  For a couple of reasons, but mainly: The audio
>>> stops 10 minutes after boot time even if there is no audio process running
>>> at the time.  For example, I can run speaker-test before 10min mark to
>>> prove audio comes out right after boot.  Then turn off speaker-test before
>>> the 10min mark, and run it after.  There is no audio.
>>>
>>> Do I understand you correctly? That is, strace speaker-test?
>>>
>>> ...or maybe I should strace another process that maybe disabling sound.
>>> Guessing which one is the root question anyway.
>>>
>>>
>>> John
>>>
>>>
>>> On Monday, January 2, 2017 at 3:05:14 PM UTC-5, William Hermans wrote:



 On Mon, Jan 2, 2017 at 12:28 PM, John Franey  wrote:

> What do you think strace would show?
>
> I used strace a long time ago.  Back then, it traced the system calls
> of an application process.   What should I look for in that output?
>
> Thanks,
> John
>

 Ok so then you know what strace is then I suppose. In your case, I
 would *imagine* strace would make things really easy to understand what is
 happening at that 10 minute mark. Since in your shoes, I'd run everything
 normally, but through strace. There is very likely going to be a lot of
 output. So you'd want to output that to a file, using the -o option( dash
 oh, as in Oscar ). Passed that I then( I would think ) becomes a matter of
 reading the file in reverse, until you find a potential culprit. That is:
 start of the end of the output file reading towards the beginning.

 Quite honestly, I have no idea what you should be looking for, But I
 suspect you'll know it when you see it. But if you do not, You could paste
 the last 10 lines of output here, or so. Then see if any one else here can
 spot a potential problem. I think that it could be very likely you will not
 see an exact cause, but instead see something that should give a very good
 indication as to what the 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/ms
>>> gid/beagleboard/49e4bbaa-0b7d-4e52-8b75-09f402c7db9d%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/CALHSORobu83x0AMj87FA%2BRLYhdEfF9XBKd%3DVwhzDxmXsOYmEhw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] hdmi audio stops at 10 minutes after boot --- always.

[William Hermans]

More to the point. Try running the command I gave above *AFTER* the audio
already stops. That'll at least tell you where, and why it fails. After
that you can investigate these reason why. Perhaps providing a fruitful
google search, or at minimum giving you something to report.

On Mon, Jan 2, 2017 at 2:57 PM, William Hermans  wrote:

> $ strace -o /path/file speaker-test
>
>
> It'll at least tell you where it stops, and most likely why.
>
> On Mon, Jan 2, 2017 at 2:54 PM, John Franey  wrote:
>
>> William,
>>
>> Thanks.
>>
>> If your suggestion is that the speaker-test program itself is silencing
>> the hdmi output with some driver callI'm really doubtful.  I hope you
>> don't mind me saying so.  For a couple of reasons, but mainly: The audio
>> stops 10 minutes after boot time even if there is no audio process running
>> at the time.  For example, I can run speaker-test before 10min mark to
>> prove audio comes out right after boot.  Then turn off speaker-test before
>> the 10min mark, and run it after.  There is no audio.
>>
>> Do I understand you correctly? That is, strace speaker-test?
>>
>> ...or maybe I should strace another process that maybe disabling sound.
>> Guessing which one is the root question anyway.
>>
>>
>> John
>>
>>
>> On Monday, January 2, 2017 at 3:05:14 PM UTC-5, William Hermans wrote:
>>>
>>>
>>>
>>> On Mon, Jan 2, 2017 at 12:28 PM, John Franey  wrote:
>>>
 What do you think strace would show?

 I used strace a long time ago.  Back then, it traced the system calls
 of an application process.   What should I look for in that output?

 Thanks,
 John

>>>
>>> Ok so then you know what strace is then I suppose. In your case, I would
>>> *imagine* strace would make things really easy to understand what is
>>> happening at that 10 minute mark. Since in your shoes, I'd run everything
>>> normally, but through strace. There is very likely going to be a lot of
>>> output. So you'd want to output that to a file, using the -o option( dash
>>> oh, as in Oscar ). Passed that I then( I would think ) becomes a matter of
>>> reading the file in reverse, until you find a potential culprit. That is:
>>> start of the end of the output file reading towards the beginning.
>>>
>>> Quite honestly, I have no idea what you should be looking for, But I
>>> suspect you'll know it when you see it. But if you do not, You could paste
>>> the last 10 lines of output here, or so. Then see if any one else here can
>>> spot a potential problem. I think that it could be very likely you will not
>>> see an exact cause, but instead see something that should give a very good
>>> indication as to what the 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/ms
>> gid/beagleboard/49e4bbaa-0b7d-4e52-8b75-09f402c7db9d%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/CALHSORp5F6Ap5x51-PkOSv_-r5%3DSGN%3DA%2BTcTOZkbPC8tXiM77g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] hdmi audio stops at 10 minutes after boot --- always.

[William Hermans]

$ strace -o /path/file speaker-test


It'll at least tell you where it stops, and most likely why.

On Mon, Jan 2, 2017 at 2:54 PM, John Franey  wrote:

> William,
>
> Thanks.
>
> If your suggestion is that the speaker-test program itself is silencing
> the hdmi output with some driver callI'm really doubtful.  I hope you
> don't mind me saying so.  For a couple of reasons, but mainly: The audio
> stops 10 minutes after boot time even if there is no audio process running
> at the time.  For example, I can run speaker-test before 10min mark to
> prove audio comes out right after boot.  Then turn off speaker-test before
> the 10min mark, and run it after.  There is no audio.
>
> Do I understand you correctly? That is, strace speaker-test?
>
> ...or maybe I should strace another process that maybe disabling sound.
> Guessing which one is the root question anyway.
>
>
> John
>
>
> On Monday, January 2, 2017 at 3:05:14 PM UTC-5, William Hermans wrote:
>>
>>
>>
>> On Mon, Jan 2, 2017 at 12:28 PM, John Franey  wrote:
>>
>>> What do you think strace would show?
>>>
>>> I used strace a long time ago.  Back then, it traced the system calls of
>>> an application process.   What should I look for in that output?
>>>
>>> Thanks,
>>> John
>>>
>>
>> Ok so then you know what strace is then I suppose. In your case, I would
>> *imagine* strace would make things really easy to understand what is
>> happening at that 10 minute mark. Since in your shoes, I'd run everything
>> normally, but through strace. There is very likely going to be a lot of
>> output. So you'd want to output that to a file, using the -o option( dash
>> oh, as in Oscar ). Passed that I then( I would think ) becomes a matter of
>> reading the file in reverse, until you find a potential culprit. That is:
>> start of the end of the output file reading towards the beginning.
>>
>> Quite honestly, I have no idea what you should be looking for, But I
>> suspect you'll know it when you see it. But if you do not, You could paste
>> the last 10 lines of output here, or so. Then see if any one else here can
>> spot a potential problem. I think that it could be very likely you will not
>> see an exact cause, but instead see something that should give a very good
>> indication as to what the 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/49e4bbaa-0b7d-4e52-8b75-09f402c7db9d%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/CALHSORqtM_zQGcPmGt2WLhrWXysaWEyiCQA1KFK4QBE3DX54tw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] hdmi audio stops at 10 minutes after boot --- always.

[John Franey]

William,

Thanks.

If your suggestion is that the speaker-test program itself is silencing the 
hdmi output with some driver callI'm really doubtful.  I hope you don't 
mind me saying so.  For a couple of reasons, but mainly: The audio stops 10 
minutes after boot time even if there is no audio process running at the 
time.  For example, I can run speaker-test before 10min mark to prove audio 
comes out right after boot.  Then turn off speaker-test before the 10min 
mark, and run it after.  There is no audio.

Do I understand you correctly? That is, strace speaker-test? 

...or maybe I should strace another process that maybe disabling sound. 
 Guessing which one is the root question anyway.


John


On Monday, January 2, 2017 at 3:05:14 PM UTC-5, William Hermans wrote:
>
>
>
> On Mon, Jan 2, 2017 at 12:28 PM, John Franey  > wrote:
>
>> What do you think strace would show?
>>
>> I used strace a long time ago.  Back then, it traced the system calls of 
>> an application process.   What should I look for in that output?
>>
>> Thanks,
>> John
>>
>
> Ok so then you know what strace is then I suppose. In your case, I would 
> *imagine* strace would make things really easy to understand what is 
> happening at that 10 minute mark. Since in your shoes, I'd run everything 
> normally, but through strace. There is very likely going to be a lot of 
> output. So you'd want to output that to a file, using the -o option( dash 
> oh, as in Oscar ). Passed that I then( I would think ) becomes a matter of 
> reading the file in reverse, until you find a potential culprit. That is: 
> start of the end of the output file reading towards the beginning.
>
> Quite honestly, I have no idea what you should be looking for, But I 
> suspect you'll know it when you see it. But if you do not, You could paste 
> the last 10 lines of output here, or so. Then see if any one else here can 
> spot a potential problem. I think that it could be very likely you will not 
> see an exact cause, but instead see something that should give a very good 
> indication as to what the 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/49e4bbaa-0b7d-4e52-8b75-09f402c7db9d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BBGW - Boot 3.8 kernel ?

[Oliv']

Small update, I tried to use the script "./update_kernel.sh --bone-channel 
--stable".
It starts to boot but give an error I am not able to understand, if 
somebody can help : "Unhandled fault: external abort on non-linefetch 
(0x1008) at 0xe0858000"

Full error log: http://pastebin.com/RQU0Ku10

-- 
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/16d9a76d-502b-4b5b-9976-7b179b214a79%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] hdmi audio stops at 10 minutes after boot --- always.

[William Hermans]

One thing that does come to mind is that having just recently removed the
kernel module from loading at boot on my own system here. Is that it
*could* be related to DMA. As it seems the sound modules do include a dma
sound module. Which, there has been some issues with DMA on this platform
in the past. I only remember seeing issues with dma in relation to SPI, but
perhaps it's also an issue for sound too ? Pure speculation on my behalf.

On Mon, Jan 2, 2017 at 1:05 PM, William Hermans  wrote:

>
>
> On Mon, Jan 2, 2017 at 12:28 PM, John Franey  wrote:
>
>> What do you think strace would show?
>>
>> I used strace a long time ago.  Back then, it traced the system calls of
>> an application process.   What should I look for in that output?
>>
>> Thanks,
>> John
>>
>
> Ok so then you know what strace is then I suppose. In your case, I would
> *imagine* strace would make things really easy to understand what is
> happening at that 10 minute mark. Since in your shoes, I'd run everything
> normally, but through strace. There is very likely going to be a lot of
> output. So you'd want to output that to a file, using the -o option( dash
> oh, as in Oscar ). Passed that I then( I would think ) becomes a matter of
> reading the file in reverse, until you find a potential culprit. That is:
> start of the end of the output file reading towards the beginning.
>
> Quite honestly, I have no idea what you should be looking for, But I
> suspect you'll know it when you see it. But if you do not, You could paste
> the last 10 lines of output here, or so. Then see if any one else here can
> spot a potential problem. I think that it could be very likely you will not
> see an exact cause, but instead see something that should give a very good
> indication as to what the 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/CALHSORrZXZiAYuzvVAtJ3krrfdVUT5RjR-PP0NwvyF5CfCbjNA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] hdmi audio stops at 10 minutes after boot --- always.

[William Hermans]

On Mon, Jan 2, 2017 at 12:28 PM, John Franey  wrote:

> What do you think strace would show?
>
> I used strace a long time ago.  Back then, it traced the system calls of
> an application process.   What should I look for in that output?
>
> Thanks,
> John
>

Ok so then you know what strace is then I suppose. In your case, I would
*imagine* strace would make things really easy to understand what is
happening at that 10 minute mark. Since in your shoes, I'd run everything
normally, but through strace. There is very likely going to be a lot of
output. So you'd want to output that to a file, using the -o option( dash
oh, as in Oscar ). Passed that I then( I would think ) becomes a matter of
reading the file in reverse, until you find a potential culprit. That is:
start of the end of the output file reading towards the beginning.

Quite honestly, I have no idea what you should be looking for, But I
suspect you'll know it when you see it. But if you do not, You could paste
the last 10 lines of output here, or so. Then see if any one else here can
spot a potential problem. I think that it could be very likely you will not
see an exact cause, but instead see something that should give a very good
indication as to what the 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/CALHSORqo-Y%3D%2BQ8JoDZzq2bJ2bbeBcGOtgiO7ugAMKAD_183Drw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: SPI on beagle bone black and beagle bone black wireless

[William Hermans]

Yeah, I dont know. For me, it's all a moot point. The biggest hurdle to
understanding devices on the beaglebone, is first understanding the
hardware period. Then you need to understand the subsystems for each device
type - On Linux. After that, device trees, and device tree overlays all
start to make sense. Device tree files after all are only hardware
descriptions.

Anyway, to answer your question, about universal IO. No I don't have a
problem with it at all. But at some point, you'll realize that universal IO
is a generic set of device tree overlays, with a tool(config-pin) to make
pix muxing much simplier. e.g. an abstraction layer. At some point, you may
actually find yourself not wanting to use it. For me, part of my nature is
that I *have* to understand how things work, after which sometimes things
may become redundant. . .

On Mon, Jan 2, 2017 at 6:10 AM, Greg  wrote:

> Hi William, great inputs and perhaps we can ask Clayton to push these
> additional details to the repository.
>
> There should be a clear delimiter between the current and experimental
> improvements.
> I wonder if there is going to be a distinct cut-over to the revised Uboot
> process?  Maybe too soon to determine.
>
> Another thing:
>
> 1.  dtb-rebuilder
> https://github.com/RobertCNelson/dtb-rebuilder
> 2.  bb.org-overlays
> https://github.com/RobertCNelson/bb.org-overlays
>
> Perhaps not a newbie concern, as I think 1 and 2 above are at the
> intermediate level.
> I think these should at least be mentioned as they are important bits for
> dealing with the Beagleboard Device Tree ecosystem.
>
> Regards,
> Greg
>
> --
> 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/d7035e17-09a1-4839-b287-cfcecc60576d%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/CALHSORom8CGBs3uDUi3MGKwJcDmsVij5MN9H2CWWTG9XKan2oQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] hdmi audio stops at 10 minutes after boot --- always.

[John Franey]

What do you think strace would show?

I used strace a long time ago.  Back then, it traced the system calls of an 
application process.   What should I look for in that output?

Thanks,
John


On Sunday, January 1, 2017 at 6:07:58 PM UTC-5, William Hermans wrote:
>
> I'd probably try to run your executable through strace, and output into a 
> file.
>
> On Sun, Jan 1, 2017 at 1:25 PM, John Franey  > wrote:
>
>> I have hdmi audio working up until 10 minutes from boot time.  Exactly 10 
>> minutes.every boot.
>>
>> I test with 'speaker-test'.  Running continuously.  Output stops exactly 
>> at TimeBoot + 10mins.
>>
>> There is no outward appearance of a problem:
>> 1)  The output of speaker-test is not affected.  Blissfully continues to 
>> test: "Right channelLeft channelRight channeletc".
>> 2) No message in dmesg.
>> 3) No message in /var/log/*
>>
>>
>> How can I debug?
>>
>> Any hypotheses?
>>
>> Thanks
>>
>> root@beaglebone:~# uname -a
>> Linux beaglebone 4.4.30-ti-r64 #1 SMP Fri Nov 4 21:23:33 UTC 2016 armv7l 
>> GNU/Linux
>>
>> root@beaglebone:~# cat /etc/debian_version
>> 8.6
>>
>>
>> -- 
>> 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/3c2aedb0-70b7-42ff-8ef7-4782590f9838%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/82c7fad8-99fd-420d-802a-44c4ba4c67fd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] hdmi audio stops at 10 minutes after boot --- always.

[John Franey]

No.  I don't have a serial debug cable.


If you have a link to the other messages, can you provide a reference (a 
link or search string or something) so I can read them too?

What exactly do you mean /that some messages only get spit out on that 
port'?  I don't know what action to take from this.

Can you elaborate?

Thanks.

On Sunday, January 1, 2017 at 3:44:10 PM UTC-5, Wulf Man wrote:
>
> Do you have a serial debug cable ?
> I have seen posts here saying that some messages only get spit out on that 
> port.
>
>
> On 1/1/2017 1:25 PM, John Franey wrote:
>
> I have hdmi audio working up until 10 minutes from boot time.  Exactly 10 
> minutes.every boot. 
>
> I test with 'speaker-test'.  Running continuously.  Output stops exactly 
> at TimeBoot + 10mins.
>
> There is no outward appearance of a problem:
> 1)  The output of speaker-test is not affected.  Blissfully continues to 
> test: "Right channelLeft channelRight channeletc".
> 2) No message in dmesg.
> 3) No message in /var/log/*
>
>
> How can I debug?
>
> Any hypotheses?
>
> Thanks
>
> root@beaglebone:~# uname -a
> Linux beaglebone 4.4.30-ti-r64 #1 SMP Fri Nov 4 21:23:33 UTC 2016 armv7l 
> GNU/Linux
>
> root@beaglebone:~# cat /etc/debian_version
> 8.6
>
>
> -- 
> 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/3c2aedb0-70b7-42ff-8ef7-4782590f9838%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/772fd90c-61c3-49e8-a4d7-6f0a675f7159%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] hdmi audio stops 10 minutes after boot, repeatable

[William Hermans]

Any reason why you can't look at the post you made yesterday ?

On Mon, Jan 2, 2017 at 12:17 PM, John Franey  wrote:

> Black's hdmi connected to an hdmi-2-av external powered device connected
> to a power amplifier connected to speakers.
>
> In other words:  Black -> hdmi-2-av -> amplifier -> speakers
>
> Audio is tested with 'speaker-test'.  Speaker-test is started soon after
> reboot.  "Right channel.left channel.right channelleft
> channel"
>
> The test tone is heard as expected until exactly 10 minutes after reboot.
>
> The only external sign of a problem is no more sound.  There are no log
> messages in dmesg or /var/log/*.  speaker-test continues to run, sending
> text to stdout.
>
>
> Any hypotheses?
>
> How can I debug?
>
> Thanks.
> John
>
>
>
>
> Other info:
>
> The faulty black runs this linux:
>
> root@beaglebone:~# uname -a
> Linux beaglebone 4.4.30-ti-r64 #1 SMP Fri Nov 4 21:23:33 UTC 2016 armv7l
> GNU/Linux
> root@beaglebone:~# cat /etc/debian_version
> 8.6
>
>
>
> I have a second black and it does not have audio problem.  It was
> purchased several months earlier than the above.  It is running factory
> provided angstrom.  I don't have it handy to obtain the 'uname -a' output.
>
> --
> 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/5a14a8d0-919d-4801-8940-2fb9c4a29b70%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/CALHSORrfk4WVm7JLHqvnu%2BhH0VBijmts%3DW3-24xvOXAXuahjCQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: hdmi audio stops 10 minutes after boot, repeatable

[John Franey]

Sorry for the double post.  Please ignore this one.  I didn't find my first 
attempt and thought it was lost.

On Monday, January 2, 2017 at 2:17:33 PM UTC-5, John Franey wrote:
>
> Black's hdmi connected to an hdmi-2-av external powered device connected 
> to a power amplifier connected to speakers.
>
> In other words:  Black -> hdmi-2-av -> amplifier -> speakers
>
> Audio is tested with 'speaker-test'.  Speaker-test is started soon after 
> reboot.  "Right channel.left channel.right channelleft 
> channel"
>
> The test tone is heard as expected until exactly 10 minutes after reboot.
>
> The only external sign of a problem is no more sound.  There are no log 
> messages in dmesg or /var/log/*.  speaker-test continues to run, sending 
> text to stdout.
>
>
> Any hypotheses?
>
> How can I debug?
>
> Thanks.
> John
>
>
>
>
> Other info:
>
> The faulty black runs this linux:
>
> root@beaglebone:~# uname -a
> Linux beaglebone 4.4.30-ti-r64 #1 SMP Fri Nov 4 21:23:33 UTC 2016 armv7l 
> GNU/Linux
> root@beaglebone:~# cat /etc/debian_version
> 8.6
>
>
>
> I have a second black and it does not have audio problem.  It was 
> purchased several months earlier than the above.  It is running factory 
> provided angstrom.  I don't have it handy to obtain the 'uname -a' output.
>

-- 
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/2b2ece49-5406-4a5c-b818-ecf65902e449%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] hdmi audio stops 10 minutes after boot, repeatable

[John Franey]

Black's hdmi connected to an hdmi-2-av external powered device connected to 
a power amplifier connected to speakers.

In other words:  Black -> hdmi-2-av -> amplifier -> speakers

Audio is tested with 'speaker-test'.  Speaker-test is started soon after 
reboot.  "Right channel.left channel.right channelleft 
channel"

The test tone is heard as expected until exactly 10 minutes after reboot.

The only external sign of a problem is no more sound.  There are no log 
messages in dmesg or /var/log/*.  speaker-test continues to run, sending 
text to stdout.


Any hypotheses?

How can I debug?

Thanks.
John




Other info:

The faulty black runs this linux:

root@beaglebone:~# uname -a
Linux beaglebone 4.4.30-ti-r64 #1 SMP Fri Nov 4 21:23:33 UTC 2016 armv7l 
GNU/Linux
root@beaglebone:~# cat /etc/debian_version
8.6



I have a second black and it does not have audio problem.  It was purchased 
several months earlier than the above.  It is running factory provided 
angstrom.  I don't have it handy to obtain the 'uname -a' output.

-- 
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/5a14a8d0-919d-4801-8940-2fb9c4a29b70%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Do not power BBB/BBG via USB?

[Alex Hayman]

I wasn't able to find one.  I believe it's built in to the hardware of 
http://www.ti.com/lit/ds/symlink/tps65217.pdf
Feel free to review and see if you come to the same conclusion that I did!

Cheers,
Alex

On Monday, January 2, 2017 at 2:29:31 AM UTC-5, Heinz Hummel wrote:
>
> Great - thanks! So there is no way to do that programmatically via PMIC?
>
> 2016-12-29 8:59 GMT+01:00 Alex Hayman 
> :
>
>> If you cut that trace on a BBB, then the BBB won't power itself up via 
>> USB.
>>
>> On Friday, December 23, 2016 at 4:25:08 AM UTC-5, Heinz Hummel wrote:
>>>
>>> Hello,
>>>
>>> I have a BBB which is currently powered via USB and external power 
>>> supply (and a similar BBG which is powered via USB and via external supply 
>>> feed into VDD from connected cape).
>>>
>>> Now when a user wants to do a full power cycle, all possible power 
>>> sources have to be disconnected which can be somewhat complicated.
>>>
>>> So my question: is there a possibility to disable power supply via USB? 
>>> E.g. a soldering jumper which has to be opened? Or in case not - is there a 
>>> possibility to permanently program the PMIC to not to power the board from 
>>> USB?
>>>
>>> Thanks!
>>>
>>> -- 
>> 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/dR_GhlwG0eM/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> beagleboard...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/5d9e2fb6-14be-4223-9375-2882df001000%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/50bc6048-b8a1-4a3b-8783-61db31471396%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: SPI on beagle bone black and beagle bone black wireless

[lorrianemayfield via BeagleBoard]

On Mon, 1/2/17, Greg  wrote:

 Subject: Re: [beagleboard] Re: SPI on beagle bone black and beagle bone black 
wireless
 To: "BeagleBoard" 
 Date: Monday, January 2, 2017, 3:10 PM
 
 Hi William, great
 inputs and perhaps we can ask Clayton to push these
 additional details to the repository.
 There should be a clear delimiter between the current
 and experimental improvements.
 I wonder if there is going to be a distinct cut-over to
 the revised Uboot process?  Maybe too soon to
 determine.
 Another thing:
 1.
  dtb-rebuilderhttps://github.com/RobertCNelson/dtb-rebuilder
 2.
  bb.org-overlayshttps://github.com/RobertCNelson/bb.org-overlays
 Perhaps not a newbie concern, as I think 1 and 2
 above are at the intermediate level. I think
 these should at least be mentioned as they are important
 bits for dealing with the Beagleboard Device Tree
 ecosystem.
 Regards,Greg
 
 
 
 
 -- 
 
 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/d7035e17-09a1-4839-b287-cfcecc60576d%40googlegroups.com.
 
 For more options, visit https://groups.google.com/d/optout.
 oldova  opozitia fata de politica domnitorului Mihail Sturdza s-a at  la 27 
martie 7 aprilie  intr-o Adunare populara desfasurata la Hotelul rg din lasi. 
Adunarea a fost condusa de Grigore Cuza. Protestand gimului lui Mihail Sturdza  
Adunarea  ce cuprindea reprezentanti ai irtelor sociale si politice  a numit o 
comisie care sa redacteze un de revendicari. Un rol important in elaborarea sa 
l-a avut Vasile n  documentul  Petitiunea-proclamatiune   apartinand boierilor 
si  moldoveni. El cuprindea 35 de puncte si avea  aparent  un caracter 
incercand sa se pastreze in limitele legalitatii politice datorita temerii de 
Rus  de aceea  la primul punct se proclama Sfanta pazire a untului Organic in 
tot cuprinsul sau si fara nici o rastalmacire   Aceasta iur  o prevedere ce 
urma sa atenueze o posibila reactie a Rusiei tariste  ii moderat reiese si din 
abordarea problemei agrare  solicitandu-se doargrabnica imbunatatire a starii 
locuitorilor sateni . Erau prevazute si revendicari cu caracter democratic  
modern  precum eliberarea detinutilor politici  o reforma a sistemului de 
invatamant  siguranta persoanei  desfiintarea cenzurii.

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

[beagleboard] Re: BBB/jessie/4.1.10-ti-r21 -- bone_capemgr: loader: failed to load slot-0 BB-SERIAL:00A0 (prio 0)

[Dean Gouramanis]

I solved the problem by installing the latest image from beaglebone.org. 
Now I can load capes no problem.

Thanks anyway. 


On Sunday, January 1, 2017 at 2:16:58 AM UTC-5, Dean Gouramanis wrote:
>
> I am having a similar problem as described above. I am trying to load a 
> custom cape. 
>
> I am trying to load a copy of BB-BONE-LCD4.dts. Eventually I plan to 
> modify this overlay to include an LCD panel, but for now i've *cloned the 
> dts file*, changed the part number to DOPTOCAPE1, and renamed the file 
> DOPTOCAPE1.dts
>
> I placed the file in /src/arm directory, then ran install.sh
>
> I cheked that DOPTOCAPE1.dtbo is now in /lib/firmware
>
> Then I made the changes in my uEnv.txt file, and rebooted.
>
> Here is debug from the boot process:
>
> [0.00] Kernel command line: console=ttyO0,115200n8 
> capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN 
> capemgr.enable_partno=dev_OPTOCAPE 
> root=UUID=509a5094-05c2-4cf0-803d-945708cd72b5 ro rootfstype=ext4 rootwait 
> coherent_pool=1M quiet net.ifnames=0 
> [0.610669] bone-capemgr bone_capemgr.9: Baseboard: 
> 'A335BNLT,000C,3914BBBK2717' 
> [0.610691] bone-capemgr bone_capemgr.9: 
> compatible-baseboard=ti,beaglebone-black 
> [0.610729] bone-capemgr bone_capemgr.9: Skipping disabled cape with 
> part# BB-BONELT-HDMI 
> [0.610773] bone-capemgr bone_capemgr.9: Skipping disabled cape with 
> part# BB-BONELT-HDMIN 
> [0.641898] bone-capemgr bone_capemgr.9: slot #0: No cape found 
> [0.679000] bone-capemgr bone_capemgr.9: slot #1: No cape found 
> [0.716114] bone-capemgr bone_capemgr.9: slot #2: No cape found 
> [0.753223] bone-capemgr bone_capemgr.9: slot #3: No cape found 
> [0.759455] bone-capemgr bone_capemgr.9: slot #4: specific override 
> [0.759476] bone-capemgr bone_capemgr.9: bone: Using override eeprom 
> data at slot 4 
> [0.759492] bone-capemgr bone_capemgr.9: slot #4: 
> 'Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G' 
> [0.759565] bone-capemgr bone_capemgr.9: slot #5: specific override 
> [0.759582] bone-capemgr bone_capemgr.9: bone: Using override eeprom 
> data at slot 5 
> [0.759595] bone-capemgr bone_capemgr.9: slot #5: 
> 'Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI' 
> [0.759667] bone-capemgr bone_capemgr.9: slot #6: specific override 
> [0.759683] bone-capemgr bone_capemgr.9: bone: Using override eeprom 
> data at slot 6 
> [0.759696] bone-capemgr bone_capemgr.9: slot #6: 
> 'Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN' 
> [0.759755] bone-capemgr bone_capemgr.9: enabled_partno part_number 
> 'dev_OPTOCAPE', version 'N/A', prio '0' 
> [0.759768] bone-capemgr bone_capemgr.9: slot #7: generic override 
> [0.759779] bone-capemgr bone_capemgr.9: bone: Using override eeprom 
> data at slot 7 
> [0.759792] bone-capemgr bone_capemgr.9: slot #7: 'Override Board 
> Name,00A0,Override Manuf,dev_OPTOCAPE' 
> [0.759896] bone-capemgr bone_capemgr.9: Skipping loading of disabled 
> cape with part# BB-BONELT-HDMI 
> [0.759908] bone-capemgr bone_capemgr.9: Skipping loading of disabled 
> cape with part# BB-BONELT-HDMIN 
> [0.760092] bone-capemgr bone_capemgr.9: loader: before slot-4 
> BB-BONE-EMMC-2G:00A0 (prio 1) 
> [0.760107] bone-capemgr bone_capemgr.9: loader: check slot-4 
> BB-BONE-EMMC-2G:00A0 (prio 1) 
> [0.760134] bone-capemgr bone_capemgr.9: initialized OK. 
> [0.762291] bone-capemgr bone_capemgr.9: loader: check slot-4 
> BB-BONE-EMMC-2G:00A0 (prio 1) 
> [0.764081] bone-capemgr bone_capemgr.9: loader: before slot-7 
> dev_OPTOCAPE:00A0 (prio 0) 
> [0.764094] bone-capemgr bone_capemgr.9: loader: check slot-7 
> dev_OPTOCAPE:00A0 (prio 0) 
> [0.764109] bone-capemgr bone_capemgr.9: loader: after slot-7 
> dev_OPTOCAPE:00A0 (prio 0) 
> [0.764124] bone-capemgr bone_capemgr.9: slot #7: Requesting part 
> number/version based 'dev_OPTOCAPE-00A0.dtbo 
> [0.764139] bone-capemgr bone_capemgr.9: slot #7: Requesting firmware 
> 'dev_OPTOCAPE-00A0.dtbo' for board-name 'Override Board Name', version 
> '00A0' 
> [1.239617] bone-capemgr bone_capemgr.9: failed to load firmware 
> 'dev_OPTOCAPE-00A0.dtbo' 
> [1.248179] bone-capemgr bone_capemgr.9: loader: failed to load slot-7 
> dev_OPTOCAPE:00A0 (prio 0) 
> [1.257645] bone-capemgr bone_capemgr.9: loader: check slot-4 
> BB-BONE-EMMC-2G:00A0 (prio 1) 
> [1.257662] bone-capemgr bone_capemgr.9: loader: after slot-4 
> BB-BONE-EMMC-2G:00A0 (prio 1) 
> [1.257685] bone-capemgr bone_capemgr.9: slot #4: Requesting firmware 
> 'cape-bone-2g-emmc1.dtbo' for board-name 'Bone-LT-eMMC-2G', version '00A0' 
> [1.257702] bone-capemgr bone_capemgr.9: slot #4: dtbo 
> 'cape-bone-2g-emmc1.dtbo' loaded; converting to live tree 
> [1.257911] bone-capemgr bone_capemgr.9: slot #4: #2 overlays 
> [1.286653] bone-capemgr bone_capemgr.9: slot #4: Applied #2 overlays. 
> [1.286678] bone-capemgr bone_capemgr.9: loader: done slot-4 

Re: [beagleboard] Re: SPI on beagle bone black and beagle bone black wireless

[Greg]

Hi William, great inputs and perhaps we can ask Clayton to push these 
additional details to the repository.

There should be a clear delimiter between the current and experimental 
improvements.
I wonder if there is going to be a distinct cut-over to the revised Uboot 
process?  Maybe too soon to determine.

Another thing:

1.  dtb-rebuilder
https://github.com/RobertCNelson/dtb-rebuilder
2.  bb.org-overlays
https://github.com/RobertCNelson/bb.org-overlays

Perhaps not a newbie concern, as I think 1 and 2 above are at the 
intermediate level. 
I think these should at least be mentioned as they are important bits for 
dealing with the Beagleboard Device Tree ecosystem.

Regards,
Greg

-- 
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/d7035e17-09a1-4839-b287-cfcecc60576d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.