Hi Trevor,
No, that would be me missing a patch in my branch... :(
It should be 4.7.10, and it did compile yesterday.
My mistake, I'm adding that right now, please retry.
Herve
-Original Message-
From: Trevor Woerner [mailto:twoer...@gmail.com]
Sent: mardi 22 novembre 2016 19:30
To: Her
Hi Xiaohui,
On Tue, 22 Nov 2016 13:25:10 Xiaohui Liu wrote:
> Under what condition will a task be rerun? My understanding is that each
> task has a signature/checksum stored somewhere in tmp/. If the checksum
> changes, bitbake will look for shared state cache in SSTATE_DIR and then in
> SSTATE_MI
On 11/22/16 11:35 AM, Jianxun Zhang wrote:
> rmc works as a generic file-based solution now. There is no need
> to keep a special case for kernel command line type which was
> designed in early days.
>
> Signed-off-by: Jianxun Zhang
> ---
> inc/rmcl.h| 27 -
> src/lib/api.
Hi everyone,
Under what condition will a task be rerun? My understanding is that each
task has a signature/checksum stored somewhere in tmp/. If the checksum
changes, bitbake will look for shared state cache in SSTATE_DIR and then in
SSTATE_MIRRORS. If no match is found, the task is run. Is my und
Thanks Khem - actually this (including the ppc64 layer from openembedded)
is what I initially tried but it fails with the current master...
Most probably I am doing something very wrong - I guess I will have to
experiment a little further... Thanks again!
On Sat, Nov 19, 2016 at 7:35 PM, Khem Raj
This is a major re-work in rmc with several key changes:
To query board-specific data in a rmc database, developers
now can take advantage of new defined APIs, either using
single-action APIs for a better performance of multiple
queries or simply calling a double-action API, which is
sufficient to
rmc works as a generic file-based solution now. There is no need
to keep a special case for kernel command line type which was
designed in early days.
Signed-off-by: Jianxun Zhang
---
inc/rmcl.h| 27 -
src/lib/api.c | 4 +-
src/lib/common/rmcl.c | 32 +++
EFI Clients linked to rmc may or may not include standard header
files, and these definitions could be different too.
The existing macros like 'WORD' also bring ambiguity among
processor architectures, so we replace them with the new internal
data types.
This change takes whatever defined for typ
Update README file to reflect some major changes in the project:
Introduce API and libraries
arch-agnostic EFI build
remove dependencies in EFI build
Signed-off-by: Jianxun Zhang
---
README | 40 +---
1 file changed, 25 insertions(+), 15 deletions(-)
diff
The current RMC_CFLAGS worked as an interface for outside .But it
should be better to use this variable to hold internal flags and
respect CFLAGS passed from outside.
Also remove -O2 flag.
Signed-off-by: Jianxun Zhang
---
Makefile | 6 +++---
Makefile.efi | 4 ++--
2 files changed, 5 insert
The two were organized in different libraries from functionality
perspective. This change merges them into a single library to
simplify linking RMC into client. There should not be much extra
footprint on the binary size because they are very small and
always work together.
We move the code into a
This patch series is based on a previous patch
"rmc: Fix include path and type definitions" submitted
on Nov 15. It includes some large key enhancements inside rmc:
() Simplify two libs into one for each context, Linux or EFI
() Provide APIs for clients. They can use either single API
to perform
On Tue 2016-11-22 @ 05:23:49 PM, Herve Jourdain wrote:
> I didn't have any such branch, but I've created them now.
> They are located at: https://github.com/hjourdain/meta-raspberrypi and
> https://github.com/hjourdain/openembedded-core.
> I've just pushed my patches there. I've not tested out of
Hi Trevor,
I didn't have any such branch, but I've created them now.
They are located at: https://github.com/hjourdain/meta-raspberrypi and
https://github.com/hjourdain/openembedded-core.
I've just pushed my patches there. I've not tested out of those repositories
yet, but I did test those patch
Herve,
Any chance your patches are available in a tree somewhere? Maybe in a branch?
Maybe on github? ;-)
I would like to give them a try (build and boot).
Best regards,
Trevor
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoc
On Tue 2016-11-22 @ 02:54:20 AM, Trevor Woerner wrote:
> I'm currently trying 3ce7378bb505825f492615bd71d19a2339e5bf55, which is the
> current HEAD of the 4.8.y branch of the raspi kernel repository.
It builds if I:
diff --git a/recipes-kernel/linux/linux-raspberrypi_4.8.bb
b/recipes-ker
Hi,
I am trying to produce a baremetal cross-compiler for aarch64 using Jethro.
In my local.conf I set TCLIBC = "baremetal" and run bitbake meta-toolchain.
The first error is: Exception: KeyError: 'aarch64'.
I think insane.bbclass will need to be updated by adding aarch64 to elf:
"el
> From: "Paul Eggleton"
> Sent: Monday, 21 November, 2016 10:15:16 PM
> I suspect it has to do with the arch mapping that goes on in
> meta/classes/package_deb.bbclass; it probably doesn't understand the
> dummy
> architecture we're giving it. The thing is even if it were to be
> "corrected"
> to
18 matches
Mail list logo
