RTEMS Source Builder OpenBSD support.

From: Karel Gardas karel.gar...@centrum.cz Date: Fri, 19 Jun 2015 12:12:16 +0200 Subject: [PATCH] add basic support for OpenBSD --- source-builder/sb/openbsd.py | 92 source-builder/sb/options.py | 3 ++ 2 files changed, 95 insertions(+) create mode

RTEMS Source Builder newlib/iconv issues on OpenBSD/Solaris

Hello, on both Solaris 11 and OpenBSD 5.7 I do have an issue with source builder which fails on newlib compilation. This shows as: checking for sparc-rtems4.11-ar... sparc-rtems4.11-ar checking for sparc-rtems4.11-ranlib... sparc-rtems4.11-ranlib checking for sparc-rtems4.11-readelf...

Re: RTEMS Source Builder newlib/iconv issues on OpenBSD/Solaris

On 06/22/15 02:35 PM, Chris Johns wrote: On 22/06/2015 6:30 am, Karel Gardas wrote: Hello, on both Solaris 11 and OpenBSD 5.7 I do have an issue with source builder which fails on newlib compilation. This shows as: checking for sparc-rtems4.11-ar... sparc-rtems4.11-ar checking for sparc

Re: Potential GSoC Student

Hi Habeeb, Cortex-M4F is supported since it is used by several BSPs. Anyway, most closest to TM4C129 is probably TM4C123 which is supported by lm4f120 BSP which is a variant of lm3s69xx BSP. Search RTEMS source tree for more information... Cheers, Karel On 03/25/16 09:13 PM, Olufowobi,

Re: State of the Omniorb port for RTEMS

Hi, you can also ask on omniORB mailing list(s). http://omniorb.sourceforge.net/ Cheers, Karel On 04/28/16 09:54 PM, Sambeet Panigrahi wrote: Hi, Omniorb is an important part of the Orocos RTT that needs to be ported to RTEMS.I found that it has already been ported to RTEMS.But all sources

pc386 BSP documentation.

Hi, attached is a patch adding some pc386 BSP documentation. Review, comments, suggestions and/or commit of it are/is highly appreciated. Thanks, Karel >From 44e7ab4da6435fbf334eae5d6e68c6eb9847421c Mon Sep 17 00:00:00 2001 From: Karel Gardas Date: Tue, 25 Aug 2020 10:28:19 + Subj

Re: x86 c++ exception handling

On 9/11/20 11:12 AM, Sebastian Huber wrote: > On 11/09/2020 10:48, Heinz Junkes wrote: > >> Here is a mail I received from a colleague. >> >> It concerns thereby an "old" problem which seemed already solved? >> >> FYI. I can run the unit tests, but I'm seeing a couple of hangs. >> The first I'm

Re: x86 c++ exception handling

On 9/11/20 11:40 AM, Sebastian Huber wrote: >> If I'm not mistaken, then this is simply fixed by using other BSP's >> variant? Like pc486/pc586/pc686 ... Those optimize for different CPUs >> and gcc's lib provides necessary synchronization functions then... > The question is if there are RTEMS

pc386 BSP/master branch build failure with smp enabled.

Hello, I've built 6/rtems-i386 tools using master branch of rtems-source-builder. $ i386-rtems6-gcc -v Using built-in specs. COLLECT_GCC=i386-rtems6-gcc COLLECT_LTO_WRAPPER=/export/home/karel/sfw/rtems/6-head-2020-09-11/libexec/gcc/i386-rtems6/10.2.1/lto-wrapper Target: i386-rtems6 Configured

Re: x86 c++ exception handling

On 9/11/20 4:06 PM, Karel Gardas wrote: > One exception found is Vertex86 cpus which still sells and boards are Typo correction: Vortex86: https://en.wikipedia.org/wiki/Vortex86 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mail

Re: x86 c++ exception handling

On 9/11/20 3:13 PM, Joel Sherrill wrote: > FWIW i386 is an 80s CPU introduced in 1985. i486 was introduced > in 1989. The Pentium was 1993. Remember It's All About the Pentium! > Pentium II was 1997 and first with SMP but maybe not setting the baseline > we want. What about to support in master

Re: pc386 BSP/master branch build failure with smp enabled.

ge test time: 0:00:00.705055 Testing time : 0:07:41.811329 > > On Fri, Sep 11, 2020 at 6:54 AM Karel Gardas wrote: >> >> >> Hello, >> >> I've built 6/rtems-i386 tools using master branch of rtems-source-builder. >> >> $ i386-rtems6-gcc -v &g

Re: Determining Linux Distribution

On 9/9/20 10:30 PM, Joel Sherrill wrote: > It reports CentOS 7 as "centos" Ubuntu 18.04 -> Ubuntu and now in linux containers (if you are curious, but I would bet you get the same result on local installed system too): Ubuntu 20.04 -> Ubuntu CentOS 8 -> centos Debian 10 -> os OpenSUSE 15.2 ->

Re: Determining Linux Distribution

On 9/9/20 11:03 PM, Karel Gardas wrote: > so Debian, Kali and OpenSuSE at least are not well handled by this > script and it's quite fun since simple: Can't judge author of the script. The post is from 2008! So I guess /etc/os-release was not so wide spread among the Linuxes at tha

Re: pc386 BSP/master branch build failure with smp enabled.

On 9/12/20 9:28 AM, Karel Gardas wrote: > On 9/12/20 6:59 AM, Gedare Bloom wrote: >> On Fri, Sep 11, 2020 at 11:53 AM Karel Gardas >> wrote: >>> >>> On 9/11/20 6:16 PM, Gedare Bloom wrote: >>>> Looks to be coming through >>>>

Re: pc386 BSP/master branch build failure with smp enabled.

On 9/12/20 6:59 AM, Gedare Bloom wrote: > On Fri, Sep 11, 2020 at 11:53 AM Karel Gardas wrote: >> >> On 9/11/20 6:16 PM, Gedare Bloom wrote: >>> Looks to be coming through >>> >>> cpukit/score/cpu/i386/include/rtems/asm.h:157 movb >>> i

Re: New build system ready for testing

On 9/15/20 9:28 AM, Sebastian Huber wrote: > Maybe it is more practical if we add a table to a wiki page in which > everyone can add the BSPs which were tested with the new build system. I think this would be fantastic to have. Thanks, Karel ___ devel

Re: New build system ready for testing

On 9/15/20 9:36 AM, Sebastian Huber wrote: > On 15/09/2020 09:32, Karel Gardas wrote: > >> On 9/15/20 9:28 AM, Sebastian Huber wrote: >>> Maybe it is more practical if we add a table to a wiki page in which >>> everyone can add the BSPs which were tested with th

Re: New build system ready for testing

On 9/16/20 3:16 AM, Chris Johns wrote: > On 15/9/20 5:36 pm, Sebastian Huber wrote: >> On 15/09/2020 09:32, Karel Gardas wrote: >> >>> On 9/15/20 9:28 AM, Sebastian Huber wrote: >>>> Maybe it is more practical if we add a table to a wiki page in which >&

Re: x86 c++ exception handling

Updated patch without debugging leftover. On 9/12/20 9:41 PM, Karel Gardas wrote: > On 9/12/20 5:33 AM, Joel Sherrill wrote: >> I suspect if you want a common floor it is a Pentium II. That's where SMP >> appeared. >> >> We can't sanity check the cpu model if we don'

Re: x86 c++ exception handling

On 9/12/20 10:00 PM, Joel Sherrill wrote: > Thanks. But in case you missed my comment on the ticket. Can't find any related ticket in rtems trac. Which one is it? > The multi-lib is > built with -mtune not -march so defaults to i386 code. The file > gcc/config/i386/t-rtems needs to be changed I

Re: x86 c++ exception handling

, we may add clear error/warning about SMP being unsupported on the particular old BSP. Attached patch implements this (clear error). It basically allows --enable-smp only for pc686 and pcp4 BSPs. Comments welcome! Thanks, Karel From b8830f094d71e8624e4f58bba8a5fc74ba69bb9a Mon Sep 17 00:00:0

Re: pc386 BSP/master branch build failure with smp enabled.

On 9/12/20 5:13 PM, Gedare Bloom wrote: > nvm, I got to it today. test master when you can please :) Thanks for fast action! And master looks good: Passed:626 Failed: 7 User Input: 6 Expected Fail: 0 Indeterminate: 0 Benchmark: 3 Timeout: 5 Invalid:

Re: Contributing to rtems

On 9/14/20 6:48 PM, Gedare Bloom wrote: > Nice to see you got through that. Right now we are actually > transitioning the new build system into place. It would be great if > you can try it out now with your BSP build and report any > feedback/problems you may encounter. Where to report issues?

Re: Build fail on debian - Toolset build error

er doesn't like. > > :- type python2 > python2 is hashed > (/Library/Frameworks/Python.framework/Versions/2.7/bin/python2) > > Thanks, >   Andrew > > > >> On 12 Oct 2020, at 11:21, Karel Gardas > <mailto:karel.gar...@centrum.cz>> wrote: >>

Re: Build fail on debian - Toolset build error

On 10/12/20 3:50 PM, Anders Montonen wrote: > Hi, > >> On 12 Oct 2020, at 15:30, Karel Gardas > <mailto:karel.gar...@centrum.cz>> wrote: >> >> >> Sure, but you have to install header files whatever this means on >> macosx. On Ubuntu this means 'a

Re: Fwd: Build fail on debian - Toolset build error

On 10/12/20 12:17 PM, Andrew Butterfield wrote: > Dear all,  > I am having a problem building RTEMs master, on OS X Mojave - see below checking whether to use python... /Library/Frameworks/Python.framework/Versions/2.7/bin/python2 checking for python... no configure: error: no usable python found

WP: pc386 BSP documentation.

31 Mon Sep 17 00:00:00 2001 From: Karel Gardas Date: Tue, 25 Aug 2020 10:28:19 + Subject: [PATCH] user/pc386 BSP: add some documentation (booting on real PC HW info still missing) --- user/bsps/bsps-i386.rst | 294 +++- 1 file changed, 293 insertions(+

Re: running pc686 samples on QEMU on RTEMS 5.1?

On 9/23/20 11:02 PM, Cudmore, Alan P. (GSFC-5820) wrote: > NASA’s Core Flight System open source bundle has support for the RTEMS > 4.11 pc686 BSP. > > RTEMS is built with the following options: > > ../rtems/configure --target=i386-rtems4.11 \ > >     --enable-rtemsbsp=pc686 \ > >    

Re: pc386 BSP documentation tweaks.

On 9/21/20 7:34 PM, Gedare Bloom wrote: > On Sat, Sep 19, 2020 at 2:31 PM Karel Gardas wrote: >> >> >> Hello, >> >> attached are three patches: >> >> pc386 BSP: add runtime options for debugging and move few lines >> around for better conte

Re: pc386 BSP documentation tweaks.

On 9/21/20 7:52 PM, Gedare Bloom wrote: >> By "long gone" I mean this option is handled by configure/make and now >> also waf, but is not preserved in the C code at all. So basically the >> option does nothing as implementation C code was probably removed. >> >> Or am I looking wrong? >> > > I

libbsd master broken for pc686 BSP

Hello, I've just tried to build libbsd master branch against the pc686 BSP build from rtems master and this still does not fly and fails with: /export/home/karel/sfw/rtems/6-tools-core2/lib/gcc/i386-rtems6/10.2.1/../../../../i386-rtems6/bin/ld: ./libbsd.a(uipc_mbuf.c.25.o): in function

Re: libbsd master broken for pc686 BSP

On 9/19/20 12:15 AM, Joel Sherrill wrote: > If you really meant the master, try 6-freebsd12 instead.  > Not sure, but Christian in a thread 'How to use lvgl on pc386 BSP' analysed my report about missing input.h IIRC and concluded that I need to use master, so hence I'm here on master. > Branch

Re: How to use lvgl on pc386 BSP.

On 9/18/20 11:51 PM, Karel Gardas wrote: > Whole demo output looks: > > i386: isr=0 irr=1 > i386: isr=0 irr=1 > FB_VESA_RM frame buffer -- driver initializing.. > > > RTEMS LVGL HELLO WORLD > > nexus0: > pcib0 pcibus 0 > pci0: on pcib0 > pci0: at

Re: How to use lvgl on pc386 BSP.

Hello Christian, On 9/7/20 6:22 PM, Christian Mauderer wrote: > Depending on your application, you might want to think about switching > to the current master instead of the release. But note that I didn't > compile the PC BSP there. So I'm not sure how well it works. i386 is > normally not a

pc386 BSP documentation tweaks.

. please review/commit or request change(s). The patches are based on my playing with BSP and seeing documentation limitations or missing info bits... Thanks, Karel >From a75c0231f2252d6980dbfb7c9c0b8870efffc53b Mon Sep 17 00:00:00 2001 From: Karel Gardas Date: Sat, 19 Sep 2020 20:12:45 + Subj

Re: How to use lvgl on pc386 BSP.

On 9/19/20 10:32 AM, Christian Mauderer wrote: > Hello Karel, > > I wasn't aware that there is a framebuffer driver in the PC BSP. Yes, in fact there are three FB drivers in pc386 BSP family: - for VGA card - for Cirrus Logic GD5446 card - for VESA BIOS Extension capable graphics card The

Re: Qemu adds Host Requirement for Meson/Ninja

Not sure, I understand what's going on here, but just over the weekend build qemu git on ubuntu 20.04 lts and the only missing package in my setup was ninja which I installed with just: sudo apt install ninja IIRC, so ubuntu at least of this particular version should be easy to go... Karel

waf examples: how to modify linker flags/how to process generated exe.

Hello, I'm slowly researching amd64 BSP multiboot domain and I'm curious if it is possible based on waf BSP's options to change either (or both) linker/gcc linking options (E.g. to add -z max-page-size=1000) and or process generated exe by other tool like objcopy (to create elf32 from elf64).

Re: [PATCH] build: Place cache file in build directory

Hello Sebastian, sorry for late warning, but this patch breaks wscript on Ubuntu 20.04 LTS. It looks like bldnode is not part of the ctx variable. At least bsp_defaults and bsp_list commands are broken by it. The output looks as: $ ./waf bsp_list Traceback (most recent call last): File

Re: Out of tree builds with waf?

On 11/5/20 6:27 PM, Sebastian Huber wrote: > 2. Waf somehow remembers this configuration. You can call "./waf" to > build it. So, there must be some hidden state in the source tree. This > is not really an out of tree build. You cannot have multiple independent > build trees. When your build

amd64 bsp issue on modern Kontron/Fujitsu board: spurious interrupt 7 on attempt to remap PIC.

Hi, I'm playing with amd64/x86_64 bsp and found out it is not working on my Fujitsu/Kontron D3598-B13 boards. I do have two of this kind. One runs with W-2123 and one with W-2265 xeon. The code I'm using is 2 days old from git. The tooling too. The issue shows as: Type '?' for a list of

Re: amd64 bsp issue on modern Kontron/Fujitsu board: spurious interrupt 7 on attempt to remap PIC.

On 12/30/20 12:17 AM, Joel Sherrill wrote: > I didn't even know the x86_64 port was mature enough to run on real > hardware.  > It is, at least hello world and ticker seem to run fine! I'm hacking in multiboot support but more and more tinker with an idea to play with real uefi support. But for

Re: qemu version for source builder

On 5/7/21 8:15 AM, Richi Dubey wrote: >  So, does this qemu not support e6500 cores (for the t2080rdb platform)? IIRC e500/e5500/e6500 are supported by ppce500. Karel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

Re: qemu-system-ppc64 does not work on powerpc/qoriq_e6500_64

On 5/10/21 2:26 PM, Richi Dubey wrote: > Thanks, I'll check it out. -bios `where you do have`/u-boot.e500. Karel > > On Mon, May 10, 2021 at 10:19 AM Sebastian Huber > > wrote: > > On 09/05/2021 06:02, Richi Dubey wrote: > >

Re: About finding the bsp for qemu ( t2080rdb)

I've tried all variants IIRC of qoriq (e550/e5500/e6500) in qemu sometime ago (5.x development branch) and it booted but then was blocked on the serial port interaction and I really had no idea how to fix that. Debugger points out to the function where RTEMS asked serial port about a status and

Re: x86_64 BSP : Status Update [ticket #2898]

On 3/29/21 2:41 PM, Karel Gardas wrote: > Or! Install VirtualBox, install FreeBSD into it but before it make sure > you tick/switch on UEFI box and then install. Once done you do have FBSD > working in UEFI environment. One very important bit! You also need to tick/switch-on PAE su

Re: x86_64 BSP : Status Update [ticket #2898]

On 3/29/21 12:08 PM, Amaan Cheval wrote: > I wouldn't recommend running it on real hardware yet - I don't think > anyone has tested it on hardware. I did and reported to the mailing list. Generally speaking works on some systems (both demos: hello/ticker) and another it causes general protection

Re: x86_64 BSP : Status Update [ticket #2898]

On 3/29/21 2:41 PM, Karel Gardas wrote: > On 3/29/21 12:08 PM, Amaan Cheval wrote: >> I wouldn't recommend running it on real hardware yet - I don't think >> anyone has tested it on hardware. > > I did and reported to the mailing list. Generally speaking works on some > sy

Re: x86_64 BSP : Status Update [ticket #2898]

On 3/29/21 6:20 PM, Shashvat wrote: > I don't know if it changes the answer to the question but it was not > intended as a GSOC application. > > I just needed a project to spend some time learning about the > architecture and how BSPs are built in general. Well, if you have spare cycles, then

Re: RTEMS on PolarFire SoC ICICLE Kit FPGA

Hi Somesh, your information are very interesting. Is it possible for your to send a diff of your changes? Thanks, Karel On 4/23/21 5:52 AM, somesh deshmukh wrote: > I was able to test the rtems hello-world example and ticker example on > the polarfire soc icicle kit. > > A little background

Re: [PATCH rtems-docs] Update package list for Ubuntu

On 12/17/21 10:35 PM, Ryan Long wrote: > diff --git a/user/hosts/posix.rst b/user/hosts/posix.rst > index 818eb25..6fbf401 100644 > --- a/user/hosts/posix.rst > +++ b/user/hosts/posix.rst > @@ -137,23 +137,23 @@ prefix under your home directory as recommended and end > up on the SD card. >

Re: [PATCH rtems-docs] Update package list for Ubuntu

iously year number. Basically since LTS does not change that much or should not besides security fixes and perhaps hardware support, then you can freely use "Ubuntu 20.04.x LTS" since I guess RTEMS will not find difference between .1, .2, .3 spins of 20.04. Thanks, Karel > > On 12/

Re: [PATCH rtems-docs] Update package list for Ubuntu

On 12/17/21 10:49 PM, Karel Gardas wrote: > On 12/17/21 10:35 PM, Ryan Long wrote: >> diff --git a/user/hosts/posix.rst b/user/hosts/posix.rst >> index 818eb25..6fbf401 100644 >> --- a/user/hosts/posix.rst >> +++ b/user/hosts/posix.rst >> @@ -137,23 +137,23 @@

Re: i386 and epiphany on FreeBSD 13 for rtems 5

On 12/24/21 6:56 PM, Joel Sherrill wrote: >> Remark: looks like you will not be able to keep tools from past working >> on modern systems indefinitely which means you can also declare rtems5 >> tools support for FreeBSD 12.x max. > > Yep. > >> Or, what about to require installed gcc able to

Re: i386 and epiphany on FreeBSD 13 for rtems 5

On 12/22/21 3:51 PM, Joel Sherrill wrote: > Hi > > Both i386 and epiphany rtems 5 GCC fail to build on FreeBSD 13. It > appears that the newer compiler on FreeBSD 13 does not like some code > from the older GCC. > > Logs linked here: > > epiphany -

Re: grub2 on old Linux Distributions (at least CentOS 7)

Hi, indeed, centos 7 is bundled with gcc 4.8.5. Now, the question is, is centos 7 still supported by RTEMS? If so, then we will need to invent some machinery to check not only for commands but also for versions in cfg files? Also if we're doing this we need to check firmly we're really on old

Please ignore today's patches.

Guys, sorry for noise on the devel. Please ignore: fix compilation of dtc-1.6.0 on FreeBSD fix compilation of Grub2 on FreeBSD. emails send from karel.gar...@centrum.cz for now. I think using git format-patch -> gedit -> select all, ctrl-c -> thunderbird -> ctrl-v is no longer acceptable

Re: RSB: add GRUB2 to the tools.

Looks like attachments are not supported? Hence including patch inline. >From f66de270bba2ec3496bf3e8504bb4d1e60c52f4c Mon Sep 17 00:00:00 2001 From: Karel Gardas Date: Wed, 10 Nov 2021 19:27:22 +0100 Subject: [PATCH] add GRUB2 to the RSB RTEMS tools and use it in 6/rtems-x86_64 build

RSB: add GRUB2 to the tools.

Hi, the attach patch adds GRUB2 into the RSB RTEMS tools. Idea is to use that on amd64 BSP for building bootable images. That's also the reason why it is used only on 6/rtems-x86_64 bset only. Thanks, Karel ___ devel mailing list devel@rtems.org

Re: RSB: add GRUB2 to the tools.

On 11/10/21 11:04 PM, Chris Johns wrote: > On 11/11/21 5:32 am, Karel Gardas wrote: >> the attach patch adds GRUB2 into the RSB RTEMS tools. Idea is to use >> that on amd64 BSP for building bootable images. That's also the reason >> why it is used only on 6/rtems-x86_64 bset

[PATCH] RSB: update dtc 1.6.0 -> dtc 1.6.1

Fixes #4221 Note: the patch updates only dtc 1.6.0 occurrences. It leaves all other dtc (1.4.x) usages as they are just to not break anything which depends on older dtc versions. --- bare/config/devel/dtc-1.6.1-1.cfg | 18 ++ bare/config/devel/qemu-couverture.bset | 2 +-

[PATCH] RSB: fix hash setup for binutils 2.37

--- rtems/config/tools/rtems-binutils-2.37.cfg | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rtems/config/tools/rtems-binutils-2.37.cfg b/rtems/config/tools/rtems-binutils-2.37.cfg index dbdc38c..8cbe738 100644 --- a/rtems/config/tools/rtems-binutils-2.37.cfg +++

Re: [PATCH] RSB: add GRUB2 to the RTEMS tools and use it in 6/rtems-x86_64 build set

This patch is tested on Ubuntu 20.04, FreeBSD 13 and Mac OS X Catalina. It is not tested on Windows due to IMHO current documentation for Windows host to be either out-dated or not correct and I'm not able to follow it to even build RSB without the patch. Yes, on FreeBSD 13 the patch is tested

Re: grub2 on old Linux Distributions (at least CentOS 7)

On 11/21/21 2:21 AM, Joel Sherrill wrote: > > > On Sat, Nov 20, 2021, 6:50 PM Karel Gardas wrote: > > > Hi, > > indeed, centos 7 is bundled with gcc 4.8.5. Now, the question is, is > centos 7 still supported by RTEMS? If so, then we will need to

[PATCH] RSB: add GRUB2 to the RTEMS tools and use it in 6/rtems-x86_64 build set

--- rtems/config/6/rtems-x86_64.bset | 5 ++ rtems/config/tools/rtems-grub-2.06.cfg | 8 +++ source-builder/config/grub2.cfg| 75 ++ 3 files changed, 88 insertions(+) create mode 100644 rtems/config/tools/rtems-grub-2.06.cfg create mode 100644

Re: fix compilation of dtc-1.6.0 on FreeBSD

On 11/12/21 11:06 PM, Joel Sherrill wrote: > Thanks for the patch. Is this fixed in dtc 1.6.1? Is there any reason > not to just bump to that? One of authors let me know that exactly the same patch is in dtc 1.6.1. If nobody go ahead I plan to submit patch with update 1.6.0 -> 1.6.1 to have this

fix compilation of dtc-1.6.0 on FreeBSD

>From b6ac0c3cc24bcda262936d5c2b97ebbb9efb8951 Mon Sep 17 00:00:00 2001 From: Karel Gardas Date: Thu, 11 Nov 2021 13:39:35 +0100 Subject: [PATCH 2/3] fix compilation of dtc-1.6.0 on FreeBSD --- source-builder/config/dtc-1-1.cfg| 5 - source-builder/patches/dtc-1.

fix compilation of Grub2 on FreeBSD.

>From efa44e47a7d2f3fcb66c7bbedfd2b6e06f1cf54c Mon Sep 17 00:00:00 2001 From: Karel Gardas Date: Thu, 11 Nov 2021 13:40:03 +0100 Subject: [PATCH 3/3] fix compilation of grub2 on FreeBSD --- source-builder/config/grub2.cfg | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --

Re: QorIQ and Qemu

Hi, please look into the thread which ends here: https://www.mail-archive.com/users@rtems.org/msg02543.html I've not been able to resolve that issue at that time unfortunately. If you are lucky and resolve that, it would be great indeed! Karel On 11/10/21 12:07 AM, Joel Sherrill wrote: > Hi

Re: [PATCH 0/5] Optimize workspace/malloc initialization

Hi Sebastian, just a question. Do you plan to preserve functionality of _Heap_Extend() in the future? Asking since I'm using it for amd64/uefi bsp. During the bsp start I get efi services pointers and use that to traverse memory map. Based on available free blocks I try to allocate memory using

Re: RSB Failure

I think you are right about certs issue: download: no ssl context suggest the same probably. But, it looks like everything is fine on the server side: $ openssl s_client -connect git.rtems.org:443 CONNECTED(0003) depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1

Re: RSB Failure

On 11/30/21 5:07 PM, Ryan Long wrote: > I forgot to mention that I'm using Ubuntu21.04. It has the > ca-certificates package installed. Is there maybe another package that > it might need? This worked fine when I did a run with RTEMS 6. What does: openssl s_client -connect git.rtems.org:443 run

STM32H7 HAL update, merge ready.

Hello Sebastian, https://github.com/kgardas/rtems/tree/stm32h7-hal-update -- contains all required/recommended by you. Please recheck and merge if possible. Thanks! Karel ___ devel mailing list devel@rtems.org

Re: STM32H7 HAL update, merge ready.

On 3/10/22 14:52, Sebastian Huber wrote: On 10/03/2022 14:49, Karel Gardas wrote: On 3/10/22 14:45, Sebastian Huber wrote: On 10/03/2022 14:41, Karel Gardas wrote: On 3/10/22 13:42, Sebastian Huber wrote: On 10/03/2022 13:18, Karel Gardas wrote: Hello Sebastian, https://github.com/kgardas

Re: Apache License 2.0 all right for BSP code?

On 3/10/22 13:36, Sebastian Huber wrote: Hello, I am about to integrate the BSP update contained in this branch: https://github.com/kgardas/rtems/tree/stm32h7-hal-update It contains code from STMicroelectronics licensed under Apache License 2.0. Is this license acceptable for RTEMS

Re: STM32H7 HAL update, merge ready.

On 3/10/22 14:45, Sebastian Huber wrote: On 10/03/2022 14:41, Karel Gardas wrote: On 3/10/22 13:42, Sebastian Huber wrote: On 10/03/2022 13:18, Karel Gardas wrote: Hello Sebastian, https://github.com/kgardas/rtems/tree/stm32h7-hal-update -- contains all required/recommended by you. Please

Re: STM32H7 HAL update, merge ready.

On 3/10/22 15:06, Sebastian Huber wrote: So, the only way out of the chaos was to: 1) replace all HAL files with new files Yes, this is fine, but if all the new files have now UNIX line endings why didn't you change the existing files to UNIX line endings before the update? I guess you

Re: STM32H7 HAL update, merge ready.

On 3/10/22 13:42, Sebastian Huber wrote: On 10/03/2022 13:18, Karel Gardas wrote: Hello Sebastian, https://github.com/kgardas/rtems/tree/stm32h7-hal-update -- contains all required/recommended by you. Please recheck and merge if possible. Is there a line ending change in the STM code

Re: Apache License 2.0 all right for BSP code?

On 3/10/22 16:24, Sebastian Huber wrote: "(b) You must cause any modified files to carry prominent notices stating that You changed the files;" This means everyone changing the files need to pay attention to this. If the Apache 2.0 files don't have an SPDX license identifier, then I think

Re: STM32H7 HAL update, merge ready.

On 3/10/22 16:10, Sebastian Huber wrote: If you would like to review changes in HAL files, then you may diff original merged projects files. They both are on github.com so you can investigate either there or on local copy. But this is HAL code, something STMicro provided and I don't see any

Re: Source-builder Qemu compiling / customizing

On 2/22/22 04:54, Sam Price wrote: Im on ubuntu 18 and trying to build qemu for microblaze. I had to modify the source-builder/defaults.mc and change several tool paths from /usr/bin to /bin (This is prob not a standard build process.) Short question. What file in rtems-source builder do I

Re: [PATCH] added malloc usable size and test

Zack, not in the position of reviewing your code, but you should probably fill the template markers (, ) in the license comment below. Thanks, Karel On 3/4/22 03:49, zack leung wrote: + * SPDX-License-Identifier: BSD-2-Clause + * + * Copyright (C) ,

Re: [PATCH] add STM32H7 BSP variant to support STM32H7B3I-DK board

On 4/1/22 18:28, Sebastian Huber wrote: Hello Karel, On 01/04/2022 18:25, Karel Gardas wrote: I've tried my best in splitting patch into smaller relevant chunks. Hopefully this time you will find it more appealing for merge. Please let me know if there is still anything I shall do

[PATCH 05/14] bsp/stm32h7: add flash latency configuration

) 2022 Karel Gardas -- 2.25.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

[PATCH 11/14] bsp/stm32h7: configure oscillator for STM32H7B3xxQ (e.g. STM32H7B3I-DK BSP)

--- bsps/arm/stm32h7/start/stm32h7-config-osc.c | 17 + 1 file changed, 17 insertions(+) diff --git a/bsps/arm/stm32h7/start/stm32h7-config-osc.c b/bsps/arm/stm32h7/start/stm32h7-config-osc.c index b639c7ca36..f790201e5a 100644 --- a/bsps/arm/stm32h7/start/stm32h7-config-osc.c

[PATCH 07/14] bsp/stm32h7: configure S(D)RAM values for STM32H7B3I-DK BSP variant

Caveat: SDRAM 1 is completely disabled for now. --- spec/build/bsps/arm/stm32h7/optmemsdram1sz.yml | 5 - spec/build/bsps/arm/stm32h7/optmemsram1sz.yml | 5 - spec/build/bsps/arm/stm32h7/optmemsram2sz.yml | 5 - spec/build/bsps/arm/stm32h7/optmemsram3sz.yml | 5 -

[PATCH 12/14] bsp/stm32h7: configure peripheral clocks for STM32H7B3xxQ (e.g. STM32H7B3I-DK BSP)

--- bsps/arm/stm32h7/start/stm32h7-config-per.c | 17 + 1 file changed, 17 insertions(+) diff --git a/bsps/arm/stm32h7/start/stm32h7-config-per.c b/bsps/arm/stm32h7/start/stm32h7-config-per.c index 79aa1494dd..ce6370d3d0 100644 --- a/bsps/arm/stm32h7/start/stm32h7-config-per.c

[PATCH 13/14] bsp/stm32h7: properly ifdef all unsupported features in start -hal file while compiling for STM32H7B3I-DK BSP

--- bsps/arm/stm32h7/start/stm32h7-hal.c | 20 1 file changed, 20 insertions(+) diff --git a/bsps/arm/stm32h7/start/stm32h7-hal.c b/bsps/arm/stm32h7/start/stm32h7-hal.c index d042a5b8c9..ecd8e4218a 100644 --- a/bsps/arm/stm32h7/start/stm32h7-hal.c +++

[PATCH 08/14] bsp/stm32h7: use appropriate STM32H7B3xxQ define for STM32H7B3I-DK BSP variant

--- spec/build/bsps/arm/stm32h7/optvariant.yml | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/spec/build/bsps/arm/stm32h7/optvariant.yml b/spec/build/bsps/arm/stm32h7/optvariant.yml index 586fa2052b..5d77ece120 100644 --- a/spec/build/bsps/arm/stm32h7/optvariant.yml +++

[PATCH 09/14] bsp/stm32h7: disable ethernet for STM32H7B3I-DK BSP variant

Note: the ethernet port is not presented on the board anyway. --- bsps/arm/stm32h7/start/stm32h7-hal-eth.c | 4 1 file changed, 4 insertions(+) diff --git a/bsps/arm/stm32h7/start/stm32h7-hal-eth.c b/bsps/arm/stm32h7/start/stm32h7-hal-eth.c index b9dac6d7f9..5fc75f0147 100644 ---

[PATCH 14/14] bsp/stm32h7: bring all required changes into system_stm32h7xx for STM32H7B3I-DK BSP variant

The changes provided here are a result of a merge from various examples system_stm32h7xx.c files provided by STMicroelectronics for the STM32H7B3I-DK board with the original RTEMS file provided for the STM32H743I-EVAL2 board. --- bsps/arm/stm32h7/start/system_stm32h7xx.c | 51

[PATCH 01/14] bsp/stm32h7: add spec file for the STM32H7B3I-DK BSP variant

file mode 100644 index 00..b33bf99826 --- /dev/null +++ b/spec/build/bsps/arm/stm32h7/bspstm32h7b3i-dk.yml @@ -0,0 +1,17 @@ +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause +arch: arm +bsp: stm32h7b3i-dk +build-type: bsp +cflags: [] +copyrights: +- Copyright (C) 2022 Karel Gardas

[PATCH 02/14] bsp/stm32h7: add power supply configuration

-BY-SA-4.0 OR BSD-2-Clause +copyrights: +- Copyright (C) 2022 Karel Gardas -- 2.25.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

[PATCH 03/14] bsp/stm32h7: disable UART 5, 7, 8, 9 and USART 3, 6, 10 for STM32H7B3I-DK BSP

--- spec/build/bsps/arm/stm32h7/optenuart5.yml | 5 - spec/build/bsps/arm/stm32h7/optenuart7.yml | 5 - spec/build/bsps/arm/stm32h7/optenuart8.yml | 5 - spec/build/bsps/arm/stm32h7/optenuart9.yml | 5 - spec/build/bsps/arm/stm32h7/optenusart10.yml | 5 -

[PATCH 04/14] bsp/stm32h7: add configuration for USART1 GPIO pins, registers and alternate function

: STM32H7_USART1_ALT_FUNC +description: | + Alternate function mapping for the USART1 pin configuration. +type: build +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause +copyrights: +- Copyright (C) 2022 Karel Gardas diff --git a/spec/build/bsps/arm/stm32h7/optusart1gpiopins.yml b/spec/build/bsps/arm

[PATCH 10/14] bsp/stm32h7: configure AHB clock divider for STM32H7B3xxQ (e.g. STM32H7B3I-DK BSP)

--- bsps/arm/stm32h7/start/stm32h7-config-clk.c | 4 1 file changed, 4 insertions(+) diff --git a/bsps/arm/stm32h7/start/stm32h7-config-clk.c b/bsps/arm/stm32h7/start/stm32h7-config-clk.c index 3e7c930201..4c25241b99 100644 --- a/bsps/arm/stm32h7/start/stm32h7-config-clk.c +++

[PATCH 06/14] bsp/stm32h7: HSE clock value configuration for STM32H7B3I-DK BSP variant

--- spec/build/bsps/arm/stm32h7/opthse.yml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/spec/build/bsps/arm/stm32h7/opthse.yml b/spec/build/bsps/arm/stm32h7/opthse.yml index 51366932e1..e5feef1114 100644 --- a/spec/build/bsps/arm/stm32h7/opthse.yml +++

Re: [PATCH] add STM32H7 BSP variant to support STM32H7B3I-DK board

On 4/1/22 18:45, Joel Sherrill wrote: The issues on Github with respect to the STMicroelectronics licensing ended up on a TODO list. Is this in reference to their Ultimate Liberty License? Is the TODO item to get clarification from them? Hopefully change it? No, this is a reference

Re: [PATCH] add STM32H7 BSP variant to support STM32H7B3I-DK board

Hello Sebastian, I've tried my best in splitting patch into smaller relevant chunks. Hopefully this time you will find it more appealing for merge. Please let me know if there is still anything I shall do. Thanks! Karel On 2/7/22 07:39, Sebastian Huber wrote: Hello Karel, [...]

  1   2   3   4   >