bone kernel questions.....

[Daniel Kulp]

Couple of questions regarding the bone kernels....

1) Is there a reason update_kernel doesn't install the various "extras" for the bone kernel like it does for the ti kernels?   I don't really care as I don't need them, but it kind of surprised me that libpruio and such were not installed.   

2) Is there any indication if/when the problem of BB-I2C2-FAST-00A0 not allowing cape-universal to work will be fixed for the bone kernels?  At least for 4.19 but preferably also for 4.14.  I'm kind of working around the issue by explicitly adding cape-universalh-00A0 to the overlays, but that's kind of a crappy way to do it.   

Related to #2: if we include BB-I2C2-FAST-00A0 , then it excludes those pins from cape-universal/pinmux entirely.   Thus, we cannot "config-pin" them to be output pins if we don't need the i2c bus.     I've created my own dts that only configures the i2c clock and leaves the pins alone.   I'm trying to determine if there are any issues with that, and if not, why isn't that the default?

Thanks!

Dan

[Robert Nelson]

On Wed, Mar 27, 2019 at 11:32 AM Daniel Kulp <d...@kulp.com> wrote:
>
>
> Couple of questions regarding the bone kernels....
>
> 1) Is there a reason update_kernel doesn't install the various "extras" for the bone kernel like it does for the ti kernels? I don't really care as I don't need them, but it kind of surprised me that libpruio and such were not installed.

https://github.com/RobertCNelson/boot-scripts/blob/2f062cfde221878a2bcb4ea87d0622aab74728e0/tools/update_kernel.sh#L565-L567

So yes, this should be extended to 4.19.x-bone, v4.14.x-bone-rt and
v4.19.x-bone-rt..

> 2) Is there any indication if/when the problem of BB-I2C2-FAST-00A0 not allowing cape-universal to work will be fixed for the bone kernels? At least for 4.19 but preferably also for 4.14. I'm kind of working around the issue by explicitly adding cape-universalh-00A0 to the overlays, but that's kind of a crappy way to do it.

This "works" fine in 4.19.x, the issue is you want me to spend time
back-porting this feature i originally started working in on
v4.16.x-bone back to v4.14.x-bone.. My big question is why? everyone
hated v4.14.x-bone-rt so they either stayed on v4.4.x-bone-rt or now
jumped to 4.19.x-bone-rt.. Thus give me an actual use case why
v4.14.x-bone vs v4.19.x-bone at this point..

debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh
git:/opt/scripts/:[2f062cfde221878a2bcb4ea87d0622aab74728e0]
eeprom:[A335BNLT000C1830BBBG0785]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[BeagleBoard.org Debian Image 2019-03-24]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot
2018.09-00002-g9d95a561c9]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot
2018.09-00002-g0b54a51eee]:[location: dd MBR]
kernel:[4.19.29-bone29]
nodejs:[v6.17.0]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/BB-I2C2-FAST-00A0.dtbo]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade <pkg>]
pkg:[bb-cape-overlays]:[4.4.20190320.1-0rcnee0~stretch+20190320]
pkg:[bb-wl18xx-firmware]:[1.20190227.1-0rcnee0~stretch+20190227]
pkg:[kmod]:[23-2rcnee1~stretch+20171005]
pkg:[librobotcontrol]:[1.0.4-git20190107.0-0rcnee0~stretch+20190108]
pkg:[firmware-ti-connectivity]:[20180825+dfsg-1rcnee1~stretch+20181217]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video
plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm
eqep admin spi tisdk weston-launch xenomai]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1
root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M
net.ifnames=0 quiet]
dmesg | grep remote
[ 1.035641] remoteproc remoteproc0: wkup_m3 is available
[ 1.387562] remoteproc remoteproc0: powering up wkup_m3
[ 1.387582] remoteproc remoteproc0: Booting fw image
am335x-pm-firmware.elf, size 217168
[ 1.390364] remoteproc remoteproc0: remote processor wkup_m3 is now up
dmesg | grep pru


debian@beaglebone:~$ config-pin -l P9.11
default gpio gpio_pu gpio_pd gpio_input uart
debian@beaglebone:~$ config-pin -q P9.11
P9_11 Mode: default Direction: in Value: 1
debian@beaglebone:~$ config-pin P9.11 uar

>
> Related to #2: if we include BB-I2C2-FAST-00A0 , then it excludes those pins from cape-universal/pinmux entirely. Thus, we cannot "config-pin" them to be output pins if we don't need the i2c bus. I've created my own dts that only configures the i2c clock and leaves the pins alone. I'm trying to determine if there are any issues with that, and if not, why isn't that the default?
>

Regards,

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

[Daniel Kulp]

#2 is definitely NOT working for me... 

root@FPPTest:/opt/scripts/tools# ./version.sh

git:/opt/scripts/:[2f062cfde221878a2bcb4ea87d0622aab74728e0]

eeprom:[A335BNLTSE0A4518BBE911FC]

model:[SanCloud_BeagleBone_Enhanced]:WiFi AP Enabled:[https://github.com/lwfinger/rtl8723bu]

dogtag:[BeagleBoard.org Debian Image 2018-10-07]

bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 2018.09-00002-g9d95a561c9]:[location: dd MBR]

bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2018.09-00002-g9d95a561c9]:[location: dd MBR]

kernel:[4.19.29-bone29]

uboot_overlay_options:[enable_uboot_overlays=1]

uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/BB-I2C2-FAST-00A0.dtbo]

uboot_overlay_options:[disable_uboot_overlay_video=1]

uboot_overlay_options:[disable_uboot_overlay_audio=1]

uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo]

uboot_overlay_options:[enable_uboot_cape_universal=1]

pkg check: to individually upgrade run: [sudo apt install --only-upgrade <pkg>]

pkg:[bb-cape-overlays]:[4.4.20190320.1-0rcnee0~stretch+20190320]

pkg:[bb-wl18xx-firmware]:[1.20190227.1-0rcnee0~stretch+20190227]

pkg:[kmod]:[23-2rcnee1~stretch+20171005]

WARNING:pkg:[librobotcontrol]:[NOT_INSTALLED]

pkg:[firmware-ti-connectivity]:[20180825+dfsg-1rcnee1~stretch+20181217]

groups:[debian : debian adm kmem dialout cdrom floppy audio dip video plugdev users systemd-journal netdev gpio pwm eqep admin spi i2c tisdk weston-launch xenomai bluetooth cloud9ide]

cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 rootwait quiet]

dmesg | grep remote

[    0.628740] remoteproc remoteproc0: wkup_m3 is available

[    0.940053] remoteproc remoteproc0: powering up wkup_m3

[    0.940074] remoteproc remoteproc0: Booting fw image am335x-pm-firmware.elf, size 217168

[    0.942727] remoteproc remoteproc0: remote processor wkup_m3 is now up

dmesg | grep pru

root@FPPTest:/opt/scripts/tools# config-pin -q P9.11

P9_11 pinmux file not found!

Cannot read pinmux file: /sys/devices/platform/ocp/ocp*P9_11_pinmux/state

If I can get it working with 4.19, I'd be OK with that, but right now, it's not.   Since I'm trying to create new images for my devices, I can definitely move everything to 4.19.  The "problem" I have is a couple of the out-of-kernel wifi drivers I build/include don't yet build properly with 4.19 which is why I've considered staying on 4.14.   That's a minor issue though.  

Dan

[Robert Nelson]

On Wed, Mar 27, 2019 at 12:04 PM Daniel Kulp <d...@kulp.com> wrote:
>

> eeprom:[A335BNLTSE0A4518BBE911FC]
> model:[SanCloud_BeagleBone_Enhanced]:WiFi AP Enabled:[https://github.com/lwfinger/rtl8723bu]

There's the problem, why didn't i see this before in your previous emails?

For the cape-universal "rewrite" to work, u-boot needs to load
"am335x-sancloud-bbe-uboot-univ.dtb" however today v4.19.x-bone only
has:

debian@beaglebone:/boot/dtbs/4.19.29-bone29$ find . | grep univ
./am335x-bone-uboot-univ.dtb
./am335x-boneblack-uboot-univ.dtb
./am335x-bonegreen-wireless-uboot-univ.dtb

debian@beaglebone:/boot/dtbs/4.19.25-ti-r16$ find . | grep univ
./am335x-bone-uboot-univ.dtb
./am335x-boneblack-uboot-univ.dtb
./am335x-bonegreen-wireless-uboot-univ.dtb

debian@beaglebone:/boot/dtbs/4.14.103-ti-r100$ find . | grep univ
./am335x-bone-uboot-univ.dtb
./am335x-boneblack-uboot-univ.dtb
./am335x-bonegreen-wireless-uboot-univ.dtb

debian@beaglebone:/boot/dtbs/4.14.103-ti-r100$ find . | grep bbe
./am335x-sancloud-bbe.dtb

So yeah, i need to grab my bbe, (pretty sure it's at home) and build
the *-univ.dtb" files..

it looks like the rtl8723bu built.. does it not work? are they
shipping with the rtl8821cu now too?

[Daniel Kulp]

Right after I posted that I realized the same thing and decided to flip the SD card over to a BBB Industrial (don't have a  regular "black" sitting here, need to go digging).     It does work there as long as I get the bootloader updated to 2018.09.   Doesn't work with 2018.01.    OK.  At least we know where the issue is.  ;)    That's a good step.

Dan

[Daniel Kulp]

On Wednesday, March 27, 2019 at 1:15:10 PM UTC-4, RobertCNelson wrote:

it looks like the rtl8723bu built.. does it not work?  are they
shipping with the  rtl8821cu now too?

The one I got a couple months ago is still using the 8723bu.   I haven't gotten it to connect yet though.   The wlan devices appear and I can scan services, but I haven't gotten it to connect.  Not sure what's going on with it.   

That said, my bigger issue my users that are using my pocketbeagle based capes and grabbing some random USB wifi adapter off Amazon that "claims" to have Linux support.   I have 6 other external drivers that I have currently been building for various use cases.  (mostly around adapters on the 5ghz bands)    A couple of those aren't building with 4.19 yet.  I just haven't had time to look into those.     Not your issue to deal with.  

[Daniel Kulp]

Any progress?   If need/want to send me a dtb to test with, that would be fine.

Also, I noticed there isn't a "pocketbeagle-univ" version in there.   Should there be?  

Dan

On Wednesday, March 27, 2019 at 1:15:10 PM UTC-4, RobertCNelson wrote:

[Robert Nelson]

On Fri, Mar 29, 2019 at 11:45 AM Daniel Kulp <d...@kulp.com> wrote:
>
>
> Any progress? If need/want to send me a dtb to test with, that would be fine.

I haven't had any free time to work on this. I think my board is at home..

> Also, I noticed there isn't a "pocketbeagle-univ" version in there. Should there be?

Nope, the whole idea behind the *-univ.dtbo setup was first tested
with the PocketBeagle by default... Then ported to the other devices.

[Daniel Kulp]

As an FYI, I checked out the kernel source and updated the arch/arm/boot/dts/Makefile file to do:

+        am335x-sancloud-bbe-uboot-univ.dtb \

and then copied arch/arm/boot/dts/am335x-sancloud-bbe.dts to arch/arm/boot/dts/am335x-sancloud-bbe-uboot-univ.dts and added the line:

#include "am335x-bone-common-univ.dtsi"

to the top (below the am335x-boneblack-common.dtsi) and rebuilt the dtbs and installed just the new one, and everything works.  :)   config-pin works. 

Dan

[Robert Nelson]

On Sat, Mar 30, 2019 at 12:26 PM Daniel Kulp <d...@kulp.com> wrote:
>
>
> As an FYI, I checked out the kernel source and updated the arch/arm/boot/dts/Makefile file to do:
>
> + am335x-sancloud-bbe-uboot-univ.dtb \
>
> and then copied arch/arm/boot/dts/am335x-sancloud-bbe.dts to arch/arm/boot/dts/am335x-sancloud-bbe-uboot-univ.dts and added the line:
>
> #include "am335x-bone-common-univ.dtsi"
>
> to the top (below the am335x-boneblack-common.dtsi) and rebuilt the dtbs and installed just the new one, and everything works. :) config-pin works.

Except for the pin's tied up via hdmi and eMMC on the header..

Forgot to dig out this board before i left for work this morning..

[Daniel Kulp]

On Apr 1, 2019, at 4:55 PM, Robert Nelson <robert...@gmail.com> wrote:

On Sat, Mar 30, 2019 at 12:26 PM Daniel Kulp <d...@kulp.com> wrote:

As an FYI, I checked out the kernel source and updated the arch/arm/boot/dts/Makefile file to do:

+        am335x-sancloud-bbe-uboot-univ.dtb \

and then copied arch/arm/boot/dts/am335x-sancloud-bbe.dts to arch/arm/boot/dts/am335x-sancloud-bbe-uboot-univ.dts and added the line:

#include "am335x-bone-common-univ.dtsi"

to the top (below the am335x-boneblack-common.dtsi) and rebuilt the dtbs and installed just the new one, and everything works.  :)   config-pin works.

Except for the pin's tied up via hdmi and eMMC on the header..

Are you sure?    With the above and:

disable_uboot_overlay_video=1

disable_uboot_overlay_audio=1 

I get a total of 59 pins that are queryable with config-pin which is the same number I get on a regular BBB:

fpp@FPPTest:/opt/fpp/scripts$ ./bbb-reportpins.sh

P8_07 Mode: default Direction: in Value: 1

P8_08 Mode: default Direction: in Value: 1

P8_09 Mode: default Direction: in Value: 1

P8_10 Mode: default Direction: in Value: 1

P8_11 Mode: default Direction: in Value: 0

P8_12 Mode: default Direction: in Value: 0

P8_13 Mode: gpio_pu Direction: in Value: 1

P8_14 Mode: gpio_pu Direction: in Value: 1

P8_15 Mode: default Direction: in Value: 0

P8_16 Mode: default Direction: in Value: 0

P8_17 Mode: default Direction: in Value: 0

P8_18 Mode: default Direction: in Value: 0

P8_19 Mode: default Direction: in Value: 0

P8_26 Mode: default Direction: in Value: 1

P8_27 Mode: gpio Direction: out Value: 0

P8_28 Mode: gpio Direction: out Value: 0

P8_29 Mode: default Direction: in Value: 0

P8_30 Mode: default Direction: in Value: 0

P8_31 Mode: default Direction: in Value: 0

P8_32 Mode: default Direction: in Value: 0

P8_33 Mode: default Direction: in Value: 0

P8_34 Mode: default Direction: in Value: 0

P8_35 Mode: default Direction: in Value: 0

P8_36 Mode: default Direction: in Value: 0

P8_37 Mode: default Direction: in Value: 0

P8_38 Mode: default Direction: in Value: 0

P8_39 Mode: default Direction: in Value: 0

P8_40 Mode: default Direction: in Value: 0

P8_41 Mode: default Direction: in Value: 0

P8_42 Mode: default Direction: in Value: 0

P8_43 Mode: default Direction: in Value: 0

P8_44 Mode: default Direction: in Value: 0

P8_45 Mode: default Direction: in Value: 0

P8_46 Mode: default Direction: in Value: 0

P9_11 Mode: default Direction: in Value: 1

P9_12 Mode: default Direction: in Value: 1

P9_13 Mode: default Direction: in Value: 1

P9_14 Mode: default Direction: in Value: 0

P9_15 Mode: default Direction: in Value: 1

P9_16 Mode: default Direction: in Value: 0

P9_17 Mode: default Direction: in Value: 1

P9_18 Mode: default Direction: in Value: 1

P9_19 Mode: default Direction: in Value: 0

P9_20 Mode: default Direction: in Value: 0

P9_21 Mode: default Direction: in Value: 1

P9_22 Mode: default Direction: in Value: 1

P9_23 Mode: default Direction: in Value: 0

P9_24 Mode: default Direction: in Value: 1

P9_25 Mode: default Direction: in Value: 0

P9_26 Mode: default Direction: in Value: 1

P9_27 Mode: default Direction: in Value: 0

P9_28 Mode: default Direction: in Value: 0

P9_29 Mode: default Direction: in Value: 0

P9_30 Mode: default Direction: in Value: 0

P9_31 Mode: default Direction: in Value: 0

P9_41 Mode: default Direction: in Value: 0

P9_42 Mode: default Direction: in Value: 0

P9_91 Mode: default Direction: in Value: 0

P9_92 Mode: default Direction: in Value: 0

I suppose I should stick an actual cape on there and check….  I’ll try that tomorrow.

Dan

Forgot to dig out this board before i left for work this morning..

-- 
Daniel Kulp
d...@kulp.com - http://dankulp.com/blog

[Robert Nelson]

On Mon, Apr 1, 2019 at 4:04 PM Daniel Kulp <d...@kulp.com> wrote:
>
>
> On Apr 1, 2019, at 4:55 PM, Robert Nelson <robert...@gmail.com> wrote:
> On Sat, Mar 30, 2019 at 12:26 PM Daniel Kulp <d...@kulp.com> wrote:
>
> As an FYI, I checked out the kernel source and updated the arch/arm/boot/dts/Makefile file to do:
>
> + am335x-sancloud-bbe-uboot-univ.dtb \
>
> and then copied arch/arm/boot/dts/am335x-sancloud-bbe.dts to arch/arm/boot/dts/am335x-sancloud-bbe-uboot-univ.dts and added the line:
>
> #include "am335x-bone-common-univ.dtsi"
>
> to the top (below the am335x-boneblack-common.dtsi) and rebuilt the dtbs and installed just the new one, and everything works. :) config-pin works.
>
>
> Except for the pin's tied up via hdmi and eMMC on the header..
>
>
>
> Are you sure? With the above and:
> disable_uboot_overlay_video=1
> disable_uboot_overlay_audio=1
>
> I get a total of 59 pins that are queryable with config-pin which is the same number I get on a regular BBB:

You should see a good dozen issue here:

dmesg | grep pinctrl

The ./*-uboot-univ.dts start out as a basic empty dts:

https://github.com/RobertCNelson/dtb-rebuilder/blob/4.14-ti/src/arm/am335x-boneblack-uboot-univ.dts

[Daniel Kulp]

root@FPPTest:/opt/fpp/src# dmesg | grep pinc

[    0.221676] pinctrl core: initialized pinctrl subsystem

[    0.809050] pinctrl-single 44e10800.pinmux: 142 pins, size 568

[    1.245538] pinctrl-single 44e10800.pinmux: pin PIN107 already requested by ocp:P9_25_pinmux; cannot claim for 48038000.mcasp

[    1.257270] pinctrl-single 44e10800.pinmux: pin-107 (48038000.mcasp) status -22

[    1.264684] pinctrl-single 44e10800.pinmux: could not request pin 107 (PIN107) from group mcasp0_pins  on device pinctrl-single

[    1.390227] pinctrl-single 44e10800.pinmux: pin PIN40 already requested by ocp:P8_45_pinmux; cannot claim for 0-0070

[    1.400871] pinctrl-single 44e10800.pinmux: pin-40 (0-0070) status -22

[    1.407460] pinctrl-single 44e10800.pinmux: could not request pin 40 (PIN40) from group nxp_hdmi_bonelt_pins  on device pinctrl-single