Re: RSB Couverture-Qemu build queries
> Please try and let me know if it is ok so I can push to master:
It worked! Everything's perfect now. Thanks Chris.
On 19 June 2017 at 23:19, Jiri Gaisler wrote:
>
>
> On 06/17/2017 10:28 AM, Cillian O'Donnell wrote:
>> On 16 June 2017 at 22:00, Jiri Gaisler wrote:
>>> Hi Cillian,
>>>
>>> the gaisler.org server is currently down due to a power problem last
>>> week. I am in the Caribbean at the moment so I can't fix it until
>>> Tuesday next week. I suggest you skip the LEON3 patches until I fix the
>>> server next week. Let me know if you get problems merging the patches,
>>> and I will try to sort it out.
>>>
>>> Jiri.
>>>
>> Ok, thanks for letting me know Jiri. I'll leave the patches till
>> Tuesday and see If I can put them back together and get them merged
>> then. Thanks Joel, I've been talking with Fabien Chouteau from the
>> Couverture project, I'll reach out to him with the patches and cc you
>> and Chris and thanks Gedare for the info.
>
> gaisler.org is up again, so you can download the patches. Let me know if
> you need help merging them.
>
> Jiri.
Great! I'll get to work on the patches today. Thanks Jiri.
>
>>
>>> On 06/16/2017 03:13 PM, Cillian O'Donnell wrote:
Hi,
I am getting the RSB to build Couverture-Qemu and I just want to check
a few things I have done so far.
1. There are about 5 patches applied to the current qemu build. Only
one of which applies cleanly to the Couverture build. Do you want me
to try and fix these up, comment them out and leave a note for
whoever wants to fix them or remove them completely? The patches that
don't work are:
%patch add qemu
pw://patchwork.ozlabs.org/patch/406903/raw/Provide-the-missing-LIBUSB_LOG_LEVEL_-for-older-libusb-or-FreeBSD.-Providing-just-the-needed-value-as-a-defined..patch
%patch add qemu
https://gaisler.org/qemu/0001-LEON3-Add-emulation-of-AMBA-plug-
play.patch
%patch add qemu
https://gaisler.org/qemu/0002-LEON3-Build-AMBA-plug-and-play-records-from-high-lev.patch
%patch add qemu
https://gaisler.org/qemu/0003-LEON3-Init-UART-timers-and-CPU-if-we-run-a-RAM-image.patch
2. For this source setting section, is the first part just dealing
with the case were this a packaged release so a tar of the download is
already included with it?
%if %{rsb_released} && %{!defined without_release_url}
%source set qemu
%{rtems_release_url}/%{rtems_version}/sources/qemu-git-42d58e7.tar.xz
%else
%source set qemu
https://github.com/AdaCore/qemu/archive/%{qemu_version}.tar.gz
%endif
3. What does the -q option do in the %prep section of the build, this
option shows up in examples in the docs but there is no description of
what it does?
%source setup qemu -q -n qemu-%{qemu_version}
4. The current qemu build is configured with the default setting to
build for all architectures but most of the arch's aren't used by
RTEMS and/or don't have machine support for same bsps, so I've added a
--target-list to only build the targets that have a corresponding bsp
(sparc64-softmmu is missing as it runs into build issues, I forgot to
mention in the initial results). However the list spills over 80 lines
so should I make a %{qemu_targets} macro and if so where should I put
it?
--make=%{__make} \
72
--target-list=arm-softmmu,i386-softmmu,lm32-softmmu,mips-softmmu,ppc-softmmu,sparc-softmmu
\
73 ${VDE_CONFIG} \
74 --disable-smartcard-nss \
Thanks,
Cillian.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] bsps: Improve interrupt vector enable/disable API
On 20/06/17 07:44, Sebastian Huber wrote: On 20/06/17 02:51, Chris Johns wrote: On 19/06/2017 23:19, Sebastian Huber wrote: Change bsp_interrupt_vector_enable() and bsp_interrupt_vector_disable() to not return a status code. Add bsp_interrupt_assert() and use it to validate the vector number in the vector enable/disable implementations. Thank you for the quick turn around on the change. It is impressive. OK to push with Gedare's minor changes. I will build everything once pushed. m68k no longer builds with this change due to: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81132 https://git.rtems.org/rtems-source-builder/commit/?id=34a310344cd357afbb236c55b748392ce3f1cbdb -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RISC-V/HiFive memory limitations
On Jun 20, 2017 1:20 AM, "Denis Obrezkov" wrote: 2017-06-20 4:00 GMT+03:00 Joel Sherrill : > > > On Jun 19, 2017 5:37 PM, "Denis Obrezkov" wrote: > > 2017-06-20 1:23 GMT+03:00 Hesham Almatary : > >> >> >> On Tue, Jun 20, 2017 at 7:33 AM, Denis Obrezkov >> wrote: >> >>> 2017-06-20 0:19 GMT+03:00 Joel Sherrill : >>> Check the value in gdb without loading it on a target. Gdb hello.exe p symbol >>> Since it is a constant, it should be as expected. If it is, you have a code loading issue. >>> Yes, it is 512 in gdb, as expected. So, is the problem with linkcmd >>> file? >>> Is that value by any chance an instruction? >>> No don't think so. >> >> >>> How to check whether it is an instruction or not? >>> >>> You can check if this value might match with any riscv32 instruction >> encodings (I believe it doesn't). See Chapter 19 (RV32/64G Instruction Set >> Listings) user-level riscv-spec 2.3-draft. You can also use >> riscv32-rtems4.12-objdump on your binary and search for this value. >> >> I was also able to run gdb, connect to the target, change the value of >>> the variable to 512, >>> reconnect to the target, make loading and read the value equal to 512. >>> >>> >>> >>> -- >>> Regards, Denis Obrezkov >>> >> >> >> >> -- >> Hesham >> > > I didn't find this value in objdump > I think that .data section wasn't properly initialized, does it look > reasonable? > > > I suspect it means that the image is not properly loaded into memory. > Download but don't execute. Then check the address. > > If it correct on download, then binary search with breakpoints and > checking the memory. Or set a hardware watchpoint on a write to that > address. > > Hesham.. does the crt code have to copy a secondary copy of the .data > initial values into place on this bsp? > > > > -- > Regards, Denis Obrezkov > > > The wrong value is present right after loading, before the execution. That sounds like either a memory map problem, a download format problem or something more bizarre. Can you run programs compiled with the bare elf toolset? If so, then there is a discrepancy between your linkcmds, download format, etc from the bare metal toolset. -- Regards, Denis Obrezkov ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RISC-V/HiFive memory limitations
2017-06-20 16:29 GMT+03:00 Joel Sherrill : > > > On Jun 20, 2017 1:20 AM, "Denis Obrezkov" wrote: > > 2017-06-20 4:00 GMT+03:00 Joel Sherrill : > >> >> >> On Jun 19, 2017 5:37 PM, "Denis Obrezkov" >> wrote: >> >> 2017-06-20 1:23 GMT+03:00 Hesham Almatary : >> >>> >>> >>> On Tue, Jun 20, 2017 at 7:33 AM, Denis Obrezkov >> > wrote: >>> 2017-06-20 0:19 GMT+03:00 Joel Sherrill : > Check the value in gdb without loading it on a target. > > Gdb hello.exe > > p symbol > > Since it is a constant, it should be as expected. If it is, you have a > code loading issue. > Yes, it is 512 in gdb, as expected. So, is the problem with linkcmd file? > > Is that value by any chance an instruction? > No don't think so. >>> >>> How to check whether it is an instruction or not? You can check if this value might match with any riscv32 instruction >>> encodings (I believe it doesn't). See Chapter 19 (RV32/64G Instruction Set >>> Listings) user-level riscv-spec 2.3-draft. You can also use >>> riscv32-rtems4.12-objdump on your binary and search for this value. >>> >>> I was also able to run gdb, connect to the target, change the value of the variable to 512, reconnect to the target, make loading and read the value equal to 512. -- Regards, Denis Obrezkov >>> >>> >>> >>> -- >>> Hesham >>> >> >> I didn't find this value in objdump >> I think that .data section wasn't properly initialized, does it look >> reasonable? >> >> >> I suspect it means that the image is not properly loaded into memory. >> Download but don't execute. Then check the address. >> >> If it correct on download, then binary search with breakpoints and >> checking the memory. Or set a hardware watchpoint on a write to that >> address. >> >> Hesham.. does the crt code have to copy a secondary copy of the .data >> initial values into place on this bsp? >> >> >> >> -- >> Regards, Denis Obrezkov >> >> >> The wrong value is present right after loading, before the execution. > > > That sounds like either a memory map problem, a download format problem or > something more bizarre. > > Can you run programs compiled with the bare elf toolset? If so, then there > is a discrepancy between your linkcmds, download format, etc from the bare > metal toolset. > > > > -- > Regards, Denis Obrezkov > > > Ok, then I will try to adapt the default linkcmd file today. -- Regards, Denis Obrezkov ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Fix beagle bsp irq issue
The latest RTEMS should work without this patch on the BBB. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS-libbsd copyright question
On 19/06/17 15:45, Sichen Zhao wrote: Ok, so i think most of my ported file shouldn't add copyright. But some file in the rtemsbsd folder , i think i modified some new code. The link is below: https://github.com/hahchenchen/rtems-libbsd/blob/usb2.0/rtemsbsd/include/bsp/nexus-devices.h#L49 https://github.com/hahchenchen/rtems-libbsd/blob/usb2.0/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h#L260 It would be easier to look at patches, so that you can see what is actually changed. In general, changes in the "freebsd" subdirectory should be as small and mechanical as possible. There should be simply nothing to do that deserves a copyright. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] bsps: Improve interrupt vector enable/disable API
On 20/06/2017 22:39, Sebastian Huber wrote: > On 20/06/17 07:44, Sebastian Huber wrote: > >> On 20/06/17 02:51, Chris Johns wrote: >> >>> On 19/06/2017 23:19, Sebastian Huber wrote: Change bsp_interrupt_vector_enable() and bsp_interrupt_vector_disable() to not return a status code. Add bsp_interrupt_assert() and use it to validate the vector number in the vector enable/disable implementations. >>> Thank you for the quick turn around on the change. It is impressive. >>> >>> OK to push with Gedare's minor changes. I will build everything once pushed. >> >> m68k no longer builds with this change due to: >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81132 > > https://git.rtems.org/rtems-source-builder/commit/?id=34a310344cd357afbb236c55b748392ce3f1cbdb > $ rtems-bsp-builder \ --rtems-tools=/build/rtems/tools/4.12 \ --rtems=/opt/work/chris/rtems/kernel/rtems.git \ --log=all-tests \ --profile=everything \ --build=tests --jobs=7/6 All passed. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
GDB 8.0 build on FreeBSD 11
Hello, I tried to build GDB 8.0 on FreeBSD 11. It didn't work similar to: https://sourceware.org/ml/gdb/2017-02/msg00061.html The corresponding bug was resolved as invalid: https://sourceware.org/bugzilla/show_bug.cgi?id=21206 We still have a GDB patch for this issue in the RSB for 7.12. Now I am a bit confused. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
