Re: [PATCH v4] Raspberrypi: updated the console interface.

[Christian Mauderer]

On 01/01/2020 07:38, Niteesh wrote:
> How to turn off optimizations, while debugging some of the variables get
> optimized out.

First: Great that it works now.

Regarding optimization: Do a

export CFLAGS_OPTIMIZE_V="-O0 -g"

before configure and make. Alternatively change it in
bsps/arm/raspberrypi/config/raspberrypi.inc but be careful to not commit
that change.

> 
> On Wed, Jan 1, 2020 at 12:02 PM Niteesh  > wrote:
> 
> Good news, The FDT works. For testing purposes, I used a different
> DTB file provided by
> raspberrpi foundation. It has a different structure than the DTB
> from FreeBSD, so I modified the
> initialization code a little bit, but anyhow it works, the registers
> are initialized from the DTB file. But they are
> virtual addresses we need to offset them before initializing the
> registers.
> 
> (gdb) p pl011_context
> $23 = {base = {lock = {interrupt = {}, mutex =
> {_Queue = {_Lock = {_next_ticket = 0,
>             _now_serving = 0}, _heads = 0x0, _owner = 0x0, _name =
> 0x0}}},
>     lock_acquire = 0x2095d1 ,
>     lock_release = 0x2095e1
> },*regs = 0x7e201000*,
> irq = 0,
>   initial_baud = 0}
> (gdb) 
> 
> I will add the offset function, and send in the patch. I am also
> planning to replace a manual search with
> fdt_node_offset_by_compatible. 
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v4] Raspberrypi: updated the console interface.

[Niteesh]

How to turn off optimizations, while debugging some of the variables get
optimized out.

On Wed, Jan 1, 2020 at 12:02 PM Niteesh  wrote:

> Good news, The FDT works. For testing purposes, I used a different DTB
> file provided by
> raspberrpi foundation. It has a different structure than the DTB from
> FreeBSD, so I modified the
> initialization code a little bit, but anyhow it works, the registers are
> initialized from the DTB file. But they are
> virtual addresses we need to offset them before initializing the registers.
>
> (gdb) p pl011_context
> $23 = {base = {lock = {interrupt = {}, mutex = {_Queue =
> {_Lock = {_next_ticket = 0,
> _now_serving = 0}, _heads = 0x0, _owner = 0x0, _name = 0x0}}},
> lock_acquire = 0x2095d1 ,
> lock_release = 0x2095e1 },*
> regs = 0x7e201000*, irq = 0,
>   initial_baud = 0}
> (gdb)
>
> I will add the offset function, and send in the patch. I am also planning
> to replace a manual search with
> fdt_node_offset_by_compatible.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v4] Raspberrypi: updated the console interface.

[Niteesh]

Good news, The FDT works. For testing purposes, I used a different DTB file
provided by
raspberrpi foundation. It has a different structure than the DTB from
FreeBSD, so I modified the
initialization code a little bit, but anyhow it works, the registers are
initialized from the DTB file. But they are
virtual addresses we need to offset them before initializing the registers.

(gdb) p pl011_context
$23 = {base = {lock = {interrupt = {}, mutex = {_Queue =
{_Lock = {_next_ticket = 0,
_now_serving = 0}, _heads = 0x0, _owner = 0x0, _name = 0x0}}},
lock_acquire = 0x2095d1 ,
lock_release = 0x2095e1 },*
regs = 0x7e201000*, irq = 0,
  initial_baud = 0}
(gdb)

I will add the offset function, and send in the patch. I am also planning
to replace a manual search with
fdt_node_offset_by_compatible.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v4] Raspberrypi: updated the console interface.

[Christian Mauderer]

On 31/12/2019 19:41, Niteesh wrote:
> On Tue, Dec 31, 2019 at 10:56 PM Vijay Kumar Banerjee
> mailto:vijaykumar9...@gmail.com>> wrote:
> 
> 
> On Tue, Dec 31, 2019 at 9:27 PM Niteesh  > wrote:
> 
> I tried the above thing it doesn't work :(
> Maybe lets stop with this. And try to get RTEMS working on rpi3
> this way, it will also be easier for me to work. Did you take a
> look at what
> caused the secondary cpu's not to halt? Is there something that
> I can do?
> Or shall we continue with this? I kind of feel lost and not at
> all happy with my progress.
> 
> Hi Niteesh,
> 
> (Not commenting on anything technical)
> 
> Just wanted to add a famous quote:
> "The first 90 percent of the code accounts for the first 90 percent
> of the
> development time. The remaining 10 percent of the code accounts for the
> other 90 percent of the development time" — Tom Cargill, Bell Labs
> (Wikipedia explains this well
> )

True. Also I know it as a 90 / 10 rule: 90 percent of the code is
written in 10 percent of the time.

> 
> It always takes more time and much more debugging than it was
> originally planned,
> you have made quite good progress in figuring out stuff and came up
> with the
> implementation quite quickly. Seems like all that is left is
> debugging, and with Christian
> helping you, that will be solved quickly as well ;-)
> 
> Happy New year :)
> 
> Great, I hope now we can get it working even faster. I have looked at
> your previous year GSOC
> work, it was great.

+1

> 
> PS: I have a pi3 as well, and would love to join the efforts on pi3
> after the exams ;-)

Thanks Vijay. Would be great. By the way: You should think about
becoming a GSoC mentor this year.

> 
> All the best for your exams.

+1

> Happy New year

Happy New year to all of you too (also I still have 2 hours till the new
year here).

> 
> 
> On Tue, Dec 31, 2019 at 8:29 PM Niteesh  > wrote:
> 
> I have an idea to debug this, but not sure whether it will
> work or not, I could
> run raspbian on versatilepb using arm1176 as cpu and 256mb ram
> this is very much similar to raspi1, I think this one also
> uses pl011, I remember
> seeing it in the linux bootup msgs.
> I could run the examples using qemu using raspi2 as the
> machine but the dtb
> file never gets passed to it. The register r2 is 0.
> qemu-system-arm -M raspi2 -m 1G -kernel fileio.exe -serial
> mon:stdio -nographic -dtb bcm2709-rpi-2-b.dtb -S -s
> This is the command I use to run my examples and connect to gdb.

I assume you load your application using gdb too? Then I would suggest
to just load the dtb via gdb too and ignore the -dtb parameter.
Basically the following gdb commands should work:

(gdb) load
(gdb) restore bcm2709-rpi-2-b.dtb binary 0x2ef0
(gdb) set $r2=0x2ef0

I checked that on my rpi2: The original bootloader loads the dtb to
0x2eff9900. I'm not sure why it uses such an odd address but I assume
it's calculated somehow. I used one a bit lower than that.

If you don't want to type that stuff every time you might want to add a
"start.gdb" script. That can for example contain the following:

```
define reset
monitor system_reset
load
restore bcm2709-rpi-2-b.dtb binary 0x2ef0
set $r2=0x2ef0
end

target remote :2331
```

If you now start your gdb with

arm-rtems5-gdb -x start.gdb path/to/your.exe

you should have a nice "reset" command that just restarts the system.

> 
> On Tue, Dec 31, 2019 at 7:31 PM Christian Mauderer
> mailto:l...@c-mauderer.de>> wrote:
> 
> On 31/12/2019 14:56, Niteesh wrote:
> > If moving uart_probe to output char, then should I move 
> > rtems_device_handler_install to console_initialize
> because, my guess
> > is that the IO initialization system would not be
> initialized properly
> > at that stage.
> 
> The uart_probe in the output char function should do a
> really minimal
> initialization. Only what is necessary to get the polled
> uart working.
> That one will only be called if you have an exception at
> a very early
> stage. In that case you are working in an exception context.
> 
> >
> > When I rename the register_arm_pl011 to
> init_context_pl011 since it's is
> > only initializing
> > the pl011 context, rather than registering it.
> >
> 

Re: [PATCH v4] Raspberrypi: updated the console interface.

[Christian Mauderer]

On 31/12/2019 14:56, Niteesh wrote:
> If moving uart_probe to output char, then should I move 
> rtems_device_handler_install to console_initialize because, my guess
> is that the IO initialization system would not be initialized properly
> at that stage.

The uart_probe in the output char function should do a really minimal
initialization. Only what is necessary to get the polled uart working.
That one will only be called if you have an exception at a very early
stage. In that case you are working in an exception context.

> 
> When I rename the register_arm_pl011 to init_context_pl011 since it's is
> only initializing
> the pl011 context, rather than registering it.
> 
> On Tue, Dec 31, 2019 at 6:32 PM Christian Mauderer  > wrote:
> 
> On 31/12/2019 13:22, Niteesh wrote:
> > It works now, the functions are getting called when used with
> fileio.exe.
> > The function bsp_start wants to print information about the board,
> 
> That print maybe should be moved to a later point. It just fetches some
> information and prints it. It doesn't even do anything usefull
> besides that.
> 
> > but
> > the console
> > initialization function is called after bsp_start, assuming that
> the FDT
> > works it still
> > crash since the console still isn't initialized, one way of fixing
> this
> > would be to add uart_probe into
> > output_char just like in imx, or we could move the printing to
> somewhere
> > else.
> 
> That might would be a good idea regardless whether the print is moved or
> not. It would allow an early exception to print anything.
> 
> >
> > On Tue, Dec 31, 2019 at 4:08 PM Christian Mauderer
> mailto:l...@c-mauderer.de>
> > >> wrote:
> >
> >
> >
> >     On 31/12/2019 11:37, Christian Mauderer wrote:
> >     > On 31/12/2019 06:11, Niteesh wrote:
> >     >> On Tue, Dec 31, 2019 at 1:13 AM Christian Mauderer
> >     mailto:l...@c-mauderer.de>
> >
> >     >> 
>  >     >>
> >     >>     On 30/12/2019 19:32, Niteesh wrote:
> >     >>     > Just to make sure that console_initialize and uart_probe
> >     are being
> >     >>     > called, I manually initialized the pl011 context to print
> >     something on
> >     >>     > serial. But they never got called. Can you just make sure
> >     that if I am
> >     >>     > missing something?
> >     >>
> >     >>     I don't think that you are missing something but the
> >     executable is
> >     >>     missing something: The functions are not linked into it.
> >     >>
> >     >>     C linker can be an odd thing: It links only object
> files that are
> >     >>     referenced. You seem to have no reference to
> >     console-config.c/o from
> >     >>     anywhere else.
> >     >>
> >     >>     RTEMS_SYSINIT_ITEM(
> >     >>       uart_probe,
> >     >>       RTEMS_SYSINIT_BSP_START,
> >     >>       RTEMS_SYSINIT_ORDER_LAST
> >     >>     );
> >     >>
> >     >>     will be only added to the linker set if the file is
> linked in
> >     anyway.
> >     >>
> >     >>     That is a bit anoying. For the imx BSP there is a UART
> drain
> >     function
> >     >>     that is called from somewhere else. Thats enough to
> bring the
> >     file in.
> >     >>
> >     >>     I think you'll need to add a reference from somewhere
> or move
> >     that stuff
> >     >>     into another file that is referenced.
> >     >>
> >     >>     If you have some init function that has to be called in
> every
> >     case you
> >     >>     can call it from some other c file where it would fit too.
> >     >>
> >     >>     Otherwise it might is necessary to construct some odd
> stuff.
> >     I'm not
> >     >>     sure whether we already had a case like this. Most
> likely it
> >     would be
> >     >>     necessary to use a RTEMS_LINKER_ROSET_ITEM_REFERENCE
> for the
> >     >>     SYSINIT_ITEM. Maybe to define a new
> >     RTEMS_SYSINIT_ITEM_REFERENCE or
> >     >>     simmilar. This should be definitively a separate commit.
> >     Please ask
> >     >>     again if you have to go that way.
> >     >>
> >     >> I didn't understand the above part. So what I did was
> created a dummy
> >     >> function in console-config.c
> >     >> and referenced in places that I know we're going to be
> called. But
> >     >> still, it didn't work. 
> >     >>
> >     >
> >     > That's a really mean bug to find:
> >     >

Re: [PATCH v4] Raspberrypi: updated the console interface.

[Christian Mauderer]

On 31/12/2019 13:22, Niteesh wrote:
> It works now, the functions are getting called when used with fileio.exe.
> The function bsp_start wants to print information about the board,

That print maybe should be moved to a later point. It just fetches some
information and prints it. It doesn't even do anything usefull besides that.

> but
> the console
> initialization function is called after bsp_start, assuming that the FDT
> works it still
> crash since the console still isn't initialized, one way of fixing this
> would be to add uart_probe into
> output_char just like in imx, or we could move the printing to somewhere
> else.

That might would be a good idea regardless whether the print is moved or
not. It would allow an early exception to print anything.

> 
> On Tue, Dec 31, 2019 at 4:08 PM Christian Mauderer  > wrote:
> 
> 
> 
> On 31/12/2019 11:37, Christian Mauderer wrote:
> > On 31/12/2019 06:11, Niteesh wrote:
> >> On Tue, Dec 31, 2019 at 1:13 AM Christian Mauderer
> mailto:l...@c-mauderer.de>
> >> >> wrote:
> >>
> >>     On 30/12/2019 19:32, Niteesh wrote:
> >>     > Just to make sure that console_initialize and uart_probe
> are being
> >>     > called, I manually initialized the pl011 context to print
> something on
> >>     > serial. But they never got called. Can you just make sure
> that if I am
> >>     > missing something?
> >>
> >>     I don't think that you are missing something but the
> executable is
> >>     missing something: The functions are not linked into it.
> >>
> >>     C linker can be an odd thing: It links only object files that are
> >>     referenced. You seem to have no reference to
> console-config.c/o from
> >>     anywhere else.
> >>
> >>     RTEMS_SYSINIT_ITEM(
> >>       uart_probe,
> >>       RTEMS_SYSINIT_BSP_START,
> >>       RTEMS_SYSINIT_ORDER_LAST
> >>     );
> >>
> >>     will be only added to the linker set if the file is linked in
> anyway.
> >>
> >>     That is a bit anoying. For the imx BSP there is a UART drain
> function
> >>     that is called from somewhere else. Thats enough to bring the
> file in.
> >>
> >>     I think you'll need to add a reference from somewhere or move
> that stuff
> >>     into another file that is referenced.
> >>
> >>     If you have some init function that has to be called in every
> case you
> >>     can call it from some other c file where it would fit too.
> >>
> >>     Otherwise it might is necessary to construct some odd stuff.
> I'm not
> >>     sure whether we already had a case like this. Most likely it
> would be
> >>     necessary to use a RTEMS_LINKER_ROSET_ITEM_REFERENCE for the
> >>     SYSINIT_ITEM. Maybe to define a new
> RTEMS_SYSINIT_ITEM_REFERENCE or
> >>     simmilar. This should be definitively a separate commit.
> Please ask
> >>     again if you have to go that way.
> >>
> >> I didn't understand the above part. So what I did was created a dummy
> >> function in console-config.c
> >> and referenced in places that I know we're going to be called. But
> >> still, it didn't work. 
> >>
> >
> > That's a really mean bug to find:
> >
> > 1. My assumption was wrong. The file is linked in. Most likely due to
> > BSP_output_char which is defined in this file.
> >
> > 2. Please remove console-termios-init.c. It would define the same
> > console_initialize() function.
> 
> Just to be clear: Remove it from the
> c/src/lib/libbsp/arm/raspberrypi/Makefile.am file.
> 
> >
> > 3. The real proble just caused a warning which was a bit hard to spot:
> > The compile doesn't know RTEMS_SYSINIT_ITEM. It thinks it's a function
> > body and warns that it defaults the return type to int. In other
> words:
> > You missed to include . If you add that the
> > RTEMS_SYSINIT_ITEM works and uart_probe is linked in.
> >
> > 4. console_initialize is still not used. It is really hard to spot
> why:
> > Most of the tests only use the configuration:
> >
> >     CONFIGURE_APPLICATION_NEEDS_SIMPLE_CONSOLE_DRIVER
> >
> > This is a simplified polled console driver. From the samples only
> > capture, fileio and pppd are using the normal console with:
> >
> >     CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
> >
> > So only for these three the console_initialize will be called.
> >
> > By the way: You can use objdump to analyze your elf-files. For example
> > to get a symbol table use:
> >
> >     arm-rtems5-objdump -t path/to/ticker.exe
> >
> > To get the disassembled code with intermixed c-sources use
> >
> >     arm-rtems5-objdump -dS path/to/ticker.exe
> >
> > 

Re: [PATCH v4] Raspberrypi: updated the console interface.

[Niteesh]

It works now, the functions are getting called when used with fileio.exe.
The function bsp_start wants to print information about the board, but the
console
initialization function is called after bsp_start, assuming that the FDT
works it still
crash since the console still isn't initialized, one way of fixing this
would be to add uart_probe into
output_char just like in imx, or we could move the printing to somewhere
else.

On Tue, Dec 31, 2019 at 4:08 PM Christian Mauderer 
wrote:

>
>
> On 31/12/2019 11:37, Christian Mauderer wrote:
> > On 31/12/2019 06:11, Niteesh wrote:
> >> On Tue, Dec 31, 2019 at 1:13 AM Christian Mauderer  >> > wrote:
> >>
> >> On 30/12/2019 19:32, Niteesh wrote:
> >> > Just to make sure that console_initialize and uart_probe are being
> >> > called, I manually initialized the pl011 context to print
> something on
> >> > serial. But they never got called. Can you just make sure that if
> I am
> >> > missing something?
> >>
> >> I don't think that you are missing something but the executable is
> >> missing something: The functions are not linked into it.
> >>
> >> C linker can be an odd thing: It links only object files that are
> >> referenced. You seem to have no reference to console-config.c/o from
> >> anywhere else.
> >>
> >> RTEMS_SYSINIT_ITEM(
> >>   uart_probe,
> >>   RTEMS_SYSINIT_BSP_START,
> >>   RTEMS_SYSINIT_ORDER_LAST
> >> );
> >>
> >> will be only added to the linker set if the file is linked in
> anyway.
> >>
> >> That is a bit anoying. For the imx BSP there is a UART drain
> function
> >> that is called from somewhere else. Thats enough to bring the file
> in.
> >>
> >> I think you'll need to add a reference from somewhere or move that
> stuff
> >> into another file that is referenced.
> >>
> >> If you have some init function that has to be called in every case
> you
> >> can call it from some other c file where it would fit too.
> >>
> >> Otherwise it might is necessary to construct some odd stuff. I'm not
> >> sure whether we already had a case like this. Most likely it would
> be
> >> necessary to use a RTEMS_LINKER_ROSET_ITEM_REFERENCE for the
> >> SYSINIT_ITEM. Maybe to define a new RTEMS_SYSINIT_ITEM_REFERENCE or
> >> simmilar. This should be definitively a separate commit. Please ask
> >> again if you have to go that way.
> >>
> >> I didn't understand the above part. So what I did was created a dummy
> >> function in console-config.c
> >> and referenced in places that I know we're going to be called. But
> >> still, it didn't work.
> >>
> >
> > That's a really mean bug to find:
> >
> > 1. My assumption was wrong. The file is linked in. Most likely due to
> > BSP_output_char which is defined in this file.
> >
> > 2. Please remove console-termios-init.c. It would define the same
> > console_initialize() function.
>
> Just to be clear: Remove it from the
> c/src/lib/libbsp/arm/raspberrypi/Makefile.am file.
>
> >
> > 3. The real proble just caused a warning which was a bit hard to spot:
> > The compile doesn't know RTEMS_SYSINIT_ITEM. It thinks it's a function
> > body and warns that it defaults the return type to int. In other words:
> > You missed to include . If you add that the
> > RTEMS_SYSINIT_ITEM works and uart_probe is linked in.
> >
> > 4. console_initialize is still not used. It is really hard to spot why:
> > Most of the tests only use the configuration:
> >
> > CONFIGURE_APPLICATION_NEEDS_SIMPLE_CONSOLE_DRIVER
> >
> > This is a simplified polled console driver. From the samples only
> > capture, fileio and pppd are using the normal console with:
> >
> > CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
> >
> > So only for these three the console_initialize will be called.
> >
> > By the way: You can use objdump to analyze your elf-files. For example
> > to get a symbol table use:
> >
> > arm-rtems5-objdump -t path/to/ticker.exe
> >
> > To get the disassembled code with intermixed c-sources use
> >
> > arm-rtems5-objdump -dS path/to/ticker.exe
> >
> > That's very usefull to find whether a symbol is linked in or not.
> >
> >>
> >>
> >> >
> >> > While going through the messages from devel-request, Joel
> mentioned
> >> > about qemu4 rsb package
> >> > how is it different from the official qemu?
> >> >
> >> > On Mon, Dec 30, 2019 at 11:53 PM G S Niteesh  >> 
> >> > >> wrote:
> >> >
> >> > The patch updates the older console interface used by the BSP,
> >> > to newer one. It also replaces the custom usart(PL011) driver
> >> > with arm-pl011. The fb function's signatures where also
> changed
> >> > to accommodate with interface update.
> >> > Update #3034
> >> > ---
> >> >  bsps/arm/raspberrypi/console/console-config.c | 186
> >> 

Re: [PATCH v4] Raspberrypi: updated the console interface.

[Christian Mauderer]

On 31/12/2019 11:37, Christian Mauderer wrote:
> On 31/12/2019 06:11, Niteesh wrote:
>> On Tue, Dec 31, 2019 at 1:13 AM Christian Mauderer > > wrote:
>>
>> On 30/12/2019 19:32, Niteesh wrote:
>> > Just to make sure that console_initialize and uart_probe are being
>> > called, I manually initialized the pl011 context to print something on
>> > serial. But they never got called. Can you just make sure that if I am
>> > missing something?
>>
>> I don't think that you are missing something but the executable is
>> missing something: The functions are not linked into it.
>>
>> C linker can be an odd thing: It links only object files that are
>> referenced. You seem to have no reference to console-config.c/o from
>> anywhere else.
>>
>> RTEMS_SYSINIT_ITEM(
>>   uart_probe,
>>   RTEMS_SYSINIT_BSP_START,
>>   RTEMS_SYSINIT_ORDER_LAST
>> );
>>
>> will be only added to the linker set if the file is linked in anyway.
>>
>> That is a bit anoying. For the imx BSP there is a UART drain function
>> that is called from somewhere else. Thats enough to bring the file in.
>>
>> I think you'll need to add a reference from somewhere or move that stuff
>> into another file that is referenced.
>>
>> If you have some init function that has to be called in every case you
>> can call it from some other c file where it would fit too.
>>
>> Otherwise it might is necessary to construct some odd stuff. I'm not
>> sure whether we already had a case like this. Most likely it would be
>> necessary to use a RTEMS_LINKER_ROSET_ITEM_REFERENCE for the
>> SYSINIT_ITEM. Maybe to define a new RTEMS_SYSINIT_ITEM_REFERENCE or
>> simmilar. This should be definitively a separate commit. Please ask
>> again if you have to go that way.
>>
>> I didn't understand the above part. So what I did was created a dummy
>> function in console-config.c
>> and referenced in places that I know we're going to be called. But
>> still, it didn't work. 
>>
> 
> That's a really mean bug to find:
> 
> 1. My assumption was wrong. The file is linked in. Most likely due to
> BSP_output_char which is defined in this file.
> 
> 2. Please remove console-termios-init.c. It would define the same
> console_initialize() function.

Just to be clear: Remove it from the
c/src/lib/libbsp/arm/raspberrypi/Makefile.am file.

> 
> 3. The real proble just caused a warning which was a bit hard to spot:
> The compile doesn't know RTEMS_SYSINIT_ITEM. It thinks it's a function
> body and warns that it defaults the return type to int. In other words:
> You missed to include . If you add that the
> RTEMS_SYSINIT_ITEM works and uart_probe is linked in.
> 
> 4. console_initialize is still not used. It is really hard to spot why:
> Most of the tests only use the configuration:
> 
> CONFIGURE_APPLICATION_NEEDS_SIMPLE_CONSOLE_DRIVER
> 
> This is a simplified polled console driver. From the samples only
> capture, fileio and pppd are using the normal console with:
> 
> CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
> 
> So only for these three the console_initialize will be called.
> 
> By the way: You can use objdump to analyze your elf-files. For example
> to get a symbol table use:
> 
> arm-rtems5-objdump -t path/to/ticker.exe
> 
> To get the disassembled code with intermixed c-sources use
> 
> arm-rtems5-objdump -dS path/to/ticker.exe
> 
> That's very usefull to find whether a symbol is linked in or not.
> 
>>  
>>
>> >
>> > While going through the messages from devel-request, Joel mentioned
>> > about qemu4 rsb package
>> > how is it different from the official qemu?
>> >
>> > On Mon, Dec 30, 2019 at 11:53 PM G S Niteesh > 
>> > >> wrote:
>> >
>> >     The patch updates the older console interface used by the BSP,
>> >     to newer one. It also replaces the custom usart(PL011) driver
>> >     with arm-pl011. The fb function's signatures where also changed
>> >     to accommodate with interface update.
>> >     Update #3034
>> >     ---
>> >      bsps/arm/raspberrypi/console/console-config.c | 186
>> ++
>> >      bsps/arm/raspberrypi/console/console_select.c | 114 ---
>> >      bsps/arm/raspberrypi/console/fbcons.c         |  78 
>> >      bsps/arm/raspberrypi/console/usart.c          | 167
>> 
>> >      bsps/arm/raspberrypi/include/bsp/fbcons.h     |  21 +-
>> >      .../arm/raspberrypi/include/bsp/raspberrypi.h |  48 ++---
>> >      bsps/arm/raspberrypi/include/bsp/usart.h      |   5 +-
>> >      c/src/lib/libbsp/arm/raspberrypi/Makefile.am  |   8 +-
>> >      8 files changed, 220 insertions(+), 407 deletions(-)
>> >      delete mode 100644 bsps/arm/raspberrypi/console/console_select.c
>> >      delete 

Re: [PATCH v4] Raspberrypi: updated the console interface.

[Christian Mauderer]

On 31/12/2019 06:11, Niteesh wrote:
> On Tue, Dec 31, 2019 at 1:13 AM Christian Mauderer  > wrote:
> 
> On 30/12/2019 19:32, Niteesh wrote:
> > Just to make sure that console_initialize and uart_probe are being
> > called, I manually initialized the pl011 context to print something on
> > serial. But they never got called. Can you just make sure that if I am
> > missing something?
> 
> I don't think that you are missing something but the executable is
> missing something: The functions are not linked into it.
> 
> C linker can be an odd thing: It links only object files that are
> referenced. You seem to have no reference to console-config.c/o from
> anywhere else.
> 
> RTEMS_SYSINIT_ITEM(
>   uart_probe,
>   RTEMS_SYSINIT_BSP_START,
>   RTEMS_SYSINIT_ORDER_LAST
> );
> 
> will be only added to the linker set if the file is linked in anyway.
> 
> That is a bit anoying. For the imx BSP there is a UART drain function
> that is called from somewhere else. Thats enough to bring the file in.
> 
> I think you'll need to add a reference from somewhere or move that stuff
> into another file that is referenced.
> 
> If you have some init function that has to be called in every case you
> can call it from some other c file where it would fit too.
> 
> Otherwise it might is necessary to construct some odd stuff. I'm not
> sure whether we already had a case like this. Most likely it would be
> necessary to use a RTEMS_LINKER_ROSET_ITEM_REFERENCE for the
> SYSINIT_ITEM. Maybe to define a new RTEMS_SYSINIT_ITEM_REFERENCE or
> simmilar. This should be definitively a separate commit. Please ask
> again if you have to go that way.
> 
> I didn't understand the above part. So what I did was created a dummy
> function in console-config.c
> and referenced in places that I know we're going to be called. But
> still, it didn't work. 
> 

That's a really mean bug to find:

1. My assumption was wrong. The file is linked in. Most likely due to
BSP_output_char which is defined in this file.

2. Please remove console-termios-init.c. It would define the same
console_initialize() function.

3. The real proble just caused a warning which was a bit hard to spot:
The compile doesn't know RTEMS_SYSINIT_ITEM. It thinks it's a function
body and warns that it defaults the return type to int. In other words:
You missed to include . If you add that the
RTEMS_SYSINIT_ITEM works and uart_probe is linked in.

4. console_initialize is still not used. It is really hard to spot why:
Most of the tests only use the configuration:

CONFIGURE_APPLICATION_NEEDS_SIMPLE_CONSOLE_DRIVER

This is a simplified polled console driver. From the samples only
capture, fileio and pppd are using the normal console with:

CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER

So only for these three the console_initialize will be called.

By the way: You can use objdump to analyze your elf-files. For example
to get a symbol table use:

arm-rtems5-objdump -t path/to/ticker.exe

To get the disassembled code with intermixed c-sources use

arm-rtems5-objdump -dS path/to/ticker.exe

That's very usefull to find whether a symbol is linked in or not.

>  
> 
> >
> > While going through the messages from devel-request, Joel mentioned
> > about qemu4 rsb package
> > how is it different from the official qemu?
> >
> > On Mon, Dec 30, 2019 at 11:53 PM G S Niteesh  
> > >> wrote:
> >
> >     The patch updates the older console interface used by the BSP,
> >     to newer one. It also replaces the custom usart(PL011) driver
> >     with arm-pl011. The fb function's signatures where also changed
> >     to accommodate with interface update.
> >     Update #3034
> >     ---
> >      bsps/arm/raspberrypi/console/console-config.c | 186
> ++
> >      bsps/arm/raspberrypi/console/console_select.c | 114 ---
> >      bsps/arm/raspberrypi/console/fbcons.c         |  78 
> >      bsps/arm/raspberrypi/console/usart.c          | 167
> 
> >      bsps/arm/raspberrypi/include/bsp/fbcons.h     |  21 +-
> >      .../arm/raspberrypi/include/bsp/raspberrypi.h |  48 ++---
> >      bsps/arm/raspberrypi/include/bsp/usart.h      |   5 +-
> >      c/src/lib/libbsp/arm/raspberrypi/Makefile.am  |   8 +-
> >      8 files changed, 220 insertions(+), 407 deletions(-)
> >      delete mode 100644 bsps/arm/raspberrypi/console/console_select.c
> >      delete mode 100644 bsps/arm/raspberrypi/console/usart.c
> >
> >     diff --git a/bsps/arm/raspberrypi/console/console-config.c
> >     b/bsps/arm/raspberrypi/console/console-config.c
> >     index d2186c918b..021428ff4b 100644
> >     --- 

Re: [PATCH v4] Raspberrypi: updated the console interface.

[Niteesh]

On Tue, Dec 31, 2019 at 1:13 AM Christian Mauderer 
wrote:

> On 30/12/2019 19:32, Niteesh wrote:
> > Just to make sure that console_initialize and uart_probe are being
> > called, I manually initialized the pl011 context to print something on
> > serial. But they never got called. Can you just make sure that if I am
> > missing something?
>
> I don't think that you are missing something but the executable is
> missing something: The functions are not linked into it.
>
> C linker can be an odd thing: It links only object files that are
> referenced. You seem to have no reference to console-config.c/o from
> anywhere else.
>
> RTEMS_SYSINIT_ITEM(
>   uart_probe,
>   RTEMS_SYSINIT_BSP_START,
>   RTEMS_SYSINIT_ORDER_LAST
> );
>
> will be only added to the linker set if the file is linked in anyway.
>
> That is a bit anoying. For the imx BSP there is a UART drain function
> that is called from somewhere else. Thats enough to bring the file in.
>
> I think you'll need to add a reference from somewhere or move that stuff
> into another file that is referenced.
>
> If you have some init function that has to be called in every case you
> can call it from some other c file where it would fit too.
>
> Otherwise it might is necessary to construct some odd stuff. I'm not
> sure whether we already had a case like this. Most likely it would be
> necessary to use a RTEMS_LINKER_ROSET_ITEM_REFERENCE for the
> SYSINIT_ITEM. Maybe to define a new RTEMS_SYSINIT_ITEM_REFERENCE or
> simmilar. This should be definitively a separate commit. Please ask
> again if you have to go that way.

I didn't understand the above part. So what I did was created a dummy
function in console-config.c
and referenced in places that I know we're going to be called. But still,
it didn't work.

>
>
>
> > While going through the messages from devel-request, Joel mentioned
> > about qemu4 rsb package
> > how is it different from the official qemu?
> >
> > On Mon, Dec 30, 2019 at 11:53 PM G S Niteesh  > > wrote:
> >
> > The patch updates the older console interface used by the BSP,
> > to newer one. It also replaces the custom usart(PL011) driver
> > with arm-pl011. The fb function's signatures where also changed
> > to accommodate with interface update.
> > Update #3034
> > ---
> >  bsps/arm/raspberrypi/console/console-config.c | 186
> ++
> >  bsps/arm/raspberrypi/console/console_select.c | 114 ---
> >  bsps/arm/raspberrypi/console/fbcons.c |  78 
> >  bsps/arm/raspberrypi/console/usart.c  | 167 
> >  bsps/arm/raspberrypi/include/bsp/fbcons.h |  21 +-
> >  .../arm/raspberrypi/include/bsp/raspberrypi.h |  48 ++---
> >  bsps/arm/raspberrypi/include/bsp/usart.h  |   5 +-
> >  c/src/lib/libbsp/arm/raspberrypi/Makefile.am  |   8 +-
> >  8 files changed, 220 insertions(+), 407 deletions(-)
> >  delete mode 100644 bsps/arm/raspberrypi/console/console_select.c
> >  delete mode 100644 bsps/arm/raspberrypi/console/usart.c
> >
> > diff --git a/bsps/arm/raspberrypi/console/console-config.c
> > b/bsps/arm/raspberrypi/console/console-config.c
> > index d2186c918b..021428ff4b 100644
> > --- a/bsps/arm/raspberrypi/console/console-config.c
> > +++ b/bsps/arm/raspberrypi/console/console-config.c
> > @@ -19,50 +19,164 @@
> >   */
> >
> >  #include 
> > +#include 
> >
> > -#include 
> >
> > -#include 
> > -#include 
> > -#include 
> > +#include 
> >  #include 
> > +#include 
> > +#include 
> >  #include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +
> > +#include 
> > +#include 
> > +
> > +arm_pl011_context pl011_context;
> > +rpi_fb_context fb_context;
>
> These could be static.
>
> > +
> > +static void output_char_serial(char c)
> > +{
> > +  arm_pl011_write_polled(_context.base, c);
> > +}
> > +
> > +void output_char_fb(char c)
> > +{
> > +  fbcons_write_polled(_context.base, c);
> > +}
> >
> > -console_tbl Console_Configuration_Ports [] = {
> > -{
> > -  .sDeviceName = "/dev/ttyS0",
> > -  .deviceType = SERIAL_CUSTOM,
> > -  .pDeviceFns = _usart_fns,
> > -  .deviceProbe = NULL,
> > -  .pDeviceFlow = NULL,
> > -  .ulCtrlPort1 = BCM2835_UART0_BASE,
> > -  .ulCtrlPort2 = 0,
> > -  .ulClock = USART0_DEFAULT_BAUD,
> > -  .ulIntVector = BCM2835_IRQ_ID_UART
> > -},
> > -{
> > -  .sDeviceName ="/dev/fbcons",
> > -  .deviceType = SERIAL_CUSTOM,
> > -  .pDeviceFns = _fns,
> > -  .deviceProbe = fbcons_probe,
> > -  .pDeviceFlow = NULL,
> > -},
> > -};
> > -
> > -#define PORT_COUNT \
> > -  (sizeof(Console_Configuration_Ports) \
> > -/ 

Re: [PATCH v4] Raspberrypi: updated the console interface.

[Christian Mauderer]

On 30/12/2019 20:43, Christian Mauderer wrote:
> On 30/12/2019 19:32, Niteesh wrote:
>> Just to make sure that console_initialize and uart_probe are being
>> called, I manually initialized the pl011 context to print something on
>> serial. But they never got called. Can you just make sure that if I am
>> missing something?
> 
> I don't think that you are missing something but the executable is
> missing something: The functions are not linked into it.
> 
> C linker can be an odd thing: It links only object files that are
> referenced. You seem to have no reference to console-config.c/o from
> anywhere else.
> 
> RTEMS_SYSINIT_ITEM(
>   uart_probe,
>   RTEMS_SYSINIT_BSP_START,
>   RTEMS_SYSINIT_ORDER_LAST
> );
> 
> will be only added to the linker set if the file is linked in anyway.
> 
> That is a bit anoying. For the imx BSP there is a UART drain function
> that is called from somewhere else. Thats enough to bring the file in.
> 
> I think you'll need to add a reference from somewhere or move that stuff
> into another file that is referenced.
> 
> If you have some init function that has to be called in every case you
> can call it from some other c file where it would fit too.
> 
> Otherwise it might is necessary to construct some odd stuff. I'm not
> sure whether we already had a case like this. Most likely it would be
> necessary to use a RTEMS_LINKER_ROSET_ITEM_REFERENCE for the
> SYSINIT_ITEM. Maybe to define a new RTEMS_SYSINIT_ITEM_REFERENCE or
> simmilar. This should be definitively a separate commit. Please ask
> again if you have to go that way.
> 
>>
>> While going through the messages from devel-request, Joel mentioned
>> about qemu4 rsb package
>> how is it different from the official qemu?

Sorry: I forgot to answer that question.

I haven't had a detailled look but I assume the following: Qemu is a
very, very active project. A version provided by a distribution is most
likely quite out of date except if you use a distribution that is
_really_ fast with packet updates. I assume that the qemu from RSB is
quite a bit newer.

>>
>> On Mon, Dec 30, 2019 at 11:53 PM G S Niteesh > > wrote:
>>
>> The patch updates the older console interface used by the BSP,
>> to newer one. It also replaces the custom usart(PL011) driver
>> with arm-pl011. The fb function's signatures where also changed
>> to accommodate with interface update.
>> Update #3034
>> ---
>>  bsps/arm/raspberrypi/console/console-config.c | 186 ++
>>  bsps/arm/raspberrypi/console/console_select.c | 114 ---
>>  bsps/arm/raspberrypi/console/fbcons.c         |  78 
>>  bsps/arm/raspberrypi/console/usart.c          | 167 
>>  bsps/arm/raspberrypi/include/bsp/fbcons.h     |  21 +-
>>  .../arm/raspberrypi/include/bsp/raspberrypi.h |  48 ++---
>>  bsps/arm/raspberrypi/include/bsp/usart.h      |   5 +-
>>  c/src/lib/libbsp/arm/raspberrypi/Makefile.am  |   8 +-
>>  8 files changed, 220 insertions(+), 407 deletions(-)
>>  delete mode 100644 bsps/arm/raspberrypi/console/console_select.c
>>  delete mode 100644 bsps/arm/raspberrypi/console/usart.c
>>
>> diff --git a/bsps/arm/raspberrypi/console/console-config.c
>> b/bsps/arm/raspberrypi/console/console-config.c
>> index d2186c918b..021428ff4b 100644
>> --- a/bsps/arm/raspberrypi/console/console-config.c
>> +++ b/bsps/arm/raspberrypi/console/console-config.c
>> @@ -19,50 +19,164 @@
>>   */
>>
>>  #include 
>> +#include 
>>
>> -#include 
>>
>> -#include 
>> -#include 
>> -#include 
>> +#include 
>>  #include 
>> +#include 
>> +#include 
>>  #include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +
>> +#include 
>> +#include 
>> +
>> +arm_pl011_context pl011_context;
>> +rpi_fb_context fb_context;
> 
> These could be static.
> 
>> +
>> +static void output_char_serial(char c)
>> +{
>> +  arm_pl011_write_polled(_context.base, c);
>> +}
>> +
>> +void output_char_fb(char c)
>> +{
>> +  fbcons_write_polled(_context.base, c);
>> +}
>>
>> -console_tbl Console_Configuration_Ports [] = {
>> -    {
>> -      .sDeviceName = "/dev/ttyS0",
>> -      .deviceType = SERIAL_CUSTOM,
>> -      .pDeviceFns = _usart_fns,
>> -      .deviceProbe = NULL,
>> -      .pDeviceFlow = NULL,
>> -      .ulCtrlPort1 = BCM2835_UART0_BASE,
>> -      .ulCtrlPort2 = 0,
>> -      .ulClock = USART0_DEFAULT_BAUD,
>> -      .ulIntVector = BCM2835_IRQ_ID_UART
>> -    },
>> -    {
>> -      .sDeviceName ="/dev/fbcons",
>> -      .deviceType = SERIAL_CUSTOM,
>> -      .pDeviceFns = _fns,
>> -      .deviceProbe = fbcons_probe,
>> -      .pDeviceFlow = NULL,
>> -    },
>> -};
>> -
>> -#define PORT_COUNT \
>> -  

Re: [PATCH v4] Raspberrypi: updated the console interface.

[Niteesh]

Any other suggestions with the code or are happy with it?

On Tue, Dec 31, 2019 at 1:13 AM Christian Mauderer 
wrote:

> On 30/12/2019 19:32, Niteesh wrote:
> > Just to make sure that console_initialize and uart_probe are being
> > called, I manually initialized the pl011 context to print something on
> > serial. But they never got called. Can you just make sure that if I am
> > missing something?
>
> I don't think that you are missing something but the executable is
> missing something: The functions are not linked into it.
>
> C linker can be an odd thing: It links only object files that are
> referenced. You seem to have no reference to console-config.c/o from
> anywhere else.
>
> RTEMS_SYSINIT_ITEM(
>   uart_probe,
>   RTEMS_SYSINIT_BSP_START,
>   RTEMS_SYSINIT_ORDER_LAST
> );
>
> will be only added to the linker set if the file is linked in anyway.
>
> That is a bit anoying. For the imx BSP there is a UART drain function
> that is called from somewhere else. Thats enough to bring the file in.
>
> I think you'll need to add a reference from somewhere or move that stuff
> into another file that is referenced.
>
> If you have some init function that has to be called in every case you
> can call it from some other c file where it would fit too.
>
> Otherwise it might is necessary to construct some odd stuff. I'm not
> sure whether we already had a case like this. Most likely it would be
> necessary to use a RTEMS_LINKER_ROSET_ITEM_REFERENCE for the
> SYSINIT_ITEM. Maybe to define a new RTEMS_SYSINIT_ITEM_REFERENCE or
> simmilar. This should be definitively a separate commit. Please ask
> again if you have to go that way.
>
> >
> > While going through the messages from devel-request, Joel mentioned
> > about qemu4 rsb package
> > how is it different from the official qemu?
> >
> > On Mon, Dec 30, 2019 at 11:53 PM G S Niteesh  > > wrote:
> >
> > The patch updates the older console interface used by the BSP,
> > to newer one. It also replaces the custom usart(PL011) driver
> > with arm-pl011. The fb function's signatures where also changed
> > to accommodate with interface update.
> > Update #3034
> > ---
> >  bsps/arm/raspberrypi/console/console-config.c | 186
> ++
> >  bsps/arm/raspberrypi/console/console_select.c | 114 ---
> >  bsps/arm/raspberrypi/console/fbcons.c |  78 
> >  bsps/arm/raspberrypi/console/usart.c  | 167 
> >  bsps/arm/raspberrypi/include/bsp/fbcons.h |  21 +-
> >  .../arm/raspberrypi/include/bsp/raspberrypi.h |  48 ++---
> >  bsps/arm/raspberrypi/include/bsp/usart.h  |   5 +-
> >  c/src/lib/libbsp/arm/raspberrypi/Makefile.am  |   8 +-
> >  8 files changed, 220 insertions(+), 407 deletions(-)
> >  delete mode 100644 bsps/arm/raspberrypi/console/console_select.c
> >  delete mode 100644 bsps/arm/raspberrypi/console/usart.c
> >
> > diff --git a/bsps/arm/raspberrypi/console/console-config.c
> > b/bsps/arm/raspberrypi/console/console-config.c
> > index d2186c918b..021428ff4b 100644
> > --- a/bsps/arm/raspberrypi/console/console-config.c
> > +++ b/bsps/arm/raspberrypi/console/console-config.c
> > @@ -19,50 +19,164 @@
> >   */
> >
> >  #include 
> > +#include 
> >
> > -#include 
> >
> > -#include 
> > -#include 
> > -#include 
> > +#include 
> >  #include 
> > +#include 
> > +#include 
> >  #include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +
> > +#include 
> > +#include 
> > +
> > +arm_pl011_context pl011_context;
> > +rpi_fb_context fb_context;
>
> These could be static.
>
> > +
> > +static void output_char_serial(char c)
> > +{
> > +  arm_pl011_write_polled(_context.base, c);
> > +}
> > +
> > +void output_char_fb(char c)
> > +{
> > +  fbcons_write_polled(_context.base, c);
> > +}
> >
> > -console_tbl Console_Configuration_Ports [] = {
> > -{
> > -  .sDeviceName = "/dev/ttyS0",
> > -  .deviceType = SERIAL_CUSTOM,
> > -  .pDeviceFns = _usart_fns,
> > -  .deviceProbe = NULL,
> > -  .pDeviceFlow = NULL,
> > -  .ulCtrlPort1 = BCM2835_UART0_BASE,
> > -  .ulCtrlPort2 = 0,
> > -  .ulClock = USART0_DEFAULT_BAUD,
> > -  .ulIntVector = BCM2835_IRQ_ID_UART
> > -},
> > -{
> > -  .sDeviceName ="/dev/fbcons",
> > -  .deviceType = SERIAL_CUSTOM,
> > -  .pDeviceFns = _fns,
> > -  .deviceProbe = fbcons_probe,
> > -  .pDeviceFlow = NULL,
> > -},
> > -};
> > -
> > -#define PORT_COUNT \
> > -  (sizeof(Console_Configuration_Ports) \
> > -/ sizeof(Console_Configuration_Ports [0]))
> > -
> > -unsigned long Console_Configuration_Count = PORT_COUNT;
> > -
> > -static void output_char(char 

Re: [PATCH v4] Raspberrypi: updated the console interface.

[Niteesh]

Just to make sure that console_initialize and uart_probe are being
called, I manually initialized the pl011 context to print something on
serial. But they never got called. Can you just make sure that if I am
missing something?

While going through the messages from devel-request, Joel mentioned about
qemu4 rsb package
how is it different from the official qemu?

On Mon, Dec 30, 2019 at 11:53 PM G S Niteesh  wrote:

> The patch updates the older console interface used by the BSP,
> to newer one. It also replaces the custom usart(PL011) driver
> with arm-pl011. The fb function's signatures where also changed
> to accommodate with interface update.
> Update #3034
> ---
>  bsps/arm/raspberrypi/console/console-config.c | 186 ++
>  bsps/arm/raspberrypi/console/console_select.c | 114 ---
>  bsps/arm/raspberrypi/console/fbcons.c |  78 
>  bsps/arm/raspberrypi/console/usart.c  | 167 
>  bsps/arm/raspberrypi/include/bsp/fbcons.h |  21 +-
>  .../arm/raspberrypi/include/bsp/raspberrypi.h |  48 ++---
>  bsps/arm/raspberrypi/include/bsp/usart.h  |   5 +-
>  c/src/lib/libbsp/arm/raspberrypi/Makefile.am  |   8 +-
>  8 files changed, 220 insertions(+), 407 deletions(-)
>  delete mode 100644 bsps/arm/raspberrypi/console/console_select.c
>  delete mode 100644 bsps/arm/raspberrypi/console/usart.c
>
> diff --git a/bsps/arm/raspberrypi/console/console-config.c
> b/bsps/arm/raspberrypi/console/console-config.c
> index d2186c918b..021428ff4b 100644
> --- a/bsps/arm/raspberrypi/console/console-config.c
> +++ b/bsps/arm/raspberrypi/console/console-config.c
> @@ -19,50 +19,164 @@
>   */
>
>  #include 
> +#include 
>
> -#include 
>
> -#include 
> -#include 
> -#include 
> +#include 
>  #include 
> +#include 
> +#include 
>  #include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include 
> +#include 
> +
> +arm_pl011_context pl011_context;
> +rpi_fb_context fb_context;
> +
> +static void output_char_serial(char c)
> +{
> +  arm_pl011_write_polled(_context.base, c);
> +}
> +
> +void output_char_fb(char c)
> +{
> +  fbcons_write_polled(_context.base, c);
> +}
>
> -console_tbl Console_Configuration_Ports [] = {
> -{
> -  .sDeviceName = "/dev/ttyS0",
> -  .deviceType = SERIAL_CUSTOM,
> -  .pDeviceFns = _usart_fns,
> -  .deviceProbe = NULL,
> -  .pDeviceFlow = NULL,
> -  .ulCtrlPort1 = BCM2835_UART0_BASE,
> -  .ulCtrlPort2 = 0,
> -  .ulClock = USART0_DEFAULT_BAUD,
> -  .ulIntVector = BCM2835_IRQ_ID_UART
> -},
> -{
> -  .sDeviceName ="/dev/fbcons",
> -  .deviceType = SERIAL_CUSTOM,
> -  .pDeviceFns = _fns,
> -  .deviceProbe = fbcons_probe,
> -  .pDeviceFlow = NULL,
> -},
> -};
> -
> -#define PORT_COUNT \
> -  (sizeof(Console_Configuration_Ports) \
> -/ sizeof(Console_Configuration_Ports [0]))
> -
> -unsigned long Console_Configuration_Count = PORT_COUNT;
> -
> -static void output_char(char c)
> +
> +static void *get_reg_of_node(const void *fdt, int node)
>  {
> -  const console_fns *con =
> -Console_Configuration_Ports [Console_Port_Minor].pDeviceFns;
> +  int len;
> +  const uint32_t *val;
> +
> +  val = fdt_getprop(fdt, node, "reg", );
> +  if (val == NULL || len < 4) {
> +return NULL;
> +  }
>
> -  con->deviceWritePolled((int) Console_Port_Minor, c);
> +  return (void *) fdt32_to_cpu(val[0]);
>  }
>
> -BSP_output_char_function_type BSP_output_char = output_char;
> +static void register_arm_pl011(
> +  const void *fdt,
> +  const char *serial
> +)
> +{
> +  arm_pl011_context *ctx = _context;
> +  int node;
> +
> +  if (strcmp(serial, "uart0") == 0) {
> +
> +rtems_termios_device_context_initialize(>base, "UART");
> +node = fdt_path_offset(fdt, serial);
> +ctx->regs = get_reg_of_node(fdt, node);
> +  }
> +
> +  rtems_termios_device_install(
> +"/dev/ttyuart0",
> +_pl011_fns,
> +NULL,
> +_context.base
> +  );
> +}
> +
> +static void register_fb( void )
> +{
> +  if (fbcons_probe(_context.base) == true) {
> +rtems_termios_device_install(
> +  "/dev/fbcons",
> +  _fns,
> +  NULL,
> +  _context.base);
> +  }
> +}
> +
> +static void console_select( const char *console )
> +{
> +  const char *opt;
> +
> +  opt = rpi_cmdline_get_arg("--console=");
> +
> +  if ( opt ) {
> +if ( strncmp( opt, "fbcons", sizeof( "fbcons" ) - 1 ) == 0 ) {
> +  if ( rpi_video_is_initialized() > 0 ) {
> +BSP_output_char = output_char_fb;
> +link("/dev/fbcons", CONSOLE_DEVICE_NAME);
> +  }
> +}else{
> +
> +  if ( console == NULL ){
> +bsp_fatal( BSP_FATAL_CONSOLE_NO_DEV );
> +  }
> +  BSP_output_char = output_char_serial;
> +  link("/dev/ttyuart0", CONSOLE_DEVICE_NAME);
> +}
> +  }
> +}
> +
> +static void uart_probe(void)
> +{
> +  const void *fdt;
> +  const char *console;
> +  int node;
> +
> +  fdt = bsp_fdt_get();
> +  node = fdt_path_offset(fdt, "/chosen");
> +
> +  console =