<div dir="auto">Cool, that's the plan.<div dir="auto"><br></div><div dir="auto">Yes, I believe it will limit the accessible RAM since page-faults never occur (due to the repetitive mapping), and we never map anything beyond the first 1 GiB of physical memory.</div><div dir="auto"><br></div><div dir="auto">I think the simplest paging scheme later will be identity mapping virtual to physical addresses. I'm just not sure of unintended consequences due to this (for eg. with the linker script's structure influencing memory-mapped devices). I guess we'll look into this when we come to it, though.</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jul 31, 2018, 1:28 AM Joel Sherrill <<a href="mailto:joel@rtems.org">joel@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Jul 30, 2018, 2:27 PM Amaan Cheval <<a href="mailto:amaan.cheval@gmail.com" target="_blank" rel="noreferrer">amaan.cheval@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Quick status update: in working on the APIC timer, as a prerequisite,<br>
I've had to setup access to the Interrupt Descriptor Table (which is<br>
great because it helps us have the basic interrupt support we need at<br>
least).<br>
<br>
Another minor issue I've run into is the fact that the APIC is located<br>
at physical address 0xfee00000 by default on most x86 processors - per<br>
the FreeBSD bootloader's paging scheme, they map every GiB of virtual<br>
memory to the first 1 GiB of physical memory (0x40000000).<br>
<br>
As a workaround, I'll probably just move the APIC address to within<br>
this accessible range (through a Model Specific Register) with an<br>
"XXX" comment about creating a better paging scheme later.<br>
<br>
Let me know if anyone thinks better paging support should also come<br>
first! If not, what's next is initializing the PIT to calibrate the<br>
APIC timer, and then we should have a pretty nice and self-contained<br>
clock driver for the x86_64 port too.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Make the clock tick and timer driver work first. </div><div dir="auto"><br></div><div dir="auto">Will this have any impact on the amount of RAM accessible until this is fixed?</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Wed, Jul 18, 2018 at 7:53 PM, Gedare Bloom <<a href="mailto:gedare@rtems.org" rel="noreferrer noreferrer" target="_blank">gedare@rtems.org</a>> wrote:<br>
> On Wed, Jul 18, 2018 at 10:17 AM, Joel Sherrill <<a href="mailto:joel@rtems.org" rel="noreferrer noreferrer" target="_blank">joel@rtems.org</a>> wrote:<br>
>><br>
>><br>
>> On Wed, Jul 18, 2018 at 12:31 AM, Sebastian Huber<br>
>> <<a href="mailto:sebastian.huber@embedded-brains.de" rel="noreferrer noreferrer" target="_blank">sebastian.huber@embedded-brains.de</a>> wrote:<br>
>>><br>
>>> Hello Amaan,<br>
>>><br>
>>> On 17/07/18 19:18, Amaan Cheval wrote:<br>
>>>><br>
>>>> Hi!<br>
>>>><br>
>>>> Now that I'm working on the clock driver, we need to pick what we<br>
>>>> support first. Our options in brief are:<br>
>>><br>
>>><br>
>>> The clock driver needs an interrupt. What is the status of the interrupt<br>
>>> controller support in the BSP?<br>
>>><br>
>>> For timekeeping we use a port of the FreeBSD timecounter in RTEMS. You may<br>
>>> have a look at the FreeBSD timecounter for this architecture, e.g.<br>
>>> sys/x86/x86/tsc.c. I looks quite complicated. I would not take to much care<br>
>>> about legacy support, e.g. ignore hardware which is older than five years?.<br>
>><br>
>><br>
>> That's not a good rule for PCs at all. The APIC was first introduced as an<br>
>> external controller with the i486,<br>
>> Based on your rule, we wouldn't support it even though it is the most likely<br>
>> choice.<br>
>><br>
><br>
> I believe he meant ignore hardware that is not available from products<br>
> in the last five years.<br>
><br>
><br>
>> Avoid things that are deemed legacy. The starting point for this is the old<br>
>> PC<br>
>> System Design Guide.<br>
>><br>
>> <a href="https://en.wikipedia.org/wiki/PC_System_Design_Guide" rel="noreferrer noreferrer noreferrer" target="_blank">https://en.wikipedia.org/wiki/PC_System_Design_Guide</a><br>
>><br>
>> If it was deemed obsolete in PC2001, then you definitely want to avoid it.<br>
>> Those<br>
>> things are just now really disappearing.<br>
>><br>
><br>
> This is consistent with my interpretation.<br>
><br>
>> --joel<br>
>><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Sebastian Huber, embedded brains GmbH<br>
>>><br>
>>> Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
>>> Phone   : +49 89 189 47 41-16<br>
>>> Fax     : +49 89 189 47 41-09<br>
>>> E-Mail  : <a href="mailto:sebastian.huber@embedded-brains.de" rel="noreferrer noreferrer" target="_blank">sebastian.huber@embedded-brains.de</a><br>
>>> PGP     : Public key available on request.<br>
>>><br>
>>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
>>><br>
>><br>
</blockquote></div></div></div>
</blockquote></div>