**** BEGIN LOGGING AT Sat Oct 08 02:59:58 2016 Oct 08 03:00:27 yeah it doesn't matter whether you separate it or not Oct 08 03:00:46 I've tried, the kernel ignores clock nodes introduced via overlays entirely as far as I can tell Oct 08 03:01:00 like I said, probably the kernel only scans for them once during early boot Oct 08 03:01:02 oh i see Oct 08 03:01:30 sounds like I should be able to use the uEnv.txt for early boot? Oct 08 03:02:16 ? Oct 08 03:03:02 you'd need to build a customized dtb and then set your uEnv.txt to use it Oct 08 03:03:14 oh Oct 08 03:03:44 I can't use cape_enable=bone_capemgr.enable_partno Oct 08 03:03:51 that won't load it early? Oct 08 03:04:27 note that it's not particularly hard... you can either build one in the kernel tree you already have now, or there's apparently a dtb-rebuilder thingy included with the standard debian beaglebone images somewhere, never used that one though Oct 08 03:04:30 so, you can definitely tweak a loaded device-tree from u-boot ... i haven't looked into weather it's feasible to do that in a batched way... Oct 08 03:04:49 vagrantc: that's definitely not appropriate here Oct 08 03:04:57 it would be an interesting alternative to an overlay... Oct 08 03:05:33 tlab: no that's not remotely early, those are loaded by some userspace service Oct 08 03:05:36 essentially, it would be a way to build a customized device-tree via u-boot Oct 08 03:06:15 vagrantc: yes, theoretically that could be done... or you could just customize the device tree, which is definitely a lot easier than implementing what you're suggesting in u-boot Oct 08 03:07:28 what produce an entire alternate file when you just want to change a few stanzas? Oct 08 03:08:04 uh yeah? that's perfectly normal, the various am335x-boneblack dtb variants all differ only by a few fragments Oct 08 03:08:25 that's why most definitions are in shared .dtsi files Oct 08 03:11:14 you can even just #include another dts file to avoid duplication Oct 08 03:14:50 http://lxr.free-electrons.com/source/arch/arm/boot/dts/am335x-boneblack.dts?v=4.4 Oct 08 03:15:08 basically shove the tt3201 overlay into that? Oct 08 03:15:59 do use the in the -bone kernel tree though, it probably differs from the mainline one Oct 08 03:16:59 and I thought you needed one of the other variants due to pin conflict? Oct 08 03:17:03 yeah it's on my hard drive, I just don't see the git it was pulled from Oct 08 03:17:23 the kernel tree is created in the KERNEL subdirectory Oct 08 03:17:24 oh yeah, hdmi audio conflict Oct 08 03:17:38 yeah, i'm well aware of include statements ... but if i'm using a mainline kernel it seems silly to regenerate the DTB to use, for example, an LCD7 cape Oct 08 03:18:09 vagrantc: why? that's what device tree is for, describing your hardware Oct 08 03:18:12 but i guess it's a matter of preference and working code Oct 08 03:19:30 I see very little added value in overlays, especially considering the amount of frustration they're causing Oct 08 03:19:31 zmatt: an add-on seems like it should be able to be... added on, not requiring regenerating anything ... Oct 08 03:20:29 a cape isn't exactly an usb device you just plug in like that Oct 08 03:20:35 zmatt: i guess my thought was that if you implemented it in u-boot, you might be able to get teh advantage(s) of overlays without some of the user-space mess. Oct 08 03:21:16 a passing thought ... will look into it more sometime Oct 08 03:21:22 maybe, but it's not implemented right now Oct 08 03:23:16 and to be honest u-boot is already an overcomplicated piece of bloatware. I don't swap out capes every 5 minutes an I'd rather have a fast and simple boot process instead of having it merge device trees at runtime when that could have been done in advance in userspace, once instead of every boot Oct 08 03:24:44 https://github.com/beagleboard/linux/tree/4.4/arch/arm/boot/dts Oct 08 03:26:04 #define EJUKEBOX 528 Oct 08 03:26:05 ... Oct 08 03:26:11 wut Oct 08 03:26:25 where? Oct 08 03:26:42 file I linked earlier (where EPROBE_DEFER is also defined) Oct 08 03:26:59 I still had it open and noticed the definition above Oct 08 03:27:19 (yeah it does have a description, but like where the hell did that name come from) Oct 08 03:28:33 freezable_schedule_timeout_killable_unsafe(NFS_JUKEBOX_RETRY_TIME); Oct 08 03:28:46 lol this keeps getting weirder Oct 08 03:28:58 for NFSv3 Oct 08 03:29:24 maybe to mean keep playing, like a jukebox Oct 08 03:29:54 "The term “JUKEBOX” is a long standing joke in the NFS community. Oct 08 03:29:54 We kept the historical error name even though it incorrectly implies Oct 08 03:29:55 a binding to a particular HSM mechanism. Given the generic Oct 08 03:29:55 intent of the error, NFS3ERR_TMP_INACCESSIBLE would be Oct 08 03:29:57 more appropriate." Oct 08 03:30:06 whoops, sorry about the hardwrap Oct 08 03:31:31 ok, was just distracted a bit :P Oct 08 03:33:31 well later, I might work on this some more tomorrow Oct 08 12:57:05 Is there any rules/guidelines to creating a boot partition on microsd for beaglebone black? Can I just make any size? Oct 08 13:15:14 clean: you don't need any Oct 08 13:15:22 the standard images haven't used one for ages Oct 08 13:21:02 there's a special header at offset 0x20000 on the microsd followed by the MLO at 0x20200 (confusingly current u-boot produces a file named "MLO" that's actually these two things combined) and then the u-boot.img goes at offset 0x60000. This is all inbetween the partition table and the first (and usually only) partition Oct 08 13:21:13 same for eMMC btw Oct 08 13:23:28 if you do use a fat boot partition then it doesn't really have a size requirement other than being big enough to hold the MLO (without aforementioned 512-byte header) and u-boot.img, and I think it needs to be the first partition and possibly marked bootable, don't remember off the top of my head Oct 08 13:24:01 raw mmc boot (the fixed offset stuff) takes priority over a fat boot partition when both are present Oct 08 13:30:37 zmatt: thanks. I'm installing parabola, putting uboot stuff on first fat partition worked so I guess the eMMC is empty. Oct 08 13:34:40 interesting about the fixed offset stuff. What's the advantage/reasons for it? In my case I just installed the uboot-omap3_beagle package from parabola with partition 1 mounted to /boot. Then it all just worked. Oct 08 13:35:43 actually that's completely the wrong u-boot. more likely you're actually using the u-boot from eMMC but its boot script might prefer to boot the OS from μSD Oct 08 13:36:31 beagleboards (not counting the new x15) used omap3, beaglebones do not Oct 08 13:41:49 and the advantage is not needing a boot partition, and it might be less error-prone maybe or less likely to be mucked up by newbies? In theory it would also allow safer upgrades of the bootloader by having redundant copies (ROM actually checks at four fixed locations, not just one) but currently that's not taken advantage of Oct 08 13:45:40 There is a uboot-am335x_bone package which I suppose would be the right one. Oct 08 13:48:36 yes, or just grab the MLO (probably has the raw header aforementioned) and u-boot.img from https://rcn-ee.com/repos/bootloader/am335x_boneblack/ Oct 08 13:49:32 that way you at least know you have the same bootloader as most bbb users Oct 08 13:50:53 (v2016.09 is the latest non-rc version) Oct 08 13:51:58 What is rcn-ee.com? By default I trust my distro pkgs more than links, until I get more comfortable with everything for bbb. Oct 08 13:53:07 rcn is robert nelson, he builds and packages the bootloaders, kernels, and filesystem images for the beagle-family Oct 08 13:53:45 I'd generally trust his stuff more than some obscure distro Oct 08 13:53:48 for the official builds? Oct 08 13:53:50 yes Oct 08 13:54:00 yeah, you do have a point. Oct 08 13:54:26 But one package is hardly going to matter if my whole distro is untrustworthy. Oct 08 13:54:59 well the point is that probably very few people use that distro on beaglebones, so that leaves the question of how much testing their builds have seen Oct 08 13:55:47 while rcn's builds are used by default on all beaglebones hence they get a lot of real-world testing Oct 08 13:56:26 for userspace packages it is far less critical how much they've been tested on your specific hardware Oct 08 13:56:30 zmatt: true. I do like arch though, I assume rcn is Ångström linux builds? Oct 08 13:56:36 no, debian Oct 08 13:56:45 Ångström hasn't been used in ages Oct 08 13:56:49 ok Oct 08 13:57:29 I think archlinuxarm would be more widely used than parabola. They don't have any howto for bbb like parabola does, but I'm sure it's doable. Oct 08 13:57:42 Just need general armv7 support I guess? Oct 08 13:58:36 generally an armv7-hardfloat (arm-linux-gnueabihf) userspace is used yes Oct 08 13:58:51 I just missed your point entirely :S . Parabola would be fine, but with more tested kernel and bootloaders from place like rcn? Oct 08 13:59:05 so that's what h is fore. Oct 08 13:59:07 for* Oct 08 13:59:23 yeah arm-linux-gnueabi without the hf is softfloat Oct 08 14:00:15 I only know the term from my failed attempts at cross compiling. Oct 08 14:00:18 or at least softfloat calling conventions, even if code does use the fpu Oct 08 14:01:04 at least on debian cross-compiling is really easy, you just apt-get install gcc-arm-linux-gnueabihf :) Oct 08 14:03:47 and yeah I'd generally expect you can freely mix a choice of kernel+dtb with a choice of userspace, except maybe a very few kernel with an ancient userspace or vice versa will give problems Oct 08 14:03:49 zmatt: do you need to setup custom toolchain directory and env vars? Oct 08 14:04:02 no? Oct 08 14:04:57 ok Oct 08 14:05:33 you can easily build customized versions of rcn's kernels btw, just clone https://github.com/RobertCNelson/bb-kernel (pick branch for desired kernel series) and follow the readme Oct 08 14:06:04 it will actually download a cross-toolchain by default Oct 08 14:06:18 but you can override that in system.sh Oct 08 14:07:01 (ditto for the linux git repo) Oct 08 14:08:22 the equivalent repo for the -ti series kernels is https://github.com/RobertCNelson/ti-linux-kernel-dev Oct 08 14:08:37 (the naming could have been a bit more consistent) Oct 08 14:12:07 zmatt: thanks. -ti as in texas instruments kernel? Oct 09 00:30:30 zmatt, laurittr: is it just me or did they add a lot of dts here https://github.com/beagleboard/linux/tree/4.4/arch/arm/boot/dts Oct 09 02:11:42 Hi Guys Oct 09 02:12:03 I am facing problem with PRU, any one can help me Oct 09 02:53:57 Amr_: explain your problem, and if anyone knows anyhing .... Oct 09 02:54:02 oh you ***d off .. **** ENDING LOGGING AT Sun Oct 09 02:59:58 2016