<amw>
Refreshed linux/m1n1 from git and having trouble with .dtb:
<roxfan>
m.arcan is probably asleep, it's 9 AM in Japan
<amw>
New linux dtb - arch/arm64/boot/dts/apple/apple-j274.dtb - gives FDT: DT CPU 1 MPIDR mismatch: 0x1 != 0x0
<modwizcode>
amw: if you're using qemu still you cannot use the latest versions of anything
<modwizcode>
I have local patches that get the latest stuff to boot by hacking away a lot of new stuff, but until I get the SMP bringup done it's going to be incompatible
<modwizcode>
The SMP bringup wouldn't be so terribly hard but I have to create a new blob of ADT with the right nodes
<amw>
modwizcode: Ok - thanks will fall back to the older linux then
<modwizcode>
You need the older m1n1 too I think, although it might work okay for now. But the device tree in m1n1 is basically the same one as in the kernel so you don't want the updated version.
<modwizcode>
You could just checkout that one file though
<amw>
I would have thought the latest .dtb would be still acceptable to the latest m1n1/proxychain/linux.py though?
brandas has quit [Quit: quit]
brandas has joined #asahi-dev
stemnic5 has joined #asahi-dev
brandas has quit [Client Quit]
stemnic has quit [Read error: Connection reset by peer]
stemnic5 is now known as stemnic
brandas has joined #asahi-dev
<modwizcode>
The dtb is processed by m1n1 itself the python side just dumps it into memory and calls a proxy function to poke it with the dynamic values from the ADT
<modwizcode>
The latest version of m1n1 expects different things to poke, and it comes with a new .dts with spots to put them.
<modwizcode>
(specifically it has more than 1 cpu definition with register properties for spin table startup in linux) that's not what you want if you want to use the single processor setup I had working
<amw>
According to linux/Documentation/devicetree/bindings/arm/cpus.yaml the address value must be 1 for arm64 v8 CPUs but they dts files have zero?
<modwizcode>
That's the dynamic part
brandas has quit [Client Quit]
<modwizcode>
iBoot supplies an apple style device tree which linux can't read, m1n1 reads that, sets up a linux compatible entry point for the secondary CPUs and then before it boots it edit's a regular dtb in memory with the correct addresses for linux to poke.
brandas has joined #asahi-dev
<modwizcode>
the QEMU I have at the moment doesn't have the iBoot entry point that m1n1 expects nor a proper apple style device tree, so m1n1 cannot set things up right when it goes to fill in the 0's so it just won't work.
<amw>
modwizcode: It's failing in m1n1 not qemu ? Or is m1n1 getting the values from qemu?
<modwizcode>
It's failing in m1n1 because qemu doesn't give it the values it needs because I've not written that code yet :)
<amw>
modwizcode: Ok - thanks
<amw>
I think I understand - the fact it didn't even get to load linux was confusing me
<amw>
So I should fall back to the old m1n1 and linux for the moment
<amw>
I mean for qemu booting - need to update the wiki too I guess.
thestr4ng3r has quit [Read error: Connection reset by peer]
thestr4ng3r has joined #asahi-dev
PhilippvK has quit [Ping timeout: 258 seconds]
phiologe has joined #asahi-dev
<modwizcode>
I'm fairly certain there's a small bug in irq-apple-aic.c as well, BITS_TO_LONGS is used which gives the number of longs to represent a given number of bits, but on 64bit arm a long is 8 bytes, the registers in the AIC afaik are 4 byte registers and it uses writel, which isn't write long but actually for writing a u32. My printouts from the emulation confirm it seems to only set half the bits
<amw>
My prog int main() { printf("sizeof(long)=%d\\n", sizeof(long));} gives 8 on both M1 MBA and old 64bit x86 linux
<modwizcode>
yeah linux is LLP64, int is 4, long and pointers are 8
<amw>
modwizcode: My M1 MBA is running MacOS if it wasn't obvious :-)
<modwizcode>
oh duh lmao
<davidrysk[m]>
amw: fwiw -- LLP64 is usually defined to mean int is 4, long is 4, long long is 8, pointers are 8
<davidrysk[m]>
(Windows is the odd one out here)
<modwizcode>
Yeah I put an extra L oops
<modwizcode>
I meant to say LP64
<davidrysk[m]>
ahhh it's ok :P
<davidrysk[m]>
apple supports ILP32 on aarch64 for the apple watch
<modwizcode>
weird
<davidrysk[m]>
(it's to save memory)
<modwizcode>
I'm not exactly sure how that would save memory
<davidrysk[m]>
you don't need to use 64-bit pointers
<modwizcode>
I misread lol I thought you said ILP64
<modwizcode>
Yes ILP32 would indeed save memory
<dhewg>
that's the x32 abi, right?
<dhewg>
which never really took off for linux
<modwizcode>
I'm a little surprised it didn't
<modwizcode>
probably too much effort and not enough understanding
<dhewg>
memory too cheap maybe
<modwizcode>
I don't think memory is *that* cheap
<dhewg>
maybe not overall, but the amount you'd save by using that abi
<dhewg>
and there're prolly tons of issues with software not properly supporting it
mxw39 has quit [Remote host closed the connection]
mxw39 has joined #asahi-dev
<amw>
On watches which aren't that cheap perhaps it's battery / power that's critical to limit the size of the ram
brandas has quit [Quit: quit]
brandas has joined #asahi-dev
brandas has quit [Client Quit]
brandas has joined #asahi-dev
brandas has quit [Client Quit]
brandas has joined #asahi-dev
<davidrysk[m]>
Yeah, RAM sucks power
<marcan>
modwizcode: can you paste the error somewhere?
<marcan>
re the FIQ thing, the CPU implementer is probably wrong. it needs to be apple (0x61) for the FIQ support code to trigger properly.
<marcan>
you should emulate the proper ID registers matching icestorm/firestorm
<marcan>
amw: yes, v2 is for new changes and will be rebased and rewrittenuntil submitted
VinDuv has joined #asahi-dev
<amw>
ok - v2 will have history re-written - the other is more suitable for branching/working from?
<Glanzmann>
davidrysk[m]: I aggree RAM sucks approx. 10% power. However I have the 16 GB macbook air and I never had a notebook that draw that less power.
<Glanzmann>
Example: I watched one hour video less than 1% power.
<Glanzmann>
I worked for 5 hours. less than 20% power gone.
<Glanzmann>
I did a teamviewer session in daylight for 2.5 hours. 16% power gone.
<Glanzmann>
In the car.
<marcan>
the "1h video, 1%" stat seems overly optimistic. was that from 100% to 99% or something like that? PMICs lie about the edges of the curve :)
<marcan>
just the display would eat more than that
<marcan>
5% I'd buy though
<Glanzmann>
yess it was 100% to 99%
<Glanzmann>
so it was a lie. However. I'm very happy with poiwer consumption
baryluk has joined #asahi-dev
<Glanzmann>
But my thinkpad is after 4 hours dead if I disable power management. With power management I'm dead after 5 hours. And by dead my mean the system is off.
<Glanzmann>
Also I noticed that the display appears to drain less power for the same brightness.
<Glanzmann>
And macbook is brighter than the t490.
<Glanzmann>
Also the macbook never gets hot unless I do qemu, but for zoom (my thinkpad starts burning battery - once I was done after 2,5 hours), video playback or normal work it never gets hot. While my thinkpad becomes hot.
qyousef has quit [Ping timeout: 240 seconds]
jato has joined #asahi-dev
amw has quit [Ping timeout: 258 seconds]
amw has joined #asahi-dev
amw has quit [Ping timeout: 246 seconds]
sbingner has quit [Ping timeout: 260 seconds]
sbingner has joined #asahi-dev
sbingner has quit [Ping timeout: 258 seconds]
amw has joined #asahi-dev
Axenntio has joined #asahi-dev
Axenntio has quit [Remote host closed the connection]
Axenntio has joined #asahi-dev
Axenntio has quit [Client Quit]
acelogic has joined #asahi-dev
<modwizcode>
i believe the whole trick of the M1 is their accelerators and their platform integration making using them to do something like decode a videk seemless
<modwizcode>
power is way better with hardware like that
<modwizcode>
marcan: can you specify the error in question?
<marcan>
08:21:22 < modwizcode> marcan: I tried building your upstream kernel branch and uh it doesn't build for me.
<marcan>
08:21:38 < modwizcode> error about labels being used with a declaration in a switch, I wrapped the cases with braces to fix.
amw has quit [Ping timeout: 264 seconds]
<modwizcode>
I'll get you a printout. j`ey linked a mailing list reply from the build test bot that had the same error tho
Axenntio has joined #asahi-dev
Axenntio has quit [Read error: Connection reset by peer]
Axenntio has joined #asahi-dev
Axenntio has quit [Remote host closed the connection]
Axenntio has joined #asahi-dev
Axenntio has quit [Remote host closed the connection]
acelogic has quit [Ping timeout: 272 seconds]
roxfan2 has joined #asahi-dev
roxfan has quit [Ping timeout: 265 seconds]
acelogic has joined #asahi-dev
josiahmendes[m] has quit [Quit: Idle for 30+ days]
mcnight[m] has quit [Quit: Idle for 30+ days]
mofux[m] has quit [Quit: Idle for 30+ days]
vimal has quit [Remote host closed the connection]
mofux[m] has joined #asahi-dev
<arnd>
dhewg, modwizcode: supporting extra ABIs in a distro is a pain, so almost nothing supports x32 applications, and the ones that do (gentoo, mainly) suffer from running into all the bugs that nobody else noticed
<arnd>
for arm64, there are still ilp32 patches getting ported to every kernel because there are a handful of users, but it never made it into mainline because that would have required maintaining the ABI indefinitely
<arnd>
it's a similar niche to big-endian arm64, which was merged early on, but has a similar set of users, and in restrospect we would have perhaps been better off without that as well
<arnd>
ilp32 does have a noticeable performance advantage (5% to 20% according to numbers I've seen) over both traditional 32-bit binaries and native 64-bit binaries, but a lot of the applications that do care about performance are the same ones that care about addressing lots of memory and want 64-bit anyway
<modwizcode>
Yeah that's basically what I figured. Correct me if I'm wrong but I think that x86 in contrast since x32 isn't a totally different instruction set and mode, can easily benefit in multiple ways, whereas for arm64 you already need a new build and x32 is just another build to maintain with hard to explain tradeoffs for users and limitations for developers.
<marcan>
modwizcode: ohh that one. thanks, just pushed a fix to upstream-bringup-v2
<modwizcode>
Yeah I was trying to pull it up for you again but I couldn't find it when I tried to replicate it locally, I was going to clean and rebuild at some point but it seems you didn't need it
<marcan>
I wonder why I never saw my compiler complain about that one
<modwizcode>
Yeah that's weird, maybe your CFLAGS are weird?
<modwizcode>
I think there's an extension to ignore that issue
<marcan>
I didn't set anything special...
<marcan>
gcc versions?
<marcan>
anyway, it's fixed now :)
<dhewg>
arnd: yeah, i figured. i think debian supports x32 too. and wasn't there at least an attempt to remove x32 support for linux?
<arnd>
Ah right, I forgot there was a whole debianport, I thought it was just a few packages for some reason. We tried killing it off twice, but chickened out each time because there are a couple of people that have specific applications (gcc mostly) running that way
Axenntio has joined #asahi-dev
<arnd>
I still hope we can kill it off before we assign system call number #512, which currently conflicts with x32
<marcan>
ha, does it halve gcc memory usage or so?
<arnd>
x32 uses numbers 512 through 547 for syscalls that require some compat handling
<arnd>
not quite, but it's a noticeable reduction nonetheless. I haven't done memory usage measurements, but did see up to 15% difference in performance on kernel builds
<arnd>
which would mostly come from better cache utilization
Axenntio has quit [Client Quit]
<modwizcode>
I'm surprised by now there's not like a late binding syscall number assignment.
Axenntio has joined #asahi-dev
<jix>
you can always compile to wasm if you want 32bit pointers ;)
Axenntio has quit [Client Quit]
roxfan has joined #asahi-dev
<marcan>
modwizcode: oh duh, because I'm building with !CONFIG_PM_SLEEP
<marcan>
that's why I never saw that error
<modwizcode>
LOL
<marcan>
second time that part of the code borks and I miss it for this reason... I should really enable that
<modwizcode>
I wasn't using your config because I lost it when I installed natively to do further work outside a VM
<modwizcode>
My current config is a lot bigger than i expect I'm kind of wondering where it's picking up the bloat
roxfan2 has quit [Ping timeout: 276 seconds]
<marcan>
heh :)
<marcan>
ok, off to sleep
<marcan>
let's see if I can fix my damn sleep schedule
<modwizcode>
I'm also going to have to figure out why when loading linux I time transfers to qemu at being like 0.3MB/s when testing in shell I can copy at like 0.5MB/s and both of those are slow
<modwizcode>
hah
<modwizcode>
good luck
<marcan>
one context switch per uart char?
<modwizcode>
I hope not
<modwizcode>
It should mostly be doing full fifo writes if my last effort on the fifo code was anything to go by
josiahmendes[m] has joined #asahi-dev
<marcan>
:)
<marcan>
hope so
<modwizcode>
But I haven't done the tracing yet :)
<marcan>
though I think m1n1 doesn't really use the FIFO properly for tx, though it does for RX probably
<modwizcode>
Need to implement timing traces that don't write one line per char to qemu's trace output which involves taking locks at least sometimes
<modwizcode>
Qemu doesn't implement anything for TX but that's not an issue
<modwizcode>
TX is "slow" but I think has literally always worked slower than RX
<modwizcode>
*faster than Rx
<modwizcode>
Anyway go to sleep and maybe when you wake up I'll have answers :)
Axenntio has joined #asahi-dev
Axenntio has quit [Remote host closed the connection]
VinDuv has joined #asahi-dev
sbingner has joined #asahi-dev
vimal has joined #asahi-dev
sbingner has quit [Excess Flood]
sbingner has joined #asahi-dev
dagb has quit [Remote host closed the connection]
Axenntio has joined #asahi-dev
Axenntio has quit [Client Quit]
mxw39 has quit [Read error: Connection reset by peer]
mxw39 has joined #asahi-dev
sbingner has quit [Ping timeout: 258 seconds]
sbingner has joined #asahi-dev
acelogic has quit [Ping timeout: 258 seconds]
acelogic has joined #asahi-dev
carlosn has left #asahi-dev [#asahi-dev]
vimal has quit [Remote host closed the connection]