ChanServ changed the topic of #asahi-dev to: Asahi Linux: porting Linux to Apple Silicon macs | Non-development talk: #asahi | General development | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-dev
* kevans91
ponders using stackable headers for the middle board in a stacked setup
<nicolas17>
marcan: just for your curiosity ^
elros has joined #asahi-dev
<elros>
Hey there, I'm unsure if this is the right place to ask, but given what's written in the contributing page, I wanted to get familiar with asahi in order to contribute by looking at the docs and helping out there. But I'm unsure on what repo exactly should I contribute. Or would it be more efficient to just look at issues on the repos under the org?
<elros>
In any case, would like to help any way I can. I am a beginner at this, however. My experience is as a web dev, mainly. I do some C programming as part of my studying efforts, on the side, but that's about as familiar as I am with things at lower levels than web...
psykose has quit [Remote host closed the connection]
psykose has joined #asahi-dev
tobhe_ has joined #asahi-dev
tobhe has quit [Ping timeout: 480 seconds]
weitcis has joined #asahi-dev
chadmed has joined #asahi-dev
i509vcb has joined #asahi-dev
<chadmed>
whats going to be the best way to do the dt schema for the smc hwmon stuff? rummaging around it looks like its probably best to write one for the whole SMC and put it under mfd
<chadmed>
but im open to suggestions
<nicolas17>
ok I'm seeing conflicting info about A17 now so nevermind
gladiac has joined #asahi-dev
nicolas17 has quit [Quit: Konversation terminated!]
rpirea_ is now known as rpirea
chadmed has quit [Remote host closed the connection]
nst has quit [Ping timeout: 480 seconds]
nst has joined #asahi-dev
cylm has quit [Ping timeout: 480 seconds]
cylm has joined #asahi-dev
hightower2 has quit [Ping timeout: 480 seconds]
cylm has quit [Ping timeout: 480 seconds]
vup2 has quit [Ping timeout: 480 seconds]
elros has joined #asahi-dev
<elros>
chadmed: Thanks a lot! But I did look at that page. The thing is I don't think I have enough knowledge to claim any of the unclaimed issues. Which is why I was kind of trying to go for docs.
<elros>
Looking at those issues I'm unsure where to start
<chadmed>
tested on j415 and j314, been meaning to get the mac mini going too but couldnt really drag that with me to hospital :)
<chadmed>
im sure there are probably issues with it though so further testing would be nice :)
cylm has joined #asahi-dev
chadmed has quit [Quit: Konversation terminated!]
cylm has quit [Ping timeout: 480 seconds]
chadmed has joined #asahi-dev
<elros>
I see... maybe I can help with that. I only have an M1 available, though. I might be able to test on an M2, but I was unable to install the fedora remix on it.
<chadmed>
it should work regardless of soc, what we need to figure out is which smc keys we are going to expose for which devices
<chadmed>
because theres like 99999 grillion keys
<chadmed>
but not all of them expose user-helpfuk information
<chadmed>
helpful*
<chadmed>
only thing im really not too sure about is all that horrid pointer voodoo in macsmc_hwmon_populate_info
<chadmed>
there just *has* to be a better way to do that
<elros>
But I'm thinking that's probably not how to do it?
as400 has quit [Remote host closed the connection]
hightower2 has joined #asahi-dev
as400 has joined #asahi-dev
<elros>
I guess the specific question is how do I do to read whatever info the hardware is printing out. In the HW:SMC page there are mentions of reading and writing, but I couldn't find out how to read and write. Nor if this is doable on a terminal emulator, for example
<_jannau__>
probably with m1n1 installed in proxy only mode in a separate partition or m1n1 installed in a macOS partition for running macOS under the HV for tracing
<j`ey>
elros: you can't do it via linux terminal (as is, I had at some point some patches to add a debugfs to the SMC stuff so you could access all the keys..)
<j`ey>
easiest way is to use m1n1 to read them (and they are some examples in the experiments/ folder in m1n1)
cylm_ has quit [Ping timeout: 480 seconds]
<elros>
Aaaah, nice to know. And sorry if my questions are basic. I really have 0 knowledge on how to work with these things. Thanks a lot everyone!
ydalton has joined #asahi-dev
<ydalton>
i have a question, where do you find the compiled dtb files? i can't seem to find them in the /boot folder. are they embedded in the kernel? uboot?
<mps>
ydalton: depends on distro kernel, i.e. how it set where to put dtb files
<_jannau__>
they are embedded in ESP/m1n1/boot.bin, location in the system is distro specific, check the update-m1n1 source and/or config
<mps>
usually /boot/dtbs-...
<_jannau__>
I think asahi alarm installs them in the module dir
<mps>
ah, interesting
<ydalton>
there's no /boot/dtbs-... folder in my installation
<ydalton>
but it could be a linux kernel if you really want it to be
<ydalton>
right?
<ydalton>
ah, i see on the wiki
<_jannau__>
yes, in that case you probably want to append boot args as well
<_jannau__>
you can also append an initrd
<ydalton>
ah i see it here
<ydalton>
can you use the chainload script to chainload m1n1 with the bootargs, dtb, linux kernel and initramfs?
<ydalton>
i figure it should work
<j`ey>
yup
* _jannau__
should prepare the initramfs hooks to copy kernel modules into a tmpfs for the live system
lena6 has quit [Read error: Connection reset by peer]
ydalton has left #asahi-dev [ERC 5.4 (IRC client for GNU Emacs 28.2)]
roxfan has joined #asahi-dev
ydalton has joined #asahi-dev
<ydalton>
hi, i was reading up on aarch64 assembly, and it said the W registers are just the 32 bit half of the 64 bit of the X registers, similar to rax and eax in x86_64 assembly. i looked at an assembly file in m1n1 and noticed it used the W registers, but i thought apple silicon does not support 32 bit arm!
<j`ey>
it supports 32bit registers still
<j`ey>
rather: aarch64 architecture includes 32-bit registers
<j`ey>
(and instructions that operatre on 32-bit quantities)
<j`ey>
but the m1 doesnt support the aarch32 ISA
nicolas17 has joined #asahi-dev
<_jannau__>
nicolas17: on one hand possible, ~10% faster but almost 10% max perf core frequency, 20% faster GPU after updating from 5 to 6 GPU cores. But I doubt apple would have talked about wider decode/execution units in the presentation if the cpu core were identical
<nicolas17>
ydalton: a hypothetical x86_64 CPU that doesn't support x86 (32-bit) instructions would still have eax, ax, and al/ah
<nicolas17>
_jannau__: guess we have to wait for the software to be out to figure out the core codenames
<nicolas17>
(iOS 17.0 RC does not include the new iPhones)
ydalton has quit [Remote host closed the connection]
chadmed has quit [Remote host closed the connection]
chadmed has joined #asahi-dev
ydalton has joined #asahi-dev
<ydalton>
i think i understand
<ydalton>
but like if you don't have instructions to use them, do they really exist?
<nicolas17>
I think you misunderstand what "64bit instructions" means :P
<_jannau__>
most aarch64 instructions can operate on x and w register (aliases)
<ydalton>
nicolas17: if i understand what it means, it's instructions that operate on 64 bit wide registers?
<_jannau__>
aarch32 has no w registers. it uses rX mnemonics since all registers are 32-bit wide
<ydalton>
yeah, i've seen those r registers before
<ydalton>
i was today years old when i realized the r registers are the w registers in aarch64
<ChaosPrincess>
in case of x86, 64 bit instructions are just 32 bit ones, but with a REX prefix in front of them, in case of arm32/aarch64, the instruction sets are quite different, and
<ydalton>
i think i get it now
<ChaosPrincess>
i'd even say 32 and 64 bit arm are different instruction sets, with 64 bit just being vaguely inspired by the 32 bit one
<ydalton>
it doesn't support arm executables
<ydalton>
but you can still use the 32 bit wide registers
<ydalton>
and arm64 32 bit code is completely different to regular arm code
<ydalton>
is my understanding correct?
<ChaosPrincess>
something like that, yes
<ydalton>
and apple silicon doesn't support the latter
<ydalton>
but you can still use the 32 bit registers
<j`ey>
the 32-bit registers are part of aarch64 too
<sven>
a bit of nitpicking: all aarch64 instructions are 32bits long, it's just that some of them operate on 32bit registers while others operate on 64bit registers
<ydalton>
yeah, i heard and saw arm64 instructions are 4 bytes wide
<j`ey>
it's not like theyre just 'leftover' or something
<ydalton>
compared to x86 with their variable length instructions
<ydalton>
y u no be simple arm/arm64
<ChaosPrincess>
id say its x86 that is the weirdo
<sven>
x86 is much much worse :D
<sven>
yeah
<ydalton>
well
<j`ey>
ydalton: it is simple!
<ydalton>
it had to hold cruft for nearly 45+ years
<sven>
yeah, which makes it much worse than aarch64 which threw away the 32bit legacy imho
<nicolas17>
fixed-length instructions are one thing letting ARM CPUs be faster
<nicolas17>
I don't think it's a *significant* difference but it's one factor
<ydalton>
well if you're not trying to decipher how long the next instruction is, when you can basically assume all instructions are 4 bytes wide, it's gonna be faster
<ChaosPrincess>
that matters surprisingly little
<sven>
it also helps that apple as an all time world-class hw team ;)
<sven>
*has
<ChaosPrincess>
a lot of hot code will run out of micro-op cache anyway
<ChaosPrincess>
sven: throwing trucks full of cash at tsmc to get the best node doesnt hurt either :P
<sven>
yup :D
<nicolas17>
ydalton: you can decode more instructions in parallel if you don't need to figure out the length of one before you can start decoding the next
<nicolas17>
but yeah I don't know to what extent instruction decoding speed affects overall speed
<ydalton>
maybe aarch64 is just built better
<ydalton>
but like if i look at x86 assembly to machine code (in hex), i can kind of guess how it all works
<ydalton>
when i look at aarch64 assembly and its machine code it looks incomprehensible
<ydalton>
also aarch32 has that weird thumb code thing
<sven>
that just sounds like you're more used to x86
<sven>
anyway, this is also pretty off topic at this point
<ydalton>
whoops
eiln has joined #asahi-dev
sefidel has quit [Remote host closed the connection]
sefidel has joined #asahi-dev
ydalton has left #asahi-dev [ERC 5.5 (IRC client for GNU Emacs 29.0.90)]
os has quit [Ping timeout: 480 seconds]
rpirea has quit [Quit: Leaving]
lynndotpy has quit [Quit: bye bye]
lynndotpy has joined #asahi-dev
eldriitch has joined #asahi-dev
jacksonchen666 has joined #asahi-dev
Guest2615 has quit [Quit: Bridge terminating on SIGTERM]
rhysmdnz has quit [Quit: Bridge terminating on SIGTERM]
Jamie has joined #asahi-dev
Jamie is now known as Guest250
rhysmdnz has joined #asahi-dev
Adilpickles has joined #asahi-dev
Adilpick1es has joined #asahi-dev
Adilpickles has quit [Ping timeout: 480 seconds]
Adilpickles has joined #asahi-dev
Adilpick1es has quit [Ping timeout: 480 seconds]
jacksonchen666 has quit [Ping timeout: 480 seconds]
le_petit_segfault has joined #asahi-dev
Adilpickles has quit [Read error: Connection reset by peer]
Adilpickles has joined #asahi-dev
Adilpickles has quit [Remote host closed the connection]
le_petit_segfault has quit [Ping timeout: 480 seconds]
hightower2 has quit [Remote host closed the connection]
hightower2 has joined #asahi-dev
maximbaz has quit [Quit: bye]
maximbaz has joined #asahi-dev
jacksonchen666 has joined #asahi-dev
eiln has quit [Quit: WeeChat 4.0.4]
eldriitch has quit [Remote host closed the connection]
elros has quit [Ping timeout: 480 seconds]
elros has joined #asahi-dev
lena6 has joined #asahi-dev
eldriitch has joined #asahi-dev
le_petit_segfault has joined #asahi-dev
le_petit_segfault has quit [Ping timeout: 480 seconds]