Using a device table overlay to disable the onboard RTC on the beaglebone black

[Tim Small]

Since the Beaglebone Black RTC is not usable (I believe due to a hw bug), I'm using an external RTC chip (A Maxim / Dallas DS1338 on i2c2 at address 0x68), and informing the kernel about this using a device tree overlay.

I'm also disabling the onboard RTC using a (currently separate) device tree overlay, this is because otherwise the omap rtc gets enumerated first which leaves the kernel time starting at jan 1st 2000 on cold boot.  The onboard rtc ends up being /dev/rtc0 (which is linked to by /dev/rtc) and ntpd does its clock drift adjustment vs this rtc-with-no-battery-backup etc. - it seemed best to just disable it, since I have another one which is actually battery-backed.

This seem to work, but I wanted to check that there wasn't some other functionality I'd be harming by doing this?

If anyone is familiar with device tree overlays, I would also appreciate a review of these:

Firstly BB-DS1388-I2C2-68.dts - which I compile with:

dtc -W no-unit_address_vs_reg -@ -I dts -O dtb -o BB-DS1388-I2C2-68-00A0.dtbo BB-DS1388-I2C2-68.dts

/dts-v1/;
/plugin/;

/ {

 compatible = "ti,beaglebone", "ti,beaglebone-black";
 part-number = "BB-DS1388-I2C2-68";
 version = "00A0";

 fragment@0 {
   target = <&i2c2>;

   __overlay__ {
     #address-cells = <1>;
     #size-cells = <0>;
     pinctrl-0 = <&i2c2_pins>;

     clock-frequency = <100000>;
     status = "okay";

     capertc: rtc@68 { /* Real time clock defined as a child of the i2c2 bus */
       compatible = "maxim,ds1338";
       #address-cells = <1>;
       #size-cells = <0>;
       reg = <0x68>;
     };
   };
 };
};

Secondly to disable the onboard RTC - BB-NO-OMAP-RTC.dts 

dtc -W no-unit_address_vs_reg -@ -I dts -O dtb -o BB-NO-OMAP-RTC-00A0.dtbo BB-NO-OMAP-RTC.dts

/dts-v1/;
/plugin/;

/ {

 compatible = "ti,beaglebone", "ti,beaglebone-black";
 part-number = "BB-NO-OMAP-RTC";
 version = "00A0";

 fragment@0 {
   target = <&rtc>;

   __overlay__ {
     status = "disabled";

   };
 };
};

Any feedback welcome!

Thanks,

Tim.

[Robert Nelson]

On Fri, Aug 25, 2017 at 4:15 AM, Tim Small <t...@seoss.co.uk> wrote:
> Since the Beaglebone Black RTC is not usable (I believe due to a hw bug),
> I'm using an external RTC chip (A Maxim / Dallas DS1338 on i2c2 at address
> 0x68), and informing the kernel about this using a device tree overlay.

Correct, without a battery it's pretty useless. ;)

>
> I'm also disabling the onboard RTC using a (currently separate) device tree
> overlay, this is because otherwise the omap rtc gets enumerated first which
> leaves the kernel time starting at jan 1st 2000 on cold boot. The onboard
> rtc ends up being /dev/rtc0 (which is linked to by /dev/rtc) and ntpd does
> its clock drift adjustment vs this rtc-with-no-battery-backup etc. - it
> seemed best to just disable it, since I have another one which is actually
> battery-backed.
>
> This seem to work, but I wanted to check that there wasn't some other
> functionality I'd be harming by doing this?
>
> If anyone is familiar with device tree overlays, I would also appreciate a
> review of these:

Your overlays look good, have you tried combining them into one file?

If it works fine as one file (BB-I2C2-DS1388-00A0.dts) , can you
submit a pull request for:

https://github.com/beagleboard/bb.org-overlays/tree/master/src/arm

and i'll push it out for all users. ;)

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...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/7ef68dd1-e7c5-49f5-9e4d-32ea021c336b%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



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

[Greg]

I think that is what I am looking for to replace the typical "hack" solution I found described in a few places with a search.

The hack solution uses a systemd service and a script to force the system clock to the value read from the hardware clock rtc1 shortly after boot.

This works, somewhat, but I noticed the hwclock was drifting several seconds per day, even after connecting the board to the internet with network time

and allowing the drift adjustment to work.  I suspected the drift adjustment is not being applied to the external clock rtc1.

Note that there is a kernel option to change the hardware clock to rtc1.  The default is of course rtc0.  So if you are building or re-building the kernel this would be the easiest solution.

I'll try your device tree fragments soon and report what happens.  Thanks for the work on this, the clock drift problem is the last piece of one of my projects still not resolved.

Regards,

Greg

[Tim Small]

On 25/08/17 19:40, Robert Nelson wrote:
> Your overlays look good, have you tried combining them into one file?
>
> If it works fine as one file (BB-I2C2-DS1388-00A0.dts) , can you
> submit a pull request for:
>
> https://github.com/beagleboard/bb.org-overlays/tree/master/src/arm
>
> and i'll push it out for all users. ;)

Thanks Robert,

The overlays work when combined into a single file, however I've noticed
that with the onboard RTC disabled, the beaglebone black no longer
powers off.

I'm guessing that the RTC is being used during shutdown? I'm not sure
whether the power off code is just using the RTC to trigger the next
stage of the shutdown code, or if it's actually used to trigger the HW
shutdown sequence directly. If the former then perhaps it would work OK
with the ds1338 if it was available earlier in the boot sequence?

Any ideas, and if waiting for ds1338 init is the answer how to arrange
for that?

If omap rtc is essential to the shutdown sequence, then I suppose I'll
see if I can either set the ds1338 to be /dev/rtc0 or just get linked to
/dev/rtc e.g. using udev?



When the 'poweroff' command is issued, then I get:

omap_rtc disabled at boot:

[ 3.788171] bone_capemgr bone_capemgr: initialized OK.
[ 3.800527] PM: rtc0 not available
[ 3.805005] hctosys: unable to open rtc device (rtc0)
...
[ 4.856569] rtc-ds1307 2-0068: rtc core: registered ds1338 as rtc0
[ 4.900682] rtc-ds1307 2-0068: 56 bytes nvram
[ 4.934936] PM: bootloader does not support rtc-only!
...
[ 7.036492] systemd[1]: System time before build time, advancing clock.

omap_rtc disabled at poweroff:

[ 57.328742] systemd-shutdown[1]: Powering off.
...
[ 57.378562] reboot: System halted
<remains powered>



omap_rtc NOT disabled (ds1338 also enabled) - at boot:

[ 3.365041] omap_rtc 44e3e000.rtc: already running
[ 3.370543] omap_rtc 44e3e000.rtc: rtc core: registered 44e3e000.rtc
as rtc0
...
[ 3.800087] bone_capemgr bone_capemgr: initialized OK.
[ 3.812568] PM: bootloader does not support rtc-only!
...
[ 3.819111] omap_rtc 44e3e000.rtc: setting system clock to 2017-09-11
12:55:47 UTC
[ 4.865031] rtc-ds1307 2-0068: rtc core: registered ds1338 as rtc1
[ 4.894450] rtc-ds1307 2-0068: 56 bytes nvram
...

omap_rtc NOT disabled - at 'poweroff':

[ 53.181208] systemd-shutdown[1]: Powering off.
...
[ 53.231249] reboot: Power down
[ 53.234626] System will go to power_off state in approx. 1 second
<power actually turns off>


Cheers,

Tim.

--
South East Open Source Solutions Limited
Registered in England and Wales with company number 06134732.
Registered Office: 2 Powell Gardens, Redhill, Surrey, RH1 1TQ
VAT number: 900 6633 53 http://seoss.co.uk/ +44-(0)1273-808309

[Tim Small]

On 11/09/17 15:03, Tim Small wrote:
> perhaps it would work OK
> with the ds1338 if it was available earlier in the boot sequence?
>
> Any ideas, and if waiting for ds1338 init is the answer how to arrange
> for that?

To answer my own question, in the debug messages I posted earlier the
ds1338 was getting initialised late because the kernel which I was using
at the time had the driver (rtc-ds1307) built as a module.

Using a kernel with the ds13xx driver built-in instead gets more sane
RTC behaviour, but still results in the shutdown code halting the system
instead of attempting a power off.

[Robert Nelson]

On Mon, Sep 11, 2017 at 9:35 AM, Tim Small <t...@seoss.co.uk> wrote:
> On 11/09/17 15:03, Tim Small wrote:
>> perhaps it would work OK
>> with the ds1338 if it was available earlier in the boot sequence?
>>
>> Any ideas, and if waiting for ds1338 init is the answer how to arrange
>> for that?
>
> To answer my own question, in the debug messages I posted earlier the
> ds1338 was getting initialised late because the kernel which I was using
> at the time had the driver (rtc-ds1307) built as a module.
>
> Using a kernel with the ds13xx driver built-in instead gets more sane
> RTC behaviour, but still results in the shutdown code halting the system
> instead of attempting a power off.

Hi Tim,

Yeah, shutdown is tied to the built-in rtc..

I'm thinking we need to do something like here in the Jetson, and add
a rtc aliases:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/tegra124-jetson-tk1.dts?h=v4.13#n12

Regards,

[Tim Small]

On 11/09/17 15:50, Robert Nelson wrote:
> I'm thinking we need to do something like here in the Jetson, and add
> a rtc aliases:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/tegra124-jetson-tk1.dts?h=v4.13#n12

Thanks Robert - much appreciated...

I found this -
http://developer.toradex.com/device-tree-customization#aliases - which
concurs. As far as I can tell unfortunately it doesn't seem possible to
dynamically add new aliases using a device tree overlay (yet?), so
that'll mean recompiling the main device tree instead I think.

Does that sound right?

I find any other way of forcing /ocp/rtc@44e3e00 to be rtc1 at least,
but I could easily be missing something of course.

Cheers,

Tim.

[Robert Nelson]

I'm close (using a pcf8523)

root@beaglebone:~# uname -r
4.9.49-ti-r58

root@beaglebone:~# dmesg | grep rtc
[ 2.428569] omap_rtc 44e3e000.rtc: already running
[ 2.429071] omap_rtc 44e3e000.rtc: rtc core: registered 44e3e000.rtc as rtc0
[ 2.649410] rtc-pcf8523 2-0068: /aliases ID 0 not available
[ 2.650843] rtc-pcf8523 2-0068: rtc core: registered rtc-pcf8523 as rtc1
[ 2.693786] PM: bootloader does not support rtc-only!
[ 2.694815] omap_rtc 44e3e000.rtc: setting system clock to
2017-09-11 20:09:40 UTC (1505160580)

https://github.com/RobertCNelson/bb.org-overlays/blob/rtc-hacks/src/arm/BB-I2C2-PCF8523-00A0.dts

for some reason, it still gave rtc0 to omap...

[Robert Nelson]

> I'm close (using a pcf8523)
>
> root@beaglebone:~# uname -r
> 4.9.49-ti-r58
>
> root@beaglebone:~# dmesg | grep rtc
> [ 2.428569] omap_rtc 44e3e000.rtc: already running
> [ 2.429071] omap_rtc 44e3e000.rtc: rtc core: registered 44e3e000.rtc as rtc0
> [ 2.649410] rtc-pcf8523 2-0068: /aliases ID 0 not available
> [ 2.650843] rtc-pcf8523 2-0068: rtc core: registered rtc-pcf8523 as rtc1
> [ 2.693786] PM: bootloader does not support rtc-only!
> [ 2.694815] omap_rtc 44e3e000.rtc: setting system clock to
> 2017-09-11 20:09:40 UTC (1505160580)
>
> https://github.com/RobertCNelson/bb.org-overlays/blob/rtc-hacks/src/arm/BB-I2C2-PCF8523-00A0.dts
>
> for some reason, it still gave rtc0 to omap...

one kinda crazy idea... we know am335x's are not battery backed up, so
what if we just specify "rtc1"

with pcf8523 plugged in:

root@beaglebone:~# dmesg | grep rtc

[ 1.982270] omap_rtc 44e3e000.rtc: rtc core: registered 44e3e000.rtc as rtc0
[ 2.186787] rtc-pcf8523 2-0068: rtc core: registered rtc-pcf8523 as rtc1
[ 2.229775] PM: bootloader does not support rtc-only!
[ 2.231880] rtc-pcf8523 2-0068: setting system clock to 2017-09-11
21:22:26 UTC (1505164946)

with pcf8523 not plugged in:

root@beaglebone:~# dmesg | grep rtc

[ 2.163450] omap_rtc 44e3e000.rtc: already running
[ 2.163946] omap_rtc 44e3e000.rtc: rtc core: registered 44e3e000.rtc as rtc0
[ 2.399128] PM: bootloader does not support rtc-only!
[ 2.400752] hctosys: unable to open rtc device (rtc1)

This is what i'm thinking:

diff --git a/patches/defconfig b/patches/defconfig
index ef7b6cd..6904989 100644
--- a/patches/defconfig
+++ b/patches/defconfig
@@ -5306,9 +5306,9 @@ CONFIG_RTC_LIB=y
CONFIG_RTC_MC146818_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
-CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
+CONFIG_RTC_HCTOSYS_DEVICE="rtc1"
CONFIG_RTC_SYSTOHC=y
-CONFIG_RTC_SYSTOHC_DEVICE="rtc0"
+CONFIG_RTC_SYSTOHC_DEVICE="rtc1"
# CONFIG_RTC_DEBUG is not set

#

It doesn't really break anything un-less someone has got the rtc
working, we only support am335x devices in teh "bone" branch.. for the
x15 in v4.9.x-ti, i can change the rtc aliases properly..

another option

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 48ef93dc614c..64ef0b3cd412 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -39,6 +39,7 @@
mmc0 = &mmc1;
mmc1 = &mmc2;
mmc2 = &mmc3;
+ rtc1 = &rtc;
};

root@beaglebone:~# dmesg | grep rtc

[ 2.163901] omap_rtc 44e3e000.rtc: rtc core: registered 44e3e000.rtc as rtc1
[ 2.399093] PM: rtc0 not available
[ 2.400713] omap_rtc 44e3e000.rtc: setting system clock to
2000-01-01 00:00:00 UTC (946684800)
[ 3.957096] PM: rtc0 not available
[ 3.962392] PM: rtc0 not available
[ 3.970378] PM: rtc0 not available
[ 16.068076] PM: rtc0 not available
[ 16.165198] PM: rtc0 not available

root@beaglebone:~# dmesg | grep rtc

[ 1.981765] omap_rtc 44e3e000.rtc: already running
[ 1.982253] omap_rtc 44e3e000.rtc: rtc core: registered 44e3e000.rtc as rtc1
[ 2.190782] rtc-pcf8523 2-0068: rtc core: registered rtc-pcf8523 as rtc0
[ 2.233734] PM: bootloader does not support rtc-only!
[ 2.234745] omap_rtc 44e3e000.rtc: setting system clock to
2017-09-11 21:33:41 UTC (1505165621)

[Robert Nelson]

Bingo, got it:

dmeroot@beaglebone:~# dmesg | grep rtc
[ 1.981906] omap_rtc 44e3e000.rtc: already running
[ 1.982366] omap_rtc 44e3e000.rtc: rtc core: registered 44e3e000.rtc as rtc1
[ 2.186792] rtc-pcf8523 2-0068: rtc core: registered rtc-pcf8523 as rtc0
[ 2.229750] PM: bootloader does not support rtc-only!
[ 2.231877] rtc-pcf8523 2-0068: setting system clock to 2017-09-11
21:41:08 UTC (1505166068)

Just missed a "0" on the 32bit register value:

https://github.com/RobertCNelson/bb.org-overlays/commit/946359cdf5fc6d2a0e1cbf04541116d6d0757848

[Tim Small]

Hi Robert,

Great, I've got that working (without hacking the main device table)
based on your example - much appreciated. I'd tried something similar
but had slipped up by putting the aliases definition at the top level,
instead of inside an __overlay__ within its own fragment.

I'd be happy to create a pull request if you think it would be useful?

Tim.

[Robert Nelson]

On Tue, Sep 12, 2017 at 3:36 AM, Tim Small <t...@seoss.co.uk> wrote:
> Hi Robert,
>
> Great, I've got that working (without hacking the main device table)
> based on your example - much appreciated. I'd tried something similar
> but had slipped up by putting the aliases definition at the top level,
> instead of inside an __overlay__ within its own fragment.
>
> I'd be happy to create a pull request if you think it would be useful?

Yeap, please submit it.

I'm also cleaning up the other RTC example in the git tree to use the aliases,.

[ferdster]

Hi,

I'm running the "Debian 9.3 2018-01-28 4GB SD IoT" image and added a PCF8523 RTC to the i2c2 bus. Specifically, I am working with this board from Adafruit:

https://www.adafruit.com/product/3295

Everything works fine manually:

config-pin P9_19 i2c

config-pin P9_20 i2c

echo pcf8523 0x68 > /sys/class/i2c-adapter/i2c-2/new_device

    [  473.652063] rtc-pcf8523 2-0068: rtc core: registered rtc-pcf8523 as rtc1

    [  473.663924] i2c i2c-2: new_device: Instantiated device pcf8523 at 0x68

hwclock -w -f /dev/rtc1

hwclock -r -f /dev/rtc1

2018-02-20 22:04:30.521921+0000

I wanted to have it come up automatically by using the BB-I2C2-PCF8523-00A0.dts as mentioned in this thread, but that causes 'config-pin' to stop working for setting up my other pins. I think this has something to do with the universal overlay now being disabled? What is the correct way to get all this working together?

Thanks.

[Robert Nelson]

I've been working on this for a few weeks. While it isn't 100% ready,
it's ready for what you just asked here ^...

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

Step 1: Install this version of U-Boot:

sudo /opt/scripts/tools/developers/update_bootloader.sh --beta

Step 2: Install this kernel:

sudo /opt/scripts/tools/update_kernel.sh --bone-channel --exp

Step 3: Update Overlays:

cd /opt/source/bb.org-overlays/
git pull
make
sudo make install

Step 4: Add Overlay to /boot/uEnv.txt

uboot_overlay_addr0=/lib/firmware/BB-I2C2-PCF8523-00A0.dtbo

(or whatever addrX)

Step 5: Reboot

sudo reboot

Step 6: Verify these 3 things:

sudo /opt/scripts/tools/version.sh | grep bootloader
dmesg | grep rtc
ls /sys/devices/platform/ocp/ | grep pinmux

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

[ferdster]

Can't boot back after step 5. I am running from eMMC, if that makes a difference. 

U-Boot SPL 2018.03-rc2-00002-ged1e504391 (Feb 16 2018 - 15:02:58 -0600)

Trying to boot from MMC2

MMC: block number 0x1 exceeds max(0x0)

MMC: block number 0x1 exceeds max(0x0)

MMC: block number 0x44 exceeds max(0x0)

MMC: block number 0x301 exceeds max(0x0)

mmc_load_image_raw_sector: mmc block read error

** Partition 1 not valid on device 1 **

spl_register_fat_device: fat register err - -1

spl_load_image_fat: error reading image u-boot.img, err - -1

spl: no partition table found

SPL: failed to boot from all boot devices

### ERROR ### Please RESET the board ###

I'll re-image tomorrow and will reboot after each step, but I assume it was upgrading the bootloader in step 1.

Thanks.

[Robert Nelson]

On Tue, Feb 20, 2018 at 6:54 PM, ferdster <ftja...@gmail.com> wrote:
> Can't boot back after step 5. I am running from eMMC, if that makes a
> difference.
>
> U-Boot SPL 2018.03-rc2-00002-ged1e504391 (Feb 16 2018 - 15:02:58 -0600)
> Trying to boot from MMC2
> MMC: block number 0x1 exceeds max(0x0)
> MMC: block number 0x1 exceeds max(0x0)
> MMC: block number 0x44 exceeds max(0x0)
> MMC: block number 0x301 exceeds max(0x0)
> mmc_load_image_raw_sector: mmc block read error
> ** Partition 1 not valid on device 1 **
> spl_register_fat_device: fat register err - -1
> spl_load_image_fat: error reading image u-boot.img, err - -1
> spl: no partition table found
> SPL: failed to boot from all boot devices
> ### ERROR ### Please RESET the board ###
>
> I'll re-image tomorrow and will reboot after each step, but I assume it was
> upgrading the bootloader in step 1.

Cool, haven't tested rc2 with the eMMC yet, i'll debug that tomorrow..

[Robert Nelson]

Okay, it "looks" like this was fixed in rc3:

Blue, eMMC boot..

U-Boot SPL 2018.03-rc3-00002-g97c27b4ee5 (Feb 20 2018 - 20:15:25 -0600)

Trying to boot from MMC2

U-Boot 2018.03-rc3-00002-g97c27b4ee5 (Feb 20 2018 - 20:15:25 -0600),
Build: jenkins-github_Bootloader-Builder-38

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 warm SW reset has occurred.
Reset Source: Power-on reset has occurred.
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Board: BeagleBone Black
<ethaddr> not set. Validating first E-fuse MAC
BeagleBone Black:
Model: BeagleBoard.org BeagleBone Blue:

Next i'm going to upgrade test my BBB farm, so let's see how many
don't come up..

[Robert Nelson]

all 19 units came back up..

[ferdster]

Now it won't boot after upgrading the kernel in step 2 (still running off eMMC):

Loading, please wait...

starting version 232

[    3.031626] usb 1-1: new high-speed USB device number 2 using musb-hdrc

[    3.193198] usb 1-1: New USB device found, idVendor=05e3, idProduct=0610

[    3.200011] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0

[    3.207193] usb 1-1: Product: USB2.0 Hub

[    3.231002] hub 1-1:1.0: USB hub found

[    3.239646] hub 1-1:1.0: 4 ports detected

Begin: Loading essential drivers ... done.

Begin: Running /scripts/init-premount ... done.

Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.

Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems

done.

Begin: Waiting for root file system ... Begin: Running /scripts/local-block ... done.

Begin: Running /scripts/local-block ... done.

Begin: Running /scripts/local-block ... done.

Begin: Running /scripts/local-block ... done.

Begin: Running /scripts/local-block ... done.

Begin: Running /scripts/local-block ... done.

Begin: Running /scripts/local-block ... done.

Begin: Running /scripts/local-block ... done.

Begin: Running /scripts/local-block ... done.

Begin: Running /scripts/local-block ... done.

Begin: Running /scripts/local-block ... done.

Begin: Running /scripts/local-block ... done.

Begin: Running /scripts/local-block ... done.

Begin: Running /scripts/local-block ... done.

Begin: Running /scripts/local-block ... done.

Begin: Running /scripts/local-block ... done.

Begin: Running /scripts/local-block ... done.

Begin: Running /scripts/local-block ... done.

Begin: Running /scripts/local-block ... done.

Begin: Running /scripts/local-block ... done.

Begin: Running /scripts/local-block ... done.

Begin: Running /scripts/local-block ... done.

Begin: Running /scripts/local-block ... done.

Begin: Running /scripts/local-block ... done.

Begin: Running /scripts/local-block ... done.

Begin: Running /scripts/local-block ... done.

Begin: Running /scripts/local-block ... done.

Begin: Running /scripts/local-block ... done.

Begin: Running /scripts/local-block ... done.

Begin: Running /scripts/local-block ... done.

done.

Gave up waiting for root file system device.  Common problems:

 - Boot args (cat /proc/cmdline)

   - Check rootdelay= (did the system wait long enough?)

 - Missing modules (cat /proc/modules; ls /dev)

ALERT!  /dev/mmcblk1p1 does not exist.  Dropping to a shell!

BusyBox v1.22.1 (Debian 1:1.22.0-19+b3) built-in shell (ash)

Enter 'help' for a list of built-in commands.

(initramfs)

Thanks.

[Robert Nelson]

That's odd, can you plug in a usb serial and grab this section of u-boot:

loading /boot/vmlinuz-4.16.0-rc2-bone3 ...
10183168 bytes read in 672 ms (14.5 MiB/s)
uboot_overlays: [uboot_base_dtb=am335x-boneblue.dtb] ...
uboot_overlays: Switching too: dtb=am335x-boneblue.dtb ...
loading /boot/dtbs/4.16.0-rc2-bone3/am335x-boneblue.dtb ...
51263 bytes read in 43 ms (1.1 MiB/s)
uboot_overlays: [fdt_buffer=0x60000] ...
uboot_overlays: loading /lib/firmware/BB-ADC-00A0.dtbo ...
695 bytes read in 262 ms (2 KiB/s)
uboot_overlays: loading /lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo ...
2402 bytes read in 277 ms (7.8 KiB/s)
loading /boot/initrd.img-4.16.0-rc2-bone3 ...
3865578 bytes read in 276 ms (13.4 MiB/s)
debug: [console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1
root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M
net.ifnames=0 quiet] ...
debug: [bootz 0x82000000 0x88080000:3afbea 88000000] ...
## Flattened Device Tree blob at 88000000
Booting using the fdt blob at 0x88000000
Loading Ramdisk to 8fc50000, end 8ffffbea ... OK
reserving fdt memory region: addr=88000000 size=6d000
Loading Device Tree to 8fbe0000, end 8fc4ffff ... OK

Starting kernel ...

[ferdster]

BTW, this is on a SeeedStudio Green Wireless.

loading /boot/vmlinuz-4.16.0-rc2-bone3 ...

10183168 bytes read in 659 ms (14.7 MiB/s)

uboot_overlays: [uboot_base_dtb=am335x-boneblack-uboot-univ.dtb] ...

uboot_overlays: Switching too: dtb=am335x-boneblack-uboot-univ.dtb ...

loading /boot/dtbs/4.16.0-rc2-bone3/am335x-boneblack-uboot-univ.dtb ...

156503 bytes read in 41 ms (3.6 MiB/s)

uboot_overlays: [fdt_buffer=0x60000] ...

uboot_overlays: loading /lib/firmware/BB-BONE-eMMC1-01-00A0.dtbo ...

1105 bytes read in 50 ms (21.5 KiB/s)

uboot_overlays: loading /lib/firmware/BB-BBGW-WL1835-00A0.dtbo ...

4681 bytes read in 111 ms (41 KiB/s)

uboot_overlays: loading /lib/firmware/BB-ADC-00A0.dtbo ...

695 bytes read in 41 ms (15.6 KiB/s)

loading /boot/initrd.img-4.16.0-rc2-bone3 ...

4459001 bytes read in 303 ms (14 MiB/s)

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

debug: [bootz 0x82000000 0x88080000:4409f9 88000000] ...

## Flattened Device Tree blob at 88000000

   Booting using the fdt blob at 0x88000000

   Loading Ramdisk to 8fbbf000, end 8ffff9f9 ... OK

   reserving fdt memory region: addr=88000000 size=87000

   Loading Device Tree to 8fb35000, end 8fbbefff ... OK

Starting kernel ...

Thanks.

[ferdster]

This is just before running the update_kernel script:

loading /boot/vmlinuz-4.9.78-ti-r94 ...

9960536 bytes read in 646 ms (14.7 MiB/s)

uboot_overlays: [uboot_base_dtb=am335x-boneblack-uboot-univ.dtb] ...

uboot_overlays: [uboot_base_dtb=am335x-boneblack-uboot.dtb] ...

uboot_overlays: Switching too: dtb=am335x-boneblack-uboot.dtb ...

loading /boot/dtbs/4.9.78-ti-r94/am335x-boneblack-uboot.dtb ...

61626 bytes read in 42 ms (1.4 MiB/s)

uboot_overlays: [fdt_buffer=0x60000] ...

uboot_overlays: loading /lib/firmware/BB-BONE-eMMC1-01-00A0.dtbo ...

1105 bytes read in 50 ms (21.5 KiB/s)

uboot_overlays: loading /lib/firmware/BB-BBGW-WL1835-00A0.dtbo ...

4681 bytes read in 111 ms (41 KiB/s)

uboot_overlays: loading /lib/firmware/BB-ADC-00A0.dtbo ...

695 bytes read in 41 ms (15.6 KiB/s)

uboot_overlays: loading /lib/firmware/univ-bbgw-EW-00A0.dtbo ...

82622 bytes read in 181 ms (445.3 KiB/s)

loading /boot/initrd.img-4.9.78-ti-r94 ...

6508361 bytes read in 426 ms (14.6 MiB/s)

debug: [console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk1p1 ro rootfstype=ext4 r                                                                                                                ootwait coherent_pool=1M net.ifnames=0] ...

debug: [bootz 0x82000000 0x88080000:634f49 88000000] ...

## Flattened Device Tree blob at 88000000

   Booting using the fdt blob at 0x88000000

   Loading Ramdisk to 8f9cb000, end 8fffff49 ... OK

   reserving fdt memory region: addr=88000000 size=83000

   Loading Device Tree to 8f945000, end 8f9cafff ... OK

Starting kernel ...

Don't know if that's the cause, but it's not loading univ-bbgw-EW-00A0.dtbo after the kernel update.

Thanks.

[Robert Nelson]

That's actually integrated into "am335x-boneblack-uboot-univ.dtb"..

Thus we just remove 'used' pinmux's.. I'm flashing that board right now..

[Robert Nelson]

Weird, booted fine here:
https://gist.github.com/RobertCNelson/836f942965fa012041c303070251143c

I used a stretch based image, what's your base image?

[ferdster]

I am using 'Debian 9.3 2018-01-28 4GB SD IoT' from here:

https://beagleboard.org/latest-images (first one on top)

I just started completely from scratch with the above base image, running from eMMC (uncommented 'init-eMMC-flasher-v3.sh' from /boot/uEnv.txt).

The only thing I did was run connmanctl to setup the wifi connection. Then I followed the first three steps from above (update u-boot, kernel, and overlays). It boots up now, but "Failed to start Load Kernel Modules."

I attached the complete boot log.

Thanks.

[Robert Nelson]

Oh, your good so far, that's something with 4.16.x-rcX, just ignore it for now..

You should be able to add:

uboot_overlay_addr0=/lib/firmware/BB-I2C2-PCF8523-00A0.dtbo

to /boot/uEnv.txt now and reboot..

[ferdster]

Yes, that seems to work to add the PCF8523 RTC, but there are some other issues.

-no more wifi (SoftAp0 or wlan0). 'ifconfig -a' only shows lo, usb0, and usb1.

-'config-pin' still does not work. For example:

    config-pin P9_24 uart

    config-pin P9_26 uart

Thanks.

[Robert Nelson]

On Wed, Feb 21, 2018 at 3:36 PM, ferdster <ftja...@gmail.com> wrote:
> Yes, that seems to work to add the PCF8523 RTC, but there are some other
> issues.

Cool

> -no more wifi (SoftAp0 or wlan0). 'ifconfig -a' only shows lo, usb0, and
> usb1.

Okay, so it's just my board here.. I'll debug some more, it's the
'overlay' for the GW, the BW works...

> -'config-pin' still does not work. For example:
> config-pin P9_24 uart
> config-pin P9_26 uart

Only gpio's are implemented, add this to get the uart working:

uboot_overlay_addr1=/lib/firmware/BB-UART1-00A0.dtbo

[ferdster]

Only gpio's are implemented

Could you clarify that because the following don't work either:

    config-pin P9_14 gpio

    config-pin P9_42 gpio

Thanks.

[Robert Nelson]

sudo apt update ; sudo apt upgrade

there's an upgraded bb-cape-overlay package

Those two pins are available:

debian@beaglebone:/sys/devices/platform/ocp$ ls | grep pinmux
ocp:P8_07_pinmux
ocp:P8_08_pinmux
ocp:P8_09_pinmux
ocp:P8_10_pinmux
ocp:P8_13_pinmux
ocp:P8_19_pinmux
ocp:P8_27_pinmux
ocp:P8_28_pinmux
ocp:P8_29_pinmux
ocp:P8_30_pinmux
ocp:P8_31_pinmux
ocp:P8_32_pinmux
ocp:P8_33_pinmux
ocp:P8_34_pinmux
ocp:P8_35_pinmux
ocp:P8_36_pinmux
ocp:P8_37_pinmux
ocp:P8_38_pinmux
ocp:P8_39_pinmux
ocp:P8_40_pinmux
ocp:P8_41_pinmux
ocp:P8_42_pinmux
ocp:P8_43_pinmux
ocp:P8_44_pinmux
ocp:P8_45_pinmux
ocp:P8_46_pinmux
ocp:P9_11_pinmux
ocp:P9_13_pinmux
ocp:P9_14_pinmux
ocp:P9_15_pinmux
ocp:P9_16_pinmux
ocp:P9_17_pinmux
ocp:P9_18_pinmux
ocp:P9_19_pinmux
ocp:P9_20_pinmux
ocp:P9_21_pinmux
ocp:P9_22_pinmux
ocp:P9_23_pinmux
ocp:P9_24_pinmux
ocp:P9_25_pinmux
ocp:P9_26_pinmux
ocp:P9_27_pinmux
ocp:P9_28_pinmux
ocp:P9_29_pinmux
ocp:P9_30_pinmux
ocp:P9_31_pinmux
ocp:P9_41_pinmux
ocp:P9_42_pinmux
ocp:P9_91_pinmux
ocp:P9_92_pinmux

[Robert Nelson]

On Wed, Feb 21, 2018 at 3:42 PM, Robert Nelson <robert...@gmail.com> wrote:
> On Wed, Feb 21, 2018 at 3:36 PM, ferdster <ftja...@gmail.com> wrote:
>> Yes, that seems to work to add the PCF8523 RTC, but there are some other
>> issues.
>
> Cool
>
>> -no more wifi (SoftAp0 or wlan0). 'ifconfig -a' only shows lo, usb0, and
>> usb1.
>
> Okay, so it's just my board here.. I'll debug some more, it's the
> 'overlay' for the GW, the BW works...

ugh, it's gpio-hog and P8_26_pinmux (Buffer Enable between the am335x
and wl1835)..

That sucks, P8_26_pinmux { status = "disabled"; }; is too late to set
it free for gpio-hog which is right away..

let's try the led option...

[ferdster]

sudo apt update ; sudo apt upgrade

there's an upgraded bb-cape-overlay package

After digging out a USB-to-Ethernet dongle for internet access, I did the upgrade and those pins now work.

Thanks.

[Robert Nelson]

Yeah, this is going to work for the BBGW at the moment, two pins need
to be set by teh gpio-hog early in bootup. However gpio-of-helper
then takes control of those pins, and wipes away the hog settings..

it looks like i need to patch gpio-of-helper to use gpiolib and then
make sure to whitelist any pins with the "hog' flag.

eta, awhile...

[Robert Nelson]

On Wed, Feb 21, 2018 at 5:01 PM, Robert Nelson <robert...@gmail.com> wrote:
> On Wed, Feb 21, 2018 at 4:38 PM, ferdster <ftja...@gmail.com> wrote:
>>> sudo apt update ; sudo apt upgrade
>>>
>>> there's an upgraded bb-cape-overlay package
>>
>> After digging out a USB-to-Ethernet dongle for internet access, I did the
>> upgrade and those pins now work.
>
> Yeah, this is going to work for the BBGW at the moment, two pins need
> to be set by teh gpio-hog early in bootup. However gpio-of-helper
> then takes control of those pins, and wipes away the hog settings..
>
> it looks like i need to patch gpio-of-helper to use gpiolib and then
> make sure to whitelist any pins with the "hog' flag.

or i could just change the bbgw "base" dtb so those pins are never
exported, thus kicking the gpiolib problem down the road a few more
years..

yeah, i'll do that... tomorrow...

[Robert Nelson]

Okay got this working this moring.. the wl_en/wl_irq pins had to be
ripped out of the cape-universal...

bb-cape-overlays:

sudo apt update ; sudo apt upgrade bb-cape-overlays

u-boot: (yes another build)

sudo /opt/scripts/tools/developers/update_bootloader.sh --beta

kernel: (4.16-rc2-bone5 building right now)

sudo /opt/scripts/tools/update_kernel.sh --bone-channel --exp

[ferdster]

Eagerly waiting to test out 4.16-rc2-bone5. Can you post here when it's out? I've been running the update_kernel.sh script every 30 minutes, but it still says the latest version is bone4.

BTW, I really appreciate all the help you have provided!

Thanks.

[Robert Nelson]

Yeah, the cron uploader job only runs a few times a day.. i just kicked it..

Files are now uploaded to the apt repo..

[ferdster]

Everything seems to work like it should. Thanks again!