On 24 August 2017 at 14:22, LOPEZ CUEVA Patricia <patricia.lopezcu...@thalesaleniaspace.com> wrote: > Hi Jiri, > > > > Thanks for your quick reply. Indeed, I did not know that patches had to be > applied to qemu, I thought it was only to the toolset. > > > > I have downloaded the three patches and tried to directly apply them to > qemu-2.9.0 without success. The patches are intended for which version of > qemu?
Hi Patricia, If you also build qemu with the RSB it will select the correct version and apply the patches for you. The build set is in bare/config/devel/qemu. I'm working to get those patches merged into upstream qemu but it hasn't happened yet. Goodluck, Cillian. > > > > In the end, I managed to apply them by modifying them a bit (only very minor > modifications), but it does not compile. Note that qemu-2.9.0 compiles > without any problem without the patches. > > > > I will not include the whole compilation output because it is huge and it > would not be useful. I will include only the first few lines of the > compilation errors: > > > > CC sparc-softmmu/hw/sparc/grlib_ambapnp.o > > In file included from > /usr/local/tools/qemu-2.9.0/include/exec/cpu-common.h:7:0, > > from /usr/local/tools/qemu-2.9.0/include/hw/hw.h:9, > > from /usr/local/tools/qemu-2.9.0/include/hw/qdev.h:4, > > from /usr/local/tools/qemu-2.9.0/include/hw/sysbus.h:6, > > from > /usr/local/tools/qemu-2.9.0/hw/sparc/grlib_ambapnp.c:23: > > /usr/local/tools/qemu-2.9.0/include/exec/hwaddr.h:11:1: error: unknown type > name ‘uint64_t’ > > typedef uint64_t hwaddr; > > ^ > > In file included from /usr/local/tools/qemu-2.9.0/include/qemu/bswap.h:4:0, > > from > /usr/local/tools/qemu-2.9.0/include/exec/cpu-common.h:10, > > from /usr/local/tools/qemu-2.9.0/include/hw/hw.h:9, > > from /usr/local/tools/qemu-2.9.0/include/hw/qdev.h:4, > > from /usr/local/tools/qemu-2.9.0/include/hw/sysbus.h:6, > > from > /usr/local/tools/qemu-2.9.0/hw/sparc/grlib_ambapnp.c:23: > > /usr/local/tools/qemu-2.9.0/include/fpu/softfloat.h:94:1: error: unknown > type name ‘uint8_t’ > > typedef uint8_t flag; > > ^ > > /usr/local/tools/qemu-2.9.0/include/fpu/softfloat.h:137:1: error: unknown > type name ‘uint16_t’ > > typedef uint16_t float16; > > ^ > > /usr/local/tools/qemu-2.9.0/include/fpu/softfloat.h:138:1: error: unknown > type name ‘uint32_t’ > > typedef uint32_t float32; > > ^ > > /usr/local/tools/qemu-2.9.0/include/fpu/softfloat.h:139:1: error: unknown > type name ‘uint64_t’ > > typedef uint64_t float64; > > ^ > > /usr/local/tools/qemu-2.9.0/include/fpu/softfloat.h:151:5: error: unknown > type name ‘uint64_t’ > > uint64_t low; > > ^ > > /usr/local/tools/qemu-2.9.0/include/fpu/softfloat.h:152:5: error: unknown > type name ‘uint16_t’ > > uint16_t high; > > ^ > > > > Currently I am trying to understand the reason for this behavior. > > > > Thanks. > > > > Patricia López Cueva > > R&D On-Board Software Engineer > > TAS-F Cannes > > > > De : Jiri Gaisler [mailto:j...@gaisler.se] > Envoyé : jeudi 24 août 2017 10:29 > À : LOPEZ CUEVA Patricia; users@rtems.org > Objet : Re: Infinite loop on _Heap_Allocate > > > > Have you applied leon3 patches for qemu from https://gaisler.org/qemu ? > > These are needed to boot RTEMS binaries properly. > > Jiri. > > > > On 08/24/2017 10:22 AM, LOPEZ CUEVA Patricia wrote: > > Hello all ! > > > > I’ve just installed rtems-4.8 on a Redhat 7 64 bits machine. I’ve installed > the release version of rtems 4.8 and the following versions of the toolset: > > - gcc 4.2.1 with newlib 1.15.0 > > - binutils 2.18 > > - gdb 6.8 > > > > The compilation and installation of the toolset and rtems run without > problem except for the documentation part which I disabled. > > > > Then I installed the rtems-4.8 examples and tried to run hello_world_c on > qemu leon3 with the command “qemu-system-sparc -nographic -M leon3_generic > -cpu LEON3 -kernel hello.exe -s –S”. > > > > Neither error nor warning was present in the compilation or the execution > process (nor the hello world message) and when I stop the execution it is > always on the _Heap_Allocate function of cpukit/score/src/heapallocate.c > file. Here is the backtrace: > > > > (gdb) c > > Continuing. > > > > Program received signal SIGINT, Interrupt. > > _Heap_Allocate (the_heap=0x40013e6c, size=<value optimized out>) at > ../../../../../../rtems-4.8.0/c/src/../../cpukit/score/src/heapallocate.c:57 > > 57 the_block = the_block->next, ++search_count) > > (gdb) bt > > #0 _Heap_Allocate (the_heap=0x40013e6c, size=<value optimized out>) at > ../../../../../../rtems-4.8.0/c/src/../../cpukit/score/src/heapallocate.c:57 > > #1 0x4000b8c8 in _Workspace_Allocate_or_fatal_error (size=52) at > ../../cpukit/../../../leon3/lib/include/rtems/score/wkspace.inl:37 > > #2 0x4000b2e4 in _User_extensions_Handler_initialization > (number_of_extensions=1, initial_extensions=0x40012cc0) at > ../../../../../../rtems-4.8.0/c/src/../../cpukit/score/src/userext.c:37 > > #3 0x40007860 in rtems_initialize_executive_early > (configuration_table=0x40013930, cpu_table=0x40013908) at > ../../../../../../rtems-4.8.0/c/src/../../cpukit/sapi/src/exinit.c:152 > > #4 0x40001924 in boot_card (argc=0, argv=0x0, envp=0x0) at > ../../../../../../../../rtems-4.8.0/c/src/lib/libbsp/sparc/leon3/../../shared/bootcard.c:117 > > #5 0x400010dc in zerobss () at > ../../../../../../../../rtems-4.8.0/c/src/lib/libbsp/sparc/leon3/../../sparc/shared/start.S:339 > > #6 0x400010dc in zerobss () at > ../../../../../../../../rtems-4.8.0/c/src/lib/libbsp/sparc/leon3/../../sparc/shared/start.S:339 > > Backtrace stopped: previous frame identical to this frame (corrupt stack?) > > (gdb) p *the_heap > > $17 = {free_list = {prev_size = 0, size = 0, next = 0xfffc8040, prev = > 0xfffc8040}, page_size = 8, min_block_size = 16, begin = 0xfffc8040, end = > 0xfffd5e50, start = 0xfffc8040, final = 0xfffd5e48, stats = {instance = 0, > > size = 56848, free_size = 56840, min_free_size = 56840, free_blocks = 1, > max_free_blocks = 1, used_blocks = 0, max_search = 0, allocs = 0, searches = > 0, frees = 0, resizes = 0}} > > > > It seems to be blocked on an infinite loop. I presume there has been a > problem with the installation of rtems that I have not seen since this is a > well proven version and it is the most basic example. > > > > Would you have an idea of what the problem might be? > > > > Thanks a lot in advance, > > Patricia Lopez Cueva > > > > > > > > > _______________________________________________ > > users mailing list > > users@rtems.org > > http://lists.rtems.org/mailman/listinfo/users > > > > > _______________________________________________ > users mailing list > users@rtems.org > http://lists.rtems.org/mailman/listinfo/users _______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
