Re: x86_64 BSP as GSOC2016 project
On Feb 9, 2016 10:37 PM, "Saket Sinha" wrote: > > Hi Joel, > > Thanks for your inputs. > > > > On Wed, Feb 10, 2016 at 1:06 AM, Joel Sherrill wrote: > > > > > > On Tue, Feb 9, 2016 at 12:08 PM, Saket Sinha > > wrote: > >> > >> Hi, > >> > >> I think this is early for this but I need to enquire if x86_64_BSP ( > >> https://devel.rtems.org/wiki/Developer/Projects/Open/x86_64_BSP ) > >> could be taken as a GSOC project this year. > >> > > > > Yes. Assuming you mean the x86_64 bit port and accompanying BSP. > > > > If you noticed my post yesterday, we have tripped across a new embedded PC > > without legacy PCI BIOS support. > > > > Could you provide the link. I am not able to locate it on mailing list > or your blog. I only posted a question this week had anyone attempted to use RTEMS on a PC without legacy BIOS. I think the answer is no. I have done a little searching for how to use the newer UEFI services to replace those we use the video and PCI but so far have only found high level information. Sorry. This one is a known need with only early research. I was going to dig into the FreeBSD source next. > > Beyond the obvious port, for the purposes of your effort, there are > > a couple of bugs and some modernization needed by the pc386 BSP which > > you will likely have to address. > > > > + PCI BIOS uses legacy support. Needs to support new and old for 32-bit > > and new only for 64 bit. > > + Better APIC support. pc386 uses legacy PIC and some LPIC for SMP. > > Probably Ok for both 32 and 64 bit to support APIC only. > > + i386 does not have Thread Local Support. Both should have it. > > + i386 has a ticket for SMP synchronization during context switch. > > The code does not use atomics. Should be fixed and x86_64 follow the > > correct pattern. > > > > So now my question is that could these be solved on an emulator like > qemu-x86, atleast for an initial POC ? > I mean is a x86_64 hardware required for it( though I have a Minnowmax board.) > I think qemu can be used for all of this. You can certainly do the APIC support without addressing the legacy video and PCI BIOS. Similar for the TLS and SMP issue. I believe the entire thing could be brought up and debugged on qemu with checkouts on real HW. Either the Minnow or even a desktop PC with the right BIOS settings. None of this is particularly new. APIC dates back at least a decade. > > > Basically x86_64 should assume a modern (non-legacy) PC and pc386 > > needs updating to support newer systems. Common hardware platform > > so hopefully the software is standard. > > > > I was going to write this up as a "PC386 Modernization" Project but some > > of it makes sense as a side-effect of your project. That project idea also > > included killing AT bus NICs which you wouldn't have any reason to get > > near. > > > > You need a subtask list (e.g. todo list) and we need to help you flesh it > > out. I only hit a few non-obvious highlights. > > > > Let me know how to dig deeper on this. Looking at the code, right but > than exactly what sections ? > libbsp/shared/i386/pci is the current legacy PCI code. The IRQ code should also be under shared. I will have to feel to see where the video probe that is failing is located. The nice thing is that each of these three can be completed in the context of the current BSP. > Regards, > Saket Sinha ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Python problem
On Tue, Feb 9, 2016 at 8:21 PM, Joel Sherrill wrote: > > > On Tue, Feb 9, 2016 at 8:15 AM, punit vara wrote: >> >> On Tue, Feb 9, 2016 at 6:56 PM, Aun-Ali Zaidi wrote: >> > Hi, >> > >> > I was having the same problem yesterday and managed to find a fix by >> > installing libpython2.7-dev: >> > >> > sudo apt-get install libpython2.7-dev >> > >> > Aun-Ali Zaidi >> > >> >> Thanks Aun-Ali. I have tried but again I am getting same error. >> Because this package would get installed when you install >> python2.7-dev > > > Can you look in the config.log for gdb where the failure occurred? Or even > at the configure.in/ac script in its source. It is looking for a very > specific > file to link against and failing. > > yum have a "provides" subcommand to search for which package provides > a specific file. Apt must have a similar capability. > > So you can figure out the file gdb needs to link and the corresponding > package which includes it. > > --joel > >> >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel > > Yes I agree with you Joel. From line 129 I found errors if you can help me out. Perhaps somebody can help me I am attaching config.log file from /home/punit/development/rtems/src/rtems-source-builder/rtems/build/arm-rtems4.12-gdb-7.9-x86_64-linux-gnu-1/build This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by configure, which was generated by GNU Autoconf 2.64. Invocation command line was $ ../gdb-7.9/configure --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=arm-rtems4.12 --verbose --disable-nls --without-included-gettext --disable-win32-registry --disable-werror --enable-sim --without-zlib --with-expat --with-python --prefix=/home/punit/development/rtems/4.12 --bindir=/home/punit/development/rtems/4.12/bin --exec-prefix=/home/punit/development/rtems/4.12 --includedir=/home/punit/development/rtems/4.12/include --libdir=/home/punit/development/rtems/4.12/lib --mandir=/home/punit/development/rtems/4.12/share/man --infodir=/home/punit/development/rtems/4.12/share/info ## - ## ## Platform. ## ## - ## hostname = punit-Compaq-420 uname -m = x86_64 uname -r = 4.2.0-27-generic uname -s = Linux uname -v = #32-Ubuntu SMP Fri Jan 22 04:49:08 UTC 2016 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = unknown /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /home/punit/development/rtems/src/rtems-source-builder/source-builder PATH: /home/punit/development/rtems/src/rtems-source-builder/rtems/build/tmp/sb-root-cxc/4.12/rtems-arm/home/punit/development/rtems/4.12/bin PATH: /home/punit/development/rtems/src/rtems-source-builder/rtems/build/tmp/sb-root/4.12/rtems-arm/home/punit/development/rtems/4.12/bin PATH: /usr/local/sbin PATH: /usr/local/bin PATH: /usr/sbin PATH: /usr/bin PATH: /sbin PATH: /bin ## --- ## ## Core tests. ## ## --- ## configure:2326: checking build system type configure:2340: result: x86_64-pc-linux-gnu configure:2387: checking host system type configure:2400: result: x86_64-pc-linux-gnu configure:2420: checking target system type configure:2433: result: arm-unknown-rtems4.12 configure:2487: checking for a BSD-compatible install configure:2555: result: /usr/bin/install -c configure:2566: checking whether ln works configure:2588: result: yes configure:2592: checking whether ln -s works configure:2596: result: yes configure:2603: checking for a sed that does not truncate output configure:2667: result: /bin/sed configure:2676: checking for gawk configure:2692: found /usr/bin/gawk configure:2703: result: gawk configure:3945: checking for x86_64-linux-gnu-gcc configure:3972: result: /usr/bin/gcc -O2 -pipe -I/home/punit/development/rtems/src/rtems-source-builder/rtems/build/tmp/sb-root/4.12/rtems-arm/home/punit/development/rtems/4.12/include configure:4241: checking for C compiler version configure:4250: /usr/bin/gcc -O2 -pipe -I/home/punit/development/rtems/src/rtems-source-builder/rtems/build/tmp/sb-root/4.12/rtems-arm/home/punit/development/rtems/4.12/include --version >&5 gcc (Ubuntu 5.2.1-22ubuntu2) 5.2.1 20151010 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:4261: $? = 0 configure:4250: /usr/bin/gcc -O2 -pipe -I/home/punit/development/rtems/src/rtems-source-builder/rtems/build/tmp/sb-root/4.12/rtems-arm/home/punit/development/rtems/4.12/include -v >&5 Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v -
Re: Python problem
We need the config.log from the subdirectory where the failure occurred. This looks like one from the top directory, Look at the build log to see what directory the build failed in and grab that one. FWIW a quick google for this issue on Ubuntu showed someone suggested: sudo apt-get install python-dev Have you done that? --joel On Wed, Feb 10, 2016 at 11:50 AM, punit vara wrote: > On Tue, Feb 9, 2016 at 8:21 PM, Joel Sherrill wrote: > > > > > > On Tue, Feb 9, 2016 at 8:15 AM, punit vara wrote: > >> > >> On Tue, Feb 9, 2016 at 6:56 PM, Aun-Ali Zaidi wrote: > >> > Hi, > >> > > >> > I was having the same problem yesterday and managed to find a fix by > >> > installing libpython2.7-dev: > >> > > >> > sudo apt-get install libpython2.7-dev > >> > > >> > Aun-Ali Zaidi > >> > > >> > >> Thanks Aun-Ali. I have tried but again I am getting same error. > >> Because this package would get installed when you install > >> python2.7-dev > > > > > > Can you look in the config.log for gdb where the failure occurred? Or > even > > at the configure.in/ac script in its source. It is looking for a very > > specific > > file to link against and failing. > > > > yum have a "provides" subcommand to search for which package provides > > a specific file. Apt must have a similar capability. > > > > So you can figure out the file gdb needs to link and the corresponding > > package which includes it. > > > > --joel > > > >> > >> ___ > >> devel mailing list > >> devel@rtems.org > >> http://lists.rtems.org/mailman/listinfo/devel > > > > > > Yes I agree with you Joel. From line 129 I found errors if you can > help me out. Perhaps somebody can help me I am attaching config.log > file from > > > /home/punit/development/rtems/src/rtems-source-builder/rtems/build/arm-rtems4.12-gdb-7.9-x86_64-linux-gnu-1/build > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Fwd: [Bug debug/65779] [5 Regression] undefined local symbol on powerpc [regression]
It looks like the PowerPC bug in GCC about local symbols is fixed. Should we bump gcc to a git tag or the next snapshot? Forwarded Message Subject: [Bug debug/65779] [5 Regression] undefined local symbol on powerpc [regression] Date: Wed, 10 Feb 2016 12:57:26 -0600 From: jakub at gcc dot gnu.org To: j...@gcc.gnu.org https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65779 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #20 from Jakub Jelinek --- Fixed. -- You are receiving this mail because: You reported the bug. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Fwd: [Bug debug/65779] [5 Regression] undefined local symbol on powerpc [regression]
On Wed, 2016-02-10 at 13:17 -0600, Joel Sherrill wrote: > It looks like the PowerPC bug in GCC about local symbols is fixed. > > Should we bump gcc to a git tag or the next snapshot? We already have. See https://lists.rtems.org/pipermail/devel/2016-January/013461.html and ht tps://git.rtems.org/rtems-source -builder/commit/?id=e3b9fb68d480a1044d75c4cac09e638ef7483114 > Forwarded Message > Subject: [Bug debug/65779] [5 Regression] undefined local symbol on > powerpc [regression] > Date: Wed, 10 Feb 2016 12:57:26 -0600 > From: jakub at gcc dot gnu.org > To: j...@gcc.gnu.org > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65779 > > Jakub Jelinek changed: > > What|Removed |Added > - > --- > Status|ASSIGNED|RESOLVED > Resolution|--- |FIXED > > --- Comment #20 from Jakub Jelinek --- > Fixed. > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Fwd: [Bug debug/65779] [5 Regression] undefined local symbol on powerpc [regression]
On Wed, Feb 10, 2016 at 6:28 PM, Nick Withers wrote: > On Wed, 2016-02-10 at 13:17 -0600, Joel Sherrill wrote: > > It looks like the PowerPC bug in GCC about local symbols is fixed. > > > > Should we bump gcc to a git tag or the next snapshot? > > We already have. See > https://lists.rtems.org/pipermail/devel/2016-January/013461.html and ht > tps://git.rtems.org/rtems-source > -builder/commit/?id=e3b9fb68d480a1044d75c4cac09e638ef7483114 Awesome! Thanks Nick! I have noticed you have been on top of things. :) > > Forwarded Message > > Subject: [Bug debug/65779] [5 Regression] undefined local symbol on > > powerpc [regression] > > Date: Wed, 10 Feb 2016 12:57:26 -0600 > > From: jakub at gcc dot gnu.org > > To: j...@gcc.gnu.org > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65779 > > > > Jakub Jelinek changed: > > > > What|Removed |Added > > - > > --- > > Status|ASSIGNED|RESOLVED > > Resolution|--- |FIXED > > > > --- Comment #20 from Jakub Jelinek --- > > Fixed. > > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
