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

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 hardware

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 Dubey

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/MAINTAINER

[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, 1:2

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: >

Re: x86_64 gcc missing crti/n

t; --joel > ___ > 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:

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, Newli

[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/b2de4260c5c71e

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 http:

[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 4/5] bsps/x86_64: Add support for RTEMS interrupts

/amd64/interrupts/idt.c @@ -0,0 +1,151 @@ +/* + * 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 of source code must retain the

[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 b/bsps/x86_64/amd6

[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 s

[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

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

en 1 second has 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/clo

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

n, Aug 12, 2018 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 > c

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

tches tomorrow or Monday hopefully. I'll be traveling Tuesday, so I'd appreciate if we can get them merged upstream Monday itself - I'm okay to have a call and walk someone through the patches and whatnot if need be. Cheers! On Sun, Aug 12, 2018 at 1:25 AM, Amaan Cheval wrote: > Hi

[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 to

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

t; I will 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

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

rely after GSoC 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/ a

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

reviews! :) On Thu, Aug 9, 2018 at 8:12 PM, 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 outpu

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 busy on Monday, so I'd really prefer to 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

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

edare 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 never starts ticking away, so when calibrating >> with the PIT, and later starting the APIC timer to genera

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

ntributors to pick it up too, if any are interested. On Tue, Aug 7, 2018 at 6:03 AM, 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:

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

d. On Wed, Aug 1, 2018 at 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 excer

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

dress 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! > > Wh

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

lled, 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,

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

Would you happen 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 defin

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

7;ll likely figure it out given enough time, so if the answers aren't at the top of your head, 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

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

t; > On Tue, Jul 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/interrup

[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 sour

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

sical 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 3

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

retty nice and self-contained 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: >>> >&

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 generali

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?

wrote: > > > 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 throug

[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 as

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

- it's likely easier 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

[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

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

others 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 succe

[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 +++ .../s

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

..b272b679d7 --- /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: +

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

ciate someone keeping an eye out for any that may be out of place or should simply be tickets 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: Minima

Re: [GSoC - x86_64] Minimal BSP to review

at 6:31 AM, Gedare Bloom 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 >> Gith

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

ingly? 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 m

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

On Sat, May 19, 2018 at 3:17 AM, Joel Sherrill wrote: > Thanks. I will try to deal with this Monday. > > My specs patches are not ready to push to gcc so I need to focus on > just the parts to make x86_64 right. > > On Fri, May 18, 2018 at 3:41 PM, Amaan Cheval > wrote: >

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 can

[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 thi

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

8 at 7:06 AM, Chris Johns 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 >>> co

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

Done, thanks for the feedback! On Tue, Jul 3, 2018 at 2:46 PM, Sebastian Huber wrote: > On 03/07/18 11:01, Amaan Cheval wrote: >> >> - Rebase with master and fix misc. issues that cropped up (commit - >> >> https://github.com/AmaanC/rtems-gsoc18/commit/a28badd8df190

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 work

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 https://git

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

mage that reads loader.conf and loads loader.efi). https://i.imgur.com/oINwNhO.png I'll bench this for now since I don't think it'll be a problem - I believe our tests can ignore extra output outside of the actual test region, yes? On Fri, Jun 29, 2018 at 6:09 AM, Chris Johns wrote: >

Re: [GSoC - x86_64] Console / serial communication

onsole to 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: > >

Re: [GSoC - x86_64] Console / serial communication

Since we skipped our meeting today, here's a quick screengrab of UART working with -serial stdio on QEMU (just inb/outb instructions directly, without termios or ns16550): https://i.imgur.com/tumtD3Z.png On Wed, Jun 27, 2018 at 10:56 AM, Amaan Cheval wrote: > Brilliant, thank you for t

Re: [GSoC - x86_64] Console / serial communication

Brilliant, thank you for the quick response and clarification! On Wed, Jun 27, 2018 at 10:51 AM, Sebastian Huber wrote: > On 27/06/18 06:59, Amaan Cheval wrote: >> >> Quick question since the BSP guide is outdated - I see several >> "methods" of RTEMS' conso

Re: [GSoC - x86_64] Console / serial communication

SP? 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 of

[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 w

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 u

[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 fun

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

ACPI 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 whatnot

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

of booting, 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: >> >>

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 stat

[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 loader

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 to

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

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 in

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

ed, Jun 6, 2018 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? &g

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

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 t

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 in RTE

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

t you think (about the LDFLAGS 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 Che

[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 b/rtems/config/

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 sou

[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" fl

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 us

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, >

  1   2   >