[OE-core] [meta-oe] modemmanager: Upgrade 1.10.6 -> 1.10.8
Includes: Fix for an issue presenting after 1.10.6 update where modem
would enter status denied state.
See:
https://cgit.freedesktop.org/ModemManager/ModemManager/commit/?h=1.10.8=47fd8a1e55cac0b0b45812e1dda826f38c264d1b
Signed-off-by: Michael Scott
---
.../{modemmanager_1.10.6.bb => modemmanager_1.10.8.bb}| 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta-oe/recipes-connectivity/modemmanager/{modemmanager_1.10.6.bb =>
modemmanager_1.10.8.bb} (92%)
diff --git a/meta-oe/recipes-connectivity/modemmanager/modemmanager_1.10.6.bb
b/meta-oe/recipes-connectivity/modemmanager/modemmanager_1.10.8.bb
similarity index 92%
rename from meta-oe/recipes-connectivity/modemmanager/modemmanager_1.10.6.bb
rename to meta-oe/recipes-connectivity/modemmanager/modemmanager_1.10.8.bb
index 92d4fe0f4..3cd21cc0d 100644
--- a/meta-oe/recipes-connectivity/modemmanager/modemmanager_1.10.6.bb
+++ b/meta-oe/recipes-connectivity/modemmanager/modemmanager_1.10.8.bb
@@ -14,8 +14,8 @@ DEPENDS = "glib-2.0 libgudev intltool-native libxslt-native"
SRC_URI =
"http://www.freedesktop.org/software/ModemManager/ModemManager-${PV}.tar.xz \
"
-SRC_URI[md5sum] = "7452a94f0d1ca361ae51ff1d287c53f5"
-SRC_URI[sha256sum] =
"3c2ca73782215664141042422759899ca9846440fc26d6223c7cf7ea4dd3c996"
+SRC_URI[md5sum] = "c05ac4246c81cc15d617c4a129232988"
+SRC_URI[sha256sum] =
"cbe174078dbdf3f746a55f0004353d3c27da2a31da553036d90fc7dc34a0169a"
S = "${WORKDIR}/ModemManager-${PV}"
--
2.24.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [OE-Core][PATCH] kernel-fitimage: uboot-sign: Check UBOOT_DTB_BINARY before adding deps
Hi Alex and Richard, On Wed, Jun 12, 2019, 9:06 PM Alex Kiernan wrote: > Hi Mike > > On Wed, Jun 12, 2019 at 11:59 PM Michael Scott wrote: > > > > > > On 6/12/19 3:21 PM, richard.pur...@linuxfoundation.org wrote: > > > On Wed, 2019-06-12 at 14:17 -0700, Michael Scott wrote: > > >> Actually, you can ignore this patch. We debugged the actual race > > >> condition contributing to the confusion, and that developer will > > >> submit a new patch with that fix. We can review if that patch makes > > >> more sense (even without tests). > > > Well, this patch merged earlier this evening as tested passed. Is that > > > a problem? > > > > Not a problem at all. I believe we also kept this change when we > > debugged the actual race condition. > > > > Wrong patch you're pointing to here? I'm guessing you meant > https://patchwork.openembedded.org/patch/161440/ You are 100% correct. I was checking email on the phone and it trimmed the subject line. Please ignore my comments with regard to this patch. Richard: You are still correct in that the u-boot signing process needs tests. My apologies, - Mike > > > -- > Alex Kiernan > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [OE-Core][PATCH] kernel-fitimage: uboot-sign: Check UBOOT_DTB_BINARY before adding deps
On 6/12/19 3:21 PM, richard.pur...@linuxfoundation.org wrote: On Wed, 2019-06-12 at 14:17 -0700, Michael Scott wrote: Actually, you can ignore this patch. We debugged the actual race condition contributing to the confusion, and that developer will submit a new patch with that fix. We can review if that patch makes more sense (even without tests). Well, this patch merged earlier this evening as tested passed. Is that a problem? Not a problem at all. I believe we also kept this change when we debugged the actual race condition. The test would need to follow: 1) Is there a pub key in the u-boot.dtb (symlinked file) in the deploy directory and is it the same as what is generated by mkimage when pointing at the fitImage in the deploy directory. 2) The race condition affects the build when there is a cached step built incorrectly. The cached build step injects the u-boot.dtb prior to it being signed. That does help explain the problem you were seeing and does some like something we could/should be testing for. Yes if possible the test should run #1 above - 3 ways: 1) clean cache for kernel/u-boot/u-boot tools, 2) cached run for kernel/u-boot/u-boot tools and 3) cached for kernel/u-boot tools, but changed u-boot (invalidate cache?) - Mike Cheers, Richard -- Michael Scott Embedded Software Engineer at Foundries.io "microPlatforms™ for Connected Products" E: m...@foundries.io W: https://www.foundries.io -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [OE-Core][PATCH] kernel-fitimage: uboot-sign: Check UBOOT_DTB_BINARY before adding deps
Hi Richard, On 6/12/19 11:02 AM, Alex Kiernan wrote: On Wed, Jun 12, 2019 at 10:59 AM Richard Purdie wrote: On Wed, 2019-06-12 at 09:15 +0100, Alex Kiernan wrote: Since UBOOT_DTB_BINARY empty means we don't need to inject signatures into the U-Boot DTB, we can remove the dependencies between consumers of these two classes and resolve a circular dependency between u-boot and kernel. Signed-off-by: Alex Kiernan --- meta/classes/kernel-fitimage.bbclass | 2 +- meta/classes/uboot-sign.bbclass | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Really wish we had tests and documentation for these classes... I know... I have a dread anytime anyone touches it, me included... I sat on this change for a couple of weeks too. The truth is the pair of them are fragile and hopelessly intertwined, but without tests they're never going to get rewritten, so I might try and take some of that on (or get someone here to do it) as I still have multiple issues with them - signing doesn't really work the way I want, I still have a circular dependency I've not tracked down, doubtless other things I can't immediately bring to mind. If we were to add some tests around it, what would you pull out as the simplest thing that it could do which would be valuable? Actually, you can ignore this patch. We debugged the actual race condition contributing to the confusion, and that developer will submit a new patch with that fix. We can review if that patch makes more sense (even without tests). The test would need to follow: 1) Is there a pub key in the u-boot.dtb (symlinked file) in the deploy directory and is it the same as what is generated by mkimage when pointing at the fitImage in the deploy directory. 2) The race condition affects the build when there is a cached step built incorrectly. The cached build step injects the u-boot.dtb prior to it being signed. Hopefully that makes sense, - Mike -- Michael Scott Embedded Software Engineer at Foundries.io "microPlatforms™ for Connected Products" E: m...@foundries.io W: https://www.foundries.io -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] uboot-sign: change u-boot do_deploy concat_dtb() hook to postfuncs
The u-boot signing process consists of 3 actions which must happen in
the right order in order to generate a correct u-boot.dtb with the
public key information which is appended to the u-boot binary.
This process is described in a long comment at the top of
uboot-sign.bbclass:
1. u-boot build generates initial version of u-boot binary and
appended u-boot.dtb. Then, via do_install_append() a copy of
this file and a symlink are added to the datadir (part of
do_install step)
2. Kernel build then picks up the u-boot dtb from the datadir and
adds the public key information during mkimage call in "Step 7"
of kernel-fitimage.bbclass::do_assemble_fitimage(). The build
system makes sure that we add the signed version of the u-boot
dtb by adding do_assemble_fitimage() as a dependency to u-boot's
do_populate_sysroot() step.
3. u-boot do_deploy then executes a new *postfuncs* hook for
"concat_dtb" which deploys a re-created u-boot binary (appended
dtb now has public key).
However, the actual code which adds the handler to u-boot's do_deploy,
sets the hook addition as "prefuncs". This ends up creating a very
racy build which for me was deploying the wrong u-boot binary because
concat_dtb was running before the fitimage was being assembled
(and adding the public key to the u-boot.dtb)
Let's set the concat_dtb step to "postfuncs" as the comment claims
which fixes the order of operations and generates the correct
u-boot.bin in the deploy directory.
Signed-off-by: Michael Scott
---
meta/classes/uboot-sign.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/uboot-sign.bbclass b/meta/classes/uboot-sign.bbclass
index 8beafff7c0..202b18502b 100644
--- a/meta/classes/uboot-sign.bbclass
+++ b/meta/classes/uboot-sign.bbclass
@@ -125,5 +125,5 @@ python () {
# kernerl's do_deploy is a litle special, so we can't use
# do_deploy_append, otherwise it would override
# kernel_do_deploy.
-d.appendVarFlag('do_deploy', 'prefuncs', ' concat_dtb')
+d.appendVarFlag('do_deploy', 'postfuncs', ' concat_dtb')
}
--
2.21.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] kernel-fitimage: generate a default conf@ entry for non-dtb images
Step 5 of fitimage_assemble() creates a series of configurations
for each kernel DTB referenced in the fitimage. These
configurations are usually used as bootm parameters to alias items
like the kernel and ramdisk, etc. The conf@ entries are also used
when generating signature data for verified boot.
Boards without kernel DTBs in the fitimage skip this step and no
conf@ entries are generated. This presents a problem if the u-boot
scripts still wish to use the conf@ references for the kernel and
ramdisk.
Examples of this would be using QEMU ARM64 or RISC-V based .WIC
images with a vfat boot partition and ext4 rootfs. The fitImage
is stored in the boot partition similar to other actual HW.
However, without the conf@ entry the boot scripts still need to
use kernel@1 and ramdisk@1 hard-coded references.
Also, a u-boot patch is currently being tested which adds signing
/ verified boot functionality for HW which doesn't use appended
u-boot DTBs. IE: QEMU uses prior stage hand-off and Raspberry
Pi 3 uses an embedded DTB, etc. By having the conf@ entry in the
fitImage, the entire OE signing process "just works" for testing
this new setup.
Signed-off-by: Michael Scott
---
meta/classes/kernel-fitimage.bbclass | 7 +++
1 file changed, 7 insertions(+)
diff --git a/meta/classes/kernel-fitimage.bbclass
b/meta/classes/kernel-fitimage.bbclass
index 2820ff9689..8ade9eb410 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -458,6 +458,13 @@ fitimage_assemble() {
fi
i=`expr ${i} + 1`
done
+ else
+ # insert 1 default configuration w/o DTBs
+ if [ "x${ramdiskcount}" = "x1" ] ; then
+ fitimage_emit_section_config ${1}
"${kernelcount}" "" "${ramdiskcount}" "${setupcount}" ""
+ else
+ fitimage_emit_section_config ${1}
"${kernelcount}" "" "" "${setupcount}" ""
+ fi
fi
fitimage_emit_section_maint ${1} sectend
--
2.21.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] procps: update legacy sysctl.conf to fix rp_filter sysctl issue
The sysctl.conf file for procps is very outdated: https://git.openembedded.org/openembedded-core/commit/?id=8a9b9a323f4363e27138077e3e3dce8139a36708 (circa 2014) The origin of this file is hard to determine and due to it's age is causing a routing issue when both wifi and ethernet are enabled. This manifested during an update from thud -> warrior due to the following: - upstream change in NetworkManager during 1.16 cycle removes the dynamic setting of rp_filter sysctl when more than one interface is enabled: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=b1082aa9a711deb96652e5b2fcaefcf399d127b8 - open-embedded updated to NetworkManager 1.16 in March 2019: https://git.openembedded.org/meta-openembedded/commit/meta-networking/recipes-connectivity/networkmanager?id=5509328af9e4fab267251456f4d6e7bd51df779a - setting in legacy sysctl.conf sets rp_filter to 1 which blocks packets with different inbound and outbound addresses. Documentation of rp_filter setting from kernel.org: rp_filter - INTEGER 0 - No source validation. 1 - Strict mode as defined in RFC3704 Strict Reverse Path Each incoming packet is tested against the FIB and if the interface is not the best reverse path the packet check will fail. By default failed packets are discarded. 2 - Loose mode as defined in RFC3704 Loose Reverse Path Each incoming packet's source address is also tested against the FIB and if the source address is not reachable via any interface the packet check will fail. This patch updates the sysctl.conf file to current which doesn't set the rp_filter mode explicity (2 is the default). NOTE: The kernel/pid_max=1 setting has been commented out as this may not be desired by default. Signed-off-by: Michael Scott --- .../procps/procps/sysctl.conf | 105 +- 1 file changed, 54 insertions(+), 51 deletions(-) diff --git a/meta/recipes-extended/procps/procps/sysctl.conf b/meta/recipes-extended/procps/procps/sysctl.conf index 34e7488bf7..253f3701bd 100644 --- a/meta/recipes-extended/procps/procps/sysctl.conf +++ b/meta/recipes-extended/procps/procps/sysctl.conf @@ -1,64 +1,67 @@ -# This configuration file is taken from Debian. +# This configuration taken from procps v3.3.15 +# Commented out kernel/pid_max=1 line # # /etc/sysctl.conf - Configuration file for setting system variables # See sysctl.conf (5) for information. -# -#kernel.domainname = example.com +# you can have the CD-ROM close when you use it, and open +# when you are done. +#dev.cdrom.autoeject = 1 +#dev.cdrom.autoclose = 1 -# Uncomment the following to stop low-level messages on console -#kernel.printk = 4 4 1 7 +# protection from the SYN flood attack +net/ipv4/tcp_syncookies=1 -##3 -# Functions previously found in netbase -# +# see the evil packets in your log files +net/ipv4/conf/all/log_martians=1 -# Uncomment the next two lines to enable Spoof protection (reverse-path filter) -# Turn on Source Address Verification in all interfaces to -# prevent some spoofing attacks -net.ipv4.conf.default.rp_filter=1 -net.ipv4.conf.all.rp_filter=1 +# makes you vulnerable or not :-) +net/ipv4/conf/all/accept_redirects=0 +net/ipv4/conf/all/accept_source_route=0 +net/ipv4/icmp_echo_ignore_broadcasts =1 -# Uncomment the next line to enable TCP/IP SYN cookies -#net.ipv4.tcp_syncookies=1 +# needed for routing, including masquerading or NAT +#net/ipv4/ip_forward=1 -# Uncomment the next line to enable packet forwarding for IPv4 -#net.ipv4.ip_forward=1 +# sets the port range used for outgoing connections +#net.ipv4.ip_local_port_range = 3276861000 -# Uncomment the next line to enable packet forwarding for IPv6 -#net.ipv6.conf.all.forwarding=1 +# Broken routers and obsolete firewalls will corrupt the window scaling +# and ECN. Set these values to 0 to disable window scaling and ECN. +# This may, rarely, cause some performance loss when running high-speed +# TCP/IP over huge distances or running TCP/IP over connections with high +# packet loss and modern routers. This sure beats dropped connections. +#net.ipv4.tcp_ecn = 0 +# Swapping too much or not enough? Disks spinning up when you'd +# rather they didn't? Tweak these. +#vm.vfs_cache_pressure = 100 +#vm.laptop_mode = 0 +#vm.swappiness = 60 -### -# Additional settings - these settings can improve the network -# security of the host and prevent against some network attacks -# including spoofing attacks and man in the middle attacks through -# redirection. Some network environments, however, require that these -# settings are disabled so review and enable them as needed. -# -# Ignore ICMP broadcasts -#net.ipv4.icmp_echo_ignore_broadcasts = 1 -# -# Ignore bogus ICMP errors -#net.ipv4.icmp_ignore_bogus_error_responses = 1 -# -# Do not accept ICMP redirects (prevent MITM attacks) -#net.i
Re: [OE-core] [PATCH v2] kernel-fitimage: support RISC-V
On 4/23/19 2:37 AM, Richard Purdie wrote:
On Fri, 2019-04-19 at 10:41 -0700, Michael Scott wrote:
On 4/12/19 9:56 PM, Michael Scott wrote:
Support RISC-V kernel image, using the "Image" target.
This change allows RISC-V support for fitImage via the following
flow: OpenSBI -> u-boot (as payload) -> Linux kernel (as fitImage
with ramdisk and dtb).
This was tested using QEMU RISC-V 64-bit.
Signed-off-by: Michael Scott
---
meta/classes/kernel-fitimage.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/kernel-fitimage.bbclass
b/meta/classes/kernel-fitimage.bbclass
index 2517d75746..09abedff8e 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -8,7 +8,7 @@ python __anonymous () {
d.setVar("DEPENDS", depends)
uarch = d.getVar("UBOOT_ARCH")
-if uarch == "arm64":
+if uarch == "arm64" or uarch == "riscv":
I didn't see any response to this v2 patch. Is this approach
acceptible? RISC-V should not attempt to use zImage for fitImage as
it now stands.
I think the v1 patch was merged. I'd take a patch to tweak the code to
the v2 version as it is slightly neater but its not essential.
Cheers,
Richard
Thank you for pointing out that v1 got merged. I didn't realize there
isn't a notification for when patches are merged and wasn't watching the
warrior branches. I'll submit the tweak patch later this week.
- Mike
--
Michael Scott
Embedded Software Engineer at Foundries.io
"microPlatforms™ for Connected Products"
E: m...@foundries.io
W: https://www.foundries.io
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] kernel-fitimage: support RISC-V
On 4/12/19 9:56 PM, Michael Scott wrote:
Support RISC-V kernel image, using the "Image" target.
This change allows RISC-V support for fitImage via the following
flow: OpenSBI -> u-boot (as payload) -> Linux kernel (as fitImage
with ramdisk and dtb).
This was tested using QEMU RISC-V 64-bit.
Signed-off-by: Michael Scott
---
meta/classes/kernel-fitimage.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/kernel-fitimage.bbclass
b/meta/classes/kernel-fitimage.bbclass
index 2517d75746..09abedff8e 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -8,7 +8,7 @@ python __anonymous () {
d.setVar("DEPENDS", depends)
uarch = d.getVar("UBOOT_ARCH")
-if uarch == "arm64":
+if uarch == "arm64" or uarch == "riscv":
I didn't see any response to this v2 patch. Is this approach
acceptible? RISC-V should not attempt to use zImage for fitImage as it
now stands.
replacementtype = "Image"
elif uarch == "mips":
replacementtype = "vmlinuz.bin"
--
Michael Scott
Embedded Software Engineer at Foundries.io
"microPlatforms™ for Connected Products"
E: m...@foundries.io
W: https://www.foundries.io
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kernel-fitimage: support RISC-V
On Sat, Apr 13, 2019, 1:49 PM Alistair Francis wrote:
> On Fri, Apr 12, 2019 at 9:56 PM Michael Scott wrote:
> >
> >
> > On 4/12/19 10:17 AM, Alistair Francis wrote:
> > > On Thu, Apr 11, 2019 at 10:46 PM Michael Scott
> wrote:
> > >> Support RISC-V kernel image, using the "Image" target.
> > >>
> > >> This change allows RISC-V support for fitImage via the following
> > >> flow: OpenSBI -> u-boot (as payload) -> Linux kernel (as fitImage
> > >> with ramdisk and dtb).
> > >>
> > >> This was tested using QEMU RISC-V 64-bit.
> > > Do you mind sharing how you tested this? I would be interested in
> > > trying this as well.
> > The current OE-based manifest for the Foundries.io Linux microPlatform
> > is found here (v42):
> > https://github.com/foundriesio/lmp-manifest
> >
> > However, I think you're interested in seeing the
> > opensbi/u-boot/fit-image work for qemuriscv64, and that won't land until
> > v43 (along with kernel 5.0.6 update).
> >
> > It should be ready in a few days. I can send you a private ping then,
> > if you'd like.
>
> If you wouldn't mind that would be great! I'm interested in adding FIT
> image OpenSBI -> u-boot -> Linux boot support to meta-riscv.
>
Ah, in that case it's fairly easy. We're using master branch meta-riscv
with this PR: https://github.com/foundriesio/meta-lmp/pull/27
- Mike
> Alistair
>
> >
> > The documentation is here:
> > https://docs.foundries.io/latest/reference/linux-building.html
> >
> > - Mike
> >
> > >
> > > Alistair
> > >
> > >> Signed-off-by: Michael Scott
> > >> ---
> > >> meta/classes/kernel-fitimage.bbclass | 2 ++
> > >> 1 file changed, 2 insertions(+)
> > >>
> > >> diff --git a/meta/classes/kernel-fitimage.bbclass
> b/meta/classes/kernel-fitimage.bbclass
> > >> index 2517d75746..2820ff9689 100644
> > >> --- a/meta/classes/kernel-fitimage.bbclass
> > >> +++ b/meta/classes/kernel-fitimage.bbclass
> > >> @@ -10,6 +10,8 @@ python __anonymous () {
> > >> uarch = d.getVar("UBOOT_ARCH")
> > >> if uarch == "arm64":
> > >> replacementtype = "Image"
> > >> +elif uarch == "riscv":
> > >> +replacementtype = "Image"
> > >> elif uarch == "mips":
> > >> replacementtype = "vmlinuz.bin"
> > >> elif uarch == "x86":
> > >> --
> > >> 2.21.0
> > >>
> > >> --
> > >> ___
> > >> Openembedded-core mailing list
> > >> Openembedded-core@lists.openembedded.org
> > >> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >
> > --
> > Michael Scott
> > Embedded Software Engineer at Foundries.io
> > "microPlatforms™ for Connected Products"
> > E: m...@foundries.io
> > W: https://www.foundries.io
> >
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] kernel-fitimage: support RISC-V
Support RISC-V kernel image, using the "Image" target.
This change allows RISC-V support for fitImage via the following
flow: OpenSBI -> u-boot (as payload) -> Linux kernel (as fitImage
with ramdisk and dtb).
This was tested using QEMU RISC-V 64-bit.
Signed-off-by: Michael Scott
---
meta/classes/kernel-fitimage.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/kernel-fitimage.bbclass
b/meta/classes/kernel-fitimage.bbclass
index 2517d75746..09abedff8e 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -8,7 +8,7 @@ python __anonymous () {
d.setVar("DEPENDS", depends)
uarch = d.getVar("UBOOT_ARCH")
-if uarch == "arm64":
+if uarch == "arm64" or uarch == "riscv":
replacementtype = "Image"
elif uarch == "mips":
replacementtype = "vmlinuz.bin"
--
2.21.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kernel-fitimage: support RISC-V
On 4/12/19 10:17 AM, Alistair Francis wrote:
On Thu, Apr 11, 2019 at 10:46 PM Michael Scott wrote:
Support RISC-V kernel image, using the "Image" target.
This change allows RISC-V support for fitImage via the following
flow: OpenSBI -> u-boot (as payload) -> Linux kernel (as fitImage
with ramdisk and dtb).
This was tested using QEMU RISC-V 64-bit.
Do you mind sharing how you tested this? I would be interested in
trying this as well.
The current OE-based manifest for the Foundries.io Linux microPlatform
is found here (v42):
https://github.com/foundriesio/lmp-manifest
However, I think you're interested in seeing the
opensbi/u-boot/fit-image work for qemuriscv64, and that won't land until
v43 (along with kernel 5.0.6 update).
It should be ready in a few days. I can send you a private ping then,
if you'd like.
The documentation is here:
https://docs.foundries.io/latest/reference/linux-building.html
- Mike
Alistair
Signed-off-by: Michael Scott
---
meta/classes/kernel-fitimage.bbclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/classes/kernel-fitimage.bbclass
b/meta/classes/kernel-fitimage.bbclass
index 2517d75746..2820ff9689 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -10,6 +10,8 @@ python __anonymous () {
uarch = d.getVar("UBOOT_ARCH")
if uarch == "arm64":
replacementtype = "Image"
+elif uarch == "riscv":
+replacementtype = "Image"
elif uarch == "mips":
replacementtype = "vmlinuz.bin"
elif uarch == "x86":
--
2.21.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Michael Scott
Embedded Software Engineer at Foundries.io
"microPlatforms™ for Connected Products"
E: m...@foundries.io
W: https://www.foundries.io
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kernel-fitimage: support RISC-V
On 4/12/19 9:35 AM, Khem Raj wrote:
On Thu, Apr 11, 2019 at 10:46 PM Michael Scott <mailto:m...@foundries.io>> wrote:
Support RISC-V kernel image, using the "Image" target.
This change allows RISC-V support for fitImage via the following
flow: OpenSBI -> u-boot (as payload) -> Linux kernel (as fitImage
with ramdisk and dtb).
This was tested using QEMU RISC-V 64-bit.
Signed-off-by: Michael Scott mailto:m...@foundries.io>>
---
meta/classes/kernel-fitimage.bbclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/classes/kernel-fitimage.bbclass
b/meta/classes/kernel-fitimage.bbclass
index 2517d75746..2820ff9689 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -10,6 +10,8 @@ python __anonymous () {
uarch = d.getVar("UBOOT_ARCH")
if uarch == "arm64":
replacementtype = "Image"
+ elif uarch == "riscv":
+ replacementtype = "Image"
Make it or condition along with arm64 check
Sure, sending v2.
elif uarch == "mips":
replacementtype = "vmlinuz.bin"
elif uarch == "x86":
--
2.21.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
<mailto:Openembedded-core@lists.openembedded.org>
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Michael Scott
Embedded Software Engineer at Foundries.io
"microPlatforms™ for Connected Products"
E: m...@foundries.io
W: https://www.foundries.io
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] kernel-fitimage: support RISC-V
Support RISC-V kernel image, using the "Image" target.
This change allows RISC-V support for fitImage via the following
flow: OpenSBI -> u-boot (as payload) -> Linux kernel (as fitImage
with ramdisk and dtb).
This was tested using QEMU RISC-V 64-bit.
Signed-off-by: Michael Scott
---
meta/classes/kernel-fitimage.bbclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/classes/kernel-fitimage.bbclass
b/meta/classes/kernel-fitimage.bbclass
index 2517d75746..2820ff9689 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -10,6 +10,8 @@ python __anonymous () {
uarch = d.getVar("UBOOT_ARCH")
if uarch == "arm64":
replacementtype = "Image"
+elif uarch == "riscv":
+replacementtype = "Image"
elif uarch == "mips":
replacementtype = "vmlinuz.bin"
elif uarch == "x86":
--
2.21.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
