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
<RealityVoid>
But, why does it need the headers for the .ssl libs though, it obviously can't link against MY openssl (different arch) and it doesn't compile openssl itself since it looks for the headers only.
<j_ey>
thats a host tool that its building
<RealityVoid>
Well, build it, loaded is with m1n1 buuut... something is off. I think.
riker77 has quit [Quit: Quitting IRC - gone for good...]
bgb has joined #asahi
riker77 has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
<RealityVoid>
Also, in the "Under Hypervisor" section, it mentions initramfs.cpio.gz - where canI get that?
yuyichao has quit [Ping timeout: 480 seconds]
matthewayers[m] has joined #asahi
<jevinskie[m]>
So if I wanted to perma-boot macOS but with m1n1 as an intermediate stage (w/ appended KC), I’ll need to write enough macho and DT parser to replicate the python chainloader. Anything else that am I missing? The python bits seem quite simple.
Joe_R_Jacobs has joined #asahi
alyssa has joined #asahi
<alyssa>
building a linux kernel on the m1 bare metal linux
<alyssa>
this seems recursive
<alyssa>
also, I did not realize kernels were supposed to build this fast???
bgb has quit [Ping timeout: 480 seconds]
Joe_R_Jacobs has quit [Remote host closed the connection]
<marcan>
jevinskie[m]: we don't really support that use case; using macOS under m1n1 is intended for tethered experiments
marvin24 has quit [Ping timeout: 480 seconds]
darkapex3 has joined #asahi
darkapex2 has quit [Ping timeout: 480 seconds]
kov has joined #asahi
sailorek1234 has joined #asahi
<jevinskie[m]>
marcan: I understand that but was curious about it as a hobby hacking project. So far to me it seems like hacking kc loading into m1n1 is the easiest/cleanest way forward
<jevinskie[m]>
The victim m1 is going to be used for research anyways. I just want untethered use and quick recovery from panics :)
<marcan>
jevinskie[m]: why not just have two macOS installs? that's what I do
<marcan>
one for linux/hypervisor experiments, one for regular use
slicey has joined #asahi
<marcan>
you can even do it that way without creating a whole separate partition if you want; that way they share a single APFS container and you don't need to reserve a whole ~70GB or so for the second install
<kode54>
I barely have room on mine for the one macOS install
<kode54>
probably should have waited a couple of months and gotten the 1TB model instead
bgb has joined #asahi
bgb_ has joined #asahi
bgb has quit [Ping timeout: 480 seconds]
bgb has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
bgb_ has joined #asahi
bgb has quit [Ping timeout: 480 seconds]
bgb_ has quit [Ping timeout: 480 seconds]
Dcow has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
leah has joined #asahi
chamomile has quit [Ping timeout: 480 seconds]
Dcow has joined #asahi
slicey has quit [Quit: zzz]
mps has quit [Ping timeout: 480 seconds]
Dcow has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
bgb has joined #asahi
<bgb>
marcan: does the USB A ports on mini work now?
aleasto has joined #asahi
<sven>
those have been working since pcie support has been merged
<_jannau_>
yes, they work with linux 5.16-rc1
<bgb>
ok
mps has joined #asahi
nskl has quit [Ping timeout: 480 seconds]
phire has quit [Remote host closed the connection]
bgb has quit [Ping timeout: 480 seconds]
bgb has joined #asahi
phire has joined #asahi
<bgb>
jannau: do i need some extra config?
<bgb>
I just followed the SW:Linux, trying to boot from USB, but ended up with "sda1 unknown-block..."
<chadmed>
filesystem driver compiled in?
<bgb>
I just compiled with defconfig, let me check
<_jannau_>
it requires CONFIG_PCIE_APPLE
<sven>
ugh, SW:Linux is severely outdated
<bgb>
just failed with OCNFIG_PCIE_APPLE again
<maz>
you'll need far more than just defconfig (which builds for 4k pages, so not much will work by default).
<maz>
you need 16k pages, ARCH_APPLE, DART support, pinctrl, and pcie at the very least.
<j_ey>
bgb: do you have EXT4 or whatever FS built in?
<bgb>
j_ey: yes
<bgb>
ext4 built in
<_jannau_>
j_ey: doesn't unknown-block means the kernel hasn't enumerated the block device
<j_ey>
not sure, but that was worth asking too
<bgb>
maz: you mean build kernel with 16K page size ?
<maz>
bgb: yes.
<maz>
otherwise, no DART support. no DART support, no PCIe. No PCIe, nothing at all.
<kettenis>
btw, I've enabled DART sub-page protection in OpenBSD
<bgb>
sven: I heard you have add 4k support for dart, right?
<firefox317_>
is there a difference in functionality/performance between simplefb and simpledrm, why would I use simpledrm over simplefb?
<sven>
kettenis: nice :D
<sven>
bgb: yes, the latest version is somewhere on the mailing list
<kettenis>
and learned the the Broadcom Ethernet controller access memory with a 64-bit granularity
<kettenis>
so it triggerred faults when I passed it a network packet aligned on an odd 32-bit boundary
<_jannau_>
firefox317_: I would expect more things to work out of the box with simpledrm, see problems on stream with X11
<firefox317_>
_jannau_: yeah okay, but its not that with simpledrm it is suddenly flicker free or something like that. We need the dcp driver for that right?
<bgb>
maz: what kernel vision are you using?
lanodan_ has quit []
lanodan has joined #asahi
<maz>
bgb: 5.16-rc1.
<marcan>
kettenis: I had the same problem with a JMicron (yeah...) FireWire controller on intel
<marcan>
it would real double size command entries always, unconditionally, and then only parse what it needed
<marcan>
so it fell off the ends of pages even for normal IOMMUs
<marcan>
I ended up sending a workaround to linux that always leaves one short entry of free space at the end of ring buffers
<marcan>
(unconditional because it doesn't really matter for non-broken controllers)
<marcan>
*read
<kettenis>
I chose to always round/up the sub-page protection to 64-bits instead of 32-bits
<kettenis>
not much of a loss I figured
<marcan>
firefox317_: correct
bgb has quit [Ping timeout: 480 seconds]
<kettenis>
marcan: ouch, that is nasty
<kettenis>
even on systems without an IOMMU it can't actually assume the physical pages exist!
<marcan>
yeah :)
<marcan>
meanwhile broadcom tg3 ethernet is still broken on Intel IOMMUs on linux (at least some chips)
<marcan>
I have my IOMMU off for that reason on my iMac...
<marcan>
it just wedges itself and even corrupts data after a while with it
<sven>
ouch
<chadmed>
ive had nothing but bad luck with broadcom chips. three macs with broadcom wifi and ethernet and my pi 4, all garbage on linux
firefox317_ has quit [Remote host closed the connection]
<marcan>
recently some broadcom person started being active on the thread again
<marcan>
who knows, they might even fix it?
slicey has joined #asahi
<chadmed>
they day broadcom *fix* something i will find the nearest monastery and devote my life to god, because that would be proof that divine miracles do exist
<kettenis>
adding an IOMMU to the architecture after the fact is asking for problems
<kettenis>
Apple did us a service by having IOMMUs that can't be disabled ;)
bgb has joined #asahi
bgb has quit [Ping timeout: 480 seconds]
zopieux has quit [Ping timeout: 480 seconds]
zopieux has joined #asahi
Dcow has joined #asahi
<mps>
managed to get m1n1 boot, last line on screen is: Running proxy...
<mps>
I think now I have to chainload kernel
<mps>
is the 5.16-rc1 good enough to boot machine and continue to making initramfs?
<j_ey>
yes
<mps>
j_ey: thanks
<mini>
tg3 breaking on intel iommu is interesting, because those are used by hp and dell in an alarming number of servers. it can't be the whole range surely
<JTL>
mini: I was wondering the same
<mini>
I'm pretty sure my old hp microserver has the iommu enabled and hasn't exploded (and that has tg3 NICs. two of them even)
gladiac is now known as Guest6293
gladiac has joined #asahi
<_jannau_>
mps: for which device? 5.16-rc1 is only on the mac mini in a somewhat useable state. framebuffer, USB-A ports and gigabit ethernet works
<j_ey>
it should work on mbp with some tweaks to the DT (not keyboard though)
<kit_ty_kate>
is the fake 80GB macOS partition still necessary with asahi-installer?
<FireFox317>
the usb c ports also work on mbp/mba
<FireFox317>
well usb 2.0 over usb c
Guest6293 has quit [Ping timeout: 480 seconds]
<psydroid[m]1>
does that data corruption happen on Skylake and Kaby Lake? and Bay Trail?
<FireFox317>
kit_ty_kate, nope its not :)
<jix_>
kit_ty_kate: nope, there still needs to be a partition, but no full mac os, IIRC I ended up with a 2.5GB partition after following the installers instruction
<psydroid[m]1>
I haven't noticed anything, but my data is most important of all
<_jannau_>
not with the dtb from 5.16-rc1 or m1n1. hotplug doesn't work
<FireFox317>
_jannau_, yeah sorry when you add the correct nodes to the dtb it works (indeed without hotplug)
<kit_ty_kate>
jix_: cool! Thanks!
<mps>
_jannau_: I'm testing on macbook pro
<sven>
for usb-c hotplug you'll also need additional patches that haven't been reviewed yet
<mps>
_jannau_: I want to get it booting, later I will search/hunt/ask for patches to add
slicey has quit [Quit: zzz]
<FireFox317>
mps, i managed to do that yesterday on my m1 macbook air
<kit_ty_kate>
m1n1 installed and booted! That was quite painless ^_^
<kit_ty_kate>
now let’s try to figure out how to install ALARM
alyssa has left #asahi [#asahi]
yuyichao has quit [Ping timeout: 480 seconds]
slicey has joined #asahi
yuyichao has joined #asahi
<mps>
' Found a kernel at ..., Found a devicetree at ..., Found a cpio initramfs at ..., No more payloads at ...' and at the end 'No valid payload found'
<mps>
does that mean I forgot to add something
<j_ey>
mps: what command are you running?
<mps>
j_ey: in 1TR?
<j_ey>
no to start the kernel
<j_ey>
are you getting "Cannot find target type!" on the log?
<mps>
I created macho payload by 'cat' all these
<mps>
j_ey: no, last line on screen and serial console is 'Running proxy...'
<j_ey>
can you paste the cat and the linux.py or run_guest.py command lines?
<mps>
I'll look in kernel config to try find if something is missing to be enabled
<j_ey>
well it sounds like it changed, since it didnt say 'no valid paylod'?
<j_ey>
you need CONFIG_FB_SIMPLE
<mps>
it is enabled , CONFIG_FB_SIMPLE=y
<mps>
but, # CONFIG_SYSFB_SIMPLEFB is not set
<j_ey>
thats ok
<mps>
# CONFIG_DRM_SIMPLEDRM is not set
<j_ey>
also fine
<mps>
j_ey: thanks again, I have now to go
darkapex3 is now known as darkapex
bgb has joined #asahi
bgb has quit [Ping timeout: 480 seconds]
leo60228 has quit [Ping timeout: 480 seconds]
leo60228 has joined #asahi
<andorinhariver[m]>
By the way, I'd just like to know
<andorinhariver[m]>
Will an installer for Asahi be out by the end of the year? I don't think there's a specific timeline, but I'd like to have a rough idea of when everything should be ready if that's possible
austriancoder_ has quit []
austriancoder has joined #asahi
<RealityVoid>
@mps, did you build the kernel yourself?
<RealityVoid>
I built it but not a whole lot happens when I load it.
<RealityVoid>
There was some mention earlier that SW:Linux is horribly out of date.
<mps>
RealityVoid: yes, I built it from 5.16-rc1 tree
<mps>
according to some people here it should boot at least. later I will try to add patches
<j_ey>
you dont need any patches for it to boot
<j_ey>
probably just a config issue (so paste that later!)
<mps>
good to hear
<mps>
j_ey: ok, I will post my config when I come back to home
<mps>
or someone who have it tested could post config
<RealityVoid>
Ok, I'l retrace my steps here and paste links to all I have, both config and the result.
<marcan>
the master branch doesn't have any particular significance in that repo
<marcan>
(yet, I guess I should do something with it?)
<RealityVoid>
I mean.. at least point in the guide to build something else? :)
<marcan>
we did say that guide was horribly out of date
<RealityVoid>
I can make a PR with th echanges.
<marcan>
:p
<marcan>
it's a wiki, you can just edit it
<RealityVoid>
But first to get it running. :))
<RealityVoid>
Oh, cool. No PR cecessary? :)) Did not know this about git wikis.
<marcan>
if the docs are horribly out of date it's because nobody who stumbled through the pain of lack of docs bothered to update/write some ;)
<marcan>
it has public write access enabled
<RealityVoid>
Yes, don't get me wrong, I don't want to sound ungrateful .\
<RealityVoid>
I will try updating it.
chamomile has joined #asahi
<RealityVoid>
The config is it still the one from the guide that we should be using? Or some other config?
<marcan>
(I honestly would do it myself, but I have a million things on my plate and this seems like a task that quite a subset of the people here could take on, so it probably makes more sense for someone to take on that task :))
<j_ey>
pretty sure you can get a framebuffer with just defconfig + ARCH_APPLE + FB_SIMPLE
<marcan>
the arm64 defconfig should work
<marcan>
ARCH_APPLE should be in defconfig already
<RealityVoid>
Yes, I agree. Again, really did not want to sound like complaining.
<marcan>
and I'd kinda hope FB_SIMPLE is too? :)
<j_ey>
nope
<marcan>
ah, then that one should be added then
<marcan>
RealityVoid: I'm not saying you are, just thought I'd *hint hint* a bit :)
<marcan>
speaking of, I guess I should update the installer with the post-usb-fix m1n1
<marcan>
now that we finally solved that annoying problem
<marcan>
let me do that now...
<marcan>
(maybe, this is USB, it's probably still cursed)
<RealityVoid>
Hah, you mean that I2C DDOS?
<RealityVoid>
DOS* technically.
<marcan>
yeah
<marcan>
well if SMC was trying to access it at the same time for some reason it's be a DDoS :)
<marcan>
installer updated
<marcan>
*it'd
Dcow has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
bps has quit [Ping timeout: 480 seconds]
Dcow has joined #asahi
mlq has joined #asahi
mlq_ has quit [Ping timeout: 480 seconds]
<RealityVoid>
what is the best way to enable non-interactively a config option in the kernel? I used ./scripts/config --set-val CONFIG_FB_SIMPLE y but maybe that's not proper?
<j_ey>
I think that script doesnt check dependencies?
<RealityVoid>
It does not. Any way that you can check them?
povik has joined #asahi
<j_ey>
I looked, but it doesnt seem like any are missing
<RealityVoid>
Doesn't seem to be any extra dependencies for this option, right.
<hell__>
run `make oldconfig` afterwards?
<RealityVoid>
Whelp, same result with the mainline.
<hell__>
if there's a problem with the option you've added, `make oldconfig` will complain
<marcan>
RealityVoid: # CONFIG_SYSFB_SIMPLEFB is not set
<marcan>
ah but I'm not sure if that one is required
<marcan>
it might not be
<j_ey>
it isnt
<marcan>
RealityVoid: this is where using the hypervisor with virtual-uart is useful
<marcan>
picocom --omap crlf --imap lfcrlf /dev/ttyACM1 on one terminal
<marcan>
then on another, cat ../build/m1n1.macho <(echo 'boot-args=earlycon console=ttySAC0,1500000 console=tty0 debug') ../../linux/arch/arm64/boot/dts/apple/*.dtb ../../linux/arch/arm64/boot/Image.gz >| /tmp/m1n1-linux.macho && python tools/run_guest.py /tmp/m1n1-linux.macho
<RealityVoid>
j_ey: the .dtb is the one that came out from linux. Shoul I have tried with the one from m1n1?
<marcan>
no, the one from linux is newer
<j_ey>
but you'll need to disable those few things I shoed in my patch
<marcan>
I need to get rid of the ones from m1n1 and move it to another repo or something that we keep properly up to date
<j_ey>
*showed
<RealityVoid>
CONFIG_SYSFB_SIMPLEFB - I can add this as well to the options, juuust in case.
<marcan>
j_ey: does having the extra pcie ports actually break it?
<j_ey>
RealityVoid: i dont have it, so it's not the issue
<j_ey>
marcan: yep, some kinda crash in the dart
<marcan>
but also yeah, if this is a j313 you need a DT that we don't have yet
<marcan>
so do what j_ey said
<marcan>
linux.py won't care, but the hypervisor method above will
<marcan>
(it'll reject the DT if it mismatches)
<RealityVoid>
Will update that as well.
<marcan>
(hence why I cat all DTs in there, but we just don't have the others yet, I need to merge jannau's series for that)
<j_ey>
marcan: it rejects it.. but not loudly
<marcan>
yeah, it just goes into proxy mode
<marcan>
I should add something about that
<j_ey>
mps had this issue earlier, it sound 'found device tree' and then fell through to the proxy
<j_ey>
s/sound/said/
<povik>
is it possible i ahve an Image.gz on my hands which 'gzip -d
<povik>
* 'gzip -d' decompressed but m1n1 cannot?
<povik>
s/decompressed/decompresses/
<povik>
am i bad at typing today...
X-Scale` has joined #asahi
<FireFox317>
I think we should also have a page on the wiki that lists which config options should be enabled to enable a specific feature. For example to enable the usb-c ports on the m1 air, i had to change one options from a module to being build into the kernel.
_chamomile has joined #asahi
<FireFox317>
i guess we can put that list on the SW:Linux page maybe
<povik>
seems there is one singular gzip format, so the issue will be somewhere else
X-Scale has quit [Ping timeout: 480 seconds]
<marcan>
j_ey: fixed
<marcan>
povik: it is possible in the sense that m1n1 is very particular about gzips not having trailing garbage and `gzip` isn't, but it would at least warn as far as I know
<marcan>
and it shouldn't happen
<j_ey>
marcan: awesome, will help with helping others :)
<marcan>
please do point out pain points like this
<marcan>
(repeatedly, if I don't do anything about them)
<marcan>
(I'm absent-minded about these things sometimes :p)
<j_ey>
noted
chamomile has quit [Ping timeout: 480 seconds]
<kit_ty_kate>
is there a way to install the linux kernel from macOS? (on the same machine) All the documentation i find so far seem to require some sort of usb setup with another laptop
<kit_ty_kate>
+ ALarm base, but i guess it’s kind of the same deal
<marcan>
we only really support tethered boot right now since we expect developers to be testing kernels frequently at this point
<j_ey>
if you use kettenis s branch with uboot, probably
bps has quit [Ping timeout: 480 seconds]
<marcan>
you *can* burn in a kernel into m1n1 but I would not recommend anyone do that since it's terrible for updating kernels
<marcan>
the real story will be u-boot as j_ey says, but I still need to look into coming up with some canonical config for that to recommend
<kit_ty_kate>
j_ey: that sounds like what I’m looking for indeed
<j_ey>
kit_ty_kate: you dont have another computer? doesnt need to be a mac laptop
<kit_ty_kate>
j_ey: i have, but it sounds a bit annoying to plug it every time i want to test something
<j_ey>
kit_ty_kate: if youre testing kernel stuff, it's pretty nice!
<povik>
(you can get away with kernel on an usb stick but rootfs on nvme)
<povik>
^ re: petitboot
<marcan>
kit_ty_kate: test something like... a new kernel? :)
<marcan>
there isn't much to test other than kernels at this point
<kit_ty_kate>
touché, fair enough
<FireFox317>
yeah it would be pretty cool if we can test a new kernel from the m1 itself, which i guess might be possible somehow if we use u-boot?
<marcan>
it would also be pretty slow
<marcan>
I guarantee no kernel developer likes doing self-hosted dev and rebooting their machine and dev environment every time, especially not when the alternaive is a 10 second test cycle
<marcan>
*alternative
<kettenis>
yes, with u-boot you can load the kernel from nvme or usb
<FireFox317>
no i wouldnt guess so either, but its pretty nice if i can just sit on the couch with my m1 air and hack on the kernel xd
bps has joined #asahi
<j_ey>
firefox317: buy a mini as well then :P
<FireFox317>
j_ey, fair enough, unfortunately i'm a poor student :P
<kettenis>
marcan: I'm doing self-hosted kernel devlopment all the time ;)
<sven>
I guess self-hosted development might work for modules but that would still be annoying. It’s hard to be ./runlinux.sh and wait maybe 10seconds until the new kernel is booted
<marcan>
kettenis: you poor you :p
<marcan>
and yeah
<kit_ty_kate>
marcan: thing is I’m not so much of a kernel dev (so I’d be pretty unhelpful there), but i’d be pretty excited to contribute some kind of a start of ALarm self-contained install on top of the asahi-install script
<marcan>
that will be part of the asahi installer once it's intended for end users
<kettenis>
marcan: I can live with a 40s test cycle (and that includes going through u-boot and the OpenBSD bootloader)
<marcan>
we're going to be shipping disk images with ALARM + custom repo with bleeding edge kernels and integration packages + some scaffolding to resize the filesystem on first boot, along with simpler modes for the installer so people can just say "please resize macos and make this much space for linux" and it does the rest
<marcan>
but none of that makes any sense until the kernel settles down :) (we're getting there)
<j_ey>
kettenis: what DE/WM are you using?
* sven
at least looked at the nvme code again today :D
<kettenis>
openbox as a WM
<kettenis>
no DE
<j_ey>
kettenis: you only use open* tools? :P
<kettenis>
I just run a bunch of xterms and chrome ;)
bps has quit [Ping timeout: 480 seconds]
yuyichao_ has joined #asahi
<marcan>
I just had a little idea. 1TR lets you set at least -v serial=<int> in boot-args, and they get passed to m1n1 is boot-args restriction is disabled in bputil (which we can do)
<marcan>
we could use that as a proxy flag
marvin24 has joined #asahi
<marcan>
for the "regular" installs, it would boot u-boot (probably in silent mode at that point, no fb console for m1n1)
<marcan>
but if you set -v it boots verbose and skips the payload and goes straight into proxy
<marcan>
that's easy to toggle from 1TR, just nvram boot-args=-v or boot-args=
<marcan>
as a bonus, for people who want to run macOS verbose but don't want to break u-boot, if boot-args restriction is *not* disabled in bputil for the m1n1 BP, that all gets ignored anyway
<marcan>
I wouldn't disable boot-args restriction by default since this is not password-gated and thus a backdoor
<marcan>
so people who want proxy mode would have to toggle it with bputil first (which requires auth), then set boot-args
yuyichao has quit [Ping timeout: 480 seconds]
marvin24_ has quit [Ping timeout: 480 seconds]
<kettenis>
marcan: that sounds reasonable
<j_ey>
could always just have a tiny partition with m1n1 without uboot?
<marcan>
yes, but that's another 2.5G and a separate install, plus it makes it harder to test certain things because at that point it's a separate OS identity
<marcan>
e.g. once we get SEP involved this might matter
<marcan>
it's up to people how they do this, of course
<marcan>
but it seems convenient to be able to flip an existing install to proxy mode without throwing in a whole new m1n1
<marcan>
(plus in theory we should eventually have support for setting boot-args from linux too)
<kettenis>
haven't looked into u-boot silent mode, but it does look like this can be done by flipping a config option
<marcan>
yeah, I figured there's something for that
<marcan>
since m1n1 can pass a kernel command line to u-boot (configured at installation time), we could use that to let users preconfigure u-boot a certain way at install time at least (or even via passing something through from boot-args if needed)
aleasto has quit [Quit: Konversation terminated!]
<kettenis>
currently this can be done by having a /config node in the device tree
<kettenis>
see doc/device-tree-bindings/config.txt in the u-boot tree
<kettenis>
there has been some discussion recently to turn this into a proper device tree binding and in that process the mechanism might change a bit
<kettenis>
anyway, we're talking about icing on a cake that isn't finished yet
<marcan>
yeah, it's easy enough to implement anyway
bradfier has quit [Quit: Leaving...]
bradfier has joined #asahi
<mps>
I got u-boot on screen. ask me for run 'usb start' but keyboard doesn't work
<mps>
do I need to use usv keyboard
<j_ey>
mps: you have to use an external keyboard
<mps>
heh
<mps>
huh, it doesn't detect my usb keyboard or adapter, no luck
<j_ey>
mps: did you get the kernel working?
<mps>
j_ey: no, not yet
<j_ey>
might be a good idea to do that, so that you can uboot something that works1
<mps>
sure, but I feel like I'm in new jungle and trying to understand a lot of new things
<j_ey>
exactly, so leave u-boot to the side!
<mps>
just wanted to see will it boot
<mps>
j_ey: kernel boots \o/
<j_ey>
mps: woot
<mps>
mounting root media failed, but that I expected for now
<mps>
now I know that I have to increase console fonts
<j_ey>
haha same
bps has joined #asahi
eleven has joined #asahi
<eleven>
hey everyone - I went over a wiki at github and have a question
<povik>
shoot
<eleven>
is asahi installed (as of now) in apfs volume ?
<povik>
well there must be an apfs volume involved to run linux, just to appease the apple software that is running at boot before the control is handed over to linux, as far as i know
<povik>
but then, no, linux doesnt use an apfs volume for its filesystem
<eleven>
So one can use anything for rootfs - ext4, btrfs etc ?
<povik>
yes
<eleven>
great. I was also wondering - are there any plans to remove macos whatsoever and leave only linux ? Asking because I'm fed up with macos on this machine.
<j_ey>
eleven: macOS will stay around for the firmware updates
<eleven>
j_ey: ok - fair enough.
<eleven>
Thanks for all the info. I guess these things could be added to wiki.
<povik>
feel free to add them if you want
<eleven>
I mean general plans on where the project is going. It would be great. For all those old pricks like me used to Linux.
<eleven>
povik: I can do this. But are you guys here sure that you will be answering all my questions ? One of these days you will probably shoot me.
<j_ey>
eleven: plenty of people asking questions :P
<RealityVoid>
Well, did, aaaand, it's dead. :)) Let me reset and retry loading the thing.
<j_ey>
RealityVoid: did you see anything on the screnn?
<RealityVoid>
I did some stuff before running that.
<j_ey>
I mean did you see any console messages on the m1?
<povik>
eleven: well i cant guarantee you will get answer to every question, but if you are missing something in the wiki, chances are you are not alone, so if you want to ask and then add it to the wiki, go ahead
<RealityVoid>
Well, nope seems to not do anything, the console on my machine is stuck and the display on the M1 has only the asahi logo.
<j_ey>
ok well if you reboot and can do: lower() in the hypervisor shell that would be good
<RealityVoid>
Yes, just did that and the result is the same.
<RealityVoid>
No shell response, asahi logo on framebuffer.
<RealityVoid>
I thought I broke it, but seems not to have been the case.
<povik>
eleven: you can reiterate on both the FAQ and Project Goals that asahi linux is not supposed to be a linux distribution, as people are often confused about that
<RealityVoid>
I do not, let me try to get that running.
<povik>
it is an effort to upstream changes to make linux usable on these machines, with any distribution
<eleven>
povik: how I understand it - there are pages to be created, but there should be someone to report what are the advancements of the project to the world.
<jannau>
j_ey: I think I should send the '#interrupt-cells' fix. I forgot again that I need it and was wondering why the cd321x probe failed
<RealityVoid>
Hope I didn't bork anything.
<jannau>
tested on a mac mini and 14-inch macbook pro
gladiac is now known as Guest6314
gladiac has joined #asahi
<j_ey>
jannau: oh, I thought that was in your patchset that you sent
<RealityVoid>
Where do you currently gather the patchsets?
<j_ey>
I meant the one jannau sent to the linux mailing list
<RealityVoid>
Ah.. ok.
<j_ey>
sven and marcan use the asahi linux repo for their stuff, and everything else is on peoples personal repos
<j_ey>
RealityVoid: btw you can run make [..] Image.gz
bps has quit [Ping timeout: 480 seconds]
<RealityVoid>
Ah, cool, that works.
Guest6314 has quit [Ping timeout: 480 seconds]
<RealityVoid>
Would update the guide,but this way at least it's clear for people what is the files they care about and it puts it in the root, so you don;t have to dig too far in the tree.
bps has joined #asahi
<RealityVoid>
Okkk, cool, now I have the debian installer on screen which is nice.. .but the USB ports went down when I entered the isntaller
<RealityVoid>
The keyboard is not working, as expected. But htere has to be an input method somehow, right?
<mps>
would be nice and useful if someone who knows for needed and useful patches can collect them or make some url/guide with list
<RealityVoid>
@jannau said he would like to do that. :)
<mps>
RealityVoid: does keyboard work on your booted kernel
<j_ey>
RealityVoid didnt take those patches
<j_ey>
RealityVoid: you could run the installer over picocom?
<RealityVoid>
Picocom, strangely, disconnects.
<RealityVoid>
Both USB's are down.
<j_ey>
uh, edit the dtb!
<mps>
RealityVoid: search for bootterm pkg, it can wait till device appears on machine
<RealityVoid>
I did, it's the dtb from you. :)
<j_ey>
RealityVoid: rerun picocom, the usb should work then
<j_ey>
RealityVoid: also reboot and swap the two console= things that you have in boot-args
<RealityVoid>
Hmm, I thought that I did the same stupid thing with the dir..
<RealityVoid>
but it does not seem to be the case.
<RealityVoid>
Here's an... uhhh.. interesting observation. If I inverrt the consoles in the aruguments, the background of the debian installer turns black. Huh.
<j_ey>
RealityVoid: you should be able to do use picocom as input now
<RealityVoid>
Yes, but it's not working. there has to be something stupid I did. When I had it under the hypervisor it worked at that point, no sweat.
<j_ey>
oh
<RealityVoid>
So then how did I bork it this time, I wonder.
<j_ey>
thst only works under the hypervisor
<RealityVoid>
Ah....
<RealityVoid>
:))
<mps>
jannau: nice
<RealityVoid>
Ok. I was trying to load the image directly.
<sven>
... and it's just 40 patches we still have to upstream
<RealityVoid>
Well, seems to work now. :)
<RealityVoid>
Under hypervisor.
<sven>
jannau: "Does not verify since the apple,dwc3 binding doesn't allow ports." huh... that's weird
<jannau>
sven: I guess 1/2f of them are already sent but the t6000 support misses patches
<kettenis>
listing (some) of the compatibles that are "in-flight"
<jannau>
sven: binding refs snps,dwc3.yaml and usb-drd.yaml and neither allows ports
<RealityVoid>
I am a bit confused by this shell over picom since I do see the menu in the shell on my pc but it is nor reflected in the display screen
<sven>
jannau: uh, that's not true
<sven>
snps,dwc3 should allow it
<sven>
let me check again
<sven>
i know that at least some rockchip devicetree has a port under dwc3
<j_ey>
RealityVoid: yes it's not mirrored like that
<jannau>
sven: arch/arm64/boot/dts/rockchip/rk3399.dtsi has a port in related display port node, that's the only match I see with 'git grep -A15 snps,dwc3'
<sven>
hrm... maybe it was somewhere else. but i'm pretty sure ports are allowed there because that's how the role-switch infrastructure works
d0p1 has joined #asahi
<sven>
hrm, can't find it anymore now ofc :D
<sven>
jannau: try to get rid of the address/size-cells stuff and the @0 in the usb node
<sven>
iirc i didn't have that in my dt that passed validation
<jannau>
yes, that fixes the complaints
<sven>
:)
jbowen has quit [Ping timeout: 480 seconds]
jbowen has joined #asahi
<jannau>
fixups pushed
<sven>
i think you could at least send the #interrupt-cells patch already
<sven>
and maybe even one to add the i2c nodes
jbowen has quit []
<jannau>
yeah, I guess we could send a patch which adds all 4 i2c nodes without devices
<sven>
yup
<sven>
i think you could even add the cd321x nodes without the connection to the usb nodes
leah has quit [Quit: WeeChat 3.3]
bps has quit [Ping timeout: 480 seconds]
<RealityVoid>
kettenis: maybe add that to the index else it will be undiscoverable