<div dir="ltr">hi Peter,<div><br></div><div>> English is not my native language.</div><div><br></div><div>Heraus mit der Sprache Mensch! :)<br></div><div><br></div><div>> published openly.<br></div><div><br></div><div>Somewere in the dark recesses of my mind I remembered that Native2.3.6 is fully documented, yes.</div><div><br></div><div>> simply scan for the module names in linker that need code and/or data in fast ram and allocate it there.</div><div><br></div><div>Yes, make it part of the boot code then perhaps.</div><div>But that could also be done in the dynamic linker.</div><div><br></div><div>But there is also the bit about the stack that Jörg remembered. </div><div><br></div><div>Vielleicht noch ein Bisschen am Denkplatz sitzen. :)</div><div><br></div><div>cheers,</div><div>j.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Aug 29, 2015 at 12:24 PM, Peter Matthias <span dir="ltr"><<a href="mailto:PeterMatthias@web.de" target="_blank">PeterMatthias@web.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Jan,<br>
<span class=""><br>
<br>
Am 28.08.2015 um 16:47 schrieb Jan de Kruyf:<br>
> Hallo Peter,<br>
><br>
> Don't know whether you followed the thread about Wojtek's needs in FPGA<br>
> programming.<br>
<br>
</span>I read the thread, but only fast and English is not my native language.<br>
<span class=""><br>
> I am very aware of Native Oberon's way of doing things. If you look long<br>
> and hard you will still find my name in some beta-testers list from the<br>
> time that Peter Muller ran Native + Gadgets.<br>
<br>
</span>Me too :-)<br>
<span class=""><br>
> > a static one for the inner core<br>
><br>
> This seems one of the trade secrets of ETH :) never found any code yet.<br>
> I am aware it exists.<br>
<br>
</span>The core system code was secret in last millennium. Since beginning of<br>
current millennium all code at least for the original system is<br>
published openly.<br>
<span class=""><br>
> Perhaps calling it the linker script leads people astray.<br>
> In an earlier post I wrote this:<br>
> -- So this morning I had a quick look in chapter 14 of the new 'Project<br>
> Oberon' and in the source files<br>
> -- that control the boot process. At the moment most addresses are hard<br>
> wired and difficult to decipher for a novice.<br>
> -- So I think what might be done is: make a 'boot parameter' module,<br>
> that exports just the required variables<br>
> -- with copious explanation --, that is imported into the regular<br>
> bootloader, Kernel etc.<br>
> This was in response to the need to execute code from high speed Bram<br>
> and the need to memory map hardware on his FPGA.<br>
<br>
</span>As I understood, there are two topics:<br>
a) accessing hardware in a type safety way<br>
b) utilizing fast hardware (BRAM) of the system<br>
<br>
While I see no sense in a), b) is a necessity.<br>
<br>
Until a generalized solution is found I would simply scan for the module<br>
names in linker that need code and/or data in fast ram and allocate it<br>
there. A generalized solution would be to mark code/date in a special<br>
way and let the linker do the allocation automatically.<br>
<br>
Regards,<br>
Peter<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
--<br>
<a href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br>
<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
</div></div></blockquote></div><br></div>