<javier__>
gordan: did I understand correctly that you are trying to boot a FIT image from the nv-u-boot?
<javier__>
gordan: I can chain load a u-boot and boot mainline just fine but I haven't tried loading and booting a FIT from the nv-u-boot nor using a initramfs
<gordan>
Hi havier__
<gordan>
javier__ even, apologies for the typo (fat finger day)
<javier__>
gordan: no worries
<gordan>
Yes, I am trying to boot the FIT image from the nv u-boot.
<gordan>
This worked on snow (I have a FIT image containing the kernel, ramdisk and DTB for that, and it just works).
<gordan>
I haven't been able to boot _anything_ from u-boot.
<gordan>
nv u-boot itself loads fine.
krzk has quit [Quit: Wychodzi]
<gordan>
But whatever I try to load at 0x42000000 and bootm, it results either in timings + black screen + lock-up (I think it's a lock-up, no way to tell), or, in case I use mainline u-boot, it locks up at "Starting kernel ..."
<gordan>
So technically, with the pre-built nv u-boots I downloaded binaries for, it gets a little further (Starting kernel ..., then some timings being worked out, then black screen)
<gordan>
AFAICT nobody has been able to boot a FIT image containing a ramdisk via vboot.
<javier__>
gordan: yes, I've never tried using a ramdisk with a FIT
<gordan>
It works on snow.
<javier__>
gordan: but I'm able to boot a zImage + FDT on peach pi from mainline u-boot chain loaded just fine
<Wizzup>
I am booting kernel with initramfs built in fine on snow and peach-pi
<sjoerd>
see kernleci, it does that a lot :)
<gordan>
I've been using it for nearly 2 years now on snow (need it because I am using zfs-root).
<sjoerd>
so that proves it works fine :)
<javier__>
gordan: you said that tried to load a uImage with bootm, at what address did you load the FDT? or it is appended?
<javier__>
and how did you create your uImage?
<gordan>
I tried cat zImage dtb > zImage.dtb, mkimage-ing that, but that didn't work either.
<gordan>
What is the exact zImage preparation required (can it be non-mkimage'd zImage)?
<javier__>
what exact command did you use for mkimage?
<javier__>
gordan: with a mainline u-boot that has CONFIG_BOOTZ enabled, there is no need to prepare the image
<javier__>
just built it, load and boot with bootz
<javier__>
I use address 0x42000000 and have the FDT appended but kernelci does not append so you can look at the addresses used there
<gordan>
mkimage -A arm -O linux -T kernel -C none -a 0 -e 0 -d zImage uImage
<javier__>
you are missing -a 0x40008000 -e 0x40008000
<javier__>
that's the addresses you should use instead of 0
<gordan>
Right, back to the beginning, then.
<gordan>
Mainline u-boot.
<gordan>
Let me check if I built it with CONFIG_BOOTZ, as that way the whole uImage thing becomes redundant.
<javier__>
gordan: the default config for peach_pi does already
<javier__>
so unless you tweak it, it should be there
<gordan>
In .config ??
<gordan>
It's not there.
<gordan>
Also not in configs/peach-pi_defconfig
<gordan>
That's with u-boot-2015.10 tarball from ftp://ftp.denx.de/pub/u-boot/u-boot-2015.10.tar.bz2
<gordan>
I do see it in ./u-boot.cfg file as #define CONFIG_CMD_BOOTZ
<javier__>
gordan: right, that's the correct option
<javier__>
that's what I get to try to list a config symbol by heart
<gordan>
It's OK. But should this be listed in the .config and configs/peach-pi_defconfig ?
<gordan>
Or is it sufficient for it to be in u-boot.cfg as a #define ?
<javier__>
gordan: Kconfig support is u-boot is still a WIP it seems since the config options are taken from both configs/* and also include/configs/
<javier__>
but yeah, it may be that I'm wrong and CONFIG_CMD_BOOTZ is not enabled by default for peach_pi, I would had sweared that was the case though...
<gordan>
Right so: 1) How do I make sure that the u-boot I build has it enabled?
<javier__>
gordan: well, the bootz command should be there
<javier__>
you mentioned that u-boot boots fine and you are able to access the u-boot prompt
<gordan>
Right, so if I re-flash that u-boot back and try it, there should be a bootz command in it?
<javier__>
exactly
<javier__>
if the bootz command is not there, then CONFIG_CMD_BOOTZ was not enabled
<gordan>
Yes, but I removed it and put a bootable FIT image for vboot back since I couldnt't get u-boot to do anything. :)
<javier__>
right
<gordan>
Let me put my u-boot back and see what happens.
<javier__>
let me build a recent u-boot, I built mine like a year ago and I may missremembering things w.r.t default enabled options
<gordan>
Hmm... How strange, I think I'm running into some vboot limitation that requires the kernel partition to be near the beginning of the disk...
* gordan
tries a USB stick with space I can reuse at the beginning...
<gordan>
Something strange happening with a USB stick I was trying. Must have done something wrong with cgpt or gdisk, will revisit later. Got it working on a different USB stick now.
<gordan>
bootz command is there.
<javier__>
gordan: yeah, I just built a 2015.10 tag and confirmed as well
<gordan>
So using bootz, where do I need to load zImage and where do I need to load the dtb?
<gordan>
zImage still at 0x42000000?
<gordan>
Where do I put the DTB?
<javier__>
gordan: 0x43000000 for example should be safe
<sjoerd>
upstream u-boot predefines where to load stuff for you
<javier__>
sjoerd: cool, I didn't know that
<gordan>
OK, assuming zImage is < 50M :)
<javier__>
sjoerd: so using {kernel,fdt}_addr_r should be the right thing to do?
<javier__>
yeah, I haven't booted that kernel for a long time, I only test mainline regularly
<javier__>
wonder if makes some assumptions on how the bootloder setup things and that is true for vboot but no for mainline u-boot...
<gordan>
The latter bit about zfsroot is something I did to get zfs root working without an initrd (using a sqhashfs image of initrd contents on a raw partition), is ignorable.
<gordan>
Possibly, but where to look?
<gordan>
I figured using the 3.8 chromeos kernel would be closer to "just working"
<javier__>
dunno, these thigns are not easy to chase and specially without a serial console
<javier__>
gordan: mainline should be "just working" modulo the mali bits
<gordan>
OK, is there a known working binary u-boot blob I could dump on my kernel partition that is usable with the chromeos kernel?
<gordan>
I also noticed that vboot adds cros_secure to boot parameters. Is that important? I don't have that in my u-boot bootargs?
<gordan>
I am using fbdev anyway for Xorg.
<gordan>
I run RedSleeve (I'm the custodian of that distro) which is soft float and I haven't even looked at building soft-float GPU drivers recently. I had a go back when I was getting stuff working on snow, but gave up, too many assmptions in various code about hard-float-ness.
<javier__>
gordan: can't remember what hte cros_secure was used for... maybe is related to the dm-verify thingsy so it shouldn't matter when using a non chromeos rootfs
<gordan>
Yeah, I didn't think it was important for what I'm doing.
<javier__>
gordan: mmm, any reason why you are building soft-float binaries instead of hf?
<javier__>
just for curiosity
<javier__>
anyway, if you can give a try to mainline and let me know if that is not working
<gordan>
Two reasons: 1) I don't want to write off the huge number of machines out there that aren't armv7hl (SheevaPlug/DreamPlug/GuruPlug, various NAS-es like the QNAP TS-421, Raspberry Pi, etc)
<gordan>
2) Back when I started the RedSleeve project in the days of EL6/F12, the toolchain for hard-float was fragile at best.
<javier__>
I really don't mind if the 3.8 vendor tree doesn't work with u-boot and only works using the vboot but I care about mainline
<gordan>
We also did EL7 RedSleeve for soft-float to support those older devices that are still in use in huge numbers, and in the vast majority of cases, hardware FPU is unused anyway.
<gordan>
There is very little that a small server does that actually gains any advantage from a FPU.
<gordan>
OK, so if I get 3.18.24 kernel, what defconfig should I use? Anything I need to add to it for the Peach Pi to fully work?
<javier__>
gordan: better to go with 4.1 instead of 3.18 if you want a long term version
<javier__>
otherwise just 4.3, the newer the better ;)
<gordan>
I try to stay at a safe distance from the bleeding edge. I use 3.18 on x86
<gordan>
I don't believe in slaving to versions and chasing goal posts. Stability is always more important than features, so when I find something that meeds the minimum feature set requirements I stick with it.
<gordan>
It's why I maintain RedSleeve rather than setting for the perpetual bleeding edge Alpha that is Fedora.
<gordan>
If 3.18 works, I'm happy with that.
<gordan>
Unless I really need 4.1.x to get some of the hardware to work properly.
<gordan>
And the patches that make it in 4.1.x haven't been backported to an earlier LT kernel.
<javier__>
gordan: the peach pi support is something new
<javier__>
gordan: so 3.18 "works" in that it boots to a serial console
<javier__>
but if you want the peripherals working then you need 4.1
<javier__>
or at least 3.19
<javier__>
and support patches are not backported, only bugfixes
<gordan>
The thing you posted a link to (kernelci) is using 3.18.22 in that example. :p
<gordan>
Ah, OK.
<gordan>
So the most recent LT I need for the frame buffer tty is 4.1?
<javier__>
gordan: yeah because is the first link I found and kernelci only (for now) cares about booting and getting a loging prompt
EmilMedve has joined #linux-exynos
<javier__>
gordan: yes, that's why I suggested that version since I assumed you talked about 3.18 due being a LTS
<javier__>
if you did because of my link, then I'm sorry about that
<gordan>
OK, 4.1.12 it is...
<gordan>
Nah, as I explained, I'm familiar with 3.18 because that's what I use on my x86 boxen.
<javier__>
OK
<Wizzup>
I would suggest 4.2 or 4.3 even
<gordan>
Then again, on Kirkwood devices I use 3.10.x LT because 3.10.x is that EL7 ships with, so it keeps it close to upstream. Not really workable for more modern devices, though (Marvell Kirkwood is ancient, that's in part why I like it, very well supported).
<javier__>
goardan: please let me know if you have any issues and I could try to boot 4.1.12
<gordan>
OK, just getting the 4.1.12 build kicked off.
<javier__>
cool
<daniels>
gordan: kernelci generally boots linux-next, heh
EmilMedve has quit [Quit: Leaving.]
<gordan>
At least the kernel doesn't take as long to build on Peach as it does on Snow...
<gordan>
Roll on the GTS scheduler so we can use all 8 cores at the same time, lopsided as it may be, it'll be amazin for large parallel compile jobs.
<Wizzup>
You can already turn that on in 4.2 at least
<Wizzup>
I did that for awhile, but it made my firefox experience considerably worse
<gordan>
Keep going. Tell me 4.3 is going to become LT and I might just jump to that shortly. ;)
<gordan>
The theing is, there are ways around that.
masta has joined #linux-exynos
<gordan>
You could set up a systemd service that runs at startup that sets affinity of everything, including init/systemd to use the 4 fast cores only.
<Wizzup>
you don't need systemd to set affinity of processes
<gordan>
And have a script to reset affinity for all processes when you want power efficiency (you could run it with a hook on power management stuff.
<gordan>
I know you don't, I just meant to make it happen on startup.
<gordan>
Anyway, you could then run compile jobs with taskset that schedules them explicitly on all cores.
<gordan>
Or, if it's only FF that was being problematic, you could just set up a wrapper script to taskset that.
<gordan>
I run my web browsers in a separate user sandbox anyway, via a wrapper script for security reasons, adding taskset to that would be pretty trivial.
<gordan>
The final straw for sandboxing my browsers into a separate dedicated user per user+app (e.g. gordan_firefox, bob_firefox, etc) was one of the recent RCE exploits in FF.
<gordan>
So now even if there is an RCE it is sandboxed to the app itself, which makes the impact far, far more limited (e.g. unless it can be stacked with a 0-day kernel local privilege escalation exploit, it cannot pilfer things like my own files, keys, etc.)
<gordan>
It's not whether you're paranoid any more, it's whether you're paranoid _enough_.
* gordan
is pondering the similarities between watching kernel compile and watching paint dry...
<gordan>
Exactly the same symptom with 4.1.12
<gordan>
Stuck at "Starting kernel ..." using mainline u-boot
<gordan>
To build the kernel I did make exynos_defconfig; make -j8 dtbs; make -j8 zImage
<gordan>
Loaded zImage to 0x42000000, dtb to 0x43000000, then bootz 0x42000000 - 0x43000000
<gordan>
Any further ideas?
<javier__>
mmm, that should work
<javier__>
let me build that tag
<gordan>
Tag?
<gordan>
Not sure if it's relevant, but I'm building everything on a soft-float distro, including mainline u-boot
<javier__>
4.1.12
<sjoerd>
u-boot doesn't use floating point so it shouldn't matter
<gordan>
Well, you say that, but the chromeos u-boot fails to compile due to hard-foat ABI issues.
<gordan>
I did manage to get it to build, but I had to modify some of the build parameters.
<sjoerd>
i can't speak for the chromeos source
<gordan>
Fair enough, I was just mentioning it because it is at least derived from u-boot
<gordan>
Has anybody got a u-boot blob that I can dump on a partition to try it?
<gordan>
Just in case it is something about my specific u-boot build that is for some unfathomable reason broken?
<gordan>
I literally did make peach-pi_defconfig; make, then mkimage'd and vbutil_kernel'd it.
<sjoerd>
is your kerenl command line correct for setting up the serial output
<gordan>
bootargs=console=tty1
<gordan>
Is that correct?
<sjoerd>
not for serial
<sjoerd>
I'm assuming here you have a serial console to the device
<javier__>
sjoerd: he doesn't have a serial console hooked afaict
<sjoerd>
Oh in that case are you sure it doesn't boot rather then it not lighting up the display :)
<javier__>
gordan: I'm building a v4.1 kernel now to test but I'm pretty sure that version worked for me before
<gordan>
Hang on, I may have dropped the ball somewhere...
<gordan>
Give me a minute to hard set something...
<javier__>
sjoerd: yeah if there is any issue is most likely the display not working rather than the machine not booting
<gordan>
Result!
<gordan>
I have the kernel crash on the screen (due to mmc storage driver not being compiled in).
<gordan>
So far so good.
<sjoerd>
gordan: what went wrong ooi?
<gordan>
I think I at some point introduced a typo into my bootargs variable that has must have been sabotaging me for some time now.
<gordan>
I just reset it explicitly.
<sjoerd>
heh
<gordan>
Well, wrong load/entry addresses for the peach didn't help
<gordan>
So it was only a problem in the past 5 minutes. :p
<gordan>
But yeah.
<sjoerd>
yeah that's why i really want people to use the preset variables rather then cargo culting numbers
<gordan>
Gotta love those compound problems where changing any 1 thing makes no difference. >:-(
<javier__>
sjoerd: +1
<gordan>
The problem is that most of the default variables are complex garbage.
<sjoerd>
and really use the extlnux.conf method as that also makes thignsa bit less errorprone
<sjoerd>
then you don't need to know anything about uboot
<gordan>
Yes, but to me it is more important to have obvious easy to assess config in u-boot than a really complex one with dozens of varialbes that won't even find the kernel on the partition layout/devices I want to use.
<javier__>
gordan: all the complexity is there for a reason to abstract the boot process to users
<javier__>
yeah you can set a very simple bootcmd for your needs but that is error prone
<gordan>
I get that. But there is definitely a wood-for-trees problem that goes with it.
<gordan>
Put it this way, the default options didn't get anywhere near working for me.
<gordan>
But then again, I didn't use a pre-cooked recipe that is to be followed blind by somebody who has no idea what it means.
<javier__>
well it will only work if you do what the default options expect
<javier__>
anyways, I'm glad that you finally got the machine booting
<gordan>
Me too! :)
<gordan>
It certainly makes future stuff easier.
<gordan>
Annoyingly, I managed to come up with a workaround for the lack of initrd that is actually better than using the initrd.
<gordan>
But I can still keep that with u-boot's extra benefits. :)
<gordan>
Thanks guys, I really appreciate your help.
<gordan>
Couldn't have gotten to the bottom of it without you.
<javier__>
yw
gordan_ has joined #linux-exynos
<gordan_>
Hmm... It looks like exynos_defconfig on 4.1.12 doesn't seem to include support for whatever the hardware clock is in the peach pi
<gordan_>
After reboot the time gets reset
<gordan_>
And dmesg shows this:
<gordan_>
s3c-rtc 101e0000.rtc: failed to find rtc source clock
<gordan_>
maz77802-rtc max77802-rtc: hctosys: unable to read the hardware clock
<gordan_>
I think that worked with the ChromeOS 3.8 kernel
<javier__>
gordan: mmm, that should be working. I'll add to my TODO to look at that if is not working with 4.3 or if some fix should be backported to 4.1.x
gordan has quit [*.net *.split]
<gordan_>
I suspect I found the difference compared to the 3.8
<gordan_>
Both max77xx and s3c are compiled into the kernel statically by default.
<gordan_>
On 4.1 defconfig
<gordan_>
On 3.8 s3c-rtc is a module
<gordan_>
I'm just rebuilding the kernel with s3c modularized, see if that makes a difference.
<javier__>
but it shoulnd't matter because the s3c should handle the case where the source rtc clock (max77802 ap clk) was still not registered and return -EPROBE_DEFER
<gordan_>
Perhaps. I'll let you know if modularizing the s3c fixes the problem.
<gordan_>
I might just have to try 4.3, just for the GTS scheduler for MOAR CORES.
gordan_ is now known as gordan
<gordan>
OK, that didn't fix it.
<gordan>
With max77802 built in on rtc0 and s3c on rtc1 as a module:
<gordan>
hwclock --rtc /dev/rtc0 --show
<gordan>
hwclock: ioctl(RTC_RD_TIME) to /dev/rtc0 to read the time failed: Invalid argument
<gordan>
hwclock --rtc /dev/rtc1 --show
<gordan>
Sun Jan 11 02:13:40 2009 -0.380541 seconds
<javier__>
gordan: and if you set a date and then do a hwclock -w to set the hw clock from the system clock ?
<javier__>
both max77802 and s3c rtc should be working
<javier__>
but it could be that a regression was introduced since the support was added in 3.19 iirc
<gordan>
max77802 seems to barf both on reading and writing to it.
<gordan>
s3c works.
<gordan>
And the time survives a reboot.
<gordan>
So as a workaround I can switch them around, have max77802 built as a module so that the time save/restore works automagically.
<gordan>
But it is definitely the max77802 driver that seems to be broken.
<gordan>
One obvious difference is that there are two max drivers now, rather than one generic one.
<gordan>
My guess would be that whenever they were spplit up something got broken.
<javier__>
gordan: not really, the combined driver wasn't a good idea at the end since the register layout was very different so caused more harm than good. Besides mainline already had a max77686 driver
<javier__>
gordan: so I took the max77802 bits to have a regulator, clk and rtc driver and only did a combined driver for the max77802 mfd part
<javier__>
and that was working when the drivers got merged so seems to be a regression
<javier__>
gordan: by having it built in or as a module you are just changing which driver ends as rtc0 but both were working
<javier__>
anyway, I added testing the max77802 RTC driver in my TODO list
<gordan>
Cool, thanks.
<gordan>
Handily, there seems to be a 2nd rtc to fall back on. :)
afaerber has quit [Quit: Ex-Chat]
<javier__>
gordan: yeah althought in the vendor tree is the opposite, max77802 is the one used and s3c is unused
<javier__>
IIRC
<gordan>
I don't have a preference between them, other than that I just want a working RTC. :)
<gordan>
It's a purely pragmatic decision.
<gordan>
I'm honestly surprised (but pleased) that there are two in this case. :)
<javier__>
gordan: yes, what I meant is that both should be (and were) working well in older kernels so something broke
<gordan>
Yup
pekka30 has quit [Ping timeout: 272 seconds]
pekka30 has joined #linux-exynos
gordan has left #linux-exynos ["Konversation terminated!"]
amitk has quit [Quit: leaving]
zombah_ has joined #linux-exynos
gordan has joined #linux-exynos
<gordan>
I spoke too soon.
<gordan>
The s3c rtc doesn't survive a cold shutdown.
<gordan>
So it seems it's the max77xxx or bust. :(
zombah_ has quit [Ping timeout: 250 seconds]
zombah_ has joined #linux-exynos
zombah_ has quit [Ping timeout: 264 seconds]
ojn has quit [Ping timeout: 246 seconds]
ojn has joined #linux-exynos
<gordan>
Hmm... I am configuring 4.3 to try on Peach Pi but I cannot seem to find the GTS scheduler that allows running all 8 cores.
<Wizzup>
gordan: simply don't enable the bL switcher and it will be on by default
<Wizzup>
IIRC
<gordan>
Oh, that simple? cool! :)
<gordan>
OK, that's interesting, in 4.3.0 the max77802 doesn't work until I save hwclock --systohc to the s3c-rtc.
<gordan>
After that the max77802 works.
<Wizzup>
:)
<gordan>
And - 8 cores!
<Wizzup>
:)
<gordan>
:D
<Wizzup>
If you have more questions, please do ask. Also, do you want a wiki account? The wiki needs a lot of love
<Wizzup>
I'm travelling so much, combined with work, I can't find even 30 minutes to just sit down and work on it
<Wizzup>
If I am not here, Swabbles can also create wiki accounts.
<gordan>
I can try to find time for it, but no promises.
<gordan>
Basically, if I can find time put a note on the RedSleeve wiki, I'm sure I can paste the non distro-specific bits to another wiki. :)
krzk has joined #linux-exynos
<Wizzup>
I run gentoo mostly, so most of my instructions would be for gentoo.
<gordan>
In fairness, there is very little distro specific stuff in getting the machine actually working.
<Wizzup>
well, x video driver is one.
<Wizzup>
they have slightly different names, and versions matter
<gordan>
What we're talking about here is all the stuff that happens _before_ the userspace actually loads
<Wizzup>
I used to use fbturbo, because it's *fast*
<gordan>
Until I can get audio working reliably, I'm not too fussed.
<gordan>
As long as webpages render fast enough, I don't need anything more than fbdev
<Wizzup>
But with xf86-video-modesetting, you can use the hdmi output
<gordan>
OK, that _is_ handy.
<Wizzup>
You'd be surprised at how fast the scripping is
<Wizzup>
That's what I meant with xrandr woks
<gordan>
For what 99% of my usage of the chromebook is, fbdev is good enough.
<gordan>
I have a 4K x86 monster laptop with a GTX970 for gaming. :p
<Wizzup>
peach-pi is my work, hobby and travel machine
<Wizzup>
so I do care a bit :)
<gordan>
Sure, I get that.
<Wizzup>
but yeah, still carry an external usb audio card ;)
<gordan>
Unfortunately, having tried the 4K matter screened laptop for work, it's impossible to go back. So.... many.... terminal... windows... :D
<Wizzup>
I don't have a 4k capable gpu at home
<gordan>
Having said that, working hdmi would be handy at times.
<Wizzup>
It is if you use a desk ;)
<Wizzup>
have a desk*
<gordan>
I was talking about a laptop.
<gordan>
At home I use an old IBM T221 since many years ago, it has only just been displaced as the highest res monitor ever made at 3840x2400. The new 5K screens finally beat it.
<gordan>
The main problem with running the T221 is that you need multiple DVI links to drive it at reasonable refresh rate due to interface bandwidth limitations.
<gordan>
1x SL-DVI and you get at most 17Hz refresh.
<gordan>
With 2x SL-DVI you get about 33Hz.
<gordan>
It can take up to 4x SL-DVI, for a maximum of 48Hz refresh.
<Wizzup>
I have a cheap 4k monitor, but nothing to drive it ;)
<Wizzup>
I had a decent amd gpu, but gave it to my dad when he needed it
<gordan>
There is also a custom adapter available to make it run off 2x DL-DVI at 48Hz, but that only works on later models with slightly updated FPGAs for signal decoding.
<Wizzup>
Ah...
<gordan>
Remember this is a monitor from 2001!
<gordan>
Back then the list price was something insane like $30,000
<gordan>
I picked mine up in 2008 for about £1,000
<gordan>
Worth every penny.
<gordan>
You need a truly monster GPU to run even a very fast game like L4D2 at full fps.
<gordan>
But let's face it, 4K isn't for gaming, it's for keeping tons of code in front of your eyes legibly all at the same time for context.
<Wizzup>
I just use a small font and mostly manage
<Wizzup>
right, I'm flying again tomorrow (was home for a total of two days), talk to you later :)
<gordan>
Later. :)
<gordan>
Ouch! The slow cores on the Exynos 5800 are over 3x slower than the fast ones!
<Wizzup>
Told you it would kill the firefox experience ;)
<gordan>
I honestly didn't expect THAT big a difference.
<gordan>
So basically the total boost from running on all 8 is only 30% over the 4 fast cores. :(
<gordan>
I mean, better than a kick in the nuts, for sure, but I kinda expected more.
<gordan>
I guess I know how they made the A7 cores so power-miserly.