This patch adds fdt support to the m68k architecture.
Signed-off-by: Angelo Dureghello
---
Changes for v2:
- add OF_CONTROL, DM and DM_SERIAL as default config options
for all cpu families
Changes for v3:
- none
---
arch/Kconfig | 1 +
arch/m68k/Kconfig| 33
Enable DT usage for all m68k boards. To provide a
working single binary, the dts has been kept as embedded.
Signed-off-by: Angelo Dureghello
---
Changes for v2:
- new patch
Changes for v3:
- none
---
configs/M5208EVBE_defconfig | 2 ++
configs/M52277EVB_defconfig
This patch adds CONFIG_DM_SPI for all m68k boards using
the cf_spi.c driver (DSPI module).
Signed-off-by: Angelo Dureghello
---
Changes for v2:
- new patch
Changes for v3:
- none
---
configs/M52277EVB_defconfig | 1 +
configs/M52277EVB_stmicro_defconfig | 1 +
At present in arch_setup_gd() it calls printch(' ') at the end which
has been a mystery for a long time as without such call the 64-bit
U-Boot just does not boot at all.
In fact this is due to the bug that board_init_f() was called with
boot_flags not being set. Hence whatever value being there
This updates travis-ci to use QEMU 3.0.0 for testing.
Signed-off-by: Bin Meng
---
Changes in v2:
- new patch to update to use QEMU 3.0.0 for travis-ci testing
.travis.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/.travis.yml b/.travis.yml
index 55d9123..d9e5b35
So far the TSC timer driver supports trying hardware calibration first
and using device tree as last resort for its running frequency as the
normal timer.
However when it is used as the early timer, it only supports hardware
calibration and if it fails, the driver just panics. This introduces
a
From: Heinrich Schuchardt
Currently the relocation of the EFI runtime on x86_64 fails. This renders
the EFI subsystem unusable. The ELF relocation records for x86_64 contain
an addend field.
Always write the function name into error messages related to the EFI
runtime relocation.
Break an
From: Heinrich Schuchardt
Currently we support only relocations of type ELF64_R_TYPE or ELF32_R_TYPE.
We should be warned if other relocation types appear in the relocation
sections.
This type of message has helped to identify code overwriting a relocation
section before relocation and
Specify X86_TSC_TIMER_EARLY_FREQ for Quark SoC so that TSC as
the early timer can be supported.
Signed-off-by: Bin Meng
---
Changes in v2:
- Change the config option value to 400 which indicates 400 MHz
arch/x86/cpu/quark/Kconfig | 4
1 file changed, 4 insertions(+)
diff --git
From: Heinrich Schuchardt
On x86_64 the field global_data_ptr is assigned before relocation. As
sections for uninitialized global data (.bss) overlap with the relocation
sections (.rela) this destroys the relocation table and leads to spurious
errors.
Initialization forces the global_data_ptr
From: Heinrich Schuchardt
Since commit 380d4f787a3f ("rtc: Allow use of RTC in SPL and TPL")
qemu-x86_64_defconfig does not boot anymore.
Fixes: 380d4f787a3f ("rtc: Allow use of RTC in SPL and TPL")
Signed-off-by: Heinrich Schuchardt
Signed-off-by: Bin Meng
---
Changes in v2: None
grub_x86.efi is for 32-bit QEMU. Generate the 64-bit one.
Signed-off-by: Bin Meng
---
Changes in v2:
- new patch to generate grub_x64.efi for qemu-x86_64 for travis-ci
.travis.yml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/.travis.yml b/.travis.yml
index f78749a..55d9123 100644
Add qemu-x86_64 to the list of targets we use for test.py runs.
Signed-off-by: Bin Meng
---
Changes in v2: None
.travis.yml | 8
1 file changed, 8 insertions(+)
diff --git a/.travis.yml b/.travis.yml
index d9e5b35..ceef585 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -412,6
There are some sections in current doc saying 64-bit is unsupported.
This apparently is out of date. Remove it.
Signed-off-by: Bin Meng
Reviewed-by: Heinrich Schuchardt
---
Changes in v2: None
doc/README.x86 | 17 -
1 file changed, 17 deletions(-)
diff --git a/doc/README.x86
With the '-march=core2' fix, it seems that we have some luck that
the 64-bit U-Boot boots again. However if we examine the disassembly
codes there are still SSE instructions elsewhere which means passing
cpu type to GCC is not enough to prevent it from generating these
instructions. A simple test
With newer kernel.org GCC (7.3.0 or 8.1.0), the u-boot.rom image
built for qemu-x86_64 target does not boot. It keeps resetting
soon after the 32-bit SPL jumps to 64-bit proper. Debugging shows
that the reset happens inside env_callback_init().
0113dd85 :
113dd85: 41 54
Currently only 32-bit U-Boot for QEMU x86 is documented. Mention
the 64-bit support.
Signed-off-by: Bin Meng
Reviewed-by: Heinrich Schuchardt
---
Changes in v2:
- some rewording in the doc per Heinrich's review comments
doc/README.x86 | 19 +--
1 file changed, 17
At present the QEMU x86_64 target is broken here and there, for
example with newer compiler it even does not boot. EFI loader does
not work either.
This series is a combination of Heinrich's EFI loader fixes and
my fixes to QEMU x86_64 target. To enable qemu-x86_64 target in
travis-ci for build
Growing of binary size asks for long assembly jumps.
Signed-off-by: Angelo Dureghello
---
Changes for v2:
- new patch
Changes for v3:
- none
---
arch/m68k/cpu/mcf547x_8x/start.S | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/m68k/cpu/mcf547x_8x/start.S
This patch adds basic dts files for all the m68k boards.
Signed-off-by: Angelo Dureghello
---
Changes for v2:
- new patch
Changes for v3:
- none
---
arch/m68k/dts/M5208EVBE.dts | 22 +++
arch/m68k/dts/M52277EVB.dts | 25
This patch adds missing CONFIG_MCFUART to Kconfig.
Signed-off-by: Angelo Dureghello
---
Changes for v2:
- better Kconfig help
Changes for v3:
- none
---
drivers/serial/Kconfig | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index
Hi Takahiro,
On Fri, 12 Oct 2018 14:09:07 +0900
AKASHI Takahiro wrote:
> With this patch, a removable USB mass storage device attached to the
> system will also be scanned to find and boot an EFI binary (that is
> BOOTEFI_NAME, see config_distro_bootcmd.h).
>
> Signed-off-by: AKASHI Takahiro
This patch adds a basic group of devicetrees, one for each
cpu family, including actually just uart and dspi devices,
since these are the drivers supporting devicetree (support
added in this patch-set).
Acked-by: Jagan Teki
Signed-off-by: Angelo Dureghello
---
Changes for v2:
- add mcf54xx.dtsi
Hi Alex,
On 29 September 2018 at 13:23, Simon Glass wrote:
> On my Ubuntu 18.04.1 machine two driver-model bus tests have started
> failing recently. The problem appears to be that the DATA region of the
> executable is protected. This does not seem correct, but perhaps there
> is a reason.
>
>
On Sat, Oct 13, 2018 at 11:52 PM Bin Meng wrote:
>
> On Sat, Oct 13, 2018 at 11:02 PM Bin Meng wrote:
> >
> > Add qemu-x86_64 to the list of targets we use for test.py runs.
> >
> > Signed-off-by: Bin Meng
> >
> > ---
> > testp.py testing is currently failing at 'tftpboot grub_x86.efi/u-boot',
On 10/13/2018 05:06 PM, Bin Meng wrote:
> Specify X86_TSC_TIMER_EARLY_FREQ for Quark SoC so that TSC as
> the early timer can be supported.
>
> Signed-off-by: Bin Meng
The Intel Quark CPU runs at 400 MHz. If you follow my suggestion for
patch 10 to set the parameter in MHz instead of Hz, please
Hi Heinrich,
On Sun, Oct 14, 2018 at 12:44 AM Heinrich Schuchardt wrote:
>
> On 10/13/2018 05:06 PM, Bin Meng wrote:
> > So far the TSC timer driver supports trying hardware calibration first
> > and using device tree as last resort for its running frequency as the
> > normal timer.
> >
> >
On Sat, Oct 13, 2018 at 1:13 PM Meul, Dirk wrote:
>
> Instead of keeping a custom environment, use a more generic approach
> by switching to distro config.
>
> Signed-off-by: Dirk Meul
Reviewed-by: Fabio Estevam
___
U-Boot mailing list
On 10/13/2018 05:06 PM, Bin Meng wrote:
> So far the TSC timer driver supports trying hardware calibration first
> and using device tree as last resort for its running frequency as the
> normal timer.
>
> However when it is used as the early timer, it only supports hardware
> calibration and if
On 10/13/2018 05:06 PM, Bin Meng wrote:
> At present in arch_setup_gd() it calls printch(' ') at the end which
> has been a mystery for a long time as without such call the 64-bit
> U-Boot just does not boot at all.
>
> In fact this is due to the bug that board_init_f() was called with
>
Instead of keeping a custom environment, use a more generic approach
by switching to distro config.
Signed-off-by: Dirk Meul
---
configs/udoo_defconfig | 2 +
include/configs/udoo.h | 112 +
2 files changed, 25 insertions(+), 89 deletions(-)
diff --git
On 10/13/2018 05:06 PM, Bin Meng wrote:
> There are some sections in current doc saying 64-bit is unsupported.
> This apparently is out of date. Remove it.
>
> Signed-off-by: Bin Meng
Reviewed-by: Heinrich Schuchardt
___
U-Boot mailing list
On 10/13/2018 05:06 PM, Bin Meng wrote:
> Currently only 32-bit U-Boot for QEMU x86 is documented. Mention
> the 64-bit support.
>
> Signed-off-by: Bin Meng
>
> ---
> Changes in this version:
> - add more information about 64-bit support
>
> doc/README.x86 | 19 +--
> 1 file
On Sat, Oct 13, 2018 at 11:02 PM Bin Meng wrote:
>
> Add qemu-x86_64 to the list of targets we use for test.py runs.
>
> Signed-off-by: Bin Meng
>
> ---
> testp.py testing is currently failing at 'tftpboot grub_x86.efi/u-boot',
> still investigating why. tftpboot works well on my local machine.
On 10/13/2018 05:06 PM, Bin Meng wrote:
> With the '-march=core2' fix, it seems that we have some luck that
> the 64-bit U-Boot boots again. However if we examine the disassembly
> codes there are still SSE instructions elsewhere which means passing
> cpu type to GCC is not enough to prevent it
At present in arch_setup_gd() it calls printch(' ') at the end which
has been a mystery for a long time as without such call the 64-bit
U-Boot just does not boot at all.
In fact this is due to the bug that board_init_f() was called with
boot_flags not being set. Hence whatever value being there
Add qemu-x86_64 to the list of targets we use for test.py runs.
Signed-off-by: Bin Meng
---
testp.py testing is currently failing at 'tftpboot grub_x86.efi/u-boot',
still investigating why. tftpboot works well on my local machine.
.travis.yml | 8
1 file changed, 8 insertions(+)
From: Heinrich Schuchardt
Currently we support only relocations of type ELF64_R_TYPE or ELF32_R_TYPE.
We should be warned if other relocation types appear in the relocation
sections.
This type of message has helped to identify code overwriting a relocation
section before relocation and
Currently only 32-bit U-Boot for QEMU x86 is documented. Mention
the 64-bit support.
Signed-off-by: Bin Meng
---
Changes in this version:
- add more information about 64-bit support
doc/README.x86 | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git
From: Heinrich Schuchardt
Since commit 380d4f787a3f ("rtc: Allow use of RTC in SPL and TPL")
qemu-x86_64_defconfig does not boot anymore.
Fixes: 380d4f787a3f ("rtc: Allow use of RTC in SPL and TPL")
Signed-off-by: Heinrich Schuchardt
Signed-off-by: Bin Meng
---
configs/qemu-x86_64_defconfig
From: Heinrich Schuchardt
Currently the relocation of the EFI runtime on x86_64 fails. This renders
the EFI subsystem unusable. The ELF relocation records for x86_64 contain
an addend field.
Always write the function name into error messages related to the EFI
runtime relocation.
Break an
From: Heinrich Schuchardt
On x86_64 the field global_data_ptr is assigned before relocation. As
sections for uninitialized global data (.bss) overlap with the relocation
sections (.rela) this destroys the relocation table and leads to spurious
errors.
Initialization forces the global_data_ptr
So far the TSC timer driver supports trying hardware calibration first
and using device tree as last resort for its running frequency as the
normal timer.
However when it is used as the early timer, it only supports hardware
calibration and if it fails, the driver just panics. This introduces
a
Specify X86_TSC_TIMER_EARLY_FREQ for Quark SoC so that TSC as
the early timer can be supported.
Signed-off-by: Bin Meng
---
arch/x86/cpu/quark/Kconfig | 4
1 file changed, 4 insertions(+)
diff --git a/arch/x86/cpu/quark/Kconfig b/arch/x86/cpu/quark/Kconfig
index 76f1592..2d667ca 100644
There are some sections in current doc saying 64-bit is unsupported.
This apparently is out of date. Remove it.
Signed-off-by: Bin Meng
---
doc/README.x86 | 17 -
1 file changed, 17 deletions(-)
diff --git a/doc/README.x86 b/doc/README.x86
index 64da4ac..fe47221 100644
---
With newer kernel.org GCC (7.3.0 or 8.1.0), the u-boot.rom image
built for qemu-x86_64 target does not boot. It keeps resetting
soon after the 32-bit SPL jumps to 64-bit proper. Debugging shows
that the reset happens inside env_callback_init().
0113dd85 :
113dd85: 41 54
With the '-march=core2' fix, it seems that we have some luck that
the 64-bit U-Boot boots again. However if we examine the disassembly
codes there are still SSE instructions elsewhere which means passing
cpu type to GCC is not enough to prevent it from generating these
instructions. A simple test
At present the QEMU x86_64 target is broken here and there, for
example with newer compiler it even does not boot. EFI loader does
not work either.
This series is a combination of Heinrich's EFI loader fixes and
my fixes to QEMU x86_64 target. The goal is to enable qemu-x86_64
target in travis-ci
Hi Mario,
On 4 October 2018 at 01:00, Mario Six wrote:
> The regmap functions currently assume that all register map accesses
> have a data width of 32 bits, but there are maps that have different
> widths.
>
> To rectify this, implement the regmap_raw_read and regmap_raw_write
> functions from
Hello Alex, hello Simon,
in arch/arm/lib/elf_aarch64_efi.lds we merge the .bss section into the
.data section with a comment by Simon:
"The EFI loader doesn't seem to like a .bss section, so we stick it into
.data".
Real live EFI binaries like iPXE's snp.efi have a .bss section:
Number of
On Sat, Oct 13, 2018 at 3:40 PM Heinrich Schuchardt wrote:
>
> On x86_64 the field global_data_ptr is assigned before relocation. As
> sections for uninitialized global data (.bss) overlap with the relocation
> sections (.rela) this destroys the relocation table and leads to spurious
> errors.
>
Hi Bin,
On 12.10.2018 17:34, Bin Meng wrote:
On Fri, Oct 12, 2018 at 10:00 PM Stefan Roese wrote:
Hi!
I just tested the latest U-Boot version on one of my x86
platforms (Baytrail theadorable-x86-dfi-bt700_defconfig).
Unfortunately this patch break the board port, resulting in
this output:
On Sat, Oct 13, 2018 at 5:43 AM Heinrich Schuchardt wrote:
>
> Currently the relocation of the EFI runtime on x86_64 fails. This renders
> the EFI subsystem unusable. The ELF relocation records for x86_64 contain
> an addend field.
>
> Always write the function name into error messages related to
On x86_64 the field global_data_ptr is assigned before relocation. As
sections for uninitialized global data (.bss) overlap with the relocation
sections (.rela) this destroys the relocation table and leads to spurious
errors.
Initialization forces the global_data_ptr into a section for
Hi Heinrich,
On Sat, Oct 13, 2018 at 12:57 PM Bin Meng wrote:
>
> Hi Heinrich,
>
> On Sat, Oct 13, 2018 at 9:07 AM Heinrich Schuchardt
> wrote:
> >
> > On x86_64 the field global_data_ptr is assigned before relocation. As
> > global data sections (.data and .bss) overlap with the relocation
When an operating system started via bootefi tries to reset or power off
this is done by calling the EFI runtime ResetSystem(). On most ARMv8 system
the actual reset relies on PSCI. Depending on whether the PSCI firmware
resides the hypervisor or in the supervisor either an HVC or an SVC command
56 matches
Mail list logo
