<div dir="ltr">Thanks Gedare. It is pushed now. Just had to find it. </div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 18, 2018 at 12:40 PM, Gedare Bloom <span dir="ltr"><<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ping -- joel<br>
<div class="HOEnZb"><div class="h5"><br>
On Fri, Jul 13, 2018 at 9:19 AM, Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br>
> This looks fine to push<br>
><br>
> On Fri, Jul 13, 2018 at 3:32 AM, Amaan Cheval <<a href="mailto:amaan.cheval@gmail.com">amaan.cheval@gmail.com</a>> wrote:<br>
>> ---<br>
>>  user/bsps/bsps-x86_64.rst | 143 ++++++++++++++++++++++++++++++<wbr>+++++++++++++++-<br>
>>  1 file changed, 142 insertions(+), 1 deletion(-)<br>
>><br>
>> diff --git a/user/bsps/bsps-x86_64.rst b/user/bsps/bsps-x86_64.rst<br>
>> index 18f80d2..19c4461 100644<br>
>> --- a/user/bsps/bsps-x86_64.rst<br>
>> +++ b/user/bsps/bsps-x86_64.rst<br>
>> @@ -1,7 +1,148 @@<br>
>>  .. comment SPDX-License-Identifier: CC-BY-SA-4.0<br>
>> +.. comment Copyright (c) 2018 Amaan Cheval <<a href="mailto:amaan.cheval@gmail.com">amaan.cheval@gmail.com</a>><br>
>>  .. comment Copyright (c) 2018 embedded brains GmbH<br>
>><br>
>>  x86_64<br>
>>  ******<br>
>><br>
>> -There are no x86_64 BSPs yet.<br>
>> +amd64<br>
>> +=====<br>
>> +<br>
>> +This BSP offers only one variant, ``amd64``. The BSP can run on UEFI-capable<br>
>> +systems by using FreeBSD's bootloader, which then loads the RTEMS executable (an<br>
>> +ELF image).<br>
>> +<br>
>> +Currently only the console driver and context initialization and switching are<br>
>> +functional (to a bare minimum), but this is enough to run the ``hello.exe`` sample<br>
>> +in the RTEMS testsuite.<br>
>> +<br>
>> +Build Configuration Options<br>
>> +---------------------------<br>
>> +<br>
>> +There are no options available to ``configure`` at build time, at the moment.<br>
>> +<br>
>> +Testing with QEMU<br>
>> +-----------------<br>
>> +<br>
>> +To test with QEMU, we need to:<br>
>> +<br>
>> +- Build / install QEMU (most distributions should have it available on the<br>
>> +  package manager).<br>
>> +- Build UEFI firmware that QEMU can use to simulate an x86-64 system capable of<br>
>> +  booting a UEFI-aware kernel, through the ``--bios`` flag.<br>
>> +<br>
>> +Building TianoCore's UEFI firmware, OVMF<br>
>> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<wbr>^^^^^^^^^^^<br>
>> +<br>
>> +Complete detailed instructions are available at `TianoCore's Github's wiki<br>
>> +<<a href="https://github.com/tianocore/tianocore.github.io/wiki/How-to-build-OVMF" rel="noreferrer" target="_blank">https://github.com/<wbr>tianocore/tianocore.github.io/<wbr>wiki/How-to-build-OVMF</a>>`_.<br>
>> +<br>
>> +Quick instructions (which may fall out of date) are:<br>
>> +<br>
>> +.. code-block:: shell<br>
>> +<br>
>> +    $ git clone git://<a href="http://github.com/tianocore/edk2.git" rel="noreferrer" target="_blank">github.com/tianocore/<wbr>edk2.git</a><br>
>> +    $ cd edk2<br>
>> +    $ make -C BaseTools<br>
>> +    $ . edksetup.sh<br>
>> +<br>
>> +Then edit ``Conf/target.txt`` to set:<br>
>> +<br>
>> +::<br>
>> +<br>
>> +    ACTIVE_PLATFORM       = OvmfPkg/OvmfPkgX64.dsc<br>
>> +    TARGET                = DEBUG<br>
>> +    TARGET_ARCH           = X64<br>
>> +    # You can use GCC46 as well, if you'd prefer<br>
>> +    TOOL_CHAIN_TAG        = GCC5<br>
>> +<br>
>> +Then run ``build`` in the ``edk2`` directory - the output should list the<br>
>> +location of the ``OVMF.fd`` file, which can be used with QEMU to boot into a UEFI<br>
>> +shell.<br>
>> +<br>
>> +You can find the ``OVMF.fd`` file like this as well in the edk2 directory:<br>
>> +<br>
>> +.. code-block:: shell<br>
>> +<br>
>> +    $ find . -name "*.fd"<br>
>> +    ./Build/OvmfX64/DEBUG_GCC5/FV/<wbr>MEMFD.fd<br>
>> +    ./Build/OvmfX64/DEBUG_GCC5/FV/<wbr>OVMF.fd <-- the file we're looking for<br>
>> +    ./Build/OvmfX64/DEBUG_GCC5/FV/<wbr>OVMF_CODE.fd<br>
>> +    ./Build/OvmfX64/DEBUG_GCC5/FV/<wbr>OVMF_VARS.fd<br>
>> +<br>
>> +Boot RTEMS via FreeBSD's bootloader<br>
>> +-----------------------------<wbr>------<br>
>> +<br>
>> +The RTEMS executable produced (an ELF file) needs to be placed in the FreeBSD's<br>
>> +``/boot/kernel/kernel``'s place.<br>
>> +<br>
>> +To do that, we first need a hard-disk image with FreeBSD installed on<br>
>> +it. `Download FreeBSD's installer "memstick" image for amd64<br>
>> +<<a href="https://www.freebsd.org/where.html" rel="noreferrer" target="_blank">https://www.freebsd.org/<wbr>where.html</a>>`_ and then run the following commands,<br>
>> +replacing paths as appropriate.<br>
>> +<br>
>> +.. code-block:: shell<br>
>> +<br>
>> +   $ qemu-img create freebsd.img 8G<br>
>> +   $ OVMF_LOCATION=/path/to/ovmf/<wbr>OVMF.fd<br>
>> +   $ FREEBSD_MEMSTICK=/path/to/<wbr>FreeBSD-11.2-amd64-memstick.<wbr>img<br>
>> +   $ qemu-system-x86_64 -m 1024 -serial stdio --bios $OVMF_LOCATION \<br>
>> +       -drive format=raw,file=freebsd.img \<br>
>> +       -drive format=raw,file=$FREEBSD_<wbr>MEMSTICK<br>
>> +<br>
>> +The first time you do this, continue through and install FreeBSD. `FreeBSD's<br>
>> +installation guide may prove useful<br>
>> +<<a href="https://www.freebsd.org/doc/handbook/bsdinstall-start.html" rel="noreferrer" target="_blank">https://www.freebsd.org/doc/<wbr>handbook/bsdinstall-start.html</a><wbr>>`_ if required.<br>
>> +<br>
>> +Once installed, build your RTEMS executable (an ELF file), for<br>
>> +eg. ``hello.exe``. We need to transfer this executable into ``freebsd.img``'s<br>
>> +filesystem, at either ``/boot/kernel/kernel`` or ``/boot/kernel.old/kernel`` (or<br>
>> +elsewhere, if you don't mind user FreeBSD's ``loader``'s prompt to boot your<br>
>> +custom kernel).<br>
>> +<br>
>> +If your host system supports mounting UFS filesystems as read-write<br>
>> +(eg. FreeBSD), go ahead and:<br>
>> +<br>
>> +1. Mount ``freebsd.img`` as read-write<br>
>> +2. Within the filesystem, back the existing FreeBSD kernel up (i.e. effectively<br>
>> +   ``cp -r /boot/kernel /boot/kernel.old``).<br>
>> +3. Place your RTEMS executable at ``/boot/kernel/kernel``<br>
>> +<br>
>> +If your host doesn't support mounting UFS filesystems (eg. most Linux kernels),<br>
>> +do something to the effect of the following.<br>
>> +<br>
>> +On the host<br>
>> +<br>
>> +.. code-block:: shell<br>
>> +<br>
>> +   # Upload hello.exe anywhere accessible within the host<br>
>> +   $ curl --upload-file hello.exe <a href="https://transfer.sh/rtems" rel="noreferrer" target="_blank">https://transfer.sh/rtems</a><br>
>> +<br>
>> +Then on the guest (FreeBSD), login with ``root`` and<br>
>> +<br>
>> +.. code-block:: shell<br>
>> +<br>
>> +   # Back the FreeBSD kernel up<br>
>> +   $ cp -r /boot/kernel/ /boot/kernel.old<br>
>> +   # Bring networking online if it isn't already<br>
>> +   $ dhclient em0<br>
>> +   # You may need to add the --no-verify-peer depending on your server<br>
>> +   $ fetch <a href="https://host.com/path/to/rtems/hello.exe" rel="noreferrer" target="_blank">https://host.com/path/to/<wbr>rtems/hello.exe</a><br>
>> +   # Replace default kernel<br>
>> +   $ cp hello.exe /boot/kernel/kernel<br>
>> +   $ reboot<br>
>> +<br>
>> +After rebooting, the RTEMS kernel should run after the UEFI firmware and<br>
>> +FreeBSD's bootloader. The ``-serial stdio`` QEMU flag will let the RTEMS console<br>
>> +send its output to the host's ``stdio`` stream.<br>
>> +<br>
>> +Clock Driver<br>
>> +------------<br>
>> +<br>
>> +The clock driver currently uses the idle thread clock driver.<br>
>> +<br>
>> +Console Driver<br>
>> +--------------<br>
>> +<br>
>> +The console driver defaults to using the ``COM1`` UART port (at I/O port<br>
>> +``0x3F8``), using the ``NS16550`` polled driver.<br>
>> --<br>
>> 2.16.0.rc0<br>
>><br>
</div></div></blockquote></div><br></div>