<marcan>
it sounds like it might work for when I bump asahi to new linux-next or -rc bases, and as a side effect preserves the old state in the history so you could dig up "what asahi looked like on top of that -rc in the past".
<marcan>
tl;dr it basically creates a dummy merge from asahi into the next base, but discards all changes; then re-applies all the patches on top
<marcan>
OTOH I probably don't want to do that for my usual rebasing/squashing/fixup cycle when working with downstream commits, so those would still be force pushes (but less painful to rebase on top of)
nabaiste^ has joined #asahi-dev
<Jamie[m]1>
downloading a file in safari under the m1n1 hypervisor seems to be reliably causing AGX-related kernel panics lol
<Jamie[m]1>
(presumably related to the animation of the file flying across the screen into the download button when a download starts?)
<tpw_rules>
kettenis: i've finally released all my work. i made two patches to u-boot i'd like to get upstreamed in some manner
<tpw_rules>
the second is code which massages device trees u-boot loads to incorporate the tweaks m1n1 makes: https://github.com/tpwrules/nixos-m1/blob/main/nix/u-boot/0001-m1n1-fdt-compat.patch this way distros can specify arbitrary device trees and have them work properly. this also means users don't have to involve kmutil to update device trees.
<tpw_rules>
theoretically this will not work if the distro device tree has more hardware than u-boot because m1n1 won't have massaged those parts. but it prints out a warning in that case and that shouldn't really happen in practice
<tpw_rules>
i'm going to sleep soon, but i would be grateful if you could help me get that second one upstreamed officially somehow instead of just taking the ideas
<marcan>
Jamie[m]1: what panics specifically?
<marcan>
tpw_rules: I'm not sure that DT massaging approach is useful; precisely what we'd want new DTs for is adding new hardware
<marcan>
given the direction things seem headed in, and that it looks like I need to add RTKit to m1n1 anyway, it's starting to sound like the future is m1n1 chainloading itself from the EFI system partition. once we have RTKit, a dumb NVMe driver shouldn't be too hard, and I'm used to throwing fatfs everywhere...
<marcan>
then *that* could be updated with new device trees and U-Boot versions
<marcan>
and we solve the having to go into 1TR for updates problem
<marcan>
(funny how originally I wanted to add storage to m1n1, then I ditched that and left it to U-Boot, and now it's sounding like it might make sense again...)
<tpw_rules>
building a new u-boot for each device tree wouldn't really work for nixos, but the nixos on arm vision is to have the platform (i.e. u-boot or m1n1) provide a complete device tree and just use uefi. lots of other distros are certainly device tree centric though. but it's fine if that ends up not being useful, i just want credit if it does :) and it does work well for now. it will only encounter problems if there are
<tpw_rules>
new i2c or usb nodes added, or m1n1 starts disabling another type of device
<tpw_rules>
and again, thank you and kettenis for actually making all the hard bits go. i couldn't have gotten this done in a week without it
<marcan>
remember one of the goals of the way we're doing the kernel stuff is that hopefully we can add partial support for new platforms without any kernel changes at all
<marcan>
just using new device trees
<marcan>
(enough to boot an installer at least)
<marcan>
that all breaks down if distros are providing their own device trees
<marcan>
the idea is the bootloader should provide the DT
<marcan>
DTs are specified to be backwards and forwards compatible for this reason
<marcan>
(and we try to keep it that way)
<marcan>
as far as I'm concerned the only problem with the current approach is updating m1n1+dt+u-boot is mildly inconvenient
<marcan>
and the solution for that isn't DT merging, it's m1n1 chainloading itself, since it's not just about the DT; we want to be able to update m1n1 too, it goes together with it
<tpw_rules>
nixos (and I) agree with the vision of the bootloader providing the DT too. but i'm not sure how practical that is. but as long as m1n1 becomes UEFI compatible, or that's all u-boot does, i would be happy.
<marcan>
u-boot provides UEFI services
<tpw_rules>
ah ok i see what you mean. yeah that would be good
<marcan>
we've already proven that m1n1 chainloading is extremely effective during development; I very, *very* rarely have updated my installed m1n1
<marcan>
(the init code is basically written to be idempotent)
<marcan>
so that plan is definitely solid as far as that is concerned
<marcan>
u-boot already has UEFI support; people are using GRUB on top of it. that's always been the plan
<marcan>
in addition, m1n1 will have to start providing PSCI services to everything down the chain at some point, with a new mechanism we'll have to invent :-)
<tpw_rules>
my imagination for the asahi installer is it would eventually just set up an EFI system partition, with an option to download Asahi's own rootfs and grub for convenience. then once the kernel stuff gets upstreamed people can just use the official UEFI installers of the distro of their choice
<marcan>
that has been the plan all along, yes
<chadmed>
pretty sure thats always been the plan
<chadmed>
yeah ^^
<tpw_rules>
alright. i'd be delighted to bang on it and update stuff i've written as soon as it's ready
<marcan>
I want to offer a list of pre-baked images (we'll do the Arch ones, other distros can maintain others) so users have that convenience, plus an option to just create a blank EFI partition and leave it to an installer
<marcan>
we could also offer some kind of mechanism to stage a netinstall image for first boot or something like that
<marcan>
tpw_rules: what is your current boot chain? no UEFI?
<tpw_rules>
no, currently it uses /boot/extlinux/extlinux.conf
<marcan>
ah...
<tpw_rules>
uefi does work though
<marcan>
yeah, tbh I'd be very grateful if you could get it working with uefi+grub since that is the direction we're going to be moving towards, and I'd rather someone document that one
<marcan>
that will also let us find out how well existing distro installers work (if we just replace the kernels)
<Jamie[m]1>
I'm guessing I might have a kernel version which is mismatched with the agx firmware
<marcan>
if you are using the HV you need to use the same exact kernel as was present in the underlying macOS
<marcan>
you can get it from the Preboot partition
<marcan>
anything else is a recipe for crashes, often right at boot
<Jamie[m]1>
yeah makes sense
<Jamie[m]1>
ty
<tpw_rules>
marcan: alright, i'll look at that tomorrow. should be straightforward. but it's my bedtime here
<marcan>
cool :)
<sven>
or we just write our own kmutil and use that auxkc hack :>
<marcan>
sven: I don't think that would work
<marcan>
apparently auxkc is not a thing with fuos
<sven>
aw :(
<sven>
anyway, nvme is simple enough. probably even simpler than rtkit
<Jamie[m]1>
oh, I've just noticed that my avd has a dart,t8110 rather than ,t6000
<marcan>
yeah, I noticed that too
<Jamie[m]1>
that kinda foils my plan of "i don't need to RE anything about the dart since others already have" lol
<marcan>
t8110 is A15; it might actually be the same as t6000 and they just typoed it :p
zsxh has joined #asahi-dev
<Jamie[m]1>
lol
<marcan>
hm, different driver though
<marcan>
t8020, t8110, t6000 have different drivers
<marcan>
I wonder what they did with t8110 then
<marcan>
though I can't imagine they changed much
<marcan>
the only thing that changed in t6000 that we cared about was the PTE format
<marcan>
I doubt they came up with *another* PTE format...
<sven>
I think they actually did
<Jamie[m]1>
I have traces if you're interested?
<sven>
look at strings of the t8110 driver
<sven>
it’s also used for thunderbolt
<marcan>
ah, heh
<marcan>
yeah, TB is bound to be more special
<Jamie[m]1>
acpiec, video decode, prores, and scaler
<sven>
I’m surprised it’s also used for avd though
<Jamie[m]1>
odd selection lol
<marcan>
there's apparently a "CTE" thing in that dart?
<marcan>
and "STT"
<sven>
yeah
<marcan>
"chunk table" "segment table"
<marcan>
heh
<sven>
it also looks like it can do one more stage for some reason?
<marcan>
but t6000 also has "segment tables"
<marcan>
ah wait, won't this be for >4G inputs?
<marcan>
t6000 DART still only supports 32-bit dvas as far as I know
<sven>
yeah, but it could already supoeot
<marcan>
so that would make sense that they added an extra stage
<sven>
*support more
<marcan>
yeah
<sven>
even the first TTBR does like 2 or 3 bits more
<marcan>
so before we had TTBR -> STT -> PT
<marcan>
now we have TTBR -> CTE -> STT -> PT
monn has joined #asahi-dev
<marcan>
*CTT
<sven>
I was kinda hoping we could just ignore all this until we get to thunderbolt :(
<marcan>
also I wonder what all the SMMU strings are about, or is this for VMs?
<sven>
SMMU is this weird thing that looked like it had that pagetable cache
<sven>
it’s not arm’s SMMU
<marcan>
ah
<marcan>
I just remember the TLB cache thing
<marcan>
were there actual registers there?
<sven>
yeah
<sven>
A few
<marcan>
heh
<marcan>
anyway, this sounds like it should be pretty easy to work out with the hv
<sven>
probably
<marcan>
just do something with AVD, break and dump the DART with the existing tools; any changes should be fairly evident
<marcan>
Jamie[m]1: apciec, you had me scared there for a second with "ACPI Embedded Controller" :p
<Jamie[m]1>
oh hahaha
monn has quit [Remote host closed the connection]
monn has joined #asahi-dev
<jannau>
marcan: installing grub and asahi as distro kernel was enough for u-boot to boot the system when I tried in summer
<jannau>
chainloading m1n1 from nvme also requires adding signing and verification into m1n1 for secure boot
monn has quit [Read error: Connection reset by peer]
<marcan>
jannau: indeed, but that's relatively easy, I was thinking about how to do that earlier
thunfisch has quit [Read error: Permission denied]
thunfisch has joined #asahi-dev
MajorBiscuit has joined #asahi-dev
Redecorating[m] has joined #asahi-dev
<kettenis>
tpw_rules: those patches facilitate exactly what I don't want to do in u-boot: letting u-boot somehow load a DTB that didn't come from m1n1
nabaiste^ has quit [Ping timeout: 480 seconds]
<marcan>
sigh, this wifi... now it tries to associate but fails
<marcan>
it smells like an auth failure, but as far as I can tell the PMK passed from the driver is correct...
nabaiste^ has joined #asahi-dev
<marcan>
ok, connecting to a no security network works, so it's definitely an auth issue
<marcan>
I don't see anything weird in the handshake though... it's like the key is wrong somehow
<matthewayers[m]>
marcan: I wonder if it’s something like an incompatibility with the spec?
<marcan>
um, no, macOS works
<matthewayers[m]>
I meant the wifi specs for security
<marcan>
again macOS works so obviously it meets the spec :-)
<marcan>
omg I made it work... please don't tell me this is the problem
<Jamie[m]1>
this is the problem
<marcan>
so normally the Linux driver sends the hashed PSK in hex form, which is one common way to represent it in contexts where a plain passphrase is accepted
<marcan>
I tried the ascii passphrase and it worked
<marcan>
... please tell me there *is* some way of sending the raw hashed PSK
<Jamie[m]1>
haha
<marcan>
ah wait... the max passphrase is longer these days it seems, for SAE
<marcan>
so there *has* to be some way of doing this, but I guess it changed?
<kettenis>
this is all handled by the firmware isn't it?
<marcan>
yes
<kettenis>
so there must be a new firmware call to pass the longer passphrase?
<marcan>
ahaha I fixed it
<marcan>
so normally flags = 1 "passphrase"
<marcan>
I... set flags to 0 and passed in the binary PSK instead of hex
<marcan>
and that worked
<marcan>
... so you're telling me the kernel didn't have to hexify stuff all along?
<marcan>
(or is this new?)
<marcan>
the problem is that now I don't know if this method works for all broadcom cards, or I need some kind of feature flag for this too
<marcan>
I think someone said the xorg fbdev driver (on top of simpledrm, not simplefb) worked?
<marcan>
kettenis: hey firefox and chromium are not a monoculture!
<kettenis>
well, on the 4K pagesize front they probably are
<sven>
so what you’re saying is I should just never submit another version of that 4K patch for the good of the entire internet? :p
<FireFox317>
firefox works for me with a defconfig kernel and the usual config options for m1 stuff (16k pages etc).
<FireFox317>
on alarm btw
<kettenis>
sven: yup ;)
<sven>
works for me :D
<marcan>
firefox317: xorg?
<FireFox317>
yep, had to launch firefox through the terminal tho, also this was like 3 weeks ago or something
<kettenis>
marcan: love how you worked a memset() in there
<marcan>
ah nevermind, it works now?
<marcan>
kettenis: it was leaking uninitialized stack to the wifi card
<marcan>
no bueno
<FireFox317>
marcan, havent tested lately
<marcan>
I saw it in the hex dump
<Redecorating[m]>
marcan: the patch you sent changing how the password is done works on bcm4364 MacBookPro16,1
<marcan>
that was fast, I was considering asking twitter
<kettenis>
marcan: yes; you should claim a CVE for this ;)
<marcan>
:p
<kettenis>
ok, OpenBSD already has the memset ;)
<kettenis>
and I think we're already using the binary data
riker77 has quit [Quit: Quitting IRC - gone for good...]
<kettenis>
sys/dev/ic/bwfm.c:bwfm_set_key_cb()
<kettenis>
so that suggests that method is supported by a wide range of hardware and firmwares
<marcan>
oh huh, nice
<marcan>
well, that makes this easy then
<marcan>
I wonder what chain of fail led to both the mainline driver and that Android one I found doing the hex dance for no reason
<dottedmag>
Maybe the oldest ones didn't support it?
<marcan>
well, the thing is bit 0 is "passphrase"
<marcan>
so you'd expect clearing it to do something useful
<marcan>
which is why I guessed that (and guessed right)
<marcan>
if this had been added later, it would've been a new flag, or 0 would mean passphrase
<marcan>
kettenis: do you know if the driver does a reset of the D11/802.11 cores on init/around firmware upload, or only of the ARM core?
<j`ey>
b8a64f0e96c2b258321ee03975aeb0f5e88a055b seems it was always that way
<marcan>
the former breaks badly and randomly on 4387
<marcan>
j`ey: yeah, I feel like someone knew about the passphrase interface but not the raw one for some reason, and then guessed (right) that the standard-ish hex passphrase form would work, and rolled with it
<marcan>
I'd say this is a Broadcom person so they should know better... but this is Broadcom we're talking about here
<dottedmag>
Submitted from @broadcom.com, curious
<marcan>
we know they're just as bad inside as they're outside :p
<marcan>
the other driver I found does not do the reset, so a priori I'm just going to special case *all* the chips I add in this patch series and not do it either on those
<marcan>
but maybe it's not needed on anything
bluerise has joined #asahi-dev
Glanzmann has joined #asahi-dev
<marcan>
at least on 4387 the ARM firmware resets the D11 cores (and presumably does it in a way that works, not what Linux does)
<bluerise>
Hiho
<Glanzmann>
marcan: xorg works for me with modsetting on debian testing on top of simpledrm. I can open firefox.
<Glanzmann>
marcan: Congrats on the wifi.
<marcan>
Jamie[m]1: I'd say "ugh, another big driver to reverse engineer", but honestly knowing Apple they might actually come up with one of the sanest wifi chipset ifaces out there...
<marcan>
and yeah firefox works now
<Glanzmann>
marcan: fbdev also works on top of simpledrm. I used your default branch for that.
<marcan>
no idea why it used not to
<marcan>
so I guess I can tweet :-)
<Glanzmann>
marcan: It was a bug in the rc kernels. We can bisect it if we really want to.
<marcan>
oh, the kernel bump fixed it? good to know
<marcan>
and I don't particularly care as long as it works
<Glanzmann>
marcan: Yes, mps spotted it.
<marcan>
cool
riker77 has joined #asahi-dev
<Glanzmann>
marcan: Also the modesetting driver in xorg which blazingly fast compared to 'fbdev' xorg. You can alread tell when you move the mouse.
<bluerise>
marcan: I think it depends on which ARM core we're using. For CA7 and CR4 we definitely also reset the 802.11 cores
<bluerise>
on CM3 there seems to be no reset of those
<bluerise>
I also remember that newer chips have two 802.11 cores, and we need to reset both
<bluerise>
That was one of the changes I added to support M1 iirc
<marcan>
and 4387 has *three* and I added support for that, only to realize it wasn't helping
<bluerise>
wow
<marcan>
the android driver I found also supports up to 3, so this isn't apple-specific
<marcan>
this is CR4, so yeah, I expect openbsd to run into the firmware explosion on 4387 (the telltale that things are about to go wrong is if the first line of the console log complains about reset_status)
<marcan>
if it *doesn't* then that would be very interesting and might lead to a fix for the reset sequence on linux :-)
<marcan>
I tried a bunch of stuff with the reset sequence, including a workaround I found in that android driver, but nothing worked
<marcan>
doing the resets just causes something to go horribly wrong with the AXI interfaces, and 1 second after boot it almost always crashes hard with AXI errors
<bluerise>
Maybe the core is doing a null-ptr-access then ;)
<marcan>
I get weird fault addresses, sometimes small, sometimes starting with ff and such, and the blocks they hit also change (sometimes the CR4, sometimes PCIe, sometimes something else)
<marcan>
so it sounds like "something went horribly wrong at the logic / clock / etc level"
<marcan>
like a bad reset really
chengsun has quit [Quit: Quit]
<marcan>
actually, there's one thing I didn't try...
chengsun has joined #asahi-dev
<marcan>
ha, that worked
<marcan>
bluerise: so apparently the cores are *already* in reset on cold startup... and it's *releasing* reset that breaks it
<Glanzmann>
I see. Wow.
<kettenis>
so they start running before the firmware has set up other bits that they depend on...
<marcan>
yeah, something like that
<marcan>
the question again here is, is this a thing that was wrong all along, or do we actually need to release reset for older chipsets
<Jamie[m]1>
seems like more differences than similarities between dart,t6000 and dart,t8110...
<marcan>
Jamie[m]1: looks like some blocks moved around, e.g. 70 -> 228
<marcan>
I think these support 64 SIDs? which explains everything getting shifted
<marcan>
800 looks like a mapping table
<marcan>
100c is probably the TCRs but with different bits?
<marcan>
500 looks like the TTBRs, but they're 64-bit instead of 32-bit?
<marcan>
or rather maybe they're just pairs instead of groups of 4 like in the other DARTs
<bluerise>
marcan: "OpenBSD does it this way" in bwfm(4) might just be a "that's how Linux did it 2-3 years ago" lol
<bluerise>
though I've been following some changes in the last year
<marcan>
the commit that introduced it in linux was like that from the start :)
<bluerise>
huh
<bluerise>
also regarding the core disable loop: at least the diff I saw made sure that each step in a disable is done for each core. so not for (chip) disable, but for (chip); part 1; for (chip); part 2
<bluerise>
not sure if that really makes a difference though
<sven>
marcan: / Jamie[m]1: looks even different from the thunderbolt darts on the m1
<sven>
and those also support 64 sids
<marcan>
bluerise: that's the case for the full process that includes re-enabling
<marcan>
however, that part itself just calls chip disable for each core individually first
<marcan>
so if we're leaving them disabled this is the same as the old behavior there
zimsneexh has quit [Ping timeout: 480 seconds]
<sven>
I think TTBRs are at 0x1400
<sven>
er. no.
<sven>
how did i get that number :/
<Jamie[m]1>
there is something at 1400
<sven>
actually, yes. i'm just confused :D
<sven>
where did RAM start on the MAX again? 0x10_0000_0000?
<marcan>
one more zero
<Jamie[m]1>
(fyi my dump is from a pro not a max, if that makes a difference)
<kettenis>
btw, is there a single memory "bank"?
<sven>
hrm. then my guess that the pagetable is at 0x10_3555_4000 doesn't work :-(
<marcan>
kettenis: yes
<sven>
oh. wait. i'm just still confused
<marcan>
usable RAM is a chunk from the middle since there are carveouts on both ends
<marcan>
but contiguous
<kettenis>
cool, that'll help adding u-boot support
<sven>
Jamie[m]1: i think the pagetable should be at 0x103_60e1_c000 and 0x100_3555_4000
<kettenis>
played a little bit with swapping the u-boot memory map based on the model
<kettenis>
unsuccessfully so far...
<marcan>
if we must we *could* ship two different builds and have the installer pick... but then you get to join Apple in the I-don't-know-how-to-build-universal-kernels hall of shame ;)
<kettenis>
it should be possible to make it work; my code that switches things around runs before the MMU gets enabled
<kettenis>
printf works at the point where things go wrong, so I *should* be able to figure this out...
aleasto has joined #asahi-dev
<Glanzmann>
marcan: Can you please push the wifi-wip branch?
fetsorn[m] has joined #asahi-dev
<marcan>
Glanzmann: if I haven't pushed it yet it's because it's not ready
<tpw_rules>
do the iSC and 1TR partitions have to be the first and last numerically, or even on disk?
<tpw_rules>
also wow diskutil does not align anything to anything
Glanzmann has joined #asahi-dev
<Glanzmann>
tpw_rules: Alignment, yes I noticed that too when I tried to create a partion on linux with parted -a optimal and about the 1tr. I have a partition number which is higher than 1tr on my macbook air and 1tr still works (power button press and select options ...)
<marcan>
1TR is just "any recovery you boot into while asserting physical presence"
<marcan>
that used to be the same in 11.x but isn't any more
<kettenis>
marcan: do you already have a diff for m1n1 to populate the wifi instance/antenna properties?
<marcan>
not yet, but the instance just goes in the DT since it's not dynamic, and the antenna doesn't actually matter for any current platform, so I just have some dummy thing in the DT for now
<marcan>
but feel free to submit something for the latter :)
<kettenis>
my thinking was that we might as well just take the instance from the ADT
<kettenis>
just in case Apple decides to source a different module at some point for a particular model
<marcan>
I mean, by that token we might as well take everything from the ADT
<marcan>
those props are hardcoded in the template ADTs
<marcan>
the antenna SKU does come from sysconfig
<kettenis>
true
<marcan>
I think "module instance" is actually the platform tbh
<marcan>
if apple does something weird in a future platform/update we just update m1n1 anyway, which we'd probably have to either way
<kettenis>
true again
<marcan>
I suspect the reason for the island codenames is just so broadcom doesn't know anything about what machines apple is working on
<kettenis>
heh
<jannau>
sven: did you already spot the missing "apple,asc-mailbox" base compatible in t8103.dtsi?
<kettenis>
not sure we settled the discussion on that ;)
<sven>
jannau: i think i have whatever was in the asahi branch in asahi-with-new-nvme
<marcan>
kettenis: I did send out a v2 :)
<marcan>
(but asahi isn't up to date with that)
<kettenis>
ah, right
<j`ey>
v2 of the dts updates?
<kettenis>
I'm ok with either name; just don't change it again ;)
<marcan>
v2 of mailbox re-compatible
<jannau>
sven: I took the dtsi change from nvme/dev and there it's missing. asahi has "apple,asc-mailbox"
<sven>
yes, i didn't change it in nvme/dev
<jannau>
yes, I see.the mailbox compatible change is just in asahi
MajorBiscuit has joined #asahi-dev
Dcow has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<kettenis>
hmm, did something change in an incompatible way in m1n1 recently?
<kettenis>
trying to chainload a new m1n1 over serial, and it hangs at
<kettenis>
Fetching ADT (0x00058000 bytes)...
<kettenis>
and then times out
okt has quit [Write error: connection closed]
okt has joined #asahi-dev
WhyNotHugo has quit [Read error: Connection reset by peer]
coder_kalyan has quit [Read error: Connection reset by peer]
WhyNotHugo has joined #asahi-dev
coder_kalyan has joined #asahi-dev
<j`ey>
chainload defaults to --xnu now by default.. but that's unlikely to be it?
<jannau>
kettenis: no issues chainloading f2eac15 (main) over f2eac15 or 73180e2 (27th October) using uart instead of usb
<kettenis>
it's the last commit that breaks things
yuyichao_ has joined #asahi-dev
<kettenis>
the m1n1 I have is c2c6da3 from August, so I guess it is getting a bit long in the tooth
bps2 has quit [Ping timeout: 480 seconds]
yuyichao has quit [Ping timeout: 480 seconds]
aleasto has quit [Remote host closed the connection]
bps2 has joined #asahi-dev
<kettenis>
now on f2eac15 but chainloading still hangs
<j`ey>
and adding --no-sepfw fixes it?
<j`ey>
pretty sure I had tested with this last commit and old m1n1, will double check
<tpw_rules>
kettenis: is u-boot set up for persistent EFI vars yet? efibootmgr is giving me input/output error. i don't need them but it would be good to know
<kettenis>
don't think it is
<kettenis>
runtime support is almost impossible, so setting them from Linux won't work
<kettenis>
should be possible to set them from u-boot itself or from an EFI bootloader, but I haven't tested that yet
<kettenis>
and maybe u-boot needs to be told where to store those variables
MajorBiscuit has quit [Ping timeout: 480 seconds]
<kettenis>
looks like fetching the ADT over serial is the problem
<kettenis>
my serial connection is just too flaky at 1500000 :(
<j`ey>
:{ (just confirmed it's working over USB)
<kettenis>
so it is the unconditional RVBAR setting that screws things up
suricato has joined #asahi-dev
joe[_]D has joined #asahi-dev
suricato_ has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #asahi-dev
bps2 has quit [Ping timeout: 480 seconds]
bmrgz has joined #asahi-dev
tbodt_ is now known as tbodt
<bmrgz>
You can set the efi variables with efidebug in u-boot. It stores them in a file in the efi partition by default.