marcan changed the topic of #asahi-dev to: Asahi Linux: porting Linux to Apple Silicon macs | General development | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-dev
brandas has joined #asahi-dev
brandas has quit [Remote host closed the connection]
brandas has joined #asahi-dev
<amw> There is only one line difference from git diff marcan/upstream-bringup marcan/upstream-bringup-v2
<modwizcode> amw: I would assume the work is still in progress.
<j`ey> amw: v1 was *just* sent to the list
<j`ey> amw: the v2 branch is for all changes from v1
<modwizcode> mmhmm
<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.
<modwizcode> Yeah use the old versions for both
brandas has quit [Quit: quit]
brandas has joined #asahi-dev
brandas has quit [Client Quit]
brandas has joined #asahi-dev
Raqbit has quit [Ping timeout: 256 seconds]
_whitelogger has joined #asahi-dev
_whitelogger has joined #asahi-dev
Raqbit has joined #asahi-dev
rwhitby has quit [Quit: ZNC - http://znc.in]
rwhitby has joined #asahi-dev
KindOne has quit [Ping timeout: 272 seconds]
KindOne has joined #asahi-dev
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?
psydruid has joined #asahi-dev
maor26 has joined #asahi-dev
Namidairo has quit [Quit: ZNC - https://znc.in]
acelogic2 has quit [Ping timeout: 256 seconds]
Namidairo has joined #asahi-dev
VinDuv has quit [Quit: Leaving.]
nufflee[m] has quit [Quit: Idle for 30+ days]
<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]
vimal has joined #asahi-dev
VinDuv has quit [Quit: Leaving.]
acelogic has quit [Ping timeout: 256 seconds]
danilonc has quit [Ping timeout: 240 seconds]
danilonc has joined #asahi-dev
acelogic has joined #asahi-dev
amw has joined #asahi-dev
amw has quit [Ping timeout: 256 seconds]
qyousef has joined #asahi-dev