IRC channel logs
2023-06-10.log
back to list of logs
<oriansj>muurkha: I think I finally found a reason to port stage0 to ESP32 <oriansj> https://www.crowdsupply.com/soldered/inkplate-6 ; I figure if I get moderately useful emacs org-mode reader with inline picture support; I'll have a first attempt at an eternity manual device and I'll just have to grow out my notes until they cover everything needed to build such a device from first principals <stikonas>actually some new ESP32 chips are riscv32 <oriansj>well I guess I am going to learn the ugly details when they show <theruran>I finally figured out that my drive with all my cloned Git repos of code on it was mounted noexec despite 'exec' ostensibly being in the 'defaults' <theruran>(fresh install.) probably a security feature of Void Linux <stikonas>theruran: oh, so it's nothing to do with pie? <stikonas>or rather non position independent executable (kaem-optional-seed) <theruran>no, I don't think so. since all checksums pass on my other Arch Linux-musl machine <muurkha>oriansj: yeah, QED as described was a pretty powerful editor <muurkha>oriansj: I think e-ink is still power-hungry enough that you need a battery or line power. building batteries at home is achievable, of course <muurkha>in theory a copper-iron battery should be 0.79 volts; six of them in series should get you five volts <muurkha>copper is pretty scarce, but iron is abundant, and if I understand correctly, it's the iron that gets consumed <oriansj>muurkha: granted, but a 25 μA @3.7v isn't a hard requirement to hit <muurkha>is that all the device needs on average? I'd've guessed more like 25 mA during use <oriansj>well the battery they reference lasting months is 1200mA <oriansj>so i am guessing aggressive write to eeprom and powerdown <oriansj>which puts this well within range which a human can charge using a hand dynamo <muurkha>but maybe that's just the peak current, like when it's erasing the dcreen <muurkha>possibly? is that what you meant, oriansj? <muurkha>it would still be sort of meaningless without knowing the voltage <muurkha>but we can probably guess that the battery voltage is somewhere in the range of 3.7V to 37V <muurkha>it's surely not 1200mAh at 0.1V or 1000V <muurkha>well, assuming those two currents are at the same voltage, but that's not a valid assumption <muurkha>there's surely a SMPS between the battery and the ESP32 <muurkha>anyway, yes, a handcrank or pullstring generator is a reasonable thing to use <muurkha>also it says 1200mA charging current is "1C" and 600mA is "0.5C" <muurkha>'s 16kJ. at a 100mW average load, which I think is typical for a Swindle, it would last about 48 hours of use <muurkha>maybe that's "months" if you read on it for half an hour before going to sleep every night <muurkha>or maybe the average power draw of the machine in use is much lower than my 100mW estimate <muurkha>16kJ at 0.2mW is two and a half years <muurkha>(of course, you need something to generate the display updates, but plausibly that could also be a lot less than a milliwatt, even with traditional CMOS) <oriansj>hmmm; valid points. Also I realize I have a good bit of software to write to achieve my desired final state of software <muurkha>but this is all based on my SWAG of 100mW <stikonas>I still need to provide you with an updated gnu style commit message <stikonas>how do I do it with your rebasing system? <janneke>stikonas: great, i'll just cherry-pick your commit to keep a linear history <stikonas>yes, no force-rebase is required for now <stikonas>but if you want me to change commit message <janneke>ah, but that rule only holds for master <stikonas>I think I am asking more about those macros you use, like !squash <stikonas>I'll just prepare the text in some editor/pastebin <janneke>the squash! is just a (magit) convenience <stikonas>though that might have to wait till the evening, I might need to go weekend shopping first <stikonas>I was trying to find where those macros are coming from... <janneke>keeping them separate for a bit makes it easier to see what changed <janneke>stikonas; so you're welcome to squash those commits into yours and then add a changelog, and otherwise i'll do just that ;) <stikonas>janneke: not sure if you saw my message, I had a bit of success with tcc but it's not able to bootstrap itself <janneke>you esp still have troubles with long long or float? <stikonas>I should probably push my intermediate changes somewhere <stikonas>and at least some of the issues are in mes C library <stikonas>assembly code in linux/riscv64-mes-gcc uses far more stuff than tcc is able to understand <stikonas>and actually running the whole chain in qemu-riscv64 (binfmt/user emulation) takes about 6 hours here <stikonas>well, mes is slow and emulation slows it further <stikonas>not much we can do about emulation being slow <stikonas>you could perhaps use native mes to build riscv64 version of tcc for development... <janneke>stikonas: you can run mescc with guile, that may speedup things a bit <stikonas>though that would need more time on my side to adjust build environment <janneke>it did/does for x86, i've done that a lot while working on tcc <janneke>but the cross-compile trick might work too <stikonas>right now I hacked live-bootstrap with some minimal changes to run riscv64 rather than x86 <stikonas>(branch name comes from my attempts to also test amd64 support) <stikonas>amd64 support is actually worse then riscv64 <stikonas>I guess nobody worked on porting x86_64_*.c files to mescc <stikonas>(and if you or somebody else want to try that live-bootstrap branch, I was running it with "./rootfs.py --arch riscv64--bwrap -p" (-p is to keep build dir present after run eventually fails) <stikonas>argh, space got lost in the command above <stikonas>./rootfs.py --arch riscv64 --bwrap --preserve <river>there was a virus in the modded minecraft community. it has been mostly sorted. but there was a meeting about mitigation and there was some discussion about things like code signing, reproducible builds, the security benefits of CI, 2fa <river>ultimately it sounds like they are not going to do reproducible builds <river>but it was interesting to listen to <janneke>river: wow, there's quite some corporate bullshit there <janneke>"safety is critical [..] and we're doing everything we can to improve and correct" <janneke>(while you say, they'll not even do rb, let alone bb?) <janneke>and the old security by obscurity bullshit <janneke>on the "security tests" they run: "exposing everything we do [..] will eventually lead to vulnerabilities" <janneke>ACTION gives up watching after 11min <stikonas>janneke: actually, thinking of your question about long long, would that even be a problem with 64-bit arches? What's the behaviour of mescc? <stikonas>I was still trying to build it with long long disabled, but could it just work? <janneke>stikonas: mescc doesn't support long long, other than parsing it <stikonas>so we might actually have fewer problems with long longs there <stikonas>there are other riscv64 problems on tcc... <stikonas>it doesn't like some assembly, complained about some casts <stikonas>and also squashed all of them into a single commit <stikonas>I also have (not committed there) a kaem file for building libc and mes <stikonas>though I'm still thinking on the best way to split it <stikonas>(i.e. do we want to have individual steps to just build libc without mes) <stikonas>I suspect more modular approach would be better <janneke>i don't really need them now, but i'm happy to include them <stikonas>well, I'm thinking about those bootstrapping projects that don't have other shell <stikonas>yes, in guix you have guile for now and can run gash early... <janneke>we will probably need them anyway when we remove guile and switch to gash-on-mes, but that will take a wile <stikonas>yeah, and not everybody has guile, e.g. even that Nixos bootstrap project doesn't have access to it <stikonas>anyway, at the very least mes and mescc can now build each other on riscv64 <janneke>yes, beautiful, great job and *thank you* <stikonas>hmm, yes, for now mes-m2 can't bootstrap tcc either <stikonas>building mes is essential (on both 0.24 and future 0.25)