OpenCores

OpenCores

[Tutorial] Running uClinux on OR1200 using Verilog

no use

no use

1/1

no use

no use

[Tutorial] Running uClinux on OR1200 using Verilog by Unknown on Sep 14, 2004			Not available!
----- Original Message ----- From: Chris Hescott<<A HREF="mailto:hesc0002@u...">hesc0002@u...</A>> [q] Running uClinux on OR1200 using Verilog Simulator I've sucessfully gotten uClinux to run on the OR1200 RTL verilog code using a verilog simulator (cadence for my case). This brief tutorial will hopefully help anyone else who would like to do the same: [/q] Hi Chris Thanks for that tutorial, I am doing a very similar thing myself and so far have only been successful with simple programs like the Dhrystone benchmark included with the core (which didn't actually output any form of log so careful analysis of the switching activity was the only way to check the program was actually running). I will use your advice to get the Linux kernel running on the RTL simulation. Have you managed to get any programs running on top of the Linux kernel? That is my aim - to have some kind of program doing computation (such as a fixed-point DCT or IDCT algorithm, or ideally the Tremor fixed point Ogg-Vorbis decoder) running under uCLinux, which is in turn running on an RTL simulated core. This will then allow me to do some power analysis on the core for various algorithms. The problem that I have is that any programs I compile then try and run (under the OR1Ksim) return "exec format error". I'm not sure where I'm going wrong here, I've tried using various file formats such as hex, bin, or32, etc and all produce the same result. That's beside the problem that I can't get many of my C programs to compile as I get loads of undefined references at the linking stage - but that's another issue entirely! Cheers Paul. ----- Original Message ----- From: Chris Hescotthesc0002@u...> Running uClinux on OR1200 using Verilog Simulator I've sucessfully gotten uClinux to run on the OR1200 RTL verilog code using a verilog simulator (cadence for my case). This brief tutorial will hopefully help anyone else who would like to do the same: Hi Chris Thanks for that tutorial, I am doing a very similar thing myself and so far have only been successful with simple programs like the Dhrystone benchmark included with the core (which didn't actually output any form of log so careful analysis of the switching activity was the only way to check the program was actually running). I will use your advice to get the Linux kernel running on the RTL simulation. Have you managed to get any programs running on top of the Linux kernel? That is my aim - to have some kind of program doing computation (such as a fixed-point DCT or IDCT algorithm, or ideally the Tremor fixed point Ogg-Vorbis decoder) running under uCLinux, which is in turn running on an RTL simulated core. This will then allow me to do some power analysis on the core for various algorithms. The problem that I have is that any programs I compile then try and run (under the OR1Ksim) return "exec format error". I'm not sure where I'm going wrong here, I've tried using various file formats such as hex, bin, or32, etc and all produce the same result. That's beside the problem that I can't get many of my C programs to compile as I get loads of undefined references at the linking stage - but that's another issue entirely! Cheers Paul.

[Tutorial] Running uClinux on OR1200 using Verilog by Unknown on Sep 17, 2004			Not available!
* <A HREF="mailto:paul_morga@yahoo.co.uk">paul_morga@yahoo.co.uk</A> (<A HREF="mailto:paul_morga@yahoo.co.uk">paul_morga@yahoo.co.uk</A>) wrote: [q] ----- Original Message ----- From: Chris Hescott<<A HREF="mailto:hesc0002@u...">hesc0002@u...</A>> [q]> Running uClinux on OR1200 using Verilog Simulator > > I've sucessfully gotten uClinux to run on the OR1200 RTL verilog > code using a verilog simulator (cadence for my case). This brief > tutorial will hopefully help anyone else who would like to do the same: [/q] Hi Chris Thanks for that tutorial, I am doing a very similar thing myself and so far have only been successful with simple programs like the Dhrystone benchmark included with the core (which didn't actually output any form of log so careful analysis of the switching activity was the only way to check the program was actually running). I will use your advice to get the Linux kernel running on the RTL simulation. Have you managed to get any programs running on top of the Linux kernel? That is my aim - to have some kind of program doing computation (such as a fixed-point DCT or IDCT algorithm, or ideally the Tremor fixed point Ogg-Vorbis decoder) running under uCLinux, which is in turn running on an RTL simulated core. This will then allow me to do some power analysis on the core for various algorithms. The problem that I have is that any programs I compile then try and run (under the OR1Ksim) return "exec format error". I'm not sure where I'm going wrong here, I've tried using various file formats such as hex, bin, or32, etc and all produce the same result.[/q] do you get this while trying it on uclinux ? do other binaries as 'ls' from supplied initrd work ? best regards, p. * paul_morga@yahoo.co.uk (paul_morga@yahoo.co.uk) wrote: ----- Original Message ----- From: Chris Hescotthesc0002@u...> > Running uClinux on OR1200 using Verilog Simulator > > I've sucessfully gotten uClinux to run on the OR1200 RTL verilog > code using a verilog simulator (cadence for my case). This brief > tutorial will hopefully help anyone else who would like to do the same: Hi Chris Thanks for that tutorial, I am doing a very similar thing myself and so far have only been successful with simple programs like the Dhrystone benchmark included with the core (which didn't actually output any form of log so careful analysis of the switching activity was the only way to check the program was actually running). I will use your advice to get the Linux kernel running on the RTL simulation. Have you managed to get any programs running on top of the Linux kernel? That is my aim - to have some kind of program doing computation (such as a fixed-point DCT or IDCT algorithm, or ideally the Tremor fixed point Ogg-Vorbis decoder) running under uCLinux, which is in turn running on an RTL simulated core. This will then allow me to do some power analysis on the core for various algorithms. The problem that I have is that any programs I compile then try and run (under the OR1Ksim) return "exec format error". I'm not sure where I'm going wrong here, I've tried using various file formats such as hex, bin, or32, etc and all produce the same result. do you get this while trying it on uclinux ? do other binaries as 'ls' from supplied initrd work ? best regards, p.

[Tutorial] Running uClinux on OR1200 using Verilog by Unknown on Sep 17, 2004			Not available!
----- Original Message ----- From: <A HREF="mailto:paul_morga@y...">paul_morga@y...</A><<A HREF="mailto:paul_morga@y...">paul_morga@y...</A>> To: Date: Tue Sep 14 11:50:55 CEST 2004 Subject: [openrisc] [Tutorial] Running uClinux on OR1200 using Verilog [q] Hi Chris Thanks for that tutorial, I am doing a very similar thing myself and so far have only been successful with simple programs like the Dhrystone benchmark included with the core (which didn't actually output any form of log so careful analysis of the switching activity was the only way to check the program was actually running). I will use your advice to get the Linux kernel running on the RTL simulation. Have you managed to get any programs running on top of the Linux kernel? That is my aim - to have some kind of program doing computation (such as a fixed-point DCT or IDCT algorithm, or ideally [/q] I've written a simple Hello World program to test the basic library routines provided by the gcc toolchain. I had to compile the program using or32-uclinux-gcc. The compiled binary was then placed in the /bin directory on the romfs and a new initrd was generated using genromfs. This new initrd must then be placed in the arch/or32/board directory and you must rebuild the uclinux kernel. Also, you need to edit the /etc/rc file in the genromfs filesystem to add your program to it. This will make the linux kernel start your program by default after it boots. Otherwise you have to do so manually by messing with the uart.rx file for the simulator. Here is my hello world program. Note the #includes are required. #include <stdio.h> #include <stdlib.h> int main() { int n = 2; printf ("Hello World!\n"); printf ("Hello my %d worlds!\n", n); exit(0); } You have to use some special settings in a Makefile to get your binary to compile: OBJS = hello.o CC = or32-uclibc-gcc LD = or32-uclibc-gcc STRIP = or32-uclibc-strip CFLAGS := $(CFLAGS) -Wall -Werror-implicit-function-declaration -D__USE_BSD LDFLAGS := -r -d all: hello hello: $(OBJS) $(LD) $(OBJS) $(LDFLAGS) -o $@ $(STRIP) -g $@ clean: rm -f .[oa] .coff ~ core hello To generate the romfs do the following: In a directory of your choice: mkdir romfs_mnt mount -o loop <path>/uClinux-2.x.x/arch/or32/board/initrd romfs_mnt mkdir romfs cp -r romfs_mnt/ romfs/ /* make your changes to the filesystem e.g. edit the rc file and copy your compiled program binary to the /bin directory / cd romfs genromfs -f <path>/uClinux-2.x.x/arch/or32/board/initrd cd <path>/uClinux-2.x.x make all <path> here is the path to your uclinux direcotry. Also, there were quite a few changes I needed to make to the or1200 orp verilog code to get this running using verilog simulation. Mostly the changes were increasing the amount of accessible memory in both the flash and srams. I'll post those changes in the future. Following the above should allow you to simulate using the or32-uclinux-sim however. --Chris ----- Original Message ----- From: paul_morga@y...paul_morga@y...> To: Date: Tue Sep 14 11:50:55 CEST 2004 Subject: [openrisc] [Tutorial] Running uClinux on OR1200 using Verilog Hi Chris Thanks for that tutorial, I am doing a very similar thing myself and so far have only been successful with simple programs like the Dhrystone benchmark included with the core (which didn't actually output any form of log so careful analysis of the switching activity was the only way to check the program was actually running). I will use your advice to get the Linux kernel running on the RTL simulation. Have you managed to get any programs running on top of the Linux kernel? That is my aim - to have some kind of program doing computation (such as a fixed-point DCT or IDCT algorithm, or ideally I've written a simple Hello World program to test the basic library routines provided by the gcc toolchain. I had to compile the program using or32-uclinux-gcc. The compiled binary was then placed in the /bin directory on the romfs and a new initrd was generated using genromfs. This new initrd must then be placed in the arch/or32/board directory and you must rebuild the uclinux kernel. Also, you need to edit the /etc/rc file in the genromfs filesystem to add your program to it. This will make the linux kernel start your program by default after it boots. Otherwise you have to do so manually by messing with the uart.rx file for the simulator. Here is my hello world program. Note the #includes are required. #include #include int main() { int n = 2; printf ("Hello World!\n"); printf ("Hello my %d worlds!\n", n); exit(0); } You have to use some special settings in a Makefile to get your binary to compile: OBJS = hello.o CC = or32-uclibc-gcc LD = or32-uclibc-gcc STRIP = or32-uclibc-strip CFLAGS := $(CFLAGS) -Wall -Werror-implicit-function-declaration -D__USE_BSD LDFLAGS := -r -d all: hello hello: $(OBJS) $(LD) $(OBJS) $(LDFLAGS) -o $@ $(STRIP) -g $@ clean: rm -f .[oa] .coff ~ core hello To generate the romfs do the following: In a directory of your choice: mkdir romfs_mnt mount -o loop /uClinux-2.x.x/arch/or32/board/initrd romfs_mnt mkdir romfs cp -r romfs_mnt/* romfs/ /* make your changes to the filesystem e.g. edit the rc file and copy your compiled program binary to the /bin directory */ cd romfs genromfs -f /uClinux-2.x.x/arch/or32/board/initrd cd /uClinux-2.x.x make all here is the path to your uclinux direcotry. Also, there were quite a few changes I needed to make to the or1200 orp verilog code to get this running using verilog simulation. Mostly the changes were increasing the amount of accessible memory in both the flash and srams. I'll post those changes in the future. Following the above should allow you to simulate using the or32-uclinux-sim however. --Chris

[Tutorial] Running uClinux on OR1200 using Verilog by Unknown on Oct 5, 2004			Not available!
----- Original Message ----- From: <A HREF="mailto:hesc0002@u...">hesc0002@u...</A><<A HREF="mailto:hesc0002@u...">hesc0002@u...</A>> To: Date: Fri Sep 17 19:29:47 CEST 2004 Subject: [openrisc] [Tutorial] Running uClinux on OR1200 using Verilog ..... [q] Also, there were quite a few changes I needed to make to the or1200 orp verilog code to get this running using verilog simulation. Mostly the changes were increasing the amount of accessible memory in both the flash and srams. I'll post those changes in the future. Following the above should allow you to simulate using the or32-uclinux-sim however. --Chris [/q] Thanks for that Chris, works a treat in simulation. Sorry for the delay in replying - I've been on holiday. I'm going to try and adapt this to work for some more complex examples although as I don't really understand the details of the compilation and linking process I suspect variations required in command line switches to account for libraries etc may prove to be a problem. If you could post up details of the modifications to the verilog for RTL simulation that would be great. Cheers Paul. ----- Original Message ----- From: hesc0002@u...hesc0002@u...> To: Date: Fri Sep 17 19:29:47 CEST 2004 Subject: [openrisc] [Tutorial] Running uClinux on OR1200 using Verilog ..... Also, there were quite a few changes I needed to make to the or1200 orp verilog code to get this running using verilog simulation. Mostly the changes were increasing the amount of accessible memory in both the flash and srams. I'll post those changes in the future. Following the above should allow you to simulate using the or32-uclinux-sim however. --Chris Thanks for that Chris, works a treat in simulation. Sorry for the delay in replying - I've been on holiday. I'm going to try and adapt this to work for some more complex examples although as I don't really understand the details of the compilation and linking process I suspect variations required in command line switches to account for libraries etc may prove to be a problem. If you could post up details of the modifications to the verilog for RTL simulation that would be great. Cheers Paul.

[Tutorial] Running uClinux on OR1200 using Verilog by Unknown on Oct 5, 2004			Not available!
Further to my previous message, I tried compiling the sample integer JPEG compression/decompression programs available from www.ijg.org (namely cjpeg and djpeg). They compiled fine with no errors or warnings using the same switches as described below, but on placing them into the ROMFS image and attemping to execute them during simulation I get the error: EXCEPTION: Read out of memory (32 bit access to 0xfffffffc) This has me baffled as everything is set up correctly in the simulator and rom.ld etc. I can only assume it's something to do with the memory routines within the code, but I'd have thought the compiler would deal with memory accesses in a way suited to the MMU-less OS. Of course there are no absolute references to the above memory location in the code, so I'm lost as to what needs to be changed to get this to run. Any replies appreciated. Paul. ----- Original Message ----- From: <A HREF="mailto:hesc0002@u...">hesc0002@u...</A><<A HREF="mailto:hesc0002@u...">hesc0002@u...</A>> To: Date: Fri Sep 17 19:29:47 CEST 2004 Subject: [openrisc] [Tutorial] Running uClinux on OR1200 using Verilog [q] I've written a simple Hello World program to test the basic library routines provided by the gcc toolchain. I had to compile the program using or32-uclinux-gcc. The compiled binary was then placed in the /bin directory on the romfs and a new initrd was generated using genromfs. This new initrd must then be placed in the arch/or32/board directory and you must rebuild the uclinux kernel. Also, you need to edit the /etc/rc file in the genromfs filesystem to add your program to it. This will make the linux kernel start your program by default after it boots. Otherwise you have to do so manually by messing with the uart.rx file for the simulator. Here is my hello world program. Note the #includes are required. #include <stdio.h> #include <stdlib.h> int main() { int n = 2; printf ("Hello World!\n"); printf ("Hello my %d worlds!\n", n); exit(0); } You have to use some special settings in a Makefile to get your binary to compile: OBJS = hello.o CC = or32-uclibc-gcc LD = or32-uclibc-gcc STRIP = or32-uclibc-strip CFLAGS := $(CFLAGS) -Wall -Werror-implicit-function-declaration -D__USE_BSD LDFLAGS := -r -d all: hello hello: $(OBJS) $(LD) $(OBJS) $(LDFLAGS) -o $@ $(STRIP) -g $@ clean: rm -f .[oa] .coff ~ core hello To generate the romfs do the following: In a directory of your choice: mkdir romfs_mnt mount -o loop <path>/uClinux-2.x.x/arch/or32/board/initrd romfs_mnt mkdir romfs cp -r romfs_mnt/ romfs/ /* make your changes to the filesystem e.g. edit the rc file and copy your compiled program binary to the /bin directory / cd romfs genromfs -f <path>/uClinux-2.x.x/arch/or32/board/initrd cd <path>/uClinux-2.x.x make all <path> here is the path to your uclinux direcotry. Also, there were quite a few changes I needed to make to the or1200 orp verilog code to get this running using verilog simulation. Mostly the changes were increasing the amount of accessible memory in both the flash and srams. I'll post those changes in the future. Following the above should allow you to simulate using the or32-uclinux-sim however. --Chris [/q] Further to my previous message, I tried compiling the sample integer JPEG compression/decompression programs available from www.ijg.org (namely cjpeg and djpeg). They compiled fine with no errors or warnings using the same switches as described below, but on placing them into the ROMFS image and attemping to execute them during simulation I get the error: EXCEPTION: Read out of memory (32 bit access to 0xfffffffc) This has me baffled as everything is set up correctly in the simulator and rom.ld etc. I can only assume it's something to do with the memory routines within the code, but I'd have thought the compiler would deal with memory accesses in a way suited to the MMU-less OS. Of course there are no absolute references to the above memory location in the code, so I'm lost as to what needs to be changed to get this to run. Any replies appreciated. Paul. ----- Original Message ----- From: hesc0002@u...hesc0002@u...> To: Date: Fri Sep 17 19:29:47 CEST 2004 Subject: [openrisc] [Tutorial] Running uClinux on OR1200 using Verilog I've written a simple Hello World program to test the basic library routines provided by the gcc toolchain. I had to compile the program using or32-uclinux-gcc. The compiled binary was then placed in the /bin directory on the romfs and a new initrd was generated using genromfs. This new initrd must then be placed in the arch/or32/board directory and you must rebuild the uclinux kernel. Also, you need to edit the /etc/rc file in the genromfs filesystem to add your program to it. This will make the linux kernel start your program by default after it boots. Otherwise you have to do so manually by messing with the uart.rx file for the simulator. Here is my hello world program. Note the #includes are required. #include #include int main() { int n = 2; printf ("Hello World!\n"); printf ("Hello my %d worlds!\n", n); exit(0); } You have to use some special settings in a Makefile to get your binary to compile: OBJS = hello.o CC = or32-uclibc-gcc LD = or32-uclibc-gcc STRIP = or32-uclibc-strip CFLAGS := $(CFLAGS) -Wall -Werror-implicit-function-declaration -D__USE_BSD LDFLAGS := -r -d all: hello hello: $(OBJS) $(LD) $(OBJS) $(LDFLAGS) -o $@ $(STRIP) -g $@ clean: rm -f .[oa] .coff ~ core hello To generate the romfs do the following: In a directory of your choice: mkdir romfs_mnt mount -o loop /uClinux-2.x.x/arch/or32/board/initrd romfs_mnt mkdir romfs cp -r romfs_mnt/* romfs/ /* make your changes to the filesystem e.g. edit the rc file and copy your compiled program binary to the /bin directory */ cd romfs genromfs -f /uClinux-2.x.x/arch/or32/board/initrd cd /uClinux-2.x.x make all here is the path to your uclinux direcotry. Also, there were quite a few changes I needed to make to the or1200 orp verilog code to get this running using verilog simulation. Mostly the changes were increasing the amount of accessible memory in both the flash and srams. I'll post those changes in the future. Following the above should allow you to simulate using the or32-uclinux-sim however. --Chris

[Tutorial] Running uClinux on OR1200 using Verilog by Unknown on Oct 12, 2004			Not available!
At what point does the Read out of memory exception occur? Does the operating system boot correctly? You should be able to see the ouput from the OS showing all of its initializations. If this is working correctly and the Read out of memory exception occurs only after the shell is started and the /etc/rc file read, then you can guess the problem is with the compiled benchmark code itself. Otherwise if the error occurs during the startup routine of the OS then there is something wrong with the configuration of the OS. You can try using "or32-uclibc-objdump -D linux" to get the assembly of your linux binary. Try searching through there to see if you can find out what instruction is trying to access this memory address. You can also play around with the simulator features to narrow down exactly what instruction is being executed when the exception occurrs. This address can then be directly referenced in objdump file to help narrow your search. You also may want to get a simple hello world program working (if you haven't already). Make sure everything is correct with the simple hello world and then add your new compiled binary of your benchmark without making any other changes to config files etc. It's possible too that your program is trying to reference a device that is mapped to that specific address and doesn't get used in any of the programs that I've used for testing. If this is the case, you'd have to try to narrow down the source of that address. This is easier if you know exactly where in the code the address is being used. Let me know if you find anything that I may have missed in the tutorial. --Chris ----- Original Message ----- From: <A HREF="mailto:paul_morga@y...">paul_morga@y...</A><<A HREF="mailto:paul_morga@y...">paul_morga@y...</A>> To: Date: Tue Oct 5 15:28:44 CEST 2004 Subject: [openrisc] [Tutorial] Running uClinux on OR1200 using Verilog [q] Further to my previous message, I tried compiling the sample integer JPEG compression/decompression programs available from www.ijg.org (namely cjpeg and djpeg). They compiled fine with no errors or warnings using the same switches as described below, but on placing them into the ROMFS image and attemping to execute them during simulation I get the error: EXCEPTION: Read out of memory (32 bit access to 0xfffffffc) This has me baffled as everything is set up correctly in the simulator and rom.ld etc. I can only assume it's something to do with the memory routines within the code, but I'd have thought the compiler would deal with memory accesses in a way suited to the MMU-less OS. Of course there are no absolute references to the above memory location in the code, so I'm lost as to what needs to be changed to get this to run. Any replies appreciated. Paul. ----- Original Message ----- From: <A HREF="mailto:hesc0002@u...">hesc0002@u...</A><<A HREF="mailto:hesc0002@u...">hesc0002@u...</A>> To: Date: Fri Sep 17 19:29:47 CEST 2004 Subject: [openrisc] [Tutorial] Running uClinux on OR1200 using Verilog [q]> I've written a simple Hello World program to test the basic [/q] library [q]> routines provided by the gcc toolchain. I had to compile the > program > using or32-uclinux-gcc. The compiled binary was then placed in [/q] the [q]> /bin directory on the romfs and a new initrd was generated [/q] using [q]> genromfs. This new initrd must then be placed in the > arch/or32/board > directory and you must rebuild the uclinux kernel. Also, you [/q] need [q]> to > edit the /etc/rc file in the genromfs filesystem to add your > program > to it. This will make the linux kernel start your program by > default > after it boots. Otherwise you have to do so manually by [/q] messing [q]> with > the uart.rx file for the simulator. > Here is my hello world program. Note the #includes are [/q] required. [q]> #include <stdio.h> > #include <stdlib.h> > int main() { > int n = 2; > printf ("Hello World!\n"); > printf ("Hello my %d worlds!\n", n); > exit(0); > } > You have to use some special settings in a Makefile to get [/q] your [q]> binary > to compile: > OBJS = hello.o > CC = or32-uclibc-gcc > LD = or32-uclibc-gcc > STRIP = or32-uclibc-strip > CFLAGS := $(CFLAGS) -Wall [/q] -Werror-implicit-function-declaration [q]> -D__USE_BSD > LDFLAGS := -r -d > all: hello > hello: $(OBJS) > $(LD) $(OBJS) $(LDFLAGS) -o $@ > $(STRIP) -g $@ > clean: > rm -f .[oa] .coff ~ core hello > To generate the romfs do the following: > In a directory of your choice: > mkdir romfs_mnt > mount -o loop [/q] <path>/uClinux-2.x.x/arch/or32/board/initrd [q]> romfs_mnt > mkdir romfs > cp -r romfs_mnt/ romfs/ > /* make your changes to the filesystem e.g. edit the rc file [/q] and [q]> copy > your compiled program binary to the /bin directory / > cd romfs > genromfs -f <path>/uClinux-2.x.x/arch/or32/board/initrd > cd <path>/uClinux-2.x.x > make all > <path> here is the path to your uclinux direcotry. > Also, there were quite a few changes I needed to make to the [/q] or1200 [q]> orp verilog code to get this running using verilog simulation. > Mostly > the changes were increasing the amount of accessible memory in [/q] both [q]> the flash and srams. I'll post those changes in the future. > Following the above should allow you to simulate using the > or32-uclinux-sim however. > --Chris > > [/q] [/q] At what point does the Read out of memory exception occur? Does the operating system boot correctly? You should be able to see the ouput from the OS showing all of its initializations. If this is working correctly and the Read out of memory exception occurs only after the shell is started and the /etc/rc file read, then you can guess the problem is with the compiled benchmark code itself. Otherwise if the error occurs during the startup routine of the OS then there is something wrong with the configuration of the OS. You can try using "or32-uclibc-objdump -D linux" to get the assembly of your linux binary. Try searching through there to see if you can find out what instruction is trying to access this memory address. You can also play around with the simulator features to narrow down exactly what instruction is being executed when the exception occurrs. This address can then be directly referenced in objdump file to help narrow your search. You also may want to get a simple hello world program working (if you haven't already). Make sure everything is correct with the simple hello world and then add your new compiled binary of your benchmark without making any other changes to config files etc. It's possible too that your program is trying to reference a device that is mapped to that specific address and doesn't get used in any of the programs that I've used for testing. If this is the case, you'd have to try to narrow down the source of that address. This is easier if you know exactly where in the code the address is being used. Let me know if you find anything that I may have missed in the tutorial. --Chris ----- Original Message ----- From: paul_morga@y...paul_morga@y...> To: Date: Tue Oct 5 15:28:44 CEST 2004 Subject: [openrisc] [Tutorial] Running uClinux on OR1200 using Verilog Further to my previous message, I tried compiling the sample integer JPEG compression/decompression programs available from www.ijg.org (namely cjpeg and djpeg). They compiled fine with no errors or warnings using the same switches as described below, but on placing them into the ROMFS image and attemping to execute them during simulation I get the error: EXCEPTION: Read out of memory (32 bit access to 0xfffffffc) This has me baffled as everything is set up correctly in the simulator and rom.ld etc. I can only assume it's something to do with the memory routines within the code, but I'd have thought the compiler would deal with memory accesses in a way suited to the MMU-less OS. Of course there are no absolute references to the above memory location in the code, so I'm lost as to what needs to be changed to get this to run. Any replies appreciated. Paul. ----- Original Message ----- From: hesc0002@u...hesc0002@u...> To: Date: Fri Sep 17 19:29:47 CEST 2004 Subject: [openrisc] [Tutorial] Running uClinux on OR1200 using Verilog > I've written a simple Hello World program to test the basic library > routines provided by the gcc toolchain. I had to compile the > program > using or32-uclinux-gcc. The compiled binary was then placed in the > /bin directory on the romfs and a new initrd was generated using > genromfs. This new initrd must then be placed in the > arch/or32/board > directory and you must rebuild the uclinux kernel. Also, you need > to > edit the /etc/rc file in the genromfs filesystem to add your > program > to it. This will make the linux kernel start your program by > default > after it boots. Otherwise you have to do so manually by messing > with > the uart.rx file for the simulator. > Here is my hello world program. Note the #includes are required. > #include > #include > int main() { > int n = 2; > printf ("Hello World!\n"); > printf ("Hello my %d worlds!\n", n); > exit(0); > } > You have to use some special settings in a Makefile to get your > binary > to compile: > OBJS = hello.o > CC = or32-uclibc-gcc > LD = or32-uclibc-gcc > STRIP = or32-uclibc-strip > CFLAGS := $(CFLAGS) -Wall -Werror-implicit-function-declaration > -D__USE_BSD > LDFLAGS := -r -d > all: hello > hello: $(OBJS) > $(LD) $(OBJS) $(LDFLAGS) -o $@ > $(STRIP) -g $@ > clean: > rm -f .[oa] .coff ~ core hello > To generate the romfs do the following: > In a directory of your choice: > mkdir romfs_mnt > mount -o loop /uClinux-2.x.x/arch/or32/board/initrd > romfs_mnt > mkdir romfs > cp -r romfs_mnt/* romfs/ > /* make your changes to the filesystem e.g. edit the rc file and > copy > your compiled program binary to the /bin directory */ > cd romfs > genromfs -f /uClinux-2.x.x/arch/or32/board/initrd > cd /uClinux-2.x.x > make all > here is the path to your uclinux direcotry. > Also, there were quite a few changes I needed to make to the or1200 > orp verilog code to get this running using verilog simulation. > Mostly > the changes were increasing the amount of accessible memory in both > the flash and srams. I'll post those changes in the future. > Following the above should allow you to simulate using the > or32-uclinux-sim however. > --Chris > >

[Tutorial] Running uClinux on OR1200 using Verilog by Unknown on Oct 13, 2004			Not available!
----- Original Message ----- From: <A HREF="mailto:hesc0002@u...">hesc0002@u...</A><<A HREF="mailto:hesc0002@u...">hesc0002@u...</A>> To: Date: Tue Oct 12 18:24:20 CEST 2004 Subject: [openrisc] [Tutorial] Running uClinux on OR1200 using Verilog [q] At what point does the Read out of memory exception occur? Does the operating system boot correctly? You should be able to see the ouput from the OS showing all of its initializations. If this is working correctly and the Read out of memory exception occurs only after the shell is started and the /etc/rc file read, then you can guess the problem is with the compiled benchmark code itself. Otherwise if the error occurs during the startup routine of the OS then there is something wrong with the configuration of the OS. [/q] It is definitely the compiled program. I can boot the OS fine, and run the hello world example from /etc/rc. But when I try to run any other programs I've compiled from freely available source I get this error. [q] You can try using "or32-uclibc-objdump -D linux" to get the assembly of your linux binary. Try searching through there to see if you can find out what instruction is trying to access this memory address. You can also play around with the simulator features to narrow down exactly what instruction is being executed when the exception occurrs. This address can then be directly referenced in objdump file to help narrow your search. [/q] OK I will try that and report results. However I'd have thought that the compiler would take care of the memory references depending on the target architecture, after all the source code has no direct memory references. I am using the same compile/link options as were posted in the Makefile for the hello world example. [q] You also may want to get a simple hello world program working (if you haven't already). Make sure everything is correct with the simple hello world and then add your new compiled binary of your benchmark without making any other changes to config files etc. It's possible too that your program is trying to reference a device that is mapped to that specific address and doesn't get used in any of the programs that I've used for testing. If this is the case, you'd have to try to narrow down the source of that address. This is easier if you know exactly where in the code the address is being used. Let me know if you find anything that I may have missed in the tutorial. [/q] Hello world is working fine, and my new program is being compiled using the same options (basically I copied the makefile, substituting the necessary source file). I'm not aware of the code accessing any devices, other than STDIN/STDOUT, which are obviously not memory mapped. Have you managed to successfully compile and run any "useful" programs? Something like the MP3 decoder would be nice, or the "Tremor" fixed-point ogg vorbis decoder. Even something simple like image decompression or DCT transform would be good. I was considering getting the existing MP3 program running which is in CVS, but that runs on RTEMS which means starting from scratch and installing with little support. Thanks Paul. ----- Original Message ----- From: hesc0002@u...hesc0002@u...> To: Date: Tue Oct 12 18:24:20 CEST 2004 Subject: [openrisc] [Tutorial] Running uClinux on OR1200 using Verilog At what point does the Read out of memory exception occur? Does the operating system boot correctly? You should be able to see the ouput from the OS showing all of its initializations. If this is working correctly and the Read out of memory exception occurs only after the shell is started and the /etc/rc file read, then you can guess the problem is with the compiled benchmark code itself. Otherwise if the error occurs during the startup routine of the OS then there is something wrong with the configuration of the OS. It is definitely the compiled program. I can boot the OS fine, and run the hello world example from /etc/rc. But when I try to run any other programs I've compiled from freely available source I get this error. You can try using "or32-uclibc-objdump -D linux" to get the assembly of your linux binary. Try searching through there to see if you can find out what instruction is trying to access this memory address. You can also play around with the simulator features to narrow down exactly what instruction is being executed when the exception occurrs. This address can then be directly referenced in objdump file to help narrow your search. OK I will try that and report results. However I'd have thought that the compiler would take care of the memory references depending on the target architecture, after all the source code has no direct memory references. I am using the same compile/link options as were posted in the Makefile for the hello world example. You also may want to get a simple hello world program working (if you haven't already). Make sure everything is correct with the simple hello world and then add your new compiled binary of your benchmark without making any other changes to config files etc. It's possible too that your program is trying to reference a device that is mapped to that specific address and doesn't get used in any of the programs that I've used for testing. If this is the case, you'd have to try to narrow down the source of that address. This is easier if you know exactly where in the code the address is being used. Let me know if you find anything that I may have missed in the tutorial. Hello world is working fine, and my new program is being compiled using the same options (basically I copied the makefile, substituting the necessary source file). I'm not aware of the code accessing any devices, other than STDIN/STDOUT, which are obviously not memory mapped. Have you managed to successfully compile and run any "useful" programs? Something like the MP3 decoder would be nice, or the "Tremor" fixed-point ogg vorbis decoder. Even something simple like image decompression or DCT transform would be good. I was considering getting the existing MP3 program running which is in CVS, but that runs on RTEMS which means starting from scratch and installing with little support. Thanks Paul.

[Tutorial] Running uClinux on OR1200 using Verilog by Unknown on Oct 13, 2004			Not available!
[q] You can try using "or32-uclibc-objdump -D linux" to get the assembly of your linux binary. Try searching through there to see if you can find out what instruction is trying to access this memory address. You can also play around with the simulator features to narrow down exactly what instruction is being executed when the exception occurrs. [/q] There are no references to ff ff ff fc (I used grep to check the output of objdump). However there are quite a few references to ff ff ff which would still be out of the scope of the memory. These are all referred by l.cust4 and l.cust8 instructions, which are customisable intructions for future use - why is the compiler using them? No other information is given for these instructions except what I assume is the instruction address. I'm assuming these instructions aren't actually executed (possibly just wasting space) hence why they're all referencing invalid memory locations. Still doesn't get me any closer to solving the exception though unfortunately. Paul. You can try using "or32-uclibc-objdump -D linux" to get the assembly of your linux binary. Try searching through there to see if you can find out what instruction is trying to access this memory address. You can also play around with the simulator features to narrow down exactly what instruction is being executed when the exception occurrs. There are no references to ff ff ff fc (I used grep to check the output of objdump). However there are quite a few references to ff ff ff which would still be out of the scope of the memory. These are all referred by l.cust4 and l.cust8 instructions, which are customisable intructions for future use - why is the compiler using them? No other information is given for these instructions except what I assume is the instruction address. I'm assuming these instructions aren't actually executed (possibly just wasting space) hence why they're all referencing invalid memory locations. Still doesn't get me any closer to solving the exception though unfortunately. Paul.

no use

no use

1/1

no use

no use

© copyright 1999-2026 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.