[PATCH 2/3] bsps/microblaze: Add support for multiple UARTs

[Alex White]

On Thu, Mar 30, 2023 at 5:54 PM Chris Johns <chrisj at rtems.org> wrote:
>
> On 31/3/2023 2:55 am, Alex White wrote:
> > On Wed, Mar 29, 2023 at 11:04 PM Chris Johns <chrisj at rtems.org> wrote:
> >>
> >> On 30/3/2023 12:26 pm, Sam Price wrote:
> >>> Same IP as the regular KCU105.
> >>> The current uart ip is dependent on the fpga.
> >>> I don't believe this modifies the kcu105 bsp, but allows other bsps to
> >>> support up to 4 uarts.
> >>
> >> I am not sure if this patch is OK. If the UART driver is needed for a console
> >> does that limits how it's configuration can be handled? If so that means the
> >> patch is OK. Adding options for a user's custom IP is questionable.
> >
> > This patch allows the user to use multiple instances of the same UART IP (AXI UART Lite v2.0) which is currently the only IP supported by the BSP.
>
> What happens if a user needs more than 4 ports? I was discussing such a project
> recently with someone and Microblaze may be an option?
>
> I do not have a better solution at the moment so I am just understand the what
> we accept and why plus how we manage it.

I see your point. A user could come along needing 5, 6, or 7 ports. It's not
sustainable to keep adding ports to the driver like this. It doesn't scale well
at all.

We probably need a build option for the maximum number of ports and a way to
configure the ports at runtime. This should be easy if the user is using a
device tree, but if they aren't, they need a way to specify the configuration of
each port.

It's late so I can't think of a good way to do this right now. Maybe only allow
some small number of ports (one?) to be specified if the user isn't using a
device tree?

Alex