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
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
m42uko has quit [Ping timeout: 258 seconds]
TomJepp has quit [Ping timeout: 260 seconds]
m42uko has joined #asahi-dev
riker77_ has joined #asahi-dev
riker77 has quit [Ping timeout: 272 seconds]
riker77_ is now known as riker77
_whitelogger has joined #asahi-dev
PhilippvK has quit [Ping timeout: 260 seconds]
phiologe has joined #asahi-dev
bisko has joined #asahi-dev
h_ro[m] has joined #asahi-dev
odmir has quit [Remote host closed the connection]
taziden has quit [Ping timeout: 272 seconds]
taziden has joined #asahi-dev
acelogic has joined #asahi-dev
VinDuv has joined #asahi-dev
mxw39 has quit [Quit: Konversation terminated!]
rwhitby has quit [Ping timeout: 264 seconds]
acelogic has quit [Ping timeout: 256 seconds]
VinDuv has quit [Quit: Leaving.]
ake has joined #asahi-dev
<sven> time to implement cdc now :)
<ar> there's now usb support in m1n1?
<sven> not yet
<sven> but soon once i'm done with this
<ar> nice
<ake> May I ask about pci? When I tried to read pci config apcie@0x690000000, I got 0xffffffff. Do I need to enable something before being able to access pci config?
<marcan> ake: yes, the PHY needs a bunch of initialization
<ake> Those tunables found in apcie node in ADT?
<ake> marcan: thank you very much.
<marcan> ake: those, and some initialization stuff. I haven't looked at it yet, but kettenis has it in u-boot
<marcan> I'm going to poke around that and USB once I wrap up the v3 comments
<sven> usb requires some clocks (clock-gates in the ADT which refers to entries in two properties of the pmgr node) to make MMIO reads/writes work and then some magic PHY pokes to allow the drd controller to come out of reset
tanmayd has joined #asahi-dev
<marcan> looking forward to uploading kernels at 40MB/s :>
<marcan> sven: you don't use IRQs, right? ideally I want the USB thing to be a polled loop, so the whole thing can run in IRQ/exception context too
<sven> I have a usb_dwc3_task() function that doesn't block (except for some while(timeout-- && read32(...) & SOME_FLAG)
<sven> it's essentially just a big state machine
<sven> you just need to call that one regularly before the host times out the transfers
<marcan> cool
<marcan> does it need to be called to NAK, or does the hardware handle that?
<marcan> (I hope the hardware handles that...)
tanmayd has quit [Remote host closed the connection]
<sven> yeah, that's done in hw
tanmayd has joined #asahi-dev
<marcan> excellent
<marcan> I'm thinking for things like CDC-ACM the host should ~never time out then, right?
<marcan> (i.e. actual data transfers)
<marcan> either way my protocol is mostly synchronous on the host->device side so it doesn't really matter
<sven> yeah, that's what I assume. during the enumeration phase it (obviously) times out rather quickly
Spectrejan[m] has quit [Quit: Idle for 30+ days]
<marcan> yeah, should be fine for mmiotrace as long as you plug it in *before* launching the guest of course
<marcan> kinda curious how macOS will react to me randomly stalling MMIO writes when my buffers are full
<marcan> we'll see I guess
<marcan> probably will just make stuff dog slow if it's the GPU, but I wonder if there are timeouts
<marcan> sven: if you're bored, we're also goingt to need spinlocks in m1n1 :>
<marcan> -t
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<sven> there's also still the frame buffer console I should fix at some point ;)
<kettenis> what's up with the framebuffer console?
<sven> not inside linux fwiw, the one in m1n1
<kettenis> ah
<kettenis> btw, I think I've sorted out the memory map issues in u-boot
<kettenis> so I'll probably push that to my u-boot repo tonight
ake has quit [Quit: Leaving]
KindOne has quit [Ping timeout: 264 seconds]
KindOne has joined #asahi-dev
tanmayd has quit [Ping timeout: 246 seconds]
tanmayd has joined #asahi-dev
acelogic has joined #asahi-dev
ake has joined #asahi-dev
arnd has quit [Changing host]
arnd has joined #asahi-dev
riker77 has quit [Ping timeout: 272 seconds]
acelogic has quit [Ping timeout: 256 seconds]
riker77 has joined #asahi-dev
acelogic has joined #asahi-dev
ake has quit [Remote host closed the connection]
ake has joined #asahi-dev
ake has quit [Remote host closed the connection]
tarzeau_ is now known as tarzeau
choozy has joined #asahi-dev
luca020400 has quit [Remote host closed the connection]
luca020400 has joined #asahi-dev
ake has joined #asahi-dev
choozy has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
acelogic has quit [Ping timeout: 245 seconds]
ake has quit [Remote host closed the connection]
ake has joined #asahi-dev
ake has quit [Remote host closed the connection]
acelogic has joined #asahi-dev
TomJepp has joined #asahi-dev
ake has joined #asahi-dev
ake has quit [Remote host closed the connection]
ake has joined #asahi-dev
ake has quit [Remote host closed the connection]
bisko has joined #asahi-dev
<kettenis> is there an easy way to grab the ADT using m1n1?
<sven> over uart? i think i just used readmem(adt_addr, adt_len)
acelogic has quit [Remote host closed the connection]
ake has joined #asahi-dev
ake has quit [Client Quit]
<marcan> yeah, pretty much
<marcan> kettenis: open("dt.bin", "wb").write(readmem(ba.devtree - ba.virt_base + ba.phys_base, ba.devtree_size))
<sven> marcan: you've just gotten very familiar with memory barriers, haven't you? i have a rather strange bug here that might be related:
<sven> so I have u32 n_events = read32(SOME_MMIO_REGISTER); if (n_events < 0) return; u32 event = read32(SOMETHING_IN_RAM);
<sven> now sometimes I see n_events > 0 but then event still has the initial value i memset it to
<sven> (the usb controller dmas to that SOMETHING_IN_RAM)
<sven> could the cpu somehow speculate its way to the read32 from RAM, read the "invalid value", then an event actually happens, then the mmio read completes and i end up with that stale event value?
<sven> adding dmb oshld fixes it, but erm, so does udelay
<marcan> sven: yes, dmb oshld is exactly what you need there
<marcan> that's a dma barrier
<marcan> you need that between mmio and dma
<marcan> same with writes and oshst
<sven> okay, great. that's what i got from the ARM ARM but i don't trust myself reading it
<marcan> look at what linux does :)
<marcan> this is the whole readl() vs readl_relaxed() thing
<sven> ah.. that would've been a good idea :D
<marcan> (which was documented in the patch arnd and I wrote)
<sven> oh, nice. i should read that
<sven> crw-rw-rw- 1 root wheel 9, 8 Mar 12 18:04 /dev/tty.usbmodemvc7855ac_dirty1 :-)
<sven> maybe i should use something else for the serial in the descriptor, heh
VinDuv has joined #asahi-dev
<kettenis> thanks; for some reason larger reads time out
<kettenis> but writing a little loop doing smaller reads did the trick
mxw39 has joined #asahi-dev
odmir has joined #asahi-dev
mxw39 has quit [Quit: Konversation terminated!]
mxw39 has joined #asahi-dev
bisko has quit [Quit: Textual IRC Client: www.textualapp.com]
<marcan> kettenis: what timeout do you get? was this with another M1 as console?
<kettenis> proxy.UartTimeout: Expected 360448 bytes, got 329929 bytes
<kettenis> using the serial thingy that bluerise created for me connected to an OpenBSD arm64 machine
<kettenis> (an odroid-n2, but I doubt that matters)
<kettenis> this is a USB serial dongle that connects to a breadboard with some resistors to connect to the m1
<kettenis> and then there is a breakout of the PD signals that goes to another OpenBSD arm64 box with a hacked kernel that sends the vendor-specific PD commands to turn on the serial ;)
<kettenis> in other words, not a particular reliable setup
tanmayd17 has joined #asahi-dev
tanmayd has quit [Ping timeout: 256 seconds]
<marcan> that's kind of odd; the read loop retries until it gets all the data, so a timeout means it got 0 bytes at some point
<marcan> perhaps data is being lost due to buffers getting full at some point?
<marcan> you can try reducing the baud rate in setup.py (p.set_baud(1500000) etc) or commenting out that code; if that fixes it then it's probably something along those lines
<marcan> unfortunately we don't have flow control, so this can happen :)
<marcan> sven's USB code should fix that
<kettenis> uploading u-boot seems to mostly work
<sven> juuuuust gotta fix something that's likely very dumb but keeps bulk xfers from working
<marcan> timeouts *reading* data would indicate the o-droid isn't keeping up; timeouts *writing* data would mean the M1 isn't keeping up, which shouldn't really happen for memory writes given it's a tight read loop (but can happen if you e.g. trip an IRQ asynchronously and it spends some time printing out info)
<marcan> I had this issue with my Glasgow UART; it got fixed increasing the on-device FIFO size (yay FPGA implementations)
<marcan> kettenis: awesome, I'll give it a shot later!
<kettenis> I have a devicetree into which a transplanted the nodes I need to enable PCIe
<kettenis> including the tunables
<kettenis> seems the tunables are not machine specific
<kettenis> but potentially model-specific
<kettenis> note that u-boot uses an 115200 serial console
<kettenis> what would be a good way to share the updated t8103.dtsi?
<kettenis> cloning a full linux kernel tree for that is a bit excessive
<kettenis> without the device tree diff you should still be able to get a prompt on serial and framebuffer
<kettenis> framebuffer is black on blueish because u-boot doesn't really support 30-bit color
<kettenis> boots grub, but the grub hits a snag loading a linux kernel
br377 has quit [Quit: WeeChat 1.4]
pg12_ has quit [Read error: Connection reset by peer]
pg12 has joined #asahi-dev
tanmayd17 has quit [Ping timeout: 246 seconds]
KindTwo has joined #asahi-dev
KindOne has quit [Ping timeout: 272 seconds]
KindTwo is now known as KindOne
mxw39 has quit [Quit: Konversation terminated!]
<kettenis> pushed a hack for that
<kettenis> with that hack loading a linux kernel and initrd seems to work
mxw39 has joined #asahi-dev
<kettenis> ok, put the device tree in the u-boot repo
<kettenis> that should be a convenient place
<jannau> kettenis: there is also dts/apple-j274.dts in m1n1
<kettenis> that one is out of date
<kettenis> so what I did to test grub is to simply dd the debian debian-10.8.0-arm64-netinst.iso to a USB stick and plug that in
<jannau> yes, it's a little annoying to update the dts in m1n1 when the one in the kernel tree is not stable
<kettenis> unavoidable at this stage of development
<kettenis> but a well-designed device tree doesn't need to change
<kettenis> and in this case the copy in the kernel tree should just be there for reference
<jannau> yes, it's not expected to change except for added devices once the initial bringup is merged
roxfan has quit [Remote host closed the connection]
roxfan has joined #asahi-dev
VinDuv has left #asahi-dev [#asahi-dev]
rwhitby has joined #asahi-dev
choozy has joined #asahi-dev