00:40 <mtrbot-ml> [mattermost] <astro> I now see that the mmu l1_table in .bss must be 16kb-aligned but that works properly with `#[repr(align(16384))]` anyway. my old comments suggest that this has not always been the case.

01:22 <mtrbot-ml> [mattermost] <sb10q> but, using Vec<u8> as stack is the same as putting the stack in DDR using the linker script and only starting core1 after DDR has been initialized, no?

01:24 <mtrbot-ml> [mattermost] <sb10q> using the Vec<u8> address vs. addresses obtained via the linker does not make a difference, as long as core1 is kept in hold until core0 initializes peripherals

01:27 <mtrbot-ml> [mattermost] <sb10q> isn't the MMU initialized by each core and after the stack pointer has taken its value? when using Vec<u8> you still have a period of time with SP pointing to DDR and the MMU uninitialized

06:41 <mtrbot-ml> [mattermost] <pca006132> pca006132 joined the team.

08:28 <mtrbot-ml> [mattermost] <sb10q> FYI, with minor modifications the ARTIQ compiler can produce riscv binaries with upstream llvm9+llvmlite

11:38 <mtrbot-ml> [mattermost] <sb10q> @astro there's still a comment in https://git.m-labs.hk/M-Labs/zc706/commit/282b4dc69aaf61e959bd0973824a87395117d5e7 that says "Aligned to 16kB" re. the BSS

11:40 <mtrbot-ml> [mattermost] <sb10q> @astro so the stack needs a 8 byte alignment? what about the heap?

19:48 <mtrbot-ml> [mattermost] <astro> yeah, 4 bytes didn't work for stack

19:48 <mtrbot-ml> [mattermost] <astro> heap starts at DDR base

22:02 <mtrbot-ml> [mattermost] <sb10q> Not always... I want to put the whole application in DDR, ocm is too small