Cape Manager for U-Boot

[Robert Nelson]

Okay, second pass more things work, more corner cases to fix...

Here is the base u-boot patch, plus the cape manager:

https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2017.01-rc2/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch

https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2017.01-rc2/0002-U-Boot-BeagleBone-Cape-Manager.patch

Probally lots of string handling bugs, found my self trying to write
everything in bash, yet it's C.. ;)

So, the fun details of U-Boot:

U-Boot found the BeagleBone Serial Cape:

Board: BeagleBone Black
<ethaddr> not set. Validating first E-fuse MAC
BeagleBone: cape eeprom: i2c_probe: 0x54:
BeagleBone: cape eeprom: i2c_probe: 0x55:
/lib/firmware/BB-BONE-SERL-03-00A1.dtbo
BeagleBone: cape eeprom: i2c_probe: 0x56:
BeagleBone: cape eeprom: i2c_probe: 0x57:
Net: eth0: MII MODE

U-Boot loaded the BeagleBone Serial Cape overlay on top of the main dtb:

loading /boot/dtbs/4.4.39-ti-r77/am335x-boneblack.dtb ...
62069 bytes read in 135 ms (448.2 KiB/s)
debug: [uboot_overlay_addr1=/lib/firmware/BB-BONE-SERL-03-00A1.dtbo] ...
loading /lib/firmware/BB-BONE-SERL-03-00A1.dtbo ...
887 bytes read in 189 ms (3.9 KiB/s)
loading /boot/initrd.img-4.4.39-ti-r77 ...
5237762 bytes read in 466 ms (10.7 MiB/s)
debug: [console=ttyO0,115200n8
bone_capemgr.disable_partno=BB-BONE-SERL-03 root=/dev/mmcblk0p1 ro
rootfstype=ext4 rootwait coherent_pool=1M quiet net.ifnames=0] ...
debug: [bootz 0x82000000 0x88080000:4fec02 88000000] ...

Kernel: second ttyS2 comes up nice and early...

root@beaglebone:~# dmesg | grep serial
[ 2.073749] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 158,
base_baud = 3000000) is a 8250
[ 2.088159] 48024000.serial: ttyS2 at MMIO 0x48024000 (irq = 159,
base_baud = 3000000) is a 8250
[ 7.807662] systemd[1]: Created slice system-serial\x2dgetty.slice.

Hurrah!!!

First issue... Now the Kernel Cape Manager get's in the way, i need to
pass a global kill switch (or find the global disable), right now you
have to "disable" capes loaded by U-Boot.. (you don't have too, it
just looks weird when they both load fine..)

root@beaglebone:~# dmesg | grep bone
[ 0.000000] Kernel command line: console=ttyO0,115200n8
bone_capemgr.disable_partno=BB-BONE-SERL-03 root=/dev/mmcblk0p1 ro
rootfstype=ext4 rootwait coherent_pool=1M quiet net.ifnames=0
[ 2.345976] bone_capemgr bone_capemgr: Baseboard:
'A335BNLT,00C0,2516BBBK2626'
[ 2.346020] bone_capemgr bone_capemgr:
compatible-baseboard=ti,beaglebone-black - #slots=4
[ 2.382381] bone_capemgr bone_capemgr: slot #0: No cape found
[ 2.412268] bone_capemgr bone_capemgr: slot #1: 'BeagleBone RS232
CAPE,00A1,Beagleboardtoys,BB-BONE-SERL-03'
[ 2.450326] bone_capemgr bone_capemgr: slot #2: No cape found
[ 2.494321] bone_capemgr bone_capemgr: slot #3: No cape found
[ 2.500199] bone_capemgr bone_capemgr: Skipping loading of disabled
cape with part# BB-BONE-SERL-03
[ 2.500214] bone_capemgr bone_capemgr: initialized OK.
[ 6.813904] systemd[1]: Set hostname to <beaglebone>.
[ 15.389423] LUN: removable read only file:
/var/cache/doc-beaglebone-getting-started/beaglebone-getting-started-2016-11-07.img

So to actually test follow:

*************Actual testing...***************************************

Step 1: Do you have a usb serial adapter to monitor the boot process?

no = stop reading now... till you have one in hand...
yes = please continue

Step 2: Remove /uEnv.txt (i forgot to code that path in this test)

rm /uEnv.txt

Step 3: Update u-boot to v2017.01-rc2

cd /opt/scripts/tools/developers/
git pull
./update_bootloader.sh --use-beta-bootloader

On reboot, it should show:

U-Boot SPL 2017.01-rc2-00003-g835d6bbf46 (Dec 29 2016 - 15:28:49)
Trying to boot from MMC1

U-Boot 2017.01-rc2-00003-g835d6bbf46 (Dec 29 2016 - 15:28:49 -0600),
Build: jenkins-github_Bootloader-Builder-496

If not, eMMC probably messing with you..

dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=10

Step 4: /boot/uEnv.txt

remove "cape_universal=enable" we dont want any false posititves...

and remember to disable your Kernel overlay:

cape_disable=bone_capemgr.disable_partno=BB-BONE-SERL-03

Step 5: Profit!!! ;)

*****************************************************************

I know it's a little limited, but something for testing over Christmas. ;)

FAQ:

What does this solve? Lots of random kernel races... (looking at
video/emmc/etc)... As U-Boot updates the final *.dtb and not the
kernel...

What about 2+ overlays? "should" work, we should be able to load 4
cape's via eeprom ID, plus a 5th via: dtb_overlay in /boot/uEnv.txt

Does this replace the current method? Yes, I'm thinking for v4.10.x+ ;)

What have you tested it on? Just BB-UART2-00A0.dtbo and then i wrote
this email up and got ready to go home...

Will this fix the issue with the painful out of box experience with
LCD3/LCD4/LCD7? Correct, as long as they have an eeprom. ;)

How do i actually test things?

Easiest, /boot/uEnv.txt

dtb=am335x-boneblack-overlay.dtb

Regards,


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

[Robert Nelson]

> First issue... Now the Kernel Cape Manager get's in the way, i need to
> pass a global kill switch (or find the global disable), right now you
> have to "disable" capes loaded by U-Boot.. (you don't have too, it
> just looks weird when they both load fine..)

adding "of_overlay_disable" to the boot arg's kills it..

[William Hermans]

On Thu, Dec 29, 2016 at 3:05 PM, Robert Nelson <robert...@gmail.com> wrote:

Okay, second pass more things work, more corner cases to fix...

Does this replace the current method? Yes, I'm thinking for v4.10.x+ ;)

<snip>

What have you tested it on?  Just BB-UART2-00A0.dtbo and then i wrote
this email up and got ready to go home...

 BB-W1-P8.26-00A0.dtbo which is an adaption of the "stock"  BB-W1-P9.12-00A0.dtbo overlay works too.

Will this fix the issue with the painful out of box experience with
LCD3/LCD4/LCD7? Correct, as long as they have an eeprom. ;)

How do i actually test things?

Easiest, /boot/uEnv.txt

dtb=am335x-boneblack-overlay.dtb

Regards,

Ok so let me get one thing clear here. I can remove "dtb=<whatever proper board file> and it should load automatically via uboot's board file loader ? One caveat here, for me anyhow. I have a modified am335x-boneblack-emmc-overlay.dtb with ethernet sleep functionality removed. So, how could I load that instead of the default for the board eeprom ?

[William Hermans]

On Thu, Dec 29, 2016 at 3:16 PM, Robert Nelson <robert...@gmail.com> wrote:

> First issue... Now the Kernel Cape Manager get's in the way, i need to
> pass a global kill switch (or find the global disable), right now you
> have to "disable" capes loaded by U-Boot.. (you don't have too, it
> just looks weird when they both load fine..)

adding "of_overlay_disable" to the boot arg's kills it..

Additionally to the previous post I've made. So assuming I leave my dtb=<board file I want loaded> in to bypass the default behavior. Does this work in this manner ? e.g. I need a specific, and custom board file to load at boot.

[William Hermans]

err, I kind of messed that post up. but the question is still valid, just hanging off the wrong post. But I was curious what you mentioned in your last post.

> adding "of_overlay_disable" to the boot arg's kills it.

So I find this a little confusing. This means we're able to disable the kernel / userspace cap manager, or the uboot cape manager? The later doesn't make sense to me. what who says that it needs to ?

[Robert Nelson]

On Thu, Dec 29, 2016 at 6:31 PM, William Hermans <yyr...@gmail.com> wrote:
>
>
> On Thu, Dec 29, 2016 at 3:05 PM, Robert Nelson <robert...@gmail.com>
> wrote:
>>
>> Okay, second pass more things work, more corner cases to fix...
>
> Does this replace the current method? Yes, I'm thinking for v4.10.x+ ;)
>
> <snip>

yeah, probably not. ;)

>>
>>
>> What have you tested it on? Just BB-UART2-00A0.dtbo and then i wrote
>> this email up and got ready to go home...
>
>
> BB-W1-P8.26-00A0.dtbo which is an adaption of the "stock"
> BB-W1-P9.12-00A0.dtbo overlay works too.

Sweet!

>>
>>
>> Will this fix the issue with the painful out of box experience with
>> LCD3/LCD4/LCD7? Correct, as long as they have an eeprom. ;)
>>
>> How do i actually test things?
>>
>> Easiest, /boot/uEnv.txt
>>
>> dtb=am335x-boneblack-overlay.dtb
>>
>> Regards,
>>
>
> Ok so let me get one thing clear here. I can remove "dtb=<whatever proper
> board file> and it should load automatically via uboot's board file loader ?
> One caveat here, for me anyhow. I have a modified
> am335x-boneblack-emmc-overlay.dtb with ethernet sleep functionality removed.
> So, how could I load that instead of the default for the board eeprom ?

As long as you specify "dtb=<something>" i won't start with a
different default dtb.. Your still in full control.

I also want to add a variable to /boot/uEnv.txt enable this, so end
users can easily disable it..

[Robert Nelson]

On Thu, Dec 29, 2016 at 6:41 PM, William Hermans <yyr...@gmail.com> wrote:
> err, I kind of messed that post up. but the question is still valid, just
> hanging off the wrong post. But I was curious what you mentioned in your
> last post.
>
>> adding "of_overlay_disable" to the boot arg's kills it.
>
> So I find this a little confusing. This means we're able to disable the
> kernel / userspace cap manager, or the uboot cape manager? The later doesn't
> make sense to me. what who says that it needs to ?

it turns out of_overlay_disable kill's everything in the kernel land.
So while it kill's the auto slot loading, it also kills manually
loading..

So what i really need to do, is patch v4.1.x/v4.4.x/v4.9.x and set a
flag so the kernel knows u-boot already loaded the 4 eeprom slots, and
doesn't try to auto load an overlay that's already loaded....

* I also need to add the eMMC, hdmi-video, hdmi-audio,
ethernet/wireless overlays. So we can do things like the old
3.8.13-bone.... (except thru u-boot)

[William Hermans]

Ok, cool, thanks Robert.

However I feel compelled to add a bit more information just in case it ever becomes important.

First up. While the one wire overlay does seem to work fine( I can talk to a 1-wire temp sensor just fine ). dmesg only gives this:

[   11.712253] Driver for 1-wire Dallas network protocol.

Where as the serial boot log I get:

. . .
Running uname_boot ...
loading /boot/vmlinuz-4.4.12-ti-r31 ...
7777640 bytes read in 513 ms (14.5 MiB/s)
loading /boot/dtbs/4.4.12-ti-r31/am335x-boneblack-emmc-overlay.dtb ...
60139 bytes read in 39 ms (1.5 MiB/s)
debug: [dtb_overlay=/lib/firmware/BB-W1-P8.26-00A0.dtbo] ...
loading /lib/firmware/BB-W1-P8.26-00A0.dtbo ...
974 bytes read in 72 ms (12.7 KiB/s)
loading /boot/initrd.img-4.4.12-ti-r31 ...
4556959 bytes read in 308 ms (14.1 MiB/s)
debug: [console=ttyO0,115200n8 root=UUID=b83ca291-b04b-4c94-819a-b33f39e574c8 ro rootfstype=ext4 rootwait coherent_pool=1M quiet] ...
. . .

No biggie to me, it works. So if that information is not in the dmesg syslogs, personally I'm fine with that. But maybe that is not your desired result ?

The rest I think you may have just answered in a new post so will read that first.

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYiX1Fyp9FzcnqrU0rR91z1mNutd4HCqWf01t0gdnaN5oA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Robert Nelson]

You just stumbled on the biggest issue...

Debugging's going to be fun.. Specially if the end user doesn't have
a usb-serial cable..

After u-boot patches the device-tree, the kernel will never know..
(that's also why things, video/mmc/wl18xx will also just work better)

[William Hermans]

On Thu, Dec 29, 2016 at 6:05 PM, Robert Nelson <robert...@gmail.com> wrote:

You just stumbled on the biggest issue...

Debugging's going to be fun..  Specially if the end user doesn't have
a usb-serial cable..

After u-boot patches the device-tree, the kernel will never know..
(that's also why things, video/mmc/wl18xx will also just work better)

Honestly, and obviously just my opinion. But if anyone is truly serious about using a beaglebone black / green*. They really need a serial debug cable. Otherwise, they should just "stay home". As far as spending a little extra time reading a couple logs, versus just one . . .yeah whatever. If you're serious, you're serious. A small price to pay for such a useful bit of hardware that can be used in many different ways.

[William Hermans]

Robert, oh right the other bit of information I needed to let you know about . . .

debian@beaglebone:~$ cd /opt/scripts/tools/developers/
debian@beaglebone:/opt/scripts/tools/developers$ git pull
Already up-to-date.

Where the boot log still says . . .

[116467.340818] reboot: Restarting system

U-Boot SPL 2017.01-rc2-00002-g52b3c56009 (Dec 23 2016 - 16:22:21)
Trying to boot from MMC2

U-Boot 2017.01-rc2-00002-g52b3c56009 (Dec 23 2016 - 16:22:21 -0600), Build: jenk  ins-github_Bootloader-Builder-493

CPU  : AM335X-GP rev 2.1

So apparently, for now. I'm unable to "play". I'd so an apt-get update. But somehow, I don't think that'd work ;)

[William Hermans]

On Thu, Dec 29, 2016 at 6:25 PM, William Hermans <yyr...@gmail.com> wrote:

Robert, oh right the other bit of information I needed to let you know about . . .

debian@beaglebone:~$ cd /opt/scripts/tools/developers/
debian@beaglebone:/opt/scripts/tools/developers$ git pull
Already up-to-date.

Where the boot log still says . . .

[116467.340818] reboot: Restarting system

U-Boot SPL 2017.01-rc2-00002-g52b3c56009 (Dec 23 2016 - 16:22:21)
Trying to boot from MMC2

U-Boot 2017.01-rc2-00002-g52b3c56009 (Dec 23 2016 - 16:22:21 -0600), Build: jenk  ins-github_Bootloader-Builder-493

CPU  : AM335X-GP rev 2.1

So apparently, for now. I'm unable to "play". I'd so an apt-get update. But somehow, I don't think that'd work ;)

What I mean, is that in this post you seem to be on build 496, where I am still in "sync" with the last post using build 493. Not sure that is important or not after the information you just posted about disabling cape manager disables everything . . . but Perhaps not.

[Robert Nelson]

Okay, time to push it out as default...

First stable build is:

U-Boot SPL 2017.01-rc2-00003-ga4c7d45040 (Dec 30 2016 - 11:30:57)

Trying to boot from MMC1

U-Boot 2017.01-rc2-00003-ga4c7d45040 (Dec 30 2016 - 11:30:57 -0600),
Build: jenkins-github_Bootloader-Builder-497

This includes a U-Boot overlays disabled by default, end user has to
enable in /boot/uEnv.txt overide..

Doc's:

to enable this new feature, set enable_boot_overlays in /boot/uEnv.txt

enable_uboot_overlays=1

First 4 slots are then auto-loaded
5th slot, can be set by user

dtb_overlay=/lib/firmware/*.dtbo

Works best with a r78 based v4.4.x kernel..

[William Hermans]

Hey Robert,

So, a question some of us who already have existing, and working images may have. Is how do we update our uboot ? When updating to a new kernel, I suspect this will happen automatically via dpkg. But what if "we" do not wish to update our kernel? Things may be working perfectly etc, and maybe we're a bit skittish about updating to a newer kernel. Or maybe we have kernel reliant software ( custom kernel modules, etc ).

I just did a git pull update of the scripts repo's but the only two files updated seem like they're unrelated. Or maybe it just seems that way to me . . .

[William Hermans]

So I thought about it for a few minutes when not otherwise busy, and figured it out on my own.


$ cd /opt/scripts/tools/developers/
$ git pull
$ sudo ./update_bootloader.sh
$ sudo reboot

serial debug:
...
[84389.038894] reboot: Restarting system

U-Boot SPL 2017.01-rc2-00003-ga4c7d45040 (Dec 30 2016 - 11:30:57)

Trying to boot from MMC2

U-Boot 2017.01-rc2-00003-ga4c7d45040 (Dec 30 2016 - 11:30:57 -0600), Build: jenkins-github_Bootloader-Builder-497

...

But I forgot to change /boot/uEnv.txt to allow uboot cape manager . . .

$ sudo nano /boot/uEnv.txt
. . .
##BeagleBone Black: HDMI (Audio/Video) disabled:
enable_uboot_overlays=1
dtb=am335x-boneblack-emmc-overlay.dtb
dtb_overlay=/lib/firmware/BB-W1-P8.26-00A0.dtbo

. . .

Serial debug now:
loading /boot/vmlinuz-4.4.12-ti-r31 ...
7777640 bytes read in 514 ms (14.4 MiB/s)

loading /boot/dtbs/4.4.12-ti-r31/am335x-boneblack-emmc-overlay.dtb ...
60139 bytes read in 39 ms (1.5 MiB/s)
debug: [dtb_overlay=/lib/firmware/BB-W1-P8.26-00A0.dtbo] ...
loading /lib/firmware/BB-W1-P8.26-00A0.dtbo ...
974 bytes read in 72 ms (12.7 KiB/s)

Testing 1-wire temp sensor:
debian@beaglebone:~$ cat /sys/bus/w1/devices/28-00000647ddf6/w1_slave
1c 01 4b 46 7f ff 04 10 e8 : crc=e8 YES
1c 01 4b 46 7f ff 04 10 e8 t=17750

Everything working fine.

[William Hermans]

dtb_overlay=/lib/firmware/BB-SPIDEV0-00A0.dtbo

*Seems* to work fine as well. I've no reason to think it doesn't work, but I have not tested the SPI transmission with spidev_test, or a logic analyzer *YET*. The overlay does seem to load the drivers fine

loading /boot/dtbs/4.4.12-ti-r31/am335x-boneblack-emmc-overlay.dtb ...
60139 bytes read in 40 ms (1.4 MiB/s)
debug: [dtb_overlay=/lib/firmware/BB-SPIDEV0-00A0.dtbo] ...
loading /lib/firmware/BB-SPIDEV0-00A0.dtbo ...
1235 bytes read in 60 ms (19.5 KiB/s)
loading /boot/initrd.img-4.4.12-ti-r31 ...

 And the interfaces show up in /dev/

debian@beaglebone:~$ ls /dev |grep spidev
spidev1.0
spidev1.1

[William Hermans]

So, I've tested this a few times over the last . . .<whatever it's been since announcement >, and I have found that loading a single overlay seems to work really good. Attempting multiple overlays however, seems to  be an exercise in frustration. e.g. It's not ready. It's possible that I got something wrong, but I do not usually do that more than once. I've tried multiple times.

So my recommendation is, if you're an embedded Linux noob, or a beginner to this platforms boot process. Steer clear. If you're reasonably experienced in both of these areas, and don't mind testing - Have fun. But I would definitely strongly advise to not attempt this on a production system.

Basically what happens is uboot complains that the cmdline kernel parameter does not contain a valid flattened device tree overlay path. Why exactly, I'm not sure. I did see uboot "mention" that it can not find a valid partition for partitions 1-6 . . . which I think may be standard uboot debug output. First, it checked the path for the UUID, then attempted the blk device. Failing ( or flailing ). However, this works perfectly fine when using:

##Example v4.1.x
#cape_disable=bone_capemgr.disable_partno=
cape_enable=bone_capemgr.enable_partno=controller,BB-ADC,BB-W1-P8.26

After making sure the overlays exist in /lib/firmware/, and then running:

root@beaglebone:~# cd /opt/scripts/tools/developers/
root@beaglebone:/opt/scripts/tools/developers# ./update_initrd.sh
root@beaglebone:/opt/scripts/tools/developers# reboot

One should also keep in mind that if you update to a newer kernel before this process. Make sure you reboot into your new kernel first. Otherwise your board *WILL* boot, but the boot process will stop inside the initramfs. I fell into this trap myself, and basically what happens. You will end up updating the initramfs you just replaced, while leaving the replacement initramfs without a clue as to where to go next. Once the initramfs loads that is.

Anyway, this is a potentially really cool, and good feature. I look forward to this working flawlessly in the future. However, at this point in time, I have to give testing a pass. As I have other priorities that must come first - currently.

[William Hermans]

By the way, the kernel I failed with was: linux-image-4.4.43-bone-rt-r16

[Robert Nelson]

So adding a couple more fdt commits from u-boot mainline: (to actually
report what failed)

loading /boot/vmlinuz-4.9.4-bone4 ...
8225160 bytes read in 543 ms (14.4 MiB/s)
loading /boot/dtbs/4.9.4-bone4/am335x-boneblack-overlay.dtb ...
52712 bytes read in 63 ms (816.4 KiB/s)
debug: [uboot_overlay_addr0=/lib/firmware/BB-BONE-LCD7-01-00A3.dtbo] ...
loading /lib/firmware/BB-BONE-LCD7-01-00A3.dtbo ...
5778 bytes read in 136 ms (41 KiB/s)
fdt_overlay_apply(): FDT_ERR_NOSPACE

that's why it's not applying it..

[William Hermans]

Not enough memory allocated ?

--
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+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYjXDCsStAuLOgobXCUzsuZcWG%2BQDBhUmjAaKxSexdCj9w%40mail.gmail.com.

[Robert Nelson]

On Wed, Jan 18, 2017 at 2:24 PM, William Hermans <yyr...@gmail.com> wrote:
> Not enough memory allocated ?

Correct by default it was only 4k, defaulted to 0x60000

seems to have fixed the big overlays...

https://github.com/RobertCNelson/Bootloader-Builder/commit/6f3929a577056d10a7994252aa521835bf3f3984

[William Hermans]

The error I noticed on my end was: libfdt fdt_check_header(): FDT_ERR_BADMAGIC Which did not really make sense to me as the overlays seems to work just fine. I did not check everythign with my overlays, but I did check gpio45, and according to the direciton, and value files it's configured correctly. But I was getting some odd boot log error message about the capemgr back peddling a non existent pin conflict. From where it came, I have no idea.

beaglebone login: [   19.548440] omap-sham 53100000.sham: initialization failed.

[   19.880445] pinctrl-single 44e10800.pinmux: pin 44e10834.0 already requested by ocp:P8_11_pinmux; cannot claim for onewire

[   19.921657] pinctrl-single 44e10800.pinmux: pin-13 (onewire) status -22

[   20.000724] pinctrl-single 44e10800.pinmux: could not request pin 13 (44e10834.0) from group pinmux_P8_11_default_pin  on device pinctrl-single

[   20.093995] w1-gpio onewire: Error applying setting, reverse things back

That's another error message I've been noticing lately. omap_sham initialization failing. But when I take a look at the output of lsmod . . .
root@beaglebone:~# lsmod |grep omap
omap_aes               13637  0
omap_rng                4572  0
omap_sham              21458  0
rng_core                7390  1 omap_rng

It seems to have loaded fine ? So I'm guessing omap_sham is related to SHA somehow, and thus probably important. Not sure why this error message though :/

 I'm also assuming it's fine since it's already loaded, but . . .I'm not 100% positive.

--
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+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYiu5hnmwr23woC5ST6X7HR2KJA8%2BfQkaA8U_%3DpaGkO%2BBA%40mail.gmail.com.

[William Hermans]

Just for informational purposes here is that one pin in my custom overlay:

. . .
exclusive-use =
        /* the pin header uses */
        "P8.11",
. . .
/* P8_11 (ZCZ ball R12) */
            P8_11_default_pin: pinmux_P8_11_default_pin {
                pinctrl-single,pins = <0x034  0x27>; };     /* Mode 7, Pull-Down, RxActive */
. . .
fragment@1 {
        target = <&ocp>;
        __overlay__ {

            P8_11_pinmux {
                compatible = "bone-pinmux-helper";
                status = "okay";
                pinctrl-names = "default";
                pinctrl-0 = <&P8_11_default_pin>;
            };
. . .

P8_11 {
                    gpio-name = "P8_11";
                    gpio = <&gpio1 13 0>;
                    input;
                    dir-changeable;
                };
. . .

Then the P8.26 1-wire overlay is exactly the same as the one example 1-wire overlay included with the stock image. But I changed the pin configuration to match P8.26 instead of what was it ? P9.12 was it ? No idea why I'm getting that boot message, and this is the first time I've ever seen it.

[William Hermans]

Yet more information I noticed, sorry for the multiple posts . . . But notice how the custom cape is attempted to load first, but the actual overlay id is dead last. It's almost as though capemgr is trying to load them simultaneously but the ADC overlay being smaller in size won out ?

root@beaglebone:~# dmesg |grep bone_capemgr
[    0.000000] Kernel command line: console=ttyO0,115200n8 bone_capemgr.enable_partno=controller,BB-ADC,BB-W1-P8.26 root=UUID=826386f9-a359-428a-a111-486cd84f92b5 ro rootfstype=ext4 rootwait coherent_pool=1M quiet ipv6.disable=1
[    4.252789] bone_capemgr bone_capemgr: Baseboard: 'A335BNLT,00C0,3214BBBK0403'
[    4.252815] bone_capemgr bone_capemgr: compatible-baseboard=ti,beaglebone-black - #slots=4
[    4.305592] bone_capemgr bone_capemgr: slot #0: No cape found
[    4.365587] bone_capemgr bone_capemgr: slot #1: No cape found
[    4.425586] bone_capemgr bone_capemgr: slot #2: No cape found
[    4.485586] bone_capemgr bone_capemgr: slot #3: No cape found
[    4.491376] bone_capemgr bone_capemgr: enabled_partno PARTNO 'controller' VER 'N/A' PR '0'
[    4.491388] bone_capemgr bone_capemgr: slot #4: override
[    4.491401] bone_capemgr bone_capemgr: Using override eeprom data at slot 4
[    4.491415] bone_capemgr bone_capemgr: slot #4: 'Override Board Name,00A0,Override Manuf,controller'
[    4.491498] bone_capemgr bone_capemgr: enabled_partno PARTNO 'BB-ADC' VER 'N/A' PR '0'
[    4.491509] bone_capemgr bone_capemgr: slot #5: override
[    4.491520] bone_capemgr bone_capemgr: Using override eeprom data at slot 5
[    4.491533] bone_capemgr bone_capemgr: slot #5: 'Override Board Name,00A0,Override Manuf,BB-ADC'
[    4.491602] bone_capemgr bone_capemgr: enabled_partno PARTNO 'BB-W1-P8.26' VER 'N/A' PR '0'
[    4.491613] bone_capemgr bone_capemgr: slot #6: override
[    4.491624] bone_capemgr bone_capemgr: Using override eeprom data at slot 6
[    4.491637] bone_capemgr bone_capemgr: slot #6: 'Override Board Name,00A0,Override Manuf,BB-W1-P8.26'
[    4.492070] bone_capemgr bone_capemgr: initialized OK.
[    4.503689] bone_capemgr bone_capemgr: slot #5: dtbo 'BB-ADC-00A0.dtbo' loaded; overlay id #0
[    4.505152] bone_capemgr bone_capemgr: slot #6: dtbo 'BB-W1-P8.26-00A0.dtbo' loaded; overlay id #1
[    4.540874] bone_capemgr bone_capemgr: slot #4: dtbo 'controller-00A0.dtbo' loaded; overlay id #2

[William Hermans]

So I stopped what I was doing and did some testing. It seems as though the current iteration of capemgr has a problem loading more than two overlays at boot, through the cmdline parameter. Both of the "custom" overlays have been injected into the initramfs via the script update_initrd.sh.

Worklog and testing output:
http://pastebin.com/YkHnZ4f2

[woody...@yahoo.com]

--------------------------------------------
On Wed, 1/18/17, William Hermans <yyr...@gmail.com> wrote:

Subject: Re: [beagleboard] Re: Cape Manager for U-Boot
To: beagl...@googlegroups.com
Date: Wednesday, January 18, 2017, 11:27 PM

compatible-baseboard=ti, beaglebone-black - #slots=4

from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORri4-GbtRRq8JaNXKj_ugZ5B6UK6KS68v15e36TZJOUWg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

ermania fascista spre concesii l-a determinat pe regele Caro al II sa

[lgil...@tethers.com]

Did this ever get sorted out?   I'm working on a BBB project and trying to load 4 dtbo files in slots 4--7, and they are not affecting the hw setup as expected.   I'm running:

debian:   

[root@beaglebone]> uname -a

Linux beaglebone 4.4.91-ti-r133 #1 SMP Tue Oct 10 05:18:08 UTC 2017 armv7l GNU/Linux

u-boot:

[root@beaglebone]> grep -a --null-data U-Boot /dev/mmcblk0

U-Boot SPL 2018.01-00002-g9aa111a004 (Jan 20 2018 - 12:45:29)

 

Here's my uEnv.txt file:

#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0

uname_r=4.4.91-ti-r133

#uuid=

dtb=

dtb=am335x-boneblack-overlay.dtb

###U-Boot Overlays###

###Documentation: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays

###Master Enable

enable_uboot_overlays=1

###

###Overide capes with eeprom

#uboot_overlay_addr0=/lib/firmware/bone_eqep2b-00A0.dtbo

#uboot_overlay_addr1=/lib/firmware/<file1>.dtbo

#uboot_overlay_addr2=/lib/firmware/<file2>.dtbo

#uboot_overlay_addr3=/lib/firmware/<file3>.dtbo

###

###Additional custom capes

uboot_overlay_addr4=/lib/firmware/maps_bbb_pwm-00A0.dtbo

uboot_overlay_addr5=/lib/firmware/maps_bbb_eqep-00A0.dtbo

uboot_overlay_addr6=/lib/firmware/maps_bbb_i2c-00A0.dtbo

uboot_overlay_addr7=/lib/firmware/maps_bbb_gpio-00A0.dtbo

###

###Custom Cape

#dtb_overlay=/lib/firmware/<file8>.dtbo

###

###Disable auto loading of virtual capes (emmc/video/wireless/adc)

disable_uboot_overlay_emmc=1

disable_uboot_overlay_video=1

disable_uboot_overlay_audio=1

disable_uboot_overlay_wireless=1

disable_uboot_overlay_adc=1

###

###PRUSS OPTIONS

###pru_rproc (4.4.x-ti kernel)

#uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo

###pru_uio (4.4.x-ti & mainline/bone kernel)

#uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo

###

###Cape Universal Enable

#enable_uboot_cape_universal=0

###

###Debug: disable uboot autoload of Cape

#disable_uboot_overlay_addr0=1

#disable_uboot_overlay_addr1=1

#disable_uboot_overlay_addr2=1

#disable_uboot_overlay_addr3=1

###

###U-Boot fdt tweaks...

#uboot_fdt_buffer=0x60000

###U-Boot Overlays###

#cmdline=coherent_pool=1M net.ifnames=0 quiet cape_universal=enable

#cmdline=coherent_pool=1M net.ifnames=0 quiet

#In the event of edid real failures, uncomment this next line:

#cmdline=coherent_pool=1M net.ifnames=0 quiet video=HDMI-A-1:1024x768@60e

##Example v3.8.x

#cape_disable=capemgr.disable_partno=

#cape_enable=capemgr.enable_partno=

##Example v4.1.x

#cape_disable=bone_capemgr.disable_partno=

#cape_enable=bone_capemgr.enable_partno=

##enable Generic eMMC Flasher:

##make sure, these tools are installed: dosfstools rsync

#cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh

# EOF 

 

[Robert Nelson]

On Fri, Mar 16, 2018 at 4:29 PM, <lgil...@tethers.com> wrote:
>> Did this ever get sorted out? I'm working on a BBB project and trying to
>> load 4 dtbo files in slots 4--7, and they are not affecting the hw setup as
>> expected. I'm running:
>
>
> debian:
> [root@beaglebone]> uname -a
> Linux beaglebone 4.4.91-ti-r133 #1 SMP Tue Oct 10 05:18:08 UTC 2017 armv7l
> GNU/Linux
>
> u-boot:
> [root@beaglebone]> grep -a --null-data U-Boot /dev/mmcblk0
>
> U-Boot SPL 2018.01-00002-g9aa111a004 (Jan 20 2018 - 12:45:29)

Please show:

sudo /opt/scripts/tools/version.sh

>> Here's my uEnv.txt file:
>
>
> #Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0
>
> uname_r=4.4.91-ti-r133
> #uuid=
> dtb=
> dtb=am335x-boneblack-overlay.dtb

^ this isn't required with u-boot overlays..

>
>
> ###U-Boot Overlays###
> ###Documentation:
> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays
> ###Master Enable
> enable_uboot_overlays=1
> ###
> ###Overide capes with eeprom
> #uboot_overlay_addr0=/lib/firmware/bone_eqep2b-00A0.dtbo
> #uboot_overlay_addr1=/lib/firmware/<file1>.dtbo
> #uboot_overlay_addr2=/lib/firmware/<file2>.dtbo
> #uboot_overlay_addr3=/lib/firmware/<file3>.dtbo
> ###
> ###Additional custom capes
> uboot_overlay_addr4=/lib/firmware/maps_bbb_pwm-00A0.dtbo
> uboot_overlay_addr5=/lib/firmware/maps_bbb_eqep-00A0.dtbo
> uboot_overlay_addr6=/lib/firmware/maps_bbb_i2c-00A0.dtbo
> uboot_overlay_addr7=/lib/firmware/maps_bbb_gpio-00A0.dtbo

[lgil...@tethers.com]

Thanks for responding!   Sorry for the delay in my reply, I did not have access to my BBB over the weekend.

One interesting note is that not only do our dts files work individually, but they also work when combined into one giant dts, so I don't believe there is any issue with their formatting.   It's only when we try to load them as four separate files that we run into problems.

Here is the output of the version.sh script:

[root@beaglebone]> ./version.sh

git:/opt/scripts/:[d36fe9a7be9ebfc872b10a470e904ab4c61c4516]

eeprom:[A335BNLT00C00515BBBK0825]

dogtag:[BeagleBoard.org Debian Image 2017-10-10]

bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 2018.01-00002-g9aa111a004]

kernel:[4.4.91-ti-r133]

nodejs:[v6.11.4]

device-tree-override:[dtb=

dtb=am335x-boneblack-overlay.dtb]

uboot_overlay_options:[enable_uboot_overlays=1]

uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/maps_bbb_pwm-00A0.dtbo]

uboot_overlay_options:[uboot_overlay_addr5=/lib/firmware/maps_bbb_eqep-00A0.dtbo]

uboot_overlay_options:[uboot_overlay_addr6=/lib/firmware/maps_bbb_i2c-00A0.dtbo]

uboot_overlay_options:[uboot_overlay_addr7=/lib/firmware/maps_bbb_gpio-00A0.dtbo]

uboot_overlay_options:[disable_uboot_overlay_emmc=1]

uboot_overlay_options:[disable_uboot_overlay_video=1]

uboot_overlay_options:[disable_uboot_overlay_audio=1]

uboot_overlay_options:[disable_uboot_overlay_wireless=1]

uboot_overlay_options:[disable_uboot_overlay_adc=1]

pkg:[bb-cape-overlays]:[4.4.20171009.0-0rcnee1~stretch+20171009]

pkg:[bb-wl18xx-firmware]:[1.20170829-0rcnee1~stretch+20170829]

pkg:[firmware-ti-connectivity]:[20170823-1rcnee0~stretch+20170830]

[lgil...@tethers.com]

Any ideas?  Help is very much appreciated.   We'd like to keep our dtbo info in four files rather than one giant one...

[Robert Nelson]

On Tue, Mar 20, 2018 at 7:48 PM, <lgil...@tethers.com> wrote:
> Any ideas? Help is very much appreciated. We'd like to keep our dtbo info
> in four files rather than one giant one...
>
>
> On Monday, March 19, 2018 at 9:45:03 AM UTC-7, lgil...@tethers.com wrote:
>>
>> Thanks for responding! Sorry for the delay in my reply, I did not have
>> access to my BBB over the weekend.
>>
>> One interesting note is that not only do our dts files work individually,
>> but they also work when combined into one giant dts, so I don't believe
>> there is any issue with their formatting. It's only when we try to load
>> them as four separate files that we run into problems.
>>
>> Here is the output of the version.sh script:
>>
>> [root@beaglebone]> ./version.sh
>> git:/opt/scripts/:[d36fe9a7be9ebfc872b10a470e904ab4c61c4516]
>> eeprom:[A335BNLT00C00515BBBK0825]
>> dogtag:[BeagleBoard.org Debian Image 2017-10-10]
>> bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot
>> 2018.01-00002-g9aa111a004]
>> kernel:[4.4.91-ti-r133]
>> nodejs:[v6.11.4]
>> device-tree-override:[dtb=
>> dtb=am335x-boneblack-overlay.dtb]

This might have broke something..

>> uboot_overlay_options:[enable_uboot_overlays=1]
>>
>> uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/maps_bbb_pwm-00A0.dtbo]
>> uboot_overlay_options:[uboot_overlay_addr5=/lib/firmware/maps_bbb_eqep-00A0.dtbo]
>> uboot_overlay_options:[uboot_overlay_addr6=/lib/firmware/maps_bbb_i2c-00A0.dtbo]
>> uboot_overlay_options:[uboot_overlay_addr7=/lib/firmware/maps_bbb_gpio-00A0.dtbo]

any chance do you have a usb serial adapter you can plug into j1, so
we can what u-boot tires to do with these 4 overlay?

[lgil...@tethers.com]

"this might have broke something" --> do you mean the >> dtb=am335x-boneblack-overlay.dtb]  line?

We have ordered a serial cable, I'll get you the boot output as soon as it arrives.   Thanks so much for your help and insight on this...

[lgil...@tethers.com]

Here is the output from uBoot on boot:

U-Boot SPL 2017.09-00002-g0f3f1c7907 (Oct 09 2017 - 15:30:22)

Trying to boot from MMC2

U-Boot 2017.09-00002-g0f3f1c7907 (Oct 09 2017 - 15:30:22 -0500), Build: jenkins-github_Bootloader-Builder-607

CPU  : AM335X-GP rev 2.1

I2C:   ready

DRAM:  512 MiB

No match for driver 'omap_hsmmc'

No match for driver 'omap_hsmmc'

Some drivers were not found

Reset Source: Global external warm reset has occurred.

Reset Source: Global warm SW reset has occurred.

Reset Source: Power-on reset has occurred.

MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1

Using default environment

Board: BeagleBone Black

<ethaddr> not set. Validating first E-fuse MAC

BeagleBone Black:

BeagleBone: cape eeprom: i2c_probe: 0x54:

BeagleBone: cape eeprom: i2c_probe: 0x55:

BeagleBone: cape eeprom: i2c_probe: 0x56:

BeagleBone: cape eeprom: i2c_probe: 0x57:

Net:   eth0: MII MODE

cpsw

Press SPACE to abort autoboot in 2 seconds

board_name=[A335BNLT] ...

board_rev=[00C0] ...

switch to partitions #0, OK

mmc0 is current device

SD/MMC found on device 0

** Bad device 0:2 0x82000000 **

** Bad device 0:2 0x82000000 **

switch to partitions #0, OK

mmc0 is current device

Scanning mmc 0:1...

gpio: pin 56 (gpio 56) value is 0

gpio: pin 55 (gpio 55) value is 0

gpio: pin 54 (gpio 54) value is 0

gpio: pin 53 (gpio 53) value is 1

switch to partitions #0, OK

mmc0 is current device

gpio: pin 54 (gpio 54) value is 1

Checking for: /uEnv.txt ...

2094 bytes read in 30 ms (67.4 KiB/s)

gpio: pin 55 (gpio 55) value is 1

Loaded environment from /uEnv.txt

Importing environment from mmc ...

Checking if uenvcmd is set ...

Checking if client_ip is set ...

Checking for: /boot.scr ...

Checking for: /boot/boot.scr ...

Checking for: /boot/uEnv.txt ...

gpio: pin 55 (gpio 55) value is 1

2249 bytes read in 26 ms (84 KiB/s)

Loaded environment from /boot/uEnv.txt

debug: [dtb=am335x-boneblack-overlay.dtb] ...

Using: dtb=am335x-boneblack-overlay.dtb ...

Checking if uname_r is set in /boot/uEnv.txt...

gpio: pin 56 (gpio 56) value is 1

Running uname_boot ...

loading /boot/vmlinuz-4.4.91-ti-r133 ...

8886912 bytes read in 579 ms (14.6 MiB/s)

uboot_overlays: dtb=am335x-boneblack-overlay.dtb in /boot/uEnv.txt, unable to use [uboot_base_dtb=am335x-boneblack-uboot.dtb] ...

loading /boot/dtbs/4.4.91-ti-r133/am335x-boneblack-overlay.dtb ...

54603 bytes read in 85 ms (627 KiB/s)

uboot_overlays: [fdt_buffer=0x60000] ...

uboot_overlays: loading /lib/firmware/AM335X-20-00A0.dtbo ...

378 bytes read in 202 ms (1000 Bytes/s)

uboot_overlays: loading /lib/firmware/maps_bbb-00A0.dtbo ...

3180 bytes read in 399 ms (6.8 KiB/s)

uboot_overlays: uboot loading of [/lib/firmware/BB-BONE-eMMC1-01-00A0.dtbo] disabled by /boot/uEnv.txt [disable_uboot_overlay_emmc=1]...

uboot_overlays: uboot loading of [/lib/firmware/BB-HDMI-TDA998x-00A0.dtbo] disabled by /boot/uEnv.txt [disable_uboot_overlay_video=1]...

uboot_overlays: uboot loading of [/lib/firmware/BB-ADC-00A0.dtbo] disabled by /boot/uEnv.txt [disable_uboot_overlay_adc=1]...

uboot_overlays: loading /lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo ...

2402 bytes read in 356 ms (5.9 KiB/s)

uboot_overlays: cape universal disabled, external cape enabled or detected...

loading /boot/initrd.img-4.4.91-ti-r133 ...

5416133 bytes read in 361 ms (14.3 MiB/s)

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

debug: [bootz 0x82000000 0x88080000:52a4c5 88000000] ...

## Flattened Device Tree blob at 88000000

   Booting using the fdt blob at 0x88000000

   Loading Ramdisk to 8fad5000, end 8ffff4c5 ... OK

   reserving fdt memory region: addr=88000000 size=6e000

   Loading Device Tree to 8fa64000, end 8fad4fff ... OK

Starting kernel ...

[    0.000823] clocksource_probe: no matching clocksources found

[    2.078244] wkup_m3_ipc 44e11324.wkup_m3_ipc: could not get rproc handle

[    2.250286] omap_voltage_late_init: Voltage driver support not added

[    2.258432] PM: Cannot get wkup_m3_ipc handle

[    2.329057] pinctrl-single 44e10800.pinmux: pin 44e10978.0 already requested by ocp:helper; cannot claim for 4819c000.i2c

[    2.340162] pinctrl-single 44e10800.pinmux: pin-94 (4819c000.i2c) status -22

[    2.347268] pinctrl-single 44e10800.pinmux: could not request pin 94 (44e10978.0) from group pinmux_i2c2_pins  on device pinctrl-single

[    2.359512] omap_i2c 4819c000.i2c: Error applying setting, reverse things back

Debian GNU/Linux 9 beaglebone ttyS0

BeagleBoard.org Debian Image 2017-10-10

Support/FAQ: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian

On Tuesday, March 20, 2018 at 6:02:57 PM UTC-7, RobertCNelson wrote:

[lgil...@tethers.com]

Sorry, please disregard the uBoot output posted previously--that was with our workaround of loading one big dtbo file.  

HERE IS THE OUTPUT FROM OUR MULTIPLE DTBOs...

U-Boot SPL 2018.01-00002-g9aa111a004 (Jan 20 2018 - 12:45:29)

Trying to boot from MMC1

U-Boot 2018.01-00002-g9aa111a004 (Jan 20 2018 - 12:45:29 -0600), Build: jenkins-github_Bootloader-Builder-32

CPU  : AM335X-GP rev 2.1

I2C:   ready

DRAM:  512 MiB

No match for driver 'omap_hsmmc'

No match for driver 'omap_hsmmc'

Some drivers were not found

Reset Source: Power-on reset has occurred.

MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1

Using default environment

Board: BeagleBone Black

<ethaddr> not set. Validating first E-fuse MAC

BeagleBone Black:

BeagleBone: cape eeprom: i2c_probe: 0x54:

BeagleBone: cape eeprom: i2c_probe: 0x55:

BeagleBone: cape eeprom: i2c_probe: 0x56:

BeagleBone: cape eeprom: i2c_probe: 0x57:

Net:   eth0: MII MODE

cpsw, usb_ether

2246 bytes read in 28 ms (78.1 KiB/s)

Loaded environment from /boot/uEnv.txt

debug: [dtb=am335x-boneblack-overlay.dtb] ...

Using: dtb=am335x-boneblack-overlay.dtb ...

Checking if uname_r is set in /boot/uEnv.txt...

gpio: pin 56 (gpio 56) value is 1

Running uname_boot ...

loading /boot/vmlinuz-4.4.91-ti-r133 ...

8886912 bytes read in 579 ms (14.6 MiB/s)

uboot_overlays: dtb=am335x-boneblack-overlay.dtb in /boot/uEnv.txt, unable to use [uboot_base_dtb=am335x-boneblack-uboot.dtb] ...

loading /boot/dtbs/4.4.91-ti-r133/am335x-boneblack-overlay.dtb ...

54603 bytes read in 84 ms (634.8 KiB/s)

uboot_overlays: [fdt_buffer=0x60000] ...

uboot_overlays: loading /lib/firmware/maps_bbb_gpio-00A0.dtbo ...

1039 bytes read in 145 ms (6.8 KiB/s)

uboot_overlays: loading /lib/firmware/maps_bbb_pwm-00A0.dtbo ...

1599 bytes read in 296 ms (4.9 KiB/s)

uboot_overlays: loading /lib/firmware/maps_bbb_i2c-00A0.dtbo ...

1312 bytes read in 300 ms (3.9 KiB/s)

uboot_overlays: loading /lib/firmware/maps_bbb_eqep-00A0.dtbo ...

2055 bytes read in 396 ms (4.9 KiB/s)

uboot_overlays: uboot loading of [/lib/firmware/BB-BONE-eMMC1-01-00A0.dtbo] disabled by /boot/uEnv.txt [disable_uboot_overlay_emmc=1]...

uboot_overlays: uboot loading of [/lib/firmware/BB-HDMI-TDA998x-00A0.dtbo] disabled by /boot/uEnv.txt [disable_uboot_overlay_video=1]...

uboot_overlays: uboot loading of [/lib/firmware/BB-ADC-00A0.dtbo] disabled by /boot/uEnv.txt [disable_uboot_overlay_adc=1]...

uboot_overlays: loading /lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo ...

2402 bytes read in 356 ms (5.9 KiB/s)

uboot_overlays: cape universal disabled, external cape enabled or detected...

loading /boot/initrd.img-4.4.91-ti-r133 ...

5416133 bytes read in 361 ms (14.3 MiB/s)

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

debug: [bootz 0x82000000 0x88080000:52a4c5 88000000] ...

## Flattened Device Tree blob at 88000000

   Booting using the fdt blob at 0x88000000

   Loading Ramdisk to 8fad5000, end 8ffff4c5 ... OK

   reserving fdt memory region: addr=88000000 size=6e000

   Loading Device Tree to 8fa64000, end 8fad4fff ... OK

Starting kernel ...

[    0.000833] clocksource_probe: no matching clocksources found

[    2.077791] wkup_m3_ipc 44e11324.wkup_m3_ipc: could not get rproc handle

[    2.249328] omap_voltage_late_init: Voltage driver support not added

[    2.257414] PM: Cannot get wkup_m3_ipc handle

Debian GNU/Linux 9 beaglebone ttyS0

BeagleBoard.org Debian Image 2017-10-10

Support/FAQ: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian

default username:password is [debian:temppwd]

beaglebone login: root

Password:

Last login: Mon Mar 26 15:39:43 PDT 2018 from 172.23.49.123 on pts/0

Linux beaglebone 4.4.91-ti-r133 #1 SMP Tue Oct 10 05:18:08 UTC 2017 armv7l

The programs included with the Debian GNU/Linux system are free software;

the exact distribution terms for each program are described in the

individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent

permitted by applicable law.

[Robert Nelson]

Okay these loaded fine..

Everything looks good, if the nodes arn't showing up, can you share
the 4 overlays source?

[lgil...@tethers.com]

They are a bit large to post as source.   I'll try attaching them...

[William Hermans]

I've noticed that sometimes the order in which you load device files can play a factor on if they will load or not. May be worth checking out.

--

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/4271bd0c-3625-43f9-b68b-5377e3abb155%40googlegroups.com.

[lgil...@tethers.com]

I attached the dts files to a reply, did you get a chance to look at them?

best,

Leo

On Monday, March 26, 2018 at 6:27:56 PM UTC-7, RobertCNelson wrote: