**** BEGIN LOGGING AT Sat Jun 02 03:00:09 2018
Jun 02 03:59:22 <kenrestivo> so let me ask you this: if overlays are A Bad Idea (tm), then what is the correct way to specify this stuff?
Jun 02 03:59:56 <kenrestivo> i need to add two drivers: one that uses gpio-keys and another that uses gpio-of-helper
Jun 02 04:00:18 <kenrestivo> on modern kernels, loading both dtbo's panics the kernel
Jun 02 04:01:17 <kenrestivo> s/both/either/g
Jun 02 04:01:38 <kenrestivo> so i suspect it's not something wrong with the dtsi files but rather just breakage in overlays in general
Jun 02 04:26:25 <zmatt> have you tried loading them using u-boot overlays?
Jun 02 04:28:07 <zmatt> in general, the correct way is by providing the right information in the DT in the first place rather than trying to patch it at runtime.  u-boot overlays enable doing so without actually customizing the .dtb file itself
Jun 02 04:29:53 <kenrestivo> [    0.926018] gpio-of-helper ocp:cape-universal: ready
Jun 02 04:30:13 <kenrestivo> yeah, it seems to load, but i haven't figured out how to get cape-universal out of the way
Jun 02 04:30:23 <kenrestivo> [    0.925433] gpio-of-helper button-led: ready
Jun 02 04:30:38 <zmatt> ohh, you have cape-universal still enabled?  well that explains all problems
Jun 02 04:30:44 <kenrestivo> i have it off!
Jun 02 04:30:46 <kenrestivo> in uenv.txt
Jun 02 04:30:59 <kenrestivo> enable_uboot_cape_universal=0
Jun 02 04:31:06 <zmatt> you need to comment out the line
Jun 02 04:31:08 <kenrestivo> also tried commenting the whole line out
Jun 02 04:31:13 <kenrestivo> still shows up as : ready
Jun 02 04:31:16 <zmatt> =0 does the same as =1
Jun 02 04:31:27 <zmatt> all that matters is whether the variable exists
Jun 02 04:31:40 <kenrestivo> gotcha. ok, will try commenting it out *again*
Jun 02 04:32:33 <kenrestivo> i feel like sticking with the beagle instead of rasberry pi, like the people in the early 2000s who stuck with freebsd instead of moving to linux
Jun 02 04:33:08 <kenrestivo> [    0.925494] gpio-of-helper ocp:cape-universal: ready
Jun 02 04:33:13 <kenrestivo> i can't get rid of the damn thing
Jun 02 04:33:16 <kenrestivo> it won't go away
Jun 02 04:33:39 <zmatt> I'm really puzzled
Jun 02 04:33:56 <kenrestivo> https://gist.github.com/kenrestivo/e71dfc4e19a92019e96569c75b291eab
Jun 02 04:33:56 <zmatt> are you booting from eMMC or sd card?
Jun 02 04:34:25 <kenrestivo> internal flash
Jun 02 04:34:35 <kenrestivo> there's no sdcard present
Jun 02 04:35:00 <kenrestivo> version.sh is pretty awesome, by the way. glad i discoverd it
Jun 02 04:35:24 <kenrestivo> would love to know what pkg: means
Jun 02 04:35:41 <kenrestivo> ah, dpkg, nevermind
Jun 02 04:36:36 <kenrestivo> but now at least it makes sense the kernel panics at dtbo load
Jun 02 04:36:45 <kenrestivo> it's teh capemgr THAT WOULD NOT DIE
Jun 02 04:37:20 <zmatt> yeah but it doesn't make sense that cape-universal is stubbornly remaining enabled
Jun 02 04:37:51 <kenrestivo> what is "ocp"?
Jun 02 04:38:40 <kenrestivo> do i have a dodgy uboot perhaps?
Jun 02 04:39:39 <zmatt> open core protocol, referring to the connection to the rest of the SoC, i.e. referring to the peripherals
Jun 02 04:40:00 <zmatt> (which also means cape-universal absolutely does not belong there, but people incorrectly toss all sorts of random crap into the ocp node)
Jun 02 04:42:52 <kenrestivo> updated uboot. still same problem. cape-universal WILL NOT DIE
Jun 02 04:43:56 <kenrestivo> is there a disable_cape_universal ?
Jun 02 04:44:09 <zmatt> yes, the absence of enable
Jun 02 04:44:19 <kenrestivo> lies.
Jun 02 04:44:46 <kenrestivo> where would i expect this bug to live?
Jun 02 04:44:48 <zmatt> also it gets implicitly disabled when u-boot loads overlays (whether due to cape-autodetection or explicit request)
Jun 02 04:44:50 <kenrestivo> in u-boot itself?
Jun 02 04:45:09 <zmatt> I have no clue, this is the first time I've seen or heard of cape-universal refusing to die
Jun 02 04:45:10 <kenrestivo> it's happening before kernel load time?
Jun 02 04:45:13 <zmatt> yes
Jun 02 04:45:23 <kenrestivo> maybe a serial console into uboot and i can poke around
Jun 02 04:45:27 <kenrestivo> or look thru uboot source
Jun 02 04:45:33 <kenrestivo> not sure what to look for though
Jun 02 04:45:36 <zmatt> checking serial console output might be useful
Jun 02 04:45:59 <zmatt> or try asking u-boot to load an overlay (even if trivial)
Jun 02 04:46:09 <kenrestivo> ok, gotta bring the uart0 pins up past the cape, or remove the cape
Jun 02 04:46:30 <zmatt> ah you have a physical cape?
Jun 02 04:46:43 <kenrestivo> i do, but it's got no eeprom on it
Jun 02 04:46:50 <kenrestivo> it's just a proto board
Jun 02 04:46:59 <kenrestivo> with a button and an led :)
Jun 02 04:47:32 <zmatt> try setting uboot_overlay_addr4 to load an overlay
Jun 02 04:47:47 <kenrestivo> in uenv.txt?
Jun 02 04:48:27 <kenrestivo> i think i know where you're going with this
Jun 02 04:49:08 <kenrestivo> the dtbo i added was in dtb_overlay not addrX
Jun 02 04:49:17 <zmatt> oh that should work too
Jun 02 04:49:24 <kenrestivo> it didn't
Jun 02 04:49:34 <kenrestivo> i mean, it did add the overlay, but it didn't whack universal
Jun 02 04:49:54 <zmatt> I'm extremely confused, it sounds like rcn broke u-boot's boot script
Jun 02 04:49:56 <kenrestivo> maybe there's a bug in uboot where the dtb_overlay doens't disable universal
Jun 02 04:50:07 <kenrestivo> that's possible, but how likely is it?
Jun 02 04:50:47 <kenrestivo> he seems like he's got his shit together, but he's just one guy (unlike the raspberriyers, who have an army of commuunity)
Jun 02 04:50:52 <zmatt> it's quite possible.  I can dig into u-boot's source code once I'm more awake
Jun 02 04:51:06 <kenrestivo> anyway, moving it to addr4 had no effect
Jun 02 04:51:17 <kenrestivo> both the custom dtbo and universal are loaded now
Jun 02 04:51:40 <kenrestivo> boot_overlay_options:[uboot_overlay_addr4=/lib/firmware/led.dtbo]
Jun 02 04:51:55 <zmatt> uboot_overlay_addr* and dtb_overlay are all equivalent
Jun 02 04:51:56 <kenrestivo> [    0.926400] gpio-of-helper ocp:cape-universal: ready
Jun 02 04:52:16 <kenrestivo> should i file a bug?
Jun 02 04:52:28 <kenrestivo> or do some uboot serial console hackery first
Jun 02 04:52:42 <kenrestivo> what kind of info would be most useful to rcn to fix the problem?
Jun 02 04:52:45 <kenrestivo> and duplicate it?
Jun 02 04:53:04 * zmatt stares blankly out of sleepy eyes
Jun 02 04:53:16 <kenrestivo> meh, it's not urgent. this is a hobby project
Jun 02 04:53:24 <kenrestivo> i'll get back to you later in the weekend or week
Jun 02 04:53:36 <zmatt> like I said, I can check for you once I'm a bit more awake
Jun 02 04:53:42 <kenrestivo> thanks
Jun 02 04:53:47 <kenrestivo> are you in germany?
Jun 02 04:53:51 <zmatt> netherlands
Jun 02 04:54:19 <kenrestivo> aye, well good morning, i guess
Jun 02 04:54:40 <kenrestivo> awfully early for a saturday morning to be hacking
Jun 02 04:55:03 <zmatt> yeah I randomly woke up
Jun 02 04:55:22 <kenrestivo> well i'm about to shutdown -h now
Jun 02 04:55:48 <kenrestivo> will check back later
Jun 02 05:04:38 <kenrestivo> i suspect it is baked into the system dtb
Jun 02 05:04:43 <kenrestivo> for the bb green
Jun 02 05:05:18 <zmatt> it shouldn't be.  when u-boot overlays are enabled, u-boot loads special -uboot versions of the dtb that exclude such crap
Jun 02 05:05:53 <zmatt> you didn't override dtb selection... right?
**** ENDING LOGGING AT Sun Jun 03 03:00:01 2018