Re: [GSoC - x86_64] Console / serial communication
On Tue, Jun 26, 2018 at 4:10 AM, Chris Johns wrote: > On 25/06/2018 21:40, Amaan Cheval wrote: >> Hi! >> >> In the last thread about using FreeBSD's bootloader to bring UEFI >> support to our port, Chris said this: >> >>> It has been a couple of years but I think FreeBSD contains some of the Intel >>> code to interface to UEFI and via this you can get to the UEFI console. This >>> should be easy but it comes with a side effect. >>> >>> UEFI boots in graphics mode and so it's console on a PC is a slow scroll >>> one. On >>> boards like a Minnow using the UEFI console has the advantage of being able >>> to >>> support any redirection UEFI has enabled such as a serial port. The >>> disadvantage >>> of this is performance and overhead. In time this may be a boot option. >>> >>> What I am not sure is the boundary between UEFI and the kernel and what is >>> enabled or available when the kernel is loaded. >> >> Source: https://lists.rtems.org/pipermail/devel/2018-June/022136.html >> >> According to my understanding, the efi_console is not available to the >> kernel - only to the loader.efi (the PE image of the bootloader, which >> eventually loads the ELF kernel). > > OK. > >> (In brief, my reasoning for this belief is that efi_console is defined >> and initialized only through the bootloader code (in stand/efi/main.c, >> when cons_probe is called). The efi_console relies on UEFI's >> BootServices, which won't be accessible when the ELF kernel is loaded, >> because ExitBootServices() is called before loading the kernel (as >> part of bi_load).) > > I suspect I was looking at a direct entry to RTEMS from EFI rather than the > better way of using loader.efi. > >> Given that information, it makes more sense to actually port a console >> driver that the ELF kernel uses, not that the bootloader uses. > > Yes this makes sense. Thank for you for researching this and resolving it. Sure thing! > >> >> I'll look into how FreeBSD implements their UART console >> (https://github.com/freebsd/freebsd/blob/1cfbfa1fae9926303f69532a97a5a766fa672582/sys/dev/uart/uart_tty.c), >> and look into possibly reusing RTEMS' existing drivers for UART >> (NS16550?) as applicable. > > There are working drivers for this device in RTEMS already (libchip) and the > i386 BSP has some support. Ah, yeah, that's why I mentioned it - I'm completely unfamiliar with these drivers, so I don't really have a way of picking _the_ one to implement first, for our minimal BSP. > > Will a text based video console be supported? As above, I can't say :P The only guiding factor I have for GSoC is to do the _minimal_ needed port first, because the project is quite wide - once _all_ the basics (clock next, some of IRQ, maybe ACPI) are done, we can look into what to improve further if we have the time. Given the possibility that we may not be able to add more than one console this summer, which would we want the most? Which driver? (I'm trying to do my own research too, of course, but if there's an obvious one you can think of, let me know!) I only picked UART because it seems to be what's used when we use QEMU's "-serial stdio" flags. > >> >> I'm not sure I know enough about serial programming _yet_, so do let >> me know if you think you have any resources that would be useful or if >> you'd like to fine-tune my plan! > > I suggest you review the ARM and SPARC bsps and follow those models. The i386 > has support for PCI based UARTS which this BSP will need to support. Will do! > >> >> P.S. - Since we last disussed it, the context initialization and >> switching are working, and the port does now make it to the user's >> Init task! :D >> > > Awesome. > > Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [GSoC - x86_64] Console / serial communication
On 25/06/2018 21:40, Amaan Cheval wrote: > Hi! > > In the last thread about using FreeBSD's bootloader to bring UEFI > support to our port, Chris said this: > >> It has been a couple of years but I think FreeBSD contains some of the Intel >> code to interface to UEFI and via this you can get to the UEFI console. This >> should be easy but it comes with a side effect. >> >> UEFI boots in graphics mode and so it's console on a PC is a slow scroll >> one. On >> boards like a Minnow using the UEFI console has the advantage of being able >> to >> support any redirection UEFI has enabled such as a serial port. The >> disadvantage >> of this is performance and overhead. In time this may be a boot option. >> >> What I am not sure is the boundary between UEFI and the kernel and what is >> enabled or available when the kernel is loaded. > > Source: https://lists.rtems.org/pipermail/devel/2018-June/022136.html > > According to my understanding, the efi_console is not available to the > kernel - only to the loader.efi (the PE image of the bootloader, which > eventually loads the ELF kernel). OK. > (In brief, my reasoning for this belief is that efi_console is defined > and initialized only through the bootloader code (in stand/efi/main.c, > when cons_probe is called). The efi_console relies on UEFI's > BootServices, which won't be accessible when the ELF kernel is loaded, > because ExitBootServices() is called before loading the kernel (as > part of bi_load).) I suspect I was looking at a direct entry to RTEMS from EFI rather than the better way of using loader.efi. > Given that information, it makes more sense to actually port a console > driver that the ELF kernel uses, not that the bootloader uses. Yes this makes sense. Thank for you for researching this and resolving it. > > I'll look into how FreeBSD implements their UART console > (https://github.com/freebsd/freebsd/blob/1cfbfa1fae9926303f69532a97a5a766fa672582/sys/dev/uart/uart_tty.c), > and look into possibly reusing RTEMS' existing drivers for UART > (NS16550?) as applicable. There are working drivers for this device in RTEMS already (libchip) and the i386 BSP has some support. Will a text based video console be supported? > > I'm not sure I know enough about serial programming _yet_, so do let > me know if you think you have any resources that would be useful or if > you'd like to fine-tune my plan! I suggest you review the ARM and SPARC bsps and follow those models. The i386 has support for PCI based UARTS which this BSP will need to support. > > P.S. - Since we last disussed it, the context initialization and > switching are working, and the port does now make it to the user's > Init task! :D > Awesome. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH v2] coverage : Add support to run coverage in supported bsp without extra options
Close #3440
---
tester/rt/test.py| 21 ++---
tester/rtems/testing/bsps/leon3-qemu-cov.ini | 1 +
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/tester/rt/test.py b/tester/rt/test.py
index 9214ad6..029ee7c 100644
--- a/tester/rt/test.py
+++ b/tester/rt/test.py
@@ -232,7 +232,7 @@ def run(command_path = None):
'--filter': 'Glob that executables must match to
run (default: ' +
default_exefilter + ')',
'--stacktrace': 'Dump a stack trace on a user
termination (^C)',
-'--coverage': 'Perform coverage analysis of test
executables.'}
+'--coverage-sets': 'Perform coverage analysis of test
executables.'}
mailer.append_options(optargs)
opts = options.load(sys.argv,
optargs = optargs,
@@ -283,14 +283,21 @@ def run(command_path = None):
raise error.general('RTEMS BSP not provided or an invalid option')
bsp = config.load(bsp[1], opts)
bsp_config = opts.defaults.expand(opts.defaults['tester'])
-coverage_enabled = opts.find_arg('--coverage')
+coverage_sets = opts.find_arg('--coverage-sets')
+try:
+coverage_enabled=opts.defaults.get('coverage')
+except:
+coverage_enabled=False
if coverage_enabled:
cov_trace = 'cov' in debug_trace.split(',')
-if len(coverage_enabled) == 2:
-coverage_runner = coverage.coverage_run(opts.defaults,
-executables,
-symbol_set =
coverage_enabled[1],
-trace = cov_trace)
+if coverage_sets:
+if len(coverage_sets)!= 2:
+raise error.general('No sets provided in --coverage-sets')
+else:
+coverage_runner = coverage.coverage_run(opts.defaults,
+executables,
+symbol_set =
coverage_sets[1],
+trace = cov_trace)
else:
coverage_runner = coverage.coverage_run(opts.defaults,
executables,
diff --git a/tester/rtems/testing/bsps/leon3-qemu-cov.ini
b/tester/rtems/testing/bsps/leon3-qemu-cov.ini
index 2f89117..6462448 100644
--- a/tester/rtems/testing/bsps/leon3-qemu-cov.ini
+++ b/tester/rtems/testing/bsps/leon3-qemu-cov.ini
@@ -38,3 +38,4 @@ target= sparc-rtems5
tester= %{_rtscripts}/qemu.cfg
bsp_qemu_opts = %{qemu_opts_base} -M leon3_generic
bsp_qemu_cov_opts = -exec-trace %{test_executable}.cov
+coverage = True
--
2.14.4
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] coverage : Add support to run coverage in supported bsp without extra options
On 15 June 2018 at 08:38, Chris Johns wrote:
> On 14/06/2018 03:12, Gedare Bloom wrote:
> > On Wed, Jun 13, 2018 at 12:23 PM, Vijay Kumar Banerjee
> > wrote:
> >> On Wed, 13 Jun 2018, 21:39 Gedare Bloom, wrote:
> >>> On Wed, Jun 13, 2018 at 11:58 AM, Vijay Kumar Banerjee
> >>> wrote:
> On 13 June 2018 at 10:29, Gedare Bloom wrote:
> > On Thu, Jun 7, 2018 at 7:08 AM, Vijay Kumar Banerjee
> > wrote:
> >> bsp = opts.find_arg('--rtems-bsp')
> >> +if 'cov' in bsp[1].split('-'):
> >
> > I'm not sure if this use of the 'cov' field in the bsp config
> filename
> > itself is the proper way to go about accomplishing the activation of
> > coverage. What are other possible ways to get this done? Is the use
> of
> > a portion of the bsp config filename done elsewhere in tester?
>
> This patch was made following Chris' comments in another thread
>
> https://lists.rtems.org/pipermail/devel/2018-June/021931.html
>
> >>>
> >>> I can't be sure, but I don't think his intent was to infer the
> >>> coverage from the ini file name.
>
> Correct.
>
> >>> For example, does the tester parse
> >>> the ini file name to check for 'qemu' to decide if that target is
> >>> being used? Instead, it should look in to the config file to read the
> >>> option somehow.
> >>
> >> In leon3-qemu.ini the bsp option inside the
> >> config file is set to leon3-qemu.
> >>
> >> There's no such special thing added to bsp for coverage.
> >> Only difference we have is that,
> >> the option 'bsp_qemu_cov_opts' is added in the coverage supported file.
> we
> >> can
> >> read the config file to see if this option is present.
> >>
> >> Shall I do it this way?
> >
> > Yes, I suspect you should.
> >
>
> Can we have 'coverage = true' in the INI file to indicate this BSP supports
> coverage?
>
> >>>
> >
> >> +coverage_enabled = True
>
> And that values maps to here.
>
> As the covoar patches are merged, shall I send a patch with the
coverage=true option ?
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[GSoC - x86_64] Console / serial communication
Hi! In the last thread about using FreeBSD's bootloader to bring UEFI support to our port, Chris said this: > It has been a couple of years but I think FreeBSD contains some of the Intel > code to interface to UEFI and via this you can get to the UEFI console. This > should be easy but it comes with a side effect. > > UEFI boots in graphics mode and so it's console on a PC is a slow scroll one. > On > boards like a Minnow using the UEFI console has the advantage of being able to > support any redirection UEFI has enabled such as a serial port. The > disadvantage > of this is performance and overhead. In time this may be a boot option. > > What I am not sure is the boundary between UEFI and the kernel and what is > enabled or available when the kernel is loaded. Source: https://lists.rtems.org/pipermail/devel/2018-June/022136.html According to my understanding, the efi_console is not available to the kernel - only to the loader.efi (the PE image of the bootloader, which eventually loads the ELF kernel). (In brief, my reasoning for this belief is that efi_console is defined and initialized only through the bootloader code (in stand/efi/main.c, when cons_probe is called). The efi_console relies on UEFI's BootServices, which won't be accessible when the ELF kernel is loaded, because ExitBootServices() is called before loading the kernel (as part of bi_load).) Given that information, it makes more sense to actually port a console driver that the ELF kernel uses, not that the bootloader uses. I'll look into how FreeBSD implements their UART console (https://github.com/freebsd/freebsd/blob/1cfbfa1fae9926303f69532a97a5a766fa672582/sys/dev/uart/uart_tty.c), and look into possibly reusing RTEMS' existing drivers for UART (NS16550?) as applicable. I'm not sure I know enough about serial programming _yet_, so do let me know if you think you have any resources that would be useful or if you'd like to fine-tune my plan! P.S. - Since we last disussed it, the context initialization and switching are working, and the port does now make it to the user's Init task! :D Cheers ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Outdated documentation hosted on the RTEMS FTP (and indexed by search engines)
On 25/06/18 08:02, Amaan Cheval wrote: Here's a few others I've found indexed on Google: -https://ftp.rtems.org/pub/rtems/people/sebh/c-user/html/glossary.html Thanks for the hint. I removed the files. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Outdated documentation hosted on the RTEMS FTP (and indexed by search engines)
Hi! A month or so ago we discussed some possibly outdated docs being hosted on the RTEMS FTP for specific users. https://lists.rtems.org/pipermail/devel/2018-May/021480.html Here's a few others I've found indexed on Google: - https://ftp.rtems.org/pub/rtems/people/sebh/c-user/html/glossary.html - https://ftp.rtems.org/pub/rtems/people/joel/doc/c_user/configuring_a_system.html Regards, Amaan ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
