**** BEGIN LOGGING AT Mon Feb 04 02:59:57 2019 Feb 04 03:00:47 pru's access to peripherals is not significantly faster than the cortex-a8's Feb 04 03:02:01 and yes there will be a pause after every byte Feb 04 03:05:51 Thanks zmatt that gives a bit clearer picture of it. Feb 04 03:20:10 so without DMA or FIFO there can only be a pause Feb 04 03:22:19 no, FIFO (and more so DMA) just reduce cpu burden: it avoids having to do stuff for each byte transferred Feb 04 03:22:40 but even without fifo you can have continuous data transfer without pauses Feb 04 03:22:55 but the pause will then be smaller than the SPI clock period Feb 04 03:23:01 ah ? Feb 04 03:24:28 as long as the TURBO flag is set, you can read the previous byte from the receive holding register and write the next byte into the transmit holding register while the current byte transfer is in progress Feb 04 03:25:06 (if TURBO is not set, it won't start a transfer until there's space in the receive holding register) Feb 04 03:26:11 I see Feb 04 03:27:49 so you'd do write first byte; loop{ wait TX event; write byte; wait RX event; read byte; }; read last byte Feb 04 03:28:52 sorry, with a final wait RX event before read last byte of course Feb 04 03:29:57 right Feb 04 03:31:06 linux's 802.15.4 isn't advanced enough for me to test all features of my driver: beacon mode, encryption, mesh Feb 04 03:31:48 so why exactly aren't you doing the byte transfers in the interrupt handler? I didn't even know mcspi supported clearing the irqstatus before performing the appropriate transfer Feb 04 03:32:40 I feel like having the interrupt handler pass events to a thread and doing byte transfers there is kinda silly Feb 04 03:33:08 (and wastes a lot of cpu time) Feb 04 03:33:27 my comrade thought it was cleaner I think Feb 04 03:33:31 but yeah that wastes time Feb 04 03:33:36 it really isn't Feb 04 03:34:04 it makes the code more prone to race conditions, makes the peripheral's behaviour more uncertain, and is incredibly inefficien Feb 04 03:34:07 t Feb 04 03:34:19 I see Feb 04 03:36:25 in my own driver since it's level-triggered I must read the IRQ status inside the ISR to release the interrupt line, otherwise it's called in a loop, so now since I use SPI inside an ISR that means I must disable interrupts everywhere else I use the SPI device Feb 04 03:36:40 or mask out that particular IRQ if possible Feb 04 03:37:17 (it is possible) Feb 04 03:37:23 at hardware level anyway Feb 04 03:38:18 but yes, that way you implicitly create mutual exclusion between the interrupt handler and other code related to that peripheral Feb 04 03:38:40 if you don't, you have to think very very very carefully about what you're doing Feb 04 03:39:15 having the irq handler send rtems events instead of directly accessing the peripheral doesn't change that fact, those rtems events are still shared state Feb 04 03:39:54 yeah Feb 04 03:40:05 but at least with events I can keep the SPI access in a single context of execution Feb 04 03:40:11 but it's not possible Feb 04 03:40:22 since it's level triggered I must read the IRQ status inside the ISR itself Feb 04 03:40:48 keeping SPI access in a single context of execution doesn't have intrinsic benefit though Feb 04 03:41:20 right Feb 04 03:41:50 seems like nobody likes 802.15.4/6LoWPAN Feb 04 03:41:52 what has intrinsic benefit is if all code that accesses shared state related to the spi peripheral and its driver is serialized Feb 04 03:42:17 but that's not the case in the code you showed Feb 04 03:42:35 since the irq handler could send rtems events at any time Feb 04 03:44:08 but the event handling itself isn't done immediately, it's done at the next event reading Feb 04 03:47:01 in linux the mac driver is half-finished, the phy driver has mysterious bugs, the userspace tools don't keep up with the novelties, there are mistranslations and stupid bugs in other tools Feb 04 03:47:18 6lowpan is underrated Feb 04 03:47:30 that doesn't surprise me Feb 04 03:47:52 the whole stack is probably written by some random people who needed to get their use of 6lowpan working Feb 04 03:48:17 yeah Feb 04 03:49:25 6lowpan hardware is not part of a typical linux system, so you basically end up with a similar situation as drivers for specific pieces of hardware: it all depends on who wrote it, but average quality will be lower than any "core" part of linux Feb 04 03:53:52 btw the TRM says that you're required to do the byte read/write *before* clearing the irqstatus bit... Feb 04 03:55:34 which is really interesting, since if they are event-triggered rather than level-triggered (which seems to be implied by the fact your code worked at all, and the requirement to clear irq status bits in the first place) then that would actually be a bit tricky since you'd have to be certain you clear the irq status within one byte-transfer-time of doing the byte read/write Feb 04 03:59:14 yeah, r/w before clearing irqstatus Feb 04 03:59:57 or you can just use dma to get max performance, least cpu usage, and not have to deal with any individual rx/tx events in the first place Feb 04 04:02:16 yeah Feb 04 04:02:20 (but it does require the receive buffer to either be in dma-coherent memory or aligned to cache write granule boundaries (16 bytes on the cortex-a8 iirc)) Feb 04 04:02:50 we'll figure that out Feb 04 04:03:41 (or, not necessarily aligned to I guess, but it can't share a granule with any memory that may be written by the cortex-a8 while the transfer is in progress) Feb 04 05:24:02 I have a situation with wpan-ping where linux doesn't send the ACK to my ping reply quick enough so there's a retransmission and wpan-ping eventually picks up the original reply and its retransmission Feb 04 05:24:15 so it shifts the sequence number and all subsequent ping requests are wrong Feb 04 05:24:41 and it enter an infinite loop because it doesn't sleep after a wrong sequence number has been detected Feb 04 05:24:55 and above all of that it spells it "sequenze number" Feb 04 05:25:08 in other words, wpan-ping is a buggy mess Feb 04 05:25:10 lol Feb 04 05:25:32 look at this magnificent code: https://paste.serveur.io/OwRThQQk.c Feb 04 05:25:41 hah, I like the title of the latest Kurzgesagt video... "Building a Marsbase is a Horrible Idea: Let’s do it! Feb 04 05:25:44 " Feb 04 05:26:01 lol Feb 04 05:27:40 I modified wpan-ping to flush the input queue and sleep before sending a new probe Feb 04 05:35:33 I don't think I understand what you're saying... why would you ever need to flush the input queue? Feb 04 05:36:40 because of linux failing to ACK in time Feb 04 05:36:45 there has been a retransmission Feb 04 05:36:55 so two ping responses await in the input queue Feb 04 05:37:12 that will shift the sequence number forever Feb 04 05:37:26 ?? Feb 04 05:37:31 "shift the sequence number" ? Feb 04 05:37:49 why don't you just discard received packets whose sequence number doesn't match what you expect? Feb 04 05:38:41 or better yet, log the fact you received a response to an old ping Feb 04 05:38:57 linux sends ping request with sequence 10, BBB responds with ping reply with sequence 10, linux fails to ACK in time so I send ping reply with sequence 10 again, linux reads ping reply with sequence 10, all is fine, then linux sends ping request with sequence 11, then reads the ping reply with sequence 10 that sleeps in the input queue Feb 04 05:39:03 there is a new mismatch, the cycle repeats Feb 04 05:39:14 why do you send another ping with the same sequence number? Feb 04 05:39:31 and you should never have packets sit in your input queue, just process them whenever they arrive Feb 04 05:39:48 well I did not code wpan-ping, but yeah the code isn't that great Feb 04 05:40:09 also ew @ the gettimeofday code, use clock_gettime with CLOCK_MONOTONIC Feb 04 05:40:37 wait, wtf Feb 04 05:40:50 it's in the wpan-tools suite of tools Feb 04 05:40:54 in every distro repository Feb 04 05:40:56 it's taking the min/max over sec and usec separately? Feb 04 05:42:05 apparently yes Feb 04 05:44:40 it really isn't that hard to make a ping utility that isn't broken... send pings on a timer, make sure each ping transmitted has a unique identifier (e.g. a sequence number, with no retransmits), track which pings have not received a reply and when the ping was sent, process replies as they are received Feb 04 05:44:52 handle timeouts of unanswered pings Feb 04 05:44:57 yeah Feb 04 05:45:16 wpan-ping has basically a for (;;) { send(); recv(); check_seq(); sleep(); } Feb 04 05:45:16 this allows multiple pings to be in flight, allows detection of duplicates or otherwise completely bogus packets Feb 04 05:45:23 everything can go wrong in this loop Feb 04 05:45:35 also they don't sleep if the sequence number is wrong Feb 04 05:45:46 so that makes a ping-pong of reply as fast as the wireless medium permits it Feb 04 05:45:50 lol Feb 04 05:46:42 also, use packet timestamping if supported. even software-timestamping done by the kernel is better than timestamping done in userspace Feb 04 05:51:33 how would you do that ? Feb 04 05:51:39 I'm searching the mans but I don't find much Feb 04 05:52:30 especially in stuff like recvmsg() Feb 04 05:56:29 ah Feb 04 05:56:30 I found it Feb 04 05:56:33 SO_TIMESTAMP Feb 04 05:56:43 then get this back with recvmsg Feb 04 05:59:43 https://www.kernel.org/doc/Documentation/networking/timestamping.txt Feb 04 06:00:41 SO_TIMESTAMPING is the most versatile option Feb 04 06:05:04 I see Feb 04 06:05:19 i.e. setsockopt(fd, SOL_SOCKET, SO_TIMESTAMPING, &val, sizeof(val)); where e.g. int val = SOF_TIMESTAMPING_RX_SOFTWARE | SOF_TIMESTAMPING_TX_SOFTWARE | SOF_TIMESTAMPING_OPT_ID | SOF_TIMESTAMPING_OPT_TSONLY Feb 04 06:10:02 note: I don't know for sure of course whether this works for wpan, but I feel it ought to Feb 04 06:10:33 there's also sample code for packet timestamping in the linux kernel tree, tools/testing/selftests/networking/timestamping/ Feb 04 06:10:59 anyway, using packet timestamps is a relatively minor thing, it just improves accuracy Feb 04 06:11:03 everything else is more important Feb 04 06:22:24 I don't know why linux doesn't send the ACKs fast enough, it should be done in hardware Feb 04 06:22:26 or is it ? Feb 04 06:22:34 maybe linux does this in software Feb 04 06:22:38 that would be pretty dumb Feb 04 06:22:50 I know linux has a "softmac" implementation Feb 04 06:22:51 didn't you say it used a softmac stack? Feb 04 06:22:54 yeah Feb 04 06:23:29 still I'd assume it replies pretty fast Feb 04 06:23:41 what is "not fast enough" in this context? Feb 04 06:24:06 a couple of microseconds, it's specified precisely in the datasheet Feb 04 06:24:25 wpan-ping expects a reply within microseconds? Feb 04 06:24:44 datasheet of what? Feb 04 06:25:17 there is no way a softmac stack running on a beaglebone is going to reply to anything in microseconds Feb 04 06:25:23 I'm talking of ACKs at 802.15.4 level Feb 04 06:25:38 it's more like milliseconds with the default settings Feb 04 06:26:08 if those are required to be given in microseconds, then that would exclude any software implementation basically Feb 04 06:26:10 the standard mandates that after 912µs without an ACK we can retransmit Feb 04 06:26:24 okay that's not "microseconds", that's nearly a milisecond Feb 04 06:26:44 yeah I didn't remember quite right the value Feb 04 06:26:59 I knew it was in multiples of 16µs, but not how many multiples Feb 04 06:27:41 what spi transfer speed are you using? Feb 04 06:27:54 since the slower the spi bus, the less time there will be to give a reply Feb 04 06:28:28 2.5MHz Feb 04 06:28:46 3.2 us per byte Feb 04 06:29:44 for ACK done in software yes Feb 04 06:30:09 but even with the softmac stack it appears that the ACKs are done in hardware Feb 04 06:30:10 is that the max speed supported by the chip you're using? Feb 04 06:30:19 5MHz is the max speed Feb 04 06:31:30 with promiscuous mode disabled, hardware ACKs are enabled: https://github.com/torvalds/linux/blob/master/drivers/net/ieee802154/mrf24j40.c#L1007 Feb 04 06:31:33 so why exactly do you think that ACKs are being produced after too much time? Feb 04 06:31:53 since it sounds like that's impossible Feb 04 06:31:55 it was my main hypothesis, but now it is no more Feb 04 06:37:22 the subject of the project was "secure IOT" after all, but we have no encryption yet Feb 04 06:37:28 lol Feb 04 06:38:02 we deviated "secure" so that it means "correct", like software without bug Feb 04 06:38:05 but we still have bugs Feb 04 06:38:16 but at least that's something we can talk on Feb 04 06:38:39 there is encryption for 802.15.4 in linux, but only in software Feb 04 06:38:46 but the module knows how to encrypt Feb 04 06:38:59 but I guess that on something that is large enough to support linux there's no need to offload that Feb 04 06:39:09 so there's no need to implement it Feb 04 06:39:26 by module I mean piece of hardware Feb 04 06:39:38 btw, you said earlier "linux's 802.15.4 isn't advanced enough for me to test all features of my driver: beacon mode, encryption, mesh" ... but when I briefly looked at the linux 802.15.4 code I immediately saw encryption stuff Feb 04 06:39:55 yeah that's the llsec part in the softmac Feb 04 06:40:13 I just saw that too Feb 04 06:40:36 let's just hope it's compatible with the specified encryption Feb 04 06:41:25 but still, the userspace tools don't look compatible with that llsec thing Feb 04 06:41:37 that sounds odd Feb 04 06:42:13 there's a dodgy branch on the git that looks like implementing it Feb 04 06:42:21 but it wouldn't suffer a fresh rebase on top of master Feb 04 06:42:28 https://github.com/linux-wpan/wpan-tools/tree/nl802154_llsec Feb 04 06:43:48 and the netlink interface support is still marked experimental in the kernel Feb 04 06:43:54 that's still something I can try Feb 04 06:50:07 ok, I rebased it without too much conflicts Feb 04 06:50:12 maybe that'll work on first try Feb 04 07:01:47 I need a kernel with the experimental interface also Feb 04 07:01:52 let's see this after a night of sleep Feb 04 07:01:55 good night Feb 04 07:03:52 good night Feb 04 09:38:07 Hi all! Feb 04 09:38:18 I'm back with some questions on device trees. Feb 04 09:39:18 I have a beaglebone black with LCD cape, which needs custom device tree entries to work. Feb 04 09:39:34 I'm working with Buildroot instead of the official Debian image. Feb 04 09:41:10 To debug the loading of device trees, I boot with manually entered commands in U-Boot: Feb 04 09:41:29 1) load mmc 0:1 $fdtaddr am335x-boneblack.dtb Feb 04 09:41:36 2) load mmc 0:1 $loadaddr zImage Feb 04 09:42:14 3) setenv bootargs  console=ttyO0,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext4 rootwait Feb 04 09:42:22 4) bootz $loadaddr - $fdtaddr Feb 04 09:42:37 This works with the default am335x-boneblack.dtb Feb 04 09:43:11 Let's dump the device tree of the now running buildroot system by: Feb 04 09:48:27 dtc -I fs -O dtb /proc/device-tree/ -o /boot/am335x-boneblack-dtc.dtb Feb 04 09:49:15 This gives a number of warnings like: Feb 04 09:49:24 Warning (status_is_string): "status" property in /ocp/timer@48040000 is not a string Feb 04 09:49:42 Warning (unit_address_vs_reg): Node /ocp/ethernet@4a100000/slave@4a100200 has a unit name, but no reg property Feb 04 09:50:00 Now I want to run Linux with this new device tree. Feb 04 09:50:06 So I replace 1) by: Feb 04 09:50:22 1) load mmc 0:1 $fdtaddr am335x-boneblack-dtc.dtb Feb 04 09:53:13 Now it is unable to boot, last console message is: Feb 04 09:53:24 Starting kernel ... Feb 04 09:53:47 So the round-trip via /proc/device-tree --> dtc --> dtb file is lossy! Feb 04 09:54:27 (I wanted to use dtc -I fs to "harvest" the working device tree from the Debian system, that's why I investigated that.) Feb 04 09:54:56 zmatt: any idea why the round-trip via "dtc -I fs -O dtb /proc/device-tree" fails? Feb 04 11:06:45 tistolz: no, apart from that it's definitely not something that's intended to work in the first place Feb 04 11:10:07 tistolz: if you want to customize the DT, do so based on the original dts Feb 04 11:10:33 you can just #include "am335x-boneblack.dts" and add your custom definitions below it Feb 04 11:14:21 oh actually I do know why it doesn't work: /proc/device-tree does not show the original DT as it was passed to the kernel, but a live view of the data structures built from the DT. some kernel code modifies these data structures, in particular the dmtimer peripheral used as system timer is given a status="disabled"; property to ensure it is not used by normal driver Feb 04 11:14:57 (except it apparently does so in a buggy way, since it's missing the 0-terminator. dtc correctly gave a warning for this) Feb 04 11:15:32 even if this weren't a problem, e.g. if you decompile the original dtb instead, then it'll still break horribly if you attempt to add any definitions to it Feb 04 11:44:11 zmatt: thank you very much for your answers, I was at lunch Feb 04 11:45:53 zmatt: I've had a look at your https://pastebin.com/b8kZfhRG and want to apply this to https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-BONE-4D4R-01-00A1.dts Feb 04 11:47:20 So I'll translate from bottom "overlay fragment node" syntax to top "normal dts fragment"? Feb 04 11:55:06 yes Feb 04 13:47:47 zmatt: Hi, my LCD cape is now working partly - but still no backlight! Feb 04 13:48:09 What works is: I get a /dev/fb0 from tilcdc, which has the right size Feb 04 13:49:04 (determined by dd if=/dev/urandom of=/dev/fb0 bs=1024 --> 255 blocks written; 255*1024 / 480 columns / 2 bpp = 2 rows) Feb 04 13:49:51 oops, I meant 272 rows Feb 04 13:50:13 lol, you can just check the video mode in sysfs Feb 04 13:51:28 cat /sys/class/drm/card0-LVDS-1/modes or /sys/class/graphics/fb0/modes Feb 04 13:52:13 you can also check /sys/class/drm/card0-LVDS-1/dpms to see whether the display is blanked Feb 04 13:52:32 OK, I get "480x272" in the first, "U:480x272p-0" in the second Feb 04 13:52:55 and "On" in the dpms file Feb 04 13:52:57 sorry I mean, in standby/off mode (I think it can be blanked without dpms) Feb 04 13:53:54 Using the debian image, I found out that the picture gets completely invisible when I turn the backlight to zero brightness (even with a max-white rectangle on black background). Feb 04 13:54:04 anything in /sys/class/backlight/ ? Feb 04 13:54:26 No, the directory is completely empty! Feb 04 13:54:31 And I get kernel error messages Feb 04 13:54:50 pwm-backlight backlight: GPIO lookup for consumer enable Feb 04 13:54:58 pwm-backlight backlight: using device tree for GPIO lookup Feb 04 13:55:12 of_get_named_gpiod_flags: can't parse 'enable-gpios' property of node '/backlight[0]' Feb 04 13:55:22 of_get_named_gpiod_flags: can't parse 'enable-gpio' property of node '/backlight[0]' Feb 04 13:55:23 please don't paste multiline output into irc, use pastebin instead Feb 04 13:55:47 sorry! Feb 04 13:55:56 I think the problem is already obvious Feb 04 13:56:15 It searches for a property in the device tree, which it cannot find Feb 04 13:56:17 the only question is why the pwm-backlight binding requires a gpio Feb 04 13:56:39 which I guess is something patched out in the beaglebone kernel Feb 04 13:57:10 For your reference, I'm using a 4.14.96 mainline kernel. Feb 04 13:57:13 it does appear the lcd has an enable signal though, gpio 3.19 Feb 04 13:57:56 Actually it would be enough if the backlight worked, I could easily check that (no matter of what the state of the LCD is) Feb 04 13:58:36 so maybe you should move that signal from lcd pins to backlight pins, and add enable-gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>; to the pwm-backlight node Feb 04 14:01:47 hi to all, first time joining this chat. I had a problem with a BBB using a modem cape, installed ModemManager + connman, modem is connected but there's no data transfer; is it the right place to ask for help? Feb 04 14:01:55 zmatt: So you are talking about the &am33xx_pinmux { ... } fragment Feb 04 14:04:57 https://pastebin.com/7uuKTe58 Feb 04 14:06:03 btw, for all nodes you create yourself (such as /backlight and /panel), the status = "okay"; line is completely pointless and can be removed Feb 04 14:06:41 (status = "okay"; is only needed if it's overriding a status = "disabled"; property in a previous declaration of the node) Feb 04 14:10:24 actually Feb 04 14:10:26 never mind Feb 04 14:10:27 undo this Feb 04 14:11:25 as far as I can tell, those messages are debug messages, not errors Feb 04 14:12:19 they 100% are Feb 04 14:13:24 those messages you copy-pasted are irrelevant and not the cause of your problem Feb 04 14:26:13 zmatt: Now I'm getting these messages: , using this dts file: (the copyright at the top stems from the Github file) Feb 04 14:26:45 please read what I just said Feb 04 14:27:02 about the irrelevant kernel messages? Feb 04 14:27:55 so this "enable-gpios" stuff is optional? Feb 04 14:27:56 about me saying you should ignore/undo the changes I suggested since the "errors" you copy-pasted are not errors at all but completely benign debug messages Feb 04 14:28:17 you may want to turn down the log level to find *actual* errors Feb 04 14:29:08 e.g. journalctl -k -p warning -b will give all kernel log messages of priority 'warning' or higher Feb 04 14:30:13 There is no systemd in a buildroot system :) It is all just busybox... Feb 04 14:30:34 ew Feb 04 14:30:59 There is a -n option for dmesg Feb 04 14:31:08 actually buildroot supports systemd Feb 04 14:31:13 as option Feb 04 14:31:26 sorry, there is no systemd in *my* buildroot Feb 04 14:31:39 I meant :) Feb 04 14:34:32 With "dmesg -r" I can see the loglevel Feb 04 14:35:39 Most lines from pwm-backlight are level 7, but this is level 4: Feb 04 14:35:41 pwm-backlight backlight: backlight supply power not found, using dummy regulator Feb 04 14:35:52 that's fine Feb 04 14:40:25 OK, I found https://lwn.net/Articles/568035/ (This series adds the ability to specify a GPIO and a power supply to Feb 04 14:40:25 enable a backlight.) So it is clear that this stuff is completely optional. Feb 04 14:44:50 ... reading through [linux kernel]/Documentation/devicetree/bindings/{leds/backlight/pwm-backlight.txt, pwm/pwm.txt} ... Feb 04 14:46:27 I don't think there's any difference between mainline and the beaglebone kernels w.r.t. the pwm-backlight driver Feb 04 14:47:49 Ah ok, so why does it fail? :'( Feb 04 14:50:11 (unrelated) btw, you should remove the #address-cells and #size-cells properties from your / {}; block Feb 04 14:50:20 (it doesn't belong in the overlay either) Feb 04 14:51:16 also wtf is that /fb block at the bottom? that is very wrong Feb 04 14:51:23 that's in the original overlay too? o.O wtf Feb 04 14:54:17 that should be replaced by &lcdc { status = "enabled"; }; Feb 04 14:54:26 (at top-level) Feb 04 14:55:10 oh it has that *too* ? Feb 04 14:55:24 Yes but with "status = "okay" " Feb 04 14:55:27 :) Feb 04 14:55:35 sorry, status = "okay"; Feb 04 14:55:36 my bad Feb 04 14:56:03 but wtf @ that duplicate definition of the lcdc peripheral Feb 04 14:56:37 I'm surprised that doesn't fail horribly and spectacularly Feb 04 14:56:52 I guess for one of them the probe fails due to inability to request the irq Feb 04 14:57:23 Hi I have X11 going into screensaver despite DPMS is disabled with "xset -dpms" and confirmed by "xset q". Any other screensaver (outside X) to check ? Feb 04 14:57:33 xset s 0 Feb 04 14:58:26 or maybe it was xset s off Feb 04 14:58:52 checking.... how to set it permanently ? .xinitrc ? Feb 04 14:59:34 Git blame shows the following commit by RobertCNelson as the origin of that strange code: Feb 04 14:59:40 https://github.com/beagleboard/bb.org-overlays/commit/6571f620a9e0d6ab266982e6fd96b77a5ab7cb14 Feb 04 15:00:04 that's just the import of those overlays Feb 04 15:00:21 rcn presumably didn't examine them closely Feb 04 15:02:05 Newbie here. I want to use the beagleboard x15 as a starting point for an industrial controller. I installed ubuntu 18.04 for the long term support. that went ok but I can't seem to install any desktop. gnome, ldxe, others just boot to blinking cursor . Am I running out of storage? Feb 04 15:03:47 zmatt: where would you put stty commands to set uart parameters at boot ? Feb 04 15:07:59 Documentation/devicetree/bindings/pwm/pwm.txt says: Feb 04 15:07:59 "PWM controller nodes must specify the number of cells used for the specifier using the '#pwm-cells' property." Feb 04 15:08:22 ... which the &ehrpwm1 node does NOT! Feb 04 15:08:52 ... adding a "#pwm-cells = <1>;" ... Feb 04 15:09:57 fred__tv: a serial port is configured by the program that uses it Feb 04 15:10:05 (normally after opening it) Feb 04 15:11:12 I have my own script , should I add inside it ?? is there a "system wide" setting ? Feb 04 15:11:22 tistolz: that's wrong Feb 04 15:11:34 tistolz: it most definitely does have #pwm-cells in mainline 4.14.96 Feb 04 15:11:44 (and the correct value is 3) Feb 04 15:12:10 tistolz: https://elixir.bootlin.com/linux/v4.14.96/source/arch/arm/boot/dts/am33xx.dtsi#L796 Feb 04 15:16:01 OK Feb 04 15:16:34 BTW, I built against an am335x-boneblack.dts from uboot, not from linux Feb 04 15:16:53 please don't Feb 04 15:17:05 The two are different, and - most striking - the one from uboot has a / { hdmi { ... } } entry. Feb 04 15:17:22 the dts files in the uboot tree are meant purely for uboot's private use and are not passed to the kernel (afaik) Feb 04 15:17:47 they're typically based on the kernel dts files, but can be older by an arbitrary amount Feb 04 15:18:00 always use the dts files that are included with the kernel you're using Feb 04 15:19:15 for your reference, this is the uboot file: https://pastebin.com/4Cv3wgGv Feb 04 15:19:23 https://elixir.bootlin.com/linux/v4.14.96/source/arch/arm/boot/dts/am335x-boneblack.dts is the Linux one Feb 04 15:21:17 OK, I'll compile the dts next time using the Linux version... Feb 04 15:23:18 But there is something I found in https://elixir.bootlin.com/linux/v4.14.96/source/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt Feb 04 15:23:51 Required properties: [...] - power-supply: regulator for supply voltage (line 13) Feb 04 15:27:10 it's not required Feb 04 15:27:38 as the kernel log message said, it will implicitly use the dummy regulator if missing Feb 04 15:27:49 ah that's it Feb 04 15:32:50 hmmmm..... why cd /home/dir and ./myscript.sh write a file into same direcory but /home/dir/myscript.sh invoked from / doesnt ? Feb 04 15:32:56 both run as root Feb 04 15:34:12 . /home/dir and myscript.sh owned by root Feb 04 15:42:09 fred__tv: relative paths are relative to the current directory. the location of the program/script is not relevant for that Feb 04 15:44:01 what a stupid.... :-(( Feb 04 15:44:17 no, otherwise not even "ls" would work Feb 04 15:44:21 what a shame.... Feb 04 15:44:34 me Feb 04 15:45:31 it's not a shame, the whole notion of "current directory" would make no sense otherwise Feb 04 15:47:34 you can determine the location of your program anyway, it is passed as argument ("$0"), so you can recover the directory in which your program is located if you really need to Feb 04 15:48:08 cd "${0%/*}" Feb 04 15:48:32 but why does it matter? just set the current directory correctly Feb 04 15:48:35 I mean shame on me, it is clear it can't work.... Feb 04 15:48:44 ah ok Feb 04 15:48:45 in fact... Feb 04 15:50:01 e.g. if you're making a startup service, just set WorkingDirectory correctly in your service file (see example: https://pastebin.com/KXVdTNrL ) Feb 04 16:05:37 interesting...! Feb 04 16:13:47 zmatt: A big fat THANK YOU! The LCD cape including backlight is now working! Feb 04 16:14:24 zmatt: All I did is compile with the Linux-supplied am335x-boneblack.dts (instead of using the uboot one) Feb 04 16:15:03 You were completely right about not using the u-boot supplied dts files! Feb 04 16:59:35 zmatt: are you still online? I owe you a virtual chocolate cake! Feb 04 19:41:26 bigeul Feb 04 21:26:51 the experimental 802.15.4 llsec crashed my raspberry pi Feb 04 21:26:58 kernel:[ 9218.662780] Code: bad PC value Feb 04 21:27:03 that's not very reassuring Feb 04 21:40:53 can you pastebin the whole traceback? Feb 04 21:44:13 I built the modules out of tree with the new config defines; but now I'm building it cleanly in-tree Feb 04 21:44:21 and I'll see if there is still the problem Feb 04 21:44:30 lol Feb 04 21:44:47 okay never mind, in that case I don't even care to see the traceback Feb 04 21:44:52 lol Feb 04 21:45:13 the config define just enabled some code in that precise module, it shouldn't hurt to build it like that Feb 04 21:45:15 but apparently it does hurt Feb 04 21:46:57 why even attempt to do it like this though? the kernel already does a decent job at avoiding unnecessary recompilation when running make after changing config Feb 04 21:49:15 ah, I thought I had to clean and rebuild and that it'd take time Feb 04 21:49:24 but if it detects changes it's .config it's fine Feb 04 21:49:26 thanks for the advice Feb 04 22:19:21 ok ok Feb 04 22:19:27 it doesn't bug anymore Feb 04 22:21:38 so, I had to enable the experimental 802.15.4 llsec support in the kernel, and rebase the llsec patches on the latest wpan-tools to get the userspace part Feb 05 01:49:50 Anyone familiar with the PRU setup? I am trying to go though the TI guide http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs. however I am only seeing /sys/class/remoteproc/remoteproc0 enabled. Any ideas on how to load the remoteproc1 & remoteproc2? Feb 05 01:50:36 ninjahipster: uhh, why would there be that many remoteproc devices? Feb 05 01:50:47 * zmatt checks wiki page Feb 05 01:51:03 remoteproc0 is the m3, remoteproc1 and 2 are the two PRU's Feb 05 01:51:47 ah. are you using the latest image? you can select between uio-pruss and remoteproc-pru in /boot/uEnv.txt, but the default is remoteproc Feb 05 01:52:35 I am using the ti-4.19 Feb 05 01:52:55 if you're using an old image, get the latest debian image from the site. if you're booting from sd card, reflashing eMMC is recommended, or otherwise at least wipe eMMC using sudo blkdiscard /dev/mmcblk1 Feb 05 01:53:42 you mean you manually installed a different kernel? why? Feb 05 01:54:38 I don't know whether everything works in the 4.19-ti series yet, it may be wise to stick to the default 4.14-ti series if you simply want things to work Feb 05 01:56:28 yeah, I have built from source https://www.digikey.com/eewiki/display/linuxonarm/BeagleBone+Black. I have also tried 4.14 and 4.4, along with the current prebuilt version BB.org has out. It seems only the remoteproc0 is enabled in any of them. Feb 05 01:58:11 why are you not just using the latest recommended image? Feb 05 01:58:35 the latest prebuilt definitely has remoteproc-pru working by default Feb 05 01:59:11 beware that if you have an old image (more specifically an old bootloader) installed on eMMC, booting a new image from sd card may have DT issues which could cause problems like these Feb 05 02:00:07 hence my recommendation to either reflash eMMC, or if you prefer booting from sd then erase eMMC to ensure the bootloader on SD is used rather than whatever is on eMMC Feb 05 02:01:16 (you can also temporarily force eMMC to be bypassed by holding down the S2 button (the button closest to the card slot) while powering on. you can let go of the button when the power led turns on) Feb 05 02:05:17 oh, he left Feb 05 02:32:12 I think I have this BBBlue hooked up to fly now! Feb 05 02:32:37 I am waiting on a xt60 (female) to show up. Then, off to the races. Cough! Finally. Feb 05 02:32:57 I guess myself could not wait. Feb 05 02:34:23 I did learn something. Power the receiver via a separate battery supply, i.e. 9v. Now, I just need to solder in a dual connection once the xt60 shows face. Boom! Flying high! Feb 05 02:35:25 Is anyone messing we the quadrature encoder inputs on the BBBlue for Flying? Feb 05 02:35:57 Well... Feb 05 02:36:11 Let me rephrase that question. Feb 05 02:37:12 Can the quadrature encoder inputs on the BBBlue associate/communicate w/ the Signal input on a Receiver via Sbus? Feb 05 02:38:20 google stops shy of understanding that question... Feb 05 02:41:59 I mean...I understand that the electricity is there and flowing. I just do not understand how it can work just yet. "Knowing is half the battle." Am I right? Feb 05 02:43:43 zmatt: Once you showed me a page online via Linux' Sbus protocol/software ideas. I will look that up. Feb 05 02:46:25 https://github.com/torvalds/linux/tree/master/drivers/sbus/char is what I found so far. Feb 05 02:48:37 Looks like a foreign language to me right now. **** ENDING LOGGING AT Tue Feb 05 03:00:01 2019