warpme_ has quit [Quit: Connection closed for inactivity]
jbrown has joined #linux-sunxi
dev1990 has quit [Remote host closed the connection]
dev1990 has joined #linux-sunxi
sunshavi has quit [Ping timeout: 256 seconds]
Mangy_Dog has quit [Ping timeout: 260 seconds]
vagrantc has quit [Quit: leaving]
<Peetz0r>
I am still trying to find out what is needed to make wake on wlan working. The rtl8723 driver seems to already support it and the pins are defined in the device tree.
<Peetz0r>
I am now trying to figure out what is needed to make crust listen to that gpio signal. But I can't figure out how to check what it's doing. I have already built crust with some more info() sprinkled around but I don't really understand what I am looking at.
<Peetz0r>
I see a constant IRQ_R_PIO_PL that seems related, but as far as I can find, it's not used for anything.
<Peetz0r>
Also, but unrelated, I can't enable things like CONFIG_DEBUG_PRINT_BATTERY because it runs out of space. I guess there's not much I can do to make it fit?
<Peetz0r>
(I also asked this in #crust but there's not many people there so I repeated the question here)
<apritzel>
Peetz0r: didn't smaeul said that Linux has to configure and enable the GPIO interrupt already? So crust just waits for that to fire?
<Peetz0r>
But that should already be happening if I enable the option on the wlan interface
<Peetz0r>
But I don't know how I could check
<Peetz0r>
(I wouldn't mind having pcb cad files of the phone right now)
<Peetz0r>
(even though I might still not be able to probe it if I knew what pin I was looking for)
<apritzel>
I'd say it's a software problem: the GPIO pin needs to be configured to trigger the associated GPIO bank IRQ, not sure if this is done already
s_frit has quit [Remote host closed the connection]
<Peetz0r>
How would I check if that's being done?
s_frit has joined #linux-sunxi
<Peetz0r>
I assume that'd be the job of the rtl8723 driver?
sunshavi has joined #linux-sunxi
<apritzel>
or more the task of some generic framework?
apritzel has quit [Ping timeout: 260 seconds]
kaspter has joined #linux-sunxi
<Peetz0r>
Can crust at least print which interrupt was triggered when waking up?
<smaeul>
Peetz0r: yes, space is tight, but A64 should not run out so soon (neither I2C nor CIR are enabled on PinePhone). where is your toolchain from? Make sure you are using a toolchain with functioning LTO, and ideally GCC 10
<Peetz0r>
might upgrade from gcc 9.1 to 10 then
<smaeul>
to verify LTO is functional, check build/scp/scp.map. it should reference filenames like /tmp/scp.elf.XXXXX.ltrans0.ltrans.o
<Peetz0r>
hmm, this is about or1k-linux-musl-gcc right? that is already 10.2.1
<Peetz0r>
And yes, I see those filenames in that file
<smaeul>
yes. for ex, with pinephone_defconfig + SERIAL + DEBUG_LOG, my gcc 10.1.0 gets "0x0000000000013394 __stack_end = .", which leaves over 2k of space for your additions
<smaeul>
(though as you found out, info() and higher don't need DEBUG_LOG)
<Peetz0r>
yeah, I already disabled _LOG, but I would love to enable the _PRINT_BATTERY
<Peetz0r>
my __stack_end is 0x00013ac8 right now
<smaeul>
with what options on top of pine64_defconfig? (one more suggestion: you can disable CONFIG_ASSERT to recover a tiny bit of space)
<Peetz0r>
with CONFIG_DEBUG_PRINT_BATTERY and CONFIG_COMPILE_TEST enabled, I get 0x00013ca8
<Peetz0r>
since that's below 0x14000, shouldn't is be just fine?
<smaeul>
no, there are 0x400 bytes at the end that are SCPI shared memory buffers
<Peetz0r>
Ah
<smaeul>
you can also decrease the stack size (probably by half). I never bothered to measure how much was used, but there's very little reentrancy
<smaeul>
trying to answer your questions: to see what IRQ caused wakeup, info() the return value of irq_poll() in common/system.c when nonzero. the bits correspond to this table (which matches platform/irq.h): https://linux-sunxi.org/INTC#A64.2FH5
<Peetz0r>
Reducing the stack size helped, lemme run this
<smaeul>
to see GPIO IRQ setup, dump the port L registers (PL_CFG0, PL_INT*) as documented in the A64 manual
<Peetz0r>
I tried printing the value of pending in the body of irq_poll_eint() but only ever got 0. But that should at least contain something nonzero when I press the button or w/e?
<Peetz0r>
Anyway, I was rebooting the phone to see the battery stats printed
<smaeul>
no, irq_poll_eint() is only for the RI pin on BraveHeart. if you have a v1.2 or were using the latest/merged Linux irqchip driver (in e.g. megi's kernel) you can turn off CONFIG_IRQ_POLL_EINT
<Peetz0r>
huh, but irq_poll doesn't do anything than calling irq_poll_eint right?
<Peetz0r>
here you can see how I am not a C dev :p
<smaeul>
having the IRQ in the device tree is not enough for it to be used by the driver, and using the IRQ in the driver is not enough for it to cause wakeup. The Linux driver must call enable_irq_wake() (or one of a few similar functions) for the IRQ to be armed during sleep
<Peetz0r>
hmm, looks like DEBUG_PRINT_BATTERY doesn't work at all. With the smaller stack I could enable DEBUG_LOG without problems, and I reduced the 30s interval to something smaller, 2s. It prints a lot of debug stuff, but no battery stuff.
<Peetz0r>
huh, weird. Id didn;t work, but now it does. Dunno why.
pCactus has joined #linux-sunxi
<smaeul>
because the timer overflows every 5 minutes (2**32/13000000/60), and the firmware can only track intervals half of that. so if you first suspend while the timer's MSB is set, you have to wait (up to 3 minutes) until it rolls over and then passes the 30 second value
<Peetz0r>
Ah, that explains
<smaeul>
your SRAM space problems are definitely caused by poor optimization, probably due to the static GCC build not including the LTO plugin (.so). the LTO wrapper executable is supposed to work the same, but apparently it does not.
asdf28 has joined #linux-sunxi
<smaeul>
LTO is supposed to inline all of the functions called once (like all of the irq_* and msgbox_* functions), so they should not show up in the linker map
<Peetz0r>
While trying more things my emmc just corrupted itself and now my phone doesn't boot anymore. yay?
<Peetz0r>
well, it can't load the kernel. crust and uboot are still there
<Peetz0r>
meh it just needed two power cycles. weird but ok
<smaeul>
one thing you may hit: if you overflow the stack, that may break SMP, which will cause Linux to delay for 30 seconds during early boot, but it will boot eventually
<Peetz0r>
heh, I just had to wait 90 seconds because I fotgot to put my sdcard back inside
<Peetz0r>
brb putting nofail in fstab :p
<Peetz0r>
I can at least report that it doesn't overflow during early boot, so we're fine there
steev has quit [Read error: Connection reset by peer]
aliosa27_ has quit [Ping timeout: 260 seconds]
steev has joined #linux-sunxi
aliosa27_ has joined #linux-sunxi
<Peetz0r>
So I can now print the config register and the battery things every 3 seconds (I am impatient like that)
<Peetz0r>
The bits for PL3 are set to S_PL_EINT3, which I assume is the right one
<smaeul>
yes, that is correct
<Peetz0r>
So, next thing to look at would be the rtl8723bs driver, check if it actually does the right thing and configures the nic to poke that gpio when it should
<Peetz0r>
if I understand correctly, it tries to go to deep sleep (aka handing control over to crust), fails at putting mmc1 (aka wifi) to sleep, and then settles for s2idle instead
mmarc__ has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
<megi>
-38 ENOSYS
<megi>
hmm
<Peetz0r>
Hey, I've seen your name on my screen a billion times the past few hours :)
<megi>
heh, what? :) I wonder if this is me patching out PM out of sunxi-mmc, but maybe not
Ke has joined #linux-sunxi
<Peetz0r>
Another question I had, where does the wifi firmware live? I don't have any in /bin/firmware (only BT firmware there), but it must be somewhere
<megi>
in the C files
<megi>
oh wait, mmc1 is just wifi
<Peetz0r>
yep
<megi>
so ENOSYS is from the wifi driver's pm callback
<megi>
maybe up the debugging level on the 8723cs driver
<megi>
there's CONFIG_RTW_DEBUG in tha Makefile in the 8723cs dir
lurchi_ has quit [Read error: Connection reset by peer]
lurchi_ has joined #linux-sunxi
<megi>
I'm pretty sure I was getting the same error when I had CONFIG_RTW_SDIO_PM_KEEP_POWER enabled
<megi>
that MMC_PM_KEEP_POWER flag is controlled by keep-power-in-suspend DT property
<megi>
so maybe you'll just need to add that to the &mmc1 node in DT
<Peetz0r>
Worth a try
<megi>
then, you'll get past that ENOSYS error, and WoL may even work :)
<Peetz0r>
okay, CONFIG_RTW_DEBUG=y, _LEVEL=6, _WOWLAN=y, CONFIG_RTW_SDIO_PM_KEEP_POWER=y, and my DT now has keep-power-in-suspend. Compiling will take a few minutes and installing will take more :p
MartijnBraam has joined #linux-sunxi
solderfumes[m] has joined #linux-sunxi
Tooniis has joined #linux-sunxi
psydruid has joined #linux-sunxi
thefloweringash has joined #linux-sunxi
kprasadvnsi[m] has joined #linux-sunxi
clementp[m] has joined #linux-sunxi
Jeremy_Rand_DT[m has joined #linux-sunxi
JuniorJPDJ has joined #linux-sunxi
z3ntu has joined #linux-sunxi
t4h4[m] has joined #linux-sunxi
davidebeatrici has joined #linux-sunxi
Irenes[m] has joined #linux-sunxi
fevv8[m] has joined #linux-sunxi
<megi>
it doesn't cause the ENOSYS anymore, here
<megi>
I'm not sure how to test wowlan though :)
<Peetz0r>
well, put it in sleep, send wol packet, pray, check if device wakes up
mmarc__ has quit [Remote host closed the connection]
<megi>
I think you need to configure wol on the interface too
mmarc__ has joined #linux-sunxi
<megi>
via some maginc iw incantation
<Peetz0r>
Yep, `iw phy0 wowlan enable any`
<Peetz0r>
almost forgiot :p
<megi>
hmm, that looks easy enough
lurchi_ has quit [Ping timeout: 265 seconds]
<Peetz0r>
But I have a feeling that this driver doesn't really respect the userland interface for these settings
<Peetz0r>
since the contents of /proc/net/rtl8723cs/wlan0/wow* don't change with that iw command
<megi>
"The configuration file of wpa_supplicant should add “wowlan_triggers=any” when"
<megi>
the driver adopt CFG80211 interface in the linux kernel.
<megi>
:D
<Peetz0r>
I guess that does the same thing as `iw phy0 wowlan enable any`
<Peetz0r>
So, where does this driver in this shape come from?
<Peetz0r>
Or should I not ask these things? :p
<megi>
the last one is from 2020-10-xx some RK tree
<megi>
+ some patches on top to untangle the RK specific bits and make it work with 5.11
<Peetz0r>
Is there some place where realtek publishes them?
<megi>
code search on github can be useful if you look for patterns like version macros that are fairly unique to this driver, etc :)
<megi>
not to public, no
<megi>
there were some passwords shared around that you could use to access their ftp
<megi>
but code there was not very current either
<Peetz0r>
Ah
<megi>
and those passwords don't work anymore
<Peetz0r>
so, it's a mess :\
<megi>
but I at least snatched soem docs out of there
<megi>
while I could
<megi>
yesj it's a mess
<megi>
staging has several copies of their driver tree
<megi>
it all looks quite similar except for differing device specific bits and versions of the tree that were available at the time someone added it to staging
<megi>
hope is rtw88 will some day grow support for SDIO
<megi>
and more devices, but I'm not sure realtek has much interest in supporting older devices
<Peetz0r>
Huh, /proc/interrupts is interesting. So I am still running the kernel with the ifdefs in place. When I suspend the phone and wake it up by the button, it also increases the number by one
<megi>
I guess my router is blocking wol packets, because they're not reaching my PP even when it's on
random_yanek has quit [Ping timeout: 272 seconds]
Mangy_Dog has joined #linux-sunxi
<Peetz0r>
I checked, the packets definitelu arrive on my phone when it's awake
<megi>
I managed to make it work too, I was listening for them on the wrong port
random_yanek has joined #linux-sunxi
<megi>
wol tool by default sends to port 40000
<Peetz0r>
Yeah, there's different kinds, but it shoudln't matter as long as the packet arrives and the body contains the mac address
<Peetz0r>
I tried it with etherwake (which does the classical udp/9) and wol (tcp/40000). both arrive, neither wake it up
asdf28 has quit [Ping timeout: 240 seconds]
<megi>
by default /proc/net/rtl8723cs/wlan0/wow_pattern_info seems to contain weird values
<megi>
pattern lengths are quite large
<megi>
when you echo mac address there there will be a new pattern at the end with size of 6
narmstrong has quit [Remote host closed the connection]
steev has quit [Remote host closed the connection]
aliosa27_ has quit [Remote host closed the connection]
<megi>
ans wol will still not work :)
<megi>
and
dev1990 has quit [Ping timeout: 260 seconds]
steev has joined #linux-sunxi
steev has quit [Remote host closed the connection]
<megi>
ah, I see, longer patterns include more conditions
steev has joined #linux-sunxi
dev1990 has joined #linux-sunxi
<Peetz0r>
Discovered another thing, the counters for the interrupt only count when `iw phy0 wowlan enable any` is set
<Peetz0r>
so, `iw` is not ignored, even though we have to use the nonstandard interface to configure it
<Peetz0r>
(and I haven't yet had any successful wakes yet)
narmstrong has joined #linux-sunxi
aliosa27_ has joined #linux-sunxi
<Peetz0r>
GOTTEM!
<Peetz0r>
I did a 'clean' so it wouldn't match on any pattern, just a magic packet
<Peetz0r>
(see table of wake up reasons in the pdf)
<Peetz0r>
all of the times I had no wake but the driver thinking it worked, was reason 0x23 (pattern match)
<Peetz0r>
with no patterns configured but magic packets enabled, sennding a magic packet actually worked
<megi>
hmm
BenG83 has joined #linux-sunxi
<megi>
yeah :)
<megi>
it works here too :)
<Peetz0r>
(it'd be super cool to have pattern work, so I can wake on packets from my matrix homeserver and ignore everything else)
<megi>
niiice
<Peetz0r>
hmm, patterns only support ipv4. that's a bit of a bummer
<Peetz0r>
but, still usable enough
<Peetz0r>
Now I want this to work on the lte modem too :D
<Peetz0r>
(but I guess I'll just wait for biktorgj's work there)
<megi>
I'll have to test how power consumption looks like with WoW enabled
<Peetz0r>
yep
<Peetz0r>
Eh, I can do that, I baked a crust with battery stats printing earlier today
<Peetz0r>
...it just woke up all by itself :O
<Peetz0r>
yeah, it wakes up on any incoming packet. And that's correct, since we left the 'wake on unicast' also enabled
<megi>
is this supposed to work transparently for tcp connections? it may right, because tcp would resend packets until PP is woken up and ready to continue the connection?
yann has quit [Ping timeout: 264 seconds]
<Peetz0r>
I guess so, yeah.
<megi>
my ssh sessions survive sleeps just fine, so I think that works
<Peetz0r>
But I also half expect matching packets to be kept in a buffer, and sent to the OS after waking up
<Peetz0r>
Not sure about either
yann has joined #linux-sunxi
<Peetz0r>
yep
<megi>
no tcp resets, ssh just hangs for the duration of sleep
<megi>
making the phone sleep over wifi may be a bit of a challenge if it will then wake on any packet, though :)
<megi>
I had to switch to serial port to make it not wake up immediately
<Peetz0r>
yeah, I killed all my ssh's
<Peetz0r>
and I also killed my matri client on the thing
<Peetz0r>
and still it wakes up quickly all the time
<KotCzarny>
megi: wake on unicast is useful when you want to implement microsleep
<KotCzarny>
and to have device maintain whatever it was doing
<megi>
microsleep is sleep between packets, or some such?
<KotCzarny>
microsleep is sleeping as much as you can while remaining usability
<Peetz0r>
I just killed phosh. No desktop, less things that want to request network stuff
<KotCzarny>
but it works better with eink screen obviously
<Peetz0r>
can be useful for times where the display is off
<megi>
yep, and with wakelocks and autosleep, I imagine
<megi>
display wakeup time is large part of the resume part of the cycle
<megi>
I don't imagine much microsleep from pinephone though, wifi takes 1s to wakeup or so, and wowlan when enabled adds a few hundred ms to the suspend, too
<megi>
while it's waking up in a work queue, further suspend is blocked
<megi>
so maybe matching by IP address can be enabled with some effort, too
<Peetz0r>
it'd be very cool if apps can say "hey, I get notifications from $ip:$port, wake me up when you have some" and do tcp long polling while sleeping
<megi>
number of these patters will be quite limited for this to be done by many apps at once
<Peetz0r>
Yeah, but one or two messaging apps and sshd is enough
<Peetz0r>
might be useful to have some UI where the user can assign slots to apps for this purpose
<megi>
yep, would be nice to not depend on some centrailzed notification service
<Peetz0r>
Anyway, time for a break.
<Peetz0r>
I'm happy with what we've done today :)
<Peetz0r>
oh, yeah, I wanted to do some power measurements too
<BenG83>
nice work
pCactus has quit [Read error: Connection reset by peer]
pCactus has joined #linux-sunxi
sunshavi has joined #linux-sunxi
asdf28 has joined #linux-sunxi
<Peetz0r>
There is ipv6 support in the code, just not the docs
<BenG83>
those rtl drivers are haunting me for 5 years now
<Peetz0r>
sorry, I guess :p
abelvesa_ has joined #linux-sunxi
<Peetz0r>
megi: Seems to be hovering around 299 - 310 mW. It does 280 - 300 mW with the stock mobian kernel.
abelvesa has quit [Ping timeout: 272 seconds]
<Peetz0r>
That would result in >30 hours of standby time with wow enabled on the pinephone
<bauen1>
how does apple do these things ? is apples push notification service just that ? except that you only need to wake on one single tcp connection ?
nga0x539 has joined #linux-sunxi
faruk_ has joined #linux-sunxi
faruk has quit [Ping timeout: 240 seconds]
gendevbot_ has quit [Ping timeout: 260 seconds]
gediz539 has quit [Ping timeout: 260 seconds]
gendevbot has joined #linux-sunxi
<Peetz0r>
I don't know how exactly iOs and Android to these things, but they use centralised servers indeed
<Peetz0r>
Oh, eh, the above numbers are with the modem enabled
<megi>
Peetz0r: that's quite a lot
<Peetz0r>
How much would you have expected?
<Peetz0r>
How low is it supposed to go (with the modem still enabled)?
<megi>
10's of mW max comapred to wifi off
<megi>
like 20-30
<megi>
modem eats like 15mW just waiting for comms from the tower
daregap has quit [Quit: daregap]
<Peetz0r>
lemme do something dirty and flow the killswitches while watching usage during suspend
<Peetz0r>
I have disabled all the killswitches but the pp is still using >260 mW
<Peetz0r>
I read that it should be closer to 110 mW
<Peetz0r>
there's two things that I can think of, the microsd-card and serial enabled in crust
<Peetz0r>
sd card is easy to test
<mmarc__>
How should I send ctrl-U to U-boot from minicom?
<mmarc__>
Does not seem to work right away. This is a key to stop the normal boot sequence.
<mmarc__>
Interestingly, even if I send ctrl-U to UART in a loop with a C code, it does not work. I'm assuming ctrl+u is an integer value of 10 to be sent.
freemangordon has quit [Ping timeout: 240 seconds]
<Peetz0r>
Well, sd card didn't make any difference for the power usage (didn't expect any) but I can't measure externally so I can't disable serial in crust
<Peetz0r>
does anyone know how much difference that should make?
<megi>
you should get ~110mW without the modem, suspended
<Peetz0r>
Yes, but how much difference is enabling/disabline serial in crust supposed to make? Can that explain the 150 mW difference? Is there something else I am missing?
<megi>
probably quite a bit
<Peetz0r>
So if we assume that all the extra power draw is coming from serial and only 10-20 mW is coming from wowlan, I think that's pretty good
kaspter has joined #linux-sunxi
xzz53__ has quit [Ping timeout: 272 seconds]
solderfumes[m] has quit [Ping timeout: 258 seconds]
xzz53 has joined #linux-sunxi
<smaeul>
Peetz0r: having serial enabled in crust makes a big difference. normally you can get to suspend depth 2 (SD_AVCC), but using UART0 keeps you at 0 (SD_NONE)
matthias_bgg has quit [Quit: Leaving]
<smaeul>
that's why serial is disabled by default for Pinebook/PinePhone. normally that gets you down to around 15 mA
<Peetz0r>
Someday I'll have access to tools that let me measure power usage outside of crust
<Peetz0r>
but that day is not today
<smaeul>
you can do it from inside crust, by saving the power measurements to SRAM and then reading them via /dev/mem after resuming
<smaeul>
the PMIC still works in the lowest suspend depth, just not the UART
<smaeul>
I have a patch for this I can push tomorrow
<Peetz0r>
Cool :)
prefixcactus has quit [Ping timeout: 265 seconds]
<smaeul>
it's not the UART it self that takes 150 mW. it's the 24 MHz crystal and PLLs. technically, if you reparented APB2 to LOSC during suspend (see sun50i-a64-ccu.c), you could use the UART at 2048 baud at full suspend depth
<Peetz0r>
That's be even cooler
<Peetz0r>
2048 baud is plenty for one line of text every few seconds
pCactus_ has joined #linux-sunxi
<smaeul>
that's why the best boards for crust development are those that expose R_UART on PL2/PL3 -- unlike the other UARTs, it can be driven from IOSC/OSC16M, and it doesn't require vcc-io enabled either
<smaeul>
and it works with VDD-SYS gated, etc, etc. :)
pCactus has quit [Ping timeout: 246 seconds]
solderfumes[m] has joined #linux-sunxi
clementp[m] has quit [Ping timeout: 240 seconds]
<apritzel>
smaeul: yeah, I always get annoyed when people waste those precious PortL pins on some GPIOs
lucascastro has quit [Ping timeout: 272 seconds]
clementp[m] has joined #linux-sunxi
lucascastro has joined #linux-sunxi
jernej has quit [Remote host closed the connection]
jernej has joined #linux-sunxi
gaston1980 has joined #linux-sunxi
MangyDog has joined #linux-sunxi
buZz_ has joined #linux-sunxi
_rze has joined #linux-sunxi
Net147_ has joined #linux-sunxi
buZz_ has joined #linux-sunxi
buZz_ has quit [Changing host]
Moe_Icenowy has joined #linux-sunxi
buZz has quit [Disconnected by services]
sunilmohan_ has joined #linux-sunxi
sunilmohan_ has joined #linux-sunxi
juri__ has joined #linux-sunxi
egbert has quit [Disconnected by services]
qschulz_ has joined #linux-sunxi
dlan_ has joined #linux-sunxi
abelvesa has joined #linux-sunxi
egbert has joined #linux-sunxi
paulk-leonov-spa has joined #linux-sunxi
abelvesa_ has quit [*.net *.split]
asdf28 has quit [*.net *.split]
Mangy_Dog has quit [*.net *.split]
Net147 has quit [*.net *.split]
tuxillo has quit [*.net *.split]
paulk-leonov has quit [*.net *.split]
sunilmohan has quit [*.net *.split]
juri_ has quit [*.net *.split]
dlan has quit [*.net *.split]
rzerres has quit [*.net *.split]
qschulz has quit [*.net *.split]
MoeIcenowy has quit [*.net *.split]
Moe_Icenowy is now known as MoeIcenowy
asdf28 has joined #linux-sunxi
buZz_ is now known as buZz
asdf28 is now known as 17QAA17E0
dlan has joined #linux-sunxi
tuxillo has joined #linux-sunxi
juri_ has joined #linux-sunxi
qschulz has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
asdf28 has joined #linux-sunxi
sunilmohan has joined #linux-sunxi
dlan has quit [Max SendQ exceeded]
juri_ has quit [Max SendQ exceeded]
asdf28 has quit [Ping timeout: 254 seconds]
Mangy_Dog has quit [Ping timeout: 254 seconds]
sunilmohan has quit [Ping timeout: 254 seconds]
qschulz has quit [Ping timeout: 254 seconds]
lucascastro has quit [Ping timeout: 240 seconds]
sunshavi has quit [Read error: Connection reset by peer]
sunshavi has joined #linux-sunxi
jernej has quit [Remote host closed the connection]
freemangordon has quit [Ping timeout: 265 seconds]