Re: [beagleboard] Disconnect HDMI cape from Cape Manager

[Kenny Koller]

By this I mean I have my uEnv.txt configured in this way and I see these 
messages. Not that it fixed it. Thanks.

On Monday, February 26, 2018 at 7:10:39 PM UTC-8, Kenny Koller wrote:
>
> Thanks. I had a line in there to disable it but have commented it out.
>
>
> uname_r=3.8.13-bone62
>
>
> optargs=quiet drm.debug=7
>
>
> findfdt=setenv fdtfile am335x-boneblack.dtb
>
>
> cape_enable=capemgr.enable_partno=BB-SPIDEV0
>
>
> #cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
>
>
>
>
> On Monday, February 26, 2018 at 7:06:12 PM UTC-8, Wulf Man wrote:
>>
>> Check /boot/uEnv.txt to see if its being loaded in there
>>
>>
>> On 2/26/2018 8:04 PM, Kenny Koller wrote:
>>
>> I am running the 3.8 kernel on an Arrow Beaglebone Black Industrial. I 
>> have rebuilt the device tree blob to exclude HDMI but I still see the error 
>> messages below. What is the best way to stop these from occuring? Are there 
>> configuration files for the cape manager? 
>>
>> Thanks
>>
>> Duchess: dmesg | grep HDMI
>>> [0.701013] bone-capemgr bone_capemgr.9: slot #5: 
>>> 'Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI'
>>> [0.701113] bone-capemgr bone_capemgr.9: slot #6: 
>>> 'Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN'
>>> [0.701654] bone-capemgr bone_capemgr.9: loader: before slot-5 
>>> BB-BONELT-HDMI:00A0 (prio 1)
>>> [0.701667] bone-capemgr bone_capemgr.9: loader: check slot-5 
>>> BB-BONELT-HDMI:00A0 (prio 1)
>>> [0.701737] bone-capemgr bone_capemgr.9: loader: before slot-6 
>>> BB-BONELT-HDMIN:00A0 (prio 2)
>>> [0.701750] bone-capemgr bone_capemgr.9: loader: check slot-6 
>>> BB-BONELT-HDMIN:00A0 (prio 2)
>>> [0.702354] bone-capemgr bone_capemgr.9: loader: check slot-5 
>>> BB-BONELT-HDMI:00A0 (prio 1)
>>> [0.704458] bone-capemgr bone_capemgr.9: loader: check slot-6 
>>> BB-BONELT-HDMIN:00A0 (prio 2)
>>> [0.726410] bone-capemgr bone_capemgr.9: loader: check slot-6 
>>> BB-BONELT-HDMIN:00A0 (prio 2)
>>> [0.726453] bone-capemgr bone_capemgr.9: loader: check slot-5 
>>> BB-BONELT-HDMI:00A0 (prio 1)
>>> [0.726467] bone-capemgr bone_capemgr.9: loader: after slot-5 
>>> BB-BONELT-HDMI:00A0 (prio 1)
>>> [0.726483] bone-capemgr bone_capemgr.9: slot #5: Requesting part 
>>> number/version based 'BB-BONELT-HDMI-00A0.dtbo
>>> [0.726499] bone-capemgr bone_capemgr.9: slot #5: Requesting firmware 
>>> 'BB-BONELT-HDMI-00A0.dtbo' for board-name 'Bone-Black-HDMI', version '00A0'
>>> [0.999594] bone-capemgr bone_capemgr.9: failed to load firmware 
>>> 'BB-BONELT-HDMI-00A0.dtbo'
>>> [1.008403] bone-capemgr bone_capemgr.9: loader: failed to load 
>>> slot-5 BB-BONELT-HDMI:00A0 (prio 1)
>>> [1.019624] bone-capemgr bone_capemgr.9: loader: check slot-6 
>>> BB-BONELT-HDMIN:00A0 (prio 2)
>>> [1.046607] bone-capemgr bone_capemgr.9: loader: check slot-6 
>>> BB-BONELT-HDMIN:00A0 (prio 2)
>>> [1.046626] bone-capemgr bone_capemgr.9: loader: after slot-6 
>>> BB-BONELT-HDMIN:00A0 (prio 2)
>>> [1.046643] bone-capemgr bone_capemgr.9: slot #6: Requesting part 
>>> number/version based 'BB-BONELT-HDMIN-00A0.dtbo
>>> [1.046661] bone-capemgr bone_capemgr.9: slot #6: Requesting firmware 
>>> 'BB-BONELT-HDMIN-00A0.dtbo' for board-name 'Bone-Black-HDMIN', version 
>>> '00A0'
>>> [1.593939] bone-capemgr bone_capemgr.9: failed to load firmware 
>>> 'BB-BONELT-HDMIN-00A0.dtbo'
>>> [1.602870] bone-capemgr bone_capemgr.9: loader: failed to load 
>>> slot-6 BB-BONELT-HDMIN:00A0 (prio 2)
>>>
>>
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/70798894-b508-499e-92c8-ba663297e275%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/beagleboard/70798894-b508-499e-92c8-ba663297e275%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>

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

Re: [beagleboard] Disconnect HDMI cape from Cape Manager

[Kenny Koller]

Thanks. I had a line in there to disable it but have commented it out.


uname_r=3.8.13-bone62


optargs=quiet drm.debug=7


findfdt=setenv fdtfile am335x-boneblack.dtb


cape_enable=capemgr.enable_partno=BB-SPIDEV0


#cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN




On Monday, February 26, 2018 at 7:06:12 PM UTC-8, Wulf Man wrote:
>
> Check /boot/uEnv.txt to see if its being loaded in there
>
>
> On 2/26/2018 8:04 PM, Kenny Koller wrote:
>
> I am running the 3.8 kernel on an Arrow Beaglebone Black Industrial. I 
> have rebuilt the device tree blob to exclude HDMI but I still see the error 
> messages below. What is the best way to stop these from occuring? Are there 
> configuration files for the cape manager? 
>
> Thanks
>
> Duchess: dmesg | grep HDMI
>> [0.701013] bone-capemgr bone_capemgr.9: slot #5: 
>> 'Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI'
>> [0.701113] bone-capemgr bone_capemgr.9: slot #6: 
>> 'Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN'
>> [0.701654] bone-capemgr bone_capemgr.9: loader: before slot-5 
>> BB-BONELT-HDMI:00A0 (prio 1)
>> [0.701667] bone-capemgr bone_capemgr.9: loader: check slot-5 
>> BB-BONELT-HDMI:00A0 (prio 1)
>> [0.701737] bone-capemgr bone_capemgr.9: loader: before slot-6 
>> BB-BONELT-HDMIN:00A0 (prio 2)
>> [0.701750] bone-capemgr bone_capemgr.9: loader: check slot-6 
>> BB-BONELT-HDMIN:00A0 (prio 2)
>> [0.702354] bone-capemgr bone_capemgr.9: loader: check slot-5 
>> BB-BONELT-HDMI:00A0 (prio 1)
>> [0.704458] bone-capemgr bone_capemgr.9: loader: check slot-6 
>> BB-BONELT-HDMIN:00A0 (prio 2)
>> [0.726410] bone-capemgr bone_capemgr.9: loader: check slot-6 
>> BB-BONELT-HDMIN:00A0 (prio 2)
>> [0.726453] bone-capemgr bone_capemgr.9: loader: check slot-5 
>> BB-BONELT-HDMI:00A0 (prio 1)
>> [0.726467] bone-capemgr bone_capemgr.9: loader: after slot-5 
>> BB-BONELT-HDMI:00A0 (prio 1)
>> [0.726483] bone-capemgr bone_capemgr.9: slot #5: Requesting part 
>> number/version based 'BB-BONELT-HDMI-00A0.dtbo
>> [0.726499] bone-capemgr bone_capemgr.9: slot #5: Requesting firmware 
>> 'BB-BONELT-HDMI-00A0.dtbo' for board-name 'Bone-Black-HDMI', version '00A0'
>> [0.999594] bone-capemgr bone_capemgr.9: failed to load firmware 
>> 'BB-BONELT-HDMI-00A0.dtbo'
>> [1.008403] bone-capemgr bone_capemgr.9: loader: failed to load slot-5 
>> BB-BONELT-HDMI:00A0 (prio 1)
>> [1.019624] bone-capemgr bone_capemgr.9: loader: check slot-6 
>> BB-BONELT-HDMIN:00A0 (prio 2)
>> [1.046607] bone-capemgr bone_capemgr.9: loader: check slot-6 
>> BB-BONELT-HDMIN:00A0 (prio 2)
>> [1.046626] bone-capemgr bone_capemgr.9: loader: after slot-6 
>> BB-BONELT-HDMIN:00A0 (prio 2)
>> [1.046643] bone-capemgr bone_capemgr.9: slot #6: Requesting part 
>> number/version based 'BB-BONELT-HDMIN-00A0.dtbo
>> [1.046661] bone-capemgr bone_capemgr.9: slot #6: Requesting firmware 
>> 'BB-BONELT-HDMIN-00A0.dtbo' for board-name 'Bone-Black-HDMIN', version 
>> '00A0'
>> [1.593939] bone-capemgr bone_capemgr.9: failed to load firmware 
>> 'BB-BONELT-HDMIN-00A0.dtbo'
>> [1.602870] bone-capemgr bone_capemgr.9: loader: failed to load slot-6 
>> BB-BONELT-HDMIN:00A0 (prio 2)
>>
>
> -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/70798894-b508-499e-92c8-ba663297e275%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/beagleboard/70798894-b508-499e-92c8-ba663297e275%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

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

[beagleboard] Disconnect HDMI cape from Cape Manager

[Kenny Koller]

I am running the 3.8 kernel on an Arrow Beaglebone Black Industrial. I have 
rebuilt the device tree blob to exclude HDMI but I still see the error 
messages below. What is the best way to stop these from occuring? Are there 
configuration files for the cape manager?

Thanks

Duchess: dmesg | grep HDMI
> [0.701013] bone-capemgr bone_capemgr.9: slot #5: 
> 'Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI'
> [0.701113] bone-capemgr bone_capemgr.9: slot #6: 
> 'Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN'
> [0.701654] bone-capemgr bone_capemgr.9: loader: before slot-5 
> BB-BONELT-HDMI:00A0 (prio 1)
> [0.701667] bone-capemgr bone_capemgr.9: loader: check slot-5 
> BB-BONELT-HDMI:00A0 (prio 1)
> [0.701737] bone-capemgr bone_capemgr.9: loader: before slot-6 
> BB-BONELT-HDMIN:00A0 (prio 2)
> [0.701750] bone-capemgr bone_capemgr.9: loader: check slot-6 
> BB-BONELT-HDMIN:00A0 (prio 2)
> [0.702354] bone-capemgr bone_capemgr.9: loader: check slot-5 
> BB-BONELT-HDMI:00A0 (prio 1)
> [0.704458] bone-capemgr bone_capemgr.9: loader: check slot-6 
> BB-BONELT-HDMIN:00A0 (prio 2)
> [0.726410] bone-capemgr bone_capemgr.9: loader: check slot-6 
> BB-BONELT-HDMIN:00A0 (prio 2)
> [0.726453] bone-capemgr bone_capemgr.9: loader: check slot-5 
> BB-BONELT-HDMI:00A0 (prio 1)
> [0.726467] bone-capemgr bone_capemgr.9: loader: after slot-5 
> BB-BONELT-HDMI:00A0 (prio 1)
> [0.726483] bone-capemgr bone_capemgr.9: slot #5: Requesting part 
> number/version based 'BB-BONELT-HDMI-00A0.dtbo
> [0.726499] bone-capemgr bone_capemgr.9: slot #5: Requesting firmware 
> 'BB-BONELT-HDMI-00A0.dtbo' for board-name 'Bone-Black-HDMI', version '00A0'
> [0.999594] bone-capemgr bone_capemgr.9: failed to load firmware 
> 'BB-BONELT-HDMI-00A0.dtbo'
> [1.008403] bone-capemgr bone_capemgr.9: loader: failed to load slot-5 
> BB-BONELT-HDMI:00A0 (prio 1)
> [1.019624] bone-capemgr bone_capemgr.9: loader: check slot-6 
> BB-BONELT-HDMIN:00A0 (prio 2)
> [1.046607] bone-capemgr bone_capemgr.9: loader: check slot-6 
> BB-BONELT-HDMIN:00A0 (prio 2)
> [1.046626] bone-capemgr bone_capemgr.9: loader: after slot-6 
> BB-BONELT-HDMIN:00A0 (prio 2)
> [1.046643] bone-capemgr bone_capemgr.9: slot #6: Requesting part 
> number/version based 'BB-BONELT-HDMIN-00A0.dtbo
> [1.046661] bone-capemgr bone_capemgr.9: slot #6: Requesting firmware 
> 'BB-BONELT-HDMIN-00A0.dtbo' for board-name 'Bone-Black-HDMIN', version 
> '00A0'
> [1.593939] bone-capemgr bone_capemgr.9: failed to load firmware 
> 'BB-BONELT-HDMIN-00A0.dtbo'
> [1.602870] bone-capemgr bone_capemgr.9: loader: failed to load slot-6 
> BB-BONELT-HDMIN:00A0 (prio 2)
>

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

[beagleboard] Re: Scheduling Latency of a Blocking UART Read.

[Kenny Koller]

Another detail is that I have had serial port code running for more than 
year on several hundred units that do not exhibit this issue. At first I 
thought it was because in this case I am using a blocking. I rewrote the 
code to use read with a timeout as with the earlier code and the problem 
persists.

I misstated the packet size above. It is 8 bytes. But that is also 
difference. My packets before were around 1 kB minimum. I'm wondering if 
there is some latency getting those bytes out of the hardware buffer or 
something like that.

On Monday, January 22, 2018 at 1:58:42 PM UTC-8, Kenny Koller wrote:
>
>
> I have a Python script that is running as a systemd service. It is using a 
> UART and SPI to communicate with an ARM processor. The process performs a 
> blocking read on the serial port waiting for 4 bytes. Using an oscilloscope 
> I measure the difference between when the serial port packet is transmitted 
> and when the read call returns. Most often this value is around 2 ms which 
> is fine. Sometimes (within 20 seconds to a minute) this value is 500 ms and 
> I've seen it be larger than 1 second. If attempted to use `chrt` to change 
> the static priority and scheduling policy. It reports that the values are 
> set correctly but the large latencies remain.
>
> This is with the 3.8.13-bone62 that I rebuilt to increase the SPI buffer. 
> The buffer size was the only change.
>
> Any thoughts on how to improve this? I can probably tolerate up to 100 ms.
>

-- 
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/f5e99901-cee0-4f23-b8ef-b0b3fef74f2e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Scheduling Latency of a Blocking UART Read.

[Kenny Koller]

I toggle an output pin on the Beaglebone in Python after the call to 
self._serial.read(8). I also measure the time in Python using time.time() 
and it jibes with what I see on the scope. Also the call to the SPI driver 
seems to have little latency and also have the SPI lines on the scope. So I 
can see the packet on the UART RX of the BBB and I can see the output pin 
go high at about the same time as the SPI clock burst and chip select.

On Monday, January 22, 2018 at 8:15:24 PM UTC-8, Przemek Klosowski wrote:
>
>
>
> On Mon, Jan 22, 2018 at 4:58 PM, Kenny Koller <ke...@understoryweather.com 
> > wrote:
>
>>
>>  the difference between when the serial port packet is transmitted and 
>> when the read call returns
>>
> Are you measuring the time to return to Python, or return from the read() 
> syscall? 
>

-- 
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/4bc14df8-acce-40f2-b9ad-2970acaf5bd5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Scheduling Latency of a Blocking UART Read.

[Kenny Koller]

I have a Python script that is running as a systemd service. It is using a 
UART and SPI to communicate with an ARM processor. The process performs a 
blocking read on the serial port waiting for 4 bytes. Using an oscilloscope 
I measure the difference between when the serial port packet is transmitted 
and when the read call returns. Most often this value is around 2 ms which 
is fine. Sometimes (within 20 seconds to a minute) this value is 500 ms and 
I've seen it be larger than 1 second. If attempted to use `chrt` to change 
the static priority and scheduling policy. It reports that the values are 
set correctly but the large latencies remain.

This is with the 3.8.13-bone62 that I rebuilt to increase the SPI buffer. 
The buffer size was the only change.

Any thoughts on how to improve this? I can probably tolerate up to 100 ms.

-- 
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/de2e6ab1-c36f-4bed-92d1-0dac0bd0b1cc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Rebuilding Kernel 3.8.13-bone62

[Kenny Koller]

For what it is worth: That script worked extremely well. That was a big 
help.

On Monday, November 6, 2017 at 5:22:18 PM UTC-8, Kenny Koller wrote:
>
> Will do. Thank you.
>
> On Monday, November 6, 2017 at 5:20:57 PM UTC-8, RobertCNelson wrote:
>>
>> On Mon, Nov 6, 2017 at 6:56 PM, Kenny Koller 
>> <ke...@understoryweather.com> wrote: 
>> > Thanks. I also found a tag (which didn't list when I searched for 
>> bone62 on 
>> > github under tags): 
>> > 
>> > Squall: git tag | grep bone62 
>> > 3.8.13-bone62 
>>
>> Yes it exists, but you'll be fighting even more issues to even use it. 
>> (well unless you had a time machine..) 
>>
>> Just follow the gist, i get this same rebuild "3.8." question 2-3 
>> times a week on average.. 
>>
>> 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/17d30be7-22e1-46a8-af59-055e17fd6954%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: SPI0 Overlay for Debian 3.8.13

[Kenny Koller]

For posterity (or extry posterity since this is for 3.8.13):

bone_capemgr should have been capemgr. A working uEnv.txt:

uname_r=3.8.13-bone62

optargs=quiet drm.debug=7

cape_enable=capemgr.enable_partno=BB-SPIDEV0

cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN

Next use compatible device tree source.

Clone g...@github.com:beagleboard/linux.git and checkout tag 3.8.13-bone62.

$ find . -name "*.dts" | grep SPI
./firmware/capes/BB-SPIDEV0-00A0.dts
./firmware/capes/BB-SPIDEV1-00A0.dts
./firmware/capes/BB-SPIDEV1A1-00A0.dts

Compile:

$ dtc -W no-unit_address_vs_reg -O dtb -o BB-SPIDEV0-00A0.dtbo -b 0 -@ BB-
SPIDEV0-00A0.dts
$ dtc --version
Version: DTC 1.4.5 

Place the .dtbo in /lib/firmware. Reboot. The SPI loopback test works:

./spidev_test -D /dev/spidev1.1
spi mode: 0
bits per word: 8
max speed: 50 Hz (500 KHz)

FF FF FF FF FF FF 
40 00 00 00 00 95 
FF FF FF FF FF FF 
FF FF FF FF FF FF 
FF FF FF FF FF FF 
DE AD BE EF BA AD 
F0 0D 


I found a DTS file that was included as part of an example of the use of 
> the ADAFruit Python library. I compiled it and placed in /lib/firmware:
>
> $ ls /lib/firmware
> 3.8.13-bone62  ADA-SPI0-01-00A0.dtbo  BB-SPI0-01-00A0.dtbo
>
> I attempt to enable this overlay in uEnv.txt.
>
> uname_r=3.8.13-bone62
> optargs=quiet drm.debug=7
> cape_enable=bone_capemgr.enable_partno=ADA-SPI0-01
>
> I can see that it is passed to the kernel.
>
> $ cat /proc/cmdline
> console=tty0 console=ttyO0,115200n8 quiet drm.debug=7 bone_capemgr.
> enable_partno=ADA-SPI0-01 root=/dev/mmcblk0p2 rw rootfstype=ext4 rootwait
>
> However the device nodes are not created and I do not see the overlay 
> listed.
>  
> $ cat /sys/devices/bone_capemgr.*/slots
>  0: 54:PF--- 
>  1: 55:PF--- 
>  2: 56:PF--- 
>  3: 57:PF--- 
>  4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
>  5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
>  7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART4
>  8: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART1
>
> dmesg information:
>
> [0.552308] bone-capemgr bone_capemgr.9: Baseboard: 
> 'A335BNLT,00C0,0816BBBK0B26'
> [0.552332] bone-capemgr bone_capemgr.9: compatible-baseboard=ti,
> beaglebone-black
> [0.583227] bone-capemgr bone_capemgr.9: slot #0: No cape found
> [0.620334] bone-capemgr bone_capemgr.9: slot #1: No cape found
> [0.657443] bone-capemgr bone_capemgr.9: slot #2: No cape found
> [0.694551] bone-capemgr bone_capemgr.9: slot #3: No cape found
> [0.700772] bone-capemgr bone_capemgr.9: slot #4: specific override
> [0.700795] bone-capemgr bone_capemgr.9: bone: Using override eeprom 
> data at slot 4
> [0.700811] bone-capemgr bone_capemgr.9: slot #4: 
> 'Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G'
> [0.700893] bone-capemgr bone_capemgr.9: slot #5: specific override
> [0.700911] bone-capemgr bone_capemgr.9: bone: Using override eeprom 
> data at slot 5
> [0.700925] bone-capemgr bone_capemgr.9: slot #5: 
> 'Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI'
> [0.700994] bone-capemgr bone_capemgr.9: slot #6: specific override
> [0.701011] bone-capemgr bone_capemgr.9: bone: Using override eeprom 
> data at slot 6
> [0.701025] bone-capemgr bone_capemgr.9: slot #6: 
> 'Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN'
> [0.701356] bone-capemgr bone_capemgr.9: loader: before slot-4 BB-BONE-
> EMMC-2G:00A0 (prio 1)
> [0.701371] bone-capemgr bone_capemgr.9: loader: check slot-4 BB-BONE-
> EMMC-2G:00A0 (prio 1)
> [0.701446] bone-capemgr bone_capemgr.9: loader: before slot-5 BB-
> BONELT-HDMI:00A0 (prio 1)
> [0.701459] bone-capemgr bone_capemgr.9: loader: check slot-5 BB-BONELT
> -HDMI:00A0 (prio 1)
> [0.701494] bone-capemgr bone_capemgr.9: initialized OK.
> [0.701950] bone-capemgr bone_capemgr.9: loader: after slot-4 BB-BONE-
> EMMC-2G:00A0 (prio 1)
> [0.701974] bone-capemgr bone_capemgr.9: slot #4: Requesting firmware 
> 'cape-bone-2g-emmc1.dtbo' for board-name 'Bone-LT-eMMC-2G', version '00A0'
> [0.701999] bone-capemgr bone_capemgr.9: slot #4: dtbo 
> 'cape-bone-2g-emmc1.dtbo' loaded; converting to live tree
> [0.702186] bone-capemgr bone_capemgr.9: slot #4: #2 overlays
> [0.702778] bone-capemgr bone_capemgr.9: slot #4: Applied #2 overlays.
> [0.702796] bone-capemgr bone_capemgr.9: loader: done slot-4 BB-BONE-
> EMMC-2G:00A0 (prio 1)
> [0.704413] bone-capemgr bone_capemgr.9: loader: after slot-5 BB-BONELT
> -HDMI:00A0 (prio 1)
> [0.704439] bone-capemgr bone_capemgr.9: slot #5: Requesting firmware 
> 'cape-boneblack-hdmi-00A0.dtbo' for board-name 'Bone-Black-HDMI', version 
> '00A0'
> [0.704468] bone-capemgr bone_capemgr.9: slot #5: dtbo 
> 'cape-boneblack-hdmi-00A0.dtbo' loaded; converting to live tree
> [0.705075] bone-capemgr bone_capemgr.9: slot #5: #4 overlays
> [0.709778] bone-capemgr bone_capemgr.9: slot #5: Applied #4 overlays.
> [0.709795] 

[beagleboard] Re: SPI0 Overlay for Debian 3.8.13

[Kenny Koller]

I mounted the eMMC card (/dev/mmcblk1) partitions and the root filesystem 
there has many .dtbo under lib/firmware but none of them are the ones lists 
from dmesg. They look to be the overlays to support the ADAFruit Python 
library. I'm not sure if those shipped with the Beaglebone distribution or 
were added by my predecessors. 

On Tuesday, November 7, 2017 at 6:33:43 PM UTC-8, Kenny Koller wrote:
>
> Also I don't understand where the cape manager is finding these .dtbo 
> files. I've searched the filesystem and the only files with this extension 
> are the two I've created and placed in /lib/firmware.
>
> On Tuesday, November 7, 2017 at 6:26:04 PM UTC-8, Kenny Koller wrote:
>>
>> I found a DTS file that was included as part of an example of the use of 
>> the ADAFruit Python library. I compiled it and placed in /lib/firmware:
>>
>> $ ls /lib/firmware
>> 3.8.13-bone62  ADA-SPI0-01-00A0.dtbo  BB-SPI0-01-00A0.dtbo
>>
>> I attempt to enable this overlay in uEnv.txt.
>>
>> uname_r=3.8.13-bone62
>> optargs=quiet drm.debug=7
>> cape_enable=bone_capemgr.enable_partno=ADA-SPI0-01
>>
>> I can see that it is passed to the kernel.
>>
>> $ cat /proc/cmdline
>> console=tty0 console=ttyO0,115200n8 quiet drm.debug=7 bone_capemgr.
>> enable_partno=ADA-SPI0-01 root=/dev/mmcblk0p2 rw rootfstype=ext4 rootwait
>>
>> However the device nodes are not created and I do not see the overlay 
>> listed.
>>  
>> $ cat /sys/devices/bone_capemgr.*/slots
>>  0: 54:PF--- 
>>  1: 55:PF--- 
>>  2: 56:PF--- 
>>  3: 57:PF--- 
>>  4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
>>  5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
>>  7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART4
>>  8: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART1
>>
>> dmesg information:
>>
>> [0.552308] bone-capemgr bone_capemgr.9: Baseboard: 
>> 'A335BNLT,00C0,0816BBBK0B26'
>> [0.552332] bone-capemgr bone_capemgr.9: compatible-baseboard=ti,
>> beaglebone-black
>> [0.583227] bone-capemgr bone_capemgr.9: slot #0: No cape found
>> [0.620334] bone-capemgr bone_capemgr.9: slot #1: No cape found
>> [0.657443] bone-capemgr bone_capemgr.9: slot #2: No cape found
>> [0.694551] bone-capemgr bone_capemgr.9: slot #3: No cape found
>> [0.700772] bone-capemgr bone_capemgr.9: slot #4: specific override
>> [0.700795] bone-capemgr bone_capemgr.9: bone: Using override eeprom 
>> data at slot 4
>> [0.700811] bone-capemgr bone_capemgr.9: slot #4: 
>> 'Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G'
>> [0.700893] bone-capemgr bone_capemgr.9: slot #5: specific override
>> [0.700911] bone-capemgr bone_capemgr.9: bone: Using override eeprom 
>> data at slot 5
>> [0.700925] bone-capemgr bone_capemgr.9: slot #5: 
>> 'Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI'
>> [0.700994] bone-capemgr bone_capemgr.9: slot #6: specific override
>> [0.701011] bone-capemgr bone_capemgr.9: bone: Using override eeprom 
>> data at slot 6
>> [0.701025] bone-capemgr bone_capemgr.9: slot #6: 
>> 'Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN'
>> [0.701356] bone-capemgr bone_capemgr.9: loader: before slot-4 BB-BONE
>> -EMMC-2G:00A0 (prio 1)
>> [0.701371] bone-capemgr bone_capemgr.9: loader: check slot-4 BB-BONE-
>> EMMC-2G:00A0 (prio 1)
>> [0.701446] bone-capemgr bone_capemgr.9: loader: before slot-5 BB-
>> BONELT-HDMI:00A0 (prio 1)
>> [0.701459] bone-capemgr bone_capemgr.9: loader: check slot-5 BB-
>> BONELT-HDMI:00A0 (prio 1)
>> [0.701494] bone-capemgr bone_capemgr.9: initialized OK.
>> [0.701950] bone-capemgr bone_capemgr.9: loader: after slot-4 BB-BONE-
>> EMMC-2G:00A0 (prio 1)
>> [0.701974] bone-capemgr bone_capemgr.9: slot #4: Requesting firmware 
>> 'cape-bone-2g-emmc1.dtbo' for board-name 'Bone-LT-eMMC-2G', version '00A0'
>> [0.701999] bone-capemgr bone_capemgr.9: slot #4: dtbo 
>> 'cape-bone-2g-emmc1.dtbo' loaded; converting to live tree
>> [0.702186] bone-capemgr bone_capemgr.9: slot #4: #2 overlays
>> [0.702778] bone-capemgr bone_capemgr.9: slot #4: Applied #2 overlays.
>> [0.702796] bone-capemgr bone_capemgr.9: loader: done slot-4 BB-BONE-
>> EMMC-2G:00A0 (prio 1)
>> [0.704413] bone-capemgr bone_capemgr.9: loader: after slot-5 BB-
>> BONELT-HDMI:00A0 (prio 1)
>> [0.704439] bone-capemgr bone_capemgr.9: slot #5: Requesting firmware 
>> 'cape-boneblack-hdmi-00A0.dtbo' for board-name 'Bone-Black-HDMI', version 
>> '0

[beagleboard] Re: SPI0 Overlay for Debian 3.8.13

[Kenny Koller]

Also I don't understand where the cape manager is finding these .dtbo 
files. I've searched the filesystem and the only files with this extension 
are the two I've created and placed in /lib/firmware.

On Tuesday, November 7, 2017 at 6:26:04 PM UTC-8, Kenny Koller wrote:
>
> I found a DTS file that was included as part of an example of the use of 
> the ADAFruit Python library. I compiled it and placed in /lib/firmware:
>
> $ ls /lib/firmware
> 3.8.13-bone62  ADA-SPI0-01-00A0.dtbo  BB-SPI0-01-00A0.dtbo
>
> I attempt to enable this overlay in uEnv.txt.
>
> uname_r=3.8.13-bone62
> optargs=quiet drm.debug=7
> cape_enable=bone_capemgr.enable_partno=ADA-SPI0-01
>
> I can see that it is passed to the kernel.
>
> $ cat /proc/cmdline
> console=tty0 console=ttyO0,115200n8 quiet drm.debug=7 bone_capemgr.
> enable_partno=ADA-SPI0-01 root=/dev/mmcblk0p2 rw rootfstype=ext4 rootwait
>
> However the device nodes are not created and I do not see the overlay 
> listed.
>  
> $ cat /sys/devices/bone_capemgr.*/slots
>  0: 54:PF--- 
>  1: 55:PF--- 
>  2: 56:PF--- 
>  3: 57:PF--- 
>  4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
>  5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
>  7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART4
>  8: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART1
>
> dmesg information:
>
> [0.552308] bone-capemgr bone_capemgr.9: Baseboard: 
> 'A335BNLT,00C0,0816BBBK0B26'
> [0.552332] bone-capemgr bone_capemgr.9: compatible-baseboard=ti,
> beaglebone-black
> [0.583227] bone-capemgr bone_capemgr.9: slot #0: No cape found
> [0.620334] bone-capemgr bone_capemgr.9: slot #1: No cape found
> [0.657443] bone-capemgr bone_capemgr.9: slot #2: No cape found
> [0.694551] bone-capemgr bone_capemgr.9: slot #3: No cape found
> [0.700772] bone-capemgr bone_capemgr.9: slot #4: specific override
> [0.700795] bone-capemgr bone_capemgr.9: bone: Using override eeprom 
> data at slot 4
> [0.700811] bone-capemgr bone_capemgr.9: slot #4: 
> 'Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G'
> [0.700893] bone-capemgr bone_capemgr.9: slot #5: specific override
> [0.700911] bone-capemgr bone_capemgr.9: bone: Using override eeprom 
> data at slot 5
> [0.700925] bone-capemgr bone_capemgr.9: slot #5: 
> 'Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI'
> [0.700994] bone-capemgr bone_capemgr.9: slot #6: specific override
> [0.701011] bone-capemgr bone_capemgr.9: bone: Using override eeprom 
> data at slot 6
> [0.701025] bone-capemgr bone_capemgr.9: slot #6: 
> 'Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN'
> [0.701356] bone-capemgr bone_capemgr.9: loader: before slot-4 BB-BONE-
> EMMC-2G:00A0 (prio 1)
> [0.701371] bone-capemgr bone_capemgr.9: loader: check slot-4 BB-BONE-
> EMMC-2G:00A0 (prio 1)
> [0.701446] bone-capemgr bone_capemgr.9: loader: before slot-5 BB-
> BONELT-HDMI:00A0 (prio 1)
> [0.701459] bone-capemgr bone_capemgr.9: loader: check slot-5 BB-BONELT
> -HDMI:00A0 (prio 1)
> [0.701494] bone-capemgr bone_capemgr.9: initialized OK.
> [0.701950] bone-capemgr bone_capemgr.9: loader: after slot-4 BB-BONE-
> EMMC-2G:00A0 (prio 1)
> [0.701974] bone-capemgr bone_capemgr.9: slot #4: Requesting firmware 
> 'cape-bone-2g-emmc1.dtbo' for board-name 'Bone-LT-eMMC-2G', version '00A0'
> [0.701999] bone-capemgr bone_capemgr.9: slot #4: dtbo 
> 'cape-bone-2g-emmc1.dtbo' loaded; converting to live tree
> [0.702186] bone-capemgr bone_capemgr.9: slot #4: #2 overlays
> [0.702778] bone-capemgr bone_capemgr.9: slot #4: Applied #2 overlays.
> [0.702796] bone-capemgr bone_capemgr.9: loader: done slot-4 BB-BONE-
> EMMC-2G:00A0 (prio 1)
> [0.704413] bone-capemgr bone_capemgr.9: loader: after slot-5 BB-BONELT
> -HDMI:00A0 (prio 1)
> [0.704439] bone-capemgr bone_capemgr.9: slot #5: Requesting firmware 
> 'cape-boneblack-hdmi-00A0.dtbo' for board-name 'Bone-Black-HDMI', version 
> '00A0'
> [0.704468] bone-capemgr bone_capemgr.9: slot #5: dtbo 
> 'cape-boneblack-hdmi-00A0.dtbo' loaded; converting to live tree
> [0.705075] bone-capemgr bone_capemgr.9: slot #5: #4 overlays
> [0.709778] bone-capemgr bone_capemgr.9: slot #5: Applied #4 overlays.
> [0.709795] bone-capemgr bone_capemgr.9: loader: done slot-5 BB-BONELT-
> HDMI:00A0 (prio 1)
> [0.709908] bone-capemgr bone_capemgr.9: loader: before slot-6 BB-
> BONELT-HDMIN:00A0 (prio 2)
> [0.709923] bone-capemgr bone_capemgr.9: loader: check slot-6 BB-BONELT
> -HDMIN:00A0 (prio 2)
> [0.709939] bone-capemgr bone_capemgr.9: loader: after slot-6 BB-BONELT
> -HDMIN:00A0 (prio 2)
> [0.709963] bone-capemgr bone_cape

[beagleboard] SPI0 Overlay for Debian 3.8.13

[Kenny Koller]

I found a DTS file that was included as part of an example of the use of 
the ADAFruit Python library. I compiled it and placed in /lib/firmware:

$ ls /lib/firmware
3.8.13-bone62  ADA-SPI0-01-00A0.dtbo  BB-SPI0-01-00A0.dtbo

I attempt to enable this overlay in uEnv.txt.

uname_r=3.8.13-bone62
optargs=quiet drm.debug=7
cape_enable=bone_capemgr.enable_partno=ADA-SPI0-01

I can see that it is passed to the kernel.

$ cat /proc/cmdline
console=tty0 console=ttyO0,115200n8 quiet drm.debug=7 bone_capemgr.
enable_partno=ADA-SPI0-01 root=/dev/mmcblk0p2 rw rootfstype=ext4 rootwait

However the device nodes are not created and I do not see the overlay 
listed.
 
$ cat /sys/devices/bone_capemgr.*/slots
 0: 54:PF--- 
 1: 55:PF--- 
 2: 56:PF--- 
 3: 57:PF--- 
 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
 5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
 7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART4
 8: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART1

dmesg information:

[0.552308] bone-capemgr bone_capemgr.9: Baseboard: 
'A335BNLT,00C0,0816BBBK0B26'
[0.552332] bone-capemgr bone_capemgr.9: compatible-baseboard=ti,
beaglebone-black
[0.583227] bone-capemgr bone_capemgr.9: slot #0: No cape found
[0.620334] bone-capemgr bone_capemgr.9: slot #1: No cape found
[0.657443] bone-capemgr bone_capemgr.9: slot #2: No cape found
[0.694551] bone-capemgr bone_capemgr.9: slot #3: No cape found
[0.700772] bone-capemgr bone_capemgr.9: slot #4: specific override
[0.700795] bone-capemgr bone_capemgr.9: bone: Using override eeprom 
data at slot 4
[0.700811] bone-capemgr bone_capemgr.9: slot #4: 
'Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G'
[0.700893] bone-capemgr bone_capemgr.9: slot #5: specific override
[0.700911] bone-capemgr bone_capemgr.9: bone: Using override eeprom 
data at slot 5
[0.700925] bone-capemgr bone_capemgr.9: slot #5: 
'Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI'
[0.700994] bone-capemgr bone_capemgr.9: slot #6: specific override
[0.701011] bone-capemgr bone_capemgr.9: bone: Using override eeprom 
data at slot 6
[0.701025] bone-capemgr bone_capemgr.9: slot #6: 
'Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN'
[0.701356] bone-capemgr bone_capemgr.9: loader: before slot-4 BB-BONE-
EMMC-2G:00A0 (prio 1)
[0.701371] bone-capemgr bone_capemgr.9: loader: check slot-4 BB-BONE-
EMMC-2G:00A0 (prio 1)
[0.701446] bone-capemgr bone_capemgr.9: loader: before slot-5 BB-BONELT-
HDMI:00A0 (prio 1)
[0.701459] bone-capemgr bone_capemgr.9: loader: check slot-5 BB-BONELT-
HDMI:00A0 (prio 1)
[0.701494] bone-capemgr bone_capemgr.9: initialized OK.
[0.701950] bone-capemgr bone_capemgr.9: loader: after slot-4 BB-BONE-
EMMC-2G:00A0 (prio 1)
[0.701974] bone-capemgr bone_capemgr.9: slot #4: Requesting firmware 
'cape-bone-2g-emmc1.dtbo' for board-name 'Bone-LT-eMMC-2G', version '00A0'
[0.701999] bone-capemgr bone_capemgr.9: slot #4: dtbo 
'cape-bone-2g-emmc1.dtbo' loaded; converting to live tree
[0.702186] bone-capemgr bone_capemgr.9: slot #4: #2 overlays
[0.702778] bone-capemgr bone_capemgr.9: slot #4: Applied #2 overlays.
[0.702796] bone-capemgr bone_capemgr.9: loader: done slot-4 BB-BONE-EMMC
-2G:00A0 (prio 1)
[0.704413] bone-capemgr bone_capemgr.9: loader: after slot-5 BB-BONELT-
HDMI:00A0 (prio 1)
[0.704439] bone-capemgr bone_capemgr.9: slot #5: Requesting firmware 
'cape-boneblack-hdmi-00A0.dtbo' for board-name 'Bone-Black-HDMI', version 
'00A0'
[0.704468] bone-capemgr bone_capemgr.9: slot #5: dtbo 
'cape-boneblack-hdmi-00A0.dtbo' loaded; converting to live tree
[0.705075] bone-capemgr bone_capemgr.9: slot #5: #4 overlays
[0.709778] bone-capemgr bone_capemgr.9: slot #5: Applied #4 overlays.
[0.709795] bone-capemgr bone_capemgr.9: loader: done slot-5 BB-BONELT-
HDMI:00A0 (prio 1)
[0.709908] bone-capemgr bone_capemgr.9: loader: before slot-6 BB-BONELT-
HDMIN:00A0 (prio 2)
[0.709923] bone-capemgr bone_capemgr.9: loader: check slot-6 BB-BONELT-
HDMIN:00A0 (prio 2)
[0.709939] bone-capemgr bone_capemgr.9: loader: after slot-6 BB-BONELT-
HDMIN:00A0 (prio 2)
[0.709963] bone-capemgr bone_capemgr.9: slot #6: Requesting firmware 
'cape-boneblack-hdmin-00A0.dtbo' for board-name 'Bone-Black-HDMIN', version 
'00A0'
[0.709990] bone-capemgr bone_capemgr.9: slot #6: dtbo 
'cape-boneblack-hdmin-00A0.dtbo' loaded; converting to live tree
[0.710292] bone-capemgr bone_capemgr.9: slot #6: BB-BONELT-HDMIN 
conflict P8.45 (#5:BB-BONELT-HDMI)
[0.719882] bone-capemgr bone_capemgr.9: slot #6: Failed verification
[0.726634] bone-capemgr bone_capemgr.9: loader: failed to load slot-6 BB
-BONELT-HDMIN:00A0 (prio 2)
[   16.416103] bone-capemgr bone_capemgr.9: part_number 'BB-UART4', version 
'N/A'
[   16.416179] bone-capemgr bone_capemgr.9: slot #7: generic override
[   16.416196] bone-capemgr bone_capemgr.9: bone: Using 

Re: [beagleboard] Rebuilding Kernel 3.8.13-bone62

[Kenny Koller]

Will do. Thank you.

On Monday, November 6, 2017 at 5:20:57 PM UTC-8, RobertCNelson wrote:
>
> On Mon, Nov 6, 2017 at 6:56 PM, Kenny Koller 
> <ke...@understoryweather.com > wrote: 
> > Thanks. I also found a tag (which didn't list when I searched for bone62 
> on 
> > github under tags): 
> > 
> > Squall: git tag | grep bone62 
> > 3.8.13-bone62 
>
> Yes it exists, but you'll be fighting even more issues to even use it. 
> (well unless you had a time machine..) 
>
> Just follow the gist, i get this same rebuild "3.8." question 2-3 
> times a week on average.. 
>
> 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/c1d87830-4587-4095-9691-6bcc969bed65%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Rebuilding Kernel 3.8.13-bone62

[Kenny Koller]

Thanks. I also found a tag (which didn't list when I searched for bone62 on 
github under tags):

Squall: git tag | grep bone62
3.8.13-bone62


On Monday, November 6, 2017 at 4:53:43 PM UTC-8, RobertCNelson wrote:
>
>
>
> On Nov 6, 2017 6:51 PM, "Kenny Koller" <ke...@understoryweather.com 
> > wrote:
>
> I have cloned github.com:beagleboard/linux.git which has the following 3.8 
> branches:
>  
>   remotes/origin/3.8
>   remotes/origin/3.8-green
>   remotes/origin/3.8.13-bone67-pruspeak
>   remotes/origin/3.8.13-bone69-bb-view-7
>   remotes/origin/3.8.13-bone71-input-polldev
>   remotes/origin/3.8.13-bone71-lsm303
>   remotes/origin/v3.8.13-bone86
>
> The kernel and distribution I have inherited from other developers is:
>
> $ uname -a
> Linux rti-a0f6fd4b07a3 3.8.13-bone62 #1 SMP Mon Aug 18 21:28:53 EDT 2014 
> armv7l GNU/Linux
>
> I'd like to rebuild this kernel with an increase to the SPI buffer size 
> but I don't see a bone62 listed. Where can I find this or reconstruct it?
>
> The reason I'm using this old kernel is that we have many systems in the 
> field that have been running with this version and I'm trying to be 
> conservative about changes.
>
>
> Just follow this.. changing the kernel version and ignoring the 2 patches
>
> https://gist.github.com/RobertCNelson/39faf80ddc9fcefae74dce2c6ca2eb45
>
>
> Regards,
>

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

[beagleboard] Rebuilding Kernel 3.8.13-bone62

[Kenny Koller]

I have cloned github.com:beagleboard/linux.git which has the following 3.8 
branches:
 
  remotes/origin/3.8
  remotes/origin/3.8-green
  remotes/origin/3.8.13-bone67-pruspeak
  remotes/origin/3.8.13-bone69-bb-view-7
  remotes/origin/3.8.13-bone71-input-polldev
  remotes/origin/3.8.13-bone71-lsm303
  remotes/origin/v3.8.13-bone86

The kernel and distribution I have inherited from other developers is:

$ uname -a
Linux rti-a0f6fd4b07a3 3.8.13-bone62 #1 SMP Mon Aug 18 21:28:53 EDT 2014 
armv7l GNU/Linux

I'd like to rebuild this kernel with an increase to the SPI buffer size but 
I don't see a bone62 listed. Where can I find this or reconstruct it?

The reason I'm using this old kernel is that we have many systems in the 
field that have been running with this version and I'm trying to be 
conservative about changes.

-- 
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/928fb354-9aae-467b-b702-6918b17ecf7a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: SPI0

[Kenny Koller]

Thanks for the confirmation and link. I already have a UART connected. 
Perhaps I'll use this to make requests to the master (Beaglebone) to read a 
frame.

Any thoughts as to why the device files/nodes are created for SPI but the 
pins aren't listed in pingroups?

On Friday, November 3, 2017 at 7:17:23 PM UTC-7, RobertCNelson wrote:
>
> I don't think this got merged, but yeah spi slave support needs some work.
>
>
> https://lwn.net/Articles/700433/
>
> Regards,
>
> On Nov 3, 2017 9:10 PM, "Kenny Koller" <ke...@understoryweather.com 
> > wrote:
>
>> I am reading the SPI docs that came with the kernel source. It looks like 
>> this driver only supports being a master and not a slave?
>>
>> On Friday, November 3, 2017 at 6:51:36 PM UTC-7, Kenny Koller wrote:
>>>
>>>
>>> At the moment our design connects a UART between the Beaglebone and an 
>>> STM32F4. I'd like to add support to receive data from the STM32F4 using 
>>> SPI. It will require receiving frames of at least 64 kB each second so a 1 
>>> MHz clock should be adequate. I'm using the 3.8.13 kernel.
>>>
>>> Some questions:
>>>
>>> Some search results suggested that the SPI driver was a kernel extension 
>>> but I was unable to find a corresponding spidev.ko in my filesystem or see 
>>> it listed with lsmod. Does this mean that the device driver has been 
>>> compiled in to the kernel?
>>>
>>> If it has been compiled within the kernel am I correct in thinking that 
>>> I'll need to rebuild the kernel and adjust the buffer size. I think the 
>>> default is 4096 and I would like it to be able to hold an entire 
>>> transaction.
>>>
>>> Finally, I'm in the process of verifying the use of SPI0. I've compiled 
>>> a device tree file (I'm using the one from ADA Fruit) and it seems to load 
>>> properly:
>>>
>>> $ echo ADA-SPI0-01 > /sys/devices/bone_capemgr.9/slots
>>> $ ls /dev/spi*
>>> /dev/spidev1.0  /dev/spidev1.1
>>>  
>>> I downloaded the kernel source and compiled 
>>> Documentation/spi/spidev_test.c for 3.8.13.
>>>
>>> I've jumpered pins 18 and 21 but I'm only seeing zeros:
>>>
>>> $ ./spidev_test /dev/spidev1.0 
>>> spi mode: 0
>>> bits per word: 8
>>> max speed: 50 Hz (500 KHz)
>>>
>>>
>>> 00 00 00 00 00 00 
>>> 00 00 00 00 00 00 
>>> 00 00 00 00 00 00 
>>> 00 00 00 00 00 00 
>>> 00 00 00 00 00 00 
>>> 00 00 00 00 00 00 
>>> 00 00 
>>>
>>> I am not see the SPI pins listed in the pingroups as some posts have 
>>> suggested:
>>>
>>>  cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pingroups  
>>>
>>> Is editing uEnv.txt and a reboot required to properly configure things? 
>>> When I tried adding the overlay to the kernel parameters the device nodes 
>>> were not created. I modified in the following way:
>>>
>>> optargs=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN capemgr.
>>> enable_partno=BB-UART5,ADA-SPI0-01 omap_wdt.nowayout=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...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/ba30c445-6367-468d-bccd-6a9945844729%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/beagleboard/ba30c445-6367-468d-bccd-6a9945844729%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

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

[beagleboard] SPI0

[Kenny Koller]

At the moment our design connects a UART between the Beaglebone and an 
STM32F4. I'd like to add support to receive data from the STM32F4 using 
SPI. It will require receiving frames of at least 64 kB each second so a 1 
MHz clock should be adequate. I'm using the 3.8.13 kernel.

Some questions:

Some search results suggested that the SPI driver was a kernel extension 
but I was unable to find a corresponding spidev.ko in my filesystem or see 
it listed with lsmod. Does this mean that the device driver has been 
compiled in to the kernel?

If it has been compiled within the kernel am I correct in thinking that 
I'll need to rebuild the kernel and adjust the buffer size. I think the 
default is 4096 and I would like it to be able to hold an entire 
transaction.

Finally, I'm in the process of verifying the use of SPI0. I've compiled a 
device tree file (I'm using the one from ADA Fruit) and it seems to load 
properly:

$ echo ADA-SPI0-01 > /sys/devices/bone_capemgr.9/slots
$ ls /dev/spi*
/dev/spidev1.0  /dev/spidev1.1
 
I downloaded the kernel source and compiled Documentation/spi/spidev_test.c for 
3.8.13.

I've jumpered pins 18 and 21 but I'm only seeing zeros:

$ ./spidev_test /dev/spidev1.0 
spi mode: 0
bits per word: 8
max speed: 50 Hz (500 KHz)


00 00 00 00 00 00 
00 00 00 00 00 00 
00 00 00 00 00 00 
00 00 00 00 00 00 
00 00 00 00 00 00 
00 00 00 00 00 00 
00 00 

I am not see the SPI pins listed in the pingroups as some posts have 
suggested:

 cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pingroups  

Is editing uEnv.txt and a reboot required to properly configure things? 
When I tried adding the overlay to the kernel parameters the device nodes 
were not created. I modified in the following way:

optargs=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN capemgr.
enable_partno=BB-UART5,ADA-SPI0-01 omap_wdt.nowayout=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/017f69a2-3cb0-4434-bb42-401ecc30e3cc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Configuring U-Boot to use eMMC.

[Kenny Koller]

Adding that I want MLO, U-Boot, and the EXT-4 all on the eMMC. Will be 
using the SD card as a FAT32 for data only.

Thanks,

Kenny

On Friday, July 21, 2017 at 12:05:25 PM UTC-7, Kenny Koller wrote:
>
> Apologies. Reposting because I forgot to fill out the type/categories...
>
>
> I'm comfortable with raw mode booting for SPL/MLO and U-Boot. I'd like to 
> configure U-Boot to pull the kernel and DTB from an EXT4 partition on the 
> eMMC.
>
> Using strings I decoded the default state of the variables and worked back 
> from $bootcmd (please see below).
>
> Must U-Boot be built with mmcdev set to 1? Is there some kind of 
> configuration option for this (I'm using the stock Yocto/Poky/Pyro source).
>
> Is another path to use saveenv to store this information in one of the 
> hidden eMMC boot sectors (assuming this is where U-Boot grabs this 
> information)?
>
> Related: Is there a clever way of partitioning, formatting, dd'ing the 
> eMMC without having to load Linux from an SD card and using its tools? Or 
> creating an image and writing it raw?
>
> Thanks,
>
> Kenny
>
>
> envboot=mmc dev ${mmcdev}; if mmc rescan; then echo SD/MMC found on 
> device ${mmcdev};if run loadbootscript; then run bootscript;else if run 
> loadbootenv; then echo Loaded env from${bootenvfile};run importbootenv;fi;
> if test -n $uenvcmd; then echo Running uenvcmd ...;run uenvcmd;fi;fi;fi;
>
>
> mmcdev=0
>
>
> loadbootscript=load mmc ${mmcdev} ${loadaddr} boot.scr
>
>
> bootscript=echo Running bootscript from mmc${mmcdev} ...; source ${
> loadaddr}
>
>
> loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenvfile}
>
>
> bootenvfile=uEnv.txt
>
>
> importbootenv=echo Importing environment from mmc${mmcdev} ...; env import
>  -t ${loadaddr}${filesize}
>

-- 
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/ccae368b-6d4a-48de-b21e-af36086685c7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Configuring U-Boot to use eMMC.

[Kenny Koller]

Apologies. Reposting because I forgot to fill out the type/categories...


I'm comfortable with raw mode booting for SPL/MLO and U-Boot. I'd like to 
configure U-Boot to pull the kernel and DTB from an EXT4 partition on the 
eMMC.

Using strings I decoded the default state of the variables and worked back 
from $bootcmd (please see below).

Must U-Boot be built with mmcdev set to 1? Is there some kind of 
configuration option for this (I'm using the stock Yocto/Poky/Pyro source).

Is another path to use saveenv to store this information in one of the 
hidden eMMC boot sectors (assuming this is where U-Boot grabs this 
information)?

Related: Is there a clever way of partitioning, formatting, dd'ing the eMMC 
without having to load Linux from an SD card and using its tools? Or 
creating an image and writing it raw?

Thanks,

Kenny


envboot=mmc dev ${mmcdev}; if mmc rescan; then echo SD/MMC found on device $
{mmcdev};if run loadbootscript; then run bootscript;else if run loadbootenv;
 then echo Loaded env from${bootenvfile};run importbootenv;fi;if test -n 
$uenvcmd; then echo Running uenvcmd ...;run uenvcmd;fi;fi;fi;


mmcdev=0


loadbootscript=load mmc ${mmcdev} ${loadaddr} boot.scr


bootscript=echo Running bootscript from mmc${mmcdev} ...; source ${loadaddr}


loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenvfile}


bootenvfile=uEnv.txt


importbootenv=echo Importing environment from mmc${mmcdev} ...; env import -t 
${loadaddr}${filesize}

-- 
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/b0c4a1ba-2caa-4dcb-b904-cd1aa481cad3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] How to configure Yocto U-Boot to Boot from eMMC?

[Kenny Koller]

I'm comfortable with raw mode booting for SPL/MLO and U-Boot. I'd like to 
configure U-Boot to pull the kernel and DTB from an EXT4 partition on the 
eMMC.

Using strings I decoded the default state of the variables and worked back 
from $bootcmd (please see below).

Must U-Boot be built with mmcdev set to 1? Is there some kind of 
configuration option for this (I'm using the stock Yocto/Poky/Pyro source).

Is another path to use saveenv to store this information in one of the 
hidden eMMC boot sectors (assuming this is where U-Boot grabs this 
information)?

Related: Is there a clever way of partitioning, formatting, dd'ing the eMMC 
without having to load Linux from an SD card and using its tools? Or 
creating an image and writing it raw?

Thanks,

Kenny


envboot=mmc dev ${mmcdev}; if mmc rescan; then echo SD/MMC found on device $
{mmcdev};if run loadbootscript; then run bootscript;else if run loadbootenv; 
then echo Loaded env from ${bootenvfile};run importbootenv;fi;if test -n 
$uenvcmd; then echo Running uenvcmd ...;run uenvcmd;fi;fi;fi;


mmcdev=0


loadbootscript=load mmc ${mmcdev} ${loadaddr} boot.scr


bootscript=echo Running bootscript from mmc${mmcdev} ...; source ${loadaddr}


loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenvfile}


bootenvfile=uEnv.txt


importbootenv=echo Importing environment from mmc${mmcdev} ...; env import -t 
${loadaddr} ${filesize}

-- 
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/96e21de1-ad7d-4727-b367-6ab83ff63b4b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] How is uEnv.txt resolved when using raw mode?

[Kenny Koller]

I was informed that the following is invoked by U-Boot:

env import -t -r $loadaddr $filesize 

I'm not sure what the flags do and have so far been unable to find 
documentation for them. But I believe this is acting on an environment that 
has been loaded in a previous command. 

What is the previous step to load this? In other words, where is U-Boot 
looking for the uEnv.txt?

The Partition 2.0 document 

 was 
vague (to me) on this point. Probably makes sense in some context.

It isn't clear to me from this page 

 
either. It seems to imply that it will search for it on /boot of the root 
filesystem. My one and only bootable partition is EXT4 so it would require 
calling ext4load (I believe). The output is trying to do something with the 
MMC but never finds what it is looking for. I'm not sure which image it is 
trying to load. Surprised there isn't a message somewhere saying "Trying to 
load environment" or "Trying to load Kernel" or whatever.

Using U-Boot 2017.01.


=> boot
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
** File not found boot.scr **
** Unrecognized filesystem type **
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
** Invalid partition 2 **
** First descriptor is NOT a primary desc on 1:1 **
switch to partitions #0, OK
mmc1(part 0) is current device
** No partition table - mmc 1 **
** First descriptor is NOT a primary desc on 1:1 **
switch to partitions #0, OK
mmc1(part 0) is current device
** First descriptor is NOT a primary desc on 1:1 **
SD/MMC found on device 1
** No partition table - mmc 1 **
## Error: "bootcmd_nand0" not defined
starting USB...
USB0:   Port not available.
cpsw Waiting for PHY auto negotiation to complete...

-- 
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/6db92e69-2e43-4a5f-98ee-d8d06efe6401%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Errors when using the SD card and raw mode?

[Kenny Koller]

Using these instructions 

 
I did the following:

Used dd to clear the first 64 MB of a 16 GB SD card to zeros.

Used sfdisk to create a single bootable Linux partition from 64 MB to the 
end of the disk.

Used dd to place MLO at 128 kB and U-Boot at 384 kB.

I formatted the partition to EXT4 and installed the root filesystem.

I'm using Yocto/Poky (Pyro branch) which is building U-Boot 2017.01.

When I boot it seems to find the SPL/MLO and load/run U-Boot:

U-Boot SPL 2017.01 (Jun 28 2017 - 23:47:37)
Trying to boot from MMC1MMC partition switch failed
*** Warning - MMC partition switch failed, using default environment

U-Boot 2017.01 (Jun 28 2017 - 23:47:37 +)
CPU  : AM335X-GP rev 2.1
I2C:   ready
DRAM:  512 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
** First descriptor is NOT a primary desc on 1:1 **
*** Warning - bad CRC, using default environment
 not set. Validating first E-fuse MAC
Net:   cpsw, usb_ether
Press SPACE to abort autoboot in 2 seconds
=> 

When I naively boot I get the following:

=> boot
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
** File not found boot.scr **
** Unrecognized filesystem type **
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
** Invalid partition 2 **
** First descriptor is NOT a primary desc on 1:1 **
switch to partitions #0, OK
mmc1(part 0) is current device
** No partition table - mmc 1 **
** First descriptor is NOT a primary desc on 1:1 **
switch to partitions #0, OK
mmc1(part 0) is current device
** First descriptor is NOT a primary desc on 1:1 **
SD/MMC found on device 1
** No partition table - mmc 1 **
## Error: "bootcmd_nand0" not defined
starting USB...
USB0:   Port not available.
cpsw Waiting for PHY auto negotiation to complete.

What is U-Boot trying to do here? Is it trying to locate the uEnv? The 
kernel? Is it trying to mount the partition and search for /boot?

I can tell that is searching for something but can only understand about 
half of these messages. What is a descriptor? What is a primary desc? Why 
are partitions referred to as 0 rather than 1-4? What does "switch to 
partitions #0" mean?


-- 
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/f6e8430b-01e9-446f-be66-7d3e4a456cef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Confusing U-Boot/MLO Messages

[Kenny Koller]

Can someone help me understand the output of U-Boot? Please see my 
questions inline in green below. Also is there a sort Theory of Ops for 
U-Boot? I found a User Manual at the DENX site but nothing about the 
details of the boot sequence and how/where it searches for things. Thanks.
 

U-Boot SPL 2017.01 (Jun 28 2017 - 23:47:37)
Trying to boot from MMC1MMC partition switch failed


I know what a partition is. What is a partition switch?

*** Warning - MMC partition switch failed, using default environment

Was it trying to read the environment from a partition or boot? We haven't 
launched U-Boot yet so what environment is this? Loaded to memory? Where?
 

reading u-boot.img 
reading u-boot.img 


Why is U-Boot being read twice? 



U-Boot 2017.01 (Jun 28 2017 - 23:47:37 +)
CPU  : AM335X-GP rev 2.1
I2C:   ready
DRAM:  512 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
** First descriptor is NOT a primary desc on 1:1 **


Does this mean a bootable partition? Looks to be MMC 1 partition 1 which 
would be true as I erased it. Why is it so upset about this? It's no 
unheard of to boot from an SD card (and lots of other methods).
 

*** Warning - bad CRC, using default environment


Found the answer to this on the DENX site: It's trying to read an 
environment from uninitialized flash.


 not set. Validating first E-fuse MAC
Net:   cpsw, usb_ether
Press SPACE to abort autoboot in 2 seconds
switch to partitions #0, OK


Partitions are referred to as 1-4 (at least with MBR). What is zero?
 

mmc0 is current device
SD/MMC found on device 0
reading boot.scr  
** Unable to read file boot.scr **
reading uEnv.txt  
411 bytes read in 3 ms (133.8 KiB/s)
Loaded env from uEnv.txt


I do have a uEnv.txt on a partition 1 (FAT) of MMC0 (SD card). I've added 
an echo statement but I'm not seeing anything from it. Should I? I was 
expecting it to execute it like script in the hush shell. Maybe it only 
assigns variables? With the above it looks to be using MMC0 (SD card). Does 
it only look at the bootable partition (FAT in my case) or will it also 
attempt to find this file elsewhere?

Importing environment from mmc0 ...
switch to partitions #0, OK 
mmc0 is current device
Scanning mmc 0:1...
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
5655304 bytes read in 389 ms (13.9 MiB/s)
34643 bytes read in 43 ms (786.1 KiB/s)I## Flattened Device Tree blob at 
8800

  Booting using the fdt blob at 0x8800
  Loading Device Tree to 8fff4000, end 8752 ... OK


What is going on here? The DT was at 8800. is it being moved? 


Starting kernel ...

Poky (Yocto Project Reference Distro) 2.3 beaglebone /dev/ttyO0
beaglebone login:

 

-- 
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/65f0a3de-3fa3-4be4-9d57-082e40c41a46%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Where do I find the load address definitions?

[Kenny Koller]

Thanks Robert. This gives me a good starting point for the U-Boot defaults 
(and some source that I will bookmark for future reference).

So these are the defaults and if someone has a reason to move the kernel 
elsewhere then the typical thing is to simply override these variables in 
U-Boot at run time? Ultimately I think there is a make target to link the 
kernel using a particular load address. So it seems you change it there and 
then edit uEnv.txt and Bob's your uncle.

Out of curiosity can you give me some insight as to how code propagates 
from the work being done at DENX to the meta-ti layer? Denys has informed 
me that he (they?) integrate meta-ti with Poky every other release. Or 
perhaps the Yocto layers like meta-ti, and ultimately meta-yocto-bsp, don't 
have any need to make changes to U-Boot because TI specific items (as in 
your example above) are already upstream? So the bitbake recipes just git 
clone from DENX directly and build?

Thanks.


On Monday, July 10, 2017 at 5:16:40 PM UTC-7, Kenny Koller wrote:
>
>
> I am assuming the following which may be incorrect so please correct as 
> necessary:
>
> The load address of the SPL (MLO) is determined by the PPL/ROM code.
>
> The SPL (MLO) must know the load address of U-Boot as it is not 
> interactive.
>
> U-Boot must be linked with the above address in mind.
>
> U-Boot can load the DTB and the kernel anywhere it likes. The DTB address 
> can be passed to the kernel (I believe through a register). The kernel 
> itself must loaded at the address at which is was linked.
>
> I'd like to understand where each of these are defined so I can 
> intelligently configure U-Boot to do the right things (rather than simply 
> copy a uEnv.txt and assume it is correct).
>
> I'm using Yocto/Poky Pyro. Where do I find all these bits of information 
> so I can tie everything together?
>
> Thanks.
>

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

[beagleboard] Where do I find the load address definitions?

[Kenny Koller]

I am assuming the following which may be incorrect so please correct as 
necessary:

The load address of the SPL (MLO) is determined by the PPL/ROM code.

The SPL (MLO) must know the load address of U-Boot as it is not interactive.

U-Boot must be linked with the above address in mind.

U-Boot can load the DTB and the kernel anywhere it likes. The DTB address 
can be passed to the kernel (I believe through a register). The kernel 
itself must loaded at the address at which is was linked.

I'd like to understand where each of these are defined so I can 
intelligently configure U-Boot to do the right things (rather than simply 
copy a uEnv.txt and assume it is correct).

I'm using Yocto/Poky Pyro. Where do I find all these bits of information so 
I can tie everything together?

Thanks.

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

[beagleboard] Yocto U-Boot and uEnv.txt Searching

[Kenny Koller]

I recently began learning Yocto/Poky and built Beaglebone Black artifacts 
using the pyro branch. I configured things such that uEnv.txt, u-boot.img, 
MLO, and zImage are on a bootable FAT32 partition. eMMC was erased. It 
boots fine.

I also did some reading of the AM335x reference manual where I learned that 
the primary program loader (PPL in ROM) can identify FAT12/16/32 partitions 
and load MLO from there but a raw mode also exists where no filesystem is 
needed at all for MLO and U-Boot.

I found this write-up 
 regarding a 
BBB partition scheme 2.0. It looks to me as if the PPL for OMAP3 on 
supported the FAT technique and that OMAP4 because supporting the raw mode.

Regarding uEnv.txt: I am seeing these files in several places:

Are these cumulative in the sense that each one found overrides / adds 
information or does it stop with the first hit?

Is this searching a generic thing in U-Boot or specific to Beaglebone?

If there are differences in searching for this file what is the history of 
U-Boot for Beaglebone? Does the Yocto version use code that evolved from 
AM335x support from TI? Or was that adopted from this community when Yocto 
began using the hardware as a reference?

Is there a document that explains the use of the various uEnv.txt as used 
by the partition scheme 2.0?

Regarding FAT v. raw mode: Since the PPL for the AM335 supports both why 
change to the 2.0 strategy? What is the advantage?

Thanks.

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

[beagleboard] Re: uEnv.txt parsing

[Kenny Koller]

>
> (The purpose of the mmcblk1boot* devices is unknown at present.)
>

Four years later I happened across this post and found it helpful.

I believe these devices map to the hidden boot sectors within the eMMC 
which hangs off the MMC1 peripheral. 

-- 
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/4353a1e6-4ca3-4246-848c-d02eacdc0c48%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] BTRFS Support

[Kenny Koller]

I read this post 

 suggesting 
that BTRFS + RAID 1 may be a good solution as a reliable read-write SD card 
root filesystem. Or at least one with a much longer life.

This warning  suggests that one not 
use BTRFS unless using Linux kernel 4.4 or greater.

I'm designing for a field units that are not easily replaced so I would 
prefer to be conservative. Is there distro + kernel release for Beaglebone 
Black that will support this?

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

[beagleboard] BTRFS with SD Card

[Kenny Koller]

I read this post 

 
suggesting that BTRFS + RAID 1 may be a good solution as a reliable 
read-write SD card root filesystem. Or at least one with a much longer life.

This warning  suggests that one not 
use BTRFS unless using Linux kernel 4.4 or greater.

I'm designing for a field units that are not easily replaced so I would 
prefer to be conservative. Is there distro + kernel release for Beaglebone 
Black that will support this? I have searched the site but it is still not 
clear to me what is available.

-- 
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/37b3865c-cc7c-4c7e-9794-233a7fd10dd9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: /etc/debian_version -> jessie / sid

[Kenny Koller]

For posterity: I tracked down one of the original developers. We're using 
the Beaglebone kernel but grabbing the distribution directly from Debian.

On Monday, June 13, 2016 at 10:03:09 AM UTC-7, Kenny Koller wrote:
>
> I'm new to a project that has integrated many Beaglebone Blacks. I'm 
> trying to determine which distribution I am using. The information below 
> suggests that I have the unstable (sid) version installed. Is this correct? 
> How do I determine the 8.x number of Debian that I am using? 
>
>
> $ cat /etc/debian_version 
>
> jessie/sid 
>
> $ uname -a 
>
> Linux rti-78a504f87da8 3.8.13-bone62 #1 SMP Mon Aug 18 21:28:53 EDT 2014 
> armv7l GNU/Linux 
>
> $ cat /etc/issue 
>
> Debian GNU/Linux jessie/sid \n \l
>
>
>

-- 
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/88facbec-8c72-414e-88d5-7efada60431e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] /etc/debian_version -> jessie / sid

[Kenny Koller]

Sorry. Left off the '-a'. Thank you.

$ lsb_release -a

No LSB modules are available.

Distributor ID: Debian

Description: Debian GNU/Linux 8.5 (jessie)

Release: 8.5

Codename: jessie

On Monday, June 13, 2016 at 11:01:41 AM UTC-7, Kenny Koller wrote:
>
> After installing 'lsb-release' I get:
>
> $ lsb_release 
>
> No LSB modules are available.
>
> On Monday, June 13, 2016 at 10:20:34 AM UTC-7, Kenny Koller wrote:
>>
>> Thanks Robert. I don't seem to have that command. Is there a package I 
>> must install?
>>
>> Know anything about this 'jessie / sid' business? 
>>
>> On Monday, June 13, 2016 at 10:07:21 AM UTC-7, RobertCNelson wrote:
>>>
>>> On Mon, Jun 13, 2016 at 12:03 PM, Kenny Koller 
>>> <ke...@understoryweather.com> wrote: 
>>> > I'm new to a project that has integrated many Beaglebone Blacks. I'm 
>>> trying 
>>> > to determine which distribution I am using. The information below 
>>> suggests 
>>> > that I have the unstable (sid) version installed. Is this correct? How 
>>> do I 
>>> > determine the 8.x number of Debian that I am using? 
>>> > 
>>> > 
>>> > $ cat /etc/debian_version 
>>> > 
>>> > jessie/sid 
>>> > 
>>> > $ uname -a 
>>> > 
>>> > Linux rti-78a504f87da8 3.8.13-bone62 #1 SMP Mon Aug 18 21:28:53 EDT 
>>> 2014 
>>> > armv7l GNU/Linux 
>>> > 
>>> > $ cat /etc/issue 
>>> > 
>>> > Debian GNU/Linux jessie/sid \n \l 
>>>
>>> lsb_release -a 
>>>
>>> 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/b6b88fd0-e65c-47dc-9155-c3d67ddb267a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] /etc/debian_version -> jessie / sid

[Kenny Koller]

After installing 'lsb-release' I get:

$ lsb_release 

No LSB modules are available.

On Monday, June 13, 2016 at 10:20:34 AM UTC-7, Kenny Koller wrote:
>
> Thanks Robert. I don't seem to have that command. Is there a package I 
> must install?
>
> Know anything about this 'jessie / sid' business? 
>
> On Monday, June 13, 2016 at 10:07:21 AM UTC-7, RobertCNelson wrote:
>>
>> On Mon, Jun 13, 2016 at 12:03 PM, Kenny Koller 
>> <ke...@understoryweather.com> wrote: 
>> > I'm new to a project that has integrated many Beaglebone Blacks. I'm 
>> trying 
>> > to determine which distribution I am using. The information below 
>> suggests 
>> > that I have the unstable (sid) version installed. Is this correct? How 
>> do I 
>> > determine the 8.x number of Debian that I am using? 
>> > 
>> > 
>> > $ cat /etc/debian_version 
>> > 
>> > jessie/sid 
>> > 
>> > $ uname -a 
>> > 
>> > Linux rti-78a504f87da8 3.8.13-bone62 #1 SMP Mon Aug 18 21:28:53 EDT 
>> 2014 
>> > armv7l GNU/Linux 
>> > 
>> > $ cat /etc/issue 
>> > 
>> > Debian GNU/Linux jessie/sid \n \l 
>>
>> lsb_release -a 
>>
>> 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/10fd76e1-e774-4b43-a6ac-fbbec8b77c51%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] /etc/debian_version -> jessie / sid

[Kenny Koller]

Thanks Robert. I don't seem to have that command. Is there a package I must 
install?

Know anything about this 'jessie / sid' business? 

On Monday, June 13, 2016 at 10:07:21 AM UTC-7, RobertCNelson wrote:
>
> On Mon, Jun 13, 2016 at 12:03 PM, Kenny Koller 
> <ke...@understoryweather.com > wrote: 
> > I'm new to a project that has integrated many Beaglebone Blacks. I'm 
> trying 
> > to determine which distribution I am using. The information below 
> suggests 
> > that I have the unstable (sid) version installed. Is this correct? How 
> do I 
> > determine the 8.x number of Debian that I am using? 
> > 
> > 
> > $ cat /etc/debian_version 
> > 
> > jessie/sid 
> > 
> > $ uname -a 
> > 
> > Linux rti-78a504f87da8 3.8.13-bone62 #1 SMP Mon Aug 18 21:28:53 EDT 2014 
> > armv7l GNU/Linux 
> > 
> > $ cat /etc/issue 
> > 
> > Debian GNU/Linux jessie/sid \n \l 
>
> lsb_release -a 
>
> 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/6d60ca61-d02e-40d3-acba-4633ebe294b2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] /etc/debian_version -> jessie / sid

[Kenny Koller]

I'm new to a project that has integrated many Beaglebone Blacks. I'm trying 
to determine which distribution I am using. The information below suggests 
that I have the unstable (sid) version installed. Is this correct? How do I 
determine the 8.x number of Debian that I am using? 


$ cat /etc/debian_version 

jessie/sid 

$ uname -a 

Linux rti-78a504f87da8 3.8.13-bone62 #1 SMP Mon Aug 18 21:28:53 EDT 2014 
armv7l GNU/Linux 

$ cat /etc/issue 

Debian GNU/Linux jessie/sid \n \l


-- 
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/5c26c04e-704c-4262-be95-43cf82585199%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.