al3xtjames has quit [Quit: Ping timeout (120 seconds)]
al3xtjames has joined #asahi-dev
axboe_ has joined #asahi-dev
axboe_ is now known as axboe
off^ has joined #asahi-dev
chadmed has quit [Ping timeout: 480 seconds]
PhilippvK has joined #asahi-dev
phiologe has quit [Ping timeout: 480 seconds]
kov has quit [Quit: Coyote finally caught me]
kov has joined #asahi-dev
axboe has quit [Quit: Lost terminal]
axboe has joined #asahi-dev
hays has quit [Remote host closed the connection]
chadmed has joined #asahi-dev
<marcan>
kettenis: u-boot currently maps all physical RAM, right?
<marcan>
that's not good :(
<marcan>
it needs to map only valid RAM
<marcan>
otherwise CPU speculation can trigger SErrors, I just got one such failure under the HV
<marcan>
hm, wait, I do see it trying to adjust the memmap?
<marcan>
er... translation is not yet enabled, how did this happen?
<marcan>
maybe the way I map things in the HV upgrades untranslated to allow speculation?
<marcan>
sigh, okay, the magic ARM "don't speculate in untranslated mode" stuff doesn't apply with EL2 translation enabled I guess
<marcan>
kettenis: pushed some misc video things to u-boot:releng/misc
<marcan>
and pushed a bunch of m1n1 changes to add a RELEASE=1 build mode, which disables the text console by default unless a fallback to proxy occurs, or unless verbose boot mode is set (nvram boot-args=-v and disable nvram restrictions in bputil)
<marcan>
if verbose mode *is* set then it also adds a 5-second proxy attempt timeout before launching payloads; you need to enumerate USB *and* open the device (either is fine) to break out of the timeout
<marcan>
maz: I think that should cover your use case?
<as400[m]>
marcan: I'm also getting u-boot memory errors from time to time on mbp 14.
<marcan>
as400[m]: on the hypervisor?
<as400[m]>
No, bare metal.
<as400[m]>
marcan: it seems like nobody else getting them. So they might be specific to j314s.
<marcan>
I got one on j314s, but it was under the HV and I think explainable by what I just fixed in m1n1
willemml has joined #asahi-dev
<as400[m]>
marcan: for me it seems like errors went away when I changed from extlinux booting to systemd boot. Last 10, or so, boots with systemd were ok. Will report if this happens again.
the_lanetly_052 has joined #asahi-dev
<j`ey>
marcan: u-boot stream? ^_^
<marcan>
not today, probably tomorrow, though there isn't that much to do in u-boot... so probably mostly like installer/releng
<j`ey>
👍
<kettenis>
marcan: no u-boot only maps available RAM
<marcan>
yeah, I saw that
<marcan>
it was a HV problem
<marcan>
apparently there's no way for a guest to invoke the magic speculation restriction rules that would normally happen for bare metal with no translation
<marcan>
so now the HV explicitly unmaps the TZ carveouts for stage 2 as it already does for stage 1 for the same reason
<mps>
I'm keeping u-boot patches for terminus fonts, took video patches from u-boot mailing list and added terminus 12x24
<marcan>
ah, I might want that, the font is tiny :)
<marcan>
though ideally it would select at runtime depending on display density... which isn't specified in the DT right now
<marcan>
j`ey: 16:41:31 <@marcan> [...] (nvram boot-args=-v and disable nvram restrictions in bputil)
<sven>
that variable actually means something like "display enabled" which is true if "verbose boot is disabled"
<marcan>
you can also just pass -v to chainload
<marcan>
it does the right thing
<marcan>
(or '' to disable it if it was enabled already)
<j`ey>
ohh I assumed that was going to need some strstr(cmdline, "-v") or whatever!
<marcan>
iBoot does that
<j`ey>
cool, got it
the_lanetly_052 has quit [Ping timeout: 480 seconds]
<kettenis>
we should probably bug apritzel about that font diff
<kettenis>
won't make 2022.04, but maybe it can be ready for 2022.07
<kettenis>
it makes sense to do some customization in what we ship with the Asahi installer
<kettenis>
although CONFIG_NO_FB_CLEAR and CONFIG_SYS_WHITE_ON_BLACK are probably candidates for upstreaming anyway
<maz>
marcan: the timeout stuff looks good to me.
<maz>
marcan: I miss some of the context, but a guest can always restrict speculation on some memory range by mapping it as device, provided thatt the hypervisor doesn't set HCR_EL2.FWB.
bluerise has quit [Ping timeout: 480 seconds]
<mps>
kettenis: iirc sjg1 had some some comments on apritzel's patches, and I didn't had time to check last 3 in series
<mps>
but I'm using first five of his patches on M1 u-boot and also on two different chromebooks, works fine on all three
coder_kalyan has joined #asahi-dev
gpanders_ has quit [Read error: Connection reset by peer]
coder_kalyan_ has quit [Read error: Connection reset by peer]
gpanders_ has joined #asahi-dev
willemml has quit [Quit: willemml]
MajorBiscuit has joined #asahi-dev
<marcan>
maz: but can't get the magic restricted speculation that you get with translation disabled entirely
<marcan>
with stage 1 translation disabled you get whatever stage 2 says instead
thevar1able has joined #asahi-dev
<marcan>
kettenis: yeah, I'm not too worried about carrying a few cosmetic patches here and there as long as they aren't hard to rebase
<maz>
marcan: MMU off at S1 gives you device memory, which is not speculated. But that relies on S2 not using FWB.
<kettenis>
marcan: is that margin diff to work around the rounded corners at the top of the display on the new laptops?
<_jannau_>
yes, the U from U-boot in the top left corner is in the rounded corner on the macbook pro 14"
<marcan>
maz: that's not my reading of the ARM nor what I see in practice
<marcan>
kettenis: yes
bluerise has joined #asahi-dev
<marcan>
but also a good idea for HDMI overscan on the Mini, which is unpredictable
<marcan>
e.g. if someone hooks it up to a TV
<kettenis>
shouldn't we adjust the start of the framebuffer on the laptops to avoid the top with the rounded corners and the notch though?
<marcan>
that's another way, yes
<marcan>
but then it's device-specific
<marcan>
though I guess we could outright do it for the whole FB in m1n1, including for linux? hm
<kettenis>
yes, that was what I was thinking
<marcan>
might make sense
<marcan>
I'll give it a try
grgy has left #asahi-dev [WeeChat 3.4]
<maz>
marcan: with S1 disabled, the strongest memory attribute wins. if that's not what you are seeing, then that's a violation of the architecture. that's c;early described in the VMSA spec.
<maz>
actually, S1 beng enabled or not doesn't matter. the combination of the two levels of translations should apply irrespective of that. only FWB is allows to change that.
<alyssa>
M1? violating the spec? never :-p
thevar1able has quit [Ping timeout: 480 seconds]
<marcan>
maz: D5.2.9 The effects of disabling a stage of address translation
<marcan>
For all other accesses, when stage 1 address translation is disabled, the assigned attributes depend
<marcan>
on whether the access is a data access or an instruction access, as follows:
<marcan>
Instruction access
<marcan>
The stage 1 translation assigns the Normal memory attribute, with the cacheability and
<marcan>
shareability attributes determined by the value of the SCTLR_ELx.I bit for the
<marcan>
translation regime
<marcan>
the only reason that doesn't explode all over the place is the later subsection "Behavior of instruction fetches when all associated stages of translation are disabled
<marcan>
which limits speculation to allow software to guarantee the CPU does not speculate into memory it shouldn't, but *only* if *all* stages of translation are disabled
<marcan>
so if you have S2 and no S1, and S2 says it's normal memory, you end up with normal memory, and things explode randomly
<marcan>
basically, tl;dr it's illegal to map read-sensitive or read-illegal memory as Normal memory into the guest if the guest ever plans to run with translation disabled, because there is no way for it to stop the CPU from speculating into it otherwise
yuyichao has quit [Ping timeout: 480 seconds]
yuyichao has joined #asahi-dev
klaus has joined #asahi-dev
klaus has quit [Quit: Konversation terminated!]
<marcan>
kettenis: pushed notch hiding to m1n1, removed the margin stuff
<marcan>
good point on that one, this makes more sense
<marcan>
I do it in kboot so it only affects the m1n1 -> u-boot (or linux) boundary
<marcan>
m1n1-m1n1 keeps the full fb, same with xnu/hv/etc
<marcan>
the code is a heuristic to avoid per-platform code (for now); we do have "is there a notch" in the ADT. it checks that, then rounds down the height to an integer 16:N aspect
<marcan>
(since we know these screens are 16:10 notchless, and one would hope Apple will stick to even dimensions plus notch)
<_jannau_>
which kicks the notch awareness can of worms down to dcp. seems sensible
<kettenis>
marcan: the margin might still make sense for overscan on hdmi tv's, but with a larger font that issue largely disappears as well I guess
<VinDuv>
So if m1n1 displays something at the top of the screen, it will stay visible indefinitely in the booted OS?
<marcan>
fwiw my margin patch was broken, it faults on scroll
<marcan>
VinDuv: m1n1 clears the screen
<marcan>
(when loading something else)
<marcan>
(except the logo)
<VinDuv>
ah ok
WhyNotHugo has quit [Remote host closed the connection]
coder_kalyan has quit [Remote host closed the connection]
gpanders_ has quit [Remote host closed the connection]
coder_kalyan has joined #asahi-dev
WhyNotHugo has joined #asahi-dev
gpanders_ has joined #asahi-dev
<Dcow[m]>
would be great to have option to use notch area (left and right side from the notch) as separate screen
<marcan>
unlikely to be practical I think, at least at the DRM level
<marcan>
it'd have to be something the compositor does
<marcan>
we don't have enough layers to fake that
<_jannau_>
multiple simple-framebuffers might work but could cause problems with the dcp driver
<marcan>
it doesn't make any sense to do it for simplefb and not dcp
<marcan>
and we can't really do it for dcp
willemml has joined #asahi-dev
coder_kalyan has quit [Remote host closed the connection]
gpanders_ has quit [Remote host closed the connection]
WhyNotHugo has quit [Remote host closed the connection]
coder_kalyan has joined #asahi-dev
WhyNotHugo has joined #asahi-dev
gpanders_ has joined #asahi-dev
willemml has quit [Quit: willemml]
phiologe has joined #asahi-dev
willemml has joined #asahi-dev
PhilippvK has quit [Ping timeout: 480 seconds]
PhilippvK has joined #asahi-dev
willemml has quit [Read error: Connection reset by peer]
phiologe has quit [Ping timeout: 480 seconds]
<sven>
hm, looks like usb 3 actually won’t be very painful. Still needs some tunables though afaict
<sven>
only annoying part is that we probably need to know the orientation of the plug which we can get from the tipd chip - but that subsystem is ofc separate from the usb-role-switch stuff that triggers the phy_set_mode in dwc3
<sven>
but as a first hack it should be enough to call typec_set_orientation before the usb role switch stuff in the tipd driver :D
___nick___ has joined #asahi-dev
___nick___ has quit []
___nick___ has joined #asahi-dev
roxfan2 is now known as roxfan
the_lanetly_052 has joined #asahi-dev
<alyssa>
ooh
MajorBiscuit has quit [Quit: WeeChat 3.4]
the_lanetly_052 has quit [Ping timeout: 480 seconds]
mini has quit [Quit: ZNC closing...]
mini has joined #asahi-dev
CME has joined #asahi-dev
___nick___ has quit [Ping timeout: 480 seconds]
sirn- has joined #asahi-dev
sirn has quit [singleton.oftc.net coherence.oftc.net]
sirn- is now known as sirn
hays has joined #asahi-dev
manawyrm has quit [Quit: Read error: 2.99792458 x 10^8 meters/second (Excessive speed of light)]