Re: x86_64 BSP : Status Update [ticket #2898]

I linked the wrong GSoC status update of mine there - here's the final report that you may find useful: https://blog.whatthedude.com/post/gsoc-final/#future-to-do On Mon, Mar 29, 2021 at 3:38 PM Amaan Cheval wrote: > > Hey Shashvat! > > I've CC'd Chris who may have something

Re: x86_64 BSP : Status Update [ticket #2898]

Hey Shashvat! I've CC'd Chris who may have something to add given that the original ticket seems to have an update from John Millard - not sure if John's made progress since my work on the x86-64 BSP was upstreamed, so I'll let Chris speak to that. I wouldn't recommend running it on real

Re: Current master fails make

Hey Richi, You probably need to upgrade and rebuild your toolchain using RSB to support these new ftw.h related tests. See this relevant mail from the list announcing this: https://lists.rtems.org/pipermail/users/2021-March/068264.html Hope that helps! On Mon, Mar 15, 2021, 12:02 PM Richi

Re: [PATCH v2] Add Amaan to MAINTAINERS

Done! https://git.rtems.org/rtems/commit/?id=486829b2766119275f74e7a2a11d7bf3a9561f54 On Fri, Feb 21, 2020 at 10:35 PM Gedare Bloom wrote: > This second one looks good, please push! > > On Thu, Feb 20, 2020 at 9:55 PM Amaan Cheval > wrote: > > > > --- > >

[PATCH v2] Add Amaan to MAINTAINERS

christian.maude...@embedded-brains.de Hesham Almataryheshamelmat...@gmail.com +Amaan Cheval am...@rtems.org Localized Write Permission == @@ -58,4 +59,5 @@ sparc Daniel Hellstrom (dan...@gaisler.com) beagle

Re: [PATCH] Add Amaan to MAINTAINERS

Made this patch before fetching/rebasing master, so it won't apply cleanly. v2 after rebasing is on its way. On Fri, Feb 21, 2020 at 10:15 AM Amaan Cheval wrote: > --- > MAINTAINERS | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS >

[PATCH] Add Amaan to MAINTAINERS

Pavel Pisa pp...@pikron.com Christian Mauderer christian.maude...@embedded-brains.de +Amaan Cheval am...@rtems.org Localized Write Permission == @@ -58,4 +59,5 @@ sparc Daniel Hellstrom (dan...@gaisler.com) beagle

Re: GSOC: Call for Mentors

Hey! I'd like to co-mentor a project too. Thanks! On Tue, Feb 18, 2020 at 8:56 AM Vijay Kumar Banerjee < vijaykumar9...@gmail.com> wrote: > Hi Gedare, > > Please add me to the list of co-mentors. > Looking forward to a great experience. :) > > Best regards, > Vijay > > > On Tue, Feb 18, 2020,

Re: x86_64 gcc missing crti/n

Quick note; I'm not at the computer, but I haven't tested with the RTEMS 6 buildsets - I can do that tomorrow too. On Thu, Mar 14, 2019, 10:52 PM Amaan Cheval wrote: > Hey! > > It seems like the RSB patch for crt[i/n] was mistakenly taken out > along with other stuff: > > htt

Re: x86_64 gcc missing crti/n

> devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel From edd8d1090eaf35a56346af8130b1d1a73fcb2d56 Mon Sep 17 00:00:00 2001 From: Amaan Cheval Date: Thu, 14 Mar 2019 22:26:48 +0530 Subject: [PATCH] 5: Fix x86_64 GCC buil

Re: Query Regarding Old Projects, for GSoC 2019

I'm not sure if the project is open, but if it is, I'd be willing to co-mentor. On Wed, Mar 6, 2019, 2:45 PM Vaibhav Gupta wrote: > I was exploring for more open projects and found the following one. > > - Port V8 Javascript Engine : > https://devel.rtems.org/wiki/Developer/Projects/Open/V8 > >

Re: git.rtems.org LetsEncrypt TLS certificate expired

Hi! Seems like rtems.org now has this issue. On Thu, Aug 16, 2018 at 6:09 AM Chris Johns wrote: > > On 15/8/18 11:19 pm, Amaan Cheval wrote: > > FYI: https://docs.rtems.org has an expired certificate too. > > > > On Wed, Aug 15, 2018 at 3:30 PM, Amaan Cheval &

Re: Aligned operations mismatch

On Wed, Aug 22, 2018 at 8:20 PM Mikhail Svetkin wrote: > > Hi all, > > I have found a problem with assembler code generation in network stack on ARM > processor (aligment fault). > > I am using: > arm-rtems5-gcc (GCC) 7.2.0 20170814 (RTEMS 5, RSB > a6d011e028a0776cedf0823940eb882e917a44e5,

[PATCH] user: Update x86-64 chapter with end-of-GSoC status

--- user/bsps/bsps-x86_64.rst | 52 ++- 1 file changed, 51 insertions(+), 1 deletion(-) diff --git a/user/bsps/bsps-x86_64.rst b/user/bsps/bsps-x86_64.rst index 19c4461..c13f369 100644 --- a/user/bsps/bsps-x86_64.rst +++ b/user/bsps/bsps-x86_64.rst @@ -136,10

Re: [GSoC - x86_64] Pre-merge issues (at -O2 optimization level) and WIP review

On Tue, Aug 14, 2018 at 7:34 PM, Joel Sherrill wrote: > > > On Sun, Aug 12, 2018 at 4:47 PM, Amaan Cheval > wrote: >> >> Hi! >> >> I've narrowed the issue down to this bintime function: >> >> https://github.com/RTEMS/rtems/blob/b2de4260c5c71e51874

Re: git.rtems.org LetsEncrypt TLS certificate expired

FYI: https://docs.rtems.org has an expired certificate too. On Wed, Aug 15, 2018 at 3:30 PM, Amaan Cheval wrote: > The HTTPS certificate for https://git.rtems.org has expired (~15 > minutes ago). Are the auto-renewal scripts failing? ___ devel m

git.rtems.org LetsEncrypt TLS certificate expired

The HTTPS certificate for https://git.rtems.org has expired (~15 minutes ago). Are the auto-renewal scripts failing? ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

[GSoC - x86_64] Final report

Hi! I've written my final report up here: https://blog.whatthedude.com/post/gsoc-final/ Let me know if you have any comments! It's been really fun working with all of you, and I look forward to more! Cheers! ___ devel mailing list devel@rtems.org

[PATCH 3/5] bsps/x86_64: Add paging support with 1GiB super pages

identity-page mapping for the 512 GiBs addressable by using static + * PML4 and PDPT tables. + * + * Section 4.5 "4-Level Paging" of Volume 3 of the Intel Software Developer + * Manual guides a lot of the code used in this file. + */ + +/* + * Copyright (c) 2018. + * Am

[PATCH 5/5] bsps/x86_64: Add APIC timer based clock driver

00..76e537755a --- /dev/null +++ b/bsps/x86_64/amd64/clock/clock.c @@ -0,0 +1,299 @@ +/* + * Copyright (c) 2018. + * Amaan Cheval + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met

[PATCH 2/5] bsps/x86_64: Reduce default RamSize to 1GiB

Simulators may not always be able to allocate 4GiB easily, and using an artificially lower RAM may cause a broken heap. Updates #2898. --- bsps/x86_64/amd64/start/linkcmds | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/bsps/x86_64/amd64/start/linkcmds

[PATCH 1/5] bsps/x86_64: Reorganize header files and compile-options

t a/cpukit/score/cpu/x86_64/include/rtems/score/cpu_asm.h b/cpukit/score/cpu/x86_64/include/rtems/score/cpu_asm.h new file mode 100644 index 00..ac43a6366d --- /dev/null +++ b/cpukit/score/cpu/x86_64/include/rtems/score/cpu_asm.h @@ -0,0 +1,50 @@ +/* + * Copyright (c) 20

[PATCH 0/5] [GSoC - x86_64] Add interrupts and clock driver

This patch series includes all of my remaining work so far on the x86_64 BSP. It supports: * Static paging support using 1GiB superpages * RTEMS interrupts * A fairly accurate clock driver based on the APIC timer calibrated by the PIT ticker.exe passes reliably on -O0 optimization level, and it

Re: [GSoC - x86_64] Pre-merge issues (at -O2 optimization level) and WIP review

passed, for eg., when the tc_frequency=100Hz - in that case the bintime's returned "now.tv_sec" value in clockgettod.c causes the wrong second to be set in "time_buffer"). https://github.com/AmaanC/rtems-gsoc18/blob/ac/daily-03-post-hello/bsps/x86_64/amd64/clock/clock.c#L51 On S

Re: [GSoC - x86_64] Pre-merge issues (at -O2 optimization level) and WIP review

at 3:43 AM, Amaan Cheval wrote: > Figured it out; turns out my code to align the stack so I could make > calls without raising exceptions was messing up and corrupting the > stack-pointer. > > Running the -O2 code now makes the clock run a bit too quickly - the > calibration may

[GSoC - x86_64] Pre-merge issues (at -O2 optimization level) and WIP review

Hi! In the process of cleaning my work up, I've run into an odd problem which only shows up when I set the optimization level to -O2. At -O0, it's perfectly fine. The issue is that somehow execution ends up at address 0x0. This likely happens due to a _CPU_Context_switch, where the rsp is set

Re: [PATCH] Rework to minimize and eventually eliminate RTEMS use of bsp_specs

try to do this before I leave about lunch. > > Looks like we both have work to do before the end of GSoC. :) > > --joel > > On Fri, Aug 10, 2018 at 6:11 AM, Amaan Cheval > wrote: >> >> Hey Joel! >> >> I'm not sure if this ever made it upstream - if it

Re: [PATCH] Rework to minimize and eventually eliminate RTEMS use of bsp_specs

ends. On Mon, Jul 9, 2018 at 10:30 AM, Amaan Cheval wrote: > To make my previous email clearer, here's what I meant with the > "minimal" GCC patch required (attached). > > To manually test, you can place gcc-STARTFILE_SPEC.patch in > $RSB/rtems/patches/ and then &quo

Re: [GSoC - x86_64] Interrupt manager and and port-specific glue - was Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a

Joel Sherrill wrote: > > > On Thu, Aug 9, 2018 at 7:43 AM, Amaan Cheval wrote: >> >> Addition to status: it doesn't seem like the RTEMS Interrupt's call to >> _Thread_Dispatch functions either - ticker.exe has outputs like the >> following (yeah, the counter is ru

Re: [GSoC - x86_64] Interrupt manager and and port-specific glue - was Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a

o have this whole > thing done by EOD Monday for me.) > > On Thu, Aug 9, 2018 at 7:03 AM, Gedare Bloom wrote: >> On Wed, Aug 8, 2018 at 12:21 PM, Amaan Cheval wrote: >>> Status update: The code is at a point where the APIC timer _should_ >>> work, but doesn't (it

Re: [GSoC - x86_64] Interrupt manager and and port-specific glue - was Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a

On Wed, Aug 8, 2018 at 12:21 PM, Amaan Cheval wrote: >> Status update: The code is at a point where the APIC timer _should_ >> work, but doesn't (it never starts ticking away, so when calibrating >> with the PIT, and later starting the APIC timer to generate IRQs, >> pretty m

Re: [GSoC - x86_64] Interrupt manager and and port-specific glue - was Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a

M, Chris Johns wrote: > On 07/08/2018 09:27, Joel Sherrill wrote: >> On Mon, Aug 6, 2018 at 8:13 AM, Amaan Cheval > <mailto:amaan.che...@gmail.com>> wrote: >> >> Thanks for all the help! I have a simple test using the RTEMS &

Re: [GSoC - x86_64] Interrupt manager and and port-specific glue - was Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a

t 10:51 PM, Joel Sherrill wrote: > I have started to reply twice but you jumped in ahead. :) > > On Wed, Aug 1, 2018 at 12:12 PM, Amaan Cheval > wrote: >> >> If my previous email _is_ in fact correct, could someone confirm? >> Because this excerpt in the documentati

Re: [GSoC - x86_64] Interrupt manager and and port-specific glue - was Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a

the address of the user’s ISR in the > RTEMS’ Vector Table**. This directive returns the previous contents of the > specified vector in the RTEMS’ Vector Table. On Wed, Aug 1, 2018 at 10:39 PM, Amaan Cheval wrote: > Okay, I think I understand finally. Sorry about the rambling! > >

Re: [GSoC - x86_64] Interrupt manager and and port-specific glue - was Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a

ed, that's an "RTEMS interrupt", and we go through the _ISR_Handler -> dispatch route I laid out earlier, leading to eventually the user's ISR. Thank you for letting me rubber-duck with you, everyone (let me know if anything above sounds off, though!) :P On Wed, Aug 1, 2018 at 10:20

Re: [GSoC - x86_64] Interrupt manager and and port-specific glue - was Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a

n to know what that "missing link" is? On Wed, Aug 1, 2018 at 9:07 PM, Joel Sherrill wrote: > > > On Wed, Aug 1, 2018 at 10:11 AM, Gedare Bloom wrote: >> >> On Wed, Aug 1, 2018 at 9:15 AM, Amaan Cheval >> wrote: >> > That's definitely very illuminat

[GSoC - x86_64] Interrupt manager and and port-specific glue - was Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a

ead, I can figure it out without wasting your time :) [1] https://devel.rtems.org/ticket/3459#comment:11 On Wed, Aug 1, 2018 at 3:18 AM, Joel Sherrill wrote: > > > On Tue, Jul 31, 2018 at 3:05 PM, Amaan Cheval > wrote: >> >> Hm, I'm not sure what to look for in the other

Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a

31, 2018 at 2:52 PM, Amaan Cheval > wrote: > >> Hi Chris! >> >> I currently have code like this in >> c/src/lib/libbsp/x86_64/amd64/Makefile.am: >> >> librtemsbsp_a_SOURCES += >> ../../../../../../bsps/x86_64/amd64/interrupts/handlers.c >&g

[GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a

Hi Chris! I currently have code like this in c/src/lib/libbsp/x86_64/amd64/Makefile.am: librtemsbsp_a_SOURCES += ../../../../../../bsps/x86_64/amd64/interrupts/handlers.c # XXX: Needed to use GCC "interrupt" attribute directives - can we pass these # flags only for the handlers.c

Re: [GSoC - x86_64] Clock driver - which hardware source to support primarily?

addresses. I'm just not sure of unintended consequences due to this (for eg. with the linker script's structure influencing memory-mapped devices). I guess we'll look into this when we come to it, though. On Tue, Jul 31, 2018, 1:28 AM Joel Sherrill wrote: > > > On Mon, Jul 30, 2018, 2:27 PM Ama

Re: [GSoC - x86_64] Clock driver - which hardware source to support primarily?

ined clock driver for the x86_64 port too. On Wed, Jul 18, 2018 at 7:53 PM, Gedare Bloom wrote: > On Wed, Jul 18, 2018 at 10:17 AM, Joel Sherrill wrote: >> >> >> On Wed, Jul 18, 2018 at 12:31 AM, Sebastian Huber >> wrote: >>> >>> Hello Amaan, >

Re: [PATCH] sptests/spfatal26: Use an illegal instruction

On Fri, Jul 20, 2018 at 12:18 AM, Joel Sherrill wrote: > > > On Thu, Jul 19, 2018 at 1:37 PM, Sebastian Huber > wrote: >> >> >> >> - Am 19. Jul 2018 um 17:03 schrieb joel j...@rtems.org: >> >> > On Thu, Jul 19, 2018 at 8:49 AM, Gedare Bloom wrote: >> > >> >> For now we don't need to

Re: [PATCH 0/1] [GSoC - x86_64] User documentation for BSP

On Wed, Jul 18, 2018 at 6:56 PM, Gedare Bloom wrote: > On Wed, Jul 18, 2018 at 9:09 AM, Amaan Cheval wrote: >> Hi! >> >> On Fri, Jul 13, 2018 at 7:32 PM, Joel Sherrill wrote: >>> >>> >>> On Fri, Jul 13, 2018 at 8:25 AM, Gedare Bloom wrote: >

Re: [PATCH 0/1] [GSoC - x86_64] User documentation for BSP

Hi! On Fri, Jul 13, 2018 at 7:32 PM, Joel Sherrill wrote: > > > On Fri, Jul 13, 2018 at 8:25 AM, Gedare Bloom wrote: >> >> Hello Amaan, >> >> >> On Fri, Jul 13, 2018 at 3:32 AM, Amaan Cheval >> wrote: >> > The built documentation can m

Re: [GSoC - x86_64] Clock driver - which hardware source to support primarily?

Hey! On Wed, Jul 18, 2018 at 11:01 AM, Sebastian Huber wrote: > Hello Amaan, > > On 17/07/18 19:18, Amaan Cheval wrote: >> >> Hi! >> >> Now that I'm working on the clock driver, we need to pick what we >> support first. Our options in brief are: > >

Re: [GSoC - x86_64] Clock driver - which hardware source to support primarily?

: > > > On Tue, Jul 17, 2018 at 12:18 PM, Amaan Cheval > wrote: >> >> Hi! >> >> Now that I'm working on the clock driver, we need to pick what we >> support first. Our options in brief are: >> >> - rdtsc; will need calibration through the PIT or one of

[GSoC - x86_64] Clock driver - which hardware source to support primarily?

Hi! Now that I'm working on the clock driver, we need to pick what we support first. Our options in brief are: - rdtsc; will need calibration through the PIT or one of the other options - PIT; likely not given how legacy it is, but it may be quite simple - APIC timer[1]; better for long-term

[PATCH 1/1] user: Add x86_64 BSP chapter

@@ -1,7 +1,148 @@ .. comment SPDX-License-Identifier: CC-BY-SA-4.0 +.. comment Copyright (c) 2018 Amaan Cheval .. comment Copyright (c) 2018 embedded brains GmbH x86_64 ** -There are no x86_64 BSPs yet. +amd64 += + +This BSP offers only one variant, ``amd64``. The BSP can run on UEFI

[PATCH 0/1] [GSoC - x86_64] User documentation for BSP

to update the RSB's QEMU to also build graphics support. P.P.S. - Some of the documentation is double-spaced, but this patch isn't. Let me know if it ought to be (the README didn't say anything of the sort, and it isn't consistent throughout). Amaan Cheval (1): user: Add x86_64 BSP chapter user

Re: [PATCH 2/2] x86_64/console: Add NS16550 polled console driver

can > begin to experiment with and enhance it. > > Thanks Amaan. We all look forward to you guiding this port and > BSP to maturity. :) > > --joel > > On Mon, Jul 9, 2018 at 6:12 AM, Amaan Cheval wrote: >> >> This addition allows us to successfully ru

[PATCH 2/2] x86_64/console: Add NS16550 polled console driver

This addition allows us to successfully run the sample hello.exe test. Updates #2898. --- bsps/x86_64/amd64/console/console.c| 123 + c/src/lib/libbsp/x86_64/amd64/Makefile.am | 2 + .../score/cpu/x86_64/include/rtems/score/cpuimpl.h | 14 +++

[PATCH 1/2] bsp/x86_64: Minimal bootable BSP

--- /dev/null +++ b/bsps/x86_64/amd64/console/console.c @@ -0,0 +1,135 @@ +/* + * Copyright (c) 2018. + * Amaan Cheval + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions

[PATCH 0/2] [GSoC - x86_64] Minimal BSP patch

on Trac instead - The way 'x86_64-context-switch.S' works directly on the 'Context_Control' structure (Ctrl+F 'CPU_SIZEOF_POINTER') Amaan Cheval (2): bsp/x86_64: Minimal bootable BSP x86_64/console: Add NS16550 polled console driver bsps/x86_64/amd64/config/amd64.cfg | 13

Re: [GSoC - x86_64] Minimal BSP to review

wrote: > On Thu, Jul 5, 2018 at 10:02 AM, Amaan Cheval wrote: >> Hi! >> >> Yeah, the individual commits aren't logical at all. I just thought we >> could review the actual code contents (in the "files changed" tab) on >> Github (https://github.com/AmaanC/

Re: [PATCH] Rework to minimize and eventually eliminate RTEMS use of bsp_specs

? For now, I'm going to leave it in. On Fri, Jul 6, 2018 at 10:46 AM, Amaan Cheval wrote: > Hey, Joel! > > The x86_64 BSP currently uses an empty bsp_specs file contingent on > (at least the x86-64 parts of) this email thread's patch making it > upstream to GCC, and making their

Re: [GSoC - x86_64] Minimal BSP to review

Hi! Yeah, the individual commits aren't logical at all. I just thought we could review the actual code contents (in the "files changed" tab) on Github (https://github.com/AmaanC/rtems-gsoc18/pull/1/files). Is this what you meant by "final patchset"? Once this PR is polished up sufficiently, I

[GSoC - x86_64] Minimal BSP to review

Hi! I've made a pull-request that's nearly complete on Github: https://github.com/AmaanC/rtems-gsoc18/pull/1/ I'd appreciate a review before I squash it into 2 commits (1. minimal BSP reaching Init task, and 2. adding the NS16550 console driver) and submit the squashed patches to devel@ after

Re: [GSoC - x86_64] Current state, next steps, and minimal mergable BSP

wrote: > >> On 29 Jun 2018, at 11:37 pm, Amaan Cheval wrote: >> >> On Fri, Jun 29, 2018 at 6:46 PM, Sebastian Huber >> wrote: >>> >>> From my point of view we can merge this stuff right now if the license and >>> copyright status is clear o

Re: GSoC IRC Meeting reschedule: 7/4 to 7/3

Hey! Sorry, I totally forgot we meant to reschedule this week's meeting - I have another conflicting commitment at that time. I'll try to pop in for a bit if possible. I'll update the wiki page with this week's work, but here's the update I'd have sent on IRC: - Got basic UART/console driver

Re: [GSoC - x86_64] Current state, next steps, and minimal mergable BSP

On Fri, Jun 29, 2018 at 6:46 PM, Sebastian Huber wrote: > Hello Amaan, > > On 29/06/18 14:31, Amaan Cheval wrote: >> >> Hi! >> >> There are 3 sections to this email: >> - An update on the current state >> - What I plan to work on next >> - An o

[GSoC - x86_64] Current state, next steps, and minimal mergable BSP

Hi! There are 3 sections to this email: - An update on the current state - What I plan to work on next - An open question on when we want to merge this upstream The current state of the BSP (available at

devel.rtems.org unavailabe?

Hi! Here's what I see when visiting https://devel.rtems.org/: Service Unavailable The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later. Regards, Amaan ___ devel mailing list

Re: [GSoC - x86_64] Console / serial communication

comconsole, vidconsole, nullconsole, and efi) I'll let y'all know as things progress! Would it be a blocker if we couldn't quiet the UEFI firmware and loader.efi? On Thu, Jun 28, 2018, 3:39 AM Chris Johns wrote: > On 28/06/2018 00:37, Amaan Cheval wrote: > > Since we skipped our me

Re: [GSoC - x86_64] Console / serial communication

On Tue, Jun 26, 2018 at 12:42 PM, Amaan Cheval wrote: > On Tue, Jun 26, 2018 at 12:15 PM, Chris Johns wrote: >> On 26/06/2018 14:29, Amaan Cheval wrote: >>> On Tue, Jun 26, 2018 at 4:10 AM, Chris Johns wrote: >>>> On 25/06/2018 21:40, Amaan Cheval wrote: >

Re: [GSoC - x86_64] Console / serial communication

On Tue, Jun 26, 2018 at 12:15 PM, Chris Johns wrote: > On 26/06/2018 14:29, Amaan Cheval wrote: >> On Tue, Jun 26, 2018 at 4:10 AM, Chris Johns wrote: >>> On 25/06/2018 21:40, Amaan Cheval wrote: >>> >>> Will a text based video console be supported? >&g

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

[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

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

Re: [GSoC - x86_64 port] Status update - June 21

On Thu, Jun 21, 2018 at 5:42 PM, Amaan Cheval wrote: > Hi! > > In lieu of our weekly meeting, here's a quick status update. The past > week, I worked on: > - Making FreeBSD's bootloader load a custom ELF kernel, and then RTEMS > static binaries > - Fixing cpu.h up to refle

[GSoC - x86_64 port] Status update - June 21

Hi! In lieu of our weekly meeting, here's a quick status update. The past week, I worked on: - Making FreeBSD's bootloader load a custom ELF kernel, and then RTEMS static binaries - Fixing cpu.h up to reflect the x86_64 feature set - Fixing the linker script up for my stub to allow for sysinit

Copyright and license notices in new and ported code

Hi! In some RTEMS source files I see a series of copyright notices, including those for individuals and corporations, for eg.: https://git.rtems.org/rtems/tree/cpukit/score/cpu/arm/include/rtems/score/cpu.h#n7 https://git.rtems.org/rtems/commit/?id=660db8c86fa16dc67c40bdeebbf671e50a7f3087 (again,

Re: [GSoC - x86_64] Using FreeBSD's UEFI loader for RTEMS static binaries

On Thu, Jun 14, 2018 at 11:25 AM, Chris Johns wrote: > On 14/06/2018 05:33, Joel Sherrill wrote: >> On Wed, Jun 13, 2018, 6:57 PM Amaan Cheval > <mailto:amaan.che...@gmail.com>> wrote: >> >> On Wed, Jun 13, 2018 at 9:35 PM, Gedare Bloom > <mailto:ge

Re: [GSoC - x86_64] Using FreeBSD's UEFI loader for RTEMS static binaries

out, though :P). On Fri, Jun 15, 2018 at 5:33 AM, Chris Johns wrote: > On 15/06/2018 03:25, Amaan Cheval wrote: >> >> For shutdown and whatnot, I imagine I'll need to get our ACPI support >> out there too, so that may be on the backburner for a little bit. >> >

Re: [GSoC - x86_64] Using FreeBSD's UEFI loader for RTEMS static binaries

Gotcha. We can leave an #error directive in what we merge initially too, like we did for the i386 SMP support. On Thu, Jun 14, 2018, 11:55 PM Gedare Bloom wrote: > On Thu, Jun 14, 2018 at 1:25 PM, Amaan Cheval > wrote: > > Sounds good! > > > > For shutdown and what

Re: [GSoC - x86_64] Using FreeBSD's UEFI loader for RTEMS static binaries

, initialization, and reaching the init task (but not having full or possibly any console support) can be the minimal. Is that a reasonable assumption? On Thu, Jun 14, 2018 at 9:42 PM, Joel Sherrill wrote: > > > On Thu, Jun 14, 2018, 6:08 PM Amaan Cheval wrote: >> >> Thanks for

Re: [GSoC - x86_64] Using FreeBSD's UEFI loader for RTEMS static binaries

Thanks for your input, everyone! I appreciate it! :) On Thu, Jun 14, 2018 at 11:25 AM, Chris Johns wrote: > On 14/06/2018 05:33, Joel Sherrill wrote: >> On Wed, Jun 13, 2018, 6:57 PM Amaan Cheval > <mailto:amaan.che...@gmail.com>> wrote: >> >> On Wed, Jun

Re: [GSoC - x86_64] Using FreeBSD's UEFI loader for RTEMS static binaries

On Wed, Jun 13, 2018 at 9:35 PM, Gedare Bloom wrote: > On Wed, Jun 13, 2018 at 11:33 AM, Amaan Cheval wrote: >> Hi! >> >> As we discussed in the last thread on the topic[1], I'm trying to use >> FreeBSD's loader.efi directly with RTEMS' generated static binaries >

[GSoC - x86_64] Using FreeBSD's UEFI loader for RTEMS static binaries

Hi! As we discussed in the last thread on the topic[1], I'm trying to use FreeBSD's loader.efi directly with RTEMS' generated static binaries (since FreeBSD's loader.efi has an ELF loader). In brief, I did this by: - Installing FreeBSD in QEMU with UEFI firmware - Confirming that FreeBSD's

Re: [PATCH] x86_64/binutils: Add PEI target to build UEFI application images

Bump :) On Tue, Jun 5, 2018 at 10:54 PM Amaan Cheval wrote: > > Original commit in binutils: > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=421acf18739edb54111b64d2b328ea2e7bf19889 > > Update #2898 > --- > rtems/config/5/rtems-x86_64.bset | 5 +

Re: [GSoC - x86_64 BSP] Using fPIC to compile RTEMS as a shared library

Minor update: I'll work on Chris' suggestion of using FreeBSD's loader.efi and having that load our static hello.exe - it ought to be a quicker test that way. On Sun, Jun 10, 2018 at 9:34 PM Amaan Cheval wrote: > > On Sun, Jun 10, 2018 at 12:38 AM Joel Sherrill wrote: > > > > &

Re: [GSoC - x86_64 BSP] Using fPIC to compile RTEMS as a shared library

On Sun, Jun 10, 2018 at 12:38 AM Joel Sherrill wrote: > > > > On Fri, Jun 8, 2018 at 7:45 PM, Chris Johns wrote: >> >> On 9/6/18 10:00 am, Joel Sherrill wrote: >> > On Thu, Jun 7, 2018, 9:01 PM Chris Johns > > > wrote: >> > > and what >> > > discussions we need

Re: [GSoC - x86_64 BSP] Using fPIC to compile RTEMS as a shared library

On Sat, Jun 9, 2018 at 5:26 AM Chris Johns wrote: > > On 9/6/18 2:39 am, Amaan Cheval wrote: > > On Fri, Jun 8, 2018 at 7:31 AM, Chris Johns wrote: > >> On 08/06/2018 01:50, Amaan Cheval wrote: > >>> > >>> Joel, Chris, I'd appreciate guidance on w

Re: [GSoC - x86_64 BSP] Using fPIC to compile RTEMS as a shared library

On Fri, Jun 8, 2018 at 7:31 AM, Chris Johns wrote: > On 08/06/2018 01:50, Amaan Cheval wrote: >> >> Joel, Chris, I'd appreciate guidance on what I ought to work on next > > I would like to see the focus on the kernel context switcher, FPU support, and > then interru

Re: [GSoC - x86_64 BSP] Using fPIC to compile RTEMS as a shared library

at 2:30 PM, Amaan Cheval wrote: > I don't know yet, but I'll look into it. I'll pause the "hello.efi" approach > work until we settle on a direction, yes? For now, primarily improving the > stub, looking into the FreeBSD ld-elf.so, etc. Sound good? > > On Wed, Jun 6, 2018, 1

Re: [GSoC - x86_64 BSP] Using fPIC to compile RTEMS as a shared library

I don't know yet, but I'll look into it. I'll pause the "hello.efi" approach work until we settle on a direction, yes? For now, primarily improving the stub, looking into the FreeBSD ld-elf.so, etc. Sound good? On Wed, Jun 6, 2018, 1:01 PM Chris Johns wrote: > On 6/6/18 5:22 pm,

Re: [GSoC - x86_64 BSP] Using fPIC to compile RTEMS as a shared library

On Wed, Jun 6, 2018 at 12:45 PM, Chris Johns wrote: > On 6/6/18 5:06 pm, Amaan Cheval wrote: >> On Wed, Jun 6, 2018 at 6:55 AM, Chris Johns wrote: >>> On 4/6/18 7:49 pm, Amaan Cheval wrote: >>>> Please let me know if that approach doesn't make sense - given that &

Re: [GSoC - x86_64 BSP] Using fPIC to compile RTEMS as a shared library

On Wed, Jun 6, 2018 at 6:55 AM, Chris Johns wrote: > On 4/6/18 7:49 pm, Amaan Cheval wrote: >> Please let me know if that approach doesn't make sense - given that >> there is no dynamic loader in the RTEMS kernel as far as I know, > > There is a dynamic loader

Re: [GSoC - x86_64 BSP] Using fPIC to compile RTEMS as a shared library

workaround, and the approach for the GCC patch so far). On Mon, Jun 4, 2018 at 6:42 PM, Joel Sherrill wrote: > > > On Mon, Jun 4, 2018 at 5:44 AM, Sebastian Huber > wrote: >> >> >> >> - Am 4. Jun 2018 um 12:20 schrieb Amaan Cheval amaan.che...@gmail.com: >> >

[PATCH] x86_64/binutils: Add PEI target to build UEFI application images

Original commit in binutils: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=421acf18739edb54111b64d2b328ea2e7bf19889 Update #2898 --- rtems/config/5/rtems-x86_64.bset | 5 + 1 file changed, 5 insertions(+) diff --git a/rtems/config/5/rtems-x86_64.bset

Re: [GSoC - x86_64 BSP] Using fPIC to compile RTEMS as a shared library

That's a good idea. That way based on the multilib variant, Newlib would be compiled using fPIC, yes? Then I could simply figure out how to solve the crtbegin and crtend dilemma (which I believe should be easier), and use those to have a dynamic/shared RTEMS kernel + user application. If that

[GSoC - x86_64 BSP] Using fPIC to compile RTEMS as a shared library

Hi! I figured I'd quickly confirm the direction I'm taking towards compiling RTEMS as a dynamic/shared library. Problems I've run into in setting up amd64.cfg to compile all of RTEMS as a shared library: - In the x86_64 tools, gcc's "-shared" flag has a different effect than the "-Wl,-shared"

Re: [PATCH] Updating trace buffer configuration

On Wed, May 30, 2018 at 6:33 PM, Vidushi Vashishth wrote: > Could you please change the > > struct _Thread_Control > > to > > Thread_Control > > and check if it still works. > > In RTEMS, we use typedefs for structures in general. > > I tried to include the threadq.h header file so that I could

Re: [GSoC] Ways to make the x86_64 port work with UEFI

On Wed, May 30, 2018 at 4:30 AM, Joel Sherrill wrote: > > > On Tue, May 29, 2018 at 11:26 AM, Amaan Cheval > wrote: >> >> On Tue, May 29, 2018 at 9:28 PM, Amaan Cheval >> wrote: >> > Noted, thanks a ton for the details! Unrelated to the topic at hand, >

Re: [GSoC] Ways to make the x86_64 port work with UEFI

On Tue, May 29, 2018 at 9:28 PM, Amaan Cheval wrote: > Noted, thanks a ton for the details! Unrelated to the topic at hand, > but out of interest, is this the only reading material for further > details? http://ceur-ws.org/Vol-1697/EWiLi16_12.pdf > > In brief: My tests for keep

Re: [GSoC] Ways to make the x86_64 port work with UEFI

s/ - https://eli.thegreenplace.net/2012/01/03/understanding-the-x64-code-models Sorry about the length of the email! On Fri, May 25, 2018 at 10:51 PM, Joel Sherrill wrote: > > > On Fri, May 25, 2018, 12:11 PM Amaan Cheval wrote: >> >> Hey! Could you link me to some code that you used for

Re: [GSoC] Ways to make the x86_64 port work with UEFI

n Fri, May 25, 2018 at 10:13 PM, Joel Sherrill <j...@rtems.org> wrote: > > > On Fri, May 25, 2018, 11:15 AM Amaan Cheval <amaan.che...@gmail.com> wrote: >> >> Hey! >> >> Skippable

Re: [GSoC] Ways to make the x86_64 port work with UEFI

38e3a0349f9f89f9d54594172c75b002b74/stand/common/boot.c#L107 [5] https://github.com/freebsd/freebsd/blob/d8596f6f687a64b994b065f3058155405dfc39db/stand/efi/loader/arch/amd64/elf64_freebsd.c#L93 On Sun, May 20, 2018 at 10:52 PM, Joel Sherrill <j...@rtems.org> wrote: > > > On S

Re: Compiler error with U_FORTIFY_SOURCE, D_FORTIFY_SOURCE options

Hi! I don't know the specifics of the thing you're talking about here, so others should definitely weigh in on that if they can, but regarding the header file; the include syntax used (, as opposed to "ssp.h") is the one used for system header files (for eg. vs "my_header.h"). I see 2

Re: [GSoC] Ways to make the x86_64 port work with UEFI

On Sat, May 19, 2018 at 6:51 PM, Gedare Bloom <ged...@rtems.org> wrote: > On Fri, May 18, 2018 at 5:53 PM, Joel Sherrill <j...@rtems.org> wrote: >> >> >> On Fri, May 18, 2018 at 3:24 PM, Amaan Cheval <amaan.che...@gmail.com> >> wrote: >>> &

Re: [PATCH] Rework to minimize and eventually eliminate RTEMS use of bsp_specs

May 18, 2018 at 7:00 PM, Joel Sherrill <j...@rtems.org> wrote: > > > > On Fri, May 18, 2018 at 1:38 AM, Amaan Cheval <amaan.che...@gmail.com> > wrote: >> >> I just compiled my local fixed copy (adding rtems.h back in) and >> there's good news! Wit

  1   2   >