Date   

[PATCH 00/10] Add SMP support for r8a7743

Biju Das <biju.das@...>
 

This patch series aims to add SMP support for r8a7743 SoC.

It is tested against linux-v4.4.112-cip18

Biju Das (4):
ARM: shmobile: Add pm support for r8a7743
dt-bindings: apmu: Document r8a7743 support
ARM: dts: r8a7743: Add APMU node and second CPU core
ARM: dts: r8a7743: Add OPP table for frequency scaling

Geert Uytterhoeven (4):
ARM: shmobile: apmu: Move #ifdef CONFIG_SMP to cover more functions
ARM: shmobile: apmu: Add debug resource reset for secondary CPU boot
ARM: shmobile: apmu: Allow booting secondary CPU cores in debug mode
ARM: dts: r8a7743: Add missing clock for secondary CA15 CPU core

Magnus Damm (2):
ARM: shmobile: apmu: Add APMU DT support via Enable method
devicetree: bindings: Renesas APMU and SMP Enable method

Documentation/devicetree/bindings/arm/cpus.txt | 1 +
.../devicetree/bindings/power/renesas,apmu.txt | 29 +++++++
arch/arm/boot/dts/r8a7743.dtsi | 25 ++++++
arch/arm/mach-shmobile/platsmp-apmu.c | 94 +++++++++++++++++++++-
arch/arm/mach-shmobile/pm-rcar-gen2.c | 3 +
5 files changed, 150 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/power/renesas,apmu.txt

--
2.7.4


Re: [PATCH] Dockerfile: add iproute2

Daniel Wagner <daniel.wagner@...>
 

Hi Daniel,

On 01/29/2018 09:31 AM, Daniel Sangorrin wrote:
runqemu requires /sbin/ip

Signed-off-by: Daniel Sangorrin <daniel.sangorrin@...>
Patch applied on next. If the test build is fine I'll apply it on master.

Thanks,
Daniel

---
Dockerfile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Dockerfile b/Dockerfile
index dbadb55..30fac76 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -15,7 +15,7 @@ RUN apt-get update && \
tar bzip2 curl dosfstools mtools parted \
syslinux tree python3-pip bc python3-yaml \
lsb-release python3-setuptools ssh-client \
- vim less mercurial && \
+ vim less mercurial iproute2 && \
echo 'deb http://deb.debian.org/debian stretch main' >> /etc/apt/sources.list.d/backports.list && \
apt-get update && \
apt-get install -y -f --no-install-recommends --target-release stretch \


Releasing draft of private GitHub cip-b_at_d-generic repo

_nobody_ _nobody_ <nobodyless@...>
 

Hello to the CIP Community,

Here is the first release of my private copy of well known GitLab
board-at-desk-single-dev (I found it also on GitHub:
https://github.com/cip-testing/board-at-desk-single-dev).

The web pointer to it: https://github.com/ZoranStojsavljevic/cip-b_at_d-generic

There are few reasons why I have decided to clone it to my own private
repo (cip-b_at_d-generic):
https://github.com/ZoranStojsavljevic/cip-b_at_d-generic. One of them
is that I everyday try to fix and enhance this repo, so no time to
communicate each and every small change to the community, since it is
very time consuming. The other reason is that I experiment with th new
releases of the Fedora (host I am using) and RubyGem packages, so I
also added to the repo the new Vagrantfile script for the --provider
libvirt, as experimental release, which is, as by the time I write
this email, still very unstable (and port forwarding, for some to me
unknown reason, does not work yet). This is aside project I am doing,
outsile of the hours, which are dedicated for the --provider
VirtualBox testing (as initially intended).

Let me do the brief explanation what are the files in the root of the projects:

importbox.sh.genesis <<======= original script for the reference
importbox.sh <<============= modified script which replaces original
one, serving to two providers
info_vbox.sh <<============= sync script which gives exact global
status of the whole system, for both Virtual Boxes and Vagrant,
managing Virtual Boxes
Vagrantfile.libvirt <<========== generic vagrant --provider libvirt
Vagrantfile config [experimental phase presently]
Vagrantfile.virtualbox <<======= generic vagrant --provider virtualbox
Vagrantfile config

Please, do note the following: both Virtual Box and libvirt are NOT
aware that there is client above them, managing them, in other words,
vagrant has one way relations with providers, so things can very
easily slip out of sync.

The another important thing done here is strategy called: "divide and
conquer", since I decided to manage one provider pre one Vagrantfile
config (Hashicorp promised long time ago to have more than one
provider in single Vagrantfile seamlessly working, but this is NOT, so
far (and still far away, seems) achieved, so upon splitting the
providers (only two so far) some of the vagrant instabilities went
away).

Do not forget, vagrant ALWAYS manages Virtual Box first, then takes on
other providers (if it does detect them in Vagrantfile).

From today I'll concentrate to start adding some more scripts into
Virtual Box part, to make CIP testing more integrated. It will be done
also using this/my repo, since all of this is not yet rock solid
proven (me and Robert Marshall can later agree what makes sense to
integrate to the main CIP testing project).

All the suggestions, addendums, criticism, improvements etc. will be
carefully considered. Please, do not hesitate to take the action, ask
questions (if anything unclear, buggy, etc.) since any input is very
welcome!

Thank you all,
Zoran Stojsavljevic


[PATCH] Dockerfile: add iproute2

Daniel Sangorrin <daniel.sangorrin@...>
 

runqemu requires /sbin/ip

Signed-off-by: Daniel Sangorrin <daniel.sangorrin@...>
---
Dockerfile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Dockerfile b/Dockerfile
index dbadb55..30fac76 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -15,7 +15,7 @@ RUN apt-get update && \
tar bzip2 curl dosfstools mtools parted \
syslinux tree python3-pip bc python3-yaml \
lsb-release python3-setuptools ssh-client \
- vim less mercurial && \
+ vim less mercurial iproute2 && \
echo 'deb http://deb.debian.org/debian stretch main' >> /etc/apt/sources.list.d/backports.list && \
apt-get update && \
apt-get install -y -f --no-install-recommends --target-release stretch \
--
2.7.4


About adding /sbin/ip to KAS

Daniel Sangorrin <daniel.sangorrin@...>
 

Hi Daniel (Wagner)

I am trying to use poky/scripts/runqemu from KAS for cip-core
but it seems that /sbin/ip needs to be present

[PATCH] Dockerfile: add iproute2

# Sorry, I can't access kas-devel mailing list because it's blocked
by our proxy.

Thanks,
Daniel


Re: [ANNOUNCE] 4.4.112-cip18-rt11

Daniel Wagner <wagi@...>
 

You can get this release via the git tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git
My scripts still need some love. The tree is here

git://git.kernel.org/pub/scm/linux/kernel/git/wagi/linux-cip-rt.git


[ANNOUNCE] 4.4.112-cip18-rt11

Daniel Wagner <daniel.wagner@...>
 

Hello CIP RT Folks!

I'm pleased to announce the 4.4.112-cip18-rt11 stable release.

You can get this release via the git tree at:

git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

branch: v4.4-rt
Head SHA1: 92b397fd34fac354e00f1ffdd51e2121e01a5ee5

Or to build 4.4.112-cip18-rt11 directly, the following patches should be applied:

http://www.kernel.org/pub/linux/kernel/v4.x/linux-4.4.tar.xz

http://www.kernel.org/pub/linux/kernel/v4.x/patch-4.4.112-cip18.xz

http://www.kernel.org/pub/linux/kernel/people/wagi/cip-rt/4.4/patch-4.4.112-cip18-rt11.patch.xz

Enjoy!
Daniel


Linux 4.4.112-cip18

Ben Hutchings <ben.hutchings@...>
 

I've released Linux version 4.4.112-cip18.  A summary of the changes
since 4.4.105-cip15:

- Merge fixes from stable versions 4.4.106-4.4.112 inclusive
- Includes mitigation for Meltdown on x86_64 only
- Apply related fixes to hpsa driver and deadline scheduler
- Fix regressions in nfsd, x86 microcode loader, and x86_64 vsyscall
- Fix r8a7743 watchdog timer clock definition

I also tagged intermediate versions 4.4.109-cip16 and 4.4.112-cip17.

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


Re: [PATCH] ARM: shmobile: r8a7743: Fix Watchdog timer clock

Chris Paterson
 

Hello Ben,

From: Ben Hutchings [mailto:ben.hutchings@...]
Sent: 24 January 2018 22:02

On Tue, 2018-01-09 at 11:48 +0000, Chris Paterson wrote:
R8A7743_CLK_RWDT should be 2 as specified in the hardware manual.
This macro doesn't seem to be used in any in-tree device trees.
You're right; it isn't at the moment.

At some point in the future we'll be adding support for RWDT to the iwg20m, so I thought I'd get this fix submitted now before I forgot.

Should it be?
If we weren't planning to use it - good question!

I guess usually a fix like this would come down the v4.4 LTS route? But as this file has been added directly to CIP this won't happen.

Presumably similar bug fix patches will have to be directly applied to CIP Kernels in the future anyway (once LTS support has ended), even if there is no known use case. There may be users of the CIP Kernel that we aren't aware of?


I've applied this anyway.
Thank you!

Kind regards, Chris


Ben.

Fixes: 9683f2eba952bc0d ("ARM: shmobile: r8a7743: Add clock index
macros for DT sources")
Reported-by: Thong Ho <thong.ho.px@...>
Signed-off-by: Chris Paterson <chris.paterson2@...>
---
 include/dt-bindings/clock/r8a7743-clock.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/dt-bindings/clock/r8a7743-clock.h
b/include/dt-bindings/clock/r8a7743-clock.h
index a5c7e387e66dfd55..53f54dfce59245d8 100644
--- a/include/dt-bindings/clock/r8a7743-clock.h
+++ b/include/dt-bindings/clock/r8a7743-clock.h
@@ -71,7 +71,7 @@
 #define R8A7743_CLK_USBDMAC1 31
 /* MSTP4 */
-#define R8A7743_CLK_RWDT 4
+#define R8A7743_CLK_RWDT 2
 #define R8A7743_CLK_USB_DDM 6
 #define R8A7743_CLK_IRQC 7
 #define R8A7743_CLK_INTC_SYS 8
--
Ben Hutchings
Software Developer, Codethink Ltd.


Re: [PATCH] ARM: shmobile: r8a7743: Fix Watchdog timer clock

Ben Hutchings <ben.hutchings@...>
 

On Tue, 2018-01-09 at 11:48 +0000, Chris Paterson wrote:
R8A7743_CLK_RWDT should be 2 as specified in the hardware manual.
This macro doesn't seem to be used in any in-tree device trees. Should
it be?

I've applied this anyway.

Ben.

Fixes: 9683f2eba952bc0d ("ARM: shmobile: r8a7743: Add clock index macros for DT sources")
Reported-by: Thong Ho <thong.ho.px@...>
Signed-off-by: Chris Paterson <chris.paterson2@...>
---
 include/dt-bindings/clock/r8a7743-clock.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/dt-bindings/clock/r8a7743-clock.h b/include/dt-bindings/clock/r8a7743-clock.h
index a5c7e387e66dfd55..53f54dfce59245d8 100644
--- a/include/dt-bindings/clock/r8a7743-clock.h
+++ b/include/dt-bindings/clock/r8a7743-clock.h
@@ -71,7 +71,7 @@
 #define R8A7743_CLK_USBDMAC1 31
 /* MSTP4 */
-#define R8A7743_CLK_RWDT 4
+#define R8A7743_CLK_RWDT 2
 #define R8A7743_CLK_USB_DDM 6
 #define R8A7743_CLK_IRQC 7
 #define R8A7743_CLK_INTC_SYS 8
--
Ben Hutchings
Software Developer, Codethink Ltd.


Re: Do we have bug in the Vagrantfile @ https://gitlab.com/rajm/board-at-desk-single-dev/blob/master/Vagrantfile

_nobody_ _nobody_ <nobodyless@...>
 

Copy that, Robert.

Please, to all: watch out for failing plugins, for both vagrant 1.9.8
and vagrant 2.0.1:
https://github.com/hashicorp/vagrant/issues/8948
https://github.com/hashicorp/vagrant/issues/9388
https://github.com/hashicorp/vagrant/issues/9396 <<== Zoran's issue

I have sorted out issues with Virtual Box: for Virtual Box I do not
see this problem (as they claim in #8948), and here I am using
advanced Virtual Box version 5.2.6 and Vagrant version 2.0.1.

I need to work on this Vagrant stabilization more... Most people are
using so far Virtual Box as provider.

Zoran Stojsavljevic

On Tue, Jan 23, 2018 at 9:47 AM, Robert Marshall
<robert.marshall@...> wrote:
_nobody_ _nobody_ <nobodyless@...> writes:

Hello to the list,

This @ is insignificant, but we need to know if this is the typo in
the comment (seems like that, although for host it could be both 8080
or 80 values).

File: https://gitlab.com/rajm/board-at-desk-single-dev/blob/master/Vagrantfile

43: # Forward port 80 for the http Lava Frontend Web Server <<= PORT 80
44: config.vm.network :forwarded_port, guest: 8080, host: 8080

Please, do note that I use my backup @, since I am (on my main
first.last@...) already on three Open Source mailing lists
(although I should say, traffic on this one is very low). ;-)

Thank you,
Zoran Stojsavljevic
Zoran

Well spotted, I've added an issue for this so that it doesn't get lost!
https://gitlab.com/cip-project/cip-testing/testing/issues/171

Robert
_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: Do we have bug in the Vagrantfile @ https://gitlab.com/rajm/board-at-desk-single-dev/blob/master/Vagrantfile

Robert Marshall <robert.marshall@...>
 

_nobody_ _nobody_ <nobodyless@...> writes:

Hello to the list,

This @ is insignificant, but we need to know if this is the typo in
the comment (seems like that, although for host it could be both 8080
or 80 values).

File: https://gitlab.com/rajm/board-at-desk-single-dev/blob/master/Vagrantfile

43: # Forward port 80 for the http Lava Frontend Web Server <<= PORT 80
44: config.vm.network :forwarded_port, guest: 8080, host: 8080

Please, do note that I use my backup @, since I am (on my main
first.last@...) already on three Open Source mailing lists
(although I should say, traffic on this one is very low). ;-)

Thank you,
Zoran Stojsavljevic
Zoran

Well spotted, I've added an issue for this so that it doesn't get lost!
https://gitlab.com/cip-project/cip-testing/testing/issues/171

Robert


Do we have bug in the Vagrantfile @ https://gitlab.com/rajm/board-at-desk-single-dev/blob/master/Vagrantfile

_nobody_ _nobody_ <nobodyless@...>
 

Hello to the list,

This @ is insignificant, but we need to know if this is the typo in
the comment (seems like that, although for host it could be both 8080
or 80 values).

File: https://gitlab.com/rajm/board-at-desk-single-dev/blob/master/Vagrantfile

43: # Forward port 80 for the http Lava Frontend Web Server <<= PORT 80
44: config.vm.network :forwarded_port, guest: 8080, host: 8080

Please, do note that I use my backup @, since I am (on my main
first.last@...) already on three Open Source mailing lists
(although I should say, traffic on this one is very low). ;-)

Thank you,
Zoran Stojsavljevic


Today's CIP News

Maemalynn Meanor <maemalynn@...>
 

CIP Community: 

Today, the CIP project announced Moxa has joined as a Silver Member. You can view the full press release here: https://www.cip-project.org/announcement/2018/01/18/industry-leader-moxa-joins-civil-infrastructure-platform-project

Please share this news with your social networks. Sample promotions are below. 


welcome @moxainc to the @cip_project! We look forward to working with you to develop an #interoperable #opensource platform that is #secure, #reliable #sustainable for more than 10 years: http://bit.ly/2DhwOx0 

.@cip_project welcomes @moxainc as a silver member that will #collaborate with other industry leaders to create a reliable, secure, #Linux based #embedded #software platform: http://bit.ly/2DhwOx0 #industrial

LinkedIn or Facebook: 
Today, the Civil Infrastructure Platform (CIP) project welcomes Moxa as a Silver Member. The membership strengthen’s Moxa’s commitment to building smart cities and offers CIP additional leadership to help develop industrial grade open source software. http://bit.ly/2DhwOx0 

Thanks for your help in spreading the great news!
Maemalynn

Maemalynn Meanor
PR Manager 
The Linux Foundation
Maemalynn@...
(602) 541-0356
Skype: Maemalynn






Re: [ANNOUNCE] Linux 4.4.15-cip15-rt10

Daniel Wagner <daniel.wagner@...>
 

On 01/11/2018 05:51 PM, Ben Hutchings wrote:
On Thu, 2018-01-11 at 09:07 +0100, Daniel Wagner wrote:
Good morning everyone,

On 01/10/2018 06:32 PM, Sebastian Andrzej Siewior wrote:
[...]
Daniel: you have the release currently in a git tree within his "user"
namespace and did not upload it to k.o. Do you plan upload it to the
stable-rt tree like Julia does and upload it to the "projects/rt/4.4"
folder on k.o.? If so we might just add a link to the cip wiki next to
4.4 and be done with it.
Steven will ask the k.o folks to give me permission to upload to
projects/rt/4.4. In short nothing should change for 4.4-rt support as
long Greg is releasing 4.4.

As for 4.4-cip(-rt), it might make sense to have a project/cip shared
folder with the 4.4-cip and 4.4-cip-rt tree.

Ben, what's your stand on this?
No-one's asked for tarballs and patches, so I don't really want to add
that step to the release process.
Fair enough ;)


Re: Meltdown and Spectre in CIP

Chris Paterson
 

Hello Ben,

Thank you for the summary.

From: cip-dev-bounces@... [mailto:cip-dev-
bounces@...] On Behalf Of Ben Hutchings
Sent: 10 January 2018 14:17

I expect that everyone's heard about the above security issues and I
understand there have been questions about how and when these will be
addressed in CIP.

My thinking is that for these are *not* serious issues for embedded systems,
though they do weaken the "defence in depth" that is normally provided by
memory protection and user privilege separation.  We do need to get fixes
out, but not urgently.

(When we discussed kernel configurations and maintainability, there was
consensus that no-one using KVM was relying on it being secure against
malicious guests - the guests were trusted.)

This is the current status of mitigations for these issues, as I understand it:

Meltdown:
- arm 32-bit: Not affected? (ARM reports that only the Cortex-A75 is
affected, but I haven't seen information from other architecture
licensees.)
ARM also lists that meltdown subvariant '3a' affects some arm 32-bit processors [1], but say that "In general, it is not believed that software mitigations for this issue are necessary".

The whitepaper ARM link to [2] implies that ARM don't think this is an issue worth worrying about as the information that can be obtained from the system registers is "not material".

Have you heard/seen anything to contradict this statement?


- x86 32-bit: Not fixed, no plans to fix. There are two affected
configurations that I'm aware of: Siemens' i386-rt and iot2000.
I doubt that the Quark processor in iot2000 is affected.
- x86 64-bit: Fully mitigated in mainline and 4.4-stable.

Spectre: will be mitigated in mainline, but still under discussion.
Based on what I've seen, I expect that it will be possible to backport most of
these to 4.4.
Will you be keeping an eye on Spectre patches on behalf of CIP as part of your maintainer role? I guess you may be in the loop a bit more than the rest of us?


[1] https://developer.arm.com/support/security-update
[2] https://developer.arm.com/support/security-update/download-the-whitepaper

Kind regards, Chris


My name is

Lynne <cristina@...>
 


My name is  Lynne Brown, Minister of Public Enterprises  I have an Investment proposal for you 


You can view my profile on my website http://www.gov.za/about-government/leaders/profile/1521 and read about me.


Get back to me on my secure Email: LNN.BROWN@...

Regards





Re: B@D: iwg20m support

Trung. Huynh <trung.huynh.uw@...>
 

Dear Daniel

-----Original Message-----
From: Daniel Sangorrin [mailto:daniel.sangorrin@...]
Sent: Thursday, January 11, 2018 12:50 PM
To: Trung. Huynh <trung.huynh.uw@...>
Cc: cip-dev@...; O365-Chan Duc. Vu <chan.vu.xv@...>; O365-Minh Thuy Dinh. Tran <minh.tran.xc@...>; O365-Anh The. Tran <anh.tran.jc@...>; Binh Thanh. Nguyen <binh.nguyen.uw@...>; O365-Yoshinori Kaneko <yoshinori.kaneko.xg@...>; O365-Yasushi Onishi <yasushi.onishi.xc@...>
Subject: RE: [cip-dev] B@D: iwg20m support

Dear Trung san,

-----Original Message-----
From: Trung. Huynh [mailto:trung.huynh.uw@...]
..

Please let me confirm just in case. Am I right if I say that you
plan to you submit not only the kernel configuration flags but also test dependency definitions to cip core, and the corresponding yaml files for B@D?.
If that's correct I will be glad to accept them.
Yes, we would love to be apart in B@D with our contribution for who need to take our test suites as a testing plan.
We do not promise this is to become excellent suites but we do our
best to have a good things that somebody to think about at first
OK, that's great!

Regarding shmobile_defconfig, attachment shows up for you.
Thanks, you only changed these flags right?
CONFIG_BLK_DEV_RAM_SIZE=250000
CONFIG_BLK_DEV_RAM_COUNT=4
You're right, the cip-core I pulled down from global site without
changing anything, it just be changed those flags and built under standalone of Linaro's cross compiler.
I just realized that you might be using the wrong branch of cip-core. You should be using the "master" branch not the "jethro"
one which was used and frozen for the cip-core release and the quickstart wiki page (the master branch depends on "morty").
The jethro branch was using a non-official CIP kernel repository (https://github.com/renesas-rz/renesas-cip) but on the master branch we are using the official CIP kernel. For that reason, shmobile_defconfig on the main branch is different and some drivers have not been merged yet.
Please could you check which branch you are using?
Is v4.4.55-cip3 the "Jethro" one? Because I saw this is the build I was use.


I have added your kernel configuration changes:
https://gitlab.com/cip-project/cip-core/commit/c1efa6325909815731abe0b69ec7e19e2e56aee7
Please let me know if that works for you.
Anyway, let get back to master branch with flags from your suggestion, the issue seems get to worse than previous one:
After uboot pull necessary packages on RAM up, it get stuck at:

Starting kernel ...

Nothing print out after this, so we didn't explore what occurring
I also tried to test with v4.4.83-cip8 if any possibility to solve the problem but same things


Could you show me how you built cip-core using Linaro's cross compiler?
By the way, cip-core builds its own toolchain, are you using Linaro's to reduce build time?
In circle development process, we build up our target packages by Yocto
But for this cip-core testing with B@D, I'm using the compiler which to be installed via Ubuntu's repository:
gcc version 4.8.4 (Ubuntu/Linaro 4.8.4-2ubuntu1~14.04.1)


Thanks,
Daniel

-----Original Message-----
From: cip-dev-bounces@...
[mailto:cip-dev-bounces@...] On Behalf Of
Daniel Sangorrin
Sent: Tuesday, December 19, 2017 8:40 AM
To: 'Daniel Wagner' <daniel.wagner@...>
Cc: cip-dev@...
Subject: Re: [cip-dev] B@D: iwg20m support

Dear Daniel Wagner,

-----Original Message-----
From: Daniel Wagner [mailto:daniel.wagner@...]
Sent: Monday, December 18, 2017 8:36 PM
To: Daniel Sangorrin
Cc: cip-dev@...
Subject: Re: [cip-dev] B@D: iwg20m support

Hi Daniel,

On 12/14/2017 06:57 AM, Daniel Sangorrin wrote:
Hi Trung-san, Robert and all

I received the AWS credentials from Agustin and uploaded
the cip-core binaries for the Renesas iwg20m board.

https://s3-us-west-2.amazonaws.com/download.cip-project.or
g/ci
p- co re /iwg20m/core-image-minimal-iwg20m.cpio.gz
https://s3-us-west-2.amazonaws.com/download.cip-project.or
g/ci
p-
co
re
/iwg20m/r8a7743-iwg20d-q7.dtb
https://s3-us-west-2.amazonaws.com/download.cip-project.or
g/ci
p-
co
re
/iwg20m/uImage
Just out of curiosity: how did you build the root fs? The
naming indicates that you used Yocto. I am still setting up
my test environment for rt testing and wrote two kas files to create me a root fs:

https://github.com/igaw/cip-rt-misc/blob/master/docs/kas-bbb
.yml
https://github.com/igaw/cip-rt-misc/blob/master/docs/kas-min
nowb
oa
rd
.y
ml

They are not self contained yet. Will fixed that right now.
The idea that you can write

kas build kas-bbb.yml

and you get a root fs for testing.
The CIP Core rootfs was built using Deby (poky build system +
meta-debian). You can see a tutorial in the CIP wiki and a more up-to- date README and kas file in the source code.

https://wiki.linuxfoundation.org/civilinfrastructureplatform/c
ip-c
or
e-
quickstart
https://gitlab.com/cip-project/cip-core/blob/master/deby/poky/
meta
-c
ip
-iwg20m/README.IWG20M.txt
https://gitlab.com/cip-project/cip-core/blob/master/deby/poky/
meta
-c
ip
-iwg20m/kas-iwg20m.yml

An overview of the CIP Core is here:
https://wiki.linuxfoundation.org/civilinfrastructureplatform/c
ip-c
or e
https://gitlab.com/cip-project/cip-core/blob/master/deby/READM
E.md

For the BBB please check this other Readme and kas file:
https://gitlab.com/cip-project/cip-core/blob/master/deby/poky/
meta
-c
ip
-bbb/README.BBB.txt
https://gitlab.com/cip-project/cip-core/blob/master/deby/poky/
meta
-c
ip
-bbb/kas-bbb.yml

You can add the packages "openssh nfs-utils rt-tests strace procps", they are available in meta-debian.

Unfortunately, you cannot simply add "meta-qt5" because it may
conflict with meta-debian. Instead you would need to use meta- debian qt5 recipes (only if you really need qt5 for testing RT).

Thanks,
Daniel Sangorrin






_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: [ANNOUNCE] Linux 4.4.15-cip15-rt10

Ben Hutchings <ben.hutchings@...>
 

On Thu, 2018-01-11 at 09:07 +0100, Daniel Wagner wrote:
Good morning everyone,

On 01/10/2018 06:32 PM, Sebastian Andrzej Siewior wrote:
[...]
Daniel: you have the release currently in a git tree within his "user"
namespace and did not upload it to k.o. Do you plan upload it to the
stable-rt tree like Julia does and upload it to the "projects/rt/4.4"
folder on k.o.? If so we might just add a link to the cip wiki next to
4.4 and be done with it.
Steven will ask the k.o folks to give me permission to upload to
projects/rt/4.4. In short nothing should change for 4.4-rt support as
long Greg is releasing 4.4.

As for 4.4-cip(-rt), it might make sense to have a project/cip shared
folder with the 4.4-cip and 4.4-cip-rt tree.

Ben, what's your stand on this?
No-one's asked for tarballs and patches, so I don't really want to add
that step to the release process.

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


Submitting two patches to https://gitlab.com/cip-project/cip-testing/board-at-desk-single-dev/

_nobody_ _nobody_ <nobodyless@...>
 

Hello Folks,

I decided to submit two patches, as my genesis to this group (warming
up period). Please, review the patches, and tell me (if any?) your
opinion. My aim is customize the repo to be as much generic as
possible (there are other aims, not important for the momentum being).

Thank you,
Zoran Stojsavljevic
_______

[1] https://gitlab.com/cip-project/cip-testing/board-at-desk-single-dev/merge_requests/52

Improving importbox.sh script

This is since I think (I hope) i have improved the initial
importbox.sh. This one is more descriptive, and has few more options.
Also, the attempt was made to create a more generic bash script which
uses Vagrant.generic file (the actual name of known vagrant
repositories names is changed to generic newBox).

Please, do note that the step [6]: "Executing the command: vagrant up
--provider which provider?" could be improved, but still one can have
argument that there are so far 4 providers, and more than 1 can be
present at the time of testing. The improvements will be to scan
through "vagrant box list command and find out if only one provider is
present, or more?

Please, also note that the first line uses bash.
_______

[2] https://gitlab.com/zoran.stojsavljevic/board-at-desk-single-dev/commit/0307e18883c69a882d3927be657cef6e615863fa

8821 - 8840 of 9641