nsklaus has quit [Read error: Connection reset by peer]
nsklaus has joined #asahi-dev
gabuscus has quit [Remote host closed the connection]
gabuscus has joined #asahi-dev
suricato_ has quit [Remote host closed the connection]
suricato has joined #asahi-dev
<alyssa>
povik: Gah, no audio this boot
<alyssa>
same symptom
<alyssa>
[ 1.121952] cs42l42 2-0048: Get Revision ID failed
<alyssa>
[ 1.133647] cs42l42: probe of 2-0048 failed with error -61
V_ has quit [Remote host closed the connection]
yuyichao has joined #asahi-dev
V has joined #asahi-dev
PhilippvK has joined #asahi-dev
phiologe has quit [Ping timeout: 480 seconds]
phiologe has joined #asahi-dev
kov has quit [Quit: Coyote finally caught me]
PhilippvK has quit [Ping timeout: 480 seconds]
kov has joined #asahi-dev
<marcan>
I'm wondering if our tipd curse extends to i2c in general or what
chadmed has quit [Read error: Connection reset by peer]
chadmed has joined #asahi-dev
jeffmiw has joined #asahi-dev
<jeffmiw>
what are the "/bits/" branches on github/asahi/linux used for ? shall I create one to share my spmi/pmu/rtc drivers ? or shall just create my branch of asahi one ?
the_lanetly_052___ has joined #asahi-dev
jeffmiw has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #asahi-dev
<kloenk>
I think I'm still not sure how to do fat. Where to read files from? direct nvme? Where should the file be stored/which name? What should I do with the file after verifying it?
<_jannau_>
kloenk: you're too fast so the infrastructure is not there. I suppose the installer will embed a config payload which will specify a GPT partition UUID of the matched EFI system partition
<kloenk>
ok, hoped I could already do something
<_jannau_>
the second stage m1n1 should be read from that partition. After verification it will be loaded by the active m1n1 in a similar fashion as the proxy chainlaod
<_jannau_>
I suppose you could start testing by creating a ESP partition and hardcode it's start and end sector
Major_Biscuit has joined #asahi-dev
<kloenk>
Sadly I only have my main mac, on which I'm very very dependend, so can only write theoreical code :)
<_jannau_>
you could check if there's a useable gpt partition crate. we only need read support
MajorBiscuit has quit [Ping timeout: 480 seconds]
<_jannau_>
as first step it would be fine if it uses the first EFI system partition
<povik>
marcan: saw the github issue and i am wondering the same
<kloenk>
Doesn't look like there is a usable gpt crate. all I found wanted to use std
<Jamie[m]1>
hm yeah
<Jamie[m]1>
gpt and gptman both use the Read/Write traits
the_lanetly_052__ has joined #asahi-dev
<kloenk>
maybe I will just write a new gpt libary with a friend together
the_lanetly_052___ has quit [Ping timeout: 480 seconds]
<_jannau_>
not sure if there strong security advantage of doing the limited gpt parsing we need in rust. one argument for rust would be that all nvme data proecessing code is in rust
<kloenk>
Yes, parsing the table in C, and just giving rust the starting address should also work. Will have to think about it
<_jannau_>
I guess you could just reuse the read part of one of the existing crates and read replace the io with what you're doing in the fat code
<marcan>
GPT is trivial anyway, shouldn't be a problem to implement in Rust
<j`ey>
kloenk: another option for vendoring is a git dependency, to avoid the full `cargo vendor` route
<kettenis>
marcan: I have seen some issues with reading back registers from the tas5770 codec immediately after writing to them (in OpenBSD)
<kettenis>
but just reading the cs42l83 revision register seems to work reliably for me
<kloenk>
[j"ey](https://matrix.to/#/@irc_oftc_j=60ey:petabyte.dev): yeah, but I favour the "cargo vender` route, as vendor cleans the crates, we don't need the CI configurations and stuff like that from the dependencies
<kloenk>
and matrix<->irc bridge creates funny texts again :)
Major_Biscuit has quit []
MajorBiscuit has joined #asahi-dev
<kloenk>
The thing that is blocking my mind right now is how to get the size of the drive. Is this reported by nvme?
<j`ey>
kloenk: I kinda don't like the vendor route, for just having a whole bunch of 'copy / pasted' code, but it doesnt reallly matter
<Jamie[m]1>
kloenk: it's in gpt (Last usable LBA)
<kloenk>
yes, just discovered that. Now reading the uefi specs :)
<ChaosPrincess>
kloenk: i also started writing a gpt parser
<kloenk>
ChaosPrincess: mind showing it to me? I think I want to write a crate, which has std support, but as default does not use std
<kloenk>
want to work together on it?
<ChaosPrincess>
sure
<kloenk>
ChaosPrincess: are you on matrix? maybe we should create a new room for this
<ChaosPrincess>
on irc
<j`ey>
can you make it an irc room?
<ChaosPrincess>
moved to pms
<kloenk>
I don't know how to, but if someone can create it, i think it's a good idea. I want to name the crate "nogpt" (as it has no_std support)
the_lanetly_052__ has quit [Ping timeout: 480 seconds]
<ChaosPrincess>
can we just assume that the block size is 4k?
<povik>
kloenk: you don't need to create it, you can simply join #nogpt
skrzyp has quit [Remote host closed the connection]
<sven>
ChaosPrincess: yes, at least all M1 Pro/Max chips have a 4k block size
skrzyp has joined #asahi-dev
kaprests has joined #asahi-dev
<kloenk>
marcan: I just discovered that the fat32 crate is eol. the author recomends rust-fatfs
off^ has joined #asahi-dev
the_lanetly_052__ has joined #asahi-dev
<kloenk>
well core_io does not build, seems like that does not work as well
<kloenk>
master does build, but it's not block based. so also a pain in the ass
the_lanetly_052___ has joined #asahi-dev
the_lanetly_052__ has quit [Ping timeout: 480 seconds]
<marcan>
kloenk: I don't particularly care about it being eol if it works
<DmitrySboychakov[m]>
nothing is bug-free, since it is eol - nothing will be fixed
<alyssa>
DmitrySboychakov[m]: it's FOSS -- if you use it and fix it yourself, congrats it's not eol anymore
<DmitrySboychakov[m]>
alyssa: that's also true :)
the_lanetly_052___ has quit [Read error: Connection reset by peer]
yuyichao has quit [Ping timeout: 480 seconds]
yuyichao has joined #asahi-dev
<kloenk>
yeah, I think using fat32, and fixing it ourself if needed is best. but I think then it's better to at least vendor that properly as an active project, and not as a dependency
<ChaosPrincess>
kloenk: you vendored rust deps incorrectly, the version now in repo has LF line endings, while cargo expects CRLF and complains about checksums not matching
<kloenk>
oh, git did that. uff. yeah, will have to fix that
<kloenk>
first will continue on my nogpt library
jbowen has quit [Ping timeout: 480 seconds]
<j`ey>
marcan: do you want to make #asahi-rs or #asahi-rust or something?
jbowen has joined #asahi-dev
bisko has joined #asahi-dev
<povik>
i tried stress-testing and doing random things with the linux pasemi i2c driver (copied out of linux, running from m1n1), but didn't see anything funny
<povik>
it was all against the cs42l part, with reads on empty addresses interspersed (because linux does that too)
<povik>
next idea: are we resetting the i2c controller properly?
<povik>
alyssa: you have recent iboot, right?
<j`ey>
povik: what does 'empty addresses' mean?
<povik>
address where no device responds
<j`ey>
ah
<povik>
so the read attempt ends in a NACK
<alyssa>
povik: no, 11.x iBoot but that was same as you I thought
<povik>
yes
<ChaosPrincess>
kloenk: fat32 is terrible and does not expose file lenghts, im forking it
<kloenk>
Can you give me some time. I would suggest giving you access to my m1n1 fork. And then putting it there as a workspace member
<ChaosPrincess>
i will fork your repo and send a pull request when im done breaking stuff :P
<kloenk>
But afk right now. Send my your username, and I’ll give you access as soon as possible
<povik>
tpw_rules: also you may want to try this ^^
<povik>
this disables the random i2c probing linux does
<povik>
sven: i think it may be a good idea to take on that change for i2c-pasemi-platform even if it doesn't fix anything. as the driver is only used on devicetree platforms where the i2c slave devices will be explicitly instantiated
<sven>
sure, just make sure it only changes the platform driver and not the pci one and send a patch to the mailing list :)
<povik>
yeah, okay then
<alyssa>
u
<povik>
here it is in commit: https://tpaste.us/r6l1 (how rude of me to send plain patches)
<ChaosPrincess>
for chainloads, what signature/hash algorithm are we gonna use?
<kettenis>
which happens to be what OpenBSD's signify tool uses as well
<kloenk>
that exact library?
<kettenis>
(ed25519 I mean, not the rust implementation)
<kloenk>
ah yeah, think nixos uses it as well. I use it for ssh
<kettenis>
signify uses its own implementation that is derived from djb's public domain implementation
<ChaosPrincess>
so, lets say /m1n1.bin containing the code to chainload, and /m1n1.sig containing the result of Signature::to_bytes from that library?
<kloenk>
Not sure yet. we could also include the signature in the bin file
<kettenis>
you typically sign the hash
<kettenis>
so that's what /m1n1.sig would be
<ChaosPrincess>
yea, the library does the hashing itself
<kettenis>
to verify you verify that /m1n1.sig was signed with the appropriate key and then you check that the hash for the loaded /m1n1.bin matches the signed hash
<ar>
/40
<kettenis>
signify uses sha256 as the hash, but these days you can probably do better
<sven>
for a proof of concept m1n1.sig plus whatever that library uses by default sounds reasonable to me
<kloenk>
Does m1n1 have gui? (Asking because what should happen if one of the two gpt headers are broken)
<ChaosPrincess>
output only
<ChaosPrincess>
you can write to a screen console, but no kb/mouse/usb support
<kloenk>
The spec only says it has to print a warning, not that user entry is required to fix a gpt header
<ChaosPrincess>
we arent fixing gpt from m1n1, thats the os job
<kloenk>
> Software should ask a user for confirmation before restoring the primary GPT and must report whenever it does modify the media to restore a GPT.
<kloenk>
okay, it would be quite easy though :)
<sven>
we should never modify the disk from m1n1
<kloenk>
yeah, fair point
<sven>
this should all be as simple and as dumb as possible. If something doesn’t work out just bail and don’t chainload anything and continue as if there was no m1n1.bin on the disk
<kloenk>
ChaosPrincess: Maybe then you should BlockDevice's write with a direct error, so it's completely forbidden