Re: [PATCH] mvebu: Enable preboot start for pci/usb/scsi/nvme

[Dennis Gilmore]

Does anyone have an alternate email for Konstantin Porotchkin? he is
listed as the maintainer for theESPRESSOBin BOARD. and his email is
bouncing because his inbox is full.

Dennis

On Mon, Apr 1, 2024 at 8:40 PM Dennis Gilmore  wrote:
>
> While preboot was enabled, it did not work as commands are needed to be
> run to enable some of the subsystems. This patch starts pci, USB, Sata,
> and nvme and makes sure that the system will boot no mater what storage
> is in use.
>
> Applogies for resending, I accidently left the u-boot list off
>
> Signed-off-by: Dennis Gilmore 
> ---
>  configs/mvebu_espressobin-88f3720_defconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/configs/mvebu_espressobin-88f3720_defconfig 
> b/configs/mvebu_espressobin-88f3720_defconfig
> index 7ecf5ab0d64..fause his inbox is full4f7a809609 100644
> --- a/configs/mvebu_espressobin-88f3720_defconfig
> +++ b/configs/mvebu_espressobin-88f3720_defconfig
> @@ -21,6 +21,7 @@ CONFIG_AHCI=y
>  CONFIG_DISTRO_DEFAULTS=y
>  CONFIG_OF_BOARD_SETUP=y
>  CONFIG_USE_PREBOOT=y
> +CONFIG_PREBOOT="pci enum; usb start; nvme scan; scsi scan;"
>  CONFIG_SYS_CONSOLE_INFO_QUIET=y
>  # CONFIG_DISPLAY_CPUINFO is not set
>  # CONFIG_DISPLAY_BOARDINFO is not set
> --
> 2.44.0
>

[PATCH] mvebu: Enable preboot start for pci/usb/scsi/nvme

[Dennis Gilmore]

While preboot was enabled, it did not work as commands are needed to be
run to enable some of the subsystems. This patch starts pci, USB, Sata,
and nvme and makes sure that the system will boot no mater what storage
is in use.

Applogies for resending, I accidently left the u-boot list off

Signed-off-by: Dennis Gilmore 
---
 configs/mvebu_espressobin-88f3720_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/mvebu_espressobin-88f3720_defconfig 
b/configs/mvebu_espressobin-88f3720_defconfig
index 7ecf5ab0d64..f4f7a809609 100644
--- a/configs/mvebu_espressobin-88f3720_defconfig
+++ b/configs/mvebu_espressobin-88f3720_defconfig
@@ -21,6 +21,7 @@ CONFIG_AHCI=y
 CONFIG_DISTRO_DEFAULTS=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_USE_PREBOOT=y
+CONFIG_PREBOOT="pci enum; usb start; nvme scan; scsi scan;"
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 # CONFIG_DISPLAY_CPUINFO is not set
 # CONFIG_DISPLAY_BOARDINFO is not set
-- 
2.44.0

Re: [PATCH v2 2/3] arm: mvebu: helios4_defconfig: enable setexpr command

[Dennis Gilmore]

I am curious about your use cases for this. as ideally all systems use the
generic distro boot paths and it is not needed for them.

Dennis

On Fri, Feb 2, 2024 at 9:13 AM Josua Mayer  wrote:

> Update the helios4 defconfig to enable the 'setexpr' command, which is a
> default and useful for various complex boot-scripts.
>
> Signed-off-by: Josua Mayer 
> ---
>  configs/helios4_defconfig | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/configs/helios4_defconfig b/configs/helios4_defconfig
> index 04194004f0..73f0638344 100644
> --- a/configs/helios4_defconfig
> +++ b/configs/helios4_defconfig
> @@ -44,7 +44,6 @@ CONFIG_CMD_MMC=y
>  CONFIG_CMD_PCI=y
>  CONFIG_CMD_SPI=y
>  CONFIG_CMD_USB=y
> -# CONFIG_CMD_SETEXPR is not set
>  CONFIG_CMD_TFTPPUT=y
>  CONFIG_CMD_CACHE=y
>  CONFIG_CMD_TIME=y
>
> --
> 2.35.3
>
>

-- 
Dennis Gilmore
Senior Manager Systems Enablement OpenShift Development

Re: [PATCH 00/21] Qualcomm generic board support

[Dennis Gilmore]

A big benefit of using the full dtb in u-boot means it can be used to
boot the system without the need to load a replacement file from disk
or elsewhere, which, AFAIK is required for the System Ready standards
and it definitely helps in cases like EFI booting.

Dennis

On Wed, Nov 29, 2023 at 10:37 AM Neil Armstrong
 wrote:
>
> On 29/11/2023 16:34, Caleb Connolly wrote:
> >
> >
> > On 23/11/2023 07:04, Sumit Garg wrote:
> >> On Wed, 22 Nov 2023 at 21:34, Caleb Connolly  
> >> wrote:
> >>>
> >>>
> >>>
> >>> On 22/11/2023 14:27, Tom Rini wrote:
>  On Wed, Nov 22, 2023 at 07:44:09PM +0530, Sumit Garg wrote:
> > On Wed, 22 Nov 2023 at 19:31, Tom Rini  wrote:
> >>
> >> On Wed, Nov 22, 2023 at 11:51:29AM +0530, Sumit Garg wrote:
> >>> Hi Caleb,
> >>>
> >>> On Tue, 21 Nov 2023 at 22:39, Caleb Connolly 
> >>>  wrote:
> >> [snip]
>  == DT loading ==
> 
>  Previously, boards used the FDT blob embedded into U-Boot (via
>  OF_SEPARATE). However, most Qualcomm boards run U-Boot as a secondary
>  bootloader, so we can instead rely on the first-stage bootloader to
>  populate some useful FDT properties for us (notably the /memory node 
>  and
>  KASLR seed) and fetch the DTB that it provides. Combined with the 
>  memory
>  map changes above, this let's us entirely avoid configuring the 
>  memory
>  map explicitly.
> >>>
> >>> Since with this change, we don't need to embed FDT blob in the u-boot
> >>> binary, so I was thinking if we really need to import DTs from Linux
> >>> for different platforms and then play a catchup game?
> >>>
> >>> For now, yes.
> >>
> >> But why? Is there any value added by larger u-boot specific DT (most
> >> of the nodes being unused by u-boot) than what currently u-boot
> >> supports? The more important part is to get alignment with Linux DT
> >> bindings. If you need to have memory/reserved-memory nodes in u-boot
> >> DT for generalization purposes then you should import those particular
> >> nodes only.
> >
> > I've been thinking about and hacking on this for the last week or so,
> > sorry for the delayed reply here.
> >
> > The value is in preventing any of the existing bindings from regressing,
> > and simplifying the bringup process for new platforms (just copy
> > SoC/PMIC DTSI and write a minimal board DTS to enable the needed hardware).
> >>
> >>> There are quite a few features which aren't handled by
> >>> U-Boot that it shouldn't need to handle (rpm/h resources for example).
> >>> Also the fixed-regulator / regulator-gpio binding differences.
> >>
> >> IMO, we should fix them first and then use Linux DT as it is.
> >
> > The biggest blocker here is USB, on sdm845 and the 4 new platforms I
> > have working, I only support USB high speed, this requires removing the
> > superspeed phy and adding a DTS property.
> >
> > I tried using OF_BOARD_SETUP to make this changes during boot but this
> > approach really isn't scalable (and I couldn't find a way to make it
> > work anyway).
> >
> >>
> >>>
> >>> I would definitely like to move towards supporting Linux DT directly,
> >>> but this approach gives us a nice middleground of minimising the U-Boot
> >>> specific DT parts.
> >>
> >> I don't see any real benefits here apart from the maintenance burden.
> >> If it had been an actual Linux DT then that can be passed to Linux as
> >> it is. However, the current modified import you are trying to do
> >> doesn't solve that purpose as well.
> >
> > Ensuring that we don't introduce non-standard bindings (by using Linux
> > DTSI) is one benefit, simplifying new platform bringup is another.
> >
> > The amount of work required to switch to upstream DT is too much to
> > block this series on. We can work on improving the situation there once
> > we have these Qualcomm improvements upstream and new boards added. I do
> > admit that this is quite an awkward middle-ground, and I would not like
> > it to last for too long.
>
> I'm a real supporter of targeting support of unmodified (or very slighly)
> Linux DT, having a reduced version of the Linux DT will be a pain at each
> sync, and you'll need to do this manually.
>
> Simply having to copy the Linux DT without any changes will make sure you
> are in sync with Linux's bindings, and will help making sure you'll boot
> unchanged Linux DTBs you get from previous loaders.
>
> And in bonus, you'll be able to chain it to the next loader like EFI.
>
> So I don't see why any work toward this goal is useless, and if an
> intermediate step is needed, let's do it.
>
> Neil
>
> >
> >>
> >> -Sumit
> >>
> >>>
> >>> IMO, the build command would look like following if we import
> >>> pre-built FDT blob from Linux:
> >>>
> >>> - Build u-boot::
> >>>
> >>>  $ export CROSS_COMPILE=
> >>>  $ make qcom_defconfig
> >>>  $ make
> >>>
> >>> - gzip u-boot::
> 

Re: [PATCH v1 2/2] doc: board: starfive: Add more info about supported driver

[Dennis Gilmore]

On Tue, Aug 22, 2023 at 9:34 AM Shengyu Qu  wrote:

> Since PLDA PCIE driver is added and VL805 support is enabled in
> defconfig for Starfive Visionfive 2, modify the document to keep
> consistent.
>
> Signed-off-by: Shengyu Qu 
>
Tested-by: Dennis Gilmore 

> ---
>  doc/board/starfive/visionfive2.rst | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/doc/board/starfive/visionfive2.rst
> b/doc/board/starfive/visionfive2.rst
> index 941899a0a4..460f23aec3 100644
> --- a/doc/board/starfive/visionfive2.rst
> +++ b/doc/board/starfive/visionfive2.rst
> @@ -20,6 +20,8 @@ The support for following drivers are already enabled:
>  3. StarFive JH7110 reset Driver.
>  4. Cadence QSPI controller Driver.
>  5. MMC SPI Driver for MMC/SD support.
> +6. PLDA PCIE controller driver.
> +7. On-board VL805 PCIE-USB controller driver.
>
>  Booting from MMC using U-Boot SPL
>  -
> --
> 2.42.0
>
>

Re: [PATCH v1 1/2] configs: starfive: Enable PCIE auto enum and NVME/USB stuff for Starfive Visionfive 2

[Dennis Gilmore]

On Tue, Aug 22, 2023 at 9:34 AM Shengyu Qu  wrote:

> Although PCIE driver already exists, board defconfig isn't configured to
> enable PCIE enum on boot, thus USB storage device and NVME drive are not
> supported by default. So modify defconfig to enable PCIE auto enum, then
> start USB subsystem and scan nvme drive on boot.
>
> Signed-off-by: Shengyu Qu 
>
Tested-by: Dennis Gilmore 

> ---
>  configs/starfive_visionfive2_defconfig | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/configs/starfive_visionfive2_defconfig
> b/configs/starfive_visionfive2_defconfig
> index e9b63e5b84..3002c96f0e 100644
> --- a/configs/starfive_visionfive2_defconfig
> +++ b/configs/starfive_visionfive2_defconfig
> @@ -30,6 +30,7 @@ CONFIG_SPL_SPI=y
>  CONFIG_SYS_LOAD_ADDR=0x8200
>  CONFIG_SYS_PCI_64BIT=y
>  CONFIG_PCI=y
> +CONFIG_PCI_INIT_R=y
>  CONFIG_TARGET_STARFIVE_VISIONFIVE2=y
>  CONFIG_SPL_OPENSBI_LOAD_ADDR=0x4000
>  CONFIG_ARCH_RV64I=y
> @@ -43,7 +44,7 @@ CONFIG_SD_BOOT=y
>  CONFIG_USE_BOOTARGS=y
>  CONFIG_BOOTARGS="console=ttyS0,115200 debug rootwait earlycon=sbi"
>  CONFIG_USE_PREBOOT=y
> -CONFIG_PREBOOT="setenv fdt_addr ${fdtcontroladdr};fdt addr
> ${fdtcontroladdr};"
> +CONFIG_PREBOOT="nvme scan; usb start; setenv fdt_addr ${fdtcontroladdr};
> fdt addr ${fdtcontroladdr};"
>  CONFIG_DEFAULT_FDT_FILE="starfive/jh7110-starfive-visionfive-2.dtb"
>  CONFIG_DISPLAY_CPUINFO=y
>  CONFIG_DISPLAY_BOARDINFO=y
> @@ -124,4 +125,9 @@ CONFIG_TIMER_EARLY=y
>  CONFIG_USB=y
>  CONFIG_USB_XHCI_HCD=y
>  CONFIG_USB_XHCI_PCI=y
> +CONFIG_USB_EHCI_HCD=y
> +CONFIG_USB_EHCI_PCI=y
> +CONFIG_USB_OHCI_HCD=y
> +CONFIG_USB_OHCI_PCI=y
> +CONFIG_USB_STORAGE=y
>  CONFIG_USB_KEYBOARD=y
> --
> 2.42.0
>
>

Re: [PATCH] Revert "spi: spi-uclass: Add support to manually relocate spi memory ops"

[Dennis Gilmore]

On Sat, Jul 24, 2021 at 11:03 AM Tom Rini  wrote:
>
> On Fri, Jul 23, 2021 at 10:49:39PM -0500, Dennis Gilmore wrote:
> > On Fri, Jul 23, 2021 at 10:25 PM Tom Rini  wrote:
> > >
> > > On Fri, Jul 23, 2021 at 09:46:44PM -0500, Dennis Gilmore wrote:
> > >
> > > > removing the header is not sufficient to have the boards booting from 
> > > > SPI.
> > > >
> > > > U-Boot TPL 2021.07-00768-g49373a3334-dirty (Jul 23 2021 - 20:42:57)
> > > > Channel 0: LPDDR4, 50MHz
> > > > BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
> > > > Channel 1: LPDDR4, 50MHz
> > > > BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
> > > > 256B stride
> > > > lpddr4_set_rate: change freq to 4 mhz 0, 1
> > > > lpddr4_set_rate: change freq to 8 mhz 1, 0
> > > > Trying to boot from BOOTROM
> > > > Returning to boot ROM...
> > > >
> > > > U-Boot SPL 2021.07-00768-g49373a3334-dirty (Jul 23 2021 - 20:42:57 
> > > > -0500)
> > > > Trying to boot from SPI
> > > >
> > > > At this point u-boot hangs, with the patch reverted I get the following
> > > > U-Boot TPL 2021.07-00769-g4af8bd872c-dirty (Jul 23 2021 - 21:20:51)
> > > > Channel 0: LPDDR4, 50MHz
> > > > BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
> > > > Channel 1: LPDDR4, 50MHz
> > > > BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
> > > > 256B stride
> > > > lpddr4_set_rate: change freq to 4 mhz 0, 1
> > > > lpddr4_set_rate: change freq to 8 mhz 1, 0
> > > > Trying to boot from BOOTROM
> > > > Returning to boot ROM...
> > > >
> > > > U-Boot SPL 2021.07-00769-g4af8bd872c-dirty (Jul 23 2021 - 21:20:51 
> > > > -0500)
> > > > Trying to boot from SPI
> > > >
> > > >
> > > > U-Boot 2021.07-00769-g4af8bd872c-dirty (Jul 23 2021 - 21:20:51 -0500)
> > > >
> > > > SoC: Rockchip rk3399
> > > > Reset cause: RST
> > > > Model: Kobol Helios64
> > > > Revision: 0.0 - Unknown
> > > > DRAM:  3.9 GiB
> > > > PMIC:  RK808
> > > > MMC:   mmc@fe32: 1, mmc@fe33: 0
> > > > Loading Environment from SPIFlash... SF: Detected w25q128 with page
> > > > size 256 Bytes, erase size 4 KiB, total 16 MiB
> > > > *** Warning - bad CRC, using default environment
> > > >
> > > > In:serial@ff1a
> > > > Out:   serial@ff1a
> > > > Err:   serial@ff1a
> > > > Model: Kobol Helios64
> > > > Revision: UNKNOWN
> > > > Net:   dw_dm_mdio_init: mdio node is missing, registering legacy mdio
> > > > busNo ethernet found.
> > > >
> > > > starting USB...
> > > > Bus usb@fe90: usb maximum-speed not found
> > > > Register 2000140 NbrPorts 2
> > > > Starting the controller
> > > > USB XHCI 1.10
> > > > scanning bus usb@fe90 for devices... 2 USB Device(s) found
> > > >scanning usb for storage devices... 0 Storage Device(s) found
> > > > Hit any key to stop autoboot:  0
> > > > switch to partitions #0, OK
> > > > mmc0(part 0) is current device
> > > > ** No partition table - mmc 0 **
> > > > Couldn't find partition mmc 0:1
> > > > switch to partitions #0, OK
> > > > mmc1 is current device
> > > > Scanning mmc 1:1...
> > > > Scanning disk m...@fe32.blk...
> > > > Scanning disk m...@fe33.blk...
> > > > ** Unrecognized filesystem type **
> > > > Found 5 disks
> > > > dw_dm_mdio_init: mdio node is missing, registering legacy mdio
> > > > busdw_dm_mdio_init: mdio node is missing, registering legacy mdio
> > > > busLoading Boot 'Fedora' failed
> > > > EFI boot manager: Cannot load any image
> > > > Found EFI removable media binary efi/boot/bootaa64.efi
> > >
> > > Is LTO on, on these platforms?  That code in question really should not
> > > be enabled, at all.  Like, if you toss an #error in that section of
> > > code, it should still build.  It does, right?
> >
> > It does still build if I put a #error in the middle of it
> >
> > $ grep LTO .config
> > CONFIG_ARCH_SUPPORTS_LTO=y
> > # CONFIG_LTO is not set
> >
> >
> > LTO is not on
>
> OK, so progress.  What toolchain are you using here?  And can you easily
> re-test with one of the kernel.org ones, or if using one already 9.2.0
> (or 11.1.0) ?


I have been using gcc 10.2.1, I will test with 11.1.1

Dennis

> --
> Tom

Re: [PATCH] Revert "spi: spi-uclass: Add support to manually relocate spi memory ops"

[Dennis Gilmore]

On Fri, Jul 23, 2021 at 10:25 PM Tom Rini  wrote:
>
> On Fri, Jul 23, 2021 at 09:46:44PM -0500, Dennis Gilmore wrote:
>
> > removing the header is not sufficient to have the boards booting from SPI.
> >
> > U-Boot TPL 2021.07-00768-g49373a3334-dirty (Jul 23 2021 - 20:42:57)
> > Channel 0: LPDDR4, 50MHz
> > BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
> > Channel 1: LPDDR4, 50MHz
> > BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
> > 256B stride
> > lpddr4_set_rate: change freq to 4 mhz 0, 1
> > lpddr4_set_rate: change freq to 8 mhz 1, 0
> > Trying to boot from BOOTROM
> > Returning to boot ROM...
> >
> > U-Boot SPL 2021.07-00768-g49373a3334-dirty (Jul 23 2021 - 20:42:57 -0500)
> > Trying to boot from SPI
> >
> > At this point u-boot hangs, with the patch reverted I get the following
> > U-Boot TPL 2021.07-00769-g4af8bd872c-dirty (Jul 23 2021 - 21:20:51)
> > Channel 0: LPDDR4, 50MHz
> > BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
> > Channel 1: LPDDR4, 50MHz
> > BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
> > 256B stride
> > lpddr4_set_rate: change freq to 4 mhz 0, 1
> > lpddr4_set_rate: change freq to 8 mhz 1, 0
> > Trying to boot from BOOTROM
> > Returning to boot ROM...
> >
> > U-Boot SPL 2021.07-00769-g4af8bd872c-dirty (Jul 23 2021 - 21:20:51 -0500)
> > Trying to boot from SPI
> >
> >
> > U-Boot 2021.07-00769-g4af8bd872c-dirty (Jul 23 2021 - 21:20:51 -0500)
> >
> > SoC: Rockchip rk3399
> > Reset cause: RST
> > Model: Kobol Helios64
> > Revision: 0.0 - Unknown
> > DRAM:  3.9 GiB
> > PMIC:  RK808
> > MMC:   mmc@fe32: 1, mmc@fe33: 0
> > Loading Environment from SPIFlash... SF: Detected w25q128 with page
> > size 256 Bytes, erase size 4 KiB, total 16 MiB
> > *** Warning - bad CRC, using default environment
> >
> > In:serial@ff1a
> > Out:   serial@ff1a
> > Err:   serial@ff1a
> > Model: Kobol Helios64
> > Revision: UNKNOWN
> > Net:   dw_dm_mdio_init: mdio node is missing, registering legacy mdio
> > busNo ethernet found.
> >
> > starting USB...
> > Bus usb@fe90: usb maximum-speed not found
> > Register 2000140 NbrPorts 2
> > Starting the controller
> > USB XHCI 1.10
> > scanning bus usb@fe90 for devices... 2 USB Device(s) found
> >scanning usb for storage devices... 0 Storage Device(s) found
> > Hit any key to stop autoboot:  0
> > switch to partitions #0, OK
> > mmc0(part 0) is current device
> > ** No partition table - mmc 0 **
> > Couldn't find partition mmc 0:1
> > switch to partitions #0, OK
> > mmc1 is current device
> > Scanning mmc 1:1...
> > Scanning disk m...@fe32.blk...
> > Scanning disk m...@fe33.blk...
> > ** Unrecognized filesystem type **
> > Found 5 disks
> > dw_dm_mdio_init: mdio node is missing, registering legacy mdio
> > busdw_dm_mdio_init: mdio node is missing, registering legacy mdio
> > busLoading Boot 'Fedora' failed
> > EFI boot manager: Cannot load any image
> > Found EFI removable media binary efi/boot/bootaa64.efi
>
> Is LTO on, on these platforms?  That code in question really should not
> be enabled, at all.  Like, if you toss an #error in that section of
> code, it should still build.  It does, right?

It does still build if I put a #error in the middle of it

$ grep LTO .config
CONFIG_ARCH_SUPPORTS_LTO=y
# CONFIG_LTO is not set


LTO is not on


> --
> Tom

Re: [PATCH] Revert "spi: spi-uclass: Add support to manually relocate spi memory ops"

[Dennis Gilmore]

removing the header is not sufficient to have the boards booting from SPI.

U-Boot TPL 2021.07-00768-g49373a3334-dirty (Jul 23 2021 - 20:42:57)
Channel 0: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
Channel 1: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
256B stride
lpddr4_set_rate: change freq to 4 mhz 0, 1
lpddr4_set_rate: change freq to 8 mhz 1, 0
Trying to boot from BOOTROM
Returning to boot ROM...

U-Boot SPL 2021.07-00768-g49373a3334-dirty (Jul 23 2021 - 20:42:57 -0500)
Trying to boot from SPI

At this point u-boot hangs, with the patch reverted I get the following
U-Boot TPL 2021.07-00769-g4af8bd872c-dirty (Jul 23 2021 - 21:20:51)
Channel 0: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
Channel 1: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
256B stride
lpddr4_set_rate: change freq to 4 mhz 0, 1
lpddr4_set_rate: change freq to 8 mhz 1, 0
Trying to boot from BOOTROM
Returning to boot ROM...

U-Boot SPL 2021.07-00769-g4af8bd872c-dirty (Jul 23 2021 - 21:20:51 -0500)
Trying to boot from SPI


U-Boot 2021.07-00769-g4af8bd872c-dirty (Jul 23 2021 - 21:20:51 -0500)

SoC: Rockchip rk3399
Reset cause: RST
Model: Kobol Helios64
Revision: 0.0 - Unknown
DRAM:  3.9 GiB
PMIC:  RK808
MMC:   mmc@fe32: 1, mmc@fe33: 0
Loading Environment from SPIFlash... SF: Detected w25q128 with page
size 256 Bytes, erase size 4 KiB, total 16 MiB
*** Warning - bad CRC, using default environment

In:serial@ff1a
Out:   serial@ff1a
Err:   serial@ff1a
Model: Kobol Helios64
Revision: UNKNOWN
Net:   dw_dm_mdio_init: mdio node is missing, registering legacy mdio
busNo ethernet found.

starting USB...
Bus usb@fe90: usb maximum-speed not found
Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus usb@fe90 for devices... 2 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0(part 0) is current device
** No partition table - mmc 0 **
Couldn't find partition mmc 0:1
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:1...
Scanning disk m...@fe32.blk...
Scanning disk m...@fe33.blk...
** Unrecognized filesystem type **
Found 5 disks
dw_dm_mdio_init: mdio node is missing, registering legacy mdio
busdw_dm_mdio_init: mdio node is missing, registering legacy mdio
busLoading Boot 'Fedora' failed
EFI boot manager: Cannot load any image
Found EFI removable media binary efi/boot/bootaa64.efi

On Thu, Jul 22, 2021 at 12:30 PM Tom Rini  wrote:
>
> On Thu, Jul 22, 2021 at 06:04:40PM +0200, Michal Simek wrote:
> >
> >
> > On 7/22/21 5:25 PM, Peter Robinson wrote:
> > > This reverts commit 346df7d4fa62afc578d820b3a18815eec765074f.
> > >
> > > This patch broke booting Rockchip systems from U-Boot residing on SPI
> > > flash, for at least the Pinebook Pro and Rockpro64, and also confirmed
> > > with the not yet upstream Helios64.
> > >
> > > Signed-off-by: Peter Robinson 
> > > Cc: T Karthik Reddy 
> > > Cc: Ashok Reddy Soma 
> > > Cc: Michal Simek 
> > > Cc: Pratyush Yadav 
> > > ---
> > >  drivers/spi/spi-uclass.c | 11 ---
> > >  1 file changed, 11 deletions(-)
> > >
> > > diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
> > > index d867b27806..ec7f4652b3 100644
> > > --- a/drivers/spi/spi-uclass.c
> > > +++ b/drivers/spi/spi-uclass.c
> > > @@ -11,7 +11,6 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > -#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > @@ -200,16 +199,6 @@ static int spi_post_probe(struct udevice *bus)
> > > ops->set_mode += gd->reloc_off;
> > > if (ops->cs_info)
> > > ops->cs_info += gd->reloc_off;
> > > -   if (ops->mem_ops) {
> > > -   struct spi_controller_mem_ops *mem_ops =
> > > -   (struct spi_controller_mem_ops *)ops->mem_ops;
> > > -   if (mem_ops->adjust_op_size)
> > > -   mem_ops->adjust_op_size += gd->reloc_off;
> > > -   if (mem_ops->supports_op)
> > > -   mem_ops->supports_op += gd->reloc_off;
> > > -   if (mem_ops->exec_op)
> > > -   mem_ops->exec_op += gd->reloc_off;
> > > -   }
> > > reloc_done++;
> > > }
> > >  #endif
> > >
> >
> > This is protected by CONFIG_NEEDS_MANUAL_RELOC which is only enable for
> > m68k and microblaze. I expect rockchip is arm and you should never have
> > this code in your binary. That's why please double check it.
>
> Yes, this really doesn't make sense.  Try also just removing spi-mem.h
> from the file and see if that causes things to work again.  If so, time
> to dig in to that header file to figure out what could be going wrong.
>
> --
> Tom

bug in SPI on rk3399 devices

[Dennis Gilmore]

I am not sure if it impacts non rk3399 devices or not, but on at least
rk3399 devices after
https://source.denx.de/u-boot/u-boot/-/commit/346df7d4fa62afc578d820b3a18815eec765074f
was applied installing u-boot into SPI flash results in an unbootable
system. SPL loads and runs, u-boot.itb is not found and the boot
hangs.  I am looking into it but would appreciate more eyes on it.

Dennis

[PATCH] rk3399: Add basic support for helios64

[Dennis Gilmore]

From: Dennis Gilmore 

This is a stripped down version of the vendor U-Boot patch by Aditya
Prayoga found in the armbian repository. This patch is enough to have
the 1G ethernet port, the micro SD card, eMMC, PCIe and UART. It sets
uart2 as the default outiput device. the defconfig file has been cleaned
up a lot from the vendor version.

The device tree file is from the for-next branch of linux-rockchip and
targeted for 5.15 needed for SPI, stdout-path, and tsadc enablement

Signed-off-by: Dennis Gilmore 
---
 arch/arm/dts/Makefile |   1 +
 .../arm/dts/rk3399-kobol-helios64-u-boot.dtsi |  23 +
 arch/arm/dts/rk3399-kobol-helios64.dts| 534 ++
 arch/arm/mach-rockchip/rk3399/Kconfig |  17 +
 board/kobol/helios64-rk3399/Kconfig   |  17 +
 board/kobol/helios64-rk3399/MAINTAINERS   |   7 +
 board/kobol/helios64-rk3399/Makefile  |   5 +
 board/kobol/helios64-rk3399/helios64.c| 262 +
 board/kobol/helios64-rk3399/sys_otp.c | 253 +
 board/kobol/helios64-rk3399/sys_otp.h |  15 +
 board/pine64/rockpro64_rk3399/Kconfig |   2 +
 configs/helios64-rk3399_defconfig | 114 
 include/configs/helios64-rk3399.h |  56 ++
 13 files changed, 1306 insertions(+)
 create mode 100644 arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3399-kobol-helios64.dts
 create mode 100644 board/kobol/helios64-rk3399/Kconfig
 create mode 100644 board/kobol/helios64-rk3399/MAINTAINERS
 create mode 100644 board/kobol/helios64-rk3399/Makefile
 create mode 100644 board/kobol/helios64-rk3399/helios64.c
 create mode 100644 board/kobol/helios64-rk3399/sys_otp.c
 create mode 100644 board/kobol/helios64-rk3399/sys_otp.h
 create mode 100644 configs/helios64-rk3399_defconfig
 create mode 100644 include/configs/helios64-rk3399.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 9fb38682e6..2788d7dd7b 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -124,6 +124,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3399) += \
rk3399-ficus.dtb \
rk3399-firefly.dtb \
rk3399-gru-bob.dtb \
+   rk3399-kobol-helios64.dtb \
rk3399-khadas-edge.dtb \
rk3399-khadas-edge-captain.dtb \
rk3399-khadas-edge-v.dtb \
diff --git a/arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi 
b/arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi
new file mode 100644
index 00..f534c14b13
--- /dev/null
+++ b/arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2020 Aditya Prayoga (adi...@kobol.io)
+ */
+
+#include "rk3399-u-boot.dtsi"
+#include "rk3399-sdram-lpddr4-100.dtsi"
+
+/ {
+   chosen {
+   u-boot,spl-boot-order = "same-as-spl", , , 

+   };
+
+   config {
+   u-boot,spl-payload-offset = <0x6>; /* @ 384KB */
+   };
+};
+
+ {
+   spiflash: flash@0 {
+   u-boot,dm-pre-reloc;
+   };
+};
diff --git a/arch/arm/dts/rk3399-kobol-helios64.dts 
b/arch/arm/dts/rk3399-kobol-helios64.dts
new file mode 100644
index 00..63c7681843
--- /dev/null
+++ b/arch/arm/dts/rk3399-kobol-helios64.dts
@@ -0,0 +1,534 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2020 Aditya Prayoga 
+ */
+
+/*
+ * The Kobol Helios64 is a board designed to operate as a NAS and optionally
+ * ships with an enclosing that can host five 2.5" hard disks.
+ *
+ * See https://wiki.kobol.io/helios64/intro/ for further details.
+ */
+
+/dts-v1/;
+#include "rk3399.dtsi"
+#include "rk3399-opp.dtsi"
+
+/ {
+   model = "Kobol Helios64";
+   compatible = "kobol,helios64", "rockchip,rk3399";
+
+   aliases {
+   mmc0 = 
+   mmc1 = 
+   spi1 = 
+   spi2 = 
+   spi5 = 
+   };
+
+   avdd_0v9_s0: avdd-0v9-s0 {
+   compatible = "regulator-fixed";
+   regulator-name = "avdd_0v9_s0";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <90>;
+   regulator-max-microvolt = <90>;
+   vin-supply = <_sys_s3>;
+   };
+
+   avdd_1v8_s0: avdd-1v8-s0 {
+   compatible = "regulator-fixed";
+   regulator-name = "avdd_1v8_s0";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   vin-supply = <_sys_s3>;
+   };
+
+   chosen {
+   stdout-path = "serial2:150n8";
+   };
+
+   clkin_gmac: external-gmac-clock {
+   compatible = "fixed-clock";
+

Re: [PATCH] rk3399: Add basic support for helios64

[Dennis Gilmore]

I have been working on an updated version, I have cleaned up the
config a lot as well as done some work to make the -u-boot.dtsi file
smaller 
https://pagure.io/u-boot/c/2472db2eff8ba0fb262a0d0264aa9d9c7b3eca32?branch=helios64
is my current WIP patch, I have built it on top of updating the base
rk3399 dtsi files to the versions in Linux 5.13
https://pagure.io/u-boot/c/64980d20f7e728afd659d0cfce2127bbf9f2e5ee?branch=helios64

The helios64 dts file in my patch includes the patches I sent to the
Linux kernel 
https://patchwork.kernel.org/project/linux-rockchip/patch/20210701004043.18585-1-dgilm...@redhat.com/
https://patchwork.kernel.org/project/linux-rockchip/patch/20210701004043.18585-2-dgilm...@redhat.com/
https://patchwork.kernel.org/project/linux-rockchip/patch/20210701004043.18585-3-dgilm...@redhat.com/
https://patchwork.kernel.org/project/linux-rockchip/patch/20210701004043.18585-4-dgilm...@redhat.com/

Dennis

On Fri, Jun 25, 2021 at 4:32 AM Florian Klink  wrote:
>
> >It boots fine with current Fedora IoT 34 nightlies, but kernel crashes are
> >very regular (sometimes recoverable, sometimes not), which looks to me like
> >the same problem that Armbian builds have, logs seem to point to an issue
> >with the dmc frequency.
> >I've compiled an excerpt of interesting looking logs from a couple of boots
> >here (you should be able to comment on the doc as well):
> >https://hackmd.io/@lorbus/SyXTj0lXu
> >
> >Please take a look and let me know what you think.
>
> I've been running eb607cd4957fb0ef97beb2a8293478be6a54240a from
> git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git
> (which is 5.13-rc1, plus a whole bunch of helios64 and more generic
> rk3399 fixes).
>
> The system comes up. I couldn't immediately trigger any of the kernel
> crashes (except one that regularly occurs on shutdown/reboot), which I
> added to the hackmd document.
>
> I think most of the kernel issues are a concern of refining the dtb in
> the kernel itself, though, not an uboot issue per se, so not sure if
> this should block the inclusion of this patch into u-boot, which seems
> to work file (once there's a version with SPDX headers everywhere)
>
> Florian
>
> On 21-03-08 17:29:23, Christian Glombek wrote:
> >I've looked into this a bit over the weekend - my current WIP patch can be
> >found here:
> >https://src.fedoraproject.org/fork/lorbus/rpms/uboot-tools/blob/helios64/f/0001-arm-Add-support-for-Kobol-Helios64-board.patch
> >
> >It's essentially the entire devicetree used in Armbian, only that I had to
> >remove the gpio{1,2,4} initialization since `gpio-hog` doesn't appear to
> >work with upstream u-boot.
> >It boots fine with current Fedora IoT 34 nightlies, but kernel crashes are
> >very regular (sometimes recoverable, sometimes not), which looks to me like
> >the same problem that Armbian builds have, logs seem to point to an issue
> >with the dmc frequency.
> >I've compiled an excerpt of interesting looking logs from a couple of boots
> >here (you should be able to comment on the doc as well):
> >https://hackmd.io/@lorbus/SyXTj0lXu
> >
> >Please take a look and let me know what you think.
> >
> >Best regards,
> >Christian
>
> --
> Florian Klink

Re: [PATCH] rk3399: Add basic support for helios64

[Dennis Gilmore]

Hi Uwe,

Not all of the new files have SPDX headers as well. There was a second
submission of this patch set this week. Perhaps you can work with
Christian on the support?

Dennis

On Sat, Feb 27, 2021 at 9:32 PM Dennis Gilmore
 wrote:
>
> On Fri, Feb 26, 2021 at 12:57 AM Uwe Kleine-König  
> wrote:
> >
> > Hi Dennis,
> >
> > thanks for your feedback.
> >
> > On 2/26/21 12:23 AM, Dennis Gilmore wrote:
> > > Thanks for submitting, I have been meaning to do so myself, I have
> > > been meaning to go through and try get the dts files in a decent
> > > shape. I think that most of what is in
> > > arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi  belongs in
> > > arch/arm/dts/rk3399-kobol-helios64.dts
> >
> > I understood that the intention of the separation into two files is that
> > the one should track the Linux dts. Is that wrong?
>
> That is not wrong, however the only things that should be in the
> -u-boot.dtsi files are the things that are u-boot specific and needed
> to make u-boot work. everything else should go into Linux also
>
>
> >
> > > I also wonder if we shouldn't
> > > default to building an image for use in the SPI flash since the system
> > > has it available.
> >
> > I didn't test that but expected that I can write the resulting image to
> > the spi flash and it works just fine. If you want something else here I
> > need some direction about what to change.
>
> at the least the env should be in spi. there may be some things I am missing
>
> Dennis
>
> >
> > Best regards
> > Uwe
> >

Re: [PATCH v2] arm: Add support for Kobol Helios64 board

[Dennis Gilmore]

Uwe submitted this board last Thursday

Dennis

On Tue, Mar 2, 2021 at 10:46 AM Christian Glombek
 wrote:
>
> The hardware is described in detail on Kobol's wiki at
> https://wiki.kobol.io/helios64/intro/.
>
> This commit is based on downstream work in Armbian by Aditya Prayoga [1].
> The devicetree is taken from Linux v5.12-rc1 and was originally submitted 
> there by
> Uwe Kleine-Koenig [2].
>
> [1] 
> https://github.com/ukleinek/armbian-build/blob/35c85295d351830aa59b624db524ba04b238faae/patch/kernel/rockchip64-current/add-board-helios64.patch
> [2] 
> https://github.com/torvalds/linux/blob/7a7fd0de4a9804299793e564a555a49c1fc924cb/arch/arm64/boot/dts/rockchip/rk3399-kobol-helios64.dts
> ---
>  arch/arm/dts/Makefile |   1 +
>  .../arm/dts/rk3399-kobol-helios64-u-boot.dtsi | 136 +++
>  arch/arm/dts/rk3399-kobol-helios64.dts| 372 ++
>  arch/arm/mach-rockchip/rk3399/Kconfig |  17 +
>  board/kobol/helios64/Kconfig  |  24 ++
>  board/kobol/helios64/MAINTAINERS  |   6 +
>  board/kobol/helios64/Makefile |   5 +
>  board/kobol/helios64/helios64.c   | 304 ++
>  board/kobol/helios64/sys_otp.c| 250 
>  board/kobol/helios64/sys_otp.h|  12 +
>  configs/helios64-rk3399_defconfig | 147 +++
>  include/configs/helios64.h|  47 +++
>  12 files changed, 1321 insertions(+)
>  create mode 100644 arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3399-kobol-helios64.dts
>  create mode 100644 board/kobol/helios64/Kconfig
>  create mode 100644 board/kobol/helios64/MAINTAINERS
>  create mode 100644 board/kobol/helios64/Makefile
>  create mode 100644 board/kobol/helios64/helios64.c
>  create mode 100644 board/kobol/helios64/sys_otp.c
>  create mode 100644 board/kobol/helios64/sys_otp.h
>  create mode 100644 configs/helios64-rk3399_defconfig
>  create mode 100644 include/configs/helios64.h
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 33e483f4fb..2c820bc2b7 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -124,6 +124,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3399) += \
> rk3399-ficus.dtb \
> rk3399-firefly.dtb \
> rk3399-gru-bob.dtb \
> +   rk3399-kobol-helios64.dtb \
> rk3399-khadas-edge.dtb \
> rk3399-khadas-edge-captain.dtb \
> rk3399-khadas-edge-v.dtb \
> diff --git a/arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi 
> b/arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi
> new file mode 100644
> index 00..6fe9d59df3
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi
> @@ -0,0 +1,136 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2020 Aditya Prayoga 
> + */
> +
> +#include "rk3399-u-boot.dtsi"
> +#include "rk3399-sdram-lpddr4-100.dtsi"
> +/ {
> +   aliases {
> +   spi0 = 
> +   spi1 = 
> +   spi2 = 
> +   ethernet0 = 
> +   ethernet1 = _lan;
> +   };
> +
> +   chosen {
> +   bootargs = "earlycon=uart8250,mmio32,0xff1a earlyprintk";
> +   stdout-path = "serial2:150n8";
> +   u-boot,spl-boot-order = "same-as-spl", , , 
> 
> +   };
> +
> +   config {
> +   u-boot,spl-payload-offset = <0x8>; /* @ 512KB */
> +   };
> +};
> +
> + {
> +   usb-mux-hs {
> +   gpio-hog;
> +   gpios = ;
> +   output-low;
> +   line-name = "USB_MUX_HS";
> +   };
> +
> +   usb-mux-oe {
> +   gpio-hog;
> +   gpios = ;
> +   output-high;
> +   line-name = "USB_MUX_OE#";
> +   };
> +
> +   soc-flash-wp {
> +   gpio-hog;
> +   gpios = ;
> +   output-low;
> +   line-name = "SOC_WP#";
> +   };
> +};
> +
> + {
> +   sata-flash-wp {
> +   gpio-hog;
> +   gpios = ;
> +   output-high;
> +   line-name = "SATA_WP#_LV";
> +   };
> +};
> +
> + {
> +   auto-on-en-d {
> +   gpio-hog;
> +   gpios = ;
> +   output-low;
> +   line-name = "AUTO_ON_EN_D";
> +   };
> +
> +   auto-on-en-clk {
> +   gpio-hog;
> +   gpios = ;
> +   output-low;
> +   line-name = "AUTO_ON_EN_CLK";
> +   };
> +
> +   board-rev-id-0 {
> +   gpio-hog;
> +   gpios = ;
> +   input;
> +   };
> +
> +   board-rev-id-1 {
> +   gpio-hog;
> +   gpios = ;
> +   input;
> +   };
> +};
> +
> +_hub {
> +   compatible = "usb-hub";
> +   usb,device-class = ;
> +};
> +
> +_prst {
> +   rockchip,pins =
> +   <2 RK_PD4 RK_FUNC_GPIO _output_low>;
> +};
> +
> +_pwr_en {
> + 

Re: [PATCH] rk3399: Add basic support for helios64

[Dennis Gilmore]

On Fri, Feb 26, 2021 at 12:57 AM Uwe Kleine-König  
wrote:
>
> Hi Dennis,
>
> thanks for your feedback.
>
> On 2/26/21 12:23 AM, Dennis Gilmore wrote:
> > Thanks for submitting, I have been meaning to do so myself, I have
> > been meaning to go through and try get the dts files in a decent
> > shape. I think that most of what is in
> > arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi  belongs in
> > arch/arm/dts/rk3399-kobol-helios64.dts
>
> I understood that the intention of the separation into two files is that
> the one should track the Linux dts. Is that wrong?

That is not wrong, however the only things that should be in the
-u-boot.dtsi files are the things that are u-boot specific and needed
to make u-boot work. everything else should go into Linux also


>
> > I also wonder if we shouldn't
> > default to building an image for use in the SPI flash since the system
> > has it available.
>
> I didn't test that but expected that I can write the resulting image to
> the spi flash and it works just fine. If you want something else here I
> need some direction about what to change.

at the least the env should be in spi. there may be some things I am missing

Dennis

>
> Best regards
> Uwe
>

Re: [PATCH] rk3399: Add basic support for helios64

[Dennis Gilmore]

Thanks for submitting, I have been meaning to do so myself, I have
been meaning to go through and try get the dts files in a decent
shape. I think that most of what is in
arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi  belongs in
arch/arm/dts/rk3399-kobol-helios64.dts I also wonder if we shouldn't
default to building an image for use in the SPI flash since the system
has it available.

Dennis



On Thu, Feb 25, 2021 at 3:14 PM Uwe Kleine-König  wrote:
>
> This is a stripped down version of the vendor U-Boot patch by Aditya
> Prayoga found in the armbian repository. This patch is enough to have
> the 1G ethernet port, the micro SD card, eMMC and UART operational and
> let it boot a Debian netboot installer.
>
> The device tree is contained in Linux v5.11-rc1. During my work on
> U-Boot I noticed a wrong pull setting, the corresponding patch is still
> in linux-next and already applied in the copy that is added by this
> patch.
>
> Signed-off-by: Uwe Kleine-König 
> ---
> Hello,
>
> @Aditya: I kept you as maintainer in MAINTAINERS, is this ok for you?
> I doubt that I'm qualified enough for that.
>
> So please wait for this question to be resolved before you apply this
> patch.
>
> Best regards
> Uwe
>
>  arch/arm/dts/Makefile |   1 +
>  .../arm/dts/rk3399-kobol-helios64-u-boot.dtsi | 266 +
>  arch/arm/dts/rk3399-kobol-helios64.dts| 372 ++
>  arch/arm/mach-rockchip/rk3399/Kconfig |  17 +
>  board/kobol/helios64/Kconfig  |  24 ++
>  board/kobol/helios64/MAINTAINERS  |   6 +
>  board/kobol/helios64/Makefile |   5 +
>  board/kobol/helios64/helios64.c   | 262 
>  board/kobol/helios64/sys_otp.c| 248 
>  board/kobol/helios64/sys_otp.h|  10 +
>  configs/helios64-rk3399_defconfig | 142 +++
>  include/configs/helios64.h|  47 +++
>  12 files changed, 1400 insertions(+)
>  create mode 100644 arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3399-kobol-helios64.dts
>  create mode 100644 board/kobol/helios64/Kconfig
>  create mode 100644 board/kobol/helios64/MAINTAINERS
>  create mode 100644 board/kobol/helios64/Makefile
>  create mode 100644 board/kobol/helios64/helios64.c
>  create mode 100644 board/kobol/helios64/sys_otp.c
>  create mode 100644 board/kobol/helios64/sys_otp.h
>  create mode 100644 configs/helios64-rk3399_defconfig
>  create mode 100644 include/configs/helios64.h
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index fd47e408f826..752ba4fd8b35 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -125,6 +125,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3399) += \
> rk3399-ficus.dtb \
> rk3399-firefly.dtb \
> rk3399-gru-bob.dtb \
> +   rk3399-kobol-helios64.dtb \
> rk3399-khadas-edge.dtb \
> rk3399-khadas-edge-captain.dtb \
> rk3399-khadas-edge-v.dtb \
> diff --git a/arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi 
> b/arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi
> new file mode 100644
> index ..84a27548a08d
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi
> @@ -0,0 +1,266 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2020 Aditya Prayoga (adi...@kobol.io)
> + */
> +
> +#include "rk3399-u-boot.dtsi"
> +#include "rk3399-sdram-lpddr4-100.dtsi"
> +
> +/ {
> +   aliases {
> +   spi0 = 
> +   ethernet0 = 
> +   };
> +
> +   chosen {
> +   bootargs = "earlycon=uart8250,mmio32,0xff1a earlyprintk";
> +   stdout-path = "serial2:150n8";
> +   u-boot,spl-boot-order = "same-as-spl", , , 
> 
> +   };
> +
> +   config {
> +   u-boot,spl-payload-offset = <0x8>; /* @ 512KB */
> +   };
> +
> +   leds {
> +   led-1 {
> +   linux,default-trigger = "panic";
> +   };
> +   };
> +
> +   vcc3v0_sd: vcc3v0-sd {
> +   startup-delay-us = <2>;
> +   };
> +};
> +
> +_alert0 {
> +   temperature = <8>;
> +};
> +
> +_alert1 {
> +   temperature = <95000>;
> +};
> +
> +_crit {
> +   temperature = <10>;
> +};
> +
> + {
> +   rk808: pmic@1b {
> +   rockchip,system-power-controller;
> +
> +   regulators {
> +   vdd_center: DCDC_REG1 {
> +   regulator-name = "vdd_center";
> +   regulator-always-on;
> +   regulator-boot-on;
> +   regulator-min-microvolt = <95>;
> +   regulator-max-microvolt = <95>;
> +   regulator-init-microvolt = <95>;
> +   regulator-ramp-delay = <6001>;
> +   

Re: [V2 2/3] ARM: mvebu: helios4 dts changes to enable SPI

[Dennis Gilmore]

could I please get someone to review this patch

Dennis

On Tue, Dec 8, 2020 at 9:07 PM  wrote:
>
> From: Dennis Gilmore 
>
> Move all aliases defintions into the main dts file
> Add u-boot definiton to i2c0 based on clearfog
> set spi1 status to okay
>
> Signed-off-by: Dennis Gilmore 
> ---
>  arch/arm/dts/armada-388-helios4-u-boot.dtsi | 23 -
>  arch/arm/dts/armada-388-helios4.dts | 14 -
>  2 files changed, 26 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/dts/armada-388-helios4-u-boot.dtsi 
> b/arch/arm/dts/armada-388-helios4-u-boot.dtsi
> index 0753889854..1047c1af23 100644
> --- a/arch/arm/dts/armada-388-helios4-u-boot.dtsi
> +++ b/arch/arm/dts/armada-388-helios4-u-boot.dtsi
> @@ -1,13 +1,5 @@
>  // SPDX-License-Identifier: GPL-2.0+
>
> -/ {
> -   aliases {
> -   i2c0 = 
> -   i2c1 = 
> -   spi1 = 
> -   };
> -};
> -
>   {
> phy-reset-gpios = < 19 GPIO_ACTIVE_LOW>;
>  };
> @@ -20,7 +12,6 @@
>  };
>
>   {
> -   status = "okay";
> u-boot,dm-spl;
>  };
>
> @@ -37,5 +28,17 @@
>  };
>
>   {
> -   u-boot,dm-spl;
> +   u-boot,dm-spl;
> +};
> +
> + {
> +   u-boot,dm-spl;
> +
> +   eeprom@52 {
> +   u-boot,dm-spl;
> +   };
> +
> +   eeprom@53 {
> +   u-boot,dm-spl;
> +   };
>  };
> diff --git a/arch/arm/dts/armada-388-helios4.dts 
> b/arch/arm/dts/armada-388-helios4.dts
> index fb49df2a3b..cbc296a46c 100644
> --- a/arch/arm/dts/armada-388-helios4.dts
> +++ b/arch/arm/dts/armada-388-helios4.dts
> @@ -22,10 +22,14 @@
> };
>
> aliases {
> -   /* So that mvebu u-boot can update the MAC addresses */
> +   /* So that mvebu u-boot can update the MAC address */
> ethernet1 = 
> +   spi1 = 
> +   i2c0 = 
> +   i2c1 = 
> };
>
> +
> chosen {
> stdout-path = "serial0:115200n8";
> };
> @@ -306,3 +310,11 @@
> };
> };
>  };
> +
> + {
> +   status = "okay";
> +};
> +
> + {
> +   status = "okay";
> +};
> --
> 2.28.0
>

Re: [PATCH v2 2/2] board: imx8mp: add boot.cmd for distro boot on iMX8MP

[Dennis Gilmore]

Hi Stefano,

I really do not think that this patch should have been merged. It is
not the preferred way to boot distros and is left in for legacy
support only.  We probably should make it as such.

Dennis

On Sat, Jan 23, 2021 at 9:53 AM  wrote:
>
> > From: Alice Guo 
> > Distro Boot requires a U-Boot-specific script named boot.scr or
> > boot.scr.uimg which contains boot commands to boot the system. The
> > boot.cmd is such a file. Use mkimage to generate boot.scr or
> > boot.scr.uimg from boot.cmd, and the command is:
> > mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "Distro Boot Script" 
> > -d boot.cmd boot.scr.uimg
> > The boot.cmd file is an example script and can be modified based on
> > needs. bootargs is set in this script and root uses the default value
> > "/dev/mmcblk1p2 rootwait rw" which can be changed by overriding mmcroot.
> > Signed-off-by: Alice Guo 
> Applied to u-boot-imx, master, thanks !
>
> Best regards,
> Stefano Babic
>
> --
> =
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
> =

Re: [EXT] Re: [PATCH v2 2/2] board: imx8mp: add boot.cmd for distro boot on iMX8MP

[Dennis Gilmore]

boot.scr is only in distro boot because prior to standardising in
extlinux.conf or grub vie efi, distros provided boot.scr files that
were tailored for each board with  detailed staps and memory locations
to load the kernel, dtb, and initramfs. the scripts were wrapped by
mkimage and at this point I would consider it to be a legacy thing
that possibly should be considered for deprecation. grub, extlinux, or
boot.scr should all be provided by the distro. u-boot just nees to
load whats provided.

Dennis

On Fri, Dec 18, 2020 at 5:11 AM Alice Guo (OSS)  wrote:
>
>
>
> > -Original Message-
> > From: Fabio Estevam 
> > Sent: 2020年12月18日 19:03
> > To: Alice Guo (OSS) 
> > Cc: Stefano Babic ; Peng Fan ;
> > dl-uboot-imx ; Ye Li ; U-Boot-Denx
> > ; Alice Guo ; Otavio Salvador
> > ; andrey.zhizhi...@leica-geosystems.com
> > Subject: [EXT] Re: [PATCH v2 2/2] board: imx8mp: add boot.cmd for distro 
> > boot
> > on iMX8MP
> >
> > Caution: EXT Email
> >
> > Hi Alice,
> >
> > On Fri, Dec 18, 2020 at 4:20 AM Alice Guo (OSS) 
> > wrote:
> >
> > > +++ b/board/freescale/imx8mp_evk/boot.cmd
> > > @@ -0,0 +1,25 @@
> > > +setenv bootargs console=${console} root=${mmcroot};
> > > +
> > > +for boot_target in ${boot_targets};
> >
> > This is not how distro boot support works.
> >
> > boot.scr or extlinux.conf scripts should be provided by the distro itself 
> > (Yocto,
> > Buildroot, Debian, etc), and not from U-Boot.
> >
> > Each distro has its own partitioning mechanism and may store the kernel, 
> > dtb in
> > different locations.
>
> Hi,
> Can you tell me where I can see more details about boot.scr? I didn't see 
> that " boot.scr or extlinux.conf scripts should be provided by the distro 
> itself".
> Thank you.
>
> Alice

Re: [PATCH] arm: mvebu: armada-xp-gp.dts: Add spi0 alias

[Dennis Gilmore]

Tested-by: Dennis Gilmore 

On Fri, 2020-12-11 at 05:47 +0100, Stefan Roese wrote:
> For correct spi bus detection the spi0 alias is needed in the DT.
> Otherwise this error will ocurr in U-Boot:
> 
> Invalid bus 0 (err=-19)
> Failed to initialize SPI flash at 0:0 (error -19)
> 
> Signed-off-by: Stefan Roese 
> Cc: Dennis Gilmore 
> ---
>  arch/arm/dts/armada-xp-gp.dts | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm/dts/armada-xp-gp.dts b/arch/arm/dts/armada-xp-
> gp.dts
> index 1139e9469a..d46475fe22 100644
> --- a/arch/arm/dts/armada-xp-gp.dts
> +++ b/arch/arm/dts/armada-xp-gp.dts
> @@ -31,6 +31,10 @@
> stdout-path = "serial0:115200n8";
> };
>  
> +   aliases {
> +   spi0 = 
> +   };
> +
> memory@0 {
> device_type = "memory";
> /*

Re: [PATCH] arm: mvebu: Add armada-xp-gp-u-boot.dtsi for U-Boot properties

[Dennis Gilmore]

Tested-by: Dennis Gilmore 

On Thu, 2020-12-10 at 06:40 +0100, Stefan Roese wrote:
> Add some missing "u-boot,dm-pre-reloc;" properties to UART0, SPI
> controller and SPI NOR flash node to enable usage in SPL. Otherwise
> these devices will not be available.
> 
> Signed-off-by: Stefan Roese 
> Cc: Dennis Gilmore 
> ---
>  arch/arm/dts/armada-xp-gp-u-boot.dtsi | 19 +++
>  1 file changed, 19 insertions(+)
>  create mode 100644 arch/arm/dts/armada-xp-gp-u-boot.dtsi
> 
> diff --git a/arch/arm/dts/armada-xp-gp-u-boot.dtsi
> b/arch/arm/dts/armada-xp-gp-u-boot.dtsi
> new file mode 100644
> index 00..2422856616
> --- /dev/null
> +++ b/arch/arm/dts/armada-xp-gp-u-boot.dtsi
> @@ -0,0 +1,19 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +/ {
> +   soc {
> +   internal-regs {
> +   serial@12000 {
> +   u-boot,dm-pre-reloc;
> +   };
> +   };
> +   };
> +};
> +
> + {
> +   u-boot,dm-pre-reloc;
> +
> +   spi-flash@0 {
> +   u-boot,dm-pre-reloc;
> +   };
> +};

Re: ARM: mvebu: enable SPI for helios4 and sata and uart images for clearfog

[Dennis Gilmore]

On Wed, Dec 9, 2020 at 7:57 AM Stefan Roese  wrote:
>
> Hi Dennis,
>
> On 09.12.20 04:07, dgilm...@redhat.com wrote:
> > In an effort to build SPI images for clearfog and helios4 I needed to make 
> > some
> > minor changes to the dts and Kconfig for the helios4 and set some variables 
> > for
> > UART and SATA images for ClearFog.
> >
> > Version 2 dropped changes for db-mv784mp-gp as the board turns out to be 
> > currently
> > broken, the serial port is not available and the system bails after loading 
> > the SPL
> > the dts changes for the helios4 have been shrunk back to remove everything 
> > not
> > needed or valid
>
> Could you please test this small patch on the db-mv784mp-gp and report
> back, if this works:
>
> diff --git a/arch/arm/dts/armada-xp-gp.dts b/arch/arm/dts/armada-xp-gp.dts
> index 1139e9469a..57aa58 100644
> --- a/arch/arm/dts/armada-xp-gp.dts
> +++ b/arch/arm/dts/armada-xp-gp.dts
> @@ -93,6 +93,7 @@
>  internal-regs {
>  serial@12000 {
>  status = "okay";
> +   u-boot,dm-pre-reloc;

with this dts change the serial port is registered correctly

Dennis
>      };
>  serial@12100 {
>  status = "okay";
>
>
> Thanks,
> Stefan
>


-- 
Dennis Gilmore
Multiple Architecture Portfolio Enablement
T: +1-312-660-3523

Re: Boot Over Ehternet- Linux Server to Raspberry Pis- Using U-boot

[Dennis Gilmore]

u-boot also supports pxe booting using a syslinux config file
https://github.com/u-boot/u-boot/blob/master/doc/README.pxe

Dennis

On Tue, Sep 15, 2020 at 5:43 PM Heinrich Schuchardt  wrote:
>
> On 9/1/20 2:49 PM, Ahsan Zia (TAU) wrote:
> > Hi All,
> >
> > I need some ideas regarding Boot Over Ehternet. I have been following the u 
> > boot document as well.
> >
> > I am attempting BoE from a Linux Server to a cluster of Raspberry Pis.
> >
> > i.e we have a Ubuntu (linux) Server with Raspbian image, the desired result 
> > is to somehow ''Mount'' the image, so that the Cluster of RPis can be 
> > booted-up using Ethernet? The image can be booted-up automatically when a 
> > new RPI is introduced into the system?
> >
> > The RPIs are Power over Ethernet, PoE hats and have Raspbian lite 
> > pre-installed. The image can be booted-up automatically when a new RPI is 
> > introduced into the system?
> >
> > Please post some ideas.
> >
> > Best Regards,
> > Ahsan Zia
> > Project Researcher,
> > Computing Sciences, Information Technology and Communication Sciences,
> > Tampere University.
> >
> >
>
> U-Boot supports booting via BOOTP and NFS:
> https://www.denx.de/wiki/publish/DULG/to-delete/LinuxNfsRoot.html
>
> Or you can use iSCSI using U-Boot and iPXE:
> https://u-boot.readthedocs.io/en/latest/uefi/iscsi.html
>
> But why do you need network boot if you already have Rasbian lite
> pre-installed on the Raspberries?
>
> What I would typically do in a cluster is to mount the working directory
> via iSCSI and keep the operating system on the SD card. This
> configuration is much more stable during OS updates then a network
> drive. And using an iSCSI server (e.g. on one of the RPis) I only need
> one SSD drive for the cluster.
>
> Best regards
>
> Heinrich

Re: [PATCH] defconfig: espressobin: enable NET_RANDOM_ETHADDR

[Dennis Gilmore]

I agree with Tom here, I have a few different systems that use this
feature, it is useful. I think most if not all of the systems I have
using it have Marvell SoC's

Dennis

On Fri, Sep 11, 2020 at 12:11 PM Tom Rini  wrote:
>
> On Fri, Sep 11, 2020 at 06:47:02PM +0200, Andre Heider wrote:
> > On 11/09/2020 18:22, Marek Behún wrote:
> > > On Fri, 11 Sep 2020 17:52:26 +0200
> > > Andre Heider  wrote:
> > >
> > > > Hi Marek,
> > > >
> > > > On 11/09/2020 13:55, Marek Behún wrote:
> > > > > On Wed, 9 Sep 2020 00:38:31 +0200 Pali Rohár 
> > > > > wrote:
> > > > > > On Tuesday 08 September 2020 08:52:56 Tom Rini wrote:
> > > > > > > Note that when CONFIG_NET_RANDOM_ETHADDR is set, we only use a
> > > > > > > random MAC address when we haven't found one either on the
> > > > > > > hardware or environment.
> > > > > >
> > > > > > I know.
> > > > > > > It also prints a warning that you are using a random MAC,
> > > > > > > so if it's documented on how to recover the real MAC a user should
> > > > > > > see that warning and fix it.
> > > > > >
> > > > > > In case you did backup of MAC address or you have MAC address
> > > > > > printed on sticker, you can restore it. If you loaded distribution
> > > > > > U-Boot which erase MAC address and you have not did any backup,
> > > > > > then your MAC address is forever lost.
> > > > >
> > > > > On Turris MOX we write the MAC address into OTP of the SOC during
> > > > > manufacturing.
> > > > >
> > > > > It is possible to write code that burns the MAC address into OTP, I
> > > > > consider this a better option than enabling random MAC address.
> > > > >
> > > > > Maybe we can enable random MAC address, and if MAC address is not
> > > > > found in environment nor OTP, issue a warning, something like
> > > > > "WARNING: MAC address lost, please burn the MAC address of your
> > > > > device to OTP with command xyz"
> > > > >
> > > > > What do you think?
> > > >
> > > > if there's a mac stored in otp during manufacturing, that's of course
> > > > the best solution. There's no need for CONFIG_NET_RANDOM_ETHADDR
> > > > then. But globalscale does not do that.
> > > >
> > > > Doing it afterwards, so u-boot claiming some otp space for itself,
> > > > and instructing the user how to write to it sounds too
> > > > dangerous/error-prone.
> > > >
> > > > For me CONFIG_NET_RANDOM_ETHADDR is a knob that should be enabled if
> > > > there's no mac address stored in a sane way (where saving it just to
> > > > an u-boot env during manufacturing doesn't count as sane, especially
> > > > if the vendor moves the spi env offset around in a firmware update).
> > > >
> > > > So I think CONFIG_NET_RANDOM_ETHADDR is enough.
> > > >
> > >
> > > I understand Pali's concerns, though.
> > >
> > > The thing is that if we enable CONFIG_NET_RANDOM_ETHADDR by default,
> > > many users that have managed to wipe their env won't care about that
> > > they are using randomly generated MAC address and won't solve the issue,
> > > which is again the spirit of correctly configure networks.
> > >
> > > If we do not enable CONFIG_NET_RANDOM_ETHADDR, the worst that can
> > > happen is that the device won't boot from network. This will force the
> > > users to solve the issue, which is not that hard
> > >setenv ethaddr aa:bb:cc:dd:ee:ff (address from the sticker)
> > >saveenv
> > > If the users boots from SD/eMMC/SATA/USB, Linux won't have problem with
> > > network, since it will generate random MAC address anyway.
> >
> > Good point, so let's assume the user doesn't have a mac stored.
> >
> > Without CONFIG_NET_RANDOM_ETHADDR:
> > * u-boot refuses to do anything network related
> > * Linux generates a random mac, network works
> >
> > With CONFIG_NET_RANDOM_ETHADDR:
> > * u-boot generates a random mac, network works
> > * Linux uses the same random mac, passed on from u-boot throught the
> > device-tree, network works
> >
> > It's still random, but at least it's consistent ;)
>
> It's also only used when we cannot find the MAC.  At the end of the day,
> the final decision here is Konstantin's (as the listed maintainer).  I
> personally think enabling the option is good given the apparent number
> of ways the real MAC will have been lost from SW, but if the maintainer
> wants to instead opt for a verbose failure message, that's fine too.
>
> --
> Tom

Re: [PATCH] ARM: Distro boot: document the need for fdtfile variable to be set

[Dennis Gilmore]

On Thu, Sep 3, 2020 at 3:24 PM Stephen Warren  wrote:
>
> On 9/3/20 2:14 PM, Dennis Gilmore wrote:
> > On Thu, Sep 3, 2020 at 2:15 PM Stephen Warren  wrote:
> >>
> >> On 9/3/20 10:40 AM, Dennis Gilmore wrote:
> >>> When testing builds provided in 
> >>> https://github.com/openwrt/openwrt/pull/3360
> >>> I discovered that fdtfile was not set and as a result the firmware was not
> >>> functional. So I am documenting what is needed.
> >>>
> >>> Signed-off-by: Dennis Gilmore 
> >>>
> >>> Cc: Atish Patra 
> >>> Cc: Lukas Auer 
> >>> Cc: Tom Rini 
> >>> Cc: Masahiro Yamada 
> >>> Cc: Vagrant Cascadian 
> >>> Cc: Stephen Warren 
> >>> Cc: Karsten Merker 
> >>> ---
> >>>  doc/README.distro | 8 
> >>>  1 file changed, 8 insertions(+)
> >>>
> >>> diff --git a/doc/README.distro b/doc/README.distro
> >>> index 5076bebd18..3eb70aeb14 100644
> >>> --- a/doc/README.distro
> >>> +++ b/doc/README.distro
> >>> @@ -224,6 +224,14 @@ fdt_addr_r:
> >>>
> >>>A size of 1MB for the FDT/DTB seems reasonable.
> >>>
> >>> +fdtfile:
> >>> +
> >>> +  Mandatory. the name of the DTB file for the specific board for instance
> >>> +  the espressobin v5 board the value is 
> >>> "marvell/armada-3720-espressobin.dtb"
> >>> +  while on a clearfog pro it is "armada-388-clearfog-pro.dtb" in the 
> >>> case of
> >>> +  a board providing its firmware based DTB this value can be used to 
> >>> override
> >>> +  the DTB with a different DTB.
> >>
> >> IIRC this variable isn't mandatory; if the DT filename follows expected
> >> ${soc}-${board}.dtb naming, then U-Boot has a default value that will
> >> work without the user or U-Boot author having to manually set this 
> >> variable.
> >>
> >> So it's certainly mandatory that U-Boot know this value at runtime, but
> >> perhaps the text should be expanded to indicate that sometimes U-Boot
> >> can provide the value itself, but sometimes the variable needs to be set?
> >
> > in include/config_distro_bootcmd.h we have the following
> > /*
> >  * On 32bit ARM systems there is a reasonable number of systems that follow
> >  * the $soc-$board$boardver.dtb name scheme for their device trees. Use that
> >  * scheme if we don't have an explicit fdtfile variable.
> >  */
> > #define BOOTENV_EFI_SET_FDTFILE_FALLBACK  \
> > "if test -z \"${fdtfile}\" -a -n \"${soc}\"; then "   \
> >   "setenv efi_fdtfile ${soc}-${board}${boardver}.dtb; "   \
> > "fi; "
> > #else
> > #define BOOTENV_EFI_SET_FDTFILE_FALLBACK
> > #endif
> >
> > that schema is not true on AArch64 and the method only works with efi
> > booting. I will update the text to list out the conditions you could
> > get away with not setting the variable
>
> I was thinking more of cmd/pxe_utils.c:label_boot(), which covers the
> extlinux.conf rather then EFI case. This certainly applies to both 32-
> and 64-bit Tegra systems at least.
>
> Specifically:
> >f1 = env_get("fdtfile");
> > if (f1) {
> > f2 = "";
> > f3 = "";
> > f4 = "";
> > } else {
> > /*
> >  * For complex cases where this code doesn't
> >  * generate the correct filename, the board
> >  * code should set $fdtfile during early 
> > boot,
> >  * or the boot scripts should set $fdtfile
> >  * before invoking "pxe" or "sysboot".
> >  */
> > f1 = env_get("soc");
> > f2 = "-";
> > f3 = env_get("board");
> > f4 = ".dtb";
> > }

That still only covers the 32-bit case, at least unless the OS is
removing the vendor directory from the dtbs. At least for fedora on
aarch64 we leave the vendor directories in place

ls /boot/dtb/
allwinner  amlogic  arm   cavium hisilicon  nvidia  rockchip
amdapm  broadcom  freescale  marvellqcomxilinx

though fedora is only supporting efi on AArch64

Dennis

Re: [PATCH] ARM: Distro boot: document the need for fdtfile variable to be set

[Dennis Gilmore]

On Thu, Sep 3, 2020 at 2:15 PM Stephen Warren  wrote:
>
> On 9/3/20 10:40 AM, Dennis Gilmore wrote:
> > When testing builds provided in https://github.com/openwrt/openwrt/pull/3360
> > I discovered that fdtfile was not set and as a result the firmware was not
> > functional. So I am documenting what is needed.
> >
> > Signed-off-by: Dennis Gilmore 
> >
> > Cc: Atish Patra 
> > Cc: Lukas Auer 
> > Cc: Tom Rini 
> > Cc: Masahiro Yamada 
> > Cc: Vagrant Cascadian 
> > Cc: Stephen Warren 
> > Cc: Karsten Merker 
> > ---
> >  doc/README.distro | 8 
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/doc/README.distro b/doc/README.distro
> > index 5076bebd18..3eb70aeb14 100644
> > --- a/doc/README.distro
> > +++ b/doc/README.distro
> > @@ -224,6 +224,14 @@ fdt_addr_r:
> >
> >A size of 1MB for the FDT/DTB seems reasonable.
> >
> > +fdtfile:
> > +
> > +  Mandatory. the name of the DTB file for the specific board for instance
> > +  the espressobin v5 board the value is 
> > "marvell/armada-3720-espressobin.dtb"
> > +  while on a clearfog pro it is "armada-388-clearfog-pro.dtb" in the case 
> > of
> > +  a board providing its firmware based DTB this value can be used to 
> > override
> > +  the DTB with a different DTB.
>
> IIRC this variable isn't mandatory; if the DT filename follows expected
> ${soc}-${board}.dtb naming, then U-Boot has a default value that will
> work without the user or U-Boot author having to manually set this variable.
>
> So it's certainly mandatory that U-Boot know this value at runtime, but
> perhaps the text should be expanded to indicate that sometimes U-Boot
> can provide the value itself, but sometimes the variable needs to be set?

in include/config_distro_bootcmd.h we have the following
/*
 * On 32bit ARM systems there is a reasonable number of systems that follow
 * the $soc-$board$boardver.dtb name scheme for their device trees. Use that
 * scheme if we don't have an explicit fdtfile variable.
 */
#define BOOTENV_EFI_SET_FDTFILE_FALLBACK  \
"if test -z \"${fdtfile}\" -a -n \"${soc}\"; then "   \
  "setenv efi_fdtfile ${soc}-${board}${boardver}.dtb; "   \
"fi; "
#else
#define BOOTENV_EFI_SET_FDTFILE_FALLBACK
#endif

that schema is not true on AArch64 and the method only works with efi
booting. I will update the text to list out the conditions you could
get away with not setting the variable

Dennis

[PATCH] ARM: Distro boot: document the need for fdtfile variable to be set

[Dennis Gilmore]

When testing builds provided in https://github.com/openwrt/openwrt/pull/3360
I discovered that fdtfile was not set and as a result the firmware was not
functional. So I am documenting what is needed.

Signed-off-by: Dennis Gilmore 

Cc: Atish Patra 
Cc: Lukas Auer 
Cc: Tom Rini 
Cc: Masahiro Yamada 
Cc: Vagrant Cascadian 
Cc: Stephen Warren 
Cc: Karsten Merker 
---
 doc/README.distro | 8 
 1 file changed, 8 insertions(+)

diff --git a/doc/README.distro b/doc/README.distro
index 5076bebd18..3eb70aeb14 100644
--- a/doc/README.distro
+++ b/doc/README.distro
@@ -224,6 +224,14 @@ fdt_addr_r:
 
   A size of 1MB for the FDT/DTB seems reasonable.
 
+fdtfile:
+
+  Mandatory. the name of the DTB file for the specific board for instance
+  the espressobin v5 board the value is "marvell/armada-3720-espressobin.dtb"
+  while on a clearfog pro it is "armada-388-clearfog-pro.dtb" in the case of
+  a board providing its firmware based DTB this value can be used to override
+  the DTB with a different DTB.
+
 ramdisk_addr_r:
 
   Mandatory. The location in RAM where the initial ramdisk will be loaded to
-- 
2.28.0

Re: U-Boot as ARM Coreboot Payload (for Chromebook Duet)

[Dennis Gilmore]

Simon,

Is there a way to replace the firmware on those boards with u-boot?  I
have a Tegra, a rockchip, and a pair of Samsung Exynos based
Chromebooks that are end of life for ChromeOS but are still quite
useful hardware platforms if there was a way to replace entirely the
bootloader with u-boot I could have hardware running supported
operating systems.

Dennis

On Sun, Aug 2, 2020 at 10:00 PM Simon Glass  wrote:
>
> Hi Matthew,
>
> On Sun, 2 Aug 2020 at 20:17, Matthew Grochowalski  wrote:
> >
> > Hello,
> >
> > Reading 
> > https://chromium.googlesource.com/chromiumos/docs/+/master/developer_mode.md,
> > it appears U-Boot should work as an alternate firmware on new ARM
> > Chromebooks.
> >
> > Trying on my Duet (Kukui/Krane), this doesn't work. Looking at the
> > RW_LEGACY contents, there's basically nothing there from the factory.
> >
> > I tried "make coreboot_defconfig" from u-boot master, but it looks
> > like this is x86 only.
> >
> > Any way to get this working on ARM(64)?
>
> I think this is Mediatek and U-Boot doesn't have support for that
> particular MT part, at least in mainline. I suspect it will happen at
> some point.
>
> The altfw U-Boot feature works on x86 Chromebooks only, at present.
> That said, most tegra and rockchip Chromebooks support U-Boot running
> 'bare-metal'.
>
> Regards,
> Simon

Re: [PATCH v1 1/2] arm: mvebu: correct SPL boot configs for SPI/MMC

[Dennis Gilmore]

resending from a different email address as Gmail rejected my first
attempt to send

On Sat, Apr 18, 2020 at 9:18 AM Dennis Gilmore
 wrote:
>
> On Fri, Apr 17, 2020 at 2:19 AM Joel Johnson  wrote:
> >
> > Update mvebu SPL boot selection mechanism for the move to driver model
> > usage by ensuring that the required driver support for SPI and MMC
> > booting is available in SPL when the respective boot method is
> > selected.
> >
> > Previously, all mvebu boards selected a boot method (implicitly
> > MVEBU_SPL_BOOT_DEVICE_SPI for many) even if SPL booting wasn't used.
> > This changes mvebu boot method selection to depend on SPL usage which
> > resolves the issue with aarch64 boards which don't use SPL getting an
> > implicit boot device selection resulting in unmet dependencies. The
> > 32-bit arm boards do use SPL, but I'm led to conclude that most aren't
> > intentionally using the MVEBU_SPL_BOOT_DEVICE selection since none have
> > SPL_DM_SPI enabled in their defconfig even though they still implicitly
> > select the SPI boot method.
> >
> > This also results in the new addition of SPL_GPIO_SUPPORT to helios4.
> > The mainline dts for helios4 includes the cd-gpios entry for sdhci with
> > identical addresses as the clearfog dts. I don't have a helios4 board
> > to confirm, but based on the current source conclude that the board
> > itself is either wired to pull the signal low for eMMC, or the default
> > MMC boot isn't fully functional in mainline. In either case, as far as
> > I can tell, including the GPIO support will at least cause no
> > regression.
>
> Currently, SPL does not find u-boot.bin on the helios4, I am working
> on syncing all of the changes done to clearfog to the helios4,
> generally speaking, any change made to clearfog needs to also, be made
> for the helios4 as they have the same SOM. the differences being in
> changes for the carrier board.
>
> Dennis
>
> > Tested on SolidRun ClearFog devices.
> >
> > Signed-off-by: Joel Johnson 
> >
> > ---
> >
> > This patch unifies two patches from a prior ClearFog specific series
> > which caused issues when building for most other mvebu boards. Now
> > build and config diff tested for all arm and aarch64 mvebu boards!
> >
> > The only substantive changes end up being the SPL dependency for boot
> > selection, along with defconfig cleanups with Kconfig consolidated
> > boot dependent values.
> >
> > The superfluous addition of SPL_MTD_SUPPORT present in the prior patch
> > for SPI booting was also removed.
> >
> > ---
> >  arch/arm/mach-mvebu/Kconfig | 12 
> >  configs/clearfog_defconfig  |  3 ---
> >  configs/controlcenterdc_defconfig   |  4 
> >  configs/db-88f6720_defconfig|  4 
> >  configs/db-88f6820-amc_defconfig|  4 
> >  configs/db-88f6820-gp_defconfig |  4 
> >  configs/db-mv784mp-gp_defconfig |  3 ---
> >  configs/ds414_defconfig |  3 ---
> >  configs/helios4_defconfig   |  1 -
> >  configs/maxbcm_defconfig|  3 ---
> >  configs/theadorable_debug_defconfig |  3 ---
> >  configs/turris_omnia_defconfig  |  4 
> >  configs/x530_defconfig  |  4 
> >  include/configs/helios4.h   |  5 -
> >  14 files changed, 12 insertions(+), 45 deletions(-)
> >
> > diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
> > index 161dee937f..645990b3ef 100644
> > --- a/arch/arm/mach-mvebu/Kconfig
> > +++ b/arch/arm/mach-mvebu/Kconfig
> > @@ -232,13 +232,25 @@ config SYS_SOC
> >
> >  choice
> > prompt "Boot method"
> > +   depends on SPL
> >
> >  config MVEBU_SPL_BOOT_DEVICE_SPI
> > bool "SPI NOR flash"
> > +   imply ENV_IS_IN_SPI_FLASH
> > +   select SPL_DM_SPI
> > +   select SPL_SPI_FLASH_SUPPORT
> > +   select SPL_SPI_LOAD
> > +   select SPL_SPI_SUPPORT
> >
> >  config MVEBU_SPL_BOOT_DEVICE_MMC
> > bool "SDIO/MMC card"
> > +   imply ENV_IS_IN_MMC
> > +   # GPIO needed for eMMC/SD card presence detection
> > +   select SPL_DM_GPIO
> > +   select SPL_DM_MMC
> > +   select SPL_GPIO_SUPPORT
> > select SPL_LIBDISK_SUPPORT
> > +   select SPL_MMC_SUPPORT
> >
> >  config MVEBU_SPL_BOOT_DEVICE_SATA
> > bool "SATA"
> > diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig
> > index 6db8b8acf6..ada35cb53b 100644
&g

Re: [U-Boot] [PATCH] arm: mvebu: helios4: Enable CONFIG_BLK and CONFIG_DM_MMC

[Dennis Gilmore]

Reviewed-by: Dennis Gilmore 
Tested-by: Dennis Gilmore 

On Mon, May 20, 2019 at 2:53 AM Stefan Roese  wrote:
>
> This patch enables CONFIG_BLK and CONFIG_DM_MMC on helios4 to remove
> these compile warnings:
>
> = WARNING ==
> This board does not use CONFIG_DM_MMC. Please update
> the board to use CONFIG_DM_MMC before the v2019.04 release.
> Failure to update by the deadline may result in board removal.
> See doc/driver-model/MIGRATION.txt for more info.
> 
> = WARNING ==
> This board does not use CONFIG_DM_USB. Please update
> the board to use CONFIG_DM_USB before the v2019.07 release.
> Failure to update by the deadline may result in board removal.
> See doc/driver-model/MIGRATION.txt for more info.
> ====
>
> Signed-off-by: Stefan Roese 
> Cc: Dennis Gilmore 
> ---
>  configs/helios4_defconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/configs/helios4_defconfig b/configs/helios4_defconfig
> index 62c2979a51..3b1737b385 100644
> --- a/configs/helios4_defconfig
> +++ b/configs/helios4_defconfig
> @@ -44,6 +44,7 @@ CONFIG_DM_I2C=y
>  CONFIG_I2C_SET_DEFAULT_BUS_NUM=y
>  CONFIG_I2C_DEFAULT_BUS_NUMBER=0x1
>  CONFIG_SYS_I2C_MVTWSI=y
> +CONFIG_DM_MMC=y
>  CONFIG_MMC_SDHCI=y
>  CONFIG_MMC_SDHCI_SDMA=y
>  CONFIG_MMC_SDHCI_MV=y
> --
> 2.21.0
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 0/6] Update support for Helios4 board

[Dennis Gilmore]

Series
Tested-By: Dennis Gilmore 
Reviewed-By: Dennis Gilmore 

El mié, 05-12-2018 a las 00:57 +0800, Aditya Prayoga escribió:
> Hi everyone,
> 
> This series add some missing peripheral support and fixed that was
> implemented on U-Boot 2013.01 Marvell version: 2015_T1.0p16
> - helios4: mmc: move environment before 1M
> - helios4: Enable I2C and IO Expander
> - helios4: Reset uSOM onboard phy during board init
> 
> and added new peripheral support and improvement
> - helios4: Enable mvebu GPIO
> - helios4: Enable SPI flash support
> - helios4: Reduce U-Boot image size
> 
> ---
> Notes
>   checkpatch.pl emit "WARNING: added, moved or deleted file(s), does
> MAINTAINERS need updating?" on 0002-arm-mvebu-helios4-Enable-I2C-
> and-
> IO-Expander.patch due to new file, armada-388-helios4-u-boot.dtsi
> 
> ---
> Changes v1 -> v2:
>   * Remove arm: mvebu: helios4: Update Load address patch.
>   * Rearrange the patch, enabling I2C and convert I2C IO expander to
> DM
> should applied together.
>   * Move u-boot specific properties into armada-388-helios4-u-
> boot.dtsi
> (Dennis Gilmore)
>   * Use generic gpio_* API to do phy reset (Baruch Siach)
> Changes v2 -> v3:
>   * Use named gpios for PHY reset (Stefan Roese)
> ---
> Aditya Prayoga (6):
>   arm: mvebu: helios4: mmc: move environment before 1M
>   arm: mvebu: helios4: Enable I2C and IO Expander
>   arm: mvebu: helios4: Enable mvebu GPIO
>   arm: mvebu: helios4: Reduce U-Boot image size
>   arm: mvebu: helios4: Enable SPI flash support
>   arm: mvebu: helios4: Reset uSOM onboard phy during board init
> 
>  arch/arm/dts/armada-388-helios4-u-boot.dtsi | 22 +
>  board/kobol/helios4/helios4.c   | 32 ---
>  configs/helios4_defconfig   | 13 +---
>  include/configs/helios4.h   | 48
> -
>  4 files changed, 64 insertions(+), 51 deletions(-)
>  create mode 100644 arch/arm/dts/armada-388-helios4-u-boot.dtsi
> 

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] net: mvneta: Add GPIO configuration support

[Dennis Gilmore]

Tested-By: Dennis Gilmore 

El mié, 05-12-2018 a las 00:39 +0800, Aditya Prayoga escribió:
> This patch add GPIO configuration support in mvneta driver.
> Driver will handle PHY reset. GPIO pins should be set in device tree.
> 
> Ported from mvpp2x
> [https://patchwork.ozlabs.org/patch/799654/]
> 
> Initial discussion to port the changes into mvneta
> [https://patchwork.ozlabs.org/patch/1005765/]
> 
> Signed-off-by: Aditya Prayoga 
> ---
>  drivers/net/mvneta.c | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/drivers/net/mvneta.c b/drivers/net/mvneta.c
> index 8cb04b5..333be8f 100644
> --- a/drivers/net/mvneta.c
> +++ b/drivers/net/mvneta.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  DECLARE_GLOBAL_DATA_PTR;
>  
> @@ -274,6 +275,9 @@ struct mvneta_port {
>   int init;
>   int phyaddr;
>   struct phy_device *phydev;
> +#ifdef CONFIG_DM_GPIO
> + struct gpio_desc phy_reset_gpio;
> +#endif
>   struct mii_dev *bus;
>  };
>  
> @@ -1749,6 +1753,17 @@ static int mvneta_probe(struct udevice *dev)
>   if (ret)
>   return ret;
>  
> +#ifdef CONFIG_DM_GPIO
> + gpio_request_by_name(dev, "phy-reset-gpios", 0,
> +  >phy_reset_gpio, GPIOD_IS_OUT);
> +
> + if (dm_gpio_is_valid(>phy_reset_gpio)) {
> + dm_gpio_set_value(>phy_reset_gpio, 1);
> + mdelay(10);
> + dm_gpio_set_value(>phy_reset_gpio, 0);
> + }
> +#endif
> +
>   return board_network_enable(bus);
>  }
>  

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/7] arm: mvebu: helios4: Enable I2C

[Dennis Gilmore]

El jue, 29-11-2018 a las 00:42 +0700, Aditya Prayoga escribió:
> On Wed, Nov 28, 2018 at 8:44 PM Dennis Gilmore 
> wrote:
> > On Wed, 2018-11-28 at 16:59 +0800, Aditya Prayoga wrote:
> > > Enable Marvell I2C driver and set default bus to external I2C
> > > bus.
> > > Define I2C aliases in device tree so it can be recognized by the
> > > driver.
> > > 
> > > Signed-off-by: Aditya Prayoga 
> > > ---
> > >  arch/arm/dts/armada-388-helios4.dts | 2 ++
> > >  configs/helios4_defconfig   | 3 +++
> > >  2 files changed, 5 insertions(+)
> > > 
> > > diff --git a/arch/arm/dts/armada-388-helios4.dts
> > > b/arch/arm/dts/armada-388-helios4.dts
> > > index a154e0f..711fc22 100644
> > > --- a/arch/arm/dts/armada-388-helios4.dts
> > > +++ b/arch/arm/dts/armada-388-helios4.dts
> > > @@ -24,6 +24,8 @@
> > >   aliases {
> > >   /* So that mvebu u-boot can update the MAC
> > > addresses */
> > >   ethernet1 = 
> > > + i2c0 = 
> > > + i2c1 = 
> > 
> > have you sent the dts changes to the linux kernel also?
> 
> No, I haven't. Should I also send it to Linux kernel? WIthout those
> aliases, Linux
> can detect the i2c buses.

we should put them in -u-boot.dtsi files if they are not needed then. 
u-boot has been trying to make sure that they can sync devicetree files
from the kernel without modification.

Dennis

> Aditya
> 
> > Dennis
> > >   };
> > > 
> > >   chosen {
> > > diff --git a/configs/helios4_defconfig
> > > b/configs/helios4_defconfig
> > > index e30eb3d..8ac8978 100644
> > > --- a/configs/helios4_defconfig
> > > +++ b/configs/helios4_defconfig
> > > @@ -39,6 +39,9 @@ CONFIG_NET_RANDOM_ETHADDR=y
> > >  CONFIG_SPL_OF_TRANSLATE=y
> > >  CONFIG_SCSI_AHCI=y
> > >  CONFIG_DM_I2C=y
> > > +CONFIG_SYS_I2C_MVTWSI=y
> > > +CONFIG_I2C_SET_DEFAULT_BUS_NUM=y
> > > +CONFIG_I2C_DEFAULT_BUS_NUMBER=0x1
> > >  CONFIG_MMC_SDHCI=y
> > >  CONFIG_MMC_SDHCI_SDMA=y
> > >  CONFIG_MMC_SDHCI_MV=y

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 6/7] arm: mvebu: helios4: Enable SPI flash support

[Dennis Gilmore]

On Wed, 2018-11-28 at 17:00 +0800, Aditya Prayoga wrote:
> Enable SPI flash support under U-Boot and SPL. The ENV size and
> offset,
> ported from U-Boot 2013.01 Marvell version: 2015_T1.0p16
> 
> To create U-Boot image for SPI flash, user would need to replace
> * CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC with
> CONFIG_MVEBU_SPL_BOOT_DEVICE_SPI
> * CONFIG_ENV_IS_IN_MMC with CONFIG_ENV_IS_IN_SPI_FLASH
> 
> Signed-off-by: Aditya Prayoga 
> ---
>  arch/arm/dts/armada-388-helios4.dts |  7 +++
>  configs/helios4_defconfig   |  1 -
>  include/configs/helios4.h   | 31
> +++
>  3 files changed, 38 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/dts/armada-388-helios4.dts
> b/arch/arm/dts/armada-388-helios4.dts
> index 711fc22..cd3fcae 100644
> --- a/arch/arm/dts/armada-388-helios4.dts
> +++ b/arch/arm/dts/armada-388-helios4.dts
> @@ -26,6 +26,7 @@
>   ethernet1 = 
>   i2c0 = 
>   i2c1 = 
> + spi1 = 
has this gone upstream to the kernel?
>   };
>  
>   chosen {
> @@ -244,6 +245,7 @@
>_spi1_cs_pins>;
>   pinctrl-names = "default";
>   status = "okay";
> + u-boot,dm-spl;
there is a method in u-boot that needs to be used where u-boot specific
snippets go into a -u-boot.dts file, I am struggling to
find the documentation on it, perhaps someone else can point us both at
it.

>   };
>  
>   sdhci@d8000 {
> @@ -308,3 +310,8 @@
>   };
>   };
>  };
> +
> + {
> + status = "okay";
> + u-boot,dm-spl;
> +};
same as above the u-boot bit should go in a armada-388-helios4-u-
boot.dts file and the generic bits in the upstream kernel dts file.

Dennis

> diff --git a/configs/helios4_defconfig b/configs/helios4_defconfig
> index 53995fe..3bb4622 100644
> --- a/configs/helios4_defconfig
> +++ b/configs/helios4_defconfig
> @@ -6,7 +6,6 @@ CONFIG_SPL_LIBGENERIC_SUPPORT=y
>  CONFIG_SYS_MALLOC_F_LEN=0x2000
>  CONFIG_TARGET_HELIOS4=y
>  CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC=y
> -CONFIG_SPL_MMC_SUPPORT=y
>  CONFIG_SPL_SERIAL_SUPPORT=y
>  CONFIG_SPL_SYS_MALLOC_SIMPLE=y
>  CONFIG_SPL=y
> diff --git a/include/configs/helios4.h b/include/configs/helios4.h
> index bd59ecf..6943378 100644
> --- a/include/configs/helios4.h
> +++ b/include/configs/helios4.h
> @@ -6,6 +6,8 @@
>  #ifndef _CONFIG_HELIOS4_H
>  #define _CONFIG_HELIOS4_H
>  
> +#include 
> +
>  /*
>   * High Level Configuration Options (easy to change)
>   */
> @@ -23,6 +25,9 @@
>  
>  /* SPI NOR flash default params, used by sf commands */
>  #define CONFIG_SF_DEFAULT_BUS1
> +#define CONFIG_SF_DEFAULT_CS 0
> +#define CONFIG_SF_DEFAULT_SPEED  10400
> +#define CONFIG_SF_DEFAULT_MODE   SPI_MODE_3
>  
>  /*
>   * SDIO/MMC Card Configuration
> @@ -43,6 +48,21 @@
>  #define CONFIG_SYS_SCSI_MAX_DEVICE  (CONFIG_SYS_SCSI_MAX_SCSI_ID
> * \
>   CONFIG_SYS_SCSI_MAX_LUN)
>  
> +#ifdef CONFIG_MVEBU_SPL_BOOT_DEVICE_SPI
> +/*
> + * SPI Flash configuration for the environment access
> + */
> +#define CONFIG_ENV_SPI_BUS   CONFIG_SF_DEFAULT_BUS
> +#define CONFIG_ENV_SPI_CSCONFIG_SF_DEFAULT_CS
> +#define CONFIG_ENV_SPI_MAX_HZCONFIG_SF_DEFAULT_SPEED
> +
> +/* Environment in SPI NOR flash */
> +#define CONFIG_ENV_SECT_SIZE SZ_64K
> +#define CONFIG_ENV_SIZE  CONFIG_ENV_SECT_SIZE
> +#define CONFIG_ENV_OFFSETSZ_1M
> +#endif
> +
> +#ifdef CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC
>  /* Environment in MMC */
>  #define CONFIG_SYS_MMC_ENV_DEV   0
>  #define CONFIG_ENV_SECT_SIZE 0x200
> @@ -50,6 +70,7 @@
>  /* stay within first 1M */
>  #define CONFIG_ENV_OFFSET(SZ_1M - CONFIG_ENV_SIZE)
>  #define CONFIG_ENV_ADDR  CONFIG_ENV_OFFSET
> +#endif
>  
>  #define CONFIG_PHY_MARVELL   /* there is a marvell phy */
>  #define PHY_ANEG_TIMEOUT 8000/* PHY needs a longer aneg
> time */
> @@ -69,7 +90,13 @@
>   */
>  #define SPL_BOOT_SPI_NOR_FLASH   1
>  #define SPL_BOOT_SDIO_MMC_CARD   2
> +
> +#ifdef CONFIG_MVEBU_SPL_BOOT_DEVICE_SPI
> +#define CONFIG_SPL_BOOT_DEVICE   SPL_BOOT_SPI_NOR_FLASH
> +#endif
> +#ifdef CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC
>  #define CONFIG_SPL_BOOT_DEVICE   SPL_BOOT_SDIO_MMC_CARD
> +#endif
>  
>  /* Defines for SPL */
>  #define CONFIG_SPL_SIZE  (140 << 10)
> @@ -88,12 +115,16 @@
>  
>  #if CONFIG_SPL_BOOT_DEVICE == SPL_BOOT_SPI_NOR_FLASH
>  /* SPL related SPI defines */
> +#define CONFIG_SPL_SPI_FLASH_SUPPORT
> +#define CONFIG_SPL_SPI_LOAD
> +#define CONFIG_SPL_SPI_SUPPORT
>  #define CONFIG_SYS_SPI_U_BOOT_OFFS   0x2
>  #define CONFIG_SYS_U_BOOT_OFFS   CONFIG_SYS_SPI_U_BOOT_O
> FFS
>  #endif
>  
>  #if 

Re: [U-Boot] [PATCH 3/7] arm: mvebu: helios4: Enable I2C

[Dennis Gilmore]

On Wed, 2018-11-28 at 16:59 +0800, Aditya Prayoga wrote:
> Enable Marvell I2C driver and set default bus to external I2C bus.
> Define I2C aliases in device tree so it can be recognized by the
> driver.
> 
> Signed-off-by: Aditya Prayoga 
> ---
>  arch/arm/dts/armada-388-helios4.dts | 2 ++
>  configs/helios4_defconfig   | 3 +++
>  2 files changed, 5 insertions(+)
> 
> diff --git a/arch/arm/dts/armada-388-helios4.dts
> b/arch/arm/dts/armada-388-helios4.dts
> index a154e0f..711fc22 100644
> --- a/arch/arm/dts/armada-388-helios4.dts
> +++ b/arch/arm/dts/armada-388-helios4.dts
> @@ -24,6 +24,8 @@
>   aliases {
>   /* So that mvebu u-boot can update the MAC addresses */
>   ethernet1 = 
> + i2c0 = 
> + i2c1 = 

have you sent the dts changes to the linux kernel also?

Dennis
>   };
>  
>   chosen {
> diff --git a/configs/helios4_defconfig b/configs/helios4_defconfig
> index e30eb3d..8ac8978 100644
> --- a/configs/helios4_defconfig
> +++ b/configs/helios4_defconfig
> @@ -39,6 +39,9 @@ CONFIG_NET_RANDOM_ETHADDR=y
>  CONFIG_SPL_OF_TRANSLATE=y
>  CONFIG_SCSI_AHCI=y
>  CONFIG_DM_I2C=y
> +CONFIG_SYS_I2C_MVTWSI=y
> +CONFIG_I2C_SET_DEFAULT_BUS_NUM=y
> +CONFIG_I2C_DEFAULT_BUS_NUMBER=0x1
>  CONFIG_MMC_SDHCI=y
>  CONFIG_MMC_SDHCI_SDMA=y
>  CONFIG_MMC_SDHCI_MV=y

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/7] arm: mvebu: helios4: Update Load address

[Dennis Gilmore]

I would strongly prefer to keep the addresses consistent across
platforms in u-boot. Is there bugs you are seeing as a result of this?

Dennis

On Wed, 2018-11-28 at 16:59 +0800, Aditya Prayoga wrote:
> Use the values from U-Boot 2013.01 Marvell version: 2015_T1.0p16
> 
> Signed-off-by: Aditya Prayoga 
> ---
>  include/configs/helios4.h | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/include/configs/helios4.h b/include/configs/helios4.h
> index ce912ea..c289490 100644
> --- a/include/configs/helios4.h
> +++ b/include/configs/helios4.h
> @@ -145,11 +145,11 @@
>   func(PXE, pxe, na) \
>   func(DHCP, dhcp, na)
>  
> -#define KERNEL_ADDR_R__stringify(0x80)
> -#define FDT_ADDR_R   __stringify(0x10)
> -#define RAMDISK_ADDR_R   __stringify(0x180)
> -#define SCRIPT_ADDR_R__stringify(0x20)
> -#define PXEFILE_ADDR_R   __stringify(0x30)
> +#define KERNEL_ADDR_R__stringify(0x208)
> +#define FDT_ADDR_R   __stringify(0x204)
> +#define RAMDISK_ADDR_R   __stringify(0x288)
> +#define SCRIPT_ADDR_R__stringify(0x300)
> +#define PXEFILE_ADDR_R   __stringify(0x310)
>  
>  #define LOAD_ADDRESS_ENV_SETTINGS \
>   "kernel_addr_r=" KERNEL_ADDR_R "\0" \

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/2] dm: Complete CONFIG_BLK migration

[Dennis Gilmore]

El mié, 27-06-2018 a las 17:40 -0400, Tom Rini escribió:
> On Sat, Jun 23, 2018 at 07:59:30AM -0600, Simon Glass wrote:
> > The time has come to migrate all boards to use CONFIG_BLK. This
> > series
> > is just a test to see what boards would have to be removed if we
> > required
> > CONFIG_BLK, as we plan to after the next release.
> > 
> > This should help maintainers see what is impacted.
> > 
> > Hopefully maintainers will be able to convert their boards over in
> > the
> > next month so we we can avoid having to remove any boards.
> > 
> > The goal is to have all boards use driver model. But so far, we do
> > allow
> > CONFIG_DM to not be defined.
> > 
> > 
> > For 'Force BLK', here is the buildman output showing failed boards
> > and the
> > relatively small number of command errors:
> > 
> > 03: Force BLK
> >   mips:  +   pic32mzdask
> >arm:  +   mixtile_loftq colibri_imx6_nospl sniper
> > omap3_zoom1 tbs2910 Mele_A1000G_quad
> > am335x_igep003x mx6ul_14x14_evk mk802_a10s am43xx_hs_evm devkit3250
> > pcm051_rev3
> > am57xx_hs_evm Empire_electronix_m712 Auxtek-T003 pcm058 zc5202
> > am335x_shc
> > am335x_shc_ict Hummingbird_A31 vining_2000 am335x_evm_usbspl
> > ot1200_spl igep00x0
> > Mele_I7 Wobo_i5 r7-tv-dongle liteboard omap3_overo am335x_boneblack
> > evb-ast2500
> > warp7 gwventana_gw5904 cairo A13-OLinuXinoM mccmon6_sd
> > apalis_imx6_nospl_it
> > wandboard birdland_bav335a colibri_imx7 colibri_imx6 inet_q972
> > xpress_spl
> > stm32f429-evaluation udoo_neo igep0032 Mele_M9 A13-OLinuXino
> > inet98v_rev2
> > A10s-OLinuXino-M riotboard snapper9260 am43xx_evm pfla02
> > mx6qsabrelite
> > apalis_imx6_nospl_com s5p_goni colibri_pxa270 snapper9g20
> > Yones_Toptech_BS1078_V2 am335x_shc_sdboot_prompt k2g_hs_evm cl-som-
> > imx7
> > am335x_shc_sdboot vf610twr_nand stm32f469-discovery am335x_evm_nor
> > mx53cx9020
> > Empire_electronix_d709 vf610twr cm_t43 pengwyn stm32f746-disco
> > Sinovoip_BPI_M2
> > Sinovoip_BPI_M3 Sinlinx_SinA31s pico-imx7d am43xx_evm_rtconly
> > LicheePi_Zero
> > pcm051_rev1 mccmon6_nor mx6sabreauto display5_factory
> > am335x_shc_prompt
> > gwventana_nand Bananapi_M2_Ultra Auxtek-T004 tbs_a711 cm_t335
> > h8_homlet_v2
> > Colombus am43xx_evm_usbhost_boot chiliboard am335x_baltos
> > colibri_vf
> > mx6ul_9x9_evk kp_imx6q_tpc bk4r1 udoo difrnce_dit4350
> > am335x_evm_norboot
> > UTOO_P66 iNet_86VS marsboard MSI_Primo81 apalis_imx6
> > bananapi_m2_berry
> > xilinx_zynqmp_r5 birdland_bav335b am43xx_evm_qspiboot CSQ_CS908
> > Ampe_A76
> > kp_imx53 am335x_evm_spiboot Cubietruck_plus k2g_evm mx6sabresd
> > omap3_logic
> > pepper colorfly_e708_q1 pcm052 gwventana_emmc
> > am335x_boneblack_vboot
> > am335x_shc_netboot xpress ot1200 cgtqmx6eval zc5601 devkit8000
> > dh_imx6 mx6cuboxi
> > am57xx_evm am335x_sl50 q8_a13_tablet sksimx6
> > 
> > microblaze:  +   microblaze-generic
> >powerpc:  +   P1010RDB-PA_36BIT_NOR_SECBOOT
> > BSC9132QDS_SDCARD_DDRCLK100_SECURE
> > P1010RDB-PB_SPIFLASH_SECBOOT T1024QDS_DDR4_SECURE_BOOT
> > controlcenterd_36BIT_SDCARD BSC9132QDS_SDCARD_DDRCLK133_SECURE
> > P1010RDB-PA_SPIFLASH_SECBOOT BSC9132QDS_NAND_DDRCLK133_SECURE
> > P1010RDB-PA_36BIT_SPIFLASH_SECBOOT P2041RDB_SECURE_BOOT
> > P5020DS_NAND_SECURE_BOOT
> > P1010RDB-PB_36BIT_NOR_SECBOOT BSC9132QDS_NOR_DDRCLK100_SECURE
> > P3041DS_SECURE_BOOT T1042D4RDB_SECURE_BOOT T1042RDB_SECURE_BOOT
> > T4240QDS_SECURE_BOOT P1010RDB-PB_36BIT_SPIFLASH_SECBOOT P1010RDB-
> > PB_NAND_SECBOOT
> > BSC9132QDS_SPIFLASH_DDRCLK100_SECURE P3041DS_NAND_SECURE_BOOT
> > T4160QDS_SECURE_BOOT T2080RDB_SECURE_BOOT B4860QDS_SECURE_BOOT
> > P4080DS_SECURE_BOOT T2080QDS_SECURE_BOOT P5040DS_SECURE_BOOT
> > P1010RDB-PB_36BIT_NAND_SECBOOT controlcenterd_36BIT_SDCARD_DEVELOP
> > P1010RDB-PA_NAND_SECBOOT BSC9132QDS_SPIFLASH_DDRCLK133_SECURE
> > P1010RDB-PA_NOR_SECBOOT controlcenterd_TRAILBLAZER_DEVELOP
> > P5020DS_SECURE_BOOT
> > T1024QDS_SECURE_BOOT T1040QDS_SECURE_BOOT
> > BSC9132QDS_NOR_DDRCLK133_SECURE
> > T1024RDB_SECURE_BOOT P5040DS_NAND_SECURE_BOOT P1010RDB-
> > PA_36BIT_NAND_SECBOOT
> > T1042RDB_PI_NAND_SECURE_BOOT T1040RDB_SECURE_BOOT
> > T1040D4RDB_SECURE_BOOT
> > BSC9132QDS_NAND_DDRCLK100_SECURE P1010RDB-PB_NOR_SECBOOT
> > T1023RDB_SECURE_BOOT
> > controlcenterd_TRAILBLAZER
> 
> So, how are the maintainers CC'd on this feeling about the
> deadline?  It
> was supposed to be 2018.05, but it's looking like we would enforce it
> for 2018.09 at this point in time.

My board was added around this time according to the email list it was
added on June 12th, 11 days before this email went out. I have not
changed anything that would affect this in the meantime, and there was
zero followups until today. I feel a bit caught off guard by it all. is
there a doc somewhere that outlines the needed changes?

Dennis

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 0/5] Add support for Pinebook

[Dennis Gilmore]

El sáb, 03-11-2018 a las 17:12 -0700, Vasily Khoruzhick escribió:
> On Sat, Nov 3, 2018 at 2:15 PM André Przywara  > wrote:
> > On 11/3/18 8:19 PM, Vasily Khoruzhick wrote:
> > > You need "allwinner" branch from this repo.
> > 
> > I deliberately switched the standard branch away, since everything
> > is
> > merged in mainline ATF now (including PMIC support). I will post U-
> > Boot
> > patches to change the instructions soon, but just use the master
> > branch
> > from the official repo (and report back any issues!):
> > https://github.com/ARM-Software/arm-trusted-firmware.git
> > 
> > You might need the latest DT in U-Boot (patches are queued, AFAIK)
> > to
> > let ATF know about your PMIC requirements.
> 
> Thanks, I just tested it - and my patches work fine with ATF from
> official repo.

I have just tested with ATF from the official repo and it all works.

Thanks

Dennis

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 0/5] Add support for Pinebook

[Dennis Gilmore]

I have tested the series on my pinebook on top of git commit
99431c1c21685fe63d46b6eac995b78ce9adce0a

I am not sure if video is expected to work or not, in my case it does
not work. 

U-Boot SPL 2018.11-rc3-00027-g77a46c3a3c (Nov 03 2018 - 13:42:47 -0500)
DRAM: 2048 MiB
Trying to boot from MMC1
NOTICE:  BL31: v1.6(release):
NOTICE:  BL31: Built : 09:10:17, Sep 23 2018
NOTICE:  BL31: Detected Allwinner A64/H64/R18 SoC (1689)
NOTICE:  BL31: STUB PMIC setup code called


U-Boot 2018.11-rc3-00027-g77a46c3a3c (Nov 03 2018 - 13:42:47 -0500)
Allwinner Technology

CPU:   Allwinner A64 (SUN50I)
Model: Pinebook
DRAM:  2 GiB
MMC:   SUNXI SD/MMC: 0, SUNXI SD/MMC: 1
Loading Environment from FAT... *** Warning - bad CRC, using default
environment

Warning: HDMI PHY init timeout!
Warning: HDMI PHY init timeout!
In:serial
Out:   serial
Err:   serial

u-boot however works fine and the system is able to boot and the
correct dtb is loaded.

Tested-by: Dennis Gilmore 

El mar, 30-10-2018 a las 14:36 -0700, Vagrant Cascadian escribió:
> Tested series applied to u-boot 2018.11-rc3 on pinebook, both with
> reboot and cold boot.
> 
> Thanks for all the work on it!
> 
> Tested-by: Vagrant Cascadian 
> 
> On 2018-10-28, Vasily Khoruzhick wrote:
> > This series adds support for the Pinebook, an allwinner A64 laptop
> > produced by Pine64. It also syncs sun50i-a64.dtsi with linux,
> > adds support for mmc delay calibration, R_I2C controller,
> > and addresses the issue with activating video bridge when any of
> > GPIOs is missing.
> > 
> > v2: - sync sun50i-a64.dtsi with linux instead of adding missing
> > nodes
> > - take sun50i-a64-pinebook.dts from linux
> > - don't introduce new Kconfig for A64 MMC calibration
> > - improve code in video bridge uclass to check for presensce of
> >   GPIO instead of ingoring EINVAL errors
> > v3: - enable calibration for H6 as well
> > - init ret variable in video_bridge_set_active()
> > - fix order of dts files Makefile
> > - split anx6345 binding into sun50i-a64-pinebook-u-boot.dts
> > - drop speaker_amp node from pinebook dts
> > - drop unnecessary options from defconfig
> > v4: - sync device tree files with linux-next
> > 
> > Vasily Khoruzhick (5):
> >   mmc: sunxi: add support for automatic delay calibration
> >   dm: video: bridge: don't fail to activate bridge if reset or
> > sleep
> > GPIO is missing
> >   sunxi: DT: A64: update device tree files for Allwinner A64 SoC
> >   sun50i: A64: add support for R_I2C controller
> >   sunxi: DT: add support for Pinebook
> > 
> >  arch/arm/dts/Makefile|   1 +
> >  arch/arm/dts/sun50i-a64-amarula-relic.dts| 168 +-
> >  arch/arm/dts/sun50i-a64-bananapi-m64.dts |  34 +-
> >  arch/arm/dts/sun50i-a64-nanopi-a64.dts   |  89 +-
> >  arch/arm/dts/sun50i-a64-olinuxino.dts| 103 +-
> >  arch/arm/dts/sun50i-a64-orangepi-win.dts | 179 ++-
> >  arch/arm/dts/sun50i-a64-pine64.dts   |  32 +-
> >  arch/arm/dts/sun50i-a64-pinebook-u-boot.dtsi |  15 +
> >  arch/arm/dts/sun50i-a64-pinebook.dts | 294
> > +
> >  arch/arm/dts/sun50i-a64-sopine-baseboard.dts |  32 +-
> >  arch/arm/dts/sun50i-a64-sopine.dtsi  |  15 +
> >  arch/arm/dts/sun50i-a64.dtsi | 313
> > +--
> >  arch/arm/include/asm/arch-sunxi/gpio.h   |   1 +
> >  arch/arm/include/asm/arch-sunxi/mmc.h|   6 +-
> >  arch/arm/mach-sunxi/Kconfig  |   1 +
> >  board/sunxi/board.c  |   6 +
> >  configs/pinebook_defconfig   |  22 ++
> >  drivers/mmc/sunxi_mmc.c  |  21 +-
> >  drivers/video/bridge/video-bridge-uclass.c   |  16 +-
> >  19 files changed, 1296 insertions(+), 52 deletions(-)
> >  create mode 100644 arch/arm/dts/sun50i-a64-pinebook-u-boot.dtsi
> >  create mode 100644 arch/arm/dts/sun50i-a64-pinebook.dts
> >  create mode 100644 configs/pinebook_defconfig
> > 
> > -- 
> > 2.19.1
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] U-Boot and The Boot Loader Specification

[Dennis Gilmore]

El vie, 19-10-2018 a las 12:12 +0200, Wolfgang Denk escribió:
> Dear Alexander,
> 
> In message <118460556.a0Y5euKZZ7@ada> you wrote:
> > >  864 /*
> > >  865  * Keywords recognized.
> > >  866  */
> > >  867 static const struct token keywords[] = {
> > >  868 {"menu", T_MENU},
> > >  869 {"title", T_TITLE},
> > >  870 {"timeout", T_TIMEOUT},
> > >  871 {"default", T_DEFAULT},
> > >  872 {"prompt", T_PROMPT},
> > >  873 {"label", T_LABEL},
> > >  874 {"kernel", T_KERNEL},
> > >  875 {"linux", T_LINUX},
> > >  876 {"localboot", T_LOCALBOOT},
> > >  877 {"append", T_APPEND},
> > >  878 {"initrd", T_INITRD},
> > >  879 {"include", T_INCLUDE},
> > >  880 {"devicetree", T_FDT},
> > >  881 {"fdt", T_FDT},
> > >  882 {"devicetreedir", T_FDTDIR},
> > >  883 {"fdtdir", T_FDTDIR},
> > >  884 {"ontimeout", T_ONTIMEOUT,},
> > >  885 {"ipappend", T_IPAPPEND,},
> > >  886 {NULL, T_INVALID}
> > >  887 };
> > > 
> > > This does not fit with your description, as you list:
> > > > Ignoring unknown command: title
> > > > Ignoring unknown command: version
> > > > Ignoring unknown command: options
> > > > Ignoring unknown command: linux
> > > > Ignoring unknown command: devicetree
> > > 
> > > OK, "version" and "options" are not implemented, but the other
> > > keywords are, so you must be doing something else wrong.
> > 
> > That's what I was saying. I suppose the handling of label and title
> > is 
> > different, so the entry group I had below 'title' was not
> > recognized as group 
> > of options for one entry, like it was when replacing title with
> > label. I can 
> > write an actually working extlinux.conf file (as showed in my last
> > mail), but 
> > that was not the question I had in the first place.
> 
> Well, what confuses me here is that you cleanly show error messages
> for example for title, linux, and devicetree, even though these
> should be recognized as valid keywords.
> 
> I think there are sublte imcompatibilities in your config file
> (and/or bugs in the code).  See also this comment (same file):
> 
>  440  * A note on the pxe file parser.
>  441  *
>  442  * We're parsing files that use syslinux grammar, which has a
> few quirks.
>  443  * String literals must be recognized based on context - there
> is no
>  444  * quoting or escaping support. There's also nothing to
> explicitly indicate
>  445  * when a label section completes. We deal with that by ending a
> label
>  446  * section whenever we see a line that doesn't include.
>  447  *
>  448  * As with the syslinux family, this same file format could be
> reused in the
>  449  * future for non pxe purposes. The only action it takes during
> parsing that
>  450  * would throw this off is handling of include files. It assumes
> we're using
>  451  * pxe, and does a tftp download of a file listed as an include
> file in the
>  452  * middle of the parsing operation. That could be handled by
> refactoring it to
>  453  * take a 'include file getter' function.
> 
> > The U-Boot documentation in the file 'doc/README.distro' could lead
> > to the 
> > impression as if U-Boot would support the BootLoaderSpec and even
> > links to it: 
> > http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/
> > 
> > That spec says basically, in my own words: "put one conf file for
> > each boot 
> > menu item in the directory /boot/loader/entries and let it have the
> > following 
> > format." 
> > 
> > The keywords differ from the ones used by extlinux/U-Boot, in my
> > opinion the 
> > U-Boot documentation in 'doc/README.distro' however is not very
> > clear about 
> > that.
> 
> I'm adding Dennis on Cc: who submitted the doc; I hope he has a
> better understanding of the state of things.

Sorry for the slow response, I have been travelling,  currently u-boot
does not support the boot loader spec, it was a goal that no-one found
the time to solve, the main issue being how to we traverse the
directories to parse all the snippets.

> > Is U-Boot supposed to honour that Boot Loader Specification?
> 
> I think it should, if possible.
> 
> > If yes: then it does not work as specified. Is anybody working on
> > making U-
> > Boot comply?
> 
> None that I know of.
There is no one working on it, I should remove the link to
BootLoaderSpec 

> > If no: would anybody mind changing the documentation to better
> > reflect what U-
> > Boot actually does and not mislead people into thinking U-Boot
> > would be 
> > compliant to that specification (like it was the case for me)? I
> > would send a 
> > patch if nobody objects.
> 
> Can we not do it the other way round, and fix the code that it
> improves and conforms (better) to the spec?

We could, I have not yet found a way to solve the problems. It would be
nice to solve them

Dennis
> Best regards,
> 
> Wolfgang Denk
> 

Re: [U-Boot] [PATCH 4/6] mvebu: select boot device at SoC level

[Dennis Gilmore]

Weird git am failed for me so I had to tweak the patch. I must have done 
something wrong on my end. I did test on the helios4 after applying the set and 
it booted fine

On 6 August 2018 2:13:33 pm GMT+02:00, Stefan Roese  wrote:
>Hi Baruch,
>
>On 06.08.2018 12:12, Baruch Siach wrote:
>> Hi Dennis,
>> 
>> Thanks for taking the time to look into this series.
>> 
>> Dennis Gilmore writes:
>>> this patch needs to be rebased on git master as it does not apply.
>> 
>> The conflict is trivial for git to handle automatically on rebase
>> (remove, remove). I assume 'git am -3' can do the same. Would you
>like
>> me to send v2 of this series for that?
>
>Seems to be fine. I just tried it and it applies fine, resolving
>the conflicts automatically. No new version necessary.
>
>Thanks,
>Stefan

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 4/6] mvebu: select boot device at SoC level

[Dennis Gilmore]

Hi Baruch,

this patch needs to be rebased on git master as it does not apply.

Thanks

Dennis
El lun, 18-06-2018 a las 21:56 +0300, Baruch Siach escribió:
> Move the gdsys Controlcenter DC specific build time kwbimage.cfg
> generation code into the mach-mvebu/ directory to be shared by all
> 32bit
> mvebu platforms.
> 
> Remove board specific kwbimage.cfg files, and use the generated one
> instead. These files are all identical, with two exceptions. Clearfog
> and Helios4 use the sdio boot device, whereas all others use spi.
> Update
> the defconfigs for the exceptional boards to generate the same
> kwbimage.cfg as before.
> 
> Signed-off-by: Baruch Siach 
> ---
>  .../a38x => arch/arm/mach-mvebu}/.gitignore   |  0
>  arch/arm/mach-mvebu/Makefile  | 30
> ++
>  arch/arm/mach-mvebu/include/mach/config.h |  4 +--
>  .../arm/mach-mvebu}/kwbimage.cfg.in   |  0
>  board/CZ.NIC/turris_omnia/kwbimage.cfg| 12 ---
>  board/Marvell/db-88f6720/kwbimage.cfg | 12 ---
>  board/Marvell/db-88f6820-amc/kwbimage.cfg | 12 ---
>  board/Marvell/db-88f6820-gp/kwbimage.cfg  | 12 ---
>  board/Marvell/db-mv784mp-gp/kwbimage.cfg  | 12 ---
>  board/Synology/ds414/kwbimage.cfg | 12 ---
>  board/gdsys/a38x/Makefile | 31 ---
> 
>  board/kobol/helios4/kwbimage.cfg  | 13 
>  board/maxbcm/kwbimage.cfg | 12 ---
>  board/solidrun/clearfog/kwbimage.cfg  | 12 ---
>  board/theadorable/kwbimage.cfg| 12 ---
>  configs/clearfog_defconfig|  2 +-
>  configs/helios4_defconfig |  2 +-
>  17 files changed, 34 insertions(+), 156 deletions(-)
>  rename {board/gdsys/a38x => arch/arm/mach-mvebu}/.gitignore (100%)
>  rename {board/gdsys/a38x => arch/arm/mach-mvebu}/kwbimage.cfg.in
> (100%)
>  delete mode 100644 board/CZ.NIC/turris_omnia/kwbimage.cfg
>  delete mode 100644 board/Marvell/db-88f6720/kwbimage.cfg
>  delete mode 100644 board/Marvell/db-88f6820-amc/kwbimage.cfg
>  delete mode 100644 board/Marvell/db-88f6820-gp/kwbimage.cfg
>  delete mode 100644 board/Marvell/db-mv784mp-gp/kwbimage.cfg
>  delete mode 100644 board/Synology/ds414/kwbimage.cfg
>  delete mode 100644 board/kobol/helios4/kwbimage.cfg
>  delete mode 100644 board/maxbcm/kwbimage.cfg
>  delete mode 100644 board/solidrun/clearfog/kwbimage.cfg
>  delete mode 100644 board/theadorable/kwbimage.cfg
> 
> diff --git a/board/gdsys/a38x/.gitignore b/arch/arm/mach-
> mvebu/.gitignore
> similarity index 100%
> rename from board/gdsys/a38x/.gitignore
> rename to arch/arm/mach-mvebu/.gitignore
> diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-
> mvebu/Makefile
> index ade7b870646f..d907fac3752d 100644
> --- a/arch/arm/mach-mvebu/Makefile
> +++ b/arch/arm/mach-mvebu/Makefile
> @@ -25,6 +25,36 @@ obj-$(CONFIG_ARMADA_375) +=
> ../../../drivers/ddr/marvell/axp/xor.o
>  obj-$(CONFIG_ARMADA_38X) += ../../../drivers/ddr/marvell/a38x/xor.o
>  obj-$(CONFIG_ARMADA_XP) += ../../../drivers/ddr/marvell/axp/xor.o
>  obj-$(CONFIG_MVEBU_EFUSE) += efuse.o
> +
> +extra-y += kwbimage.cfg
> +
> +KWB_REPLACE += BOOT_FROM
> +ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_SPI),)
> + KWB_CFG_BOOT_FROM=spi
> +endif
> +ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC),)
> + KWB_CFG_BOOT_FROM=sdio
> +endif
> +
> +ifneq ($(CONFIG_SECURED_MODE_IMAGE),)
> +KWB_REPLACE += CSK_INDEX
> +KWB_CFG_CSK_INDEX = $(CONFIG_SECURED_MODE_CSK_INDEX)
> +
> +KWB_REPLACE += SEC_BOOT_DEV
> +KWB_CFG_SEC_BOOT_DEV=$(patsubst "%",%, \
> + $(if $(findstring
> BOOT_SPI_NOR_FLASH,$(CONFIG_SPL_BOOT_DEVICE)),0x34) \
> + $(if $(findstring
> BOOT_SDIO_MMC_CARD,$(CONFIG_SPL_BOOT_DEVICE)),0x31) \
> + )
> +
> +KWB_REPLACE += SEC_FUSE_DUMP
> +KWB_CFG_SEC_FUSE_DUMP = a38x
> +endif
> +
> +$(src)/kwbimage.cfg: $(src)/kwbimage.cfg.in include/autoconf.mk \
> + include/config/auto.conf
> + $(Q)sed -ne '$(foreach V,$(KWB_REPLACE),s/^#@$(V)/$(V)
> $(KWB_CFG_$(V))/;)p' \
> + <$< >$(dir $<)$(@F)
> +
>  endif # CONFIG_SPL_BUILD
>  obj-y+= gpio.o
>  obj-y+= mbus.o
> diff --git a/arch/arm/mach-mvebu/include/mach/config.h
> b/arch/arm/mach-mvebu/include/mach/config.h
> index 2acfd3314a68..9f51411e43f1 100644
> --- a/arch/arm/mach-mvebu/include/mach/config.h
> +++ b/arch/arm/mach-mvebu/include/mach/config.h
> @@ -32,12 +32,12 @@
>  #endif
>  
>  /*
> - * By default kwbimage.cfg from board specific folder is used
> + * By default the generated mvebu kwbimage.cfg is used
>   * If for some board, different configuration file need to be used,
>   * CONFIG_SYS_KWD_CONFIG should be defined in board specific header
> file
>   */
>  #ifndef CONFIG_SYS_KWD_CONFIG
> -#define  CONFIG_SYS_KWD_CONFIG   $(CONFIG_BOARDDIR)/kwbimage.c
> fg
> +#define  CONFIG_SYS_KWD_CONFIG   arch/arm/mach-
> mvebu/kwbimage.cfg
>  #endif /* CONFIG_SYS_KWD_CONFIG */
>  
>  /* Add target to build it 

Re: [U-Boot] [PATCH 1/4] arm: mvebu: solidrun-microsom: update SPI flash compatible

[Dennis Gilmore]

El vie, 15-06-2018 a las 19:01 +0300, Baruch Siach escribió:
> Hi Dennis,
> 
> On Fri, Jun 15, 2018 at 10:40:20AM -0500, Dennis Gilmore wrote:
> > On Thu, 2018-06-14 at 22:23 +0300, Baruch Siach wrote:
> > > On Thu, Jun 14, 2018 at 02:10:31PM -0500, Dennis Gilmore wrote:
> > > > running sf probe on one of my clearfogs with this set of
> > > > patches
> > > > applied I got 
> > > > 
> > > > SF: unrecognized JEDEC id bytes: ff, ff, ff
> > > > Failed to initialize SPI flash at 1:0 (error -2)
> > > 
> > > Do you use the clearfog_defconfig?
> > 
> > yes I did, I am testing on a clearfog pro
> > 
> > > Does current U-Boot master work for you?
> > 
> > 2018.03 fails the same. I have another clearfog pro and a clearfog
> > base
> > I can test with, though I have the internal mmc on my base and now
> > wish
> > I had not done so.
> > 
> > > For the record, on my Clearfog Base 'sf probe' shows:
> > > 
> > > SF: Detected w25q32bv with page size 256 Bytes, erase size 4 KiB,
> > > total 4 MiB
> > > 
> > > This works with or without these patches.
> > 
> > mine does not work either way, so it is no worse off. I would like
> > to
> > put u-boot in SPI on them all 
> 
> Can you read/write the SPI flash from Linux?
Sorry, I have been travelling, I can not access the SPI flash from
Linux, I currently do not have physical access to my solid-run based
boards. Nothing in my testing is any worse off.

Dennis

> baruch
> 
> > > > On Thu, 2018-06-14 at 18:17 +0300, Baruch Siach wrote:
> > > > > Add the "spi-flash" compatible string so that the generic
> > > > > sf_probe
> > > > > driver can probe the SPI flash on the SolidRun SOM.
> > > > > 
> > > > > Signed-off-by: Baruch Siach 
> > > > > ---
> > > > >  arch/arm/dts/armada-38x-solidrun-microsom.dtsi | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
> > > > > b/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
> > > > > index a2627223ce3b..74f58de85c43 100644
> > > > > --- a/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
> > > > > +++ b/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
> > > > > @@ -86,7 +86,7 @@
> > > > >   w25q32: spi-flash@0 {
> > > > >   #address-cells = <1>;
> > > > >   #size-cells = <1>;
> > > > > - compatible = "w25q32", "jedec,spi-nor";
> > > > > + compatible = "w25q32", "jedec,spi-nor",
> > > > > "spi-
> > > > > flash";
> > > > >   reg = <0>; /* Chip select 0 */
> > > > >   spi-max-frequency = <300>;
> > > > >   status = "disabled";
> 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/4] arm: mvebu: solidrun-microsom: update SPI flash compatible

[Dennis Gilmore]

On Thu, 2018-06-14 at 22:23 +0300, Baruch Siach wrote:
> Hi Dennis,
> 
> On Thu, Jun 14, 2018 at 02:10:31PM -0500, Dennis Gilmore wrote:
> > running sf probe on one of my clearfogs with this set of patches
> > applied I got 
> > 
> > SF: unrecognized JEDEC id bytes: ff, ff, ff
> > Failed to initialize SPI flash at 1:0 (error -2)
> 
> Do you use the clearfog_defconfig?

yes I did, I am testing on a clearfog pro

> 
> Does current U-Boot master work for you?
2018.03 fails the same. I have another clearfog pro and a clearfog base
I can test with, though I have the internal mmc on my base and now wish
I had not done so.


> 
> For the record, on my Clearfog Base 'sf probe' shows:
> 
> SF: Detected w25q32bv with page size 256 Bytes, erase size 4 KiB,
> total 4 MiB
> 
> This works with or without these patches.
mine does not work either way, so it is no worse off. I would like to
put u-boot in SPI on them all 

Dennis

> baruch
> 
> > Dennis
> > 
> > On Thu, 2018-06-14 at 18:17 +0300, Baruch Siach wrote:
> > > Add the "spi-flash" compatible string so that the generic
> > > sf_probe
> > > driver can probe the SPI flash on the SolidRun SOM.
> > > 
> > > Signed-off-by: Baruch Siach 
> > > ---
> > >  arch/arm/dts/armada-38x-solidrun-microsom.dtsi | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
> > > b/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
> > > index a2627223ce3b..74f58de85c43 100644
> > > --- a/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
> > > +++ b/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
> > > @@ -86,7 +86,7 @@
> > >   w25q32: spi-flash@0 {
> > >   #address-cells = <1>;
> > >   #size-cells = <1>;
> > > - compatible = "w25q32", "jedec,spi-nor";
> > > + compatible = "w25q32", "jedec,spi-nor", "spi-
> > > flash";
> > >   reg = <0>; /* Chip select 0 */
> > >   spi-max-frequency = <300>;
> > >   status = "disabled";
> 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/4] arm: mvebu: solidrun-microsom: update SPI flash compatible

[Dennis Gilmore]

running sf probe on one of my clearfogs with this set of patches
applied I got 

SF: unrecognized JEDEC id bytes: ff, ff, ff
Failed to initialize SPI flash at 1:0 (error -2)


Dennis


On Thu, 2018-06-14 at 18:17 +0300, Baruch Siach wrote:
> Add the "spi-flash" compatible string so that the generic sf_probe
> driver can probe the SPI flash on the SolidRun SOM.
> 
> Signed-off-by: Baruch Siach 
> ---
>  arch/arm/dts/armada-38x-solidrun-microsom.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
> b/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
> index a2627223ce3b..74f58de85c43 100644
> --- a/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
> +++ b/arch/arm/dts/armada-38x-solidrun-microsom.dtsi
> @@ -86,7 +86,7 @@
>   w25q32: spi-flash@0 {
>   #address-cells = <1>;
>   #size-cells = <1>;
> - compatible = "w25q32", "jedec,spi-nor";
> + compatible = "w25q32", "jedec,spi-nor", "spi-flash";
>   reg = <0>; /* Chip select 0 */
>   spi-max-frequency = <300>;
>   status = "disabled";
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] arm: mvebu: clearfog: use the microsom .dtsi

[Dennis Gilmore]

Reviewed-by: Dennis Gilmore 
Tested-by: Dennis Gilmore 

On Thu, 2018-06-14 at 18:17 +0300, Baruch Siach wrote:
> Use hardware description from the recently introduced microsom .dtsi
> file to reduce duplication.
> 
> Signed-off-by: Baruch Siach 
> ---
>  arch/arm/dts/armada-388-clearfog.dts | 63 +++---
> --
>  1 file changed, 6 insertions(+), 57 deletions(-)
> 
> diff --git a/arch/arm/dts/armada-388-clearfog.dts
> b/arch/arm/dts/armada-388-clearfog.dts
> index a0b566a5ae0e..1403600e5b02 100644
> --- a/arch/arm/dts/armada-388-clearfog.dts
> +++ b/arch/arm/dts/armada-388-clearfog.dts
> @@ -50,6 +50,7 @@
>  #include 
>  #include 
>  #include "armada-388.dtsi"
> +#include "armada-38x-solidrun-microsom.dtsi"
>  
>  / {
>   model = "SolidRun Clearfog A1";
> @@ -70,11 +71,6 @@
>   stdout-path = "serial0:115200n8";
>   };
>  
> - memory {
> - device_type = "memory";
> - reg = <0x 0x1000>; /* 256 MB */
> - };
> -
>   reg_3p3v: regulator-3p3v {
>   compatible = "regulator-fixed";
>   regulator-name = "3P3V";
> @@ -84,11 +80,6 @@
>   };
>  
>   soc {
> - ranges =  -   MBUS_ID(0x01, 0x1d) 0 0xfff0 0x10
> -   MBUS_ID(0x09, 0x19) 0 0xf110 0x1
> -   MBUS_ID(0x09, 0x15) 0 0xf111 0x1>;
> -
>   internal-regs {
>   ethernet@3 {
>   mac-address = [00 50 43 02 02 02];
> @@ -108,15 +99,6 @@
>   status = "okay";
>   };
>  
> - ethernet@7 {
> - mac-address = [00 50 43 02 02 01];
> - pinctrl-0 = <_rgmii_pins>;
> - pinctrl-names = "default";
> - phy = <_dedicated>;
> - phy-mode = "rgmii-id";
> - status = "okay";
> - };
> -
>   i2c@11000 {
>   /* Is there anything on this? */
>   clock-frequency = <10>;
> @@ -226,22 +208,6 @@
>   status = "okay";
>   };
>  
> - mdio@72004 {
> - pinctrl-0 = <_pins>;
> - pinctrl-names = "default";
> -
> - phy_dedicated: ethernet-phy@0 {
> - /*
> -  * Annoyingly, the marvell
> phy driver
> -  * configures the LED
> register, rather
> -  * than preserving reset-
> loaded setting.
> -  * We undo that rubbish
> here.
> -  */
> - marvell,reg-init = <3 16 0
> 0x101e>;
> - reg = <0>;
> - };
> - };
> -
>   pinctrl@18000 {
>   clearfog_dsa0_clk_pins: clearfog-
> dsa0-clk-pins {
>   marvell,pins = "mpp46";
> @@ -260,12 +226,6 @@
>   marvell,pins = "mpp20";
>   marvell,function = "gpio";
>   };
> - clearfog_sdhci_pins: clearfog-sdhci-
> pins {
> - marvell,pins = "mpp21",
> "mpp28",
> -"mpp37",
> "mpp38",
> -"mpp39",
> "mpp40";
> - marvell,function = "sd0";
> - };
>   clearfog_spi1_cs_pins: spi1-cs-pins
> {
>   marvell,pins = "mpp55";
>   marvell,function = "spi1";
> @@ -311,7 +271,7 @@
>   bus-width = <4>;
>   cd-gpios = < 20
> GPIO_ACTIVE_LOW>;
>   n

Re: [U-Boot] [PATCH 3/4] arm: mvebu: Better align Clearfog dts file with Linux kernel

[Dennis Gilmore]

Reviewed-by: Dennis Gilmore 
Tested-by: Dennis Gilmore 

On Thu, 2018-06-14 at 18:17 +0300, Baruch Siach wrote:
> From: Jon Nettleton 
> 
> This makes changes so the u-boot dts file is structured more
> similar to the mainline linux dtsi file.  It provides a minimal
> common dts that can work for most boards based on the ClearFog
> platform.  Ethernet support is only supported for eth0 however
> all devices are left enabled so u-boot can generate and
> provide mac addresses for all of the network interfaces.
> 
> Signed-off-by: Jon Nettleton 
> [baruch: rebase on recent changes]
> Signed-off-by: Baruch Siach 
> ---
>  arch/arm/dts/armada-388-clearfog.dts | 386 +++
> 
>  1 file changed, 151 insertions(+), 235 deletions(-)
> 
> diff --git a/arch/arm/dts/armada-388-clearfog.dts
> b/arch/arm/dts/armada-388-clearfog.dts
> index 1403600e5b02..16a47d59e667 100644
> --- a/arch/arm/dts/armada-388-clearfog.dts
> +++ b/arch/arm/dts/armada-388-clearfog.dts
> @@ -81,174 +81,6 @@
>  
>   soc {
>   internal-regs {
> - ethernet@3 {
> - mac-address = [00 50 43 02 02 02];
> - phy-mode = "sgmii";
> - status = "okay";
> -
> - fixed-link {
> - speed = <1000>;
> - full-duplex;
> - };
> - };
> -
> - ethernet@34000 {
> - mac-address = [00 50 43 02 02 03];
> - managed = "in-band-status";
> - phy-mode = "sgmii";
> - status = "okay";
> - };
> -
> - i2c@11000 {
> - /* Is there anything on this? */
> - clock-frequency = <10>;
> - pinctrl-0 = <_pins>;
> - pinctrl-names = "default";
> - status = "okay";
> -
> - /*
> -  * PCA9655 GPIO expander, up to 1MHz
> clock.
> -  *  0-CON3 CLKREQ#
> -  *  1-CON3 PERST#
> -  *  2-CON2 PERST#
> -  *  3-CON3 W_DISABLE
> -  *  4-CON2 CLKREQ#
> -  *  5-USB3 overcurrent
> -  *  6-USB3 power
> -  *  7-CON2 W_DISABLE
> -  *  8-JP4 P1
> -  *  9-JP4 P4
> -  * 10-JP4 P5
> -  * 11-m.2 DEVSLP
> -  * 12-SFP_LOS
> -  * 13-SFP_TX_FAULT
> -  * 14-SFP_TX_DISABLE
> -  * 15-SFP_MOD_DEF0
> -  */
> - expander0: gpio-expander@20 {
> - /*
> -  * This is how it should be:
> -  * compatible =
> "onnn,pca9655",
> -  *   "nxp,pca9555";
> -  * but you can't do this
> because of
> -  * the way I2C works.
> -  */
> - compatible = "nxp,pca9555";
> - gpio-controller;
> - #gpio-cells = <2>;
> - reg = <0x20>;
> -
> - pcie1_0_clkreq {
> - gpio-hog;
> - gpios = <0
> GPIO_ACTIVE_LOW>;
> - input;
> - line-name =
> "pcie1.0-clkreq";
> - };
> - pcie1_0_w_disable {
> - gpio-hog;
> - gpios = <3
> GPIO_ACTIVE_LOW>;
> - output-low;
> - line-name =
> "pcie1.0-w-disable";
> - 

Re: [U-Boot] [PATCH 4/4] arm: mvebu: helios4: remove duplicate sdhci pins node

[Dennis Gilmore]

Reviewed-by: Dennis Gilmore 
Tested-by: Dennis Gilmore 

On Thu, 2018-06-14 at 18:17 +0300, Baruch Siach wrote:
> The same pinctrl node appears in the solidrun-microsom dtsi. Use that
> instead.
> 
> Cc: Dennis Gilmore 
> Signed-off-by: Baruch Siach 
> ---
>  arch/arm/dts/armada-388-helios4.dts | 8 +---
>  1 file changed, 1 insertion(+), 7 deletions(-)
> 
> diff --git a/arch/arm/dts/armada-388-helios4.dts
> b/arch/arm/dts/armada-388-helios4.dts
> index 049d32296475..a154e0f4f477 100644
> --- a/arch/arm/dts/armada-388-helios4.dts
> +++ b/arch/arm/dts/armada-388-helios4.dts
> @@ -248,7 +248,7 @@
>   bus-width = <4>;
>   cd-gpios = < 20
> GPIO_ACTIVE_LOW>;
>   no-1-8-v;
> - pinctrl-0 = <_sdhci_pins
> + pinctrl-0 = <_sdhci_pins
>_sdhci_cd_pins>;
>   pinctrl-names = "default";
>   status = "okay";
> @@ -286,12 +286,6 @@
>   marvell,pins = "mpp20";
>   marvell,function = "gpio";
>   };
> - helios_sdhci_pins: helios-sdhci-pins 
> {
> - marvell,pins = "mpp21",
> "mpp28",
> -"mpp37",
> "mpp38",
> -"mpp39",
> "mpp40";
> - marvell,function = "sd0";
> - };
>   helios_led_pins: helios-led-pins {
>   marvell,pins = "mpp24",
> "mpp25",
>  "mpp49",
> "mpp50",
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC] arm: mvebu: Add Helios4 Armada 38x initial support

[Dennis Gilmore]

El mar, 29-05-2018 a las 08:41 +0200, Stefan Roese escribió:
> Hi Dennis,
> 
> On 26.05.2018 22:02, dgilm...@redhat.com wrote:
> > From: Dennis Gilmore 
> > 
> > The helios4 is built on the SolidRun Armada 38x SOM.
> 
> Which specific SoM?
https://www.solid-run.com/introducing-helios4-personal-cloud/ is
announcing it from SolidRun it is based on https://www.solid-run.com/ma
rvell-armada-family/armada-som-system-on-module/ the one used in the
helios4 has 2GiB of ECC ram. The microsom is split out in the kernel
dts files https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linu
x.git/tree/arch/arm/boot/dts/armada-38x-solidrun-microsom.dtsi 


> 
> > The port os based on the ClearFog board, using information from
> > https://github.com/helios-4/u-boot-marvell as well as dtb input
> > from https://github.com/helios-4/linux-marvell
> > 
> > Currently ECC is not enabled
ECC is enabled and working, it had not been earlier.

> > Signed-off-by: Dennis Gilmore 
> 
> Please address all the comments that Chris already mentioned in his
> review.

Working on addressing them all.

Thanks

Dennis
> Thanks,
> Stefan
> 
> > ---
> >   arch/arm/dts/Makefile   |   1 +
> >   arch/arm/dts/armada-388-helios4.dts | 454
> > 
> >   arch/arm/mach-mvebu/Kconfig |   7 +
> >   board/solidrun/helios4/MAINTAINERS  |   6 +
> >   board/solidrun/helios4/Makefile |   5 +
> >   board/solidrun/helios4/README   |  46 +++
> >   board/solidrun/helios4/helios4.c| 160 ++
> >   board/solidrun/helios4/kwbimage.cfg |  12 +
> >   configs/helios4_defconfig   |  57 
> >   include/configs/helios4.h   | 185 
> >   10 files changed, 933 insertions(+)
> >   create mode 100644 arch/arm/dts/armada-388-helios4.dts
> >   create mode 100644 board/solidrun/helios4/MAINTAINERS
> >   create mode 100644 board/solidrun/helios4/Makefile
> >   create mode 100644 board/solidrun/helios4/README
> >   create mode 100644 board/solidrun/helios4/helios4.c
> >   create mode 100644 board/solidrun/helios4/kwbimage.cfg
> >   create mode 100644 configs/helios4_defconfig
> >   create mode 100644 include/configs/helios4.h
> > 
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index a0349a8975..a18f4bbf7b 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -91,6 +91,7 @@ dtb-$(CONFIG_ARCH_MVEBU) +=   
> > \
> > armada-375-db.dtb   \
> > armada-388-clearfog.dtb \
> > armada-388-gp.dtb   \
> > +   armada-388-helios4.dtb  \
> > armada-385-amc.dtb  \
> > armada-7040-db.dtb  \
> > armada-7040-db-nand.dtb \
> > diff --git a/arch/arm/dts/armada-388-helios4.dts
> > b/arch/arm/dts/armada-388-helios4.dts
> > new file mode 100644
> > index 00..562cce4c2b
> > --- /dev/null
> > +++ b/arch/arm/dts/armada-388-helios4.dts
> > @@ -0,0 +1,454 @@
> > +/*
> > + * Device Tree file for SolidRun Clearfog revision A1 rev 2.0
> > (88F6828)
> > + *
> > + *  Copyright (C) 2015 Russell King
> > + *
> > + * This board is in development; the contents of this file work
> > with
> > + * the A1 rev 2.0 of the board, which does not represent final
> > + * production board.  Things will change, don't expect this file
> > to
> > + * remain compatible info the future.
> > + *
> > + * This file is dual-licensed: you can use it either under the
> > terms
> > + * of the GPL or the X11 license, at your option. Note that this
> > dual
> > + * licensing only applies to this file, and not this project as a
> > + * whole.
> > + *
> > + *  a) This file is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License
> > + * version 2 as published by the Free Software Foundation.
> > + *
> > + * This file is distributed in the hope that it will be useful
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty
> > of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See
> > the
> > + * GNU General Public License for more details.
> > + *
> > + * Or, alternatively
> > + *
> > + *  b) Permission is hereby granted, free of charge, to any person
> > + * obtaining a copy of this software and associated
> > documentation
> > + * files (the "Softwar

Re: [U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Dennis Gilmore]

El mié, 25-10-2017 a las 20:41 +0200, Karsten Merker escribió:
> [CCing Vagrant Cascadian, the Debian U-Boot maintainer]
> 
> On Wed, Oct 25, 2017 at 02:42:50PM +0100, Andre Przywara wrote:
> > On 25/10/17 12:58, Siarhei Siamashka wrote:
> > > On Tue, 24 Oct 2017 18:21:43 +0100
> > > Andre Przywara  wrote:
> > > > That being said I have prepared a patch to switch sunxi ARM64
> > > > boards
> > > > over to ENV_IS_IN_FAT, because I guess we will hit the wall
> > > > soon there
> > > > and have no Thumb2 to get off lightly.
> 
> [...]
> > > I don't think that we have any significant number of U-Boot env
> > > users
> > > on 32-bit sunxi hardware either. For example, we can do a search
> > > in
> > > the linux-sunxi wiki to compare the usage of environment vs.
> > > boot.scr
> > > and uEnv.txt:
> > > 
> > >https://linux-sunxi.org/index.php?search=saveenv
> > >https://linux-sunxi.org/index.php?search=boot.scr
> > >https://linux-sunxi.org/index.php?search=uenv.txt
> > > 
> > > Using saveenv is justified only in very rare exceptional cases.
> > > They do
> > > exist, otherwise Maxime would not have encountered the problem in
> > > the
> > > first place. But I think that we should encourage Maxime to
> > > migrate 
> > > away from it. I would really like to know a bit more about his
> > > use case.
> 
> Hello,
> 
> I cannot speak for Maxime, but from a distro point of view there are
> at
> least two common usecases:
> 
> a) Changing the default boot order
> 
>At least among Debian users it is not uncommon to run the
>installer from an SD-card (Debian provides SD-card images with
>u-boot and the Debian installer) and install the distro to a
>harddisk (especially on the A20 where native SATA is
>available).  The default boot order is MMC before SATA and
>USB, i.e. after installing to SATA or USB, the user must
>change the boot order by setting the boot_targets variable
>accordingly and saving it into the persistent environment,
>because otherwise the system would reboot into the installer
>on the SD card all the time instead of booting the installed
>system.  Removing the SD card isn't an option because then
>there wouldn't be any (mainline) u-boot anymore.
> 
>This isn't a problem when installing to the SD-card from which
>the installer was loaded as the SD-card gets repartitioned and
>the installer is overwritten in that case.
This is a bit unfortunate, if only we had spi or some other flash for
stroing u-boot on all the hardware so that vendors could ship something
that just works. wiping out the installer would b an option, but that
is pretty ugly. 

> b) Changing the default console device
> 
>The Debian boot.scr passes the contents of the u-boot console
>variable to the kernel as the system console device.  All
>sunxi-based systems default to serial console, but there are
>quite a number of users that don't have a serial console cable
>but instead run their console on HDMI.  They change their
>system console by setting the u-boot "console" variable
>accordingly and running saveenv. This works as u-boot runs
>its own console both on serial and simplefb in parallel, while
>the Linux kernel can only have one system console device at
>a time.
u-boot and the linux kernel actually default to displaying to both the
serial console and the HDMI console. the user can intereact with both
at the same time. At least it is true on the sunxi machines I have
tested it on, with zero need to setup any console lines or do anything
special. I suspect that you no longer need to have a boot.scr at all.

> > As mentioned above, I don't care so much about a saved environment,
> > but
> > I am merely a "user" of U-Boot, so it's not really my call.
> > As long as there is a non-negligible amount of users, we should
> > consider
> > preserving the saved environment.
> > 
> > > The Linux distributions don't seem to rely on the U-Boot
> > > environment
> > > (if I understood their feedback correctly).
> > 
> > That would be an interesting data point to know for sure.
> 
> Please see above :-).
> 
> > > Currently boot.scr or uEnv.txt is loaded from FAT or other
> > > partitions as part of distro boot. Is this really not enough?

> In Debian's case it is "other partitions". Debian doesn't create
> any FAT partitions on non-UEFI systems. The /boot partition is
> ext2 and for the other partitions ext4 is the default filesystem.
> Therefore forcing the environment onto a FAT partition would
> surely cause problems when upgrading an existing system to a
> newer u-boot version.
> 
> uEnv.txt is AFAICS not used by mainline u-boot at all, at least
> on sunxi-based systems.

Fedora does not use or support uEnv.txt or boot.scr our disk images
ship with a fat partition at the start so that we can ship the firmware
needed to boot on a raspberry pi, however any 32 bit system installed
using anaconda will not have a 

Re: [U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Dennis Gilmore]

El lun, 23-10-2017 a las 09:35 +0200, Maxime Ripard escribió:
> On Fri, Oct 20, 2017 at 04:33:57PM -0500, Dennis Gilmore wrote:
> > El jue, 19-10-2017 a las 16:58 +0200, Maxime Ripard escribió:
> > > On Thu, Oct 19, 2017 at 03:42:11PM +0100, Andre Przywara wrote:
> > > > Hi,
> > > > 
> > > > On 19/10/17 14:24, Maxime Ripard wrote:
> > > > > On Thu, Oct 19, 2017 at 02:03:55PM +0100, Andre Przywara
> > > > > wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > On 19/10/17 09:26, Maxime Ripard wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > Most featureful boards, such as the Cubietruck, have been
> > > > > > > broken since
> > > > > > > the release 2017.09.
> > > > > > > 
> > > > > > > This is due to a size increase of the binary that will
> > > > > > > trip
> > > > > > > us across
> > > > > > > the size we've been using in the u-boot-sunxi-with-
> > > > > > > spl.bin
> > > > > > > file.
> > > > > > > 
> > > > > > > We would have two ways to work around it. The first one
> > > > > > > would
> > > > > > > be to
> > > > > > > just increase the offset of the environment. However,
> > > > > > > since
> > > > > > > it would
> > > > > > > break all the environments of our users and possibly the
> > > > > > > custom
> > > > > > > partition scheme that they would have created, it doesn't
> > > > > > > really seem
> > > > > > > like a smart move.
> > > > > > 
> > > > > > Is that really such a problem? How many people rely on
> > > > > > having
> > > > > > their
> > > > > > custom environment preserved over an update? (That's an
> > > > > > honest
> > > > > > question)
> > > > > 
> > > > > All of them, I guess. In your U-boot upgrade script, do you
> > > > > do a
> > > > > 'env
> > > > > default -a; saveenv' all the time ?
> > > > > 
> > > > > I know I don't.
> > > > 
> > > > Well, I never use the saved environment and always expected
> > > > some
> > > > user or
> > > > board specific environment to come from some file (boot.scr or
> > > > something
> > > > loaded via TFTP). But that's just my personal use, hence I was
> > > > asking.
> > > 
> > > Well, even if you want to boot to tftp, you'll need to have some
> > > setup
> > > to do, even just to use a different server IP, and that will be
> > > in
> > > the
> > > environment.
> > 
> > I personally just use pxe boot
> 
> It's not really about what personally you use, but what any user can
> use.
Not saying that it is. but how I use it is really simple for the user
to use without needing to have a ton of specific knowledge about how u-
boot works

> > dhcp
> > pxe get
> > pxe boot
> > and pick the right option. nothing needed on the client side.
> 
> It has the assumption that the DHCP server is setup properly, which
> might or might not be the case, especially when it comes to the
> server
> option being there and valid.
> 
> Maxime
Anyone doing something like this on X86 has to have the same setup. its
not that hard of a ask to assume that a pxe environment is available.
you can skip the dhcp part and set the serrver ip and system ip
manually, its just simpler to use dhcp

Dennis
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Dennis Gilmore]

El jue, 19-10-2017 a las 16:58 +0200, Maxime Ripard escribió:
> On Thu, Oct 19, 2017 at 03:42:11PM +0100, Andre Przywara wrote:
> > Hi,
> > 
> > On 19/10/17 14:24, Maxime Ripard wrote:
> > > On Thu, Oct 19, 2017 at 02:03:55PM +0100, Andre Przywara wrote:
> > > > Hi,
> > > > 
> > > > On 19/10/17 09:26, Maxime Ripard wrote:
> > > > > Hi,
> > > > > 
> > > > > Most featureful boards, such as the Cubietruck, have been
> > > > > broken since
> > > > > the release 2017.09.
> > > > > 
> > > > > This is due to a size increase of the binary that will trip
> > > > > us across
> > > > > the size we've been using in the u-boot-sunxi-with-spl.bin
> > > > > file.
> > > > > 
> > > > > We would have two ways to work around it. The first one would
> > > > > be to
> > > > > just increase the offset of the environment. However, since
> > > > > it would
> > > > > break all the environments of our users and possibly the
> > > > > custom
> > > > > partition scheme that they would have created, it doesn't
> > > > > really seem
> > > > > like a smart move.
> > > > 
> > > > Is that really such a problem? How many people rely on having
> > > > their
> > > > custom environment preserved over an update? (That's an honest
> > > > question)
> > > 
> > > All of them, I guess. In your U-boot upgrade script, do you do a
> > > 'env
> > > default -a; saveenv' all the time ?
> > > 
> > > I know I don't.
> > 
> > Well, I never use the saved environment and always expected some
> > user or
> > board specific environment to come from some file (boot.scr or
> > something
> > loaded via TFTP). But that's just my personal use, hence I was
> > asking.
> 
> Well, even if you want to boot to tftp, you'll need to have some
> setup
> to do, even just to use a different server IP, and that will be in
> the
> environment.

I personally just use pxe boot
dhcp
pxe get
pxe boot
and pick the right option. nothing needed on the client side.

Dennis
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Dennis Gilmore]

El jue, 19-10-2017 a las 15:24 +0200, Maxime Ripard escribió:
> On Thu, Oct 19, 2017 at 02:03:55PM +0100, Andre Przywara wrote:
> > Hi,
> > 
> > On 19/10/17 09:26, Maxime Ripard wrote:
> > > Hi,
> > > 
> > > Most featureful boards, such as the Cubietruck, have been broken
> > > since
> > > the release 2017.09.
> > > 
> > > This is due to a size increase of the binary that will trip us
> > > across
> > > the size we've been using in the u-boot-sunxi-with-spl.bin file.
> > > 
> > > We would have two ways to work around it. The first one would be
> > > to
> > > just increase the offset of the environment. However, since it
> > > would
> > > break all the environments of our users and possibly the custom
> > > partition scheme that they would have created, it doesn't really
> > > seem
> > > like a smart move.
> > 
> > Is that really such a problem? How many people rely on having their
> > custom environment preserved over an update? (That's an honest
> > question)
> 
> All of them, I guess. In your U-boot upgrade script, do you do a 'env
> default -a; saveenv' all the time ?
> 
> I know I don't.
I personally do not do anything to the environment ever if I can help
it. I rely on u-boot having the smarts to just do the right thing and
boot my system for me. if the environment moves, as I use the defaults
it will just continue to work.

Dennis
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] detect and setup solidrun hummingboard2

[Dennis Gilmore]

El jue, 24-08-2017 a las 12:45 -0300, Fabio Estevam escribió:
> Hi Dennis,
> 
> On Thu, Aug 24, 2017 at 12:34 PM, Dennis Gilmore <den...@ausil.us>
> wrote:
> 
> > "findfdt="\
> > +   "if test $board_name = HUMMINGBOARD2 && test
> > $board_rev = MX6Q ; then " \
> > +   "setenv fdtfile imx6q-hummingboard2.dtb;
> > fi; " \
> > +   "if test $board_name = HUMMINGBOARD2 && test
> > $board_rev = MX6DL ; then " \
> > +   "setenv fdtfile imx6dl-hummingboard2.dtb;
> > fi; " \
> 
> Patch looks good, but I do not see any hummingboard2 device tree in
> the mainline kernel.
> 
> Is there anyone working on sending them upstream?

https://patchwork.kernel.org/patch/9515739/ is the patch fedora is
carrying that has the dtb files. Hopefully Jon can provide some info on
current status to upstream it

Dennis
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] detect and setup solidrun hummingboard2

[Dennis Gilmore]

The hummingboard2 is slightly different to the cubox i and to the
hummingboard. The GPIO pin info to probe came from solidruns
for of u-boot on github.
https://github.com/SolidRun/u-boot-imx6/blob/imx6/board/solidrun/mx6_cubox-i/mx6_cubox-i.c#L569-L589
I have tested on a hummingboard-edge witha  imx6 solo and 512mb of
ram.

Signed-off-by: Dennis Gilmore <dgilm...@redhat.com>
---
 board/solidrun/mx6cuboxi/mx6cuboxi.c | 35 +--
 include/configs/mx6cuboxi.h  |  4 
 2 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c 
b/board/solidrun/mx6cuboxi/mx6cuboxi.c
index 7e59fb259e..32d1465d8b 100644
--- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
+++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
@@ -349,6 +349,7 @@ static bool is_hummingboard(void)
 * Machine selection -
 * Machineval1, val2
 * -
+* HB2x x
 * HB rev 3.x x 0
 * CBi0 1
 * HB 1 1
@@ -362,9 +363,37 @@ static bool is_hummingboard(void)
return true;
 }
 
+static bool is_hummingboard2(void)
+{
+   int val1;
+
+   SETUP_IOMUX_PADS(hb_cbi_sense);
+
+   gpio_direction_input(IMX_GPIO_NR(2, 8));
+
+val1 = gpio_get_value(IMX_GPIO_NR(2, 8));
+
+   /*
+* Machine selection -
+* Machineval1
+* ---
+* HB20
+* HB rev 3.x x
+* CBix
+* HB x
+*/
+
+   if (val1 == 0)
+   return true;
+   else
+   return false;
+}
+
 int checkboard(void)
 {
-   if (is_hummingboard())
+   if (is_hummingboard2())
+   puts("Board: MX6 Hummingboard2\n");
+   else if (is_hummingboard())
puts("Board: MX6 Hummingboard\n");
else
puts("Board: MX6 Cubox-i\n");
@@ -375,7 +404,9 @@ int checkboard(void)
 int board_late_init(void)
 {
 #ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
-   if (is_hummingboard())
+   if (is_hummingboard2())
+   env_set("board_name", "HUMMINGBOARD2");
+   else if (is_hummingboard())
env_set("board_name", "HUMMINGBOARD");
else
env_set("board_name", "CUBOXI");
diff --git a/include/configs/mx6cuboxi.h b/include/configs/mx6cuboxi.h
index 5930f591cb..ce9b5469ee 100644
--- a/include/configs/mx6cuboxi.h
+++ b/include/configs/mx6cuboxi.h
@@ -108,6 +108,10 @@
"fi; "  \
"fi\0" \
"findfdt="\
+   "if test $board_name = HUMMINGBOARD2 && test $board_rev = MX6Q 
; then " \
+   "setenv fdtfile imx6q-hummingboard2.dtb; fi; " \
+   "if test $board_name = HUMMINGBOARD2 && test $board_rev = MX6DL 
; then " \
+   "setenv fdtfile imx6dl-hummingboard2.dtb; fi; " \
"if test $board_name = HUMMINGBOARD && test $board_rev = MX6Q ; 
then " \
"setenv fdtfile imx6q-hummingboard.dtb; fi; " \
"if test $board_name = HUMMINGBOARD && test $board_rev = MX6DL 
; then " \
-- 
2.13.3

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] detect and setup solidrun hummingboard2

[Dennis Gilmore]

The hummingboard2 is slightly different to the cubox i and to the
hummingboard. The GPIO pin info to probe came from solidruns
for of u-boot on github.
https://github.com/SolidRun/u-boot-imx6/blob/imx6/board/solidrun/mx6_cubox-i/mx6_cubox-i.c#L569-L589
I have tested on a hummingboard-edge witha  imx6 solo and 512mb of
ram.

Signed-off-by: Dennis Gilmore <dgilm...@redhat.com>
---
 board/solidrun/mx6cuboxi/mx6cuboxi.c | 33 -
 include/configs/mx6cuboxi.h  |  4 
 2 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c 
b/board/solidrun/mx6cuboxi/mx6cuboxi.c
index 7e59fb259e..43a7a52978 100644
--- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
+++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
@@ -349,6 +349,7 @@ static bool is_hummingboard(void)
 * Machine selection -
 * Machineval1, val2
 * -
+* HB2x x
 * HB rev 3.x x 0
 * CBi0 1
 * HB 1 1
@@ -362,9 +363,37 @@ static bool is_hummingboard(void)
return true;
 }
 
+static bool is_hummingboard2(void)
+{
+   int val1;
+
+   SETUP_IOMUX_PADS(hb_cbi_sense);
+
+   gpio_direction_input(IMX_GPIO_NR(2, 8));
+
+val1 = gpio_get_value(IMX_GPIO_NR(2, 8));
+
+   /*
+* Machine selection -
+* Machineval1
+* ---
+* HB20
+* HB rev 3.x x
+* CBix
+* HB x
+*/
+
+   if (val1 == 0)
+   return true;
+   else
+   return false;
+}
+
 int checkboard(void)
 {
-   if (is_hummingboard())
+   if (is_hummingboard2())
+   puts("Board: MX6 Hummingboard2\n");
+   else if (is_hummingboard())
puts("Board: MX6 Hummingboard\n");
else
puts("Board: MX6 Cubox-i\n");
@@ -376,6 +405,8 @@ int board_late_init(void)
 {
 #ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
if (is_hummingboard())
+   env_set("board_name", "HUMMINGBOARD2");
+   else if (is_hummingboard())
env_set("board_name", "HUMMINGBOARD");
else
env_set("board_name", "CUBOXI");
diff --git a/include/configs/mx6cuboxi.h b/include/configs/mx6cuboxi.h
index 5930f591cb..ce9b5469ee 100644
--- a/include/configs/mx6cuboxi.h
+++ b/include/configs/mx6cuboxi.h
@@ -108,6 +108,10 @@
"fi; "  \
"fi\0" \
"findfdt="\
+   "if test $board_name = HUMMINGBOARD2 && test $board_rev = MX6Q 
; then " \
+   "setenv fdtfile imx6q-hummingboard2.dtb; fi; " \
+   "if test $board_name = HUMMINGBOARD2 && test $board_rev = MX6DL 
; then " \
+   "setenv fdtfile imx6dl-hummingboard2.dtb; fi; " \
"if test $board_name = HUMMINGBOARD && test $board_rev = MX6Q ; 
then " \
"setenv fdtfile imx6q-hummingboard.dtb; fi; " \
"if test $board_name = HUMMINGBOARD && test $board_rev = MX6DL 
; then " \
-- 
2.13.3

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] mx6ul_evk: Remove SPL support

[Dennis Gilmore]

On Tuesday, April 19, 2016 10:11:37 PM CDT Stefano Babic wrote:
> Hi Fabio,
> 
> On 19/04/2016 17:19, Fabio Estevam wrote:
> > Currently mx6ul evk fails to boot with some SD cards such as
> > SanDisk microSD HC - 8GB:
> > 
> > U-Boot SPL 2016.05-rc1-28384-g108f841 (Apr 19 2016 - 11:19:11)
> > Trying to boot from MMC1
> > spl: mmc block read error
> > SPL: failed to boot from all boot devices
> > ### ERROR ### Please RESET the board ###
> 
> Well, it does not work because mmc is not working - mmc should be fixed,
> then.
> 
> > As a proper fix for SPL is not available, change to booting via
> > non-SPL mode, so that we can have always have a reliable boot.
> > 
> > Signed-off-by: Fabio Estevam 
> > ---
> > 
> >  board/freescale/mx6ul_14x14_evk/imximage.cfg  |  88 +++
> >  board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c | 172
> >  -- configs/mx6ul_14x14_evk_defconfig
> >  |   3 +-
> >  3 files changed, 89 insertions(+), 174 deletions(-)
> >  create mode 100644 board/freescale/mx6ul_14x14_evk/imximage.cfg
> > 
> > diff --git a/board/freescale/mx6ul_14x14_evk/imximage.cfg
> > b/board/freescale/mx6ul_14x14_evk/imximage.cfg new file mode 100644
> > index 000..f413753
> > --- /dev/null
> > +++ b/board/freescale/mx6ul_14x14_evk/imximage.cfg
> > @@ -0,0 +1,88 @@
> > +/*
> > + * Copyright (C) 2015 Freescale Semiconductor, Inc.
> > + *
> > + * SPDX-License-Identifier:GPL-2.0+
> > + *
> > + * Refer docs/README.imxmage for more details about how-to configure
> > + * and create imximage boot image
> > + *
> > + * The syntax is taken as close as possible with the kwbimage
> > + */
> > +
> > +#define __ASSEMBLY__
> > +#include 
> > +
> > +/* image version */
> > +
> > +IMAGE_VERSION 2
> > +
> > +/*
> > + * Boot Device : one of
> > + * spi/sd/nand/onenand, qspi/nor
> > + */
> > +BOOT_FROM  sd
> > +
> > +/* New DDR type MT41K256M16TW-107 */
> > +
> > +/* Enable all clocks */
> > +DATA 4 0x020c4068 0x
> > +DATA 4 0x020c406c 0x
> > +DATA 4 0x020c4070 0x
> > +DATA 4 0x020c4074 0x
> > +DATA 4 0x020c4078 0x
> > +DATA 4 0x020c407c 0x
> > +DATA 4 0x020c4080 0x
> > +
> > +DATA 4 0x020E04B4 0x000C
> > +DATA 4 0x020E04AC 0x
> > +DATA 4 0x020E027C 0x0030
> > +DATA 4 0x020E0250 0x0030
> > +DATA 4 0x020E024C 0x0030
> > +DATA 4 0x020E0490 0x0030
> > +DATA 4 0x020E0288 0x0030
> > +DATA 4 0x020E0270 0x
> > +DATA 4 0x020E0260 0x0030
> > +DATA 4 0x020E0264 0x0030
> > +DATA 4 0x020E04A0 0x0030
> > +DATA 4 0x020E0494 0x0002
> > +DATA 4 0x020E0280 0x0030
> > +DATA 4 0x020E0284 0x0030
> > +DATA 4 0x020E04B0 0x0002
> > +DATA 4 0x020E0498 0x0030
> > +DATA 4 0x020E04A4 0x0030
> > +DATA 4 0x020E0244 0x0030
> > +DATA 4 0x020E0248 0x0030
> > +DATA 4 0x021B001C 0x8000
> > +DATA 4 0x021B0800 0xA1390003
> > +DATA 4 0x021B080C 0x
> > +DATA 4 0x021B083C 0x41570155
> > +DATA 4 0x021B0848 0x4040474A
> > +DATA 4 0x021B0850 0x40405550
> > +DATA 4 0x021B081C 0x
> > +DATA 4 0x021B0820 0x
> > +DATA 4 0x021B082C 0xf333
> > +DATA 4 0x021B0830 0xf333
> > +DATA 4 0x021B08C0 0x00921012
> > +DATA 4 0x021B08b8 0x0800
> > +DATA 4 0x021B0004 0x0002002D
> > +DATA 4 0x021B0008 0x1B333030
> > +DATA 4 0x021B000C 0x676B52F3
> > +DATA 4 0x021B0010 0xB66D0B63
> > +DATA 4 0x021B0014 0x01FF00DB
> > +DATA 4 0x021B0018 0x00201740
> > +DATA 4 0x021B001C 0x8000
> > +DATA 4 0x021B002C 0x26D2
> > +DATA 4 0x021B0030 0x006B1023
> > +DATA 4 0x021B0040 0x004F
> > +DATA 4 0x021B 0x8418
> > +DATA 4 0x021B0890 0x23400A38
> > +DATA 4 0x021B001C 0x02008032
> > +DATA 4 0x021B001C 0x8033
> > +DATA 4 0x021B001C 0x00048031
> > +DATA 4 0x021B001C 0x15208030
> > +DATA 4 0x021B001C 0x04008040
> > +DATA 4 0x021B0020 0x0800
> > +DATA 4 0x021B0818 0x0227
> > +DATA 4 0x021B0004 0x0002552D
> > +DATA 4 0x021B0404 0x00011006
> > +DATA 4 0x021B001C 0x
> > diff --git a/board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c
> > b/board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c index
> > 88d3fbd..4de5ece 100644
> > --- a/board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c
> > +++ b/board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c
> > @@ -703,175 +703,3 @@ int checkboard(void)
> > 
> > return 0;
> >  
> >  }
> > 
> > -
> > -#ifdef CONFIG_SPL_BUILD
> > -#include 
> > -#include 
> > -#include 
> > -
> > -
> > -static struct mx6ul_iomux_grp_regs mx6_grp_ioregs = {
> > -   .grp_addds = 0x0030,
> > -   .grp_ddrmode_ctl = 0x0002,
> > -   .grp_b0ds = 0x0030,
> > -   .grp_ctlds = 0x0030,
> > -   .grp_b1ds = 0x0030,
> > -   .grp_ddrpke = 0x,
> > -   .grp_ddrmode = 0x0002,
> > -#ifdef CONFIG_TARGET_MX6UL_9X9_EVK
> > -   .grp_ddr_type = 0x0008,
> > -#else
> > -   .grp_ddr_type = 0x000c,
> > -#endif
> > -};
> > -
> > -#ifdef CONFIG_TARGET_MX6UL_9X9_EVK
> > -static struct 

Re: [U-Boot] [PATCH] sunxi: Add support for Cubietruck Plus

[Dennis Gilmore]

On Saturday, March 19, 2016 5:43:52 PM CDT Dennis Gilmore wrote:
> Hans,
> 
> What is the status of this patch?
> 
> Dennis

With the patch applied building for Cubietruck_plus fails with 

  ld.bfd   -pie  --gc-sections -Bstatic -Ttext 0x4a00 -o u-boot -T u-
boot.lds arch/arm/cpu/armv7/start.o --start-group  arch/arm/cpu/built-in.o  
arch/arm/cpu/armv7/built-in.o  arch/arm/lib/built-in.o  board/sunxi/built-in.o  
cmd/built-in.o  common/built-in.o  disk/built-in.o  drivers/built-in.o  
drivers/dma/built-in.o  drivers/gpio/built-in.o  drivers/i2c/built-in.o  
drivers/mmc/built-in.o  drivers/mtd/built-in.o  drivers/mtd/onenand/built-in.o  
drivers/mtd/spi/built-in.o  drivers/net/built-in.o  drivers/net/phy/built-in.o  
drivers/pci/built-in.o  drivers/power/built-in.o  drivers/power/battery/built-
in.o  drivers/power/fuel_gauge/built-in.o  drivers/power/mfd/built-in.o  
drivers/power/pmic/built-in.o  drivers/power/regulator/built-in.o  drivers/
serial/built-in.o  drivers/spi/built-in.o  drivers/usb/dwc3/built-in.o  
drivers/usb/emul/built-in.o  drivers/usb/eth/built-in.o  drivers/usb/gadget/
built-in.o  drivers/usb/gadget/udc/built-in.o  drivers/usb/host/built-in.o  
drivers/usb/musb-new/built-in.o  drivers/usb/musb/built-in.o  drivers/usb/phy/
built-in.o  drivers/usb/ulpi/built-in.o  fs/built-in.o  lib/built-in.o  net/
built-in.o  test/built-in.o  test/dm/built-in.o --end-group arch/arm/lib/
eabi_compat.o  -L /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/6.0.0 -lgcc -Map 
u-boot.map
board/sunxi/built-in.o: In function `i2c_init_board':
/builddir/build/BUILD/u-boot-2016.03/board/sunxi/board.c:363: undefined 
reference to `clock_twi_onoff'
ld.bfd: BFD version 2.26.20160125 assertion fail elf32-arm.c:8434
ld.bfd: error: required section '.rel.plt' not found in the linker script
ld.bfd: final link failed: Invalid operation


> On Wednesday, January 27, 2016 4:34:44 PM CDT Chen-Yu Tsai wrote:
> > Cubietruck Plus is a A83T/H8 based development board. The board has
> > standard DDR3 SDRAM, AXP818 PMIC/codec, SD/MMC, eMMC, USB 2.0 host
> > via HSIC USB Hub, USB OTG, SATA via USB bridge, gigabit ethernet,
> > WiFi, headphone out / mic in, and various GPIO headers.
> > 
> > The board also has an EEPROM on i2c0 which holds the MAC address.
> > 
> > DLDO3 and DLDO4 provide power to the EMAC pins and PHY. Pin PA20
> > is connected to the reset control of the PHY. EMAC is not actually
> > supported yet.
> > 
> > The DTS is the same as the one already in the kernel.
> > 
> > Signed-off-by: Chen-Yu Tsai <w...@csie.org>
> > ---
> > 
> >  arch/arm/dts/Makefile   |  1 +
> >  arch/arm/dts/sun8i-a83t-cubietruck-plus.dts | 65
> > 
> > + configs/Cubietruck_plus_defconfig  
> > |
> > 18 
> > 
> >  3 files changed, 84 insertions(+)
> >  create mode 100644 arch/arm/dts/sun8i-a83t-cubietruck-plus.dts
> >  create mode 100644 configs/Cubietruck_plus_defconfig
> > 
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index 1c7d359..e338db5 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -184,6 +184,7 @@ dtb-$(CONFIG_MACH_SUN8I_A33) += \
> > 
> > sun8i-a33-sinlinx-sina33.dtb
> >  
> >  dtb-$(CONFIG_MACH_SUN8I_A83T) += \
> >  
> > sun8i-a83t-allwinner-h8homlet-v2.dtb \
> > 
> > +   sun8i-a83t-cubietruck-plus.dtb \
> > 
> > sun8i-a83t-sinovoip-bpi-m3.dtb
> >  
> >  dtb-$(CONFIG_MACH_SUN8I_H3) += \
> >  
> > sun8i-h3-orangepi-pc.dtb \
> > 
> > diff --git a/arch/arm/dts/sun8i-a83t-cubietruck-plus.dts
> > b/arch/arm/dts/sun8i-a83t-cubietruck-plus.dts new file mode 100644
> > index 000..88b1e09
> > --- /dev/null
> > +++ b/arch/arm/dts/sun8i-a83t-cubietruck-plus.dts
> > @@ -0,0 +1,65 @@
> > +/*
> > + * Copyright 2015 Chen-Yu Tsai
> > + *
> > + * Chen-Yu Tsai <w...@csie.org>
> > + *
> > + * This file is dual-licensed: you can use it either under the terms
> > + * of the GPL or the X11 license, at your option. Note that this dual
> > + * licensing only applies to this file, and not this project as a
> > + * whole.
> > + *
> > + *  a) This file is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License as
> > + * published by the Free Software Foundation; either version 2 of the
> > + * License, or (at your option) any later version.
> > + *
> > + * This file is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > 

Re: [U-Boot] [PATCH] sunxi: Add support for Cubietruck Plus

[Dennis Gilmore]

Hans,

What is the status of this patch?

Dennis

On Wednesday, January 27, 2016 4:34:44 PM CDT Chen-Yu Tsai wrote:
> Cubietruck Plus is a A83T/H8 based development board. The board has
> standard DDR3 SDRAM, AXP818 PMIC/codec, SD/MMC, eMMC, USB 2.0 host
> via HSIC USB Hub, USB OTG, SATA via USB bridge, gigabit ethernet,
> WiFi, headphone out / mic in, and various GPIO headers.
> 
> The board also has an EEPROM on i2c0 which holds the MAC address.
> 
> DLDO3 and DLDO4 provide power to the EMAC pins and PHY. Pin PA20
> is connected to the reset control of the PHY. EMAC is not actually
> supported yet.
> 
> The DTS is the same as the one already in the kernel.
> 
> Signed-off-by: Chen-Yu Tsai 
> ---
>  arch/arm/dts/Makefile   |  1 +
>  arch/arm/dts/sun8i-a83t-cubietruck-plus.dts | 65
> + configs/Cubietruck_plus_defconfig   |
> 18 
>  3 files changed, 84 insertions(+)
>  create mode 100644 arch/arm/dts/sun8i-a83t-cubietruck-plus.dts
>  create mode 100644 configs/Cubietruck_plus_defconfig
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 1c7d359..e338db5 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -184,6 +184,7 @@ dtb-$(CONFIG_MACH_SUN8I_A33) += \
>   sun8i-a33-sinlinx-sina33.dtb
>  dtb-$(CONFIG_MACH_SUN8I_A83T) += \
>   sun8i-a83t-allwinner-h8homlet-v2.dtb \
> + sun8i-a83t-cubietruck-plus.dtb \
>   sun8i-a83t-sinovoip-bpi-m3.dtb
>  dtb-$(CONFIG_MACH_SUN8I_H3) += \
>   sun8i-h3-orangepi-pc.dtb \
> diff --git a/arch/arm/dts/sun8i-a83t-cubietruck-plus.dts
> b/arch/arm/dts/sun8i-a83t-cubietruck-plus.dts new file mode 100644
> index 000..88b1e09
> --- /dev/null
> +++ b/arch/arm/dts/sun8i-a83t-cubietruck-plus.dts
> @@ -0,0 +1,65 @@
> +/*
> + * Copyright 2015 Chen-Yu Tsai
> + *
> + * Chen-Yu Tsai 
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +#include "sun8i-a83t.dtsi"
> +
> +/ {
> + model = "Cubietech Cubietruck Plus";
> + compatible = "cubietech,cubietruck-plus", "allwinner,sun8i-a83t";
> +
> + aliases {
> + serial0 = 
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins_b>;
> + status = "okay";
> +};
> diff --git a/configs/Cubietruck_plus_defconfig
> b/configs/Cubietruck_plus_defconfig new file mode 100644
> index 000..bb0b336
> --- /dev/null
> +++ b/configs/Cubietruck_plus_defconfig
> @@ -0,0 +1,18 @@
> +CONFIG_ARM=y
> +CONFIG_ARCH_SUNXI=y
> +CONFIG_MACH_SUN8I_A83T=y
> +CONFIG_DRAM_CLK=672
> +CONFIG_DRAM_ZQ=15355
> +CONFIG_DRAM_ODT_EN=y
> +CONFIG_MMC0_CD_PIN="PF6"
> +CONFIG_I2C0_ENABLE=y
> +CONFIG_AXP_GPIO=y
> +CONFIG_DEFAULT_DEVICE_TREE="sun8i-a83t-cubietruck-plus"
> +# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> +CONFIG_SPL=y
> +CONFIG_SYS_EXTRA_OPTIONS="RGMII,MACPWR=SUNXI_GPD(20)"
> +# CONFIG_CMD_IMLS is not 

[U-Boot] [PATCH] arm: mvebu: enable generic distro boot config

[Dennis Gilmore]

Switch all of the mvebu boards to support disto generic booting
This will enable Fedora, Debian and other distros to support
mvebu systems easier. Tested on SolidRun ClearFog

Signed-off-by: Dennis Gilmore <dgilm...@redhat.com>
---
 include/configs/clearfog.h  |  5 ---
 include/configs/mv-common.h | 86 -
 2 files changed, 85 insertions(+), 6 deletions(-)

diff --git a/include/configs/clearfog.h b/include/configs/clearfog.h
index f0de827..926b3c5 100644
--- a/include/configs/clearfog.h
+++ b/include/configs/clearfog.h
@@ -104,11 +104,6 @@
 #define CONFIG_SYS_CONSOLE_INFO_QUIET  /* don't print console @ startup */
 #define CONFIG_SYS_ALT_MEMTEST
 
-/* Keep device tree and initrd in lower memory so the kernel can access them */
-#define CONFIG_EXTRA_ENV_SETTINGS  \
-   "fdt_high=0x1000\0" \
-   "initrd_high=0x1000\0"
-
 /* SPL */
 /*
  * Select the boot device here
diff --git a/include/configs/mv-common.h b/include/configs/mv-common.h
index d12d725..e219243 100644
--- a/include/configs/mv-common.h
+++ b/include/configs/mv-common.h
@@ -57,7 +57,7 @@
 #define CONFIG_SYS_BAUDRATE_TABLE  { 9600, 19200, 38400, 57600, \
  115200,230400, 460800, 921600 }
 /* auto boot */
-#define CONFIG_BOOTDELAY   3   /* default enable autoboot */
+#define CONFIG_BOOTDELAY   2   /* default enable autoboot */
 #define CONFIG_PREBOOT
 
 #define CONFIG_OF_LIBFDT   /* Device tree support */
@@ -152,4 +152,88 @@
 #define CONFIG_LZO
 #endif
 
+#ifndef CONFIG_SPL_BUILD
+#include 
+
+/*
+* 160M RAM (256M minimum minus 64MB heap + 32MB for u-boot, stack, fb, etc.
+* 32M uncompressed kernel, 16M compressed kernel, 1M fdt,
+* 1M script, 1M pxe and the ramdisk at the end.
+*/
+#define SDRAM_OFFSET(x) 0x0##x
+
+#define KERNEL_ADDR_R  __stringify(SDRAM_OFFSET(200))
+#define FDT_ADDR_R __stringify(SDRAM_OFFSET(300))
+#define SCRIPT_ADDR_R  __stringify(SDRAM_OFFSET(310))
+#define PXEFILE_ADDR_R __stringify(SDRAM_OFFSET(320))
+#define RAMDISK_ADDR_R __stringify(SDRAM_OFFSET(330))
+
+#define MEM_LAYOUT_ENV_SETTINGS \
+"bootm_size=0xa00\0" \
+"kernel_addr_r=" KERNEL_ADDR_R "\0" \
+"fdt_addr_r=" FDT_ADDR_R "\0" \
+"scriptaddr=" SCRIPT_ADDR_R "\0" \
+"pxefile_addr_r=" PXEFILE_ADDR_R "\0" \
+"ramdisk_addr_r=" RAMDISK_ADDR_R "\0"
+
+#ifdef CONFIG_MMC
+#define BOOT_TARGET_DEVICES_MMC(func) func(MMC, mmc, 0)
+#else
+#define BOOT_TARGET_DEVICES_MMC(func)
+#endif
+
+#ifdef CONFIG_CMD_SATA
+#define BOOT_TARGET_DEVICES_SATA(func) func(SATA, sata, 0) func(SATA, sata, 1)
+#define CONFIG_PREBOOT  "sata init"
+#else
+#define BOOT_TARGET_DEVICES_SATA(func)
+#endif
+
+#ifdef CONFIG_USB_STORAGE
+#define BOOT_TARGET_DEVICES_USB(func) func(USB, usb, 0)
+#else
+#define BOOT_TARGET_DEVICES_USB(func)
+#endif
+
+#define BOOT_TARGET_DEVICES(func) \
+BOOT_TARGET_DEVICES_MMC(func) \
+BOOT_TARGET_DEVICES_SATA(func) \
+BOOT_TARGET_DEVICES_USB(func) \
+func(PXE, pxe, na)
+
+#include 
+
+#ifdef CONFIG_USB_KEYBOARD
+#define CONSOLE_STDIN_SETTINGS \
+"preboot=usb start\0" \
+"stdin=serial,usbkbd\0"
+#else
+#define CONSOLE_STDIN_SETTINGS \
+"stdin=serial\0"
+#endif
+
+#ifdef CONFIG_VIDEO
+#define CONSOLE_STDOUT_SETTINGS \
+"stdout=serial,vga\0" \
+"stderr=serial,vga\0"
+#else
+#define CONSOLE_STDOUT_SETTINGS \
+"stdout=serial\0" \
+"stderr=serial\0"
+#endif
+
+#define CONSOLE_ENV_SETTINGS \
+CONSOLE_STDIN_SETTINGS \
+CONSOLE_STDOUT_SETTINGS
+
+#define CONFIG_EXTRA_ENV_SETTINGS \
+CONSOLE_ENV_SETTINGS \
+MEM_LAYOUT_ENV_SETTINGS \
+"fdtfile=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
+"console=ttyS0,115200\0" \
+BOOTENV
+#else /* ifndef CONFIG_SPL_BUILD */
+#define CONFIG_EXTRA_ENV_SETTINGS
+#endif
+
 #endif /* _MV_COMMON_H */
-- 
2.5.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Dennis Gilmore]

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 generic distro framework U-Boot will grok
> > >> https://wiki.freedesktop.org/www/Specifications/BootLoaderSpec/ and
> > >> things Just Work.  I setup a bunch of SD cards with Debian and Fedora
> > >> over holiday so I can drop them in whatever board and boot up Linux as
> > >> a
> > >> sanity test.
We do not fully support bootloader spec in u-boot today. but I know that we 
want to one day 

> > >> I certainly can see a usecase for kicking off an EFI binary as part of
> > >> fitting into existing work-flows.  But we do already have a something
> > >> for getting rid of that particular pain-point and it's working :)
> > 
> > [snip]
> > 
> > Executive summary: https://xkcd.com/927/
> 
> Oh pretty much.  I guess the point I am driving at here is that EFI
> loading (to kick off GRUB2) needs to fit in with the framework that
> other distros have already adapted to.  Or heck, maybe you can convince
> them to switch over to this instead?  Hans or Dennis, what do you think?

not opposed to it, but it is not something that we have evaluated, I know 
debian have done a lot of work to ensure that their systems support 
extlinux.conf also. which is the same syslinux format as used by 
extlinux/syslinux/isolinux on x86, the user experience is somewhat similiar to 
that of grub on other arches.  Long term I have planed to wire up menu support 
so you get a menu to interact with rather than a list of boot options, as well 
as the ability to edit the commandline arguments. I would not say we have 
perfect support today for extlinux. so far SuSE is the only one saying no to 
what has been proposed. It was brought up on both the u-boot and linaro cross 
distro list back in 2013[1][2] with no one saying it was not a good idea.while 
there was less feedback than I would have liked it was positive.

Anyway my main question is how dtb support would work. As that really is the 
trickiest part that I can think of.  Something that is gracefully dealt with 
in the extlinux support, regardless of distro.  Going this approach to me 
feels like trying to put a Ford engine in a GM car by adding a volkswagon 
gearbox. can we make grub a u-boot application? that is not using CONFIG_API 
or does not need to have hard coded memory locations in it?  we looked at 
grub2 support years ago as we felt that it would be the way to go as it seemed 
people were standardising on it. and decided that there were too many issues 
with the implementation for it to be viable.  so we went the route of 
proposing the extlinux.conf file option. 

Dennis 


[1] https://lists.linaro.org/pipermail/cross-distro/2013-August/000439.html
[2] http://lists.denx.de/pipermail/u-boot/2013-August/160080.html


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: mvebu: Add SolidRun ClearFog Armada 38x initial support

[Dennis Gilmore]

Trying to test this  I have hit an error with CONFIG_PHY_ADDR not defined.

I am guessing that I am missing some other sets of patches. digging through 
patchwork I am not able to figure it out.  there is a bunch of patches in 
patchwork that say they are in NEW state however they are in the tree so not 
labeled correctly.  Any clues as to which patch sets this depends on are 
appreciated.

Dennis


On Friday, November 27, 2015 04:15:17 PM Stefan Roese wrote:
> This patch adds basic support for the SolidRun ClearFog Armada 38x based
> board to mainline U-Boot. Supported interfaces / devices are:
> - DDR3
> - UART
> - MMC
> - Ethernet port 0 (connected to dedicated PHY)
> - I2C
> 
> The included DT source was taken from Russell King's ftp server:
> http://www.home.arm.linux.org.uk/~rmk/clearfog/
> 
> With only minor modifications, like the addition of some aliases and the
> "u-boot,dm-pre-reloc" property.
> 
> Signed-off-by: Stefan Roese 
> Cc: Rabeeh Khoury 
> Cc: Luka Perkov 
> ---
>  arch/arm/Kconfig |   1 +
>  arch/arm/dts/Makefile|   1 +
>  arch/arm/dts/armada-388-clearfog.dts | 509
> +++ arch/arm/mach-mvebu/Kconfig  | 
>  3 +
>  board/solidrun/clearfog/Kconfig  |  12 +
>  board/solidrun/clearfog/MAINTAINERS  |   6 +
>  board/solidrun/clearfog/Makefile |   7 +
>  board/solidrun/clearfog/README   |  18 ++
>  board/solidrun/clearfog/clearfog.c   | 156 +++
>  board/solidrun/clearfog/kwbimage.cfg |  12 +
>  configs/clearfog_defconfig   |  20 ++
>  include/configs/clearfog.h   | 183 +
>  12 files changed, 928 insertions(+)
>  create mode 100644 arch/arm/dts/armada-388-clearfog.dts
>  create mode 100644 board/solidrun/clearfog/Kconfig
>  create mode 100644 board/solidrun/clearfog/MAINTAINERS
>  create mode 100644 board/solidrun/clearfog/Makefile
>  create mode 100644 board/solidrun/clearfog/README
>  create mode 100644 board/solidrun/clearfog/clearfog.c
>  create mode 100644 board/solidrun/clearfog/kwbimage.cfg
>  create mode 100644 configs/clearfog_defconfig
>  create mode 100644 include/configs/clearfog.h
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 4ddc2de..0c4794b 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -801,6 +801,7 @@ source "board/siemens/draco/Kconfig"
>  source "board/siemens/pxm2/Kconfig"
>  source "board/siemens/rut/Kconfig"
>  source "board/silica/pengwyn/Kconfig"
> +source "board/solidrun/clearfog/Kconfig"
>  source "board/spear/spear300/Kconfig"
>  source "board/spear/spear310/Kconfig"
>  source "board/spear/spear320/Kconfig"
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 9719103..0494997 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -47,6 +47,7 @@ dtb-$(CONFIG_TEGRA) += tegra20-harmony.dtb \
>   tegra210-p2571.dtb
> 
>  dtb-$(CONFIG_ARCH_MVEBU) +=  \
> + armada-388-clearfog.dtb \
>   armada-388-gp.dtb   \
>   armada-xp-gp.dtb\
>   armada-xp-maxbcm.dtb
> diff --git a/arch/arm/dts/armada-388-clearfog.dts
> b/arch/arm/dts/armada-388-clearfog.dts new file mode 100644
> index 000..b2dfd56
> --- /dev/null
> +++ b/arch/arm/dts/armada-388-clearfog.dts
> @@ -0,0 +1,509 @@
> +/*
> + * Device Tree file for SolidRun Clearfog revision A1 rev 2.0 (88F6828)
> + *
> + *  Copyright (C) 2015 Russell King
> + *
> + * This board is in development; the contents of this file work with
> + * the A1 rev 2.0 of the board, which does not represent final
> + * production board.  Things will change, don't expect this file to
> + * remain compatible info the future.
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + *
> + * This file is distributed in the hope that it will be useful
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to 

Re: [U-Boot] [ANN] U-Boot v2015.10-rc5 released

[Dennis Gilmore]

On Thursday, October 15, 2015 04:55:55 PM Tom Rini wrote:
> On Thu, Oct 15, 2015 at 03:52:08AM +0200, Andreas Färber wrote:
> > Am 15.10.2015 um 02:40 schrieb Tom Rini:
> > > On Thu, Oct 15, 2015 at 02:28:34AM +0200, Andreas Färber wrote:
> > >> Am 12.10.2015 um 17:18 schrieb Tom Rini:
> > >>> If you have a regression, speak up.
> > >> 
> > >> For -rc4 I had reported that CONFIG_API is broken for sunxi among
> > >> others. I was told this was fallout of the new Driver Model. Has anyone
> > >> thought about how to fix this? Is that already a lost cause for
> > >> 2015.10?
> > >> 
> > >> Improving test coverage for such off-by-default features will also be
> > >> helpful going forward. For instance, Simon's brand-new rk3288 code was
> > >> lacking some MMC define for CONFIG_API to build iirc - that part is
> > >> trivial to fix when actually build-testing. I'll see if I can polish
> > >> some of my fixes in time.
> > > 
> > > I'm just not sure what to do about CONFIG_API some days.  I know one use
> > > case is for GRUB but I'd like to move away from that if possible
> > > (distros should be doing the generic distro bits and extlinux.conf).
> > > After that, I'm only hazily aware of the real use-cases.
> > 
> > The problem is that no other platform uses those. On x86_64, ppc64le,
> > s390x, aarch64, etc. we always use GRUB2. Whether it's boot.scr,
> > extlinux.conf or anything else, it'll require changes to distro tools
> > that end up being special-cased to 32-bit arm. With more and more server
> > vendors adopting UEFI and aarch64, that seems a waste of effort.
> 
> That's a thing to ponder, yes.  There's nothing ARM32 centric about the
> generic distro framework and it's on my TODO list now to poke Fedora
> about enabling the extlinux.conf knob on x86 because there's a growing
> number of platforms using U-Boot there.  And hikey does (and Juno
> should/will) be doing it as well.

it is already there 
https://rhinstaller.github.io/anaconda/boot-options.html#boot-loader-options  
add extlinux to the boot arguments on a x86 
install and it will use extlinux.


> > A boot.scr is easy to generate once for an installation image, and I see
> > Guillaume has been helping to make it usable where necessary, but as
> > long as that points to a single zImage / initrd / dtb (ext4 symlinks
> > pointing to the latest), after the user installs a new kernel package,
> > things might simply become unbootable for the average user. That's where
> > GRUB is handy in offering a selection of multiple kernels to go back to
> > a previously working state. I'm not particularly attached to CONFIG_API
> > myself - if the same can be achieved either in GRUB without CONFIG_API
> > or inside U-Boot with scripts and without GRUB, I'd be happy to hear
> > about it. :)
> 
> Well, that roughly is the point of the whole config_distro_defaults /
> config_distro_bootcmd stuff is that the distro doesn't have to care what
> board it's on, it can just boot.

yep :)

> > Regarding GRUB, I've mainly tested it on jetson-tk1 (adjusting grub's
> > hardcoded RAM offsets), and I've found it to load unreliably, as if
> > there's garbage in memory. Might be our 2.02~beta2 is missing some
> > backports. bootz works fine, so I guess bootm is not to blame there.
> > 
> > Anyway, I think it's valid to say that we should either fix CONFIG_API
> > to build okay, or drop it completely, but not carry it around in
> > decaying state. ;)
> 
> So as Wolfgang brought up, FreeBSD uses CONFIG_API so some care must be
> taken here, but we need to cover things a lot better than we do today.

the reason we did not look at grub was that it needed hard coded values, so 
you would need different grub builds for different boards. and a whole world 
of extra pain, and no one was actively working on the arm port of grub. u-boot 
had the extlinux support built in. though I need to find time to extend it a 
bit.

Dennis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 3/3] port vexpress to use distro boot commands

[Dennis Gilmore]

remove options defined in the distro defaults
add distro bot commands
set scriptaddr value

Signed-off-by: Dennis Gilmore den...@ausil.us
---
 include/configs/vexpress_common.h | 34 +-
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/include/configs/vexpress_common.h 
b/include/configs/vexpress_common.h
index 0c1da01..bed8ffd 100644
--- a/include/configs/vexpress_common.h
+++ b/include/configs/vexpress_common.h
@@ -123,7 +123,6 @@
 #define CONFIG_SYS_L2CACHE_OFF 1
 #define CONFIG_INITRD_TAG  1
 #define CONFIG_SYS_GENERIC_BOARD
-#define CONFIG_OF_LIBFDT   1
 
 /* Size of malloc() pool */
 #define CONFIG_SYS_MALLOC_LEN  (CONFIG_ENV_SIZE + 128 * 1024)
@@ -152,18 +151,6 @@
 #define CONFIG_SYS_SERIAL0 V2M_UART0
 #define CONFIG_SYS_SERIAL1 V2M_UART1
 
-/* Command line configuration */
-#define CONFIG_CMD_DHCP
-#define CONFIG_CMD_PXE
-#define CONFIG_MENU
-#define CONFIG_CMD_ELF
-#define CONFIG_CMD_ENV
-#define CONFIG_CMD_PING
-#define CONFIG_CMD_BOOTZ
-#define CONFIG_SUPPORT_RAW_INITRD
-
-#define CONFIG_CMD_FAT
-#define CONFIG_DOS_PARTITION   1
 #define CONFIG_MMC 1
 #define CONFIG_CMD_MMC
 #define CONFIG_GENERIC_MMC
@@ -177,8 +164,6 @@
 #define CONFIG_BOOTP_BOOTPATH
 #define CONFIG_BOOTP_GATEWAY
 #define CONFIG_BOOTP_HOSTNAME
-#define CONFIG_BOOTP_PXE
-#define CONFIG_BOOTP_PXE_CLIENTARCH0x100
 
 /* Miscellaneous configurable options */
 #define CONFIG_SYS_LOAD_ADDR   (V2M_BASE + 0x8000)
@@ -200,9 +185,22 @@
 CONFIG_SYS_INIT_RAM_SIZE - \
 GENERATED_GBL_DATA_SIZE)
 #define CONFIG_SYS_INIT_SP_ADDRCONFIG_SYS_GBL_DATA_OFFSET
+#define CONFIG_CMD_ECHO
+
+#include config_distro_defaults.h
 
 /* Basic environment settings */
-#define CONFIG_BOOTCOMMAND run bootflash;
+#define CONFIG_BOOTCOMMAND \
+   run distro_bootcmd;  \
+   run bootflash; 
+
+#define BOOT_TARGET_DEVICES(func) \
+func(MMC, mmc, 1) \
+func(MMC, mmc, 0) \
+func(PXE, pxe, na) \
+func(DHCP, dhcp, na)
+#include config_distro_bootcmd.h
+
 #ifdef CONFIG_VEXPRESS_ORIGINAL_MEMORY_MAP
 #define CONFIG_PLATFORM_ENV_SETTINGS \
loadaddr=0x80008000\0 \
@@ -211,6 +209,7 @@
ramdisk_addr=0x4480\0 \
maxramdisk=0x180\0 \
pxefile_addr_r=0x8800\0 \
+   scriptaddr=0x8800\0 \
kernel_addr_r=0x80008000\0
 #elif defined(CONFIG_VEXPRESS_EXTENDED_MEMORY_MAP)
 #define CONFIG_PLATFORM_ENV_SETTINGS \
@@ -220,10 +219,12 @@
ramdisk_addr=0x0c80\0 \
maxramdisk=0x180\0 \
pxefile_addr_r=0xa800\0 \
+   scriptaddr=0xa800\0 \
kernel_addr_r=0xa0008000\0
 #endif
 #define CONFIG_EXTRA_ENV_SETTINGS \
CONFIG_PLATFORM_ENV_SETTINGS \
+BOOTENV \
console=ttyAMA0,38400n8\0 \
dram=1024M\0 \
root=/dev/sda1 rw\0 \
@@ -287,7 +288,6 @@
 
 #define CONFIG_SYS_BARGSIZECONFIG_SYS_CBSIZE /* Boot args buffer */
 #define CONFIG_SYS_LONGHELP
-#define CONFIG_CMDLINE_EDITING 1
 #define CONFIG_SYS_MAXARGS 16  /* max command args */
 
 #endif /* VEXPRESS_COMMON_H */
-- 
2.4.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/3] Move setting CONFIG_BOOTP_VCI_STRING to before including the vexpress-common header

[Dennis Gilmore]

Signed-off-by: Dennis Gilmore den...@ausil.us
---
 include/configs/vexpress_ca15_tc2.h | 2 +-
 include/configs/vexpress_ca5x2.h| 2 +-
 include/configs/vexpress_ca9x4.h| 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/configs/vexpress_ca15_tc2.h 
b/include/configs/vexpress_ca15_tc2.h
index b43afa2..59b6310 100644
--- a/include/configs/vexpress_ca15_tc2.h
+++ b/include/configs/vexpress_ca15_tc2.h
@@ -12,8 +12,8 @@
 #define __VEXPRESS_CA15X2_TC2_h
 
 #define CONFIG_VEXPRESS_EXTENDED_MEMORY_MAP
-#include vexpress_common.h
 #define CONFIG_BOOTP_VCI_STRING U-boot.armv7.vexpress_ca15x2_tc2
+#include vexpress_common.h
 
 #define CONFIG_SYSFLAGS_ADDR   0x1c010030
 #define CONFIG_SMP_PEN_ADDRCONFIG_SYSFLAGS_ADDR
diff --git a/include/configs/vexpress_ca5x2.h b/include/configs/vexpress_ca5x2.h
index 7719d59..a4ffdf5 100644
--- a/include/configs/vexpress_ca5x2.h
+++ b/include/configs/vexpress_ca5x2.h
@@ -12,7 +12,7 @@
 #define __VEXPRESS_CA5X2_h
 
 #define CONFIG_VEXPRESS_EXTENDED_MEMORY_MAP
-#include vexpress_common.h
 #define CONFIG_BOOTP_VCI_STRING U-boot.armv7.vexpress_ca5x2
+#include vexpress_common.h
 
 #endif /* __VEXPRESS_CA5X2_h */
diff --git a/include/configs/vexpress_ca9x4.h b/include/configs/vexpress_ca9x4.h
index 38ac4ed..71233d8 100644
--- a/include/configs/vexpress_ca9x4.h
+++ b/include/configs/vexpress_ca9x4.h
@@ -12,7 +12,7 @@
 #define __VEXPRESS_CA9X4_H
 
 #define CONFIG_VEXPRESS_ORIGINAL_MEMORY_MAP
-#include vexpress_common.h
 #define CONFIG_BOOTP_VCI_STRING U-boot.armv7.vexpress_ca9x4
+#include vexpress_common.h
 
 #endif /* VEXPRESS_CA9X4_H */
-- 
2.4.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Setting up vexpress u-boot for distro configs and use in virt

[Dennis Gilmore]

Hi all,

The attached patches fix up a minor noise issue if a board defines its own
value for CONFIG_BOOTP_VCI_STRING, makes sure we do not hit any noise on
vexpress and port to the distro boot configs while maintaining the existing
boot setup.

I have built and tested for vexpress_ca15_tc2 using qemu-system-arm, however
I hit a snag with an illegal instruction.
U-Boot 2015.07-rc2-00140-gef0f2f5-dirty (Jun 27 2015 - 06:42:35 -0500)

DRAM:  1 GiB
WARNING: Caches not enabled
Flash: 128 MiB
MMC:   MMC: 0
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Net:   smc911x-0
Warning: smc911x-0 using MAC address from net device

Hit any key to stop autoboot:  0 
MMC Device 1 not found
no mmc device at slot 1
switch to partitions #0, OK
mmc0 is current device
env - environment handling commands

Usage:
env default [-f] -a - [forcibly] reset default environment
env default [-f] var [...] - [forcibly] reset variable(s) to their default 
values
env delete [-f] var [...] - [forcibly] delete variable(s)
env export [-t | -b | -c] [-s size] addr [var ...] - export environment
env import [-d] [-t [-r] | -b | -c] addr [size] - import environment
env print [-a | name ...] - print environment
env run var [...] - run commands in an environment variable
env save - save environment
env set [-f] name [arg ...]

Scanning mmc 0:1...
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
486 bytes read in 32 ms (14.6 KiB/s)
Ignoring unknown command: ui
Ignoring malformed menu command:  autoboot
Ignoring malformed menu command:  hidden
Ignoring unknown command: totaltimeout
Fedora-Server-armhfp-22-3 Boot Options.
1:  Fedora-Server-armhfp-22-3 (4.0.4-301.fc22.armv7hl)
Enter choice: 1
1:  Fedora-Server-armhfp-22-3 (4.0.4-301.fc22.armv7hl)
Retrieving file: /initramfs-4.0.4-301.fc22.armv7hl.img
38558585 bytes read in 4209 ms (8.7 MiB/s)
Retrieving file: /vmlinuz-4.0.4-301.fc22.armv7hl
5645832 bytes read in 688 ms (7.8 MiB/s)
append: ro root=UUID=fe0fbdbc-e734-4f07-9b1c-7564e3a356b9 
console=ttyAMA0,38400n8
Kernel image @ 0xa0008000 [ 0x00 - 0x562608 ]

Starting kernel ...

undefined instruction
pc : [9ffac060]  lr : [9ff83b24]
sp : 9fee1be8  ip : a0008000 fp : 9ff83b50
r10:   r9 : 9fee2f00 r8 : 9fee1ce4
r7 :   r6 : 001a r5 : 0131  r4 : 
r3 : 80002000  r2 : 80002000 r1 : 08e0  r0 : 
Flags: nzcv  IRQs off  FIQs off  Mode UK6_32
Resetting CPU ...

resetting ...


In the end my goal here is to have a u-boot that works with qemu-system-arm so 
that
the user never needs to extract files out of the system in order to get a 
booting vm.
The answer may well be to make a virt specific u-boot that can set the amount 
of ram, 
cpu, etc based on what qemu tells it is there.

Regards 

Dennis

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 1/3] PXE: if a board has set its own value for CONFIG_BOOTP_VCI_STRING do not set the default one. Use the board set value instead

[Dennis Gilmore]

Signed-off-by: Dennis Gilmore den...@ausil.us
---
 include/config_distro_defaults.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/include/config_distro_defaults.h b/include/config_distro_defaults.h
index bd8fbca..d8165cc 100644
--- a/include/config_distro_defaults.h
+++ b/include/config_distro_defaults.h
@@ -23,12 +23,18 @@
 #if defined(__arm__) || defined(__aarch64__)
 #define CONFIG_BOOTP_PXE_CLIENTARCH 0x100
 #if defined(__ARM_ARCH_7__) || defined(__ARM_ARCH_7A__)
+#if !defined(CONFIG_BOOTP_VCI_STRING)
 #define CONFIG_BOOTP_VCI_STRING U-boot.armv7
+#endif
 #elif defined(__aarch64__)
+#if !defined(CONFIG_BOOTP_VCI_STRING)
 #define CONFIG_BOOTP_VCI_STRING U-boot.armv8
+#endif
 #else
+#if !defined(CONFIG_BOOTP_VCI_STRING)
 #define CONFIG_BOOTP_VCI_STRING U-boot.arm
 #endif
+#endif
 #elif defined(__i386__)
 #define CONFIG_BOOTP_PXE_CLIENTARCH 0x0
 #elif defined(__x86_64__)
-- 
2.4.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 00/16] tegra: Expand Nyan-big support

[Dennis Gilmore]

On Sunday, June 07, 2015 06:55:36 PM Simon Glass wrote:
 Hi Tom,
 
 On 5 June 2015 at 16:27, Tom Warren twar...@nvidia.com wrote:
  Simon,
  
  Applied to u-boot-tegra/master, then I rebased against u-boot/master and
  uploaded it back to denx.de/u-boot-tegra/master.  ./MAKEALL -s tegra
  works OK. I didn't test on any real HW - my nyan-big system is offline
  temporarily.
  
  PTAL and let me know if it's working OK and I'll get a PR out to TomR
  first thing next week.
 Thanks - it seems to work fine for me.

Trying to test this out and I think I am missing something in how to get it 
installed so it just works. is there some docs somewhere on how to get it 
installed?

Dennis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 6/9] config_distro_bootcmd.h: Add shared block definition for the host interface

[Dennis Gilmore]

On Monday, April 13, 2015 10:54:24 PM Sjoerd Simons wrote:
 Define the common shared block environment for the host interface in
 preperation for the sandbox build to use config_distro_bootcmd.
 
 Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
 Acked-by: Simon Glass s...@chromium.org
 Acked-by: Stephen Warren swar...@nvidia.com
Acked-by : Dennis Gilmore den...@ausil.us

 ---
 
 Changes in v4: None
 Changes in v3: None
 Changes in v2: None
 
  include/config_distro_bootcmd.h | 13 +
  1 file changed, 13 insertions(+)
 
 diff --git a/include/config_distro_bootcmd.h
 b/include/config_distro_bootcmd.h index d71e58d..3a360ca4 100644
 --- a/include/config_distro_bootcmd.h
 +++ b/include/config_distro_bootcmd.h
 @@ -48,6 +48,18 @@
  #define BOOTENV_DEV_NAME_BLKDEV(devtypeu, devtypel, instance) \
   #devtypel #instance  
 
 +#ifdef CONFIG_SANDBOX
 +#define BOOTENV_SHARED_HOST  BOOTENV_SHARED_BLKDEV(host)
 +#define BOOTENV_DEV_HOST BOOTENV_DEV_BLKDEV
 +#define BOOTENV_DEV_NAME_HOSTBOOTENV_DEV_NAME_BLKDEV
 +#else
 +#define BOOTENV_SHARED_HOST
 +#define BOOTENV_DEV_HOST \
 + BOOT_TARGET_DEVICES_references_HOST_without_CONFIG_SANDBOX
 +#define BOOTENV_DEV_NAME_HOST \
 + BOOT_TARGET_DEVICES_references_HOST_without_CONFIG_SANDBOX
 +#endif
 +
  #ifdef CONFIG_CMD_MMC
  #define BOOTENV_SHARED_MMC   BOOTENV_SHARED_BLKDEV(mmc)
  #define BOOTENV_DEV_MMC  BOOTENV_DEV_BLKDEV
 @@ -167,6 +179,7 @@
  #define BOOTENV_DEV(devtypeu, devtypel, instance) \
   BOOTENV_DEV_##devtypeu(devtypeu, devtypel, instance)
  #define BOOTENV \
 + BOOTENV_SHARED_HOST \
   BOOTENV_SHARED_MMC \
   BOOTENV_SHARED_USB \
   BOOTENV_SHARED_SATA \

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2] add README.distro file

[Dennis Gilmore]

On Mon, 12 Jan 2015 20:57:29 +0100
Sjoerd Simons sjoerd.sim...@collabora.co.uk wrote:

 On Mon, 2015-01-12 at 17:57 +, Ian Campbell wrote:
  On Mon, 2015-01-12 at 10:34 -0700, Stephen Warren wrote:
 
   * boot.scr must be generated (to boot.scr.uimg) using 
   bootloader-specific tools, rather than extlinux.conf,
   grub.conf, ... all just need the generation of a text file.
  
  Debian already has the tooling (and has for years) to reproduce
  boot.scr automatically on upgrades of various relevant components,
  the user never needs to see the mkimage stuff (that tooling also
  handles various legacy non-config_distro_bootcmd systems, so it's
  going to have to remain for the time being either way).
  
  Currently the extlinux.conf generating stuff is tied to the x86
  syslinux packages, it could be reworked and pulled out into arch
  indep packages, but there doesn't seem to be all that much benefit
  compared with what we have now which is working fairly well for us
  (not to imply that it's perfect).
 
 One big downside of the boot.scr as generated by flash-kernel in
 Debian is that it doesn't have a menu, which extlinux can provide
 currently. Thus with extlinux we could provide a more similar
 experience to what folks get on x86 with e.g. Grub, iotw select
 provide menu options to boot previous kernels or single user mode etc.
 
 I do hope to get to experimenting a bit with this for the boards, i
 care about soon. My patchset that was in discussion there was
 actually some pre-work for those things ;). It would be nice if, in
 the end, flash-kernel wouldn't be needed for boards with modern
 u-boot and follwing the distro_boot_cmds, but I'm not actually
 involved with Debians u-boot package so not my call :)

I am carrying some patches in Fedora that were written by someone from
debian porting a board to use the generic options, though it was
incomplete and was missing variables for pxe booting to work. while we
get a menu and you can choose older kernels currently there is no way
to edit things dynamically. this is a feature I want to add. make it
easy to append boot arguments etc. there seems to at least be interest
in the debian camp. to what extent that interest goes I am not sure.

I will cover how things are in Fedora.  It is still not perfect but
is getting better every release. grubby updates extlinux.conf on kernel
install/update/removal etc the exact same code is used on x86 and arm.
we have a extlinux-bootloader package on arm that provides the
framework needed that comes with syslinux-extlinux. anaconda writes out
extlinux.conf on install. I have some scripting work to do to update it
and add the fdtdir entry to extlinux.conf on install. the anaconda code
to deal with extlinux.conf is shared between x86 and arm.
appliance-creator which is the tool we use to make disk images writes
out correct extlinux.conf files for both x86 and arm

from a end user perspective the experience is similar but not quite
exactly the same. longer term id like to use u-boots menu code to offer
up a menu to select the kernel and add editing features. But it is much
easier now to support new boards than it ever has been in the past.

Dennis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/4] config_distro_bootcmd: Scan all partitions for boot files

[Dennis Gilmore]

On Mon, 12 Jan 2015 10:42:27 -0700
Stephen Warren swar...@wwwdotorg.org wrote:

 On 01/10/2015 11:27 AM, Dennis Gilmore wrote:
  On Tue, 06 Jan 2015 17:43:19 -0700
  Stephen Warren swar...@wwwdotorg.org wrote:
 
  (CCing Dennis so he can comment from a distro perspective re:
  partition table bootable flags v.s. scanning all partitions)
 
  On 01/06/2015 10:07 AM, Sjoerd Simons wrote:
  On Mon, 2015-01-05 at 13:24 -0700, Stephen Warren wrote:
  On 01/05/2015 10:13 AM, Sjoerd Simons wrote:
  Not all devices use the convention that the boot scripts are on
  the first partition. For example on chromebooks it seems common
  for the first two partitions to be ChromeOS kernel partitions.
 
  ChromeOS seems to have adopted its own unique setup. it is not a
  typical configuration.
 
 
  So instead of just the first partition scan all partitions on a
  device with a filesystem u-boot can recognize.
 
  I had planned (but obviously never got around to...) enhancing
  the scripts to look up the (set of?) bootable partition(s) on
  the disk and to attempt to load the boot files from there.
  Bootable would be defined as the MBR bootable flag, or GPT
  legacy bootable attribute.
 
  That would allow the code to zero in on the one specific
  partition that it was supposed to look at, rather than searching
  all partitions.
 
  Do you have any thoughts re: which option is better?
 
  I did wonder about this as well. I do personally consider the
  bootable flag as a rather obsolete/legacy thing (GPT even
  specifies it as a legacy flag), so i was wary about using it..
  Also i've been bitten a few times on systems that did rely on the
  bootable flag (what, what, why does it not boot, oo),
  which was another reason for heading this route.
 
  I really like the idea of using the bootable flag and looking at it
  but if its legacy in GPT will it go away in some future partition
  table layout? UEFI Requires that a ESP exist. I think requiring
  that the bootable flag exist is acceptable.
 
 One other alternative for GPT is to invent a new partition type UUID
 for bootable partitions. This likely has more implications though,
 since any tool that looks at the partition type UUID would have to be
 updated. I have no idea how many such tools exist though.

or perhaps use the ESP flag. though that might be totally confusing for
all.


 
  One issue with this approach is that there's no way for the user to
  short-circuit the scanning. If I put a ChromiumOS install on an SD
  card and leave it plugged into a system that's going to end up
  booting from eMMC since that's where the boot files are, there are
  lots of partitions to scan on that SD card, which will be a bit
  annoying.
 
  That is what happens on x86 today though. if you had a bootable
  cdrom/dvdrom or usb stick it will boot from that before the local
  install.
 
 x86 doesn't search all the partitions though, only those marked with
 the bootable flag. That's why I'm trying to drive the standard distro
 boot process (as implemented by U-Boot) to honor the bootable flag
 and ignore other partitions.

Right, bios uses the bootable flag, UEFI uses the ESP partition which
is why I guess GPT has the bootable flag as a legacy option. I'm in
agreement with you on honouring the bootable flag. I was just trying to
point out that if you put say a usb stick in a machine that had a live
image installed on it that's what the x86 system would boot.

Dennis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/4] config_distro_bootcmd: Scan all partitions for boot files

[Dennis Gilmore]

On Wed, 07 Jan 2015 12:46:20 +0100
Sjoerd Simons sjoerd.sim...@collabora.co.uk wrote:

 
   This is about the default setup though, it would be really nice
   to get consistent behaviour. I would be inclined to say that the
   defaults should conservatively try the internal/main storage
   first (assuming there will be an OS is installed there) and only
   fallback to other options later. 
  
  I'm inclined the other way, which is to boot of a removable media
  first if someone has gone to the effort to plug one in. People
  building kiosks etc who want to lock it down to internal only can
  still do so.
 
 This is the general problem of the user doing an action but the system
 really being unable to devine the intention behind that action.. An
 external storage device can have been plugged in for a lot of reasons,
 not just to boot from (you might have wnated to copy/inspect/change
 some data on the card). I would argue that the main reason for folks
 to plug in external storage devices into computers is not because
 they'd like to boot from it and furthermore that a lot of people
 would be confused if leaving in a storage card/stick makes the system
 unbootable.
 
 I suspect this argument comes down to how you expect users to normally
 use the system.. Iotw as a general computing device, just like your
 laptop or desktop machine or as a development toy where you regularly
 boot from external media (I would expect the former, but that's just
 me).

Well the intention here is for general computing devices. Where when
you get a machine you would pxe install or boot from a install image
provided by the os vendor. I think we should follow how x86 works and
default to external media first, then internal media followed by
network. All with the user being able to override the settings either
permanently or in a one off fashion.

Dennis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/4] config_distro_bootcmd: Scan all partitions for boot files

[Dennis Gilmore]

On Tue, 06 Jan 2015 17:43:19 -0700
Stephen Warren swar...@wwwdotorg.org wrote:

 (CCing Dennis so he can comment from a distro perspective re:
 partition table bootable flags v.s. scanning all partitions)
 
 On 01/06/2015 10:07 AM, Sjoerd Simons wrote:
  On Mon, 2015-01-05 at 13:24 -0700, Stephen Warren wrote:
  On 01/05/2015 10:13 AM, Sjoerd Simons wrote:
  Not all devices use the convention that the boot scripts are on
  the first partition. For example on chromebooks it seems common
  for the first two partitions to be ChromeOS kernel partitions.

ChromeOS seems to have adopted its own unique setup. it is not a
typical configuration.

 
  So instead of just the first partition scan all partitions on a
  device with a filesystem u-boot can recognize.
 
  I had planned (but obviously never got around to...) enhancing the
  scripts to look up the (set of?) bootable partition(s) on the disk
  and to attempt to load the boot files from there. Bootable would
  be defined as the MBR bootable flag, or GPT legacy bootable
  attribute.
 
  That would allow the code to zero in on the one specific partition
  that it was supposed to look at, rather than searching all
  partitions.
 
  Do you have any thoughts re: which option is better?
 
  I did wonder about this as well. I do personally consider the
  bootable flag as a rather obsolete/legacy thing (GPT even specifies
  it as a legacy flag), so i was wary about using it.. Also i've been
  bitten a few times on systems that did rely on the bootable flag
  (what, what, why does it not boot, oo), which was another
  reason for heading this route.

I really like the idea of using the bootable flag and looking at it but
if its legacy in GPT will it go away in some future partition table
layout? UEFI Requires that a ESP exist. I think requiring that the
bootable flag exist is acceptable.

  This way does no extra work if the first partition is the partition
  with the boot partition when compared to only checking partitions
  with the bootable flag as both would need to list existing
  partitions.
 
  If the first few partitions have no filesystems, the extra work
  compared to the bootable-flag approach would just be probing the
  filesystem type, which tends to be relatively simple, so i don't
  see a big issue there (it's more work to scan for a missing boot
  file).
 
  If your first few partitions are ones without the bootfiles, some
  more effort is wasted as it will be probing those for viable boot
  files.. However, in my experience, partition layouts with the
  bootfiles not on the first filesystem partitions is rather
  uncommmon. So again, i didn't feel that that was problematic. If
  you have an odd parition layout, your boot time will be ever so
  slightly longer :)
 
  The only issue in my mind is when multiple partitions, for
  whatever reason, have bootfiles. In which case the first one will
  get picked with this approach, while with the partition-boot-flag
  approach you'd have a way to specify, no really just look at that
  one.. However, i suspect the likelihood of forgetting to set the
  boot flag is higher (been there, done that) then accidentally
  leaving boot files on partitions before the intended boot partition
  (which also requires on uncommon layout), so even then i suspect
  this approach is more friendly/less error-prone.
 
  This patch looks fine assuming this option (rather than bootable
  flag) is selected.
 
  Well my thoughts on the matter are above, If folks feel strongly
  about this approach being the wrong way I'd love to hear their
  arguments :).
 
 One issue with this approach is that there's no way for the user to 
 short-circuit the scanning. If I put a ChromiumOS install on an SD
 card and leave it plugged into a system that's going to end up
 booting from eMMC since that's where the boot files are, there are
 lots of partitions to scan on that SD card, which will be a bit
 annoying.

That is what happens on x86 today though. if you had a bootable
cdrom/dvdrom or usb stick it will boot from that before the local
install.

Dennis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2] add README.distro file

[Dennis Gilmore]

On Mon, 05 Jan 2015 12:55:46 -0700
Stephen Warren swar...@wwwdotorg.org wrote:

 On 12/28/2014 03:09 AM, Ian Campbell wrote:
  On Mon, 2014-12-22 at 13:46 -0700, Stephen Warren wrote:
  [...]
  +
  +The U-Boot syslinux and pxe boot commands require a number of
  environment +variables be set. Default values for these variables
  are often hard-coded into +CONFIG_EXTRA_ENV_SETTINGS in the
  board's U-Boot configuration file, so that +the user doesn't have
  to configure them. +
  +fdt_addr:
  +
  +  Optional. If specified a dtb to boot the system must be
  available at the
  +  given address.
  +
  +fdt_addr_r:
  +
  +  Mandatory.
 
  Isn't this one only mandatory if ${fdt_addr} is not given?
 
 Yes. I guess it's mandatory for at least one of fdt_addr or
 fdt_addr_r to be set, according to common/cmd_pxe.c:
fdt_addr_r is actually mandatory unless you do not support device
tree at all, which is not expected at all anymore. The reason being
that the user/distro can override the vendor supplied dtb for whatever
reason, by supplying a fdt/dtb fdtdir/dtbdir entry in extlinux.conf  in
the past at times on calxeda hardware we had to override the dtb to work
with newer kernels until we could update the systems firmware.

   * fdt usage is optional:
   * It handles the following scenarios. All scenarios are
  exclusive *
   * Scenario 1: If fdt_addr_r specified and fdt label is
  defined in
   * pxe file, retrieve fdt blob from server. Pass fdt_addr_r
  to bootm,
   * and adjust argc appropriately.
   *
   * Scenario 2: If there is an fdt_addr specified, pass it
  along to
   * bootm, and adjust argc appropriately.
   *
   * Scenario 3: fdt blob is not available.
 
 So, I'll need to reword that a little to make that clear.

going forward Scenario 3 is not a supportable option. board files are
being removed from the kernel and dtb files are needed to boot
machines. at least for Fedora we do not support any systems that do not
support devicetree. so while the code in cmd_pxe.c is written for it to
be optional it is not. having fdt_addr_r does not force the use of a
dtb as it requires the config to specify it, so you could boot a legacy
kernel just fine by omitting the definition in the config file.

Dennis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH 7/7] Switch am335x_evm.h to use config_distro_defaults and config_distro_bootcmd. Add scriptaddr to DEFAULT_LINUX_BOOT_ENV, as scriptaddr is used for boot scripts in config_dis

[Dennis Gilmore]

On Fri,  3 Oct 2014 15:08:43 -0700
Vagrant Cascadian vagr...@debian.org wrote:

 Signed-off-by: Vagrant Cascadian vagr...@debian.org
 ---
 
  include/configs/am335x_evm.h  | 26 +-
  include/configs/ti_armv7_common.h |  1 +
  2 files changed, 18 insertions(+), 9 deletions(-)
 
 diff --git a/include/configs/am335x_evm.h
 b/include/configs/am335x_evm.h index e2f7ead..b25d990 100644
 --- a/include/configs/am335x_evm.h
 +++ b/include/configs/am335x_evm.h
 @@ -18,6 +18,21 @@
  
  #include configs/ti_am335x_common.h
  
 +#include config_distro_defaults.h
 +
 +#define BOOTENV_BOOT_PARTITIONS 2

On Fedora we use partition 1 everywhere for /boot so this should be 1
2 though partition 2 is swap in out standard images. we really need to
read the partition table and find the bootable partition. 

We are defaulting to telling people to put u-boot and the MLO in raw
disk space.

 +
 +#define BOOTENV_INIT_COMMAND run findfdt ;
 +#ifdef CONFIG_NAND
 +#define BOOTENV_POST_COMMAND run nandboot ;
 +#endif
 +
 +#define BOOT_TARGET_DEVICES(func) \
 + func(MMC, mmc, 0) \
 + func(MMC, mmc, 1)
 +
 +#include config_distro_bootcmd.h
 +
  #ifndef CONFIG_SPL_BUILD
  # define CONFIG_FIT
  # define CONFIG_TIMESTAMP
 @@ -185,17 +200,10 @@
   if test $fdtfile = undefined; then  \
   echo WARNING: Could not determine device
 tree to use; fi; \0 \ NANDARGS \
 - DFUARGS
 + DFUARGS \
 + BOOTENV
  #endif
  
 -#define CONFIG_BOOTCOMMAND \
 - run findfdt;  \
 - run mmcboot; \
 - setenv mmcdev 1;  \
 - setenv bootpart 1:2;  \
 - run mmcboot; \
 - run nandboot;
 -
  /* NS16550 Configuration */
  #define CONFIG_SYS_NS16550_COM1  0x44e09000  /*
 Base EVM has UART0 */ #define CONFIG_SYS_NS16550_COM2
 0x48022000/* UART1 */ diff --git
 a/include/configs/ti_armv7_common.h
 b/include/configs/ti_armv7_common.h index 85171db..f405fea 100644 ---
 a/include/configs/ti_armv7_common.h +++
 b/include/configs/ti_armv7_common.h @@ -54,6 +54,7 @@
  #define DEFAULT_LINUX_BOOT_ENV \
   loadaddr=0x8200\0 \
   kernel_addr_r=0x8200\0 \
 + scriptaddr=0x8200\0 \
   fdtaddr=0x8800\0 \
   fdt_addr_r=0x8800\0 \
   rdaddr=0x8808\0 \

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Wandboard console speed

[Dennis Gilmore]

Hi all,

The default environment for the wandboard does not specify the speed
for the console. I have an open bug in Fedora[1] I am curious if there
was a particular reason why the speed is not set, or if i should just
send in a patch to change it?  I really do not want to carry a patch
around forever. 


Dennis

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1044778
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Wandboard console speed

[Dennis Gilmore]

On Wed, 13 Aug 2014 15:00:43 -0300
Fabio Estevam feste...@gmail.com wrote:

 On Wed, Aug 13, 2014 at 2:55 PM, Dennis Gilmore den...@ausil.us
 wrote:
  Hi all,
 
  The default environment for the wandboard does not specify the speed
  for the console. I have an open bug in Fedora[1] I am curious if
  there was a particular reason why the speed is not set, or if i
  should just send in a patch to change it?  I really do not want to
  carry a patch around forever.
 
 Actually we do specify the baudrate in wandboard.h:
 
 console=${console},${baudrate}

must have changed recentlyish we are using 2014.04 and it's
console=ttymxc0 im in the process of updating to 2014.10 so i guess
its a non issue anymore

Dennis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Wandboard console speed

[Dennis Gilmore]

On Wed, 13 Aug 2014 15:33:43 -0300
Fabio Estevam feste...@gmail.com wrote:

 On Wed, Aug 13, 2014 at 3:30 PM, Dennis Gilmore den...@ausil.us
 wrote:
 
  must have changed recentlyish we are using 2014.04 and it's
  console=ttymxc0 im in the process of updating to 2014.10 so i
  guess its a non issue anymore
 
 It is the same in 2014.04:
 
 http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/wandboard.h;h=6c74c72952586f3e9264591c41af34d4bfa8e1e1;hb=dda0dbfc69f3d560c87f5be85f127ed862ea6721
 
 Please check lines 137 and 160.

check line 112, most boards just use the console variable and not the
way you have it set. in my porting to generic distro configs it seems
that we dropped off the re-configuring of the variable.  Ill send in a
patch to clean things up soon. along with porting to the distro generic
configs

Dennis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd

[Dennis Gilmore]

On Tue, 12 Aug 2014 19:29:02 +0200
Jeroen Hofstee jer...@myspectrum.nl wrote:

 Hello Stephan,
 
 On 11-08-14 20:55, Stephen Warren wrote:
 
 snip
 
  No, Linux distros need to be able to install a single bootloader
  configuration file to tell the bootloader how to boot.
 
  Don't understand this, I though extlinux is yet another
  chainloaded bootloader? I doubt there is the bootloader.
  I don't understand why it needs a single bootloader. It gets
  in handy if the last bootloader is known, but I don't even see
  why that is required.
 
  This is obviously where the disconnect is...
 
  extlinux is (IIRC) a bootloader yes. However, this patch isn't
  about extlinux, but extlinux.conf.
 
 
 haha, right that is a funny misunderstanding. Yes, extlinux is
 indeed a bootloader and I was in the impression you actively
 searched for it to chainload it. And to make extlinux a requirement
 for distro support... And as I tried to explain I am not that fond of
 such an approach in general, and that had nothing to do, as Tom
 suggested, with booting FreeBSD, it is just the image I encountered
 searching  for it in various places. It remains a badly named file
 though (for U-boot), but well so be it, I guess.

u-boot in the pxe code has an implementation that parses the syslinux
config file. though there really is nothing that says its a linux only
thing, admittedly I'm a bit naive as to how things like freebsd boot
but i assume you can load a kernel and pass some boot arguments just
the same. We are looking for a extlinux.conf file as that's what
extlinux looks for and we are mimicking the functionality.

  extlinux.conf is a text file format the defines a menu of bootable 
  OSs. It's a (de-facto I suppose) standard that's implemented by 
  extlinux (if indeed that is a piece of SW:-) and also U-Boot and 
  barebox and likely other bootloaders too.
 
  So, when U-Boot locates extlinux.conf on disk and processes it,
  it's parsing a configuration file/menu, not chain-loading/executing
  another bootloader.
 
 
 I see, so shouldn't we document then who is in charge of its format
 at least, before we start making a U-boot/distro specific version of
 it?

We are using the same format as is used by the syslinux project. we
support a couple of optional items to specify the dtb, fdt and fdtdir,
fdt is a location to a devicetree blob and fdtdir is a directory where
you can find devicetree blobs.

 snip example file
 
  That would require all Linux distros to have specific support to 
  install boot.scr, which is a bootloader-specific format script
  file. Systems that boot using e.g. Barebox or other bootloaders
  presumably can't process boot.scr. However, if all bootloaders end
  up supporting extlinux.conf, the distro won't care what bootloader
  is on the HW.
 
 We will see if this works, I am bit skeptical, but it is at least a 
 whole lot
 better then polling all possible options, where I took the patch for.
 (Well not all yet, but the start to do so).

Even with checking the different places that we can find the config
file. There is no noise, u-boot doesn't print out when there is no files
found only when it find them. The time to check for the existence of
the file is very quick.

Dennis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd

[Dennis Gilmore]

On Wed, 06 Aug 2014 10:01:09 -0600
Stephen Warren swar...@wwwdotorg.org wrote:

 On 07/30/2014 04:37 PM, Stephen Warren wrote:
  From: Dennis Gilmore den...@ausil.us
 
  This generic $bootcmd, and associated support macros, automatically
  searches a defined set of storage devices (or network protocols)
  for an extlinux configuration file or U-Boot boot script in various
  standardized locations. Distros that install such a boot config
  file/script in those standard locations will get easy-to-set-up
  booting on HW that enables this generic $bootcmd.
 
 Simon, are you OK with these patches following the discussion?
 Dennis, I assume you're OK with the new version of this patch?
I am okay with this version.

Dennis

 I assume that your acks would go a long way towards Tom applying this 
 series.
 
 Thanks.
 ___
 U-Boot mailing list
 U-Boot@lists.denx.de
 http://lists.denx.de/mailman/listinfo/u-boot

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd

[Dennis Gilmore]

On Mon, 4 Aug 2014 04:13:41 -0600
Simon Glass s...@chromium.org wrote:

 Hi Stephen,
 
 On 31 July 2014 17:00, Stephen Warren swar...@wwwdotorg.org wrote:
  On 07/31/2014 04:03 PM, Simon Glass wrote:
 
  Hi Stephen,
 
  On 30 July 2014 23:37, Stephen Warren swar...@wwwdotorg.org
  wrote:
 
  From: Dennis Gilmore den...@ausil.us
 
  This generic $bootcmd, and associated support macros,
  automatically searches a defined set of storage devices (or
  network protocols) for an extlinux configuration file or U-Boot
  boot script in various standardized locations. Distros that
  install such a boot config file/script in those standard
  locations will get easy-to-set-up booting on HW that enables this
  generic $bootcmd.
 
  Boards can define the set of devices from which boot is
  attempted, and the order in which they are attempted. Users may
  later customize this set/order by edting $boot_targets.
 
  Users may interrupt the boot process and boot from a specific
  device simply by executing e.g.:
 
  $ run bootcmd_mmc1
  or:
  $ run bootcmd_pxe
 
  This patch was originally written by Dennis Gilmore based on
  Tegra and rpi_b boot scripts. I have made the following
  modifications since then:
 
  * Boards must define the BOOT_TARGET_DEVICES macro in order to
  specify the set of devices (and order) from which to attempt
  boot. If needed, we can define a default directly in
  config_distro_bootcmd.h.
 
  * Removed $env_import and related variables; nothing used them,
  and I think it's better for boards to pre-load an environment
  customization file using CONFIG_PREBOOT if they need.
 
  * Renamed a bunch of variables to suit my whims:-)
 
  Signed-off-by: Dennis Gilmore den...@ausil.us
  Signed-off-by: Stephen Warren swar...@nvidia.com
 
 
  I do understand the desirability of getting something sorted in
  this area. But I am not thrilled with all the macro magic. How
  does this fit with the new Kconfig setup? It encourages a single
  setting for each variable, and I feel that the #ifdefs are not
  compatible with that.
 
 
  I think Kconfig would be completely unsuitable for this kind of
  detailed configuration. Kconfig is great for enabling/disabling
  features, but applying it here feels too much to me. Equally,
  Kconfig is rather new in U-Boot. It'd be better to enable the
  feature so that distros can rely on it, and then refactor it later
  if required.
 
 Are you saying that we can reimplement this in a nicer way and distros
 will still see the same behaviour?
As long as the implementation loads a extlinux.conf file yes. how
things are implemented in u-boot really does not matter at all. the API
between os and u-boot is the config file. 

 
  I do feel that actually implementing the boot script as U-Boot
  environment variables is much preferred over hard-coding any
  algorithm into U-Boot. That way, the user can easily modify the
  scripts as they desire. If we just put e.g. $boot_targets into the
  environment or DT, but none of the other scripts in this patch, the
  user would be much more severely restricted in how they could
  reconfigure the system to act how they want.
 
 But that worries me. It means that it is easy for one board to deviate
 from what is essentially an undocumented boot standard, and then we
 will end up having to support that use case in the future.
 
 Or if it is documented, where is that?

http://www.syslinux.org/wiki/index.php/Doc/syslinux
we have added fdt and fdtdir options for dealing with dtb.  we probably
should have our own documentation. We have adopted a standard. 

 
 
  Would it be possible to put the settings in the device tree somehow
  instead of CONFIGs?
 
 
  At least part of the information isn't a HW description, but rather
  user-/vendor configuration. So, I don't think it's appropriate to
  put this into DT. Equally, very few U-Boot platforms currently use
  DT, and I certainly hope it doesn't become mandatory in any way.
  So, using DT for this purpose would severely limit the platforms
  where this feature was available.
 
 The only platforms I see support for in your series are Tegra (which
 has DT) and Raspberry PI. Adding basic DT support is not really
 onerous so doesn't impose any real limits on adoption. In any case I'm
 mostly just responding to what I see might become a large and
 mandatory script setup in U-Boot. Would it not be better now to
 document this clearly and specify that changes are not supported? Then
 we might be able to refactor it later and still retain compatibility.
 If we have a clear API separate from the implementation then it is
 easier to live with the scripts knowing we can do things a different
 way later.
 
 Looking at this from a driver model perspective we would probably want
 to have a list of devices to try, in a certain order. Certainly driver
 model would support the approach in this series, but it would be a
 very ugly way of achieving the goal IMO.
 
 BTW in your series bootpart is always 1

Re: [U-Boot] [PATCH 7/7] sunxi: Add environment settings to make extlinux.conf booting work

[Dennis Gilmore]

On Fri, 01 Aug 2014 12:57:31 -0600
Stephen Warren swar...@wwwdotorg.org wrote:

 On 08/01/2014 01:46 AM, Hans de Goede wrote:
  Automatic booting using an extlinux.conf file requires various
  environment variables to be set.
 
 Acked-by: Stephen Warren swar...@nvidia.com
 
 I'd personally be tempted to set fdt_high=0x, 
 initrd_high=0x to stop U-Boot copying the DT/initrd from the 
 load location to some other location under 256M, but that's just an 
 optimization and entirely optional.

There has been quite a few times where using 0xff has caused
issues. I really think you should set bootm_size to something
reasonable. beaglebones for instance has to be 0x1000 as the
beaglebone white only has 256M of ram. and let u-boot move things
around, ensuring we do not get into a place where the decompressed
kernel overwrites memory. This behaviour is what I had in the docs I
had written earlier in the year.

Dennis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 7/7] sunxi: Add environment settings to make extlinux.conf booting work

[Dennis Gilmore]

On Fri, 01 Aug 2014 14:22:40 -0600
Stephen Warren swar...@wwwdotorg.org wrote:

 On 08/01/2014 02:05 PM, Dennis Gilmore wrote:
  On Fri, 01 Aug 2014 12:57:31 -0600
  Stephen Warren swar...@wwwdotorg.org wrote:
 
  On 08/01/2014 01:46 AM, Hans de Goede wrote:
  Automatic booting using an extlinux.conf file requires various
  environment variables to be set.
 
  Acked-by: Stephen Warren swar...@nvidia.com
 
  I'd personally be tempted to set fdt_high=0x,
  initrd_high=0x to stop U-Boot copying the DT/initrd from
  the load location to some other location under 256M, but that's
  just an optimization and entirely optional.
 
  There has been quite a few times where using 0xff has caused
  issues.
 
 What kind of issues?
 
 At least for Tegra, I've carefully chosen the values for the various 
 load addresses so that there won't be issues. (Without that I can
 easily see the potential for issues.) I've seen far more repeated
 problems when U-Boot moves the DT/initrd around than than when it
 didn't (none in that case). Besides, it's completely redundant and
 unnecessary work if the blobs are already loaded at sane addresses,
 which they are on Tegra at least.

Mostly to do with the decompressed kernel overwriting the initrd or dtb
resulting in machines that would hang on boot. it came up quite a few
times earlier this year on both imx and omap.

Dennis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 00/10] ARMv7: add PSCI support to U-Boot

[Dennis Gilmore]

On Sat, 26 Apr 2014 13:17:01 +0100
Marc Zyngier marc.zyng...@arm.com wrote:

 PSCI is an ARM standard that provides a generic interface that
 supervisory software can use to manage power in the following
 situations:
 - Core idle management
 - CPU hotplug
 - big.LITTLE migration models
 - System shutdown and reset
 
 It basically allows the kernel to offload these tasks to the firmware,
 and rely on common kernel side code that just calls into PSCI.
 
 More importantly, it gives a way to ensure that CPUs enter the kernel
 at the appropriate exception level (ie HYP mode, to allow the use of
 the virtualization extensions), even across events like CPUs being
 powered off/on or suspended.
 
 The main idea here is to turn some of the existing U-Boot code into a
 separate section that can live in secure RAM (or a reserved page of
 memory), containing a secure monitor that will implement the PSCI
 operations. This code will still be alive when U-Boot is long gone,
 hence the need for a piece of memory that will not be touched by the
 OS.
 
 This patch series contains 3 parts:
 - the first four patches are just bug fixes
 - the next two refactor the HYP/non-secure code to allow relocation
   in secure memory
 - the last four contain the generic PSCI code and DT infrastructure
 
 This implements the original 0.1 spec, as nobody implements the new
 0.2 version so far. I plan to update this support to 0.2 once there is
 an official binding available (and support in the kernel).
 
 Most of the development has been done on an Allwinner A20 SoC, which
 is the main user of this code at the moment. I hope new SoCs will be
 using this method in the future (my primary goal for this series being
 to avoid more stupid SMP code from creeping up in the Linux
 kernel). As instructed, I've removed the A20 support code and made it
 a separate series, as there is now an effort to mainline this code
 (see Ian Campbell patch series).
 
 With these three series applied, the A20 now boots in HYP mode, Linux
 finds the secondary CPU without any SMP code present in the kernel,
 and runs KVM out of the box. The Xen/ARM guys managed to do the same
 fairly easily, as did at least one XVizor user.
 
 This code has also been tested on a VExpress TC2, running KVM with all
 5 CPUs, in order to make sure there was no obvious regression.
 
 The code is also available at:
 git://git.kernel.org/pub/scm/linux/kernel/git/maz/u-boot.git
 wip/psci-v4
 
 A fully merged branch with the A20 support is in the wip/psci-v4-a20
 branch of the same repo.
 
 Cheers,
 
 M.
 
 From v3:
 - Return ARM_PSCI_RET_INVAL instead of ARM_PSCI_RET_NI when PSCI is
 entered with an invalid function code.
 - Fix !NONSEC compilation
 - Rebased on top of adcdeac
 
 From v2:
 - Dropped the secure stack allocation from the generic PSCI code.
 There was too little space there for it to be really useful, and the
 arch code knows a lot better about its requirements anyway. It is now
 the responsibility of the arch code to provide a stack. This allows
 it to get rid of the silly game with the thread registers that was
 confusing everyone...
 - Added provision for FIQ handling in secure mode. Allwinner A20 is 
 going to require this for CPU_OFF.
 - Better integration of the FDT injection code with the rest of the 
 code, fixing the truncated FDT issue that people have been reporting 
 (courtesy of Ma Haijun).
 - Cleanup of the AW-specific code (stack allocation, timer macro).
 - Rebased on mainline U-Boot (on top of 22a240c32c13).
 
 From v1:
 - Complete rewrite, now directly relocating the secure code withing
 U-Boot, instead of having a separate psci blob.
 
 Ma Haijun (1):
   ARM: convert arch_fixup_memory_node to a generic FDT fixup function
 
 Marc Zyngier (9):
   ARM: HYP/non-sec: move switch to non-sec to the last boot phase
   ARM: HYP/non-sec: add a barrier after setting SCR.NS==1
   ARM: non-sec: reset CNTVOFF to zero
   ARM: add missing HYP mode constant
   ARM: HYP/non-sec: add separate section for secure code
   ARM: HYP/non-sec: allow relocation to secure RAM
   ARM: HYP/non-sec: add generic ARMv7 PSCI code
   ARM: HYP/non-sec: add the option for a second-stage monitor
   ARM: HYP/non-sec/PSCI: emit DT nodes
 
  arch/arm/config.mk  |   2 +-
  arch/arm/cpu/armv7/Makefile |   5 +
  arch/arm/cpu/armv7/nonsec_virt.S| 168
 +---
 arch/arm/cpu/armv7/psci.S   | 102 +++
 arch/arm/cpu/armv7/virt-dt.c| 100 +++
 arch/arm/cpu/armv7/virt-v7.c|  59 ---
 arch/arm/cpu/u-boot.lds |  30 ++
 arch/arm/include/asm/armv7.h|  11 ++-
 arch/arm/include/asm/proc-armv/ptrace.h |   2 +
 arch/arm/include/asm/psci.h |  35 +++
 arch/arm/include/asm/secure.h   |  26 +
 arch/arm/lib/bootm-fdt.c|  14 ++-
 arch/arm/lib/bootm.c|  27 +++--
 

Re: [U-Boot] [PATCH v4 00/10] ARMv7: add PSCI support to U-Boot

[Dennis Gilmore]

On Sat, 26 Apr 2014 17:31:03 +0100
Marc Zyngier marc.zyng...@arm.com wrote:

 On 2014-04-26 15:24, Dennis Gilmore wrote:
  On Sat, 26 Apr 2014 13:17:01 +0100
  Marc Zyngier marc.zyng...@arm.com wrote:
 
  PSCI is an ARM standard that provides a generic interface that
  supervisory software can use to manage power in the following
  situations:
  - Core idle management
 
 [...]
 
 
  this series fails to compile for me
CC  spl/arch/arm/cpu/armv7/virt-v7.o
  arch/arm/cpu/armv7/virt-v7.c: In function ‘armv7_init_nonsec’:
  arch/arm/cpu/armv7/virt-v7.c:128:41: error: ‘_smp_pen’ undeclared
  (first use in this function)
smp_set_core_boot_addr((unsigned long)secure_ram_addr(_smp_pen), 
  -1);
   ^
  arch/arm/cpu/armv7/virt-v7.c:128:41: note: each undeclared
  identifier is reported only once for each function it appears in
  arch/arm/cpu/armv7/virt-v7.c:134:3: error: ‘_nonsec_init’ undeclared
  (first use in this function)
secure_ram_addr(_nonsec_init)();
 ^
 
  is there a series I am missing?
 
 Interesting. What are you compiling for? Having the non-virt part
 built in the SPL is unexpected though..

Cubietruck trying to pull in the patches so we can support it in
Fedora, ended up being user error. I did a make mrproper and
reconfigured then it built fine.

Dennis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] config: enable CONFIG_API in distro config

[Dennis Gilmore]

On Sun, 20 Apr 2014 09:55:53 -0700
Simon Glass s...@chromium.org wrote:

 Hi Dennis,
 
 On 19 April 2014 08:42, Dennis Gilmore den...@ausil.us wrote:
 
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  On Sat, 19 Apr 2014 15:01:40 +0100
  Ian Campbell i...@hellion.org.uk wrote:
 
   On Fri, 2014-04-18 at 11:43 -0600, Simon Glass wrote:
Hi Stephen,
   
On 18 April 2014 11:23, Stephen Warren swar...@wwwdotorg.org
wrote:
 On 04/18/2014 09:35 AM, Tom Rini wrote:
 On Thu, Apr 10, 2014 at 03:55:48PM -0500, Rob Herring wrote:

 From: Rob Herring r...@kernel.org

 CONFIG_API is needed for u-boot apps such as grub2, so
 enable it for distro config.

 Cc: Dennis Gilmore den...@ausil.us
 Signed-off-by: Rob Herring r...@kernel.org

 This breaks a number of boards that have opted in to the
 distro config. The full list is:
 whistler trimslice beaver tec paz00 ventana cardhu harmony
 dalmore plutux medcom-wide rpi_b venice2 colibri_t20_iris
 tec-ng seaboard

 How do you guys want to handle this?  I can apply now and
 they can be fixed up later, or I can wait for fixup patches
 to come out and apply them all at once.  Thanks!

 I've sent patches that solve all the build problems on Tegra
 with CONFIG_API enabled.

 That said, I still conceptually object to
 config_distro_defaults.h enabling API support in order to
 support grub; I believe the distros need to get together and
 nail down a *single* boot mechanism to standardize upon,
 rather than having Fedora support BootloaderSpec,
 Ubuntu/Linaro(?) support Grub, something else support LILO,
 something else support UEFI,
  
   AIUI the distros *are* standardising: on grub2.
 
  not in arm space at least,
 
 
 I have no great love for grub2 and the pain of not using on ARM
 devices would in my case succumb to an extremely small aspirin.

that I know of only ppc and x86 use grub2, I never quite got it working
on sparc before I gave up on the platform. What we are trying to do is
to make the default user experience just work, be simple, easily
updateable. 

 
   AIUI BootloaderSpec is a spec to standardise the configuration of
   UEFI. It is used to install the distro's bootloader (often grub2)
   into the UEFI boot list, for grub-on-UEFI scenarios.
 
  not at all true, bootloader spec is designed to be a platform and
  bootloader agnostic way to boot open systems. its designed to
  share /boot between open operating systems, UEFI, bios, u-boot etc
  have zero to do with it. you can compliantly boot operating systems
  using any type of platform
 
   Where the lowlevel firmware is u-boot then they want to use grub2
   on it so that things are consistently grub no matter whether the
   platform uses UEFI, u-boot, PC BIOS etc.
  
 etc. Without this, we'll force every U-Boot binary to
 be bloated with all kinds of redundant code. Having a single
 standard mechanism was always the point of
 config_distro_defaults.h in my mind. If we really need Grub
 support, wouldn't it be better to have U-Boot parse and
 execute grub.cfg, just like it does extlinux.cfg?
   
That seems to make a lot more sense to me. How hard can it
possibly be?
  
   Very. grub.cfg is essentially a complete bash-a-like programming
   language. At work we try to parse it for Xen's pygrub utility
   and it breaks pretty frequently when people introduce random new
   variables etc.
 
  Which is why we are standardising distro booting using u-boots
  syslinux compatibility in distro land.  it's not uncommon to users,
  since isos have used isolinux for years. right now its feature set
  is somewhat simple. but over time we should be able to do things
  like commandline editing and using menu to select different
  kernels.  But there is a very solid foundation available today that
  works really well.
 
 
 Can you suggest a starting point for trying this out on am ARM
 platform? (e.g. OMAP, Tegra, Exynos) I'd like to see how it works.

as of 2014.04 it will work on tegra, its worked on calxeda since it was
added but their default environment is outside of u-boot itself. I have
some patches submitted that need futher thought and work converting
omap and wandboard. If you have a prefered platform I can throw
together a patch for you to test.

 
 
  AFAIK no one is really working on grub2 for use with u-boot as
  linaro who was doing the work have decided to drop u-boot support
  and only do UEFI.
 
 
 So UEFI boots through grub2? We seem to have a talent for making
 things complicated?
UEFI is loading grub2. I think some people have tried gummiboot, i do
not know of anyone using UEFI directly as its not really all that
simple to do.

 Regards,
 Simon

Dennis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] TI: Add, use a DEFAULT_LINUX_BOOT_ENV environment string

[Dennis Gilmore]

On Tue, 11 Mar 2014 15:42:01 -0400
Tom Rini tr...@ti.com wrote:

 To deal with a reoccurring problem properly we need to specify
 addresses for the Linux kernel, Flatted Device Tree and ramdisk that
 obey the constraints within the kernel's Documentation/arm/Booting
 file but also make sure that we relocate things within a valid
 address range.
 
 It is possible with these addresses to also set fdt_high and
 initrd_high to the value of 0x.  We don't do this by default
 to allow for the most likely success of people using custom addresses
 however.
 
 Signed-off-by: Tom Rini tr...@ti.com

Tested-by: Dennis Gilmore dgilm...@redhat.com
Reviewed-By: Dennis Gilmore dgilm...@redhat.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] am335x_evm: Update the ramdisk args, we pass things in just fine via DT

[Dennis Gilmore]

On Tue, 11 Mar 2014 15:42:02 -0400
Tom Rini tr...@ti.com wrote:

 Signed-off-by: Tom Rini tr...@ti.com
 ---
  include/configs/am335x_evm.h |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/include/configs/am335x_evm.h
 b/include/configs/am335x_evm.h index 6bd8aec..11088b3 100644
 --- a/include/configs/am335x_evm.h
 +++ b/include/configs/am335x_evm.h
 @@ -79,7 +79,7 @@
   nfsopts=nolock\0 \
   static_ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}
 \ ::off\0 \
 - ramroot=/dev/ram0 rw ramdisk_size=65536
 initrd=${rdaddr},64M\0 \
 + ramroot=/dev/ram0 rw\0 \
   ramrootfstype=ext2\0 \
   mmcargs=setenv bootargs console=${console}  \
   ${optargs}  \


Reviewed-By: Dennis Gilmore dgilm...@redhat.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] am43xx_evm: Update the ramdisk args, we pass things in just fine via DT

[Dennis Gilmore]

On Tue, 11 Mar 2014 15:42:03 -0400
Tom Rini tr...@ti.com wrote:

 Signed-off-by: Tom Rini tr...@ti.com
 ---
  include/configs/am43xx_evm.h |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/include/configs/am43xx_evm.h
 b/include/configs/am43xx_evm.h index 2c5..2d9825b 100644
 --- a/include/configs/am43xx_evm.h
 +++ b/include/configs/am43xx_evm.h
 @@ -128,7 +128,7 @@
   usbroot=/dev/sda2 rw\0 \
   usbrootfstype=ext4 rootwait\0 \
   usbdev=0\0 \
 - ramroot=/dev/ram0 rw ramdisk_size=65536
 initrd=${rdaddr},64M\0 \
 + ramroot=/dev/ram0 rw\0 \
   ramrootfstype=ext2\0 \
   mmcargs=setenv bootargs console=${console}  \
   ${optargs}  \

Reviewed-By: Dennis Gilmore dgilm...@redhat.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 0/6] unified boot environment

[Dennis Gilmore]

Hi All,

The attached patches build on the work for generic distro config, as well as
Stephen Warrens implementation for tegra. They depend on Toms Patches to move
ti to using DEFAULT_LINUX_BOOT_ENV on TI systems.

There is a README file to describe how to convert a system. I have added a
header to be included that will allow all boards to boot in the same way and
I have ported over three boards to use it.

Dennis


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 1/6] add README.distro file

[Dennis Gilmore]

Add documentation on how to setup a system to use the generic distro
configs and boot commands. This spells out what is needed to make a
system conformant, but does not limit the board to only the defaults.

Signed-off-by: Dennis Gilmore den...@ausil.us
---
 doc/README.distro | 76 +++
 1 file changed, 76 insertions(+)
 create mode 100644 doc/README.distro

diff --git a/doc/README.distro b/doc/README.distro
new file mode 100644
index 000..435c578
--- /dev/null
+++ b/doc/README.distro
@@ -0,0 +1,76 @@
+/*
+ * (C) Copyright 2014 Red Hat Inc.
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+Generic distro configuration
+
+
+configuring
+---
+To configure a board to run the generic distro setup and enable generic distros
+to easily support your board.
+
+you will need to include a pair of headers to enable the boot environment and
+configuration options needed. It is best to only include when not doing an
+SPL build.
+
+#ifndef CONFIG_SPL_BUILD
+#include config_distro_defaults.h
+#include config_distro_bootcmd.h
+#endif
+
+There is some memory addresses you will need to define in
+CONFIG_EXTRA_ENV_SETTINGS
+fdt_addr:
+Optional, If specified a dtb to boot the system must be available at the given
+address.
+
+fdt_addr_r:
+Mandatory, This is the location where the sysboot/pxeboot with load the dtb to,
+using the fdtdir/devicetreedir or fdt/devicetree options in the pxe/extlinux
+config file. The location can be anywhere in ram it just needs to not overlap
+with anything, allowing 1 megabyte seems to be a safe option.
+
+ramdisk_addr_r:
+Mandatory, This is the location where the sysboot/pxeboot with load the
+initramfs to, using the initrd option in the pxe/extlinux config file, the
+location of the initramfs does not matter, there needs to be enough room to be
+able to store any image. Making the image the last item stored should allow for
+any initramfs to fit and not overwrite anything else.
+
+kernel_addr_r:
+Mandatory, This is the location where the sysboot/pxeboot with load the kernel
+to,using the kernel option in the pxe/extlinux config file, the location of the
+kernel needs to 
+
+pxe_addr_r:
+Mandatory, used by the PXE code to hold the pxelinux config file. The location
+can be anywhere in ram it just needs to not overlap with anything, allowing 1 
+megabyte seems to be a safe option.
+
+scriptaddr:
+Mandatory, used to load boot.scr to The location can be anywhere in ram it just
+needs to not overlap with anything, allowing 1 megabyte seems to be a safe
+option.
+
+suggested mapping:
+For suggestions on memory locations for arm systems  you must follow the
+guidelines specified in Documentation/arm/Booting in the Linux kernel tree.
+For other architectures you must follow the guidelines for the architecture.
+
+make sure you also include BOOTCMDS_COMMON in CONFIG_EXTRA_ENV_SETTINGS
+
+You should not set initrd_high and fdt_high to 0x as the user should
+not need to edit the memory locations having the initramfs and dtb being
+relocatable is best to ensure the system will boot in all situations. 
+
+booting your system
+---
+in the most simplest form CONFIG_BOOTCOMMAND just needs one line
+
+for target in ${boot_targets}; do run bootcmd_${target}; done 
+
+you can run any setup before going through the targets for example run a
+command to set fdtfile variable for the dtb for your board.
-- 
1.9.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 5/6] move pandaboard over to use the generic distro configuation and environment

[Dennis Gilmore]

port pandaboard to use the generic distro configuation.
remove duplicated config options, clean up the environment, include new
environment.

Signed-off-by: Dennis Gilmore den...@ausil.us
---
 include/configs/omap4_panda.h |  2 --
 include/configs/ti_omap4_common.h | 37 +++--
 2 files changed, 11 insertions(+), 28 deletions(-)

diff --git a/include/configs/omap4_panda.h b/include/configs/omap4_panda.h
index 7378acd..1b81a24 100644
--- a/include/configs/omap4_panda.h
+++ b/include/configs/omap4_panda.h
@@ -33,8 +33,6 @@
 
 #define CONFIG_UBOOT_ENABLE_PADS_ALL
 
-#define CONFIG_CMD_PING
-#define CONFIG_CMD_DHCP
 
 #include configs/ti_omap4_common.h
 #define CONFIG_CMD_NET
diff --git a/include/configs/ti_omap4_common.h 
b/include/configs/ti_omap4_common.h
index 387f570..f9baa50 100644
--- a/include/configs/ti_omap4_common.h
+++ b/include/configs/ti_omap4_common.h
@@ -86,6 +86,7 @@
 /*
  * Environment setup
  */
+#ifndef CONFIG_SPL_BUILD
 #define CONFIG_EXTRA_ENV_SETTINGS \
DEFAULT_LINUX_BOOT_ENV \
console=ttyO2,115200n8\0 \
@@ -102,16 +103,16 @@
vram=${vram}  \
root=${mmcroot}  \
rootfstype=${mmcrootfstype}\0 \
-   loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0 \
+   loadbootscript=load mmc ${mmcdev} ${kernel_addr_r} boot.scr\0 \
bootscript=echo Running bootscript from mmc${mmcdev} ...;  \
-   source ${loadaddr}\0 \
-   loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0 \
+   source ${kernel_addr_r}\0 \
+   loadbootenv=load mmc ${mmcdev} ${kernel_addr_r} uEnv.txt\0 \
importbootenv=echo Importing environment from mmc${mmcdev} ...;  \
-   env import -t ${loadaddr} ${filesize}\0 \
-   loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0 \
+   env import -t ${kernel_addr_r} ${filesize}\0 \
+   loadimage=load mmc ${bootpart} ${kernel_addr_r} 
${bootdir}/${bootfile}\0 \
mmcboot=echo Booting from mmc${mmcdev} ...;  \
run mmcargs;  \
-   bootz ${loadaddr} - ${fdtaddr}\0 \
+   bootz ${kernel_addr_r} - ${fdt_addr_r}\0 \
findfdt=\
if test $board_name = sdp4430; then  \
setenv fdtfile omap4-sdp.dtb; fi;  \
@@ -123,29 +124,13 @@
setenv fdtfile omap4-panda-es.dtb; fi; \
if test $fdtfile = undefined; then  \
echo WARNING: Could not determine device tree to use; 
fi; \0 \
-   loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}\0 \
+   loadfdt=load mmc ${bootpart} ${fdt_addr_r} ${bootdir}/${fdtfile}\0 \
+   BOOTCMDS_COMMON
+#endif
 
 #define CONFIG_BOOTCOMMAND \
run findfdt;  \
-   mmc dev ${mmcdev}; if mmc rescan; then  \
-   echo SD/MMC found on device ${mmcdev}; \
-   if run loadbootscript; then  \
-   run bootscript;  \
-   else  \
-   if run loadbootenv; then  \
-   run importbootenv;  \
-   fi; \
-   if test -n ${uenvcmd}; then  \
-   echo Running uenvcmd ...; \
-   run uenvcmd; \
-   fi; \
-   fi; \
-   if run loadimage; then  \
-   run loadfdt; \
-   run mmcboot;  \
-   fi;  \
-   fi
-
+   for target in ${boot_targets}; do run bootcmd_${target}; done 
 /*
  * Defines for SPL
  * It is known that this will break HS devices. Since the current size of
-- 
1.9.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/6] add header with a generic set of boot commands defined.

[Dennis Gilmore]

As the next step in a generic config we are introducing a set of generic boot
paramaters. Depending on the hardwares configuration, booting from supported
hardware will be enabled, mmc, usb, sata, scsi, ide, pxe and dhcp.

There is nothing to stop this being extended to support nand and any other
type of storage that comes along. An ideal future enhancement will be to
allow the user to dynamically reorder the boot devices, and allow one off
boots. for example simply be able to pxe boot to reinstall

Signed-off-by: Dennis Gilmore den...@ausil.us
---
 include/config_distro_bootcmd.h | 208 
 1 file changed, 208 insertions(+)
 create mode 100644 include/config_distro_bootcmd.h

diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
new file mode 100644
index 000..0fe94be
--- /dev/null
+++ b/include/config_distro_bootcmd.h
@@ -0,0 +1,208 @@
+/*
+ * (C) Copyright 2014
+ * NVIDIA Corporation www.nvidia.com
+ *  
+ * Copyright 2014 Red Hat, Inc.
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H
+#define _CONFIG_CMD_DISTRO_BOOTCMD_H
+
+
+#ifdef CONFIG_CMD_MMC
+#define BOOTCMDS_MMC \
+   mmc_boot= \
+   setenv devtype mmc;  \
+   if mmc dev ${devnum}; then  \
+   run scan_boot;  \
+   fi\0 \
+   bootcmd_mmc0=setenv devnum 0; run mmc_boot;\0 \
+   bootcmd_mmc1=setenv devnum 1; run mmc_boot;\0
+#define BOOT_TARGETS_MMC mmc1 mmc0
+#else
+#define BOOTCMDS_MMC 
+#define BOOT_TARGETS_MMC 
+#endif
+
+#ifdef CONFIG_CMD_USB
+#define BOOTCMD_INIT_USB run usb_init; 
+#define BOOTCMDS_USB \
+   usb_init= \
+   if ${usb_need_init}; then  \
+   set usb_need_init false;  \
+   usb start 0;  \
+   fi\0 \
+   \
+   usb_boot= \
+   setenv devtype usb;  \
+   BOOTCMD_INIT_USB \
+   if usb dev ${devnum}; then  \
+   run scan_boot;  \
+   fi\0 \
+   \
+   bootcmd_usb0=setenv devnum 0; run usb_boot;\0 \
+   bootcmd_usb1=setenv devnum 1; run usb_boot;\0
+#define BOOT_TARGETS_USB usb0 usb1
+#else
+#define BOOTCMD_INIT_USB 
+#define BOOTCMDS_USB 
+#define BOOT_TARGETS_USB 
+#endif
+
+#ifdef CONFIG_CMD_SATA
+#define BOOTCMDS_SATA \
+   sata_boot= \
+   setenv devtype sata;  \
+   if sata dev ${devnum}; then  \
+   run scan_boot;  \
+   fi\0 \
+   \
+   bootcmd_sata0=setenv devnum 0; run sata_boot;\0 \
+   bootcmd_sata1=setenv devnum 1; run sata_boot;\0
+#define BOOT_TARGETS_SATA sata0 sata1
+#else
+#define BOOTCMDS_SATA 
+#define BOOT_TARGETS_SATA 
+#endif
+
+#ifdef CONFIG_CMD_SCSI
+#define BOOTCMDS_SCSI \
+scsi_boot= \
+setenv devtype scsi;  \
+if scsi dev ${devnum}; then  \
+run scan_boot;  \
+fi\0 \
+\
+bootcmd_scsi0=setenv devnum 0; run scsi_boot;\0 \
+bootcmd_scsi1=setenv devnum 1; run scsi_boot;\0
+#define BOOT_TARGETS_SCSI scsi0 scsi1
+#else
+#define BOOTCMDS_SCSI 
+#define BOOT_TARGETS_SCSI 
+#endif
+
+#ifdef CONFIG_CMD_IDE
+#define BOOTCMDS_IDE \
+ide_boot= \
+setenv devtype ide;  \
+if ide dev ${devnum}; then  \
+run scan_boot;  \
+fi\0 \
+\
+bootcmd_ide0=setenv devnum 0; run ide_boot;\0 \
+bootcmd_ide1=setenv devnum 1; run ide_boot;\0
+#define BOOT_TARGETS_IDE ide0 ide1
+#else
+#define BOOTCMDS_IDE 
+#define BOOT_TARGETS_IDE 
+#endif
+
+#ifdef CONFIG_CMD_DHCP
+#define BOOTCMDS_DHCP \
+   bootcmd_dhcp= \
+   BOOTCMD_INIT_USB \
+   if dhcp ${scriptaddr} boot.scr.uimg; then \
+   source ${scriptaddr};  \
+   fi\0
+#define BOOT_TARGETS_DHCP dhcp
+#else
+#define BOOTCMDS_DHCP 
+#define BOOT_TARGETS_DHCP 
+#endif
+
+#if defined(CONFIG_CMD_DHCP)  defined(CONFIG_CMD_PXE)
+#define BOOTCMDS_PXE \
+   bootcmd_pxe= \
+   BOOTCMD_INIT_USB \
+   dhcp;  \
+   if pxe get; then  \
+   pxe boot;  \
+   fi\0
+#define BOOT_TARGETS_PXE pxe
+#else
+#define BOOTCMDS_PXE 
+#define BOOT_TARGETS_PXE 
+#endif
+
+#define BOOTCMDS_COMMON \
+   rootpart=1\0 \
+   \
+   do_envimport=   \
+   load ${devtype} ${devnum}:${rootpart} ${loadaddr}   \
+   ${environment}\0\
+   env import -t ${loadaddr} $filesize\0   \
+   \
+   envimport=  \
+   for environment in ${boot_envs}; do \
+   if test -e ${devtype} ${devnum}:${rootpart

[U-Boot] [PATCH 4/6] move beagleboard over to use the generic distro configuation and environment

[Dennis Gilmore]

port beagleboard to use the generic distro configuation.
remove duplicated config options, clean up the environment, include new
environment.

Signed-off-by: Dennis Gilmore den...@ausil.us
---
 include/configs/am335x_evm.h  | 62 +--
 include/configs/ti_armv7_common.h | 32 ++--
 2 files changed, 23 insertions(+), 71 deletions(-)

diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 11088b3..1dd4486 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -50,9 +50,9 @@
nandrootfstype=ubifs rootwait=1\0 \
nandboot=echo Booting from nand ...;  \
run nandargs;  \
-   nand read ${fdtaddr} u-boot-spl-os;  \
-   nand read ${loadaddr} kernel;  \
-   bootz ${loadaddr} - ${fdtaddr}\0
+   nand read ${fdt_addr_r} u-boot-spl-os;  \
+   nand read ${kernel_addr_r} kernel;  \
+   bootz ${kernel_addr_r} - ${fdt_addr_r}\0
 #else
 #define NANDARGS 
 #endif
@@ -100,60 +100,28 @@
nfsroot=${serverip}:${rootpath},${nfsopts} rw  \
ip=dhcp\0 \
bootenv=uEnv.txt\0 \
-   loadbootenv=load mmc ${mmcdev} ${loadaddr} ${bootenv}\0 \
+   loadbootenv=load mmc ${mmcdev} ${kernel_addr_r} ${bootenv}\0 \
importbootenv=echo Importing environment from mmc ...;  \
-   env import -t $loadaddr $filesize\0 \
+   env import -t $kernel_addr_r $filesize\0 \
ramargs=setenv bootargs console=${console}  \
${optargs}  \
root=${ramroot}  \
rootfstype=${ramrootfstype}\0 \
-   loadramdisk=load mmc ${mmcdev} ${rdaddr} ramdisk.gz\0 \
-   loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0 \
-   loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}\0 \
-   mmcloados=run mmcargs;  \
-   if test ${boot_fdt} = yes || test ${boot_fdt} = try; then  \
-   if run loadfdt; then  \
-   bootz ${loadaddr} - ${fdtaddr};  \
-   else  \
-   if test ${boot_fdt} = try; then  \
-   bootz;  \
-   else  \
-   echo WARN: Cannot load the DT;  \
-   fi;  \
-   fi;  \
-   else  \
-   bootz;  \
-   fi;\0 \
-   mmcboot=mmc dev ${mmcdev};  \
-   if mmc rescan; then  \
-   echo SD/MMC found on device ${mmcdev}; \
-   if run loadbootenv; then  \
-   echo Loaded environment from ${bootenv}; \
-   run importbootenv; \
-   fi; \
-   if test -n $uenvcmd; then  \
-   echo Running uenvcmd ...; \
-   run uenvcmd; \
-   fi; \
-   if run loadimage; then  \
-   run mmcloados; \
-   fi; \
-   fi;\0 \
spiboot=echo Booting from spi ...;  \
run spiargs;  \
sf probe ${spibusno}:0;  \
-   sf read ${loadaddr} ${spisrcaddr} ${spiimgsize};  \
-   bootz ${loadaddr}\0 \
+   sf read ${kernel_addr_r} ${spisrcaddr} ${spiimgsize};  \
+   bootz ${kernel_addr_r}\0 \
netboot=echo Booting from network ...;  \
setenv autoload no;  \
dhcp;  \
-   tftp ${loadaddr} ${bootfile};  \
-   tftp ${fdtaddr} ${fdtfile};  \
+   tftp ${kernel_addr_r} ${bootfile};  \
+   tftp ${fdt_addr_r} ${fdtfile};  \
run netargs;  \
-   bootz ${loadaddr} - ${fdtaddr}\0 \
+   bootz ${kernel_addr_r} - ${fdt_addr_r}\0 \
ramboot=echo Booting from ramdisk ...;  \
run ramargs;  \
-   bootz ${loadaddr} ${rdaddr} ${fdtaddr}\0 \
+   bootz ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}\0 \
findfdt=\
if test $board_name = A335BONE; then  \
setenv fdtfile am335x-bone.dtb; fi;  \
@@ -166,15 +134,13 @@
if test $fdtfile = undefined; then  \
echo WARNING: Could not determine device tree to use; 
fi; \0 \
NANDARGS \
-   DFUARGS
+   DFUARGS \
+   BOOTCMDS_COMMON
 #endif
 
 #define CONFIG_BOOTCOMMAND \
run findfdt;  \
-   run mmcboot; \
-   setenv mmcdev 1;  \
-   setenv bootpart 1:2;  \
-   run mmcboot; \
+   for target in ${boot_targets}; do run bootcmd_${target}; done  \
run nandboot;
 
 /* NS16550 Configuration */
diff --git a/include/configs/ti_armv7_common.h 
b/include/configs

[U-Boot] [PATCH 6/6] pxe: additionaly check for fdt_file env variable

[Dennis Gilmore]

some boards have used fdt_file while others have used fdtfile to
define the name of the fdt file. If we do notget a fdtfile environment
variable, additionally check for fdt_file.

Signed-off-by: Dennis Gilmore den...@ausil.us
---
 common/cmd_pxe.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/common/cmd_pxe.c b/common/cmd_pxe.c
index 3483328..c58e471 100644
--- a/common/cmd_pxe.c
+++ b/common/cmd_pxe.c
@@ -712,6 +712,13 @@ static int label_boot(cmd_tbl_t *cmdtp, struct pxe_label 
*label)
char *f1, *f2, *f3, *f4, *slash;
 
f1 = getenv(fdtfile);
+   /*
+* some boards have used fdt_file as the environment 
variable for
+* defining the device tree file so lets check for 
fdt_file also.
+*/
+   if (!f1) {
+   f1 = getenv(fdt_file);
+   }
if (f1) {
f2 = ;
f3 = ;
-- 
1.9.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 3/6] move wandboard over to use the generic distro configuation and environment

[Dennis Gilmore]

port wandboard to use the generic distro configuation.
remove duplicated config options, clean up the environment, include new
environment.

Signed-off-by: Dennis Gilmore den...@ausil.us
---
 include/configs/wandboard.h | 92 +++--
 1 file changed, 14 insertions(+), 78 deletions(-)

diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h
index 6c74c72..386fe78 100644
--- a/include/configs/wandboard.h
+++ b/include/configs/wandboard.h
@@ -49,8 +49,6 @@
 #define CONFIG_CMD_BMODE
 #define CONFIG_CMD_SETEXPR
 
-#define CONFIG_BOOTDELAY   5
-
 #define CONFIG_SYS_MEMTEST_START   0x1000
 #define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_MEMTEST_START + 500 * SZ_1M)
 #define CONFIG_LOADADDR0x1200
@@ -66,15 +64,8 @@
 #define CONFIG_CMD_MMC
 #define CONFIG_GENERIC_MMC
 #define CONFIG_BOUNCE_BUFFER
-#define CONFIG_CMD_EXT2
-#define CONFIG_CMD_FAT
-#define CONFIG_DOS_PARTITION
 
 /* Ethernet Configuration */
-#define CONFIG_CMD_PING
-#define CONFIG_CMD_DHCP
-#define CONFIG_CMD_MII
-#define CONFIG_CMD_NET
 #define CONFIG_FEC_MXC
 #define CONFIG_MII
 #define IMX_FEC_BASE   ENET_BASE_ADDR
@@ -100,6 +91,11 @@
 #define CONFIG_IPUV3_CLK 26000
 #define CONFIG_IMX_HDMI
 
+#ifndef CONFIG_SPL_BUILD
+#include config_distro_defaults.h
+#include config_distro_bootcmd.h
+#endif
+
 #if defined(CONFIG_MX6DL) || defined(CONFIG_MX6S)
 #define CONFIG_DEFAULT_FDT_FILEimx6dl-wandboard.dtb
 #elif defined(CONFIG_MX6Q)
@@ -111,11 +107,14 @@
image=zImage\0 \
console=ttymxc0\0 \
splashpos=m,m\0 \
-   fdt_high=0x\0 \
-   initrd_high=0x\0 \
-   fdt_file= CONFIG_DEFAULT_FDT_FILE \0 \
-   fdt_addr=0x1800\0 \
+   fdtfile= CONFIG_DEFAULT_FDT_FILE \0 \
+   fdt_addr_r=0x1800\0 \
boot_fdt=try\0 \
+   pxefile_addr_r=0x17f0\0 \
+   scriptaddr=0x17e0\0 \
+   kernel_addr_r=0x1100\0 \
+   ramdisk_addr_r=0x1810\0 \
+   bootm_size=0x2000\0 \
ip_dyn=yes\0 \
mmcdev= __stringify(CONFIG_SYS_MMC_ENV_DEV) \0 \
mmcpart=1\0 \
@@ -134,70 +133,12 @@
mmc write ${loadaddr} 0x2 ${fw_sz};  \
fi;   \
fi\0 \
-   mmcargs=setenv bootargs console=${console},${baudrate}  \
-   root=${mmcroot}\0 \
-   loadbootscript= \
-   fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0 \
-   bootscript=echo Running bootscript from mmc ...;  \
-   source\0 \
-   loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}\0 \
-   loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0 \
-   mmcboot=echo Booting from mmc ...;  \
-   run mmcargs;  \
-   if test ${boot_fdt} = yes || test ${boot_fdt} = try; then  \
-   if run loadfdt; then  \
-   bootz ${loadaddr} - ${fdt_addr};  \
-   else  \
-   if test ${boot_fdt} = try; then  \
-   bootz;  \
-   else  \
-   echo WARN: Cannot load the DT;  \
-   fi;  \
-   fi;  \
-   else  \
-   bootz;  \
-   fi;\0 \
-   netargs=setenv bootargs console=${console},${baudrate}  \
-   root=/dev/nfs  \
-   ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0 \
-   netboot=echo Booting from net ...;  \
-   run netargs;  \
-   if test ${ip_dyn} = yes; then  \
-   setenv get_cmd dhcp;  \
-   else  \
-   setenv get_cmd tftp;  \
-   fi;  \
-   ${get_cmd} ${image};  \
-   if test ${boot_fdt} = yes || test ${boot_fdt} = try; then  \
-   if ${get_cmd} ${fdt_addr} ${fdt_file}; then  \
-   bootz ${loadaddr} - ${fdt_addr};  \
-   else  \
-   if test ${boot_fdt} = try; then  \
-   bootz;  \
-   else  \
-   echo WARN: Cannot load the DT;  \
-   fi;  \
-   fi;  \
-   else  \
-   bootz;  \
-   fi;\0
+   BOOTCMDS_COMMON
 
 #define CONFIG_BOOTCOMMAND \
-  mmc dev ${mmcdev}; if mmc rescan; then  \
-  if run loadbootscript; then  \
-  run bootscript;  \
-  else  \
-  if run loadimage; then  \
-  run mmcboot;  \
-  else run netboot;  \
-  fi

Re: [U-Boot] [PATCH v1 0/9] sunxi: initial upstreamining effort

[Dennis Gilmore]

On Fri, 14 Mar 2014 10:16:42 -0400
Tom Rini tr...@ti.com wrote:

 On Fri, Mar 14, 2014 at 10:33:32AM +, Ian Campbell wrote:
 
  Hi,
  
  This is my first cut at an upstreamable series based upon the
  https://github.com/linux-sunxi/u-boot-sunxi.git#sunxi tree. The
  intention is to present a minimal starting point for upstreaming to
  which support for other processors, peripherals, boards etc can be
  added in the future. Therefore this has been stripped right back and
  currently supports only sun7i processors and the cubietruck
  board. Supported peripherals are UART, MMC and Ethernet.
 
 Some global comments:
 - If you haven't already, make sure it's all checkpatch clean.
 - Use the SPDX tags rather than including the GPL boilerplate.
 - Please re-word the commit messages.  The how we got here / where
 this is from is fine for the cover letter.
 - Magic numbers need to be defined.

I have a quick request also, Please incorporate the ongoing generic
distro work as most if not all of the sunxi systems I know of are
targets for generic distros.

Dennis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] unable to build tools with 2014.04-rc2 for x86

[Dennis Gilmore]

Hi,

to date I have been doing a make tools on x86 builds without doing any
configuration to build mkimage for use on x86 hosts. with 2014.04-rc2
the build fails with

make tools
Makefile:485: *** System not configured - see README.  Stop.

As there is no x86 configs I can not select one, and if I choose
something random,  such as sheevaplug build fails with 

make  CROSS_COMPILE=  tools
  GEN include/autoconf.mk.dep
cc1: error: bad value (armv5te) for -march= switch
  GEN include/autoconf.mk
cc1: error: bad value (armv5te) for -march= switch
  CHK include/config/uboot.release
  UPD include/config/uboot.release
  CHK include/generated/version_autogenerated.h
  UPD include/generated/version_autogenerated.h
  CHK include/generated/timestamp_autogenerated.h
  UPD include/generated/timestamp_autogenerated.h
  HOSTCC  scripts/basic/fixdep
  CC  lib/asm-offsets.s
lib/asm-offsets.c:1:0: error: bad value (armv5te) for -march= switch
 /*
 ^
make[1]: *** [lib/asm-offsets.s] Error 1
make: *** [prepare0] Error 2


if i put a blank include/config.mk to make the System not configured
check happy, the build fails with 

make tools
  CHK include/config/uboot.release
  CHK include/generated/version_autogenerated.h
  CHK include/generated/timestamp_autogenerated.h
  UPD include/generated/timestamp_autogenerated.h
  Could not find linker script.
make: *** [prepare1] Error 1


So the question is how am I supposed to build mkimage for x86?

Dennis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] unable to build tools with 2014.04-rc2 for x86

[Dennis Gilmore]

On Thu, 13 Mar 2014 12:47:16 +0900
Masahiro Yamada yamad...@jp.panasonic.com wrote:

 Hello Dennis,
 
 
  So the question is how am I supposed to build mkimage for x86?
 
 
 I think
   make  CROSS_COMPILE=arm-linxu-gnu-  sheevaplug_config   tools
 will work for you.
 
 
 tools/  is built for host (x86) even if the target board is
 configured for ARM.

having to add a build dependency on a cross compiler seems really wrong.

Seems to me we should fix things so tools are buildable without such
requirements.

seems that when doing native builds detection does not work right either

+ make 'HOSTCC=gcc -O2 -g -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong 
--param=ssp-buffer-size=4 -grecord-gcc-switches  -march=armv7-a -mfpu=vfpv3-d16 
 -mfloat-abi=hard' -j4
make: arm-linux-gcc: Command not found
/bin/sh: arm-linux-gcc: command not found
dirname: missing operand
Try 'dirname --help' for more information.
  GEN include/autoconf.mk.dep
/bin/sh: arm-linux-gcc: command not found
  GEN include/autoconf.mk
/bin/sh: arm-linux-gcc: command not found
  CHK include/config/uboot.release
  CHK include/generated/timestamp_autogenerated.h
  UPD include/generated/timestamp_autogenerated.h
  UPD include/config/uboot.release
  HOSTCC  scripts/basic/fixdep
  CHK include/generated/version_autogenerated.h
/bin/sh: arm-linux-gcc: command not found
/bin/sh: arm-linux-ld.bfd: command not found
  UPD include/generated/version_autogenerated.h
  CC  lib/asm-offsets.s
/bin/sh: arm-linux-gcc: command not found

Dennis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Dennis Gilmore]

On Wed, 19 Feb 2014 10:40:15 -0700
Stephen Warren swar...@wwwdotorg.org wrote:

 On 02/17/2014 10:56 AM, Dennis Gilmore wrote:
  Signed-off-by: Dennis Gilmore den...@ausil.us
 
 Patch description?
I failed in my rush to get it out for feedback.
 
  diff --git a/include/config_distro_bootcmd.h
  b/include/config_distro_bootcmd.h
 
  +#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H
  +#define _CONFIG_CMD_DISTRO_BOOTCMD_H
  +
  +
 
 Is there a need for 2 blank lines there?
no, will clean it up
 
  +#define BOOTCMDS_COMMON \
  +   rootpart=1\0 \
 
 We should really stop hard-coding that. I meant to (but evidently
 never got around to) re-write the commands so that they could
 automatically determine which partition to use, based on the MBR
 bootable flag or GPT partition flags.
 
 Still, we can probably make that enhancement separately later.

I fully agree, we should be able to work it out later. I also renamed
it to bootpart since it is where we will boot from, which may or may
not be the root filesystem
 
  +#define BOOT_TARGETS_MMC mmc1 mmc0
 
 We really ought to make the order of multiple MMC devices in
 BOOT_TARGETS configurable. For example, we may have 2 boards that both
 want to boot from SD card if present, else fall back to internal eMMC,
 yet one has mmc0=eMMC,mmc1=SD, and the other mmc0=SD,mmc1=eMMC. On
 Tegra, we're just lucky that hasn't been an issue yet. Equally, not
 all boards have 2 eMMC devices.

I did wonder if that was better being left out here and something that
the board set.
 
  +   scan_boot=
  \
  +   echo Scanning ${devtype} ${devnum}...;
   \
  +   for prefix in ${boot_prefixes}; do
   \
  +   run sysboot_boot;
\
  +   run envimport;
   \
  +   run script_boot;
 \
 
 This isn't quite right for the Raspberry Pi at least.

 What I wanted was for uEnv.txt to *always* be loaded from SD card
 before any other boot activity. The SD card is known to exist on this
 platform, since it's the only place the SoC's boot ROM can load the
 initial binary firmware from.

I know some distros use commands in uEnv.txt to boot, or at the least
they set variables and load a boot.scr I was trying to make sure we
cover those people. The definition of what uEnv.txt is and how it
should be used is pretty murky to me. I have seen it used in a few
different ways. I know some people really want them. So probably best
to work out a better way to support it.
http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-uEnv.txtbasedbootscript
for instance specifies all the boot commands in uEnv.txt really I would
rather people just use a extlinux.conf file, I just do not want to take
away the option to use something people see as valuable.
 
 The idea is that since the Pi has nowhere to store any environment,
 and the default environment's boot_targets is hard-coded in the U-Boot
 binary, we need some way for the user to configure the value of
 boot_targets to e.g. force network or USB boot. We want to do this
 before executing bootcmd, so that bootcmd looks at the user's desired
 boot_targets, rather than part way through executing bootcmd, which is
 far too late.
 
 Now, on the Pi, this all happens via CONFIG_PREBOOT, so it will still
 work even with the run envimport as above. However, I think we want
 to make the run envimport within scan_boot optional, so it doesn't
 get repeated.
 
 I wouldn't be surprised if other platforms ought to be working in the
 exact same way?
 
  +   boot_targets= \
  +   BOOT_TARGETS_MMC\
  +   BOOT_TARGETS_USB\
  +   BOOT_TARGETS_SATA   \
  +   BOOT_TARGETS_PXE\
  +   BOOT_TARGETS_DHCP   \
  +   \0 \
 
 I'd be tempted to require the board-specific config to set
 boot_targets, so that appropriate customization can be applied?
sure, Ideally its something that can be changed on the fly and we just
ship a suggested ordering. That is probably something for down the road
though. 
 
  +   boot_envs=uEnv.txt\0 \
 
 I wonder if boards want to customize that for backwards-compatibility?
Perhaps.

Might need to redo some of this. I've since added SCSI and IDE and they
are things I have seen in the wild also. Maybe we can simplify things
somehow so that adding new hardware types is really simple.


Dennis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot