On Sat, 2017-01-14 at 02:06 +, Andre Przywara wrote:
> Newer OrangePi Zero boards all come with 16 Mib SPI flash soldered,
> from
> which the board can actually boot from.
> Enable the SPL support for the SPI controller and SPI flash to allow
> putting the SPL, the DT and U-Boot proper into the
+Simon,
On Fri, Jan 13, 2017 at 4:12 AM, Joakim Tjernlund
wrote:
> I found two repos w.r.t x86_64 for u-boot, which one should I use?
>
U-Boot x86_64 support is not in mainstream yet.
> I am ATM only looking at USING the qemu-x86 target for now.
>
> BTW, I found tools/binman/binman.py only work
Hi Joakim,
On Sat, Jan 14, 2017 at 9:25 PM, Joakim Tjernlund
wrote:
> On Sat, 2017-01-14 at 19:51 +0800, Bin Meng wrote:
>> +Simon,
>>
>> On Fri, Jan 13, 2017 at 4:12 AM, Joakim Tjernlund
>> wrote:
>> > I found two repos w.r.t x86_64 for u-boot, which one should I use?
>> >
>>
>> U-Boot x86_64 s
On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass wrote:
> Addresses should not be cast to size_t. Use uintptr_t instead.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2: None
>
> arch/x86/lib/relocate.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Reviewed-by: Bin Meng
On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass wrote:
> Much of the cpu and interrupt code cannot be compiled on 64-bit x86. Move it
> into its own directory and build it only in 32-bit mode.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2: None
>
> arch/x86/cpu/Makefile
On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass wrote:
> Add a 64-bit relocation function. SPL loads U-Boot into RAM at a fixed
> address and runs it. U-Boot then relocates itself to the top of RAM using
> this relocation function.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2: None
>
> ar
Hi Simon,
On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass wrote:
> SPL needs to set up the machine ready for loading 64-bit U-Boot and jumping
> to it. Call the existing init routines in order to accomplish this.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2: None
>
> arch/x86/include/asm
Hi Simon,
On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass wrote:
> There is not much needed at present, but set up a separate directory to put
> this code as it grows.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2: None
>
> arch/x86/cpu/Makefile| 4 +++-
> arch/x86/cpu/x86_64
Hi Simon,
On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass wrote:
> At present this is just an ordinary variable. We may consider making it a
> fixed register in the future.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2: None
>
> arch/x86/cpu/x86_64/cpu.c | 13 +
> arc
On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass wrote:
> When SPL is used we need to build the 16-bit start-up code. Add Makefile
> rules to handle this.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2: None
>
> scripts/Makefile.spl | 9 -
> 1 file changed, 8 insertions(+), 1 deletio
On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass wrote:
> When SPL and U-Boot proper have different settings for this flag, we need to
> use the correct one. Fix this up in the interrupt code.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2: None
>
> arch/x86/cpu/i386/interrupt.c | 2 +-
> 1
On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass wrote:
> If SPL is used it is always build in 32-bit mode. Add a link script to
> handle the correct placement of the sections.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2: None
>
> arch/x86/cpu/u-boot-spl.lds | 74
> ++
On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass wrote:
> This needs a different image format from 32-bit x86, so add a new link
> script.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2: None
>
> arch/x86/cpu/config.mk | 6
> arch/x86/cpu/u-boot-64.lds | 76
> +
On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass wrote:
> Remove the very old x86 code and add support for 64-bit.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2: None
>
> arch/x86/include/asm/byteorder.h | 17 +
> 1 file changed, 9 insertions(+), 8 deletions(-)
>
Reviewed-b
Hi Simon,
On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass wrote:
> Adjust types as needed to support 64-bit compilation.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2: None
>
> arch/x86/include/asm/posix_types.h | 5 +
> arch/x86/include/asm/types.h | 5 +
> 2 files changed,
Hi Simon,
On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass wrote:
> We don't support SDRAM init in 64-bit mode since it is essentially
> impossible to get into that mode before SDRAM set up. Provide dummy functions
> for now. At some point we will need to pass the SDRAM parameters through from
> SPL.
Hi Simon,
On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass wrote:
> This doesn't work at present. Disable it for now.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2: None
>
> arch/x86/cpu/ivybridge/Makefile | 2 ++
> 1 file changed, 2 insertions(+)
Except the commit title typo: Skipt -> Sk
Hi Simon,
On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass wrote:
> This is left out of the example memory map. Add it to avoid confusion.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2: None
>
> doc/README.x86 | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/doc/README.x86 b/doc/RE
On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass wrote:
> This is not supported, so disable it for now.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2: None
>
> arch/x86/lib/Makefile | 2 ++
> drivers/pci/pci_rom.c | 2 +-
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
Reviewed-by: Bin
On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass wrote:
> This doesn't build at present and is not used in a 64-bit build. Disable it
> for now.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2: None
>
> arch/x86/include/asm/cpu.h | 3 +++
> 1 file changed, 3 insertions(+)
>
Reviewed-by: Bin
On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass wrote:
> These cannot be built in this mode, so drop them.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2: None
>
> arch/x86/lib/Makefile | 4
> 1 file changed, 4 insertions(+)
>
Reviewed-by: Bin Meng
___
Hi Simon,
On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass wrote:
> These are currently not supported. Calling 64-bit code from 64-bit U-Boot is
> much simpler, so this code is not needed. setjmp() is not yet implemented for
> 64-bit.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2: None
>
>
On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass wrote:
> Booting into linux from 64-bit U-Boot is not yet supported. Avoid bringing
> in the bootm code until it is implemented.
>
> Of course 32-bit U-Boot still supported booting into both 32- and 64-bit
> kernels.
>
> Signed-off-by: Simon Glass
> --
On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass wrote:
> Some files cannot be built with 64-bit and mostly don't make sense in that
> context. Disable them.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2: None
>
> arch/x86/cpu/Makefile | 9 -
> 1 file changed, 8 insertions(+), 1 del
On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass wrote:
> This is not currently supported, so drop the code.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2: None
>
> arch/x86/lib/interrupts.c | 5 +
> 1 file changed, 5 insertions(+)
>
Reviewed-by: Bin Meng
_
Hi Simon,
On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass wrote:
> To avoid using BSS in SPL before SDRAM is set up, move this field to
> global_data.
>
Why is this needed? pirq routing table setup is done after SDRAM
initialization. Isn't SPL doing this with a different order?
> Signed-off-by: Si
On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass wrote:
> Add a rough function to handle jumping from 32-bit SPL to 64-bit U-Boot.
> This still needs work to clean it up.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2: None
>
> arch/x86/cpu/call64.S | 3 +++
> arch/x86/cpu/i386/cpu.c
On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass wrote:
> This avoids using BSS before SDRAM is set up in SPL.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2: None
>
> arch/x86/lib/pirq_routing.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
Reviewed-by: Bin Meng
___
On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass wrote:
> This code is only used in 32-bit mode. Move it so that it does not get
> built with 64-bit U-Boot.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2: None
>
> arch/x86/cpu/Makefile| 3 ---
> arch/x86/cpu/i386/Makefile |
On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass wrote:
> Set up the 64-bit U-Boot text base if building for that target.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2: None
>
> board/google/chromebook_link/Kconfig | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
Reviewed-by: Bi
On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass wrote:
> We don't have the code for this yet. Add a dummy version for now, so that
> EFI builds correctly.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2:
> - Add the 'val' parameter to longjmp()
>
> arch/x86/cpu/x86_64/Makefile | 2 +-
> arc
On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass wrote:
> When building for 64-bit we need to put an SPL binary into the image. Update
> the binman image description to reflect this.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2: None
>
> arch/x86/dts/u-boot.dtsi | 19 +++
>
On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass wrote:
> This code is only used in 32-bit mode. Move it so that it does not get
> built with 64-bit U-Boot.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2: None
>
> arch/x86/cpu/Makefile| 2 +-
> arch/x86/cpu/i386/Makefile |
On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass wrote:
> Update config.mk settings to support both 32-bit and 64-bit U-Boot.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2: None
>
> arch/x86/config.mk | 30 --
> arch/x86/cpu/config.mk | 2 --
> 2 files chang
Hi Simon,
On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass wrote:
> Add a new link config which uses 64-bit U-Boot. This is not fully
> functional but is it a start. Missing features:
>
> - SDRAM sizing
> - Booting linux
> - EFI support
> - SCSI device init
> (and others)
>
> Signed-off-by: Simon Gla
Hi Simon,
On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass wrote:
> If SPL is used we want to use the generic SPL framework and boot from SPI
> via a board-specific means. Add these options to the board config file.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2: None
>
> configs/chromebook
On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass wrote:
> Add the correct pre-relocation tag so that the required device tree nodes
> are present in the SPL device tree.
>
> On x86 it doesn't make a lot of sense to have a separate SPL device tree.
> Since everything is in the same ROM we might as well
On Wed, 11 Jan 2017 22:08:03 -0700
Simon Glass wrote:
> Hi Emmanuel,
>
> On 28 December 2016 at 03:57, Emmanuel Vadot wrote:
> > On Wed, 28 Dec 2016 11:30:10 +0100
> > Emmanuel Vadot wrote:
> >
> >>
> >> Hello Simon,
> >>
> >> On Fri, 23 Dec 2016 01:39:06 -0700
> >> Simon Glass wrote:
> >>
>
On Sat, 2017-01-14 at 19:51 +0800, Bin Meng wrote:
> +Simon,
>
> On Fri, Jan 13, 2017 at 4:12 AM, Joakim Tjernlund
> wrote:
> > I found two repos w.r.t x86_64 for u-boot, which one should I use?
> >
>
> U-Boot x86_64 support is not in mainstream yet.
So I should use u-boot-x86.git for now then
Can you simultaneously use both Ethernet interfaces on the A64? I've
received conflicting answers to this question.
On Fri, Jan 13, 2017 at 9:06 PM, Andre Przywara wrote:
> The OrangePi Zero can happily use the EMAC along with its integrated
> PHY to use Ethernet (for TFTP booting, for instance).
On Sat, Jan 14, 2017 at 02:38:02PM +0100, Emmanuel Vadot wrote:
> On Wed, 11 Jan 2017 22:08:03 -0700
> Simon Glass wrote:
>
> > Hi Emmanuel,
> >
> > On 28 December 2016 at 03:57, Emmanuel Vadot wrote:
> > > On Wed, 28 Dec 2016 11:30:10 +0100
> > > Emmanuel Vadot wrote:
> > >
> > >>
> > >> Hel
Hi Joakim,
On 14 January 2017 at 04:51, Bin Meng wrote:
> +Simon,
>
> On Fri, Jan 13, 2017 at 4:12 AM, Joakim Tjernlund
> wrote:
>> I found two repos w.r.t x86_64 for u-boot, which one should I use?
>>
>
> U-Boot x86_64 support is not in mainstream yet.
I'll be sending v3 fairly soon. But even
Hi Rick,
On 3 January 2017 at 11:21, Rick Bronson wrote:
> Hi Simon,
>
> I'm not sure what to do about (in drivers/power/regulator/rk808.c):
>
> static const struct rk808_reg_info rk808_ldo[] = {
> { 100, 10, LDO1_ON_VSEL, 5, },
> ...
>
> I had to change this table as my LDO v
On 4 January 2017 at 05:45, Heinrich Schuchardt wrote:
> IEC 8-13:2008 Quantities and units
> Part 13: Information science and technology
>
> defines the prefixes to use for binary multiples.
>
> Instead of writing
> Data Size:6726132 Bytes = 6568.49 kB = 6.41 MB
> in dumpimage we should w
On 4 January 2017 at 11:32, York Sun wrote:
> Without a prompt in Kconfig, SECURE_BOOT cannot be selected by
> defconfig. The option was dropped unintentionally when defconfig
> files were cleaned up. Three targets were impacted
> ls1043ardb_SECURE_BOOT, ls2080ardb_SECURE_BOOT,
> ls2080aqds_SECURE
On 5 January 2017 at 03:16, Jaehoon Chung wrote:
> Add the i2c_5 node and pmic as its child node.
>
> Signed-off-by: Jaehoon Chung
> ---
> arch/arm/dts/exynos4210-universal_c210.dts | 164
> +
> 1 file changed, 164 insertions(+)
Reviewed-by: Simon Glass
___
On 8 January 2017 at 22:47, Jaehoon Chung wrote:
> Add the i2c_5 node and pmic as its child node.
>
> Signed-off-by: Jaehoon Chung
> ---
> arch/arm/dts/exynos4210-universal_c210.dts | 164
> +
> 1 file changed, 164 insertions(+)
Reviewed-by: Simon Glass
___
Hi Maxim,
On 4 January 2017 at 12:46, Maxim Sloyko wrote:
> Signed-off-by: Maxim Sloyko
> ---
>
> arch/arm/Kconfig | 7 +++
> arch/arm/Makefile | 1 +
> arch/arm/mach-aspeed/Kconfig | 15 +++
> arch/arm/mach-aspeed/Makefile | 8
> 4 files ch
Hi Maxim,
On 4 January 2017 at 12:46, Maxim Sloyko wrote:
> Add support for timer for Aspeed ast2400/ast2500 devices.
> The driver actually controls several devices, but because all devices
> share the same Control Register, it is somewhat difficult to completely
> decouple them. Since only one t
On 4 January 2017 at 12:46, Maxim Sloyko wrote:
> The driver uses watchdog timer to do resets and particular
> watchdog device to use is hardcoded (0)
>
> Signed-off-by: Maxim Sloyko
> ---
>
> drivers/sysreset/Makefile | 1 +
> drivers/sysreset/sysreset_ast.c | 55
> +
Hi Maxim,
On 4 January 2017 at 12:46, Maxim Sloyko wrote:
> The driver is compatible with AST2400 and AST2500 watchdogs.
> There is no uclass for Watchdog yet, so the driver does not follow
> the driver model. It also uses fixed clock, so no clock driver
> is needed.
>
> # Conflicts:
> # ar
Hi Maxim,
On 5 January 2017 at 15:20, Maxim Sloyko wrote:
> On Wed, Jan 4, 2017 at 7:26 PM, Tom Rini wrote:
>> On Wed, Jan 04, 2017 at 05:18:42PM -0800, Maxim Sloyko wrote:
>>> On Wed, Jan 4, 2017 at 12:58 PM, Tom Rini wrote:
>>> > On Wed, Jan 04, 2017 at 11:46:49AM -0800, Maxim Sloyko wrote:
>
Hi Maxim,
On 4 January 2017 at 12:46, Maxim Sloyko wrote:
> Helper function to get access to SCU (System Control Unit) through Clock
> driver. This is similar to rockchip_get_cru function, which was used as
> an example.
>
> It will be used by other drivers to get access to SCU.
>
> Signed-off-by
Hi Maxim,
On 4 January 2017 at 12:46, Maxim Sloyko wrote:
> This driver is ast2500 specific and is not compatible with earlier
ast2500-specific
> versions of this chip. The differences are not that large, but they are
> in somewhat random places, so making it compatible with ast2400 is not
> wo
Hi Maxim,
On 4 January 2017 at 12:46, Maxim Sloyko wrote:
> Signed-off-by: Maxim Sloyko
> ---
>
> include/configs/aspeed-common.h | 84
> +
> 1 file changed, 84 insertions(+)
> create mode 100644 include/configs/aspeed-common.h
>
> diff --git a/include/
Hi Maxim,
On 4 January 2017 at 12:46, Maxim Sloyko wrote:
> Signed-off-by: Maxim Sloyko
> ---
>
> arch/arm/mach-aspeed/Makefile| 2 +-
> arch/arm/mach-aspeed/ast2500-board.c | 74
>
> 2 files changed, 75 insertions(+), 1 deletion(-)
> create mode
Hi Maxim,
On 4 January 2017 at 12:46, Maxim Sloyko wrote:
> The driver is very ast2500 specific and is completely incompatible
ast2500-specific
> with previous versions of the chip.
>
> The memory controller is very poorly documented by Aspeed in the
> datasheet, with any mention of the whole r
On 17 December 2016 at 15:48, Simon Glass wrote:
> On 16 December 2016 at 02:33, Maxime Ripard
> wrote:
>> On Thu, Dec 15, 2016 at 03:03:27PM -0800, Stefan Agner wrote:
>>> From: Stefan Agner
>>>
>>> There are lots of reason why a FDT application might fail, the
>>> error code might give an indi
On 25 December 2016 at 22:24, Simon Glass wrote:
> On 21 December 2016 at 03:58, Stefan Agner wrote:
>> From: David Gibson
>>
>> The fdt_overlay_apply() function purports to support the edge cases where
>> an overlay has no fixups to be applied, or a base tree which has no
>> symbols (the latter
Hi Maxim,
On 4 January 2017 at 12:46, Maxim Sloyko wrote:
> ---
>
Commit message?
> ---
>
> Signed-off-by: Maxim Sloyko
> ---
> arch/arm/mach-aspeed/ast2500/Kconfig | 7 +++
> board/aspeed/evb_ast2500/Kconfig | 12
> board/aspeed/evb_ast2500/Makefile | 1 +
> b
On 4 January 2017 at 12:46, Maxim Sloyko wrote:
> Signed-off-by: Maxim Sloyko
Please add a commit message explaining where it came from.
> ---
>
> arch/arm/dts/Makefile| 2 ++
> arch/arm/dts/ast2500-evb.dts | 23 +++
> 2 files changed, 25 insertions(+)
> create mo
On 12 January 2017 at 19:19, Simon Glass wrote:
> On 9 January 2017 at 08:08, Andreas Färber wrote:
>> On a Raspberry Pi 2 disagreements on cell endianness can be observed:
>>
>> U-Boot> fdt print /soc/gpio@7e20 phandle
>> phandle = <0x000d>
>> U-Boot> fdt get value myvar /soc/gpio@
Hi Tom,
Just a few fixes.
The following changes since commit 70c1e0474a9df2c4493b4e2330cc41d3132b4e90:
Merge git://git.denx.de/u-boot-rockchip (2017-01-12 21:20:51 -0500)
are available in the git repository at:
git://git.denx.de/u-boot-fdt.git
for you to fetch changes up to b05bf6c75d03c9
There is no CONFIG_OF_PLATDATA, only CONFIG_SPL_OF_PLATDATA, so rename
the two references to CONFIG_OF_PLATDATA to CONFIG_SPL_OF_PLATDATA.
Signed-off-by: Tom Rini
---
common/spl/spl.c | 2 +-
drivers/serial/Kconfig | 2 +-
scripts/config_whitelist.txt | 1 -
3 files changed, 2
This is wrong at present, so genboardscfg.py gives the following warnings:
WARNING: no status info for 'chromebook_minnie'
WARNING: no maintainers for 'chromebook_minnie'
Fix it.
Signed-off-by: Simon Glass
---
board/google/veyron/MAINTAINERS | 4 ++--
1 file changed, 2 insertions(+), 2 deleti
2017-01-04 20:08 GMT+09:00 Masahiro Yamada :
> Enable SDMA (Single Operation DMA) for LD11, but not for LD20.
> The SDMA does not work for LD20 boards because they are generally
> equipped with more memory than fits in the 32 bit physical address
> space supported by the SDMA.
>
> Signed-off-by: Ma
2017-01-04 20:08 GMT+09:00 Masahiro Yamada :
> The "cdns,sd4hc" is a fallback of the IP. Add the SoC-specific
> compatible string.
>
> Signed-off-by: Masahiro Yamada
Applied to u-boot-uniphier/master.
--
Best Regards
Masahiro Yamada
___
U-Boot mailin
On Sat, Jan 14, 2017 at 10:14:44AM -0700, Simon Glass wrote:
> Hi Tom,
>
> Just a few fixes.
>
> The following changes since commit 70c1e0474a9df2c4493b4e2330cc41d3132b4e90:
>
> Merge git://git.denx.de/u-boot-rockchip (2017-01-12 21:20:51 -0500)
>
> are available in the git repository at:
>
On Tue, Jan 10, 2017 at 05:22:06PM -0500, Tom Rini wrote:
> The MACH_TYPE for IGEP0032 was never officially used and has been
> removed from upstream, so we must not use it. In order to remove this
> we need to rework the status LED logic.
>
> Cc: Enric Balletbo i Serra
> Signed-off-by: Tom Rin
On Tue, Jan 10, 2017 at 05:22:07PM -0500, Tom Rini wrote:
> Before we can sync with the latest mach-types.h file from the Linux
> Kernel we need to remove some instances of MACH_TYPE_xxx from our
> sources. As these values have been removed from the canonical upstream
> source we should not be us
On Tue, Jan 10, 2017 at 05:22:08PM -0500, Tom Rini wrote:
> This re-syncs the MACH_TYPE_xxx values from the Linux Kernel v4.9
> release. In addition this removes all of the machine_arch_type and
> machine_is_xxx logic that is unused in U-Boot. This removal removes a
> large number of otherwise u
On Sat, Jan 14, 2017 at 12:21:39PM -0500, Tom Rini wrote:
> There is no CONFIG_OF_PLATDATA, only CONFIG_SPL_OF_PLATDATA, so rename
> the two references to CONFIG_OF_PLATDATA to CONFIG_SPL_OF_PLATDATA.
>
> Signed-off-by: Tom Rini
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Descrip
On Tue, Jan 10, 2017 at 05:22:05PM -0500, Tom Rini wrote:
> The MACH_TYPE values for the omap37xx based platforms are no longer
> officially valid, so we must not set and pass them. In order to not
> reference them but still be able to set the default fdtfile based on the
> board detection logic
Hi Tom,
I think this did not get applied yet?
--
Stefan
On 2016-12-22 22:51, Stefan Agner wrote:
> From: Stefan Agner
>
> This converts the following to Kconfig:
> CONFIG_SPL_RAM_DEVICE
>
> Signed-off-by: Stefan Agner
> ---
>
> Changes in v3: None
> Changes in v2: None
>
> common/spl/Kc
On Sat, Jan 14, 2017 at 01:14:42PM -0800, Stefan Agner wrote:
> Hi Tom,
>
> I think this did not get applied yet?
Thanks for the reminder, testing this now.
>
> --
> Stefan
>
> On 2016-12-22 22:51, Stefan Agner wrote:
> > From: Stefan Agner
> >
> > This converts the following to Kconfig:
>
Splitting reset assertion (support_card_reset) and deassertion
(support_card_init) is not adding much value any more. Handle
all the initialization of Support Card in support_card_init(),
then remove support_card_reset().
Also, detect_num_flash_banks() can have a static qualifier.
Signed-off-by:
Merge sbc-admulti.c and sbc-savepin.c into a single file to avoid
code duplication.
Signed-off-by: Masahiro Yamada
---
arch/arm/mach-uniphier/init.h | 27 ++-
arch/arm/mach-uniphier/init/init-ld11.c| 6 +--
arch/arm/mach-uniphier/init/init-ld20.c
Currently, memconf-sld3.c and memconf-pxs2.c duplicate the code.
There are 3 patterns in terms of MEMCONF init:
- DRAM 2 channels: LD4, sLD8, Pro4, Pro5, LD11
- DRAM 3 channels: sLD3
- DRAM 3 channels (Ch2 is disable by MEMCONF[21]): Pxs2, LD20
All of them can be moved into a single file by
The code here is cluttered due to the switch statement. Introduce a
table of callbacks to clean up the initialization code across SoCs.
Signed-off-by: Masahiro Yamada
---
arch/arm/mach-uniphier/board_init.c | 219 +++-
1 file changed, 140 insertions(+), 79 delet
At first, we thought the LD20 PLL setting would be board dependent,
but this argument turned out unneeded after all.
Signed-off-by: Masahiro Yamada
---
arch/arm/mach-uniphier/board_init.c | 8 +---
arch/arm/mach-uniphier/clk/pll-ld20.c | 4 +---
arch/arm/mach-uniphier/init.h | 2 +
These functions never fail, so no need to return a value.
Signed-off-by: Masahiro Yamada
---
arch/arm/mach-uniphier/bcu/bcu-ld4.c | 4 +---
arch/arm/mach-uniphier/bcu/bcu-sld3.c | 4 +---
arch/arm/mach-uniphier/init.h | 4 ++--
3 files changed, 4 insertions(+), 8 deletions(-)
diff --g
Mostly cleanups of SoC init code.
Masahiro Yamada (9):
ARM: uniphier: remove unneeded argument of uniphier_ld20_pll_init()
ARM: uniphier: split out UMC clock enable
ARM: uniphier: refactor MEMCONF init code
ARM: uniphier: refactor SBC init code
ARM: uniphier: refactor Support Card init
Merge init-*.c into a single file using a table of callbacks because
the initialization flow is almost common among SoCs.
Signed-off-by: Masahiro Yamada
---
arch/arm/mach-uniphier/Makefile | 3 +-
arch/arm/mach-uniphier/clk/Makefile | 6 +-
arch/arm/mach-uniphier/clk/dpll-pro5.c
Initialize SBC and Support Card in U-Boot proper instead of SPL.
We may run different firmware (ex. ARM Trusted Firmware) before
U-Boot, and basic SoC initialization may be done there. In that
case, SPL may not be used.
The motivation for preparing SBC and Support Card in SPL was to use
LED for
The clock enable bits for UMC are more SoC-specific than for
the other hardware blocks. Separate the UMC clocks and the other
clocks for better code reuse across SoCs.
Signed-off-by: Masahiro Yamada
---
arch/arm/mach-uniphier/clk/Makefile| 18 ++---
.../clk/{early-clk-l
85 matches
Mail list logo
