04:05 <mtrbot-ml> [mattermost] <sb10q> @astro I don't understand the comment "The stack must not be in OCM because core1 still has to initialize its MMU before it can access DDR."

04:05 <mtrbot-ml> [mattermost] <sb10q> did you mean, "The stack must not be in DDR..."

04:05 <mtrbot-ml> [mattermost] <sb10q> @astro why are you aligning the BSS section to 16KB?

04:09 <mtrbot-ml> [mattermost] <sb10q> @astro any comment about logging in drivers?https://git.m-labs.hk/M-Labs/zc706/issues/18

04:22 <mtrbot-ml> [mattermost] <sb10q> @astro can a core reset itself? if a core does ``slcr.a9_cpu_rst_ctrl.modify(|_, w| w.a9_rst1(true))`` on itself then the reset will stay asserted and the core will essentially lock up, correct?

05:26 <mtrbot-ml> [mattermost] <sb10q> "Examples of registers modified by the BootROM are listed in Table 6-22. [...] These values were obtained from test run on the ZC702 board with the 7z020 production device and the ZC706 board with the 7z035/7z045 production devices."

05:26 <mtrbot-ml> [mattermost] <sb10q> as if those were physical characteristics and not something deterministic produced by their software :|

05:27 <mtrbot-ml> [mattermost] <sb10q> the zynq boot process is one big mess

22:56 <mtrbot-ml> [mattermost] <astro> from TRM section 3.7 Application Processing Unit (APU) Reset:

22:56 <mtrbot-ml> [mattermost] <astro> > [...] a CPU cannot run the code

22:56 <mtrbot-ml> [mattermost] <astro> that applies the software reset to itself. This reset needs to be applied by the other CPU or through

22:56 <mtrbot-ml> [mattermost] <astro> JTAG or PL.

22:57 <mtrbot-ml> [mattermost] <astro> just a remnant from getting a first boot

23:16 <mtrbot-ml> [mattermost] <astro> yes, fixed, thank you. however I'm not even 100% sure that booting with stack on DDR prior per-core MMU init won't work. you could just try using a `Vec<u8>` as stack.

23:32 <mtrbot-ml> [mattermost] <dpn> @pmldrmota and I now have a working phase-coherent SUServo POC – now just to add some UI polish and clean up the code a bit…