baryluk has quit [Quit: server kernel update. will be back]
awordnot has quit [Ping timeout: 246 seconds]
<tmlind>
hi all, in case anybody is wondering how to use the corellium kernel wlan patch, it gets mac from otp and there's also a custom script in their ubuntu image that's needed
<tmlind>
the kernel patch alone is not enough
maor26 has quit [Read error: Connection reset by peer]
<tmlind>
the related userspace script is wifistart, i think it was in /usr/bin
<tmlind>
it reads some proc entries and writes them to the wlan driver
acelogic has joined #asahi-dev
<Glanzmann>
tmlind: I have not looked at it, but you need a fat partition and copy the firmwar to it.
<Glanzmann>
I assume that this fat partition is mounted and the firmware for the broadcom wifi is retrieved.
maor26 has joined #asahi-dev
<Glanzmann>
For me it worked out of the box.
<Glanzmann>
But I had to do increase the partition 100MB was not enough because the firmware is 150 MB so I did a 1 GB partition, but that's it.
imobilis has quit [Quit: bye]
imobilis has joined #asahi-dev
danilonc has quit [Quit: WeeChat 1.9.1]
danilonc has joined #asahi-dev
danilonc has joined #asahi-dev
danilonc has quit [Changing host]
danilonc has quit [Client Quit]
danilonc has joined #asahi-dev
danilonc has quit [Client Quit]
danilonc has joined #asahi-dev
danilonc has quit [Client Quit]
danilonc has joined #asahi-dev
<tmlind>
Glanzmann: ok, for me the interface did not get started without the script as no mac was found
<tmlind>
also for me the ubuntu image created broken firmware symlinks with the same script
<tmlind>
the kernel .config from /proc/config.gz seems to be the ubuntu distro .config, so far no luck booting with just enableing simple-framebuffer and apple options with m1ni
danilonc has quit [Disconnected by services]
danilonc_ has joined #asahi-dev
danilonc has joined #asahi-dev
danilonc_ has quit [Client Quit]
awordnot has joined #asahi-dev
kettenis has quit [Quit: leaving]
kettenis has joined #asahi-dev
<marcan>
I don't think we can really support the corellium kernel/distro here
<marcan>
I have no idea what they're doing and whatever was just discussed sounds... quite horrible.
hir0 has quit [Quit: hir0]
VinDuv has joined #asahi-dev
<kettenis>
FWIW U-Boot is exclusively nGnRnE device mappings for devices it seems
<marcan>
that's good to know
<marcan>
so we would probably be fine for that, *except* for the double mapping potentially causing issues
<kettenis>
yes, the core might spontaniously combust if you do that
<Glanzmann>
tmlind: If you follow the guide, it works. SO basically reduce apfs container, create two new partitions, one with 16GB, one with 1 GB
<Glanzmann>
than you dd the raspberry pie image on the 16 GB one.
<Glanzmann>
on the 1 GB you copy the firmware from macos.
<Glanzmann>
Than you boot into 1 true recovery and install the kernel.
<Glanzmann>
And it works.
<marcan>
Glanzmann: I think #asahi-offtopic is probably a better place to discuss this
<Glanzmann>
Will switch channels, btw. good work on the v2 patch series today. ;-) I look forward to get it merged upstream.
<marcan>
thanks :)
<marcan>
hope I can send it tomorrow, and then if this moves forward well we should be able to increase our parallellism.
<Glanzmann>
DHL says my serial console arrives today, don't believe it becauase it is still 600km away, but we will see.
<marcan>
heh :)
<marcan>
aswesome
<marcan>
-s
<modwizcode>
So on ARM there's the VIRT timers, which at first I thought were like "if (virtualized) { return VIRT_TIMER_REG; } else { return PHYS_TIMER_REG; }" but that's not at all how that seems to work?
<kettenis>
the package Bluerise sent me arrived today so I hope to have some sort of serial console tonight
<marcan>
modwizcode: it's.... complicated.
<marcan>
there are 4 timers.
<Glanzmann>
marcan: Perfect. Btw. I read some things on IRC or you said it, That some of the I/O devices is directly connected to the memory bus without PCIe inbetween, is that true or did I misunderstand something?
<modwizcode>
It seems like they can work that way if you have a specific enhanced virtualization flag (which I expect everything has), but it doesn't seem that's how they're intended to be used? Or rather they don't redirect.
<modwizcode>
But like from what I can tell if you read phys you either get a trap (without extension) or virt (maybe?) (with extension?)
<marcan>
you're probably thinking of my comments about how corellium faked a PCIe bus instead of adding non-PCIe support to nvme
<modwizcode>
if you read virt it shouldn't need to do that either way. But you have to intentionally be needing virt
<Glanzmann>
Exactly.
<marcan>
yeah the NVMe is not PCIe
<Glanzmann>
okay, so on x86 we have physical memory, we have the legacy io bus and we have pcie lines, so how is it on m1?
<marcan>
on x86 we have.... lots of things.
<marcan>
this isn't really about physical connections, it's about how you find devices
<Glanzmann>
I see. On x86 that would be the acpi tables?
<marcan>
on x86 there's ACPI, there's PCI(e), there's legacy ISA PnP stuff we should avoid talking about, there's semi-fixed stuff like firmware, and there's a pile of one-off junk like the local APICs
<marcan>
on arm64 there's basically devicetree or ACPI, depending on the system, and PCI(e)
<Glanzmann>
I see. And the devices are accessiable, like on x86 via the physical address space?
<marcan>
yes
<Glanzmann>
Okay. So we need to look at the device tree to find out the offsets of the devices.
<marcan>
yes
<Glanzmann>
Which you probably already did.
<marcan>
yes
<marcan>
the "problem" is that the Linux NVMe driver does not support devicetree, because this is the first device ever that has NVMe that *isn't* PCIe
<j`ey>
Glanzmann: thats how we get UART address etc
<marcan>
and the solution is to just add support for that, just like every other device type that has to support both
<modwizcode>
That's going to be a seperate patch though right?
<marcan>
e.g. USB xHCI supports both, so you can have PCI USB3.0 adapter cards, and built-in USB 3.0 support in ARM SoCs
<marcan>
and both work fine
<marcan>
yes
<Glanzmann>
I see.
<marcan>
corellium are... doing weird hacky stuff, and for some reason they decided to just make up a fake PCIe bus so the linux NVMe driver would "find" the NVMe device
<marcan>
I don't know what made them think that was a good idea
<kettenis>
btw the mini has both: PCIe xHCI and "platform" xHCI ;)
<marcan>
like they wrote a driver for a PCIe controller that doesn't exist, that just returns static data for everything
<marcan>
kettenis: I thought it was dwc3, which isn't xHCI? or is it?
<Glanzmann>
Probably the fastest thing. But now I get a little bit of idea how it works.
<modwizcode>
They probably did that the same reason I wrote hacky bindings in qemu. It worked
<kettenis>
the "host" part of dwc3 is xHCI
<arnd>
I have started patching the name pci driver to separate out some of the pci dependencies, but its not done yet
<marcan>
ah, that explains why I could've sworn I saw xHCI somewhere nested under that
<marcan>
that's very good to know
<arnd>
s/name/nvme/
<mjg59>
Years ago Intel were talking about what turned into Moorestown and wanted to know how it should expose SoC devices and Linus said "Just make it look like PCI"
<marcan>
arnd: oh cool!
<mjg59>
So we ended up with something that looked almost entirely unlike PCI
<marcan>
lol
<modwizcode>
So it's his fault :p
<mjg59>
So there's precedent here!
<marcan>
I mean if you *actually* have embedded PCI devices that's fine
<marcan>
that's how every x86 SoC works
<marcan>
like any Ryzen etc
<mjg59>
These were very much not PCI
<modwizcode>
A lot of platform devices do seem exposed as fake PCI devices. Which if it's enough faked to respond properly to the PCI driver stack then whatever it probably saves code.
<mjg59>
arch/x86/pci/intel_mid_pci.c
<marcan>
I mean they aren't "fake"
<marcan>
PCI doesn't have to be a physical bus
<marcan>
anything that looks like PCI to software is PCI for all intents and purposes
<marcan>
it might even have real PCI lines inside the SoC for all we know, though that would admittedly be silly
<arnd>
A lot of the server arm chips are like that as well: close enough to pci to almost make it work but then need some pci vendor/device id specific quirks
<modwizcode>
I meant fake as in it probably isn't actually ever sending real PCIe transactions
<modwizcode>
although for all I know it might
<marcan>
I would expect quite a few embedded PCI devices to be actually implemented as PCIe at the TLP level or so
<marcan>
because people will buy IP cores with all that crap baked in
<marcan>
so you throw away the PHY and glue it to a "real" PCI controller otherwise
<modwizcode>
yeahhhh I guess that would make sense
<marcan>
at least I bet that's common
<modwizcode>
Lots of people do that kind of thing with AXI although that's admittedly a bit different, still ends up with things like routing a memory controller to AXI only to immediately send it to another IP block to unwrap AXI.
<Glanzmann>
And thunderbolt is also PCIe so probably 4 lanes v4? And they use the same physical connector as usb-c?
<marcan>
TB is not PCIe
<arnd>
Via Wondermedia SoCs had Via network and gpu components with existing PCI drivers, and their BSP also faked a bus. Those were likely real PCI devices,just without the host portion
<marcan>
TB is a packet switched MPLS-like network
<modwizcode>
TB just tunnels PCIe TLP right?
<marcan>
you then *tunnel* PCIe over TB
<Glanzmann>
I see. wow.
<modwizcode>
I'm amazed that works at all honestly
hir0 has joined #asahi-dev
<marcan>
it often doesn't
<marcan>
just ask whitequark
<modwizcode>
Oh believe me I have
<marcan>
I fully expect to be dragging her in here once I get to those cursed controllers, because there is no way they aren't cursed
<modwizcode>
heh
<marcan>
OTOH, this might be the first TB device in existence where we actually have to deal with all the low level stuff
<marcan>
for better or for worse
<marcan>
quite possibly for better, in the long run
<modwizcode>
Is it the first TB device in existance with a non Intel derived controller?
<marcan>
but I guess we'll see
<marcan>
I think so!
<modwizcode>
I thought that all existing designs were IP licensed so this is the first I've heard
<marcan>
the chips on the board are just redrivers
<marcan>
doesn't everything else literally use intel chips?
<modwizcode>
(which is why they all have the same weird bugs!)
<modwizcode>
I think it was a licensening requirement
<marcan>
like other than redrivers is there even any non-intel TB silicon?
<modwizcode>
They wouldn't let you use non-intel silicon even if you wanted to I think
<marcan>
though I guess with USB4 that will change
<modwizcode>
Even after opening up TB3 I think there were still issues with being forced to use Intel controllers
<marcan>
the whole ecosystem is so bizarre
<marcan>
like those TB host port PCIe cards that "only work on compatible motherboards" with intel CPUs
<marcan>
except you short two pins on the connector on the side and they work anywhere
<modwizcode>
Huuuuh I was not aware of that lol
<Glanzmann>
wow.
<marcan>
yeak ask wq about that one too
<modwizcode>
"the engineers wanted to use them for something else"
<opticron>
that's just hateful
<Glanzmann>
And the docking stations for example from lenovo are also thunderbolt aren't they?
<marcan>
then there was that Sony docking station that used *light peak*
<modwizcode>
It very much reads as "marketing said we had to make this not work, but I have an AMD computer" or something lol
<marcan>
optical TB
<modwizcode>
that would have been terrible but it sounds so futuristic and cool
<modwizcode>
TB was supposed to support both still but I think only those weird corning cables exist
<marcan>
the original standard used USB connectors
<modwizcode>
I'd love to know just how hard it was to make those optical TB3 cables though
<marcan>
with the optical fibers in the plastic area
<modwizcode>
Really?
<modwizcode>
Ohhh
<modwizcode>
right
<marcan>
that is what sony used
<modwizcode>
That's cursed
<marcan>
and since I guess nobody cares by now: google actually prototyped using that format for datacenter optical ethernet at some point
<modwizcode>
Actually that will probably be the next upgrade to USB-C, a fiber but only in some cables ;)
<marcan>
I saw photos of testing racks
<marcan>
don't think it was ever deployed though
<marcan>
AIUI they used the same optical transceivers as light peak, but with ethernet over them
<hir0>
They must have been chunky cables to get the optical adapters in them
<modwizcode>
Was that before GbE fiber specs came out?
<marcan>
no, it's just that those connectors are cheap and robust, much more than typical datacenter optical stuff
<marcan>
so it would've made sense for intra-rack ethernet
<marcan>
machine to TOR switch
<modwizcode>
I mean I've handled more than a few optical fiber cablely things, they're not *that* fragile
<marcan>
but now they just use copper for that
<modwizcode>
(the datacenter ones not the plastic ones)
<marcan>
hir0: the cables are just plain fiber
<marcan>
yeah, but the light peak stuff ought to have been cheaper and more robust
<marcan>
especially wrt junk on the connectors and such
<modwizcode>
It was supposed to be plastic fiber based I think
<marcan>
yeah
<marcan>
exactly
<modwizcode>
The problem is of course power
<marcan>
well in a datacenter you don't need that
<marcan>
:)
<hir0>
So where do they do the electrical -> optical conversion then? Is it something like an SFP adapter?
<modwizcode>
well but that wasn't the point of light peak tho
<modwizcode>
It would be in the SFP yes
<marcan>
hir0: in the switch
<modwizcode>
oh?
<marcan>
and the ethernet cards
<Glanzmann>
marcan: I see. I also that makes most sense, using coper instead of fibre for short distance.
<marcan>
modwizcode: it wasn't SFP
<marcan>
that's the point
<marcan>
it was custom hardware with a pile of "USB" ports
<modwizcode>
I figured they just used an SFP with a special port
<marcan>
SFP would make it unlikely to be cost effective, plus IIRC the transceivers Intel was using were a different aspect ratio anyway
<Glanzmann>
marcan: Does that mean google uses RJ45?
<davidrysk[m]>
There’s a couple of AMD boards that use cards with Intel controllers, apparently whitequark knows how to “hotwire” those controllers to work in more places
<marcan>
IIRC it's some iPass variant
<marcan>
i.e. same connector line as external SAS
<marcan>
those are pretty popular for this kind of stuff
<modwizcode>
Everyone loves a new connector
<Glanzmann>
I see.
<tmlind>
i guess there's no device info regs populated for the fake pci devices on the interconnect related regs around the devices at all?
<modwizcode>
There's no fake pci on the M1
<marcan>
tmlind: ?
<marcan>
yeah there is nothing like that
<tmlind>
ok
<marcan>
anyway, this isn't a difficult problem to solve
<marcan>
tons of devices have pcie and dt bindings
<marcan>
there is an obvious correct solution here (broadly, minutiae aside); it doesn't really need much more discussion
<Glanzmann>
marcan: What is dt?
brandas_ has quit [Ping timeout: 264 seconds]
<marcan>
devicetree
<modwizcode>
device tree
<Glanzmann>
Ah device tree.
<Glanzmann>
Okay.
* marcan
switches to calling it of to confuse people more
<Glanzmann>
Yeah, so it bastically just another way to populate the offset for the I/O devices.
<Glanzmann>
Btw, have you already figured out with all devices are directly connected to the physical device tree (physical address space) or if there are more bridges. I heard already the keyboard is on antoher bus, what about audio and the camera?
<modwizcode>
Does reading the AIC "reason" reg mask IPIs automatically or are they masked immediately? If so do you know if it masks only IPIs from the initial IPI it's handling or all of them?
<marcan>
broadly speaking, the things the bindings have to deal with are mapping registers, registering IRQs, configuration details, power management stuff, and DMA related things, and for dt and SoC devices in general, usually power/clock controls
<marcan>
modwizcode: reading reason does
<marcan>
it masks whatever it reports
<marcan>
that's the whole pattern in AIC, reading reason gives you *one* thing and masks *that* thing
roxfan2 is now known as roxfan
<Glanzmann>
And about the IO MMU (Dart) does the m1 really need it? Can you do DMA over usb4/thunderbolt?
<modwizcode>
With IPIs it doesn't tell you the sender though does it?
<marcan>
yes
<marcan>
no
<marcan>
the sender isn't recorded anywhere
<marcan>
for starters I'm going to look into m1n1 putting all the DARTs into bypass, we'll add support for that when we get there
<marcan>
that is a blocker for TB support, I refuse to do it without an IOMMU
<marcan>
and *may* be a blocker for graphics depending on how that's implemented, security/process context wise
<marcan>
but we should have it by then anyway
<marcan>
for basic USB/internal-PCIe/NVMe bringup we don't need it
<Glanzmann>
I see it.
<marcan>
certainly nothing the bootloaders need to care about, at least at this stage
<Glanzmann>
Do you guys have any thunderbolt devices?
<marcan>
I have a test card
<marcan>
that intel devkit thing with a PCIe slot
<modwizcode>
I think the confusion is that the register in linux that's IPI_SEND you originally called FLAG_SET and IPI_ACK was FLAG_CLEAR, but in reality you write the other bit in the ACK reg, so it's not like SET/CLEAR
<Glanzmann>
I thought about buying a network card, but have not done so.
<marcan>
modwizcode: yeah, I had that wrong originally
<marcan>
that's why the linux names changed
<modwizcode>
Right
<marcan>
need to update the doc, feel free to edit it
<modwizcode>
I was going to update the doc after I verified things further with you/emulation
<modwizcode>
The other bits (besides the self bit) in the ACK register are unused then?
<marcan>
as far as I can tell, yes
<modwizcode>
or just unknown at least
<marcan>
probably unused
<marcan>
it's w1c so you can't prove they're unused :p
<marcan>
but that's a pretty sensible assumption to make
<Glanzmann>
marcan: Are you still building the custom usb cable, or do you drop it after you can just use two macs?
<marcan>
next week
<marcan>
I just had too many distractions this week, what with the v1 feedback and misc experiments
<Glanzmann>
I see.
<modwizcode>
Wish I had a Mac to work on stuff, probably for the best though. I have enough distractions
<Glanzmann>
modwizcode: If you wish, I can set mine up so that you can access it remotely.
<Glanzmann>
modwizcode: Were are you located?
<modwizcode>
I mean at the moment I think that would be premature. I have a lot on my plate. I suspect it'd be better overall to do something like testing of features that marcan implements.
<marcan>
and I should get some sleep :)
<Glanzmann>
marcan: Yes, or wait 2 more hours and stay aware.
<Glanzmann>
Have a good morning sleep.
<Glanzmann>
awake*
hir0 has quit [Quit: hir0]
leah2 has quit [Ping timeout: 260 seconds]
leah2 has joined #asahi-dev
kettenis has quit [Quit: leaving]
brandas has quit [Quit: quit]
brandas has joined #asahi-dev
VinDuv has quit [Quit: Leaving.]
amw has joined #asahi-dev
austriancoder has quit [Read error: Connection reset by peer]