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
<jn__> nGnRnE = non-gathering, non-reordering, no early write acknowledgement
<jn__> robinp: i don't see a connection to any of these features
<jn__> (except superficially, everything mentioned is about memory access in a broad sense)
<jn__> that everything*
acelogic has joined #asahi-dev
acelogic has quit [Ping timeout: 256 seconds]
ransom has joined #asahi-dev
ransom has quit [Ping timeout: 256 seconds]
ransom has joined #asahi-dev
tiagom has joined #asahi-dev
ransom has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
modwizcode has quit [Quit: Later]
tiagom has quit [Quit: tiagom]
tiagom has joined #asahi-dev
artemist has quit [Ping timeout: 258 seconds]
artemist has joined #asahi-dev
tiagom has quit [Quit: tiagom]
artemist has quit [Read error: Connection reset by peer]
artemist has joined #asahi-dev
acelogic has joined #asahi-dev
tiago has joined #asahi-dev
tiago has quit [Client Quit]
tiagom has joined #asahi-dev
tiagom has quit [Quit: leaving]
ransom has joined #asahi-dev
ransom has quit [Client Quit]
tiagom has joined #asahi-dev
tiagom has quit [Client Quit]
tiagom has joined #asahi-dev
tiagom has quit [Client Quit]
tiagom has joined #asahi-dev
r3n has quit [Ping timeout: 264 seconds]
tiagom has quit [Quit: leaving]
tiagom has joined #asahi-dev
_whitelogger has joined #asahi-dev
tiagom has quit [Quit: leaving]
n40455 has joined #asahi-dev
n40455 has left #asahi-dev [#asahi-dev]
acelogic has quit [Ping timeout: 256 seconds]
VinDuv has joined #asahi-dev
acelogic has joined #asahi-dev
m1kr0[m] has joined #asahi-dev
VinDuv has quit [Quit: Leaving.]
acelogic has quit [Read error: Connection reset by peer]
acelogic has joined #asahi-dev
acelogic has quit [Remote host closed the connection]
acelogic has joined #asahi-dev
volpe has joined #asahi-dev
bostjan has joined #asahi-dev
acelogic has quit [Remote host closed the connection]
acelogic has joined #asahi-dev
volpe_ has joined #asahi-dev
fsc has joined #asahi-dev
mogery has joined #asahi-dev
_jannau_ has joined #asahi-dev
wiloon has joined #asahi-dev
mogeryy has joined #asahi-dev
fsc_ has joined #asahi-dev
fsc has quit [Ping timeout: 256 seconds]
mogery has quit [Ping timeout: 256 seconds]
Esmil has quit [Ping timeout: 256 seconds]
Esmil has joined #asahi-dev
Axenntio has joined #asahi-dev
r1fl has joined #asahi-dev
DrWhax has quit [Ping timeout: 240 seconds]
yeoj has quit [Ping timeout: 240 seconds]
yeoj has joined #asahi-dev
vijfhoek has joined #asahi-dev
DrWhax has joined #asahi-dev
acelogic has quit [Ping timeout: 264 seconds]
Axenntio has quit [Ping timeout: 272 seconds]
thresh has joined #asahi-dev
taziden has quit [Ping timeout: 240 seconds]
mogeryy has quit [Read error: Connection reset by peer]
<jix> marcan: from yt: Michiel Visser​Unaligned on the last write in init?
<jix> missing a * 4 there?
taziden has joined #asahi-dev
volpe has quit [Remote host closed the connection]
volpe_ is now known as volpe
<jix> marcan: get the physical addr from the mapped one and check that?
e820 has joined #asahi-dev
e820 has quit [Client Quit]
mogeryy has joined #asahi-dev
maor26 has joined #asahi-dev
wiloon has quit [Quit: Connection closed for inactivity]
mogeryy has quit [Client Quit]
mogeryy has joined #asahi-dev
mogeryy has quit [Remote host closed the connection]
mogeryy has joined #asahi-dev
mogeryy has quit [Remote host closed the connection]
mogeryy has joined #asahi-dev
maor26 has quit [Remote host closed the connection]
maor26 has joined #asahi-dev
snalty has joined #asahi-dev
mogeryy has quit [Remote host closed the connection]
fewfewwe has joined #asahi-dev
amw2 has joined #asahi-dev
amw2 has quit [Ping timeout: 246 seconds]
vimal has joined #asahi-dev
vimal has quit [Remote host closed the connection]
vimal has joined #asahi-dev
amw2 has joined #asahi-dev
amw2 has quit [Ping timeout: 265 seconds]
<diddledan> it looks like xnu sets the MAIR value for nGnRE to a different number than Linux does
<diddledan> Linux and the ARM spec says to use 0x1 so I think Linux is spec correct. I'm not sure why the Apple Silicon might be using a different value
<diddledan> as to WFI it looks like XNU does do WFI so it's not broken entirely.. the XNU does an extra command between dsb and wfi
<j`ey> diddledan: 0x1, but in position 3
<diddledan> j`ey: aah
amw2 has joined #asahi-dev
<yrlf> so many quirks on that machine, oof
amw2 has quit [Ping timeout: 256 seconds]
<vijfhoek> kind of to be expected when a party has full control over both hardware and software
<vijfhoek> doesn't really matter if they break the spec, as long as it's documented internally
amw2 has joined #asahi-dev
<j`ey> marcan: did you fix the typo in dts?
Alex[m] has joined #asahi-dev
<jn__> bools in DT are empty properties
PdimH has joined #asahi-dev
amw2 has quit [Ping timeout: 265 seconds]
<yrlf> let's see what LKML says about the patch
<j`ey> i dont think they will be too happy with parts of it :P
<j`ey> i also think they messed up the emails
maor has joined #asahi-dev
maor26 has quit [Ping timeout: 256 seconds]
<jn__> marcan: does the kernel output have the "tty0 enabled"/"earlycon0 disabled" thing in it?
<_jannau_> marcan: samsung-uart probably works not yet. there's "samsung-uart …: could not find driver data" in the log
<jn__> oh good, simple-fb already supports 30bit pixel formats
jamadazi has joined #asahi-dev
<jn__> marcan: you might need ranges; on /chosen
<jn__> other DTs that use simple-fb have it
<j`ey> jn__: what's he trying now? im in another meeting and havent been listening
<jn__> j`ey: bringing up simple-framebuffer
<jn__> and it works!
<jn__> congrats :)
<diddledan> needs moar pingu
<jn__> pingus are on the way
<diddledan> this is way faster than I expected it to happen
<jn__> marcan: the individual device data selected by the compat strings in the samsung-tty driver are guarded by #if CPU_S3*
<diddledan> with 4 big cores and 4 little ones and the bigLITTLE concept becoming more mainstream we need the pingus to be 4 big and 4 small
<jn__> diddledan: hehe, that'd be nice
<jn__> diddledan: reminds me of the two/three big and eight small pingus on the Playstation 3
<diddledan> yeah that's the idea! :-)
<Shiz> what's poppin'
fewfewwe has quit [Quit: Connection closed]
<j`ey> Shiz: framebuffs!
<diddledan> hopefully not fuses or capacitors!
<jn__> Shiz: fiq+timer running, simplefb running, uart about to start working
<Shiz> nice
<jn__> tux on top of the framebuffer watching over all of this :)
myfreeweb has joined #asahi-dev
<myfreeweb> marcan: don't forget to remove allwinner stuff from the framebuffer
<myfreeweb> and next line allwinner-pipelines
<myfreeweb> marcan: fixed-clock
aknt has joined #asahi-dev
<jn__> ugh, sprintf(clkname, "clk_uart_baud%d", cnt); clk = clk_get(ourport->port.dev, clkname);
<jn__> (from the samsung try driver)
<jn__> does that look up the clock by global name?
<ar> someone in the youtube chat claims so >David Ryskalczyk​ e.g. clock-names = "uart", "clk_uart_baud0";
plainbits has joined #asahi-dev
<davidrysk[m]> that's me
<davidrysk[m]> I can talk here
TomJepp has joined #asahi-dev
PdimH has quit [Quit: WeeChat 2.9]
modwizcode has joined #asahi-dev
luca020400 has joined #asahi-dev
aknt has quit [Quit: Leaving]
hungryhugo has joined #asahi-dev
<diddledan> corellium claim fully working ubuntu https://twitter.com/DMConstantino/status/1351910277349056513
ransom has joined #asahi-dev
ransom has quit [Client Quit]
<_jannau_> they pushed usb support to github a couple of hours ago: https://github.com/corellium/linux-m1/commits/master
<thecake21[m]> pretty impressive they got there so fast.
<thecake21[m]> guess having tons of experience with apple socs from iphones did pay off here
<j`ey> and probably it's the same USB controller?
<thecake21[m]> gpu acceleration is still the hardest part imho. and not something you can throw together in a few days
skg has quit [Quit: 〜バイバイ〜!]
skg has joined #asahi-dev
sharpiro has joined #asahi-dev
<agraf> power management will also be a lot of fun ;)
<diddledan> should be be 200 = IRQ enable; 100 = IRQ unmask?
<diddledan> or other way about?
<diddledan> I would expect the 000xxx bytes to be TX and xxx000 to be RX
<diddledan> and I would expect them to mimic each other
<diddledan> I think RX remasks on purpose because you're expected to drain the buffer before enabling the interrupt or it'll keep firing for every received byte
<diddledan> would it be easier to reason about by using bitshifting in the code rather than defining the values using hex? that way we can be sure of the actual bits that are being set
jamadazi has quit [Ping timeout: 272 seconds]
<dhewg> quote his nick to get his attention
sharpiro has quit [Quit: Leaving]
<davidrysk[m]> marcan: cutoff at 2am?
lethalbit has joined #asahi-dev
jamadazi has joined #asahi-dev
<Stary> marcan, from stream chat: ​@marcan just FYI s3c6400 already supports a single-interrupt mode
jamadazi has quit [Client Quit]
VinDuv has joined #asahi-dev
<davidrysk[m]> marcan: when are you going to sleep? it's nearly 3am
hungryhugo has quit [Quit: Connection closed]
<marcan> shrug
<marcan> let me finish this
<dhewg> usually he mentions to go to bed, and then like two more hours
<davidrysk[m]> alright :)
Axenntio has joined #asahi-dev
alicela1n[m] has joined #asahi-dev
alicela1n[m] is now known as Alice[m]
<ar> this isn't turning into a circular thing, where printk's from irq_* stuff cause serial writes, and serial writes cause the same irq_ things to happen, right?
Axenntio has quit [Ping timeout: 272 seconds]
<yrlf> marcan: your apple_serial code is still using some S3C... macros, don't know if that is deliberate
uberushaximus has quit [Ping timeout: 256 seconds]
<modwizcode> So I've been playing around with other stuff and I was curious what compiler and linker flags m1n1 used and I'm now wondering why it's linked as a shared library before being copied out. Does it make a difference if it's linked that way vs as an executable if you're just copying out the mach-o that's been constructed in the guts anyway?
plainbits has quit [Quit: Bye!]
<winocm> position independent code maybe?
<sven> leftovers from a decade old codebase originally written for the wii :)
<modwizcode> I looked at a PR and aparently the way shared is (ab)used here annoys clang which partially answered that question. But I realized there's other weirdness like I'm pretty sure it should be linked with -nostdlib or at least -nostartfiles theoretically. The invocations for doing non-hosted stuff are always like a random smattering of options because I feel like they just get copied forever.
<modwizcode> Yeah
<sven> for some reason the linker has -shared and -pie
<jix> the only difference when removing -shared is that some relocation data doesn't end up in the elf (and in turn the macho) ... but I'm pretty sure that isn't used anyway?
<modwizcode> Probably also because the most documentation you get is other projects with a bunch of those flags/the individual flag documentation which is very unclear about what things actually do. Like -pie is defined as something like "enables position independent executable" or something.
<modwizcode> Which doesn't tell you how that differs from -fpic, nor is the difference between -fPIE and -pie explained (I think I'm remembering the flag names right)
<roxfan> -fpie, -fpic, -pie, -fPIC, -fPIE, -shared, ...
<modwizcode> yep
<modwizcode> I'm pedantic about these things and I have not figured out what the big flags are. the docs say large mode but wtf does that mean
<modwizcode> I assume maybe using larger offsets but I don't see why I have to tell it to do that???
<jannau> marcan: apple-uart uses 1<<5 for UTRSTAT_TX, 1<<8 is called AUTOBAUD
fsc_ has quit [Quit: leaving]
TehLink has joined #asahi-dev
TheLink has quit [Ping timeout: 240 seconds]
TehLink is now known as TheLink
<yrlf> jix: what difference are you getting when removing the shared? for my GCC toolchain removing -shared literally has no effect when -pie also exists
<jix> yrlf: ah I partially failed at looking at the diff... I do get a difference... but it's less than I thought
<modwizcode> After a bit of research I think what would probably be desired is -fpic when doing codegen and -shared when linking.
<yrlf> modwizcode: that small/large stuff is about -mcmodel, the code size model
HotSwap has joined #asahi-dev
<modwizcode> Afaik (according to one place, next route is checking the gcc/ld source) the difference is the PIE has a fixed entry point
<modwizcode> which is not what we want
<modwizcode> AT least I don't think it's what we want it might not matter
<modwizcode> But "correctness" suggest it's not
<jix> so uh that's a single relocation?
<yrlf> so e.g. in the large code model it must support offsets in the full 4GB range
<yrlf> oh yeah, that's a single NONE relocation
<modwizcode> I don't think m1n1 should be big enough (I think it's not the overall size but internal to function size or something) to matter for that
<modwizcode> wtf is a "NONE" relocation
<yrlf> I don't know why they are put in the ELF anyway, since they literally encode no information
<modwizcode> I think there's a flag on to do it anyway
<modwizcode> --no-apply-dynamic-relocs I think this might do it
<jix> yrlf: aarch64-linux-gnu-gcc (GCC) 10.2.0 GNU ld (GNU Binutils) 2.35.1
<modwizcode> but don't quote me on that
<modwizcode> "-Bsymbolic" I really want to know if this flag is there for a reason because looking it up suggests it does not
<yrlf> modwizcode: at least according to `gcc -dumpspecs`, -shared already implies -Bsymbolic for the linker call
<yrlf> so maybe the goal was to replicate what GCC would do?
<yrlf> modwizcode: apparently, NONE relocations are sometimes used to tell the linker that a section references another to not --gc-sections the other one away
<yrlf> but that doesn't apply here, since these NONE relocations don't contain a symbol
<yrlf> modwizcode: where have you seen that PIE has a fixed entry point?
<modwizcode> Uhh it was a random blog post: https://eklitzke.org/position-independent-executables it was literally like the one thing I could find that gave a specific difference. I was going to follow up by checking my own code then the compiler source but my build system was broken.
<yrlf> yeah, the hardcoded address thing is wrong
<modwizcode> damn it made sense too
<yrlf> the address in e_entry in the ELF header is relative to the base where the ELF is loaded
<modwizcode> Ahhh I didn't actually know that
<yrlf> that code needs to be dynamic relocation free, and will relocate the rest of the ELF
<yrlf> that's apply_rela()
<modwizcode> Right that part made sense to me
citruscitrus[m] has joined #asahi-dev
<yrlf> okay, that also contains some random "am I the dynamic loader" code, but apart from that
<yrlf> so it's not _that_ minimal
<modwizcode> ah of course
<yrlf> for a dynamically linked binary that is not -static-pie, the loader takes care of the relocating
<yrlf> I think I'm slipping a bit into off-topic territory now I think
<modwizcode> No I think this is relevant I was asking because I think the flags being used for m1n1 should probably be paired down (apparently the existing ones break clang) and the fix for that didn't seem... quite right.
<yrlf> so, effectively, the topic was: what linker flags are _actually_ needed for m1n1, right?
<modwizcode> Yeah
<modwizcode> And the compiler flags too
<yrlf> effectively, what m1n1 needs is -static-pie behaviour
<modwizcode> for -static-pie what does that do?
<yrlf> m1n1 needs to be relocatable, and m1n1 doesn't have a dynamic loader that loads it
<yrlf> -static-pie is actually a GCC flag, not an LD flag
<yrlf> so you have to look into the gcc -dumpspecs to see how it invokes LD then
<yrlf> for clang, there's nothing like -dumpspecs, so we have to find out ourselves what the equivalent ld.lld args are (probably the same as for GNU ld, but there might be slight quirks)
<roxfan> -v may be enough
<yrlf> yeah, verbose might be enough to get clang to tell us
<yrlf> so the LD stuff is probably not that hard to figure out
<yrlf> the question is if clang has an equivalent to -mabi=lp64
<yrlf> the -mgeneral-regs-only is also pretty much a hack, that I preemptively added since I noticed that printf writes to the q registers that aren't saved on interrupt.
<yrlf> it's pure luck that GCC doesn't use them as well
<Fanfwe> Root shell, yay !
<stemnic> \o/
VinDuv has quit [Quit: Leaving.]
<fridtjof[m]> Ah, that's what the R stands for? :D
<dottedmag> marcan: R is 01010010 so it really looks like a previous' character garbage in a shift register
bostjan has quit [Quit: Leaving]
<Ristovski> good stream, very productive
<jn__> unexpected problems have been my experience with linux porting, too
<modwizcode> What was the issue in the end?
<jn__> modwizcode: the UART does interrupts weirdly
<jn__> edge-triggered, it seems
<modwizcode> right but I was trying to figure out the specific
<vijfhoek> apple has weird hardware, part 231
<modwizcode> I thought the interrupt controller was level triggered?
<jn__> modwizcode: yeah, so that mismatch seems to create problems, if i understood it correctly
<modwizcode> Ah that's what I was getting at, maybe I'll notice it if I rewatch from beginning at some point. The bit I watched was like "oh that's it" and then was like "okay I'm done" maybe next time he'll explain XD
<marcan> the UART has an internal interrupt controller
<marcan> *that* has its sources edge-triggered
<marcan> its output is level-triggered into AIC
<marcan> the mismatch isn't the problem, the UART driver assuming level-triggered support is the problem
<davidrysk[m]> aah...
<j`ey> and AIC only supports edge level?
<jn__> thanks for clarifying
<modwizcode> ah
<diddledan> "edge level"? that seems like a paradox
<modwizcode> That's interesting
<j`ey> err you know what I meant :P
<modwizcode> "our innovative technology features edge level interrupts for greater performance" ;)
<davidrysk[m]> lmao the DMA stuff for the core is `#if 0`'d out
<davidrysk[m]> (for the uart)
<davidrysk[m]> (in xnu)
<diddledan> "and the spurving bearing feeds into the encabulator"
<davidrysk[m]> it seems that apple doesn't use interrupts though, their driver is polled-mode
<vijfhoek> interesting
<vijfhoek> possibly for a reason
<diddledan> might find the DMA stuff is blocked-out because of the unified memory architecture
<diddledan> either that or I'm speaking out of my bum :-p
snalty has quit [Quit: Leaving]
maor has quit [Ping timeout: 272 seconds]
volpe has quit [Remote host closed the connection]
Emantor has quit [Quit: ZNC - http://znc.in]
Emantor has joined #asahi-dev
<yrlf> huh, I think I have found GCC compiler flags that make it resolve ALL of the relocations at compile time
<yrlf> like, literally only NONE relocations remain
<yrlf> the code looks good though
<yrlf> haven't found a way to do it portably (i.e. clang) yet
<yrlf> probably not _really_ needed, since what we have works, but I kind of want to know
<j`ey> what flags? that sounds like it just got lucky.. because all the flags ive seen just minimise relocations
<yrlf> (the flags are -static-pie for compiling and -static -pie for linking, clang doesn't like -static-pie for compiling though)
<yrlf> yeah, most likely just got lucky
<yrlf> well, at least for the binary sizes we have here it will always work if we have -z notext
<yrlf> because then the compiler can generate relative accesses for everything
<yrlf> I think the easiest way we can force a relocation there is `int x; int * xptr = x;` globally somewhere
<yrlf> because that can't be done relatively, since its literally data
<yrlf> I was looking around trying different flags since both GCC and clang were generating relocations that I have definitely already seen GCC optimize away in my own projects
<modwizcode> I've been playing with it too and I was having things go very wrong but it looks like you're right -static-pie or the equivilient functionality is what we want here, the current flags are basically what (at least one definition of) -static-pie does
kit_ty_kate has joined #asahi-dev
<j`ey> yrlf: it could generate some code before main :P
<yrlf> yeah, what -static-pie does at the linker level is usually -static -pie --no-dynamic-linker. the latter is done here by /DISCARD/ing the .interp and .dynamic sections
<j`ey> (to set the int x thing)
<yrlf> j`ey: sounds ugly
<yrlf> wait, that's effectively what `apply_rela` is
<j`ey> yeah