[yocto] Force rebuild to regenerate .ko

[Raymond Yeung]

I've a Intel Ethernet driver, ixgbe.ko.  I made some changes (debug logs) to 
the source file.  How do I force the .ko to be regenerated within yocto 
environment, without rebuilding the entire yocto code base?

I tried to do bitbake of the image name earlier, but bitbake decides that 
there's nothing to be done.  This is even after I'd removed the cache and 
sstate directories.

Thanks,
Raymond
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] : [yocto-4.18]: intel-socfpga: kernel patches

[Bruce Ashfield]

On 2018-10-12 7:03 PM, Li, Meng wrote:

Hi Bruce,

My pull request have been at the end of this email thread.


ahahah! I see it now.


The head part of pull request as below.
I push these patches into https://github.com/limeng-linux/linux-yocto-4.18.git, 
on branch v4.18/standard/intel-socfpga. A public repo.
Can you access them?
Or I need to send pull request with other style?


This will work fine, I just missed it in my original read through
the request.

Bruce



  The following changes since commit 0cdc8564c61958a39704d97e008120bd7c762f60:
  
 Merge tag 'v4.18.9' into v4.18/standard/base (2018-09-21 11:13:02  -0400)
  
  are available in the git repository at:
  
 https://github.com/limeng-linux/linux-yocto-4.18.git   v4.18/standard/intel-socfpga
  
  for you to fetch changes up to a0fe17724f45667d757cdf29d20030ff21ca1491:
  
 spi-nor: add support for mx25u51245g (2018-10-10 00:31:57 -0700)


thanks ,
Limeng



-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Friday, October 12, 2018 10:36 PM
To: Li, Meng
Cc: linux-yocto@yoctoproject.org
Subject: Re: [linux-yocto]: [yocto-4.18]: intel-socfpga: kernel patches

On 10/10/2018 09:49 PM, meng...@windriver.com wrote:

From: Limeng 


Hi Bruce,

I am working on BSP intel-socfpga.

Could you please help to create branch "v4.18/standard/intel-socfpga" in

linux-yocto kernel?

And then merge these kernel patches into this branch.


I created the branch, but the patches never came through. Is there
somewhere you can stage them, and then send a pull request ?

Bruce



I verify these patches on Intel-PSG stratix10 development board.
Boot up log as below:

Starting kernel ...

Booting Linux on physical CPU 0x00 [0x410fd034]
Linux version 4.18.9-yoctodev-standard (oe-user@oe-host) (gcc version

8.2.0 (GCC)) #1 SMP PREEMPT Sat Sep 29 10:47:46 UTC 2018

Machine model: SoCFPGA Stratix 10 SoCDK
earlycon: uart0 at MMIO32 0xffc02000 (options '115200n8')
bootconsole [uart0] enabled
efi: Getting EFI parameters from FDT:
efi: UEFI not found.
Reserved memory: created DMA memory pool at 0x,

size 16 MiB

OF: reserved mem: initialized node svcbuffer@0, compatible id shared-

dma-pool

cma: Reserved 16 MiB at 0x7e80
psci: probing for conduit method from DT.
psci: PSCIv65535.65535 detected in firmware.
psci: Using standard PSCI v0.2 function IDs
psci: MIGRATE_INFO_TYPE not supported.
psci: SMC Calling Convention v1.0
random: get_random_bytes called from start_kernel+0x9c/0x458 with

crng_init=0

percpu: Embedded 23 pages/cpu @(ptrval) s53784 r8192 d32232

u94208

Detected VIPT I-cache on CPU0
CPU features: enabling workaround for ARM erratum 845719
CPU features: detected: Kernel page table isolation (KPTI)
Built 1 zonelists, mobility grouping on.  Total pages: 512064
Kernel command line: console=ttyS0,115200n8 earlycon root=/dev/nfs rw

no_console_suspend rootwait
nfsroot=128.224.162.206:/home/wrsadmin/Project/Native/nfsroot/intel-
stratix10-1018,v3,p

Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Memory: 2011824K/2080768K available (9276K kernel code, 1060K rwdata,

4192K rodata, 960K init, 649K bss, 52560K reserved, 16384K cma-reserved)

SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
ftrace: allocating 31531 entries in 124 pages
Preemptible hierarchical RCU implementation.
  Tasks RCU enabled.
NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
GIC: Using split EOI/Deactivate mode
arch_timer: cp15 timer(s) running at 400.00MHz (phys).
clocksource: arch_sys_counter: mask: 0xff max_cycles:

0x5c4093a7d1, max_idle_ns: 440795210635 ns

sched_clock: 56 bits at 400MHz, resolution 2ns, wraps every

4398046511103ns

Console: colour dummy device 80x25
Calibrating delay loop (skipped), value calculated using timer frequency..

800.00 BogoMIPS (lpj=160)

pid_max: default: 32768 minimum: 301
Security Framework initialized
Mount-cache hash table entries: 4096 (order: 3, 32768 bytes)
Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes)
ASID allocator initialised with 32768 entries
Hierarchical SRCU implementation.
EFI services will not be available.
smp: Bringing up secondary CPUs ...
Detected VIPT I-cache on CPU1
CPU1: Booted secondary processor 0x01 [0x410fd034]
Detected VIPT I-cache on CPU2
CPU2: Booted secondary processor 0x02 [0x410fd034]
Detected VIPT I-cache on CPU3
CPU3: Booted secondary processor 0x03 [0x410fd034]
smp: Brought up 1 node, 4 CPUs
SMP: Total of 4 processors activated.
CPU features: detected: 32-bit EL0 Support
CPU: All CPU(s) started at EL2
alternatives: patching kernel code
devtmpfs: initialized
clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns:

764504178510 ns

futex hash table entries: 1024 (order: 4, 65536 bytes)
xor: measuring software checksum speed
 8regs :  

Re: [linux-yocto] : [yocto-4.18]: intel-socfpga: kernel patches

[Li, Meng]

Hi Bruce,

My pull request have been at the end of this email thread.
The head part of pull request as below.
I push these patches into https://github.com/limeng-linux/linux-yocto-4.18.git, 
on branch v4.18/standard/intel-socfpga. A public repo.
Can you access them?
Or I need to send pull request with other style?

 The following changes since commit 0cdc8564c61958a39704d97e008120bd7c762f60:
 
Merge tag 'v4.18.9' into v4.18/standard/base (2018-09-21 11:13:02  -0400)
 
 are available in the git repository at:
 
https://github.com/limeng-linux/linux-yocto-4.18.git   
v4.18/standard/intel-socfpga
 
 for you to fetch changes up to a0fe17724f45667d757cdf29d20030ff21ca1491:
 
spi-nor: add support for mx25u51245g (2018-10-10 00:31:57 -0700)

thanks ,
Limeng


> -Original Message-
> From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
> Sent: Friday, October 12, 2018 10:36 PM
> To: Li, Meng
> Cc: linux-yocto@yoctoproject.org
> Subject: Re: [linux-yocto]: [yocto-4.18]: intel-socfpga: kernel patches
> 
> On 10/10/2018 09:49 PM, meng...@windriver.com wrote:
> > From: Limeng 
> >
> >
> > Hi Bruce,
> >
> > I am working on BSP intel-socfpga.
> >
> > Could you please help to create branch "v4.18/standard/intel-socfpga" in
> linux-yocto kernel?
> > And then merge these kernel patches into this branch.
> 
> I created the branch, but the patches never came through. Is there
> somewhere you can stage them, and then send a pull request ?
> 
> Bruce
> 
> >
> > I verify these patches on Intel-PSG stratix10 development board.
> > Boot up log as below:
> >
> > Starting kernel ...
> >
> > Booting Linux on physical CPU 0x00 [0x410fd034]
> > Linux version 4.18.9-yoctodev-standard (oe-user@oe-host) (gcc version
> 8.2.0 (GCC)) #1 SMP PREEMPT Sat Sep 29 10:47:46 UTC 2018
> > Machine model: SoCFPGA Stratix 10 SoCDK
> > earlycon: uart0 at MMIO32 0xffc02000 (options '115200n8')
> > bootconsole [uart0] enabled
> > efi: Getting EFI parameters from FDT:
> > efi: UEFI not found.
> > Reserved memory: created DMA memory pool at 0x,
> size 16 MiB
> > OF: reserved mem: initialized node svcbuffer@0, compatible id shared-
> dma-pool
> > cma: Reserved 16 MiB at 0x7e80
> > psci: probing for conduit method from DT.
> > psci: PSCIv65535.65535 detected in firmware.
> > psci: Using standard PSCI v0.2 function IDs
> > psci: MIGRATE_INFO_TYPE not supported.
> > psci: SMC Calling Convention v1.0
> > random: get_random_bytes called from start_kernel+0x9c/0x458 with
> crng_init=0
> > percpu: Embedded 23 pages/cpu @(ptrval) s53784 r8192 d32232
> u94208
> > Detected VIPT I-cache on CPU0
> > CPU features: enabling workaround for ARM erratum 845719
> > CPU features: detected: Kernel page table isolation (KPTI)
> > Built 1 zonelists, mobility grouping on.  Total pages: 512064
> > Kernel command line: console=ttyS0,115200n8 earlycon root=/dev/nfs rw
> no_console_suspend rootwait
> nfsroot=128.224.162.206:/home/wrsadmin/Project/Native/nfsroot/intel-
> stratix10-1018,v3,p
> > Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
> > Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
> > Memory: 2011824K/2080768K available (9276K kernel code, 1060K rwdata,
> 4192K rodata, 960K init, 649K bss, 52560K reserved, 16384K cma-reserved)
> > SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
> > ftrace: allocating 31531 entries in 124 pages
> > Preemptible hierarchical RCU implementation.
> >  Tasks RCU enabled.
> > NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
> > GIC: Using split EOI/Deactivate mode
> > arch_timer: cp15 timer(s) running at 400.00MHz (phys).
> > clocksource: arch_sys_counter: mask: 0xff max_cycles:
> 0x5c4093a7d1, max_idle_ns: 440795210635 ns
> > sched_clock: 56 bits at 400MHz, resolution 2ns, wraps every
> 4398046511103ns
> > Console: colour dummy device 80x25
> > Calibrating delay loop (skipped), value calculated using timer frequency..
> 800.00 BogoMIPS (lpj=160)
> > pid_max: default: 32768 minimum: 301
> > Security Framework initialized
> > Mount-cache hash table entries: 4096 (order: 3, 32768 bytes)
> > Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes)
> > ASID allocator initialised with 32768 entries
> > Hierarchical SRCU implementation.
> > EFI services will not be available.
> > smp: Bringing up secondary CPUs ...
> > Detected VIPT I-cache on CPU1
> > CPU1: Booted secondary processor 0x01 [0x410fd034]
> > Detected VIPT I-cache on CPU2
> > CPU2: Booted secondary processor 0x02 [0x410fd034]
> > Detected VIPT I-cache on CPU3
> > CPU3: Booted secondary processor 0x03 [0x410fd034]
> > smp: Brought up 1 node, 4 CPUs
> > SMP: Total of 4 processors activated.
> > CPU features: detected: 32-bit EL0 Support
> > CPU: All CPU(s) started at EL2
> > alternatives: patching kernel code
> > devtmpfs: initialized
> > clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns:
> 

Re: [yocto] [prelink-cross] [PATCH] x86_64: allow prelinking of PIE executables with COPY relocs

[Mark Hatle]

On 10/10/18 3:50 PM, Sergei Trofimovich wrote:
> COPY relocs are fine to have in PIE executables (as opposed to
> shared libraries).
> 
> By enabling prelink on PIEs we achieve a few goals:
> - prelink more PIE files on system: nicer for uniformity,
> - avoid spurious warnings about shared libraries with COPY relocs
> 
> It's usefult to prelink PIEs when kernel ASLR is disabled:
> kernel.randomize_va_space=0 + PIE-randomization patches.
> 
> I have gcc built as `--enable-default-pie` (generates PIE
> executables by default).
> 
> Testsute results before the change:
>   PASS:  14
>   FAIL:  31
> 
> After the change:
>   PASS:  32
>   FAIL:  13

After applying this patch, I think it uncovered another issue.

See:

http://git.yoctoproject.org/cgit/cgit.cgi/prelink-cross/log/?h=cross_prelink_staging

specifically:

http://git.yoctoproject.org/cgit/cgit.cgi/prelink-cross/commit/?h=cross_prelink_staging=b10e14218646d8b74773b82b0f8b395bce698fa2


Running the test suite, I was getting 4 failures that each manifested 
themselves as:

FAIL: layout1.sh  ../src/prelink: testsuite/layout1: section file offsets not
monotonically increasing
FAIL: cxx2.sh ../src/prelink: testsuite/cxx2: section file offsets not
monotonically increasing
FAIL: cxx3.sh ../src/prelink: testsuite/cxx3: section file offsets not
monotonically increasing
FAIL: quick1.sh   ../src/prelink: testsuite/quick1.tree/usr/bin/bin3: section
file offsets not monotonically increasing

Before this patch they would report:

   COPY relocations don't point into .bss or .sbss section

So I suspect that enabling the PIE executable prelinking has either triggered a
corner case or uncovered a bug in the existing function.

What I am seeing happen, if I dump the sections is:

   section 15 .fini file offset range 12f4 and 12fd
   section 16 .gnu.conflict file offset range 1300 and 2080
   section 17 .rodata file offset range 2000 and 20a3
   section 18 .eh_frame_hdr file offset range 20a4 and 2118

When the .gnu.conflict section is added and processed, it ends up inserting
immediately after .fini.   It then ends up taking more space then the gap allows
for (by 0x80 bytes in this case.)

I looked at the code for a couple of hours, and I'm not making any real progress
on it.

Do you have time to investigate this?

My little hack is enough to identify when this over write happens and abort..
but I suspect it's probably fixable instead.  (I don't intend to keep the hack
commit when transferring this over)

--Mark

> Signed-off-by: Sergei Trofimovich 
> ---
>  src/arch-x86_64.c |  4 ++--
>  src/dso.c | 19 +++
>  src/prelink.h |  1 +
>  3 files changed, 22 insertions(+), 2 deletions(-)
> 
> diff --git a/src/arch-x86_64.c b/src/arch-x86_64.c
> index 5c95f47..2f6c551 100644
> --- a/src/arch-x86_64.c
> +++ b/src/arch-x86_64.c
> @@ -179,7 +179,7 @@ x86_64_prelink_rela (struct prelink_info *info, GElf_Rela 
> *rela,
>   value + rela->r_addend - info->resolvetls->offset);
>break;
>  case R_X86_64_COPY:
> -  if (dso->ehdr.e_type == ET_EXEC)
> +  if (dso->ehdr.e_type == ET_EXEC || dso_is_pie(dso))
>   /* COPY relocs are handled specially in generic code.  */
>   return 0;
>error (0, 0, "%s: R_X86_64_COPY reloc in shared library?", 
> dso->filename);
> @@ -503,7 +503,7 @@ x86_64_undo_prelink_rela (DSO *dso, GElf_Rela *rela, 
> GElf_Addr relaaddr)
>write_le32 (dso, rela->r_offset, 0);
>break;
>  case R_X86_64_COPY:
> -  if (dso->ehdr.e_type == ET_EXEC)
> +  if (dso->ehdr.e_type == ET_EXEC || dso_is_pie(dso))
>   /* COPY relocs are handled specially in generic code.  */
>   return 0;
>error (0, 0, "%s: R_X86_64_COPY reloc in shared library?", 
> dso->filename);
> diff --git a/src/dso.c b/src/dso.c
> index a5fcec5..9fcfc3d 100644
> --- a/src/dso.c
> +++ b/src/dso.c
> @@ -1106,6 +1106,25 @@ dso_is_rdwr (DSO *dso)
>return dso->elfro != NULL;
>  }
>  
> +/* Return true is DSO is position independent executable.
> +
> +   There is no simple way to distinct between shared library
> +   and PIE executable.  Use presence of interpreter as a heuristic.  */
> +
> +int dso_is_pie(DSO *dso)
> +{
> +  int i;
> +
> +  if (dso->ehdr.e_type != ET_DYN)
> +return 0;
> +
> +  for (i = 0; i < dso->ehdr.e_phnum; ++i)
> +if (dso->phdr[i].p_type == PT_INTERP)
> +  return 1;
> +
> +  return 0;
> +}
> +
>  GElf_Addr
>  adjust_old_to_new (DSO *dso, GElf_Addr addr)
>  {
> diff --git a/src/prelink.h b/src/prelink.h
> index 93dbf7a..d8a00c6 100644
> --- a/src/prelink.h
> +++ b/src/prelink.h
> @@ -298,6 +298,7 @@ int reopen_dso (DSO *dso, struct section_move *move, 
> const char *);
>  int adjust_symbol_p (DSO *dso, GElf_Sym *sym);
>  int check_dso (DSO *dso);
>  int dso_is_rdwr (DSO *dso);
> +int dso_is_pie(DSO *dso);
>  void read_dynamic (DSO *dso);
>  int set_dynamic (DSO *dso, GElf_Word tag, GElf_Addr value, int fatal);
>  int 

[yocto] [prelink-cross][PATCH] Add option to return an error if all binaries cannot be prelinked

[Kyle Russell]

Otherwise, there's no way to validate whether or not the operation
was actually successful without rescanning.

Signed-off-by: Kyle Russell 
---
 src/doit.c| 16 +++-
 src/main.c|  8 +++-
 src/prelink.h |  2 +-
 3 files changed, 19 insertions(+), 7 deletions(-)

diff --git a/src/doit.c b/src/doit.c
index 1e32ad5..3784866 100644
--- a/src/doit.c
+++ b/src/doit.c
@@ -237,11 +237,11 @@ error_out:
   return;
 }
 
-void
+int
 prelink_all (void)
 {
   struct collect_ents l;
-  int i;
+  int i, fails = 0;
 
   l.ents =
 (struct prelink_entry **) alloca (prelink_entry_count
@@ -250,7 +250,13 @@ prelink_all (void)
   htab_traverse (prelink_filename_htab, find_ents, );
 
   for (i = 0; i < l.nents; ++i)
-if (l.ents[i]->done == 1
-   || (l.ents[i]->done == 0 && l.ents[i]->type == ET_EXEC))
-  prelink_ent (l.ents[i]);
+{
+  if (l.ents[i]->done == 1
+ || (l.ents[i]->done == 0 && l.ents[i]->type == ET_EXEC))
+   prelink_ent (l.ents[i]);
+  if (l.ents[i]->type == ET_UNPRELINKABLE)
+   fails++;
+}
+
+  return fails;
 }
diff --git a/src/main.c b/src/main.c
index 0cea86d..6ba89d5 100644
--- a/src/main.c
+++ b/src/main.c
@@ -47,6 +47,7 @@ int one_file_system;
 int enable_cxx_optimizations = 1;
 int exec_shield;
 int undo, verify;
+int errors;
 enum verify_method_t verify_method;
 int quick;
 int compute_checksum;
@@ -90,6 +91,7 @@ static struct argp_option options[] = {
   {"black-list",   'b', "PATH", 0, "Blacklist path" },
   {"cache-file",   'C', "CACHE", 0, "Use CACHE as cache file" },
   {"config-file",  'c', "CONF", 0, "Use CONF as configuration file" },
+  {"errors",'e', 0, 0,  "Returns an error if all binaries are not 
prelinkable" },
   {"force",'f', 0, 0,  "Force prelinking" },
   {"dereference",  'h', 0, 0,  "Follow symlinks when processing directory 
trees from command line" },
   {"one-file-system",  'l', 0, 0,  "Stay in local file system when processing 
directories from command line" },
@@ -139,6 +141,9 @@ parse_opt (int key, char *arg, struct argp_state *state)
   if (add_to_blacklist (arg, dereference, one_file_system))
exit (EXIT_FAILURE);
   break;
+case 'e':
+  errors = 1;
+  break;
 case 'f':
   force = 1;
   break;
@@ -524,7 +529,8 @@ main (int argc, char *argv[])
 prelink_load_cache ();
 
   layout_libs ();
-  prelink_all ();
+  if(prelink_all () && errors)
+return EXIT_FAILURE;
 
   if (! no_update && ! dry_run)
 prelink_save_cache (all);
diff --git a/src/prelink.h b/src/prelink.h
index 93dbf7a..c7b57e2 100644
--- a/src/prelink.h
+++ b/src/prelink.h
@@ -574,7 +574,7 @@ int get_relocated_mem (struct prelink_info *info, DSO *dso, 
GElf_Addr addr,
 
 int layout_libs (void);
 
-void prelink_all (void);
+int prelink_all (void);
 
 int undo_all (void);
 
-- 
2.17.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [prelink-cross][PATCH] Support copy relocations in .data.rel.ro

[Mark Hatle]

On 10/12/18 9:06 AM, Kyle Russell wrote:
> Do you want me to just resent my last two patches?  I don't mind if that would
> be easier, and I'll remember to add the Signed-off-by. :)

I was able to pull them from the mailing list archives and have them applied to
my local tree.  I have a few other patches and then I'll be pushing to the
staging tree.

--Mark

> On Fri, Oct 12, 2018 at 10:00 AM Mark Hatle  > wrote:
> 
> On 10/4/18 9:12 AM, Kyle Russell wrote:
> > Hey Mark,
> >
> > Do you think this approach is reasonable?  If so, I have another patch 
> I'd
> like
> > to propose that would enable us to better catch error scenarios (like 
> the last
> > two patches address) that we might encounter during do_image_prelink.  
> We just
> > happened to detect these last two issues even though image_prelink 
> didn't fail
> > the build, so I'd like to provide an option to enable a little more 
> assertive
> > error path, if desired.
> 
> I'm getting caught back up on my prelink 'TODO' set.  The approach seems
> reasonable to me.  However, I appear to have lost the reference to the 
> original
> patch email.
> 
> I'm going to try to reapply from this email (or the list archive), but I 
> may
> need you to resend it.  I'll let you [and others know] once I get these 
> things
> merged.
> 
> Thanks!
> --Mark
> 
> > Thanks,
> > Kyle
> >
> > On Fri, Sep 28, 2018 at 10:57 AM Kyle Russell  
> > >> wrote:
> >
> >     binutils-2.28 (17026142ef35b62ac88bfe517b4160614902cb28) adds 
> support
> >     for copying read-only dynamic symbols into .data.rel.ro
>  
> >     instead of .bss
> >     since .bss is technically writable.  This causes prelink to error 
> out on
> >     any binary containing COPY relocations in .data.rel.ro
>  .
> >
> >     Read-only variables defined in shared libraries should be copied 
> directly
> >     into the space allocated for them in .data.rel.ro 
> 
>  by
> >     the linker.
> >
> >     To achieve this, we determine whether either of the two sections
> >     containing copy relocations is .data.rel.ro 
> .  If so, we
> >     relocate the
> >     symbol memory directly into the existing section instead of 
> constructing
> >     a new .(s)dynbss section once prelink_build_conflicts() returns.
> >
> >     Fixes cxx1.sh, cxx2.sh, and cxx3.sh on Fedora 28 (which uses
> >     binutils-2.29).
> >     ---
> >      src/conflict.c | 51 
> +-
> >      src/undo.c     |  9 +
> >      2 files changed, 47 insertions(+), 13 deletions(-)
> >
> >     diff --git a/src/conflict.c b/src/conflict.c
> >     index 9ae2ddb..5613ace 100644
> >     --- a/src/conflict.c
> >     +++ b/src/conflict.c
> >     @@ -450,7 +450,7 @@ get_relocated_mem (struct prelink_info *info, 
> DSO
> *dso,
> >     GElf_Addr addr,
> >      int
> >      prelink_build_conflicts (struct prelink_info *info)
> >      {
> >     -  int i, ndeps = info->ent->ndepends + 1;
> >     +  int i, reset_dynbss = 0, reset_sdynbss = 0, ndeps =
> info->ent->ndepends + 1;
> >        struct prelink_entry *ent;
> >        int ret = 0;
> >        DSO *dso;
> >     @@ -675,6 +675,11 @@ prelink_build_conflicts (struct prelink_info 
> *info)
> >                          dso->filename);
> >                   goto error_out;
> >                 }
> >     +
> >     +         name = strptr (dso, dso->ehdr.e_shstrndx,
> dso->shdr[bss1].sh_name);
> >     +         if (strcmp(name, ".data.rel.ro 
> ") == 0)
> >     +           reset_sdynbss = 1;
> >     +
> >               firstbss2 = i;
> >               info->sdynbss_size = cr.rela[i - 1].r_offset -
> cr.rela[0].r_offset;
> >               info->sdynbss_size += cr.rela[i - 1].r_addend;
> >     @@ -702,6 +707,10 @@ prelink_build_conflicts (struct prelink_info 
> *info)
> >                 }
> >             }
> >
> >     +      name = strptr (dso, dso->ehdr.e_shstrndx, 
> dso->shdr[bss2].sh_name);
> >     +      if (strcmp(name, ".data.rel.ro 
> ") == 0)
> >     +        reset_dynbss = 1;
> >     +
> >            info->dynbss_size = cr.rela[cr.count - 1].r_offset
> >                               - cr.rela[firstbss2].r_offset;
> >            info->dynbss_size += cr.rela[cr.count - 1].r_addend;
> >     @@ -719,9 +728,9 @@ 

Re: [linux-yocto] : [yocto-4.18]: intel-socfpga: kernel patches

[Bruce Ashfield]

On 10/10/2018 09:49 PM, meng...@windriver.com wrote:

From: Limeng 


Hi Bruce,

I am working on BSP intel-socfpga.

Could you please help to create branch "v4.18/standard/intel-socfpga" in 
linux-yocto kernel?
And then merge these kernel patches into this branch.


I created the branch, but the patches never came through. Is there
somewhere you can stage them, and then send a pull request ?

Bruce



I verify these patches on Intel-PSG stratix10 development board.
Boot up log as below:

Starting kernel ...

Booting Linux on physical CPU 0x00 [0x410fd034]
Linux version 4.18.9-yoctodev-standard (oe-user@oe-host) (gcc version 8.2.0 
(GCC)) #1 SMP PREEMPT Sat Sep 29 10:47:46 UTC 2018
Machine model: SoCFPGA Stratix 10 SoCDK
earlycon: uart0 at MMIO32 0xffc02000 (options '115200n8')
bootconsole [uart0] enabled
efi: Getting EFI parameters from FDT:
efi: UEFI not found.
Reserved memory: created DMA memory pool at 0x, size 16 MiB
OF: reserved mem: initialized node svcbuffer@0, compatible id shared-dma-pool
cma: Reserved 16 MiB at 0x7e80
psci: probing for conduit method from DT.
psci: PSCIv65535.65535 detected in firmware.
psci: Using standard PSCI v0.2 function IDs
psci: MIGRATE_INFO_TYPE not supported.
psci: SMC Calling Convention v1.0
random: get_random_bytes called from start_kernel+0x9c/0x458 with crng_init=0
percpu: Embedded 23 pages/cpu @(ptrval) s53784 r8192 d32232 u94208
Detected VIPT I-cache on CPU0
CPU features: enabling workaround for ARM erratum 845719
CPU features: detected: Kernel page table isolation (KPTI)
Built 1 zonelists, mobility grouping on.  Total pages: 512064
Kernel command line: console=ttyS0,115200n8 earlycon root=/dev/nfs rw 
no_console_suspend rootwait 
nfsroot=128.224.162.206:/home/wrsadmin/Project/Native/nfsroot/intel-stratix10-1018,v3,p
Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Memory: 2011824K/2080768K available (9276K kernel code, 1060K rwdata, 4192K 
rodata, 960K init, 649K bss, 52560K reserved, 16384K cma-reserved)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
ftrace: allocating 31531 entries in 124 pages
Preemptible hierarchical RCU implementation.
 Tasks RCU enabled.
NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
GIC: Using split EOI/Deactivate mode
arch_timer: cp15 timer(s) running at 400.00MHz (phys).
clocksource: arch_sys_counter: mask: 0xff max_cycles: 0x5c4093a7d1, 
max_idle_ns: 440795210635 ns
sched_clock: 56 bits at 400MHz, resolution 2ns, wraps every 4398046511103ns
Console: colour dummy device 80x25
Calibrating delay loop (skipped), value calculated using timer frequency.. 
800.00 BogoMIPS (lpj=160)
pid_max: default: 32768 minimum: 301
Security Framework initialized
Mount-cache hash table entries: 4096 (order: 3, 32768 bytes)
Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes)
ASID allocator initialised with 32768 entries
Hierarchical SRCU implementation.
EFI services will not be available.
smp: Bringing up secondary CPUs ...
Detected VIPT I-cache on CPU1
CPU1: Booted secondary processor 0x01 [0x410fd034]
Detected VIPT I-cache on CPU2
CPU2: Booted secondary processor 0x02 [0x410fd034]
Detected VIPT I-cache on CPU3
CPU3: Booted secondary processor 0x03 [0x410fd034]
smp: Brought up 1 node, 4 CPUs
SMP: Total of 4 processors activated.
CPU features: detected: 32-bit EL0 Support
CPU: All CPU(s) started at EL2
alternatives: patching kernel code
devtmpfs: initialized
clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 
764504178510 ns
futex hash table entries: 1024 (order: 4, 65536 bytes)
xor: measuring software checksum speed
8regs :  1967.000 MB/sec
8regs_prefetch:  1701.000 MB/sec
32regs:  2255.000 MB/sec
32regs_prefetch:  1912.000 MB/sec
xor: using function: 32regs (2255.000 MB/sec)
DMI not present or invalid.
NET: Registered protocol family 16
cpuidle: using governor ladder
vdso: 2 pages (1 code @ (ptrval), 1 data @ (ptrval))
hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
DMA: preallocated 256 KiB pool for atomic allocations
raid6: int64x1  gen()   381 MB/s
raid6: int64x1  xor()   380 MB/s
raid6: int64x2  gen()   583 MB/s
raid6: int64x2  xor()   504 MB/s
raid6: int64x4  gen()   833 MB/s
raid6: int64x4  xor()   618 MB/s
raid6: int64x8  gen()   980 MB/s
raid6: int64x8  xor()   635 MB/s
raid6: neonx1   gen()   625 MB/s
raid6: neonx1   xor()   732 MB/s
raid6: neonx2   gen()   959 MB/s
raid6: neonx2   xor()   975 MB/s
raid6: neonx4   gen()  1263 MB/s
raid6: neonx4   xor()  1180 MB/s
raid6: neonx8   gen()  1291 MB/s
raid6: neonx8   xor()  1205 MB/s
raid6: using algorithm neonx8 gen() 1291 MB/s
raid6:  xor() 1205 MB/s, rmw enabled
raid6: using neon recovery algorithm
vgaarb: loaded
Intel Service Layer Driver Initialized
SCSI subsystem initialized
usbcore: registered new interface 

Re: [yocto] [Yocto][poky][meta] already-stripped ignore if set for any other package then INSANE_SKIP_${PN}

[Burton, Ross]

On Thu, 11 Oct 2018 at 18:14, Måns Zigher  wrote:
> I have been struggling with a problem where I need to create a package in a 
> recipe and set already-stripped for that package. The package in question is 
> not the the default one so I am trying to set it by using
>
> INSANE_SKIP_${PN} += " \
> dev-so \
> already-stripped \
> "

You say no the default one, but PN is "the default" one, so that's
probably why that doesn't work.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [prelink-cross][PATCH] Support copy relocations in .data.rel.ro

[Kyle Russell]

Do you want me to just resent my last two patches?  I don't mind if that
would be easier, and I'll remember to add the Signed-off-by. :)

On Fri, Oct 12, 2018 at 10:00 AM Mark Hatle 
wrote:

> On 10/4/18 9:12 AM, Kyle Russell wrote:
> > Hey Mark,
> >
> > Do you think this approach is reasonable?  If so, I have another patch
> I'd like
> > to propose that would enable us to better catch error scenarios (like
> the last
> > two patches address) that we might encounter during do_image_prelink.
> We just
> > happened to detect these last two issues even though image_prelink
> didn't fail
> > the build, so I'd like to provide an option to enable a little more
> assertive
> > error path, if desired.
>
> I'm getting caught back up on my prelink 'TODO' set.  The approach seems
> reasonable to me.  However, I appear to have lost the reference to the
> original
> patch email.
>
> I'm going to try to reapply from this email (or the list archive), but I
> may
> need you to resend it.  I'll let you [and others know] once I get these
> things
> merged.
>
> Thanks!
> --Mark
>
> > Thanks,
> > Kyle
> >
> > On Fri, Sep 28, 2018 at 10:57 AM Kyle Russell  > > wrote:
> >
> > binutils-2.28 (17026142ef35b62ac88bfe517b4160614902cb28) adds support
> > for copying read-only dynamic symbols into .data.rel.ro <
> http://data.rel.ro>
> > instead of .bss
> > since .bss is technically writable.  This causes prelink to error
> out on
> > any binary containing COPY relocations in .data.rel.ro <
> http://data.rel.ro>.
> >
> > Read-only variables defined in shared libraries should be copied
> directly
> > into the space allocated for them in .data.rel.ro <
> http://data.rel.ro> by
> > the linker.
> >
> > To achieve this, we determine whether either of the two sections
> > containing copy relocations is .data.rel.ro .
> If so, we
> > relocate the
> > symbol memory directly into the existing section instead of
> constructing
> > a new .(s)dynbss section once prelink_build_conflicts() returns.
> >
> > Fixes cxx1.sh, cxx2.sh, and cxx3.sh on Fedora 28 (which uses
> > binutils-2.29).
> > ---
> >  src/conflict.c | 51
> +-
> >  src/undo.c |  9 +
> >  2 files changed, 47 insertions(+), 13 deletions(-)
> >
> > diff --git a/src/conflict.c b/src/conflict.c
> > index 9ae2ddb..5613ace 100644
> > --- a/src/conflict.c
> > +++ b/src/conflict.c
> > @@ -450,7 +450,7 @@ get_relocated_mem (struct prelink_info *info,
> DSO *dso,
> > GElf_Addr addr,
> >  int
> >  prelink_build_conflicts (struct prelink_info *info)
> >  {
> > -  int i, ndeps = info->ent->ndepends + 1;
> > +  int i, reset_dynbss = 0, reset_sdynbss = 0, ndeps =
> info->ent->ndepends + 1;
> >struct prelink_entry *ent;
> >int ret = 0;
> >DSO *dso;
> > @@ -675,6 +675,11 @@ prelink_build_conflicts (struct prelink_info
> *info)
> >  dso->filename);
> >   goto error_out;
> > }
> > +
> > + name = strptr (dso, dso->ehdr.e_shstrndx,
> dso->shdr[bss1].sh_name);
> > + if (strcmp(name, ".data.rel.ro ") ==
> 0)
> > +   reset_sdynbss = 1;
> > +
> >   firstbss2 = i;
> >   info->sdynbss_size = cr.rela[i - 1].r_offset -
> cr.rela[0].r_offset;
> >   info->sdynbss_size += cr.rela[i - 1].r_addend;
> > @@ -702,6 +707,10 @@ prelink_build_conflicts (struct prelink_info
> *info)
> > }
> > }
> >
> > +  name = strptr (dso, dso->ehdr.e_shstrndx,
> dso->shdr[bss2].sh_name);
> > +  if (strcmp(name, ".data.rel.ro ") == 0)
> > +reset_dynbss = 1;
> > +
> >info->dynbss_size = cr.rela[cr.count - 1].r_offset
> >   - cr.rela[firstbss2].r_offset;
> >info->dynbss_size += cr.rela[cr.count - 1].r_addend;
> > @@ -719,9 +728,9 @@ prelink_build_conflicts (struct prelink_info
> *info)
> >   && strcmp (name = strptr (dso, dso->ehdr.e_shstrndx,
> > dso->shdr[bss1].sh_name),
> >  ".dynbss") != 0
> > - && strcmp (name, ".sdynbss") != 0)
> > + && strcmp (name, ".sdynbss") != 0 && strcmp (name, ".
> data.rel.ro
> > ") != 0)
> > {
> > - error (0, 0, "%s: COPY relocations don't point into .bss
> or .sbss
> > section",
> > + error (0, 0, "%s: COPY relocations don't point into .bss,
> .sbss,
> > or .data.rel.ro  sections",
> >  dso->filename);
> >   goto error_out;
> > }
> > @@ -730,9 +739,9 @@ prelink_build_conflicts (struct prelink_info
> *info)
> >   && strcmp 

Re: [yocto] [prelink-cross][PATCH] Support copy relocations in .data.rel.ro

[Mark Hatle]

On 10/4/18 9:12 AM, Kyle Russell wrote:
> Hey Mark,
> 
> Do you think this approach is reasonable?  If so, I have another patch I'd 
> like
> to propose that would enable us to better catch error scenarios (like the last
> two patches address) that we might encounter during do_image_prelink.  We just
> happened to detect these last two issues even though image_prelink didn't fail
> the build, so I'd like to provide an option to enable a little more assertive
> error path, if desired.

I'm getting caught back up on my prelink 'TODO' set.  The approach seems
reasonable to me.  However, I appear to have lost the reference to the original
patch email.

I'm going to try to reapply from this email (or the list archive), but I may
need you to resend it.  I'll let you [and others know] once I get these things
merged.

Thanks!
--Mark

> Thanks,
> Kyle
> 
> On Fri, Sep 28, 2018 at 10:57 AM Kyle Russell  > wrote:
> 
> binutils-2.28 (17026142ef35b62ac88bfe517b4160614902cb28) adds support
> for copying read-only dynamic symbols into .data.rel.ro 
> 
> instead of .bss
> since .bss is technically writable.  This causes prelink to error out on
> any binary containing COPY relocations in .data.rel.ro 
> .
> 
> Read-only variables defined in shared libraries should be copied directly
> into the space allocated for them in .data.rel.ro  by
> the linker.
> 
> To achieve this, we determine whether either of the two sections
> containing copy relocations is .data.rel.ro .  If so, 
> we
> relocate the
> symbol memory directly into the existing section instead of constructing
> a new .(s)dynbss section once prelink_build_conflicts() returns.
> 
> Fixes cxx1.sh, cxx2.sh, and cxx3.sh on Fedora 28 (which uses
> binutils-2.29).
> ---
>  src/conflict.c | 51 +-
>  src/undo.c     |  9 +
>  2 files changed, 47 insertions(+), 13 deletions(-)
> 
> diff --git a/src/conflict.c b/src/conflict.c
> index 9ae2ddb..5613ace 100644
> --- a/src/conflict.c
> +++ b/src/conflict.c
> @@ -450,7 +450,7 @@ get_relocated_mem (struct prelink_info *info, DSO 
> *dso,
> GElf_Addr addr,
>  int
>  prelink_build_conflicts (struct prelink_info *info)
>  {
> -  int i, ndeps = info->ent->ndepends + 1;
> +  int i, reset_dynbss = 0, reset_sdynbss = 0, ndeps = 
> info->ent->ndepends + 1;
>    struct prelink_entry *ent;
>    int ret = 0;
>    DSO *dso;
> @@ -675,6 +675,11 @@ prelink_build_conflicts (struct prelink_info *info)
>                      dso->filename);
>               goto error_out;
>             }
> +
> +         name = strptr (dso, dso->ehdr.e_shstrndx, 
> dso->shdr[bss1].sh_name);
> +         if (strcmp(name, ".data.rel.ro ") == 0)
> +           reset_sdynbss = 1;
> +
>           firstbss2 = i;
>           info->sdynbss_size = cr.rela[i - 1].r_offset - 
> cr.rela[0].r_offset;
>           info->sdynbss_size += cr.rela[i - 1].r_addend;
> @@ -702,6 +707,10 @@ prelink_build_conflicts (struct prelink_info *info)
>             }
>         }
> 
> +      name = strptr (dso, dso->ehdr.e_shstrndx, dso->shdr[bss2].sh_name);
> +      if (strcmp(name, ".data.rel.ro ") == 0)
> +        reset_dynbss = 1;
> +
>        info->dynbss_size = cr.rela[cr.count - 1].r_offset
>                           - cr.rela[firstbss2].r_offset;
>        info->dynbss_size += cr.rela[cr.count - 1].r_addend;
> @@ -719,9 +728,9 @@ prelink_build_conflicts (struct prelink_info *info)
>           && strcmp (name = strptr (dso, dso->ehdr.e_shstrndx,
>                                     dso->shdr[bss1].sh_name),
>                      ".dynbss") != 0
> -         && strcmp (name, ".sdynbss") != 0)
> +         && strcmp (name, ".sdynbss") != 0 && strcmp (name, ".data.rel.ro
> ") != 0)
>         {
> -         error (0, 0, "%s: COPY relocations don't point into .bss or 
> .sbss
> section",
> +         error (0, 0, "%s: COPY relocations don't point into .bss, .sbss,
> or .data.rel.ro  sections",
>                  dso->filename);
>           goto error_out;
>         }
> @@ -730,9 +739,9 @@ prelink_build_conflicts (struct prelink_info *info)
>           && strcmp (name = strptr (dso, dso->ehdr.e_shstrndx,
>                                     dso->shdr[bss2].sh_name),
>                      ".dynbss") != 0
> -         && strcmp (name, ".sdynbss") != 0)
> +         && strcmp (name, ".sdynbss") != 0 && strcmp (name, ".data.rel.ro
> ") != 0)
>         {
> -         error (0, 0, "%s: COPY relocations don't point into .bss or 
> 

[yocto] [meta-cgl][PATCH 1/2] cluster-glue: support multiple dbg packages

[Hongxu Jia]

Since `da5ec06 package: Add auto package splitting of .debug file'
applied in oe-core, only one dbg package is split by default,
set NOAUTOPACKAGEDEBUG = '1' to support multiple dbg packages

Use `=+' to replace `+=', it will split user define sub package first

Add missing dirs to FILES_${PN}-dbg

Signed-off-by: Hongxu Jia 
---
 meta-cgl-common/recipes-cgl/cluster-glue/cluster-glue_1.0.12.bb | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta-cgl-common/recipes-cgl/cluster-glue/cluster-glue_1.0.12.bb 
b/meta-cgl-common/recipes-cgl/cluster-glue/cluster-glue_1.0.12.bb
index c8a3ff6..0673482 100644
--- a/meta-cgl-common/recipes-cgl/cluster-glue/cluster-glue_1.0.12.bb
+++ b/meta-cgl-common/recipes-cgl/cluster-glue/cluster-glue_1.0.12.bb
@@ -70,7 +70,8 @@ pkg_postinst_${PN} () {
fi
 }
 
-PACKAGES += "\
+NOAUTOPACKAGEDEBUG = "1"
+PACKAGES =+ "\
 ${PN}-plugin-test \
 ${PN}-plugin-test-dbg \
 ${PN}-plugin-test-staticdev \
@@ -104,7 +105,10 @@ FILES_${PN} = "${sysconfdir} /var ${libdir}/lib*.so.* 
${sbindir} ${datadir}/clus
"
 
 FILES_${PN}-dbg += "${libdir}/heartbeat/.debug/ \
+${sbindir}/.debug/ \
+${libdir}/.debug/ \
"
+
 FILES_${PN}-plugin-compress = "${libdir}/heartbeat/plugins/compress/*.so"
 FILES_${PN}-plugin-compress-staticdev = 
"${libdir}/heartbeat/plugins/compress/*.*a"
 FILES_${PN}-plugin-compress-dbg = 
"${libdir}/heartbeat/plugins/compress/.debug/"
-- 
2.7.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-cgl][PATCH 2/2] resource-agents: support multiple dbg packages

[Hongxu Jia]

Since `da5ec06 package: Add auto package splitting of .debug file'
applied in oe-core, only one dbg package is split by default,
set NOAUTOPACKAGEDEBUG = '1' to support multiple dbg packages

Correct dirs for FILES_${PN}-extra/FILES_${PN}-extra-dbg/
FILES_${PN}-dbg, previously dirs are obsolete.

Signed-off-by: Hongxu Jia 
---
 .../recipes-cgl/cluster-resource-agents/resource-agents_4.0.1.bb  | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git 
a/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents_4.0.1.bb 
b/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents_4.0.1.bb
index 2a9643b..8b2b8e1 100644
--- 
a/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents_4.0.1.bb
+++ 
b/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents_4.0.1.bb
@@ -55,11 +55,12 @@ do_install_append() {
 # tickle_tcp is published under GPLv3, we just split it into ${PN}-extra,
 # and it's required by portblock, so move portblock into ${PN}-extra together.
 PACKAGES_prepend  = "${PN}-extra ${PN}-extra-dbg ldirectord "
-FILES_${PN}-extra = "${libdir}/resource-agents/heartbeat/tickle_tcp \
+NOAUTOPACKAGEDEBUG = "1"
+FILES_${PN}-extra = "${libexecdir}/heartbeat/tickle_tcp \
  ${libdir}/ocf/resource.d/heartbeat/portblock \
  ${datadir}/resource-agents/ocft/configs/portblock \
 "
-FILES_${PN}-extra-dbg += 
"${libdir}/resource-agents/heartbeat/.debug/tickle_tcp"
+FILES_${PN}-extra-dbg = "${libexecdir}/heartbeat/.debug/tickle_tcp"
 
 FILES_ldirectord = " \
 ${sbindir}/ldirectord \
@@ -101,4 +102,5 @@ FILES_${PN} += "${datadir}/cluster/* \
 "
 
 FILES_${PN}-dbg += "${libdir}/ocf/resource.d/heartbeat/.debug \
-${libdir}/resource-agents/heartbeat/.debug "
+${sbindir}/.debug \
+${libexecdir}/heartbeat/.debug "
-- 
2.7.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto