Re: [PATCH] arm/raspberrypi: Fix linker map

2019-07-28 Thread Sebastian Huber 



On 29/07/2019 07:49, Chris Johns wrote:

On 29/7/19 3:45 pm, Sebastian Huber wrote:

On 29/07/2019 07:36, Chris Johns wrote:

On 29/7/19 3:23 pm, Sebastian Huber wrote:


could someone with a Raspberry Pi please test this patch.



RTEMS failed to start. It has broken something. I retested by running master
again.


The start address changes with this patch. How does this system know what it
should boot?



I only applied the patch and run it. What is the new start address so I can
update the mkimage script?


What was the old start address? The new one is probably:

0x00200080

I am not sure about the 0x80 tail, it should be the same as it was 
previously.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] arm/raspberrypi: Fix linker map

2019-07-28 Thread Chris Johns 
On 29/7/19 3:45 pm, Sebastian Huber wrote:
> On 29/07/2019 07:36, Chris Johns wrote:
>> On 29/7/19 3:23 pm, Sebastian Huber wrote:
>>>
>>> could someone with a Raspberry Pi please test this patch.
>>>
>>
>> RTEMS failed to start. It has broken something. I retested by running master
>> again.
> 
> The start address changes with this patch. How does this system know what it
> should boot?
> 

I only applied the patch and run it. What is the new start address so I can
update the mkimage script?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] arm/raspberrypi: Fix linker map

2019-07-28 Thread Sebastian Huber 

On 29/07/2019 07:36, Chris Johns wrote:

On 29/7/19 3:23 pm, Sebastian Huber wrote:


could someone with a Raspberry Pi please test this patch.



RTEMS failed to start. It has broken something. I retested by running master 
again.


The start address changes with this patch. How does this system know 
what it should boot?


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] arm/raspberrypi: Fix linker map

2019-07-28 Thread Sebastian Huber 

Hello,

could someone with a Raspberry Pi please test this patch.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] arm/raspberrypi: Fix linker map

2019-07-28 Thread Sebastian Huber 
Add NULL-pointer protection.  Make MMU table read-only.  Move vector
table to start section.

Close #3774.
---
 bsps/arm/raspberrypi/start/linkcmds | 34 --
 1 file changed, 8 insertions(+), 26 deletions(-)

diff --git a/bsps/arm/raspberrypi/start/linkcmds 
b/bsps/arm/raspberrypi/start/linkcmds
index 58423abecb..7a1bcbac73 100644
--- a/bsps/arm/raspberrypi/start/linkcmds
+++ b/bsps/arm/raspberrypi/start/linkcmds
@@ -14,35 +14,13 @@
  * @brief Raspberry Pi memory map.
  */
 
-/**
- * 
- *   Region NameRegion BeginRegion Size
- * VECTOR_RAM0x08008k
- * RAM0x80008000128M
- * 
- *
- * 
- *   Section NameSection Runtime RegionSection Load 
Region
- * .startRAM
- * .vectorVECTOR_RAM
- * .textRAMRAM_EXT
- * .rodataRAMRAM_EXT
- * .dataRAMRAM_EXT
- * .fastRAMRAM_EXT
- * .bssRAM
- * .workRAM
- * .stackRAM
- * 
- */
-
 MEMORY {
-VECTOR_RAM (AIW) : ORIGIN = 0x0   , LENGTH = 16k
-   RAM_MMU(AIW) : ORIGIN = 0x4000, LENGTH = 16k
-RAM(AIW) : ORIGIN = 0x8000, LENGTH = 128M - 32k
+RAM_MMU(AIW) : ORIGIN = 0x0010, LENGTH = 16k
+RAM(AIW) : ORIGIN = 0x0020, LENGTH = 128M - 2M
 }
 
 REGION_ALIAS ("REGION_START", RAM);
-REGION_ALIAS ("REGION_VECTOR", VECTOR_RAM);
+REGION_ALIAS ("REGION_VECTOR", RAM);
 REGION_ALIAS ("REGION_TEXT", RAM);
 REGION_ALIAS ("REGION_TEXT_LOAD", RAM);
 REGION_ALIAS ("REGION_RODATA", RAM);
@@ -61,7 +39,11 @@ REGION_ALIAS ("REGION_NOCACHE_LOAD", RAM);
 
 bsp_stack_abt_size = DEFINED (bsp_stack_abt_size) ? bsp_stack_abt_size : 1024;
 
-bsp_section_robarrier_align = DEFINED (bsp_section_robarrier_align) ? 
bsp_section_robarrier_align : 1M;
+bsp_section_rwbarrier_align = DEFINED (bsp_section_rwbarrier_align) ? 
bsp_section_rwbarrier_align : 1M;
+
+bsp_vector_table_in_start_section = 1;
+
 bsp_translation_table_base = ORIGIN (RAM_MMU);
+bsp_translation_table_end = ORIGIN (RAM_MMU) + LENGTH (RAM_MMU);
 
 INCLUDE linkcmds.armv4
-- 
2.16.4

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

How to handle pinmux in libbsd (was: Re: [PATCH 10/10] TI Pinmux : Port to RTEMS)

2019-07-28 Thread Christian Mauderer 
On 28/07/2019 12:42, Vijay Kumar Banerjee wrote:
> 
> 
> 
> On Sat, Jul 27, 2019 at 7:35 PM Christian Mauderer  > wrote:
> 
> Does this initialize only the pins for drivers that are registered in
> libbsd or all pins? I think you had an extended boot log where you might
> could see it.
> 
> If it is all pins, this might interfere with RTEMS drivers that are not
> libbsd based. In that case we need some kind of solution (not sure yet
> which one).
> 
> It's muxing more pins than just the HDMI, including i2c pins. Please have
> a look at the log that I got from RTEMS:
> https://paste.ofcode.org/kVvrdYAfvC3G6kBtG5iaTb
> 
> These pins to be initialized are being decided from the device tree nodes 
> with the pinctrl-single,pins property. If the initialized pins are not
> all required,
> then I would like to propose a solution of using an overlay to rename the 
> property to "rtems-pinctrl-single,pins" or something like this for the
> pins that 
> we need to be initialized, like hdmi. And in the ti_pinmux.c modify the
> code to
> search for this property instead of the default.
> 
> I haven't attempted doing it but before I attempt I would like to make
> sure if
> you think it's OK and not too hackish approach. 

I'm not that happy with doing that in the device tree because it puts
special requirements on the used one. From an application programmers
perspective I wouldn't expect that there are two locations that can have
an influence on my I2C pins. In this case: The i2c driver and the device
tree. But I'm not yet sure how a good solution could look like.

From my point of view it would be optimal if libbsd only initializes the
pins that are used by a libbsd driver and not for example the led pins.
But that isn't how the pinmux driver is intended to work.

An alternative could be to do the pin initialization in the BSP based on
the device tree instead of importing the FreeBSD pinmux driver.
Currently there is no clean consistent implementation how the pins are
handled in the drivers. So a clean up wouldn't hurt. Depending on how
much work that is, it could be a hack for now and for example a GSoC
project for next year.

I think we don't have a clean consistent API for GPIO for a lot of BSPs.
So it wouldn't hurt to either find out whether we have one and implement
a device tree parser for it or define one (most likely based on FreeBSD
pinmux) and implement it for some existing and in future also for new BSPs.

Let's wait for some other opinions here.

Best regards

Christian
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Add framebuffer in BBB

2019-07-28 Thread Christian Mauderer 
On 28/07/2019 13:07, Vijay Kumar Banerjee wrote:
> 
> 
> 
> On Sun, Jul 28, 2019 at 1:31 PM Christian Mauderer  > wrote:
> 
> On 27/07/2019 21:43, Vijay Kumar Banerjee wrote:
> >
> >
> >
> > On Sat, Jul 27, 2019 at 7:37 PM Christian Mauderer
> mailto:l...@c-mauderer.de>
> > >> wrote:
> >
> >     On 26/07/2019 13:41, Christian Mauderer wrote:
> >     > On 26/07/2019 13:22, Vijay Kumar Banerjee wrote:
> >     >> Hello everyone!
> >     >>
> >     >> I'm excited to post the following patchset. With this patchset
> >     >> I have the framebuffer working in BBB and have tested it with a
> >     >> BBB revC with HDMI connected Screen.
> >     >>
> >     >> This patchset uses mmap and hence it's necessary to apply the
> >     >> patche ON TOP OF mmap patch to avoid merge conflict.
> >     >>
> >     >> In reply to this mail, I'll be attaching a picture of the
> screen
> >     >> where my rectangle drawing application made a nice red
> rectangle
> >     >> on the screen just like in FreeBSD.
> >     >>
> >     >> Thanks and regards,
> >     >> Vijay
> >     >>
> >     >
> >     > Hello Vijay,
> >     >
> >     > it's great that you now have a working driver. Well done.
> >     >
> >     > I hadn't had a look at most patches yet and most likely that
> will
> >     need a
> >     > bit of time. It's a lot of stuff. Most likely the bigger
> patches won't
> >     > reach the mailing list so maybe adding a link to a branch on
> your
> >     github
> >     > repo would be good.
> >     >
> >     > Note: Please don't send a v2 right now. I'm sure there are more
> >     comments
> >     > (maybe not only from me). Collect comments for at least one
> or two
> >     days
> >     > and create an update afterwards.
> >     >
> >     > Some notes reading the patch overview:
> >     >
> >     >> [PATCH 01/10] TDA19988 : Import from FreeBSD
> >     >> [PATCH 02/10] TDA19988 : port to RTEMS
> >     >> [PATCH 03/10] am335x display drivers: Import from FreeBSD
> >     >> [PATCH 04/10] am335x display drivers : Port to RTEMS
> >     >> [PATCH 05/10] fbd : Import from FreeBSD
> >     >> [PATCH 06/10] fbd : Port to RTEMS
> >     >
> >     > Is fbd a prerequisite of am335x_lcd? In that case it would
> have been
> >     > better to reorder the patches. As long as every version
> compiles (to
> >     > allow git bisect) I would accept that order too. But as a
> general rule
> >     > prerequisites should be prior to the parts that use it.
> >     >
> >     >> [PATCH 07/10] VT : Import from FreeBSD
> >     >> [PATCH 08/10] VT : Port to RTEMS
> >     >
> >     > Is the vt still necessary? I think it was an intermediate
> step to try
> >     > whether it's initializing the display. Did you try without it?
> >     >
> >     >> [PATCH 09/10] TI Pinmux : Import from FreeBSD
> >     >> [PATCH 10/10] TI Pinmux : Port to RTEMS
> >     >
> >     > Again: prerequisite. So they should be one of the first.
> >     >
> >     > Best regards
> >     >
> >     > Christian
> >     >
> >
> >     One general question: When trying the patches, my monitor has
> been set
> >     up as 1440x900 instead of it's native resolution. Did you
> check whether
> >     the resolution on your screen is set correctly?
> >
> > It's not setting fb with the "preferred videomode", I can confirm that
> > the resolution
> > set by FreeBSD and RTEMS is same.
> 
> OK. Sooner or later it might would be good to find out how to set
> another resolution. Currently I have the following output:
> 
> 
> Preferred mode: 1920x1200 @ 60Hz
> Number of extension blocks: 1
> fb0: detected videomode: 1440x900 @ 60KHz
> fbd0 on fb0
> 
> 
> It's a bit odd that not the preferred mode is used. But if it is the
> same for FreeBSD it's OK for a start.
> 
> One other problem: I tried to create some solid regions and it seems
> that there are a few artefacts. Can you try that on your screen and tell
> me whether you get them too? For the code and an image how it looks like
> on my screen take a look at
>     https://gist.github.com/c-mauderer/051689bb1199caf20a08d9844c44c113
> 
> Some of the lines vanished after a few seconds. I think that could be a
> memory caching issue.
> 
> I see the same. Some lines come back after a few seconds:
> https://drive.google.com/file/d/1CA61bs0nipUygRpotmyL-Hd8khG_RIbD/view?usp=sharing
>  

OK. Like I said: My first guess would be a caching issue. Do you know
where or how the video memory is allocated? Is it a fixed area or
dynamically during

Re: [PATCH] Add framebuffer in BBB

2019-07-28 Thread Vijay Kumar Banerjee 
On Sun, Jul 28, 2019 at 1:31 PM Christian Mauderer 
wrote:

> On 27/07/2019 21:43, Vijay Kumar Banerjee wrote:
> >
> >
> >
> > On Sat, Jul 27, 2019 at 7:37 PM Christian Mauderer  > > wrote:
> >
> > On 26/07/2019 13:41, Christian Mauderer wrote:
> > > On 26/07/2019 13:22, Vijay Kumar Banerjee wrote:
> > >> Hello everyone!
> > >>
> > >> I'm excited to post the following patchset. With this patchset
> > >> I have the framebuffer working in BBB and have tested it with a
> > >> BBB revC with HDMI connected Screen.
> > >>
> > >> This patchset uses mmap and hence it's necessary to apply the
> > >> patche ON TOP OF mmap patch to avoid merge conflict.
> > >>
> > >> In reply to this mail, I'll be attaching a picture of the screen
> > >> where my rectangle drawing application made a nice red rectangle
> > >> on the screen just like in FreeBSD.
> > >>
> > >> Thanks and regards,
> > >> Vijay
> > >>
> > >
> > > Hello Vijay,
> > >
> > > it's great that you now have a working driver. Well done.
> > >
> > > I hadn't had a look at most patches yet and most likely that will
> > need a
> > > bit of time. It's a lot of stuff. Most likely the bigger patches
> won't
> > > reach the mailing list so maybe adding a link to a branch on your
> > github
> > > repo would be good.
> > >
> > > Note: Please don't send a v2 right now. I'm sure there are more
> > comments
> > > (maybe not only from me). Collect comments for at least one or two
> > days
> > > and create an update afterwards.
> > >
> > > Some notes reading the patch overview:
> > >
> > >> [PATCH 01/10] TDA19988 : Import from FreeBSD
> > >> [PATCH 02/10] TDA19988 : port to RTEMS
> > >> [PATCH 03/10] am335x display drivers: Import from FreeBSD
> > >> [PATCH 04/10] am335x display drivers : Port to RTEMS
> > >> [PATCH 05/10] fbd : Import from FreeBSD
> > >> [PATCH 06/10] fbd : Port to RTEMS
> > >
> > > Is fbd a prerequisite of am335x_lcd? In that case it would have
> been
> > > better to reorder the patches. As long as every version compiles
> (to
> > > allow git bisect) I would accept that order too. But as a general
> rule
> > > prerequisites should be prior to the parts that use it.
> > >
> > >> [PATCH 07/10] VT : Import from FreeBSD
> > >> [PATCH 08/10] VT : Port to RTEMS
> > >
> > > Is the vt still necessary? I think it was an intermediate step to
> try
> > > whether it's initializing the display. Did you try without it?
> > >
> > >> [PATCH 09/10] TI Pinmux : Import from FreeBSD
> > >> [PATCH 10/10] TI Pinmux : Port to RTEMS
> > >
> > > Again: prerequisite. So they should be one of the first.
> > >
> > > Best regards
> > >
> > > Christian
> > >
> >
> > One general question: When trying the patches, my monitor has been
> set
> > up as 1440x900 instead of it's native resolution. Did you check
> whether
> > the resolution on your screen is set correctly?
> >
> > It's not setting fb with the "preferred videomode", I can confirm that
> > the resolution
> > set by FreeBSD and RTEMS is same.
>
> OK. Sooner or later it might would be good to find out how to set
> another resolution. Currently I have the following output:
>
> 
> Preferred mode: 1920x1200 @ 60Hz
> Number of extension blocks: 1
> fb0: detected videomode: 1440x900 @ 60KHz
> fbd0 on fb0
> 
>
> It's a bit odd that not the preferred mode is used. But if it is the
> same for FreeBSD it's OK for a start.
>
> One other problem: I tried to create some solid regions and it seems
> that there are a few artefacts. Can you try that on your screen and tell
> me whether you get them too? For the code and an image how it looks like
> on my screen take a look at
> https://gist.github.com/c-mauderer/051689bb1199caf20a08d9844c44c113
>
> Some of the lines vanished after a few seconds. I think that could be a
> memory caching issue.
>
> I see the same. Some lines come back after a few seconds:
https://drive.google.com/file/d/1CA61bs0nipUygRpotmyL-Hd8khG_RIbD/view?usp=sharing


> >
> > Best regards
> >
> > Christian
> >
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 10/10] TI Pinmux : Port to RTEMS

2019-07-28 Thread Vijay Kumar Banerjee 
On Sat, Jul 27, 2019 at 7:35 PM Christian Mauderer 
wrote:

> Does this initialize only the pins for drivers that are registered in
> libbsd or all pins? I think you had an extended boot log where you might
> could see it.
>
> If it is all pins, this might interfere with RTEMS drivers that are not
> libbsd based. In that case we need some kind of solution (not sure yet
> which one).
>
> Beneath that: I added some comments in the code below.
>
> On 26/07/2019 13:22, Vijay Kumar Banerjee wrote:
> > ---
> >  Makefile.todo | 13 ++
> >  buildset/default.ini  |  1 +
> >  libbsd.py | 33 +++
> >  rtemsbsd/include/bsp/nexus-devices.h  |  1 +
> >  .../machine/rtems-bsd-kernel-namespace.h  |  9 +
> >  .../include/rtems/bsd/local/fdt_pinctrl_if.h  | 40 +++
> >  rtemsbsd/local/fdt_pinctrl_if.c   | 27 +
> >  7 files changed, 124 insertions(+)
> >  create mode 100644 rtemsbsd/local/fdt_pinctrl_if.c
> >
> > diff --git a/Makefile.todo b/Makefile.todo
> > index ed1e428e..1bf61432 100644
> > --- a/Makefile.todo
> > +++ b/Makefile.todo
> > @@ -53,6 +53,8 @@ GENERATED += $(LOCAL_INC)/hdmi_if.h
> >  GENERATED += $(LOCAL_SRC)/hdmi_if.c
> >  GENERATED += $(LOCAL_INC)/fb_if.h
> >  GENERATED += $(LOCAL_SRC)/fb_if.c
> > +GENERATED += $(LOCAL_INC)/fdt_pinctrl_if.h
> > +GENERATED += $(LOCAL_SRC)/fdt_pinctrl_if.c
> >  GENERATED += rtemsbsd/include/machine/rtems-bsd-regdomain.h
> >  GENERATED += rtemsbsd/rtems/rtems-bsd-regdomain.c
> >
> > @@ -279,6 +281,17 @@ $(LOCAL_SRC)/fb_if.c:
> $(FREEBSD_SRC)/sys/dev/fb/fb_if.m
> >   -e 's|#include "fb_if.h"|#include |'
> >   mv fb_if.c $@
> >
> > +$(LOCAL_INC)/fdt_pinctrl_if.h:
> $(FREEBSD_SRC)/sys/dev/fdt/fdt_pinctrl_if.m
> > + awk -f $(TOOLS)/makeobjops.awk $< -h
> > + mv fdt_pinctrl_if.h $@
> > +
> > +$(LOCAL_SRC)/fdt_pinctrl_if.c:
> $(FREEBSD_SRC)/sys/dev/fdt/fdt_pinctrl_if.m
> > + awk -f $(TOOLS)/makeobjops.awk $< -c
> > + sed -i fdt_pinctrl_if.c \
> > + -e '1 i\#include \n' \
> > + -e 's|#include "fdt_pinctrl_if.h"|#include
> |'
> > + mv fdt_pinctrl_if.c $@
> > +
> >  $(LOCAL_SRC)/gpio_if.c: $(FREEBSD_SRC)/sys/dev/gpio/gpio_if.m
> >   awk -f $(TOOLS)/makeobjops.awk $< -c
> >   mv gpio_if.c $@
> > diff --git a/buildset/default.ini b/buildset/default.ini
> > index 1d052a48..eed5cb75 100644
> > --- a/buildset/default.ini
> > +++ b/buildset/default.ini
> > @@ -38,6 +38,7 @@ dev_usb_wlan = off
> >  dev_wlan_rtwn = off
> >  iic = on
> >  display = on
> > +ti_pinmux = on
> >  dhcpcd = on
> >  dpaa = on
> >  evdev = on
> > diff --git a/libbsd.py b/libbsd.py
> > index 775eeeac..cdd97010 100644
> > --- a/libbsd.py
> > +++ b/libbsd.py
> > @@ -840,6 +840,38 @@ class display(builder.Module):
> >  mm.generator['source']()
> >  )
> >
> > +#
> > +# TI PINMUX
> > +#
> > +class ti_pinmux(builder.Module):
> > +
> > +def __init__(self, manager):
> > +super(ti_pinmux, self).__init__(manager, type(self).__name__)
> > +
> > +def generate(self):
> > +mm = self.manager
> > +self.addKernelSpaceHeaderFiles(
> > +[
> > +'sys/arm/ti/ti_pinmux.h',
> > +'sys/arm/ti/omap4/omap4_scm_padconf.h',
> > +'sys/arm/ti/am335x/am335x_scm_padconf.h',
> > +]
> > +)
> > +self.addKernelSpaceSourceFiles(
> > +[
> > +'sys/arm/ti/ti_pinmux.c',
> > +'sys/dev/fdt/fdt_pinctrl.c',
>
> That looks like a general file. So either this module isn't ti_pinmux
> but pinmux or the pinctrl should be somewhere else.
>
> > +'sys/arm/ti/am335x/am335x_scm_padconf.c',
> > +],
> > +mm.generator['source']()
> > +)
> > +self.addRTEMSSourceFiles(
> > +[
> > +'local/fdt_pinctrl_if.c',
>
> Same for that.
>
> OK. I think it can be renamed to pinmux as I didn't find any other heading
to put it
under. Would you suggest some other section?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 10/10] TI Pinmux : Port to RTEMS

2019-07-28 Thread Vijay Kumar Banerjee 
On Sat, Jul 27, 2019 at 7:35 PM Christian Mauderer 
wrote:

> Does this initialize only the pins for drivers that are registered in
> libbsd or all pins? I think you had an extended boot log where you might
> could see it.
>
> If it is all pins, this might interfere with RTEMS drivers that are not
> libbsd based. In that case we need some kind of solution (not sure yet
> which one).
>
> It's muxing more pins than just the HDMI, including i2c pins. Please have
a look at the log that I got from RTEMS:
https://paste.ofcode.org/kVvrdYAfvC3G6kBtG5iaTb

These pins to be initialized are being decided from the device tree nodes
with the pinctrl-single,pins property. If the initialized pins are not all
required,
then I would like to propose a solution of using an overlay to rename the
property to "rtems-pinctrl-single,pins" or something like this for the pins
that
we need to be initialized, like hdmi. And in the ti_pinmux.c modify the
code to
search for this property instead of the default.

I haven't attempted doing it but before I attempt I would like to make sure
if
you think it's OK and not too hackish approach.

> Beneath that: I added some comments in the code below.
>
> On 26/07/2019 13:22, Vijay Kumar Banerjee wrote:
> > ---
> >  Makefile.todo | 13 ++
> >  buildset/default.ini  |  1 +
> >  libbsd.py | 33 +++
> >  rtemsbsd/include/bsp/nexus-devices.h  |  1 +
> >  .../machine/rtems-bsd-kernel-namespace.h  |  9 +
> >  .../include/rtems/bsd/local/fdt_pinctrl_if.h  | 40 +++
> >  rtemsbsd/local/fdt_pinctrl_if.c   | 27 +
> >  7 files changed, 124 insertions(+)
> >  create mode 100644 rtemsbsd/local/fdt_pinctrl_if.c
> >
> > diff --git a/Makefile.todo b/Makefile.todo
> > index ed1e428e..1bf61432 100644
> > --- a/Makefile.todo
> > +++ b/Makefile.todo
> > @@ -53,6 +53,8 @@ GENERATED += $(LOCAL_INC)/hdmi_if.h
> >  GENERATED += $(LOCAL_SRC)/hdmi_if.c
> >  GENERATED += $(LOCAL_INC)/fb_if.h
> >  GENERATED += $(LOCAL_SRC)/fb_if.c
> > +GENERATED += $(LOCAL_INC)/fdt_pinctrl_if.h
> > +GENERATED += $(LOCAL_SRC)/fdt_pinctrl_if.c
> >  GENERATED += rtemsbsd/include/machine/rtems-bsd-regdomain.h
> >  GENERATED += rtemsbsd/rtems/rtems-bsd-regdomain.c
> >
> > @@ -279,6 +281,17 @@ $(LOCAL_SRC)/fb_if.c:
> $(FREEBSD_SRC)/sys/dev/fb/fb_if.m
> >   -e 's|#include "fb_if.h"|#include |'
> >   mv fb_if.c $@
> >
> > +$(LOCAL_INC)/fdt_pinctrl_if.h:
> $(FREEBSD_SRC)/sys/dev/fdt/fdt_pinctrl_if.m
> > + awk -f $(TOOLS)/makeobjops.awk $< -h
> > + mv fdt_pinctrl_if.h $@
> > +
> > +$(LOCAL_SRC)/fdt_pinctrl_if.c:
> $(FREEBSD_SRC)/sys/dev/fdt/fdt_pinctrl_if.m
> > + awk -f $(TOOLS)/makeobjops.awk $< -c
> > + sed -i fdt_pinctrl_if.c \
> > + -e '1 i\#include \n' \
> > + -e 's|#include "fdt_pinctrl_if.h"|#include
> |'
> > + mv fdt_pinctrl_if.c $@
> > +
> >  $(LOCAL_SRC)/gpio_if.c: $(FREEBSD_SRC)/sys/dev/gpio/gpio_if.m
> >   awk -f $(TOOLS)/makeobjops.awk $< -c
> >   mv gpio_if.c $@
> > diff --git a/buildset/default.ini b/buildset/default.ini
> > index 1d052a48..eed5cb75 100644
> > --- a/buildset/default.ini
> > +++ b/buildset/default.ini
> > @@ -38,6 +38,7 @@ dev_usb_wlan = off
> >  dev_wlan_rtwn = off
> >  iic = on
> >  display = on
> > +ti_pinmux = on
> >  dhcpcd = on
> >  dpaa = on
> >  evdev = on
> > diff --git a/libbsd.py b/libbsd.py
> > index 775eeeac..cdd97010 100644
> > --- a/libbsd.py
> > +++ b/libbsd.py
> > @@ -840,6 +840,38 @@ class display(builder.Module):
> >  mm.generator['source']()
> >  )
> >
> > +#
> > +# TI PINMUX
> > +#
> > +class ti_pinmux(builder.Module):
> > +
> > +def __init__(self, manager):
> > +super(ti_pinmux, self).__init__(manager, type(self).__name__)
> > +
> > +def generate(self):
> > +mm = self.manager
> > +self.addKernelSpaceHeaderFiles(
> > +[
> > +'sys/arm/ti/ti_pinmux.h',
> > +'sys/arm/ti/omap4/omap4_scm_padconf.h',
> > +'sys/arm/ti/am335x/am335x_scm_padconf.h',
> > +]
> > +)
> > +self.addKernelSpaceSourceFiles(
> > +[
> > +'sys/arm/ti/ti_pinmux.c',
> > +'sys/dev/fdt/fdt_pinctrl.c',
>
> That looks like a general file. So either this module isn't ti_pinmux
> but pinmux or the pinctrl should be somewhere else.
>
> > +'sys/arm/ti/am335x/am335x_scm_padconf.c',
> > +],
> > +mm.generator['source']()
> > +)
> > +self.addRTEMSSourceFiles(
> > +[
> > +'local/fdt_pinctrl_if.c',
>
> Same for that.
>
> > +],
> > +mm.generator['source']()
> > +)
> > +
> >  #
> >  # USB
> >  #
> > @@ -5198,6 +5230,7 @@ def load(mm):
> >  mm.addModule(evdev(mm))
> >  mm.addModule(iic(mm))
> >  mm.addModule(display(mm))
> > +

Re: [PATCH 08/10] VT : Port to RTEMS

2019-07-28 Thread Vijay Kumar Banerjee 
On Sun, Jul 28, 2019 at 1:27 PM Christian Mauderer 
wrote:

> On 27/07/2019 22:31, Vijay Kumar Banerjee wrote:
> >
> >
> > On Sat, Jul 27, 2019 at 7:26 PM Christian Mauderer  > > wrote:
> >
> > I'm still not entirely convinced what VT does. I tried to remove it
> (had
> > to remove the vt_fb_attach() / _detach() from fbd.c too) and it still
> > works. So why do you need VT?
> >
> > I removed the VT commit and the app was not able to open the fb device,
> > if you can open the device with just removing the VT part from fbd, then
> > maybe some other part of the VT commit is necessary to open the device,
> > I'll have a look and report and try to see if minimum to no parts of vt
> > is needed.
> > (We already removed most part from it, just initialization is there).
>
> That's odd. I can just revert the two VT patches with "git revert ",
> remove vt_fb_attach() / ..._detach() and I still get an output.
>
> Maybe I was doing something wrong. In a fresh branch without the VT commit
and the vt part removed from fbd. It's working. So I'll totally leave this
VT part.
and add the vtophys define fbd patch itself so that the define isn't
required in the
source.

> [...]
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC PRU: AM35xx Clock driver

2019-07-28 Thread Christian Mauderer 
On 28/07/2019 11:22, Nils Hölscher wrote:
> 
> 
> On Sat, 27 Jul 2019 at 14:34, Christian Mauderer  > wrote:
> 
> On 24/07/2019 16:53, Nils Hölscher wrote:
> > Hi,
> >
> > @Vijay Kumar Banerjee  >  thanks for the
> > dtb file.
> > I build my file from FreeBSD master.
> >
> > Prcm attaches now but still after the pruss driver...:
> > "
> > nexus0: 
> > ofwbus0:  on nexus0
> > simplebus0:  on ofwbus0
> > *ti_pruss0:  mem
> > 0x4a30-0x4a37 irq 20,21,22,23,24,25,26,27 on simplebus0
> > ti_pruss0: could not enable PRUSS clock
> > device_attach: ti_pruss0 attach returned 6*
> > simplebus1:  on simplebus0*
> > am335x_prcm0:  mem
> 0x20-0x203fff
> > on simplebus1*
> 
> Hello Nils,
> 
> I'm not sure about the order. But what seems a little bit odd is that
> the prcm0 is found in simplebus0 while am335x_prcm0 is found on
> simplebus1. Maybe it's worth investigating how that order is created and
> how it is handled in RTEMS.
> 
> 
> Thanks for the information.
> I think the way rtems initializes the bsd modules differs from the way
> described in the libbsd manuel.
> But I will have to investigate that further.
> 
>  

I'm not 100% sure but as far as I know the _modules_ should be
initialized in the given order (early module prior to normal module).
But the device detection is something different. I think there is some
loop in simplebus that loops over the devices and asks every driver
whether it wants to handle that device. If yes the driver can have it.
If no the device is unhandled.

For a module that is mentioned in the device tree I would expect that
the order in the device tree binary is the one used. For devices outside
of the device tree most likely some link order is used.

If you have a debugger you might want to search for the loops and take a
look at when they are called and how they add devices. I don't think
that there are that many early modules yet that would use the device
tree. So it's possible that there is some call missing that would parse
the device tree for early modules.

> 
> 
> A general note regarding the prcm module: In RTEMS most (non-libbsd)
> drivers enable their power and clocks themself. Please make sure that
> the FreeBSD prcm doesn't interfere with that. Otherwise you might get
> odd effects.
> 
> Thanks I will keep that in mind.
> 
> Best,
> Nils 
> 
> 
> Best regards
> 
> Christian
> 
> > *am335x_prcm_attach*
> > "
> >
> > Is there anything else I can do besides using MODULE_DEPENDENCY,
> which I
> > already use.
> > The prcm module is also a EARLY_DRIVER_MODULE.
> >
> > Best,
> > Nils
> >
> > On Wed, 24 Jul 2019 at 16:04, Vijay Kumar Banerjee
> > mailto:vijaykumar9...@gmail.com>
> >>
> wrote:
> >
> >
> >
> >     On Wed, Jul 24, 2019 at 7:03 PM Nils Hölscher
> mailto:nilho...@gmail.com>
> >     >> wrote:
> >
> >
> >
> >         On Wed, 24 Jul 2019 at 15:14, Vijay Kumar Banerjee
> >            >> wrote:
> >
> >
> >
> >
> >             On Wed, Jul 24, 2019 at 6:36 PM Nils Hölscher
> >             mailto:nilho...@gmail.com>
> >> wrote:
> >
> >                 Hi again,
> >
> >             Hi Nils 
> >
> >                 I just decompiled my device tree and checked.
> >                 The probe code of the prcm driver is as follows:
> >                 "
> >                 static int
> >                 am335x_prcm_probe(device_t dev)
> >                 {
> >                 printk("am335x_prcm_probe\n");
> >
> >                 if (!ofw_bus_status_okay(dev)){
> >                 printk("ofw_bus_status_not_okay\n");
> >                 return (ENXIO);
> >                 }
> >
> >             Do you get the "ofw_bus_status_not_okay" print ? 
> >
> >         Yes. But I also see the other print. except the success one. 
> >
> >                 if (ofw_bus_is_compatible(dev, "ti,am3-prcm")) {
> >                 device_set_desc(dev, "AM335x Power and Clock
> >                 Management");
> >                 printk("PROBE SUCESSFULL\n");
> >                 return(BUS_PROBE_DEFAULT);
> >                 }
> >                 printk("ofw_bus incompatible\n");
> >                 return (ENXIO);
> >                 }
> >                 "
>

Re: GSoC PRU: AM35xx Clock driver

2019-07-28 Thread Nils Hölscher 
On Sat, 27 Jul 2019 at 14:34, Christian Mauderer  wrote:

> On 24/07/2019 16:53, Nils Hölscher wrote:
> > Hi,
> >
> > @Vijay Kumar Banerjee   thanks for the
> > dtb file.
> > I build my file from FreeBSD master.
> >
> > Prcm attaches now but still after the pruss driver...:
> > "
> > nexus0: 
> > ofwbus0:  on nexus0
> > simplebus0:  on ofwbus0
> > *ti_pruss0:  mem
> > 0x4a30-0x4a37 irq 20,21,22,23,24,25,26,27 on simplebus0
> > ti_pruss0: could not enable PRUSS clock
> > device_attach: ti_pruss0 attach returned 6*
> > simplebus1:  on simplebus0*
> > am335x_prcm0:  mem 0x20-0x203fff
> > on simplebus1*
>
> Hello Nils,
>
> I'm not sure about the order. But what seems a little bit odd is that
> the prcm0 is found in simplebus0 while am335x_prcm0 is found on
> simplebus1. Maybe it's worth investigating how that order is created and
> how it is handled in RTEMS.


Thanks for the information.
I think the way rtems initializes the bsd modules differs from the way
described in the libbsd manuel.
But I will have to investigate that further.




> A general note regarding the prcm module: In RTEMS most (non-libbsd)
> drivers enable their power and clocks themself. Please make sure that
> the FreeBSD prcm doesn't interfere with that. Otherwise you might get
> odd effects.
>
Thanks I will keep that in mind.

Best,
Nils

>
> Best regards
>
> Christian
>
> > *am335x_prcm_attach*
> > "
> >
> > Is there anything else I can do besides using MODULE_DEPENDENCY, which I
> > already use.
> > The prcm module is also a EARLY_DRIVER_MODULE.
> >
> > Best,
> > Nils
> >
> > On Wed, 24 Jul 2019 at 16:04, Vijay Kumar Banerjee
> > mailto:vijaykumar9...@gmail.com>> wrote:
> >
> >
> >
> > On Wed, Jul 24, 2019 at 7:03 PM Nils Hölscher  > > wrote:
> >
> >
> >
> > On Wed, 24 Jul 2019 at 15:14, Vijay Kumar Banerjee
> > mailto:vijaykumar9...@gmail.com>>
> wrote:
> >
> >
> >
> >
> > On Wed, Jul 24, 2019 at 6:36 PM Nils Hölscher
> > mailto:nilho...@gmail.com>> wrote:
> >
> > Hi again,
> >
> > Hi Nils
> >
> > I just decompiled my device tree and checked.
> > The probe code of the prcm driver is as follows:
> > "
> > static int
> > am335x_prcm_probe(device_t dev)
> > {
> > printk("am335x_prcm_probe\n");
> >
> > if (!ofw_bus_status_okay(dev)){
> > printk("ofw_bus_status_not_okay\n");
> > return (ENXIO);
> > }
> >
> > Do you get the "ofw_bus_status_not_okay" print ?
> >
> > Yes. But I also see the other print. except the success one.
> >
> > if (ofw_bus_is_compatible(dev, "ti,am3-prcm")) {
> > device_set_desc(dev, "AM335x Power and Clock
> > Management");
> > printk("PROBE SUCESSFULL\n");
> > return(BUS_PROBE_DEFAULT);
> > }
> > printk("ofw_bus incompatible\n");
> > return (ENXIO);
> > }
> > "
> > So it seems the prcm part in the device tree has to be
> > compatible to "ti,am3-prcm".
> > The thing is the decompiled device tree states just that:
> > "
> > prcm@0 {
> > compatible =
> > "ti,am3-prcm\0simple-bus";
> >
> > In my device tree, it runs successfully and the decompiled
> > compatible looks like  :
> > ```
> > prcm@20 {
> > compatible = "ti,am3-prcm";
> > reg = < 0x20 0x4000 >;
> > linux,phandle = < 0x4a >;
> > phandle = < 0x4a >;
> > ```
> >
> > OK, this is awkward, cause we both should have used the same
> > sources.
> >
> > Have you checked that your source is from the tree matching the
> > libBSD HEAD
> > commit?
> >
> > reg = <0x00 0x2000>;
> > #address-cells = <0x01>;
> > #size-cells = <0x01>;
> > ranges = <0x00 0x00 0x2000>;
> > phandle = <0x5a>;
> > [...]
> > "
> > Any ideas would help, cause I am currently not able to
> > understand this behaviour.
> > Also without this driver even the dev_usb_bbb driver
> > shouldn't work.
> > However it attaches because it doesn't check for the
> > clocks

Re: [PATCH] Add framebuffer in BBB

2019-07-28 Thread Christian Mauderer 
On 27/07/2019 21:43, Vijay Kumar Banerjee wrote:
> 
> 
> 
> On Sat, Jul 27, 2019 at 7:37 PM Christian Mauderer  > wrote:
> 
> On 26/07/2019 13:41, Christian Mauderer wrote:
> > On 26/07/2019 13:22, Vijay Kumar Banerjee wrote:
> >> Hello everyone!
> >>
> >> I'm excited to post the following patchset. With this patchset
> >> I have the framebuffer working in BBB and have tested it with a
> >> BBB revC with HDMI connected Screen.
> >>
> >> This patchset uses mmap and hence it's necessary to apply the
> >> patche ON TOP OF mmap patch to avoid merge conflict.
> >>
> >> In reply to this mail, I'll be attaching a picture of the screen
> >> where my rectangle drawing application made a nice red rectangle
> >> on the screen just like in FreeBSD.
> >>
> >> Thanks and regards,
> >> Vijay
> >>
> >
> > Hello Vijay,
> >
> > it's great that you now have a working driver. Well done.
> >
> > I hadn't had a look at most patches yet and most likely that will
> need a
> > bit of time. It's a lot of stuff. Most likely the bigger patches won't
> > reach the mailing list so maybe adding a link to a branch on your
> github
> > repo would be good.
> >
> > Note: Please don't send a v2 right now. I'm sure there are more
> comments
> > (maybe not only from me). Collect comments for at least one or two
> days
> > and create an update afterwards.
> >
> > Some notes reading the patch overview:
> >
> >> [PATCH 01/10] TDA19988 : Import from FreeBSD
> >> [PATCH 02/10] TDA19988 : port to RTEMS
> >> [PATCH 03/10] am335x display drivers: Import from FreeBSD
> >> [PATCH 04/10] am335x display drivers : Port to RTEMS
> >> [PATCH 05/10] fbd : Import from FreeBSD
> >> [PATCH 06/10] fbd : Port to RTEMS
> >
> > Is fbd a prerequisite of am335x_lcd? In that case it would have been
> > better to reorder the patches. As long as every version compiles (to
> > allow git bisect) I would accept that order too. But as a general rule
> > prerequisites should be prior to the parts that use it.
> >
> >> [PATCH 07/10] VT : Import from FreeBSD
> >> [PATCH 08/10] VT : Port to RTEMS
> >
> > Is the vt still necessary? I think it was an intermediate step to try
> > whether it's initializing the display. Did you try without it?
> >
> >> [PATCH 09/10] TI Pinmux : Import from FreeBSD
> >> [PATCH 10/10] TI Pinmux : Port to RTEMS
> >
> > Again: prerequisite. So they should be one of the first.
> >
> > Best regards
> >
> > Christian
> >
> 
> One general question: When trying the patches, my monitor has been set
> up as 1440x900 instead of it's native resolution. Did you check whether
> the resolution on your screen is set correctly?
> 
> It's not setting fb with the "preferred videomode", I can confirm that
> the resolution
> set by FreeBSD and RTEMS is same. 

OK. Sooner or later it might would be good to find out how to set
another resolution. Currently I have the following output:


Preferred mode: 1920x1200 @ 60Hz
Number of extension blocks: 1
fb0: detected videomode: 1440x900 @ 60KHz
fbd0 on fb0


It's a bit odd that not the preferred mode is used. But if it is the
same for FreeBSD it's OK for a start.

One other problem: I tried to create some solid regions and it seems
that there are a few artefacts. Can you try that on your screen and tell
me whether you get them too? For the code and an image how it looks like
on my screen take a look at
https://gist.github.com/c-mauderer/051689bb1199caf20a08d9844c44c113

Some of the lines vanished after a few seconds. I think that could be a
memory caching issue.

> 
> Best regards
> 
> Christian
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 08/10] VT : Port to RTEMS

2019-07-28 Thread Christian Mauderer 
On 27/07/2019 22:31, Vijay Kumar Banerjee wrote:
> 
> 
> On Sat, Jul 27, 2019 at 7:26 PM Christian Mauderer  > wrote:
> 
> I'm still not entirely convinced what VT does. I tried to remove it (had
> to remove the vt_fb_attach() / _detach() from fbd.c too) and it still
> works. So why do you need VT?
> 
> I removed the VT commit and the app was not able to open the fb device,
> if you can open the device with just removing the VT part from fbd, then
> maybe some other part of the VT commit is necessary to open the device,
> I'll have a look and report and try to see if minimum to no parts of vt
> is needed.
> (We already removed most part from it, just initialization is there). 

That's odd. I can just revert the two VT patches with "git revert ",
remove vt_fb_attach() / ..._detach() and I still get an output.

> 
> By the way: The fbd commits won't link without that one. So if you
> convince me that VT is necessary you _have_ to reorder or merge fbd and
> VT. We can't have any commits that don't compile. It would prevent to
> use tools like `git bisect`.
> 
> OK. I will merge them into one FBD patch then and put them before the
> display
> driver patch of am335x
> 
> On 26/07/2019 13:22, Vijay Kumar Banerjee wrote:
> > ---
> >  freebsd/sys/dev/vt/colors/vt_termcolors.c |  2 ++
> >  freebsd/sys/dev/vt/hw/fb/vt_fb.c          |  2 ++
> >  freebsd/sys/dev/vt/vt_core.c              | 30
> +++
> >  libbsd.py                                 |  3 +++
> >  rtemsbsd/include/machine/vm.h             |  1 +
> >  5 files changed, 38 insertions(+)
> >
> > diff --git a/freebsd/sys/dev/vt/colors/vt_termcolors.c
> b/freebsd/sys/dev/vt/colors/vt_termcolors.c
> > index c7ef4b80..6a3836c4 100644
> > --- a/freebsd/sys/dev/vt/colors/vt_termcolors.c
> > +++ b/freebsd/sys/dev/vt/colors/vt_termcolors.c
> > @@ -144,6 +144,7 @@ vt_palette_init(void)
> >       for (i = 0; i < NCOLORS; i++) {
> >               snprintf(tunable, sizeof(tunable),
> >                   "kern.vt.color.%d.rgb", i);
> > +#ifndef __rtems__
> >               if (TUNABLE_STR_FETCH(tunable, rgb, sizeof(rgb))) {
> >                       if (vt_parse_rgb_triplet(rgb, , , ) ==
> 0) {
> >                               /* convert to percentages */
> > @@ -152,6 +153,7 @@ vt_palette_init(void)
> >                               color_def[i].b = b*100/255;
> >                       }
> >               }
> > +#endif /* __rtems__ */>      }
> >  }
> > 
> > diff --git a/freebsd/sys/dev/vt/hw/fb/vt_fb.c
> b/freebsd/sys/dev/vt/hw/fb/vt_fb.c
> > index 8eb2744b..c9544c06 100644
> > --- a/freebsd/sys/dev/vt/hw/fb/vt_fb.c
> > +++ b/freebsd/sys/dev/vt/hw/fb/vt_fb.c
> > @@ -51,10 +51,12 @@ static struct vt_driver vt_fb_driver = {
> >       .vd_init = vt_fb_init,
> >       .vd_fini = vt_fb_fini,
> >       .vd_blank = vt_fb_blank,
> > +#ifndef __rtems__
> >       .vd_bitblt_text = vt_fb_bitblt_text,
> >       .vd_invalidate_text = vt_fb_invalidate_text,
> >       .vd_bitblt_bmp = vt_fb_bitblt_bitmap,
> >       .vd_drawrect = vt_fb_drawrect,
> > +#endif /* __rtems__ */
> >       .vd_setpixel = vt_fb_setpixel,
> >       .vd_postswitch = vt_fb_postswitch,
> >       .vd_priority = VD_PRIORITY_GENERIC+10,> diff --git
> a/freebsd/sys/dev/vt/vt_core.c b/freebsd/sys/dev/vt/vt_core.c
> > index 5f2b1b0e..af0e47eb 100644
> > --- a/freebsd/sys/dev/vt/vt_core.c
> > +++ b/freebsd/sys/dev/vt/vt_core.c
> > @@ -47,7 +47,9 @@ __FBSDID("$FreeBSD$");
> >  #include 
> >  #include 
> >  #include 
> > +#ifndef __rtems__
> >  #include 
> > +#endif /* __rtems__ */
> >  #include 
> >  #include 
> >  #include 
> > @@ -83,6 +85,7 @@ static tc_opened_t  vtterm_opened;
> >  static tc_ioctl_t    vtterm_ioctl;
> >  static tc_mmap_t     vtterm_mmap;
> > 
> > +#ifndef __rtems__
> >  const struct terminal_class vt_termclass = {
> >       .tc_bell        = vtterm_bell,
> >       .tc_cursor      = vtterm_cursor,
> > @@ -104,6 +107,7 @@ const struct terminal_class vt_termclass = {
> >       .tc_ioctl       = vtterm_ioctl,
> >       .tc_mmap        = vtterm_mmap,
> >  };
> > +#endif /* __rtems__ */
> > 
> >  /*
> >   * Use a constant timer of 25 Hz to redraw the screen.
> > @@ -129,6 +133,7 @@ static VT_SYSCTL_INT(debug, 0, "vt(9) debug
> level");
> >  static VT_SYSCTL_INT(deadtimer, 15, "Time to wait busy process in
> VT_PROCESS mode");
> >  static VT_SYSCTL_INT(suspendswitch, 1, "Switch to VT0 before
> suspend");
> > 
> > +#ifndef __rtems__
> >  /* Allow to disable some keyboard combinations. */
> >  static VT_SYSCTL_INT(kbd_halt, 1, "Enable halt keyboard
> combination.  "
> >      "See