**** BEGIN LOGGING AT Wed Oct 28 02:59:57 2020 Oct 28 13:13:00 I'm working through the basic example uses of the BBBlue, and wanted to assemble an EduMiP.Any source for EduMiP WowWee drivetrain besides tearing apart a WowWee Mip? Oct 28 14:09:54 m Oct 28 15:57:00 Greetings :) Oct 28 15:57:25 Someone already know about the Beaglebone Green *Gateway*? Doesn't have the Ethernet removed but may have broken spi0 (doesn't even work with /lib/firmware/BB-SPIDEV0-00A0.dtbo and "spidev_test -D /dev/spidev0.0") can someone confirm this? Oct 28 16:00:56 it does have the ethernet removed, they just compensated by adding an integrated usb hub with a usb-ethernet adapter Oct 28 16:01:10 which means you can expect ethernet to suck Oct 28 16:04:43 what problem are you seeing? have you double-checked the pinmux? (e.g. using my show-pins utility) Oct 28 16:09:04 based on the schematic it does not look like any expansion header I/O pins are used on board other than those for eMMC (P8.03-06, P8.20-25), all other pins should be freely usable, i.e. it should be fully backwards compatible with the BBB/BBG with regard to expansion headers Oct 28 16:13:51 Oct 28 16:14:18 right, and P9.19-20 for i2c to the rtc, though those pins are configured as i2c by default on all beaglebones anyway Oct 28 16:33:34 Okay, I guess I misconfigured something then. Ethernet doesn't matter if it sucks, it's nice that it's on-board and not taking up pins :) Oct 28 17:08:31 Does that look right? (show-pins) https://pastebin.com/5JcJwJn8 Oct 28 17:31:01 Why is clock RX & down ?! Oct 28 17:34:50 No, that's correct. Oct 28 19:00:44 looks fine Oct 28 19:03:22 rx is required for mcspi clock pin, pull direction doesn't matter hugely though preferably it should be down for spi mode 0 or 1 and up for spi mode 2 or 3 Oct 28 19:05:42 Hmm... Oct 28 19:06:29 You had some tips for the uEnv.txt (which I unfortunately lost due to a bad SD card), could name them again, please? Oct 28 19:08:31 you'd need to be more specific, no idea what "tips" you could be referring to Oct 28 19:09:57 the only generic tip I can think of is to have something like "rng_core.default_quality=100" in your cmdline var, but current images already include that Oct 28 19:10:51 Correct Oct 28 19:11:00 That's the uEnv.txt https://pastebin.com/cG6nzwdV Oct 28 19:11:21 As I remember I should disable cape universal, right? Oct 28 19:11:44 uhh why are there no comments in this uEnv.txt ? Oct 28 19:12:15 I reconstructed it from the dead one, I copy/pasted the "good" parts Oct 28 19:12:37 ehm, for most people I'd say leave cape universal enabled, unless you have specific reason to disable it Oct 28 19:13:18 a custom spi device like the encx24j600 may sometimes be a good reason to disable cape-universal Oct 28 19:13:39 it's definitely a good reason to not be able to use that spi device directly from userspace :P Oct 28 19:14:15 and you should have just leave the /boot/uEnv.txt with its comments intact, they're fine defaults for most purposes Oct 28 19:15:12 generally all you need to do is uncomment disable_uboot_overlay_video=1 if you want to use those pins for other purposes Oct 28 19:15:24 Dis-/enabling cape universal doesn't change anything, it all went back to the "encx24j600: Chip is not detected" I had for months :/ Oct 28 19:16:27 I recall the chip name and there being an issue, I don't recall whether it was eventually solved nor if so what the problem was Oct 28 19:17:33 It was solved (by you :) ), the problem was the clock not being pulled down and set as input (see line 50): https://pastebin.com/mgRFRjaR Oct 28 19:18:42 It worked fine, until the SD card died. I took the dts, compiled it with bb.org-overlays again and put together that uEnv.txt, but it doesn't do the trick Oct 28 19:19:25 it's probably just something silly, like a wiring issue or poor contact Oct 28 19:19:58 But I remember doing all kind of configuration stuff that you suggested. Oct 28 19:20:04 for safety do keep cape-universal disabled until the issue is solved, just to exclude it having impact Oct 28 19:20:14 But yes, I'll now replace all the wires. Oct 28 19:20:21 I can't imagine what configuration could be relevant Oct 28 19:20:27 Disable by commenting it out, right? Oct 28 19:20:32 Not just say "=0" Oct 28 19:20:32 yes Oct 28 19:20:57 the value is irrelevant, what matters is the existence of the variable, so =0 is equivalent to =1 Oct 28 19:21:14 Wow, that sounds flawed ^^ Oct 28 19:24:28 were you using some specific encx24j600 breakout board? Oct 28 19:25:11 picmod100 froim digilent Oct 28 19:26:36 wow, actual 0 google hits Oct 28 19:27:25 Sorry... pmodnic100 => https://reference.digilentinc.com/reference/pmod/pmodnic100/start Oct 28 19:27:39 anyway, I was gonna say make sure the interrupt line has a pull-up, but the internal pull-up that P9.11 has by default (which is what it's connected to according to your dts) should suffice Oct 28 19:28:14 The pmodnic100 fortunately does the pullup already on the interupt line Oct 28 19:28:42 Because it only breaks out SPI Oct 28 19:31:02 Cables swapped, same problem Oct 28 19:31:02 ok it uses spi mode 0, then using pulldown on clk is indeed correct, and it may be required to disable cape-universal if the encx24j600 driver doesn't explicitly set the spi mode to 0 (iirc it didn't seem to) Oct 28 19:31:26 I'm by the way using P9.17+18+21+22 Oct 28 19:33:53 can you verify that ls /sys/bus/spi/devices/spi0.0/of_node/ does not show 'spi-cpha' nor 'spi-cpol' ? Oct 28 19:34:41 Yes Oct 28 19:34:42 https://pastebin.com/5BdAmtwM Oct 28 19:34:53 *Yes, I can verify that it doesn't Oct 28 19:36:02 'kay... then everything seems fine, apart from the it not working that is :P Oct 28 19:36:09 Funny thing is that the kernel command line always has "bone_capemgr.uboot_capemgr_enabled=1" in it Oct 28 19:36:20 Yes :P Oct 28 19:36:21 that's normal Oct 28 19:36:50 that's u-boot communicating to the kernel that u-boot overlays are being used and the legacy runtime overlay mechanism should be disabled Oct 28 19:37:13 Ahh okay! Oct 28 19:37:54 my next step would probably be to temporarily set compatible="spidev"; and see if the device responds from userspace... whatever you read back may be indicative of what's going on Oct 28 19:37:59 and/or just grab a scope Oct 28 19:38:07 brb Oct 28 19:38:29 It does not respond from userspace, just FFs Oct 28 19:39:53 using /lib/firmware/BB-SPIDEV0-00A0.dtbo Oct 28 19:45:40 Okay, I tried again, now it's all 00s. Weird. But still not the answer I would like to get from it. Oct 28 20:01:00 if you use that overlay be sure to override the spi mode and frequency since neither will be configured correctly for the encx. I suggested just changing compatible= in your overlay exactly to keep as much as possible the same Oct 28 20:01:19 not doing that is also how your pinmux issue went unnoticed for longer than it should have been Oct 28 20:02:03 what test are you performing exactly? Oct 28 20:02:21 anyway, just grab the scope already :P Oct 28 20:03:36 How can I override the spi mode? I thought leaving out spi-chpa and spi-cpol is explicitely disabling them? Oct 28 20:04:07 And frequency is set, too, starting low at 8000000 and was even working with 32000000 last time Oct 28 20:04:38 I was talking about your userspace test Oct 28 20:04:49 BB-SPIDEV0-00A0 has spi-cpha; Oct 28 20:04:56 EW !! Oct 28 20:05:07 but only on cs0 Oct 28 20:05:14 why? i don't fucking know Oct 28 20:05:20 complete mystery Oct 28 20:05:26 What dtbo would work then? Oct 28 20:06:07 your own with compatible="spidev"; ... or, like I said, if you use BB-SPIDEV0-00A0 then override the mode and frequency from userspace when doing the transfer Oct 28 20:06:53 Then how the heck did it work last time? I don't see anything other than BB-SPIDEV0-00A0.dtbo Oct 28 20:07:08 Well, going to edit the dts now... Oct 28 20:07:26 then I assume last time you used the second option? Oct 28 20:07:32 i.e. set the mode from userspace Oct 28 20:08:30 (using SPI_IOC_WR_MODE ) Oct 28 20:11:09 I changed the compatible string now Oct 28 20:11:32 also you never answered 21:02 <@zmatt> what test are you performing exactly? Oct 28 20:12:11 Getting all FFs again: https://pastebin.com/KL69im4A Oct 28 20:12:49 Right, sorry, these: https://pastebin.com/pz3tpe9Z (Sending init commands, etc., just like the driver does) Oct 28 20:13:16 ^ this is when it answered correctly just some weeks ago, now it's all FFs Oct 28 20:14:09 btw why are you using sudo? the debian user has rights to use spi devices Oct 28 20:14:42 Didn't work without it, tried it with, standard linux debugging technique :P Oct 28 20:14:45 anyway, I'd say grab the scope already Oct 28 20:14:50 "didn't work" ? Oct 28 20:14:58 Same result, all FFs Oct 28 20:15:02 it gave permission denied? Oct 28 20:15:06 okay so it didn't Oct 28 20:15:07 I wish I had easy access to a scope :/ Oct 28 20:15:17 I thought you used a scope for debugging last time? Oct 28 20:15:37 Right, because I drove somewhere Oct 28 20:15:42 I see Oct 28 20:15:55 time to learn to use BeagleLogic I guess? ;) Oct 28 20:16:03 Never heard of it Oct 28 20:16:24 *googling* Oct 28 20:16:52 turns a beaglebone into a logic analyzer, max 12 channels and 100 MHz sampling Oct 28 20:17:18 failing all that, the next tool is an analog VOM Oct 28 20:17:20 Amazing what these time bring for a budget (and physical size) Oct 28 20:17:31 failing that, a DMM Oct 28 20:17:52 Is suicide an option? :/ Oct 28 20:18:03 failing that, a LED + resistor Oct 28 20:18:11 mindbyte: it's been around for a long time. in fact the biggest question would be: has its kernel driver been ported to kernel 4.19 or does it require some specific old kernel? :P Oct 28 20:18:17 lots of options, no need to brute force debug with a scope Oct 28 20:18:20 And a high speed camera to capture the LEDs, that's genius! Oct 28 20:18:27 no need Oct 28 20:18:42 eyes are fine for this purpose Oct 28 20:19:40 Okay, I'll try to find someone with a scope again Oct 28 20:19:47 Thanks for your help, again :) Oct 28 20:21:54 that BeagleLogic looks similar to what I was planning to do Yesterday Oct 28 20:22:58 btw What do FFs even mean on SPI? Oct 28 20:23:17 it means the miso line is high Oct 28 20:24:19 I mean.. what do you mean "what do FFs mean" ? no value for any data byte in either direction "means" anything on SPI in general, since SPI just transports bytes and neither knows nor cares what those bytes "mean" Oct 28 20:25:14 (or I should even say "bits", the transfer size is not actually required to be a multiple of 8 bits) Oct 28 20:25:17 more strictly speaking it means the shift register in the McSPI saw 1's in the input Oct 28 20:25:49 Maybe it could generally be a sign for "there's another device doing something garbadge while reading", was just a bit desperate question Oct 28 20:25:59 Bah, just started and i already need to optimize. sin() is way too slow Oct 28 20:26:07 mindbyte: what other device? Oct 28 20:26:19 zmatt: exactly :D Oct 28 20:26:58 Konsgnx: trigonometric functions tend to be slow yes Oct 28 20:27:20 Konsgnx: btw, does your sine need to be of arbitrary frequency, or just be tunable in some narrow range? Oct 28 20:27:21 i may need to add on a fpga... Oct 28 20:27:36 tunable across wide range. Oct 28 20:27:49 and with a sweep function Oct 28 20:28:09 so closer to arbitrary Oct 28 20:28:22 Konsgnx are you doing polygon approximation, if so you can do a binary search into a table and then interpolate Oct 28 20:28:38 binary search? usually just a direct lookup Oct 28 20:29:01 if for flats Oct 28 20:29:03 floats Oct 28 20:29:16 data type seems irrelevant Oct 28 20:29:44 ya, but with a 16-bit lookup, the resolution compared to 20 bit sine is up to 25bits Oct 28 20:29:52 sorry 25 integers Oct 28 20:29:53 how can you lookup any float directly? unless you truncate to n-digits Oct 28 20:30:24 as in 25steps between sin(0) and sin(1/65535) Oct 28 20:31:54 mm302: there's no reason to use floats here in the first place, but even if you do then yeah obviously you'd scale it and convert to integer to do the table lookup Oct 28 20:32:01 anyway brb, food Oct 28 20:36:20 you're right zmatt, so you can have a table with 2^n values value a_i = sin(2*pi*i/2^n) , then from x find closest lower i and then interpolate Oct 28 20:37:30 tricky though to do certain things without division Oct 28 20:38:21 Konsgnx: I've written an ASRC that can interpolate a band-limited signal with very high quality, i.e. given a pregenerated sine at your max frequency it could interpolate it to yield one of lower frequency. it uses 3.4% cpu load, but that's mostly due to being a bit excessive quality Oct 28 20:38:48 I'm pretty sure there are better and faster ways to generate a sine, but it does show that the BBB should have no problem with this task Oct 28 20:40:08 ah right I forgot about your samplerate Oct 28 20:40:13 can it make arbitrary interpolation size? like .0032x of the base sine? Oct 28 20:40:33 yup it's fast. Oct 28 20:40:51 Cordic in fpga may be the best bet Oct 28 20:44:38 actually if you want to know all points with same dt you can use a formula for sin(a+b) Oct 28 20:44:57 yeah I was thinking about that too Oct 28 20:45:05 I mean sin(a+k*dt) Oct 28 20:47:38 you can generate a sine by repeatedly applying a (frequency-dependent) 2x2 matrix to 2-element state vector combined with normalizing the length of that vector to keep it from diverging due to rounding error Oct 28 20:48:01 but dunno how badly the inaccuracy will bite at low frequencies Oct 28 20:49:58 and normalization requires computing a reciprocal square root Oct 28 20:55:01 and if the frequency needs to be continuously variable it doesn't help anyway Oct 28 21:01:50 gtg Thank you guys! Oct 28 21:26:30 where can I see the magic done by config-pin ? I'd like to do whatever it does inside my little app when it starts Oct 28 22:31:44 it just writes to sysfs vars Oct 28 22:33:23 e.g. https://pastebin.com/MKtWJ8G8 Oct 28 22:34:44 (the glob is because the exact names are somewhat kernel-dependent) Oct 28 22:36:20 oh interesting Oct 28 22:40:24 I didn't run out of questions sorry Matt, I usually call prussdrv_open(PRU_EVTOUT_0) that I assume is to open PRU0, but I actually see there are 8 alternatives to correspond to /dev/uio 0..7, why that? Oct 28 22:40:59 one per irq from pruss to the cortex-a8 Oct 28 22:41:36 I thought PRU_EVTOUT_0=/dev/uio0=PRU0 and PRU_EVTOUT_1=/dev/uio1=PRU1 Oct 28 22:41:51 no Oct 28 22:43:26 oh right, that's the event that has to match what's sent later from the PRU to the host to terminate Oct 28 22:43:43 if that's how you choose to set it up Oct 28 22:45:59 normally on the PRU I set `MOV R31.b0, PRU0_ARM_INTERRUPT+16` and this somehow triggers PRU_EVTOUT_0 on the host Oct 28 22:47:06 i'm puzzled about how u-boot, u-boot.bin u-boot-dtb.bin files are made, i.e. which flags/args, how is appended the dtb... surfing the makefiles is a pain Oct 28 22:47:20 either of the cores can trigger (via R31) any of the 16 software-defined events which, together with the 16 other events from the pru subsystem and 32 other events from the rest of the system, can be freely routed to the 10 irq outputs of the intc (2 to bits 30-31 of R31 of both cores, the remaining 8 to the cortex-a8) Oct 28 22:47:47 CoffeeBreakfast: uhh what Oct 28 22:48:59 oh right recent versions of u-boot also use dtb.. it appends it? it doesn't simply embed it as a variable? Oct 28 22:51:48 mm302: and those last 8 outputs (i.e. outputs 2...9 of the intc) become separate uio devices, which libprussdrv just _assumes_ they're uio0..7 (even though that's a bad assumption that is easily violated if there happen to be other uio devices unrelated to pruss) Oct 28 22:52:18 how can I see how the r31.b0 value is routed to the host event from PRU0 and PRU1? Oct 28 22:53:13 ha I didn't know other devices (not pruss) could use those /dev/uio* files Oct 28 22:54:18 there is no difference between PRU0 and PRU1 in how a write to r31.b0 is treated. writing 32..47 to r31.b0 (of either core) sets event 16..31 in the intc Oct 28 22:54:20 for example on the example I see (19+16)=35 seems to map to PRU_EVTOUT_0 on the host Oct 28 22:54:20 LD links the compiled files into u-boot if i understood correctly.. then, how u-boot.bin with the dtb are made from that elf? Oct 28 22:55:15 oh cool, thanks very much, I see now Oct 28 22:56:54 mm302: the mismatch between the value written to r31 and the event number is just a fuck-up: there's a pruss in older SoCs (omap-L1xx) where events 32..63 of the intc were software-triggered, and you simply wrote the event number into R31 Oct 28 22:57:24 the am335x cut that range in half and moved it to events 16..31 but didn't adjust the logic in the pru to keep the event number matching Oct 28 22:59:37 I may try to test if 35..42 on PRU (R31) -> PRU_EVTOUT_ 0..7 on host Oct 28 23:02:16 mm302: are you using prussdrv_pruintc_init() ? Oct 28 23:02:26 otherwise I don't see any reason why any intc mapping would be set up Oct 28 23:02:48 yes Oct 28 23:03:06 well then you're providing it with the mapping as argument Oct 28 23:05:29 CoffeeBreakfast: to create a raw binary, you use a linker script to define the exact layout of the binary during linking and then extract it from the ELF executable using objcopy Oct 28 23:06:40 true, thanks again Oct 28 23:21:27 CoffeeBreakfast: btw you realize that if you pass V=1 as argument to make that the makefile will use verbose mode and print the actual commands executed? Oct 28 23:23:00 I tried with --just-print Oct 28 23:25:17 I'd be surprised if that doesn't just completely break the makefile Oct 28 23:27:22 it does.. lol Oct 28 23:27:38 well then my expectations are met perfectly :) Oct 28 23:28:26 regardless, the commands being replaced by a brief message of what it's doing is not caused by make itself hence not influenced by options/flags of make itself Oct 28 23:28:47 it's something these particular makefiles are doing (which u-boot inherited from the linux kernel) Oct 28 23:29:51 there are a few options that influence the build process I think, see "make help" for details Oct 28 23:44:36 I'm debugging u-boot in a stm32 MCU Oct 28 23:47:25 what? why would you ever want to run u-boot on one of those? o.O Oct 28 23:50:01 just for fun/learning... also the debug probe is includded in almost all boards Oct 28 23:50:15 unless you mean a stm32mp15 but I think st killed those a long time ago Oct 28 23:51:06 I have the stm32f429-discovery Oct 28 23:52:11 right, so u-boot makes zero sense Oct 28 23:53:31 mainline u-boot has no support for cortex-m to begin with Oct 28 23:54:00 why would you want to use a bloat like uboot on the m's? Oct 28 23:54:16 there's also nothing for it to load... the application you run is already in flash from which it can be directly executed Oct 28 23:54:20 defconfig files for that board are in mainline u-boot and linux.. u-boot is huge for that. there are smaller bootloader.. but i'm running u-boot just to debug it Oct 28 23:55:04 that thing runs linux? o.O Oct 28 23:55:17 that sounds like masochism Oct 28 23:57:16 8MB ram Oct 29 00:02:13 It wouldn't run crysis (?) Oct 29 00:15:54 Heh? Oct 29 00:16:38 I have not seen a bbb-drawing bot recently or ever now that I recall. I must do it! Do it for Danny! Oct 29 00:16:53 Be prepared! **** ENDING LOGGING AT Thu Oct 29 02:59:57 2020