<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]
<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)
<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]