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
<tpw_rules>
i assume getting a stable display is dependent on DCP work. is there some kernel branch somewhere i can use to give that a whirl?
<tpw_rules>
so i've got kettenis uboot booting, but something goes wrong handing off to the kernel. the screen just prints Starting kernel... and the hypervisor console only goes this far: pastebin.com/z0Dc09EM it seems to freeze because the network never comes up
<tpw_rules>
booting it without the hypervisor does not help
skipwich has joined #asahi
Dcow_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
leah has joined #asahi
PhilippvK has joined #asahi
phiologe has quit [Ping timeout: 480 seconds]
marvin24_ has joined #asahi
marvin24 has quit [Ping timeout: 480 seconds]
marvin24 has joined #asahi
yuyichao has joined #asahi
marvin24_ has quit [Ping timeout: 480 seconds]
marvin24_ has joined #asahi
marvin24 has quit [Ping timeout: 480 seconds]
sailorek1234 has joined #asahi
Glanzmann has joined #asahi
<Glanzmann>
tpw_rules: For the mini, rerun the asahi installer with the oldest version (10.1 I think). That one gives you a display on the mini (on macbook air the newest version also gives you display).
<marcan>
tpw_rules: you want keep_bootcon when stuff fails right after the serial init
<Glanzmann>
About the resolution, since dcp is currently not working, you can try the following steps (untested - I'll test them if I have the time): https://pbot.rmdir.de/aabP_zkJFhxOIbysRcsJZQ
<marcan>
Glanzmann: anything <12.0.1 works, please don't tell people to go to the oldest firmware for no reason
<Glanzmann>
marcan: What is the newest that works?
<Glanzmann>
Btw, yesterday a macos update was released, I immediatly tried it, but still does not give video on mini.
<marcan>
anything <12.0.1
<marcan>
yes we know
<marcan>
it's looking like I'll have to add iBoot-protocol DCP support to m1n1 to bring up the display
<marcan>
(sigh, thanks apple)
<Glanzmann>
marcan: Yes, looks like it, but the code is probably already there.
<marcan>
?
<marcan>
m1n1 has no native DCP support
<marcan>
and nobody has even reverse engineered the iBoot protocol yet
<Glanzmann>
tpw_rules: Than about the xorg. If you want to run wayland, firefox and other applications will just work. If you go with xorg, I recommend on using the 'fbdev' driver instead of the default 'modesetting' Because with the fbdev, firefox works. About video playback. The best results I got was with mpv using the 'drm' driver.
<Glanzmann>
marcan: Alyssa wrote some experiments for m1n1 which at least sets the resolution.
<Glanzmann>
marcan: Alyssa has a kernel dcp driver which currently does not work, but worked in the past which was able to do 'hdmi hotplug'.
<marcan>
those are python
<marcan>
I wrote the DCP python stuff
<marcan>
that is not using the iBoot protocol nor is it C
<marcan>
I am fully aware of the kernel driver she wrote based on my python :)
<marcan>
none of this helps what I want to do in m1n1 which implies writing a minimal RTKit stack in C for m1n1 and then reverse engineering and writing a minimal client for the iBoot DISP0 service endpoint
<marcan>
because we are *not* putting dcpep support in m1n1
<Glanzmann>
marcan / sven: About the random writes with sync issue, has someone already looked up the nvme device in the apples and looked up, if it has 'powerloss protect - a supercapacitor on the ssd which dumps the write cache on a flash chip on powerloss', if that is the case we can skip the 'flush cache' on the sync.
<marcan>
the controller is in the SoC, there is no supercapacitor for that
<Glanzmann>
marcan: I see. So this is no off the shelf device.
<marcan>
well of course it isn't, otherwise we wouldn't have to write a driver for it
<Glanzmann>
Okay, got it.
<chadmed>
i dont even think its even based on anything, it breaks the nvme spec in a couple of places aiui
<marcan>
it's custom, embedded in the SoC
<marcan>
like many other things about this SoC
<chadmed>
yeah
<sven>
I have some outdated rtkit c code for m1n1 somewhere fwiw. Should be in a closed PR I think
<Glanzmann>
Okay, got it.
<Glanzmann>
marcan: New notebooks have a battery (for the nvme write cache). If you boot up macos on mini, pull the physical plug, the screen stays on for ca. 1 second. Maybe macos uses that second to destage the nvme write cache.
<sven>
speculation isn’t going to help anyone
<marcan>
Glanzmann: all laptops have a battery, ???
<Glanzmann>
marcan: My bad. What I wanted to say is the nvme on the notebooks can use the battery of the notebook to destage the write cache.
<marcan>
yes, it can
<Glanzmann>
On the mini, I just pulled the plug and noticed that my screen stays on for one more second. So maybe they have enough power in a capcitor or a battery hidden in the power supply (has someone disassembled that) to destage the write cache on power loss.
<marcan>
it's obviously safe to not flush caches on a laptop if you have last-gasp handling of some sort
<marcan>
and the capacitor of the system PSU might also be enough to do the same on desktops, if it has last-gasp notification too, though I'm not sure how that works out with the iMacs having it external
<marcan>
there is no magic battery
<Glanzmann>
Got it.
<chadmed>
the M1 mini's power supply has enough capacitance to keep the system going for a second or two if its idling yeah but thats not a substitute for safe disk handling
<marcan>
it's normal for a low power machine to run for a second or so off of the main SMPS reservoir cap
<marcan>
chadmed: it is *if* designed that way
<Glanzmann>
Good point.
<marcan>
which we don't know
<sven>
if you want to help go and use my nvme tracer and see what’s up. Throwing out random ideas doesn’t get us anywhere
<marcan>
but either way cache flushes shouldn't kill performance like they do
<Glanzmann>
I agree.
<Glanzmann>
sven: Good point.
<Rakshit[m]>
Hey guys, can anyone guide me on how I can start contributing 😅 or if there's anyone who I could join and help?
<Rakshit[m]>
There's so much going on I don't know where to start haha
<Rakshit[m]>
But as for my experience, I know Kernel character Device Development :P
<mini>
thanks to everyone who's been involved in the project so far :) my m1 mac mini now boots up into debian so I can use it as a local & fast arm64 build machine!
jkm has joined #asahi
jkm has quit []
conradev has quit [Quit: -]
conradev has joined #asahi
<sorear>
I just want to say that I love what you did with the color-coded support matrix
<mps>
just built latest asahi kernel and booted it. keyboard works (I'm typing on it right now) and touchpad work
<mps>
sound driver is loaded but doesn't work. got this in dmesg: PS mca1: Failed to reach power state 0xf (now: 0x24f)
StupidYui has joined #asahi
<mps>
very good progress, thanks all who works on this
<mps>
touchpad is too sensitive, can move cursor even without contacting surface
al3xtjames0 has joined #asahi
al3xtjames has quit [Read error: Connection reset by peer]
al3xtjames0 is now known as al3xtjames
aafsmarak[m] has joined #asahi
<mps>
f2fs doesn't work, dmesg says '07:21 .....................@marcan| I wrote the DCP python stuff
<mps>
uh sorry
aafsmarak[m] has left #asahi [#asahi]
<mps>
f2fs doesn't work, dmesg says '07:21 .....................@marcan| I wrote the DCP python stuff
<mps>
uhh
<mps>
sorry again
<j`ey>
>_<
<mps>
F2FS not supported on PAGE_SIZE(16384) != 4096
<mps>
keyboard and touchpad are to sensitive
<mps>
too*
<j`ey>
I assumed it was a PAGE_SIZE issue, but nice it's that explicit about it
<sven>
ah yes... that reminds me that i also need to pick up those dart patches for 4k page size again
<mps>
I'll rebuild with 4K and check
<sven>
with 4k anything attached to pcie will not work fwiw
<sven>
(no usb a ports, no wifi, no ethernet at least)
<j`ey>
mps has a mbp, so just no wifi
<sven>
and no sd card reader
<mps>
I'm not sure but I think usb worked when I build it with 4K about week ago
<sven>
yes, usb *C* works
<j`ey>
because that's USB C, not USB A
<sven>
usb *A* on the mini doesn't
<mps>
sven: aha, that is
Dcow_ has joined #asahi
Dcow has quit [Read error: Connection reset by peer]
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi
<mps>
yes, on mbp with 4K pages f2fs works and also usb-c
<mps>
but firefox still doesn't
Dcow has joined #asahi
<Glanzmann>
What is f2fs?
<mps>
flash friendly filesystem
<Namidairo>
compression does not exist on it to give you more space, it's there for flash endurance :P
<mps>
Namidairo: compression is added in last few kernels
<j`ey>
marcan: planning on having a stream this week?
<marcan>
j`ey: yes, haven't decided when yet though
<marcan>
I wanted to do it today but ended up with too many things to pick at
<Glanzmann>
wifi
<j`ey>
Glanzmann: yup
<j`ey>
marcan: look forward to it, if/when it happens ^_^
<nilsi[m]>
Looks like the September progress report is pinned still on the asahi twitter account.
<marcan>
nilsi[m]: thanks, just updated it :)
kyoto has joined #asahi
kyoto has quit [Remote host closed the connection]
darkapex2 has joined #asahi
darkapex1 has quit [Ping timeout: 480 seconds]
sailorek1234 has quit [Quit: sailorek1234]
c10l8 has joined #asahi
guan_ has joined #asahi
aeroraptor_ has joined #asahi
sjg1_ has joined #asahi
philpax_ has joined #asahi
tertu has joined #asahi
c10l has quit [Ping timeout: 480 seconds]
jabashque_ has joined #asahi
Lightsword_ has joined #asahi
nkaretnikov_ has joined #asahi
tardyp_ has joined #asahi
sorear_ has joined #asahi
Vaughn_ has joined #asahi
guan has quit [Ping timeout: 480 seconds]
guan_ is now known as guan
nkaretnikov has quit [Ping timeout: 480 seconds]
nkaretnikov_ is now known as nkaretnikov
gruetze_ has joined #asahi
sorear has quit [Ping timeout: 480 seconds]
sorear_ is now known as sorear
tbodt_ has joined #asahi
tbodt has quit [Ping timeout: 480 seconds]
rcombs has quit [Ping timeout: 480 seconds]
Lightsword has quit [Ping timeout: 480 seconds]
jabashque has quit [Ping timeout: 480 seconds]
<tpw_rules>
marcan: i tried keep_bootcon, but i'm not sure that's the problem and nothing really cahnged. i think something goes wrong when linux tries to take over the DART/iommu. i'm using extlinux boot, but maybe that's not really working now? booting the kernel through grub loaded by efi seems to work though
tardyp has quit [Ping timeout: 480 seconds]
tardyp_ is now known as tardyp
Vaughn has quit [Ping timeout: 480 seconds]
Vaughn_ is now known as Vaughn
aeroraptor has quit [Ping timeout: 480 seconds]
aeroraptor_ is now known as aeroraptor
sjg1 has quit [Ping timeout: 480 seconds]
sjg1_ is now known as sjg1
philpax has quit [Ping timeout: 480 seconds]
tertu2 has quit [Ping timeout: 480 seconds]
_jannau_ has quit [Ping timeout: 480 seconds]
yuyichao has quit [Ping timeout: 480 seconds]
gruetzkopf has quit [Ping timeout: 480 seconds]
_jannau_ has joined #asahi
<sven>
does m1n1 remove the first dwc3/darts these days if you boot it in the HV?
<sven>
otherwise things will go very wrong when linux starts using those
<sven>
tpw_rules: ^-- if you try to run linux in the HV
<j`ey>
unless I mis understood
<sven>
ah. then maybe check if your m1n1 already has that commit ;)
<tpw_rules>
i've tried booting it without the hypervisor too. i'm using u-boot to try to load the kernel via an extlinux.conf. it loads, then prints "Starting kernel..." on the u-boot console on my HDMI screen, then nothing else happens. if i run it in the HV, then the same stuff happens on the screen but this is all i get over /dev/ttyACM1: https://pastebin.com/z0Dc09EM . it never seems to progress further as the network never
<tpw_rules>
comes up
<sven>
382f00000 is the DART that should be used by the HV, isn't it?
<_jannau_>
does the u-boot mem layout script_addr/ramdisk_adr? script_addr is required for extlinux boot
<tpw_rules>
i set those values to something which seemed to work
rcombs has joined #asahi
<_jannau_>
tpw_rules: which usb-c port do you use on the mac mini?
<tpw_rules>
the one apple labels as the DFU port
<_jannau_>
the one closest to the power button? then the dart at @382f00000 should not be there
<tpw_rules>
yes
<tpw_rules>
if i download the kernel over m1n1, then it boots fine, and that DART is still there
<_jannau_>
how old is the m1n1 on disk? do you chainload a current one before run_guest.py
<tpw_rules>
it's yesterday's master
<tpw_rules>
going through u-boot also works if i have u-boot load grub with efi, then have grub start the kernel
<marcan>
are you passing in a device tree at some point post-m1n1?
<_jannau_>
it's expected to be there for the bare metal boot. It's a problem for the HV as it is the same USB port the HV uses
<marcan>
if you're somehow overriding the device tree that m1n1/the HV cooks up with a fresh one, that won't work
<tpw_rules>
ok yeah, u-boot is loading one
<tpw_rules>
but this doesn't work even without the HV. does that also need a custom device tree? does the linux.py script appropriately massage the device tree i pass it?
<_jannau_>
it must not then running under the hypervisor
jkm has joined #asahi
<marcan>
tpw_rules: linux.py does
<tpw_rules>
well perhaps i have two problems. if i simply chain u-boot instead of running it under the hypervisor, it still doesn't boot and i don't get any console output on the video screen. but i don't have any compatible usb-serial hardware to get a serial console, so maybe it is failing at a different point.
<marcan>
it would under the hypervisor too, if you do that (e.g. run it over vUART, though most people wouldn't do that)
<marcan>
the hypervisor has a virtual UART
<marcan>
open the second ttyACM device
<matthewayers[m]>
Would somebody be able to spend some time with me making sure that I have everything set up to contribute to the project? I would very much like to help out over the next month or so as I am out of classes but I am not quite sure where to start even after reading through the documentation. Any help would be appreciated. Feel free to DM me if you are interested and we can hopefully set something up.
<tpw_rules>
yes. if i do that then i lose connection when the kernel sets up the DART for that because it conflicts with m1n1 and it never appears to boot further
<marcan>
yes
<marcan>
you need to stop overriding the device tree
<marcan>
that's completely unsupported; m1n1 is the source of truth there, it's not just about hypervisor stuff
<marcan>
with the HV you should be loading a m1n1 + devicetree + u-boot payload, where m1n1 takes care of the DT munging
<marcan>
and no DTs anywhere else after that
<tpw_rules>
okay. so loading a device tree is expected to break things even without the HV being in the picture
<marcan>
basically, device trees must go through the m1n1 kboot.c code (which is called by both the embedded payload runner and linux.py)
<marcan>
yes
<marcan>
it might not break things very badly (yet) but it's still a terrible idea :-)
<tpw_rules>
alright, i'll fix that
<marcan>
I actually wonder what u-boot does about the framebuffer? I guess it transplants /chosen at least... but yeah, there's more than that
<tpw_rules>
i think whatever it does is wrong because i never get one from the kernel... but being able to boot it under the HV is a step towards rectifying that
<marcan>
then it might not even do that
<marcan>
I sure hope it transplants the memory range at least... if it doesn't then you're lucky it works at all
<tpw_rules>
by the way, is there any opinion about publishing some sort of "how to install linux on your m1" guide and precompiled materials? i don't want to unnecessarily increase your support burden
<marcan>
I won't stop you, but I do want to work on making that less painful myself in the very near future...
<marcan>
though at least if you're telling people how to set up u-boot + grub, that's a lot more useful than people burning kernels into m1n1 with kmutil :p
yuyichao has joined #asahi
<tpw_rules>
ok. i don't intend to really try to publicize it but i don't want to keep it to myself. it seems nobody has really put all the pieces in one coherent place yet
<marcan>
yeah, some docs to point people to are helpful
<marcan>
(even for myself, once I get around to starting to bundle u-boot with the installer)
<marcan>
I just hope it doesn't end up on Hacker News prematurely :-)
<tpw_rules>
thank you for all your hard work too, and all the other contributors.
<tpw_rules>
yeah exactly
<tpw_rules>
that reminds me, would pointing people to https://mrcn.st/alxsh be a problem
<marcan>
I just did on HN a few minutes ago; I'm reluctant to put it in any high-visibility doc of ours just *yet* but I certainly want people who are going to try to run this to use it
<marcan>
(in HN it was under a disclaimer that this is for kernel devs :p)
<tpw_rules>
perfect, thank you.
<marcan>
FWIW the real URL will be alx.sh once this is properly published :)
<tpw_rules>
yes
<tpw_rules>
also by the way, i somehow confused it the first time i used it and it told me to start step 2 from /Volumes/''/step2.sh
<marcan>
yeah, I wonder what happened there...
<_jannau_>
matthewayers[m]: I would start with compiling m1n1 and the linux kernel and then start with installing m1n1
<mini>
I had that once, but the other time it Did /Volumes/Linux/step2.sh like I expected
<_jannau_>
matthewayers[m]: I
<_jannau_>
matthewayers[m]: feel free to ask questions here if you run in to problems. I think that's more efficient than a 1 on 1
<marcan>
print(f"Installing stub macOS into {self.part.name} ({self.part.label})")
<mini>
but my install approach was: build m1n1, cross-compile a kernel, get yourself a rootfs, stick the rootfs on usb, use the install script to get a version of m1n1 running, boot linux under the hypervisor (useful for debugging, as you get easy usb serial outputs), copy the rootfs over, and then boom, working nicely :)
<marcan>
tpw_rules: do you remember if that message had the right thing in the parentheses?
<c10l8>
Is it safe to YOLO that script on my M1 Air? :D
<mini>
the hypervisor is incredibly helpful for getting up and running :)
<tpw_rules>
marcan: i don't, sorry. the script ultimately ended up in /Volumes/Linux\ 1/step2.sh and executed without problems once i found it
<marcan>
yeah, if you have multiple with the same name it gets confusing
<marcan>
but I didn't expect it to outright say ''
<marcan>
wonder if it's a diskutil issue...
<tpw_rules>
i'm not 100% sure why it was Linux 1 and not Linux. i created a container called Linux in disk utility before starting
<marcan>
the mountpoint gets a number appended if there is another one with the same name already
yuyichao_ has joined #asahi
<marcan>
that's not the volume name, just the mountpoint
<marcan>
also, I think I haven't tested existing-container mode in a long time, maybe that's broken!
<marcan>
I should test it again
<tpw_rules>
it didn't let me do anything until i created the container. i guess it's easier to create just a blank space with the command line diskutil, but disk utility itself seemed to automatically format it
<marcan>
yes, blank space is easiest, but you need the commandline diskutil for that
<marcan>
the GUI diskutil is... limited and broken in interesting ways
<tpw_rules>
oh yes. i found my own bug in it
<mini>
I did it last night using an existing container - I resized down to a 40G macOS, and created a 5GB APFS called "Linux", and the rest as a FAT32 for later formatting as ext4
<mini>
and I did get the right name once, but the wrong name once too, and I'm not quite sure what was different
<mini>
(once it was '', once it was 'Linux')
<tpw_rules>
if you create a FAT partition with lower case characters in the name, it fails to format it and gives it the wrong name
<marcan>
heh
<marcan>
I get the feeling I need to add a logging framework (not log4j :p) to the installer and have it copy out its log to the target Preboot partition or so, for post-facto debugging
<tpw_rules>
so just to be sure, changing the resolution on the mini's hdmi port from linux is not supported yet?
<marcan>
having extremely verbose debug logs behind the scenes would be very helpful (and also make it easier for me to trim down the output)
<tpw_rules>
that reminds me, you were saying it was scary to have access to the SPI NOR flash from linux, but have now added it to the device trees. did you find some reason to touch it?
yuyichao has quit [Ping timeout: 480 seconds]
<marcan>
tpw_rules: you need the DCP driver, but that's limited to 11.4 right now; it's on my list of things to look at and forward-port to 12.0...
<marcan>
but then again if you have 12.0 HDMI won't work at all right now without DCP :D
<tpw_rules>
how do i get it? i think i installed with 11.4 my second time.
<marcan>
tpw_rules: well, I'm also not advertising this to end users yet, and also I hear you can't actually brick it by wiping NOR
<marcan>
supposedly the restore process actually phones home to apple to download the calibration/etc info
<marcan>
I should actually test that though :-)
<tpw_rules>
"supposedly"? :)
<marcan>
I have a brand new Mini here... maybe it should be sacrificed to science...
<tpw_rules>
is the dcp driver in the linux-asahi branch? or some other one
<sven>
you already wanted to sacrifice it once and it didn't happen!
<marcan>
but yeah, tbh I just added it to test the SPI driver, but I might disable it by default
<marcan>
sven: every time I try to sacrifice it I come up with some way to achieve the same thing through software!
<marcan>
tpw_rules: it is not
<marcan>
I think alyssa just tried to rebase it recently?
<sven>
it'll also need proper locked DART support
<tpw_rules>
ok, i will have to try to track that down then because my display barely works and it's a pain
<sven>
and be ported over from the DMA api to the raw iommu api
<marcan>
how was I supposed to know that was going to work that well :D
<sven>
you can overwrite the NOR from software, can't you? :-P
<marcan>
yes :p
<mini>
is HDMI display compatibility a bit wonky, even with 11.4?
<tpw_rules>
that's my experience
<mini>
I found the apple stuff even only brings up my display successfully about 50% of the time
<marcan>
12.0 messed with DCP a lot, maybe it improved?
<tpw_rules>
i will say it's significantly worse than in macos itself
<marcan>
oh you mean the iBoot bring-up?
<marcan>
that's not too surprising
<mini>
yeah, to the point that I often don't even have any video for the boot options picker
<mini>
(but if I do it blindly, it *does* then boot into 1TR okay)
yuyichao_ has quit [Quit: Konversation terminated!]
yuyichao_ has joined #asahi
<jkm>
Hello all, is Linux already usable on Mac Mini M1?
<jkm>
Or Linux image that is ready to install on Mac Mini M1?
<jkm>
Or is it still WIP?
<j`ey>
jkm: usuable to what level?
<matthewayers[m]>
jannau: Thanks!
<j`ey>
there's no simple install-everything script yet
<jkm>
j`ey: By usable I mean working DE (eg. GNOME/KDE) and HDMI output to external monitor.
<j`ey>
jkm: that works, no GPU accel thouggh
Dcow has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<tpw_rules>
marcan: so the only way for the user to update their device tree will be to use kmutil? can u-boot be taught to do the same munging m1n1 does, or does it not have enough information?
<marcan>
tpw_rules: correct; no, u-boot does not have access to the ADT and cannot be taught to do what m1n1 does
<marcan>
eventually there will be an "update my m1n1" option in the installer, so you can just do the same curl and it'll run kmutil for you
yuyichao has joined #asahi
<tpw_rules>
so i should use kmutil to install m1n1 + my kernel's device tree + u-boot, have u-boot pass the kernel the device tree it's been given by m1n1, and start the kernel?
<marcan>
correct
<marcan>
device trees are not (in principle) tied to kernels, they are just maintained alongside the kernel
<tpw_rules>
ok, i had been using u-boot's device tree instead of my kernel's.
<marcan>
ah, well, that's a different thing, talk to kettenis
<marcan>
there are some differences that should eventually disappear
<marcan>
ISTR we need m1n1 to add some u-boot specific properties for the UART and its PMGR nodes
<marcan>
but yes, I think right now you need a couple changes for u-boot on top of the kernel device tree
<tpw_rules>
so the u-boot one is a superset rather than a subset? i guess it's easy enough to diff, but i'll have to double check later
<marcan>
well, it's probably both right now due to missing stuff
<marcan>
but it *should* be a superset ultimately
<tpw_rules>
mmm
yuyichao_ has quit [Ping timeout: 480 seconds]
<mini>
hm, interestingly if I use a different HDMI monitor it works far more reliably
<mini>
I guess the iboot display bringup stuff is a little rough
<marcan>
sounds like another reason to put my own attempt at that in m1n1...
<marcan>
given apple took it out entirely in 12.0.1 :/
<mini>
on my lg 4k (which I was using with this mac mini when it was my daily driver...) it's pretty much flawless. on a spare dell 24" it's very broken
<marcan>
I've never really had it go wrong myself, but yeah...
<tpw_rules>
my choices are doesn't work at all and works until the machine reboots
<mini>
tpw_rules: that's what I was seeing with the dell u2413 I was using. if you have a different monitor it's worth a shot
<mini>
I wonder if it works well with those cheap hdmi -> usb2 capture devices
<mini>
the UVC ones that are <20 USD/EUR/GBP
somkls^ has quit [Remote host closed the connection]
Dcow has joined #asahi
kgarrington has joined #asahi
<kgarrington>
Is the on-die ram in Apple Silicon ECC? Does that term even mean anything when there are no slots?
kgarrington has quit [Remote host closed the connection]
<marcan>
I briefly thought it was but I think it isn't; in fact I think ECC is impossible with 16-bit LPDDR channels :(
<marcan>
(or, well, not cost effective anyway)
<marcan>
it's not on-die, it's on package, fwiw
<marcan>
mini: I use it with a cheap usb3 one and it works
<marcan>
(the ~$30-40 ones)
<mini>
excellent, there's one on my desk... somewhere...
<mini>
I'll try that
<mini>
is it actually USB3 or does it just have a blue bit of plastic? I know some of them were doing that
<jn>
(i've seen rather wasteful ECC with 8 bit data + 5 bit polinomial + 3 bits wasted, but that's besides the point for this discussion)
<mini>
(in fact, the one I've just found on my desk is USB2, but has a blue bit of plastic in the connector. no USB3 pins!)
riker77 has quit [Quit: Quitting IRC - gone for good...]
riker77 has joined #asahi
riker77 has quit []
jkm has quit []
kgarrington has joined #asahi
kgarrington has quit [Remote host closed the connection]
kgarrington has quit [Remote host closed the connection]
kgarrington has joined #asahi
tdmm has joined #asahi
kgarrington has quit [Remote host closed the connection]
riker77 has joined #asahi
Dcow has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Dcow has joined #asahi
tdmm has quit [Remote host closed the connection]
tdmm has joined #asahi
Dcow has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
yamii has joined #asahi
Dcow has joined #asahi
Dcow has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Dcow has joined #asahi
Dcow has quit []
somkls^ has joined #asahi
lendi[m] has joined #asahi
<lendi[m]>
Hello!
c10l8 has quit [Remote host closed the connection]
c10l8 has joined #asahi
c10l8 has quit [Remote host closed the connection]
c10l8 has joined #asahi
c10l8 has quit [Remote host closed the connection]
c10l8 has joined #asahi
c10l8 has quit [Remote host closed the connection]
c10l8 has joined #asahi
c10l8 has quit [Remote host closed the connection]
c10l8 has joined #asahi
c10l8 has quit [Remote host closed the connection]
c10l8 has joined #asahi
<lendi[m]>
Soo... How useable is Linux on m1? I need a laptop for school, but I don't wanna get a x86 based laptop since the battery is so much better on arm.
c10l8 has quit [Remote host closed the connection]
c10l8 has joined #asahi
c10l8 has quit [Remote host closed the connection]
c10l8 has joined #asahi
c10l8 has quit [Remote host closed the connection]
c10l8 has joined #asahi
c10l8 has quit [Remote host closed the connection]
c10l8 has joined #asahi
c10l8 has quit [Remote host closed the connection]
c10l8 has joined #asahi
c10l8 has quit [Remote host closed the connection]
c10l8 has joined #asahi
c10l8 has quit [Remote host closed the connection]
c10l8 has joined #asahi
c10l8 has quit [Remote host closed the connection]
c10l8 has joined #asahi
c10l8 has quit [Remote host closed the connection]
<mps>
lendi[m]: it is not yet ready for casual users, more for developers and reverse enginers, and for those who want to play with it
<mps>
though some people uses it
<matthewayers[m]>
lendi: I am a student right now and I've resorted to using a Docker container for anything Linux-related until this project is mature enough to do a bare metal install
<matthewayers[m]>
That being said, I am going to set my computer up to contribute to the development of it over winter break
<mps>
there are cheap (used_ arm64 chromebooks which can be used quite fine with linux (I use them for more than 5 years)
<mps>
s/(used_/used/
<lendi[m]>
Okey, thanks! I'll look into it! Do you have any recommendations?
<mps>
currently I use old acer R13 chromebook with renewed battery which keeps it on battery around 12 hours, but it doesn't have GPU driver for linux
Dcow has joined #asahi
<matthewayers[m]>
lendi: If you are looking at using Linux on a Mac with Intel but don't want to deal with the T2 chip, there are probably some used 2015 MacBook Pro models floating around on Ebay. If you prefer something newer but still want Linux, there are companies that will ship laptops with Linux pre-installed, or you could do what mps did and use an old Chromebook.
<mps>
also my daughter use samsung chromebook (rk3399, gru-kevin) which have GPU driver
Dcow has quit []
<mps>
also I have old i3 intel macbook (2010 year) which still works fine with linux, but battery is not so good
<lendi[m]>
matthewayers[m]: It's mainly the arm chip im after because of the battery. And also, where I live we don't really have a good way of buying used, sadly
<lendi[m]>
But hey, maybe the stock os is enough for now? I never really used a Mac before, but I know that it's based of UNIX
<mps>
lendi[m]: I run linux in qemu on macos about for about month, works fine but plugging perifherals (usb) is cumbersome
<mps>
so not much usable for daily use
<lendi[m]>
Yeah, but it would be enough for application testing ig...
<mps>
yes, I think
<lendi[m]>
Otherwise I'll have to just bring my old shitty Linux laptop, but that works too ig :p
Dcow has joined #asahi
Dcow has quit []
___nick___ has joined #asahi
c10l8 has joined #asahi
c10l8 has quit [Remote host closed the connection]
___nick___ has quit []
c10l8 has joined #asahi
c10l8 has quit [Remote host closed the connection]
c10l8 has joined #asahi
c10l8 has quit [Remote host closed the connection]
c10l8 has joined #asahi
c10l8 has quit [Read error: Connection reset by peer]
c10l8 has joined #asahi
c10l8 has quit [Remote host closed the connection]
c10l8 has joined #asahi
c10l8 has quit [Remote host closed the connection]
c10l8 has joined #asahi
c10l8 has quit [Remote host closed the connection]
c10l8 has joined #asahi
c10l8 has quit [Remote host closed the connection]
c10l8 has joined #asahi
c10l8 has quit [Remote host closed the connection]
c10l8 has joined #asahi
c10l8 has quit [Remote host closed the connection]
c10l8 has joined #asahi
___nick___ has joined #asahi
c10l8 has quit [Remote host closed the connection]
c10l8 has joined #asahi
c10l8 has quit [Remote host closed the connection]
c10l8 has joined #asahi
c10l8 has quit [Remote host closed the connection]
c10l8 has joined #asahi
c10l8 has quit [Remote host closed the connection]
c10l8 has joined #asahi
c10l8 has quit [Remote host closed the connection]
<matthewayers[m]>
lendi: I use macOS as my daily driver right now and have little to no issues. It works very well for a lot of college-related tasks and there are plenty of ways to get around software incompatibilities. If you want more of a linux-like experience, definitely download Homebrew (https://brew.sh)
c10l8 has joined #asahi
<lendi[m]>
Oh, cool! I'll look into the stuff more.
<lendi[m]>
Homebrew looks really interesting
___nick___ has quit [Ping timeout: 480 seconds]
<clover[m]>
macOS is a killer laptop OS, using it on desktop multimonitor setups is still very awkward to me
<clover[m]>
i got a magic trackpad which helps a good deal
Dcow has joined #asahi
andreafeletto has joined #asahi
Dcow has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Dcow has joined #asahi
ey3ball[m] has joined #asahi
Dcow has quit []
<ey3ball[m]>
Hi everyone ! I'm trying to get up and running with Asahi's dev setup but I'm currently hitting a wall while attempting to install m1n1 into my stub partition
<ey3ball[m]>
I'm getting the following error from kmutil : Error Domain=KMErrorDomain Code=71 "Fileset Error: Invalid Mach-O boot properties" UserInfo={NSLocalizedDescription=Fileset Error: Invalid Mach-O boot properties}
<ey3ball[m]>
does this ring any bell ?
Dcow has joined #asahi
Dcow has quit []
yuyichao has quit [Quit: Konversation terminated!]