marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | Not ready for end users / self contained install yet. Soon. | 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
sheepgoose has quit [Remote host closed the connection]
chadmed has quit [Quit: Konversation terminated!]
sheepgoose has joined #asahi
sheepgoose_ has joined #asahi
amarioguy has quit [Remote host closed the connection]
<j`ey>
Glanzmann: unlucky I didn't find those docs!
eroux has joined #asahi
pulsar[m] has joined #asahi
<kov>
Glanzmann, \o I was trying to use the debian live system you build to play with setting up luks but apparently dm-crypt et al are missing from the kernel, could I trouble you to add that? ;D
eroux has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Glanzmann>
Thank you, I'll have a look at it and try to script it, so that in future, we don't have to do that manually.
<Glanzmann>
j`ey: For me the mini works undermacos with an eizo monitor using a usb-c cable that was shipped with the monitor.
<j`ey>
mine is some samsung monitor, didn't work. I could maybe try again with 12.x to see if anything was fixed
linearcannon has quit [Remote host closed the connection]
<Glanzmann>
j`ey: A friend of mine, who has the same monitor, also uses the usb-c cable to that monitor under 11.x and it works.
<j`ey>
doesnt work with 12.x either
<j`ey>
I have a keyboard/mouse attached to the display, those work, but the display itself doesnt
<Glanzmann>
I see.
<j`ey>
it might not work under linux then either, which would be a shame
<Glanzmann>
povik: Nice, if you have a tree for the speakers on the air, ping me, I'm eager to try it. :-)
Shiz has quit [Ping timeout: 480 seconds]
povik has quit [Remote host closed the connection]
povik has joined #asahi
linearcannon has joined #asahi
the_lanetly_052__ has joined #asahi
Shiz has joined #asahi
the_lanetly_052 has quit [Ping timeout: 480 seconds]
<kettenis>
mps: some arm64 linux kernel features are only offered by the EFISTUB
<kettenis>
the most notable feature right now is better address space randomization if the EFI random number generator protocol is supported
<kettenis>
(which isn't the case for U-Boot yet for these Apple systems)
eroux has joined #asahi
<maz>
there is probably going to be more, such as entering the kernel with the MMU on, which speeds things up.
<kettenis>
and the proposed EFI PSCI conduit
<maz>
yup
<maz>
not using EFI on arm64 is a bit backward, tbh.
<kettenis>
ultimately that may mean no suspend/resume support if you don't boot using EFISTUB
<j`ey>
(or only s2idle)
<kettenis>
deep sleep will probably already require PSCI
<kettenis>
so even s2idle will be better with EFI
thesophiaxu[m] is now known as Orionian
<kettenis>
note that you don't have to use grub; U-Boot can in principle load your kernel and boot it using the EFISTUB
<kettenis>
but I'm not sure that functionality is exposed through extlinux.conf
<maz>
or use the DEI2 shell if you are really perverse! :D
<maz>
EDK2*
akemin_dayo has joined #asahi
<mps>
aha, understand
<mps>
but till now I used arm64 boxes without EFI, and all worked fine
<mps>
kettenis: maz: thanks for explanation
<Orionian>
Hi everyone! Just got Debian up and running, but I'm wondering what kinds of work would be needed for audio to work?
<Dcow[m]1>
the povik's work
<Dcow[m]1>
what model?)
<j`ey>
kettenis: any idea about this? => load nvme 0:4 ${kernel_addr_r} /Image ** Reading file would overwrite reserved memory ** ?
<Orionian>
Dcow: It's an M1 macbook air
<_jannau_>
j`ey: how large is Image?
<j`ey>
_jannau_: 15M
<j`ey>
14735368 Image
<kettenis>
j`ey: I've seen that at some point, but not recently
<kettenis>
the dynamic assignment of the address variables in U-Boot might not be 100% fool-proof
ciggi_ has joined #asahi
<_jannau_>
j`ey: what value is in ${kernel_addr_r}?
<j`ey>
814600000 0x308dcf40
<j`ey>
(unless u-boot is alreadt in hex and I just converted it again lol)
<kettenis>
I think you did ;)
ciggi has quit [Ping timeout: 480 seconds]
<j`ey>
where's the 0x! :P
<_jannau_>
u-boot is hex, that makes more sense
<kettenis>
except that some variables have an explicit 0x and others don't ;)
<j`ey>
_jannau_: is that value reasonable?
<kettenis>
if this is an t8103 system, yes
<j`ey>
it is
<Dcow[m]1>
thesophiaxu: as far I know, it's already supported
<kettenis>
j'ey: is this reproducable?
<j`ey>
kettenis: yes, I get it every time
eroux has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<j`ey>
wait.. I may have done something very silly
<j`ey>
yes I did, ignore me, sorry
<kettenis>
still curious what you did ;)
<j`ey>
# CONFIG_EFI is not set
<j`ey>
the usual :P
<Orionian>
Dcow: it says unsupported on the wiki page, don't know if it's outdated though, should I just compile the kernel from the asahi-linux branch?
<j`ey>
Orionian: the audio jack should work
<Dcow[m]1>
I'am not sure. If it's supported - should be already in asahi.
<Dcow[m]1>
it's need additional configure in alsamixer
<Dcow[m]1>
there are peaple who has m1 air
<Orionian>
Ah I mean the speakers
<Dcow[m]1>
but maybe it's has only audio jack support
<Orionian>
I see, thanks!
<Glanzmann>
Orionian: audio jack works, speakers code is not yet available, but povik had it running 2 weeks ago on my wifes notebook. :-)
<Glanzmann>
So probably soon.
<povik>
Orionian: air has jack support in the asahi branch, and untested speaker support in my wip branch
<povik>
the wip branch is what Glanzmann refers to :)
<Glanzmann>
povik: If you have an untested branch, I need to test it.
<mps>
Glanzmann: I fried speakers on my one chromebook, so this time will 'let' someone to this experience :)
<povik>
should be okay as long as you first try with speakers attenuated, then you turn them up later
<mps>
povik: does it works on j293
<povik>
the alsamixer knob controls the target chip itself, so it will be attenuated even if the samples get messed up on their way there
<povik>
mps: which one is that? the t8xx mbp?
<mps>
povik: yes, mbp
<povik>
that also lies untested in my wip branch, let things settle a bit then i will point you to a branch
<mps>
povik: where is the branch
<mps>
you fork or?
<mps>
your*
<povik>
it's in my fork on github but i discourage you from taking it as is right now
<mps>
povik: ok, I'm not in hurry, when you think it is ready to test tell us
<povik>
ok
Gues__________________________ has joined #asahi
amw has quit [Ping timeout: 480 seconds]
<j`ey>
neat: efi: EFI v2.90 by Das U-Boot
dlssscr^ has quit [Remote host closed the connection]
<mps>
j`ey: nice
<mps>
with boot.scr?
<j`ey>
nah, not yet, just normal u-boot
<j`ey>
but now I'm getting the '** Reading file would overwrite reserved memory **' again :|
<mps>
build compressed kernel, maybe it will help
<j`ey>
it still has to uncompress it to that same location I believe
<mps>
well, I'm not sure
<j`ey>
ive booted twice now, out of about 10 times
<j`ey>
there seems to be a reserved region at 0x815420000 size: 0xc4000
<j`ey>
and it's trying to load at 0x814600000 size 0xe2ea00, which does overlap
<j`ey>
kettenis: can you remind me how big the openbsd kernel is?
<maz>
on my VM, about 14M.
<j`ey>
ok, so similar size to my kernel
<maz>
but obsd has a loader, similar to grub
<j`ey>
ah right
<maz>
you're trying to load the kernel directly, which isn't the same thing.
<mps>
j`ey: I don't have problem with extlinux, kernel size is 16M
<j`ey>
I guess no-one tried loading it directly
MajorBiscuit has joined #asahi
<kettenis>
the code jannau added reserves 128M - 2M for the kernel, su there should be plenty of space
<j`ey>
maybe there
<j`ey>
's something in the background that reserves based on those vars, because that commit just sets the variables
<kettenis>
what I fear is that somehow that region ends up overlapping another region
<kettenis>
or it overlaps the device tree
<kettenis>
do you have to use kernel_addr_r?
<kettenis>
or can you use loadaddr
<j`ey>
kernel_addr_r is just what the default EFI loader uses
<kettenis>
no the efi loader uses $loadaddr by default
<jannau>
j`ey: I don't think ARMV8_SPIN_TABLE will do anything on apple silicon but should not be enabled
<jannau>
you can check with `fdt addr ${fdtcontroladdr}; fdt print /memreserve`
<j`ey>
jannau: thanks will try later, didnt work out where it's coming from yet (and taking a break now)
<j`ey>
and yeah ARMV8_SPIN_TABLE is off in the config anyway
eroux has joined #asahi
Gues__________________________ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
joske has joined #asahi
<Glanzmann>
joske: Do you two audio devices for jack and speakers or does it detect if a jack is plugged?
<Glanzmann>
have*
<joske>
Glanzmann: ah didn't check that yet
<joske>
it only shows 1 output in the gui
<joske>
that doesn't seem to work yet
<joske>
when I plug in a headset, audio still comes from speakers
<joske>
anyway, great progress! :-D
<Glanzmann>
:-)
<Glanzmann>
I see. Thanks for trying
Glanzmann has quit [Quit: leaving]
yuyichao has quit [Ping timeout: 480 seconds]
the_lanetly_052__ has quit [Ping timeout: 480 seconds]
yuyichao has joined #asahi
joske has quit [Quit: Leaving]
joske has joined #asahi
the_lanetly_052__ has joined #asahi
joske has quit [Ping timeout: 480 seconds]
joske has joined #asahi
the_lanetly_052__ has quit [Ping timeout: 480 seconds]
<j`ey>
jannau: hmm fdt print /memreserve libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
<ar>
/27
<jannau>
that was mostly to check if ARMV8_SPIN_TABLE does something
<j`ey>
it seems that m1n1 is doing it, I missed it before kboot_prepare_dt
eroux has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
gladiac has quit [Quit: k thx bye]
Glanzmann has joined #asahi
<jannau>
I missed mem_rsv, I tought we exclude that too by increasing the start of ram
<j`ey>
so I think that means the dynamic layout stuff needs to take the reserved nodes into account or?
<jannau>
yes
<kettenis>
but we don't have any reserved-memory nodes, at least not yet
<j`ey>
it's the /memreserve/ stuff
<kettenis>
ah, but if thise cover part of normal memory, those should be covered by reserved-memory as well
<kettenis>
at least that is my understanding
<kettenis>
ah, maybe not
<j`ey>
the problem is that setting the kernel_addr_r dynamically like it is, is it could end overlapping the reserved DT or m1n1 code (from kboot_prepare_dt
<j`ey>
)
<kettenis>
yes, and m1n1 needs to mark those as reserved somehow
<kettenis>
so yes, it seems that we need a bit more smarts in the code that sets up the address variables
<kettenis>
keeping all those addresses at the top would probably help
<kettenis>
u-boot totally lacks the infrastructure to do this in a sensible way
<jannau>
I agree, it's only at the bottom because some linux aarch64 documentation mentions that ancient linux versions can't use memory below the kernel
<kettenis>
so m1n1 has two reservations
<kettenis>
the first is for the FDT and allocated by m1n1
<kettenis>
the second is m1n1 itself, which is dependent on where iBoot loads m1n1 isn't it?
roxfan has quit [Remote host closed the connection]
roxfan has joined #asahi
roxfan has quit [Remote host closed the connection]
roxfan has joined #asahi
Lucy[m] has left #asahi [#asahi]
joske has quit [Read error: Connection reset by peer]
joske has joined #asahi
acez[m] has joined #asahi
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
joske has quit [Quit: Quit]
user982492 has joined #asahi
yuyichao has quit [Ping timeout: 480 seconds]
boardwalk has quit [Quit: Ping timeout (120 seconds)]
boardwalk has joined #asahi
Gue___________________________ has joined #asahi
pFalken has quit [Quit: WeeChat 3.0]
yuyichao has joined #asahi
planglois has joined #asahi
planglois has left #asahi [ERC (IRC client for Emacs 27.2)]
Gu____________________________ has joined #asahi
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Gue___________________________ has quit [Ping timeout: 480 seconds]