**** BEGIN LOGGING AT Wed Aug 21 02:59:58 2019 Aug 21 07:26:14 hello Aug 21 07:26:37 I was able to successfully boot into a Devuan prebuilt image Aug 21 07:26:53 but cannot boot to a newer libreboot kernel Aug 21 07:27:20 even a blinking textual cursor does not appear on boot Aug 21 07:27:37 just a blank black display, nothing else Aug 21 07:28:06 #kernel_file=zImage Aug 21 07:28:06 #initrd_file=uInitrd Aug 21 07:28:06 kernel_file=vmlinuz-5.2.9-gnu Aug 21 07:28:06 initrd_file=initrd.img-5.2.9-gnu Aug 21 07:28:39 btw, even reversing commenting to an old kernel does NOT boot old kernel Aug 21 07:28:46 how it is possible? Aug 21 07:29:04 only replacing uEnv by its old backup copy works again Aug 21 07:34:41 and it is old BBB by 2013 Aug 21 07:34:55 it boots from SD without any key combinations pressed Aug 21 07:35:09 just enough to insert SD card Aug 21 07:35:26 I guess BROM logic was different in 2013 compared to recent one? Aug 21 07:52:58 at least able to boot old kernel now Aug 21 07:53:06 how to boot new kernel from: Aug 21 07:53:07 deb mirror://linux-libre.fsfla.org/pub/linux-libre/freesh/mirrors.txt freesh main Aug 21 07:53:20 is BBB compatible with a libre kernel at all? Aug 21 07:53:37 kernel_file=vmlinuz-5.2.9-gnu Aug 21 07:53:38 initrd_file=initrd.img-5.2.9-gnu Aug 21 08:01:11 ok bye Aug 21 08:04:15 can anyone help me please? lost connection recently, may be missing something? Aug 21 08:04:31 oh you're back Aug 21 08:05:22 I think the u-boot used by the beaglebone has always been configured to try booting linux from SD first and eMMC second Aug 21 08:05:38 that should be true on both ancient and current images Aug 21 08:06:40 however, if SD card contains a linux rootfs that is much newer or just wildly different from what the u-boot on eMMC is expecting, then it may fail to boot such an SD card, or it will boot but have weird issues Aug 21 08:08:30 hence, when booting from SD card while eMMC has a bootloader, the recommendation to use the S2 button to ensure u-boot is loaded from SD card rather than eMMC Aug 21 08:09:23 BROM is part of the hardware and therefore has not changed since the introduction of the beaglebone black Aug 21 08:10:40 as for what these random kernels you dug up support... check their kernel config I guess Aug 21 08:57:33 zmatt, thank you very much for your suggestion Aug 21 08:58:03 most likely I booted successfully earlier from an old uboot 2013 Aug 21 08:58:11 does it look for SD/uEnv.txt? Aug 21 08:58:33 I specify a kernel to boot from uEnv.txt Aug 21 08:58:45 which is located on SD card Aug 21 08:59:44 but if trying to boot pressing a button near USB will bring the whole thing to a blank screen the same as with not working kernels too Aug 21 09:00:15 then since it does not work with button, I guess there is a problem at least with uboot on SD? Aug 21 09:20:35 nah Aug 21 09:21:15 are you very sure it booted your unusual system using that old u-boot? did you confirm that "uname -r" showed the expected version tag? Aug 21 09:24:41 also, if you're using some unusual image rather than one 's rcn's images, you should use the u-boot that came with that image, not whatever was on eMMC. there's no reason to expect these to be compatible Aug 21 10:14:30 zmatt, please look at: Aug 21 10:14:31 http://pasted.co/9258b4ee Aug 21 10:14:52 there is uname output and /proc/cpuinfo Aug 21 10:43:02 are you showing this to me as confirmation that it didn't boot your 5.2.9-gnu kernel? (also why /proc/cpuinfo? I know what CPU the beaglebone has) Aug 21 11:16:19 zmatt, do you think a modification like this would allow two separate python scripts to each use a PRU seperately? https://pastebin.com/HjX18eJRhttps://pastebin.com/HjX18eJR Aug 21 11:17:20 *separately Aug 21 11:29:20 hunterl: well initialize() should be done only once since it affects shared stuff like the interrupt controller Aug 21 11:29:58 once that's done, you don't need to call initialize() at all, just do a .full_reset() on your core Aug 21 11:30:19 so no, I don't agree with this chance Aug 21 11:30:21 *change Aug 21 11:30:37 this initialize() still affects both cores Aug 21 11:31:03 (indirectly by changing global pruss config and (re)initializing the interrupt controller) Aug 21 11:32:03 core.full_reset() is the only core-specific part, so if you want a core-specific reset you just call that instead of pruss.initialize(), which is meant to initialize pruss as a whole Aug 21 11:33:32 Gotcha. I have two independent scripts that use different PRUs. Currently I have only one of them call initialize() and so I have to make sure this script is run first. It would be nice to allow them to be called in either order or only run one and not the other. Aug 21 11:34:06 Perhaps I could check if the PRU is running and call initialize() if not. Aug 21 11:35:09 both cores being halted is probably a good indication that it's okay to do pruss.initialize() Aug 21 11:37:21 to avoid race-conditions if both scripts start at the same time, you could flock() the uio device file descriptor while doing global stuff (checking whether initialize() is needed and doing initialize() and any other global config you may need) Aug 21 11:43:57 Ok, and say that the script crashes and the core is still running. I guess that I could always do a core reset at the beginning of the script to avoid this problem. Aug 21 11:44:17 I mean if the core is still running and the script restarts. Aug 21 11:50:43 yes Aug 21 12:25:40 Ok, thanks! I'm going to give that a try. Aug 21 12:54:16 dcmertens: perhaps echo stop > /sys/class/remoteproc/remoteproc1/state ; echo start > /sys/class/remoteproc/remoteproc1/state Aug 21 12:55:25 msh2, thanks! Aug 21 12:55:44 I'm using uio, though, so no dice unless there's something magical or horrible name overloading going on Aug 21 12:56:05 * dcmertens questions whether it'd called uio Aug 21 12:56:17 that is, I'm not using remoteproc Aug 21 13:01:55 ah *nod*. dunno then, maybe rmmod/insmod if they're modules? Aug 21 13:02:04 dcmertens: what are you doing that gets pruss wedged so bad that you end up having to reset the BBB ? Aug 21 13:02:21 zmatt, I'm not sure, but I think it was a broken jump table Aug 21 13:02:33 that should at worst crash the core Aug 21 13:03:00 well, when I tried to re-run my code, which initializes the PRUSS, etc, it simply said "Bus error" Aug 21 13:03:10 wtf Aug 21 13:03:11 it's OK, I got rid of the jump table Aug 21 13:03:17 how Aug 21 13:03:20 and now things seem to be working Aug 21 13:03:21 anything in kernel log? Aug 21 13:03:30 zmatt, I don't care enough to investigate Aug 21 13:03:32 fine but this still sounds really weird Aug 21 13:03:33 sorry Aug 21 13:03:35 :( Aug 21 13:03:48 well, y'know, it could be the analog addendum. :-) Aug 21 13:03:59 henceforth, any really weird problems can be blamed on that. :-) Aug 21 13:07:04 anyway, to answer your original question, it is possible to reset pruss, but uio-pruss does not expose any way to do so, so you'd have to manually set and then clear a bit in a PRCM register via /dev/mem Aug 21 13:07:27 zmatt, ah, ok Aug 21 13:10:26 I don't know what happens if you reset pruss while a transfer is in progresss on either its slave port from the L3 or one of its master ports to the L3... if something is wedged then waiting for outstanding transfers to complete could hang forever, while not waiting for transfers to complete could cause protocol errors and lock up other parts of the SoC Aug 21 13:40:02 msh2: pretty sure that unbinding the driver (including by removing the module) will just cause the pruss clock to be gated and not trigger a reset, but I'm not 100% sure Aug 21 13:40:46 with remoteproc pru it seems you'd need to unbind the pruss_soc_bus (which requires unbinding everything in it) Aug 21 13:43:17 zmatt I was thinking that reloading the driver would give the PRU a new firmware, which would have to jump to the start? Aug 21 13:43:27 though haven't tried, I'm using remoteproc Aug 21 13:44:13 he asked about resetting pruss, not merely reloading firmware Aug 21 13:45:40 resetting pruss has more than just jumping to the start? (sorry for my ignorance) Aug 21 13:47:14 ehm, yes. for one, you're just talking about a pru core, not the entire pru subsystem Aug 21 13:47:53 and in this case the hardware got so confused that even merely attempting to access it caused bus errors Aug 21 13:48:40 bus errors sound like kernel brokenness? Aug 21 13:49:11 no, they're basically errors returned by the hardware Aug 21 13:50:37 in this case, with uio-pruss, userspace is accessing pruss directly, the kernel is only involved in power management, setting up memory mappings, and delivering interrupts Aug 21 13:51:09 ah, *nod* Aug 21 13:53:59 hi all Aug 21 13:54:14 How to use spi in Cloud9/javascript?thanks in advance Aug 21 14:09:47 i wonder if somebody help me Aug 21 14:10:01 How to use spi in Cloud9/javascript? Aug 21 14:14:52 me1616: don't repeat your question after waiting only 15 minutes. most people here only glance at chat occasionally, so it can take a while to get any response Aug 21 14:15:47 I don't know anything about cloud9. As for using spi in nodejs, that's something you can just google Aug 21 14:47:43 @zmatt thank you i check node.js Aug 21 14:48:14 but i need some information about spi library for javascript Aug 21 14:57:08 me1616, I tried to google that for you, but I came up dry Aug 21 14:57:45 it might take some specific and/or creative search strings Aug 21 14:57:57 do you have a link to the cloud9 API? Aug 21 15:00:44 cloud9 is just an IDE Aug 21 15:01:34 so the search is just "spi javascript" or "spi nodejs" ... in both cases the first result was a nodejs spi library Aug 21 15:13:19 oh you make my day Aug 21 15:13:25 thank you so much Aug 21 16:06:18 good evening or day Aug 21 16:07:26 uname -a Aug 21 16:07:28 Linux devuan 4.9.105 #1 SMP PREEMPT Tue Jun 5 23:00:15 CEST 2018 armv7l GNU/Linux Aug 21 16:07:49 is here any indication of what version of uboot is used? Aug 21 16:08:01 m Aug 21 16:08:02 and how to know if it is not indicated here Aug 21 16:09:04 I need to determine whether uboot from eMMC is used or one from SD card Aug 21 16:09:16 please suggest how to do this Aug 21 16:13:43 /opt/scripts/tools/version.sh maybe? Aug 21 16:15:37 also: dmesg | grep mmc Aug 21 16:17:31 there is no /opt/scripts/tools/version.sh Aug 21 16:17:49 at least in a beowulf ARM chroot Aug 21 16:18:13 but on the hardware I tried another release ASCII Aug 21 16:56:46 CoffeeBreakfast, please look at dmesg output, is it any helpful? Aug 21 16:56:57 https://pastebin.com/raw/mZjQA6fK Aug 21 17:12:36 / (and kernel?) is from your SD.. not sure about uboot Aug 21 17:53:21 CoffeeBreakfast, sure kernel is from SD (image from Devuan website) Aug 21 17:53:57 how to determine which uboot is used? Aug 21 17:54:54 btw, it reacts to changes on SD card /boot/uENv.txt Aug 21 17:55:26 if changing kernel in this file it does not boot anymore Aug 21 17:56:09 but if trying to boot with a pressed key near USB it does not boot either even with a good kernel which worked earlier Aug 21 17:58:23 have you tried using the serial port (on J1) ? Aug 21 18:16:12 CoffeeBreakfast, what advantage is of using serial port? Aug 21 18:16:32 I did not try it yet, not sure why to do Aug 21 18:17:19 does uboot have any output to serial? Aug 21 18:17:37 and no output to display? Aug 21 18:18:40 options do not alter this behaviour ? Aug 21 18:18:53 are there any uboot options available? Aug 21 18:24:13 yes, you can enter into uboot prompt Aug 21 18:45:55 thanks for the info Aug 21 18:46:23 general RS232 cannot be used? Aug 21 18:46:31 voltage, etc.? Aug 21 18:47:02 3.3v Aug 21 19:03:45 interesting how people seem to consequently ignore that you can put more than one word in a google search Aug 21 19:07:21 I want to put regex on google search... never used to "what can i do with..." Aug 21 19:16:00 *palm* Aug 21 19:18:49 Ho Dear Aug 21 19:22:03 regexp is Turing complete or not?... Aug 21 19:24:34 CoffeeBreakfast, it depends on which regex Aug 21 19:35:47 it turns out that the query input have some special characters, like ".." Aug 21 19:35:57 *operators Aug 21 19:36:43 when I said, "more than one word" I didn't mean "one word plus redundant clutter" **** ENDING LOGGING AT Thu Aug 22 02:59:56 2019