Compiler error

[yogeshbio]

Hello Zhiyi huang, I did git clone https://github.com/zhiyihuang/xv6_rpi_port.git

I have my compiler arm-none-eabi- from code sourcery.

When i give $make ARMGNU= <my compiler path/arm-none-eabi>, it gives me this compilation error. Is there any reason for it not to compile?

/xv6_rpi_port# make /home/yk/xv6/arm-2014.05/bin/arm-none-eabi-as -I source/ source/entry.s -o build/entry.o /home/yk/xv6/arm-2014.05/bin/arm-none-eabi-as -I source/ source/exception.s -o build/exception.o gcc -c -fno-pic -static -Wno-packed-bitfield-compat -fno-builtin -fno-strict-aliasing -fshort-wchar -O2 -Wall -MD -ggdb -Werror -fno-omit-frame-pointer -fno-stack-protector -Wa,-march=armv6 -Wa,-mcpu=arm1176jzf-s -I include source/bio.c -o build/bio.o Assembler messages: Fatal error: invalid -march= option: `armv6' make: *\ [build/bio.o] Error 1

Please let me know the steps you used for compilation.?

Did kernel.img successfully build for you?

Regards Yogesh

[zhiyihuang]

Hi, Just use make. If it can't find your compiler, then specify your compiler path in PATH. Hope that helps. Zhiyi

Hello Zhiyi huang, I did git clone https://github.com/zhiyihuang/xv6_rpi_port.git

I have my compiler arm-none-eabi- from code sourcery.

When i give $make ARMGNU= <my compiler path/arm-none-eabi>, it gives me this compilation error. Is there any reason for it not to compile?

/xv6_rpi_port# make /home/yk/xv6/arm-2014.05/bin/arm-none-eabi-as -I source/ source/entry.s -o build/entry.o /home/yk/xv6/arm-2014.05/bin/arm-none-eabi-as -I source/ source/exception.s -o build/exception.o gcc -c -fno-pic -static -Wno-packed-bitfield-compat -fno-builtin -fno-strict-aliasing -fshort-wchar -O2 -Wall -MD -ggdb -Werror -fno-omit-frame-pointer -fno-stack-protector -Wa,-march=armv6 -Wa,-mcpu=arm1176jzf-s -I include source/bio.c -o build/bio.o Assembler messages: Fatal error: invalid -march= option: `armv6' make: *\ [build/bio.o] Error 1

Please let me know the steps you used for compilation.?

Did kernel.img successfully build for you?

Regards Yogesh

---

Reply to this email directly or view it on GitHub: https://github.com/zhiyihuang/xv6_rpi_port/issues/1

[yogeshbio]

i use linux ubuntu and have do not have the compiler installed that is why i mention the compiler path

Also i see that ARMGNU is commented in make file.

I tried uncommenting it and try to build by giving the path , but issue is the same.

Note : it compiles 3 files in build directory (entry.o, exception.o and keyboard.o) , but gives error in bio.c file make /home/yk/xv6/arm-2014.05/bin/arm-none-eabi-as -I source/ source/entry.s -o build/entry.o /home/yk/xv6/arm-2014.05/bin/arm-none-eabi-as -I source/ source/exception.s -o build/exception.o /home/yk/xv6/arm-2014.05/bin/arm-none-eabi-as -I source/ source/keyboard.s -o build/keyboard.o gcc -c -fno-pic -static -Wno-packed-bitfield-compat -fno-builtin -fno-strict-aliasing -fshort-wchar -O2 -Wall -MD -ggdb -Werror -fno-omit-frame-pointer -fno-stack-protector -Wa,-march=armv6 -Wa,-mcpu=arm1176jzf-s -I include source/bio.c -o build/bio.o Assembler messages: Fatal error: invalid -march= option: `armv6' make: *\ [build/bio.o] Error 1

[yogeshbio]

NOw managed to get it past.

You need to specify cc: also in the makefile properly as CC := /home/yk/xv6/arm-2014.05/bin/arm-none-eabi-gcc Where CC points to the actual compiler path. Now it compiles but i get this new error (related to libcsud.a)

/home/yk/xv6/arm-2014.05/bin/arm-none-eabi-ld --no-undefined build/entry.o build/exception.o build/keyboard.o build/bio.o build/console.o build/exec.o build/file.o build/fs.o build/kalloc.o build/log.o build/mailbox.o build/main.o build/memide.o build/mmu.o build/pipe.o build/proc.o build/spinlock.o build/string.o build/syscall.o build/sysfile.o build/sysproc.o build/timer.o build/trap.o build/uart.o build/vm.o -L. -l csud -Map kernel.map -o build/output.elf -T kernel.ld /home/yk/xv6/arm-2014.05/bin/arm-none-eabi-ld: error: ./libcsud.a(keyboard.c.o) uses VFP register arguments, build/output.elf does not /home/yk/xv6/arm-2014.05/bin/arm-none-eabi-ld: warning: ./libcsud.a(keyboard.c.o) uses 32-bit enums yet the output is to use variable-size enums; use of enum values across objects may fail /home/yk/xv6/arm-2014.05/bin/arm-none-eabi-ld: failed to merge target specific data of file ./libcsud.a(keyboard.c.o) /home/yk/xv6/arm-2014.05/bin/arm-none-eabi-ld: error: ./libcsud.a(platform.c.o) uses VFP register arguments, build/output.elf does not /home/yk/xv6/arm-2014.05/bin/arm-none-eabi-ld: warning: ./libcsud.a(platform.c.o) uses 32-bit enums yet the output is to use variable-size enums; use of enum values across objects may fail /home/yk/xv6/arm-2014.05/bin/arm-none-eabi-ld: failed to merge target specific data of file ./libcsud.a(platform.c.o) /home/yk/xv6/arm-2014.05/bin/arm-none-eabi-ld: error: ./libcsud.a(usbd.c.o) uses VFP register arguments, build/output.elf does not /home/yk/xv6/arm-2014.05/bin/arm-none-eabi-ld: warning: ./libcsud.a(usbd.c.o) uses 32-bit enums yet the output is to use variable-size enums; use of enum values across objects may fail

[yogeshbio]

The above gets solved by adding more compiler Flags option as -mfloat-abi=hard. below is the cflags i used. Now it generates kernel.img :-)

CFLAGS := -fno-pic -static -Wno-packed-bitfield-compat -fno-builtin -fno-strict-aliasing -fshort-wchar -O2 -Wall -MD -ggdb -Werror - fno-omit-frame-pointer -fno-stack-protector -mfloat-abi=hard -Wa,-march=armv6 -Wa,-mcpu=arm1176jzf-s -I include

[zhiyihuang]

Great to know you fixed the compilation on Linux:-) I never compiled it on other platforms except Raspberry Pi itself. Zhiyi

The above gets solved by adding more compiler Flags option as -mfloat-abi=hard. below is the cflags i used. Now it generates kernel.img :-)

CFLAGS := -fno-pic -static -Wno-packed-bitfield-compat -fno-builtin -fno-strict-aliasing -fshort-wchar -O2 -Wall -MD -ggdb -Werror - fno-omit-frame-pointer -fno-stack-protector -mfloat-abi=hard -Wa,-march=armv6 -Wa,-mcpu=arm1176jzf-s -I include

---

Reply to this email directly or view it on GitHub: https://github.com/zhiyihuang/xv6_rpi_port/issues/1#issuecomment-59607328

[yogeshbio]

Hello Mr Huang,

I am able to boot raspberry pi board with your xv6 port after generating kernel.img

But I had 2 questions :

Question 1.) I see that init in entry.s file is at address 0x80008000 (kernel.ld) which I think is kernel virtual address ? But during kernel boot, as initially mmu is off, How this kernel virtual address 0x80008000 is getting converted to physical address and how this instruction is getting executed in entry.s ?

Question 2.) In the original xv6 port to raspberry pi https://code.google.com/p/xv6-rpi/ the entry.s is as below

SECTIONS { /* the entry point, before enabling paging. The code to enable paging needs to have the same virtual/physical address. entry.S and start.c run in this initial setting.*/ . = 0x10000;

}

Here they mention that before mmu is enabled the address used is 0x10000.

Any idea why they have mentioned it like this ?

But the kernel.img from this https://code.google.com/p/xv6-rpi/ is not booting on the board , while the kernel.img from your xv6 port is booting on the target :-)

Any explanation you have for this ?

regards Yogesh

[zhiyihuang]

Hi Yogesh,

Question 1: The virtual address 0x80008000 is converted to physical address 0x8000, which is achieved through the page table set in mmu.c. The bootloader loads the kernel at physical address 0x8000 and pass control to the instruction there, basically ip (r15) is set to 0x8000 after bootload.

Question 2: 0x10000 is the location of the first instruction to be executed after bootloading on PC. I don't know much about https://code.google.com/p/xv6-rpi/ as I ported xv6 directly from the MIT xv6 code for PC. I guess the ported code at https://code.google.com/p/xv6-rpi/ is run in QEMU so it can set the location of the first instruction to any place as long as QEMU knows about it.

Hope that helped.

Zhiyi

On 10/21/14, 1:15 AM, yogk wrote:

Hello Mr Huang,

I am able to boot raspberry pi board with your xv6 port after generating kernel.img

But I had 2 questions :

Question 1.) I see that init in entry.s file is at address 0x80008000 (kernel.ld) which I think is kernel virtual address ? But during kernel boot, as initially mmu is off, How this kernel virtual address 0x80008000 is getting converted to physical address and how this instruction is getting executed in entry.s ?

Question 2.) In the original xv6 port to raspberry pi https://code.google.com/p/xv6-rpi/ the entry.s is as below

SECTIONS { /* the entry point, before enabling paging. The code to enable paging needs to have the same virtual/physical address. entry.S and start.c run in this initial setting.*/ . = 0x10000;

}

Here they mention that before mmu is enabled the address used is 0x10000.

Any idea why they have mentioned it like this ?

But the kernel.img from this https://code.google.com/p/xv6-rpi/ is not booting on the board , while the kernel.img from your xv6 port is booting on the target :-)

Any explanation you have for this ?

regards Yogesh

— Reply to this email directly or view it on GitHub https://github.com/zhiyihuang/xv6_rpi_port/issues/1#issuecomment-59741170.

[yogeshbio]

Hello Mr Huang,

thanks for the information. for Question 1.) As you say the virtual address 0x80008000 gets converted to physical address by mmu.c through page table.

But during the time bootloader loads kernel.img, mmu is OFF. So during this time who converts this virtual address 0x80008000 to physical address 0x8000?

I will try to boot the kernel.img by mentioning in kernel.ld the .init at 0x8000 instead of 0x80008000.

As IP(r15) must point to 0x8000 our INIT Section =.init in kernel.ld must also be 0x8000 instead of 0x80008000 as this is the first instruction executed in kernel.

/* * First and formost we need the .init section, containing the code to be run first. We allow room for the ATAGs and stack and conform to * the bootloader's expectation by putting this code at 0x8000. / .init 0x8000 : AT(0x8000) { *(.init) }

Is my understanding correct ?

Regards Yogesh

On Tue, Oct 21, 2014 at 1:40 AM, Zhiyi Huang notifications@github.com wrote:

Hi Yogesh,

Question 1: The virtual address 0x80008000 is converted to physical address 0x8000, which is achieved through the page table set in mmu.c. The bootloader loads the kernel at physical address 0x8000 and pass control to the instruction there, basically ip (r15) is set to 0x8000 after bootload.

Question 2: 0x10000 is the location of the first instruction to be executed after bootloading on PC. I don't know much about https://code.google.com/p/xv6-rpi/ as I ported xv6 directly from the MIT xv6 code for PC. I guess the ported code at https://code.google.com/p/xv6-rpi/ is run in QEMU so it can set the location of the first instruction to any place as long as QEMU knows about it.

Hope that helped.

Zhiyi

On 10/21/14, 1:15 AM, yogk wrote:

Hello Mr Huang,

I am able to boot raspberry pi board with your xv6 port after generating kernel.img

But I had 2 questions :

Question 1.) I see that init in entry.s file is at address 0x80008000 (kernel.ld) which I think is kernel virtual address ? But during kernel boot, as initially mmu is off, How this kernel virtual address 0x80008000 is getting converted to physical address and how this instruction is getting executed in entry.s ?

Question 2.) In the original xv6 port to raspberry pi https://code.google.com/p/xv6-rpi/ the entry.s is as below

SECTIONS { /* the entry point, before enabling paging. The code to enable paging needs to have the same virtual/physical address. entry.S and start.c run in this initial setting.*/ . = 0x10000;

}

Here they mention that before mmu is enabled the address used is 0x10000.

Any idea why they have mentioned it like this ?

But the kernel.img from this https://code.google.com/p/xv6-rpi/ is not booting on the board , while the kernel.img from your xv6 port is booting on the target :-)

Any explanation you have for this ?

regards Yogesh

— Reply to this email directly or view it on GitHub < https://github.com/zhiyihuang/xv6_rpi_port/issues/1#issuecomment-59741170 .

— Reply to this email directly or view it on GitHub https://github.com/zhiyihuang/xv6_rpi_port/issues/1#issuecomment-59831371 .

[zhiyihuang]

Hi Yogesh, Sorry for the late reply as I was marking exams these days.

On 10/22/14, 1:05 AM, yogk wrote:

Hello Mr Huang,

thanks for the information. for Question 1.) As you say the virtual address 0x80008000 gets converted to physical address by mmu.c through page table. Yes.

But during the time bootloader loads kernel.img, mmu is OFF. So during this time who converts this virtual address 0x80008000 to physical address 0x8000?

After booloading, physical addresses are used and the image is loaded at 0x8000. So the entry code of the image assumes physical addresses but quickly enable MMU after a stack space is set.

I will try to boot the kernel.img by mentioning in kernel.ld the .init at 0x8000 instead of 0x80008000.

As IP(r15) must point to 0x8000 our INIT Section =.init in kernel.ld must also be 0x8000 instead of 0x80008000 as this is the first instruction executed in kernel.

Yes. It is done by the bootloader.

/* * First and formost we need the .init section, containing the code to be run first. We allow room for the ATAGs and stack and conform to * the bootloader's expectation by putting this code at 0x8000. / .init 0x8000 : AT(0x8000) { *(.init) }

I don't quite understand your question here.

Zhiyi

Is my understanding correct ?

Regards Yogesh

On Tue, Oct 21, 2014 at 1:40 AM, Zhiyi Huang notifications@github.com wrote:

Hi Yogesh,

Question 1: The virtual address 0x80008000 is converted to physical address 0x8000, which is achieved through the page table set in mmu.c. The bootloader loads the kernel at physical address 0x8000 and pass control to the instruction there, basically ip (r15) is set to 0x8000 after bootload.

Question 2: 0x10000 is the location of the first instruction to be executed after bootloading on PC. I don't know much about https://code.google.com/p/xv6-rpi/ as I ported xv6 directly from the MIT xv6 code for PC. I guess the ported code at https://code.google.com/p/xv6-rpi/ is run in QEMU so it can set the location of the first instruction to any place as long as QEMU knows about it.

Hope that helped.

Zhiyi

On 10/21/14, 1:15 AM, yogk wrote:

Hello Mr Huang,

I am able to boot raspberry pi board with your xv6 port after generating kernel.img

But I had 2 questions :

Question 1.) I see that init in entry.s file is at address 0x80008000 (kernel.ld) which I think is kernel virtual address ? But during kernel boot, as initially mmu is off, How this kernel virtual address 0x80008000 is getting converted to physical address and how this instruction is getting executed in entry.s ?

Question 2.) In the original xv6 port to raspberry pi https://code.google.com/p/xv6-rpi/ the entry.s is as below

SECTIONS { /* the entry point, before enabling paging. The code to enable paging needs to have the same virtual/physical address. entry.S and start.c run in this initial setting.*/ . = 0x10000;

}

Here they mention that before mmu is enabled the address used is 0x10000.

Any idea why they have mentioned it like this ?

But the kernel.img from this https://code.google.com/p/xv6-rpi/ is not booting on the board , while the kernel.img from your xv6 port is booting on the target :-)

Any explanation you have for this ?

regards Yogesh

— Reply to this email directly or view it on GitHub <

https://github.com/zhiyihuang/xv6_rpi_port/issues/1#issuecomment-59741170

.

— Reply to this email directly or view it on GitHub

https://github.com/zhiyihuang/xv6_rpi_port/issues/1#issuecomment-59831371 .

— Reply to this email directly or view it on GitHub https://github.com/zhiyihuang/xv6_rpi_port/issues/1#issuecomment-59917195.

[yogeshbio]

Hello Sir,

Thank you so much for your inputs and time.

Regards Yogesh

On Tue, Oct 28, 2014 at 3:25 AM, Zhiyi Huang notifications@github.com wrote:

Hi Yogesh, Sorry for the late reply as I was marking exams these days.

On 10/22/14, 1:05 AM, yogk wrote:

Hello Mr Huang,

thanks for the information. for Question 1.) As you say the virtual address 0x80008000 gets converted to physical address by mmu.c through page table. Yes.

But during the time bootloader loads kernel.img, mmu is OFF. So during this time who converts this virtual address 0x80008000 to physical address 0x8000?

After booloading, physical addresses are used and the image is loaded at 0x8000. So the entry code of the image assumes physical addresses but quickly enable MMU after a stack space is set.

I will try to boot the kernel.img by mentioning in kernel.ld the .init at 0x8000 instead of 0x80008000.

As IP(r15) must point to 0x8000 our INIT Section =.init in kernel.ld must also be 0x8000 instead of 0x80008000 as this is the first instruction executed in kernel.

Yes. It is done by the bootloader.

/* * First and formost we need the .init section, containing the code to be run first. We allow room for the ATAGs and stack and conform to * the bootloader's expectation by putting this code at 0x8000. / .init 0x8000 : AT(0x8000) { *(.init) }

I don't quite understand your question here.

Zhiyi

Is my understanding correct ?

Regards Yogesh

On Tue, Oct 21, 2014 at 1:40 AM, Zhiyi Huang notifications@github.com wrote:

Hi Yogesh,

Question 1: The virtual address 0x80008000 is converted to physical address 0x8000, which is achieved through the page table set in mmu.c. The bootloader loads the kernel at physical address 0x8000 and pass control to the instruction there, basically ip (r15) is set to 0x8000 after bootload.

Question 2: 0x10000 is the location of the first instruction to be executed after bootloading on PC. I don't know much about https://code.google.com/p/xv6-rpi/ as I ported xv6 directly from the MIT xv6 code for PC. I guess the ported code at https://code.google.com/p/xv6-rpi/ is run in QEMU so it can set the location of the first instruction to any place as long as QEMU knows about it.

Hope that helped.

Zhiyi

On 10/21/14, 1:15 AM, yogk wrote:

Hello Mr Huang,

I am able to boot raspberry pi board with your xv6 port after generating kernel.img

But I had 2 questions :

Question 1.) I see that init in entry.s file is at address 0x80008000 (kernel.ld) which I think is kernel virtual address ? But during kernel boot, as initially mmu is off, How this kernel virtual address 0x80008000 is getting converted to physical address and how this instruction is getting executed in entry.s ?

Question 2.) In the original xv6 port to raspberry pi https://code.google.com/p/xv6-rpi/ the entry.s is as below

SECTIONS { /* the entry point, before enabling paging. The code to enable paging needs to have the same virtual/physical address. entry.S and start.c run in this initial setting.*/ . = 0x10000;

}

Here they mention that before mmu is enabled the address used is 0x10000.

Any idea why they have mentioned it like this ?

But the kernel.img from this https://code.google.com/p/xv6-rpi/ is not booting on the board , while the kernel.img from your xv6 port is booting on the target :-)

Any explanation you have for this ?

regards Yogesh

— Reply to this email directly or view it on GitHub <

https://github.com/zhiyihuang/xv6_rpi_port/issues/1#issuecomment-59741170

.

— Reply to this email directly or view it on GitHub

< https://github.com/zhiyihuang/xv6_rpi_port/issues/1#issuecomment-59831371> .

— Reply to this email directly or view it on GitHub < https://github.com/zhiyihuang/xv6_rpi_port/issues/1#issuecomment-59917195 .

— Reply to this email directly or view it on GitHub https://github.com/zhiyihuang/xv6_rpi_port/issues/1#issuecomment-60676371 .

[yogeshbio]

Hello Mr Huang,

I now try to test the working of USB stack (libcsud) on rpi board. Since you have already included libcsud, is keyboard already working ? I connected the usb keyboard and nothing happens.

Currently my aim is the following:

-- Get USB stack working for at least keyboard ,mass storage device

Is there any better USB stack other than libcsud which is easily portable in raspberry pi xv6 ?

Regards Yogesh

[zhiyihuang]

H Yogesh, The USB library libcsud does only work for some keyboards as it only has implemented control transfer without interrupt transfer, so I disabled it in xv6_rpi_port. I am cc'ing this message to Alex who is the author of libcsud. He is working on interrupt transfer and may have some update on the library. Best regards, Zhiyi

Hello Mr Huang,

I now try to test the working of USB stack (libcsud) on rpi board. Since you have already included libcsud, is keyboard already working ? I connected the usb keyboard and nothing happens.

Currently my aim is the following:

-- Get USB stack working for at least keyboard ,mass storage device

Is there any better USB stack other than libcsud which is easily portable in raspberry pi xv6 ?

Regards Yogesh

---

Reply to this email directly or view it on GitHub: https://github.com/zhiyihuang/xv6_rpi_port/issues/1#issuecomment-61639114

[mattwynyard]

Hi Zhiyi,

Could I please be taken of this email. Just finished exams so need a sleep. :) Thanks Matt

Sent from my iPhone

On 5/11/2014, at 8:32 am, Zhiyi Huang notifications@github.com wrote:

H Yogesh, The USB library libcsud does only work for some keyboards as it only has implemented control transfer without interrupt transfer, so I disabled it in xv6_rpi_port. I am cc'ing this message to Alex who is the author of libcsud. He is working on interrupt transfer and may have some update on the library. Best regards, Zhiyi

Hello Mr Huang,

I now try to test the working of USB stack (libcsud) on rpi board. Since you have already included libcsud, is keyboard already working ? I connected the usb keyboard and nothing happens.

Currently my aim is the following:

-- Get USB stack working for at least keyboard ,mass storage device

Is there any better USB stack other than libcsud which is easily portable in raspberry pi xv6 ?

Regards Yogesh

---

Reply to this email directly or view it on GitHub: https://github.com/zhiyihuang/xv6_rpi_port/issues/1#issuecomment-61639114 — Reply to this email directly or view it on GitHub.

[ghost]

Hi Zhiyi,

I got this compiled, but unable to boot into xv6 after replacing the kernel image. I’m using the “Raspberry pi 2” model, do you see if it has got anything to do because of this.

Thanks Surya.

[zhiyihuang]

The port is for armv6, but RPI 2 is based on armv7.

Hi Zhiyi,

I got this compiled, but unable to boot into xv6 after replacing the kernel image. I’m using the “Raspberry pi 2� model, do you see if it has got anything to do because of this.

Thanks Surya.

---

Reply to this email directly or view it on GitHub: https://github.com/zhiyihuang/xv6_rpi_port/issues/1#issuecomment-94597871

[surya2891]

Thanks a lot for your reply Zhiyi.

I'm attempting it to port the xv6 to armV7, with your project as a reference.

Just to be sure, i guess in your project the USB keyboard was not integrated. So how did the interaction happen, were you using the UART for sending/receiving the data with the RPI and the computer(for COM port interaction)?

Thanks Surya.

[surya2891]

Hi Zhiyi,

I understood that serial port is used for keyboard inputs, what kind of video output works for this version, HDMI or composite video or the serial ? I see that in console.c, we have codes to draw the characters onto a screen - so would be glad to know before i begin :)

Thanks Surya.

[zhiyihuang]

The output is to both the serial port and the GPU memory. Zhiyi

Hi Zhiyi,

I understood that serial port is used for keyboard inputs, what kind of video output works for this version, HDMI or composite video or the serial ? I see that in console.c, we have codes to draw the characters onto a screen - so would be glad to know before i begin :)

Thanks Surya.

---

Reply to this email directly or view it on GitHub: https://github.com/zhiyihuang/xv6_rpi_port/issues/1#issuecomment-95357425

[surya2891]

Hi Yogesh and Zhiyi,

Now, i'm getting into the same question you asked before.

during the time bootloader loads kernel.img, mmu is OFF. So during this time who converts this virtual address 0x80008000 to physical address 0x8000?

Did you derive anything out by setting the init address to 0x8000? The execution fails, most probably.

Thanks Surya.

[zhiyihuang]

Sorry about this long delay. I started a new project last year and was very focused. I guess you have figured out the answer:-) Zhiyi