<marcan>
where'd 245 come from? I saw 250 in the plist
<marcan>
and setup/hold are 20us per the magic reg blob
<jannau>
the 245 are an error. the 45 come from the plist: CS to Clock Us and Clock to CS Us
<marcan>
I guess apple themselves are inconsistent...
<jannau>
20us seems to work fine, I'll use 20us and leave a comment that those might be 45 us
the_lanetly_052___ has joined #asahi-dev
thunfisch has quit [Read error: No route to host]
thunfisch has joined #asahi-dev
<maz>
marcan: yeah, that's on my long list of things to do. let me shake off this hangover first! ;-)
bps2 has joined #asahi-dev
bps3 has joined #asahi-dev
timokrgr has quit [Quit: User left the chat]
bps2 has quit [Ping timeout: 480 seconds]
timokrgr has joined #asahi-dev
<j`ey>
marcan: oh nice, just saw you submitted the spi driver
aleasto has joined #asahi-dev
<marcan>
maz: :-)
bps3 has quit [Ping timeout: 480 seconds]
Glanzmann has quit [Quit: leaving]
m6wiq has joined #asahi-dev
Glanzmann has joined #asahi-dev
m6wiq has quit [Quit: Leaving]
m6wiq has joined #asahi-dev
m6wiq has quit [Quit: Leaving]
VinDuv has joined #asahi-dev
kumoko has joined #asahi-dev
alyssa has joined #asahi-dev
<alyssa>
....M1 Mini headphone jack support you say?
* alyssa
rebases kernel
<alyssa>
$ git pull linux-next...
<Glanzmann>
alyssa: Long time no see. If you have a dcp driver for me to try on mini or macbook air, let me know. I'm excited to try your new tree.
<alyssa>
Let's see
<alyssa>
I've been doing Mali stuff for the past few months
<alyssa>
I really had two goals with the M1, GPU bring-up and making linux-on-m1 my main machine
<alyssa>
waiting on marcan to reverse the GPU register/firmware stuff before either of us can tackle GPU kernel, and as for the latter?
<alyssa>
I mean, my asahi box *has* been my main machine for months now :)
<Glanzmann>
alyssa: Btw, we noticed that on 'simple drm' firefox does not work with the xorg modsetting driver, but it does with the fbdev driver, any idea why? (does not work means the gui doesn't come up. With konquerer the gui comes up but if you browse to the website the page display array stays empty).
<Glanzmann>
alyssa: I'm also waiting for that. He promised GPU accelerated desktop within one year. He still has plenty of time. :-)
<marcan>
I didn't *promise* anything :p
<marcan>
I know better than that
<Glanzmann>
Yes, I'm looking for that twitter post.
<alyssa>
marcan: Oh, so you will do it! Thanks!
<marcan>
I said "challenge accepted"
<alyssa>
I'm on holiday next week, I expect to have m1n1 reference code waiting for me 🙃
<marcan>
alyssa: I've got things to get merged into 5.17!
<alyssa>
Alas
<alyssa>
And I've got new shiny Malis to play with
<marcan>
and a wifi patchset to rewrite!
<marcan>
seriously though, my current goal is to tie up all these loose ends by EOY, so that *next* I can get working on the GPU kernel driver
<alyssa>
=D
<marcan>
also at least we have feature parity on the new laptops, that's gotta be worth something right? :>
<j`ey>
marcan: for wifi, you want a real smc driver, or ok with just doing the gpio poke via m1n1?
<marcan>
j`ey: we need a real SMC driver anyway, I'll be doing that once I take care of the wifi firmware situation
<alyssa>
the two tasks are orthogonal, though
<marcan>
they are
<alyssa>
otoh, the wifi firmware situation is the much harder one
<marcan>
eh
<marcan>
I know what needs to be done
<alyssa>
good
<marcan>
I can crank out a v1 this coming week
<marcan>
and maybe even get started on SMC
<j`ey>
marcan: and also progress report
<alyssa>
OK so why does linux build so slowly on my chromebook (targetting the M1) but so fast on my M1 (targetting the Chromebook)
<alyssa>
🙃
<marcan>
yes, I was going to do that today but alas... kinda crashed this afternoon since I had to wake up early for something
<j`ey>
alyssa: I wonder!
<marcan>
also, tbh, just running KDE on the M1 Pro MBP with the keyboard/touchpad patches feels silly, as in silly how well it works on a damn framebuffer
<alyssa>
marcan: 💯
<alyssa>
GNOME + M1 Mini + DCP here but still
<alyssa>
it should not work this well
<marcan>
yeah
<marcan>
I tried DCP but alas it's not quite there :p
<j`ey>
marcan: that's running ALARM off the NVMe?
<alyssa>
I mean
<marcan>
OTOH the PMGR fixups I should send out to SoC tomorrow unborked it :p
<marcan>
j`ey: yes
<alyssa>
right now the only useful thing the DCP driver does (over simpledrm) is mode sets
<marcan>
(I accidentally broke DCP with PMGR, turns out DCP needs a special snowflake feature)
<marcan>
alyssa: and vsync hopefully
<alyssa>
marcan: ostensibly, but you still get tearing because software rasterizer borked
<j`ey>
marcan: so right now: watchdog, dt fixups, pmgr (2 sets), PMU, AICv2, SPI
<j`ey>
marcan: anything else on the mailing list?
<alyssa>
anyway as-is DCP is a must-have on the Mini and useless on the laptops
<marcan>
j`ey: SDHCI quirks are in review too
<marcan>
alyssa: right
<j`ey>
marcan: Hey folks,
<marcan>
j`ey: yeah I know I know
<marcan>
T_T
<j`ey>
marcan: :D
<marcan>
copypasta fail and I totally missed it
<alyssa>
what's this?
<marcan>
I sent out a v2 with subject "Hey folks," on the cover letter
<alyssa>
ahh
<alyssa>
(That would change with ATCPHY nonsense taken care of to get displayport on the type-C ports..)
<marcan>
I normally copy and paste from subject to end of cover letter when re-spinning the .patch files, but something went horribly wrong
bps3 has joined #asahi-dev
<jannau>
j`ey: dart-t6000 and apple-dwc3 reset quirk. the latter semi-hard requirement for adding the usb-c ports to the dts
<marcan>
j`ey: that one is applied, I think you mean the other t6k support patch?
<j`ey>
oh, I didn't know that got applied, great!
<j`ey>
oh sorry yeah, i meant the other ones. too many patches
kumoko has quit [Quit: Leaving]
the_lanetly_052__ has joined #asahi-dev
the_lanetly_052___ has quit [Ping timeout: 480 seconds]
<alyssa>
ld: drivers/gpu/drm/bridge/display-connector.o:(.rodata+0x68): undefined reference to `drm_atomic_helper_bridge_duplicate_state'
<alyssa>
what did alyssa break today
<alyssa>
oh was missing kms helper due to rebasing funny
<povik>
oh hey alyssa
<Glanzmann>
alyssa: The DCP driver can also do screen rotation, run firefox and does not burn the lid down when closed.
<povik>
you may still be the first other person to try out the sound driver for all i know
<povik>
i can send the .config options you need if you are interested
<Glanzmann>
povik: I'm also interested.
<povik>
okay then, i will put them up somewhere
<Glanzmann>
alyssa: And DCP can change the resolution on the mini.
<Glanzmann>
alyssa: Without DCP you can not turn the screen off as a result, when the lid is closed it gets hot as hell.
<Glanzmann>
povik: Have you tried to run your patches on top of jannau's patchset?
<povik>
no i haven't, if it has pmgr with all the domains then i don't expect issues
<jannau>
it's just applespi patches on top of asahi (potentially rebased onto 5.16-rc4)
<povik>
okay then that should work just fine
<Glanzmann>
jannau: mps and I also have rebased it on top of git head from torvalds, also works.
<Glanzmann>
rebased, is to much. We applied the patch and it works.
<jannau>
keyboard works with spi-hid-apple
<Glanzmann>
jannau: I worked the whole day with the air with your latest patchset, it works really well, no caps lock hangs, I was able to switch meta and alt and the touchpad also works great (no random jumps, when I type).
<j`ey>
jannau: !!
<alyssa>
Ugh rebase conflicts etc
<alyssa>
ok, that one was easy
<alyssa>
Needed to backport changes from pci.c to apple-ans.c b84ba30b6c7a ("block: remove the gendisk argument to blk_execute_rq")
<alyssa>
but that was a 2 line fix
<alyssa>
Glanzmann: er, does my DCP driver turn the screen off when the lid closed? I assume that needs a lot more driver work?
<alyssa>
or are there patches to it floating around?
<alyssa>
I've been off in Mali land
<kettenis>
won't it automatically blank the screen after a little while?
<alyssa>
maybe?
<alyssa>
I guess that's userspace's job
<alyssa>
I guess "lid closed" is an event from the SMC or something
<kettenis>
event_name-bit8 = lid
<kettenis>
so, yes
<alyssa>
ok, rebased on linux-next. let's see if I broke anything
<Glanzmann>
alyssa: I know we're not supposed to use it or talk about it, but did you fix wifi and can you tell me what the new names for the firmware are?
<alyssa>
aaaand I broke DCP
<alyssa>
kettenis: ack
<povik>
mine is based on that asahi branch
<povik>
(or was few days ago)
<povik>
Glanzmann: asahi-sound
<alyssa>
povik: I'm attempting to rebase yours on linux-next and add back the few extra things it's missing compared to my old branch
<Glanzmann>
povik: I see, perfect.
<alyssa>
or would be, currently wondering why DCP is unhappy
<povik>
could be that power state issue marcan mentioned?
<alyssa>
gah I need serial
<alyssa>
povik: I mean it used to work ...
<povik>
yes, because some power domain the driver didnt know about
<povik>
and now it does
<alyssa>
mumble
<alyssa>
You have "arm64: dts: apple: t8103: Add apple,min-ps to DCP PMGR nodes" in your tree ...
<povik>
okay it's not that
<alyssa>
oh, but I probably need to update my device tree bindings for DCP to specify the appropriate domains, duh.
<alyssa>
Ummm in the mean time I would love to know why simpledrm isn't working .
<alyssa>
---right because disp dart
<alyssa>
i haven't touched this in a while
<alyssa>
-----because I didn't cherrypick DCP right
<alyssa>
God I'm slow today
bps2 has joined #asahi-dev
<alyssa>
Kernels are hard ..
<alyssa>
Okay, simple-drm is ok
<matthewayers[m]>
Yeah, I’m waiting until my final exams are over to really dive into this stuff on my own machine
<alyssa>
apple-pmgr-pwrstate 23b700000 power-manager:power-controller@2c0 failed to add parent domain -22
<alyssa>
that seems .. sus
<alyssa>
0x2c0 is ps_mca1
<alyssa>
povik: ^
<alyssa>
I assume that has to do with the hack on the tip of the tree
<povik>
hmm
bps3 has quit [Ping timeout: 480 seconds]
<alyssa>
DCP not booting regardless, uhh I assume I need those DT changes
<alyssa>
uhh
<alyssa>
I don't see a power domain for dcp
<alyssa>
at least not separate from disp0 which is marked always-on
<sven>
that should be the correct domain
<alyssa>
oh the driver isn't even probing
<alyssa>
...why not? :X
<alyssa>
y'know I would really have liked you to call my probe function, linux
<alyssa>
Oh it's errr trying to probe apple but not dcp..
<alyssa>
Evidently my DT is really screwed up then
<povik>
rip your DT
<alyssa>
oh I think I know
<alyssa>
god linux
<alyssa>
no that shouldn't matter
<alyssa>
i swear tg
<alyssa>
Yep there we go one line DT change
<alyssa>
....and why won't Xorg start
<alyssa>
Premature celebration
<alyssa>
oh, a kernel crash fun
<Glanzmann>
povik: I just tried to compile you tree, so what I did is the following: I extracted your commits, than I took v5.16-rc4, applied the tree from jannau and than applied your patches (all but 562e8c388a6976ef472d17cda7b252c1bca9dccd bceause it was already in I think). Than I set the kernel options, but everytime I run olddefconfig all of your kernel options (with the exception of
<Glanzmann>
CONFIG_COMMON_CLK_APPLE_NCO=y) get thrown out, any ideas?
<alyssa>
oh, because coprocessor crashed.
<alyssa>
um.
<povik>
Glanzmann: yes, dependencies of those options are disabled
<povik>
that's why make olddefconfig doesn't do the trick
<povik>
or whatever that command is
<Glanzmann>
I see, so what should I do?
<povik>
make menuconfig can tell you what those dependencies are, you should enable them
<Glanzmann>
I see, than I go hunting and let you know how it went.
<alyssa>
Why would the DCP crash on asahi-sound+DCP :|
<Glanzmann>
povik: When I do a 'git grep CONFIG_APPLE_ADMAC', I get only one hit (drivers/dma/Makefile:obj-$(CONFIG_APPLE_ADMAC) += apple-admac.o) but it doesn't seem to be in any kernel config file, how can that work?
<povik>
hmm, i may be missig something, let's see
<j`ey>
Glanzmann: it's APPLE_ADMAC'
<j`ey>
in Kconfig it doesnt have the CONFIG_
<Glanzmann>
j`ey: Just found it, I shut up and go hunting.
<Glanzmann>
povik: This was my fault.
<povik>
hey we all do them
* alyssa
is feeling pretty dumb herself
<alyssa>
So far things are strictly more broken than they were this morning :V
<alyssa>
sven: what happened with tx_prepare / dma_wmb
<alyssa>
and with BUFFER_REQUEST_IOVA changing
<povik>
Glanzmann: i think you can look up dependencies in make menuconfig, searching by option name
<sven>
what do you mean 'what happened'?
<Glanzmann>
Thank you for the tip. I was searching for it. Just found the first one.
<povik>
great
<alyssa>
sven: I'm looking for changes between my branch and povik's to figure out why DCP broke
<alyssa>
I notice rtkit had those changes, wanted to know if that might have been relevnat
<j`ey>
so rtkit needs them, or is it users of rtkit?
<j`ey>
ok ^
<alyssa>
what gets me is that the breakage is only when starting Xorg
<alyssa>
the initial modeset in fbcon works fine, and weston starts ok
<alyssa>
apple mbox was changed substantially between mainline and the old version I had, maybe that was implicated
<alyssa>
no functional changes other than compatible strings which I already fixed
<alyssa>
it's crashing during set_digital_out_mode
<alyssa>
Hm.
<alyssa>
It successfully did a mode set (fbcon) to 96, 34
<alyssa>
no
<alyssa>
It successfully did a mode set (fbcon) to 90, 72
<alyssa>
Starting X tries to make it mode set to 96, 34 which fails
<Glanzmann>
povik: I selected every option, but I can't select this one: CONFIG_COMMON_CLK_APPLE_NCO=y - It does now show up in th menu, see screnshot: Are you compiling using a cross compiler or native? - https://ab34.de/u/screenshot-t490-2021-12-12-18_47_40.png
<alyssa>
96, 34 is 1024x768, 90,72 is 3840x2160
<alyssa>
but that doesn't make sense
<j`ey>
Glanzmann: press / then type 'COMMON_CLK_APPLE_NCO'
<j`ey>
Glanzmann: it will show you what deps ae needed
<alyssa>
unless this is a soft resolution
<Glanzmann>
j`ey: I see. I'll check them again.
<alyssa>
DCP what are you doing
<alyssa>
...so funny story that broke things worse
<povik>
are you crosscompiling? do you invoke menuconfig with ARCH=arm64? (i think that's needed)
<Glanzmann>
povik: I'm cross compiling and I'm invoking it like that. But let me try to set ARCH_APPLE and see if the options show up, but then there is probably a mistake in the dependencies.
<alyssa>
I should strongly consider getting food
<j`ey>
not sure how you have ARCH_APPLE=n, its in defconfig
<sven>
uh, without ARCH_APPLE many thing won't work
<j`ey>
sven: many thing => anything :D
<Glanzmann>
Now it shows up, compiling.
<Glanzmann>
sven: Somewhat, deselected it.
<alyssa>
Okay that hack should not have fixed it. Um.
<alyssa>
Glanzmann: Now about audio. Should I see be seeing any ALSA devices?
* alyssa
sweats
<povik>
you should
<povik>
aplay -l
<alyssa>
no soundcards found
<povik>
:(
<povik>
post your dmesg
<Glanzmann>
alyssa: You need to search for every of these options:
<povik>
Glanzmann: yeah, me using clang is probably why i didn't see that
aleasto has quit [Quit: Konversation terminated!]
<alyssa>
and me setting WERROR=n
<Glanzmann>
povik: It booted up, started X and I think it crashed but it could also mean that it deselected more stuff in the config and I just don't have any device drivers for usb and network
<Glanzmann>
I have autostart X
aleasto has joined #asahi-dev
aleasto has quit []
<Glanzmann>
povik: Do you have a kernel and dtb with nvme and network in it, than I can try to boot your binary blob.
<Glanzmann>
I also still have macos 11 on that system, maybe I should upgrade to macos 12.1.
slicey has joined #asahi-dev
<povik>
Glanzmann: i do have such blob
<povik>
macos version should be irrelevant for audio hw
bps2 has quit [Ping timeout: 480 seconds]
aleasto has joined #asahi-dev
the_lanetly_052___ has joined #asahi-dev
bps2 has joined #asahi-dev
the_lanetly_052__ has quit [Read error: Connection reset by peer]
<alyssa>
I admit working sound on Linux+M1 is pretty magical
<Glanzmann>
povik: It is working. I heard some sound from the internal speakers.
<alyssa>
povik: regardless of alsamixer
<alyssa>
Pulseaudio doesn't seem to know about 0,1 at all
<povik>
noted
<alyssa>
Rebooting via the watchdog driver seems broken for me
<alyssa>
so let's see, today I...
<jannau>
I found the 3rd driver for the raw events from the touchpad: drivers/hid/hid-magicmouse.c
<alyssa>
+ got speaker working in my kernel thanks to povik
<alyssa>
- broke wifi
<alyssa>
- broke reboot
<alyssa>
- broke modesetting
<alyssa>
no wait reboot is ok
<alyssa>
nvm, so only 2 steps back not 3
<jannau>
in other news touchpad is working with spi hid as well
<alyssa>
jannau: woo!
<alyssa>
what do you mean 3rd?
<j`ey>
jannau: puuussshh
<jannau>
linux has 3 distinct drivers for the touchpad events. applespi (used by corellium), kettenis found bcm5974 (input device), hid-magicmouse is convenient since it is already hid
<kettenis>
ah, yes, there's that one as well
<kettenis>
i believe that code supports the apple magick trackpad
<jannau>
it does
<kettenis>
which probably uses the same hardware as the laptops
<kettenis>
the bcm5974 driver looked cleaner to me
* alyssa
gives up
<alyssa>
it was worth a try
<alyssa>
i guess i'll try again when more of this stuff is mainlined because i just cant
bps2 has joined #asahi-dev
<alyssa>
sorry
<j`ey>
:{
alyssa has left #asahi-dev [#asahi-dev]
bps2 has quit [Ping timeout: 480 seconds]
bps2 has joined #asahi-dev
<unrelentingtech>
kettenis: maybe the same hardware on the actual touch handling side but the external "magic" devices do their own processing so the packets are quite different. touches on magic already have IDs assigned
<unrelentingtech>
jannau: yeah, applespi authors copy-pasted pieces of bcm5974 instead of making their driver a HID transport for bcm5974 to run on
<unrelentingtech>
and how they pull the model number from the 107th byte of what they described as "touchpad_info_protocol with 105 unknown bytes" but really is the HID descriptor
<unrelentingtech>
on the 2015 MBP (the one with both USB and SPI) the descriptor literally is the exact same over USB and SPI
<unrelentingtech>
and the "model number" in that byte is 3, which makes sense, it's the previous one to the one applespi started with (4)
<unrelentingtech>
oh btw that byte in the decoded HID descriptor is part of: '0x96, 0xDF, 0x03, // Report Count (991)' ← the 0x03 here. that's the report count for the vendor-defined collection
<jannau>
unrelentingtech: hid-magicmouse works out of the box with my WIP SPI HID transport driver
<unrelentingtech>
as trackpad2?
<jannau>
yes
<unrelentingtech>
hm yeah, looks like they use INPUT_MT_TRACK for trackpad2 (only)
<jannau>
it even uses the same payload to switch on multitouch
<kettenis>
unrelentingtech: so the touchpad on the M1 macbook pro has 0x96, 0xd7, 0x06
<unrelentingtech>
ah well the x,y look right, they do decode a 16-bit number there
<unrelentingtech>
but the further down things in magicmouse just use 1-byte values, while the bcm5974 struct is all le16
<unrelentingtech>
kettenis: cool, so it's the same "model 6" applespi already knows about from /* MBP13,3 MBP14,3 */
<kettenis>
yup, so that's the variant of the packet that works
yuyichao has joined #asahi-dev
<unrelentingtech>
wait wh.. what are they doing in that magic trackpad2 code with `tdata[1]`. why is that byte in both X and Y o_0
<kettenis>
so the numbers are decoded as two 13-bit numbers encoded in 4 bytes
<unrelentingtech>
wait are they getting the same result as ` c->y.min + c->y.max - raw2int(f->abs_y)` from bcm5974 with.. this
<povik>
Glanzmann: pushed DTs with added jack codec across all M1 devices, it's in asahi-sound, so if you get it compiled, you can try that on the air
<Glanzmann>
povik: Thank you, I'll try and let you know.
<povik>
thank you too :)
<Glanzmann>
Btw. I have now another problem with my mini. I updated it to macos 12.1. And now the mini does not produce an output on my eizo or hdmi grabber. But I can chainload using proxy and boot linux using proxy. If I boot macos by pressing the poewr button long, no issue. I tried dozens of power cycles and reinstalled m1n1 twice. I also put my self compiled m1n1. Any ideas?
<j`ey>
yes, apple broke something
<Glanzmann>
j`ey: I see, what did you do? Did you downgrade the 'm1n1' Linux 2.5 GB partition to an older macos version?
<j`ey>
I'm not sure if that is possible, maybe you have to make another partition
<j`ey>
or maybe you cant even downgrade like that at all?
<j`ey>
if the system firmware is 12.0, you might not be able to sinstall 11
<j`ey>
(I just stuck with 11 so far)
<sven>
you can't downgrade SMC, ANS and uhhh.. SEP.
<sven>
but the rest can be downgraded from 1TR
<Glanzmann>
So this is a known problem?
<sven>
yes
<Glanzmann>
Has soemone managed to get it running again?
<sven>
no idea
<Glanzmann>
I see, thank you.
<j`ey>
I think you can run dcp.py to fix it
<Glanzmann>
j`ey: Good idea, I'll try this right now. Btw. do you know how you change the resolution using dcp.py? Alyssa once told me, but I probably no longer have the code.
<Glanzmann>
dcp.py did not do the trick. I now try to downgrade using the asahi installer.
<j`ey>
I dont
<Glanzmann>
I see, thanks.
<Glanzmann>
sven: I once accidently deleted my 1tr partition and had to survive the mac using a second mac, does that maybe pull the trick?
<sven>
do what trick?
<Glanzmann>
To revert the firmware so that I have hdmi output on the mini again.
<sven>
no
<Glanzmann>
I see.
<sven>
we'll probably have to speak the iBoot DCP protocol in m1n1 to make that work
<Glanzmann>
I see. That will be interesting.
<Glanzmann>
sven: I did the following. I deleted the 2.5 GB stub partion, ran the installer again and installed macos 11.4 (first option) after that I have a visual again on the mini.
<Glanzmann>
So my mini is back usable (m1n1, xorg and so on).
<sven>
yeah, just like i said
<j`ey>
great
<Glanzmann>
sven: I missed that, sorry.
<Glanzmann>
I thought there was no solution so far.
<sven>
that's hardly a solution
<sven>
it's a workaround at best
<Glanzmann>
I thought once the firmware was updated to 12.1 you could not go back.
<sven>
21:31:37 <sven> but the rest can be downgraded from 1TR
<Glanzmann>
sven: I agree, but it lets me use my device for the time being.
<Glanzmann>
sven: I see.
jmr2 has joined #asahi-dev
<jmr2>
sven: just trying to understand that last bit. The wiki says "iBoot2 (per-OS copy) loads auxiliary CPU engine firmwares from OS APFS Preboot partition".
<jmr2>
There's an exception for SMC/ANS/SEP? Where's the firmware stored for those?
<sven>
exactly
<sven>
ANS is stored on the NOR flash
<kettenis>
ANS is needed to load firmware from NVMe
<sven>
no idea about the rest but i'd assume the rest is stored in there as well
<sven>
SEP is where all their security is, they probably don't want you to ever downgrade that ;)
<jmr2>
kettenis: It makes a lot of sense once you put it that way.... Woops...
aleasto has quit [Quit: Konversation terminated!]
<j`ey>
what about custom SEP firmware sven? :P
<sven>
sure, just find me a secure boot bypass for that one :P
aleasto has joined #asahi-dev
<jmr2>
I'm wondering whether the NOR flash could be backed-up and restored, but I'd bet that their online authentication would foil that.
aleasto has quit [Remote host closed the connection]
<jmr2>
Once again, thanks !
<sven>
SEP also has (limited) internal non-volatile memory afaik
<sven>
and i'm pretty sure they store a anti-replay counter in there
<sven>
it also doesn't really matter to us. it probably even helps since it means that ANS and SEP will be backward-compatible