Hi Simon and all,
> I have been avoiding this thread but today I attended a talk on ATF and
> ARM's approach in general.
For the benefits of others, that was me talking at the OSFC conference (video
and slides should appear soon here:
On 04/09/2019 18:56, Marek Vasut wrote:
> On 9/4/19 7:32 PM, Andre Przywara wrote:
Hi Marek,
>>> I have been avoiding this thread but today I attended a talk on ATF
>>> and ARM's approach in general. ARM seems to be moving towards an
>>> approach of providing increasingly complex source code to
On 2019/9/4 上午12:29, Matwey V. Kornilov wrote:
Makefile now produces ready-to-deploy idbloader.img file.
Signed-off-by: Matwey V. Kornilov
Reviewed-by: Kever Yang
Thanks,
- Kever
---
board/theobroma-systems/lion_rk3368/README | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
On 2019/9/4 上午12:29, Matwey V. Kornilov wrote:
Makefile now produces ready-to-deploy idbloader.img file.
Signed-off-by: Matwey V. Kornilov
Reviewed-by: Kever Yang
Thanks,
- Kever
---
doc/README.rockchip | 21 ++---
1 file changed, 2 insertions(+), 19 deletions(-)
diff
On Wed, Sep 04, 2019 at 11:51:41AM +0900, Masahiro Yamada wrote:
> On Sun, Jun 30, 2019 at 11:20 PM Marek Vasut wrote:
> >
> > On 6/30/19 4:17 PM, Tom Rini wrote:
> > > On Sun, Jun 30, 2019 at 04:03:52PM +0200, Marek Vasut wrote:
> > >> On 6/30/19 3:57 PM, Tom Rini wrote:
> > >>> On Sat, Jun 29,
This patch series introduces new SPL and TPL specific Kconfig entries for
DM_SPI* options. Such change allows using the spi driver in SPL/TPL or
U-Boot proper.
First two patches - related to ls10{42}* NXP soc fix some issues with
defining the DM_SPI* defines in .h file instead of Kconfig.
This
This change allows more fine tuning of driver model based SPI support in
SPL and TPL. It is now possible to explicitly enable/disable the DM_SPI
support in SPL and TPL via Kconfig option.
Before this change it was necessary to use:
/* SPI Flash Configs */
#if defined(CONFIG_SPL_BUILD)
This patch moves the CONFIG_DM_SPI_FLASH and CONFIG_SPI_FLASH_DATAFLASH
to be defined in Kconfig, not in board specific header file
(include/configs/.h).
Before this change the CONFIG_DM_SPI_FLASH was not set in .config (so it
was not possible to use CONFIG_IS_ENABLED(DM_SPI_FLASH) in SPI DM/DTS
This patch fixes issue with defining the DM_SPI_FLASH in the
configs/include/ instead of enabling this option in Kconfig.
The problem is that CONFIG_IS_ENABLED(DM_SPI_FLASH) shows false as there
is no DM_SPI_FLASH=y in .config (but the define is set in u-boot.cfg).
As a result conversion of
On Tue, Sep 03, 2019 at 06:03:40PM -0500, Joe Hershberger wrote:
> On Tue, Sep 3, 2019 at 3:05 AM Wolfgang Denk wrote:
> >
> > Dear Tom,
> >
> > In message Heiko Schocher
> > wrote:
> > >
> > > I am just testing U-Boot Environment flags and they do not work anymore
> > > with
> > > current
On Wed, Sep 4, 2019 at 1:01 PM Tom Rini wrote:
>
> On Tue, Sep 03, 2019 at 10:04:42AM +0200, Wolfgang Denk wrote:
> > Dear Tom,
> >
> > In message Heiko Schocher
> > wrote:
> > >
> > > I am just testing U-Boot Environment flags and they do not work anymore
> > > with
> > > current mainline
We faced with regressions caused by
commit c4e8862308d4 (mtd: spi: Switch to new SPI NOR framework)
This switch was performed by removing entire u-boot spi-flash
core implementation and copying it from another project.
However the switch is performed without proper testing and
investigations
Commit c4e8862308d4 (mtd: spi: Switch to new SPI NOR framework)
performs switch from previous 'spi_flash' infrastructure without
proper testing/investigations which results in regressions.
Fix regression related to SST26 flash IC series which is lacking
protection ops implementation which were
On Tue, Sep 03, 2019 at 10:04:42AM +0200, Wolfgang Denk wrote:
> Dear Tom,
>
> In message Heiko Schocher
> wrote:
> >
> > I am just testing U-Boot Environment flags and they do not work anymore with
> > current mainline U-Boot ...
> ...
> > reason is your commit:
> >
> > commit
On 9/4/19 7:32 PM, Andre Przywara wrote:
[...]
>> I have been avoiding this thread but today I attended a talk on ATF
>> and ARM's approach in general. ARM seems to be moving towards an
>> approach of providing increasingly complex source code to add more
>> layers of security software to fully
The current brcmnand driver is based on 4.18 linux kernel which uses
mtd_set_ooblayout to set ecc layout. But nand base code in u-boot is from
old kernel which does not use this new API and expect nand_chip.ecc.layout
structure to be set. This cause nand_scan_tail function running into a bug
check
On Tue, 3 Sep 2019 19:17:14 -0700
Simon Glass wrote:
Hi Simon,
> On Tue, 2 Jul 2019 at 11:42, Marek Vasut wrote:
> >
> > On 6/30/19 3:38 AM, André Przywara wrote:
> > > On 30/06/2019 00:03, Marek Vasut wrote:
> > >
> > > Marek,
> > >
> > > you seem to be quite defensive in your answer
> >
Hi Faiz,
> -Original Message-
> From: Faiz Abbas
> Sent: Wednesday, September 4, 2019 5:40 PM
> To: u-boot@lists.denx.de
> Cc: tr...@konsulko.com; Alexey Brodkin ;
> paule...@forallsecure.com;
> faiz_ab...@ti.com
> Subject: [PATCH] disk: part_dos: Allocate at least one block size for
Hi Heinrich,
https://patchwork.ozlabs.org/patch/1156517/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Ralph,
https://patchwork.ozlabs.org/patch/1149481/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi liucheng,
https://patchwork.ozlabs.org/patch/1155275/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Heinrich,
https://patchwork.ozlabs.org/patch/1156730/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Tom,
This PR has bug, CVE, and regression fixes as well as a few features that took
some back-and-forth.
Travis tested here: https://travis-ci.org/jhershbe/u-boot/builds/580493530
The following changes since commit 448f11f7503995746a7b71e5e3b3a831c4651be9:
Merge tag 'arc-for-2019.10-rc4'
Hi Patrick,
https://patchwork.ozlabs.org/patch/1140379/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Heinrich,
https://patchwork.ozlabs.org/patch/1144982/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Patrick,
https://patchwork.ozlabs.org/patch/1140378/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Stefan,
https://patchwork.ozlabs.org/patch/1152998/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Michael,
https://patchwork.ozlabs.org/patch/1153632/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi liucheng,
https://patchwork.ozlabs.org/patch/1155278/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Alex,
https://patchwork.ozlabs.org/patch/1136772/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Heinrich,
https://patchwork.ozlabs.org/patch/1156731/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Heinrich,
https://patchwork.ozlabs.org/patch/1139395/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi liucheng,
https://patchwork.ozlabs.org/patch/1155276/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Alex,
https://patchwork.ozlabs.org/patch/1143592/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Matt,
https://patchwork.ozlabs.org/patch/1138980/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi liucheng,
https://patchwork.ozlabs.org/patch/1155274/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Heinrich,
https://patchwork.ozlabs.org/patch/1139392/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Bin,
https://patchwork.ozlabs.org/patch/1146935/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Ramon,
https://patchwork.ozlabs.org/patch/1133816/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Alex,
https://patchwork.ozlabs.org/patch/1136774/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Alex,
https://patchwork.ozlabs.org/patch/1136771/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Ramon,
https://patchwork.ozlabs.org/patch/1133815/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi liucheng,
https://patchwork.ozlabs.org/patch/1155277/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Joe,
https://patchwork.ozlabs.org/patch/1139393/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Alex,
https://patchwork.ozlabs.org/patch/1136773/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Florinel,
https://patchwork.ozlabs.org/patch/1099898/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Ramon,
https://patchwork.ozlabs.org/patch/1133814/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Alex,
https://patchwork.ozlabs.org/patch/1132514/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi Joe,
https://patchwork.ozlabs.org/patch/1139394/ was applied to
http://git.denx.de/?p=u-boot/u-boot-net.git
Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi all,
On 13/08/2019 11:34, Simon Glass wrote:
> +Stephen Warren
>
> Hi Matthias,
>
> On Thu, 1 Aug 2019 at 05:42, Matthias Brugger wrote:
>>
>> Hi all,
>>
>> On 26/07/2019 11:13, matthias@kernel.org wrote:
>>> From: Matthias Brugger
>>>
>>> According to the device tree specification,
On Wed, Sep 4, 2019 at 11:39 PM Joe Hershberger wrote:
>
> Hi Bin,
>
> On Wed, Sep 4, 2019 at 6:51 AM Bin Meng wrote:
> >
> > Hi Joe,
> >
> > On Thu, Aug 15, 2019 at 3:03 AM Joe Hershberger
> > wrote:
> > >
> > > Hi Radu,
> > >
> > > Is there something you can switch on to select the correct
Hi Bin,
On Wed, Sep 4, 2019 at 6:51 AM Bin Meng wrote:
>
> Hi Joe,
>
> On Thu, Aug 15, 2019 at 3:03 AM Joe Hershberger
> wrote:
> >
> > Hi Radu,
> >
> > Is there something you can switch on to select the correct register on
> > the appropriate platform?
> >
> > On Wed, Aug 14, 2019 at 5:31 AM
Hi Lokesh
Thank you for the patch.
BR
Fabien
On 04/09/2019 12:31 PM, Lokesh Vutla wrote:
> The current rproc-elf-loader supports loading of only 32 bit elf files.
> Introduce support for loading of 64 bit elf files in rproc-elf-loader.
>
> Signed-off-by: Lokesh Vutla
Reviewed-by: Fabien
Hi Lokesh
On 04/09/2019 12:31 PM, Lokesh Vutla wrote:
> Introduce a common remoteproc elf loader and checker functions that
> automatically detects the 64 bit elf file or 32 bit elf file and
> loads/checks the sections accordingly.
>
> Signed-off-by: Lokesh Vutla
Reviewed-by: Fabien Dessenne
>
Hi Lokesh
On 04/09/2019 12:31 PM, Lokesh Vutla wrote:
> rproc_elf32_load_image() rely on user to send a valid address for elf loading.
> Instead do a sanity check on the address passed by user. This will help
> all rproc elf users to not call sanity_check explicitly before calling
> elf_loading.
Hi Lokesh
I have successfully tested this patch for stm32_copro.
BR
Fabien
On 04/09/2019 12:31 PM, Lokesh Vutla wrote:
> Introduce a new parameter "size" that accepts size of the region to
> remoteproc ops callback device_to_virt(). This can enforce more checks
> on the region that
From: Joseph Chen
Signed-off-by: Joseph Chen
Signed-off-by: Elaine Zhang
---
drivers/power/pmic/rk8xx.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/drivers/power/pmic/rk8xx.c b/drivers/power/pmic/rk8xx.c
index 00c8a2e091d8..df2056913ced 100644
Fix an issue where some sections are never loaded : if p_type is
different from PT_LOAD the phdr pointer must be incremented.
Signed-off-by: Fabien Dessenne
---
drivers/remoteproc/rproc-elf-loader.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
From: Alexey Brodkin
Date: Sep/04/2019, 06:59:01 (UTC+00:00)
> Hi Joe,
>
> > -Original Message-
> > From: Joe Hershberger
> > Sent: Wednesday, September 4, 2019 1:10 AM
> > To: Alexey Brodkin
> > Cc: Ralph Siemsen ; Joseph Hershberger
> > ; u-
> > b...@lists.denx.de;
Signed-off-by: Elaine Zhang
---
drivers/power/pmic/rk8xx.c | 1 +
drivers/power/regulator/rk8xx.c | 674 +++-
include/power/rk8xx_pmic.h | 11 +-
3 files changed, 600 insertions(+), 86 deletions(-)
diff --git a/drivers/power/pmic/rk8xx.c
From: Joseph Chen
include sub modules: pmic, regulator
Signed-off-by: Joseph Chen
Signed-off-by: Elaine Zhang
---
drivers/power/pmic/rk8xx.c | 6 -
drivers/power/regulator/rk8xx.c | 55 -
include/power/rk8xx_pmic.h | 1 +
3 files
From: Joseph Chen
include sub modules: pmic, regulator
Signed-off-by: Joseph Chen
Signed-off-by: Elaine Zhang
---
drivers/power/pmic/rk8xx.c | 109 --
drivers/power/regulator/rk8xx.c | 198 +++-
include/power/rk8xx_pmic.h |
From: Joseph Chen
support parse regulator standard property:
regulator-off-in-suspend;
regulator-init-microvolt;
regulator-suspend-microvolt:
regulator_get_suspend_enable
regulator_set_suspend_enable
regulator_get_suspend_value
regulator_set_suspend_value
Signed-off-by: Joseph Chen
Signed-off-by: Elaine Zhang
---
drivers/power/pmic/rk8xx.c | 1 +
drivers/power/regulator/rk8xx.c | 17 +
include/power/rk8xx_pmic.h | 1 +
3 files changed, 19 insertions(+)
diff --git a/drivers/power/pmic/rk8xx.c b/drivers/power/pmic/rk8xx.c
index
From: Joseph Chen
Signed-off-by: Joseph Chen
Signed-off-by: Elaine Zhang
---
drivers/power/pmic/pmic-uclass.c | 11 +++
include/power/pmic.h | 9 +
2 files changed, 20 insertions(+)
diff --git a/drivers/power/pmic/pmic-uclass.c b/drivers/power/pmic/pmic-uclass.c
Support more PMIC and improve compatibility between pmics.
Elaine Zhang (2):
power: pmic: rk816: support rk816 pmic
power: pmic: rk805: support rk805 pmic
Joseph Chen (6):
dm: regulator: support regulator more state
power: pmic: rk8xx: bind more function
dm: pmic: add pmic_shutdown()
The blk_dread() following the mbr allocation reads one block from the
device. This will lead to overflow if block size is greater than the
size of legacy_mbr. Fix this by allocating at least one block size.
Signed-off-by: Faiz Abbas
---
disk/part_dos.c | 3 ++-
1 file changed, 2 insertions(+),
Hi Tom,
Ah OK. I was worried about doing it in one step. It might be too late
now but will take a look when I get time and we can see if it is safe.
Regards,
Simon
On Wed, 28 Aug 2019 at 18:19, Tom Rini wrote:
>
> On Wed, Aug 28, 2019 at 10:11:16AM -0600, Simon Glass wrote:
> > Hi Tom,
> >
>
Hi Heiko,
The place where the issue comes up is in ubispl_load_volumes(), but that
calls ipl_load() internally.
I guess there are several options
1) Create a distinct ubispl_scan() function to do the scan without loading
anything and then a new load volume function that takes offset
Hi Tom,
> On Tue, Sep 03, 2019 at 05:56:36PM +0200, Lukasz Majewski wrote:
> > Hi Tom,
> >
> > > On Fri, Aug 23, 2019 at 11:02:27PM +0200, Lukasz Majewski wrote:
> > > > Hi Tom,
> > > >
> > > > > On Tue, Aug 13, 2019 at 03:47:31PM +0200, Lukasz Majewski
> > > > > wrote:
> > > > > >
Alexey,
On 04/09/19 6:53 PM, Alexey Brodkin wrote:
> Hi Faiz,
>
>> -Original Message-
>> From: Faiz Abbas
>> Sent: Wednesday, September 4, 2019 4:09 PM
>> To: Alexey Brodkin
>> Cc: paule...@forallsecure.com; tr...@konsulko.com; u-boot@lists.denx.de
>> Subject: Re: [PATCH] Revert "part:
Hi Tom, Alexey,
On 04/09/19 7:19 PM, Tom Rini wrote:
> On Wed, Sep 04, 2019 at 01:46:52PM +, Alexey Brodkin wrote:
>> Hi Faiz,
>>
>>> -Original Message-
>>> From: Alexey Brodkin
>>> Sent: Wednesday, September 4, 2019 4:23 PM
>>> To: Faiz Abbas
>>> Cc: paule...@forallsecure.com;
On Wed, Sep 04, 2019 at 01:46:52PM +, Alexey Brodkin wrote:
> Hi Faiz,
>
> > -Original Message-
> > From: Alexey Brodkin
> > Sent: Wednesday, September 4, 2019 4:23 PM
> > To: Faiz Abbas
> > Cc: paule...@forallsecure.com; tr...@konsulko.com; u-boot@lists.denx.de
> > Subject: RE:
Hi Faiz,
> -Original Message-
> From: Alexey Brodkin
> Sent: Wednesday, September 4, 2019 4:23 PM
> To: Faiz Abbas
> Cc: paule...@forallsecure.com; tr...@konsulko.com; u-boot@lists.denx.de
> Subject: RE: [PATCH] Revert "part: Allocate only one legacy_mbr buffer"
>
> Hi Faiz,
>
> >
Hi Faiz,
> -Original Message-
> From: Faiz Abbas
> Sent: Wednesday, September 4, 2019 4:09 PM
> To: Alexey Brodkin
> Cc: paule...@forallsecure.com; tr...@konsulko.com; u-boot@lists.denx.de
> Subject: Re: [PATCH] Revert "part: Allocate only one legacy_mbr buffer"
>
> Hi Alexey,
>
> On
Hi Alexey,
On 04/09/19 6:27 PM, Alexey Brodkin wrote:
> Hi Faiz,
>
> [snip]
>
> I guess what you really want to do is to allocate buffer for "mbr"
> dynamically of size which is max(sizeof(legacy_mbr), dev_desc->blksz).
>
With the assumption that blksz is always greater
Hello Joel,
Am 04.09.2019 um 06:57 schrieb Joel Peshkin:
It seems that, in the process of doing any sort of secure boot chain of
trust, anything loading a UBI volume in preparation to authenticate it,
will load a volume of unknown size into a buffer prior to checking the
signature of that
Hi Faiz,
[snip]
> >>> I guess what you really want to do is to allocate buffer for "mbr"
> >>> dynamically of size which is max(sizeof(legacy_mbr), dev_desc->blksz).
> >>>
> >>
> >> With the assumption that blksz is always greater than
> >> sizeof(legacy_mbr), this should work:
> >>
> >>
Hi Alexey,
On 04/09/19 5:16 PM, Alexey Brodkin wrote:
> Hi Faiz,
>
>> -Original Message-
>> From: Faiz Abbas
>> Sent: Wednesday, September 4, 2019 2:44 PM
>> To: Alexey Brodkin
>> Cc: paule...@forallsecure.com; tr...@konsulko.com; u-boot@lists.denx.de
>> Subject: Re: [PATCH] Revert
Correct the text representation of UsbClass device path nodes.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_device_path_to_text.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_device_path_to_text.c
b/lib/efi_loader/efi_device_path_to_text.c
Hi Joe,
On Thu, Aug 15, 2019 at 3:03 AM Joe Hershberger wrote:
>
> Hi Radu,
>
> Is there something you can switch on to select the correct register on
> the appropriate platform?
>
> On Wed, Aug 14, 2019 at 5:31 AM Bin Meng wrote:
> >
> > This reverts commit
Hi Faiz,
> -Original Message-
> From: Faiz Abbas
> Sent: Wednesday, September 4, 2019 2:44 PM
> To: Alexey Brodkin
> Cc: paule...@forallsecure.com; tr...@konsulko.com; u-boot@lists.denx.de
> Subject: Re: [PATCH] Revert "part: Allocate only one legacy_mbr buffer"
>
> Hi Alexey,
>
> On
Hi Alexey,
On 04/09/19 3:42 PM, Alexey Brodkin wrote:
> Hi Faiz,
>
>> -Original Message-
>> From: Faiz Abbas
>> Sent: Wednesday, September 4, 2019 12:22 PM
>> To: u-boot@lists.denx.de
>> Cc: paule...@forallsecure.com; faiz_ab...@ti.com; Alexey Brodkin
>> ;
>> tr...@konsulko.com
>>
If the interface type is greater than 1, render all 32 bytes of the MAC
address.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_device_path_to_text.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/lib/efi_loader/efi_device_path_to_text.c
Vendor device paths may contain data. When converting vendor device paths
to text this binary data has to be rendered.
UEFI SCT, 2017, 5.4.7.1.3
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_device_path_to_text.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
From: Kedar Chitnis
The A72 U-Boot code loads and boots a number of remote processors
including the C71x DSP, both the C66_0 and C66_1 DSPs, and the various
Main R5FSS Cores. In order to view the code loaded by the U-Boot by
remote cores, U-Boot should configure the memory region with right
From: Suman Anna
Add a new file include/environment/ti/k3_rproc.h that defines
common environment variables useful for booting various remote
processors from U-Boot. This file is expected to be included in
the board config files with the EXTRA_ENV_RPROC_SETTINGS added
to
Add README file explaining the build and boot procedure for J721E evm.
Signed-off-by: Lokesh Vutla
---
board/ti/j721e/README | 227 ++
1 file changed, 227 insertions(+)
create mode 100644 board/ti/j721e/README
diff --git a/board/ti/j721e/README
From: Suman Anna
Enable the R5F remoteproc driver for the AM65x GP EVM so that the
MCU domain R5F cores can be booted from A53 U-boot.
Signed-off-by: Suman Anna
Signed-off-by: Lokesh Vutla
---
configs/am65x_evm_a53_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git
Enable R5F and DSP remoteproc drivers for j721e running on a72.
Signed-off-by: Lokesh Vutla
---
configs/j721e_evm_a72_defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/configs/j721e_evm_a72_defconfig b/configs/j721e_evm_a72_defconfig
index 6e355f5247..6e0c3f05fb 100644
---
From: Suman Anna
The A53 U-boot can support early booting of the MCU R5F remote processor(s)
from U-boot prompt to achieve various system usecases before booting the
Linux kernel. Update the default BOOTCOMMAND to provide an automatic and
easier way to start the MCU R5F cores through added
From: Suman Anna
Add support to boot some remoteprocs at U-boot prompt on the J721E EVM
boards by using the 'boot_rprocs' and other env variables defined in the
common environment file k3_rproc.h, and updating the 'DEFAULT_RPROCS'
macro.
The list of R5F cores to be started before loading and
Thanks Heiko,
On Wed, 4 Sep 2019 at 07:24, Heiko Schocher wrote:
> Hello Loic,
>
> added Lukasz as he is the DFU custodian.
>
> Am 03.09.2019 um 09:59 schrieb Loic Poulain:
> > Hi,
> >
> > AFAIU, today it's possible to update a UBI partition via DFU with a new
> UBI
> > blob using 'partubi'.
>
On Wed, 4 Sep 2019 11:54:40 +0200
Lukasz Majewski wrote:
> Hi Stefano, Heiko,
>
> > On 04/09/19 10:46, Lukasz Majewski wrote:
> > > Hi Heiko,
> > >
> > >> Hello Lukasz,
> > >>
> > >> added Stefano to cc as he is the imx custodian.
> > >
> > > I've relied on patman ... Thanks for
SoCs with K3 architecture have an integrated Arm Cortex-R5F subsystem
that is comprised of dual-core Arm Cortex-R5F processor cores. This R5
subsytem can be configured at boot time to be either run in a LockStep
mode or in an Asymmetric Multi Processing (AMP) fashion in Split-mode.
This subsystem
From: Suman Anna
The A53 U-Boot code can load and boot the MCU domain R5F cores (either a
single core in LockStep mode or 2 cores in Split mode) to achieve various
early system functionalities. Change the memory attributes for the DDR
regions used by the remote processors so that the cores can
Power domain for the remote cores needs to be handled in a right
sequence as mandated by the spec. Introduce tisci helper apis
that can control power-domains of remote cores. TISCI clients
can use this api and control the remote cores power domain instead
of hooking it to power-domain layer.
From: Suman Anna
Add support to boot the MCU domain R5F Core0 remoteproc at U-boot prompt
on the AM65x EVM boards by using the 'boot_rprocs' and other env variables
defined in the common environment file k3_rproc.h, and updating the
'DEFAULT_RPROCS' macro.
The default configuration is to use
From: Suman Anna
Some Texas Instruments K3 family of SoCs have one of more Digital Signal
Processor (DSP) subsystems that are comprised of either a TMS320C66x
CorePac and/or a next-generation TMS320C71x CorePac processor subsystem.
Add the device tree bindings document for the C66x DSP devices
From: Suman Anna
The Texas Instruments K3 family of SoCs have one of more dual-core
Arm Cortex R5F processor subsystems/clusters (R5FSS). Add the device
tree bindings document for these R5F subsystem devices. These R5F
processors do not have an MMU, and so require fixed memory carveout
regions
1 - 100 of 131 matches
Mail list logo
