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
<PthariensFlame[m]>
So what does the M1 Ultra officially having "32 Neural Engine core" mean for the ANE@1 on each die?
<PthariensFlame[m]>
Does the fact that having two ANEs hooked up at once is apparently not a problem tell us anything about why one (or two) of them are still disabled?
<PthariensFlame[m]>
s/core/cores/
<user982492>
I noticed that Alyssa is developing the GPU drivers on macOS. Will that mean that macOS will get Vulkan support? If so, will it be good enough to run VKD3D-Proton?
off^ has joined #asahi
amarioguy has joined #asahi
<bluetail[m]>
<user982492> "I noticed that Alyssa is..." <- Yea, but I doubt it will happen within the next 12 months
<bluetail[m]>
My personal thought on this, perhaps in 2 years
<user982492>
Will the driver for M1 GPU work for M2, M3, ...? Or will it have to be redone each time?
off^ has quit [Ping timeout: 480 seconds]
Gu____________________________ has joined #asahi
Gues__________________________ has quit [Ping timeout: 480 seconds]
branon has joined #asahi
<branon>
m1 ultra support when
<chadmed>
it should Just Work(tm) with a devicetree
<branon>
:)
<user982492>
Are their Vulkan features or extensions that M1 cannot efficiently support?
pwg_ has joined #asahi
<chadmed>
there'll probably be a few things, yeah. we will have to emulate them in software
<chadmed>
that's putting the horse before the cart though. the current focus is on GLES compliance as a baseline and to understand what the hardware can and cannot do
<chadmed>
and that's before even thinking about making GLES fast :P
<chadmed>
good news is once we understand the hardware, writing a vulkan driver means we get zink support, so we only have to worry about making vulkan work nicely after that
pwg has quit [Ping timeout: 480 seconds]
<user982492>
Why write GLES at all if zink can be used?
<chadmed>
its a (relative to vulkan) small API, but is enough to give us accelerated desktop environments and web browsers so its a good starting point for reverse engineering and understanding the hardware while also implementing must-have features
<user982492>
That makes sense
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
csileeeeeeeeeeeeeeeeeeeeeeeeoe has joined #asahi
user982492 has joined #asahi
riker77_ has joined #asahi
riker77 has quit [Ping timeout: 480 seconds]
riker77_ is now known as riker77
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
pfdub[m] has joined #asahi
<pfdub[m]>
Hey There, wanting to help with checking notes and creating documentation. I currently have a MacMini M1, know a bit about networking, good at Java, haven't programmed C in a while. How do I get permissions to see earlier messages so I can see what is going on?
csileeeeeeeeeeeeeeeeeeeeeeeeoe has quit [Remote host closed the connection]
<Aaron[m]1>
<pfdub[m]> "I am hoping to get permission..." <- Matrix doesn't have any function to grant specific users access to history
csileeeeeeeeeeeeeeeeeeeeeeeeoe has quit [Remote host closed the connection]
<chadmed>
matrix is just a bridge to the IRC channels on OFTC
<chadmed>
this is an IRC channel
the_lanetly_052__ has joined #asahi
colemancda has quit []
gladiac has joined #asahi
sheepgoose has quit [Ping timeout: 480 seconds]
sheepgoose has joined #asahi
sheepgoose has quit [Ping timeout: 480 seconds]
sheepgoose has joined #asahi
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<jannau>
apple's order system is strange, the same M1 Ultra / 128GB config has an earlier delivery date when configured from the m1 max mac studio
eroux has joined #asahi
memoryleak has joined #asahi
<arnd>
jannau: good to know. I don't expect it to actually make a difference. It seems another difference is that doing it this way you can pick a 512GB SSD, while the other one starts at 1TB for an extra €230. For the difference, I would probably get a 2TB m.2 drive and an external TB enclosure.
sheepgoose has quit [Ping timeout: 480 seconds]
<jannau>
as far as I'm aware the store delivery estimates are somewhat reliable. The difference is not a few days but a month: 30th of march to 6th of april vs 4th to 11th of may
<jannau>
it's the other way for the 64GB ram config
sheepgoose has joined #asahi
memoryleak has quit [Ping timeout: 480 seconds]
sheepgoose has quit [Ping timeout: 480 seconds]
ciggi has joined #asahi
sheepgoose has joined #asahi
memoryleak has joined #asahi
<marcan>
jannau: weird, maybe I should've tried that...
<marcan>
huh, indeed, it's earlier, though still later than what I got (at least now)
<marcan>
oh well
<rednaks[m]>
Been reading that Linux scheduler wasn't ready for 12th gen was there any specific dev on the scheduler made for the M1 ?
<chadmed>
arm chips have had heterogeneous multiprocessing for a long time so the infrastructure was all there
<rednaks[m]>
oh nice then :) thanks
<chadmed>
intels problem aiui was getting the linux scheduler to actually play nicely with their hardware scheduler block, which they call thread director
<Glanzmann>
amw: Yes, thats bullseye. Because someone else is also running Debian stable, but did not have a trackpad, so I told him about libinput. He took the one from testing and than it was working for him.
<Glanzmann>
amw: The exact same x error I had before, but I don't know what I did to get rid of it.
<amw>
Glanzmann: Your live-stick only has an initrd (big one) - has that got X in it?
<Glanzmann>
amw: No, it has not. But you can do apt update; apt install xinit blackbox xterm
<Glanzmann>
or any other package for that matter.
<Glanzmann>
So as long as you don't run out of ram, you can install whatever you want including gnome.
<amw>
ok - assume it has the wifi stuff in it?
<Glanzmann>
Yes.
<Glanzmann>
It uses the new location.
<Glanzmann>
So make sure that you have a vendorfw/firmware.tar on your efi partition, than it works out of the box.
<Glanzmann>
amw: The current version uses 4k pagesize.
<Glanzmann>
j`ey: Is the m1n1 chainloading from disk already working for kernel junior developers?
<j`ey>
Glanzmann: looks like it's working now, just not pushed yet
<j`ey>
well, pushed to the rust branch, so you could try build it at least.. if you wanted
<Glanzmann>
I see, I did a git pull and there was a new branch 'rust' that is why I was asking.
<Glanzmann>
j`ey: Is there a quickstart howto what needs to be done to test it?
<j`ey>
Glanzmann: no
<j`ey>
Glanzmann: installing rustup is probably a good first step
<Glanzmann>
I see, I'll try in 1,5 hours or so and ask if I don't get it running.
<Glanzmann>
Thank you.
<amw>
Glanzmann: You initrd contains the .deb files (in var/cache/apt/archives) that were used to build it :-)
<amw>
Glanzmann: Looks like my initrd is missing the wifi firmware - probably didn't put it in the right spot - thanks will play with it tomorrow - should be fun
eroux has joined #asahi
euxine has joined #asahi
amarioguy has joined #asahi
yuyichao_ has quit [Ping timeout: 480 seconds]
mbilker has joined #asahi
<Glanzmann>
amw: You can also manually extract it and than run the commands from /etc/rc.local
euxine has quit [Remote host closed the connection]
<j`ey>
make CHAINLOADING=1 to get the nvme chainloadin code
<Glanzmann>
Thanks. I see.
<Glanzmann>
j`ey: So m a r c a n currently puts it in the installer?
<Glanzmann>
Than I only need to put my m1n1/u-boot into right directory?
<mps>
Glanzmann: ah, I misunderstood then, sorry
<j`ey>
Glanzmann: exactly
<Glanzmann>
Cool.
<Glanzmann>
Has m a r c a n mentioned in the stream how he plan to distribute the to be chainloaded object? Will he put in the kernel package or as a separate package?
<mps>
j`ey: where u-boot should be put? '/' on ESP
<j`ey>
not sure
<Glanzmann>
mps: I'll find soon enough and tell you.
<povik>
concatenated to m1n1 maybe
<j`ey>
it might not be fixed, you might be able to specify it
<mps>
j`ey: ok, will look source later
<povik>
m1n1 the second, to be specific
<mps>
Glanzmann: no, you don't have to look this for me, I'm not in hurry
<Glanzmann>
mps: m. is working on the installer as soon as he is finised, I'll get the efi zip extract it and than I know the filename.
<Glanzmann>
mps: I'll look it up for myself to adopt the debian installer and than tell you. :-)
<j`ey>
povik: mIInII
<povik>
yeah
<mps>
Glanzmann: ok, and thanks :)
<Glanzmann>
I'll call it studio.
<Glanzmann>
Or uart.
bisko has joined #asahi
<kov>
Glanzmann, can I haz dm-crypt on that one =D
<Glanzmann>
kov: Do you have the options, than I put them in.
<Glanzmann>
j`ey: It is building.
<kov>
Glanzmann, CONFIG_DM_CRYPT and CONFIG_CRYPTO_AES should probably be enough
<kov>
there are a bunch of hardware-specific acceleration options CONFIG_CRYPTO_AES_ARM64_CE CONFIG_CRYPTO_AES_ARM64_CE_CCM CONFIG_CRYPTO_AES_ARM64_CE_BLK CONFIG_CRYPTO_AES_ARM64_NEON_BLK CONFIG_CRYPTO_AES_ARM64_BS, I don't know which are useful but I think none are required
<kov>
hopefully with those two only we can use cryptsetup to prepare or fix the file systems from debian live
mbilker has quit [Quit: Arch Linux Rules]
mbilker has joined #asahi
<Glanzmann>
Let me rebuild with them then.
<mps>
kov: I enabled all of them as modules, as I do for alpine linux-edge kernel
<Glanzmann>
kov: CONFIG_CRYPTO_AES was already in, CONFIG_DM_CRYPT was missing. I'm rebuilding. Should be done in 5 minutes.
<Glanzmann>
mps: I will try to take the Debian config and enable the asahi specific options and put that in a script, than this should be once and for all working, hopefully. I tried that before but the kernel was not booting for whatever reason.
<Glanzmann>
And in the future I'll probably boot two different variants: 4k and 16k pagesize so that everyone has what he wants/needs.
<j`ey>
what *they* want :)
<Glanzmann>
jannaus says it is more reasonable to ship a 4k kernel because that is what distros probably will do and more stuff works. m a r c a n says he wants to ship 16k so that more stuff breaks and gets fixed.
<mps>
Glanzmann: strange it is not booting if the needed parts for asahi is enabled
<Glanzmann>
I'm also more a 16k person. But I noticed that most users want 4k for the time being.
<kov>
mps, same
<Glanzmann>
mps: Maybe it was just me doing something stupid. I'll try again. And if it does not boot, I'll boot it in the hypervisor and see what is actually breaking.
<Glanzmann>
j`ey: Got it. :-)
<mps>
Glanzmann: you should get error on console if you remove 'quiet' from kernel cmdline and add loglevel=7
<Glanzmann>
Last time no console came up ...
<Glanzmann>
kov: You're build artefacts are ready.
<mps>
oh, that is strange then, could be clash with CONFIG_FB somewhere
<Glanzmann>
Or me doing something stupid.
<Glanzmann>
I'll try now.
<mps>
earlier (unrelated to asahi) I had this problem with simpledrm and FB on one test machine
<mps>
but forgot details
<_jannau_>
I would not expect that distros off multiple kernel images or multiple installer images for an efi distro installer. This only matters when enough HW support is upstream (or as patches in the distro kernel)
<mps>
btw, I reported f2fs problem with 16K pages to upstream, waiting for answer
<Glanzmann>
jannau: The Debian installer guy also says that debian will add an additional flavor regarding the kernel for m1.
<arnd>
mps: the problem that a lot of users reported with CONFIG_FB is that DRM_FBDEV_EMULATION no longer forces CONFIG_FB=y, but instead gets turned off when you have DRM_KMS_HELPER=y and FB!=y
<arnd>
so you need to manually enable CONFIG_FB=y in order to use the FBDEV emulation
<_jannau_>
Glanzmann: but will they add an installer/live image using that kernel flavor? I hope not
<Glanzmann>
jannau: No, they will do that once it is upstream.
<Glanzmann>
arnd: That could be my problem, then.
<mps>
jmr2: I don't have github account, please do this if you have it
<jmr2>
It might be easier for others to do it if you provided a description of the issue and a link to your bug report. But you know that github accounts are free, right?
jmr2 has quit [Quit: Page closed]
amarioguy has quit [Ping timeout: 480 seconds]
<mps>
hm, jmr2 left? I don't want to create account on microsoft owned platform
<emergenz[m]>
<jmr2> "It might be easier for others to..." <- Free as in beer, but not free as in speech
amarioguy has joined #asahi
ciggi has quit [Ping timeout: 480 seconds]
kloenk has quit [Remote host closed the connection]
amarioguy has quit [Ping timeout: 480 seconds]
<marcan>
pushed a new installer, OS kernel is probably broken (:p) but the UEFI only option should work and now does the whole chainloaded m1n1 magic
<j`ey>
marcan: can you push the insaller to git too?
<j`ey>
(np if you wanted to fix the commits up later)
<tpw_rules>
marcan: is the chainloaded m1n1 written down anywhere? want to know how to trigger it and stuff
<marcan>
it's in the commit message
<j`ey>
tpw_rules: 4575b35479306e1942fb726454a8c892921548df in m1n1 shows an example
<_jannau_>
wasn't it just a PCIe module late loading issue? The keyboard was probed. So it could work on the laptops or with a keyboard connected to the usb-c ports
<tpw_rules>
ah so it is, thanks
<marcan>
yeah, probably works on the laptops?
<marcan>
but also USB-C didn't work either so that's bork
<marcan>
also wifi didn't load either I think
<marcan>
anyway, I'll debug later
<mps>
iiuc from example, make and install m1n1 in 1TR, put m1n1.bin on ESP
<kov>
tpw_rules, _jannau_ I thought that was what marcan was working on in the last stream?
<kov>
or did I misunderstand what the chainload feature was
<j`ey>
kov: what he worked chainloaded m1n1 off nvme, from m1n1
<kov>
oh I see
<j`ey>
not chainloading m1n1 from uboot/grub
<kov>
so you put a new m1n1 somewhere and it'll chainload from there
<j`ey>
exactly, so you do: m1n1 -> m1n1+u-boot (chainload from ESP)
<j`ey>
so that u-boot can be upgraded by the distro
<kov>
great, that way the dtb can be upgraded as well, is the protection against downgrades already a thing as well?
<j`ey>
no protection there
<Glanzmann>
So I tried to modify a debian distro kernel and added the asahi options. I verified that all options are in. When I boot I see it reaching userland but it never starts x or offers me a login prompt. The keyboard appears to be _not_ working. But all the SPI options are in.
<Glanzmann>
And if I press the power button it shutdowns cleanly.
<Glanzmann>
But yes, I guess it is the simpledrm issue. So let me try that and report back.
<mps>
j`ey: I'm building on aarch64
<mps>
not cross building
<marcan>
you're cross building because the rust target is not linux
<j`ey>
^
<mps>
ah
<j`ey>
its a 'bare metal' target
<psykose>
they're not packaged afaik
<mps>
psykose: right
<psykose>
you would need rustup, if it has those
<j`ey>
rustup does
<psykose>
with rustup add `RUSTFLAGS="-C target-feature=-crt-static"` to be safe, and the rest should work fine
<mps>
psykose: where to add these flags?
<psykose>
export, env
<psykose>
not that it probably matters for bare metal anyway :p but i have no idea
<j`ey>
yeah it shouldnt need that
csileeeeeeeeeeeeeeeeeeeeeeeeoe has joined #asahi
<psykose>
i don't think it would affect the build in that case at all, but in regular builds the rustup musl toolchains are broken
<mps>
psykose: it doesn't :)
<psykose>
:)
<mps>
you are right
<mps>
(looks like I have to relearn about rust build system again)
<psykose>
you can just run rustup-init, then after it's rustup target add or something
<mps>
already did, but didn't helped
<psykose>
you have to load the new env vars
<psykose>
namely just adding ~/.cargo/bin to path
<psykose>
and make sure that is before the system rust
<mps>
psykose: ok, thanks
<arnd>
jannau: I ordered mine now with expected delivery Apr 6-13, but now the product page says May 6-13 regardless of the model. Either they the order system it, or enough people did the same thing until the dates lined up
<pugguu[m]1>
Glanzmann: is the chain loading working in debian?
<Glanzmann>
pugguu[m]1: Not yet.
<Glanzmann>
But soon.
<Glanzmann>
pugguu[m]1: I have to put one file into esp.tar and than it works.
<Glanzmann>
At least I hope so.
<pugguu[m]1>
Awesome
<Glanzmann>
marcan: But it is simpledrm.
<Glanzmann>
Because I now built in the module but I can tell from the dmesg that it is not initializing
<pugguu[m]1>
By the way I’m now making it a thing to ask for things to update every once in a while
<maz>
arnd: ah, there *is* a version with a smaller nvme?
eroux has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<arnd>
maz: yes, you have to pick the 10-core model first, and then upgrade to the larger CPU but keep the small SSD, jannau first noticed that doing this also gives you four week delivery instead of eight weeks for identical hardware config
<j`ey>
maz: yeah you start by configuring the m1 max version
<maz>
ah, nice!
<arnd>
but now it seems to all be up to eight weeks
<maz>
just in time for my birthday!
<arnd>
(in apple.com/de/)
eroux has joined #asahi
<arnd>
maz: oh, it still works in apple.com/uk/: 2-3 weeks vs 8-9 weeks
eroux has quit []
<maz>
arnd: says 9 May - 13 May
<arnd>
maz: ok, I see it now, the 2-3 weeks delivery is only for 32GB RAM, which is not available with the Ultra
eroux has joined #asahi
<pugguu[m]1>
<arnd> "maz: yes, you have to pick the 1..." <- Yea I did that trick to get a 16gb ram for Cheaper instead of getting the 16gb 512 I got a 16gb 256 and saved 200 quid at the time until they made the 512 model 8GB by defult
<pugguu[m]1>
Or something like that lol
amarioguy has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Quit: WeeChat 3.4]
amarioguy has joined #asahi
the_lanetly_052__ has quit [Ping timeout: 480 seconds]
<Glanzmann>
marcan: So I tried compiling SIMPLEDRM that does not solve my problem, than I tried to remove CONFIG_FB_EFI, than I have no framebuffer.
<Glanzmann>
For me it appears we need both, but they need to be intialized in the right order so FB_EFI initialized the framebuffer but simpledrm is providing the /dev/dri/card0
<Glanzmann>
And efi fb seems to be fb0 and simpledrm seems to be fb1.
<jevinskie[m]>
marcan: did you eventually find IODTNVRAM::unescapeBytesToData()?
<mps>
Glanzmann: I have FB_EFI, SYSFB and DRM_SIMPLEDRM, all =y and it works fine
<Glanzmann>
Okay.
<Glanzmann>
I have the same, but on the debian distro kernel it does not work but with my old config which is probably based on yours or jannaus it works.
user982492 has joined #asahi
<mps>
Glanzmann: do you have CONFIG_FB_SIMPLE, maybe it should be disabled
<Glanzmann>
# CONFIG_SYSFB_SIMPLEFB is not set
<mps>
have no idea then
<Glanzmann>
mps: It was: CONFIG_BACKLIGHT_GPIO=m
<Glanzmann>
Which was missing.
<Glanzmann>
So now xorg works, but sound does not come up.
<mps>
heh
<Glanzmann>
povik: Any idea? [ 2.236988] apple-pmgr-pwrstate 23b700000.power-management:power-controller@2c0: PS mca1: Failed to reach power state 0xf (now: 0x24f)
<Glanzmann>
I wonder why it was not a compile failure, but it is clear the new simpledrm has backlight binding, so simpledrm was not initializing for me.
<Glanzmann>
so efifb is fb0; simpledrm is fb1
<arnd>
Glanzmann: what happens when the gpio backlight driver is not there? No backlight or probe failure?
<mps>
Glanzmann: I don't have /dev/fb1
<Glanzmann>
arnd: It seems that I get a probe failure, because I get no simpledrm log message at all.
<Glanzmann>
mps: I assume you have no efi support in your kernel, this is why efi fb is never initalized: [ 0.000000] efi: UEFI not found.
<Glanzmann>
So now I'll try to throw out efi_fb.
<arnd>
Glanzmann: I think that message is the opposite: efi support is in the kernel but not the boot loader
<mps>
right, I boot with extlinux.conf
<Glanzmann>
arnd: I see, thanks.
<arnd>
Glanzmann: if the lack of the backlight-gpio driver causes the probe to fail, that might be a bug in the simpledrm driver, but I don't see where it references the backlight at all
<mps>
didn't yet found time to switch back to EFI
<Glanzmann>
arnd: I'll thow it out again, recompile and verify my assumption.
<arnd>
I would expect it to treat the backlight as optional: if no driver is found, it would continue without backlight
<mps>
arnd: simpledrm worked without gpio earlier
<mps>
so I think it is not related, but idk for sure
<Glanzmann>
mps: But that was before marcan did the patch.
<arnd>
I think there should also be some handover code, which ensures that you can boot with a built-in simpledrm or simplefb or efifb but later load the real driver that then owns the device after the simple drivers give it up.
<Glanzmann>
Also when I rmmod backlight_gpo my xorg hangs.
<arnd>
I can imagine that there is no handover between efifb and simpledrm because both expect to be the early drivers, not the real ones
<Glanzmann>
but I can press the powerbutton and see the shutdown messages.
<marcan>
arnd: the DCP driver will do proper handover
<marcan>
which is why I expect simpledrm to be built in
amarioguy has quit [Ping timeout: 480 seconds]
<j`ey>
arnd: the backlight code in simpledrm is only in the asahi linux repo
<jannau>
handoff from simpledrm to dcp already works
<arnd>
there should also be handover from efi_earlycon to efifb, but I assume nobody here is actually using efi_earlycon (despite it being really useful for debugging problems in early boot)
<marcan>
backlight can't really be "optional" because it could be a module, and we need the usual PROBE_DEFER stuff to handle init order properly
<arnd>
ah right, you can't have it both ways like this
<marcan>
but in that case it doesn't actually do it properly
<marcan>
so it *should* be optional (and sometimes broken)
<arnd>
j`ey: ok, that's why I didn't see that commit in mainline ;-)
<marcan>
(that needs a fix to handle PROBE_DEFER)
<marcan>
either way that backlight stuff is a stopgap
<marcan>
it'll go away entirely once DCP is in
<marcan>
I don't plan on trying to have handoff/fallback for that
<arnd>
so it works when CONFIG_BACKLIGHT_CLASS_DEVICE is disabled, and it works before that commit
<marcan>
it's going away from the DT once DCP is in
<Glanzmann>
arnd / marcan: I verified that the simpledrm does not initialize when I move the gpio_backlight module out of the way and rebuild the initrd
<bluetail[m]>
slightly off-topic: Does pastebot runs in docker or something, and how do you invocate a new upload? Through pipe?
<Glanzmann>
But I can tell that he is hydrated due to the toilet breaks and that he is proper fed, because he interrupted a stream to get something to eat. :-)
kaferka has joined #asahi
<Glanzmann>
So now I need poviks expertise to get the sound up and than we have a 'proper' distro kernel for Debian with the asahi options.
<arnd>
marcan: I think we probably want to always ignore -EPROBE_DEFER from devm_of_find_backlight() in the simpledrm, but not ignore it in any of the real drivers, so only the handoff gets deferred but not the console messages
<arnd>
that's probably what you and in mind as well
<povik>
Glanzmann: fixed in wip tree (that error you posted ^^)
<Glanzmann>
povik: Okay, so what is the best way to incorporate your wip tree in the current asahi branch?
<Glanzmann>
Just a 'git pull' or should i cherry pick a few commits?
<Glanzmann>
povik: Also with your wip branch, do I have speakers or the jack on the macbook air?
<kaferka>
hey there - i'm no dev by any means but could anyone point me towards the detection timeout for pcie on m1? my wi-fi is missing and I want to poke around for fun.
<j`ey>
but I think someone (chadmed?) said that it didn't help, but of course it's fun tro trying thins
<kaferka>
j`ey: yeah, i thought that was it but i guess i can confirm chadmed's finding
<kaferka>
but yeah it is fun - adhd is a bitch but asahi linux gets me going lol
<povik>
Glanzmann: ehm, best is to wait
<povik>
second best is pull
<povik>
it's on top of asahi, don't know if still current asahi
<Glanzmann>
I see.
<j`ey>
kaferka: were you K-A on youtube?
<kaferka>
j`ey: yeah haha
<j`ey>
kaferka: I read your message :-)
<kaferka>
thanks :')
<tpw_rules>
Glanzmann: what page size is your kernel?
<tpw_rules>
that x is crashing on
<Glanzmann>
tpw_rules: 4k
<Glanzmann>
tpw_rules: Issue resolved. Issue was that gpio-backlight was not in the kernel as a result simpledrm was not initializing as a result x did not start due to a colormapping issue.
<Glanzmann>
amw: PING. This is also the problem you had.
<Glanzmann>
j`ey: So about the new installer is it ready for junior kernel developers?
<Glanzmann>
Is it already on the usual location or do I need to build it myself?
<bluetail[m]>
<j`ey> "kaferka: https://github.com/..."; <- You guys are merging with Torvalds? Just to put that into perspective, Linus Torvalds is the main developer of the Linux kernel.
<bluetail[m]>
I think that is kinda impressive.
<j`ey>
bluetail[m]: yes all the code is going upstream
<j`ey>
Glanzmann: I think it's ready yeah
<Glanzmann>
Than lets deploy it.
<j`ey>
Glanzmann: you'll have to create the m1n1+uboot yourself, and double check where it's actually expected to be, I cant remember where
<j`ey>
bluetail[m]: you can already boot on the m1 with mainline linux.. it just doesnt have many features
<Glanzmann>
j`ey: Will do so.
<povik>
ha! turned out my speakers were being continuously throttled by the brownout detector
<povik>
that explains two things: why they weren't too loud, why one of them died sometimes
<j`ey>
something about the low frequencies?
<bluetail[m]>
povik: Brownout detector? Inside your home installation? That's... interesting...
<povik>
hm? home installation?
<povik>
j`ey: no, just bad (default) configuration
<j`ey>
povik: any progress on the fast audio?
<bluetail[m]>
povik: Thinking about M1 internal speakers, they don't have brownout detectors, do they?
<povik>
j`ey: fast? :D
<Glanzmann>
mps: That appears to be the path for the to be chainloaded object: esp/m1n1/boot.bin
<povik>
bluetail[m]: they do
<j`ey>
povik: you said the audio was sped up (yesterday or a few days ago)
<povik>
bluetail[m]: or rather the chip driving them has
<povik>
each speaker has its own chip, so i consider them together
<povik>
j`ey: oh right, that was just bad NCO config, easy to fix
<povik>
one final thing i was fixing now was reliability
<bluetail[m]>
povik: What do you do to solve that? Would you just communicate to the brownout connector to consistently push a specific voltage?
<bluetail[m]>
detector*
<povik>
bluetail[m]: i configure the chip over i2c, copying what apple configures
<j`ey>
povik: ah cool
<povik>
now let's slap a new compatible onto it and ship it!!!
<povik>
i am very excited i fixed both issues i had with it at once :D
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mps>
Glanzmann: aha, but I can't built m1n1 now because of rust build crap^Wsystem on alpine
<Glanzmann>
mps: Let marcan build the 'rust' m1n1 and build it without rust.
<Glanzmann>
And than the spinning rust will chainload your m1n1.
<Glanzmann>
mps: This is what I'm about to do.
<j`ey>
mps: can you paste your current m1n1 apkbuild (with rust attempt), maybe i will have a play later
<mps>
j`ey: I can upgrade it alpine aports later this evening, but will not push to alpine because it will fail and block builders
kaferka has quit [Read error: Connection reset by peer]
___nick___ has quit []
<mps>
I mean, upgrage in local branch
<mps>
(I'm out of house now)
___nick___ has joined #asahi
user982492 has joined #asahi
vnogueira has quit [Remote host closed the connection]
vnogueira has joined #asahi
<Glanzmann>
m a r c a n / j`ey / mps: Installer works, thanks. Chainloading, too. Where do I get the u-boot tree with the fancy asahi logo in the middle from?
<Glanzmann>
povik: Sound works from speakers with your wip branch merged, for now I'll not put in the debian tree and wait until m a r c a n has merged it.
<Glanzmann>
povik: But I actually like this way better, because now I can play one audio stream on the speaker and hear another one on the jack. So this is a feature, not a bug.
<povik>
that mode of playing in parallel through the speakers and jack has a defect
<povik>
there's noise mixed-in then, at a period
<povik>
don't know how that happens yet
<Glanzmann>
I see.
<j`ey>
Glanzmann: asahi branch in u-boot has the options 058c0bf9bb2601f1618b48822cb5851381e48d53
<bluetail[m]>
Glanzmann: Realizing I was the one not researching before asking the question. rmdir's pastebot has cli integration right in front of me, I just didnt see it.
<Glanzmann>
bluetail[m]: It has actually two: curl and perl. :-)
<Glanzmann>
j`ey: I also adopted debian installer image for the new asahi installer.
<Glanzmann>
marcan: How do you package the /boot/efi/m1n1/boot.bin? Do you put it in the kernel package or in a seperate package or what are you plans with it?
tanty has quit []
<opticron>
awesome, sound and deep sleep are the last things I need for this machine to be a daily driver
<Glanzmann>
opticron: What m1 machine do you have?
tanty has joined #asahi
<opticron>
14" m1m
<opticron>
currently have debian on it from the pre-release install process, but I'll probably need to redo that for the chainloading release
<mps>
Glanzmann: your work on integration different things (from user POV) is awesome, I have to say
<mps>
(I drink too much wine with friends and I'm 'out' today to try anything)
tanty has quit []
<Glanzmann>
opticron: I just changed my debian from prerelease to the newest asahi installer.
<Glanzmann>
mps: Hrhr, I need to hit bed, have to get up tomorrow at 06:00 ...
<Glanzmann>
mps: Anyway, I tested the spakers and they work. You can find everything you need in the history of this git repository: https://git.zerfleddert.de/cgi-bin/gitweb.cgi/m1-debian but I'm not shipping it for the time being.
<Glanzmann>
Until it is merged into the asahi branch.
<Glanzmann>
But the speakers and the jack work.
<Glanzmann>
marcan: Maybe you want to have a look at this: https://pbot.rmdir.de/l_4gY-U6xwrKxa0yzWvzQA - You can reproduce it with this config: tg.st/u/config-debian-distro-kernel-2022-03-09-4k
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
amarioguy has joined #asahi
eroux has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mofux[m]>
is there documentation / guide somewhere on how to try the current installer? i'm feeling adventurous :)
csileeeeeeeeeeeeeeeeeeeeeeeeoe has quit [Remote host closed the connection]
<landscape15[m]>
mofux: read the wiki on GitHub. There is all the information you need.
gladiac has quit [Quit: k thx bye]
amarioguy has quit [Ping timeout: 480 seconds]
Gues__________________________ has joined #asahi
<tpw_rules>
could the m1n1 stuff be taught to fwupd?
<tpw_rules>
and/or use the efi updatecapsule mechanism?
<kettenis>
without efi variable support that is hard
<tpw_rules>
i think you can put it in a specific directory
<kettenis>
ah right, that might be good enough
user982492 has joined #asahi
artemist has joined #asahi
pent1ckel has quit [Remote host closed the connection]
pent1ckel has joined #asahi
<mofux[m]>
landscape15: thx, got it working on M1 Air (alarm boots)
<mofux[m]>
seems there is no easy way to connect to wifi yet on the alarm base (wifi-menu not working because dialog is missing)
<mofux[m]>
also sometimes the login hangs after reboot. and sometimes wlan0 is not there after reboot
<mofux[m]>
but i assume it's too early to report these?
<j`ey>
wlan0 not coming up sometimes is known, for wifi there should be `iwd`