Re: [U-Boot] Beagle-XM: u-boot SPL fat support (was Re: [opensuse-arm] Beagleboard Xm CPU speed)

On 19.03.2013, at 23:12, Tom Rini wrote: On 03/19/2013 03:53 PM, Alexander Graf wrote: On 19.03.2013, at 18:01, Nishanth Menon wrote: Change in subject. Original thread start: http://lists.opensuse.org/opensuse-arm/2013-03/msg00076.html On 17:15-20130319, Guillaume Gardet

Re: [U-Boot] Beagle-XM: u-boot SPL fat support (was Re: [opensuse-arm] Beagleboard Xm CPU speed)

Am 10.05.2013 um 20:51 schrieb Tom Rini tr...@ti.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/10/2013 02:31 PM, Alexander Graf wrote: On 19.03.2013, at 23:12, Tom Rini wrote: On 03/19/2013 03:53 PM, Alexander Graf wrote: On 19.03.2013, at 18:01, Nishanth Menon wrote

Re: [U-Boot] Beagle-XM: u-boot SPL fat support (was Re: [opensuse-arm] Beagleboard Xm CPU speed)

Am 11.05.2013 um 02:08 schrieb Wolfgang Denk w...@denx.de: Dear Alexander, In message 154a1277-6344-4ab8-9d98-58bbcc38c...@suse.de you wrote: Well, that would make the situation on OMAP slightly better, but wouldn't help on other SoCs. I think we should rather try and get a reasonably

Re: [U-Boot] Beagle-XM: u-boot SPL fat support (was Re: [opensuse-arm] Beagleboard Xm CPU speed)

On 19.03.2013, at 18:01, Nishanth Menon wrote: Change in subject. Original thread start: http://lists.opensuse.org/opensuse-arm/2013-03/msg00076.html On 17:15-20130319, Guillaume Gardet wrote: Le 19/03/2013 17:04, Nishanth Menon a écrit : On 08:47-20130319, gary wrote: Just a FYI,

Re: [U-Boot] [PATCH 1/3] PPC 85xx: Detect e500v2 / e500mc during runtime

On 21.01.2014, at 03:25, Scott Wood scottw...@freescale.com wrote: On Sun, 2014-01-19 at 16:19 +0100, Alexander Graf wrote: With the qemu-ppce500 machine type we can run the same board with either an e500v2 or an e500mc core plugged in. This means that the IVOR setup can't be based

Re: [U-Boot] [PATCH 3/3] PPC 85xx: Add qemu-ppce500 machine

On 21.01.2014, at 03:25, Scott Wood scottw...@freescale.com wrote: On Sun, 2014-01-19 at 16:19 +0100, Alexander Graf wrote: For KVM we have a special PV machine type called ppce500. This machine is inspired by the MPC8544DS board, but implements a lot less features than that one. It also

Re: [U-Boot] [PATCH 3/3] PPC 85xx: Add qemu-ppce500 machine

On 24.01.2014, at 01:49, Scott Wood scottw...@freescale.com wrote: On Thu, 2014-01-23 at 14:08 +0100, Alexander Graf wrote: On 21.01.2014, at 03:25, Scott Wood scottw...@freescale.com wrote: On Sun, 2014-01-19 at 16:19 +0100, Alexander Graf wrote: For KVM we have a special PV machine type

Re: [U-Boot] [PATCH 3/3] PPC 85xx: Add qemu-ppce500 machine

On 24.01.2014, at 02:39, Scott Wood scottw...@freescale.com wrote: On Fri, 2014-01-24 at 02:25 +0100, Alexander Graf wrote: On 24.01.2014, at 01:49, Scott Wood scottw...@freescale.com wrote: On Thu, 2014-01-23 at 14:08 +0100, Alexander Graf wrote: On 21.01.2014, at 03:25, Scott Wood scottw

[U-Boot] [PATCH v2 1/6] PPC 85xx: Detect e500v2 / e500mc during runtime

With the qemu-ppce500 machine type we can run the same board with either an e500v2 or an e500mc core plugged in. This means that the IVOR setup can't be based on compile time decisions, so instead we have to do a runtime check which CPU generation we're running on. Signed-off-by: Alexander Graf

[U-Boot] [PATCH v2 0/6] PPC 85xx: Add support for QEMU's ppce500 PV machine

device tree - find PCI controllers from device tree - find CPU speed from device tree Alexander Graf (6): PPC 85xx: Detect e500v2 / e500mc during runtime PPC 85xx: Add ELF entry point PPC 85xx: Add qemu-ppce500 machine PPC 85xx: Find CCSRBAR on ppce500 from device tree PPC 85xx: Find

[U-Boot] [PATCH v2 3/6] PPC 85xx: Add qemu-ppce500 machine

ppce500 machine as it is implemented today. Signed-off-by: Alexander Graf ag...@suse.de --- v1 - v2: - Write device tree offset directly into global variable - use r4 rather than r2 for that - access fdt directly from in-memory copy - remove unneeded header includes - clean up pci

[U-Boot] [PATCH v2 4/6] PPC 85xx: Find CCSRBAR on ppce500 from device tree

The definition of our ppce500 PV machine is that every address is dynamically determined through device tree bindings. So don't hardcode where CCSR is in our physical memory layout but instead read it dynamically from the device tree we get passed on boot. Signed-off-by: Alexander Graf ag

[U-Boot] [PATCH v2 2/6] PPC 85xx: Add ELF entry point

We want to be able to directly execute the ELF binary without going through the u-boot.bin one. To know where we have to start executing this ELF binary we have to tell the linker where our entry point is. Signed-off-by: Alexander Graf ag...@suse.de --- arch/powerpc/cpu/mpc85xx/u-boot.lds

[U-Boot] [PATCH v2 5/6] PPC 85xx: Find PCI host controllers on ppce500 from device tree

The definition of our ppce500 PV machine is that every address is dynamically determined through device tree bindings. So don't hardcode where PCI devices are in our physical memory layout but instead read them dynamically from the device tree we get passed on boot. Signed-off-by: Alexander

[U-Boot] [PATCH v2 6/6] PPC 85xx: Find CPU speed on ppce500 from device tree

-by: Alexander Graf ag...@suse.de --- arch/powerpc/cpu/mpc85xx/Makefile |2 ++ board/freescale/qemu-ppce500/qemu-ppce500.c | 43 +++ 2 files changed, 45 insertions(+) diff --git a/arch/powerpc/cpu/mpc85xx/Makefile b/arch/powerpc/cpu/mpc85xx/Makefile index ef7637a

Re: [U-Boot] [PATCH v2 6/6] PPC 85xx: Find CPU speed on ppce500 from device tree

On 04.02.2014, at 03:52, Scott Wood scottw...@freescale.com wrote: On Fri, 2014-01-31 at 12:16 +0100, Alexander Graf wrote: The only thing we know in our PV machine through device tree is the clock speed of the CPUs. Take that as CPU speed, system speed and ddr speed so that we have some

Re: [U-Boot] [PATCH v2 1/6] PPC 85xx: Detect e500v2 / e500mc during runtime

On 04.02.2014, at 02:59, Scott Wood scottw...@freescale.com wrote: On Fri, 2014-01-31 at 12:16 +0100, Alexander Graf wrote: With the qemu-ppce500 machine type we can run the same board with either an e500v2 or an e500mc core plugged in. This means that the IVOR setup can't be based

Re: [U-Boot] [PATCH v2 3/6] PPC 85xx: Add qemu-ppce500 machine

On 04.02.2014, at 03:19, Scott Wood scottw...@freescale.com wrote: On Fri, 2014-01-31 at 12:16 +0100, Alexander Graf wrote: +void pci_init_board(void) +{ +struct fsl_pci_info pci_info; +const void *fdt = get_fdt(); +int pci_node; + +puts(\n); + +pci_node

Re: [U-Boot] [PATCH v2 4/6] PPC 85xx: Find CCSRBAR on ppce500 from device tree

On 04.02.2014, at 03:24, Scott Wood scottw...@freescale.com wrote: On Fri, 2014-01-31 at 12:16 +0100, Alexander Graf wrote: The definition of our ppce500 PV machine is that every address is dynamically determined through device tree bindings. So don't hardcode where CCSR is in our physical

Re: [U-Boot] [PATCH v2 5/6] PPC 85xx: Find PCI host controllers on ppce500 from device tree

On 04.02.2014, at 03:47, Scott Wood scottw...@freescale.com wrote: On Fri, 2014-01-31 at 12:16 +0100, Alexander Graf wrote: The definition of our ppce500 PV machine is that every address is dynamically determined through device tree bindings. So don't hardcode where PCI devices are in our

Re: [U-Boot] [PATCH v2 3/6] PPC 85xx: Add qemu-ppce500 machine

On 06.02.2014, at 23:55, Scott Wood scottw...@freescale.com wrote: On Thu, 2014-02-06 at 13:48 +0100, Alexander Graf wrote: On 04.02.2014, at 03:19, Scott Wood scottw...@freescale.com wrote: On Fri, 2014-01-31 at 12:16 +0100, Alexander Graf wrote: +void pci_init_board(void) +{ + struct

Re: [U-Boot] [PATCH v2 6/6] PPC 85xx: Find CPU speed on ppce500 from device tree

On 07.02.2014, at 02:33, Scott Wood scottw...@freescale.com wrote: On Thu, 2014-02-06 at 12:11 +0100, Alexander Graf wrote: On 04.02.2014, at 03:52, Scott Wood scottw...@freescale.com wrote: On Fri, 2014-01-31 at 12:16 +0100, Alexander Graf wrote: The only thing we know in our PV machine

Re: [U-Boot] [PATCH v2 1/6] PPC 85xx: Detect e500v2 / e500mc during runtime

On 07.02.2014, at 01:51, Scott Wood scottw...@freescale.com wrote: On Thu, 2014-02-06 at 12:40 +0100, Alexander Graf wrote: On 04.02.2014, at 02:59, Scott Wood scottw...@freescale.com wrote: On Fri, 2014-01-31 at 12:16 +0100, Alexander Graf wrote: With the qemu-ppce500 machine type we can

Re: [U-Boot] [PATCH v2 5/6] PPC 85xx: Find PCI host controllers on ppce500 from device tree

On 06.02.2014, at 23:52, Scott Wood scottw...@freescale.com wrote: On Thu, 2014-02-06 at 14:26 +0100, Alexander Graf wrote: On 04.02.2014, at 03:47, Scott Wood scottw...@freescale.com wrote: On Fri, 2014-01-31 at 12:16 +0100, Alexander Graf wrote: The definition of our ppce500 PV machine

Re: [U-Boot] [PATCH v2 5/6] PPC 85xx: Find PCI host controllers on ppce500 from device tree

On 06.02.2014, at 23:52, Scott Wood scottw...@freescale.com wrote: On Thu, 2014-02-06 at 14:26 +0100, Alexander Graf wrote: On 04.02.2014, at 03:47, Scott Wood scottw...@freescale.com wrote: On Fri, 2014-01-31 at 12:16 +0100, Alexander Graf wrote: The definition of our ppce500 PV machine

Re: [U-Boot] [Qemu-ppc] [PATCH v2 5/6] PPC 85xx: Find PCI host controllers on ppce500 from device tree

On 07.02.2014, at 15:54, Alexander Graf ag...@suse.de wrote: On 06.02.2014, at 23:52, Scott Wood scottw...@freescale.com wrote: On Thu, 2014-02-06 at 14:26 +0100, Alexander Graf wrote: How about using fdt_translate_address() or other existing functionality? Mind to show exactly how

[U-Boot] [PATCH v3 0/6] PPC 85xx: Add support for QEMU's ppce500 PV machine

ccsr map - s/cell size/cell count/ - add temporary map define - use fdt_get_base_address() to find region - use new APIs - remove myfdt helpers Alexander Graf (6): fdt_support: split fdt_getprop_u32_default fdt_support: Add helper function to read ranges property PPC: 85xx: Remove IVOR

[U-Boot] [PATCH v3 6/6] PPC 85xx: Add qemu-ppce500 machine

machine and tries to rely solely on device tree for device enumeration. Signed-off-by: Alexander Graf ag...@suse.de --- v1 - v2: - Write device tree offset directly into global variable - use r4 rather than r2 for that - access fdt directly from in-memory copy - remove unneeded header

[U-Boot] [PATCH v3 2/6] fdt_support: Add helper function to read ranges property

-by: Alexander Graf ag...@suse.de --- common/fdt_support.c | 94 + include/fdt_support.h |2 ++ 2 files changed, 96 insertions(+) diff --git a/common/fdt_support.c b/common/fdt_support.c index 65c68f9..17fa852 100644 --- a/common/fdt_support.c +++ b

[U-Boot] [PATCH v3 4/6] PPC: 85xx: Generalize DDR TLB mapping function

The DDR mapping function really is just a generic virtual - physical mapping function. Generalize it so it can support any virtual starting offset and IO maps just the same. Signed-off-by: Alexander Graf ag...@suse.de --- arch/powerpc/cpu/mpc85xx/tlb.c | 48

[U-Boot] [PATCH v3 1/6] fdt_support: split fdt_getprop_u32_default

We already have a nice helper to give us a property cell value with default fall back from a path. Split that into two helpers - one for the old path based lookup and one to give us a value based on a node offset. Signed-off-by: Alexander Graf ag...@suse.de --- common/fdt_support.c | 38

[U-Boot] [PATCH v3 3/6] PPC: 85xx: Remove IVOR reset

There is no need to set IVORs to anything but their default values, so let's leave them where they are. Suggested-by: Scott Wood scottw...@freescale.com Signed-off-by: Alexander Graf ag...@suse.de --- arch/powerpc/cpu/mpc85xx/cpu_init.c |4 -- arch/powerpc/cpu/mpc85xx/fixed_ivor.S

[U-Boot] [PATCH v3 5/6] PPC 85xx: Add ELF entry point

We want to be able to directly execute the ELF binary without going through the u-boot.bin one. To know where we have to start executing this ELF binary we have to tell the linker where our entry point is. Signed-off-by: Alexander Graf ag...@suse.de --- arch/powerpc/cpu/mpc85xx/u-boot.lds

Re: [U-Boot] [PATCH v3 4/6] PPC: 85xx: Generalize DDR TLB mapping function

On 19.02.2014, at 00:21, Scott Wood scottw...@freescale.com wrote: On Tue, 2014-02-11 at 01:10 +0100, Alexander Graf wrote: -if (memsize) -print_size(memsize, left unmapped\n); +if (size) +print_size(size, left unmapped\n); +} The print_size should move

Re: [U-Boot] [PATCH v3 6/6] PPC 85xx: Add qemu-ppce500 machine

On 19.02.2014, at 01:03, Scott Wood scottw...@freescale.com wrote: On Tue, 2014-02-11 at 01:10 +0100, Alexander Graf wrote: diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S index bb0025c..8982c78 100644 --- a/arch/powerpc/cpu/mpc85xx/start.S +++ b/arch

[U-Boot] [PATCH v4 6/6] PPC 85xx: Add qemu-ppce500 machine

machine and tries to rely solely on device tree for device enumeration. Signed-off-by: Alexander Graf ag...@suse.de --- v1 - v2: - Write device tree offset directly into global variable - use r4 rather than r2 for that - access fdt directly from in-memory copy - remove unneeded header

[U-Boot] [PATCH v4 3/6] PPC: 85xx: Remove IVOR reset

There is no need to set IVORs to anything but their default values, so let's leave them where they are. Suggested-by: Scott Wood scottw...@freescale.com Signed-off-by: Alexander Graf ag...@suse.de --- arch/powerpc/cpu/mpc85xx/cpu_init.c |4 -- arch/powerpc/cpu/mpc85xx/fixed_ivor.S

[U-Boot] [PATCH v4 0/6] PPC 85xx: Add support for QEMU's ppce500 PV machine

map - search for PCI based on device type rather than compatible - remove unnecessary cast - call get_linear_ram_size directly - override get_tbclk with timebase-frequency fetching code Alexander Graf (6): fdt_support: split fdt_getprop_u32_default fdt_support: Add helper function

[U-Boot] [PATCH v4 2/6] fdt_support: Add helper function to read ranges property

-by: Alexander Graf ag...@suse.de --- common/fdt_support.c | 94 + include/fdt_support.h |2 ++ 2 files changed, 96 insertions(+) diff --git a/common/fdt_support.c b/common/fdt_support.c index 65c68f9..17fa852 100644 --- a/common/fdt_support.c +++ b

[U-Boot] [PATCH v4 5/6] PPC 85xx: Add ELF entry point

We want to be able to directly execute the ELF binary without going through the u-boot.bin one. To know where we have to start executing this ELF binary we have to tell the linker where our entry point is. Signed-off-by: Alexander Graf ag...@suse.de --- arch/powerpc/cpu/mpc85xx/u-boot.lds

[U-Boot] [PATCH v4 4/6] PPC: 85xx: Generalize DDR TLB mapping function

The DDR mapping function really is just a generic virtual - physical mapping function. Generalize it so it can support any virtual starting offset and IO maps just the same. Signed-off-by: Alexander Graf ag...@suse.de --- v3 - v4: - change tlb_map to return unmapped size and get ram/io

[U-Boot] [PATCH v4 1/6] fdt_support: split fdt_getprop_u32_default

We already have a nice helper to give us a property cell value with default fall back from a path. Split that into two helpers - one for the old path based lookup and one to give us a value based on a node offset. Signed-off-by: Alexander Graf ag...@suse.de --- common/fdt_support.c | 38

Re: [U-Boot] [ppc] qemu-ppce500 howto

On 22.05.14 09:52, Alon Bar-Lev wrote: Hi, Trying to run the qemu-ppce500 within qemu. I am using -bios u-boot.bin and no luck, I get live signal. I am using latest u-boot master and qemu master. Command: $ ./qemu-system-ppc -M ppce500 -nographic -bios u-boot.bin Tried to load u-boot as

Re: [U-Boot] [ppc] qemu-ppce500 howto

On 24.05.14 09:23, Alon Bar-Lev wrote: On Thu, May 22, 2014 at 12:04 PM, Alexander Graf ag...@suse.de wrote: On 22.05.14 09:52, Alon Bar-Lev wrote: Hi, Trying to run the qemu-ppce500 within qemu. I am using -bios u-boot.bin and no luck, I get live signal. I am using latest u-boot master

Re: [U-Boot] [ppc] qemu-ppce500 howto

On 25.05.2014, at 13:10, Alon Bar-Lev alon.bar...@gmail.com wrote: On Sun, May 25, 2014 at 1:08 PM, Alexander Graf ag...@suse.de wrote: On 24.05.14 09:23, Alon Bar-Lev wrote: On Thu, May 22, 2014 at 12:04 PM, Alexander Graf ag...@suse.de wrote: On 22.05.14 09:52, Alon Bar-Lev wrote

Re: [U-Boot] [ppc] qemu-ppce500 howto

On 25.05.2014, at 13:33, Alon Bar-Lev alon.bar...@gmail.com wrote: On Sun, May 25, 2014 at 2:16 PM, Alexander Graf ag...@suse.de wrote: On 25.05.2014, at 13:10, Alon Bar-Lev alon.bar...@gmail.com wrote: On Sun, May 25, 2014 at 1:08 PM, Alexander Graf ag...@suse.de wrote: On 24.05.14

[U-Boot] [PATCH 3/3] PPC 85xx: Add qemu-ppce500 machine

ppce500 machine as it is implemented today. Signed-off-by: Alexander Graf ag...@suse.de --- arch/powerpc/cpu/mpc85xx/start.S|7 + arch/powerpc/include/asm/config_mpc85xx.h |4 + board/freescale/qemu-ppce500/Makefile | 10 ++ board/freescale/qemu-ppce500/qemu-ppce500.c

[U-Boot] [PATCH 0/3] PPC 85xx: Add support for QEMU's ppce500 PV machine

. This patch set implements support for this PV machine type in U-Boot, enabling users to run their virtual machines with netboot, u-boot payload binaries or other fun things they come up with. Alexander Graf (3): PPC 85xx: Detect e500v2 / e500mc during runtime PPC 85xx: Add ELF entry point PPC

[U-Boot] [PATCH 2/3] PPC 85xx: Add ELF entry point

We want to be able to directly execute the ELF binary without going through the u-boot.bin one. To know where we have to start executing this ELF binary we have to tell the linker where our entry point is. Signed-off-by: Alexander Graf ag...@suse.de --- arch/powerpc/cpu/mpc85xx/u-boot.lds

[U-Boot] [PATCH 1/3] PPC 85xx: Detect e500v2 / e500mc during runtime

With the qemu-ppce500 machine type we can run the same board with either an e500v2 or an e500mc core plugged in. This means that the IVOR setup can't be based on compile time decisions, so instead we have to do a runtime check which CPU generation we're running on. Signed-off-by: Alexander Graf

Re: [U-Boot] [PATCH v4 6/6] PPC 85xx: Add qemu-ppce500 machine

On 19.03.14 19:49, York Sun wrote: On 02/20/2014 07:59 AM, Scott Wood wrote: On Thu, 2014-02-20 at 13:52 +0100, Alexander Graf wrote: diff --git a/arch/powerpc/cpu/mpc85xx/cpu.c b/arch/powerpc/cpu/mpc85xx/cpu.c index 3e99b07..51f2085 100644 --- a/arch/powerpc/cpu/mpc85xx/cpu.c +++ b/arch

[U-Boot] [PATCH 4/6] PPC: 85xx: Generalize DDR TLB mapping function

The DDR mapping function really is just a generic virtual - physical mapping function. Generalize it so it can support any virtual starting offset and IO maps just the same. Signed-off-by: Alexander Graf ag...@suse.de --- v3 - v4: - change tlb_map to return unmapped size and get ram/io

[U-Boot] [PATCH 6/6] PPC 85xx: Add qemu-ppce500 machine

machine and tries to rely solely on device tree for device enumeration. Signed-off-by: Alexander Graf ag...@suse.de --- v1 - v2: - Write device tree offset directly into global variable - use r4 rather than r2 for that - access fdt directly from in-memory copy - remove unneeded header

[U-Boot] [PATCH v5 0/6] PPC 85xx: Add support for QEMU's ppce500 PV machine

on the cmdline - use __weak instead of __attribute__((weak)) - use esel parameter in map_fdt_as() - explicitly define start and end of PCI map range Alexander Graf (6): fdt_support: split fdt_getprop_u32_default fdt_support: Add helper function to read ranges property PPC: 85xx: Remove

[U-Boot] [PATCH 2/6] fdt_support: Add helper function to read ranges property

-by: Alexander Graf ag...@suse.de --- common/fdt_support.c | 94 + include/fdt_support.h |2 ++ 2 files changed, 96 insertions(+) diff --git a/common/fdt_support.c b/common/fdt_support.c index cc0bf76..fcd2523 100644 --- a/common/fdt_support.c +++ b

[U-Boot] [PATCH 1/6] fdt_support: split fdt_getprop_u32_default

We already have a nice helper to give us a property cell value with default fall back from a path. Split that into two helpers - one for the old path based lookup and one to give us a value based on a node offset. Signed-off-by: Alexander Graf ag...@suse.de --- common/fdt_support.c | 38

[U-Boot] [PATCH 5/6] PPC 85xx: Add ELF entry point

We want to be able to directly execute the ELF binary without going through the u-boot.bin one. To know where we have to start executing this ELF binary we have to tell the linker where our entry point is. Signed-off-by: Alexander Graf ag...@suse.de --- arch/powerpc/cpu/mpc85xx/u-boot.lds

[U-Boot] [PATCH 3/6] PPC: 85xx: Remove IVOR reset

There is no need to set IVORs to anything but their default values, so let's leave them where they are. Suggested-by: Scott Wood scottw...@freescale.com Signed-off-by: Alexander Graf ag...@suse.de --- arch/powerpc/cpu/mpc85xx/cpu_init.c |4 -- arch/powerpc/cpu/mpc85xx/fixed_ivor.S

Re: [U-Boot] [PATCH 3/6] PPC: 85xx: Remove IVOR reset

Am 17.04.2014 um 02:46 schrieb York Sun york...@freescale.com: On 04/11/2014 08:09 AM, Alexander Graf wrote: diff --git a/nand_spl/board/freescale/mpc8572ds/Makefile b/nand_spl/board/freescale/mpc8572ds/Makefile index c639b12..c58b7a4 100644 --- a/nand_spl/board/freescale/mpc8572ds

Re: [U-Boot] [PATCH v4 6/6] PPC 85xx: Add qemu-ppce500 machine

Am 28.04.2014 um 20:40 schrieb York Sun york...@freescale.com: On 02/20/2014 04:52 AM, Alexander Graf wrote: For KVM we have a special PV machine type called ppce500. This machine is inspired by the MPC8544DS board, but implements a lot less features than that one. It also provides

Re: [U-Boot] [PATCH 1/4] powerpc/mpc85xx: Ignore FDT pointer for non-QEMU in cpu_init_early_f()

: Alexander Graf ag...@suse.de Acked-by: Alexander Graf ag...@suse.de Alex ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 0/5] PPC 85xx QEMU: Additional fixes

also no longer get warnings that I should convert the board to the generic board mechanism. Alex Alexander Graf (5): PPC 85xx QEMU: Always assume 1 core PPC 85xx QEMU: Don't use HID1 powerpc/mpc85xx: Update TLB CAMs in relocated mode powerpc/mpc85xx: Pass 0 flags to board_init_f PPC

[U-Boot] [PATCH 3/5] powerpc/mpc85xx: Update TLB CAMs in relocated mode

We want to use the TLB mapping helpers in relocated mode as well. These helpers need to have awareness of already occupied TLB entries. We already had them in sync in non-relocated mode, but need to resync them when we move into relocated. Signed-off-by: Alexander Graf ag...@suse.de --- arch

[U-Boot] [PATCH 2/5] PPC 85xx QEMU: Don't use HID1

For the QEMU machine type, we can plug in either e500v2, e500mc, e5500 or e6500 style cores into the system. U-boot has to work with all of them. So avoid using HID1 which is not available on e500mc systems to make sure we don't trap on it. Signed-off-by: Alexander Graf ag...@suse.de --- arch

[U-Boot] [PATCH 5/5] PPC 85xx QEMU: Make a generic board file

This patch enables the E500 QEMU board to use the generic cross-arch board infrastructure. Signed-off-by: Alexander Graf ag...@suse.de --- include/configs/qemu-ppce500.h |1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/qemu-ppce500.h b/include/configs/qemu-ppce500.h index

[U-Boot] [PATCH 1/5] PPC 85xx QEMU: Always assume 1 core

would have to rip CPUs out of already existing spin tables and respin them from u-boot. It would be a pretty big mess. So only assume we have a single core. This fixes errors about CONFIG_MP being disabled. Signed-off-by: Alexander Graf ag...@suse.de --- arch/powerpc/cpu/mpc8xxx/cpu.c

[U-Boot] [PATCH 4/5] powerpc/mpc85xx: Pass 0 flags to board_init_f

The new generic board_init_f has an argument now that takes a number of prepopulated gd-flags bits. We don't have any, so let's set this to 0. Signed-off-by: Alexander Graf ag...@suse.de --- arch/powerpc/cpu/mpc85xx/start.S |1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/cpu

Re: [U-Boot] [PATCH 4/5] powerpc/mpc85xx: Pass 0 flags to board_init_f

On 30.04.14 19:28, York Sun wrote: On 04/30/2014 10:21 AM, Alexander Graf wrote: The new generic board_init_f has an argument now that takes a number of prepopulated gd-flags bits. We don't have any, so let's set this to 0. Signed-off-by: Alexander Graf ag...@suse.de --- arch/powerpc/cpu

[U-Boot] [PATCH] qemu-ppce500: Add support for 64bit CCSR map

it. Plus we forgot to support 64bit physical addresses. This patch fixes that mishap, making u-boot work fine with latest QEMU again. Signed-off-by: Alexander Graf ag...@suse.de --- include/configs/qemu-ppce500.h |8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/include

[U-Boot] [PATCH] qemu-ppce500: Align code at 64k boundary

The QEMU u-boot located itself at a 4k aligned offset which the rest of the code didn't really expect. Align it with 64k to allow the memory code to deal with 64k granularity. This fixes broken interrupt delivery with the ppce500 machine for me. Signed-off-by: Alexander Graf ag...@suse.de

Re: [U-Boot] [PATCH 0/9] EFI payload / application support

On 04.01.16 23:37, Dennis Gilmore wrote: > On Monday, January 04, 2016 02:54:40 PM Tom Rini wrote: >> On Mon, Jan 04, 2016 at 07:41:42PM +0100, Andreas Färber wrote: >>> Am 04.01.2016 um 19:03 schrieb Andreas Färber: Am 04.01.2016 um 17:56 schrieb Tom Rini: > Please note that with the

Re: [U-Boot] [PATCH 0/9] EFI payload / application support

On 26.12.15 20:34, Leif Lindholm wrote: > On Sat, Dec 26, 2015 at 05:27:48PM +0100, Alexander Graf wrote: >>>> This patch set is the result of pursuing this endeavor. >>> >>> Thanks, this is a very cool thing. >>> I meant to reply sooner, but C

Re: [U-Boot] [PATCH 4/9] efi_loader: Add boot time services

On 22.12.15 15:15, Andreas Färber wrote: > Am 22.12.2015 um 14:57 schrieb Alexander Graf: >> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c >> new file mode 100644 >> index 000..ed95962 >> --- /dev/null >> ++

Re: [U-Boot] [PATCH 0/9] EFI payload / application support

On 22.12.15 19:28, Matwey V. Kornilov wrote: > 2015-12-22 16:57 GMT+03:00 Alexander Graf <ag...@suse.de>: >> This is my Christmas present for my openSUSE friends :). >> > > Santa, do you have u-boot rpm packed with the patches to test? Once OBS has finished compilin

Re: [U-Boot] [PATCH 8/9] efi_loader: Add "bootefi" command

On 24.12.15 12:15, Matwey V. Kornilov wrote: > Why just not to implement standard EFI behaviour when EFI looks for > boot-efi partition and proceed? Well, what is "standard EFI behavior"? There are 2 standard ways I'm aware of: 1) NVRAM The default case for 99.9% of the boots on normal EFI

Re: [U-Boot] [PATCH 0/9] EFI payload / application support

On 25.12.15 04:29, Tom Rini wrote: > On Tue, Dec 22, 2015 at 02:57:47PM +0100, Alexander Graf wrote: > >> This is my Christmas present for my openSUSE friends :). >> >> U-Boot is a great project for embedded devices. However, convincing >> everyone involved th

Re: [U-Boot] [PATCH 0/9] EFI payload / application support

On 26.12.15 16:31, Leif Lindholm wrote: > On Tue, Dec 22, 2015 at 02:57:47PM +0100, Alexander Graf wrote: >> This is my Christmas present for my openSUSE friends :). >> >> U-Boot is a great project for embedded devices. However, convincing >> everyone involved that

Re: [U-Boot] [PATCH 8/9] efi_loader: Add "bootefi" command

On 26.12.15 19:55, Leif Lindholm wrote: > On Fri, Dec 25, 2015 at 10:25:22AM +0100, Andreas Färber wrote: >> Am 25.12.2015 um 10:02 schrieb Alexander Graf: >> [snip] >>> The reason I implemented "bootefi" was really because it's the natural >>> fit into

Re: [U-Boot] [PATCH] qemu-ppce500: pass 'range_id' around in pci_map_region

On 21.12.15 10:19, Miao Yan wrote: > In pci_map_region(), pass 'range_id' to fdt_read_range(), > otherwise the same address will be mapped again in other > calls to pci_map_region() > > Signed-off-by: Miao Yan <yammiaob...@gmail.com> Oops :). Reviewed-by: Alexander Graf &

[U-Boot] [PATCH 7/9] efi_loader: Add disk interfaces

-Boot's read and write functions. Signed-off-by: Alexander Graf <ag...@suse.de> --- include/efi_loader.h | 1 + lib/efi_loader/efi_disk.c | 227 ++ 2 files changed, 228 insertions(+) create mode 100644 lib/efi_loader/efi_disk.c diff --git a/i

[U-Boot] [PATCH 3/9] efi_loader: Add PE image loader

EFI uses the PE binary format for its application images. Add support to EFI PE binaries as well as all necessary bits for the "EFI image loader" interfaces. Signed-off-by: Alexander Graf <ag...@suse.de> --- include/efi_loader.h | 37 + include/pe.h

[U-Boot] [PATCH 6/9] efi_loader: Add runtime services

ust create an extremely minimal RTS stub that just declares all functions as unsupported. We could in the future map U-boot environment variables to EFI variables here. Signed-off-by: Alexander Graf <ag...@suse.de> --- arch/arm/cpu/armv8/u-boot.lds | 8 ++ arch/arm/cpu/u-boot.lds | 13

[U-Boot] [PATCH 5/9] efi_loader: Add console interface

, hoping that everyone managed to jump on the train by now. Signed-off-by: Alexander Graf <ag...@suse.de> --- include/efi_loader.h | 5 + lib/efi_loader/efi_console.c | 371 +++ 2 files changed, 376 insertions(+) create mode 100644 lib/efi_

[U-Boot] [PATCH 9/9] efi_loader: hook up in build environment

Now that we have all the bits and pieces ready for EFI payload loading support, hook them up in Makefiles and KConfigs so that we can build. Signed-off-by: Alexander Graf <ag...@suse.de> --- lib/Kconfig | 1 + lib/Makefile| 1 + lib/efi_loader/Kconfig

[U-Boot] [PATCH 4/9] efi_loader: Add boot time services

r the boot time services and also exposes a system table, which is the point of entry descriptor table for EFI payloads. Signed-off-by: Alexander Graf <ag...@suse.de> --- include/efi_loader.h | 41 +++ lib/efi_loader/efi_boottime.c | 838 ++ 2 fi

[U-Boot] [PATCH 2/9] include/efi_api.h: Add more detailed API definitions

The EFI API header is great, but missing a good chunk of function prototype, GUID defines and enum declarations. This patch extends it to cover more of the EFI API. It's still not 100% complete, but sufficient enough for our EFI payload interface. Signed-off-by: Alexander Graf <ag...@suse

[U-Boot] [PATCH 0/9] EFI payload / application support

arguments against U-Boot internally and give users the chance to run with the same level of comfort on all firmware types. Alex Alexander Graf (9): disk/part.c: Expose a list of available block drivers include/efi_api.h: Add more detailed API definitions efi_loader: Add PE image loader efi_l

[U-Boot] [PATCH 1/9] disk/part.c: Expose a list of available block drivers

-by: Alexander Graf <ag...@suse.de> --- disk/part.c| 25 + include/part.h | 2 ++ 2 files changed, 27 insertions(+) diff --git a/disk/part.c b/disk/part.c index 909712e..5bc64c7 100644 --- a/disk/part.c +++ b/disk/part.c @@ -26,6 +26,31 @@ struct block_drvr {

[U-Boot] [PATCH 8/9] efi_loader: Add "bootefi" command

and then have a simple boot command to execute them. So in our case, you would do # load mmc 0:1 $loadaddr grub.efi # bootefi $loadaddr which then gets you into a grub shell. Fdt information known to U-boot via the fdt addr command is also passed to the EFI payload. Signed-off-by: Alexander Graf

[U-Boot] [PATCH] efi_loader: Add DM_VIDEO support

Some systems are starting to shift to support DM_VIDEO which exposes the frame buffer through a slightly different interface. This is a poor man's effort to support the dm video interface instead of the lcd one. We still only support a single display device. Signed-off-by: Alexander Graf <

Re: [U-Boot] [PATCH] libfdt: Add option to disable arch_fixup_fdt() calls

On 06/09/2016 04:23 PM, Michal Simek wrote: Disable arch_fixup_fdt() calls for cases where U-Boot shouldn't update memory setup in DTB file. One example of usage of this option is to boot OS with different memory setup than U-Boot use. Signed-off-by: Michal Simek

Re: [U-Boot] [PATCH] libfdt: Add option to disable arch_fixup_fdt() calls

On 06/09/2016 04:32 PM, Michal Simek wrote: On 9.6.2016 16:29, Alexander Graf wrote: On 06/09/2016 04:23 PM, Michal Simek wrote: Disable arch_fixup_fdt() calls for cases where U-Boot shouldn't update memory setup in DTB file. One example of usage of this option is to boot OS with different

Re: [U-Boot] [PATCH v4 1/2] armv8: Support loading 32-bit OS in AArch32 execution state

On 06/08/2016 07:14 AM, Alison Wang wrote: To support loading a 32-bit OS, the execution state will change from AArch64 to AArch32 when jumping to kernel. The architecture information will be got through checking FIT image, then U-Boot will load 32-bit OS or 64-bit OS automatically.

Re: [U-Boot] [PATCH] libfdt: Add option to disable arch_fixup_fdt() calls

On 10.06.16 14:31, Michal Simek wrote: > On 10.6.2016 14:12, Alexander Graf wrote: >> >> >> On 10.06.16 13:51, Michal Simek wrote: >>> On 10.6.2016 13:13, Alexander Graf wrote: >>>> >>>> >>>> On 10.06.16 13:07, Michal Simek wro

Re: [U-Boot] [PATCH] libfdt: Add option to disable arch_fixup_fdt() calls

On 10.06.16 13:07, Michal Simek wrote: > On 9.6.2016 16:40, Alexander Graf wrote: >> On 06/09/2016 04:32 PM, Michal Simek wrote: >>> On 9.6.2016 16:29, Alexander Graf wrote: >>>> On 06/09/2016 04:23 PM, Michal Simek wrote: >>>>> Disable arch_fixup

Re: [U-Boot] [PATCH v3 1/2] armv8: Support loading 32-bit OS in AArch32 execution state

On 03.06.16 05:11, Huan Wang wrote: >> On 26.05.16 10:41, Alison Wang wrote: >>> To support loading a 32-bit OS, the execution state will change from >>> AArch64 to AArch32 when jumping to kernel. >>> >>> The architecture information will be got through checking FIT image, >>> then U-Boot will

Re: [U-Boot] [PATCH v3 1/2] armv8: Support loading 32-bit OS in AArch32 execution state

Am 03.06.2016 um 11:31 schrieb Huan Wang : >> On 03.06.16 05:11, Huan Wang wrote: On 26.05.16 10:41, Alison Wang wrote: > To support loading a 32-bit OS, the execution state will change from > AArch64 to AArch32 when jumping to kernel. > > The

Re: [U-Boot] [PATCH] libfdt: Add option to disable arch_fixup_fdt() calls

On 10.06.16 13:51, Michal Simek wrote: > On 10.6.2016 13:13, Alexander Graf wrote: >> >> >> On 10.06.16 13:07, Michal Simek wrote: >>> On 9.6.2016 16:40, Alexander Graf wrote: >>>> On 06/09/2016 04:32 PM, Michal Simek wrote: >>>>> On 9.6.

Re: [U-Boot] [PATCH v4 1/2] armv8: Support loading 32-bit OS in AArch32 execution state

> Am 15.06.2016 um 05:04 schrieb Huan Wang : > > Hi, Alex, > >>> On 06/08/2016 07:14 AM, Alison Wang wrote: >>> To support loading a 32-bit OS, the execution state will change from >>> AArch64 to AArch32 when jumping to kernel. >>> >>> The architecture information will be

Re: [U-Boot] [PATCH v4 1/2] armv8: Support loading 32-bit OS in AArch32 execution state

> Am 15.06.2016 um 05:04 schrieb Huan Wang : > > Hi, Alex, > >>> On 06/08/2016 07:14 AM, Alison Wang wrote: >>> To support loading a 32-bit OS, the execution state will change from >>> AArch64 to AArch32 when jumping to kernel. >>> >>> The architecture information will be

  1   2   3   4   5   6   7   8   9   10   >