bone kernel questions.....

Daniel_Kulp · March 27, 2019, 4:32pm

Couple of questions regarding the bone kernels…

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

RobertCNelson · March 27, 2019, 4:49pm

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,

Daniel_Kulp · March 27, 2019, 5:04pm

#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:[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

RobertCNelson · March 27, 2019, 5:14pm

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

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.

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

Regards,

Daniel_Kulp · March 27, 2019, 5:27pm

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 · March 27, 2019, 5:53pm

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 · March 29, 2019, 4:45pm

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

RobertCNelson · March 29, 2019, 4:59pm

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.

Regards,

Daniel_Kulp · March 30, 2019, 5:26pm

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

RobertCNelson · April 1, 2019, 8:55pm

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

Regards,

Daniel_Kulp · April 1, 2019, 9:04pm

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

RobertCNelson · April 1, 2019, 9:34pm

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

Regards,

Daniel_Kulp · April 1, 2019, 9:44pm

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