TUD-OS / NRE

NOVA runtime environment (official branch)
GNU General Public License v2.0
33 stars 12 forks source link

Error during Cross Compile Build #47

Closed lonnietc closed 3 years ago

lonnietc commented 3 years ago

Hi All,

I know that a lot of this code and build process may be a bit dated, but I think that I want to use NRE instead of trying to get NUL to work and ported over to x86_64 based.

Optimally, I would like to build the NRE set and run against the latest NOVE hypervisor (), and am not sure where the Github for NOVA is being called in this Repo.

I have an Ubuntu 20.04 system and would like to build up a small ISO demo with NRE, but as you might expect, given the age of the repo, I have gotten some errors already just in locating of off-site files.


:~/NRE-test/test/cross$ ./build.sh x86_64 Downloading binutils, gcc and newlib... --2021-06-29 15:15:06-- http://ftp.gnu.org/gnu/binutils/binutils-2.23.2.tar.bz2 Resolving ftp.gnu.org (ftp.gnu.org)... 2001:470:142:3::b, 209.51.188.20 Connecting to ftp.gnu.org (ftp.gnu.org)|2001:470:142:3::b|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 21440347 (20M) [application/x-bzip2] Saving to: ‘binutils-2.23.2.tar.bz2’

binutils-2.23.2.tar.bz2 100%[===================================================================================>] 20.45M 5.76MB/s in 3.6s

2021-06-29 15:15:10 (5.76 MB/s) - ‘binutils-2.23.2.tar.bz2’ saved [21440347/21440347]

--2021-06-29 15:15:10-- http://ftp.gnu.org/gnu/gcc/gcc-4.8.1/gcc-4.8.1.tar.bz2 Resolving ftp.gnu.org (ftp.gnu.org)... 2001:470:142:3::b, 209.51.188.20 Connecting to ftp.gnu.org (ftp.gnu.org)|2001:470:142:3::b|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 86753166 (83M) [application/x-bzip2] Saving to: ‘gcc-4.8.1.tar.bz2’

gcc-4.8.1.tar.bz2 100%[===================================================================================>] 82.73M 3.70MB/s in 26s

2021-06-29 15:15:36 (3.13 MB/s) - ‘gcc-4.8.1.tar.bz2’ saved [86753166/86753166]

--2021-06-29 15:15:36-- ftp://sources.redhat.com/pub/newlib/newlib-1.20.0.tar.gz => ‘newlib-1.20.0.tar.gz’ Resolving sources.redhat.com (sources.redhat.com)... 209.132.183.64 Connecting to sources.redhat.com (sources.redhat.com)|209.132.183.64|:21... connected. Logging in as anonymous ... Login incorrect.

I actually have GCC "gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)" already installed and would like to see if everything could be compiled with the latest versions of things.

On a side question, is the "Cross-Compiling" required.

Still new to everything and am learning as I go, here. Cheers, Lonnie

Nils-TUD commented 3 years ago

Hi,

I just had a few minutes and tried to build it myself again. There were indeed a couple of issues, which are - at least on my machine - fixed now. Please try the latest commit again.

However, at least for me, VBE seems to be still broken. Maybe that's a BIOS issue? Unfortunately, my QEMU version does not let me choose a different BIOS either. Not sure how to fix that :/

Optimally, I would like to build the NRE set and run against the latest NOVE hypervisor (), and am not sure where the Github for NOVA is being called in this Repo.

You can just update the submodule in kernel/nova to a different version and try to get it working.

On a side question, is the "Cross-Compiling" required.

It's not strictly required, but it simplifies a few things, in particular when using C++ exceptions and dynamic linking (not supported yet, but I was planning for it :)).

lonnietc commented 3 years ago

Thanks Nils, I will download the new version and give it a try,

In step 2, did you use (a) or (b) in your testing?

a) If you want to download a precompiled cross-compiler, execute download.sh , where is either x86_32 or x86_64. It will download the compiler into /opt/nre-cross-. There are only precompiled versions for certain host platforms, of course.

b) Otherwise, execute build.sh , where is either x86_32 or x86_64. This builds the cross compiler. Thus, it will take a few minutes :)

Please list your ISO generation and build steps so that I can do the exact same tests here.

If you let me know what they are then I will see if I can replicate your exact output here to let you know what works, or not, for me.

Truly appreciate your help and Thanks again, Lonnie

Nils-TUD commented 3 years ago

I used (b) with x86_64. Not sure whether the precompiled cross compilers still work on todays systems. I guess not.

You can otherwise just follow the README.

lonnietc commented 3 years ago

Thanks.

Will give it a try here in just a little while and let you know.

lonnietc commented 3 years ago

I was able to just try it out and have a problem when it tries to build gcc 4.8.1:


checking for the correct version of gmp.h... no configure: error: Building GCC requires GMP 4.2+, MPFR 2.4.0+ and MPC 0.8.0+. Try the --with-gmp, --with-mpfr and/or --with-mpc options to specify their locations. Source code for these libraries can be found at their respective hosting sites as well as at ftp://gcc.gnu.org/pub/gcc/infrastructure/. See also http://gcc.gnu.org/install/prerequisites.html for additional info. If you obtained GMP, MPFR and/or MPC from a vendor distribution package, make sure that you have installed both the libraries and the header files. They may be located in separate packages.

Did you have to install GMP 4.2+, MPFR 2.4.0+ and MPC 0.8.0+?

Or, is it disabled in the "build.sh" script?

Please forgive me being a bit slow on this, but I am not clear as to why you are using these older apps for building NOVA+NRE.

The current version of gcc is 9 but you are requiring to use gcc 4.8.1.

I'm just not clear on this part.

You did mention that you are not really working on this project a lot now days which is my guess as to why the older gcc, binutils, etc. but could be wrong.

Cheers

Nils-TUD commented 3 years ago

Did you have to install GMP 4.2+, MPFR 2.4.0+ and MPC 0.8.0+?

In a sense, yes. They were already installed on my system, therefore I didn't think of mentioning this in my earlier post. And you can use their latest version, btw.

Please forgive me being a bit slow on this, but I am not clear as to why you are using these older apps for building NOVA+NRE.

The current version of gcc is 9 but you are requiring to use gcc 4.8.1.

I'm just not clear on this part.

You did mention that you are not really working on this project a lot now days which is my guess as to why the older gcc, binutils, etc. but could be wrong.

Yes, that's the only reason. But with the recent changes, building the old gcc and binutils should be fine. I built it with gcc 11.1.

lonnietc commented 3 years ago

I was able to get the dependencies installed for GMP 4.2+, MPFR 2.4.0+ and MPC 0.8.0+

But, alas I ran into some redefinition errors in the compiling of "expect.c" from gcc


g++ -c -DIN_GCC_FRONTEND -O2 -std=c++11 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -Icp -I/home/lonnie/NRE-test/test/cross/x86_64/src/gcc/gcc -I/home/lonnie/NRE-test/test/cross/x86_64/src/gcc/gcc/cp -I/home/lonnie/NRE-test/test/cross/x86_64/src/gcc/gcc/../include -I/home/lonnie/NRE-test/test/cross/x86_64/src/gcc/gcc/../libcpp/include -I/home/lonnie/NRE-test/test/cross/x86_64/src/gcc/gcc/../libdecnumber -I/home/lonnie/NRE-test/test/cross/x86_64/src/gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/home/lonnie/NRE-test/test/cross/x86_64/src/gcc/gcc/../libbacktrace /home/lonnie/NRE-test/test/cross/x86_64/src/gcc/gcc/cp/except.c -o cp/except.o In file included from ./tm.h:21, from /home/lonnie/NRE-test/test/cross/x86_64/src/gcc/gcc/cp/except.c:27: /home/lonnie/NRE-test/test/cross/x86_64/src/gcc/gcc/config/elfos.h:102:21: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix] 102 | fprintf ((FILE), "%s"HOST_WIDE_INT_PRINT_UNSIGNED"\n",\ | ^ /home/lonnie/NRE-test/test/cross/x86_64/src/gcc/gcc/config/elfos.h:170:24: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix] 170 | fprintf ((FILE), ","HOST_WIDE_INT_PRINT_UNSIGNED",%u\n", \ | ^ In file included from ./tm.h:30, from /home/lonnie/NRE-test/test/cross/x86_64/src/gcc/gcc/cp/except.c:27: /home/lonnie/NRE-test/test/cross/x86_64/src/gcc/gcc/defaults.h:126:24: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix] 126 | fprintf ((FILE), ","HOST_WIDE_INT_PRINT_UNSIGNED",%u\n", \ | ^ In file included from /home/lonnie/NRE-test/test/cross/x86_64/src/gcc/gcc/cp/except.c:1005: cfns.gperf:101:1: error: ‘const char libc_name_p(const char, unsigned int)’ redeclared inline with ‘gnu_inline’ attribute cfns.gperf:26:14: note: ‘const char libc_name_p(const char, unsigned int)’ previously declared here cfns.gperf:26:14: warning: inline function ‘const char libc_name_p(const char, unsigned int)’ used but never defined make[1]: [Makefile:1058: cp/except.o] Error 1 make[1]: Waiting for unfinished jobs.... make[1]: Leaving directory '/home/lonnie/NRE-test/test/cross/x86_64/build/gcc/gcc' make: *** [Makefile:3904: all-gcc] Error 2

Strange in that I have a freshly installed Ubuntu 20.04 (installed from their ISO just for this purpose) and then ran the "./build.sh x86_64" in the nre/cross directory and seem like I cannot get a clean build.

I can go in and edit the expect.c file to comment out the inline definition, if needed to make it work. Cheers,

lonnietc commented 3 years ago

Also, sorry about the large bold in the posting since I just copied and pasted the error messages from a terminal and they show up that way for some reason.

Nils-TUD commented 3 years ago

Oh, sorry, I just saw that I forgot to commit one patch. Please try again (you have to rebuild it to let build.sh apply the new patch).

lonnietc commented 3 years ago

Making progress now it seems.

Was able to complete the gcc, binutils, etc. build and then went into the "nre" directory at which time I did "./b" to build all, but now have an error in that part:


CXX build/x86_64-debug/apps/vmmng/VMConfig.o CXX build/x86_64-debug/apps/vmmng/VMMngService.o CXX build/x86_64-debug/apps/vmmng/vmmng.o LD build/x86_64-debug/apps/unittests/unittests CXX build/x86_64-debug/services/acpi/HostACPI.o CXX build/x86_64-debug/services/acpi/HostATARE.o CXX build/x86_64-debug/services/acpi/acpi.o CXX build/x86_64-debug/services/console/ConsoleService.o In file included from services/console/ConsoleService.h:25:0, from services/console/ConsoleService.cc:19: services/console/VBE.h:19:29: fatal error: nul/motherboard.h: No such file or directory

include <nul/motherboard.h>

                         ^

compilation terminated. scons: *** [build/x86_64-debug/services/console/ConsoleService.o] Error 1 scons: building terminated because of errors.

Cheers

lonnietc commented 3 years ago

Wait a moment as I may have made a mistake on this side.

lonnietc commented 3 years ago

Well, I have had success with getting through the "./b" build.

Then I tried the

./b qemu boot/test

It fires up NOVA+NRE quickly shows that it is 4 CPU's for a few seconds:

Screenshot from 2021-06-30 15-27-35

Then shows the reboot screen:

Screenshot from 2021-06-30 15-27-55

The Serial Terminal shows:

Screenshot from 2021-06-30 15-28-14

lonnietc commented 3 years ago

Is this as far as you got since you did mention some issue with QEMU?

Nils-TUD commented 3 years ago

That looks good, yes.

Yes, I don't know exactly what it is, but the console component should listen to keystrokes like ctrl+0 etc. to switch between different consoles (e.g., when using boot/vmmng). But that doesn't work for some reason. And I also tried it with VirtualBox, but it has the same problem. I haven't looked into it yet, though. Maybe this has nothing to do with VBE or the BIOS, but is a keyboard issue?

lonnietc commented 3 years ago

I have not been able to build the iso yet but just tried it via QEMU.

In the past, I tried the the NUL Userland Demos

http://os.inf.tu-dresden.de/nul/

demo 0.2 ---- http://os.inf.tu-dresden.de/nul/NOVA-0.2.iso.bz2 demo 0.3 --- http://os.inf.tu-dresden.de/nul/NOVA-0.3.iso.bz2 NOVA Xmas Alpha Demo --- http://os.inf.tu-dresden.de/nul/NOVA-Xmas-Alpha.iso

The demo 0.3 seemed to work on some hardware, but I seem to recall someone telling me that I needed to change something for the keyboard to make it work as it would go all of the way through to Tutor but could not do anything. I cannot seem to locate that information but think that it might be important here.

  1. Currently Demo 0.3 not working in QEMU or on native hardware (Think that it is the keyboard problem, as a guess)

  2. The NOVA Xmas Alpha Demo, which is older, does in fact work for me in QEMU (Ubuntu and Windows machines) as well as VirtualBox in both modes shown in the Grub boot.

In the images that I sent, the one thing that interest me, and concerns me also is in the last 3 lines with 2 of them saying that PD terminated on CPU 1 and on CPU 2, but then again I do not know if that is also expected behavior.

Cheers, Lonnie

Nils-TUD commented 3 years ago

Ok, I've found it. All my guesses were completely wrong. The problem was in NOVA's IOAPIC handling, so that interrupts were not working and everything got stuck. Fortunately, @alex-ab already fixed it, so I just took his commit :)

lonnietc commented 3 years ago

Awesome since I was just guessing, I will grab the latest from the NRE repo and build up things to test.

lonnietc commented 3 years ago

SUCCESS (on booting and console) !!!!

I was able to boot up the build and have a single console that I can cycle through:

Keybindings:

ctrl + left/right: switch between consoles ctrl + up/down: switch between subconsoles ctrl + 0..9: switch to console 0..9. You can also use esc to get to console 0 ctrl + end: reboot the host-machine

Hypervisor Boot Screen (1): Booted up wonderfully

Screenshot from 2021-07-01 07-57-08

SysInfo Screen (2): Using

Screenshot from 2021-07-01 07-57-42

could not initiate any other screens and applications may not be installed yet since I am not sure what all if fired up with the:

./b quemu boot/test

Now, I want dig into the script to have it create a full iso with your scripts that will probably include some NRE applications. If we can get that to work then it seems that your NRE repository will be exactly what I am seeking and I can dig into really trying to pull some components together while also learning from the AWESOME work that you, Alex, Julian, Udo, and the others from TUD-OS Group have done.

This is GREAT.....

I truly appreciate all of your help and efforts to get this working.

Cheers

Nils-TUD commented 3 years ago

That's great to hear :)

lonnietc commented 3 years ago

Hi Nils,

I was just wondering if the fix from @alexb had already been pushed up to Udo since I think that it would be NOVA wide?

https://github.com/TUD-OS/NRE/issues/47#issuecomment-872035850

Udo NOVA:

https://github.com/udosteinberg/NOVA

If not, then how can I grab that commit so that I can have a patch file to look into applying it to the latest NOVA when I start upgrading to that version.

This part of doing push/pulls is a bit new to me.

Cheers and have a great day.

Nils-TUD commented 3 years ago

No, I didn't push that to Udo's repo. I'm also not sure whether it's still relevant for the current version there.

It is pushed to the NOVA fork that NRE uses, though. You could either check the source when upgrading to the newer NOVA version to see whether it has the same issue or just try whether interrupts are working correctly. However, I guess that Udo also fixed the issue at some point, so probably you don't have to worry about that.

lonnietc commented 3 years ago

Thanks and I will keep that in mind when I get to that point, which might be a while since there is still much more higher priority items on the list now.