<nergzd723>
Let me know if this is not a correct room for questions like that
<marcan>
nergzd723: I forget how we figured out the offset, maybe that came from corellium? Either way nowadays we'd be using the hypervisor to find things like that, but I imagine that won't work on A7/A8 era devices.
<j`ey>
nergzd723: you could maybe look back at some of the streams to see..
<jannau>
has to be stream from january 2021, fortunately there's a date in the title
<nergzd723>
thank you :)
<marcan>
I think it did come from corellium though
<nergzd723>
marcan: I think corellium has a different offset
<marcan>
they might compute it differently but it has to hit the same register to work
<jannau>
it started off as absolute value 0x23b754000L
<marcan>
IIRC they had the cluster/core stuff wrong
<marcan>
and I initially didn't understand what the second bit set did (then I realized it had to do with enabling system-level stuff for the core, e.g. IRQs don't work without it)
<nergzd723>
They also appear to be doing something with Coresight register, is that not relevant to M1?
<marcan>
corellium do a lot of stuff that isn't relevant to anything or outright wrong
<marcan>
hence why I avoid trying to look at their code; it has caused several people much confusion
<AdryzzOLEDEdition[m]>
they just need it to boot, not to work well
<nergzd723>
teir drivers are usually a mess...
AdryzzOLEDEdition[m] is now known as AdryzzOLEDEdition[m]1
<marcan>
AdryzzOLEDEdition[m]: they just need their hypervisor to convince iOS to boot, not to actually emulate the hardware as it actually functions
<nergzd723>
the sad thing about A7/A8 is that they have an older generation of NAND controller, newer devices use pcie for storage.
<marcan>
that sounds painful...
<marcan>
no ANS taking care of that I guess?
<nergzd723>
what is ANS?
<marcan>
the NAND controller
<nergzd723>
not sure about it
<marcan>
if you end up having to implement the FTL in software, I wish you luck...
<nergzd723>
well, it would be a long way to NAND for sure
<nergzd723>
Right now I'm trying to convince USB to work, but it won't work properly
<nergzd723>
did you get USB on M1?
<marcan>
don't those devices use dwc2?
<marcan>
M1 uses dwc3
<nergzd723>
yes, mine is using dwc2
<nergzd723>
interesting
<marcan>
different hardware then, you'll have to adapt the driver or write your own
<marcan>
I mean in m1n1
<marcan>
linux has a dwc2 driver
<nergzd723>
well, the current state of affairs is that Linux driver probes, detects cable("new full/high-speed device..."), but on PCs side I also see "new full/high speed device..." but then "device doesn't accept address ..."
<marcan>
that sounds like Linux is treating it as a *host* port, not a *device* port
<nergzd723>
The host controller on PC tries to power cycle it and do other things, but it doesn't succeed
<marcan>
you need to put it in gadget mode
<nergzd723>
Yeah - I suspect as much
<marcan>
right now it sounds like you have two hosts trying to talk to each other and falsely detecting each other as a full/high speed device for whatever reason
<nergzd723>
I don't think it's supposed to announce new connections if it's acting as a peripheral
<marcan>
it isn't
<marcan>
not like that
<nergzd723>
but I only enabled DWC2_PERIPHERAL only, and some gadget configuration is applied, so I assume it must be in peripheral mode
<nergzd723>
needs more guesswork I guess
<nergzd723>
g_ether iirc
<marcan>
there's also the lightning controller involved, Tristar or whatever, right?
<marcan>
on those devices
<marcan>
though I think that should boot in device mode for DFU to work, if the AP doesn't tell it to do anything special
<nergzd723>
I'm very happy it ended up working in any case, spent too much time on figuring out the bootloader doesn't load kernel fully...
<marcan>
does the AIC driver work without changes?
<nergzd723>
must be configured, Pongo (bootloader) also uses USB
<nergzd723>
marcan: some CPU registers don't exist on A8, so konradybcio and me hacked it a bit
<nergzd723>
uncore one and one of fiq ones I think
<marcan>
sure, but the AIC side itself works fine?
<marcan>
not the FIQ side
<nergzd723>
SYS_IMP_APL_IPI_SR_EL1 and SYS_IMP_APL_UPMCR0_EL1
<nergzd723>
marcan: yep, works fine for USB controller
<nergzd723>
it uses AIC_IRQ
<nergzd723>
didn't get to test i2c/spi, I guess USB first
<marcan>
the SYS_IMP_APL_IPI_SR_EL1 thing is a bug at this point, the static_branch_likely(&use_fast_ipi) should be moved outside that if so it doesn't even try to touch that register if Fast IPIs are not in use
<marcan>
then it won't try to use them for <8103
<marcan>
the uncore one, yeah, I guess that needs its own test/compatible check
<marcan>
good to hear AIC really did stay compatible
<marcan>
robher was complaining about me introducing AIC2 right after AIC1 :p
<nergzd723>
also, there's no EL2 on A7/A8 :)
<marcan>
yeah, thought so
<nergzd723>
And the path with timer FIQ returned -ENOENT
<j`ey>
nergzd723: so just EL3/1/0?
<nergzd723>
yes
<nergzd723>
DARTs probe fine too by the way
<marcan>
that's good news too
<nergzd723>
can't know if they work though...
<marcan>
USB isn't using the DART?
<nergzd723>
there are also half reg DARTs, which is fun
<nergzd723>
0x2000 size in ADT instead of 0x4000 for most others
<nergzd723>
no, USB isn't
<nergzd723>
the apcie one is one of halved ones
<nergzd723>
so that must be fun
<nergzd723>
that's about it, I guess, thanks for your advises :)
<marcan>
I think the normal DARTs only have like 0x300 bytes worth of registers, so 0x2000 vs 0x4000 doesn't sounds like it necessarily means anything
<marcan>
most things are 16K aligned due to the page size only
<nergzd723>
That's good to know :)
bisko has joined #asahi-re
bisko has quit [Read error: Connection reset by peer]