marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | General project discussion | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-stream #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
yuyichao_ has quit [Ping timeout: 480 seconds]
Dcow has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
Axenntio has joined #asahi
Axenntio has quit [Remote host closed the connection]
<marcan>
radnic: what hardware?
<marcan>
fwiw hotplugging doesn't work (more than the initial connection); that is expected
<aidenfoxivey>
hotplug means putting in the USB after the boot process is completed?
X-Scale has joined #asahi
X-Scale` has quit [Ping timeout: 480 seconds]
nskl has quit [Ping timeout: 480 seconds]
yuyichao_ has joined #asahi
aidenfoxivey has quit [Ping timeout: 480 seconds]
chile09[m] is now known as rolodondo9378[m]
<marcan>
hotplug means removing the USB cable and putting it in again (on either end)
<marcan>
the first connection does work
kov has quit [Quit: Coyote finally caught me]
PhilippvK has joined #asahi
phiologe has quit [Ping timeout: 480 seconds]
jabashque has joined #asahi
aidenfoxivey has joined #asahi
kov has joined #asahi
marvin24_ has joined #asahi
marvin24 has quit [Ping timeout: 480 seconds]
psykose has quit [Ping timeout: 480 seconds]
psykose has joined #asahi
<tmlind>
fyi looks like hotplug of devices works with usb-c to usb-a adapter cable kept plugged in, this sounds like some unhandled interrupt for some usb-c related pin in the phy driver maybe?
<tmlind>
this still with the old corellium hacked kernel, can't quite yet upgrade :)
<radnic>
Sorry for answering late, I have a MacBook Air 13 with 500 GB ssd.
<radnic>
Initial connection works, I see here, if I put it in after the Mac is booted. Did not try disconnecting and connecting again.
<radnic>
First attempts were with the USB and power already connected. And the failure still showed. That was when/why, I tried different cable conneciton permutations.
<tmlind>
hmm so is the macbook spi keyboard already working then? maybe i can attempt to upgrade then with some usb wlan dongle..
nskl has joined #asahi
sailorek1234 has joined #asahi
handlerug has quit [Read error: Connection reset by peer]
handlerug has joined #asahi
WhyNotHugo has quit [Read error: Connection reset by peer]
<tmlind>
jannau: sounds like dwc3 should just need to reinit the phy connection over ulpi/utmi whatever it might be after the repeater reset, i doubt dwc3 needs a reset
<tmlind>
jannau: thanks for the m1-keyboard link
<marcan>
tmlind: we already know why this happens; it's a hardware design problem in the mac that requires a complete phy reset every time things are hotplugged at the type C end
<marcan>
we already have a workaround for it
<tmlind>
i doubt that's the right fix though
<marcan>
it is what macOS does
<tmlind>
i doubt that's the right fix though
<marcan>
and further, macOS *still* has another bug where dwc3 wedges itself hard sometimes
<marcan>
and *that* needs an even bigger reset hammer to fix
<marcan>
which is what we'll do
<marcan>
yes, we looked for smaller hammers to use
<marcan>
and then that problem showed up
<marcan>
which needed an even bigger one
<marcan>
it's DesignWare, it should be presumed to be buggy and crappy
<tmlind>
probably the issue is re-establishing the communication from dwc3 to the phy after the repeater reset
<marcan>
that's *one* issue
<marcan>
dwc3 wedging itself hard is another issue
<tmlind>
to me it sounds that dwc3 can hang if the link to phy is misconfigured after repeater reset
<marcan>
the whole thing is poorly designed because the ace2 autonomously resets the phy without any input from dwc3/software
<marcan>
that means all bets are off as to what happens on the link
<tmlind>
yeah sounds buggy :)
<marcan>
it's no surprise some conditions can cause it to wedge
<marcan>
and need a hardware reset
<tmlind>
yeah probably read/write to the phy hangs dwc3
<marcan>
have you read the eUSB2 spec? it's insane :)
<marcan>
USB-IF somehow manages to make every new standard even crazier than the last
<tmlind>
i had my share of usb already 15 years ago
<marcan>
well, now we have Type C and eUSB2 to deal with
<marcan>
it's worse :p
<marcan>
(I've been doing USB for ~18 years now too)
<tmlind>
i'm still stuck dealing with crappy usb hardware too :)
<tmlind>
out of the usb hardware out there, dwc3 is quite sane actually
<marcan>
at least it's not dwc2, sure
<marcan>
but then there's this phy business in front
<tmlind>
no, not dwc2 for sure
<tmlind>
is the repeater interrupt wired somewhere to a gpio line on the soc?
<marcan>
interrupt?
<marcan>
the i2c is wired to the ace2 master bus
<marcan>
I forget if there's an irq...
<tmlind>
it should be possible to deal with the repeater and the phy with a custom phy driver
<tmlind>
as long as there's some interrupt..
<marcan>
we have a notification from the ace2 that a hotplug happened, which is how we currently know to reset the dwc3
<marcan>
in particular when transitioning from host/device mode to none mode
<tmlind>
it should be likely be handled by drivers/phy, then the phy driver notifies dwc3 in a standard way
<marcan>
there is already a standard way
<marcan>
dwc3 already gets notifications from the connector stuff about what mode the port is in
<marcan>
so it can switch roles
<marcan>
that's what we're using
<marcan>
we're just adding a quirk that changes the way dwc3 handles role switches
<marcan>
so it does the reset when going through disconnected mode
<marcan>
and yes, there will be a phy driver, but as I said resetting the phy is not enough (I'd have *loved* if it were, but we haven't found a way to bring it back to life after the big wedge without a bigger reset)
<marcan>
of course, if you think you can find one, feel absolutely free to dig around :)
<marcan>
but even macOS gets wedged by this bug right now
<marcan>
it's on the list of things we currently do better than macos :p
<tmlind>
yeah to me it sounds that also a phy driver is needed, and after the phy reset, dwc3 needs to reinit the ulpi/utmi whatever data connection to the phy
<marcan>
that's all internal anyway
<marcan>
but the problem seems to be dwc3 wedges itself in a bad way, not just a phy link issue; ask sven about it
<tmlind>
well the whole dwc3 probably hangs trying to read/write from the phy :)
<marcan>
the phy is internal
<marcan>
don't confuse the phy and the eUSB2 repeater
<marcan>
it would've been a lot saner if they'd handled the eUSB2 problem more like a phy, but instead they did some crazy stuff, typical for USB-IF :p
<tmlind>
yeah sounds hacky
<tmlind>
anyways, this all can be dealt with later too, just smells bad
<marcan>
hardware often smells bad
<marcan>
especially when USB is involved :p
<marcan>
but as I said, we tried pretty hard to do this a saner way; feel free to try :)
<tmlind>
the right person to comment on this is really felipe on the mailing lists, he might have some better ideas
<tmlind>
i'm allergic to usb nowadays :p
<sven>
fwiw, macOS does essentially the same thing
<marcan>
sven: you know more about the hard dwc3 wedging in device mode, how bad was it?
<sven>
can’t even soft reset the core anymore
<tmlind>
that's probably because some read/write to the phy already was done at that point..
<marcan>
again it's not the phy, it's eUSB2 that is dropping out :)
<marcan>
the phy does not get reset externally
<sven>
and dwc3 really doesn’t enjoy if you reset the phy while it’s not kept in reset itself
<marcan>
but the eUSB2 repeater has a bunch of weirdo state machines and even a config protocol, so it's possible that some kind of transaction wedges in a nasty way when it gets reset
<tmlind>
yeah
<tmlind>
let's see what felipe suggests, has he commented on the related patches?
<sven>
not yet
<marcan>
wasn't this all merged already anyway?
<sven>
no
<marcan>
ah, I thought it was for some reason
<marcan>
it'll be more fun when we support USB3/USB4/TB3 anyway though
<sven>
the usb pd stuff was merged
<marcan>
I get the feeling we aren't going to get away without sticking apple tunables in the DT for that one...
<sven>
yeah :/
<tmlind>
fun for years to come!
<sven>
thunderbolt itself is going to be a mess anyway
<marcan>
AIUI this is the first device in existence that does thunderbolt outside of intel controllers/firmware
<marcan>
so this is all new to the kernel
<marcan>
we have some ARM boards doing DP/USB3 over Type C which is why at least we have all the infra for connector mode switching for that
<marcan>
but we need to add TB to that mix
<marcan>
and from when I took a look at the existing code... it wasn't the best engineered to begin with :P
maor has joined #asahi
<marcan>
sven: USB3 doesn't need the ACIO m3s right?
<marcan>
I guess that's mostly just for TB?
<sven>
no
<sven>
only TB, yes
<marcan>
makes sense
<sven>
usb3 just needs a few magic register pokes and some tunables IIRC
<marcan>
yeah, I guess those m3s are probably in charge of doing all the LS channel stuff for TB
<marcan>
oh yeah, did you see I found *another* M3?
<marcan>
it's in AVD, and we need to load its firmware, and it has to come from cutting up the kext :/
<marcan>
at least it's not signed though, so if someone is bored enough it could be reverse engineered / reimplemented
<sven>
ugh
slicey has joined #asahi
<marcan>
~35kB or so, depending on the IP core version
<sven>
that’s not too bad. Still annoying though
<marcan>
yeah
<marcan>
I wonder if this is partially because that firmware is lost if the AVD is power gated; wouldn't surprise me
<marcan>
I don't see a power domain that screams AVD/MMX though
<marcan>
ah, but AVD at least does claim to power gate itself in the pstate reg
<marcan>
so that's entirely plausible
maor26 has quit [Ping timeout: 480 seconds]
<marcan>
sven: for the next pmgr submission I'm thinking of actually dumping in the entire set of pwrstate nodes (like I tested yesterday for t6000), wonder what they'll say :D
<marcan>
on the plus side I was right, zero changes in t6000 there that we need to worry about
<marcan>
I've also decided the syscon nodes are going to be strictly for this, and sized after the pstate reg blocks (so highest reg rounded up to 0x100)
<marcan>
(well, to 16k probably works better)
<marcan>
so anything else from pmgr is going to get separate nodes
<marcan>
I have a script to convert the ADT device list to pwrstate DT nodes, but it still needs manual munging because I don't fully understand/agree with how apple decides what should be powered on and off on boot (they have a bit for that, but they set it on stuff that isn't necessary like UARTs, but they also set it on stuff that absolutely is like SPMI...)
<marcan>
I should commit this, I cleaned up a bunch of the pmgr stuff yesterday
<sven>
:D
<tmlind>
heh wondering why no upstream patches from corellium.. maybe because of strange directory paths in strings corellium.macho | grep home
<marcan>
tmlind: they admitted in their BlackHat talk that the whole thing was just intended as a hypervisor validation platform
<marcan>
same reason Apple has an internal Linux port to these things
<marcan>
so it seems the whole releasing it and saying they'll upstream it was pure PR talk and they never had any intention to do that
<marcan>
(much less maintain it)
<marcan>
they've been CCed on a ton of the submissions too and never said a word
<tmlind>
yeah what a pity if they cannot really participate, oh well
<marcan>
it kind of goes against their business model so I'm not surprised
<marcan>
if they really wanted to participate they'd share whatever internal hardware documentation they have
<marcan>
but that would go directly against their business interests
<tmlind>
i heard apple uses linux internally for new hardware bring up or something like that
<marcan>
they do
<marcan>
there's one chicken bit set with a comment above it (back when apple was releasing source for this) saying it was found on linux
<marcan>
that's how we know :)
<tmlind>
again, what a waste of resources if they cannot participate
<marcan>
shrug, given the quality of their port I'm not too worried
<marcan>
given their entire business is a hypervisor you'd think they'd spend time figuring out register definitions properly...
<marcan>
but I think they're taking the approach that if it runs it's good enough
<tmlind>
usable mostly as hardware documentation, just like any other arm vendor trees..
<marcan>
might work for virtualizing iOS, but not great for linux
<marcan>
yeah, but some of it is outright wrong :-)
<tmlind>
of course :)
<marcan>
they had some GPIO_CONFIG_DONE bit that was actually GPIO_INPUT_BUFFER_ENABLE
<marcan>
:p
<marcan>
and they also had confused sysreg names for different CPU generations in their attempt at porting over the chicken bits (which was dangerously close to the original xnu asm for the same)
<marcan>
I know that approach well because I've been there; hack on it until it works, make the PoC
<marcan>
and for a virtualization product... that's kind of all you need in the end, as long as macOS runs (the m1n1 hypervisor doesn't take a very different approach there, given it's a research tool)
<marcan>
but when you're upstreaming a port... it actually matters that you understand the hardware and drive it properly
<tmlind>
right, and if the hardware is usable, it might get that kind of attention :)
<marcan>
yes :)
<marcan>
this is why I poke around registers to see what I find, I don't just do what macOS does
<marcan>
found some interesting things in the new interrupt controller, like CPU cluster priority and delivery delays/timeouts (not 100% certain on everything yet, but it's nice to know these features exist)
<tmlind>
yup, the same applies to a lot of soc documentation out there too
<marcan>
(and this is why I was saying we've tried on the USB issue, believe me :p)
<tmlind>
yeah sure
<marcan>
< tmlind> usable mostly as hardware documentation, just like any other arm vendor trees.. <- this is what got Chris mad at me, btw
<marcan>
I mentioned the old sandcastle tree was not upstreamable on a reply somewhere (it wasn't even signed off...)
<marcan>
then he got mad at me and I mentioned that in that state it would only be useful at docs
<marcan>
then he stopped talking to me and 2 days later announced they'd "ported" Linux to the M1
<tmlind>
heh ok :)
linearcannon has quit [Read error: No route to host]
<j_ey>
tmlind: that keyboard link is just the corellium spi+input patches rebased onto 5.16 (which has the pinctrl driver)
<marcan>
huh, I was wondering after someone mentioned rowhammer on twitter...
<marcan>
I think these machines might all have ECC RAM?!
<marcan>
if so, about time! (and now I don't want to use any other consumer machine)
<marcan>
(there's an ECC disable bit in AMCC, and it seems to not be set...)
<marcan>
(on neither M1 nor M1 Pro)
<tmlind>
j_ey: yeah i noticed, that's why i started wondering about the corellium patches again
<FireFox317>
marcan, what would you use the ECC ram for?
<marcan>
firefox317: for not getting random bit errors because RAM bits are too small these days
<marcan>
it is completely ridiculous that *every other storage technology* has used ECC for decades, and ECC RAM is still not standard
<marcan>
the idea that we can stick billions of bits in chunks of silicon and somehow have zero errors is completely insane
<Fruit>
ecc is standard in ddr5 I believe
<mini>
I thought that was a watered down internal thing, not the full thing you'd think of as ECC (with error reporting etc)
<jannau>
marcan: isn't that just link ecc to make (lp)ddr5 work and not storage ecc
<marcan>
(we don't have a driver for this yet of course, but it's the same reporting stuff that was barfing on T6000 when I mapped the framebuffer as cached and DISP0 realtime fetches were hitting the CPU cache)
<mini>
is macOS running it in the ECC enabled state?
<mini>
ah, you said above already. reading comprehension!
<marcan>
it seems m1n1 already is, if I'm interpreting this right
<marcan>
the T810x driver has a function to enable ECC, but the T6000 one doesn't; I think these days iBoot would enable it during mem init
<mini>
my comment about 'watered down internal thing' was re ddr5 as a whole, not the m1 specifically
<mini>
but if m1 & especially m1 pro/max have active ECC that's a really nice bonus on an already pretty damn impressive platform
aleasto has joined #asahi
<marcan>
I wonder how we could test this...
<Namidairo>
try to rowhammer them /s
<mini>
it makes sense though - if they're doing a multi-die M1 Max for pro machines, people will want ECC support. and once you've had to build it for that you might as well just use it
<JTL>
> 09:09 <@marcan> I think these machines might all have ECC RAM?!
<JTL>
wait what?
<JTL>
which machines exactly? :P
<JTL>
as for testing if ECC is working, since it's soldered you can't passthrough a shim that shorts data pins to ground like some people did with DDR4, so some form of heat/radiation to try and induce errors?
<JTL>
heh
<mini>
none of those pins are exposed, are they? surely they're all buried in apple's packaging because of how the RAM is done?
<JTL>
mini: hence my thinking
<marcan>
JTL: all of them
<JTL>
*all* M1 machines?
<marcan>
yes
<JTL>
wow
<marcan>
so on M1/t8103, there's an mcc_ecc=1 bootarg, but indeed the operation it does is a no-op: the register already has that value
<JTL>
interesting
<ar>
actual ram ecc, not just cache ecc?
<JTL>
^
<mini>
you'd really think apple would be only too happy to stick it on their spec sheets
<JTL>
ditto
<JTL>
When M1 launched I wonder if the (apparent) lack of ECC was just another waste opportunity
<marcan>
ah, might be cache ECC
<marcan>
bank/way/entry would suggest cache
<marcan>
hm
* JTL
grimace
<JTL>
yeah...
<marcan>
the thing is I'm not even sure how you'd do ECC on a system with 16-bit channels
<marcan>
that's a bit of a problem
<marcan>
DDR5 has 32-bit channels that become 40-bit channels with ECC (2x the ECC overhead of prior standards)
<marcan>
but LPDDR with 16-bit channels... what are you going to do, make them 24 bits?
<marcan>
also it seems we might not be using the cache at all in m1n1/linux yet? there is explicit enable code...
<marcan>
(the AMCC cache, not the CPU cache)
chamomile has joined #asahi
slicey has quit [Quit: cya]
bgb has joined #asahi
<marcan>
also AMCC got interesting in t6000... t8103 had 1 AMCC with 4 planes and 8 channels; t6000 seems to have 4 AMCCs with 4 planes and ? channels, and t6001 has 8 AMCCs.
<marcan>
(and the m1n1 code that checks the TZ regs is not correct on t6000 and works by accident, heh)
<bgb>
marcan: what is TZ regs? TrustZone?
<marcan>
yes, the only TrustZone feature Apple still use on paper
<marcan>
it's just the carveouts
<bgb>
ah, souds like making the device "secure" so that normal world cannot access
<marcan>
it just does that for some RAM regions
<marcan>
mostly NVMe and SEP related
<marcan>
there is no actual EL3/trustzone on these chips
<marcan>
it's used for coprocessor carveouts instead
<marcan>
we need to unmap them because otherwise the CPU might speculatively read from them, and cause a SError
<marcan>
this isn't necessary in a "normal" OS which only maps things on demand, but in m1n1 we want to map all physical RAM by defaults to simplify experiments
<marcan>
-s
<bgb>
got it, so the "S" bit in MMU page table attribute has no meaning?
<bgb>
marcan: btw, I met almost the same situation as radnic. I reset the device with "Arduino based PD". does this also relate to the "hotplug" issue?
<marcan>
the hpm0 thing?
<Namidairo>
so I take it they won't be running any TF-A then
<marcan>
no
<marcan>
which is also why we need to invent a new wheel so m1n1 can provide PSCI from the same EL2 as the kernel
<marcan>
since we'll need something like that for sleep mode
<marcan>
(I talked about this in -dev yesterday)
<bgb>
marcan: yeah. the hpm0 fail
<sven>
hpm0 init fail is different from the hotplug issue fwiw
<sven>
i kinda hoped that init fail was fixed with that i2c fix
<sven>
I don’t think we’ll ever have hotplug support inside m1n1. getting that to work would be quite annoying without a big benefit
<_jannau_>
I've seen occasionally i2c warnings/errors on the m1 max without noticeable broken functionality
<_jannau_>
could have been chainloading + work on usb init related
<sven>
without the hpm init the ports can’t act as a power source
<sven>
so essentially usb host mode won’t work
<marcan>
problem is if I can't repro I can't fix it :/
<bgb>
sven: so, CDC ACM function should work? but, sometimes ttyACMx not showed on host
<sven>
yes, CDC ACM works even without the hpm init
<sven>
and same here: I’ve never been able to reproduce any of this so I can’t really fix it either
Dcow has joined #asahi
<_jannau_>
don't we skip usb init if hpm init fails?
<sven>
hrm, could be
<_jannau_>
no, we don't
<jannau>
I can't reproduce either on the mac mini in ~25 chainload, 15 reboots both through vdmtool and power button
<maz>
bgb_: something like "perf state -e PMUNAME/event=0xXX/ELs SOMEPROGRAM", where PMUNAME is one of apple_{ice,fire}storm_pmu, XX is the event number you want, ELs is one of {u,k,uk}, and SOMEPROGRAM the stuff you want to profile. you can count multiple events on multiple PMUs (comma separated).
<maz>
perf stat*
<bgb_>
maz: for perf executable, I just cross compile under linux/tools/perf, and pack it into ramdisk, right?
<marcan>
pushed some MCC magic (in a new mcc.c) to handle the t8103/t6000 MCCs properly and ostensibly do the magic cache enable dance
<marcan>
maybe things will be magically even faster now :)
robinp[m] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<kettenis>
marcan: with all the pmgr nodes added, Linux will actually turn off some of the power domains?
<marcan>
yes, everything not used
<marcan>
(which is why adding them is a good idea before the drivers are ready)
<kettenis>
unless they're marked as always-on i suppose
<marcan>
yes
<maz>
bgb_: that's up to you. for me, this is an 'apt install' away (and I stopped cross-compiling many years ago...).
<maz>
(or rather, I cross-compile to x86/ppc/mips when I really need it)
<kettenis>
I only cross-compile when bringing up a new architecture ;)
<bgb_>
maz: so, you setup ubuntu distro on Mac?
<kettenis>
anyway, marcan, it would be good if a new pmgr patch set happens soon so I can push my u-boot driver upstream
<maz>
bgb_: Debian.
<marcan>
kettenis: yeah, working on that, just got sidetracked by MCC today
<mort_>
the high-level software changes to get gnome to work around the notch feels interesting
<mort_>
*hypothetical high-level software changes
<mort_>
if all goes well, I'm getting a 14" pro tomorrow and will almost certainly play around with avahi
<mort_>
asahi*
<bgb_>
maz: I don't know how to setup, any instructions or links?
<arnd_>
marcan: regarding ECC, it appears that LPDDR4 and LPDDR5 chips advertised with "integrated ECC" do this by having all the error correction logic in the package and no additional data lines to the host, so they can automatically correct any single-bit errors but would not raise an exception to the host for a double-bit error. I can see announcements of this from LPDDR4 manufacturers but there is no indication that these are being sold (any
<arnd_>
more).
<arnd_>
LPDDR5 also adds a "link ECC" option, which would comput a checksum only for data that gets sent between CPU and RAM and checked on the other end.
robinp[m] has joined #asahi
<arnd_>
I think you can have any combination of the two on LPDDR5, but only the "link ECC" would lead to the CPU noticing a problem
<maz>
bgb_: I really don't think you want to adopt my installation method... I installed a complete Debian VM on a USB device, plugged it onto the mini. The kernel gets loaded over USB as a m1n1 payload.
<mps>
and local shell script, probably could adapt it
<_jannau_>
I wouldn't spend much on this as this would be only a temporay solution. the expected boot path is m1n1+u-boot payload with efi provided by u-boot
<mps>
you mean m1n1 and u-boot combined in one image?
<sven>
yeah
<_jannau_>
yes, that works already since a long time via m1n1 payload mode but nobody has spent time so far preparing an image
<mps>
aha, there is u-boot fork or patches for M1?
robinp[m] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<sven>
yes, kettenis has a u-boot fork and has been working on upstreaming M1 support
<mps>
last time I looked u-boot git log didn't seen it
<mort_>
you'd still need m1n1, right? Or is the plan to eventually make it possible for u-boot to be booted directly by whatever boot firmware macs have
robinp[m] has joined #asahi
<mps>
aiui m1n1 is (and will) be needed with u-boot
<mort_>
what's the advantage to u-boot then? I get something like grub or gummiboot because they can provide a boot select GUI but afaik uboot doesn't do that
<mini>
u-boot can provide an EFI environment. makes it easier to boot arbitrary linux
<mort_>
ah
<j_ey>
mort_: u-boot will probably load grub if thats what the distro normally does
marvin24 has joined #asahi
bgb_ has joined #asahi
Dcow has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
<mort_>
by the way, what's the state of graphics currently? I kept up with the GPU reverse engineering posts but I haven't seen any in a while
marvin24_ has quit [Ping timeout: 480 seconds]
bgb has quit [Ping timeout: 480 seconds]
Dcow has joined #asahi
as400 has joined #asahi
<as400>
Hey everyone. I've seen discussion on u-boot.
<as400>
u-boot can provide boot menu as long as it is able to initialize graphics
<as400>
or display
<as400>
So actually no need for loading grub after booting m1n1+u-boot payload
<sven>
sure, that's up to the individual linux distributions. we'll promise them m1n1+u-boot and they can figure out the rest :-)
<as400>
oh - good plan I guess
<mort_>
I'm not completely in love with the thought of mac bootloader -> m1n1 -> uboot -> emulated efi environment -> grub -> linux
<maz>
some of us actually need grub.
<as400>
maz: like what exactly for ? Just curious.
<maz>
as400: imagine you have a zoo of about 40 machine, not two of them the same. you deploy a test kernel on that many boxes. EFI+grub is the only way to do that sanely.
<as400>
Well, in case of u-boot + config file, you just add few lines and you're ready to go.
<maz>
as400: you are missing the point. I don't want to add anything. all I'm doing is 'dpkg -i mykernel.deb', and get the standard distro tools to do their job.
<as400>
maz: ok - indeed I didn't understand you correctly
myon98 has quit [Quit: Bouncer maintainance...]
<as400>
Anyway - is initializing display by u-boot possible already ?
<sven>
it can reuse the framebuffer initialized by iboot
<sven>
(i think. my m1 isn't connected to any screen)
<as400>
that's great
<as400>
same with keyboard ?
sailorek1234 has quit []
sailorek1234 has joined #asahi
sailorek1234 has quit []
robinp[m] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Dcow has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
myon98 has joined #asahi
<mps>
u-boot with numbered menu is quite enough for me
<as400>
I have a question to MBP 14 8-core M1 Pro owners - what is the real time on battery based on your experiences ? Asking because I'm really tempted to buy this baby.
<kettenis>
u-boot + usb keyboard already works
<kettenis>
u-boot + laptop keyboard will probably work before the end of the year
<as400>
kettenis: thanks - great news.
<kettenis>
(the lack of laptop keyboard support annoys me enough for that to happen)
<mps>
kettenis: could you give url of your u-boot fork
<kettenis>
but basic support with working usb is already upstream and should be part of the 2022.01 release
<mps>
and current u-boot git?
<kettenis>
yes
<mps>
good
<kettenis>
device trees are still a bit of a mess
<mps>
I'm quite irritated with macos already (using it about one week) and I want to switch it to linux
bgb has joined #asahi
<mps>
though I'm short on time these days (as usual on every last two months of year)
<kettenis>
note that at this point there is no m1 pro/max support in u-boot
<sven>
what's missing to clean up that device tree mess btw.? pmgr and nvme? or is there anything else left?
<kettenis>
a few more bindings for things like spmi, spi (including the keyboard)
bgb_ has quit [Ping timeout: 480 seconds]
<kettenis>
and proper device trees for the different models (which janneau is working on)
<_jannau_>
usb-reset to add dwc3 + i2c + cd321x officially
maor has joined #asahi
<sven>
kettenis: so i think i'm in favor of having a separate SART node at this point because of the differences between M1 and Pro/Max
<kettenis>
that was my thinking as well
maor26 has quit [Ping timeout: 480 seconds]
Dcow has joined #asahi
yuyichao_ has quit [Ping timeout: 480 seconds]
as400 has left #asahi [#asahi]
<marcan>
fwiw I already have proper devicetrees for all the t6k models in my branch (at least for upstream stuff, plus the things I'm merging in)
<marcan>
sven: yeah, I agree
<marcan>
mort_: each boot stage does something discretely useful. there is nothing wrong with having things split up into stages.
<marcan>
m1n1 does the init that iBoot doesn't and bridges to the devicetree world; u-boot handles I/O and provides EFI services; grub is provided by distros and is what they know how to integrate and manage.
<marcan>
< sven> (i think. my m1 isn't connected to any screen) <- you should fix that, it makes boot a good 10 seconds slower or so
<marcan>
(dunno why, retries I guess)
<sven>
I have a dumb dongle that pretends to be a hdmi screen connected for that
<marcan>
ah, then it *is* connected to a "screen" :p
<sven>
fair :D
<marcan>
also I still find it hilarious that without a screen it sets up a frambuffer with the portrait screen dimensions of the iPhone 4 or something
<sven>
lol
<akemin_dayo>
wait, it does? that is amazing wwww
<marcan>
width: 640
<marcan>
height: 1136
<marcan>
iPhone 5, apparently
<akemin_dayo>
oh, that's the uh, iphone 5 resolution
<akemin_dayo>
the 16:9 dAR
<kettenis>
something upsets u-boot though if no screen is connected
<marcan>
could be the depth?
<marcan>
it's 32bpp apparently, as opposed to the usual 30
<marcan>
(which actually means 24)
<kettenis>
shouldn't matter, but I'll keep that in mind when I get around to debugging this issue
___nick___ has joined #asahi
___nick___ has quit []
___nick___ has joined #asahi
maor has quit [Quit: Leaving]
gabriele_ has joined #asahi
as400 has joined #asahi
<as400>
Guys, where is iboot located on macs ? SPI flash ?