**** BEGIN LOGGING AT Wed Sep 25 02:59:57 2019 Sep 25 08:47:06 Hello, are there any opengl ports for c66x cores of bb-x15? Sep 25 08:49:55 or for the same DSP cores of Beaglebone AI Sep 25 08:56:48 hello Sep 25 08:59:35 anyone know how you remove the cloud9 stuff out of the beaglebone debian builds Sep 25 10:54:41 m Sep 25 12:38:21 mrpackethead2: you can probably just remove the packages with apt, although if you want a clean/lean system you're probably better off starting with the console image and just installing things you want rather than starting with the iot image and removing things you don't want Sep 25 13:06:39 zmatt: which packages might those be, potentially?! :) [since that's usually 2/3 of the battle..] Sep 25 13:06:49 but yeah, your synopsis is indeed good :D Sep 25 13:08:11 dpkg --get-selections | grep -P 'cloud9|c9' Sep 25 13:08:12 :P Sep 25 13:15:06 very good :p Sep 25 14:24:54 i have an old dtbo made for a custom cape, working well on 3.8 kernels. loading it on a newer image (stretch on BeagleBoard.org Debian Image 2018-10-14 with 4.14.71-ti-r80) gives an error at boot: failed on fdt_overlay_apply(): FDT_ERR_BADOVERLAY. how can i investigate further? Sep 25 14:25:16 this is the boot log: https://paste.debian.net/1102531/ Sep 25 14:25:45 and here is the dts: https://paste.debian.net/1102530/ Sep 25 14:27:12 samael: at the very least recompile with the latest device tree compiler Sep 25 14:27:38 it is also possible the overlay might need changes, lemme see Sep 25 14:28:26 yeah, the off-by-one in uart labels is no longer the case. uart is now just &uart1 Sep 25 14:29:24 zmatt: at the time i needed to use the rcn patched version of dtc. is there some up to date documentation to follow out there to avoid common mistakes? Sep 25 14:29:57 samael: just use the dtc that's already installed on the current image Sep 25 14:31:20 I think that and the lack of weird off-by-one issues that 3.8 had are the only things to be aware of Sep 25 14:31:50 samael: i see rs485 usage... you'll need to rebuild with omap_serial vs serial_8250_omap... Sep 25 14:32:17 oh yeah, or modify the DT to support 8250's rs485 mode Sep 25 14:32:40 which seems more sensible than recompiling the kernel Sep 25 14:33:16 it's hit or miss, depending on how he's using 485... Sep 25 14:33:59 I know it has the limitation of not supporting a gpio for driver-enable (only the rts pin), are there more issues? Sep 25 14:36:03 i'm really not a dt and driver expert. in case i need the serial_8250_omap, should i recompile the kernel? i'd prefer to approach it from the dts if feasible (and practical) Sep 25 14:37:22 Mostly, just a lot of yelling from the user that it wasn't a drop in. ;) Sep 25 14:38:23 samael: here is one example (using the default serial setting): https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-UART4-RS485-00A0.dts#L105-L115 Sep 25 14:39:24 hmm, it does support using a gpio? Sep 25 14:39:44 this is not documented in the DT binding Sep 25 14:40:21 https://www.kernel.org/doc/Documentation/devicetree/bindings/serial/rs485.txt Sep 25 14:40:53 oh it does seem like it wasn't supported in serial-core yet in 4.14, it might need 4.19 Sep 25 14:41:05 but it is in: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/serial/8250.txt Sep 25 14:41:10 (stupid huh..) Sep 25 14:42:08 ah I didn't know the 8520 driver supported that Sep 25 14:42:23 a bit odd it's in there and not in serial-core (if that's indeed the case) Sep 25 14:44:25 rcn-ee[m]: wait, all this is irrelevant since he's doing userspace control of driver enable Sep 25 14:44:31 so kernel driver support is irrelevant Sep 25 14:45:09 samael: fixing the uart references and recompiling with the dtc that's already installed should suffice Sep 25 14:48:30 rcn-ee[m]: afaict 4.19 does not support modem-control gpios in serial-core or 8520, they must have added that later Sep 25 14:49:12 yeah it's not in the 4.19 DT bindings either Sep 25 14:53:27 samael: if you want to let the kernel automatically manage rs485 driver-enable then you'd need to ensure that the uart's actual rts pin is used for it (with appropriate pinmux), a 4.19 kernel (or later) is installed, and either your DT sets the linux,rs485-enabled-at-boot-time; property on the uart or userspace enables RS485 mode via an ioctl(). you can also configure some other properties in DT (see ... Sep 25 14:53:34 ...https://www.kernel.org/doc/Documentation/devicetree/bindings/serial/rs485.txt ) but I think those can also be configured from userspace. if you don't care about kernel-managed driver-enable and are perfectly happy with userspace control of driver-enable (like you're evidently doing right now) then you don't need to worry about all this Sep 25 14:55:08 sorry for the delay, i'm really ignorant about all that and was trying to figure it out. Sep 25 14:55:33 zmatt: i'm really happy with userspace if feasible Sep 25 14:56:08 of course it is, and you don't need to change anything in your DT for it Sep 25 14:56:58 like I said, unless you specifically *want* the kernel to manage driver-enable you can completely ignore this whole rs485 discussion Sep 25 14:57:39 AFAIU, i could just load the stock DT without adding custom ones, use config-pin to make the appropriate pinmux, and then what? i think i'm still missing something about the ioctl() you mention Sep 25 14:58:03 that's another alternative yes, you can use config-pin instead of an overlay Sep 25 14:58:09 whichever you prefer Sep 25 14:58:51 the ioctl thing is part of the kernel-controlled driver-enable discussion therefore ignore it Sep 25 15:01:04 on 3.8, together with the custom dtbo, i used to run this at boot time to tell the kernel driver to properly manage the RE/DE timings using the GPIO declared in the DT: https://paste.debian.net/1102543/ Sep 25 15:02:07 if you prefer to use an overlay (e.g. to get pins configured early) then you just need to fix up the uart references (since they're no longer off-by-one) and recompile the dtbo. you should in that case also *either* disable cape-universal by commenting out the relevant line in /boot/uEnv.txt *or* add a block similar to this one to your overlay (but for all uart pins used by it): ... Sep 25 15:02:13 ...https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-UART1-00A0.dts#L49-L57 Sep 25 15:04:01 disabling cape-universal and using an overlay would make things pretty much identical to how they were on 3.18, while using cape-universal means you have the configure the pins from userspace (e.g. using config-pin) and other minor changes, such as the gpio already being exported by default Sep 25 15:04:19 oh and in both cases the serial devices are now /dev/ttyS*, not /dev/ttyO* Sep 25 15:04:39 although I think there may still be backwards-compatibility symlinks from ttyO* to ttyS* Sep 25 15:06:38 i'll follow your advice and ignore the dt/kernel parts. i'll start to stick with config-pin as i think it's perfectly acceptable for me. still, i don't get how does the link between the uart and the choosen gpio gets done to properly manage the re/de signal Sep 25 15:08:01 that link only exists in your hardware, since (according to your current dts) you're just using some gpios to control each driver-enable Sep 25 15:08:02 (i know, i'm thick-headed. please be patient :D) Sep 25 15:08:46 your existing software presumably hardcodes which gpio is used to control the driver-enable of which uart Sep 25 15:09:19 it Sep 25 15:09:46 sorry. it's done in this script: https://paste.debian.net/1102543/ Sep 25 15:10:16 lines 32-33 is where that information is hardcoded Sep 25 15:10:46 now i see the whole picture. Sep 25 15:11:45 i'll try asap. many thanks! Sep 25 15:11:49 oh wait, you *do* use kernel control of rs485 Sep 25 15:11:57 you just enable it from userspace rather than from DT Sep 25 15:12:09 in that case I'm afraid the whole discussion above *does* apply Sep 25 15:13:35 heh... too good to be true :D anyway, is it enough to fix the uart numbers removing the +1 offset, and recompile the dts with the dtc on the standard images? Sep 25 15:14:10 not for kernel-managed rs485 mode no Sep 25 15:17:32 at least I don't think so Sep 25 15:17:35 I'm not 100% sure Sep 25 15:17:46 I think it would need kernel 4.19 at the very least Sep 25 15:17:55 still, it seems you saved me a lot of trial and error. let's start to dig in Sep 25 15:18:32 4.19 definitely supports kernel-managed rs485 but I'm unsure about using a gpio (instead of rts) for the driver-enable signal Sep 25 15:18:32 the kernel version is not really a problem. aside from the serial use, there are no other constraints Sep 25 15:19:55 you could definitely first just try it, perhaps even with the default 4.14 kernel Sep 25 15:21:07 if rs485 doesn't work with 4.14 nor 4.19 then probably the easiest workaround is recompiling the kernel with omap_serial instead of 8520_omap .. then it'll all work again like it did in 3.8 Sep 25 15:21:45 the process is pretty easy, here are some notes => https://pastebin.com/eLhrp1Hg Sep 25 15:23:27 you'd want to enable CONFIG_SERIAL_OMAP ("OMAP serial port support") and CONFIG_SERIAL_OMAP_CONSOLE ("Console on OMAP serial port") while disabling CONFIG_SERIAL_8250 ("8250/16550 and compatible serial support") Sep 25 15:27:18 alternatively (to keep using 8520_omap) you'd need a "sufficiently recent" kernel but I don't know what's sufficiently recent, do know that you'd need to use a -bone kernel rather than a -ti one, and don't know what caveats there might be with 5.x-bone kernels :) Sep 25 15:28:43 sorry for overwhelming you with options, but I've tried to list them in ascending order of headache ;) Sep 25 15:35:33 zmatt: your support is indeed priceless. i'd really have to offer you a good beer Sep 25 15:35:55 hehe, thanks, but I don't drink alcohol Sep 25 15:36:53 i know places where you can easily change your mind. but i'm sure some other tipping methods would work, either :) Sep 25 15:39:17 thinking further, what's the best solution to put in place regarding the compatibility with the latest debian images? sooner or later (and i hope the former) we'd have to stick with buster, and BTW i'd like to be future-proof Sep 25 15:40:23 i guess they are compatible with the 4.19 (or other recent kernels), so there should be no big worries. is that correct? Sep 25 15:40:45 sadly nothing's been 100% future proof with DT's... Sep 25 15:41:08 but fortunately you're not using much as far as DT is concerned Sep 25 15:41:26 and if you use cape-universal then it's not really your problem anymore :) Sep 25 15:41:54 and yeah I'd use buster... in fact we do use buster :P Sep 25 15:42:25 i see. one more question: will all this be valid on bb-ai too? Sep 25 15:42:53 (i just ordered a couple of them this morning. can't wait to put my hands on them...) Sep 25 15:43:16 from what I've heard, you might not want to *physically* put your hands on them while they're running XD Sep 25 15:43:21 *put Sep 25 15:44:24 apparently they get rather hot Sep 25 15:44:32 yeah i was reading about the high temp issues. nonetheless i've been waiting for such an update for a longtime Sep 25 15:44:57 but I have no idea what the situation is with pinmux on the ai... it's quite a headache on the am572x Sep 25 15:45:04 i'm sure it will get addressed soon Sep 25 15:46:33 The BBAI is easy... "EVERYTHING" has to be done in u-boot... ;) Sep 25 15:46:40 the problem with the am572x is that changing pinmux at runtime is known to be able to cause a glitch on the I/O Sep 25 15:47:02 yup Sep 25 15:48:34 ok, i need to plan some time to study all that, then Sep 25 15:48:57 rcn-ee[m]: I've had an idea: after loading the DT and applying overlays, use libfdt to iterate it and look for "default" pinctrl states for pinmux and iodelay, put a table of that info in internal SRAM, copy a small helper function into SRAM and jump into it, let it put EMIF into self-refresh, isolate I/Os, apply pinmux and iodelay, unisolate I/O, take emif out of self-refresh, return back to u-boot Sep 25 15:50:06 feels like it ought to be doable... Sep 25 15:50:59 then at least DT and overlays can be used the way they are now Sep 25 15:52:42 and maybe a kernel property to indicate the default pinctrl is already taken care of (for pinmux it could double-check that it is and complain loudly if it isn't, for iodelay it probably shouldn't do anything at all due to erratum i933) Sep 25 15:52:55 a DT property to indicate to the kernel I mean Sep 25 15:54:52 then at least pin config can be done in the main DT and overlays Sep 25 15:55:17 which is already a substantial improvement over having to hardcode it into SPL :P Sep 25 15:57:50 or if the pinmux and iodelay is stored as a flat array in SPL, it might also be doable to make a userspace utility that loads the skeleton dtb, applies configured overlays, extracts the pinctrl information and binary-patches it into SPL Sep 25 15:59:01 (I've had these ideas for a while now and wanted to look into them for the x15, but I think they're going to be even more relevant now with the bbai) Sep 25 16:07:10 zmatt, so what i've read, to make things really safe on the am57xx, all the pinmuxing needs to be done before DDR init.. so spl.. Sep 25 16:07:20 rcn-ee: can you install libinline-files-perl by default? Sep 25 16:08:44 jkridner: looks like i added that to buster, i need to add it to stretch Sep 25 16:11:11 added Sep 25 16:23:41 rcn-ee[m]: it needs to be done while I/O is isolated, my suggestion above was for a way to do so at a later stage in u-boot Sep 25 16:26:39 it kinda resembles what's done for deepsleep on the am335x (for a similar reason: namely ddr3 being temporarily inaccessible) Sep 25 16:27:35 (but without having to save/restore EMIF config since we're not actually powering anything down) Sep 25 16:29:47 I don't know if anything else is active in u-boot that might be affected other than ddr3... I guess maybe the console uart might see a glitch (depending on what's internally sent to the peripheral while in I/O isolation) but that shouldn't be hard to deal with either Sep 25 16:36:01 hmm, actually I'd guess that the console is currently already active before SPL does I/O isolation anyway, so to the extent this is an issue it's probably already solved Sep 25 16:36:18 no wait Sep 25 16:36:19 I'm dumb Sep 25 16:36:48 it can't enable the console until it has done pin config Sep 25 16:59:55 for anyone who has a BeagleBone AI board, I'd be curious what 'sudo hexdump /dev/mmcblk1boot0' shows. Sep 25 17:01:15 does the bbai u-boot make use of those regions? Sep 25 17:13:24 zmatt, jkridner is looking to see if embest actually added an id in production units at that location Sep 25 17:14:42 I'm finally writing the dang code to read it.... Sep 25 17:14:47 I've got some of the production boards at home I can check the code with tomorrow. Sep 25 17:15:03 getting embarassed not having an upstream submission. Sep 25 17:16:24 an id in boot0? ehh Sep 25 17:17:01 a serial number... Sep 25 17:17:18 yeah but why in boot0 ? that's not exactly what it's meant for Sep 25 17:18:12 poor man's i2c eeprom. ;) Sep 25 17:19:32 I guess it doesn't really matter since sysboot can't be configured to use the eMMC boot partitions anyway Sep 25 17:20:51 oh actually never mind it does try to use the boot partitions by default Sep 25 17:21:43 so yeah, using boot partitions would allow for atomic bootloader updates Sep 25 17:40:07 yeah, getting u-boot into those boot partitions would be nice. do you know if it scans multiple locations? Sep 25 17:42:52 got TI to put up http://www.ti.com/tool/BEAGLE-3P-BBONE-AI Sep 25 17:43:01 hopefully I got all of the right docs listed. Sep 25 17:53:59 I believe I can use the CTRL_CORE_BOOTSTRAP register at 0x4A0026C4 to determine if the eMMC should be configured by the boot mode Sep 25 17:54:00 -> 00008102, MODE=2 (USB/SD/eMMC) Sep 25 17:54:10 jkridner[m]: you select which of the two boot partitions is active in an eMMC config bit, eMMC will simply send the contents of the active boot partition to bootrom (when this feature is enabled) Sep 25 17:54:13 so, I'll do that in u-boot before reading the eMMC Sep 25 17:54:53 that doesn't tell you whether it is configured, since it will try usb and SD first Sep 25 17:55:04 so, only a single location for whichever partition is active? Sep 25 17:55:32 yes, so you'd update the contents of the inactive boot partition and then flip the toggle Sep 25 17:55:35 I guess putting the serial number in where we did likely broke doing the atomic switch (no redudnant area to put the new bootlaoder) Sep 25 17:55:59 hence the "<@zmatt> an id in boot0? ehh" Sep 25 17:56:31 if you want to use the boot partitions as they're intended, for atomic bootloader updates, then you'll have to overwrite the serial number (unless you put it somewhere near the end) Sep 25 19:32:08 zmatt..thanks, i'd ratehr start with a very barebones. Sep 25 19:32:22 that console version sounds more like what i need. Sep 25 19:32:45 i'm trying to set up AWS greengrass Sep 25 19:35:49 yeah then go for the console image Sep 25 19:53:05 zmatt, not sure why i missed that to start with. I was looking for a 'minimal' install Sep 25 20:06:31 yeah "minimal" would be a better name than "console" Sep 25 20:28:13 hi, is it on purpose - when I try to see beagleboard.org projects almost on any click the pop-up "Join the world’s best hardware engineers." appears? Sep 25 20:28:46 what Sep 25 20:29:09 that doesn't sound right Sep 25 20:29:57 seens to be working here Sep 25 20:30:01 no popups Sep 25 20:30:14 zmatt: try to choose different projects here https://beagleboard.org/p Sep 25 20:30:35 or categories Sep 25 20:30:57 yes, that's where I am, no popups for me Sep 25 20:31:05 and you have to be not logged in Sep 25 20:31:09 I'm not Sep 25 20:31:41 ok, ublock will dill with that then Sep 25 20:31:51 lemme check Sep 25 20:31:52 no popups for me either, but then I always use an adblocker and have popups disabled Sep 25 20:32:08 the web's not worth using otherwise Sep 25 20:32:20 ublock disabled, still no popups Sep 25 20:35:11 zmatt.. where would i find the 'minimal' image? Sep 25 20:36:02 how can I find DSP related projects? it seems there is nothing in bb-x15 section Sep 25 20:36:15 mrpackethead: https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Stretch_Console_Snapshot or https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Buster_Console_Snapshot Sep 25 20:37:37 zmatt! thanks. Sep 25 20:39:28 also, does somebody tried to port opengl to c6x dsp? Sep 25 20:40:01 what does that even mean? opengl is a specification, you implement it, you don't port it Sep 25 20:40:08 s/did/does/ s/tried/try/ Sep 25 20:41:33 zmatt: but you can take existing implementation and port it to dsp, right? Sep 25 20:41:35 https://e2e.ti.com/support/processors/f/791/t/87167?OpenGL-on-c66x Sep 25 20:42:03 embden: opencl is running on the dsp of the x15.. i think those that care about opengl just use the sgx processor. Sep 25 20:42:35 I was about to ask, why would you want to use the c66x for opengl instead of using the gpu? Sep 25 20:44:14 zmatt: I was wondering whether it is possible to make a render (e.g. blender) on several bb-x15 Sep 25 20:44:51 using bb-x15 to full extent Sep 25 20:45:14 doesn't blender support openCL? Sep 25 20:45:39 yeap it does: https://docs.blender.org/manual/en/latest/render/cycles/gpu_rendering.html Sep 25 20:45:53 on specific cards Sep 25 20:46:53 blender is open, embden should be able to exetned there OpenCL to the version used on the x15. ;) Sep 25 20:47:01 true Sep 25 20:47:18 the EVEs might actually be better targets than the DSPs but I'm not sure Sep 25 20:48:15 it was super naive idea, I was just wondering whether it is possible at all Sep 25 20:48:31 you asked an x y question though Sep 25 20:48:49 you asked about opengl on the dsp, which would have given you little or no progress in your actual goal Sep 25 20:49:09 embden: it's possible, you just need to do some work. ;) Sep 25 20:49:15 zmatt: not sure about this Sep 25 20:49:39 because newer blender require opengl library Sep 25 20:49:54 and refuses to work without it Sep 25 20:50:07 requires* Sep 25 20:50:14 So pickup some used gtx1070x's off ebay.. ;) Sep 25 20:50:23 they probably link to it to detect supported graphics cards Sep 25 20:50:39 or maybe use it for the user interface Sep 25 20:50:46 zmatt: maybe Sep 25 20:51:05 https://docs.blender.org/manual/en/latest/render/cycles/gpu_rendering.html clearly indicates they require very specific features to suppor gpu rendering Sep 25 20:51:48 so while they use opengl (with a ton of vendor extensions no doubt) to interface to nvidia cards, that's of no use for supporting a different target Sep 25 20:52:08 similarly they use OpenCL for GPU rendering on certain AMD graphics cards Sep 25 20:52:25 on the x15 you only have 2GB of ram, and you need to share some with both DSP's.. For a blender run, i think you'll be memory starved.. Sep 25 20:52:54 yes, but I am not going to do it anyway) Sep 25 20:53:30 I am also wondering whether there will be new TI ARM+DSP SoCs? Sep 25 20:53:32 So why'd you ask? kinda silly... Sep 25 20:53:49 try: ti.com Sep 25 20:53:53 rcn-ee: I've just realized that it would be too much work Sep 25 20:55:04 embden: am654x is already out, am752x is in the pipeline Sep 25 20:55:34 zmatt: I though I read somewhere that there will be no more mobile processors from TI? Sep 25 20:55:38 they're both quite different from the am572x though, they're both actually keystone devices Sep 25 20:55:43 yeah omap is long dead Sep 25 20:55:58 So, will there be new beagleboards? Sep 25 20:56:07 I'm guessing am572x is probably their last omap-derived SoC Sep 25 20:56:08 embden: these are automtive processors.. mobile processors died 5 years ago.. Sep 25 20:56:32 embden: the bbai was just released last thursday.. ;) Sep 25 20:56:58 rcn-ee: but it has the same soc as bb-x15 Sep 25 20:58:01 so? AM6 is slower then am5 (a53 vs a15), am7 is still down the pipe... Sep 25 20:58:55 zmatt. thanks.. I'm all good now, and am using the 10.1 image. which is perfect for me Sep 25 20:59:12 and rcn-ee thanks for the continous work you put in on these beagles Sep 25 20:59:48 rcn-ee I had a problem with this soc during last GSoC. People in mailing list responded like: it is outdated soc, so I nobody probably care much Sep 25 21:00:04 s/I// Sep 25 21:00:31 Oh there is a lot off issues with AM5, that was fixed in AM6... (it's still faster. ;) ) Sep 25 21:01:00 it's hard to sell and "upgarde" that isn't an upgrade.. Sep 25 21:01:12 But AM6 looks like an industry solution with ECC memory Sep 25 21:01:16 oh much flak would pi get if the pi4 was slower then the pi3 Sep 25 21:02:05 embden: just wait for AM7.. it's a nice upgrade over AM5. Sep 25 21:02:56 rcn-ee: can I read about it somewhere? Sep 25 21:03:22 http://www.ti.com/lit/ug/spruil1/spruil1.pdf Sep 25 21:06:12 that's impressive, can't imagine how much will it cost Sep 25 21:06:51 I mean something like bb-x15 with that core on it Sep 25 21:06:56 SoC* Sep 25 21:07:48 hmm, what was the difference between am5729 and am5749 again... Sep 25 21:08:04 eve? Sep 25 21:08:20 dual dsp, dual .... Sep 25 21:09:01 yeah eves': AM5728 with 4 EVEs. AM5749 has 2 EVE Sep 25 21:09:46 embden: when the am7 comes out, a bbx15 variant should be around the same price as an x15 today.. Sep 25 21:10:37 oh yeah, but added ECC stuff here and there... added some camera stuff to the die (but not supported in the am5749 part) Sep 25 21:10:45 added MCAN Sep 25 21:16:24 it is interesting whether there will be the crossbar device in am7.. like in am5? Sep 25 21:17:32 availability seems "interesting".. AM5729BABCX ($58.69) and -XA ($66.76) are listed as no stock, -XAE is listed as not available, for the AM5749ABZ the -X ($57.22) and -XA ($63.62) are likewise no stock but the -XEA ($70.03) is in stock by mouser Sep 25 21:17:44 embden: what do you mean? Sep 25 21:17:46 without crossbar interrupt controller xen virtualization would work on am5729 almost out of a box Sep 25 21:19:06 zmatt: in am5729 there is an interrupt routing device called crossbar located between ARM's GIC and external devices Sep 25 21:19:35 okay you meant the interrupt crossbar... the word "interrupt" in that is not optional if you want people to know what you're talking about Sep 25 21:19:51 yeah, interrupt crossbar Sep 25 21:21:00 I don't know much about xen, wouldn't the crossbar be the responsibility of dom0 ? Sep 25 21:22:24 zmatt the problem was that xen could handle only one interrupt-controller. So, it just refused to work without it Sep 25 21:23:08 that sounds dumb, every gpio controller is also an interrupt controller (in the DT and for linux) Sep 25 21:24:08 zmatt: I don't know how xen handles this but with crossbar it refused to work Sep 25 21:24:28 so file a bug report? :P Sep 25 21:24:31 it was my gsoc task to add the support Sep 25 21:24:57 I don't see why xen needs to know or care about the interrupt crossbar Sep 25 21:25:43 Xen just assumes that there is one interrupt controller and it is arm's GIC Sep 25 21:26:26 you can see some code produced by me: https://github.com/embeddedden/xen/compare/master...embeddedden:patch_for_gsoc?expand=1 Sep 25 21:26:33 again, what about the gpio controllers? Sep 25 21:27:11 maybe they fixed it already? Sep 25 21:27:32 like I have interrupts-extended = <&gpio0 12 IRQ_TYPE_LEVEL_LOW>; on some device in one of our beaglebone DTs Sep 25 21:28:00 an i2c i/o expander might also be used as interrupt controller Sep 25 21:30:44 zmatt: I believe they should deal with it somehow - maybe just ignoring Sep 25 21:32:35 well it depends on why they need to know Sep 25 21:34:36 like to XEN, the crossbar should probably just be some opaque device that sends a bunch of irqs to GIC, which should all be mapped to dom0 Sep 25 21:35:55 I guess the serial console might be the issue Sep 25 21:36:02 ? Sep 25 21:36:26 that's the only reason I can think of: if XEN itself needs to receive some device interrupts Sep 25 21:36:58 but there may be simpler solutions for that Sep 25 21:37:35 e.g. have u-boot setup a crossbar mapping for it and let DT pretend the uart is connected directly to the GIC Sep 25 21:38:06 or set it up in arm/platforms/omap5.c rather Sep 25 21:38:47 if you can't even explain why xen needs this, I don't understand why you started writing code for it :P Sep 25 21:39:39 although I guess it might be nice to have anyway, e.g. if you ever want to be able to map device interrupts to VMs Sep 25 21:47:01 zmatt: yes, console Sep 25 21:58:27 embden: look at it differently, without the interrupt crossbar you would have missed out on a great gsoc project! ;) Sep 25 21:59:17 zmatt: yeah, I just want to try to run to OS simultaneously on a mobile devboard Sep 25 21:59:44 on something like bb-x15, so, the project was the first step to the goal Sep 25 22:00:35 wouldn't kvm be easier? Sep 25 22:01:40 I think it might be easier - never tried it Sep 25 22:01:55 kvm Sep 25 22:02:20 I just didn't know the state of kvm on arm Sep 25 22:02:23 it seems people have used kvm successfully => https://lists.debian.org/debian-arm/2016/11/msg00024.html Sep 25 22:03:18 interesting... Sep 25 22:04:04 it might suit me even better Sep 25 22:05:05 When I was investigating the state of the arm virtualization I haven't found much about kvm Sep 25 22:05:19 For KVM, just make sure you have the version of u-boot with the hypervisor bits set.. i don't remember off hand when it when into u-boot or if that is still rfc'ed.. Sep 25 22:08:24 also, the arm machines are not listed here: https://www.linux-kvm.org/page/Host_Support_Status Sep 25 22:12:32 dont' think anyone's cared about that page: https://www.linux-kvm.org/index.php?title=Host_Support_Status&action=history Sep 25 22:13:47 rcn-ee so, that was a problem I wasn't able to find more information on kvm than on xen Sep 25 22:13:52 Im loving this.. Sep 25 22:14:08 AWS GreenGrass running lambdas on the Beaglebone Sep 25 22:37:56 embden: have you consider getting GPGPU working with the SGX on the Beagle family of boards? Sep 25 22:38:59 ds2: not yet Sep 25 22:39:36 I mean I will need it Sep 25 22:39:55 embden: it was another GSoC idea I put out... I have some skeleton code to create things but no shader code written Sep 25 22:40:22 the SGX isn't used in most cases (driver issues and headless usage) Sep 25 22:41:01 ds2: my overall idea is to run both Linux and Android simultaneously Sep 25 22:43:11 and abandon the idea of running blender on top of bb-x15 - of you talk about it Sep 25 22:44:38 abandoned Sep 25 22:54:01 just got a beaglebone AI...have had three temp shutdowns...not doing anything special other than running the stock image. now after not having plugged in for over 4 hours im not getting any boots Sep 25 22:54:11 any ideas or should i just returnit? Sep 25 22:54:40 oof Sep 25 23:00:27 embden: via Xen or? Sep 25 23:00:47 ds2: probably I should try kvm first Sep 25 23:01:08 embden: KVM would be cool... would live to cut the control Android has over the HW Sep 25 23:01:26 or even plain containers would be interesting Sep 25 23:01:39 freeze and thaw Android as needed Sep 25 23:02:43 yes, the idea is to also include SELinux management mechanism..though, I am not sure how to achieve all of these using kvm Sep 25 23:03:19 smbrandonjr: you're not the only one with thermal issues, though you're the first report of a board having maybe died.... what are the symptoms exactly, does it seem to partially boot and then fail, or no activity at all? have you tried booting it from an sd card containing the latest image, to exclude the possibility that it's just failing to boot due to filesystem corruption? Sep 25 23:07:44 i did download the latest 9.9 iot image from bb site and flashed to sd card and i get same response as if booting from emmc....when i plug it in i only get the LED next to USB C port, user LEDs never do anything Sep 25 23:20:28 hmm Sep 25 23:23:10 jkridner[m]: ^ Sep 25 23:30:39 ewwwwwwwwww SELinux Sep 25 23:33:30 SELinux is coating the outside of a weaved basket with silicone caulk and calling it a water basin Sep 25 23:35:03 context? how did selinux come up? Sep 25 23:36:17 zmatt: embden's comment about yes, the idea is to also include SELinux management mechanism..though, I..... Sep 25 23:36:31 oh I somehow overlooked that Sep 26 00:02:29 @embden: you can do that with: https://anbox.io/ Sep 26 00:13:29 rcn-ee[m]: doesn't anbox run qemu with a fresh kernel? Sep 26 00:19:47 if your are on ARM, it just runs in userspace in a container, just using the android kenrel module Sep 26 00:59:20 Hello, all. I just got some BB AI's and I'm seeing some strange behavior with them. Sep 26 01:01:25 if you're hoping to get feedback on that you might want to describe that strange behaviour :P Sep 26 01:02:01 Yes of course. The CPU and RAM are running incredibly hot. Sep 26 01:02:25 I see the Kingston RAM chip at 95C right now, which is basically the thermal limit in the spec sheet. Sep 26 01:02:39 And it's just sitting idle. Booted up and doing nothing. Sep 26 01:02:45 yeah I've heard a lot of reports Sep 26 01:02:57 OK so this isn't a bad batch or something that I happened to get. Sep 26 01:03:14 well I don't know, but if it is then at least you're not the only one ;P Sep 26 01:03:22 Mine came from Mouser. Sep 26 01:04:05 And the other thing is I can't seem to disable the wifi/hdmi/etc with the uBoot.env cape disable flags that worked fine in my BBBlack systems. Sep 26 01:04:15 uEnv.txt that is Sep 26 01:04:31 I'm honestly a bit puzzled by all this, I have a bbx15 which has the same SoC, no heat sink or fan, cpu governor "performance" (fixed 1.5 GHz), and if I kept one core at 100% cpu load it still didn't rise above 80 degrees Sep 26 01:04:42 yes overlays are not working right now Sep 26 01:05:16 OK definitely in early adopter territory here. Sep 26 01:05:22 hdmi shouldn't really be doing much anyway unless you plugged in a hdmi monitor Sep 26 01:05:41 Console keeps throwing errors, [ 12.750429] omapdss error: HDMI I2C Master Error Sep 26 01:05:54 hmm Sep 26 01:06:17 I also need to reclaim a bunch of pins on the connectors that required me to disable as much as I can Sep 26 01:06:31 is that still necessary on the bbai? it seems unlikely Sep 26 01:06:35 lemme look at the schematic Sep 26 01:06:55 To be fair I just tried to map over what I did on the BBB to the BBAI Sep 26 01:08:11 And we are operating in a situation where I have to remove the wireless capability. Our telescope shares a mountaintop with a radio telescope and we aren't allowed to use wifi or bt. Sep 26 01:08:17 actually I know it's not the case since the am572x has an integrated hdmi phy with dedicated pins Sep 26 01:08:32 does rfkill not work? Sep 26 01:08:52 I wasn't aware of that command, cool Sep 26 01:09:56 you could probably also customize the DT to disable the wifi/bt chipset entirely Sep 26 01:10:58 If heat is a problem and turning off the chipset is possible I might pursue that. It's enough that it doesn't transmit on the antenna, for now. Sep 26 01:11:17 PaulRichards: I'm curious, could you run my show-pins utility and share its output via a paste service? => https://github.com/mvduin/bbb-pin-utils/tree/bbx15-experimental#show-pins Sep 26 01:11:44 I'm wondering what its default pinmux is currently Sep 26 01:11:45 About that, /opt/scripts/device/bone/show-pins.pl doesn't work because it's missing a Perl module Sep 26 01:12:01 apt-get install libinline-files-perl fixes that Sep 26 01:12:19 I think that's a heavily patched version of an ancient version of my show-pins script Sep 26 01:12:24 I have little to do with it Sep 26 01:12:29 Ah ok! Sep 26 01:13:11 I'm installing the link you just sent me Sep 26 01:13:50 you can probably just do sudo show-pins -v | pastebinit if pastebinit is installed (it probably is by default) Sep 26 01:14:20 maybe -vv even Sep 26 01:14:39 since this version of the script is technically for the bbx15 and not the bbai so its idea of which pins are useful to show will be wrong Sep 26 01:14:45 root@beaglebone:/usr/local/sbin# ./show-pinsCaution: Uses peripheral names from . See README there for details.Died at ./show-pins line 97, <> line 30. Sep 26 01:14:53 grr Sep 26 01:14:56 now what Sep 26 01:14:59 I did get the other show pins to work Sep 26 01:15:13 hold on lemme see if I fucked something up with the recent commit Sep 26 01:15:51 hmm it works on my bbx15 (kernel 4.14.62-ti-r69) Sep 26 01:15:51 http://paste.debian.net/1102627/ is the other one Sep 26 01:16:21 PaulRichards I got mine from mouser also Sep 26 01:16:29 smbrandonjr overheating, too? Sep 26 01:16:32 fwiw Sep 26 01:16:50 yes have had 3 shutdowns due to temp and unable to boot back up since the 3rd one Sep 26 01:16:58 PaulRichards: which kernel version is this btw? Sep 26 01:17:04 I've had shutdowns that I thought were temp, I think that confirms it Sep 26 01:17:15 Linux beaglebone 4.14.108-ti-r113 #1 SMP PREEMPT Wed Jul 31 00:01:10 UTC 2019 armv7l GNU/Linux Sep 26 01:17:27 ok Sep 26 01:17:33 wasnt doing anything special, most i did was an apt-get update Sep 26 01:17:39 weird that my script dies for you, lemme check what line that is Sep 26 01:18:07 hmm something weird about gpios Sep 26 01:18:30 can you share the contents of /sys/kernel/debug/gpio ? Sep 26 01:18:52 http://paste.debian.net/1102629/ Sep 26 01:19:42 wtf, the kernel doesn't necessarily list the gpiochips in order? that's weird Sep 26 01:19:45 PaulRichards: r114 add's a 500Mhz operating point, it doesn't save much power. Sep 26 01:20:20 (it also lowers the cpu set points for temp) Sep 26 01:20:54 rcn-ee[m] I assume you're the owner of the builds site https://rcn-ee.com/rootfs/bb.org/testing/ ? Sep 26 01:21:03 rcn-ee[m] thanks for maintaining that Sep 26 01:21:06 yeap, that's my server Sep 26 01:21:45 PaulRichards: as a quick workaround, in line 97 ("$chip{index} == @gpiochip or die;") change the "or die" to "or last" Sep 26 01:21:56 I tried the 09-22 nightly but it was super angry about lots of things Sep 26 01:22:38 zmatt ok that worked http://paste.debian.net/1102630/ Sep 26 01:22:42 I should see if I can merge jkridner's work with my work Sep 26 01:23:26 was it buster or stretch? with stretch it added the 500Mhz point (4.14.x), with buster it's (4.19.x) with my hacked up brcmfmac/cypress patchset.. Sep 26 01:23:38 I forgot the -vv, here's with that param added. http://paste.debian.net/1102631/ Sep 26 01:23:59 rcn-ee[m] am57xx-debian-9.11-lxqt-armhf-2019-09-22-4gb.img.xz Sep 26 01:24:33 what is your power supply? Sep 26 01:24:38 just curious Sep 26 01:24:47 USB-C cable right from my Macbook Pro Sep 26 01:33:00 PaulRichards: ah i see the issue: ```/dev/mmcblk0p1 3.4G 3.3G 0 100% / Sep 26 01:33:01 ``` Sep 26 01:33:30 hmm doesn't look full at the moment Sep 26 01:33:32 oot@beaglebone:/usr/local/sbin# df -kFilesystem 1K-blocks Used Available Use% Mounted onudev 203192 0 203192 0% /devtmpfs 62520 7092 55428 12% /run/dev/mmcblk1p1 15000584 3510232 10708632 25% /tmpfs 312596 8 312588 1% /dev/shmtmpfs 5120 4 5116 Sep 26 01:33:32 1% /run/locktmpfs 312596 0 312596 0% /sys/fs/cgrouptmpfs 62516 4 62512 1% /run/user/1000 Sep 26 01:33:32 fs is probally corrupt...too small... okay what bloated things... Sep 26 01:33:46 oh I see ok Sep 26 01:33:51 different device Sep 26 01:34:16 yeah, after a fresh dd, the "img" is too big for the 85% of 4GB we use.. Sep 26 01:34:23 got it, yup Sep 26 01:35:22 i'll generate a new image tomorrow morning.. i think it's the "cloud-examples" repo, as they keep adding stuff to that.. Sep 26 01:38:52 rcn-ee[m] thanks I'll look for it Sep 26 01:40:29 ugh, or i know what it is... We added the ti-tidl application this week.. (and that's only going to get bigger) ugh.. okay i will split "lxqt" into two images, "lxqt" and "lxqt-tidl".. (and the same for iot..) Sep 26 01:40:46 rcn-ee[m] we're running your bone-debian-9.6-iot-armhf-2019-01-20-4gb.img.xz image successfully on our BBB's in the Keck telescopes and we want to move to the AIs for a bit more performance. So far so good, though. Sep 26 01:41:08 jkridner: ti-tidl blew up our image size, i'm splitting it into two.. ^ Sep 26 01:42:30 PaulRichards: except for the thermal issue.. i have small desk fan running on mine.. Sep 26 01:43:10 PaulRichards: this fan cape should be avaible soon.. https://www.youtube.com/watch?v=v3_hNBJbqME Sep 26 01:43:12 rcn-ee[m]: yes we're going to have to tackle the thermal issue. The primary mirror runs anywhere from -4 to 4C and we're going to have 36 of these parked underneath it. Sep 26 01:44:01 fans are great for dispersing the heat but I'd prefer not to make it in the first place Sep 26 01:44:32 oh and we have the BBB / BBAI mounted upside-down onto another board, there's no way to mount anything vertical on it Sep 26 01:44:38 hum, if your mirror is that temp, maybe a big block of metal on each board like the jetson nano Sep 26 01:45:48 we're a good 5 feet or more from the actual mirror itself, mounted on a deck underneath it. heat is a concern if we're making a lot of it and running glycol to 36 of these is impossible Sep 26 01:46:40 right now the board doesn't get hot, it just doesn't leave the processor efficiently.. (unlike the x15 pcb design) Sep 26 01:46:52 so the processor get's warm.. Sep 26 01:47:01 the RAM seems to get even hotter Sep 26 01:47:41 hum, i'll grab my flir gun, we might be able to downlock the memory... Sep 26 01:48:31 https://www.dropbox.com/s/1muazfy9p33omkk/2019-09-25%2014.56.05.jpg?dl=0 Sep 26 01:51:17 rcn-ee[m]: there are a couple of pins that are muxed to mode 14 (gpio) but don't actually *have* a gpio mux mode => https://pastebin.com/raw/EdaFh8dB those should probably be muxed to 15 (safe) Sep 26 01:54:21 * rcn-ee[m] uploaded an image: FLIR.png (285KB) < https://matrix.org/_matrix/media/v1/download/matrix.org/NJUuLBUzbyBNtzaqFHwQeUeE > Sep 26 01:54:45 PaulRichards: i need to get a distance sensor on this gun, but he pmic for me is the hottest.. Sep 26 01:55:53 Interesting! I just realized when I looked at the RAM I was taking it through the heat rising off the CPU. if I come at it a different direction it shows 50C. Sep 26 01:56:06 zmatt something about 15 actually shuts of the pin in a weird state, so when 2 pins are sharing a connection, 15 was bad... jkridner do you have that mode 15 email from TI? Sep 26 01:56:22 ??? Sep 26 01:56:52 now I'm really curious because that sentence sounds very odd to me Sep 26 01:59:09 regardless, using an invalid mux mode can't be a good idea either, or did TI state that doing so was fine? Sep 26 01:59:58 zmatt: let's ping Jason, i've searched in slack, i can find the mode 15 issue with share pins.. It was something about when it's in mode 15 the pin is disabled, but it pulls up/down and pin shared with it.. So it was better to leave it in a gpio - no pull up state (mode 14).. Sep 26 02:00:32 as in, it pulls in a way that's different from the configured pull-up/down ? Sep 26 02:00:32 rcn-ee[m]: OK so the takeaway for the moment is to watch for your next stretch build and that should give me the 500MHz feature and decrease the temperature a bit? Sep 26 02:01:08 rcn-ee[m]: ok I'll wait Sep 26 02:01:10 PaulRichards: you get that change by running: sudo /opt/scripts/tools/update_kernel.sh Sep 26 02:02:07 @rcn Sep 26 02:02:13 rcn-ee[m]: got it, ok Sep 26 02:02:26 and after you install that, you can also edit /boot/uEnv.txt (uname_r) and return to the previous kernel.. Sep 26 02:02:46 rcn-ee[m]: also I see some pins with rx enabled but no internal or external pull-up/down, that's not good either Sep 26 02:06:15 Well that was an adventure. I reboted my BBAI and it crashed my Mac. Sep 26 02:06:54 lol Sep 26 02:07:38 rcn-ee[m]: P8.13/18/19 should probably have internal pull-down enabled Sep 26 02:08:23 Ouch new kernel not so great, it's detecting and spamming me with heat errors now. Sep 26 02:09:17 it has lower set points, jason was trying to get the cpuidle stuff to help cool it down.. Sep 26 02:09:43 Here are the set points in that kernel: https://github.com/RobertCNelson/ti-linux-kernel-dev/commit/0d4ad727b6aae7bd364e82e11f4f036bcca4e0ff#diff-6ac5941eca97242f88f971b762186dcdR19525 Sep 26 02:10:11 but people are seeing overheating even when it's idle, so I can't imagine cpuidle helping much then Sep 26 02:10:43 (although I don't know how idle "idle" is on the default image) Sep 26 02:11:16 it's "powersave"... Sep 26 02:11:46 i've cooked a few of the proto's (before they made sure they shipped wiht a heatsink.) Sep 26 02:12:21 is my x15 just unusually chill? a favorable process corner? Sep 26 02:13:11 no, gerald just did an awesome job on the x15 to get the pcb to help remove all the heat Sep 26 02:14:06 I have such a hard time believing that that is *so* much better than an actual heatsink... I though using the pcb for cooling was more a thing if you didn't want to use a proper heatsink? Sep 26 02:14:14 *thought Sep 26 02:17:09 maybe I'm wrong, maybe my intuition is just way off on this, it just surprises me Sep 26 02:18:37 Sorry, was searching my email for a flir shot of my x15 during development.. the pcb did a good enough job, a heatsink wasn't required.. Sep 26 02:18:58 but if you ran youtube.com or wanted full 1.5Ghz a heatsink would eventually be needed for long durations.. Sep 26 02:20:21 mine seems to level off around 80 with one core at full 1.5 GHz 100% load (and the other core idle), no video active Sep 26 02:20:39 it might have still be going up but extremely slowly Sep 26 02:23:04 also FLIR sounds pretty cool :D Sep 26 02:24:36 found them Sep 26 02:24:48 * rcn-ee[m] uploaded an image: IR000073.jpg (28KB) < https://matrix.org/_matrix/media/v1/download/matrix.org/frHtmeukNhZErORmauIJFUrM > Sep 26 02:24:57 * rcn-ee[m] uploaded an image: IR000074.jpg (27KB) < https://matrix.org/_matrix/media/v1/download/matrix.org/VMaCrfeIUzDpSZjGnfOSClRR > Sep 26 02:25:20 ah right, FLIR can't properly measure shiny metallic surfaces Sep 26 02:25:24 back of the x15 pcb is actually hotter then the front.. Sep 26 02:27:15 crazy that was ti's 3.12.x kernel.. first bring up on dra7, so no pm. ;) Sep 26 02:27:17 would need to cover the SoC in black marker or something to be able to get an IR reading (might actually help with cooling too, if radiative cooling is a significant factor.. actually have no idea) Sep 26 02:27:21 heh Sep 26 02:27:44 * rcn-ee[m] sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/ekLpUsEptPISTeVhEtSewrGX > Sep 26 02:28:47 I mean, that's barely warm to the touch :P Sep 26 02:29:43 I wonder how hot the topside of the cpu actually was Sep 26 02:36:14 what device are you using to get those readings rcn-ee[m]? Sep 26 02:37:26 if my math is right, then if the cpu surface were black and its (line-of-sight) environment is room temperature then at 45 C it would lose 8.5 W via thermal radiation, and that increases rapidly with increasing temperature (14.8 W at 60 C, 21.9 W at 75 C, 30.0 W at 90 C) Sep 26 02:37:54 (this is with the thermal radiation is received back from the room temperature surroundings already subtracted) Sep 26 02:40:12 I'm kinda tempted to try to see if marking the topside black actually makes a difference lol Sep 26 02:42:46 smbrandonjr: i don't think we have them anymore, co-worker had it: https://www.flir.com/browse/industrial/handheld-thermal-cameras/ Sep 26 02:44:49 price tag: "request info" ... never a good sign Sep 26 02:45:45 ah some do have price tags... which are indeed yikes Sep 26 02:45:53 oh they are spendy.. that's why i made one out of a bbb+flir sensor+ti-dlp https://github.com/eewiki/bbb-dlp-flir-project Sep 26 02:47:19 anyway, time to head home, bbl Sep 26 02:47:54 late **** ENDING LOGGING AT Thu Sep 26 02:59:57 2019