<zmatt>
journal recovery is the fastest form of recovery, any alternate will be worse
<zmatt>
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
<Siegurd>
the problem is that it is a fresh installed image and it has no power loses
<Siegurd>
maybe I should turn off read only mode, do all checks and make read only again?
<zmatt>
that's pointless since the filesystem *isn't* mounted readonly
<zmatt>
if it were, you wouldn't get this message
xet7 has quit [Remote host closed the connection]
<zmatt>
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
xet7 has joined #beagle
<Siegurd>
how can I check it?
<zmatt>
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
<Siegurd>
OK, 1 sec
<zmatt>
also, for reference, this is what it looks like if the root filesystem is actually being mounted readonly: https://pastebin.com/raw/wLMPgZUG
<zmatt>
of course when using overlayfs it's technically not even the root filesystem, so things will look different anyway
<zmatt>
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
<zmatt>
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
<zmatt>
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
<zmatt>
also, I'm not seeing any kernel messages here, did you remove the "quiet" option from your kernel parameters?
<Siegurd>
this is full UART log of startup and shutdown with overlayroot=tmpfs and deleted "quiet" option in /boot/uEnv.txt https://pastebin.com/egDvMr0a
<zmatt>
hmm, the kernel doesn't log to the serial console even without quiet? annoying, must be a setting somewhere
<zmatt>
during shutdown I mean
<Siegurd>
maybe the journal can help?
<zmatt>
but also, I don't see the problem you claim to be having... this boot was clean
<zmatt>
line 359, "rootfs: clean"
<Siegurd>
ok, will try to do a clean install if image one more time on weekend
<zmatt>
... but, it seems to be working fine right now?
<Siegurd>
of image
<zmatt>
I dunno
<zmatt>
unless your previous boot was non-overlayroot
<Siegurd>
no, it still adds +10 seconds to booting process
<zmatt>
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 ?
<zmatt>
note btw that initramfs (which is required for overlayroot) also adds boot time (about 11 seconds on my system)
<Siegurd>
maybe that's the reason...
<zmatt>
well, you're using initramfs in both cases here
<zmatt>
with or without overlayroot
<Siegurd>
I add my C++ program to run as a service with Before=basic.target
<Siegurd>
After=local-fs.target sysinit.target
<zmatt>
hope you know what you're doing
<zmatt>
why are you ordering your service before basic.target ? that sounds like a recipe for slowing down boot
mattb0ne has joined #beagle
<Siegurd>
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.
<zmatt>
it's possible overlayroot's scripts just take more time (e.g. to load the necessary drivers and executables from filesystem)
<zmatt>
who knows
<mattb0ne>
zmatt: I am getting no suitable conversion function from sysGpio to sysGpio *" exists
<mattb0ne>
when I try to use one of the functions
<mattb0ne>
will pastebin
<mattb0ne>
one momemnt
<zmatt>
mattb0ne: pass e.g. &GPIO0 as argument
<zmatt>
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
<zmatt>
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
<Siegurd>
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.
<zmatt>
Before=something does not cause your service to start sooner, it causes that something to start later
<zmatt>
it's a way to delay other things
<zmatt>
normally systemd tries to start things in parallel as much as possible, which typically results in the most efficient startup
<zmatt>
beware btw that services by default have an implicit After=basic.target unless you have DefaultsDependencies=no
<Siegurd>
but we have 1 core CPU so...
<zmatt>
yes, but processes often spend time blocked on stuff
<zmatt>
during which other processes could do useful work
<Siegurd>
I mean that for example usb modem handling service could be delayed cuz my program don't use it for work.
<zmatt>
also, ordering yourself between sysinit.target and basic.target is fairly useless
<zmatt>
basic.target is generally reached a fraction of a second after sysinit.target
<zmatt>
the main thing that happens is starting socket listeners, and you almost always want to be ordered after that
<mattb0ne>
i was trying to make compile time constants you dont do that with #define?
<zmatt>
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
<zmatt>
mattb0ne: no
<zmatt>
mattb0ne: #define creates macros
<zmatt>
which are basically just compile-time search-and-replace
<mattb0ne>
ok use const?
<zmatt>
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
<mattb0ne>
lol ok
<zmatt>
it may not even matter at all
<zmatt>
which I did add almost immediately
<zmatt>
your old version was definitely better, since your macro version is completely broken
<mattb0ne>
ok
<zmatt>
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
<zmatt>
(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)
<mattb0ne>
i see
<mattb0ne>
question for you
<mattb0ne>
so I just jammed an array in shared_vars in the C code
<mattb0ne>
how would i specify the array on the python side
<mattb0ne>
python doesnt have arrays
<mattb0ne>
right?
<zmatt>
it does, but in this case you're specifically asking about ctypes, whose syntax for array types is type * count
<zmatt>
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
<zmatt>
(to ensure compatibility of structures between python and pru)
<mattb0ne>
can you do a quick example I learn better that way
<mattb0ne>
16 bit alignment
<mattb0ne>
i have uint16_t signal[1000] in the C code
<zmatt>
the total size of the fields *prior* to it should be a multiple of 2 bytes
<mattb0ne>
I can do signal uint16_t *1000
<zmatt>
yep, that's how you declare that type on the python side
<mattb0ne>
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
<mattb0ne>
i could do another array like u16*3
<mattb0ne>
before and that would be put me at 2^4
<zmatt>
no, multiple of 2 bytes (16 bits)
<zmatt>
not multiple of 16 bytes
<zmatt>
so you're already fine, no padding needed
<zmatt>
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
<zmatt>
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
<zmatt>
you can do block assignment, e.g. shmem.signal[:] = [0] * len(shmem.signal) would fill it with all-zeros
<zmatt>
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)
<mattb0ne>
ok
Shadyman has quit [Remote host closed the connection]
set_ has joined #beagle
set_ has quit [Ping timeout: 276 seconds]
mattb0ne has quit [Ping timeout: 256 seconds]
otisolsen70_ has joined #beagle
otisolsen70 has quit [Ping timeout: 250 seconds]
mattb0ne has joined #beagle
<Siegurd>
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).
<zmatt>
journalctl -o with-unit -b
mattb0ne has quit [Ping timeout: 256 seconds]
<zmatt>
oh that doesn't help for this
<zmatt>
since you're looking at the messages from systemd itself
<zmatt>
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
<zmatt>
it would be a nice feature to be able to add custom columns
<zmatt>
to journalctl's usual output
argonautx has joined #beagle
<Siegurd>
systemctl list-unit-files --state=enabled gives enabled services. There are not so many)
wonko-the-sane has joined #beagle
wonko-the-sane has quit [Quit: leaving]
wonko-the-sane has joined #beagle
otisolsen70__ has joined #beagle
florian has joined #beagle
otisolsen70_ has quit [Ping timeout: 246 seconds]
CrazyEddy has quit [Ping timeout: 250 seconds]
otisolsen70__ has quit [Quit: Leaving]
russ has quit [Ping timeout: 246 seconds]
wonko-the-sane has quit [Remote host closed the connection]
wonko-the-sane has joined #beagle
set_ has joined #beagle
russ has joined #beagle
wonko-the-sane has quit [*.net *.split]
wonko-the-sane has joined #beagle
<Siegurd>
Can I now how many seconds past since last boot to start up specified service?
<ogra>
uptime -s
<ogra>
(and then pipe that to "date" to compute the seconds)
<Siegurd>
Im not so good in linux bash
mattb0ne has joined #beagle
argonautx has quit [Read error: Connection reset by peer]
argonautx has joined #beagle
vagrantc has joined #beagle
mattb00ne has joined #beagle
mattb0ne has quit [Ping timeout: 256 seconds]
mattb00ne has quit [Ping timeout: 256 seconds]
akaWolf has quit [Ping timeout: 256 seconds]
Guest8270 has joined #beagle
Guest8270 has quit [Client Quit]
florian has quit [Quit: Ex-Chat]
mattb00ne has joined #beagle
mag has quit [Remote host closed the connection]
CrazyEddy has joined #beagle
akaWolf has joined #beagle
mag has joined #beagle
<mattb00ne>
zmatt: what is the best way to slow down the code
<mattb00ne>
it is running too fast
<mattb00ne>
if I bump up cycles to high the core faults
<mattb00ne>
in delay cycles
<Siegurd>
C++?
<mattb00ne>
C
<mattb00ne>
the PRU in the beaglebone
<mattb00ne>
I have it running a PID loop
<Siegurd>
use interrupts and signals
<mattb00ne>
that works with uio
<mattb00ne>
?
<mattb00ne>
i have seen interupts with rproc
<mattb00ne>
but I am not using that to control the PRU
<Siegurd>
ah, no, I didn't use PRU. My C++ program use general gpio interfaces. And what you're trying to make with PRU?
<mattb00ne>
PID controller
<mattb00ne>
to add position control on a DC motor
argonautx has quit [Quit: Leaving]
<mattb00ne>
zmatt: gpio_set_high( dev, 1u << gpio ); is not actually changing the value of the pin
mattb00ne has quit [Ping timeout: 276 seconds]
ikarso has joined #beagle
mattb00ne has joined #beagle
Abhishek_ has quit [Quit: Connection closed for inactivity]
set_ has quit [Ping timeout: 240 seconds]
Siegurd has quit [Quit: Leaving]
mattb00ne has quit [Ping timeout: 256 seconds]
mattb00ne has joined #beagle
mattb00ne has quit [Ping timeout: 276 seconds]
mattb00ne has joined #beagle
mattb00ne has quit [Remote host closed the connection]
mattb0ne has joined #beagle
lucascastro has quit [Remote host closed the connection]
lucascastro has joined #beagle
<mattb0ne>
quiet too quiet
set_ has joined #beagle
<zmatt>
mattb0ne: there shouldn't be any __delay_cycles at all since your code is synchronized to the measurement rate of the load cell
<zmatt>
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
<zmatt>
mattb0ne: did you first configure the gpio as output?
CrazyEddy is now known as foxhole
zjason``` has quit [Read error: Connection reset by peer]