**** BEGIN LOGGING AT Thu Apr 21 02:59:57 2022 Apr 21 09:52:00 This is what I have done to put file system in read only mode: https://pastebin.com/cvdL9q1e Apr 21 09:53:26 I'm not familiar with overlayroot, sorry, but the fact that it's doing journal recovery implies the filesystem is in fact not mounted readonly Apr 21 09:55:44 to switch off file recovery I goggled this solution, but no change to startup time. https://raspberrypi.stackexchange.com/questions/88721/how-to-avoid-fsck-at-boot-timing-out Apr 21 09:56:08 journal recovery is the fastest form of recovery, any alternate will be worse Apr 21 09:57:01 if you want better, you need to avoid an unclean filesystem entirely, which means either unmounting the filesystem prior to power loss, or mounting it readonly Apr 21 09:58:17 the problem is that it is a fresh installed image and it has no power loses Apr 21 10:01:31 maybe I should turn off read only mode, do all checks and make read only again? Apr 21 10:05:01 that's pointless since the filesystem *isn't* mounted readonly Apr 21 10:05:09 if it were, you wouldn't get this message Apr 21 10:05:55 if you're getting this even after a clean reboot, my guess would be overlayroot is somehow messing up the system's ability to unmount the root filesystem at shutdown Apr 21 10:08:40 how can I check it? Apr 21 10:11:18 hmm, if you remove "quiet" from the kernel parameters (in the cmdline variable in /boot/uEnv.txt) then you'd be able to observe messages about it via the serial console during shutdown Apr 21 10:12:14 OK, 1 sec Apr 21 10:15:21 also, for reference, this is what it looks like if the root filesystem is actually being mounted readonly: https://pastebin.com/raw/wLMPgZUG Apr 21 10:16:50 of course when using overlayfs it's technically not even the root filesystem, so things will look different anyway Apr 21 10:32:22 https://pastebin.com/KszgK0JX Apr 21 10:34:31 Siegurd: this looks like your filesystem was unclean the first time and clean the second time.... but don't forget that whether the filesystem is clean or unclean at boot will depend on your *previous* boot Apr 21 10:35:42 and this is also not providing any useful info about what may be causing the unclean filesystem, for which you need to capture what's happening at shutdown when using overlayroot, not what's happening at boot Apr 21 10:37:01 https://pastebin.com/7w1sT7Q9 Apr 21 10:37:11 shutdown log Apr 21 10:39:23 yeah it looks like systemd doesn't know/understand what overlayroot did, so it's remounting the overlayfs (which is the rootfs) read-only, but not the _real_ underlying filesystem... which is something which overlayroot should probably take care of instead, but evidently it doesn't Apr 21 10:39:49 also, I'm not seeing any kernel messages here, did you remove the "quiet" option from your kernel parameters? Apr 21 10:48:40 this is full UART log of startup and shutdown with overlayroot=tmpfs and deleted "quiet" option in /boot/uEnv.txt https://pastebin.com/egDvMr0a Apr 21 10:51:39 hmm, the kernel doesn't log to the serial console even without quiet? annoying, must be a setting somewhere Apr 21 10:51:53 during shutdown I mean Apr 21 10:52:41 maybe the journal can help? Apr 21 10:53:38 but also, I don't see the problem you claim to be having... this boot was clean Apr 21 10:53:58 line 359, "rootfs: clean" Apr 21 11:04:51 ok, will try to do a clean install if image one more time on weekend Apr 21 11:05:16 ... but, it seems to be working fine right now? Apr 21 11:05:23 of image Apr 21 11:05:24 I dunno Apr 21 11:05:38 unless your previous boot was non-overlayroot Apr 21 11:06:20 no, it still adds +10 seconds to booting process Apr 21 11:07:03 Startup finished in 19.397s (kernel) + 32.540s (userspace) = 51.938s Apr 21 11:07:20 well not in the log you just showed, so so was your previous boot (prior to the one whose log you just pastebinned) non-overlayroot ? Apr 21 11:09:38 note btw that initramfs (which is required for overlayroot) also adds boot time (about 11 seconds on my system) Apr 21 11:10:29 maybe that's the reason... Apr 21 11:11:20 well, you're using initramfs in both cases here Apr 21 11:11:27 with or without overlayroot Apr 21 11:12:08 I add my C++ program to run as a service with Before=basic.target Apr 21 11:12:08 After=local-fs.target sysinit.target Apr 21 11:13:04 hope you know what you're doing Apr 21 11:13:27 why are you ordering your service before basic.target ? that sounds like a recipe for slowing down boot Apr 21 11:14:13 when on fresh installed image it runs (my gpio LED starts flashing) in 30 seconds. When I switched to read only mode my program starts after 30+12=42 seconds. Apr 21 11:14:48 it's possible overlayroot's scripts just take more time (e.g. to load the necessary drivers and executables from filesystem) Apr 21 11:15:12 who knows Apr 21 11:15:26 zmatt: I am getting no suitable conversion function from sysGpio to sysGpio *" exists Apr 21 11:15:41 when I try to use one of the functions Apr 21 11:16:01 will pastebin Apr 21 11:16:04 one momemnt Apr 21 11:16:17 mattb0ne: pass e.g. &GPIO0 as argument Apr 21 11:17:24 tbh I'm not completely sure why I defined those macros like I did... I guess to be similar to how TI's own headers for peripherals work Apr 21 11:17:37 ok let me try that Apr 21 11:18:12 mattb0ne: also, did you catch the last things I said before you left? (at the top of https://libera.irclog.whitequark.org/beagle/2022-04-21 ) Apr 21 11:19:22 mattb0ne: also, I documented it in my header (line 68 of https://pastebin.com/anqLbyav ) Apr 21 11:20:29 the unicode thing Apr 21 11:20:35 i just read it now Apr 21 11:21:33 and beware of your macros... I'm not sure you want to use macros for this anyway, but if you do you should definitely wrap their definitions in parentheses Apr 21 11:23:31 why before basic.target? cuz I need start C++ program as soon as possible after powerup. And after sysinit.target the fs and necessary drivers to work my program are loaded. Maybe I can delay or switch places other "heavy" services? That may be a solution. So my program will start at the wary beginning, and after that all other services will have delayed start. Apr 21 11:24:17 Before=something does not cause your service to start sooner, it causes that something to start later Apr 21 11:24:22 it's a way to delay other things Apr 21 11:25:02 normally systemd tries to start things in parallel as much as possible, which typically results in the most efficient startup Apr 21 11:25:31 beware btw that services by default have an implicit After=basic.target unless you have DefaultsDependencies=no Apr 21 11:25:38 but we have 1 core CPU so... Apr 21 11:25:52 yes, but processes often spend time blocked on stuff Apr 21 11:26:12 during which other processes could do useful work Apr 21 11:30:28 I mean that for example usb modem handling service could be delayed cuz my program don't use it for work. Apr 21 11:30:41 also, ordering yourself between sysinit.target and basic.target is fairly useless Apr 21 11:31:49 basic.target is generally reached a fraction of a second after sysinit.target Apr 21 11:32:36 https://pastebin.com/rgCHhJP2 Apr 21 11:33:13 the main thing that happens is starting socket listeners, and you almost always want to be ordered after that Apr 21 11:33:43 i was trying to make compile time constants you dont do that with #define? Apr 21 11:33:45 in general, you almost always want to be ordered after basic.target, which is of course exactly why systemd adds an implicit After=basic.target dependency to services by default Apr 21 11:33:49 mattb0ne: no Apr 21 11:34:03 mattb0ne: #define creates macros Apr 21 11:34:21 which are basically just compile-time search-and-replace Apr 21 11:35:09 ok use const? Apr 21 11:35:52 mattb0ne: for now just forget what I said about making those coefficients compile-time constants, it's probably the least important thing I've said of everything in your code Apr 21 11:36:05 lol ok Apr 21 11:36:08 it may not even matter at all Apr 21 11:36:13 which I did add almost immediately Apr 21 11:36:39 your old version was definitely better, since your macro version is completely broken Apr 21 11:42:08 ok Apr 21 11:43:29 whenever you use macros, you need to be really careful since like I said, it's literally just compile-time search-and-replace, i.e.: https://pastebin.com/raw/kVagz3dg Apr 21 11:45:07 (and for macros with arguments, those arguments are likewise substituted directly, basically as text, into the macro expression... not as values like they would be for function calls) Apr 21 11:47:04 i see Apr 21 11:47:07 question for you Apr 21 11:47:28 so I just jammed an array in shared_vars in the C code Apr 21 11:47:40 how would i specify the array on the python side Apr 21 11:47:48 python doesnt have arrays Apr 21 11:47:53 right? Apr 21 11:48:28 it does, but in this case you're specifically asking about ctypes, whose syntax for array types is type * count Apr 21 11:50:39 note that an array should have the same alignment as its base type, i.e. an array of 16-bit integers should have 2-byte alignment Apr 21 11:50:58 (to ensure compatibility of structures between python and pru) Apr 21 11:55:56 can you do a quick example I learn better that way Apr 21 11:56:09 16 bit alignment Apr 21 11:56:35 i have uint16_t signal[1000] in the C code Apr 21 11:56:45 the total size of the fields *prior* to it should be a multiple of 2 bytes Apr 21 11:56:50 I can do signal uint16_t *1000 Apr 21 11:57:02 yep, that's how you declare that type on the python side Apr 21 11:59:14 so I have a u32 u32 and u16 in front of that so that is 4+4+2=10 in bytes so I would need a padding of 6 bytes to get 16 Apr 21 11:59:37 i could do another array like u16*3 Apr 21 11:59:49 before and that would be put me at 2^4 Apr 21 11:59:51 no, multiple of 2 bytes (16 bits) Apr 21 11:59:55 not multiple of 16 bytes Apr 21 12:00:14 so you're already fine, no padding needed Apr 21 12:01:16 another simple rule: if your struct elements are sorted by alignment, with the elements requiring the greatest alignment first and the elements requiring the least alignment last, you're always fine Apr 21 12:02:12 e.g. if you've got u32 elements first, followed by just u16 elements (whether individual or part of an array) then you're fine Apr 21 12:02:19 ok Apr 21 12:02:38 one last question for ya Apr 21 12:02:43 writing to memory from python Apr 21 12:02:49 I need to fill that array with points Apr 21 12:07:37 so what's the question? Apr 21 12:07:53 you can just access it like an array Apr 21 12:10:25 can i do a block assignment Apr 21 12:10:31 or do I have to assign one by one Apr 21 12:11:24 you can do block assignment, e.g. shmem.signal[:] = [0] * len(shmem.signal) would fill it with all-zeros Apr 21 12:12:52 just don't try to assign to shmem.signal itself, you do always need to index (even if it's just [:] to slice the entire array contents) Apr 21 12:13:33 ok Apr 21 12:57:29 journalctl /lib/systemd/systemd -b gives me a log of systemd startup. But it shows only description of the services not their file names (ex. it shows "D-Bus System Message Bus" but I want "dbus.service" instead). Apr 21 13:01:16 journalctl -o with-unit -b Apr 21 13:02:41 oh that doesn't help for this Apr 21 13:03:10 since you're looking at the messages from systemd itself Apr 21 13:04:45 yeah it does include the unit name as fields in those messages, but I don't think there's a way to like add those as a column... you can filter by them (using -u) or dump the complete log entries (with -o export) to get all fields embedded in each journal entry, which is a big ton of spam Apr 21 13:04:57 it would be a nice feature to be able to add custom columns Apr 21 13:05:07 to journalctl's usual output Apr 21 13:08:58 systemctl list-unit-files --state=enabled gives enabled services. There are not so many) Apr 21 15:28:56 Can I now how many seconds past since last boot to start up specified service? Apr 21 15:29:36 uptime -s Apr 21 15:30:10 (and then pipe that to "date" to compute the seconds) Apr 21 15:34:20 Im not so good in linux bash Apr 21 18:21:05 zmatt: what is the best way to slow down the code Apr 21 18:21:11 it is running too fast Apr 21 18:21:42 if I bump up cycles to high the core faults Apr 21 18:21:48 in delay cycles Apr 21 18:23:52 C++? Apr 21 18:24:19 C Apr 21 18:24:29 the PRU in the beaglebone Apr 21 18:24:33 I have it running a PID loop Apr 21 18:24:40 use interrupts and signals Apr 21 18:25:13 that works with uio Apr 21 18:25:14 ? Apr 21 18:25:24 i have seen interupts with rproc Apr 21 18:25:33 but I am not using that to control the PRU Apr 21 18:28:22 ah, no, I didn't use PRU. My C++ program use general gpio interfaces. And what you're trying to make with PRU? Apr 21 19:08:04 PID controller Apr 21 19:08:25 to add position control on a DC motor Apr 21 19:23:11 zmatt: gpio_set_high( dev, 1u << gpio ); is not actually changing the value of the pin Apr 21 22:10:42 quiet too quiet Apr 21 22:37:46 mattb0ne: there shouldn't be any __delay_cycles at all since your code is synchronized to the measurement rate of the load cell Apr 21 22:38:55 i.e. adding __delay_cycles() does not change the rate at which your loop runs, it just reduces the time available per loop iteration until it fails to process the load cell data and faults Apr 21 22:41:50 mattb0ne: did you first configure the gpio as output? Apr 21 23:42:25 back Apr 21 23:42:45 yeah I had an overlay for the pin Apr 21 23:42:49 i can paste Apr 21 23:43:16 https://pastebin.com/5QxrRsYW Apr 21 23:43:24 it is P9.13 Apr 21 23:43:27 or 0.31 Apr 21 23:43:43 the one I am intending to use. I have no problem switching it from python Apr 21 23:53:37 that is my overlay Apr 21 23:53:54 zmatt: could I use the C sleep function to slow down the loop? Apr 22 01:47:35 you can't slow down the loop, since it is synchronized to the fixed-rate measurements from the load cell Apr 22 01:48:45 oh he left Apr 22 02:12:35 I am here! Apr 22 02:28:20 back **** ENDING LOGGING AT Fri Apr 22 02:59:56 2022