Bug, or conflict with kernels 4.x and universal IO

GoogleGroups
1

So this is probably more of an oversight than a bug. But when loading some overlays via config-pin overlay , AFTER already having loaded an overlay through /boot/uEnv.txt. At least one pin will still continue function correctly( electrically ) but the file that indicates the actual value of the pin will not update correctly. As an GPI( input ). Which has nothing to do with a conflict in overlays, as I have a custom overlay that initializes several GPIO pins, as well as a few PWM pins. Plus I am loading BB-ADC-00A0.dtbo, and BB-W1-P8.26-00A0.dtbo, Where BB-W1-P8.26-00A0.dtbo is an adaption of the stock overlay BB-W1-P9.12-00A0.dtbo.

None of the above overlays describe, or use any of the same pins. So there can not be a conflict between overlays in that regard.

The fix I found for this problem, was to load all the overlays through /boot/uEnv.txt. Through cape_enable=bone_capemgr.enable_partno=

The pin in question that we’re having issues with is P8.16. Which if memory serves me correctly is also tied to another processor pad/pin through a zero ohm resistor.

Before, all the GPI’s would read correctly through the value file using a shell script. While this one pin would always read 0. Now, the pin value file works correctly.

@Robert,

Has the ability to load multiple overlays through uboot been implemented yet ?

2

I should also add, that I have only tested this “fix” on a beaglebone green. I seem to recall that this problem does not exist when using a beaglebone black.

3

Use this in /boot/uEnv.txt

enable_uboot_overlays=1
uboot_overlay_addr0=/lib/firmware/BB-CAPE-1-00A0.dtbo
uboot_overlay_addr1=/lib/firmware/BB-CAPE-2-00A0.dtbo
uboot_overlay_addr2=/lib/firmware/BB-CAPE-3-00A0.dtbo
uboot_overlay_addr3=/lib/firmware/BB-CAPE-4-00A0.dtbo
dtb_overlay=/lib/firmware/BB-CAPE-5-00A0.dtbo

Regards,

4

Awesome, thanks Robert.

5

Hello all,

Simple question, hope there is a simple answer. After some googling,
I've been unable to discover how and when the ipv4 address for
interface SoftAp0 is set. I would like to change the address from
192.168.8.1 to some other private ipv4 address, ie 192.168.200.1 or
whatever, just something other than 8.1. Part two of that question is
what would break if the change is made?

I know how to keep /etc/dnsmasq.d/SoftAp0 static and modify
the ip values for issuing to clients, just need to know how to get
SoftAp0's base ip changed.

Beaglebone Green Wireless with image:
BeagleBoard.org Debian Image 2017-01-08

Thanks,
Ross

6

Oops, forgot the subject...

7

It is very easy, just edit /etc/network/interfaces.

Laurel

8

So, you can define this in:

ip_prefix="192.168.8"

/usr/bin/bb-wl18xx-tether

https://github.com/rcn-ee/repos/blob/master/bb-wl18xx-firmware/suite/jessie/debian/bb-wl18xx-tether#L26

But i really should move this to:

/etc/default/bb-wl18xx

Careful around:

https://github.com/rcn-ee/repos/blob/0161650aa1e1da854425144c9d50d2d774a6f6e6/bb-wl18xx-firmware/suite/jessie/debian/bb-wl18xx-tether#L286-L291

as i hard-coded that to 192.168.8.x

I'll fix those both up right now..

Regards,

9

That works, thanks Robert....

Ross

10

Pushed out:

https://github.com/rcn-ee/repos/commit/d8253954216fe6aa3baf43cb4580ca4542bded55

It's now building, should hit apt repo in a half hour or so...

Regards,

11

Robert,

So, I got around to updating to the latest bootloader this morning, and, well something went wrong. not sure exactly what yet. But here is the serial debug output. For some reason it can’t seem to find a valid boot partition ?

http://pastebin.com/tUqkDvef

12

the issue is 4.4.9-bone-rt-r10...

grab 4.4.39-bone-rt-r16 or later, which includes a dtc resync:

https://github.com/RobertCNelson/bb-kernel/blob/722d8ee587bc6573c01136ef18dc14d0de903f46/patches/dtc/0001-scripts-dtc-Update-to-upstream-version-overlays.patch

as that fixes:
libfdt fdt_check_header(): FDT_ERR_BADMAGIC

and:
debug: [bootz 0x82000000 0x88080000:48b75f 88000000] ...
ERROR: Did not find a cmdline Flattened Device Tree
Could not find a valid device tree

Regards,

13

D'oh . . .Ok, was sure it was my fault, and it was. Way too early of a
kernel, and I did not even think about that.

*After an apt-get update . . .*
*root@beaglebone:~#* apt-cache search linux-image |grep 4.4.39-bone
linux-image-4.4.39-bone-rt-r14 - Linux kernel, version 4.4.39-bone-rt-r14
linux-image-4.4.39-bone-rt-r15 - Linux kernel, version 4.4.39-bone-rt-r15
linux-image-4.4.39-bone14 - Linux kernel, version 4.4.39-bone14
linux-image-4.4.39-bone15 - Linux kernel, version 4.4.39-bone15

What am I missing ?

14

of course my dtc update alone wasn't built-able..

Grab the next release, where i fixed the dtc build errors...

linux-image-4.4.41-bone-rt-r16

Regards,

15

Thanks Robert. The odd thing, when I do a std apt-cache search linux-image |grep bone. I don’t see those versions, or they’re ordered out of sequence, and I just look in the wrong place I guess. So in context of 4.4.x, the kernel I pulled in “seemed” to be the newest. shrug