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-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
mxw39 has quit [Remote host closed the connection]
mxw39 has joined #asahi
mxw39 has quit [Client Quit]
mxw39 has joined #asahi
mxw39 has quit [Quit: Konversation terminated!]
maor26 has quit [Ping timeout: 246 seconds]
mxw39 has joined #asahi
mxw39 has quit [Client Quit]
mxw39 has joined #asahi
mxw39 has quit [Remote host closed the connection]
<marcan>
basically just `cat m1n1.macho kernel dtb initramfs > m1n1-with-stuff.macho`
<marcan>
the kernel & initramfs should be compressed (because otherwise m1n1 can't tell where they end)
<marcan>
there's a mach-o trick (and iBoot loading quirk) used to make this work without touching the mach-o headers, just with a simple cat
<marcan>
let me know how it works :)
<marcan>
the initramfs is optional of course
<marcan>
kernel & dtb are required
Graypup_ has joined #asahi
<marcan>
I actually haven't tested it end to end with kmutil, just via chainload.py, but my prior experiments suggest everything should work
<marcan>
so let me know if someone does :)
klaus has joined #asahi
maor26 has joined #asahi
<Glanzmann>
ar: will try it and report back.
<ar>
Glanzmann: ?
<Glanzmann>
Wrong tab completion. This was for marcan.
delogips[m] has quit [Quit: Idle for 30+ days]
amw has quit [Ping timeout: 276 seconds]
acelogic has quit [Remote host closed the connection]
<Glanzmann>
marcan: m1n1 Debian dependencies, maybe we can mention them in the documentation: apt install gcc-aarch64-linux-gnu libc6-dev-arm64-cross device-tree-compiler imagemagick
<Glanzmann>
This is for Debian bullseye (testing)
<Glanzmann>
Are there instructions how to build the kernel and a kernel config?
<Glanzmann>
Found it.
<Glanzmann>
What initrd do you guys use the debian installer?
poppoppenguin has joined #asahi
VinDuv has quit [Quit: Leaving.]
VinDuv has joined #asahi
<marcan>
I just have a DIY thing with busybox
<Glanzmann>
I see.
<Glanzmann>
marcan: I was able to compile m1n1 and the kernel. However I had to turn off Firmware loading facility (FW_LOADER) [Y/n/?] (NEW) n
<Glanzmann>
Will try to boot it now and report back.
<jannau>
Glanzmann: I'll try if m1n1-payload.macho works with kmutil for me
<Glanzmann>
Thanks.
<marcan>
I genuinely have no idea where that EXTRA_FIRMWARE came from... it's in several of my x86 .configs, but I cannot for the life of me find how those .configs would've ended up in my asahi linux tree, looking back at shell history
<marcan>
oh well, a mystery
<Glanzmann>
That is what beta testers are for. :-)
<marcan>
macos does not use macos as the bootloader
<marcan>
macos uses macos as the *setup menu*, which is different
<marcan>
macos never boots macos
<Glanzmann>
I see.
<marcan>
when you pick something in the boot picker, it sets boot-related nvram variables and reboots
<Glanzmann>
I see.
<Glanzmann>
Than I misunderstood you last ime.
<jannau>
Glanzmann: my m1n1-payload.macho works with `kmutil configure-boot`. it displays penguins and boot messages until init switches to the serial console
<j`ey>
Glanzmann: marcan changed the default branch, so that should work now
<Glanzmann>
Perfect, got it.
<Glanzmann>
I rebuild the kernel and try again now.
<Glanzmann>
I rebuild the kernel using the right branch, create a new https://ab34.de/u/m1n1-payload.macho, but the same thing. I see the m1n1 asahi logo but no kernel boots.
<marcan>
Glanzmann: did you put back my config?
<marcan>
using the wrong tree will mess up your config
<jannau>
config looks correct now
<jannau>
I'm currently chainloading
<Glanzmann>
marcan: Yes.
<Glanzmann>
But probably I screwed something else up.
Calchan has quit [Ping timeout: 276 seconds]
macc24 has quit [Ping timeout: 276 seconds]
<jannau>
Glanzmann: your m1n1-payload boots here on a mac mini
<marcan>
weird, I can't think of what would make it not work on an Air
<marcan>
I'll try that later
<Glanzmann>
Perfect, my mini arrives soon, than I can try the mini.
<Glanzmann>
marcan: If it works for you on the air, I can also retry.
<Glanzmann>
Btw. has someone managed to build the @corelliumhq kernel. I think the repository is up and they also have now included a kernel config.
<jannau>
Glanzmann: yes, I booted a self-built cerellium kernel last week with arch linux arm root fs
<Glanzmann>
jannau: Any idea why the init ramdisk from your paste does not show? Did I forget to enable a driver?
<Glanzmann>
jannau: Wow, do you have the instructions anywhere?
<Glanzmann>
jannau: Few days ago I put the corelliumhq stuff on my NVMe (including the ubuntu raspberry image) but I normally use debian. So probably I'll try to deb bootstrap the kernel.
<Glanzmann>
Has someone also made a asahi kernel tree with the corelliumhq drivers?
<jannau>
Glanzmann: there's more output on the framebuffer console it's missing from the serial output due to missing "console=tyySAC0,1500000". init seems to simply exit
<Glanzmann>
I see.
<jannau>
for the corellium kernel build. I extracted the config via ./scripts/extract-ikconfig in the kernel, slimmed it down and built it
<jannau>
that gives you kernel Image and device tree to use with their preloader-m1
<Glanzmann>
I see
<jannau>
preloader-m1 produces a linux.macho which is equivalent to m1n1-payload.macho
<jannau>
it boots without initramfs so everything for mounting the root partition needs to be built in
<Glanzmann>
I see.
<jannau>
I haven't looked how the boot process with nvme works, previously the root partion was by default "/dev/sda2"
<Glanzmann>
I have the nvme boot on my m1.
<Glanzmann>
I can extract the kernel config and see how it works, but I'm currently installing macos on a second apfs volume.
<marcan>
huh. indeed it does not boot on the air
<marcan>
no serial after the kernel (m1n1 is fine)
<marcan>
well that's going to require some debugging
<Glanzmann>
I see. strange.
<Glanzmann>
marcan: The first corelliumhq also did not boot on the air, only on the mini. Maybe a small quirk.
<marcan>
oh wait
<marcan>
FDT: unsupported fb depth 65566, not enabling
<marcan>
lol
<marcan>
but no serial is weird too
<marcan>
ohh right that's the "retina" flag
<Glanzmann>
I see.
<jannau>
I would expect that every arm64 rootfs works with their kernel. kernel modules have to copied to the rootfs
<Glanzmann>
Yep.
klaus has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<marcan>
Glanzmann: my kernel boots and gives serial on the mini
<marcan>
er, on the air
<marcan>
maybe the lack of framebuffer broke something
<Glanzmann>
can you upload to me, than I'll try on my device. https://ab34.de/u
<Glanzmann>
marcan: You boot without framebuffer?
<marcan>
the framebuffer was broken because m1n1 was getting confused by the retina flag
<marcan>
I just fixed that, pushing now
<Glanzmann>
Okay, than I'll retry with that.
<marcan>
what I don't understand is why your build did not give me serial on the air anyway, while it did on the mini
<Glanzmann>
No idea. Strange.
<Glanzmann>
marcan: Got the change and recompiled, have to wait an hour until macos is reinstalled.
<marcan>
wait why are you reinstalling macos?
<marcan>
?!
<jannau>
second macos install
<marcan>
but you don't have to reinstall every time?
<jannau>
I think it's the initial install
<marcan>
ah ok
<Glanzmann>
No, I had previously only one macos partition. Now doing the second and maybe also do a third.
<marcan>
that one is confirmed working OK as a direct install
<Glanzmann>
Perfect, I'll try it in about an hour.
<Glanzmann>
marcan: So m1n1 does compress the kernel, but the initrd is uncompressed by the kernel, right? Like on x86?
<jannau>
yes
<marcan>
m1n1 uncompresses the initrd because it doesn't know it's an initrd until it uncompresses it
<marcan>
it's an artifact of the `cat` solution
<Glanzmann>
hrhr.
<marcan>
but who cares who uncompresses it, it has to happen anyway
<Glanzmann>
Oh I see. So m1n1 lookas at the kernel head, determines the size, than uncompresses it notices it is an initrd and put it compressed in the RAM and batches some addresses for the kernel to find it.
<jannau>
in the linux.py loader case the initramfs is uncompressed by the kernel
<marcan>
yes, but not in payload mode
<Glanzmann>
I see.
<marcan>
in payload mode it has no idea where files start and end, so for compressed files it just uncompresses until it gets to the end, only then can it start parsing the next file
<marcan>
that's why I had to patch tinf/minlzma to support that
<jannau>
the kernel supports more decompression algorithms than m1n1
<Glanzmann>
Yeah, but I was thinking maybe my initramfs does not work because m1n1 does not have the compression algorithm. But it is probably only gzip, but I'm not sure if it is cpio.
klaus has joined #asahi
<marcan>
Glanzmann: I tried booting without fb (re-introducing the bug) with my kernel and it works
<marcan>
well, just chainloading
<marcan>
but unless we're hitting very specific corner cases here, I think something was weird about your kernel there
<marcan>
Glanzmann: initramfs is always cpio
<Shiz>
btw, i can easily modify that lzo implementation to be compliant again, in case we wanna have lzo support in m1n1
<Glanzmann>
marcan: Okay, I didn't know, I thought that other formats also supported, but yes, makes sense.
<marcan>
Shiz: gzip is fast now, is it worth it? :p
<Shiz>
maybe for mirroring the kernel supported format list at most then 😅
<jannau>
Shiz: lzo compressed Image is 10% larger than gzip. the increased load time over uart will be larger than gunzip time with mmu
<jannau>
zstd would be interesting compared to gzip (slightly smaller image and expected faster decompress) but xz is more than 20% smaller and still decodes fast enough
<Glanzmann>
Hmm, I rebuild m1n1, the kernel using marcans main tree; but still no framebuffer on macbook air: https://ab34.de/u/m.macho
<Glanzmann>
I see the m1n1 asahi logo, but no kernel booting up.
Chainsaw has joined #asahi
<marcan>
Glanzmann: can you try my binary?
<Glanzmann>
marcan: Your payload works.
<marcan>
can you make one without the initramfs? it takes forever to upload over serial :)
<Glanzmann>
marcan: Can you upload me your kernel and your initrd, than I rule out one after the other. https://ab34.de/u
<Glanzmann>
But building a kernel should be as simple as. git clone; copy config; run make with the crosscompiler stuff
<marcan>
you should probably "make oldconfig" too
<marcan>
don't forget to always use the ARCH= stuff with any make invocation
<marcan>
otherwise it will clobber the config
<Glanzmann>
Maybe that's it.
<Glanzmann>
I rebuild from scratch and report back.
choozy has joined #asahi
<Glanzmann>
I updaed the wiki to mention the same and rebuilding right now.
VinDuv has quit [Quit: Leaving.]
<dhewg>
that's probably where the firmware knob came from, one stream had multiple wrong invocations with that exact problem
<j`ey>
make vs make.sh
<marcan>
dhewg: but why would that get turned on even on intel
<marcan>
I can't find how that would happen
<dhewg>
maybe some ancient .config you had lying around
<dhewg>
i had that one time with some ps3 knobs
<dhewg>
(years after i stopped messing with linux on ps3)
<marcan>
dhewg: yeah, I have that in the config in my /usr/src/linux and my main linux tree I clone from, which is understandable
<marcan>
but I couldn't find how that got copied over to my asahi tree in my shell history
<marcan>
since I did a git clone --reference of the other repo, not a plain cp or anything
<marcan>
*shrug*
<dhewg>
huh well dunno, whatever, case closed :P
<dhewg>
but that and many other related sneaky issues can be "fixed" with `git clean -fdx`, which i run every now and then in any clone for that reason
<dhewg>
what's the "retina flag"?
<Glanzmann>
I think I found the issue, when I switches the branch I ended up in the wrong branch again.
<Glanzmann>
So I had not your commits in it. I'm rebuilding now and that's hopefully it.
<arnd>
marcan, dhewg: 'make oldconfig' in an empty object tree takes the defaults from /boot/config-`uname -r` rather than from the Kconfig defaults or the architecture defconfig, so cross-compiling without a .config results in a very odd configuration.
<arnd>
marcan: I don't see a patch to arch/arm64/configs/defconfig in your patch series. Can you add a patch that turns ons the minimum set of options that are needed to get a booting kernel?
<dhewg>
oh lol, how sneaky
<arnd>
that way, the instructions can just include 'make defconfig', which would be a larger kernel because it supports a few dozen other platforms, but at least it would work
<Glanzmann>
arnd: I think the instructions work almost, they just did not mention which git branch to use.
<Glanzmann>
So I did the same mistake by accident twice. When I ran: git reset --hard HEAD; git clean -f -x -d
<marcan>
arnd: ohhh is *that* what it does
<marcan>
well that explains it then
<Glanzmann>
Now it works, so my problem was that I had the wrong branch.
<Shiz>
arnd: wait what
<Shiz>
oh
<Shiz>
it does try `pwd`/.config before that, right
<Shiz>
i was wondering if i've been miscompiling my kernel for years :)
<arnd>
Shiz: yes, of course. If you have a .config, it will use it
<Glanzmann>
I always to cp /boot/config-bla .config; make oldconfig
<Shiz>
same
<arnd>
this is just if you use O=objdir with an empty or nonexisting directly
<Shiz>
well
<Shiz>
i do zcat /proc/config.gz > .conig
<Shiz>
:)
<arnd>
I just keep one objdir per machine I want to run on
<kettenis>
so my u-boot enumerates the pci bus now
<marcan>
nice!
<marcan>
kettenis: did you port the corellium pcie driver or write your own?
<kettenis>
but I fear I need to add some sort of DART (IOMMU) support before the usb controller can talk to usb devices
<marcan>
yeah, I was going to look at DART next
<marcan>
I wonder if there's an off bit we can just poke for now
<kettenis>
this is a port of the corellium driver
<marcan>
if not, I was considering just making m1n1 load identity map tables on everything
<marcan>
(for now)
<j`ey>
marcan: that would be nice, like the off bit for faults :p
<marcan>
well the fault thing is covering up problems
<marcan>
this is just not using a feature
<marcan>
different things :p
<kettenis>
yes, that was my thinking as well
<j`ey>
marcan: :-)
<marcan>
DART is required from thunderbolt
<marcan>
I refuse to go *that* far without DART
<marcan>
but until we get *there*, we don't strictly speaking need it
<marcan>
*for
<never_released>
kettenis: please use DART since the beginning
<never_released>
You can set it to bypass mode
<never_released>
but please don't
<kettenis>
for u-boot?
<never_released>
takes less time overall to build it right
<marcan>
never_released: why?
<marcan>
for a bootloader?
<never_released>
overall, it takes less time to build it right since the beginning
<never_released>
yes
<marcan>
I fail to see how building IOMMU support takes less time than flipping an off bit
<never_released>
because proper support has to come later
<never_released>
to boot from a TB drive
<never_released>
and the DART driver is small
<never_released>
it's not a big piece
<marcan>
no offense, but you guys aren't exactly doing stellar on the "build it right from the beginning" front :p
<never_released>
marcan: I'm writing Windows drivers for it, not even looking at most of the linux stuff :p
<marcan>
I intend to look at DART but I'm not going to let that block everything else because if it doesn't have to
<j`ey>
turning it off seems like a good place to start, with exploring things
<never_released>
not a good idea for something _that_ important
<marcan>
it's important for TB
raster has quit [Read error: Connection reset by peer]
<marcan>
it's nice to have for everything else
<marcan>
ffs, half the x86 world still does not IOMMUs
<never_released>
a driver is already written
<kettenis>
and the TB ports are safe for now
raster has joined #asahi
<marcan>
*use
<never_released>
and is dual-BSD 3 clause or GPLv2
<never_released>
so...
<kettenis>
they aren't even powered up as far as I can tell
<marcan>
never_released: a driver which I won't pull until I audit it to make sure nobody copied code :)
<marcan>
(as per our policy)
<never_released>
if you want to go NIH that's fine
<never_released>
just say that you want NIH
<marcan>
if corellium were open about their development policies and process I wouldn't have to NIH anything
<never_released>
you know the product
<never_released>
it's a virtualisation solution
<marcan>
I know they are reading kexts to write the linux drivers
<marcan>
that is a *fact*
<never_released>
and you do.
<marcan>
because those drivers use bit names which are *impossible* to divine and which happen to match strings on those kexts
<marcan>
yes, I will, but *I* know what I'm doing and I have a policy and I'm not hiding anything; however, I've seen endless people get it wrong, including corellium employees
<marcan>
for this approach to work you need a *lot* of confidence on the person doing it
<marcan>
and I do not have that confidence on corellium
<marcan>
and I never will if, for starters, they never *talk* to anyone
<never_released>
I can rephrase it another way: Corellium trusts you just as much as you trust them.
<marcan>
so you're absolutely welcome to upstream those drivers, and then it's upstream's problem, but I won't do it for you without an audit, because until that happens *I* can't vouch for those drivers under my own criteria
<marcan>
ffs I streamed my linux bring-up, go watch if you want to know how I work
<marcan>
let me know when corellium streams anything :)
<marcan>
or when they have a RE policy
<marcan>
or when anything :p
<marcan>
you're also welcome to look for code I wrote that infringes copyright
<marcan>
because I can point at OSS code written by corellium employees that blatantly infringes copyright :-)
<marcan>
(but I won't publicly, but it's there)
<Glanzmann>
marcan: That was the twitter post ... so it was about corelliumhq, because in the twitter post you said it is not. :-)
<marcan>
Glanzmann: it wasn't about their kernel
<Glanzmann>
I see.
<marcan>
and it wasn't about corellium *at the time that code was written*
<marcan>
however, that person happens to now be a corellium employee :)
<Glanzmann>
I see.
<Glanzmann>
marcan: So you probably say, we can't submit the corelliumhq drivers as is upstream.
<marcan>
well, I'm saying *I* won't
<marcan>
not without first some auditing
<marcan>
this is a personal decision
<marcan>
I do not speak for upstream nor for anyone else's criteria
<marcan>
but *I* do not feel confident vouching for that code without further scrutiny
<Glanzmann>
I see.
<marcan>
I did merge two of their patches earlier (though then they had to be rewritten); those were obviously fine since they touched core linux code and couldn't have copied anything
<marcan>
obviously fine stuff is fine
<kettenis>
anayway, u-boot has zero infrastructure for IOMMU's, so bypassing the damn thing is the only real option for now
<marcan>
I'm not saying their code is tainted, I'm saying I personally would like further assurances
<Glanzmann>
Got it.
<marcan>
I have a blog post drafted about this (not specific to corellium), I should post it soon
<Glanzmann>
I look forward to read it.
<marcan>
but to give you a really bad example, and something I've avoided talking about in the past too much, that burned me:
<kettenis>
so if anybody has a clue about how to do that, hints would be appreciated
<marcan>
when I helped start the whole wii homebrew thing, we decided to work with and contribute to libogc, a homebrew SDK for the GameCube
<marcan>
only after we were invested in it, did I realize it had whole chunks of code blatantly decompiled from nintendo's games/SDK
<marcan>
including some literal chunks of assembler copied and pasted verbatim
<marcan>
by then we were too invested in that thing to do anything about it
<marcan>
and I've hated it ever since
<marcan>
I had to stop the person responsible from continuing that path for the new wii drivers
<marcan>
so most of that stuff is clean
<Glanzmann>
I see.
<marcan>
but most importantly, the GPU drivers, and a bunch of the other GameCube era drivers, are blatant decompiles
<marcan>
I do *not* want to go through that shit again
<marcan>
*especially* not with Apple, and *especially* not with the kernel
<Glanzmann>
Got it.
<marcan>
sometimes it's blatant like that, sometimes it's accidental
<marcan>
sometimes it's just lack of knowledge of how copyright law works
<marcan>
but the point is, the only real way to know is either an annoying audit, which necessarily taints you too, as you have to basically read Apple's code and compare
<marcan>
or to just *trust* the person
<marcan>
and trust has to be earned
<marcan>
and Corellium, right now, have done everything but earn my trust
<marcan>
when I read vendor code, I'm building hardware documentation in my head
<marcan>
and ideally writing it out, at least as drafts, or as test code
<marcan>
and then I probe the hardware to further understand it in ways the original code doesn't make obvious
<marcan>
and *then* I use that knowledge to write my own code
<Glanzmann>
I understand the difference.
<marcan>
it results in better code, better understanding of the hardware, and avoids copyright infringement (even though it doesn't have the person-to-person barrier that textbook cleanroom approaches do)
<marcan>
(cleanroom is a legal defense, not a legal requirement)
<Glanzmann>
understood.
<marcan>
e.g. the corellium chicken bits - there's stuff in there that is not necessary
<marcan>
it wasn't even chicken bits
<marcan>
but that distinction was lost in their asm blobs
<marcan>
it was more obvious looking at Apple's code and comparing with open xnu, since the structure gave away those weren't part of the tunables section
<Glanzmann>
I remeber that. So there is some magic initialization noone knows where it is coming from and it is probably coming from some binary on macos.
<marcan>
*then* I mapped all the actual chicken bits back to documented header bits
<marcan>
and sorted and cleaned them up
<marcan>
do we have to set the same bits? sure, otherwise the CPUs explode
<marcan>
but I can confidently say none of Apple's expression remains in my code, other than somewhat-similar register names and the bits that are set (facts are not copyrightable, names are facts and so are bits that need to be flipped to make the hardware work)
<marcan>
and then I could use the register documentation knowledge to e.g. fix the wfi problem without that linux patch
<marcan>
also, some of corellium's register names were just wrong :)
<Glanzmann>
hrhr.
<marcan>
or for another example: corellium's cpustart driver sets *two* bits per core to start it, but with zero documentation as to what they do
<marcan>
I tried setting one and it worked
<marcan>
then I later found out IRQs were broken without the other one
<marcan>
so my conclusion is the other bit is some kind of systemwide "this cpu is alive" bit or similar
<marcan>
this is more information that can be gleaned from corellium's opaque "flip two magic bits with no register names" code
<Glanzmann>
Got it.
<marcan>
(in particular AIC wasn't even dispatching IRQs to its CPU aliases without the other bit, so it was clearly deeply aware of those CPUs being off)
<marcan>
(even if they were on)
<marcan>
then I already mentioned the L2C serror reporting stuff :)
<marcan>
that wasn't copied from apple, that was just something they cooked up presumably to hide address mapping errors in their port
<marcan>
but again, no docs
<marcan>
so how do we know what it does?
<marcan>
so yeah, if they spent all this time reversing the SoCs, how about they share some docs instead of piles of vendor code :)
<Glanzmann>
Yes, impossible to maintain it later on.
<modwizcode>
marcan: The AIC can report multiple reason codes due to interrupt prioritization right?
<marcan>
modwizcode: one per CPU, whatever is the highest priority
<modwizcode>
if you are handling a lower priority interrupt and you reenable interrupts do you get preempted?
<marcan>
it's kind of like a FIFO
<never_released>
AIC is _simple_
<marcan>
modwizcode: yes
<modwizcode>
I'm trying to figure out the best way to emulate it in QEMU and have encountered a few annoyances (worked around temporarily but I need to get it right now)
<marcan>
there is only one IRQ line
<never_released>
no superfluous features that can be removed imo
<marcan>
so as long as anything is pending in AIC it is active
<marcan>
(for your CPU)
<marcan>
the correct way to emulate it is: on reason register reads, find the lowest active not-masked IRQ bit with the affinity bit for your current CPU set, then return that as the reason, and set the mask bit
<modwizcode>
Question though: HW IRQ comes in, I disable IRQ mask on CPU and then am handling where I disable it again (without reading the ACK/reason register) do I get prempted again immediately? The new reason will be the same or not?
<modwizcode>
That's all I was going to do but I wanted to understand the semantics better
<marcan>
if you read the reason bit, that already masks the IRQ for you
<modwizcode>
doesn't help that using qemu's built in bitmap code is annoyingly not the answer since you need to access the bit words directly in 32bit units and it works only in longs.
<marcan>
so once you do that, you will not be preempted again unless you unmask it, or another IRQ was pending, or comes in
<modwizcode>
*reading the ack* sets the mask?
<marcan>
yes
<modwizcode>
OH
<modwizcode>
Okay I need to document that and implement that
<modwizcode>
In simplicity sometimes lies unexpected complexity :)
<modwizcode>
There's a lot of interactions that aren't obvious between the components.
<never_released>
looked at old devices
<marcan>
admittedly those docs are barebones and quite terse
<marcan>
it was more of a mental note than real docs
<never_released>
and seems that reg interface is stable since A5
<never_released>
for AIC
<never_released>
aka 2011
<modwizcode>
Yeah I think it wasn't clear that reading the reason = is acked and not that "irq is acked at some point"
<modwizcode>
I could have probably figured that out if I reread them I guess
<never_released>
modwizcode: is your code available somewhere?
<never_released>
or not yet
<modwizcode>
I still need to figure out a not terrible path for handling the per-cpu state. For now I use a terrible hack that's definitely only safe for a single processor and even then probably not safe
<modwizcode>
The real question is if this code gets called in a locked context or not which happily I can't easily figure out
<modwizcode>
It's pretty messy, I'm publishing stuff without pretty much any cleanup. I have a lot of verbose comments to remember my thoughts on various things for fixup
<modwizcode>
Some of which are quite outdated :p
<modwizcode>
Also due to licensing concerns I haven't used the register names list from M1N1 but I probably should. I'm trying to put everything I'm doing under MIT even though generally QEMU is GPLv2+, but I think M1N1 is mostly MIT
choozy has quit [Ping timeout: 260 seconds]
<modwizcode>
note that for that code to work you need to use either a patched version of m1n1 which bypasses some SMP bits that I still haven't gotten around to implementing.
<modwizcode>
or an older version
<marcan>
oh yeah, re: the corellium cpustart driver: I have no idea why they do the coresight unlock yet, also their code doesn't even document the fact that what they're doing *is* a standard coresight unlock there; the register offset is standard
<Glanzmann>
upupu
<marcan>
so: do they not *know* that (which means they're copying what apple code does without understanding it, which is a no-no in my book), or are they intentionally obfuscating their drivers to not give away too much hardware documentation because that's their business?
<marcan>
(or are they just writing bad code? :))
<marcan>
either way, I don't like it
<kettenis>
never attribute to malice...
<kettenis>
(so I'm going with option #3)
<marcan>
kettenis: I mean, my first two interactions with corellium were first dismissal, then accusations from them, so... I may have some bias here :p
poppoppenguin has quit [Ping timeout: 240 seconds]
<marcan>
one thing the Corellium CTO did *directly* claim to me was that them having won against Apple on the copyright claims in that lawsuit means their Linux code is clean... which is a complete non-sequitor and total nonsense, because the lawsuit wasn't about that, plus it was a fair use defense which depends on application, plus it doesn't mean it magically covered all code they wrote, and many other ...
<marcan>
... reasons.
<marcan>
so as you might expect I don't have a high opinion of their understanding of copyright law :)
<marcan>
*non-sequitur
<marcan>
anyway, off to dinner and sleep, and i'm taking tomorrow off - I have too much other stuff neglected over the past few weeks ;)
<modwizcode>
marcan: btw in qemu if I enable interrupt reporting sometimes I see data aborts from linux after boot, they stop once the thing is booted.
<marcan>
data aborts, like normal translation failures?
<marcan>
presumably that's normal
<marcan>
i.e. page faults
<modwizcode>
Hmm okay those might not be relevant then
<modwizcode>
there was something else though hang on
<modwizcode>
let me try to grab a copy
<modwizcode>
I don't usually boot with IRQ spew on because it's an awful mess, especially if serial console comes up
<marcan>
I mean if they were a problem linux would've complained, so presumably the fact it handled them quietly means they aren't
<modwizcode>
Yeah hopefully they're nothing. ?I thought it reported MMU stuff different though
<modwizcode>
Prefetch abort
<marcan>
that's an instruction page fault
<modwizcode>
Okay we're good then
<modwizcode>
My mistake I thought it reported translation issues with a seperate MMU tag but I must be remembering something else
Tokamak has joined #asahi
alexanderwillner has quit [Quit: Idle for 30+ days]
Jamie[m] has quit [Quit: Idle for 30+ days]
ts170[m] has quit [Quit: Idle for 30+ days]
Tokamak has quit [Ping timeout: 256 seconds]
mndza has joined #asahi
<arnd>
marcan: regarding https://github.com/AsahiLinux/docs/wiki/HW:AIC, does that mean there is no MSI support in the AIC at all? Does it just emulate it in the pci host bridge with a shared irq line for all MSIs?
<kettenis>
but the MSIs are handled by the pcie controller and translated into regular AIC interrupts by the looks of it
<kettenis>
lookslike you can have 8 MSIs per root port
<never_released>
kettenis: I hope that most of the code being BSD helps you
<never_released>
for some drivers, because they're derivatives of a GPLed driver, that wasn't possible
<arnd>
ah, so there is one MSI address per CPU in the PCIe host bridge, and presumably you could have multiple devices target each one of them
<never_released>
also please change from AAPL, to apple, for devicetrees
<never_released>
all caps is very odd
vimal has quit [Remote host closed the connection]
<never_released>
and there's precedent with full names being used: allwinner, amlogic for example
<kettenis>
to be honest, the license only really matters for future GPU code
<jix>
never_released: AAPL instead of apple was an upstream request IIRC
<never_released>
jix: it's still a not very sane one
<never_released>
pushback is needed sometimes
<never_released>
it's unlike every other arm target
<kettenis>
our driver model is different enough that copying code straight from Linux drivers usually doesn't make sense
vimal has joined #asahi
<kettenis>
arnd, it looks like you can pick one of the 32 available AIC interrupts by passing its number in the messsage
<arnd>
kettenis: right: it seems I misread, and there is only a single doorbell on for all MSIs, and a very limited number of messages
<kettenis>
and I think you have to use the AIC to route that interrupt to the appropriate CPU
<arnd>
it's probably fine as long as there is only one device connected to each port then, but it won't help when having multiple high-speed devices on thunderbolt
<jn__>
there is also precedent for AAPL (and SUNW for Sun Microsystems), from the old OpenFirmware days
<jn__>
i agree apple looks nicer, but the "precedent" argument needs to be balanced
<arnd>
kettenis: and I wonder if the MSI delivery is racy, as is often the case with custom PCIe host bridges that come with their own MSI controller: a device might send some DMA transfer and a message to tell the CPU that the DMA is done, but that DMA might still be in progress when the MSI is forwarded to AIC and gets handled in the driver
<never_released>
jn__: those aren't Arm
<never_released>
for all other Arm systems, a newer convention is used
<arnd>
never_released: I think we tend to use the stock ticker symbols in lowercase when their is one
<never_released>
here it's uppercase even...
<arnd>
while amlogic is publicly traded, "688099" does not make a good identifier through, so they went with the name of the company
<jannau>
APPL is used in the kernel for powerpc
<never_released>
and even then
<never_released>
for Intel
<never_released>
intel is used instead of intc
<arnd>
I'm fine with either symbol (aapl, AAPL or apple) when merging the patches, there is just no good answer in this case
<never_released>
(in the arm code)
<never_released>
so it's just very arbitrary anyway
<modwizcode>
AAPL is annoying because it is fairly unreadable if you try to use it in variable names. I made the cpu core defs use AAPL since I did those changes after the linux patches were posted but I think I'm going to change them back (all the identifiers I use use apple).
<kettenis>
and IBM uses both IBM and ibm
<kettenis>
there just is't enough OCD around ;)
<modwizcode>
AAPLM1CPUState :)
zopieux has quit [Ping timeout: 272 seconds]
<jix>
never_released: I agree that apple looks much nicer (but my opinion doesn't matter at all, heh) and I'm also not convinced that AAPL from ppc days should be taken as precedent for the arm stuff... I just think that discussing it here without continuing the discussion on the mailing list (where there was no pushback after the AAPL suggestion) will lead anywhere
zopieux has joined #asahi
<arnd>
I don't know why Intel started using "intel," for the x86 and mips SoCs but "altr," for the arm ones (post acquisition)
<never_released>
arnd: intel, is also used for Intel's own Arm chips
sickdelan has joined #asahi
<arnd>
never_released: which ones?
<never_released>
arnd: intel,sa1100 for example
<arnd>
ah, keembay and agilex
<never_released>
and strongarm too
<never_released>
using an all caps stock ticker unlike everyone else doesn't make so much sense
<kettenis>
mergers and acquisitions should be forbidden!
<arnd>
ah right, so it was probably started by someone else contributing dts files, not intel
<arnd>
I wonder what the original DNARD/Shark was using
<never_released>
Nvidia chips also use nvidia, instead of nada,
<never_released>
*nvda,
<never_released>
which is the stock ticker
<jn__>
never_released: using the prefix that was already associated with Apple does make some sense to me
<modwizcode>
heh I like the idea of Nvidia having "nada" as their stock ticker :p
<never_released>
jn__: it stands out compared to every other arm platform
<jn__>
whether the apple hardware in question is uses powerpc or arm based CPUs is IMHO secondary to this question
<jix>
jn__: AFAICT there is zero chance of any overlap of old PPC mac device tree stuff and new apple arm stuff, so it might be a good point to settle on something more uniform
<arnd>
the more important question is whether we want to go along with what apple use themselves, or better use something intentionally different to not have conflicting bindings, since anything they have is almost certainly incompatible
<jn__>
i (as a bystander) am ok with "apple" as the prefix, but i think the argument has to include that there's the tradition of AAPL and you're with that to follow the other tradition of using a sane prefix
sickdelan has quit [Quit: Leaving]
<jn__>
jix: agreed
Tokamak has joined #asahi
<jn__>
s/you're with that/you're breaking with that/
<arnd>
the whole purpose of the prefix is to make a namespace that will never conflict with whatever someone else does in their machines, so using "apple," would be less likely to conflict
<jannau>
I propose U+F8FF to paint this bikeshed
<arnd>
I would personally use "pasemi,", ;-)
<jix>
arnd: given that apple uses a different device tree format, I don't see the issue with a collision to what they ship for mac os, or am I missing something here?
<arnd>
jix: the risk of something actually conflicting would be extremely low, agreed
<arnd>
the only chance I can see something going wrong in practice would be if there is a portable application that can run in both Linux and MacOS and that tries to make sense of the dt
Tokamak has quit [Ping timeout: 256 seconds]
<never_released>
arnd: Apple themselves use... hx,
<never_released>
(aka H-series processor)
<never_released>
or even more bizarre in general
<never_released>
<ip block name>,<version>
<never_released>
for example aic,1
frode_0xa has quit [Ping timeout: 240 seconds]
thestr4ng3r_ has joined #asahi
thestr4ng3r has quit [Ping timeout: 276 seconds]
VinDuv has joined #asahi
hthh_ has quit [Ping timeout: 272 seconds]
hthh_ has joined #asahi
Tokamak has joined #asahi
rotbot9k has joined #asahi
<marcan>
arnd: the i2c is pasemi so...
<marcan>
that's another corellium driver that's likely getting thrown away, because I contacted the i2c-pasemi author and got docs and confirmed that it *does* support IRQs and we can add that and have it tested on the pasemi platform
<marcan>
never_released: remember what I said about talking to people? :-)
<TheJollyRoger>
Ahoy captain marcan. I heard you were designing a new cable, I'm excited to see what it will be like.
<kettenis>
marcon: can you share those docs?
<marcan>
unfortunately I can't
<marcan>
but I'm sure I can look up anything we need
<Glanzmann>
Most expensive serial port I ever bought.
<TheJollyRoger>
Oh wow.
<marcan>
that's certainly the fastest path right now :-)
<TheJollyRoger>
Using an entire computer for a cable o.O!
<marcan>
but yes I'll be cost-reducing it 10-20x or so at least
<marcan>
:p
<kettenis>
my i2c driver on u-boot is based on the pasemi linux driver but some of the additional bits that the correllium driver sets are defenitely necessary
<sven>
Glanzmann: don't make the same mistake i did and make sure to get a real superspeed usb-c cable. the charging cable delivered with the macbook air doesn't work.
<marcan>
I need to go through a round of comparing the apple hw to the pasemi doc and seeing how much they diverge
<Glanzmann>
ANd the most expensive. But I could just have gone to my soldering iron station, but after I saw marcans message in IRC I immediately ordered one.
<sven>
and now i have to wait until monday or tuesday for my serial adapter to work :)
<marcan>
whoops
<Glanzmann>
sven: I'll try the ones I have, if they don't work, I'll order another one. I already hearrd that the cable that ships with macbook air, does not work.
<marcan>
yeah no charging cable will work
<marcan>
those are all USB2.0
<kettenis>
I started out with trying to get the dwc3 usb controllers to work
<sven>
Glanzmann: okay, great :)
<kettenis>
but got stuck trying to make sense out of the i2c type-c controller chip
<Mary_>
tbh, being able to dev for a m1 on another m1 feel very comfy
<sven>
marcan: to make things more confusing: i did check on apple.com and confused their "charging cable" with their "thunerbolt charging cable" which probably would work *sigh*
<sven>
*thunderbolt
<marcan>
heh yeah :)
<marcan>
kettenis: well I've been messing with those PD controllers through the other end so...
<sven>
i should've known better with usb's history of naming things, heh
<marcan>
do you have the docs for those? those are public, the related public chip's at least
<marcan>
Mary_: nice rust bringup btw :)
<marcan>
very biribiri
macc24 has quit [Ping timeout: 258 seconds]
<Mary_>
Thanks ^^ say MISAKA
<Mary_>
Haven't done much yet on it tbh
macc24 has joined #asahi
<j`ey>
macc24: rust bringup?
<j`ey>
err, Mary_
<Mary_>
(Mostly reused part of my bootloader stuffs that I originaly made for the TX1)
<kettenis>
marcan: yes I found the TI docs
<j`ey>
Mary_: something online?
poppoppenguin has joined #asahi
<Mary_>
j`ey, I still haven't made the sources public (kind of want to at least have the mmu setup work correctly first)
<j`ey>
Mary_: so it's a bootloader for the m1?
<Mary_>
Yeah and mostly a playground thing for me to experiment some stuffs ^^
<j`ey>
Cool, I'll be interested to take a look when it's public
<eta>
Mary_: wait does your thing use m1n1 or is it standalone
<Mary_>
eta: currently chainloading with m1n1 while keeping the mmu on but I plan to be able to make it run without m1n1
<eta>
Mary_: oh right, nice
poppoppenguin has quit [Quit: Leaving]
choozy has joined #asahi
<j`ey>
Mary_: looking on your github, I see you have a global_asm with a .macro inside and are using that from inline asm!(), I was doing that before, but it felt a bit weird, I wasnt sure if it meant to work or just worked by accident
jld has quit [Ping timeout: 272 seconds]
jld has joined #asahi
mndza has quit [Ping timeout: 265 seconds]
irl25519 has joined #asahi
<TheJollyRoger>
I wonder if anyone would like me to do a branded, 3D printable cable casing for the debugging cable...?
<TheJollyRoger>
The only thing I'll need is I'll need to know precisely the diameter of the cable, the dimensions of what's going into it...
Bublik has joined #asahi
<jn__>
TheJollyRoger: what kind of cable casing would it be? the kind that you can store a rolled-up cable in?
acelogic has joined #asahi
<TheJollyRoger>
jn__: well, likely it'd just be a box, since the resin from a 3D printer is extremely fragile.
<jn__>
makes sense
<TheJollyRoger>
Yeah. I improved the debugging cables I made for android handsets, I got rid of the "glue channel" and simply started gluing the cable in place, and then made them a little slimmer and lighter.
<TheJollyRoger>
I made them so overbuilt the first time around because I didn't actually have the PCBs in my hand.
<TheJollyRoger>
*I made them really overbuilt the first time.
<TheJollyRoger>
So I made everything really thick and with generous clearances so I could file it down.
<TheJollyRoger>
Or pack material.
<marcan>
TheJollyRoger: it's not actually going to be a cable, it's going to be a board with two type C ports
<TheJollyRoger>
marcan: oh!
<TheJollyRoger>
I could design a casing for the PCB, then.
<marcan>
will work with normal cables, but I want to try to source special passthrough cables for the target side from china for a reasonable price, since that adds features
<TheJollyRoger>
Oh!
<marcan>
(I found at least one source so far but they're like $35)
<TheJollyRoger>
Yowch, and here I thought that Anker and Aukey cables were pricey.
<TheJollyRoger>
marcan: I later improved the design of the casings on my github, after Dan let me know that the fragile littel plug was in an awkward position and hanging off the end of the phone.
<TheJollyRoger>
*little plug
<TheJollyRoger>
And snapped off the PCB.
<TheJollyRoger>
So I replaced it with a female-to-female plug and since it wasn't in as much hurry as before, I could afford to wait until the boards were in my hand before I designed another.
Tokamak has quit [Ping timeout: 272 seconds]
Tokamak has joined #asahi
amw has joined #asahi
Tokamak has quit [Ping timeout: 240 seconds]
Tokamak has joined #asahi
Tokamak has quit [Ping timeout: 265 seconds]
Mrmaxmeier has quit [Remote host closed the connection]
VinDuv has quit [Quit: Leaving.]
Mrmaxmeier has joined #asahi
raster has quit [Read error: Connection reset by peer]
Tokamak has joined #asahi
irl25519 has quit [Quit: irl25519]
<arnd>
never_released, marcan: from another look at https://github.com/corellium/linux-m1/blob/master/drivers/pci/controller/pcie-apple-m1.c and the adt dump, it appears that the MSI irqchip is not physically a part of PCIe host bridge, but rather part of the AIC itself. The irqchip code in the host driver does not actually interact with any hardware registers but fakes one MSI interrupt for each AIC interrupt.
ky0ko has joined #asahi
<arnd>
handling it in the aic driver directly should be much simpler
<arnd>
but it does mean that it would ideally be part of the aic DT binding from the start
<never_released>
arnd: thinking about how much of the PCIe code really has to be there, but uh
<never_released>
depends on how much into deep sleep you want to enter
<never_released>
(because macOS so far seems to stay in an always-connected mode, never bringing down a good part of the HW)
<never_released>
I wonder if a true ACPI S3-like deep sleep state without connectivity is wanted, or if a more S0ix-like mode only is preferable