> De: "Trevor Woerner"
> À: ydir...@free.fr
> Cc: "Khem Raj" , "Yocto-mailing-list"
>
> Envoyé: Mercredi 23 Juin 2021 14:51:39
> Objet: Re: [yocto] [meta-rockchip][PATCH 1/4] centralize console settings
>
> On Wed 2021-06-23 @ 08:10:07 PM, ydir...@free.fr wrote:
> > > De: "Khem Raj"
> > > À:
- Mail original -
> De: "Khem Raj"
> À: "Trevor Woerner"
> Cc: "Yocto-mailing-list"
> Envoyé: Mercredi 23 Juin 2021 11:32:57
> Objet: Re: [yocto] [meta-rockchip][PATCH 1/4] centralize console settings
>
> On Wed, Jun 23, 2021 at 8:25 AM Trevor Woerner
> wrote:
> >
> > The console
From: Yann Dirson
This is a RK3328 board from Pine64.
Board details at https://wiki.pine64.org/wiki/ROCK64.
Default image is built to boot from SD-card. Building an image for
eMMC requires to set RK_BOOT_DEVICE="mmcblk0".
Signed-off-by: Yann Dirson
---
This is just basic initi
Le mar. 15 juin 2021 à 10:16, Trevor Woerner a écrit :
>
> On Tue 2021-06-15 @ 10:03:31 AM, Yann Dirson wrote:
> > Le lun. 14 juin 2021 à 18:19, Trevor Woerner a écrit :
> > >
> > > Hi Yann,
> > >
> > > Thanks for the contribution!
> > >
Le lun. 14 juin 2021 à 18:19, Trevor Woerner a écrit :
>
> Hi Yann,
>
> Thanks for the contribution!
>
> On Mon 2021-05-31 @ 04:00:58 PM, yann.dir...@blade-group.com wrote:
> > From: Yann Dirson
> >
> > This is a RK3328 board from Pine64.
> > Board deta
From: Yann Dirson
This is a RK3328 board from Pine64.
Board details at https://wiki.pine64.org/wiki/ROCK64.
Default image is built to boot from SD-card. Building an image for
eMMC requires to set RK_BOOT_DEVICE="mmcblk0".
Signed-off-by: Yann Dirson
---
This is just basic initi
Le lun. 31 mai 2021 à 10:20, Yann Dirson via lists.yoctoproject.org
a écrit :
>
> From: Yann Dirson
>
> This is a RK3328 board from Pine64.
> Board details at https://wiki.pine64.org/wiki/ROCK64.
>
> Signed-off-by: Yann Dirson
> ---
>
> This is just basic initia
From: Yann Dirson
This is a RK3328 board from Pine64.
Board details at https://wiki.pine64.org/wiki/ROCK64.
Signed-off-by: Yann Dirson
---
This is just basic initial support without a kernel BSP. As is the
board boots with a serial console.
Note I had to create the SoC definition for rk3328
From: Yann Dirson
Take the firmware from rbwifibt, as a compatible one does not seem to
be available in broadcom-bt-firmware.
Disclaimer: I have only been able to scan/pair with devices, I could
not establish a connection. However, with the same board I've had the
same results with the board
From: Yann Dirson
This patch provides "standard" and "tiny" BSP.
There is still much work to be done in dispatching feature to individual
scc files - the more boards we can support the better it will get.
Not all SoC/board features are covered yet either (esp. Wifi/Blue
From: Yann Dirson
This is required for wifi support on nanopi-m4 with kernel 5.10.
This is dependant on poky commit commit
698fd81c551b52ff7f4a26e42d9acf9ad4ce5639,
"linux-firmware: include all relevant files in -bcm4356".
This file was fetched from
https://github.com/armbian/firmw
From: Yann Dirson
With this version the most board features work (Wifi requires recent
poky master for a linux-firmware fix), except for the audio jack and
possibly Bluetooth support (the WIP patches are mostly here for
discussion).
I'm not especially happy with the BT support:
- it uses
From: Yann Dirson
---
conf/machine/include/nanopi-m4.inc| 5 -
recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.cfg | 5 +
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/conf/machine/include/nanopi-m4.inc
b/conf/machine/include/nanopi-m4.inc
index
From: Yann Dirson
As far as the AP6356S in NanoPi-m4 is concerned, the included wifi firmware
is for Rockchip's kernel tree, but for Bluetooth firmware this seems to be
the proper "upstream" package.
Changes from Rockchip's version:
- use /lib/firmware/brcm/, not /system/etc/firmware/
From: Yann Dirson
There is a known issue in mainline kernel making the machine unusable
once a HDMI screen is plugged. This patch lets VOPB be alone to use
the HDMI port and avoids the issue while providing wupport for the largest
set of video modes, at the expense of double-screen support
Le mer. 12 mai 2021 à 20:33, Diego Santa Cruz
a écrit :
>
> > -Original Message-
> > From: yocto@lists.yoctoproject.org On
> > Behalf Of Bruce Ashfield via lists.yoctoproject.org
> > Sent: 12 May 2021 16:25
> > To: Yann Dirson
> > Cc: Yocto d
Le mer. 12 mai 2021 à 16:25, Bruce Ashfield a écrit :
>
> On Wed, May 12, 2021 at 10:07 AM Yann Dirson
> wrote:
> >
> > Thanks for those clarifications!
> >
> > Some additional questions below
> >
> > Le mer. 12 mai 2021 à 15:19, Bruce Ashfield a
Thanks for those clarifications!
Some additional questions below
Le mer. 12 mai 2021 à 15:19, Bruce Ashfield a écrit :
>
> On Wed, May 12, 2021 at 7:14 AM Yann Dirson
> wrote:
> >
> > I am currently working on a kmeta BSP for the rockchip-based NanoPI M4
> > [
here I'm providing both "standard" and "tiny"
KTYPE's ?
[1] https://lists.yoctoproject.org/g/yocto/message/53454
[2] https://lists.yoctoproject.org/g/yocto/message/53452
[3] https://lists.yoctoproject.org/g/yocto/topic/61340326
Best regards,
--
Yann Dirson
Blade / Shadow -- http:/
From: Yann Dirson
Take the firmware from rbwifibt, as a compatible one does not seem to
be available in broadcom-bt-firmware.
Disclaimer: I have only been able to scan/pair with devices, I could
not establish a connection. However, with the same board I've had the
same results with the board
From: Yann Dirson
As far as the AP6356S in NanoPi-m4 is concerned, the included wifi firmware
is for Rockchip's kernel tree, but for Bluetooth firmware this seems to be
the proper "upstream" package.
Changes from Rockchip's version:
- use /lib/firmware/brcm/, not /system/etc/firmware/
From: Yann Dirson
---
conf/machine/include/nanopi-m4.inc| 5 -
recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.cfg | 5 +
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/conf/machine/include/nanopi-m4.inc
b/conf/machine/include/nanopi-m4.inc
index
From: Yann Dirson
This patch provides "standard" and "tiny" BSP.
There is still much work to be done in dispatching feature to individual
scc files - the more boards we can support the better it will get.
Not all SoC/board features are covered yet either (esp. Wifi/Blue
From: Yann Dirson
There is a known issue in mainline kernel making the machine unusable
once a HDMI screen is plugged. This patch lets VOPB be alone to use
the HDMI port and avoids the issue while providing wupport for the largest
set of video modes, at the expense of double-screen support
From: Yann Dirson
With this version the Wifi works (requires recent poky master for a
linux-firmware fix).
I'm not especially happy with the BT support:
- it uses the rkwifibt repo because I don't have any other BT firmware
for this chip
- I was not able to get it to work on the board I have
From: Yann Dirson
This is required for wifi support on nanopi-m4 with kernel 5.10.
This is dependant on poky commit commit
698fd81c551b52ff7f4a26e42d9acf9ad4ce5639,
"linux-firmware: include all relevant files in -bcm4356".
This file was fetched from
https://github.com/armbian/firmw
From: Yann Dirson
There is a known issue in mainline kernel making the machine unusable
once a HDMI screen is plugged. This patch lets VOPB be alone to use
the HDMI port and avoids the issue while providing wupport for the largest
set of video modes, at the expense of double-screen support
From: Yann Dirson
The Wifi/BT support requires firmware, to be properly packaged; BT
support itself is still buggy in mainline; audio jack requires a
couple of patches.
Changes in v5:
- removed AP6356S-related config options, will come later with proper
wifi/bt support
- removed
From: Yann Dirson
This patch provides "standard" and "tiny" BSP.
There is still much work to be done in dispatching feature to individual
scc files - the more boards we can support the better it will get.
Not all SoC/board features are covered yet either (esp. Wifi/Blue
Le mar. 4 mai 2021 à 23:03, Trevor Woerner a écrit :
>
> On Mon 2021-04-26 @ 04:58:10 PM, yann.dir...@blade-group.com wrote:
> > From: Yann Dirson
> >
> > This patch provides "standard" and "tiny" BSP.
> >
> > There is still much work to be
e interested in ROOTLESS_X="1", to open a non-priviledged X11 session.
>
> Regards,
> Vijay
>
>
--
Yann Dirson
Blade / Shadow -- http://shadow.tech
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53289): https://lists.yoctop
From: Yann Dirson
Signed-off-by: Yann Dirson
---
conf/machine/include/nanopi-m4.inc | 2 ++
1 file changed, 2 insertions(+)
diff --git a/conf/machine/include/nanopi-m4.inc
b/conf/machine/include/nanopi-m4.inc
index 603160f..a14b705 100644
--- a/conf/machine/include/nanopi-m4.inc
+++ b/conf
From: Yann Dirson
This patch provides "standard" and "tiny" BSP.
There is still much work to be done in dispatching feature to individual
scc files - the more boards we can support the better it will get.
Not all SoC/board features are covered yet either (esp. Wifi/Blue
From: Yann Dirson
Changes in v4:
- install our bsp files in bsp/rockchip/ rather than directly in bsp/
- also add "serial" to MACHINE_FEATURES
Changes in v3:
- relocate the bsp files into files/ so we don't have to add linux-yocto/
to FILESEXTRAPATHS for all other kernels
- removed
From: Yann Dirson
This will allow us to define a single set of kernel BSP for all
variants of the board (which only need to differ in u-boot dts).
Signed-off-by: Yann Dirson
---
conf/machine/include/nanopi-m4.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/conf/machine/include/nanopi
> create mode 100644 recipes-kernel/linux/files/bsp/nanopi-m4-standard.scc
> create mode 100644 recipes-kernel/linux/files/bsp/nanopi-m4-tiny.scc
> create mode 100644 recipes-kernel/linux/files/bsp/nanopi-m4.cfg
> create mode 100644 recipes-kernel/linux/files/bsp/nanopi-m4.scc
> create mode
Le ven. 23 avr. 2021 à 19:19, Joshua Watt a écrit :
>
>
> On 4/23/21 11:58 AM, Yann Dirson wrote:
>
> From: Yann Dirson
>
> Changes from v2:
> - turn the DISTRO_FEATURE idea into separate RFC patches so as to allow
>merging of basic support
> - remove optee-os
From: Yann Dirson
This causes OP-TEE to get included into the u-boot.itb fitImage so u-boot
can load it for the trusted-firmware-a BL31 to run it.
This has to be enabled through PACKAGECONFIG += "optee".
Signed-off-by: Yann Dirson
---
recipes-bsp/u-boot/u-boot%.bbappend | 8 ++
From: Yann Dirson
This sets up a central switch for OP-TEE operation, activating support
in all dependent recipes at the same time:
- u-boot
- trusted-firmware-a
- kernel (not part of this patch, has to be implemented separately)
Signed-off-by: Yann Dirson
---
recipes-bsp/trusted-firmware
From: Yann Dirson
FIXME:
- this is not specific to the board, and would indeed apply to any SoC
supported by OP-TEE.
- should rather be selected by "optee" in DISTRO_FEATURES, maybe using
a dts overlay
---
.../0001-nanopi-declare-optee-presence.patch | 30 ++
From: Yann Dirson
FIXME:
- provide an .scc with proper information
- maybe bundle with dts overlay
- select a more suitable path in config namespace
---
recipes-kernel/linux/files/bsp/tee.cfg | 2 ++
1 file changed, 2 insertions(+)
create mode 100644 recipes-kernel/linux/files/bsp/tee.cfg
From: Yann Dirson
As discussed in https://github.com/OP-TEE/optee_os/issues/4542, ASLR
support currently has to be disabled for OP-TEE to boot.
Signed-off-by: Yann Dirson
---
conf/machine/include/rk3399.inc | 2 +
...399-enable-serial-console-by-default.patch | 52
From: Yann Dirson
This is meant as a safeguard against having optee-os included without the
required support in u-boot and trusted-firmware-a.
Signed-off-by: Yann Dirson
---
recipes-security/optee/optee%.bbappend | 3 +++
1 file changed, 3 insertions(+)
diff --git a/recipes-security/optee
From: Yann Dirson
Changes from v2:
- turn the DISTRO_FEATURE idea into separate RFC patches so as to allow
merging of basic support
- remove optee-os patch that proved unnecessary
Changes from v1:
- fix last-minute typo in TFA_SPD setting, which led to optee not being started
- use
From: Yann Dirson
This instructs TF-A to:
- load OP-TEE OS as BL32, but still relies on the actual image to be
provided through other means, eg. in u-boot.itb
- run opteed as Secure Payload Dispatcher
This has to be enabled through PACKAGECONFIG += "optee".
Signed-off-by: Y
From: Yann Dirson
This patch provides "standard" and "tiny" BSP.
There is still much work to be done in dispatching feature to individual
scc files - the more boards we can support the better it will get.
Not all SoC/board features are covered yet either (esp. Wifi/Blue
From: Yann Dirson
Changes from in v3:
- relocate the bsp files into files/ so we don't have to add linux-yocto/
to FILESEXTRAPATHS for all other kernels
- removed the "don't force KCONFIG_MODE to alldefconfig" (not needed finally,
and causing interferences in default setup)
- ad
From: Yann Dirson
Lets USB tools be installed if the distro activates the feature.
Signed-off-by: Yann Dirson
---
conf/machine/include/nanopi-m4.inc | 2 ++
1 file changed, 2 insertions(+)
diff --git a/conf/machine/include/nanopi-m4.inc
b/conf/machine/include/nanopi-m4.inc
index 603160f
From: Yann Dirson
This will allow us to define a single set of kernel BSP for all
variants of the board (which only need to differ in u-boot dts).
Signed-off-by: Yann Dirson
---
conf/machine/include/nanopi-m4.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/conf/machine/include/nanopi
From: Yann Dirson
This is the current state of working patches being discussed in
https://github.com/OP-TEE/optee_os/issues/4542
---
conf/machine/include/rk3399.inc | 2 +
...399-enable-serial-console-by-default.patch | 46 +++
.../optee/files/rk3399-boot
From: Yann Dirson
FIXME:
- provide an .scc with proper information
- maybe bundle with dts overlay
- select a more suitable path in config namespace
---
recipes-kernel/linux/files/bsp/tee.cfg | 2 ++
1 file changed, 2 insertions(+)
create mode 100644 recipes-kernel/linux/files/bsp/tee.cfg
From: Yann Dirson
This instructs TF-A to:
- load OP-TEE OS as BL32, but still relies on the actual image to be
provided through other means, eg. in u-boot.itb
- run opteed as Secure Payload Dispatcher
This is configured automatically when DISTRO_FEATURE includes "optee".
From: Yann Dirson
FIXME:
- this is not specific to the board, and would indeed apply to any SoC
supported by OP-TEE.
- should rather be selected by "optee" in DISTRO_FEATURES, maybe using
a dts overlay
---
.../0001-nanopi-declare-optee-presence.patch | 30 ++
From: Yann Dirson
This tries to provide a generic framework for easier OP-TEE support in
BSP layers. It would probably make sense to have the generic parts in
meta-arm when they are finalized. Today the kernel/dts handling is
still not properly done, and patches to fix rk3399 support in OP-TEE
From: Yann Dirson
This causes OP-TEE to get included into the u-boot.itb fitImage so u-boot
can load it for the trusted-firmware-a BL31 to run it.
This is configured automatically when DISTRO_FEATURE includes "optee".
Signed-off-by: Yann Dirson
---
recipes-bsp/u-boot/u-boot%.bb
From: Yann Dirson
This effectively sets up a single switch to activate OP-TEE support.
Disabling optee-* recipes when the feature is not set is not the
primary goal, though it can occasionally be handy to catch
dependencies pulling them without using the new DISTRO_FEATURE, which
provides
From: Yann Dirson
FIXME:
- provide an .scc with proper information
- maybe bundle with dts overlay
- select a more suitable path in config namespace
---
recipes-kernel/linux/files/bsp/tee.cfg | 2 ++
1 file changed, 2 insertions(+)
create mode 100644 recipes-kernel/linux/files/bsp/tee.cfg
From: Yann Dirson
FIXME:
- this is not specific to the board, and would indeed apply to any SoC
supported by OP-TEE.
- should rather be selected by "optee" in DISTRO_FEATURES, maybe using
a dts overlay
---
.../0001-nanopi-declare-optee-presence.patch | 30 ++
From: Yann Dirson
This is the current state of working patches being discussed in
https://github.com/OP-TEE/optee_os/issues/4542
---
conf/machine/include/rk3399.inc | 2 +
...399-enable-serial-console-by-default.patch | 46 +++
.../optee/files/rk3399-boot
From: Yann Dirson
This effectively sets up a single switch to activate OP-TEE support.
Disabling optee-* recipes when the feature is not set is not the
primary goal, though it can occasionally be handy to catch
dependencies pulling them without using the new DISTRO_FEATURE, which
provides
From: Yann Dirson
This causes OP-TEE to get included into the u-boot.itb fitImage so u-boot
can load it for the trusted-firmware-a BL31 to run it.
This is configured automatically when DISTRO_FEATURE includes "optee".
Signed-off-by: Yann Dirson
---
recipes-bsp/u-boot/u-boot%.bba
From: Yann Dirson
This tries to provide a generic framework for easier OP-TEE support in
BSP layers. It would probably make sense to have the generic parts in
meta-arm when they are finalized. Today the kernel/dts handling is
still not properly done, and patches to fix rk3399 support in OP-TEE
From: Yann Dirson
This instructs TF-A to:
- load OP-TEE OS as BL32, but still relies on the actual image to be
provided through other means, eg. in u-boot.itb
- run opteed as Secure Payload Dispatcher
This is configured automatically when DISTRO_FEATURE includes "optee".
From: Yann Dirson
TF-A runs between two u-boot stages which both uses 150 baud, it
just makes no sense to use the same UART at a different rate.
Here is a sample session with the successive stages, with TF-A artificially
separated for emphasis:
[20210406-175438.135934] U-Boot TPL 2021.01
hat's the vendor BSP settings. Would we have good technical reasons
to switch back ?
>
> My two cent addendum/thinking,
> Zee
> ___
>
>
> On Wed, Apr 7, 2021 at 1:47 AM Yann Dirson
> wrote:
> >
> > From: Yann Dirson
> >
> > TF-A runs between tw
From: Yann Dirson
TF-A runs between two u-boot stages which both uses 150 baud, it
just makes no sense to use the same UART at a different rate.
Here is a sample session with the successive stages, with TF-A artificially
separated for emphasis:
[20210406-175438.135934] U-Boot TPL 2021.01
es as needed, or their own .cfg snippets if no existing
feature matches.
Did i overlook some use-case that would not be covered ?
Le jeu. 25 mars 2021 à 18:11, Yann Dirson via lists.yoctoproject.org
a écrit :
>
> = "Hi Trevor,
>
> Le mer. 24 mars 2021 à 01:41, Trevor Woerner
From: Yann Dirson
This second iteration adds support for KBUILD_DEFCONFIG="", as well as
a loosely-related patch to avoid touching KCONFIG_MODE.
Kernel weight:
- standard11MB
- tiny 5MB
- tiny with no defconfig 2.5MB
Changes in v2:
- adde
From: Yann Dirson
This patch provides "standard" and "tiny" BSP.
There is still much work to be done in dispatching feature to individual
scc files - the more boards we can support the better it will get.
Not all SoC features are covered yet either.
Tiny is not really test
From: Yann Dirson
When using in-kernel defconfig this is already the default, but
linux-yocto defaults to "allnoconfig" mode when a defconfig is
specified in SRC_URI, and there is no reason to override this
globally.
---
conf/machine/include/rockchip-defaults.inc | 1 -
1 file
From: Yann Dirson
Signed-off-by: Yann Dirson
---
conf/machine/include/nanopi-m4.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/conf/machine/include/nanopi-m4.inc
b/conf/machine/include/nanopi-m4.inc
index 74cdae8..603160f 100644
--- a/conf/machine/include/nanopi-m4.inc
+++ b/conf
From: Yann Dirson
Signed-off-by: Yann Dirson
---
...{linux-yocto-dev.bbappend => linux-yocto%.bbappend} | 0
recipes-kernel/linux/linux-yocto-rt_%.bbappend | 10 --
recipes-kernel/linux/linux-yocto-tiny_%.bbappend | 10 --
recipes-kernel/linux/linux-yoc
From: Yann Dirson
---
...{linux-yocto-dev.bbappend => linux-yocto%.bbappend} | 0
recipes-kernel/linux/linux-yocto-rt_%.bbappend | 10 --
recipes-kernel/linux/linux-yocto-tiny_%.bbappend | 10 --
recipes-kernel/linux/linux-yocto_%.bbappend|
From: Yann Dirson
---
conf/machine/include/nanopi-m4.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/conf/machine/include/nanopi-m4.inc
b/conf/machine/include/nanopi-m4.inc
index 74cdae8..603160f 100644
--- a/conf/machine/include/nanopi-m4.inc
+++ b/conf/machine/include/nanopi-m4.inc
From: Yann Dirson
This patch provides "standard" and "tiny" BSP.
There is still much work to be done in dispatching feature to individual
scc files - the more boards we can support the better it will get.
It's sad that when a different kernel type is selected, and
From: Yann Dirson
This is a first draft of a kmeta BSP for nanopi-m4, with rough
granularity for now. For testing and comments. See patch 3 to
play with "linux-yocto-tiny" config.
Yann Dirson (3):
linux-yocto: reduce bbappend duplication
NanoPi-M4: let all variants use the sam
= "Hi Trevor,
Le mer. 24 mars 2021 à 01:41, Trevor Woerner a écrit :
>
> On Tue 2021-03-23 @ 12:59:24 PM, Yann Dirson wrote:
> > Hi Trevor,
> >
> > Le lun. 22 mars 2021 à 16:50, Trevor Woerner a écrit :
> > > > BTW, I'm also unclear on what to do ne
s.
One possibility would be using a KERNEL_CONFIG_VARIANT variable, whose
values would select consistent sets of KBUILD_DEFCONFIG + KCONFIG_MODE
+ SRC_URI_append. Standard variants could include "mainline" as the
default, and
maybe "customhw" which would bring just the hw fe
From: Yann Dirson
We have two board variants, respectively with 2GB and 4GB RAM.
Signed-off-by: Yann Dirson
---
Changes from v2:
- commit message rework
- add wic.bmap
Changes from v1:
- split in two distinct machines: nanopi-m4 and nanopi-m4-2gb
conf/machine/include/nanopi-m4.inc
Hi Joshua,
Le lun. 22 mars 2021 à 19:24, Joshua Watt a écrit :
>
>
> On 3/22/21 9:59 AM, Yann Dirson wrote:
>
> Hi Trevor,
>
> Le lun. 22 mars 2021 à 15:47, Trevor Woerner a écrit :
>
> On Mon 2021-03-22 @ 02:42:12 PM, yann.dir...@blade-group.com wrote:
>
> T
to provide defconfig files for those machines,
but then there are
several options to handle that. Would a minimal hw-focused defconfig
suitable for
`KCONFIG_MODE = "--allnoconfig"` be a good option ?
Le lun. 22 mars 2021 à 16:00, Yann Dirson via lists.yoctoproject.org
a écrit :
>
> H
From: Yann Dirson
---
Changes from v1: split in two distinct machines: nanopi-m4 and nanopi-m4-2gb
conf/machine/include/nanopi-m4.inc| 22 +++
conf/machine/nanopi-m4-2gb.conf | 8 +++
conf/machine/nanopi-m4.conf | 8
a standard way to specify such hardware
variants, that
would be recognized as such by the layer index ?
--
Yann Dirson
Blade / Shadow -- http://shadow.tech
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52792): https://lists.yoctoproject.
From: Yann Dirson
This supports both the 2GB and 4GB versions of the board. This is not
done with 2 different machine definitions since only u-boot has to
change between those two configurations, but with a NANOPIM4_HW variable
to set in local.conf.
Note I could only test the 2GB version
Le mar. 16 févr. 2021 à 18:43, Pokybuild User <
pokybu...@centos8-ty-1.yocto.io> a écrit :
>
> Build hash information:
>
> bitbake: 0a3bf681530bd63fc0036ca81ef868ab53fde56c
> meta-arm: aa63e31b6edb5197764c21434219050ab51f0fbd
> meta-gplv2: 6e8e969590a22a729db1ff342de57f2fd5d02d43
> meta-intel:
Oh, and beware of master and dunfell with llvm-config, if your target is
multilib.
You may need the patch referenced in
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13937
Le ven. 26 juin 2020 à 10:17, Yann Dirson a
écrit :
> Did you check that llvm-native is listed in the sysroot-provid
ta: Fix Deprecated warnings from regexs
> 0053740c01 llvm: Enable AMDGPU backend for native/native-sdk builds too
> 5e6e08512e llvm: Use HOST_ARCH in LLVM_TARGETS_TO_BUILD for builds
> 865eb1c140 llvm: Use YOCTO_ALTERNATE_MULTILIB_NAME environment variable
> in llvm-config
> 7153a
that package?
>
> Thank you.
>
> Kind regards,
>
> - jh
>
>
> --
> "A man can fail many times, but he isn't a failure until he begins to
> blame somebody else."
> -- John Burroughs
>
>
--
Yann Dirson
Blade / Shadow -- http://shadow.t
he diff within the submodule as a patch
> - so you leave the submodule commit pointer where it is and instead
> include all the necessary changes to the submodule in the patch. Would
> that work for you?
>
>
--
Yann Dirson
Blade / Shadow -- http://shadow.tech
-=-=-=-=-=-=-=-=-=-=
> > it attempts to boot, crosses bootloader and proceeds to linux boot but
> > then gets hing around dwmmc_rockchip loading.
> >
> > Attached the complete serial log. Your help is greatly appreciated.
>
> According to the log, your board is a "tinker-board-s", please
Le jeu. 19 mars 2020 à 18:04, Richard Purdie <
richard.pur...@linuxfoundation.org> a écrit :
> On Thu, 2020-03-19 at 17:29 +0100, Yann Dirson wrote:
> >
> >
> > Le jeu. 19 mars 2020 à 17:07, Mike Looijmans
> a écrit :
> > > On 19-03-2020 12:04, Richard
ovide a jub-server, all make-based recipes would
automatically get their jobs properly limited. There is a (sadly not
merged yet)
MR [1] for ninja tu gain job-server support as well, through which we
should have
a pretty good coverage of the recipes set (as a backend for cmake, meson,
and more).
account the
> number of cores and thus have a custom script which does caps the threads
> so that 2 gigs of RAM for each are available.
>
> Though I'm sure plain C and plain poky projects have less requirements for
> RAM.
>
> -Mikko
>
>
to this group.
>
> View/Reply Online (#47760):
> https://lists.yoctoproject.org/g/yocto/message/47760
> Mute This Topic: https://lists.yoctoproject.org/mt/68804558/3618661
> Group Owner: yocto+ow...@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [
>
94 matches
Mail list logo
