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

[Vijay Kumar Banerjee]

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).

> 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_tvtterm_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 kbdmap(5) to configure.");
> > @@ -149,11 +154,13 @@ VT_SYSCTL_INT(splash_ncpu, 0, "Override number of
> logos displayed "
> >  VT_SYSCTL_INT(splash_cpu_style, 2, "Draw logo style "
> >  "(0 = Alternate beastie, 1 = Beastie, 2 = Orb)");
> >  VT_SYSCTL_INT(splash_cpu_duration, 10, "Hide logos after (seconds)");
> > +#endif /* __rtems__ */
> >
> >  static unsigned int vt_unit = 0;
> >  static MALLOC_DEFINE(M_VT, "vt", "vt device");
> >  struct vt_device *main_vd = _consdev;
> >
> > +#ifndef __rtems__
> >  /* Boot logo. */
> >  extern unsigned int vt_logo_width;
> >  extern unsigned int vt_logo_height;
> > @@ -169,6 +176,7 @@ extern struct 

Re: [PATCH] Add framebuffer in BBB

[Vijay Kumar Banerjee]

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.

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

Re: [PATCH] Add framebuffer in BBB

[Christian Mauderer]

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?

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

[Christian Mauderer]

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.

> +],
> +mm.generator['source']()
> +)
> +
>  #
>  # USB
>  #
> @@ -5198,6 +5230,7 @@ def load(mm):
>  mm.addModule(evdev(mm))
>  mm.addModule(iic(mm))
>  mm.addModule(display(mm))
> +mm.addModule(ti_pinmux(mm))
>  
>  mm.addModule(dev_usb(mm))
>  mm.addModule(dev_usb_controller(mm))
> diff --git a/rtemsbsd/include/bsp/nexus-devices.h 
> b/rtemsbsd/include/bsp/nexus-devices.h
> index 313c40d4..a22102c8 100644
> --- a/rtemsbsd/include/bsp/nexus-devices.h
> +++ b/rtemsbsd/include/bsp/nexus-devices.h
> @@ -54,6 +54,7 @@ RTEMS_BSD_DRIVER_SMC0(0x4e00,  RVPBXA9_IRQ_ETHERNET);
>  RTEMS_BSD_DEFINE_NEXUS_DEVICE(ofwbus, 0, 0, NULL);
>  SYSINIT_DRIVER_REFERENCE(simplebus, ofwbus);
>  SYSINIT_DRIVER_REFERENCE(ti_scm, simplebus);
> +SYSINIT_DRIVER_REFERENCE(ti_pinmux, simplebus);
>  SYSINIT_DRIVER_REFERENCE(am335x_prcm, simplebus);
>  SYSINIT_DRIVER_REFERENCE(usbss, simplebus);
>  SYSINIT_DRIVER_REFERENCE(musbotg, usbss);
> diff --git a/rtemsbsd/include/machine/rtems-bsd-kernel-namespace.h 
> b/rtemsbsd/include/machine/rtems-bsd-kernel-namespace.h
> index d796d3d1..96ca6a7c 100644
> --- a/rtemsbsd/include/machine/rtems-bsd-kernel-namespace.h
> +++ 

Re: [PATCH 06/10] fbd : Port to RTEMS

[Christian Mauderer]

On 27/07/2019 15:15, Christian Mauderer wrote:
> On 26/07/2019 13:22, Vijay Kumar Banerjee wrote:
>> ---
>>  freebsd/sys/dev/fb/fbd.c  |  3 ++
>>  libbsd.py |  4 +++
>>  rtemsbsd/include/bsp/nexus-devices.h  |  3 ++
>>  .../machine/rtems-bsd-kernel-namespace.h  | 35 +++
>>  rtemsbsd/include/rtems/bsd/local/opt_fb.h |  0
>>  5 files changed, 45 insertions(+)
>>  create mode 100644 rtemsbsd/include/rtems/bsd/local/opt_fb.h
>>
>> diff --git a/freebsd/sys/dev/fb/fbd.c b/freebsd/sys/dev/fb/fbd.c
>> index 60ce4bc3..33cdc348 100644
>> --- a/freebsd/sys/dev/fb/fbd.c
>> +++ b/freebsd/sys/dev/fb/fbd.c
>> @@ -59,6 +59,9 @@ __FBSDID("$FreeBSD$");
>>  #include 
>>  
>>  #include 
>> +#ifdef __rtems__
>> +#define vtophys(a) (a)
>> +#endif /* __rtems__ */
> 
> That seems to be already defined in rtemsbsd/include/machine/vm.h which
> should be included via . Why is it necessary?

Just have noted it: You added that to machine/vm.h in your later patch.
So it should be removable here (if you merge the patches) or you should
move the definition in machine/vm.h to this patch (if you don't merge them).

> 
>>  
>>  LIST_HEAD(fb_list_head_t, fb_list_entry) fb_list_head =
>>  LIST_HEAD_INITIALIZER(fb_list_head);
>> diff --git a/libbsd.py b/libbsd.py
>> index 4808105b..71eb3577 100644
>> --- a/libbsd.py
>> +++ b/libbsd.py
>> @@ -807,6 +807,8 @@ class display(builder.Module):
>>  'sys/sys/fbio.h',
>>  'sys/sys/consio.h',
>>  'sys/sys/terminal.h',
>> +'sys/dev/vt/hw/fb/vt_fb.h',
>> +'sys/dev/vt/colors/vt_termcolors.h',
>>  ]
>>  )
>>  self.addKernelSpaceSourceFiles(
>> @@ -821,6 +823,8 @@ class display(builder.Module):
>>  'sys/arm/ti/am335x/am335x_lcd.c',
>>  'sys/arm/ti/am335x/am335x_pwmss.c',
>>  'sys/arm/ti/am335x/am335x_ecap.c',
>> +'sys/dev/fb/fb.c',
>> +'sys/dev/fb/fbd.c',
>>  ],
>>  mm.generator['source']()
>>  )
>> diff --git a/rtemsbsd/include/bsp/nexus-devices.h 
>> b/rtemsbsd/include/bsp/nexus-devices.h
>> index 2c718295..313c40d4 100644
>> --- a/rtemsbsd/include/bsp/nexus-devices.h
>> +++ b/rtemsbsd/include/bsp/nexus-devices.h
>> @@ -68,6 +68,9 @@ SYSINIT_DRIVER_REFERENCE(ofw_iicbus, rtems_i2c);
>>  SYSINIT_DRIVER_REFERENCE(iic, iicbus);
>>  SYSINIT_DRIVER_REFERENCE(tda, iicbus);
>>  SYSINIT_DRIVER_REFERENCE(iicbus, rtems_i2c);
>> +SYSINIT_DRIVER_REFERENCE(fbd, fb);
>> +SYSINIT_DRIVER_REFERENCE(fb, fb_mod);
>> +SYSINIT_MODULE_REFERENCE(fb_mod);
>>  #ifdef RTEMS_BSD_MODULE_NET80211
>>  SYSINIT_DRIVER_REFERENCE(rtwn_usb, uhub);
>>  SYSINIT_MODULE_REFERENCE(wlan_ratectl_none);
>> diff --git a/rtemsbsd/include/machine/rtems-bsd-kernel-namespace.h 
>> b/rtemsbsd/include/machine/rtems-bsd-kernel-namespace.h
>> index 3951da79..d796d3d1 100644
>> --- a/rtemsbsd/include/machine/rtems-bsd-kernel-namespace.h
>> +++ b/rtemsbsd/include/machine/rtems-bsd-kernel-namespace.h
>> @@ -1266,6 +1266,16 @@
>>  #define eventhandler_find_list _bsd_eventhandler_find_list
>>  #define eventhandler_prune_list _bsd_eventhandler_prune_list
>>  #define eventhandler_register _bsd_eventhandler_register
>> +#define fb_commonioctl _bsd_fb_commonioctl
>> +#define fbd_devclass _bsd_fbd_devclass
>> +#define fbd_driver _bsd_fbd_driver
>> +#define fbd_list _bsd_fbd_list
>> +#define fbd_register _bsd_fbd_register
>> +#define fb_dump_adp_info _bsd_fb_dump_adp_info
>> +#define fb_dump_mode_info _bsd_fb_dump_mode_info
>> +#define fbd_unregister _bsd_fbd_unregister
>> +#define fb_list_head _bsd_fb_list_head
>> +#define fb_type _bsd_fb_type
>>  #define fdt_addrsize_cells _bsd_fdt_addrsize_cells
>>  #define fdt_data_get _bsd_fdt_data_get
>>  #define fdt_data_to_res _bsd_fdt_data_to_res
>> @@ -5515,8 +5525,18 @@
>>  #define vht80_chan_ranges _bsd_vht80_chan_ranges
>>  #define vesagtf_mode _bsd_vesagtf_mode
>>  #define vesagtf_mode_params _bsd_vesagtf_mode_params
>> +#define vid_allocate _bsd_vid_allocate
>> +#define vid_configure _bsd_vid_configure
>>  #define videomode_count _bsd_videomode_count
>>  #define videomode_list _bsd_videomode_list
>> +#define vid_find_adapter _bsd_vid_find_adapter
>> +#define vid_get_adapter _bsd_vid_get_adapter
>> +#define vid_get_switch _bsd_vid_get_switch
>> +#define vid_init_struct _bsd_vid_init_struct
>> +#define vid_register _bsd_vid_register
>> +#define vid_release _bsd_vid_release
>> +#define vidsw _bsd_vidsw
>> +#define vid_unregister _bsd_vid_unregister
>>  #define vlan_cookie_p _bsd_vlan_cookie_p
>>  #define vlan_devat_p _bsd_vlan_devat_p
>>  #define vlan_input_p _bsd_vlan_input_p
>> @@ -5533,6 +5553,21 @@
>>  #define vsnprintf _bsd_vsnprintf
>>  #define vsnrprintf 

Re: [PATCH 06/10] fbd : Port to RTEMS

[Christian Mauderer]

On 26/07/2019 13:22, Vijay Kumar Banerjee wrote:
> ---
>  freebsd/sys/dev/fb/fbd.c  |  3 ++
>  libbsd.py |  4 +++
>  rtemsbsd/include/bsp/nexus-devices.h  |  3 ++
>  .../machine/rtems-bsd-kernel-namespace.h  | 35 +++
>  rtemsbsd/include/rtems/bsd/local/opt_fb.h |  0
>  5 files changed, 45 insertions(+)
>  create mode 100644 rtemsbsd/include/rtems/bsd/local/opt_fb.h
> 
> diff --git a/freebsd/sys/dev/fb/fbd.c b/freebsd/sys/dev/fb/fbd.c
> index 60ce4bc3..33cdc348 100644
> --- a/freebsd/sys/dev/fb/fbd.c
> +++ b/freebsd/sys/dev/fb/fbd.c
> @@ -59,6 +59,9 @@ __FBSDID("$FreeBSD$");
>  #include 
>  
>  #include 
> +#ifdef __rtems__
> +#define vtophys(a) (a)
> +#endif /* __rtems__ */

That seems to be already defined in rtemsbsd/include/machine/vm.h which
should be included via . Why is it necessary?

>  
>  LIST_HEAD(fb_list_head_t, fb_list_entry) fb_list_head =
>  LIST_HEAD_INITIALIZER(fb_list_head);
> diff --git a/libbsd.py b/libbsd.py
> index 4808105b..71eb3577 100644
> --- a/libbsd.py
> +++ b/libbsd.py
> @@ -807,6 +807,8 @@ class display(builder.Module):
>  'sys/sys/fbio.h',
>  'sys/sys/consio.h',
>  'sys/sys/terminal.h',
> +'sys/dev/vt/hw/fb/vt_fb.h',
> +'sys/dev/vt/colors/vt_termcolors.h',
>  ]
>  )
>  self.addKernelSpaceSourceFiles(
> @@ -821,6 +823,8 @@ class display(builder.Module):
>  'sys/arm/ti/am335x/am335x_lcd.c',
>  'sys/arm/ti/am335x/am335x_pwmss.c',
>  'sys/arm/ti/am335x/am335x_ecap.c',
> +'sys/dev/fb/fb.c',
> +'sys/dev/fb/fbd.c',
>  ],
>  mm.generator['source']()
>  )
> diff --git a/rtemsbsd/include/bsp/nexus-devices.h 
> b/rtemsbsd/include/bsp/nexus-devices.h
> index 2c718295..313c40d4 100644
> --- a/rtemsbsd/include/bsp/nexus-devices.h
> +++ b/rtemsbsd/include/bsp/nexus-devices.h
> @@ -68,6 +68,9 @@ SYSINIT_DRIVER_REFERENCE(ofw_iicbus, rtems_i2c);
>  SYSINIT_DRIVER_REFERENCE(iic, iicbus);
>  SYSINIT_DRIVER_REFERENCE(tda, iicbus);
>  SYSINIT_DRIVER_REFERENCE(iicbus, rtems_i2c);
> +SYSINIT_DRIVER_REFERENCE(fbd, fb);
> +SYSINIT_DRIVER_REFERENCE(fb, fb_mod);
> +SYSINIT_MODULE_REFERENCE(fb_mod);
>  #ifdef RTEMS_BSD_MODULE_NET80211
>  SYSINIT_DRIVER_REFERENCE(rtwn_usb, uhub);
>  SYSINIT_MODULE_REFERENCE(wlan_ratectl_none);
> diff --git a/rtemsbsd/include/machine/rtems-bsd-kernel-namespace.h 
> b/rtemsbsd/include/machine/rtems-bsd-kernel-namespace.h
> index 3951da79..d796d3d1 100644
> --- a/rtemsbsd/include/machine/rtems-bsd-kernel-namespace.h
> +++ b/rtemsbsd/include/machine/rtems-bsd-kernel-namespace.h
> @@ -1266,6 +1266,16 @@
>  #define  eventhandler_find_list _bsd_eventhandler_find_list
>  #define  eventhandler_prune_list _bsd_eventhandler_prune_list
>  #define  eventhandler_register _bsd_eventhandler_register
> +#define  fb_commonioctl _bsd_fb_commonioctl
> +#define  fbd_devclass _bsd_fbd_devclass
> +#define  fbd_driver _bsd_fbd_driver
> +#define  fbd_list _bsd_fbd_list
> +#define  fbd_register _bsd_fbd_register
> +#define  fb_dump_adp_info _bsd_fb_dump_adp_info
> +#define  fb_dump_mode_info _bsd_fb_dump_mode_info
> +#define  fbd_unregister _bsd_fbd_unregister
> +#define  fb_list_head _bsd_fb_list_head
> +#define  fb_type _bsd_fb_type
>  #define  fdt_addrsize_cells _bsd_fdt_addrsize_cells
>  #define  fdt_data_get _bsd_fdt_data_get
>  #define  fdt_data_to_res _bsd_fdt_data_to_res
> @@ -5515,8 +5525,18 @@
>  #define  vht80_chan_ranges _bsd_vht80_chan_ranges
>  #define  vesagtf_mode _bsd_vesagtf_mode
>  #define  vesagtf_mode_params _bsd_vesagtf_mode_params
> +#define  vid_allocate _bsd_vid_allocate
> +#define  vid_configure _bsd_vid_configure
>  #define  videomode_count _bsd_videomode_count
>  #define  videomode_list _bsd_videomode_list
> +#define  vid_find_adapter _bsd_vid_find_adapter
> +#define  vid_get_adapter _bsd_vid_get_adapter
> +#define  vid_get_switch _bsd_vid_get_switch
> +#define  vid_init_struct _bsd_vid_init_struct
> +#define  vid_register _bsd_vid_register
> +#define  vid_release _bsd_vid_release
> +#define  vidsw _bsd_vidsw
> +#define  vid_unregister _bsd_vid_unregister
>  #define  vlan_cookie_p _bsd_vlan_cookie_p
>  #define  vlan_devat_p _bsd_vlan_devat_p
>  #define  vlan_input_p _bsd_vlan_input_p
> @@ -5533,6 +5553,21 @@
>  #define  vsnprintf _bsd_vsnprintf
>  #define  vsnrprintf _bsd_vsnrprintf
>  #define  vsprintf _bsd_vsprintf
> +#define  vt_fb_attach _bsd_vt_fb_attach
> +#define  vt_fb_bitblt_bitmap _bsd_vt_fb_bitblt_bitmap
> +#define  vt_fb_bitblt_text _bsd_vt_fb_bitblt_text
> +#define  vt_fb_blank _bsd_vt_fb_blank
> +#define  vt_fb_detach _bsd_vt_fb_detach
> +#define  vt_fb_drawrect 

Re: [PATCH 05/10] fbd : Import from FreeBSD

[Christian Mauderer]

On 26/07/2019 13:22, Vijay Kumar Banerjee wrote:
> ---
>  freebsd/sys/dev/fb/fb.c   | 762 ++
>  freebsd/sys/dev/fb/fbd.c  | 372 +++
>  freebsd/sys/dev/vt/colors/vt_termcolors.h |  63 ++
>  freebsd/sys/dev/vt/hw/fb/vt_fb.h  |  54 ++

Again: Part of vt is already imported here. Maybe it would be good to
merge the VT and fbd patches and put them before am335x_lcd? That would
split it up in a general display framework patch and one special driver.

>  4 files changed, 1251 insertions(+)
>  create mode 100644 freebsd/sys/dev/fb/fb.c
>  create mode 100644 freebsd/sys/dev/fb/fbd.c
>  create mode 100644 freebsd/sys/dev/vt/colors/vt_termcolors.h
>  create mode 100644 freebsd/sys/dev/vt/hw/fb/vt_fb.h
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Add framebuffer in BBB

[Christian Mauderer]

On 27/07/2019 02:52, Chris Johns wrote:
> On 26/7/19 9:41 pm, Christian Mauderer wrote:
>> 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.
> 
> There are no oversize posts in the thread.
> 
> Chris

Hello Chris,

thanks for checking that. In my experience a lot of FreeBSD import
commits tend to be over the limit. Vijay put me on CC so I didn't see
whether all patches have been sent to the mailing list. Therefore I
thought it would be worth noting it.

Best regards

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

Re: GSoC PRU: AM35xx Clock driver

[Christian Mauderer]

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.

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.

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 error code.
> 
> I remember testing this a few days ago for my fb drivers and
> it was attaching alright,
> if I remember correctly. If changing the dtb doesn't work
> for you, I won't mind checking
> again, this will give me a hint for the display issue as well. 
> 
> I will keep you updated on this.
> Would you be so kind and send me your compiled device tree? 
> 
> Please find it attached in this mail. 
> 
> Note: I have removed the 

Re: [PATCH v2] user/exe : Add Device Tree section

[Christian Mauderer]

Hello Vijay,

sorry for the long delay between posting and review. It was a busy week.

Would that replace part of the documentation you did in the beagle BSP?
In that case it might could be good to remove it from there and put up a
reference.

@all: Could one of our native English speakers please proof-read that too?

On 23/07/2019 06:41, Vijay Kumar Banerjee wrote:
> ---
>  user/exe/device-tree.rst | 100 +++
>  user/exe/index.rst   |   1 +
>  2 files changed, 101 insertions(+)
>  create mode 100644 user/exe/device-tree.rst
> 
> diff --git a/user/exe/device-tree.rst b/user/exe/device-tree.rst
> new file mode 100644
> index 000..fcbcfd7
> --- /dev/null
> +++ b/user/exe/device-tree.rst
> @@ -0,0 +1,100 @@
> +.. SPDX-License-Identifier: CC-BY-SA-4.0
> +
> +.. Copyright (C) 2018 Vijay Kumar Banerjee 

Wrong year. Except you started with that last year.

> +
> +Device Tree
> +===
> +.. index:: Device Tree
> +
> +A Device Tree is a data structure that is used to describe properties of
> +non-discoverable hardware instead of hardcoding them on the Kernel. The 
> device
> +tree data is generally stored in a `.dts` or a Device Tree Source (DTS) file.
> +This file is then compiled into a binary format called Device Tree Blob (DTB)
> +with `.dtb` extension. RTEMS preferably uses DTB built from the FreeBSD 
> source
> +tree matching the libbsd HEAD commit hash.

If RTEMS is used together with libbsd the DTB should be build from the
FreeBSD source tree matching the commit that is used for `freebsd-org`
in libbsd.

> +
> +Building the DTB
> +
> +
> +A single device tree source (DTS) file can be built using the `dtc` tool in
> +libfdt using the following command :
> +
> +.. code-block:: none
> +
> +dtc -I dts -O dtb -o my-devicetree.dtb my-devicetree.dts
> +

Maybe already mention the -@ option here if someone wants to use overlays.

> +For building the DTS from the FreeBSD source, the `make_dtb.sh` script
> +from `freebsd/sys/tools/fdt` must be used as most of the DTS files in FreeBSD
> +have included `.dtsi` files from their source tree. An example is given 
> below as
> +a reference of how to build the device tree from the FreeBSD source.
> +
> +`NOTE : The following example uses FreeBSD master branch from github mirror 
> as

I think there shouldn't be a space between NOTE and the colon, should there?

> +an example. It is advised to always use the source from the commit matching 
> the
> +libBSD HEAD.`

... matching `freebsd_org` in libbsd.

> +
> +.. code-block:: shell
> +   :linenos:
> +
> + #We're using the script from freebsd/sys/tools/make_dtb.sh
> + #Target device: Beaglebone Black.
> + #Architecture: Arm.
> + #DTS source name: am335x-boneblack.dts
> +
> + #The make_dtb.sh script uses environment variable MACHINE
> + export MACHINE='arm'
> +
> + SCRIPT_DIR=$HOME/freebsd/sys/tools/fdt
> +
> + #The arguments to the script are
> + # $1 -> Build Tree (This is the path to freebsd/sys/ directory)
> + # $2 -> DTS source file
> + # $3 -> output path of the DTB file
> +
> + ${SCRIPT_DIR}/make_dtb.sh ${SCRIPT_DIR}/../../ \
> + ${SCRIPT_DIR}/../../gnu/dts/arm/am335x-boneblack.dts \
> + $(pwd)
> +
> +Using Device Tree Overlay
> +-
> +
> +Device tree overlay is used either to add properties or devices to the 
> existing
> +device tree. Adding any property to DTS using an overlay will override the
> +current values in the DTB. The Overlays enable us to modify the device tree
> +using a small maintainable plugin without having to edit the whole Base Tree.
> +
> +There are two ways of applying an overlay on top of the built dtb.
> +
> +#. Use fdtoverlay from libfdt
> +
> +#. Add the overlay in the root partition of the SDcard and apply it using 
> u-boot

"U-Boot" - they use big letters on their home page:
http://www.denx.de/wiki/U-Boot. Please also fix that in the rest of the
text below.

> +   from the uEnv.txt file.

uEnv.txt isn't a must. I think it's a Beagle convention (and maybe for
some other boards too). Just stop after "apply it using U-Boot"

> +
> +The fdtoverlay command can be used as follows:
> +
> +.. code-block:: none
> +
> +fdtoverlay -i my-base-tree.dtb -o output-tree.dtb my-overlay.dtbo
> +
> +To apply it from u-boot during system initialization we have to add the 
> device
> +tree overlay file in the root directory of the SDcard and use uEnv.txt to 
> load
> +and apply the overlay.

Again: SD card (by the way: There should be a space between SD and card
as far as I know) and uEnv.txt is for Beagle.

> +
> +Below is a sample script that can be used as a reference to write the 
> uEnv.txt
> +properly so that it applies all the overlays (.dtbo):
> +
> +.. code-block:: shell
> +:linenos:
> +
> +overlays="fdt addr 0x8800"
> +app=rtems-app.img
> +DTB_INSTALL_NAME=my-basetree.dtb
> +
> +for f in "$(pwd)"/*.dtbo
> +do
> +

Re: [PATCH v5] Add mmap

[Christian Mauderer]

Pushed. Especially now that you have a display working with it, I'm OK
with that patch.

On 18/07/2019 10:56, Vijay Kumar Banerjee wrote:
> ---
>  freebsd/sys/kern/kern_conf.c   |  8 +++
>  freebsd/sys/sys/conf.h |  2 +-
>  rtemsbsd/include/machine/vm.h  |  2 ++
>  rtemsbsd/sys/fs/devfs/devfs_devs.c | 38 ++
>  testsuite/cdev01/test_cdev.c   | 21 -
>  testsuite/cdev01/test_cdev01.h |  3 ++-
>  testsuite/cdev01/test_main.c   |  4 
>  7 files changed, 71 insertions(+), 7 deletions(-)
> 
> diff --git a/freebsd/sys/kern/kern_conf.c b/freebsd/sys/kern/kern_conf.c
> index 92237d9d..560a450a 100644
> --- a/freebsd/sys/kern/kern_conf.c
> +++ b/freebsd/sys/kern/kern_conf.c
> @@ -328,8 +328,8 @@ static struct cdevsw dead_cdevsw = {
>   .d_write =  dead_write,
>   .d_ioctl =  dead_ioctl,
>   .d_poll =   dead_poll,
> -#ifndef __rtems__
>   .d_mmap =   dead_mmap,
> +#ifndef __rtems__
>   .d_strategy =   dead_strategy,
>  #endif /* __rtems__ */
>   .d_name =   "dead",
> @@ -522,7 +522,6 @@ giant_kqfilter(struct cdev *dev, struct knote *kn)
>   return (retval);
>  }
>  
> -#ifndef __rtems__
>  static int
>  giant_mmap(struct cdev *dev, vm_ooffset_t offset, vm_paddr_t *paddr, int 
> nprot,
>  vm_memattr_t *memattr)
> @@ -541,6 +540,7 @@ giant_mmap(struct cdev *dev, vm_ooffset_t offset, 
> vm_paddr_t *paddr, int nprot,
>   return (retval);
>  }
>  
> +#ifndef __rtems__
>  static int
>  giant_mmap_single(struct cdev *dev, vm_ooffset_t *offset, vm_size_t size,
>  vm_object_t *object, int nprot)
> @@ -667,8 +667,8 @@ prep_cdevsw(struct cdevsw *devsw, int flags)
>   devsw->d_write = dead_write;
>   devsw->d_ioctl = dead_ioctl;
>   devsw->d_poll = dead_poll;
> -#ifndef __rtems__
>   devsw->d_mmap = dead_mmap;
> +#ifndef __rtems__
>   devsw->d_mmap_single = dead_mmap_single;
>   devsw->d_strategy = dead_strategy;
>   devsw->d_dump = dead_dump;
> @@ -702,8 +702,8 @@ prep_cdevsw(struct cdevsw *devsw, int flags)
>   FIXUP(d_write,  no_write,   giant_write);
>   FIXUP(d_ioctl,  no_ioctl,   giant_ioctl);
>   FIXUP(d_poll,   no_poll,giant_poll);
> -#ifndef __rtems__
>   FIXUP(d_mmap,   no_mmap,giant_mmap);
> +#ifndef __rtems__
>   FIXUP(d_strategy,   no_strategy,giant_strategy);
>  #endif /* __rtems__ */
>   FIXUP(d_kqfilter,   no_kqfilter,giant_kqfilter);
> diff --git a/freebsd/sys/sys/conf.h b/freebsd/sys/sys/conf.h
> index 4ace162f..c0a66442 100644
> --- a/freebsd/sys/sys/conf.h
> +++ b/freebsd/sys/sys/conf.h
> @@ -209,8 +209,8 @@ struct cdevsw {
>   d_write_t   *d_write;
>   d_ioctl_t   *d_ioctl;
>   d_poll_t*d_poll;
> -#ifndef __rtems__
>   d_mmap_t*d_mmap;
> +#ifndef __rtems__
>   d_strategy_t*d_strategy;
>   dumper_t*d_dump;
>  #endif /* __rtems__ */
> diff --git a/rtemsbsd/include/machine/vm.h b/rtemsbsd/include/machine/vm.h
> index e69de29b..351b7472 100644
> --- a/rtemsbsd/include/machine/vm.h
> +++ b/rtemsbsd/include/machine/vm.h
> @@ -0,0 +1,2 @@
> +#define VM_MEMATTR_DEFAULT 0
> +#define VM_MEMATTR_UNCACHEABLE 1
> diff --git a/rtemsbsd/sys/fs/devfs/devfs_devs.c 
> b/rtemsbsd/sys/fs/devfs/devfs_devs.c
> index 7c697b0a..7b09e530 100644
> --- a/rtemsbsd/sys/fs/devfs/devfs_devs.c
> +++ b/rtemsbsd/sys/fs/devfs/devfs_devs.c
> @@ -387,6 +387,43 @@ devfs_imfs_kqfilter(rtems_libio_t *iop, struct knote *kn)
>   return error;
>  }
>  
> +static int
> +devfs_imfs_mmap(rtems_libio_t *iop, void **addr, size_t len, int prot,
> +off_t off)
> +{
> + struct cdev *cdev = devfs_imfs_get_context_by_iop(iop);
> + struct file *fp = rtems_bsd_iop_to_fp(iop);
> + struct thread *td = rtems_bsd_get_curthread_or_null();
> + struct file *fpop;
> + struct cdevsw *dsw;
> + int error, ref;
> +
> + if (td != 0) {
> + if (cdev == NULL) {
> + error = ENXIO;
> + goto err;
> + }
> + if (cdev->si_flags & SI_ALIAS) {
> + cdev = cdev->si_parent;
> + }
> + dsw = dev_refthread(cdev, );
> + if (dsw == NULL) {
> + error = ENXIO;
> + goto err;
> + }
> + fpop = td->td_fpop;
> + curthread->td_fpop = fp;
> + error = dsw->d_mmap( cdev, off, (vm_paddr_t *) addr, prot, 
> VM_MEMATTR_DEFAULT);
> + td->td_fpop = fpop;
> + dev_relthread(cdev, ref);
> + } else {
> + error = ENOMEM;
> + }
> +
> +err:
> + return rtems_bsd_error_to_status_and_errno(error);
> +}
> +
>  static const rtems_filesystem_file_handlers_r devfs_imfs_handlers = {
>   .open_h = 

Re: [PATCH] user/bsps : Fix formatting and typo in arm/beagle

[Christian Mauderer]

Pushed.

On 22/07/2019 06:12, Vijay Kumar Banerjee wrote:
> ---
>  user/bsps/arm/beagle.rst | 55 +++-
>  1 file changed, 37 insertions(+), 18 deletions(-)
> 
> diff --git a/user/bsps/arm/beagle.rst b/user/bsps/arm/beagle.rst
> index 84bfe2d..eb4ecfb 100644
> --- a/user/bsps/arm/beagle.rst
> +++ b/user/bsps/arm/beagle.rst
> @@ -5,10 +5,10 @@
>  beagle
>  ==
>  
> -This BSP supports four variants, `beagleboardorig`, `beagleboardxm`, 
> `beaglebonewhite`
> -and `beagleboneblack`. The basic hardware initialization is not performed by
> -the BSP.  A boot loader with device tree support must be used to start the 
> BSP,
> -e.g. U-Boot.
> +This BSP supports four variants, `beagleboardorig`, `beagleboardxm`,
> +`beaglebonewhite` and `beagleboneblack`. The basic hardware initialization is
> +not performed by the BSP.  A boot loader with device tree support must be 
> used
> +to start the BSP, e.g., U-Boot.
>  
>  TODO(These drivers are present but not documented yet):
>  
> @@ -33,33 +33,39 @@ To boot via uboot, the ELF must be converted to a U-Boot 
> image like below:
>  Getting the Device Tree Blob
>  
>  
> -The Device Tree Blob(dtb) is needed to load the device tree while starting up
> +The Device Tree Blob (DTB) is needed to load the device tree while starting 
> up
>  the kernel. We build the dtb from the FreeBSD source matching the commit hash
>  from the libbsd HEAD of freebsd-org. For example if the HEAD is at
>  "19a6ceb89dbacf74697d493e48c388767126d418"
> -Then the right dts file is:
> +Then the right Device Tree Source (DTS) file is:
>  
> https://github.com/freebsd/freebsd/blob/19a6ceb89dbacf74697d493e48c388767126d418/sys/gnu/dts/arm/am335x-boneblack.dts
>  
> -.. code-block:: none
> +.. code-block:: shell
> +   :linenos:
>  
>   #building the dtb
>   #We will use the script from 
> https://github.com/freebsd/freebsd/blob/19a6ceb89dbacf74697d493e48c388767126d418/sys/tools/fdt/make_dtb.sh
>  
> - export MACHINE='arm' #The make_dtb.sh script uses environment variable 
> MACHINE
> + #The make_dtb.sh script uses environment variable MACHINE
> + export MACHINE='arm'
> +
>   SCRIPT_DIR=$HOME/freebsd/sys/tools/fdt
> +
>   #The arguments to the script are
>   # $1 -> Build Tree
>   # $2 -> DTS source file
>   # $3 -> output path of the DTB file
> +
>   ${SCRIPT_DIR}/make_dtb.sh ${SCRIPT_DIR}/../../ \
>   ${SCRIPT_DIR}/../../gnu/dts/arm/am335x-boneblack.dts \
>   $(pwd)
> +
>  Writing the uEnv.txt file
>  -
>  
>  The uEnv.txt file is needed to set any environment variable before the 
> kernel is
> -loaded. Each line is a u-boot command that the uboot will execute during
> -starting up.
> +loaded. Each line is a u-boot command that the uboot will execute during 
> start
> +up.
>  
>  Add the following to a file named uEnv.txt:
>  
> @@ -72,8 +78,14 @@ Add the following to a file named uEnv.txt:
>  I2C Driver
>  --
>  
> -This BSP uses the I2C framework and is registered using
> -``am335x_i2c_bus_register()`` the function prototype is given below:
> +For registering the `/dev/i2c-0` device, a wrapper function is provided,
> +``bbb_register_i2c_0()`` similarly ``bbb_register_i2c_1()`` and
> +``bbb_register_i2c_2()`` are respectively used to register `i2c-1` and 
> `i2c-2`.
> +
> +For registering an I2C device with a custom path (say `/dev/i2c-3`) the
> +function ``am335x_i2c_bus_register()`` has to be used.
> +
> +The function prototype is given below:
>  
>  .. code-block:: C
>  
> @@ -84,12 +96,19 @@ This BSP uses the I2C framework and is registered using
> rtems_vector_number irq
> );
>  
> -This function is needed only while registering with custom path with custom
> -values. For registering the `/dev/i2c-0` device, a wrapper function is 
> provided,
> -``bbb_register_i2c_0()`` similarly ``bbb_register_i2c_1()`` and
> -``bbb_register_i2c_2()`` are respectively used to register `i2c-1` and 
> `i2c-2`.
> -
>  SPI Driver
>  --
>  
> -The SPI device `/dev/spi-0` can be registered with ``bbb_register_spi_0()```
> +The SPI device `/dev/spi-0` can be registered with ``bbb_register_spi_0()``
> +
> +For registering with a custom path, the ``bsp_register_spi()`` can be used.
> +
> +The function prototype is given below:
> +
> +.. code-block:: C
> +
> +rtems_status_code bsp_register_spi(
> +   const char *bus_path,
> +   uintptr_t   register_base,
> +   rtems_vector_number irq
> +);
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel