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
<chadmed>
its interesting that it doesnt power up at all. maybe it was a last minute decision to remove its functionality so they just fuse enough of it off so that it doesn't turn on?
<chadmed>
depending on where in the design cycle they decided not to use it, and tsmc's yields it wouldnt make financial sense to spin a new silicon rev just to get rid of it. the validation costs alone would be ridiculous
jmr2 has joined #asahi
<jmr2>
Glanzmann: thanks for your various documents. I just tether-booted the whole chain for the first time, and it's quite fun to watch.
<jmr2>
Two comments: 1) instead of deleting fbaa64.efi (I still have it without ill effects), you can uninstall grub-efi-arm64-signed and its dependencies.
<jmr2>
2) I couldn't get dpkg-reconfigure grub-efi-arm64 to install grub. I ended up using mps's --efi-directory instead of your --removable, since it uses a path instead of a device - less risky.
<jmr2>
In the end, installing grub is three commands: apt-get install grub-efi grub-efi-arm64-signed- ; grub-install --target=arm64-efi --efi-directory=/boot/efi --removable ; update-grub
g8rfx9wozue0e9pa3n[m] has joined #asahi
skipwich has quit [Ping timeout: 480 seconds]
skipwich has joined #asahi
chengsun has quit [Quit: Quit]
chengsun has joined #asahi
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi
djk121[m] has joined #asahi
chengsun_ has joined #asahi
chengsun has quit [Ping timeout: 480 seconds]
skipwich has quit [Ping timeout: 480 seconds]
akemin_dayo has quit [Ping timeout: 480 seconds]
chengsun_ has quit [Quit: Quit]
chengsun has joined #asahi
PhilippvK has joined #asahi
jhnsn has joined #asahi
jx0 has quit [Ping timeout: 480 seconds]
<tpw_rules>
so i don't proclaim to have the best experimental setup, but i did put in some reasonable effort, and found that compiling an arbitrary linux kernel in a ramdisk is about 25% slower with 4K pages as opposed to 16K (1539 vs 1218 seconds)
* jmr2
feels like I'm doing the LinuxFromScratch install that I always wanted to do but never found the time to :-D
<tpw_rules>
there was one time it was only 10% slower, but i can't really explain why
<tpw_rules>
does the linux scheduler know the difference between the power and efficiency cores? maybe one of them is worse at 4K pages
<jmr2>
I think you're just seeing less memory alloc/dealloc, and possibly better cache performance.
<tpw_rules>
regardless i think i'm going to switch nixos over to 4k just so i can avoid all the 16k breakage
<jmr2>
What was the "new" breakage you recently reported?
<tpw_rules>
so it seems it's faster the first test after a reboot but otherwise it settles down to that 25% number with every subsequent test
<Glanzmann>
tpw_rules: I did not put the iommu.patch in my git because I thought it is outdated and just an experiment. I try to stay as close as possible to the asahi branch.
<Glanzmann>
jmr2: Thank you, I put that in the wiki instead. Also what I thought about is using the cat trick for the initrd (you can apparantly concat two initrd.gz cpio archives and the kernel extracts both into memory).
<Glanzmann>
for the wifi firmare.
jhnsn has quit []
<Glanzmann>
jmr2: I updated all documentation I could find (U-Boot, Debian and my quickstart.txt)
<Glanzmann>
Btw. with Macos 12.2 comes new wifi firmware. It works for me on the mini and the air.
m6wiq has joined #asahi
<Glanzmann>
With Macos 12.2 and 12.1 stub the hdmi seems sometimes not initialize after reboot. Am I the only one seeing this?
espo has joined #asahi
<chadmed>
twp_rules: the scheduler knows they are different but since the cpufreq driver is on hold and the dmips/mhz info in the DT was part of that commit, it cant effectively schedule between them
<chadmed>
as it stands theyre all treated identically performance-wise
<Glanzmann>
Does someone know how I build a non tethered m1n1 boot object to include kernel command line?
<Glanzmann>
So I'm trying jannaus dcp kernel. I tried with u-boot but that doesn't work.
<Glanzmann>
Now I want to use a non tethered m1n1.
<Glanzmann>
But include a kernel command line.
<Glanzmann>
I found it in my own documentation .... cat build/m1n1.macho <(echo 'boot-args=net.ifnames=0 rw root=UUID=FE9C5AC8-EDF4-442E-A09E-E0451606898E rootwait rootfstype=ext4') Image.gz t8103-j274.dtb > m1.macho
<chadmed>
in menuconfig its under Boot options
<chadmed>
but you can also do that yeah ^
<Glanzmann>
chadmed: No I meant the quick and easy eway.
<espo>
morning
<chadmed>
good evening :-P
<espo>
;)
<Glanzmann>
jannau: A little bit late, but I just tried the dcp branch and it works well for me. I don't get u-boot with the dtb to work, but m1n1 chainloading works. hotplug works, putting a monitor with a smaller output on it and than putting the bigger one back also works. Mouse is fast. Scrolling in xterm is much slower than simpledrm. I can make a video if you want. Here is the dmesg:
<Glanzmann>
jannau: So I just verfied 'running' dmesg in tmux is dogslow but in a plain xterm is very fast. But I saw tmux being slow in other setups when a lot of output is out, but here it seems particular slow.
espo_ has joined #asahi
chadmed has quit [Ping timeout: 480 seconds]
<Glanzmann>
jannau: Modesetting and rotation also works. I'm using fbdev at the moment. I'll try modesetting xorg driver.
espo has quit [Ping timeout: 480 seconds]
espo_ is now known as espo
<Glanzmann>
jannau: I'll work the whole week with it and let you know how it went.
<Glanzmann>
I also noticed that I use on the air no longer modesetting but fbdev. So For now I'll stay on the modesetting on the mini.
<mps>
I got this in dmesg when added iommu.patch `1.376072] cs42l42 2-0048: CS42L42 Device ID (42A83). Expected 42A42`
<mps>
and sound is not initialized
<mps>
ahm, sound drivers can't be build as modules, I see
chadmed has joined #asahi
<kettenis>
mps: that message is normal (and povik should probably change the driver such that it doesn't print the "Expected 42A42" bit)
<mps>
kettenis: yes, but I forgot that I saw it earlier in dmesg output
<mps>
and forgot that I have to build sound drivers in-kernel, not as modules
nsklaus_ has joined #asahi
nsklaus has quit [Read error: Connection reset by peer]
<mps>
fine, with iommu patch and 4K page size f2fs works
m6wiq1 has quit [Read error: Connection reset by peer]
<mps>
tpw_rules: I confirm your speed test with 4K page size, about 25% slowdown
<sven>
wouldn’t surprise me if the cores are optimized for 16k and 4K was just added as a hack to allow 4K pages in userspace
<mps>
I wonder why some programs are 'limited' to 4K pages
<mps>
in meantime I tested build some of my crystal lang programs with 4K and 16K pages and don't speed differences, maybe 1-3%
<mps>
s/don't/don't see/
<chadmed>
mps: probably a hard coded page size somewhere in the code. that was the problem with libunwind
<chadmed>
couldnt find a similar instance in llvm-libunwind though
<chadmed>
4K support (at least in userspace on macos) makes sense for as long as Apple intends to support their DTK/Rosetta stack
<jannau>
Glanzmann: good to hear. I'm a little surprised that the crash fix made it work. no need to make a video show speed differences. I haven't looked at that at all, still running dcp with hv and tracing
___nick___ has joined #asahi
<kettenis>
I have a hard time believing the 25% hit is because of Apple's implementation when Rosetta2 clearly is an important feature for the processor architecture transition
___nick___ has quit []
___nick___ has joined #asahi
<sven>
could also be that the 4K iommu patch does something weird which slowly everything down, but that would also surprise me
<sven>
*to slow
<sven>
erm.. *slows actually
<kettenis>
unfortunately OpenBSD doesn't support 16K pages on arm64, so I can't make a comparison
<sven>
pff… slacker ;p
<kettenis>
better ASLR with 4K pages ;)
<povik>
what's that? 2 bits of additional entropy?
<kettenis>
every little bit helps!
<jannau>
grub doens't seem to be thing used on arch linux arm. The kerenl packages I looked at install the kernel image as as "Image" and "Image.gz" which is not detected as kernel from the arch linux grub-mkconfig
<jannau>
the compressed Image.gz is useless since mkinitcpio can only handle x86 style compressed kernel images with built-in decompression
<mps>
last time I tried Arch alarm was about 3 years ago so I forgot details
<mps>
I've built alpine kernel pkg (APKBUILD) and it boots fine with grub, also creates initramfs on install
<jannau>
I did that the x86 kernel PKGBUILD does 'install -Dm644 "$(make -s image_name)" "$modulesdir/vmlinuz"' which is only marginally better than copying "Image" from the well known location
<jannau>
not really impressed on how arch linux (arm) handles kernel packaging
<mps>
yes, also I have this `cp arch/$KARCH/boot/Image.gz $pkgdir/boot/vmlinuz-$kver` in some custom scripts to build arm64 kernels
<mps>
iirc Arch alarm have somewhat complicated PKGBUILD for kernels because they build chromebooks kernels also
<Glanzmann>
jannau: Are you able to boot the dcp branch via u-boot, because when I try that I always get a black screen.
<Glanzmann>
I already tried u-boot with the dtb from the dcp branch, no luck.
<Glanzmann>
jannau: With Debian it work pretty well. Biggest problem is the signed shim and that u-boot expects the efi boot binary in the removable media and my default grub on Debian tries to update nvram variables, but this can be disabled, but apparantly not from the Debian installer, maybe I have to talk to them and it is possible but I just don't know how.
m6wiq2 has quit [Quit: Leaving]
* jannau
is only doing this because arch linux arm since marcan wants to offer that in the asahi installer
akemin_dayo has quit [Ping timeout: 480 seconds]
<jannau>
Glanzmann: I haven't tried booting a kernel with dcp through u-boot? I don't see why that shouldn't work assuming the correct dtb is embedded in the m1n1+u-boot binary
<Glanzmann>
jannau: Maybe I do something stupid, but I have not managed.
<Glanzmann>
jannau: With m1n1 tethered or untethered (my current setup), it works.
nicooo is now known as nicoo
<Glanzmann>
kettenis: Regarding u-boot, can I simply use the dtb of a kernel, or do I have to add anything special for it to work with u-boot?
<Glanzmann>
Because everything I tried myself, I did not get it to work.
<Glanzmann>
jannau: I think u-boot adds that to the device tree: https://tg.st/u/t8103-u-boot.dtsi. So I probably need to copy the dts from the dcp branch to u-boot and than build u-boot again and than it will work. I'll try that.
<kettenis>
that should no longer be necessary if you have an up-to-date m1n1
<kettenis>
but other stuff will break
<kettenis>
wifi for example and usb too
<Glanzmann>
I see, for me I did not see a picture on the screen for the mini.
<Glanzmann>
kettenis: But the right way is to copy the dts from the kernel to u-boot and than rebuild u-boot isn't it?
<kettenis>
the right thing for now is to merge changes into the u-boot dts
<Glanzmann>
I see, I'll try it.
<jannau>
Glanzmann: does it boot at all for you?
<jannau>
I get a SError on intialization of one of hte locked darts
<kettenis>
u-boot master might work better
<Glanzmann>
jannau: No, it does not. I don't even see m1n1 output. But that is probably due to the late hdmi initialization.
<Glanzmann>
kettenis: Is it upstream?
off^ has joined #asahi
<Glanzmann>
Wow. It appears to be.
<kettenis>
no nvme yet, no spi keyboard yet, no smc (maybe ever)
<kettenis>
but it does the darts in a different way
<Glanzmann>
Oh I see.
<Glanzmann>
kettenis: Btw. have you already look at the pro/max for u-boot? I don't have any pro/max devices but was wondering about u-boot support.
<jannau>
kettenis: no change for me with u-boot master but problems are expected if u-boot does anything with disp0/dcp dart
<jannau>
the changes work as expected but u-boot does not work
<Glanzmann>
jannau: I see that I'll just stick with the non tethered m1n1 for now.
<Glanzmann>
kettenis: About the no smc maybe ever in u-boot, is this a problem, or will smc just move to the smc kernel driver in OpenBSD?
<kettenis>
no point in adding smc support to u-boot when the kernels handle turning on the wifi
<Glanzmann>
I see.
<Glanzmann>
Btw. I tested macbook air with my hotspot on the mobile phone which did not work before, but now does. But I assume that marcan has fixed it?
<kettenis>
jannau: I don't think u-boot master would touch the dcp DART
<kettenis>
not so sure about the apple-m1-m1n1-nvme branch
<jannau>
kettenis: will it initialize all darts in the devicetree or only used ones?
<kettenis>
only used ones
<jannau>
that would explain why adding locked dart handling doesn't change anything
<jannau>
but the most simple explonation I have for the vanishing framebuffer as soon as u-boot loads is a reconfigured disp0-dart
<kettenis>
if you can point me at the relevant commit that add the nodes I can have a look
<kettenis>
applying those diffs to the u-boot dts files works just fine
<tpw_rules>
sven: for the record i still had the 4k patch applied when doing 16k tests, it just had a 16k kernel configured.
<tpw_rules>
i think arch linux arm has libunwind 1.6, does it give you problems jannau?
<jannau>
kettenis: in both u-boot master and apple-m1-m1n1-nvme? master probably works for me, testing is inconvenient due to the missing nvme support
<jannau>
tpw_rules: I haven't noticed anything so far except for a not working as expected gdb (haven't looked into it yet)
<chadmed>
jannau: i think for the mid term the sanest way to handle asahi support in ALARM would be to have an AUR repo with our own PKGBUILD that sanely installs a kernel and efi bootloader. since their whole schtick is providing a barebones rootfs for power users/embedded, i cant see them rushing to actually provide a sane distro kernel and way of installing it
m6wiq has joined #asahi
<jannau>
I believe that is the plan, fork ALARM to provide something useable and while doing so work with upstream to integrate things back in
<Glanzmann>
jannau: I'm curious what the first version of the installer will look like. Will alarm be the only planned distribution or are any others planned?
<kettenis>
jannau: yes both master and the branch work for me
<chadmed>
hopefully we will eventually be able to add ALARM (and its forks) to the list of distros that support EBBR. will make things a lot easier to maintain and install
<Glanzmann>
What is EBBR?
<chadmed>
Arm's "embedded" boot specification, which we are (coincidentally?) following pretty closely
<chadmed>
qrd is distros are able to assume a uefi environment, PSCI and optionally a device tree and thus focus their boot tooling on that, rather than have to try and cater to the existing approximately eleventy grillion different embedded boot procedures
<Glanzmann>
jannau, chadmed I see, thanks.
<jannau>
Glanzmann: dcp works with u-boot master
<Glanzmann>
chadmed / jannau: I have not understood how we will propagate the dtb to m1n1. So lets assume I have to kernels: one with dcp and one without, both have different device trees, so how will that be communicated to m1n1? Because m1n1 needs to load the dtb before grub, but only once I picked the kernel in grub, you know which device tree I need.
<Glanzmann>
jannau: Wow.
<Glanzmann>
jannau: I see, so I can plug a usb stick in my mini and use that for boot?
<Glanzmann>
Or have you rebased the nvme, spi and smc patches on top of master?
<jannau>
yes, as long as nvme is not u-boot master you need the ESP on a USB stick
<kettenis>
or apply the patch sets submitted upstream:
<Glanzmann>
Keyboard will work on the mini, because it is usb.
<kettenis>
oh, no pcie support in the upstream bits either, so no type-A ports
<Glanzmann>
kettenis: But with a usb-c to usb-a hub it will work.
<jannau>
Glanzmann: the devicetree is statically embedded in m1n1 + u-boot payload and can not change dependent on the kernel
<chadmed>
m1n1 does not need to know about the devicetree in an EBBR environment since it's just chainloading u-boot, which is then chainloading grub, which is what will pass the dt to the kernel
<chadmed>
or we do that yeah, dt is statically provided by a concatenated m1n1 payload
<chadmed>
which i _think_ is the plan here
<jannau>
booting a kernel without dcp driver works however with the dcp devicetree
<Glanzmann>
jannau: I see. But in the end we need to get a stable device tree and if it changes, we just need to chainload m1n1 with the new device tree embedded or reinstall it in 1tr.
<chadmed>
and also which is why we arent anywhere near ready for end users to jump on board, even if we had a sane environment where kernels can be swapped out on the fly, we're still at a point where the dt is unstable
<Glanzmann>
chadmed: I see and we don't have chainload support.
<jannau>
chadmed: the devicetree has to be provided by m1n1 as it adopts it to dynamic data provided by iboot
<Glanzmann>
chadmed: I mean with m1n1/u-boot/grub you can already swap kernels on the fly.
<Glanzmann>
jannau: I see.
<chadmed>
yeah we can swap kernels, but since m1n1 is providing the dt in this instance if the dt changes youd still need to get into 1tr and build a new boot payload
<chadmed>
honestly it wont be an issue once the DT is stable since its not like the machines can magically just change on us
<Glanzmann>
Yep. And I was wondering how that will work out in the end, but it is clear, device trees will stabilize and m1n1 takes care of them.
<chadmed>
yeah pretty much
<chadmed>
at that point we will have an (almost) EBBR compliant boot environment on these machines, and almost compliant is compliant enough for a generic EBBR-capable distro to install an efi bootloader
<kettenis>
and it is good for security as it won't be possible to put malicious stuff in the device tree without going through 1TR
<Glanzmann>
jannau: How did you try u-boot master? Did you use a usb stick and a usb keyboard via a usb-c hub?
<jannau>
yes, although I did not touch the keyboard
<Glanzmann>
jannau: And the device tree you got by copying the the device tree from the kernel to u-boot and said 'make'?
<Glanzmann>
I'll also try to rebase kettenis missing patches on top of master u-boot and see if that works.
<jannau>
by applying the changes from f9753ef3e94eb416dbe017c88f8939d2fc3f0f28 and 02468d323e6fc040f4b12346c8ae97209e195939 manually to the .dtsi files in u-boot
<Glanzmann>
jannau: I see, thank you.
the_lanetly_052___ has joined #asahi
the_lanetly_052__ has quit [Ping timeout: 480 seconds]
akemin_dayo has joined #asahi
skipwich has joined #asahi
jx0 has joined #asahi
jx0 has quit []
MajorBiscuit has joined #asahi
<landscape15[m]>
Does anyone know the exact model of M1 NOR flash memory? Just curious
<landscape15[m]>
jn: thanks. I didn’t watch there. I’ll search for more docs
<landscape15[m]>
btw it’s the same brand of old MBA :D
espo_ has joined #asahi
espo has quit [Ping timeout: 480 seconds]
the_lanetly_052___ has quit [Ping timeout: 480 seconds]
espo_ has quit [Quit: Leaving]
MajorBiscuit has quit [Quit: WeeChat 3.3]
jmr has joined #asahi
jmr has left #asahi [#asahi]
jmr2 has joined #asahi
<jmr2>
landscape15[m]: you could probably just copy the DT nodes from the T6000 to the T8103 and read the info from dmesg... but that's definitely not risk-free.
pavan has joined #asahi
jmr2 has quit [Remote host closed the connection]
Raito_Bezarius has left #asahi [upgrading cluster]
popo__ has joined #asahi
<nsklaus_>
a little bit offtopic but, once asahi is installed and primary OS, how do i copy files to iphone ? (specificaly to the apple's "files.app")
<nsklaus_>
but the problem is that it doesn't seem to list or give access to files.app
popo_ has quit [Ping timeout: 480 seconds]
jx0 has joined #asahi
<nsklaus_>
from what i see libmobiledevice give a very limited access to the iphone filesystem, the most important point to be able to copy & delete files on and off iphone is to get access to files.app space on iphone
<nsklaus_>
would be nice to figure a way to be able to performs tasks like this directly from asahi instead of having to reboot to macos just to have proper access to ios devices