**** BEGIN LOGGING AT Tue Sep 05 03:00:01 2017 Sep 05 13:30:47 hello. what is the "administrative password" asked in the latest debian image for the BBB? Sep 05 13:31:15 i tried temppwd and the root one (which is nothing) but it don't work Sep 05 14:49:39 mturquette: what is an "HDI" PCB? Sep 05 14:50:24 mturquette: for a simple layout, start with the BeagleBone Black Wireless or BeagleBone Blue layout which use the SIP. Sep 05 15:38:34 jkridner: Sep 05 15:38:57 http://www.epectec.com/pcb/hdi-boards.html Sep 05 15:39:06 We've resolved the issue on our side. Sep 05 16:01:46 any recommends for up to date device tree tutorials? Sep 05 16:02:04 is there a device tree tutorial for bbb that is up to date? i am using latest bbb image Linux beaglebone 4.4.54-ti-r93 Sep 05 18:26:44 i just bought the bbg. i wanted to check from where i can download bootloader sources Sep 05 20:28:24 rsv13: it looks like this is the repository containing rcn's patches and build script for u-boot -> https://github.com/RobertCNelson/Bootloader-Builder Sep 05 20:30:20 rsv13: alternatively you can just grab the mainline u-boot and apply the appropriate patch(es) from here -> https://rcn-ee.com/repos/git/u-boot-patches/ Sep 05 20:31:26 (specifically "0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch", and in recent u-boot versions also "0002-U-Boot-BeagleBone-Cape-Manager.patch") Sep 05 20:32:51 zmatt: I was not able to find the MT41K256M16TW-107 specific settings in those Sep 05 20:33:14 zarzar: "device tree tutorial" is a bit vague, do you mean just how DT works in general and how to write device tree source files? Sep 05 20:33:43 rsv13: I'll take a look in a moment Sep 05 20:38:13 zmatt: my goal is device tree overlay for bbb for uart1, spi0 (spidev1.0), and GPIO 48 and 49 for gpio Sep 05 20:38:36 rsv13: which version of u-boot are you looking at? Sep 05 20:40:54 zarzar: for overlays you may want to take a peek at my "overlay-utils" -> https://github.com/mvduin/overlay-utils it uses a perl script to convert a normal device tree snippet (in a dtsi file) to the awful format used by overlays Sep 05 20:40:59 zmatt: i found the dts files on my bbb, was going to make copies and use Sep 05 20:41:03 zmatt: https://rcn-ee.com/repos/git/u-boot-patches/v2017.07/0002-U-Boot-BeagleBone-Cape-Manager.patch Sep 05 20:41:37 rsv13: you did notice I mentioned two patches are relevant? Sep 05 20:42:13 zarzar: if you're going to modify the main dts then you're not making an overlay Sep 05 20:42:24 zmatt: should I use a device tree instead of overlay? Sep 05 20:42:37 zarzar: an overlay is a runtime patch to the device tree Sep 05 20:44:10 zmatt: i did check those patches. but i think i could not find the settings for MT41K256M16TW-107 chip Sep 05 20:44:59 so, it doesn't matter hugely... overlays could be more convenient for experimentation since it avoids recompiling the main DT (and risk not being able to boot if you somehow mess something up big time), but on the other hand overlays have really crappy diagnostics, are more limited in what you can do, and sometimes end up confusing the kernel Sep 05 20:45:05 rsv13: ok, I'll checl Sep 05 20:45:08 *check Sep 05 20:46:35 zarzar: also, for inexplicable reason, overlays have a really messy format compared to device tree fragments normally... but that's one thing I worked around in my overlay-utils project Sep 05 20:46:48 zarzar: so, take for example this -> https://github.com/mvduin/overlay-utils/blob/master/uart4.dtsi Sep 05 20:47:10 zmatt: i am running from sd card, would that make it easier to recover if i messed up the dt? Sep 05 20:47:12 zarzar: you could either #include that in the main .dts file and recompile it Sep 05 20:47:26 zarzar: of course, just change /boot/uEnv.txt back Sep 05 20:47:58 ok cool, so changing device tree is the best choice then based on your info Sep 05 20:48:01 oh, tip: do not modify existing dts files, create new ones instead (by copying some existing one, or even simpler just #include) with a different name Sep 05 20:48:08 ok Sep 05 20:48:17 which one is the main dt? Sep 05 20:49:01 this to avoid overwriting the stock dts files, which would complicate recovery and might lead to confusion further down the road Sep 05 20:49:16 depends on the device variant, but e.g. am335x-boneblack.dts Sep 05 20:49:31 oh, I was still saying Sep 05 20:49:49 so, you can either #include that uart4.dtsi example I made in your main dts Sep 05 20:50:05 or, type "make uart4.dtbo" to build an overlay from it Sep 05 20:50:23 same source works for both thanks to a bit of magic I do :) Sep 05 20:50:50 oh ok, so include, don't modify, good point Sep 05 20:51:10 include is easier for maintenance Sep 05 20:51:24 avoids having to keep merging if updates happen upstream Sep 05 20:51:43 note btw that you can always override stuff that's in the include Sep 05 20:52:14 if necessary you can even delete properties or entire nodes that were created earlier in the file Sep 05 20:52:35 include in main dts, won't that be overridden by contents of dts? Sep 05 20:52:47 contents of main dts? Sep 05 20:53:08 zarzar: so, what I mean is: create your own .dts file with a custom name, #include whatever is the default dts for your platform, then add your own additions Sep 05 20:53:34 compile that custom dts, place it in /boot/dtbs or /boot/dtbs/$uname_r Sep 05 20:53:38 oh i thought you meant include in the main dts Sep 05 20:53:57 I meant "main dts" as opposed to overlays Sep 05 20:54:56 sorry for any confusion... I don't know the best terminology either Sep 05 20:55:39 all good, if i understand correctly you are saying replace the dt with my custom dt that includes the previous dt? Sep 05 20:56:27 when your custom dtb is in place, set "dtb=custom-name.dtb" in /boot/uEnv.txt Sep 05 20:56:51 if you mess up, all you have to do is mount the card on some other system and comment out that line again Sep 05 20:57:17 oh ok Sep 05 20:58:20 at least, that's what I do and seems to me like the best way to go about it Sep 05 20:58:34 currently no overlay is included in uEnv.txt Sep 05 20:58:58 dtb= tells u-boot which file to load as main device tree, it's not related to overlays Sep 05 20:58:59 no dtbo, they are all commented out\ Sep 05 20:59:30 I don't know much about the u-boot overlays stuff, I've never really dug into it Sep 05 20:59:55 rsv13: don't worry, I haven't forgotten :) Sep 05 20:59:59 the uEnv.txt file has; #dtb= Sep 05 21:00:12 zarzar: yeah by default u-boot will pick a dtb based on detected hardware Sep 05 21:00:19 oh ok Sep 05 21:01:09 so, "u-boot overlays" refers to the (fairly new) ability of u-boot to load overlay files and patch the device tree before handing it to the kernel Sep 05 21:01:33 as opposed to how overlays normally work, which is by the kernel loading the overlay and patching the runtime representation of the device tree Sep 05 21:01:58 ok the custom dtb would be based on the existing dtb Sep 05 21:02:37 right? i'm not sure what that is though, will assume it is am335x-boneblack.dtbo Sep 05 21:02:50 if you have a normal beaglebone black then yes Sep 05 21:02:59 .dtb Sep 05 21:03:36 dts = source file, dtsi = include file, dtb = compiled dt ("blob"), dtbo = compiled overlay Sep 05 21:03:52 i ran dtc -I fs -O dts /sys/firmware/devicetree/base but it is not clear what file that displays... Sep 05 21:04:16 it's showing what u-boot gave to the kernel Sep 05 21:04:39 stored in RAM? Sep 05 21:05:29 yeah, u-boot prepares in ram: the kernel, the device tree, and (if used) the initramfs, and then jumps to the kernel (passing pointers to DT and initramfs as arguments) Sep 05 21:06:15 ok Sep 05 21:06:19 that device tree will be what it loaded from .dtb, possibly patched by some overlays (if u-boot overlays is used), and it might do some other last-minute changes I think Sep 05 21:07:37 is dts for dtb or dtbo? Sep 05 21:08:45 either Sep 05 21:09:18 so, this is an example .dts for a dtb -> https://github.com/RobertCNelson/dtb-rebuilder/blob/4.9-ti/src/arm/am335x-boneblack.dts Sep 05 21:09:32 oh ok Sep 05 21:10:33 this is one for a dtbo -> https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/beaglelogic-00A0.dts Sep 05 21:11:31 note the /plugin/ directive (line 10), and the weird structure it has (root node only contains some metadata and "fragment" nodes, each representing a patch to be done) Sep 05 21:11:58 so i need to copy the main dts, modify it, compile it, and add the include to uEnv.txt, am i missing any steps? Sep 05 21:12:29 instead of copying it you can just use the #include directive in your own dts Sep 05 21:12:44 i also need to verify the main dts is am335x-boneblack.dts/am335x-boneblack.dtb Sep 05 21:13:00 if you have a serial cable you can see u-boot's messages about what it's loading Sep 05 21:13:19 oh ok, i see, that is good Sep 05 21:13:44 wait but then there could be clonflicting sections Sep 05 21:13:52 conflicting*** Sep 05 21:13:56 no Sep 05 21:14:34 i.e. gpio 48 specified to default to gpio_pd, then in my dtb set to default to gpio_pu Sep 05 21:15:26 each section (aka fragment) of a DT source file is a patch to the tree Sep 05 21:16:00 but more than one section can path the same gpio/peripheral, right? Sep 05 21:16:12 patch*** Sep 05 21:16:21 so, &foo { x = 42; }; says: edit existing node labeled "foo" by setting property "x" to 42 (creating it if it doesn't exist, overriding the previous value if it did exist) Sep 05 21:16:51 ok, there could be numerous overrides, potentially Sep 05 21:17:12 and not only can you add/change properties and add nodes, you can even delete properties and delete nodes Sep 05 21:17:15 is it evaluated from beginning to end be fore it is applied? Sep 05 21:18:05 the compiler evaluates each fragment, then merges it into the tree Sep 05 21:20:04 oh, the compile step, ok cool Sep 05 21:20:11 dtc Sep 05 21:20:44 so how do i know what dtb my bbb is running with now/ Sep 05 21:20:48 ? Sep 05 21:21:18 is that possible to know? i guess not since it is handled by uboot Sep 05 21:21:32 checking u-boot's output via the serial console is probably the easiest way. or using knowledge of what u-boot does Sep 05 21:22:14 in the time before u-boot overlays it was pretty simple, there was one default dtb for each major beaglebone variant and that's it Sep 05 21:22:23 i have neither, i'll have to do a diff Sep 05 21:22:48 a diff? Sep 05 21:23:03 the dtc output and the dts file Sep 05 21:23:27 should match up, unless it included overlays, dang\ Sep 05 21:23:36 heh, you mean output of the decompiler? Sep 05 21:24:00 yes Sep 05 21:24:19 dtc -I fs -O dts /sys/firmware/devicetree/base Sep 05 21:24:25 tip: decompiling a compiled blob is kinda a last resort thing... the output is quite awful compared to the original sources Sep 05 21:25:33 oh, bummer Sep 05 21:26:13 no way to know then, that's kind of bummer for the device tree system Sep 05 21:26:49 I can't really blame the device tree system for that Sep 05 21:27:04 could potentially be apinful to recreate a system Sep 05 21:27:05 it's a mechanism for the bootloader to pass information about the hardware to the kernel Sep 05 21:27:35 a one way path Sep 05 21:27:36 originally the DT was actually entirely produced by the firmware/bootloader Sep 05 21:27:43 not loaded from any file Sep 05 21:28:33 dtb was just an intermediate format used to have the firmware pass it's device tree to the kernel Sep 05 21:29:01 only later someone got the idea of reusing the same thing as a file format on devices with simple stupid bootloaders :) Sep 05 21:30:00 looks like the device tree is complicated, based on /opt/source/dtb-4.9-ti/src/arm/am335x-boneblack.dts Sep 05 21:30:12 so i won't know for sure if i have the right one Sep 05 21:30:23 anyway... it would be nice if u-boot left a record somewhere of how it obtained/constructed the DT, but I guess noone bothered to do that since it's not *that* hard to figure out Sep 05 21:30:41 compiler should add it to the dtb Sep 05 21:31:03 add what? Sep 05 21:31:10 and what about the overlays? Sep 05 21:31:20 and any manual patches performed by u-boot directly? Sep 05 21:31:25 add the file name and names of the inluded files Sep 05 21:31:45 would solve it mostly Sep 05 21:32:13 could include file path and name of dts and includes Sep 05 21:32:33 not really... this is not the compiler's place. what you want to know here is what u-boot did, that's not the compiler's concern Sep 05 21:32:39 there's some stuff like that in the decompiled version already i think Sep 05 21:32:45 the file path... where the file was located when it was compiled? Sep 05 21:32:51 that sounds very useless Sep 05 21:33:03 anyway, all that isn't there :) Sep 05 21:33:04 would be useful to me right now Sep 05 21:33:49 seems odd to me that the running system doesn't have anyway to determine how it it was started Sep 05 21:34:13 it was started by u-boot conjuring a kernel, a DT, and an initramfs out of thin air Sep 05 21:34:14 anyway, i'll have to get back to it after dinner Sep 05 21:34:19 you also have no idea where it got the kernel Sep 05 21:35:19 true, but you can find out about the kernel right? maybe not Sep 05 21:35:21 (some old u-boot versions had a fun issue where you could end up booting a kernel from μSD but rootfs from eMMC... net effect being that it would seem you booted from eMMC, but with the wrong kernel) Sep 05 21:36:11 oh, yea, i read about that\ Sep 05 21:36:30 thanks for the help zmatt, very helpful, much appreciated\ Sep 05 21:36:39 hence, if you want to know.... serial console Sep 05 21:36:41 i'll be back in an hour or 2\ Sep 05 21:36:48 ok cool Sep 05 21:38:37 rsv13: oh, duh, the config doesn't actually depend on the exact ram chip used... those constants are just very badly named Sep 05 21:41:18 ehm, okay bye, you're welcome **** ENDING LOGGING AT Wed Sep 06 03:00:01 2017