marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | General project discussion | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
bgb has quit [Ping timeout: 246 seconds]
<kettenis>
usb works and I can type commands using a usb keyboard and load and run the OpenBSD/arm64 UEFI bootloader
<kettenis>
need to clean up a few things before pushing the changes to my u-boot github repository
raster has quit [Quit: Gettin' stinky!]
bgb has joined #asahi
bgb has quit [Ping timeout: 258 seconds]
bgb has joined #asahi
bgb has quit [Ping timeout: 264 seconds]
bgb has joined #asahi
bgb has quit [Ping timeout: 265 seconds]
bgb has joined #asahi
bgb has quit [Ping timeout: 240 seconds]
bgb has joined #asahi
bgb has quit [Ping timeout: 256 seconds]
qyousef has quit [Ping timeout: 272 seconds]
qyousef has joined #asahi
cexpo has joined #asahi
odmir has quit [Read error: Connection reset by peer]
bjornjulander[m] has quit [Ping timeout: 240 seconds]
khronokernel[m] has quit [Ping timeout: 240 seconds]
winocm has quit [Ping timeout: 240 seconds]
gabiruh has joined #asahi
Tokamak has joined #asahi
mofux[m] has quit [Ping timeout: 268 seconds]
shadaj[m] has quit [Ping timeout: 268 seconds]
aimileus has quit [Ping timeout: 268 seconds]
numa[m] has quit [Ping timeout: 268 seconds]
crafteck[m] has quit [Ping timeout: 268 seconds]
mikewilks[m] has quit [Ping timeout: 268 seconds]
the_darkfire_[m] has quit [Ping timeout: 268 seconds]
citruscitrus[m] has quit [Ping timeout: 268 seconds]
sib1234[m] has quit [Ping timeout: 268 seconds]
u3126[m] has quit [Ping timeout: 268 seconds]
hwatwasthat[m] has quit [Ping timeout: 268 seconds]
M1f4a9[m] has quit [Ping timeout: 268 seconds]
thecake21[m] has quit [Ping timeout: 268 seconds]
akda5id[m] has quit [Ping timeout: 268 seconds]
etienneli[m] has quit [Ping timeout: 268 seconds]
_alice has quit [Ping timeout: 268 seconds]
emily has quit [Ping timeout: 268 seconds]
bgb has joined #asahi
bgb has quit [Ping timeout: 240 seconds]
marvin24 has quit [Ping timeout: 258 seconds]
marvin24 has joined #asahi
pedrojordao[m] has joined #asahi
Lumi[m] has joined #asahi
samumartinf[m] has joined #asahi
nutmanja[m] has joined #asahi
TellowKrinkle[m] has joined #asahi
xerpi[m] has joined #asahi
ConeOfAttack[m] has joined #asahi
smist08[m] has joined #asahi
skillfulman23[m] has joined #asahi
PedroAraujo[m] has joined #asahi
affieuk[m] has joined #asahi
bfredl has joined #asahi
tarik02[m] has joined #asahi
wolf511[m] has joined #asahi
liur[m] has joined #asahi
yuyangchee98[m] has joined #asahi
foxlet has joined #asahi
jevinskie[m] has joined #asahi
noneucat has joined #asahi
dyniec[m] has joined #asahi
delroth[m] has joined #asahi
hypergenesis[m] has joined #asahi
dancer[m] has joined #asahi
KurtGarloff[m] has joined #asahi
Jasper[m] has joined #asahi
fridtjof[m] has joined #asahi
krishbin[m] has joined #asahi
devinvs[m] has joined #asahi
jean-franoiswitz has joined #asahi
assusdan[m] has joined #asahi
iparaskev[m] has joined #asahi
peterkovar[m] has joined #asahi
Bastian[m] has joined #asahi
rockinrobstar[m] has joined #asahi
enverb[m] has joined #asahi
davidrysk[m] has joined #asahi
fried_dede[m] has joined #asahi
rustylerp[m] has joined #asahi
dpatterbee[m] has joined #asahi
bylaws has joined #asahi
tr0[m] has joined #asahi
Alex[m]3 has joined #asahi
nirusu[m] has joined #asahi
ewlsh[m] has joined #asahi
erenatas[m] has joined #asahi
julian[m]1 has joined #asahi
flokk[m] has joined #asahi
bastilian has joined #asahi
ah-[m] has joined #asahi
Alice[m] has joined #asahi
ryanhrob[m] has joined #asahi
ponikrf[m] has joined #asahi
sta[m] has joined #asahi
Avion[m] has joined #asahi
randohacker[m] has joined #asahi
ar88kk[m] has joined #asahi
Jan[m]1 has joined #asahi
undvasistas[m] has joined #asahi
ldhacker[m] has joined #asahi
redbluescreen[m] has joined #asahi
bakk[m] has joined #asahi
asmon[m] has joined #asahi
konradybcio has joined #asahi
nickray has joined #asahi
blazra has joined #asahi
nhlism[m] has joined #asahi
clover[m] has joined #asahi
josiahmendes[m] has joined #asahi
psydruid has joined #asahi
notafile has joined #asahi
ganpa has joined #asahi
jamesmunns[m] has joined #asahi
botoxparty[m] has joined #asahi
svenpeter has joined #asahi
zvtu[m] has joined #asahi
printfn[m] has joined #asahi
radex|m[m] has joined #asahi
Eighth_Doctor has joined #asahi
vchernin[m] has joined #asahi
ashton314[m] has joined #asahi
coinquest[m] has joined #asahi
izzyisles[m] has joined #asahi
bjornjulander[m] has joined #asahi
ronyrus[m] has joined #asahi
khronokernel[m] has joined #asahi
noc0lour has joined #asahi
Bennett[m] has joined #asahi
winocm has joined #asahi
brentr123[m] has joined #asahi
daniel[m]7 has joined #asahi
d_u_f_f[m] has joined #asahi
user1tt[m] has joined #asahi
crafteck[m] has joined #asahi
rootspring[m] has joined #asahi
thecake21[m] has joined #asahi
mofux[m] has joined #asahi
sib1234[m] has joined #asahi
citruscitrus[m] has joined #asahi
numa[m] has joined #asahi
shadaj[m] has joined #asahi
mikewilks[m] has joined #asahi
etienneli[m] has joined #asahi
akda5id[m] has joined #asahi
aimileus has joined #asahi
the_darkfire_[m] has joined #asahi
hwatwasthat[m] has joined #asahi
M1f4a9[m] has joined #asahi
_alice has joined #asahi
Spectrejan[m] has joined #asahi
u3126[m] has joined #asahi
emily has joined #asahi
bgb has joined #asahi
bgb has quit [Ping timeout: 256 seconds]
bgb has joined #asahi
bgb has quit [Ping timeout: 246 seconds]
<sven>
nice :-)
bgb has joined #asahi
maor26 has joined #asahi
amw has quit [Ping timeout: 246 seconds]
VinDuv has joined #asahi
bgb_ has joined #asahi
bgb has quit [Ping timeout: 240 seconds]
mndza has joined #asahi
VinDuv has quit [Quit: Leaving.]
amw has joined #asahi
raster has joined #asahi
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
amw has quit [Ping timeout: 246 seconds]
<marcan>
maz, arnd: so thinking about the DT binding for the MMIO map mode... should it apply to the current node, or only children?
<marcan>
if it applies to the current node and children, that would make it impossible to declare an MMIO mode for a PCI controller but not the actual, dynamically-discovered PCI devices (assuming the PCI code eventually grows support for this too, which isn't in scope for v2 since the default works there)
<arnd>
marcan: the way I suggested would be only for the children
<marcan>
but if it only applies to children, it wouldn't be usable to set the mode for a single device that needs it
<marcan>
though I guess a dummy bus could be introduced
<marcan>
but that feels icky
<arnd>
I was thinking similar to how pci and isa nodes work, which use ranges properties to create multiple address ranges, with a flag in the top word (or top bits of the 64-bit address) distinguishing between types of registers
<marcan>
what bugs me about that one is overloading the top bits, which is fine until someone comes along with 64-bit PAs
<marcan>
if we had a separate cell for that it would be ideal, but then we need a bool to signal it, and it would break forwards compat of newer DTs with older kernels
<arnd>
marcan: you can totally have #address-cells=<3> in a regular bus, I don't think that causes issues with the kernel, though it might not work as intended in other consumers of the dt
<marcan>
hah
<marcan>
but wait, that'd make all the child addresses 3-cell too?
<arnd>
yes, unless you have another bus underneath that turns them back into #address=cells=<1> or #address-cells=<2>
<marcan>
wait, wouldn't the *root* have to be address-cells=<3>?
<marcan>
and then the bus can be <2>
<marcan>
and ranges maps 2 -> 3, and the top cell defines the mode
<maz>
I think that's how PCI works.
<maz>
(though it uses the top cell for other purposes, AFAICR)
* maz
goes and reread the OF/PCI stuff...
<arnd>
the root bus could be #address-cells=<3>, but I was thinking <2> here
<marcan>
pci is backwards afaict
<marcan>
i.e. it maps 3 to 2
<marcan>
so it maps <io type, addr> -> <addr>
<arnd>
with the /soc node adding a third cell to encode flags like pci and isa
<marcan>
which is why it has address-cells=<3>
<marcan>
also I thought I read mapping code in linux that assumed address-cells was always 2 or 1
<marcan>
it certainly assumes max 64 bits of address, since it uses u64 for everything
<arnd>
right, we do limit phys_addr_t/resource_size_t to 64 bits, but 'struct resource' does encode the PCI addresses including the flags
<arnd>
the address gets truncated to the size of resource_size_t
<marcan>
right, and that gets handled by pci bus-specific translation in of/address.c
<arnd>
so adding a fourth case (aside from pci, isa and default) in there is slightly ugly, but it's the best I could come up with so far
<marcan>
of_bus_pci_translate just skips the first cell of the address, then goes through the default code which indeed just truncates things implicitly
<arnd>
using the ranges property at least makes it possible to have more complex mappings in the future
<marcan>
and then the map function looks at that
<arnd>
marcan: on PCI, the flags get parsed by the PCI host driver when setting up the pci_host_bridge resources, which get used for assigning resources to child devices
<marcan>
right
<arnd>
traditionally, open firmware had assigned the resources to devices and listed them as "ranges" and "reg" properties in the device nodes of the pci child nodes, but we don't do that in fdt because Linux is capable of scanning the pci bus itself
<marcan>
though DTs can still specify stuff to assign configuration to otherwise dynamically discovered, devices, right?
<arnd>
yes, you can specify your own DT properties for things that PCI cannot detect, and you can add a probe-only property (don't remember the spelling) in the host bridge to tell the kernel it should not reassign the resources
<marcan>
so the flags for pci are mapped to IORESOURCE_ constants, which is quite... congested
<arnd>
yes, I noticed
<marcan>
we could fit in a IORESOURCE_MEM_NONPOSTED in as the *last* available bit
<marcan>
in that section
<arnd>
if it's a custom type, it could be 0x00000500
<arnd>
the types don't have to be distinct bits (see IORESOURCE_REG)
<marcan>
true
<marcan>
though this seems to be clearly a subtype of MEM
<arnd>
right, it might be better to have IORESOURCE_MEM with an extra flag
<arnd>
it's also possible that some of the ioresource flags are entirely unused
<arnd>
most of this originally came from PCMCIA and ISAPnP I think
<marcan>
this file dates back to... I don't even want to know :)
<marcan>
it predates git at least
<marcan>
and so do *all* the MEM_ flags
<marcan>
but stepping back, assuming we do it this way, let me get it straight
<marcan>
what PCI does is map 3->2, and then the PCI code knows what type it needs and supplies the necessary info when requesting resources via the OF translation code
<marcan>
here, there is no "PCI code", child nodes are just devices. so if we do the same thing, then every subnode needs to specify posted/nonposted as the top cell
<marcan>
(in its regs)
<marcan>
(unless we add a sub-bus to translate back to 1 or 2 cells)
<arnd>
Yes, I think that would work for this generation, but there is a small chance that a future SoC would require doing something similar to my suggestion, and then we implement two methods
<marcan>
I may not quite understand your suggestion yet, I thought this is what you were suggesting
<arnd>
sorry, I misread what you said
<marcan>
but then this seems somewhat magic; in PCI we start with knowledge of the type, and this gets mapped to plain MMIO, but those MMIO ranges implicitly encode the type (for any given soc), the IORESOURCE_ flags seem mostly ancillary? only the IO/MEM distinction and the PREFETCH flag apply
<marcan>
however, here we'd be mapping "one magic address encoding info" to "an address completely devoid of info" and setting some flags behind the scenes
<marcan>
and then we have the issue of what PCI does, because if we use 3-cell form suddenly now the PCI nodes need to do 3->3, and some resources are going to be IORESOURCE_IO
<arnd>
the pci ranges doing 3->3 conversion should just work fine, all this means is that you can specify in the parent address whether a particular downstream range corresponds to an upstream posted or non-posted area
Bublik has joined #asahi
<arnd>
so an mmio range looks like
<marcan>
of_bus_default_translate is broken for this AFAICT; it currently zeroes out the entire destination address
<marcan>
that memset needs to be, well, removed AFAICT, since it's already setting the translated address cells anyway
<marcan>
yeah, that doesn't work right now :) (but it would if we just remove that memset, I wonder where that came from...)
<marcan>
looks like it was there from the beginning, probably safe to remove unless there are broken DTs out there that rely on that
<arnd>
I don't see what you mean. The memset() in of_bus_default_translate() only clears the low 64 bits of the address, as it gets called with a modified addr and na value
<arnd>
or do you mean we couldn't use of_bus_default_translate() for the new bus?
<arnd>
regarding IORESOURCE_IO, I don't think that is supported at all in the M1, at least the ADT doesn't seem to list it
<marcan>
wait, isn't that modified addr thing *another* bug?
<marcan>
it's supposed to be *pna*
<marcan>
pci does 3 -> 2; pna should already be 2 here
acelogic has quit [Ping timeout: 264 seconds]
<marcan>
that means the pci code is not properly translating addresses crossing a 4GB boundary
<marcan>
ignoring PCI for a second; the generic code first turns the range into an offset, then memcpies the parent address from the range into addr, then calls the translation function, which is supposed to add the offset into the range
<marcan>
the default translation function right now *zeroes* the entire target address before writing back the translated address to the last one or two cells
<arnd>
that is possible: as I said, we don't actually rely on the translation across PCI host bridges but rather set up the PCI-to-host windows when creating the pci_host_bridge devices in other code
<marcan>
the PCI one translates one fewer cell than it needs, in 64b cases, and works practically by accident in 32b cases; in the latter case, addr is an invalid pointer to the *end* of the parent address buffer, wait, how does this work again? :)
<marcan>
unless I'm misreading the code, this is broken
<marcan>
anyway, the fix is to remove the -1 (actually to just get rid of the pci-specific translation function, just call the default directly) and then remove the memset so that it doesn't clobber any upper cells >2
<marcan>
arnd: this ought to be submittable completely out of band from that series, right? the pci bugfix in particular, probably also removing the memset? the latter just seems generically useful
<marcan>
(as right now the translation isn't correct anyway, even if nothing relies on the upper cells surviving)
<arnd>
yes, it could be separate, I'm just not sure yet what changes are actually needed. I think what we need is for ->translate() to take both 'na' and 'pna' arguments like ->map() does, but I'd have to reread it several times more and look at the git history to see how we got to what it is now
<marcan>
I think it's fine with 'pna', as the translation is via an offset anyway; this is assuming we accept that the top cells are not getting treated as "proper ranges"
<marcan>
however, `map` right now ignores the top cell for (p)na=3, so there is no matching on that
<marcan>
i.e. (1,0,0) will currently match a range for (0,0,0)
vimal has quit [Quit: Leaving]
<arnd>
yes, from reading it a little more, I would conclude that it works as intended: ->translate() gets called with the 64-bit address portion of the child address and a copy of the parent's base address from the ranges, and it is documented to assume that it is in fact translatable
<marcan>
it gets called with the *offset*
<marcan>
of the 64bit portions
<arnd>
right
<marcan>
so the memset is superfluous; all it does is corrupt the upper part of the parent's base address to 0
<marcan>
and of_bus_isa_translate / of_bus_pci_translate are broken; they are skipping the top cell of the *parent* output address array, which is already correcly sized; those buses use an extra cell in the *child* address but that is not what translate() deals with
<marcan>
but you said that codepath isn't used, right?
<arnd>
I'd have to check what powerpc and sparc do for their of-based PCI probe, but I think they still use the PCI BARs for reading the addresses rather than the DT information
<arnd>
it seems those use of_pci_address_to_resource(), which reads the resources in the PCI bus node and assumes it does not need to translate those further
<marcan>
AFAICT the bug has been in there from the beginning; d1405b869 added this code
<arnd>
ah, it does __of_address_to_resource(), which has different paths for IORESOURCE_MEM and IORESOURCE_IO, and assumes it can translate memory addresses without caring about the upper bits, and treating I/O ports special
bgb_ has quit [Ping timeout: 256 seconds]
<arnd>
limiting the intermediate addresses to 64 bit was an intentional simplification at the time, as nothing relied on it, but that probably means it's not a great idea to start relying on it now
<marcan>
just removing the memcpy, fixing the broken pci/isa translation, and changing the default map function to just compare any higher cells would make this all work with >64-bit intermediate addresses, as long as ranges/offsets do not cross a 64-bit boundary
<marcan>
i.e. without having to introduce >64-bit math, it would probably cover all use cases of those higher cells for flags/info, as long as any such high cells are not grouped together (mapping a range >2**64 to cover multiple flag types would be wrong, however leaving those default mapped would be fine)
<marcan>
*the memset
<arnd>
right, it might be good to warn if a 64-bit boundary is crossed, but I don't think it's worth trying to handle that correctly
<marcan>
actually, as long as size-cells <= 2, we're pretty much safe modulo wrapping into the upper bits, which isn't something any of the current code handles properly anyway
amw has joined #asahi
<kettenis>
for OpenBSD I was planning to use the bus_space(9) abstraction to make sure PCIe mmio address space gets mapped nGnRE
<kettenis>
so I think I can get away with that without any hints in the device tree
<kettenis>
having #addr-cells be 3 outside of pci space would be somewhat painful
<arnd>
kettenis: from the man page for bus_space(9), I think this would correspond to Linux's regmap, which lets you abstract all kinds of buses that have some form of indexed registers (mmio, pio, i2c, spi, ...)
<kettenis>
indeed
<kettenis>
although we don't actually use it for i2c
<arnd>
in this case, the Linux implementation would presumably require all drivers to use regmap_write()/regmap_read() for accessing any of the internal registers, rather than our normal writel()/readl(). It could still work with drivers that are shared with other machines, but regmap does have a noticeable overhead because it requires an indirect function call instead of a fancy pointer dereference
<kettenis>
with some cleverness you could avoid the function pointer overhead for the actual access
<kettenis>
but TBH I don't think you'd want to overhaul this part of the linux kernel design
<kettenis>
bus_space(9) is a fairly clever design, but the API makes your drivers a bit wordy
<arnd>
Right, I think haivng a regular __iomem pointer with readl/writel but a special way to map it is the right abstraction for Linux, the question is just where to hand the special logic for creating the page tables
<arnd>
the approach discussed above would have the purpose of encoding it in 'struct resource' in order to have the ioremap_resource() family of functions do the right thing based on an architecture specific change
<arnd>
there are probably other ways to have that flag set, as well as other ways to hack the ioremap() internals function to not require that flag
ephe_meral has joined #asahi
ephe_meral has quit [Ping timeout: 256 seconds]
ephe_meral has joined #asahi
TheJollyRoger has quit [Ping timeout: 268 seconds]
Code_Red1 has joined #asahi
robinp_ has quit [Read error: Connection reset by peer]
ephe_meral has quit [Ping timeout: 264 seconds]
Bublik has quit [Ping timeout: 240 seconds]
Bublik has joined #asahi
amw has quit [Ping timeout: 240 seconds]
acelogic has joined #asahi
ephe_meral has joined #asahi
TheJollyRoger has joined #asahi
TheJollyRoger has quit [Ping timeout: 268 seconds]
<robher>
arnd, marcan: I'm not a fan of a flag for this in DT. A new flag in PCI cells would be tolerable, but if we're talking a flag cell on default buses I'd expect that would not work on any existing code. And if OpenBSD doesn't need a flag, neither should Linux.
<robher>
If we have resource flags plumbed, we could just handle it in the DT address code like the other Mac quirks.
<marcan>
yeah, the extra cell is definitely going to cause pain for code that (not unreasonably) assumes #address-cells is always <= 2
<marcan>
(including linux to some extent as we found)
<marcan>
robher: so how do you suggest signaling in the DT what attributes are required for a given mapping? per device?
<kettenis>
part of the reason we (OpenBSD) don't need this flag is because we use nGnRnE by default
<robher>
marcan: We don't really need per device do we? It's PCI and not-PCI AIUI.
<kettenis>
correct (as far as we know at this point)
<arnd>
robher: specifically it's the PCI memory space, so the PCI device node itself has a mix of the two, because its own registers are like the rest of MMIO
<robher>
I'd guess we'd need a way to change the default and then PCI mappings override that.
<arnd>
I'd like to see of_address_resource to set a flag in 'struct resource' for any device that needs it, which would nicely happen to work because PCI devices create their resources differently
<marcan>
there are two options there: either change every PCI driver to not use ioremap() (so we can actually do something about it), or register the PCI address ranges into ioremap() somehow so it can find out that way
<robher>
arnd: It's own registers are in 'reg' and a default bus and the memory space is in ranges, so that should be okay.
<arnd>
so there just needs to be a sane DT representation to make it work not just by accident by also on other implementations
<marcan>
this is one reason why going the other way is easier, because non-PCI drivers are less likely to use plain ioremap, and there is a limited set of them we care about
<arnd>
we might want to introduce a non-devm_ version of ioremap_resource() if some driver wants it, but that should be easy enough to do, and most drivers benefit of using the dev_ioremap_resource() over the many other variants anyway
<arnd>
marcan: in case you end up converting drivers from ioremap() to devm_ioremap_resource(), watch out for the implied 'request_mem_region' that prevents an address from being mapped more than once, but is not implied by the normal ioremap
<marcan>
good point
<arnd>
On the question how to determine whether that flag should be set, an empty property similar to 'dma-coherent' and 'big-endian' sounds reasonable, but I'm unsure whether it should affect only that device or the children
<arnd>
if it only affects the device itself, it would make the PCI case work nicely, but it would be required in every single device node
<arnd>
(those that have a reg property)
<marcan>
yeah, somewhat spammy, though I don't mind personally for our DT
<robher>
Ideally those would be in bus nodes.
<robher>
Like dma-ranges is supposed to be.
<marcan>
so defining the ranges and access types within that bus?
<robher>
marcan: Hopefully only 1 type per bus, but yes.
<marcan>
well, pci is logically nested within nGnRnE-requiring buses I think
<marcan>
(in particular the pci controllers themselves)
<marcan>
(but also nearby are pci IOMMUs and related things)
<robher>
so the PCI controller picks up the flag from the parent bus for it's regs and PCI children get the flag from the PCI node.
<robher>
A flag property or a flags cell work the same way ultimately. It's just inband vs. OOB WRT ranges.
<kettenis>
that would fit the OpenBSD bus/driver model nicely and U-Boot wouldn't worry about it
<marcan>
ah, so not actually a ranges definition, just a flag property but picked up from buses?
<marcan>
(sorry, got confused by dma-ranges)
<marcan>
looking it up recursively, or just the immediate parent?
ephe_meral has quit [Ping timeout: 264 seconds]
<robher>
marcan: Probably recursively or recursively for empty 'ranges' only.
ephe_meral has joined #asahi
<marcan>
since we need to be able to override it, if it's recursive, it should be a property with actual values then
<marcan>
(not just an empty bool)
Bublik has quit [Ping timeout: 240 seconds]
<robher>
I meant whether 'ranges' is empty or not. Empty ranges means inherits parent address space or 1:1 translation. No ranges means not a translatable bus.
<marcan>
robher: what I'm saying is that if we do more than the immediate parent, we need some way of turning off the setting if it was turned off at a higher level
<marcan>
e.g. on the pci controllers
<marcan>
so it can't just be an empty flag property
<marcan>
*turned on at a higher level
choozy has joined #asahi
<arnd>
For endianess, we have a tristate 'big-endian;', 'little-endian;' or no property meaning it is whatever the default for that compatible string is. We could do the same in bus nodes here, with one value meaning 'all children use nGnRnE', one for 'all children use 'nGnRE' registers, and no property meaning either that its inherited from grandparent, or not to do anything special
<robher>
marcan: Close enough for a prototype. If a property works, then implying from compatible strings can too. (See 'MacRISC' in the DT address code.) But better to discuss that with a concrete implementation and that wouldn't affect most of it.
<kettenis>
that can now load an UEFI bootloader from a usb disk connected to the type-A ports n the mini
<kettenis>
only tested with the corellium pre-loader for now
_whitelogger has joined #asahi
<maz>
kettenis: small nit about your CPTR_EL2 change: you should be able to leave the programming via CPACR_EL1 (E2H redirects the access to CPTR_EL2 and shuffle bits around).
<maz>
kettenis: yes, the ARM ARM is unreadable.
<kettenis>
the bit where it enables the fpu?
<maz>
kettenis: yup.
klardotsh has joined #asahi
<kettenis>
ah, so that could save me three instructions
<maz>
critical path! :)
<kettenis>
well, this is common code and on some boards it runs in SRAM
<maz>
it's mostly that you can get rid of this patch altogether.
<kettenis>
so every byte counts ;)
<kettenis>
no, I can't
<kettenis>
without that change it does *not* enable the fpu
<maz>
the write to cpacr_el1 should definitely do it.
ephe_meral has quit [Ping timeout: 272 seconds]
<kettenis>
and u-boot dies when the first varargs function gets hit
<maz>
at EL2 with E2H, cpacr_el1 *is* cptr_el2.
<kettenis>
typically that is snprintf
<j`ey>
kettenis: why do you need fp/simd?
<j`ey>
you/you-boot :P
<kettenis>
right but the layout of cptr_el2 changes if E2H is enabled
<maz>
not if you access it via cpacr_el1. that's the whole point of VHE.
ephe_meral has joined #asahi
<kettenis>
with E2H on, cptr_el2 has the same layout as cpacr_el1 (because they are aliased I suppose)
<kettenis>
is that not how other VHE supporting CPUs behave with W2H on?
<maz>
VHE implementations must be able to use their _EL1 registers from EL2 and see their own state being affected by them.
<maz>
since you can run an EL1 OS at EL2 almost transparently.
<kettenis>
j'ey I don't know, but if you don't compile with -mgeneral-regs-only varargs functions such as snprintf save the fpu registers on the stack
<kettenis>
maz right, and I suspect that works fine
<maz>
kettenis: it must, or Linux wouldn't boot, for example.
<kettenis>
that should work for vbar_el1 as well isn't it?
<maz>
indeed.
<maz>
also, be careful when using _EL1 *and* _EL2 registers from EL2, the two views are not guaranteed to be synchronised (isb is your friend).
<kettenis>
there is an isb conveniently located close by
<kettenis>
and it works as expected
<maz>
fab!
<kettenis>
already sent that bit upstream, but I'll roll a v3
choozy has joined #asahi
ephe_meral has quit [Ping timeout: 256 seconds]
<kettenis>
thanks for looking at it
<maz>
no worries.
suskun has joined #asahi
suskun has quit [Remote host closed the connection]
suskun has joined #asahi
VinDuv has joined #asahi
suskun has quit [Ping timeout: 272 seconds]
<modwizcode>
I wonder what the idea behind the delayed "deferred" style fast IPIs are, I don't know enough about all the uses to understand where that would benefit you