On Thu, Jul 29, 2021 at 9:32 AM Simon Glass wrote:
>
> On Tue, 27 Jul 2021 at 22:00, Bin Meng wrote:
> >
> > If for some reason, TSC timer frequency cannot be determined from
> > hardware, nor is it specified in the device tree, U-Boot will panic
> > resulting in endless reset during boot.
> >
>
On Sat, Jul 31, 2021 at 9:35 AM Simon Glass wrote:
>
> On Tue, 27 Jul 2021 at 22:00, Bin Meng wrote:
> >
> > Currently there are two places to specify the x86 TSC timer frequency
> > with one in Kconfig used for early timer and the other one in device
> > tree used when the frequency cannot be
On Sat, Jul 31, 2021 at 9:35 AM Simon Glass wrote:
>
> On Tue, 27 Jul 2021 at 09:15, Bin Meng wrote:
> >
> > These 2 options are no longer needed as now binman is used to build
> > u-boot.rom.
> >
> > Signed-off-by: Bin Meng
> > ---
> >
> > Kconfig| 21 -
On Sat, Jul 31, 2021 at 9:35 AM Simon Glass wrote:
>
> On Tue, 27 Jul 2021 at 07:30, Bin Meng wrote:
> >
> > binman complains when binary blobs are present:
> >
> > Node '/binman/rom/intel-vga': Offset 0xfff9 (4294508544) overlaps
> > with previous entry
On Tue, 27 Jul 2021 at 22:00, Bin Meng wrote:
>
> Currently there are two places to specify the x86 TSC timer frequency
> with one in Kconfig used for early timer and the other one in device
> tree used when the frequency cannot be determined from hardware.
>
> This may potentially create an
On Tue, 27 Jul 2021 at 09:15, Bin Meng wrote:
>
> These 2 options are no longer needed as now binman is used to build
> u-boot.rom.
>
> Signed-off-by: Bin Meng
> ---
>
> Kconfig| 21 -
> arch/x86/Kconfig | 2 --
> arch/x86/cpu/quark/Kconfig |
On Tue, 27 Jul 2021 at 07:30, Bin Meng wrote:
>
> binman complains when binary blobs are present:
>
> Node '/binman/rom/intel-vga': Offset 0xfff9 (4294508544) overlaps
> with previous entry '/binman/rom/u-boot-dtb-with-ucode' ending at
> 0xfff9204c (4294516812)
>
> Adjust VGA rom
Hi Simon,
On Wed, Jul 28, 2021 at 12:00 PM Bin Meng wrote:
>
> Currently there are two places to specify the x86 TSC timer frequency
> with one in Kconfig used for early timer and the other one in device
> tree used when the frequency cannot be determined from hardware.
>
> This may potentially
Hi Simon,
On Sat, Jul 31, 2021 at 9:03 AM Simon Glass wrote:
>
> On Fri, 30 Jul 2021 at 14:15, Andy Shevchenko
> wrote:
> >
> > IRQ polarity in CSRT has the same definition as by ACPI specification
> > chapter 19.6.64 "Interrupt (Interrupt Resource Descriptor Macro)", i.e.
> > ActiveHigh is 0,
On Fri, 30 Jul 2021 at 14:15, Andy Shevchenko
wrote:
>
> IRQ polarity in CSRT has the same definition as by ACPI specification
> chapter 19.6.64 "Interrupt (Interrupt Resource Descriptor Macro)", i.e.
> ActiveHigh is 0, and ActiveLow is 1. On Intel Tangier the DMA controller
> IRQ polarity is
On Sat, Jul 31, 2021 at 7:44 AM Bin Meng wrote:
>
> On Sat, Jul 31, 2021 at 4:15 AM Andy Shevchenko
> wrote:
> >
> > IRQ polarity in CSRT has the same definition as by ACPI specification
> > chapter 19.6.64 "Interrupt (Interrupt Resource Descriptor Macro)", i.e.
> > ActiveHigh is 0, and
On Sat, Jul 31, 2021 at 3:02 AM Simon Glass wrote:
>
> On Thu, 29 Jul 2021 at 06:18, Bin Meng wrote:
> >
> > Except ICH7 SPI, all SPI flashes connected to ICH9 / Fast SPI should
> > have "m25p,fast-read" property present in their DT nodes.
> >
> > Signed-off-by: Bin Meng
> > ---
> >
> >
On Sat, Jul 31, 2021 at 4:15 AM Andy Shevchenko
wrote:
>
> IRQ polarity in CSRT has the same definition as by ACPI specification
> chapter 19.6.64 "Interrupt (Interrupt Resource Descriptor Macro)", i.e.
> ActiveHigh is 0, and ActiveLow is 1. On Intel Tangier the DMA controller
> IRQ polarity is
On Fri, Jul 30, 2021 at 03:48:15PM -0600, Simon Glass wrote:
> Hi Tom,
>
> On Fri, 30 Jul 2021 at 15:33, Tom Rini wrote:
> >
> > On Fri, Jul 30, 2021 at 01:02:18PM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Thu, 29 Jul 2021 at 07:52, Tom Rini wrote:
> > > >
> > > > On Wed, Jul 28,
Hi Tom,
On Fri, 30 Jul 2021 at 15:33, Tom Rini wrote:
>
> On Fri, Jul 30, 2021 at 01:02:18PM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 29 Jul 2021 at 07:52, Tom Rini wrote:
> > >
> > > On Wed, Jul 28, 2021 at 07:44:37PM -0600, Simon Glass wrote:
> > > > Hi,
> > > >
> > > > On Wed,
On Fri, Jul 30, 2021 at 01:02:18PM -0600, Simon Glass wrote:
> Hi Tom,
>
> On Thu, 29 Jul 2021 at 07:52, Tom Rini wrote:
> >
> > On Wed, Jul 28, 2021 at 07:44:37PM -0600, Simon Glass wrote:
> > > Hi,
> > >
> > > On Wed, 28 Jul 2021 at 17:55, Tom Rini wrote:
> > > >
> > > > On Thu, Jul 29, 2021
IRQ polarity in CSRT has the same definition as by ACPI specification
chapter 19.6.64 "Interrupt (Interrupt Resource Descriptor Macro)", i.e.
ActiveHigh is 0, and ActiveLow is 1. On Intel Tangier the DMA controller
IRQ polarity is ActiveHigh.
Note, in DSDT (see southcluster.asl) it's described
Hi Tom,
On Thu, 29 Jul 2021 at 07:52, Tom Rini wrote:
>
> On Wed, Jul 28, 2021 at 07:44:37PM -0600, Simon Glass wrote:
> > Hi,
> >
> > On Wed, 28 Jul 2021 at 17:55, Tom Rini wrote:
> > >
> > > On Thu, Jul 29, 2021 at 01:45:49AM +0200, Heinrich Schuchardt wrote:
> > > >
> > > >
> > > > On
On Thu, 29 Jul 2021 at 06:18, Bin Meng wrote:
>
> Except ICH7 SPI, all SPI flashes connected to ICH9 / Fast SPI should
> have "m25p,fast-read" property present in their DT nodes.
>
> Signed-off-by: Bin Meng
> ---
>
> arch/x86/dts/bayleybay.dts| 1 +
>
Hi Tom,
On Fri, 30 Jul 2021 at 11:26, Tom Rini wrote:
>
> On Fri, Jul 30, 2021 at 10:59:22AM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Fri, 30 Jul 2021 at 09:10, Tom Rini wrote:
> > >
> > > On Fri, Jul 30, 2021 at 08:44:29AM -0600, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On
From: Jan Kiszka
Prepares for the addition of the IOT2050 board which is based on the TI
AM65x. The board comes in two variants, Basic and Advanced, so there are
separate dts files. Furthermore, the SPL has its own device tree.
Based on original board support by Le Jin, Gao Nian and Chao Zeng.
From: Jan Kiszka
To avoid the need of extra boot scripting on AM65x for loading a
watchdog firmware, add the required rproc init and loading logic for the
first R5F core to the watchdog start handler. In case the R5F cluster is
in lock-step mode, also initialize the second core. The firmware
From: Jan Kiszka
Add the DT entry for a watchdog based on RTI1. It requires additional
firmware on the MCU R5F cores to handle the expiry, e.g.
https://github.com/siemens/k3-rti-wdt. As this firmware will also lock
the power domain to protect it against premature shutdown, mark it
shared.
From: Jan Kiszka
This allows to use the watchdog in custom scripts but does not enforce
that the OS has to support it as well.
Signed-off-by: Jan Kiszka
---
arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 16
configs/iot2050_defconfig| 6 ++
2 files
From: Jan Kiszka
This adds support for the IOT2050 Basic and Advanced devices. The Basic
used the dual-core AM6528 GP processor, the Advanced one the AM6548 HS
quad-core version.
Both variants are booted via a Siemens-provided FSBL that runs on the R5
cores. Consequently, U-Boot support is
This is the baseline support for the SIMATIC IOT2050 devices.
Changes in v4:
- rebased
- make rtd-wdt firmware a "loadable" inside U-Boot proper fit image,
avoiding controversial embedding as object
- improved mmc1 removal from boot_targets
- fixed various build issues
Changes in v3:
-
Hi Román
On Fri, Jul 30, 2021, 7:44 PM Roman Kopytin
wrote:
> Hello, dear U-boot team
>
> I have question about your old feature: U-boot patch for adding of the
> public key to dtb file.
>
> https://patchwork.ozlabs.org/project/uboot/patch/1363650725-30459-37-git-send-email-sjg%40chromium.org/
Hello, dear U-boot team
I have question about your old feature: U-boot patch for adding of the public
key to dtb file.
https://patchwork.ozlabs.org/project/uboot/patch/1363650725-30459-37-git-send-email-sjg%40chromium.org/
I can’t understand, can we work only with public key? Why do we need to
On Fri, Jul 30, 2021 at 10:59:22AM -0600, Simon Glass wrote:
> Hi Tom,
>
> On Fri, 30 Jul 2021 at 09:10, Tom Rini wrote:
> >
> > On Fri, Jul 30, 2021 at 08:44:29AM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Thu, 29 Jul 2021 at 07:22, Tom Rini wrote:
> > > >
> > > > On Wed, Jul 28,
Hi Tom,
On Fri, 30 Jul 2021 at 09:10, Tom Rini wrote:
>
> On Fri, Jul 30, 2021 at 08:44:29AM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 29 Jul 2021 at 07:22, Tom Rini wrote:
> > >
> > > On Wed, Jul 28, 2021 at 07:27:08PM -0600, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On
With glibc 2.33 (Ubuntu package glibc6 2.33-0ubuntu9) building
sifive_unmatched_defconfig results in:
In file included from /usr/include/stdio.h:866,
from ././include/compiler.h:26,
from :
In function ‘snprintf’,
inlined from ‘rsa_engine_get_priv_key’ at
On Fri, Jul 30, 2021 at 08:44:29AM -0600, Simon Glass wrote:
> Hi Tom,
>
> On Thu, 29 Jul 2021 at 07:22, Tom Rini wrote:
> >
> > On Wed, Jul 28, 2021 at 07:27:08PM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Wed, 28 Jul 2021 at 17:28, Simon Glass wrote:
> > > >
> > > > Hi again,
> >
Hi Tom,
On Thu, 29 Jul 2021 at 07:22, Tom Rini wrote:
>
> On Wed, Jul 28, 2021 at 07:27:08PM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Wed, 28 Jul 2021 at 17:28, Simon Glass wrote:
> > >
> > > Hi again,
> > >
> > > On Mon, 26 Jul 2021 at 08:06, Simon Glass wrote:
> > > >
> > > > Hi Tom,
On 7/30/21 8:23 AM, Matthias Schiffer wrote:
strlcat() need to be passed the full buffer length. The incorrect call
caused truncation of partition names for fastboot_raw_partition_... and
fastboot_partition_alias_... env lookup to much less than PART_NAME_LEN.
Fixes: 69a752983171 ("fastboot:
On 30/07/2021 14:28, Mattijs Korpershoek wrote:
> The SEI-610 and SEI-510 boards are well supported in the
> Android Open Source project via the yukawa [1] platform.
>
> Their U-Boot version, despite being public [2] is not in mainline.
>
> Android has multiple OSes it can boot into:
> * Main
Hi Neil,
Neil Armstrong writes:
> On 30/07/2021 10:55, Mattijs Korpershoek wrote:
>> The SEI-610 and SEI-510 boards are well supported in the
>> Android Open Source project via the yukawa [1] platform.
>>
>> Their U-Boot version, despite being public [2] is not in mainline.
>>
>> Android has
Since set_control_reg is available in sdhci.c, use it and remove
arasan_sdhci_set_control_reg().
Signed-off-by: Ashok Reddy Soma
Reviewed-by: Jaehoon Chung
---
(no changes since v1)
drivers/mmc/zynq_sdhci.c | 21 +
1 file changed, 1 insertion(+), 20 deletions(-)
diff
From: T Karthik Reddy
As per SD spec when SD host controller is reset, it takes 1000msec
to detect the card state. In case, if we enable the sd bus voltage &
card detect state is not stable, then host controller will disable
the sd bus voltage.
In case of warm/subsystem reboot, due to unstable
Move tapdelay function calls to zynq_sdhci.c and make them static
inline. zynqmp_tap_delay.h has function prototypes for the functions
defined in tap_delays.c, which will not be needed anymore.
Remove tap_delays.c and zynqmp_tap_delay.h files.
Signed-off-by: Ashok Reddy Soma
---
Changes in v3:
Currently xilinx sdhci driver is using zynqmp_mmio_write() to set
tapdelay values and DLL resets. Continue to use this for SPL and mini
U-Boot where U-Boot will be executed at EL3 level.
Use firmware call xilinx_pm_request() using appropriate arguments to
set input/output tapdelays and also for
Change return type of arasan_sdhci_set_tapdelay() to int, to facilitate
returning errors. Get return values from input and output set clock phase
functions inside arasan_sdhci_set_tapdelay() and return those errors.
Signed-off-by: T Karthik Reddy
Signed-off-by: Ashok Reddy Soma
---
Changes in
set_delay() has return type as void. If there are any errors while
setting tapdelay's it won't be able to return them.
Change the prototype of set_delay() in sdhci_ops structure and return
the errors from wherever it is called.
Signed-off-by: Ashok Reddy Soma
---
(no changes since v2)
Changes
From: T Karthik Reddy
Add enums for pm node id's, pm ioctl id's, tapdelay types, dll reset types
Signed-off-by: T Karthik Reddy
Signed-off-by: Ashok Reddy Soma
---
(no changes since v1)
include/zynqmp_firmware.h | 127 ++
1 file changed, 127
This patch series updates/fixes below things:
- Handle errors from tapdelay functions and return to set_delay()
- Add ZynqMP firmware related enums which are used in sdhci driver
- Replace mmio_write() with firmware call xilinx_pm_request()
- Move tapdelay setting code from tap_delays.c to
Right now meson64_android does not know how to boot into Android
Recovery: it simply falls back to "fastboot" mode in the bootloader.
Implement the boot to recovery.
While at it, use the standard BCB way instead of a sm for consistency.
Signed-off-by: Mattijs Korpershoek
Acked-by: Neil
SEI-610 and SEI-510 are both for Android boards based on Yukawa[1]
Enable the BCB command to enable the standard Android boot flow.
[1] https://android.googlesource.com/device/amlogic/yukawa/
Signed-off-by: Mattijs Korpershoek
Acked-by: Neil Armstrong
---
configs/sei510_defconfig | 1 +
With the introduction of a generic reboot flag implemented in commit
a362ce214f ("fastboot: Implement generic fastboot_set_reboot_flag"), we
no longer need the custom PSCI implementation to handle the reboot reason.
This reverts commit 9a34dedfae0ebb031a45324c2fed8c39b2c6fcf2.
Signed-off-by:
Whenever we test for boot-fastboot in the BCB, it means that Android
wants us to boot into recovery with a special mode (fastbootd).
Force reboot into recovery in that case.
Note: we don't erase the bcb on purpose here: recoveryOS needs to read
the BCB as well to know if it boots into regular
The SEI-610 and SEI-510 boards are well supported in the
Android Open Source project via the yukawa [1] platform.
Their U-Boot version, despite being public [2] is not in mainline.
Android has multiple OSes it can boot into:
* Main android
* Recovery OS
* Fastbootd (recovery OS with fastboot
As of today, we use a "vendor specific" secure monitor call for the
reboot reason (sm).
We should not need this. Android uses the BCB (Bootloader Control Block)
to communicate with the bootloader.
Implement "reboot into bootloader" using the standard BCB way instead of
using sm calls.
Add support for enumerating MMC card in a given mode using mmc rescan and
mmc dev commands. The speed mode is provided as the last argument in these
commands and is indicated using the index from enum bus_mode in
include/mmc.h. A speed mode can be set only if it has already been enabled
in the
strlcat() need to be passed the full buffer length. The incorrect call
caused truncation of partition names for fastboot_raw_partition_... and
fastboot_partition_alias_... env lookup to much less than PART_NAME_LEN.
Fixes: 69a752983171 ("fastboot: Fix possible buffer overrun")
Signed-off-by:
On 30/07/2021 10:55, Mattijs Korpershoek wrote:
> The SEI-610 and SEI-510 boards are well supported in the
> Android Open Source project via the yukawa [1] platform.
>
> Their U-Boot version, despite being public [2] is not in mainline.
>
> Android has multiple OSes it can boot into:
> * Main
Migrate the dm_warn function to log macro with
LOGC_DM category and LOGL_WARNING level.
This macro allows filtering with log command and allows
output on all log backend.
Signed-off-by: Patrick Delaunay
---
drivers/core/util.c | 11 ---
include/dm/util.h | 2 +-
2 files changed, 1
Add a message on probe in driver model core when the default
pinctrl selection failed.
This message is displayed only when the pinctrl API is
implemented, i.e. when result is not ENOSYS.
Signed-off-by: Patrick Delaunay
---
drivers/core/device.c | 16
1 file changed, 12
Use the return value ENOSYS for unsupported API
- pinctrl_generic_set_state
- pinctrl_select_state
Signed-off-by: Patrick Delaunay
---
include/dm/pinctrl.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/dm/pinctrl.h b/include/dm/pinctrl.h
index
Hi Jaehoon,
On 30/07/21 3:02 pm, Jaehoon Chung wrote:
> On 7/30/21 6:20 PM, Aswath Govindraju wrote:
>> Hi Jaehoon,
>>
>> On 30/07/21 2:44 pm, Jaehoon Chung wrote:
>>> Hi Aswath,
>>>
>>> On 7/30/21 2:12 PM, Aswath Govindraju wrote:
Hi Jaehoon,
On 30/07/21 4:00 am, Jaehoon Chung
Hi,
On 7/29/21 6:47 PM, Alexandru Gagniuc wrote:
This test verifies that ECDSA_UCLASS is implemented, and that
ecdsa_verify() works as expected. The definition of "expected" is
"does not find a device, and returns -ENODEV".
The lack of a hardware-independent ECDSA implementation prevents us
Hi,
On 7/29/21 6:47 PM, Alexandru Gagniuc wrote:
FIT signatures can now be implemented with ECDSA. The assumption that
all FIT images are signed with RSA is no longer valid. Thus, instead
of 'select'ing RSA, only 'imply' it. This doesn't change the defaults,
but allows one to explicitly disable
Hi,
On 7/29/21 6:47 PM, Alexandru Gagniuc wrote:
The STM32MP ROM provides several service. One of them is the ability
to verify ecdsa256 signatures. Hook the ROM API into the ECDSA uclass.
Signed-off-by: Alexandru Gagniuc
---
arch/arm/mach-stm32mp/Kconfig| 9 +++
Hi,
On 7/29/21 6:47 PM, Alexandru Gagniuc wrote:
Implement the crypto_algo .verify() function for ecdsa256. Because
it backends on UCLASS_ECDSA, this change is focused on parsing the
keys from devicetree and passing this information to the specific
UCLASS driver.
Signed-off-by: Alexandru
Hi Alexandru,
On 7/29/21 6:47 PM, Alexandru Gagniuc wrote:
Define a UCLASS API for verifying ECDSA signatures. Unlike
UCLASS_MOD_EXP, which focuses strictly on modular exponentiation,
the ECDSA class focuses on verification. This is done so that it
better aligns with mach-specific
Based on thread
https://lists.denx.de/pipermail/u-boot/2021-June/451828.html
especially
"Overall we have a deficiency in the UEFI implementation in that we
cannot deal with block devices added or removed after initialization."
there is a need to deal with removable media as usb/scsi/sata.
That's
Add firmware based reset controller for Xilinx ZynqMP SoC to let other
drivers to call reset functions. Driver is only tested on Xilinx ZynqMP but
support for Xilinx Versal can be simply added. That's why reset_id and
nr_reset are assigned in probe folder.
Driver is inpired by driver from Linux
Based on discussion at
https://lore.kernel.org/r/20200318125003.ga2727...@kroah.com we got
recommendation to use explicit values for all enum values.
The patch is following this recommendation.
Signed-off-by: Michal Simek
Link:
On 7/30/21 6:20 PM, Aswath Govindraju wrote:
> Hi Jaehoon,
>
> On 30/07/21 2:44 pm, Jaehoon Chung wrote:
>> Hi Aswath,
>>
>> On 7/30/21 2:12 PM, Aswath Govindraju wrote:
>>> Hi Jaehoon,
>>>
>>> On 30/07/21 4:00 am, Jaehoon Chung wrote:
Hi Aswath,
On 7/29/21 11:55 PM, Aswath
Hi Jaehoon,
On 30/07/21 2:44 pm, Jaehoon Chung wrote:
> Hi Aswath,
>
> On 7/30/21 2:12 PM, Aswath Govindraju wrote:
>> Hi Jaehoon,
>>
>> On 30/07/21 4:00 am, Jaehoon Chung wrote:
>>> Hi Aswath,
>>>
>>> On 7/29/21 11:55 PM, Aswath Govindraju wrote:
Add support for enumerating MMC card in a
On Thu, Jul 29, 2021 at 8:26 PM Zong Li wrote:
>
> On Wed, Jul 28, 2021 at 11:18 PM Sean Anderson wrote:
> >
> > On 7/28/21 3:25 AM, Zong Li wrote:
> > > On Wed, Jul 28, 2021 at 12:29 PM Sean Anderson wrote:
> > >>
> > >> On 7/27/21 4:54 AM, Zong Li wrote:
> > >>> Invokes the generic
Hi Aswath,
On 7/30/21 2:12 PM, Aswath Govindraju wrote:
> Hi Jaehoon,
>
> On 30/07/21 4:00 am, Jaehoon Chung wrote:
>> Hi Aswath,
>>
>> On 7/29/21 11:55 PM, Aswath Govindraju wrote:
>>> Add support for enumerating MMC card in a given mode using mmc rescan and
>>> mmc dev commands. The speed mode
Right now meson64_android does not know how to boot into Android
Recovery: it simply falls back to "fastboot" mode in the bootloader.
Implement the boot to recovery.
While at it, use the standard BCB way instead of a sm for consistency.
Signed-off-by: Mattijs Korpershoek
---
SEI-610 and SEI-510 are both for Android boards based on Yukawa[1]
Enable the BCB command to enable the standard Android boot flow.
[1] https://android.googlesource.com/device/amlogic/yukawa/
Signed-off-by: Mattijs Korpershoek
---
configs/sei510_defconfig | 1 +
configs/sei610_defconfig | 1 +
As of today, we use a "vendor specific" secure monitor call for the
reboot reason (sm).
We should not need this. Android uses the BCB (Bootloader Control Block)
to communicate with the bootloader.
Implement "reboot into bootloader" using the standard BCB way instead of
using sm calls.
Whenever we test for boot-fastboot in the BCB, it means that Android
wants us to boot into recovery with a special mode (fastbootd).
Force reboot into recovery in that case.
Note: we don't erase the bcb on purpose here: recoveryOS needs to read
the BCB as well to know if it boots into regular
With the introduction of a generic reboot flag implemented in commit
a362ce214f ("fastboot: Implement generic fastboot_set_reboot_flag"), we
no longer need the custom PSCI implementation to handle the reboot reason.
This reverts commit 9a34dedfae0ebb031a45324c2fed8c39b2c6fcf2.
Signed-off-by:
The SEI-610 and SEI-510 boards are well supported in the
Android Open Source project via the yukawa [1] platform.
Their U-Boot version, despite being public [2] is not in mainline.
Android has multiple OSes it can boot into:
* Main android
* Recovery OS
* Fastbootd (recovery OS with fastboot
Hi Pratyush,
On Fri, Jul 30, 2021 at 3:31 PM Pratyush Yadav wrote:
>
> On 30/07/21 03:20PM, Bin Meng wrote:
> > The DT bindings of "jedec,spi-nor" [1] defines "m25p,fast-read" property
> > to indicate that "fast read" opcode can be used to read data from the
> > chip instead of the usual "read"
On 30/07/21 03:20PM, Bin Meng wrote:
> The DT bindings of "jedec,spi-nor" [1] defines "m25p,fast-read" property
> to indicate that "fast read" opcode can be used to read data from the
> chip instead of the usual "read" opcode.
>
> If this property is not present in DT, mask out fast read in
>
Hi Bin,
On 29/07/21 07:58PM, Bin Meng wrote:
> The DT bindings of "jedec,spi-nor" [1] defines "m25p,fast-read" property
> to indicate that "fast read" opcode can be used to read data from the
> chip instead of the usual "read" opcode.
>
> If this property is not present in DT, mask out fast read
The DT bindings of "jedec,spi-nor" [1] defines "m25p,fast-read" property
to indicate that "fast read" opcode can be used to read data from the
chip instead of the usual "read" opcode.
If this property is not present in DT, mask out fast read in
spi_nor_init_params(). This change mirrors the same
The smart spi_nor_adjust_hwcaps() does not respect the SPI flash's
hwcaps, and only looks to the controller on what can be supported.
The flash's hwcaps needs to be AND'ed before checking.
Fixes: 71025f013ccb ("mtd: spi-nor-core: Rework hwcaps selection")
Signed-off-by: Bin Meng
Reviewed-by:
On 7/30/21 7:33 AM, AKASHI Takahiro wrote:
> On Fri, Jul 30, 2021 at 06:41:01AM +0200, Michal Simek wrote:
>>
>>
>> On 7/30/21 4:35 AM, AKASHI Takahiro wrote:
>>> On Thu, Jul 29, 2021 at 04:09:32PM +0200, Michal Simek wrote:
Hi,
On 6/10/21 2:59 PM, AKASHI Takahiro wrote:
> On
81 matches
Mail list logo
