On 20/08/2021 20.18, Simon Glass wrote:
> Hi Harm,
>
> On Wed, 18 Aug 2021 at 08:09, Harm Berntsen wrote:
>>
>> On Thu, 2021-05-13 at 19:39 -0600, Simon Glass wrote:
>>> int clk_uclass_post_probe(struct udevice *dev)
>>> {
>>> + int ret;
>>> +
>>> /*
>>> * when a clock
On 15/10/2021 11.02, Peng Fan (OSS) wrote:
>
>
> On 2021/10/14 20:52, Rasmus Villemoes wrote:
>> Currently, if one builds for an iMX platform != imx8m and selects
>> CONFIG_SPL_BOOTROM_SUPPORT, the build breaks because some
>> definitions (struct rom_api, the enum
ant to tie this exclusively to use for verified
boot.
Signed-off-by: Rasmus Villemoes
---
Getting the public key metadata into .dtsi form can be done with a
little scripting (roughly 'mkimage -K' of a dummy image followed by
'dtc -I dtb -O dts'). I have a script that does that, along with
options to set
On 16/09/2021 18.52, Fabio Estevam wrote:
> Hi Rasmus,
>
> On Thu, Sep 16, 2021 at 11:53 AM Rasmus Villemoes
> wrote:
>>
>> Commit 0d52bab46 (mx7dsabre: Enable DM_ETH) changed these flags from 0
>> (aka GPIO_ACTIVE_HIGH) to GPIO_ACTIVE_LOW. It claimed to "Als
On 02/10/2021 02.38, Simon Glass wrote:
> At present U-Boot environment variables, and thus scripts, are defined
> by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text
> to this file and dealing with quoting and newlines is harder than it
> should be. It would be better if we
Please note that this is not a resubmission of fdt_add_pubkey, I merely
mentioned that in passing (and cc'ed Roman because of his interest in
that) as a previous attempt at solving the problem of getting the public
key info baked into U-Boot's .dtb, an approach that I've since learnt is
not
On 21/10/2021 18.03, Tom Rini wrote:
> On Thu, Oct 21, 2021 at 09:59:38AM -0600, Simon Glass wrote:
>> Hi Marek,
>>
>> On Thu, 21 Oct 2021 at 07:28, Marek Behún wrote:
>>>
>>> On Thu, 21 Oct 2021 15:25:37 +0200
>>> Marek Behún wrote:
>>>
Hello,
On Thu, 21 Oct 2021 15:06:51 +0200
Hi
I'm having trouble getting serial download to work on an imx8mp evk. I'm
building on top of v2021.10.
The SPL + U-Boot proper that I build work fine when I write them to an
SD card and boot from that, also boot from eMMC with the same binaries
works fine.
I can also succesfully get the SPL
On 24/10/2021 21.54, Simon Glass wrote:
> Hi Rasmus,
>
> On Fri, 22 Oct 2021 at 00:41, Rasmus Villemoes
> wrote:
>>
>> On 21/10/2021 18.03, Tom Rini wrote:
>>> On Thu, Oct 21, 2021 at 09:59:38AM -0600, Simon Glass wrote:
>>>> Hi Marek,
>>>&
On 28/09/2021 10.56, Rasmus Villemoes wrote:
> The build system already automatically looks for and includes an
> in-tree *-u-boot.dtsi when building the control .dtb. However, there
> are some things that are awkward to maintain in such an in-tree file,
> most notably the metadat
ant to tie this exclusively to use for verified
boot.
Reviewed-by: Simon Glass
Signed-off-by: Rasmus Villemoes
---
v2: rebase to current master, add paragraph to
doc/develop/devicetree/control.rst as suggested by Simon. I've taken
the liberty of keeping his R-b tag as this mostly just re
(1) When one wants to get rid of CONFIG_LEGACY_IMAGE_FORMAT, one also
has to wrap any boot script in a FIT rather than a uImage. While it's
not directly documented anywhere how to do that, it seems that a minimal
.its for achieving it is
/dts-v1/;
/ {
description = "U-Boot script(s)";
On 10/11/2021 01.18, Rasmus Villemoes wrote:
> On 09/11/2021 20.42, Tom Rini wrote:
>> On Tue, Nov 09, 2021 at 08:21:07PM +0100, Heiko Thiery wrote:
>>> Hi Wolfgang,
>>>
>
>>> I know this is not a perfect solution but I don't know how to get my
&
On 09/11/2021 20.42, Tom Rini wrote:
> On Tue, Nov 09, 2021 at 08:21:07PM +0100, Heiko Thiery wrote:
>> Hi Wolfgang,
>>
>> I know this is not a perfect solution but I don't know how to get my
>> board merged without doing this kind of workaround for the U-Boot CI.
>
> Unfortunately in these days
On 12/11/2021 20.28, Simon Glass wrote:
> At present mkimage supports signing FITs, the standard U-Boot image type.
>
> Various people are opposed to using FIT since:
>
> a) it requires adding support for FIT into other bootloaders, notably
>UEFI
> b) it requires packaging a kernel in this
On 27/10/2021 15.22, Tom Rini wrote:
> On Wed, Oct 27, 2021 at 12:43:38PM +0800, Bin Meng wrote:
>> Hi Simon,
>>
>> gitlab reported the following test error below:
>>
>> === FAILURES
>> ===
>> __
On 05/11/2021 11.16, Jan Kiszka wrote:
> Hi all,
>
> in order to use CONFIG_FIT_SIGNATURE and also
> CONFIG_SPL_FIT_SIGNATURE, a public key needs to be placed into the
> control FDT. So far, I only found mkimage being able to do that during
> FIT image signing. That is fairly unhandy and often
On 17/08/2021 08.17, Heiko Schocher wrote:
> cherry-picked from NXP code:
> 719d665a87c6: ("MLK-20467 imx8m: Fix issue for booting signed image through
> uuu")
>
> which fixes secure boot on imx8m based boards.
>
[...]
> Works on sdcard and QSPI NOR boot on phycore-imx8mp board.
Hm, the
On 25/10/2021 17.18, Simon Glass wrote:
> Hi Rasmus,
>
> On Mon, 25 Oct 2021 at 01:06, Rasmus Villemoes
> wrote:
>> Exactly, there's really never any case where that would be sensible. But
>> I would probably go a bit further and simply restrict varnames to the
>
On 26/10/2021 03.28, Simon Glass wrote:
> Hi Rasmus,
>
> On Tue, 28 Sept 2021 at 02:57, Rasmus Villemoes
> wrote:
>>
>> The build system already automatically looks for and includes an
>> in-tree *-u-boot.dtsi when building the control .dtb. However, there
>&
On 14/12/2021 09.23, c...@etri.re.kr wrote:
> Hello,
>
> Is there any way I can see the cpp output of a file (for example
> arch/arm/lib/vsprintf.c) after the build? (in the Makefile option for
> example)
make foo/bar/baz.i
for any foo/bar/baz.c file which normally produces foo/bar/baz.o.
If
On 10/12/2021 01.14, Simon Glass wrote:
> Hi,
>
> On Wed, 8 Dec 2021 at 11:10, Philippe REYNES
> wrote:
>>
>>
>> Everybody agrees with this proposal ?
>
> So long as this is not a shell script and is done with a binman entry, yes.
No, no and please no. Binman really isn't as wonderful and
On 17/11/2021 18.52, Philippe Reynes wrote:
> This commit adds a script gen_pre_load_header.sh
> that generate the header used by the image pre-load
> stage.
>
> Signed-off-by: Philippe Reynes
> ---
> tools/gen_pre_load_header.sh | 174 +++
> 1 file changed, 174
On 30/11/2021 17.02, Tom Rini wrote:
> On Tue, Nov 30, 2021 at 05:39:36PM +0200, Andy Shevchenko wrote:
>>> These files are products of `make O=...`. There are no issues when I
>>> build inside the tree (dunno why). But I definitely won't build in the
>>> source tree folder.
>>
>> I realized that
On 14/12/2021 16.10, Chan Kim wrote:
> But when I do
> make CROSS_COMPILE=aarch64-none-elf- lib/tiny-printf.1
> make: *** No rule to make target 'lib/tiny-printf.1'. Stop.
letter i , not digit 1
Rasmus
om all the
arch/*/dts/Makefile files to the new scripts/Makefile.dts.
Signed-off-by: Rasmus Villemoes
---
arch/arc/dts/Makefile| 2 ++
arch/arm/dts/Makefile| 2 ++
arch/m68k/dts/Makefile | 2 ++
arch/microblaze/dts/Makefile | 2 ++
arch/mips/dts/Makefile | 2 ++
ar
On 13/01/2022 13.52, Tom Rini wrote:
> On Thu, Jan 13, 2022 at 08:56:02AM +0100, Rasmus Villemoes wrote:
>> On 12/01/2022 22.56, Tom Rini wrote:
>>> I also think I've seen cases where doing:
>>> if (CONFIG_EVALUATES_TO_ZERO) {
>>> ...
>>> }
>>
Ping
On 21/11/2021 14.52, Rasmus Villemoes wrote:
> The build system already automatically looks for and includes an
> in-tree *-u-boot.dtsi when building the control .dtb. However, there
> are some things that are awkward to maintain in such an in-tree file,
> most notably
On 01/11/2021 02.17, Simon Glass wrote:
> Some bright sparks have decided that a cast on a constant cannot be a
> constant, so offsetof() produces this warning on clang-10:
>
> include/intel_gnvs.h:113:1: error: static_assert expression is not an
> integral constant expression
>
On 12/01/2022 22.56, Tom Rini wrote:
> On Wed, Jan 12, 2022 at 02:28:21PM -0700, Simon Glass wrote:
>> Hi Ilias,
>>
>> On Mon, 1 Nov 2021 at 01:05, Ilias Apalodimas
>> wrote:
>>>
>>> On Mon, 1 Nov 2021 at 03:19, Simon Glass wrote:
At present if an optional Kconfig value needs to be
On 19/01/2022 02.42, Simon Glass wrote:
> At present this has a minor bug in that it reads the byte before the
> start of the string.
Only for an empty string, AFAICS. Which is a bug, of course, but mostly
the caller is to blame.
Also it doesn't handle a non-numeric prefix which is
> only one
On 27/01/2022 16.06, Simon Glass wrote:
> Hi Rasmus,
>
> On Sun, 21 Nov 2021 at 07:55, Rasmus Villemoes
> wrote:
>>
>> (1) When one wants to get rid of CONFIG_LEGACY_IMAGE_FORMAT, one also
>> has to wrap any boot script in a FIT rather than a uImage. While i
On 14/01/2022 17.51, Simon Glass wrote:
> Hi Rasmus,
>
> On Tue, 26 Oct 2021 at 02:08, Rasmus Villemoes
> wrote:
>>
>> On 26/10/2021 03.28, Simon Glass wrote:
>>> Hi Rasmus,
>>>
>>> On Tue, 28 Sept 2021 at 02:57, Rasmus Villemoes
>>> w
On 25/01/2022 00.50, Simon Glass wrote:
> Hi Rasmus,
>
> On Mon, 24 Jan 2022 at 15:15, Rasmus Villemoes
> wrote:
>>
>> On 24/01/2022 18.57, Simon Glass wrote:
>>
>>>> And the thing about "adding the signature" - yes, indeed,
On 24/01/2022 18.57, Simon Glass wrote:
> Hi,
>
> On Mon, 24 Jan 2022 at 09:02, Tom Rini wrote:
>>
>> On Mon, Jan 10, 2022 at 02:34:41PM +0100, Rasmus Villemoes wrote:
>>
>>> When building for a custom board, it is quite common to maintain a
>>>
On 24/01/2022 18.57, Simon Glass wrote:
>> And the thing about "adding the signature" - yes, indeed, _signing_ can
>> and should be done after building. But that is not at all what this
>> started with, this is about embedding the metadata that U-Boot (or SPL)
>> will need for _verifying_ during
On 15/09/2023 15.05, João Paulo Silva Gonçalves wrote:
> Hi Marek,
>
> I was testing fastboot image download over usb for imx8mp (from usb
> recovery patch of verdin-imx8mp) and i am having error messages on
> endpoint request dequeue function of DWC3 gadget controller. However,
> download is
x_evm_a53_defconfig
am64x_evm_r5_defconfig
am65x_evm_a53_defconfig
am65x_hs_evm_a53_defconfig
iot2050_defconfig
j7200_evm_a72_defconfig
j721e_evm_a72_defconfig
j721s2_evm_a72_defconfig
j721s2_evm_r5_defconfig
verdin-am62_r5_defconfig
Signed-off-by: Rasmus Villemoes
---
common/spl/Kconfig
a risk of some boards
breaking. The solution for those boards will probably be to just drop
CONFIG_SYS_SPL_MALLOC, since that hasn't actually done anything.
Rasmus Villemoes (2):
spl: make SYS_SPL_MALLOC depend on !(SPL_STACK_R &&
SPL_SYS_MALLOC_SIMPLE)
malloc_sim
of
mem_malloc_init() which will actually update the bookkeeping variables
relevant to the actual and active malloc() implementation.
Signed-off-by: Rasmus Villemoes
---
common/dlmalloc.c | 2 +-
common/malloc_simple.c | 7 +++
include/malloc.h | 7 +--
3 files changed, 13
On 11/10/2023 20.37, Tom Rini wrote:
> On Thu, Sep 28, 2023 at 10:02:57AM +0200, Rasmus Villemoes wrote:
>
>> The man page correctly said that -B was ignored without -E, while the
>> `mkimage -h` output suggested otherwise. Now that -B can actually be
>> used by its
On 12/10/2023 04.17, Sean Anderson wrote:
> I was hoping you would respond to my most-recent email regarding this
> series.
> In particular:
>
> | Why does mkimage have to do this? Can't you just use truncate or, in a
> | binman context, align-size?
In both cases, that just affects the size of
On 17/10/2023 12.44, Richard Marko wrote:
> If we try to build using external dtc using
>
>> make DTC=dtc
>
> we get a confusing error like
>
>> make[2]: *** No rule to make target 'arch/x86/dts/bayleybay.dtb',
>> needed by 'dtbs'. Stop.
>
> Workaround is to use
>
>> make DTC=$( which dtc )
Hi,
I'm trying to resurrect an old submission of a driver for ti,lp5562, so
had occasion to dig into drivers/led/. And I think commit 83c63f0d118 is
buggy or at least incomplete.
Many of the drivers that were subsequently modified to not do that
"label" parsing rely, in their .probe method, on
On 25/10/2023 18.01, Marcel Ziswiler wrote:
> Hi Rasmus
>
> On Tue, 2023-10-24 at 16:32 +0200, Rasmus Villemoes wrote:
>> What am I missing?
>
> Good question. Some more debugging revealed that we are missing 464 bytes at
> the beginning of the buffer. Why
> woul
On 05/11/2023 21.03, Simon Glass wrote:
> This little series corrects a problem I noticed with arm64 images,
> where the kernel is not recognised:
The $subject is misleading, bootm works just fine with compressed arm64
images, with the type set to "kernel".
> Type: Kernel Image
On 07/11/2023 01.46, Sean Anderson wrote:
> On 10/13/23 14:30, Rasmus Villemoes wrote:
>> On 12/10/2023 04.17, Sean Anderson wrote:
>>
>>> I was hoping you would respond to my most-recent email regarding this
>>> series.
>>> In particular:
>>>
>
On 07/11/2023 08.30, Rasmus Villemoes wrote:
> I'll send a revert to Tom for the prematurely applied fixup.
Oh, I see that's already done. Good.
Rasmus
pagesize. Fix this by recording the actual bytes downloaded.
>
> Fixes: 4b4472438f5a ("imx: spl_imx_romapi: avoid tricky use of
> spl_load_simple_fit() to get full FIT size")
> Signed-off-by: Marcel Ziswiler
>
Thanks for reporting and fixing this, and sorry for the trouble.
Acked-by: Rasmus Villemoes
de-effect of
swallowing the first following char. But I never found the time to dig
into why or if it was even fixable.
Tom has already applied this, but nevertheless
Tested-by: Rasmus Villemoes
Rasmus
On 04/11/2023 20.43, Simon Glass wrote:
> Hi Rasmus,
> Are you planning a new version of this series?
No. AFAICT there's nothing to be done on my end.
Rasmus
().
Extend the logic in the csf.sh script so that the csf blob is padded
to CONFIG_CSF_SIZE minus the size of the IVT header.
Signed-off-by: Rasmus Villemoes
---
doc/imx/habv4/csf_examples/mx8m/csf.sh | 8
1 file changed, 8 insertions(+)
diff --git a/doc/imx/habv4/csf_examples/mx8m/csf.sh
b/doc
and not actually the node name.
Homogenize these cases and make imx8mp the same as the other imx8m*
variants. The binman type is explicitly given and no longer derived
from the node name, and the csf.sh script will work for all four SOCs.
Signed-off-by: Rasmus Villemoes
---
arch/arm/dts/imx8mp-u
On 19/09/2023 20.27, Marek Vasut wrote:
> On 9/19/23 12:00, Rasmus Villemoes wrote:
>> When built with CONFIG_IMX_HAB, the full FIT image, including stuff
>> tacked on beyond the end of the fdt structure, is expected to be (fdt
>> size rounded up to 0x1000 boundary)+CONFI
On 21/09/2023 03.02, Simon Glass wrote:
> Hi Rasmus,
>
> On Tue, 19 Sept 2023 at 05:37, Rasmus Villemoes
> wrote:
>>
>> In some cases, using the "external data" feature is impossible or
>> undesirable, but one may still want (or need) the FIT image to
().
Extend the logic in the csf.sh script so that the csf blob is padded
to CONFIG_CSF_SIZE minus the size of the IVT header.
Signed-off-by: Rasmus Villemoes
---
v2: use dd instead of truncate.
doc/imx/habv4/csf_examples/mx8m/csf.sh | 13 +
1 file changed, 13 insertions(+)
diff --git a/doc
On 25/09/2023 15.10, Simon Glass wrote:
> Hi Rasmus,
>
> On Mon, 25 Sept 2023 at 02:47, Rasmus Villemoes
> wrote:
>> Since patches 2,3,4 touch binman code, could you take all four?
>
> Yes, will do. I didn't pick them up in the most recent PR as I try to
> have t
On 20/06/2023 00.41, Tobias Deiminger wrote:
> quiet_cmd_wrap = WRAP$@
> -cmd_wrap = echo "\#include <../$(patsubst $(obj)/%,%,$@)>" >$@
> +cmd_wrap = echo "\#include <../$(patsubst $(obj)/generated/%,%,$@)>" >$@
>
> -$(obj)/boot/%.c $(obj)/common/%.c $(obj)/env/%.c $(obj)/lib/%.c:
>
On 25/09/2023 20.19, Tom Rini wrote:
> On Mon, Sep 25, 2023 at 10:27:43AM +0200, Rasmus Villemoes wrote:
>> On 04/05/2023 14.35, Rasmus Villemoes wrote:
>>> On 03/05/2023 16.54, Tom Rini wrote:
>>
>>>> The one last problem now is on stm32mp15_dhcor_basic which
Signed-off-by: Rasmus Villemoes
---
doc/mkimage.1 | 6 --
tools/mkimage.c | 2 +-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/doc/mkimage.1 b/doc/mkimage.1
index 76c7859bb0..1a4bc25936 100644
--- a/doc/mkimage.1
+++ b/doc/mkimage.1
@@ -281,8 +281,10 @@ properties. A \(oqdata
On 27/09/2023 21.02, Sean Anderson wrote:
> On 9/19/23 07:37, Rasmus Villemoes wrote:
>> In some cases, using the "external data" feature is impossible or
>> undesirable, but one may still want (or need) the FIT image to have a
>> certain alignment. Also, given
On 29/09/2023 18.02, Tom Rini wrote:
> On Fri, Sep 29, 2023 at 09:15:00AM -0600, Simon Glass wrote:
>> Honestly at this point I've forgotten what this is all about.
Fair enough, let me try to recap, though even a summary is a bit long.
(1) I wanted to do what $subject says, and you seemed to be
On 02/10/2023 20.56, Simon Glass wrote:
> Hi Tom,
>
> On Mon, 2 Oct 2023 at 10:22, Tom Rini wrote:
>>
>>> I'm really not sure that replacing build rules with a board CONFIG is
>>> a good idea. I suppose part of my confusion is why the Makefile is
>>> considered a problem?
>>
>> Because it's
On 03/10/2023 00.46, Tom Rini wrote:
> On Tue, Oct 03, 2023 at 12:27:25AM +0200, Heinrich Schuchardt wrote:
>>
>> error = stdio_register(dev);
>> -#if !defined(CONFIG_SPL_BUILD) || CONFIG_IS_ENABLED(ENV_SUPPORT)
>> -/* check if this is the standard input device */
>> -if (!error &&
On 25/09/2023 17.14, Jonas Karlman wrote:
>> fit,align
>> -Indicates what alignment to use for the FIT and its external data,
>> -and provides the alignment to use. This is passed to mkimage via
>> -the -B flag.
>> +Indicates what alignment to use for the FIT
depend on the phony scripts_basic
target.
Signed-off-by: Rasmus Villemoes
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 8af1fa9468..069c03696a 100644
--- a/Makefile
+++ b/Makefile
@@ -2447,7 +2447,7 @@ cmd_genenv = \
These IS_ENABLED(CONFIG_SPL_LOAD_FIT) cases can no longer be reached,
and thus get_fit_image_size() is also redundant.
Signed-off-by: Rasmus Villemoes
---
arch/arm/mach-imx/spl_imx_romapi.c | 25 ++---
1 file changed, 2 insertions(+), 23 deletions(-)
diff --git a/arch/arm
sb loading with IMX_HAB actually work.
[1]
https://lore.kernel.org/u-boot/20230523113651.292806-1-rasmus.villem...@prevas.dk/
Rasmus Villemoes (2):
imx: spl_imx_romapi: avoid tricky use of spl_load_simple_fit() to get
full FIT size
imx: spl_imx_romapi.c: remove dead code
arch/ar
ternal data, has been tacked on beyond the fdt
structure), and always provide valid data from the ->read callback.
This only affects the CONFIG_SPL_LOAD_FIT case - I don't have any
hardware or experience with the CONFIG_SPL_LOAD_IMX_CONTAINER case, so
I leave that alone for now.
Signed-off-b
I was surprised to discover that mkimage effectively ignores -B when
used by itself - the help text suggests otherwise, and it's a
completely reasonable thing to have.
Also, binman already translates a fit,align property into a -B
argument, without requiring fit,external-offset to be set.
Rasmus
Signed-off-by: Rasmus Villemoes
---
tools/binman/ftest.py | 10 +
tools/binman/test/311_fit_align.dts | 58 +
2 files changed, 68 insertions(+)
create mode 100644 tools/binman/test/311_fit_align.dts
diff --git a/tools/binman/ftest.py b/tools/binman
pected for -B to be effectively ignored without -E.
Signed-off-by: Rasmus Villemoes
---
tools/fit_image.c | 40
1 file changed, 40 insertions(+)
diff --git a/tools/fit_image.c b/tools/fit_image.c
index 9fe69ea0d9..2f5b25098a 100644
--- a/tools/fit_image.c
+++ b/tool
In preparation for adding a test case for fit,align without
fit,external-offset present, rename the existing test case and
corresponding file.
Signed-off-by: Rasmus Villemoes
---
tools/binman/ftest.py | 4 ++--
.../test/{275_fit_align.dts
Eliminate the repetition "what alignment to use ... and provides the
alignment to use", and indicate that fit,align can both be used by
itself and together with fit,external-offset.
Signed-off-by: Rasmus Villemoes
---
tools/binman/entries.rst | 5 ++---
1 file changed, 2 insert
On 21/09/2023 03.02, Simon Glass wrote:
> Hi Rasmus,
>
> On Fri, 15 Sept 2023 at 11:51, Rasmus Villemoes
> wrote:
>>
>> Currently, setting both CONFIG_SPL_SYS_MALLOC_SIMPLE and
>> CONFIG_SYS_SPL_MALLOC (but not CONFIG_SPL_STACK_R) doesn't work as
>> expect
to .dtso, and the .dts->.dtbo rule is gone since v6.5 (commit
81d362732bac). So this is also a step towards staying closer to linux
with respect to both Kbuild and device tree sources.
Signed-off-by: Rasmus Villemoes
---
.../dts/{zynqmp-sck-kr-g-revA.dts => zynqmp-sck-kr-g-revA.dtso} | 0
.
to .dtso, and the .dts->.dtbo rule is gone since v6.5 (commit
81d362732bac). So this is also a step towards staying closer to linux
with respect to both Kbuild and device tree sources.
Signed-off-by: Rasmus Villemoes
---
arch/sandbox/dts/{overlay0.dts => overlay0.dtso} | 0
arch/sandb
Moving towards using .dtso for overlay sources, update the
documentation examples to follow that pattern.
Signed-off-by: Rasmus Villemoes
---
doc/develop/uefi/uefi.rst | 4 ++--
doc/usage/fdt_overlays.rst | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/doc/develop/uefi
urn.
This is not quite complete as there are some files under test/ that
still need converting, but as they currently rely on being compiled to
.dtb (in order to, in turn, be applicable for the .dtb -> .dtb.S ->
.dtb.o rules), that's a bit more involved than simple renaming.
Rasmus Villemoes (5):
arm: dts:
to .dtso, and the .dts->.dtbo rule is gone since v6.5 (commit
81d362732bac). So this is also a step towards staying closer to linux
with respect to both Kbuild and device tree sources.
Signed-off-by: Rasmus Villemoes
---
...-cl-iot-gate-ied-adc0.dts => imx8mm-cl-iot-gate-ied-adc0.dtso} | 0
to .dtso, and the .dts->.dtbo rule is gone since v6.5 (commit
81d362732bac). So this is also a step towards staying closer to linux
with respect to both Kbuild and device tree sources.
Signed-off-by: Rasmus Villemoes
---
... => k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay.dts
On 04/05/2023 14.35, Rasmus Villemoes wrote:
> On 03/05/2023 16.54, Tom Rini wrote:
>> The one last problem now is on stm32mp15_dhcor_basic which is a
>> defconfig missing one from OF_LIST but including it in the its file, so
>> the above is the patch we need.
>>
>
On 22/09/2023 17.26, Simon Glass wrote:
>>> Shouldn't this be fdt_open_into()?
>>
>> I honestly just copy-pasted fit_extract_data() and shaved it down to the
>> part that does the "align the FDT part of the file".
>>
>> I don't really understand your question. Are you saying this doesn't
>> work
programs.
Rasmus Villemoes (2):
serial: serial-uclass.c: move definition of _serial_flush up a bit
serial: introduce CONFIG_CONSOLE_FLUSH_ON_NEWLINE
common/Kconfig | 11 +++
drivers/serial/serial-uclass.c | 28
2 files changed, 27 insertions
one doesn't then know exactly where the
hang happens.
Introduce a config knob allowing one to wait for the uart fifo to
drain whenever a newline character is printed, roughly corresponding
to the effect of setvbuf(..., _IOLBF, ...) in ordinary C programs.
Signed-off-by: Rasmus Villemoes
Preparation for next patch.
Signed-off-by: Rasmus Villemoes
---
drivers/serial/serial-uclass.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c
index 067fae2614..2f75ff878c 100644
On 17/10/2023 17.33, Marek Vasut wrote:
> On 10/17/23 15:29, Rasmus Villemoes wrote:
>> static int led_gpio_bind(struct udevice *parent)
>> {
...
>> ret = device_bind_driver_to_node(parent, "gpio_led",
>> ofnode_get_name(no
On 18/10/2023 09.43, Rasmus Villemoes wrote:
> On 17/10/2023 17.33, Marek Vasut wrote:
>> Which string ? The "bcm6753-led" is driver name , so that would have to
>> be parametrized.
>
> Exactly. The only difference between the two examples (apart from the
> sco
All existing drivers in drivers/led/ contain a .bind method that does
exactly the same thing, with just the actual driver name
differing. Create a helper so all those individual methods can be
changed to one-liners.
Signed-off-by: Rasmus Villemoes
---
drivers/led/led-uclass.c | 18
to
what e3aa76644c2a did, but that then vanished with the next commit.]
Fixes: 83c63f0d1185 ("led: Move OF "label" property parsing to core")
Signed-off-by: Rasmus Villemoes
---
drivers/led/led-uclass.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/driv
ith the linux driver), most of the
logic is unchanged from Doug's original patch, so he is still listed
as author.
Doug Zobel (1):
led: add TI LP5562 LED driver
Rasmus Villemoes (5):
led-uclass: do not create fallback label for top-level node
led-uclass: honour ->label field populated by dr
If the driver's own .bind method has populated uc_plat->label, don't
override that. This is necessary for an upcoming driver for ti,lp5562,
where the DT binding unfortunately says to use "chan-name" and not
"label".
Signed-off-by: Rasmus Villemoes
---
drivers/led/led-uc
.
As our boards only have the R,G,B outputs connected, I have not
actually tested how the white channel behaves, but the R,G,B work
exactly as expected.
[1]
https://lore.kernel.org/u-boot/1547150757-1561-1-git-send-email-douglas.zo...@climate.com/
Cc: Doug Zobel
Signed-off-by: Rasmus Villemoes
Signed-off-by: Rasmus Villemoes
---
drivers/led/led_gpio.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/led/led_gpio.c b/drivers/led/led_gpio.c
index fbed151b5d..71421de628 100644
--- a/drivers/led/led_gpio.c
+++ b/drivers/led/led_gpio.c
@@ -11,7
Signed-off-by: Rasmus Villemoes
---
drivers/led/led_pwm.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/led/led_pwm.c b/drivers/led/led_pwm.c
index 7c8eae9337..ae6de3087a 100644
--- a/drivers/led/led_pwm.c
+++ b/drivers/led/led_pwm.c
@@ -9,7 +9,6
On 04/10/2023 04.10, Simon Glass wrote:
> On Tue, 3 Oct 2023 at 04:02, Rasmus Villemoes
> wrote:
>>
>> We're seeing sporadic errors like
>>
>> ENVCinclude/generated/env.txt
>> HOSTCC scripts/basic/fixdep
>> ENVPinclude/generated/env.in
&g
On 19/10/2023 15.04, Richard Marko wrote:
> If we try to build using external dtc using
>
>> make DTC=dtc
>
> we get a confusing error like
>
>> make[2]: *** No rule to make target 'arch/x86/dts/bayleybay.dtb',
>> needed by 'dtbs'. Stop.
>
> Workaround is to use
>
>> make DTC=$( which dtc )
On 19/10/2023 15.54, Marek Vasut wrote:
> On 10/19/23 11:58, Rasmus Villemoes wrote:
>> If the driver's own .bind method has populated uc_plat->label, don't
>> override that. This is necessary for an upcoming driver for ti,lp5562,
>> where the DT binding unfortunatel
On 19/10/2023 15.51, Marek Vasut wrote:
> On 10/19/23 11:58, Rasmus Villemoes wrote:
>> Many existing drivers, and led-uclass itself, rely on uc_plat->label
>> being NULL for the device representing the top node, as opposed to the
>> child nodes representing ind
On 19/10/2023 15.58, Marek Vasut wrote:
> On 10/19/23 11:58, Rasmus Villemoes wrote:
>> From: Doug Zobel
>>
>> Driver for the TI LP5562 4 channel LED controller. Supports
>> independent on/off control of all 4 channels. Supports LED_BLINK on 3
>> independent ch
501 - 600 of 810 matches
Mail list logo
