<bauen1>
this is your daily PSA: remember to do your backups (and unless you test them you don't have backups)
2021-05-21
<bauen1>
*event
<bauen1>
i doubt this little even will be able to invalidate an xkcd https://xkcd.com/1782/ ...
<bauen1>
[TheBug]: my argument for oftc would be that it's now the most stable option
2021-05-20
<smaeul>
bauen1: D1 has a single combined NBROM/SBROM with a lot of "if secure mode" checks throughout (so a lot of opportunity for bugs)
<suniel>
apritzel, bauen1, smaeul: when you say: "with most allwinner chips there's fel that gives you execution access over usb, and that usually can't be disabled ; and fel can often be used to read/write the efuses again breaking secureboot if you have usb access"
<suniel>
apritzel, bauen1, smaeul: thanks guys for your inputs
<apritzel>
this is at least what smaeul and bauen1 did ...
<bauen1>
btw is there anything known about allwinners risc-v chip security features (if any) ?
<bauen1>
another thing, with most allwinner chips there's fel that gives you execution access over usb, and that usually can't be disabled ; and fel can often be used to read/write the efuses again breaking secureboot if you have usb access
<bauen1>
and secure boot on allwinner is very rarely used (because there's no documentation and because the implementation is often broken)
<bauen1>
actually there's an u-boot branch where i pushed some of my tests
<bauen1>
suniel: i've never published anything, but if you can explain your threat model a bit i can tell you if it's possible to achive on the H6 (and therefor likely to be achievable on the H3)
<bauen1>
smaeul: suniel: you could still use the efuses to store a secret key (but that is subjected to limitations) coupled with secure boot
<suniel>
bauen1: is it possible to share any document/writeup(if it exists - which has some sort of steps) for the secureboot you implemented on H6
<suniel>
bauen1: search on google, looks like couple of people have implemented secure boot on H3, but findings are not that clear
<suniel>
bauen1: thats a good experience you shared, then i will do research BROM a bit
<bauen1>
suniel: well, the h6 does implement signature verification of the bootloader, but there's 1-2 bugs that allow one to bypass it if you have write access to the boot medium (so linux root or basic physical access)
<bauen1>
suniel: yes
<suniel>
bauen1: so you are saying that, you have attempted secure boot on H6 and eventually found out that H6 sbrom is not secure(meaning secure boot not achieved) ?
<suniel>
bauen1: so chain of trust is continued till linux + initrd (like sbrom verifies spl, spl verifies uboot and uboot verifies linux)
<bauen1>
with u-boot i had a sbrom -> toc0 signed-image spl -> u-boot -> linux + initrd ; where the spl and u-boot itself both do signature checks
<bauen1>
suniel: that's possible to do (i've at least attempted it on a pine h64) but it won't be secure if the h3 sbrom is anything similiar to the h6 sbrom
<suniel>
bauen1: we want to implement secure boot authentication and encryption for H3 SOC based target
<bauen1>
suniel: oh and just a heads-up secureboot on devices including the h6 and earlier are probably insecure to some extend
<bauen1>
suniel: also what exactly is your usecase ?
<suniel>
bauen1: thanks for the advice. will go through the logs
<bauen1>
suniel: well, secureboot for allwinner in general, keywords: a64, h6, toc0, sbrom, efuse, fuse
<suniel>
bauen1, you mean about secure boot for H3 ?
<bauen1>
suniel: you should also take a look at the chatlogs of this channel, as not everything has made its way into the wiki
2021-04-29
<apritzel>
bauen1: so the first thing the H616 BROM checks, is bit 15 at 0x070001a0, but it just writes something different back, depending on the result
<bauen1>
it's actually been quite a while since i last touched my h6 :/
<bauen1>
but iirc the super standby detection is in very very early boot, so the magic values / addresses should be easy to find out
<bauen1>
apritzel: i don't have a h616 and haven't taken a look at its brom yet
<apritzel>
bauen1: smaeul: and this super standby is different right, both in terms of the key and trigger mechanism and also that it requires an eGON image in memory?
<apritzel>
bauen1: smaeul: there was this "felreset" trick for the H6, where we write the magic plus address into RTC_BASE + 0x1b8/0x1bc, then do a watchdog reset
2021-04-16
<bauen1>
apritzel: in the best case allwinner will recycle a lot of peripherals, but i haven't found any technical docs yet (didn't look too closely), maybe pine64 has already gotten some
<bauen1>
montjoie: i also haven't found anything better than the "press release", and that after experimenting with the h6 / a64 i'm not expecting anything too "good" / "interesting" tbh
<bauen1>
re the D1, are there any more details available on any security elements of the chip ? the "press releases" where a bit light on details
2021-02-19
<bauen1>
how does apple do these things ? is apples push notification service just that ? except that you only need to wake on one single tcp connection ?
2021-02-15
<bauen1>
mripard: with a "free" ISA there is nothing legally preventing you from implementing your own CPU (or softcore) and there for also makes it easier (but a pipe dream probably) to open source the hardware, at least i think so
<mripard>
bauen1: I don't really see how the "freeness" of the ISA changes things compared to a public one like the ARM ISA is
<bauen1>
a free ISA should make it easier, still not practical but easier
<bauen1>
true true, and allwinner doesn't just give out details for free :/
<apritzel>
bauen1: but that's mostly an integration choice anyway, isn't it?
<bauen1>
but details on the security side of the risc-v core are pretty non-existent over the web as far as i can find
<bauen1>
shouldn't the specific optimisations (-fxxxx) then be enabled by default instead of enforcing -O >= 1 ?
2021-02-03
<bauen1>
^ linux kernel 5.10
2021-01-31
<bauen1>
smaeul: another idea, if the sbrom is anything like the h6, find the first non-0 word from the end and then start dumping there, with a bit of luck it's the fel enter code
<bauen1>
at the cost of potentially bricking the board forever if you're not careful
<bauen1>
smaeul: and i haven't tried this, but if you're willing to sacrifice a few sid bytes you could use it to get some more code and call it from rtc, that could allow you the space to implement uart
<bauen1>
now i kind of want one ...
<bauen1>
smaeul: stack smashing can be prevented by clever signing, so that would could make the h616 "secure" against "conventional" attacks
<bauen1>
so loading some code into sram is a bit more difficult
<bauen1>
smaeul: and keep in mind that at the time the rtc hotplug is (presumably) checked sram was still disabled on the h6 and required setting some magic bits to enable
<bauen1>
i suppose you could still try to do that by resetting the h616 at just the right time before the sram is cleared, but that's annoying to do
<bauen1>
so they've actually done things mostly right this time
<bauen1>
oh wait no sram is cleared
<bauen1>
smaeul: maybe try to see if the "nbrom jump code" is copied to the same address as the h6, or use the rtc to find the address of something that looks like it then dump it
<smaeul>
bauen1: it is cleared by NBROM first thing in the FEL entry path. I assume SBROM probably clears it first thing as well, but I haven't checked
<bauen1>
oh and worst case you could also try to do a power fault injection attack to bypass toc0 verification, might need an fpga
<bauen1>
smaeul: is the sram cleared by sbrom or nbrom and if it wasn't would that help ?
<bauen1>
smaeul: but does the hotplug trick still work (and you have ~0x20 bytes of storage to work with ?) ?
<smaeul>
bauen1: I don't know where the BROM switch is. that's the problem.
<bauen1>
well that might make this also not work then
<bauen1>
smaeul: or maybe try to switch to the nbrom and jump to $0x0
<bauen1>
smaeul: you could also use the led (or other gpio) to transmit data
<bauen1>
something like `./sunxi-fel writel 0x07022000 0x17777777 writel 0x07022010 0x80 # set link led on`
<bauen1>
though knowing how the sbrom looks makes it easier ...
<bauen1>
smaeul: you can put enough code into the rtc "general purpose" to do some magic probably
<smaeul>
bauen1: RTC trick would not work because entire SRAM is zeroed when entering BROM
<bauen1>
and the rtc trick (cpu 0 hotplug) didn't work either ?
<bauen1>
and from all this i assume that you don't yet have an image that is actually accepted ?
<bauen1>
smaeul: i'm still confused, so if you supply an extremly long toc0 image (which one btw) what happens ?
<smaeul>
bauen1: it's hard to say exactly what happens without the SBROM code, but it appears that the stack smashing works when it tries to enter FEL
<bauen1>
smaeul: so stack smashing using an evil toc0 image doesn't work and it just goes to FEL ?
<bauen1>
hm sounds interesting
2021-01-06
<apritzel>
bauen1: the low current measurement path is protected by an 200mA fuse, and that's easy to exceed (accidentally)
<bauen1>
i mean consumer grade extension cords are usually limited to ~3.5kW around here
<bauen1>
apritzel: if you can give me commands to pass to sunxi-fel then i can test mine too, i got this board for free from tllim a few months back (wow time really does fly)
2021-01-05
<apritzel>
bauen1: ... and from Linux as well. Keep in mind that the green LED stays on, as it just signals voltage on the power connector (it's not behind the PMIC)
<apritzel>
bauen1: so poweroff works on my Pine H64, from U-Boot at least (CMD_POWEROFF)
<apritzel>
bauen1: Re: OR1K cross-compiler: but yeah, I hear you. distros should provide toolchains
<bauen1>
apritzel: yes
<apritzel>
bauen1: what board is this? Pine H64?
<apritzel>
bauen1: poweroff should work without crust
<bauen1>
so crust is also responsible for proper power-off / reboot, that explains why my initial gentoo test just kind of hanged after poweroff
<bauen1>
apritzel: i've compiled gcc often enough, that i like avoid it when possible :D
<apritzel>
bauen1: it's not too hard to compile a stage 1 cross compiler yourself
<bauen1>
having gcc-10 with or1k would be useful just so i can compile crust without another major hurdle
2021-01-04
<bauen1>
u-boot really is the best
<bauen1>
huh, this is funny, the more often i rebuild uboot, the larger the resulting binary seems to get :D
<bauen1>
ugh, the spc on the h6 is kind of weird, i think i've found the register responsible to set the secure / non-secure mode, but i can't get it to work reliably and i also can't find the exact bit responsible
<bauen1>
but even for power glitching you want to be as close to the target to make things more reliable
<bauen1>
ah i see
<bauen1>
apritzel: including physical access in a threat model is quite difficult due to how many things you could potentially do
<bauen1>
lol
<bauen1>
a tiny bit of power glitching will probably get you past the SBROMs certificate check too
<bauen1>
at the end of the day it's all a matter of how much money or wrenches the attacker has
<bauen1>
apritzel: i've defined my threat model to have sort-of physical access but with some pretty big restrictions on what you can do to the SoC itself, which does make it rather pointless
<bauen1>
but yes, generally it's a bit of a pointless exercise
<bauen1>
though i must say that the arm isa is also very appealing
<bauen1>
apritzel: i would love to have a "secure" system containing only libre open source components, but currently i'm a bit on a budget so i might as well experiment with some cheaper chips and see how far i get
<bauen1>
also removing bga chips doesn't strike me as very complicated, soldering on an fpga connector or something like that might be (https://youtu.be/zdvvk0NdAy0?t=218)
<bauen1>
*there's always the 5$ wrench crypto bypass
<bauen1>
there
<bauen1>
apritzel: yes i am too paranoid, but it's fun and risc-v isn't quite in my price range yet
<apritzel>
bauen1: are you sure you are not too paranoid here? If you are worried that people can attack and intercept a BGAed DRAM, then I am not sure using an Allwinner chip is the right solution to begin with ...
<bauen1>
apritzel: i assume that the attacker can modify/read dram with very low cost, but accessing sram is a bit harder
<apritzel>
bauen1: but there is no code other than your SPL running, and you just checked that every component is trustworthy, before jumping away to the next image
<bauen1>
apritzel: i don't want to have the image in dram being modified after it has been verified but before it's being copied and jumped to
<bauen1>
apritzel: thanks for reminding me, i need to check if it copies first and then verifies or the other way around
<bauen1>
apritzel: you mean of keeping everything in SRAM or still using the SPL ?
<apritzel>
bauen1: I understand that part, but still not sure what your concern is
<bauen1>
apritzel: i suppose i'm kind of (ab)using spl as better boot rom that supports proper signature checks
<bauen1>
why does u-boot have any form of support for the IOMMU ?
<bauen1>
yes, u-boot makes up about 565kb of the entire fit, so if i can move that out of the way in some form that would be awesome
<bauen1>
ops
<bauen1>
724
<apritzel>
bauen1: (if that was your concern)
<bauen1>
apritzel: i don't care about u-boot being in dram, i just don't want secure-world stuff touching dram without integrity checks / encryption
<apritzel>
bauen1: I think we switched the way the FIT image is created, from external to embedded
<apritzel>
bauen1: the whole point of the SPL is to enable DRAM, so that it can load the actual U-Boot
<apritzel>
bauen1: ???
<bauen1>
it is a nice ~700kb, so some size reduction is necessary before i can think about puttint that into sram
<bauen1>
but i think the spl is still loading the u-boot fit image into dram, which is bad
<bauen1>
plus `288 dts/dt-spl.dtb` and maybe 1-2kb overhead from the toc0
<bauen1>
apritzel: 61456 spl/u-boot-spl-nodtb.bin
<apritzel>
bauen1: how big is the SPL then?
<bauen1>
KotCzarny: the chip is fine, so i don't see a problem here
<bauen1>
it seems that i can actually get the spl to do the most important buisness completely in sram, the stack and bss section aren't that big
<bauen1>
if the chip doesn't melt, then the temperature is fine /s
<bauen1>
i've now "added" (read as: hacked on) fdt configuration signature verification to the spl, and it now only boots atfs that have been signed
<bauen1>
apritzel: no
<apritzel>
bauen1: does the BROM clear the hotplug registers at some point?
<bauen1>
hm, maybe i'll do some diggign in the nbrom why it might not work
<apritzel>
jernej: bauen1: re felreset: I checked again: on the H6 the sequence indeed works, but not on the A64
<apritzel>
bauen1: not easily, but you can hack in a U-Boot command that dumps the CurrentEL system register
<bauen1>
on that note, is there an easy way i can use to check what mode u-boot is being executed in ?
<bauen1>
which is why i would be surprised if the processor still boots to fel fine if you remove power from Vcc but keep Vcc-RTC on, preserving the RTC values but clearing everything else (including what seems to enable the SRAM chips)
<bauen1>
some care needs to be taken, since directly calling the fel skips some important bits of the n/sbrom that enable some SRAM chips and some clocks
<apritzel>
bauen1: ha, thanks, I think you found my bug ;-)
<bauen1>
or right, the fel_enter offset in the nbrom on that chip might be different
<bauen1>
apritzel: so something like `mw .w 0x01F001b8 0xFA50392F`, `mw .w 0x01f001bc 0x20`, `reset` ?
<bauen1>
apritzel: can you try by using the same registers as the h6 but with the base address of the a64 (0x01F00000) ?
<apritzel>
bauen1: indeed, good point
<bauen1>
apritzel: but then they might not be part of the rtc (and thus might not survive a watchdog reset)
<apritzel>
bauen1: by "works" I mean with an RMR reset, which is just resetting the core
<apritzel>
bauen1: they are in the CPUCFG block, but it works, as this is what I use for the SPL 64-bit FEL return
<bauen1>
apritzel: are the hotplug registers part of the rtc (0x01F00000) in a64 ? i don't see them in the manual
<apritzel>
bauen1: the hotplug registers are elsewhere, but BROM is at 0x0 as well
<bauen1>
apritzel: doesn't the A64 have the brom somewhere else ?
<bauen1>
they survive anything short of a write or loss of power to both Vcc and Vcc-RTC (or voltage drop below 1.7v or something like that)
<bauen1>
apritzel: they do
<bauen1>
jernej: yes, the trick above is untested
<bauen1>
apritzel: did reset the board or trigger a reset from u-boot of some form ?
<bauen1>
so something like `mw .w 0x070001b8 0xFA50392F`, `mw .w 0x070001bc 0x20`, then reset the board
<bauen1>
s/be/get/
<bauen1>
jernej: if you write the wrong values, the board could be stuck in some form of loop until you clear the registers (stored in the RTC and therefor retain their values if Vcc-RTC has power)
<bauen1>
basic idea is `writel 0x070001b8 0xFA50392F writel 0x070001bc 0x20`, trigger reset without disrupting power to Vcc-RTC
<bauen1>
jernej: but just to be sure, you do have a way of completely removing power to the processor in case things go bad ?
<bauen1>
"easy" as in 3 memory writes and triggering a reset, let me dig those up
<bauen1>
jernej: oh then it's easy
<bauen1>
jernej: what is the processor ?
<bauen1>
jernej: then you need to trigger a board reset after writing some magic values and the jump address into magic registers, iirc apritzel actually made a patch that does that
<jernej>
bauen1: thanks, but it's in 64-bit mode
<bauen1>
jernej: triggering a jump to NBROM+0x20 in AArch32 mode should do the trick, not sure if u-boot offers a nice way of doing that
<bauen1>
but the amount of dark magic required is a bit much currently
<bauen1>
nice, i got verified boot from spl -> u-boot to work
2021-01-02
<bauen1>
finding my issue with u-boot so "quickly" is great, it only gets worse from here :D
<bauen1>
smaeul: by the way, do you plan on submitting the mkimage toc0 patches to upstream u-boot ?
<bauen1>
but for now a complete verified boot would be a nice thing to have
<bauen1>
OP-TEE seems to have the features necessary to swap integrity protected / encrypted pages from dram <-> sram when necessary, but it also requires >=250kb sram
<bauen1>
but i only really care about the secure world for that so just maybe
<bauen1>
apritzel: i mean, the theoretical goal would be to prevent attacks that modify / read dram (using external methods, or maybe rowhammer (?) ), but with this little SRAM that might not be possible
<apritzel>
bauen1: for the arm64 SPL we were/are so short of memory, that we have to pull many ugly tricks
<apritzel>
bauen1: I think this is one of the main purposes of U-Boot: annoying developers ;-)
<bauen1>
ideally i don't want to use DRAM, but that is a goal for later :D
<bauen1>
apritzel: i mean, technically it's my fault, but u-boot sure does offer you plenty of ways of hurting yourself
<apritzel>
bauen1: yeah, the SPL is quite fragile
<bauen1>
after a lot of "led debugging" i've figured out why spl was broken, turns out reading from dram without initializing the controller just doesn't really work (caused by the spl thinking that the device tree was after the bss section)
<bauen1>
i've now got a similiar patch to increase the spl size on a h6, but lack a "normal" board to test it with, it works fine with toc0 and smaeul mkimage, so if someone has some interest in that and time to test it, i could also put it up somewhere
<bauen1>
basically `gd_fdt_blob()` returns NULL in my configuration, just need to figure out why, hopefully related to my configuration, but i'll have to do that later
<bauen1>
it might be related to me disabling CONFIG_DM_SPL despite SPL_FIT_SIGNATURE depending on it (and patching out the single call that i could find)
<bauen1>
in my code
<bauen1>
or not so good because i don't really know how to fix it
<bauen1>
nice, i've probably found a NULL pointer dereference in u-boots spl
<bauen1>
actually, it might be the signature code causing some weird error, just adding a massive printf works, but enabling the code that does the signature checks breaks
<bauen1>
but anything above that results in errors of some kind
<bauen1>
yup, 48KiB seems to work
2021-01-01
<bauen1>
or rather, the second that i push the spl just over ~32kb, resulting in padding to 60kb (wtf that shouldn't happen) things just kind of break randomly
<bauen1>
so there's probably more to it
<bauen1>
alrighty, so after some testing hunting down heisenbugs, it seems that "just" setting the size to 63kb doesn't work
<bauen1>
but that is something to go of
<bauen1>
kind of stuck on `## Checking hash(es) for Image atf ...` :D
<bauen1>
huh, great so this works now to some extend
<bauen1>
smaeul: does binman use CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR or do i need to turn some additional knobs for that ?
<apritzel>
bauen1: to be honest, I only built a 40KB SPL from the *U-Boot source* so far, there might be more surprises (in the build system, memory map or linker scripts) if we exceed certain limits like 64KB
<bauen1>
yes, and it seems to happily load parts of itself without any form of checksum whatsoever, at least that is my hypothesis
<bauen1>
which i need to switch to fit anyway for verification
<bauen1>
probably legacy image loading
<bauen1>
yes, so making the spl bigger (up to maximum of ~63kb) seems to work but for some reason the spl then just starts entering some kind of loop of printing the welcome message, probably after loading something from the sd
<bauen1>
apritzel: thanks, the last patch is what i'm looking for
<apritzel>
bauen1: for my large SPL tests I just had less than 8KB of code, filled up with a pattern up to the limit, which got verified by the code
<bauen1>
apritzel: so i've tried to up the spl size to 64kb (minus toc0 magic bytes ~2kb ?) but it fails to execute properly, it actually loads as evidented by a lack of fel, i've setup the headers so the toc0 firmware isn't actually moved (the copy still happens but is effectively a nop) to 0x20840, could this be because after the 32kb SRAM A1 comes the SRAM C which is shared with AR100 and "weird" according
2020-12-31
<apritzel>
bauen1: and on the H6 the BROM does even boot larger SPLs (up to 139KB) with an eGON header (w/o the secure fuse burnt)
<apritzel>
bauen1: I see, thanks. I thought that this limit was somewhat artificial, just wanted to point out that the SPL can go beyond 32KB (we need this for the H616 already)
<bauen1>
i'll just worry about that when i run out of memory to put things
<bauen1>
actually, probably quite hard, there's only 32k + 80k sram, part of which will be used up by the trusted-firmware-a, so very tight, even if you swap+encrypt pages to dram when possible
<bauen1>
yes, ideally i would use all available sram as secure, including the spi flash as secure peripheral, but even then things are tight
<bauen1>
but yes, using vendorid is good enough, and leaves more bytes for the secure state encryption key and rollback counter
<bauen1>
if you smash the stack you can do just about anything you want
<bauen1>
you could even put the old image at the backup spl location for automatic fallback i think
<bauen1>
right, not as smooth as possible, but doable
<bauen1>
so you would need to first boot with a new image signed by the old key
<bauen1>
but doesn't the sbrom do a == check on the vendor id ?
<bauen1>
oh right
<bauen1>
smaeul: my idea would be to start the bootloader with a tiny shim that loads the current rollback counter (e.g. from sid or rtc) and then compares it to its own, update the rollback counter if necessary or prevent boot
<bauen1>
the "documented" rollback counter registers of the trusted watchdog are also not persistent, so that is annoying
<smaeul>
bauen1: you could implement the rollback counter using the vendor ID
<bauen1>
smaeul: i would have to double check the sbrom dump, but i don't think the sbrom actually implements the rollback counter
<bauen1>
i think rollbacks could be prevented by having a tiny shim at the start of any signed boot code that does the rollback counter check
<bauen1>
there's a few other concerning things too, i don't really want to have anything up to a firmware tpm implementation touch dram at all, but that might not be possible without some heavy patches ; and the sbrom still lacks rollback pervention
<bauen1>
still even with 64kb i'm having trouble fitting the spl, since the fit_signature features requires massive amounts of code, just for a simple rsa implementation
<bauen1>
yes, i just mean without that shim, but everything works fine now
<bauen1>
there is no optimization, but i would like to avoid having "two" copies of the bootloader in memory, especially if i later need to abuse those header fields to make sure the header is signed
<smaeul>
bauen1: I use what I pushed, so CONFIG_SPL_TEXT_BASE (== 0x20060). the memmove() is unconditional, I don't know if there's an optimization to skip copying when src == dst
<bauen1>
oh, looks like it was trying to boot some left over spl
<bauen1>
the spl is loaded and activates uart before going into a loop of printing its version
<bauen1>
smaeul: so far i've used pine_h64_defconfig, adjusted SPL_TEXT_START = 0x20840 and then used mkimage with '-a 0x20840', which should result in not copying the spl around at all
<bauen1>
smaeul: by the way, did you try using mkimage to put the spl directly into the toc0 image ?
<bauen1>
you first need to know about the feature, and allwinner has done a good job hiding that it exists lol
<smaeul>
bauen1: right, that's all it is
<bauen1>
i mean i can still use it, security by obscurity isn't bad, it just shouldn't be the only thing
<bauen1>
yet they named it "CRYPTO", gotta love allwinner manuals
<bauen1>
yes, that looks like it
<smaeul>
bauen1: it looks like there is some fixed component, then the key is shuffled and XORed with the data https://tpaste.us/N8nm
<bauen1>
actually that means i have 64kb *facepalm*
<bauen1>
but i only have 1 instruction to ensure the size doesn't exceed 128kb, and just storing zeros in the upper two bytes is simple enough
<bauen1>
apritzel: the 32kb limit is artificial and created by my code in the rtc that "patches" the sbrom to make it actually secure, in theory the h6 can boot a toc0 image up to around 128kb
<bauen1>
so with scrambling it just mixes where the values are actually stored, so that they're no longer stored in a linear order ?
<bauen1>
thanks, i'll take a look then when i get to the point of having crust working
<smaeul>
bauen1: it's address-dependent, so it breaks DRAM size detection if enabled at that point. the easist way to play with it is from the crust "shell"
<bauen1>
smaeul: nice, do you have some example code of getting DRAM scrambling on the a64 or some general idea of what it does (just xor, or maybe something more complicated ?)
<smaeul>
bauen1: the "crypto" registers in the RTC are for DRAM scrambling, which I was able to get working on the A64
<smaeul>
bauen1: All I know is the SPC register layout (confirmed against the BSP once I knew what to look for), not the meaning of individual bits
2020-12-30
<apritzel>
bauen1: smaeul: do those CPU hotplug registers (magic + start addr) survive a watchdog reset? Or only a core reset?
<apritzel>
bauen1: where does this "hard 32KB" limit come from?