**** BEGIN LOGGING AT Sun Jan 27 02:59:57 2019 Jan 27 05:09:48 Hi there, got my beaglebone black wireless out again and did a fresh install of debian with a flasher image. Right after installation I did a sudo apt update and upgrade, and the bonescript package keeps failing. See the output here: https://pastebin.com/JyrQBKwt Jan 27 05:10:24 I removed and purged bonescript and c9, but upon new install same error Jan 27 05:10:48 Any ideas what could have gone wrong? Jan 27 05:11:19 Also, what is more powerful for using the bbb PWM, timers etc... python-BBIO or bonescript? Jan 27 08:58:50 anyone working with barmetal application my bbb wireless? Jan 27 11:44:51 * zmatt . o O ( baremetal application on the bbb wireless? good luck with the wifi ) Jan 27 14:37:53 zmatt, how do you mean good luck with the wifi? Jan 27 16:02:59 well I estimate that that's not going to be an easy driver to write Jan 27 19:25:37 I inherited a board where sysboot 15 can be in unpredictable states durning power up and it's causing an issue with sys_clkin_ck. Sysboot expects 26mhz in and of course the board has a 24mhz crystal Jan 27 19:26:15 I found this bit of device tree info https://e2e.ti.com/support/processors/f/791/t/530777 is there a way to compile this in an overlay? Jan 27 19:26:34 lolsborn: what is causing sysboot 15 to be in an unpredictable state? Jan 27 19:26:41 something wrong with the pull resistor? Jan 27 19:27:19 It has an external sensor attached that can pull it the other direction depending on it's reading Jan 27 19:27:42 Unfortunately it's not something I can fix in the hardware as they've already shipped it Jan 27 19:27:52 *facepalm* Jan 27 19:29:28 and sure you can compile that into an overlay Jan 27 19:29:57 easiest is with my overlay-utils: https://github.com/mvduin/overlay-utils Jan 27 19:30:21 then you can literally paste that highlighted line into a file named force-24MHz.dtsi and do "make force-24MHz.dtbo" Jan 27 19:30:52 Ok, I'll give it a go Jan 27 19:31:07 "IoT" Jan 27 19:32:40 I'm trying to think if there are more consequences to the misdetected osc frequency... at least it's better that the osc is slower than it thinks rather than faster than it thinks, so it's not going to accidently overclock stuff Jan 27 19:33:09 Right now the issue is it breaks uarts Jan 27 19:33:13 that too yes Jan 27 19:33:15 and usb Jan 27 19:34:18 I hope u-boot uses a fixed configuration for the PLLs rather than computing them Jan 27 19:36:01 I'm most concerned about the core PLL and the ddr3 clock derived from it, since it can't really be changed once the memory controller has been initialized Jan 27 19:36:59 and by default bootrom will correctly configure the core PLL so I don't know if u-boot touches it at all Jan 27 19:38:38 if it doesn't, then a ton of clocks will remain too slow, including the ddr3 clock, which also means its refresh time specs will be violated Jan 27 19:41:44 oh there's a separate ddr ppl, for some reason I thought it ran off the core pll... I'm confusing it with the omap5 I think Jan 27 19:42:44 okay this isn't good... it will pick the "correct" pll configuration based on sysboot14+15 Jan 27 19:43:47 probably the best workaround would be to hack u-boot to simply overwrite those sysboot bits extremely early on (the register which holds the captured sysboot state is writable) Jan 27 19:43:49 does that mean it's going to ignore my overlay? I just reapplied power and am about to see what happens Jan 27 19:44:08 it means u-boot SPL will misconfigure the PLLs Jan 27 19:44:28 :-( Jan 27 19:44:29 and maybe the kernel will fix some of them for you, but it can't fix all of them Jan 27 19:44:40 in particular, the kernel can't touch the DDR PLL Jan 27 19:45:33 besides the uarts not working the system has been pretty stable, what would I worry about if the ddr ppl was off? Jan 27 19:46:16 the system does seem sluggish, but I'm not sure if it's just because I'm used to a 10-core i7 with 64gb of ram or if it's underclocked Jan 27 19:46:18 decreased system performance, and memory refresh timings may be violated Jan 27 19:46:56 would that lead to memory corruption? Jan 27 19:47:55 in theory violating the refresh timings might reduce memory reliability (especially near the maximum allowed temperatures), although the difference between 26 and 24 isn't huge so I'm not sure if it's a big worry in practice Jan 27 19:48:50 https://elixir.bootlin.com/u-boot/latest/source/arch/arm/mach-omap2/am33xx/sys_info.c#L60 Jan 27 19:49:22 so, that ctrl->statusreg register from which they're obtaining sysboot values Jan 27 19:49:30 it can be modified Jan 27 19:50:18 if you patch u-boot to fix the sysboot 14+15 early enough, then u-boot will fix the configuration of the PLLs and the kernel will likewise use the correct settings, no overlay needed Jan 27 19:52:26 Cool, I'll take a look at that. Thanks for the help. Jan 27 19:54:28 I think board_init_f() is called very early Jan 27 19:55:11 (after hw_data_init(), which sets the "ctrl" global variable) Jan 27 20:14:36 The overlay compiles, but doesn't seem to solve the problem for me. May be spelunking in uBoot in a bit. Jan 27 20:15:25 it's quite possible the kernel doesn't meddle with any PLL at all Jan 27 20:15:48 except the MPU PLL maybe, although it's also possible it leaves that to the cm3 firmware, not sure **** ENDING LOGGING AT Mon Jan 28 02:59:57 2019