**** BEGIN LOGGING AT Thu Jan 17 02:59:57 2019 Jan 17 07:28:30 to install kernel 4.20.1 on the BBB is this thing appropriate ? https://github.com/RobertCNelson/armv7-multiplatform/tree/4.20.1-armv7-x2 Jan 17 08:26:22 mawk: is it not available through the script in /opt? Jan 17 08:35:03 65/5000 Good morning, is there any chance that we will get from a special price on PocketBeagle ? Jan 17 08:35:27 We are a company that manufactures lighting lamps Siled Jan 17 08:36:08 We need this computer for the lamp driver :) Jan 17 08:37:14 talk to the distributors or the manufacturer Jan 17 08:38:25 which is probably Element14, digikey, mouser, … Jan 17 08:39:05 ah and Arrow Jan 17 08:39:35 you're most welcome ;-) Jan 17 09:24:40 Hello, I want to ask if there is a way to factory reset a bbgw Jan 17 09:29:00 boot from SD, clear eMMC Jan 17 09:29:32 https://beagleboard.org/latest-images Jan 17 09:42:45 But which is the recommended version for bbgw, I want to use bluetooth as well Jan 17 09:43:04 and iot or lxqt? Jan 17 09:43:27 stable version Jan 17 09:58:56 mawk: you should probably use a -bone series kernel instead Jan 17 09:59:10 bill___: do you need HDMI output and a 'desktop' experience? if not IoT Jan 17 09:59:37 be aware that some functionality may only be available in the -ti series kernels Jan 17 09:59:47 bill___: bbgw has no hdmi, hence use the iot image Jan 17 10:02:20 ah, right Jan 17 10:23:23 i have a beagleboard x15; i need to enable all of its (6) serial ports, which in understand requires uboot/pinmux. can i use the standard uboot or is there a special one for teh x15? Jan 17 15:02:48 Hi, a suggestion needed: I have a pair of numeric value coming as answer from serial line, how can I use them to be visualized as graph into an LCD7 ? Jan 17 16:21:18 no tbr 4.19.9 is the most recent Jan 17 16:22:35 -ti series only exist for LTS kernels, i.e. after 4.14-ti the next one is 4.19-ti (and I don't know what the status of that series is, i.e. whether all non-mainline features have been forward-ported yet) Jan 17 16:22:41 ah, I see Jan 17 16:23:17 I tried the -bone series but it couldn't boot because of an unknown instruction, so I thought it wasn't made for the right chip Jan 17 16:23:23 it was 4.14.91-bone17 Jan 17 16:23:29 huh, that's weird Jan 17 16:23:46 maybe that's fixed in the 4.20.1-bone17, I'm trying that Jan 17 16:23:49 somehow miscompiled or something? Jan 17 16:23:55 it was from the repo Jan 17 16:24:20 I've gotten kernels that crash with illegal instruction when using certain debian gcc versions to compile the kernel Jan 17 16:25:00 this does illustrate how little testing the -bone series get apparently :/ Jan 17 16:25:08 lol Jan 17 16:25:47 my custom kernels (which are currently based on 4.14.78-bone17) work fine though Jan 17 16:41:44 ah the 4.20.1-bone2 works Jan 17 16:42:01 with a few kernel warnings Jan 17 16:42:06 [ 59.270598] WARNING: CPU: 0 PID: 933 at drivers/clk/clk.c:828 clk_core_disable_lock+0x17/0x20 Jan 17 16:42:07 [ 59.270603] l4_per_cm:clk:00d4:0 already disabled Jan 17 16:42:13 doesn't seem very important Jan 17 16:42:33 that sounds bad Jan 17 16:43:15 sounds like maybe the new prcm infra is being used but doesn't work quite right yet Jan 17 16:44:00 it's just to bisect a bug, so as long as this doesn't impact the networking stack and related stuff I'm fine Jan 17 16:44:27 btw, a -bone kernel that crashes on boot, especially from an LTS series like 4.14, should probably be reported to rcn Jan 17 16:47:21 as an issue in https://github.com/RobertCNelson/bb-kernel I guess Jan 17 16:47:44 that probably works Jan 17 17:15:33 whatever kernel version I try, that has different module code, I get the same result Jan 17 17:15:44 garbage in my frames starting from some byte position Jan 17 17:15:53 I'm starting to wonder if my hardware is right Jan 17 17:16:03 but it worked before with a particular combination of kernel versions and in one direction Jan 17 17:19:37 can anyone here talk about why pru code may not start? Jan 17 17:19:54 I have a binary I have flashed to PRU0, but it won't start on PRU1 Jan 17 17:21:56 you don't "flash" code to a pru Jan 17 17:22:33 but yeah it's possible I suppose for code to be pru-dependent, although usually it shouldn't be Jan 17 17:23:47 what exactly do you mean by "not start" ? what symptoms are you experiencing? Jan 17 17:26:35 so, there are a few steps to get a new set of bits executing on the pru: Jan 17 17:26:43 - Copy the firmware to a file Jan 17 17:26:58 - Cat the file name into the /sys device as appropriate Jan 17 17:27:07 oh you mean using remoteproc-pru ? I've never used that Jan 17 17:27:13 - cat 'start' into the sys state device Jan 17 17:27:16 yeah Jan 17 17:27:59 I've only used uio-pruss, either using my own C++ code or my py-uio library ( https://github.com/mvduin/py-uio ) Jan 17 17:28:02 well, I have a blink-led binary that runs on 1 pru, but not the other Jan 17 17:28:31 gotcah, that seems to be on the deprecation roadmap, so I was using the new remoteproc stuff Jan 17 17:29:07 well remoteproc isn't a useful replacement yet imho Jan 17 17:29:50 (if ever) Jan 17 17:30:17 and keeping uio-pruss working is trivial effort, so I doubt it's going to go away any time soon Jan 17 17:30:25 the uio infrastructure itself has been around since the dawn of time Jan 17 17:30:59 what makes it less than suitable? Jan 17 17:31:12 no support for shared memory for example Jan 17 17:31:20 (afaik) Jan 17 17:31:42 yeah, you have to roll-up sends into messages I think Jan 17 17:32:04 so I've seen applications switch to use remoteproc, and then end up using /dev/mem to map shared memory, which is of course gross and far worse than just sticking to uio-pruss Jan 17 17:32:37 huh, so you can still use `/dev/mem` with remoteproc? Jan 17 17:32:39 rpmsg is slow, limited, and overcomplicated Jan 17 17:33:11 I mean, you can use /dev/mem whenever you want, it doesn't know or care about what is being used by other drivers Jan 17 17:33:27 which is why it's bad I guess Jan 17 17:34:20 yep, and I've often enough seen people experience bus errors because some dumb piece of code tried to access pruss via /dev/mem while it was not enabled Jan 17 17:34:35 when using uio that will never happen Jan 17 17:35:31 I'm out of ideas to test my 6lowpan Jan 17 17:35:42 I can solder a fresh pair of transceivers, get fresh cables Jan 17 17:35:46 but if that doesn't work I don't know Jan 17 17:35:53 I'll have to study the module source code for good Jan 17 17:36:13 getting stuff working can be rough Jan 17 17:37:38 otherwise I can just drop linux and don't try my setup with a border router like I intended Jan 17 17:38:15 because fixing linux is out of specs anyway Jan 17 17:38:23 the work is about the RTEMS rtos Jan 17 17:41:13 that I run on the bbb Jan 17 17:41:33 also the bbb bsp of rtems is very lacunar, I also have to write SPI drivers Jan 17 17:41:50 that'd be my contribution to the bbb world Jan 17 17:43:41 it doesn't have ethernet drivers either but that's a bit more difficult Jan 17 17:43:56 maybe when I'm super motivated Jan 17 18:02:10 zmatt: do you know of any good applications examples using the rproc world? Jan 17 18:04:19 not really the right person to ask, since I don't use rproc :) Jan 17 22:59:29 Hello, I have a BBB board, Rev B board with 2 GB eMMC Flash with original Angstrom image. I want to update the on board eMMC Linux to Debian. What version of Debian should I download for my 2 GB eMMC board? Jan 17 23:00:36 of the current images, only the console image is small enough to fit in 2 GB eMMC. The iot image used to fit, but it no longer does (I have no idea how it got so bloated) Jan 17 23:00:47 the alternative would be to boot from sd card Jan 17 23:03:19 I don't see a "console image" listed on the beagleboard.org/latest-images page. Which version is it? Jan 17 23:03:37 https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Stretch_Snapshot_console Jan 17 23:04:51 Is there anything special/extra that I need to do if I want to leave the SSD card in the BBB and boot from it all the time? Jan 17 23:05:04 SD card you mean Jan 17 23:05:11 I'd suggest erasing the eMMC in that case Jan 17 23:07:07 Thank you. I will try loading the console image onto an SD card and loading that image into FLASH memory. Jan 17 23:07:09 since your eMMC currently has a very old image, you may need to hold down the S2 button to boot from sd card Jan 17 23:07:52 once you've booted from sd card, you can either erase eMMC (sudo blkdiscard /dev/mmcblk1) or change the card into an eMMC flasher (by uncommenting the appropriate line in /boot/uEnv.txt) and reboot to reflash eMMC Jan 18 00:53:59 Hello! Jan 18 01:11:05 ok zmatt installing 5.0 fixed some regressions I guess Jan 18 01:11:10 now I have half-correct fragmentation Jan 18 01:11:19 only a patch of 6 bytes keeps being zero Jan 18 01:11:23 now I can read the module code Jan 18 01:11:28 PING fdff:dead:cafe:babe::2(fdff:dead:cafe:babe::2) 100 data bytes Jan 18 01:11:28 108 bytes from fdff:dead:cafe:babe::2: icmp_seq=1 ttl=64 time=27.8 ms Jan 18 01:11:28 wrong data byte #57 should be 0x39 but was 0x0 Jan 18 01:11:28 #8 8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 Jan 18 01:11:30 #40 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 0 0 0 0 0 0 0 40 41 42 43 44 45 46 47 Jan 18 01:11:32 #72 48 49 4a 4b 4c 4d 4e 4f 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f 60 61 62 63 Jan 18 01:12:27 DSP! Jan 18 01:12:56 dead cfe babe lol Jan 18 01:13:02 I like that Jan 18 01:13:13 lol Jan 18 01:13:48 I use de:ad:be:ef:0001 and such Jan 18 01:23:02 fragmentation from RPi to BBB is fine, but from BBB to RPi is buggy Jan 18 01:23:11 only difference I can see is the bbb kernel is PREEMPT Jan 18 01:23:25 it's the same thing as linux-rt patch right ? Jan 18 01:28:01 https://github.com/beagleboard/linux Jan 18 01:28:06 Both! Jan 18 01:29:56 You can pick and choose. Jan 18 01:34:36 yes Jan 18 01:34:44 but I had to get 5.0 so not many choices Jan 18 01:35:08 I used https://github.com/RobertCNelson/bb-kernel/tree/am33x-v5.0 Jan 18 01:35:23 which is package linux-image-5.0.0-rc2-bone0 Jan 18 01:37:12 Oh. Jan 18 01:37:30 I heard that the 5.0 v of the kernel had some issues. Jan 18 01:37:45 probably, it's still rc Jan 18 01:37:48 I will have to read what was written but it is about connection problems. Jan 18 01:37:53 but the issues I have with networking aren't related Jan 18 01:37:57 Oh. Jan 18 01:37:59 5.0 fixed most of them Jan 18 01:37:59 Okay. Jan 18 01:38:02 Aw! Jan 18 01:38:04 Cool! Jan 18 01:38:07 now the problems are just a msall patch of bytes that are zero Jan 18 01:38:12 before that it was very random Jan 18 01:38:15 small* Jan 18 01:38:21 yeah Jan 18 01:38:22 msall = small, got it. Jan 18 01:38:36 I spent many days trying every combination of kernels between the bbb and the rpi to get this connection thing working Jan 18 01:38:43 5.0 on both sides is the closest to working I've found Jan 18 01:38:53 Did you try 4.20.x? Jan 18 01:38:58 now that I have something close to working I can start modifying the module code Jan 18 01:38:58 yes Jan 18 01:39:23 Oh. You seem like you are in a differenct realm. I do not mess w/ changing modules or dtbs files. Jan 18 01:39:30 Good luck. Jan 18 01:39:33 lol Jan 18 01:39:34 thank you Jan 18 01:39:43 well the module is quite short and auto-contained, it should go fine Jan 18 01:40:19 Oh. One bit of advice, write down what it was beforehand. Just in case. Like that fellow zmatt always types, backup! Jan 18 01:40:29 and modules are surprisingly easy to compile Jan 18 01:40:33 Oh! Jan 18 01:40:34 Really? Jan 18 01:40:48 make -C /lib/modules/$(uname -r)/build M=$PWD Jan 18 01:40:52 inside the module directory Jan 18 01:40:53 Dang! Jan 18 01:40:58 That is cool info. Jan 18 01:40:59 and the Makefile you should use is a couple lines Jan 18 01:41:00 Thank you. Jan 18 01:41:06 Hmm. Nice. Jan 18 01:41:16 it's using the mother module inside the current kernel headers to know how to compile Jan 18 01:41:28 Make is a long book to read. Did you ever pick it up? Jan 18 01:41:32 the mother Makefile* Jan 18 01:41:47 well at school they made us write makefile by hand so it's fine Jan 18 01:41:51 but I don't know every arcane secret Jan 18 01:41:52 Oh. Jan 18 01:42:08 See, that book is an issue. Too many pages and not enough time. Jan 18 01:42:29 Hey mawk: ? Jan 18 01:42:37 yes ? Jan 18 01:42:46 What dsp book would you recommend? Jan 18 01:43:02 I never used DSPs for now so I don't know Jan 18 01:43:10 Okay. No issue. Jan 18 01:43:15 or maybe you just mean as a mathematical theory ? Jan 18 01:43:24 I have been searching for a good book. Jan 18 01:43:28 I used school books for that, I have no particular book to recommand Jan 18 01:43:35 I have a m4. Jan 18 01:44:02 I want to c/c++ and .asm file the hell out of this m4. I cannot find cheap books on the subject. Jan 18 01:44:20 Sorry for being so blunt. Jan 18 01:44:34 Okay. Thank you for chatting w/ me. Jan 18 01:45:09 when it comes to code I usually read official documentations, not much books or tutorial Jan 18 01:45:19 Oh. That is smart. Jan 18 01:45:31 Docs. are good at times. Esp. when it comes to the chip. Jan 18 01:45:35 eg when I had to make a small x86_64 kernel I just read the intel docs, alongside with a few references on VGA, BIOS and stuff Jan 18 01:45:38 yeah Jan 18 01:45:56 You got mad skills, mawk. Jan 18 01:46:02 Yes, I typed that out. Jan 18 01:46:04 lol Jan 18 01:49:14 Yep. Jan 18 01:58:18 mawk: I found the TRM from ARM. Jan 18 02:00:57 nice Jan 18 02:04:39 TRM! Jan 18 02:06:07 Hey mawk: Do you want to see the same bunch of scripts for the Motor Bridge Cape and BBGW for making motors move? Jan 18 02:06:41 The Seeed Studio people put a Atmel processor on this Cape for the BBB a while back. Jan 18 02:08:33 The only thing I like about the BBG and BBGW is that they have those two grove connectors for processing via UART. Jan 18 02:09:00 I have no need for a total of four USB ports for one board. Jan 18 02:18:25 yes set_ Jan 18 02:19:31 I swapped the two transceivers and my problem is the same, so the problem definately comes from the BBB Jan 18 02:19:44 next step is to compile without preempt-rt Jan 18 02:19:49 but it already looks good enough Jan 18 02:19:53 I just have to send packets small enough Jan 18 02:19:57 and no ugly fragmentation Jan 18 02:46:03 https://pastebin.com/H7iHgMGs is the funny Python (repetitious) software for making straight, u-turn, straight, u-turn in the opposite direction, and etc... Jan 18 02:46:04 ... Jan 18 02:46:12 This is w/out controls. Jan 18 02:46:17 It just goes. Jan 18 02:46:31 I plan on putting in controls one day. Jan 18 02:47:25 That was my start w/ software and the BBG. BBG = no controls Jan 18 02:47:43 I got tired of testing receivers. **** ENDING LOGGING AT Fri Jan 18 02:59:57 2019