Hi
I tried my luck on the u-boot irc channel but nobody cared so I am
asking this here again.
Does cpu_get_count(..) return the number of physical CPUs or the
number of logical CPUs?
I am currently preparing a patch set which adds
arch/x86/cpu/queensbay/cpu.c and there I need
to specify a struct
On 04/06/2018 01:23 AM, Alexander Graf wrote:
>
>
> On 06.04.18 01:03, Heinrich Schuchardt wrote:
>> On 04/06/2018 12:43 AM, Alexander Graf wrote:
>>>
>>>
>>> On 05.04.18 23:28, Ivan Gorinov wrote:
Check FileHeader.Machine to make sure the EFI executable image is built
for the same arch
On Wed, Apr 4, 2018 at 12:36 PM, Maxime Ripard
wrote:
> On Wed, Apr 04, 2018 at 12:13:01PM +0530, Jagan Teki wrote:
>> On Wed, Mar 21, 2018 at 4:48 PM, Maxime Ripard
>> wrote:
>> > From: Philipp Tomsich
>> >
>> > Throughput tests have shown the sunxi_mmc driver to take over 10s to
>> > read 10MB
Hi Jaehoon,
On Wed, Mar 21, 2018 at 12:18:58PM +0100, Maxime Ripard wrote:
> From: Philipp Tomsich
>
> Throughput tests have shown the sunxi_mmc driver to take over 10s to
> read 10MB from a fast eMMC device due to excessive delays in polling
> loops.
>
> This commit restructures the main polli
Booting with SMP fails on the Allwinner A20 CPU.
https://gist.github.com/xypron/2524ba898d6905d959c744c2b05da196
When executing bootefi we need to
* copy the Power State Coordination Interface (PSCI) code to its
destination address
* switch between our hypervisor mode (HYP) and the supervisor mo
Check FileHeader.Machine to make sure the EFI executable image is built
for the same architecture. For example, 32-bit U-Boot on x86 will print
an error message instead of loading an x86_64 image and crashing.
Signed-off-by: Ivan Gorinov
---
include/pe.h | 4 +++
lib/efi_lo
On Wed, Apr 04, 2018 at 02:25:09PM +0530, Jagan Teki wrote:
> Hi Tom,
>
> Please pull this PR, these changes were there since from last release.
>
> thanks,
> Jagan.
>
> The following changes since commit 0354f4bef0f1ff1e160673794577ca00b23f3f1a:
>
> sunxi: Add DRAM_SUN8I_A83T kconfig entry
On 06.04.18 01:03, Heinrich Schuchardt wrote:
> On 04/06/2018 12:43 AM, Alexander Graf wrote:
>>
>>
>> On 05.04.18 23:28, Ivan Gorinov wrote:
>>> Check FileHeader.Machine to make sure the EFI executable image is built
>>> for the same architecture. For example, 32-bit U-Boot on x86 will print
>>>
On 04/06/2018 12:43 AM, Alexander Graf wrote:
>
>
> On 05.04.18 23:28, Ivan Gorinov wrote:
>> Check FileHeader.Machine to make sure the EFI executable image is built
>> for the same architecture. For example, 32-bit U-Boot on x86 will print
>> an error message instead of loading an x86_64 image a
On 05.04.18 23:28, Ivan Gorinov wrote:
> Check FileHeader.Machine to make sure the EFI executable image is built
> for the same architecture. For example, 32-bit U-Boot on x86 will print
> an error message instead of loading an x86_64 image and crashing.
>
> Signed-off-by: Ivan Gorinov
> ---
>
Check FileHeader.Machine to make sure the EFI executable image is built
for the same architecture. For example, 32-bit U-Boot on x86 will print
an error message instead of loading an x86_64 image and crashing.
Signed-off-by: Ivan Gorinov
---
include/pe.h | 24 +++
Hi Bryan,
On Thu, Apr 5, 2018 at 3:46 PM, Bryan O'Donoghue
wrote:
> --- a/arch/arm/mach-imx/mx7/soc.c
> +++ b/arch/arm/mach-imx/mx7/soc.c
> @@ -180,6 +180,8 @@ int arch_cpu_init(void)
> isolate_resource();
> #endif
>
> + init_snvs();
Shouldn't this be called only if CONFIG_SECURE
+ Stefano
On 05/04/18 19:46, Bryan O'Donoghue wrote:
Working with HAB on the i.MX7 we've encountered a case where a board that
successfully authenticates u-boot when booting Linux via OPTEE subsequently
fails to properly bring up the RTC.
The RTC registers live in the low-power block of the Sec
Working with HAB on the i.MX7 we've encountered a case where a board that
successfully authenticates u-boot when booting Linux via OPTEE subsequently
fails to properly bring up the RTC.
The RTC registers live in the low-power block of the Secure Non-Volatile
Storage (SNVS) block.
The root cause o
On Thu, Apr 5, 2018 at 11:28 AM, Marek Vasut wrote:
> On 04/05/2018 04:46 PM, Dinh Nguyen wrote:
>>
>>
>> On 04/05/2018 09:12 AM, Dinh Nguyen wrote:
>>> v
>>>
>>> On 04/04/2018 05:56 PM, Marek Vasut wrote:
On 04/05/2018 12:18 AM, Dinh Nguyen wrote:
> Add a DM compatible reset driver for t
On 04/05/2018 04:46 PM, Dinh Nguyen wrote:
>
>
> On 04/05/2018 09:12 AM, Dinh Nguyen wrote:
>> v
>>
>> On 04/04/2018 05:56 PM, Marek Vasut wrote:
>>> On 04/05/2018 12:18 AM, Dinh Nguyen wrote:
Add a DM compatible reset driver for the SoCFPGA platform.
Signed-off-by: Dinh Nguyen
>>
Hi Ivan,
On Thu, Apr 5, 2018 at 7:07 AM, Ivan Gorinov wrote:
> The microcode update data block encoded in Device Tree is used by
> the bootstrap processor (BSP) but not passed to the other CPUs (AP).
>
I don't understand what the bug is here. The AP microcode update is
done in sipi_vector.S.
>
sst26wf flash series block protection implementation differs
from other SST series, so add specific implementation
flash_lock/flash_unlock/flash_is_locked functions for sst26wf
flash ICs.
Signed-off-by: Eugeniy Paltsev
---
Changes v2->v3:
* Move SST26 command defenition to sf_internal.h
* Merge
This commit adds support for the SST sst26wf016, sst26wf032
and sst26wf064 flash IC.
Signed-off-by: Eugeniy Paltsev
---
Changes v2->v3:
* None.
Changes v1->v2:
* None.
drivers/mtd/spi/spi_flash_ids.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mtd/spi/spi_flash_ids.c b/dri
Add support for the SST sst26wf016, sst26wf032 and sst26wf064 flash IC:
sst26wf*** flash series block protection implementation differs from other
SST series, so we add implementation for sst26wf*** lock/unlock/is_locked
functions.
Add sst26wf016, sst26wf032 and sst26wf064 flash IC info to spi_fl
On 03/15/2018 12:07 AM, Yogesh Narayan Gaur wrote:
> Updated copyright info for the issues reported after running
> check-legal test.
>
> Signed-off-by: Yogesh Gaur
> ---
> Legally NXP and Freescale Semiconductor are same entity.
> drivers/net/fsl-mc/dpbp.c | 2 +-
> drivers/net/fsl-mc/
On 04/05/2018 09:12 AM, Dinh Nguyen wrote:
> v
>
> On 04/04/2018 05:56 PM, Marek Vasut wrote:
>> On 04/05/2018 12:18 AM, Dinh Nguyen wrote:
>>> Add a DM compatible reset driver for the SoCFPGA platform.
>>>
>>> Signed-off-by: Dinh Nguyen
>>
>> [...]
>>
>>> +static int socfpga_reset_request(stru
v
On 04/04/2018 05:56 PM, Marek Vasut wrote:
> On 04/05/2018 12:18 AM, Dinh Nguyen wrote:
>> Add a DM compatible reset driver for the SoCFPGA platform.
>>
>> Signed-off-by: Dinh Nguyen
>
> [...]
>
>> +static int socfpga_reset_request(struct reset_ctl *reset_ctl)
>> +{
>> +debug("%s(reset_ct
Am Montag, 2. April 2018, 11:51:30 CEST schrieb Dr. Philipp Tomsich:
> Arturri,
>
> > On 2 Apr 2018, at 11:38, Artturi Alm wrote:
> >
> > On Sun, Apr 01, 2018 at 10:21:50PM +0200, Philipp Tomsich wrote:
> >>> We use ARM arch timer instead.
> >>>
> >>> Signed-off-by: Kever Yang
> >>> ---
> >>>
On Thu, Apr 5, 2018 at 6:10 PM, Eugeniy Paltsev
wrote:
> On Wed, 2018-04-04 at 19:58 +0530, Jagan Teki wrote:
>> On Mon, Mar 26, 2018 at 4:38 PM, Eugeniy Paltsev
>> wrote:
>> > sst26wf flash series block protection implementation differs
>> > from other SST series, so add implementation for sst26
On Wed, 2018-04-04 at 19:58 +0530, Jagan Teki wrote:
> On Mon, Mar 26, 2018 at 4:38 PM, Eugeniy Paltsev
> wrote:
> > sst26wf flash series block protection implementation differs
> > from other SST series, so add implementation for sst26wf
> > lock/unlock/is_locked functions.
[snip]
> >
> > +/* ss
> In raspberrypi-firmware 7fdcd00e00a42a1c91e8bd6f5eb8352fe9358557 and
> later start.elf now sets the EMMC clock to 200 MHz.
>
> According to Phil Elwell in
> https://github.com/raspberrypi/firmware/issues/953
> the SDHost controller shares the core/VPU clock and doesn't use
> the EMMC clock.
>
>
On Wed, 2018-04-04 at 16:07 -0700, Ivan Gorinov wrote:
> The microcode update data block encoded in Device Tree is used by
> the bootstrap processor (BSP) but not passed to the other CPUs (AP).
BSP abbreviation is confusing. AP is even more looking to preceding
words. I don't see either where they
Sorry to warm up this old thread, but I think the implementation of
env_save does not really work on error:
On my board, I have the environment stored in QSPI. If saving fails,
env_save tries to continue to the next environment driver, but
env_driver_lookup/env_get_location always returns the
Introduce functions to print information about loaded images.
If we want to analyze an exception in an EFI image we need the offset
between the PC and the start of the loaded image.
With efi_print_image_info() we can print the necessary information for a
single image, e.g.
UEFI image [0xbffe6000
If a crash occurs the relocation information of loaded EFI images is
displayed.
---
v4
Remove merged patches.
Avoid ifdefs by using a stub function.
v3
Remove merged patches.
Change the output format for loaded images.
v2
Merge with "efi_loader: print inform
If an exception occurs in a UEFI loaded image we need the start address of
the image to determine the relocation offset.
This patch adds the necessary lines after the registers in the crash dump.
A possible output would be:
UEFI image [0xbffe6000:0xbffe631f] pc=0x138 '/\snp.efi'
With the offset
> The Raspberr Pi Foundation released a new RPi3 version which we want
> to detect as well, so we can enable ethernet on it and know the correct
> device tree file name.
>
> Add an identifier for it.
>
> Signed-off-by: Alexander Graf
Thanks, applied to efi-next
Alex
__
> The new Raspberry Pi B 3+ has a lan78xx device attached to it. Let's add
> driver support in U-Boot for it.
>
> Signed-off-by: Alexander Graf
Thanks, applied to efi-next
Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listin
> The new Raspberry Pi B 3+ has a lan78xx device attached to it. Let's add
> driver support in U-Boot for it.
>
> Signed-off-by: Peter Robinson
Thanks, applied to efi-next
Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listin
When we enable CONFIG_OF_BOARD on Raspberry Pis, we may end up without
serial console support in early boot. Hence we need to make the serial
port optional, otherwise we will never get to the point where serial
would be probed.
Signed-off-by: Alexander Graf
---
configs/rpi_0_w_defconfig | 1 +
c
On 04/04/2018 04:36 PM, Heinrich Schuchardt wrote:
If an exception occurs in a UEFI loaded image we need the start address of
the image to determine the relocation offset.
This patch adds the necessary lines after the registers in the crash dump.
A possible output would be:
UEFI image [0xbffe60
On 04/04/2018 09:14 PM, Heinrich Schuchardt wrote:
On 04/04/2018 06:11 PM, Alexander Graf wrote:
On 04.04.18 17:10, Heinrich Schuchardt wrote:
On 04/04/2018 02:32 PM, Alexander Graf wrote:
On 03.04.18 21:59, Heinrich Schuchardt wrote:
The UEFI spec mandates that unaligned memory access shou
By using this file one can avoid cluttering .h file with u-boot
HUSH commands necessary for booting target device.
With such approach the commands are stored only in one place and can be
reused if needed.
Signed-off-by: Lukasz Majewski
Reviewed-by: Stefano Babic
---
Changes in v2:
- None
bo
This commit provides support for Kieback & Peter GmbH IMX6Q based
TPC board.
U-boot console output:
U-Boot SPL 2018.05-rc1-5-g631e2d01fd (Apr 04 2018 - 21:16:24 +0200)
Trying to boot from MMC1
U-Boot 2018.05-rc1-5-g631e2d01fd (Apr 04 2018 - 21:16:24 +0200)
CPU: Freescale i.MX6Q rev1.5
40 matches
Mail list logo
