[PATCH 3/3] i386/virtualpok BSP, virtual BSP to be used with POK, build with enable-paravirt

[Gedare Bloom]

On Thu, Dec 5, 2013 at 8:39 AM, Philipp Eppelt
<philipp.eppelt at mailbox.tu-dresden.de> wrote:
> On 12/03/2013 05:49 PM, Gedare Bloom wrote:
>> On Sat, Nov 30, 2013 at 4:13 AM, Philipp Eppelt
>> <philipp.eppelt at mailbox.tu-dresden.de> wrote:
>>> ---
>>>  c/src/lib/libbsp/i386/acinclude.m4                 |   2 +
>>>  c/src/lib/libbsp/i386/virtualpok/Makefile.am       |  87 ++++++++
>>>  c/src/lib/libbsp/i386/virtualpok/README.virt       |  15 ++
>>>  c/src/lib/libbsp/i386/virtualpok/bsp_specs         |  14 ++
>>>  c/src/lib/libbsp/i386/virtualpok/clock/ckinit.c    | 139 ++++++++++++
>>>  c/src/lib/libbsp/i386/virtualpok/configure.ac      |  23 ++
>>>  c/src/lib/libbsp/i386/virtualpok/console/console.c | 184 ++++++++++++++++
>>>  c/src/lib/libbsp/i386/virtualpok/include/bsp.h     |  53 +++++
>>>  .../virtualpok/include/virtualizationlayerbsp.h    |  58 +++++
>>>  c/src/lib/libbsp/i386/virtualpok/irq/irq.c         |  85 +++++++
>>>  c/src/lib/libbsp/i386/virtualpok/irq/irq.h         |  79 +++++++
>>>  c/src/lib/libbsp/i386/virtualpok/libpart.a         | Bin 0 -> 130636 bytes
>>>  .../i386/virtualpok/make/custom/virtualpok.cfg     |  17 ++
>>>  c/src/lib/libbsp/i386/virtualpok/preinstall.am     |  79 +++++++
>>>  c/src/lib/libbsp/i386/virtualpok/start/_start.S    |  37 ++++
>>>  .../libbsp/i386/virtualpok/start/bspgetworkarea.c  | 102 +++++++++
>>>  .../lib/libbsp/i386/virtualpok/startup/bspstart.c  |  41 ++++
>>>  c/src/lib/libbsp/i386/virtualpok/startup/linkcmds  | 244 +++++++++++++++++++++
>>>  18 files changed, 1259 insertions(+)
>>>  create mode 100644 c/src/lib/libbsp/i386/virtualpok/Makefile.am
>>>  create mode 100644 c/src/lib/libbsp/i386/virtualpok/README.virt
>>>  create mode 100644 c/src/lib/libbsp/i386/virtualpok/bsp_specs
>>>  create mode 100644 c/src/lib/libbsp/i386/virtualpok/clock/ckinit.c
>>>  create mode 100644 c/src/lib/libbsp/i386/virtualpok/configure.ac
>>>  create mode 100644 c/src/lib/libbsp/i386/virtualpok/console/console.c
>>>  create mode 100644 c/src/lib/libbsp/i386/virtualpok/include/bsp.h
>>>  create mode 100644 c/src/lib/libbsp/i386/virtualpok/include/virtualizationlayerbsp.h
>>>  create mode 100644 c/src/lib/libbsp/i386/virtualpok/irq/irq.c
>>>  create mode 100644 c/src/lib/libbsp/i386/virtualpok/irq/irq.h
>>>  create mode 100644 c/src/lib/libbsp/i386/virtualpok/libpart.a
>>>  create mode 100644 c/src/lib/libbsp/i386/virtualpok/make/custom/virtualpok.cfg
>>>  create mode 100644 c/src/lib/libbsp/i386/virtualpok/preinstall.am
>>>  create mode 100644 c/src/lib/libbsp/i386/virtualpok/start/_start.S
>>>  create mode 100644 c/src/lib/libbsp/i386/virtualpok/start/bspgetworkarea.c
>>>  create mode 100644 c/src/lib/libbsp/i386/virtualpok/startup/bspstart.c
>>>  create mode 100644 c/src/lib/libbsp/i386/virtualpok/startup/linkcmds
>>>
>> <patch snipped>
>> Four comments.
>>
>> 1) I think libpart.a should not be included?
> You won't be able to compile the bsp unless there is a libpart.a
> present. The build process will fail with undefined reference at
> link-time. I thought it might be good to have it as an example, without
> implementing, building and copying it in/from POK.
>
> I can drop it and provide a link to my github repo in the README. There
> one can download libpart.a.
>
The concern with including libpart.a is that it is a binary blob,
which is something we have not really put in to RTEMS. If the upstream
permits redistributing binary blob then it may be OK, but it is an
issue that should be considered carefully. For now I would prefer to
have the user be directed to how to build this libpart.a file and have
some way to link to it like a BSPOPT or something. I'm not certain
what the right technical solution would be.

>> 2) can the linkcmds be shared between virtualpok and pc386?
> There are some differences. In the pc386 linkcmds ENTRY(start) is
> commented out and the RamBase definition is missing. In virtualpok the
> sections start at 0x1000 instead of 0x0. I don't know how this will
> affect the pc386 dependent BSPs.
> I copied the rest, as I didn't make any other changes (I didn't add
> RamBase, was that definition dropped?)
>
OK. There is in general a lot of copy-paste between linkcmds. The ARM
architecture has a nicely structured way of sharing linkcmds. Your
implementation is fine for now though.

>
>> 3) remane _start.S to be start.S
> done.
>> 4) move bspgetworkarea.c to startup/ instead of start/.
> done.
>
>
> Cheers,
> Philipp
>