Hello list, Long time no see... ;-) Just for the sake of Reality: the generic initramfs building from the: https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipsystembuildhowto Does not wor

https://github.com/ZoranStojsavljevic/imx6-sabre-automotive-bsp Zoran _______ <zoran.stojsavljevic.de@...> wrote:

Found it... http://variwiki.com/index.php?title=Yocto_Build_Release&release=RELEASE_MORTY_V1 Actually, it is thud, after all. But within few days I'll release public github repo with complete Sabre Au

Hello to all, I am trying to find out some recent yocto repo, which contains YOCTO reference repo for the following NXP board: MCIMXABASEV1 also called SABRE platform. Here is one repo I found reading

Evaluation clearing process by CIp Consortium (Legal Implications)??? Well... ;-) Zoran _______

Chris, Thank you for the prompt reply. Indeed, you took care/thought about everything. I've learned quite a bit, I must admit! Your script build_kernel.sh is portable and adaptable to many kernel case

After I sent the email I have spotted the same: that actually it is line 123 in your script: /opt/build_kernel.sh: line 123 There should exist two different paths for the same names: [1] For x86: ~/gi

Quick ad-hoc observation: [1] From https://gitlab.com/cip-project/cip-kernel/linux-cip/-/jobs/260410825 Interesting line...WTH is wrong with the line 123 (CONFIG_SPI_DEBUG=y)? [2] From https://lkml.or

You are correct, I should write that these are preliminary WTH/ad-hoc results (I need to fix/rerun these in the correct setup, I know). Again, correct. I wrote nsec instead usec, having in mind INTEL

With all due respect (and I do really respect prominent CIP founders), I need to make this problem solved solely by myself... But, anyway, thank you for the advise! :-) Zoran _______

(limitations): I could NOT connect with ETH to target (something is wrongly set with my local.conf for YOCTO rootfs)... Here is my approximate recipe for rootfs I am using for the test (initramfs) for

U R targeting 4.19.50-cip3-rt2... I do agree 100%, but I have some problems to do rt-tests (connecting BBB target to my VM). Please, stay tuned. I'll resolve these problems ASAP (if ?, then Ill publis

I finally was able to make the viable .config... For the previous rt-kernel for BBB. root@beaglebone:~# uname -a Linux beaglebone 4.19.13-cip1-rt1 #1 PREEMPT RT Tue Jul 23 12:18:18 GMT 2019 armv7l GNU

>> Good point. I have not yet tried running 4.19 on the BBB, but I can >> look at adding one - or perhaps Nobuhiro or Pavel already has a >> suitable config? Excellent point, which spares me time to b

For the starters, could you, please, forward to me the public (I assume so, somewhere on CIP pages) web pointer of the README file you are talking about? I know that I fell on this list out of nowhere

OK, I see. Wrong check-out! git checkout -b cip_v4.19.58-cip6 v4.19.58-cip6 Yup... This is the root cause of the problem! v4.19.13-cip1 v4.19.13-cip1-rt1 v4.19.13-cip1-rt1-rebase v4.19.13-cip2 v4.19.1

Yup... I am very interested in this one, I should say. ;-) Let us see what will come out of this effort. :-) Thank you, Zoran Stojsavljevic _______

Please, could you refer to reply above (practical exercises using lava_server_vm VM) to Ben and Daniel? You can also check and verify it... Maybe, after all, I am doing something very wrong. But I do

> This never existed in the upstream kernel, only in -rt branches. > It still exists in 4.19-rt. Sure. The following is done by me: git clone git://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-ci

Hello Ben, Daniel, I started my own investigation about RT kernels, namely 4.19. I proceed very carefully over the kernel config parameters... BUt the last one I inspected today got me nowhere!? Seems