Re: [u-boot-test-hooks PATCH 1/7] travis-ci: Add qemu_arm_spl board

2021-11-03 Thread Tuomas Tynkkynen

Hi,

On 30.10.2021 21.25, Simon Glass wrote:

From: Tuomas Tynkkynen 


^ Some mishap with the From: line here, since I did not write the patch?



This is similar to the existing qemu_arm target, except that the 'bios' is
image.bin (containing both SPL and U-Boot) rather than in u-boot.bin

Signed-off-by: Simon Glass 
---


Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option

2021-10-27 Thread Tuomas Tynkkynen

Hi,

On 27.10.2021 17.08, Simon Glass wrote:

Hi François,

On Tue, 26 Oct 2021 at 00:07, François Ozog  wrote:


Hi Simon

Position unchanged on this series: adding fake dts for boards that generate 
their device tree in the dts directory is not good. If you have them in 
documentation the it is acceptable.


I think we are going to have to disagree on this one. I actually used
the qemu one in testing/development recently. We have to have a way to
develop in-tree with U-Boot. It does not impinge on any of your use
cases, so far as I know.



How about having the file just contain a single line

#include 

... where this generated-*.dts is not checked to the source tree. Then 
of course comments on how to generate it via qemu -dumpdtb + dtc, with 
appropriate precautions (ie. must be regenerated if qemu command line is 
changed or qemu is upgraded), intended use case, and so forth.


Re: qemu_arm64_defconfig: PCI autoconfig fails for qemu-system-aarch64 -m 4G

2020-01-04 Thread Tuomas Tynkkynen
Hi Heinrich,

On Wed, 1 Jan 2020 at 19:58, Heinrich Schuchardt  wrote:
>
> Dear all,
>
> I want to run qemu_arm64_defconfig with 4G.
>
> qemu-system-aarch64 -machine virt -m 4G -smp cores=2 \
> -bios u-boot.bin -cpu cortex-a53 -nographic -gdb tcp::1234 \
> -netdev user,id=eth0,tftp=tftp -device e1000,netdev=eth0 \
> -device virtio-rng-pci

Out of curiosity, why E1000 over virtio-net?

> I see an error:
>
...
> pci_hose_phys_to_bus: invalid physical address
>
> The error does not occur for a smaller RAM size.
>
> I added some debug output:
>
> _dm_pci_phys_to_bus:
> phys_addr 0x00013ffecb40,
> res->phys_start 0x1000,
> res->bus_start 0x1000
>
> As qemu_arm64_defconfig does not define CONFIG_SYS_PCI_64BIT the
> calculated bus address is truncated.

Makes sense.

> If CONFIG_SYS_PCI_64BIT is defined for qemu_arm64_defconfig and the
> memory is less then 4 GiB an error
> PCI: Failed autoconfig bar 10
> occurs.

I believe this happens because the handling of the ranges DT property
handling (or it
could be in the PCI core itself, not sure) is a bit simplistic in U-Boot.

The ranges property in QEMU-generated dtb contains two PCI_REGION_MEM ranges,
one below 32-bit boundary and one above it. But decode_regions() in U-Boot only
supports one range of given type. When CONFIG_SYS_PCI_64BIT is unset,
only the region below 32-bit boundary is used, otherwise the one above 32-bits
is used. See commit 52ba907328ec069ff1cec6cbe659f1714c68ed33.

Thus with CONFIG_SYS_PCI_64BIT set any PCI devices which do not support 64-bit
mem BARs stop working. This should happen regardless of the RAM size, right?

> For 3GiB memory I observed the following values:
>
> _dm_pci_phys_to_bus:
> phys_addr 0xfffecbc0,
> res->phys_start 0x1000,
> res->bus_start 0x1000
>
> When I define type pci_addr_t as 64bit everything works correctly.
>
> Why does the number of bits in pci_addr_t depend on CONFIG_SYS_PCI_64BIT
> and not on the bitness of the system?

As I understand it, some PCI host controllers may require using 64-bit PCI bus
addresses but still be connected to a 32-bit CPU.

> It is especially worrisome that CONFIG_SYS_PCI_64BIT is not documented
> at all. I wonder if Kumar remembers why he introduced it in 2008.
>
> I tried to change the definition of the following types in pci.h
>
> typedef phys_addr_t pci_addr_t;
> typedef phys_addr_t pci_size_t;
>
> This lets qemu-x86_defconfig fail with
> Error binding driver 'cpu_qemu': -12
>
> Using
>
> typedef unsigned long pci_addr_t;
> typedef unsigned long pci_size_t;
>
> does not produce the error but I am not sure if this is the right approach.
>

One solution would be to fix decode_regions() to work with multiple regions
of the same type and then enable CONFIG_SYS_PCI_64BIT.

I think another solution would be to simply limit U-Boot from being
relocated above
the 32-bit boundary. IIRC some other 64-bit boards do this as well. In
fact, this
might be the better solution because some bus mastering PCI devices cannot
access memory above 32-bit. As far as I can tell, E1000 is not affected but
for example EHCI is.


Re: [PATCH v3 2/3] efi: qemu: arm64: Add efi_rng_protocol implementation for the platform

2019-12-28 Thread Tuomas Tynkkynen
Hi,

On Sat, 28 Dec 2019 at 17:19, Heinrich Schuchardt  wrote:
>
> On 12/28/19 4:03 PM, Sughosh Ganu wrote:
> >
> > On Sat, 28 Dec 2019 at 20:01, Heinrich Schuchardt  > > wrote:
> >
> > On 12/27/19 3:26 PM, Sughosh Ganu wrote:
> >  > Add support for the EFI_RNG_PROTOCOL routines for the qemu arm64
> >  > platform. EFI_RNG_PROTOCOL is an uefi boottime service which is
> >  > invoked by the efi stub in the kernel for getting random seed for
> >  > kaslr.
> >  >
> >  > The routines are platform specific, and use the virtio-rng device on
> >  > the platform to get random data.
> >  >
> >  > The feature can be enabled through the following config
> >  > CONFIG_EFI_RNG_PROTOCOL
> >  >
> >  > Signed-off-by: Sughosh Ganu  > >
...
>
> Adding the uclass_get_device() solution in a weak function is ok for me.
>
> When testing I already experienced that I had to issue the `virtio scan`
> command.
>

But in board_init() in qemu-arm.c we already call virtio_init(). If that is not
working correctly, there is a bug that should be fixed instead.

Maybe the problem is that PCI bus has not been scanned at the time of
that virtio_init() call (so everything would work correctly with virtio-mmio
but virtio-pci is broken)?


Re: [U-Boot] [PATCH] qemu-arm: Add persistent environment support

2018-12-12 Thread Tuomas Tynkkynen
Hi Sumit, Takahiro,

On Wed, 12 Dec 2018 10:42:56 +0900
Takahiro Akashi  wrote:

> On Tue, Dec 11, 2018 at 06:04:05PM +0530, Sumit Garg wrote:
> > On Mon, 26 Nov 2018 at 16:51, Sumit Garg 
> > wrote:  
> > >
> > > Currently on qemu-arm platforms environment is kept in RAM.
> > > Instead use pflash device 1 to provide persistent environment
> > > support across device reset.
> > >
> > > Also (optionally) provide support for persistent environment
> > > across qemu machine OFF/ON using following instructions:
> > >
> > > - Create envstore.img using qemu-img:
> > > qemu-img create -f raw envstore.img 64M
> > > - Add a pflash drive parameter to the command line:
> > > -drive if=pflash,format=raw,index=1,file=envstore.img
> > >
> > > Signed-off-by: Sumit Garg 
> > > ---
> > >  configs/qemu_arm64_defconfig | 7 +++
> > >  configs/qemu_arm_defconfig   | 7 +++
> > >  doc/README.qemu-arm  | 6 ++
> > >  include/configs/qemu-arm.h   | 8 +++-
> > >  4 files changed, 27 insertions(+), 1 deletion(-)
> > >  
> > 
> > Gentle reminder. Please let me know if you have any further
> > comments.  

I'm not too familiar with the UEFI/ATF related aspects here, but I
think that the read-only parts (aka u-boot.bin) and read-write parts
(the U-Boot environment) should belong to different files (which is
what this patch series does). Basically, IMO as a normal user I should
be able to run QEMU on a distro-provided U-Boot binary with something
like:

qemu-system-arm -bios /usr/share/u-boot/qemu_arm.bin

and not have it fail due to not having write permission to /usr/.

> Another use case is atf + u-boot (although I don't know people are
> interested in it). Put bl1.bin in flash0(0x0-0x400) and put
> fip.bin in flash1(0x400-0x800). Please note that, with
> secure=on, flash0 is in secure and flash1 is in non-secure.
> While I admit that your patch is workable, my point is that there are
> different use cases and it may not be a good idea to put one
> configuration in qemu-arm.h.

Can EDK2 in QEMU boot with ATF and if so, how does it lay out things?
Would it be possible to build U-Boot in such a way that u-boot.bin
could be substituted in existing build scripts or instructions in place
of the EDK2 binary so that things still work the same?

Or in other words, if EDK2 has already has a working
implementation of something (such as the flash layout), IMO we should
prefer to use that instead of reimplementing it in a different
way.

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


Re: [U-Boot] [PATCH] qemu-arm: Enable VirtIO distro target

2018-11-12 Thread Tuomas Tynkkynen
Hi Sumit,

On Mon, 12 Nov 2018 15:29:08 +0530
Sumit Garg  wrote:

> With -device virtio-blk-device,drive=hd0, it could detect distro boot
> target.
> 
> Signed-off-by: Sumit Garg 
> ---
...
> diff --git a/include/configs/qemu-arm.h b/include/configs/qemu-arm.h
> index fedc466..437c3ae 100644
> --- a/include/configs/qemu-arm.h
> +++ b/include/configs/qemu-arm.h
> @@ -25,7 +25,8 @@
>  
>  #define BOOT_TARGET_DEVICES(func) \
>   func(SCSI, scsi, 0) \
> - func(DHCP, dhcp, na)
> + func(DHCP, dhcp, na) \
> + func(VIRTIO, virtio, 0)
>  
>  #include 
>  

I think typically DHCP is the very last boot option since it can take
quite long to notice if there's no DHCP server on the network and fall
back to the next option. So perhaps an order of

SCSI; VIRTIO; DHCP

would be better.

Other than that, looks fine to me.

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


Re: [U-Boot] [PATCH v2 3/3] ARM: qemu-arm: define fdt_addr_r

2018-10-24 Thread Tuomas Tynkkynen
Hi Takahiro,

On Mon, 22 Oct 2018 13:40:07 +0900
AKASHI Takahiro  wrote:

> This variable, fdt_addr_t, is missing in the current qemu-arm.h while
> it seems to be mandatory, at least, to run distro_bootcmd as expected.
> So just add its definition. A size of 1MB would be enough.
> 
> Signed-off-by: AKASHI Takahiro 
> ---
>  include/configs/qemu-arm.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/configs/qemu-arm.h b/include/configs/qemu-arm.h
> index 91fb8d47edf8..0e66f946dde5 100644
> --- a/include/configs/qemu-arm.h
> +++ b/include/configs/qemu-arm.h
> @@ -55,6 +55,7 @@
>   "fdt_high=0x\0" \
>   "initrd_high=0x\0" \
>   "fdt_addr=0x4000\0" \
> + "fdt_addr_r=0x4010\0" \
>   "scriptaddr=0x4020\0" \
>   "pxefile_addr_r=0x4030\0" \
>   "kernel_addr_r=0x4040\0" \

The same problem as in the previous version still exists; applying
these as-is would regress any boot entries in PXE files that use the
FDTDIR directive since it'd try to load a non-existent .dtb and fail.

We need some way to avoid that; maybe some magic value
(e.g. fdtfile=none) or a separate environment variable or CONFIG_
option.

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


Re: [U-Boot] [PATCH 2/2] ARM: qemu-arm: define fdt_addr_r

2018-10-24 Thread Tuomas Tynkkynen
On Thu, 18 Oct 2018 09:25:04 +0200
Alexander Graf  wrote:

> On 18.10.18 00:25, Tuomas Tynkkynen wrote:
> > Hi Alexander,
> > 
> > On Tue, 16 Oct 2018 15:04:26 +0200
> > Alexander Graf  wrote:
> > 
> > ...  
> >>> 
> >>>> Glancing at cmd/pxe.c,
> >>>> there is a problem though, in that if ${fdt_addr_r} were defined,
> >>>> a PXE file using the FDTDIR directive would attempt loading a dtb
> >>>> file named "-qemu-arm.dtb" instead of falling back to using
> >>>> ${fdt_addr}. That bug would need to be fixed first before
> >>>> applying this patch.
> >>
> >> Well, and that load will fail and everyone's happy, no?   
> > 
> > No, because currently if DTB loading from the filesystem/tftp is
> > attempted and it fails, it aborts the boot. It doesn't matter if
> > it's via a 'FDT' or 'FDTDIR' directive. In the case of typical
> > hardware that's probably the desired behaviour.
> > 
> > I guess the qemu_arm + FDTDIR case can be fixed by not attempting
> > a .dtb load if the default fdtfile is not known due to $soc or
> > $board being unset. At least I doubt that some other board could be
> > relying on a filename containing literally "" :)  
> 
> Well - IIRC $soc and $board should also always be defined ;). So yet
> another thing to fix in the QEMU port.

As far as I know $soc is only used for computing the default $fdtfile,
but we explicitly don't want to compute one for qemu_arm.

> >   
> >> IMHO we should
> >> fall back to $fdtcontroladdr always  
> > 
> > FWIW, to me the idea of passing $fdtcontroladdr to the OS has always
> > filled me with dread. On top of the usual backwards- and
> > forwards-compatibility problems that happen when mixing and matching
> > kernels and DTBs from different releases, you now have to deal
> > with  
> 
> That's something that we seriously as a community need to get sorted
> out. We're pushing hard for it in the EBBR context. The fact that
> people are afraid of putting *hardware desciption* into their
> firmware is just mind boggling.

But until/if that is solved anyone trying to rely on $fdtcontroladdr
will get burned, or at least that's what the experience for sunxi
sounds like where stuff like adding new regulators to DT breaks  
old kernels that lack the regulator driver. (And where the proposed
solution to that was some hack that just uses fixed regulators instead,
throwing the hardware description aspect out the window).

And it doesn't look like an isolated situation, you'd have got equally
hosed e.g when RPi switched to using the sdhost IP in place of the
other MMC controller, or when Tegra landed USB3 driver support thus
switched the .dts to using the XUSB controllers over the USB2 ones.

> > issues like U-Boot specific .dts that are majorly diverged from
> > Linux ones, or where the .dts is otherwise from Linux but the
> > U-Boot specific  
> 
> These case should really be the minority. And if you see those, please
> fix them.

Well, for the case of Tegra124, being able to use a recent
unmodified .dts from Linux for U-Boot would require writing an USB3
driver in order to not break USB functionality. That's not exactly a
simple fix.

> > additions break it for Linux, or where the .dts used is wrong for
> > the  
> 
> I've never seen a case where a U-Boot addition broke the DT for Linux.
> 

See e.g. 96a82d33f8c5bd3e90098b540349b7b9e43e27da fixing such instances.

> > specific hardware revision but close enough for U-Boot's purposes,
> > and so on...  
> 
> Again, something that just needs fixing. Device trees belong to the
> entity that knows hardware, not to the OS. Otherwise you lose the
> abstraction layer that DT gives you and you lose the ability to run
> "generic" kernels. And of course you break the ecosystem, because now
> good luck running BSD, your own little toy OS, etc ;)
> 

It's been possible to make generic images using the U-Boot distro stuff
(where U-Boot knows just the .dtb filename to load from the ones
installed by kernel's `make dtbs_install`) for over three years now.

Sure it doesn't fulfill the "DT doesn't belong to the OS" goal... but
given that features (incl. DT bindings) get developed in vendor kernels
first but upstream won't typically accept then unchanged, having a
single .dtb that satisfies both has been a logical impossibility so far.

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


Re: [U-Boot] [PATCH 2/2] ARM: qemu-arm: define fdt_addr_r

2018-10-17 Thread Tuomas Tynkkynen
Hi Alexander,

On Tue, 16 Oct 2018 15:04:26 +0200
Alexander Graf  wrote:

...
> >   
> >> Glancing at cmd/pxe.c,
> >> there is a problem though, in that if ${fdt_addr_r} were defined,
> >> a PXE file using the FDTDIR directive would attempt loading a dtb
> >> file named "-qemu-arm.dtb" instead of falling back to using
> >> ${fdt_addr}. That bug would need to be fixed first before applying
> >> this patch.  
> 
> Well, and that load will fail and everyone's happy, no? 

No, because currently if DTB loading from the filesystem/tftp is
attempted and it fails, it aborts the boot. It doesn't matter if it's
via a 'FDT' or 'FDTDIR' directive. In the case of typical hardware
that's probably the desired behaviour.

I guess the qemu_arm + FDTDIR case can be fixed by not attempting
a .dtb load if the default fdtfile is not known due to $soc or $board
being unset. At least I doubt that some other board could be relying
on a filename containing literally "" :)

> IMHO we should
> fall back to $fdtcontroladdr always

FWIW, to me the idea of passing $fdtcontroladdr to the OS has always
filled me with dread. On top of the usual backwards- and
forwards-compatibility problems that happen when mixing and matching
kernels and DTBs from different releases, you now have to deal with
issues like U-Boot specific .dts that are majorly diverged from Linux
ones, or where the .dts is otherwise from Linux but the U-Boot specific
additions break it for Linux, or where the .dts used is wrong for the
specific hardware revision but close enough for U-Boot's purposes,
and so on...

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


Re: [U-Boot] [PATCH 2/2] ARM: qemu-arm: define fdt_addr_r

2018-10-14 Thread Tuomas Tynkkynen
Hi Takahiro,

On Fri, 12 Oct 2018 14:07:57 +0900
AKASHI Takahiro  wrote:

> This variable, fdt_addr_t, is missing in the current qemu-arm.h while
> it seems to be mandatory, at least, to run distro_bootcmd as expected.
> So just add its definition. A size of 1MB would be enough.
> 

In what way is this required for distro_bootcmd to work? At least in the
past I've tested qemu_arm64_defconfig and EFI boot with the Fedora
netinst image and it has worked fine in stock U-Boot.

Note that these '-machine virt' based targets are slightly different
from real hardware in the sense that instead of loading a .dtb file
provided by the OS, the device tree is provided by QEMU. In the hunk
below you can see "fdt_addr=0x4000\0" providing the address of
the QEMU-provided device tree which the distro scripts should be
using.

I guess in principle having ${fdt_addr_r} set as well shouldn't hurt and
might be used for testing/unusual purposes. Glancing at cmd/pxe.c,
there is a problem though, in that if ${fdt_addr_r} were defined, a PXE
file using the FDTDIR directive would attempt loading a dtb file named
"-qemu-arm.dtb" instead of falling back to using ${fdt_addr}.
That bug would need to be fixed first before applying this patch.

> Signed-off-by: AKASHI Takahiro 
> ---
>  include/configs/qemu-arm.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/configs/qemu-arm.h b/include/configs/qemu-arm.h
> index 91fb8d47edf8..0e66f946dde5 100644
> --- a/include/configs/qemu-arm.h
> +++ b/include/configs/qemu-arm.h
> @@ -55,6 +55,7 @@
>   "fdt_high=0x\0" \
>   "initrd_high=0x\0" \
>   "fdt_addr=0x4000\0" \
> + "fdt_addr_r=0x4010\0" \
>   "scriptaddr=0x4020\0" \
>   "pxefile_addr_r=0x4030\0" \
>   "kernel_addr_r=0x4040\0" \

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


Re: [U-Boot] [PATCH 1/3] efi_loader: support USB boot in distro boot script

2018-10-13 Thread Tuomas Tynkkynen
Hi Takahiro,

On Fri, 12 Oct 2018 14:09:07 +0900
AKASHI Takahiro  wrote:

> With this patch, a removable USB mass storage device attached to the
> system will also be scanned to find and boot an EFI binary (that is
> BOOTEFI_NAME, see config_distro_bootcmd.h).
> 
> Signed-off-by: AKASHI Takahiro 
> ---
>  include/config_distro_bootcmd.h | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/include/config_distro_bootcmd.h
> b/include/config_distro_bootcmd.h index 76e12b7bf4ee..dd47e27d6835
> 100644 --- a/include/config_distro_bootcmd.h
> +++ b/include/config_distro_bootcmd.h
> @@ -26,7 +26,12 @@
>   */
>  
>  #define BOOTENV_SHARED_BLKDEV_BODY(devtypel) \
> - "if " #devtypel " dev ${devnum}; then " \
> + "if test " #devtypel " = usb ; then " \
> + "if " #devtypel " info ${devnum}; then " \
> + "setenv devtype " #devtypel "; " \
> + "run scan_dev_for_boot_part; " \
> + "fi;" \
> + "elif " #devtypel " dev ${devnum}; then " \
>   "setenv devtype " #devtypel "; " \
>   "run scan_dev_for_boot_part; " \
>   "fi\0"

I can't see how this patch is needed - "usb dev" is a valid command
(via do_usb() -> blk_common_cmd()) as long as CONFIG_USB_STORAGE is set.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 00/27] virtio: Introduce VirtIO driver support

2018-09-27 Thread Tuomas Tynkkynen

Hi Simon,

On 09/27/2018 04:43 PM, Simon Glass wrote:
...


How does this all get tested? Could we have a simple sandbox driver?



We can switch the Travis-CI jobs for the QEMU boards to use virtio-net
instead of the current network cards for the TFTP tests. I don't know
if there are pytest equivalents for block devices.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 18/27] riscv: qemu: Include some useful commands

2018-09-27 Thread Tuomas Tynkkynen

Hi Bin,

On 09/23/2018 04:42 PM, Bin Meng wrote:

With the virtio net and blk drivers, we can do more stuff with some
useful commands. Imply those in the board Kconfig.

Signed-off-by: Bin Meng 
---

  board/emulation/qemu-riscv/Kconfig | 8 
  1 file changed, 8 insertions(+)

diff --git a/board/emulation/qemu-riscv/Kconfig 
b/board/emulation/qemu-riscv/Kconfig
index 5ae56da..37a80db 100644
--- a/board/emulation/qemu-riscv/Kconfig
+++ b/board/emulation/qemu-riscv/Kconfig
@@ -21,5 +21,13 @@ config BOARD_SPECIFIC_OPTIONS # dummy
imply VIRTIO_MMIO
imply VIRTIO_NET
imply VIRTIO_BLK
+   imply CMD_PING
+   imply CMD_FS_GENERIC
+   imply DOS_PARTITION
+   imply EFI_PARTITION
+   imply ISO_PARTITION
+   imply CMD_EXT2
+   imply CMD_EXT4
+   imply CMD_FAT
  
  endif




How about using DISTRO_DEFAULTS?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 16/27] arm: qemu: Enumerate virtio bus during early boot

2018-09-27 Thread Tuomas Tynkkynen

Hi Bin,

On 09/23/2018 04:42 PM, Bin Meng wrote:

Currently devices on the virtio bus is not automatically enumerated,
which means peripherals on the virtio bus are not discovered by their
drivers. This uses board_init() to do the virtio enumeration.

Signed-off-by: Bin Meng 
---

  board/emulation/qemu-arm/Kconfig| 3 +++
  board/emulation/qemu-arm/qemu-arm.c | 7 +++
  2 files changed, 10 insertions(+)


...

diff --git a/board/emulation/qemu-arm/Kconfig b/board/emulation/qemu-arm/Kconfig
index d1c08c2..16b80fe 100644
--- a/board/emulation/qemu-arm/Kconfig
+++ b/board/emulation/qemu-arm/Kconfig
@@ -5,5 +5,8 @@ config SYS_TEXT_BASE

config BOARD_SPECIFIC_OPTIONS # dummy
def_bool y
+   imply VIRTIO_MMIO
+   imply VIRTIO_NET
+   imply VIRTIO_BLK


I think we should have VIRTIO_PCI here as well, so that QEMU command lines
that work on x86 will work on ARM just as well.

...

--- a/board/emulation/qemu-arm/qemu-arm.c
+++ b/board/emulation/qemu-arm/qemu-arm.c
@@ -4,6 +4,7 @@
   */
  #include 
  #include 
+#include 
  
  #ifdef CONFIG_ARM64

  #include 
@@ -58,6 +59,12 @@ struct mm_region *mem_map = qemu_arm64_mem_map;
  
  int board_init(void)

  {
+   /*
+* Make sure virtio bus is enumerated so that peripherals
+* on the virtio bus can be discovered by their drivers
+*/
+   virtio_init();
+
return 0;
  }
  



Note that in include/configs/qemu-arm.h, the boards auto-enumerate
PCI devices with a different mechanism, like this:

#define CONFIG_PREBOOT "pci enum"

I am not sure which one is better but at least we should be consistent.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 13/27] virtio: Add block driver support

2018-09-27 Thread Tuomas Tynkkynen

Hi Simon,

On 09/27/2018 04:42 PM, Simon Glass wrote:

On 23 September 2018 at 06:42, Bin Meng  wrote:

From: Tuomas Tynkkynen 

This adds virtio block device driver support.

Signed-off-by: Tuomas Tynkkynen 
Signed-off-by: Bin Meng 
---

...


Why does this use __u32 instead of u32?



The header comes from include/uapi from Linux where the underscored
forms are the convention/rule.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 05/27] virtio: Add net driver support

2018-09-27 Thread Tuomas Tynkkynen

Hi Bin,

On 09/23/2018 04:42 PM, Bin Meng wrote:

From: Tuomas Tynkkynen 

This adds virtio net device driver support.

Signed-off-by: Tuomas Tynkkynen 
Signed-off-by: Bin Meng 
---

...

+static u32 feature[] = {
+   VIRTIO_NET_F_MAC
+};
+
+static u32 feature_legacy[] = {
+   VIRTIO_NET_F_MAC
+};


These can be const.

...

+
+static void virtio_net_stop(struct udevice *dev)
+{
+   /*
+* There is no way to stop the queue from running, unless we issue
+* a reset to the virtio device, and re-do the queue initialization
+* from the beginning.
+*/
+}


Unless I missed it, we still need to do something when we pass control to
Linux so that the memory used for receive buffers doesn't get overwritten
by the virtio device during Linux boot.

I think this can be done by calling virtio_reset() on the device in some
uclass-level hook, maybe .child_post_remove().
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 03/27] virtio: Add codes for virtual queue/ring management

2018-09-27 Thread Tuomas Tynkkynen

Hi Bin,

On 09/23/2018 04:42 PM, Bin Meng wrote:

From: Tuomas Tynkkynen 

This adds support for managing virtual queue/ring, the channel
for high performance I/O between host and guest.

Signed-off-by: Tuomas Tynkkynen 
Signed-off-by: Bin Meng 
---

...


+
+/*
+ * Barriers in virtio are tricky. Since we are not in a hyperviosr/guest
+ * scenario, having these as nops is enough to work as expected.
+ */
+
+static inline void virtio_mb(void)
+{
+}
+
+static inline void virtio_rmb(void)
+{
+}
+
+static inline void virtio_wmb(void)
+{
+}
+
+static inline void virtio_store_mb(__virtio16 *p, __virtio16 v)
+{
+   WRITE_ONCE(*p, v);
+}
+
+#endif /* _LINUX_VIRTIO_RING_H */


I am not convinced it's safe to leave these barriers empty. For instance
if KVM acceleration is used, I believe U-Boot could be running on one
core concurrently with QEMU's IO thread running on a different core.
Thus we need memory barriers on both sides so that updates to the
vring are observed in the correct order.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 02/27] dm: Add a new uclass driver for VirtIO transport devices

2018-09-27 Thread Tuomas Tynkkynen

Hi Bin,

Thanks for the patches, they look great. Some minor comments:

On 09/23/2018 04:42 PM, Bin Meng wrote:

This adds a new virtio uclass driver for “virtio” [1] family of
devices that are are found in virtual environments like QEMU,
yet by design they look like physical devices to the guest.

The uclass driver provides child_pre_probe() and child_post_probe()
methods to do some common operations for virtio device drivers like
device and driver supported feature negotiation, etc.

[1] http://docs.oasis-open.org/virtio/virtio/v1.0/virtio-v1.0.pdf

Signed-off-by: Tuomas Tynkkynen 
Signed-off-by: Bin Meng 
---...
+
+config VIRTIO
+   bool
+   help
+ This option is selected by any driver which implements the virtio
+ bus, such as CONFIG_VIRTIO_MMIO or CONFIG_VIRTIO_PCI.


I think most other places use the term 'transport' over 'bus'.


+
+int virtio_get_config(struct udevice *vdev, unsigned int offset,
+ void *buf, unsigned int len)
+{
+   struct dm_virtio_ops *ops;
+
+   ops = virtio_get_ops(vdev->parent);
+   if (!ops->get_config)
+   return -ENOSYS;


I'm not sure how useful the -ENOSYS fallbacks for most of these ops
are. E.g. a transport lacking .find_vqs() cannot ever be useful
for implementing real-world devices.

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


Re: [U-Boot] [PATCH 2/4] ata: ahci: Don't cap AHCI port count under CONFIG_DM_SCSI

2018-09-14 Thread Tuomas Tynkkynen

Hi,

On 09/14/2018 01:55 PM, Simon Glass wrote:

On 13 September 2018 at 00:28, Tuomas Tynkkynen  wrote:

When using device model this sort of hardcoded limits aren't used or
necessary.

Signed-off-by: Tuomas Tynkkynen 
---
  drivers/ata/ahci.c | 2 ++
  1 file changed, 2 insertions(+)


Reviewed-by: Simon Glass 

But please see below


diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 333f0457f6..5fafb63aeb 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -230,8 +230,10 @@ static int ahci_host_init(struct ahci_uc_priv *uc_priv)
 debug("cap 0x%x  port_map 0x%x  n_ports %d\n",
   uc_priv->cap, uc_priv->port_map, uc_priv->n_ports);

+#if !defined(CONFIG_DM_SCSI)


Can you use this instead?

if (IS_DEFINED(CONFIG_DM_SCSI))




No, that won't work because after patch 3 CONFIG_SYS_SCSI_MAX_SCSI_ID
won't be defined for boards using CONFIG_DM_SCSI, so using the preprocessor
is necessary.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 3/4] ata: Drop CONFIG_SYS_SCSI_MAX_* from boards using DM_SCSI

2018-09-12 Thread Tuomas Tynkkynen
These options are not used or necessary when device model is being used
for SCSI. Just drop them.

Signed-off-by: Tuomas Tynkkynen 
---
 include/configs/dra7xx_evm.h| 4 
 include/configs/qemu-arm.h  | 3 ---
 include/configs/x86-common.h| 4 
 include/configs/xilinx_zynqmp.h | 7 ---
 4 files changed, 18 deletions(-)

diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
index fcaf3a1e13..d8d6d2f6b0 100644
--- a/include/configs/dra7xx_evm.h
+++ b/include/configs/dra7xx_evm.h
@@ -113,10 +113,6 @@
 
 /* SATA */
 #define CONFIG_SCSI_AHCI_PLAT
-#define CONFIG_SYS_SCSI_MAX_SCSI_ID1
-#define CONFIG_SYS_SCSI_MAX_LUN1
-#define CONFIG_SYS_SCSI_MAX_DEVICE (CONFIG_SYS_SCSI_MAX_SCSI_ID * \
-   CONFIG_SYS_SCSI_MAX_LUN)
 
 /* NAND support */
 #ifdef CONFIG_NAND
diff --git a/include/configs/qemu-arm.h b/include/configs/qemu-arm.h
index 66729b7d4f..5a12a32d39 100644
--- a/include/configs/qemu-arm.h
+++ b/include/configs/qemu-arm.h
@@ -20,9 +20,6 @@
 /* For timer, QEMU emulates an ARMv7/ARMv8 architected timer */
 #define CONFIG_SYS_HZ   1000
 
-/* For block devices, QEMU emulates an ICH9 AHCI controller over PCI */
-#define CONFIG_SYS_SCSI_MAX_SCSI_ID 6
-
 /* QEMU emulates the ARM AMBA PL031 RTC */
 #define CONFIG_SYS_RTC_PL031_BASE  0x0901
 
diff --git a/include/configs/x86-common.h b/include/configs/x86-common.h
index f0b027e69c..ab345326e8 100644
--- a/include/configs/x86-common.h
+++ b/include/configs/x86-common.h
@@ -28,10 +28,6 @@
 #define CONFIG_LBA48
 #define CONFIG_SYS_64BIT_LBA
 
-#define CONFIG_SYS_SCSI_MAX_SCSI_ID2
-#define CONFIG_SYS_SCSI_MAX_LUN1
-#define CONFIG_SYS_SCSI_MAX_DEVICE (CONFIG_SYS_SCSI_MAX_SCSI_ID * \
-CONFIG_SYS_SCSI_MAX_LUN)
 #endif
 
 /* Generic TPM interfaced through LPC bus */
diff --git a/include/configs/xilinx_zynqmp.h b/include/configs/xilinx_zynqmp.h
index a65e8fedff..0ab32611ce 100644
--- a/include/configs/xilinx_zynqmp.h
+++ b/include/configs/xilinx_zynqmp.h
@@ -122,13 +122,6 @@
 # define CONFIG_SYS_EEPROM_SIZE(64 * 1024)
 #endif
 
-#ifdef CONFIG_SATA_CEVA
-#define CONFIG_SYS_SCSI_MAX_SCSI_ID2
-#define CONFIG_SYS_SCSI_MAX_LUN1
-#define CONFIG_SYS_SCSI_MAX_DEVICE (CONFIG_SYS_SCSI_MAX_SCSI_ID * \
-CONFIG_SYS_SCSI_MAX_LUN)
-#endif
-
 #define CONFIG_SYS_BOOTM_LEN   (60 * 1024 * 1024)
 
 #define CONFIG_CLOCKS
-- 
2.16.3

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


[U-Boot] [PATCH 4/4] configs: Drop CONFIG_SYS_SCSI_MAXDEVICE

2018-09-12 Thread Tuomas Tynkkynen
This option has never been used for anything. Drop it.

Signed-off-by: Tuomas Tynkkynen 
---
 include/configs/MPC8544DS.h   | 3 +--
 include/configs/MPC8572DS.h   | 1 -
 include/configs/MPC8610HPCD.h | 1 -
 include/configs/MPC8641HPCN.h | 1 -
 include/configs/sbc8641d.h| 1 -
 scripts/config_whitelist.txt  | 1 -
 6 files changed, 1 insertion(+), 7 deletions(-)

diff --git a/include/configs/MPC8544DS.h b/include/configs/MPC8544DS.h
index 2568e95270..d825f0fc33 100644
--- a/include/configs/MPC8544DS.h
+++ b/include/configs/MPC8544DS.h
@@ -280,8 +280,7 @@ extern unsigned long get_board_sys_clk(unsigned long dummy);
 #define CONFIG_SYS_SCSI_MAX_SCSI_ID4
 #define CONFIG_SYS_SCSI_MAX_LUN1
 #define CONFIG_SYS_SCSI_MAX_DEVICE (CONFIG_SYS_SCSI_MAX_SCSI_ID * 
CONFIG_SYS_SCSI_MAX_LUN)
-#define CONFIG_SYS_SCSI_MAXDEVICE  CONFIG_SYS_SCSI_MAX_DEVICE
-#endif /* SCSCI */
+#endif /* CONFIG_SCSI_AHCI */
 
 #endif /* CONFIG_PCI */
 
diff --git a/include/configs/MPC8572DS.h b/include/configs/MPC8572DS.h
index 8c92c3f832..dd081e8c12 100644
--- a/include/configs/MPC8572DS.h
+++ b/include/configs/MPC8572DS.h
@@ -464,7 +464,6 @@
 #define CONFIG_SYS_SCSI_MAX_SCSI_ID4
 #define CONFIG_SYS_SCSI_MAX_LUN1
 #define CONFIG_SYS_SCSI_MAX_DEVICE (CONFIG_SYS_SCSI_MAX_SCSI_ID * 
CONFIG_SYS_SCSI_MAX_LUN)
-#define CONFIG_SYS_SCSI_MAXDEVICE  CONFIG_SYS_SCSI_MAX_DEVICE
 #endif /* SCSI */
 
 #endif /* CONFIG_PCI */
diff --git a/include/configs/MPC8610HPCD.h b/include/configs/MPC8610HPCD.h
index cfb7135870..02fd864727 100644
--- a/include/configs/MPC8610HPCD.h
+++ b/include/configs/MPC8610HPCD.h
@@ -278,7 +278,6 @@
 #define CONFIG_SYS_SCSI_MAX_SCSI_ID4
 #define CONFIG_SYS_SCSI_MAX_LUN1
 #define CONFIG_SYS_SCSI_MAX_DEVICE (CONFIG_SYS_SCSI_MAX_SCSI_ID * 
CONFIG_SYS_SCSI_MAX_LUN)
-#define CONFIG_SYS_SCSI_MAXDEVICE  CONFIG_SYS_SCSI_MAX_DEVICE
 #endif
 
 #endif /* CONFIG_PCI */
diff --git a/include/configs/MPC8641HPCN.h b/include/configs/MPC8641HPCN.h
index 68bc710b02..bc69efbbe6 100644
--- a/include/configs/MPC8641HPCN.h
+++ b/include/configs/MPC8641HPCN.h
@@ -373,7 +373,6 @@ extern unsigned long get_board_sys_clk(unsigned long dummy);
 #define CONFIG_SYS_SCSI_MAX_SCSI_ID4
 #define CONFIG_SYS_SCSI_MAX_LUN1
 #define CONFIG_SYS_SCSI_MAX_DEVICE (CONFIG_SYS_SCSI_MAX_SCSI_ID * 
CONFIG_SYS_SCSI_MAX_LUN)
-#define CONFIG_SYS_SCSI_MAXDEVICE  CONFIG_SYS_SCSI_MAX_DEVICE
 #endif
 
 #endif /* CONFIG_PCI */
diff --git a/include/configs/sbc8641d.h b/include/configs/sbc8641d.h
index c509822814..d777e7a36a 100644
--- a/include/configs/sbc8641d.h
+++ b/include/configs/sbc8641d.h
@@ -298,7 +298,6 @@
 #define CONFIG_SYS_SCSI_MAX_SCSI_ID4
 #define CONFIG_SYS_SCSI_MAX_LUN1
 #define CONFIG_SYS_SCSI_MAX_DEVICE (CONFIG_SYS_SCSI_MAX_SCSI_ID * 
CONFIG_SYS_SCSI_MAX_LUN)
-#define CONFIG_SYS_SCSI_MAXDEVICE  CONFIG_SYS_SCSI_MAX_DEVICE
 #endif
 
 #endif /* CONFIG_PCI */
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index 30c79a643e..6a4a20ac3a 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -4101,7 +4101,6 @@ CONFIG_SYS_SCCR_USBDRCM
 CONFIG_SYS_SCCR_USBMPHCM
 CONFIG_SYS_SCR
 CONFIG_SYS_SCRATCH_VA
-CONFIG_SYS_SCSI_MAXDEVICE
 CONFIG_SYS_SCSI_MAX_DEVICE
 CONFIG_SYS_SCSI_MAX_LUN
 CONFIG_SYS_SCSI_MAX_SCSI_ID
-- 
2.16.3

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


[U-Boot] [PATCH 2/4] ata: ahci: Don't cap AHCI port count under CONFIG_DM_SCSI

2018-09-12 Thread Tuomas Tynkkynen
When using device model this sort of hardcoded limits aren't used or
necessary.

Signed-off-by: Tuomas Tynkkynen 
---
 drivers/ata/ahci.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 333f0457f6..5fafb63aeb 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -230,8 +230,10 @@ static int ahci_host_init(struct ahci_uc_priv *uc_priv)
debug("cap 0x%x  port_map 0x%x  n_ports %d\n",
  uc_priv->cap, uc_priv->port_map, uc_priv->n_ports);
 
+#if !defined(CONFIG_DM_SCSI)
if (uc_priv->n_ports > CONFIG_SYS_SCSI_MAX_SCSI_ID)
uc_priv->n_ports = CONFIG_SYS_SCSI_MAX_SCSI_ID;
+#endif
 
for (i = 0; i < uc_priv->n_ports; i++) {
if (!(port_map & (1 << i)))
-- 
2.16.3

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


[U-Boot] [PATCH 1/4] ata: ahci: Loop over the actual number of ports, not the maximum

2018-09-12 Thread Tuomas Tynkkynen
The loop in ahci_start_ports() is looping over the maximum number of
SCSI devices in the system, which can be larger than the amount of ports
a particular AHCI controller has. The extra looping isn't directly
harmful because the link_port_map bitmap won't have the bit set for a
nonexistent port, but it is wasteful. Replace the loop limit with the
port count of the AHCI controller instead.

Signed-off-by: Tuomas Tynkkynen 
---
 drivers/ata/ahci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index c35912bd33..333f0457f6 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -980,7 +980,7 @@ static int ahci_start_ports(struct ahci_uc_priv *uc_priv)
 
linkmap = uc_priv->link_port_map;
 
-   for (i = 0; i < CONFIG_SYS_SCSI_MAX_SCSI_ID; i++) {
+   for (i = 0; i < uc_priv->n_ports; i++) {
if (((linkmap >> i) & 0x01)) {
if (ahci_port_start(uc_priv, (u8) i)) {
printf("Can not start port %d\n", i);
-- 
2.16.3

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


Re: [U-Boot] [PATCH 12/12] riscv: Add QEMU virt board support

2018-09-09 Thread Tuomas Tynkkynen

On 09/08/2018 04:28 AM, Bin Meng wrote:

Hi Tuomas,

On Sat, Sep 8, 2018 at 7:14 AM Tuomas Tynkkynen  wrote:

[...]


You can find my branch here:

https://github.com/dezgeg/u-boot/tree/virtio

It should work under qemu_arm64_defconfig as follows:

qemu-system-aarch64 -machine virt -cpu cortex-a57 -m 512 \
   -bios u-boot.bin -s -nographic \
   -netdev user,id=net0 -device virtio-net-device,netdev=net0 \
   -drive if=none,file=disk.img,id=disk0 \
   -device virtio-blk-device,drive=disk0

I tried with Fedora-Server-netinst-aarch64-28-1.1.iso I had lying
around and letting it auto-boot worked fine.

Also interrupting the boot and doing 'virtio scan; dhcp' gets a
successful DHCP lease from QEMU's internal server.



Thank you for sharing your WIP. I just did a quick look and it seems
that you implemented the virtio uclass in a similar way like pci
uclass. My implementation is slightly different. I don't introduce
VIRTIO_GENERIC device and a complex driver matching logci like PCI. I


Yeah, VIRTIO_GENERIC ended up looking quite weird. It's not even used
normally, e.g. virtio-net doesn't end up using it at all:

=> dm tree
 Classindex  Probed  Driver  Name
-
 virtio  31  [ + ]   virtio_mmi  |-- virtio_mmio@a003e00
 eth  1  [ + ]   virtio_net  |   `-- virtio_net

It does get used for virtio-blk though:

 virtio  30  [ + ]   virtio_mmi  |-- virtio_mmio@a003c00
 virtio_gen   0  [ + ]   virtio_blk  |   `-- virtio_blk
 blk  0  [ + ]   virtblk |   `-- virtio_blk.blk

But that is only because I couldn't make the block device (i.e.
the one with UCLASS_BLK) without introducing some device in the
middle. All of the functions like blk_create_device() seem to be
designed for the use cases of say, an AHCI controller having
multiple SATA ports or an SCSI device having multiple LUNs.

I guess the right thing to do would be to split blk_create_device()
so that it would be possible to have a tree like this:

 virtio  30  [ + ]   virtio_mmi  |-- virtio_mmio@a003c00
 blk  0  [ + ]   virtio_blk  |   `-- virtio_blk

Then the need for UCLASS_VIRTIO_GENERIC would go away.


just did simple driver matching based on virtio device id. I wrote
some skeleton drivers to verify this can work with both virtio-mmio
and virtio-pci devices.


I took a brief look and these things still need work:

- Some of the virtio headers imported verbatim cause compiler
   warnings because we don't disable strict aliasing.

- Architectures need to import various definitions from Linux.
   At least PAGE_SIZE & PAGE_SHIFT and wmb() & rmb().
   (currently there are just gross hacks around this)

- Feature negotiation (needed for virtio-net to be able to
   set/get a MAC address) is not implemented yet.

- The virtio-pci transport is not implemented, only virtio-mmio.

- Error handling is missing in many places.

- Resource cleanup in some places, like virtio-net which needs to
   remove live buffers from the RX virtqueue on shutdown and I haven't
   looked into how to do that.

- Lots of small things like removing debug/commented out code, wrong
   kerneldoc comments, dead/uneeded code etc. to be cleaned up.

Have fun and let me know if you have questions.



Thanks for all these details! I will try integrating some of your WIP
with mine. I think I can directly use the virtio-blk and virtio-net
drivers from your tree as a start.

Regards,
Bin
___
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] [PATCH 12/12] riscv: Add QEMU virt board support

2018-09-07 Thread Tuomas Tynkkynen
Hi Bin,

On Fri, 7 Sep 2018 09:49:24 +0800
Bin Meng  wrote:

> Hi Tuomas,
> 
> On Fri, Sep 7, 2018 at 5:03 AM Tuomas Tynkkynen
>  wrote:
> >
> > Hi Bin,
> >
> > On 09/04/2018 12:31 PM, Bin Meng wrote:  
> > > Hi Lukas,
> > >
> > > On Tue, Sep 4, 2018 at 5:39 AM Auer, Lukas
> > >  wrote:  
> > >>
> > >> On Thu, 2018-08-30 at 00:54 -0700, Bin Meng wrote:  
> > >>> This adds QEMU RISC-V 'virt' board target support, with the
> > >>> hope of helping people easily test U-Boot on RISC-V.
> > >>>
> > >>> The QEMU virt machine models a generic RISC-V virtual machine
> > >>> with support for the VirtIO standard networking and block
> > >>> storage devices. It has CLINT, PLIC, 16550A UART devices in
> > >>> addition to VirtIO and it also uses device-tree to pass
> > >>> configuration information to guest software. It implements
> > >>> RISC-V privileged architecture spec v1.10.
> > >>>
> > >>> Both 32-bit and 64-bit builds are supported. Support is pretty
> > >>> much preliminary, only booting to U-Boot shell with the UART
> > >>> driver on a single core. Booting Linux is not supported yet.
> > >>>  
> > >>
> > >> For your information and to avoid duplicate work, I am working
> > >> on a patch set that improves RISC-V support in u-boot. I am
> > >> currently able to boot Linux on a multi-core setup in QEMU, but
> > >> they are not quite ready to submit yet.
> > >>  
> > >
> > > This is great! My next step is to work on virtio driver support in
> > > U-Boot as qemu-riscv virt machine has these devices but we don't
> > > have corresponding drivers in U-Boot.  
> > At some point I was working on porting the virtio stack from Linux
> > to U-Boot and IIRC got virtio-blk and virtio-net working on ARM.
> > But other things consumed my time and I never quite finished that
> > work. Let me know if you want to take a look.  
> 
> This is great. I just finished reading the virtio 1.0 spec and was
> about to start the work. My interest was to add virtio-blk and
> virtio-net driver to U-Boot too since they are most common devices
> (others are not used too much I believe). If you already have the
> drivers working, I can help to bring them upstream.

You can find my branch here:

https://github.com/dezgeg/u-boot/tree/virtio

It should work under qemu_arm64_defconfig as follows:

qemu-system-aarch64 -machine virt -cpu cortex-a57 -m 512 \
  -bios u-boot.bin -s -nographic \
  -netdev user,id=net0 -device virtio-net-device,netdev=net0 \
  -drive if=none,file=disk.img,id=disk0 \
  -device virtio-blk-device,drive=disk0

I tried with Fedora-Server-netinst-aarch64-28-1.1.iso I had lying
around and letting it auto-boot worked fine.

Also interrupting the boot and doing 'virtio scan; dhcp' gets a
successful DHCP lease from QEMU's internal server.

I took a brief look and these things still need work:

- Some of the virtio headers imported verbatim cause compiler
  warnings because we don't disable strict aliasing.

- Architectures need to import various definitions from Linux.
  At least PAGE_SIZE & PAGE_SHIFT and wmb() & rmb().
  (currently there are just gross hacks around this)

- Feature negotiation (needed for virtio-net to be able to
  set/get a MAC address) is not implemented yet.

- The virtio-pci transport is not implemented, only virtio-mmio.

- Error handling is missing in many places.

- Resource cleanup in some places, like virtio-net which needs to
  remove live buffers from the RX virtqueue on shutdown and I haven't
  looked into how to do that.

- Lots of small things like removing debug/commented out code, wrong
  kerneldoc comments, dead/uneeded code etc. to be cleaned up.

Have fun and let me know if you have questions.

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


[U-Boot] [PATCH] .travis.yml: Fix typo in sun7i job description

2018-09-07 Thread Tuomas Tynkkynen
'builman' -> 'buildman'

Signed-off-by: Tuomas Tynkkynen 
---
 .travis.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.travis.yml b/.travis.yml
index 95cfa5b6fc..ea3b20e063 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -189,7 +189,7 @@ matrix:
 - name: "buildman sun6i"
   env:
 - BUILDMAN="sun6i"
-- name: "builman sun7i"
+- name: "buildman sun7i"
   env:
 - BUILDMAN="sun7i"
 - name: "buildman sun8i"
-- 
2.16.3

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


Re: [U-Boot] [PATCH 12/12] riscv: Add QEMU virt board support

2018-09-06 Thread Tuomas Tynkkynen

Hi Bin,

On 09/04/2018 12:31 PM, Bin Meng wrote:

Hi Lukas,

On Tue, Sep 4, 2018 at 5:39 AM Auer, Lukas
 wrote:


On Thu, 2018-08-30 at 00:54 -0700, Bin Meng wrote:

This adds QEMU RISC-V 'virt' board target support, with the hope of
helping people easily test U-Boot on RISC-V.

The QEMU virt machine models a generic RISC-V virtual machine with
support for the VirtIO standard networking and block storage devices.
It has CLINT, PLIC, 16550A UART devices in addition to VirtIO and
it also uses device-tree to pass configuration information to guest
software. It implements RISC-V privileged architecture spec v1.10.

Both 32-bit and 64-bit builds are supported. Support is pretty much
preliminary, only booting to U-Boot shell with the UART driver on
a single core. Booting Linux is not supported yet.



For your information and to avoid duplicate work, I am working on a
patch set that improves RISC-V support in u-boot. I am currently able
to boot Linux on a multi-core setup in QEMU, but they are not quite
ready to submit yet.



This is great! My next step is to work on virtio driver support in
U-Boot as qemu-riscv virt machine has these devices but we don't have
corresponding drivers in U-Boot. 

At some point I was working on porting the virtio stack from Linux to
U-Boot and IIRC got virtio-blk and virtio-net working on ARM. But other
things consumed my time and I never quite finished that work. Let me
know if you want to take a look.

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


Re: [U-Boot] [PATCH] ARM: dts: logicpd-torpedo-37xx-devkit-u-boot: Fix MMC Card Detect

2018-09-05 Thread Tuomas Tynkkynen

Hi Adam,

On 09/03/2018 05:08 PM, Adam Ford wrote:

When re-syncing the DTS files from the kernel, something caused
the MMC driver to no longer detect the MMC card. Undoing the
CD-invert appears to fix the issue.

Fixes: e6ea2390cde3 ("ARM: DTS: Resync LogicPD-Torpedo-37xx-devkit
with Linux 4.18-RC4")



Looking at that commit, we see:

-   cd-gpios = < 31 IRQ_TYPE_LEVEL_LOW>;  /* gpio127 */
+   cd-gpios = < 31 GPIO_ACTIVE_LOW>; /* gpio127 */


IRQ_TYPE_LEVEL_LOW is defined as 8, which in this context should get
interpreted as GPIO_TRANSITORY which is ignored by U-Boot. Thus the
card-detect polarity got toggled by that commit.

If ACTIVE_LOW is indeed the correct polarity (and I'm guessing it
is because otherwise MMC wouldn't work in Linux), this patch sounds
correct.

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


Re: [U-Boot] [RFC 1/3] test/py: convert fs-test.sh to pytest

2018-09-04 Thread Tuomas Tynkkynen

Hi,

On 08/31/2018 10:22 AM, AKASHI Takahiro wrote:

Hi Tuomas,

Thank you for interesting pointers.

On Thu, Aug 30, 2018 at 01:56:41PM +0300, Tuomas Tynkkynen wrote:

Hi Heinrich, Takahiro

On 08/30/2018 01:26 PM, AKASHI Takahiro wrote:

On Thu, Aug 30, 2018 at 12:01:32PM +0200, Heinrich Schuchardt wrote:

On 08/30/2018 08:52 AM, AKASHI Takahiro wrote:

On Wed, Aug 29, 2018 at 11:36:51PM +0200, Heinrich Schuchardt wrote:

...

Using sudo for me is a NO-NO. I will not run any test that uses sudo.


So this means that you have never tested file system using test-fs.sh.

Since my script is logically "general", it can, if we want, run against
other file systems as well. "sudo mount" is the only solution for those cases.


There are two general non-root implementations that I know of:

1) http://libguestfs.org/ which IIRC launches a small Linux VM in QEMU
to do the filesystem accesses. I am not sure if the performance would be
acceptable without KVM (which I assume we don't have in Travis).


I didn't dig into this tool, but if it is all about VM on qemu,
the discussion here, whether we should be allowed to use sudo or not,
would be pointless as we can do whatever we want to do under VM.



But that's exactly what was wanted - that the user running the tests for U-Boot
doesn't need to have sudo access on their build machine.

BTW I briefly benchmarked this on a AWS free-tier machine (no KVM available),
and copying a 2G file onto an ext4 partition took:

- 33s natively (sudo mount -o loop fs.img /mnt; sudo cp bigfile /mnt/; sudo 
umount /mnt)
- 2m 44s with guestfs (guestfish add fs.img : run : mount /dev/sda / : copy-in 
bigfile /)

so a 80% slowdown for things like Travis CI but still not unbearably slow.
I'm assuming here that it will run much faster with KVM and that developers 
usually
have KVM-capable machines so this shouldn't affect developers too badly.



2) https://github.com/lkl/linux which is a port of Linux to run in userspace
as a library. It comes with tools like cptofs and lklfuse to access any
filesystem Linux has a driver for.


It appears to be a kind of libos or unikernel, or rather,
resembles a sandbox of u-boot?


Correct.




Sadly lkl isn't packaged in many distros.


Too bad.



Yes, I'd say libguestfs is the most promising solution so far.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] ARM: qemu-arm: Fix qemu_arm64_defconfig for QEMU 3.0

2018-09-04 Thread Tuomas Tynkkynen
QEMU 3.0 introduced additional memory-mapped regions for PCI-E ECAM and
MMIO. Thus we need to add them to our MMU map or U-Boot will crash with
a Synchronous Abort during PCI-E probing when it tries to access the
unmapped ECAM memory area.

Reported-by: Jonathan Gray 
Signed-off-by: Tuomas Tynkkynen 
---
 board/emulation/qemu-arm/qemu-arm.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/board/emulation/qemu-arm/qemu-arm.c 
b/board/emulation/qemu-arm/qemu-arm.c
index 1f5a33d520..812c90636d 100644
--- a/board/emulation/qemu-arm/qemu-arm.c
+++ b/board/emulation/qemu-arm/qemu-arm.c
@@ -17,7 +17,7 @@ static struct mm_region qemu_arm64_mem_map[] = {
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
 PTE_BLOCK_INNER_SHARE
}, {
-   /* Peripherals */
+   /* Lowmem peripherals */
.virt = 0x0800UL,
.phys = 0x0800UL,
.size = 0x3800,
@@ -31,6 +31,22 @@ static struct mm_region qemu_arm64_mem_map[] = {
.size = 255UL * SZ_1G,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
 PTE_BLOCK_INNER_SHARE
+   }, {
+   /* Highmem PCI-E ECAM memory area */
+   .virt = 0x401000ULL,
+   .phys = 0x401000ULL,
+   .size = 0x1000,
+   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+PTE_BLOCK_NON_SHARE |
+PTE_BLOCK_PXN | PTE_BLOCK_UXN
+   }, {
+   /* Highmem PCI-E MMIO memory area */
+   .virt = 0x80ULL,
+   .phys = 0x80ULL,
+   .size = 0x80ULL,
+   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+PTE_BLOCK_NON_SHARE |
+PTE_BLOCK_PXN | PTE_BLOCK_UXN
}, {
/* List terminator */
0,
-- 
2.16.3

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


Re: [U-Boot] [RFC 1/3] test/py: convert fs-test.sh to pytest

2018-08-30 Thread Tuomas Tynkkynen

Hi Heinrich, Takahiro

On 08/30/2018 01:26 PM, AKASHI Takahiro wrote:

On Thu, Aug 30, 2018 at 12:01:32PM +0200, Heinrich Schuchardt wrote:

On 08/30/2018 08:52 AM, AKASHI Takahiro wrote:

On Wed, Aug 29, 2018 at 11:36:51PM +0200, Heinrich Schuchardt wrote:

On 08/23/2018 09:25 AM, AKASHI Takahiro wrote:

In this commit, the same set of test cases as in test/fs/fs-test.sh
is provided using pytest framework.
Actually, fs-test.sh provides three variants:"sb" (sb command), "nonfs"
(fatxx and etc.) and "fs" (hostfs), and this patch currently supports
only "nonfs" variant; So it is not a replacement of fs-test.sh for now.

Simple usage:
   $ py.test test/py/tests/test_fs []

You may also specify filesystem types to be tested:
   $ py.test test/py/tests/test_fs --fs-type fat32 []

Signed-off-by: AKASHI Takahiro 
---
  test/py/tests/test_fs/conftest.py| 175 +++
  test/py/tests/test_fs/fstest_defs.py |  10 ++
  test/py/tests/test_fs/test_basic.py  | 246 +++
  3 files changed, 431 insertions(+)
  create mode 100644 test/py/tests/test_fs/conftest.py
  create mode 100644 test/py/tests/test_fs/fstest_defs.py
  create mode 100644 test/py/tests/test_fs/test_basic.py

diff --git a/test/py/tests/test_fs/conftest.py 
b/test/py/tests/test_fs/conftest.py
new file mode 100644
index ..fefeb4c9663f
--- /dev/null
+++ b/test/py/tests/test_fs/conftest.py
@@ -0,0 +1,175 @@
+# SPDX-License-Identifier:  GPL-2.0+
+# Copyright (c) 2018, Linaro Limited
+# Author: Takahiro Akashi 
+
+import pytest
+import re
+from subprocess import call, check_call, check_output, CalledProcessError
+from fstest_defs import *
+
+supported_fs_basic = ['fat16', 'fat32', 'ext4']
+
+#
+# Filesystem test specific setup
+#
+def pytest_addoption(parser):
+parser.addoption('--fs-type', action='append', default=None,
+help='Targeting Filesystem Types')
+
+def pytest_configure(config):
+global supported_fs_basic
+
+def intersect(listA, listB):
+return  [x for x in listA if x in listB]
+
+supported_fs = config.getoption('fs_type')
+if supported_fs:
+print("*** FS TYPE modified: %s" % supported_fs)
+supported_fs_basic =  intersect(supported_fs, supported_fs_basic)
+
+def pytest_generate_tests(metafunc):
+if 'fs_obj_basic' in metafunc.fixturenames:
+metafunc.parametrize('fs_obj_basic', supported_fs_basic,
+indirect=True, scope='module')
+
+#
+# Helper functions
+#
+def fstype_to_ubname(fs_type):
+if re.match('fat', fs_type):
+return 'fat'
+else:
+return fs_type
+
+def check_ubconfig(config, fs_type):
+if not config.buildconfig.get('config_cmd_%s' % fs_type, None):
+pytest.skip('.config feature "CMD_%s" not enabled' % fs_type.upper())
+if not config.buildconfig.get('config_%s_write' % fs_type, None):
+pytest.skip('.config feature "%s_WRITE" not enabled'
+% fs_type.upper())
+
+def mk_fs(config, fs_type, size, id):
+fs_img = '%s.%s.img' % (id, fs_type)
+fs_img = config.persistent_data_dir + '/' + fs_img
+
+if fs_type == 'fat16':
+mkfs_opt = '-F 16'
+elif fs_type == 'fat32':
+mkfs_opt = '-F 32'
+else:
+mkfs_opt = ''
+
+if re.match('fat', fs_type):
+fs_lnxtype = 'vfat'
+else:
+fs_lnxtype = fs_type
+
+count = (size + 1023) / 1024
+
+try:
+check_call('rm -f %s' % fs_img, shell=True)
+check_call('dd if=/dev/zero of=%s bs=1K count=%d'
+% (fs_img, count), shell=True)
+check_call('mkfs.%s %s %s'
+% (fs_lnxtype, mkfs_opt, fs_img), shell=True)
+return fs_img
+except CalledProcessError:
+call('rm -f %s' % fs_img, shell=True)
+raise
+
+#
+# Fixture for basic fs test
+# derived from test/fs/fs-test.sh
+#
+# NOTE: yield_fixture was deprecated since pytest-3.0
+@pytest.yield_fixture()
+def fs_obj_basic(request, u_boot_config):
+fs_type = request.param
+fs_img = ''
+
+fs_ubtype = fstype_to_ubname(fs_type)
+check_ubconfig(u_boot_config, fs_ubtype)
+
+mount_dir = u_boot_config.persistent_data_dir + '/mnt'
+small_file = mount_dir + '/' + SMALL_FILE
+big_file = mount_dir + '/' + BIG_FILE
+try:
+
+# 3GiB volume
+fs_img = mk_fs(u_boot_config, fs_type, 0xc000, '3GB')
+
+# Mount the image so we can populate it.
+check_call('mkdir -p %s' % mount_dir, shell=True)
+check_call('sudo mount -o loop,rw %s %s'
+% (fs_img, mount_dir), shell=True)


Should I grant sudo to anybody who can commit to U-Boot?


I don't get your point.
I think using "sudo" solely in testing should be allowed.


Just use exfat-fuse and fuse2fs.


It will not be a good idea to use those tools which are not
provided in every distribution.
I'd like to leave "sudo mount" statement as a backstop.


Fuse is a base functionality of Linux. On Travis we are using the Ubuntu
distribution which contains said 

[U-Boot] [PATCH] i2c: Drop CONFIG_SYS_I2C_MXS

2018-08-15 Thread Tuomas Tynkkynen
Last user of this driver went away in May 2017, in
commit eb5ba3aefdf0f6 ("i2c: Drop use of CONFIG_I2C_HARD")

Signed-off-by: Tuomas Tynkkynen 
---
 drivers/i2c/Makefile  |   1 -
 drivers/i2c/mxs_i2c.c | 319 --
 2 files changed, 320 deletions(-)
 delete mode 100644 drivers/i2c/mxs_i2c.c

diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index da368cc02a..f2cbe78c53 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -24,7 +24,6 @@ obj-$(CONFIG_SYS_I2C_LPC32XX) += lpc32xx_i2c.o
 obj-$(CONFIG_SYS_I2C_MESON) += meson_i2c.o
 obj-$(CONFIG_SYS_I2C_MVTWSI) += mvtwsi.o
 obj-$(CONFIG_SYS_I2C_MXC) += mxc_i2c.o
-obj-$(CONFIG_SYS_I2C_MXS) += mxs_i2c.o
 obj-$(CONFIG_SYS_I2C_OMAP24XX) += omap24xx_i2c.o
 obj-$(CONFIG_SYS_I2C_RCAR_I2C) += rcar_i2c.o
 obj-$(CONFIG_SYS_I2C_RCAR_IIC) += rcar_iic.o
diff --git a/drivers/i2c/mxs_i2c.c b/drivers/i2c/mxs_i2c.c
deleted file mode 100644
index 6766d37547..00
--- a/drivers/i2c/mxs_i2c.c
+++ /dev/null
@@ -1,319 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Freescale i.MX28 I2C Driver
- *
- * Copyright (C) 2011 Marek Vasut 
- * on behalf of DENX Software Engineering GmbH
- *
- * Partly based on Linux kernel i2c-mxs.c driver:
- * Copyright (C) 2011 Wolfram Sang, Pengutronix e.K.
- *
- * Which was based on a (non-working) driver which was:
- * Copyright (C) 2009-2010 Freescale Semiconductor, Inc. All Rights Reserved.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#defineMXS_I2C_MAX_TIMEOUT 100
-
-static struct mxs_i2c_regs *mxs_i2c_get_base(struct i2c_adapter *adap)
-{
-   if (adap->hwadapnr == 0)
-   return (struct mxs_i2c_regs *)MXS_I2C0_BASE;
-   else
-   return (struct mxs_i2c_regs *)MXS_I2C1_BASE;
-}
-
-static unsigned int mxs_i2c_get_bus_speed(struct i2c_adapter *adap)
-{
-   struct mxs_i2c_regs *i2c_regs = mxs_i2c_get_base(adap);
-   uint32_t clk = mxc_get_clock(MXC_XTAL_CLK);
-   uint32_t timing0;
-
-   timing0 = readl(_regs->hw_i2c_timing0);
-   /*
-* This is a reverse version of the algorithm presented in
-* i2c_set_bus_speed(). Please refer there for details.
-*/
-   return clk / timing0 >> 16) - 3) * 2) + 38);
-}
-
-static uint mxs_i2c_set_bus_speed(struct i2c_adapter *adap, uint speed)
-{
-   struct mxs_i2c_regs *i2c_regs = mxs_i2c_get_base(adap);
-   /*
-* The timing derivation algorithm. There is no documentation for this
-* algorithm available, it was derived by using the scope and fiddling
-* with constants until the result observed on the scope was good enough
-* for 20kHz, 50kHz, 100kHz, 200kHz, 300kHz and 400kHz. It should be
-* possible to assume the algorithm works for other frequencies as well.
-*
-* Note it was necessary to cap the frequency on both ends as it's not
-* possible to configure completely arbitrary frequency for the I2C bus
-* clock.
-*/
-   uint32_t clk = mxc_get_clock(MXC_XTAL_CLK);
-   uint32_t base = ((clk / speed) - 38) / 2;
-   uint16_t high_count = base + 3;
-   uint16_t low_count = base - 3;
-   uint16_t rcv_count = (high_count * 3) / 4;
-   uint16_t xmit_count = low_count / 4;
-
-   if (speed > 54) {
-   printf("MXS I2C: Speed too high (%d Hz)\n", speed);
-   return -EINVAL;
-   }
-
-   if (speed < 12000) {
-   printf("MXS I2C: Speed too low (%d Hz)\n", speed);
-   return -EINVAL;
-   }
-
-   writel((high_count << 16) | rcv_count, _regs->hw_i2c_timing0);
-   writel((low_count << 16) | xmit_count, _regs->hw_i2c_timing1);
-
-   writel((0x0030 << I2C_TIMING2_BUS_FREE_OFFSET) |
-   (0x0030 << I2C_TIMING2_LEADIN_COUNT_OFFSET),
-   _regs->hw_i2c_timing2);
-
-   return 0;
-}
-
-static void mxs_i2c_reset(struct i2c_adapter *adap)
-{
-   struct mxs_i2c_regs *i2c_regs = mxs_i2c_get_base(adap);
-   int ret;
-   int speed = mxs_i2c_get_bus_speed(adap);
-
-   ret = mxs_reset_block(_regs->hw_i2c_ctrl0_reg);
-   if (ret) {
-   debug("MXS I2C: Block reset timeout\n");
-   return;
-   }
-
-   writel(I2C_CTRL1_DATA_ENGINE_CMPLT_IRQ | I2C_CTRL1_NO_SLAVE_ACK_IRQ |
-   I2C_CTRL1_EARLY_TERM_IRQ | I2C_CTRL1_MASTER_LOSS_IRQ |
-   I2C_CTRL1_SLAVE_STOP_IRQ | I2C_CTRL1_SLAVE_IRQ,
-   _regs->hw_i2c_ctrl1_clr);
-
-   writel(I2C_QUEUECTRL_PIO_QUEUE_MODE, _regs->hw_i2c_queuectrl_set);
-
-   mxs_i2c_set_bus_speed(adap, speed);
-}
-
-static void mxs_i2c_setup_read(struct i2c_adapter *adap, uint8_t chip, int len)
-{
-   struct mxs_i2c_regs *i2c_regs = mxs_i2c_get_base(adap);
-
-   writel(I2C_QUEUECMD_RETAIN_CLO

Re: [U-Boot] [PATCH v3 6/6] mmc: arm_pl180_mmci: Remove cd_inverted host's struct field

2018-07-25 Thread Tuomas Tynkkynen

On 07/24/2018 03:37 PM, Patrice Chotard wrote:

As platform uses GPIOs for card detection, it's
simpler and more readable to use GPIO_ACTIVE_(LOW|HIGH)
in the gpio flags instead of using the cd-inverted
property.


Reported-by: Tuomas Tynkkynen 
Signed-off-by: Patrice Chotard 
---


Sounds good but doesn't this series need to also remove
the usage of cd-inverted from the DT? Like:

diff --git a/arch/arm/dts/stm32429i-eval.dts b/arch/arm/dts/stm32429i-eval.dts
index c16594b7e4..f6753a4d1a 100644
--- a/arch/arm/dts/stm32429i-eval.dts
+++ b/arch/arm/dts/stm32429i-eval.dts
@@ -223,8 +223,7 @@
  {
status = "okay";
vmmc-supply = <_vcard>;
-   cd-gpios = < 15 GPIO_ACTIVE_HIGH>;
-   cd-inverted;
+   cd-gpios = < 15 GPIO_ACTIVE_LOW>;
pinctrl-names = "default", "opendrain";
pinctrl-0 = <_pins>;
pinctrl-1 = <_pins_od>;
diff --git a/arch/arm/dts/stm32f746-disco.dts b/arch/arm/dts/stm32f746-disco.dts
index e47f762e54..187c94b99b 100644
--- a/arch/arm/dts/stm32f746-disco.dts
+++ b/arch/arm/dts/stm32f746-disco.dts
@@ -307,8 +307,7 @@

  {
status = "okay";
-   cd-gpios = < 13 0>;
-   cd-inverted;
+   cd-gpios = < 13 GPIO_ACTIVE_LOW>;
pinctrl-names = "default", "opendrain";
pinctrl-0 = <_pins>;
pinctrl-1 = <_pins_od>;
diff --git a/arch/arm/dts/stm32f769-disco.dts b/arch/arm/dts/stm32f769-disco.dts
index 59c9d31c21..210be07ccc 100644
--- a/arch/arm/dts/stm32f769-disco.dts
+++ b/arch/arm/dts/stm32f769-disco.dts
@@ -256,8 +256,7 @@

  {
status = "okay";
-   cd-gpios = < 15 0>;
-   cd-inverted;
+   cd-gpios = < 15 GPIO_ACTIVE_LOW>;
pinctrl-names = "default", "opendrain";
pinctrl-0 = <_pins_b>;
pinctrl-1 = <_pins_od_b>;


diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mmc/arm_pl180_mmci.c
index 1cd780b3eec0..f71d79ecd6ba 100644
--- a/drivers/mmc/arm_pl180_mmci.c
+++ b/drivers/mmc/arm_pl180_mmci.c
@@ -499,11 +499,8 @@ static int dm_mmc_getcd(struct udevice *dev)
struct pl180_mmc_host *host = dev->priv;
int value = 1;
  
-	if (dm_gpio_is_valid(>cd_gpio)) {

+   if (dm_gpio_is_valid(>cd_gpio))
value = dm_gpio_get_value(>cd_gpio);
-   if (host->cd_inverted)
-   return !value;
-   }
  
  	return value;

  }
diff --git a/drivers/mmc/arm_pl180_mmci.h b/drivers/mmc/arm_pl180_mmci.h
index 6b98db6cd978..36487be288b2 100644
--- a/drivers/mmc/arm_pl180_mmci.h
+++ b/drivers/mmc/arm_pl180_mmci.h
@@ -192,7 +192,6 @@ struct pl180_mmc_host {
struct mmc_config cfg;
  #ifdef CONFIG_DM_MMC
struct gpio_desc cd_gpio;
-   bool cd_inverted;
  #endif
  };
  



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


Re: [U-Boot] [PATCH v2 6/6] mmc: arm_pl180_mmci: Add "cd_inverted" DT property read

2018-07-24 Thread Tuomas Tynkkynen

Hi Patrice,


On 07/24/2018 12:39 PM, Patrice Chotard wrote:

Add missing read of "cd_inverted" property in DT.



If your platform uses GPIOs for card detection, it's
simpler and more readable to use GPIO_ACTIVE_(LOW|HIGH)
in the gpio flags instead of using the cd-inverted
property. See Linux commit 45e01f401a2a16a8d7 where this
was done for sunxi). Then this commit isn't needed.

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


Re: [U-Boot] [PATCH v2 1/2] rtc: pl031: convert the driver to driver model

2018-07-04 Thread Tuomas Tynkkynen

Hi Akashi,

Thank you for the DM conversion.

On 07/04/2018 10:36 AM, AKASHI Takahiro wrote:
<..snip..>

diff --git a/include/dm/platform_data/rtc_pl031.h 
b/include/dm/platform_data/rtc_pl031.h
new file mode 100644
index 00..8e4ba1ce69
--- /dev/null
+++ b/include/dm/platform_data/rtc_pl031.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+
+#ifndef __rtc_pl031_h
+#define __rtc_pl031_h
+
+#include 
+
+struct pl031_rtc_platdata {
+   phys_addr_t base;
+};
+
+#endif



I think this file won't be necessary, the structure can stay private to pl031.c.
PL031 is an ARM IP block and U-Boot on ARM uses the device tree to locate 
devices.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 1/2] rtc: pl031: convert the driver to driver model

2018-07-04 Thread Tuomas Tynkkynen

On 07/04/2018 11:53 AM, Alexander Graf wrote:

On 07/04/2018 09:36 AM, AKASHI Takahiro wrote:

This patch is missing a patch description. I'm not the maintainer of the rtc 
code base so it's not my call, but I personally just reject all patches with 
empty patch descriptions ;).

And thanks a lot for doing the conversion! I think it's a very good step 
forward.


Signed-off-by: AKASHI Takahiro 
---

...snip...

  /*
- * Reset the RTC. We set the date back to 1970-01-01.
+ * Get the current time from the RTC
   */
-void rtc_reset(void)
+static int pl031_rtc_get(struct udevice *dev, struct rtc_time *tm)
  {
-    RTC_WRITE_REG(RTC_LR, 0x00);
-    if(!pl031_initted)
-    rtc_init();
+    struct pl031_rtc_platdata *pdata = dev_get_platdata(dev);
+    ulong tim;
+
+    if (!tm) {
+    puts("Error getting the date/time\n");
+    return -1;
+    }
+
+    if (!pl031_initted)


In theory with dm you can now have multiple instances of the device, right? So 
we can no longer have a global variable that indicates if a device is 
initialized. Instead, this needs to move into device private data.



I think the initialization code in rtc_init() should be move to the .probe 
callback instead, so there's no need to keep the bool aroun.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/1] ARM: qemu-arm: enable RTC

2018-07-02 Thread Tuomas Tynkkynen

Hi Heinrich,

On 06/29/2018 01:34 AM, Heinrich Schuchardt wrote:

QEMU provides an emulated ARM AMBA PrimeCell PL031 RTC.

The patch sets the base address in the board include file according to the
definition in hw/arm/virt.c of the QEMU source. It defines the Kconfig
option for the existing driver, and enables the RTC driver in
qemu_arm64_defconfig and qemu_arm_defconfig as well as the date command.

We need an RTC to provide the GetTime() runtime service in the UEFI
subsystem.

Signed-off-by: Heinrich Schuchardt 
---
  configs/qemu_arm64_defconfig | 2 ++
  configs/qemu_arm_defconfig   | 2 ++
  drivers/rtc/Kconfig  | 7 +++
  include/configs/qemu-arm.h   | 3 +++
  4 files changed, 14 insertions(+)



Reviewed-by: Tuomas Tynkkynen 
Tested-by: Tuomas Tynkkynen 

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


Re: [U-Boot] inappropriate PCI configuration on arm64 qemu?

2018-06-01 Thread Tuomas Tynkkynen

On 06/01/2018 10:21 AM, AKASHI Takahiro wrote:

Tuomas,

On Thu, May 31, 2018 at 01:32:20PM +0300, Tuomas Tynkkynen wrote:

Hi Akashi,

On 05/31/2018 08:05 AM, AKASHI Takahiro wrote:

Simon,

On Wed, May 30, 2018 at 01:18:30PM -0600, Simon Glass wrote:

+Tuomas

Hi Akashi,

On 28 May 2018 at 01:59, AKASHI Takahiro  wrote:

When I tried to add a SD card to qemu's virt machine (2.10.0) as,
 --
 -device sdhci-pci \
 -device sd-card,drive=my_sd \
 -drive if=none,id=my_sd,format=raw,file=/path/my/sd.img
 --
u-boot doesn't configure a SDHCI controller properly and an attached
device is never detected.

Digging into the code, I found
* reading BAR5 in dm_pciauto_setup_device() shows BAR5 is a 32-bit address,
* pciauto_region_allocate() allocates a 64-bit address (0x80.ABCD.)
   to BAR5 as res->bus_lower is 0x80..
* Upper 32-bit value is not written back to BAR5 because of !found_mem64
   (BAR5 is the last one and no succeeding BAR anyway.)

On the other hand,
* Qemu defines two PCI memory regions for MMIO:
 (from qemu's hw/arm/virt.c)
 --
 [VIRT_PCIE_MMIO] =  { 0x1000, 0x2eff },
 [VIRT_PCIE_PIO] =   { 0x3eff, 0x0001 },
 [VIRT_PCIE_ECAM] =  { 0x3f00, 0x0100 },
 [VIRT_MEM] ={ 0x4000, RAMLIMIT_BYTES },
 /* Second PCIe window, 512GB wide at the 512GB boundary */
 [VIRT_PCIE_MMIO_HIGH] =   { 0x80ULL, 0x80ULL },
 --
* A PCI card is configured in decode_regions() so that
   'hose' has only one entry per each type of memory regions.
   This behavior was introduced by Simon's patch:
 --
 commit 9526d83ac5a
 Author: Simon Glass 
 Date:   Thu Nov 19 20:26:58 2015 -0700

 dm: pci: Support decoding ranges with duplicate entries
 --
* As a result, MMIO region (0x1000.-0x2eff.) is overwritten
   and MMIO_HIGH is the only one available at runtime.

I believe that this behavior is the root cause of my issue, and
by reverting the patch mentioned above, everything works fine.

While I understand a concern mentioned in the commit message,
there should be a better way to manage the case.


There was a series that changed things in this area. Can you take a look?

PCI: dm: Ignore 64-bit memory regions if CONFIG_SYS_PCI_64BIT not set


Ah, I didn't know that, but it seems to me that it is still insufficient.
This hack won't work on 32-bit PCI card. I found another patch from Tuomas:


Did you try it? As of today's master all of the patches are applied and at
least the e1000 NIC and the Intel AHCI card that I tested works.
The effect of the commit is to indeed avoid the problem you mentioned:


Yes, I ran my patch but *with* CONFIG_SYS_PCI_64BIT.



I meant: Did you try your QEMU command that enables the SDHCI on U-Boot
master, without any patches? It should just work.


* As a result, MMIO region (0x1000.-0x2eff.) is overwritten
and MMIO_HIGH is the only one available at runtime.


Note that even on aarch64, CONFIG_SYS_PCI_64BIT is *not* set by default.
And on ARM we would need to skip that region in U-Boot anyway because
we don't have the means to access physical addresses above the 4GB
boundary with the CPU using U-Boot's identity-mapped page tables.


Maybe you're right regarding aarch64, but the issue is not about arm/arm64
but PCI configuration. Some arch/machines, freescale mostly?, have
already enabled CONFIG_SYS_PCI_64BIT. I'm afraid that there may be
a possibility that your patch breaks them.



Which patch?

The "PCI: dm: Ignore 64-bit memory regions if CONFIG_SYS_PCI_64BIT not set"
commit adds:

+   if (!IS_ENABLED(CONFIG_SYS_PCI_64BIT) &&
+   type == PCI_REGION_MEM && upper_32_bits(pci_addr)) {
+   debug(" - beyond the 32-bit boundary, ignoring\n");
+   continue;
+   }

I.e. the patch is a no-op if CONFIG_SYS_PCI_64BIT is set. Also I don't
think PowerPC uses DM PCI, so that code is not executed at all on those
platforms.

If you mean in "PCI: autoconfig: Don't allocate 64-bit addresses to 32-bit only
resources" that someone could have been relying on the truncation of high
32 bits of bus addresses with 32-bit only devices, none of the FSL platforms
have bus addresses above 32-bits, only physical addresses (seen with
git grep CONFIG_SYS_PCIE._MEM_), so that shouldn't cause a problem either.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] inappropriate PCI configuration on arm64 qemu?

2018-05-31 Thread Tuomas Tynkkynen

Hi Akashi,

On 05/31/2018 08:05 AM, AKASHI Takahiro wrote:

Simon,

On Wed, May 30, 2018 at 01:18:30PM -0600, Simon Glass wrote:

+Tuomas

Hi Akashi,

On 28 May 2018 at 01:59, AKASHI Takahiro  wrote:

When I tried to add a SD card to qemu's virt machine (2.10.0) as,
 --
 -device sdhci-pci \
 -device sd-card,drive=my_sd \
 -drive if=none,id=my_sd,format=raw,file=/path/my/sd.img
 --
u-boot doesn't configure a SDHCI controller properly and an attached
device is never detected.

Digging into the code, I found
* reading BAR5 in dm_pciauto_setup_device() shows BAR5 is a 32-bit address,
* pciauto_region_allocate() allocates a 64-bit address (0x80.ABCD.)
   to BAR5 as res->bus_lower is 0x80..
* Upper 32-bit value is not written back to BAR5 because of !found_mem64
   (BAR5 is the last one and no succeeding BAR anyway.)

On the other hand,
* Qemu defines two PCI memory regions for MMIO:
 (from qemu's hw/arm/virt.c)
 --
 [VIRT_PCIE_MMIO] =  { 0x1000, 0x2eff },
 [VIRT_PCIE_PIO] =   { 0x3eff, 0x0001 },
 [VIRT_PCIE_ECAM] =  { 0x3f00, 0x0100 },
 [VIRT_MEM] ={ 0x4000, RAMLIMIT_BYTES },
 /* Second PCIe window, 512GB wide at the 512GB boundary */
 [VIRT_PCIE_MMIO_HIGH] =   { 0x80ULL, 0x80ULL },
 --
* A PCI card is configured in decode_regions() so that
   'hose' has only one entry per each type of memory regions.
   This behavior was introduced by Simon's patch:
 --
 commit 9526d83ac5a
 Author: Simon Glass 
 Date:   Thu Nov 19 20:26:58 2015 -0700

 dm: pci: Support decoding ranges with duplicate entries
 --
* As a result, MMIO region (0x1000.-0x2eff.) is overwritten
   and MMIO_HIGH is the only one available at runtime.

I believe that this behavior is the root cause of my issue, and
by reverting the patch mentioned above, everything works fine.

While I understand a concern mentioned in the commit message,
there should be a better way to manage the case.


There was a series that changed things in this area. Can you take a look?

PCI: dm: Ignore 64-bit memory regions if CONFIG_SYS_PCI_64BIT not set


Ah, I didn't know that, but it seems to me that it is still insufficient.
This hack won't work on 32-bit PCI card. I found another patch from Tuomas:


Did you try it? As of today's master all of the patches are applied and at
least the e1000 NIC and the Intel AHCI card that I tested works.
The effect of the commit is to indeed avoid the problem you mentioned:

>>> * As a result, MMIO region (0x1000.-0x2eff.) is overwritten
>>>and MMIO_HIGH is the only one available at runtime.

Note that even on aarch64, CONFIG_SYS_PCI_64BIT is *not* set by default.
And on ARM we would need to skip that region in U-Boot anyway because
we don't have the means to access physical addresses above the 4GB
boundary with the CPU using U-Boot's identity-mapped page tables.


---
 commit d71975ae6e0
     Author: Tuomas Tynkkynen 
 Date:   Mon May 14 19:38:13 2018 +0300

 PCI: autoconfig: Don't allocate 64-bit addresses to 32-bit only
 resources
---

This approach looks too conservative if 32-bit window is also available,
in addition to 64-bit space, as in the case of qemu-arm.


Yes, the patch is very minimal - I just wanted to fix the silent truncation
of 64-bit addresses to 32-bit addresses and complain instead, nothing more.

(As the default config of qemu_arm* doesn't have CONFIG_SYS_PCI_64BIT,
the condition won't actually trigger in practice).


I'd like to propose supporting at least two type of PCI memory regions,
low mem (normal case) and high mem.
Attached is my experimental implementation for this although I might have
made any mistake as I'm not very much familiar with PCI specification.



Yes, in theory it could be useful for some future hardware, but for QEMU
point of view the current situation of totally ignoring the 64-bit mem region
is probably good enough, given that most of the useful hardware that QEMU
can enable is limited to 32-bit addressing anyway.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/1] efi_loader: avoid make race condition

2018-05-29 Thread Tuomas Tynkkynen

Hi,

On 05/27/2018 11:28 PM, Heinrich Schuchardt wrote:

When building .efi targets a race condition was observed:

If %_efi.so is not yet built before trying to build %.efi and error
*** No rule to make target '%.efi'
occurs. By explicitly adding %_efi.so to the targets this is avoided.

Reported-by: Tuomas Tynkkynen 
Signed-off-by: Heinrich Schuchardt 
---
Hello Tuomas,

please, test if this resolves your problem.

Best regards

Heinrich
---
  lib/efi_loader/Makefile   | 4 +++-
  lib/efi_selftest/Makefile | 2 ++
  2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index c6046e36d26..d31393c7a28 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -10,7 +10,9 @@ CFLAGS_helloworld.o := $(CFLAGS_EFI) -Os -ffreestanding
  CFLAGS_REMOVE_helloworld.o := $(CFLAGS_NON_EFI) -Os
  
  ifneq ($(CONFIG_CMD_BOOTEFI_HELLO_COMPILE),)

-always += helloworld.efi
+always-y += \
+helloworld_efi.so \
+helloworld.efi
  endif
  


The always-y variable isn't processed by Kbuild. So effectively this hunk
makes helloworld.efi to be never built at all.

If I do s/always-y/always/ on that line, that just changes the eventual
error message to:

make[3]: *** No rule to make target 'lib/efi_loader/helloworld_efi.so', needed 
by '__build'.  Stop.

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


Re: [U-Boot] Parallel make issue with helloworld.efi

2018-05-27 Thread Tuomas Tynkkynen

Hi Heinrich,

Thanks for taking a look.

On 05/27/2018 08:11 PM, Heinrich Schuchardt wrote:

On 11/07/2017 04:57 PM, Tuomas Tynkkynen wrote:

Hi,

Every now and then I see parallel builds failing, e.g. with
Linksprite_pcDuino3_Nano_defconfig:

   CC  lib/efi_loader/efi_bootmgr.o
   CC  lib/efi_loader/efi_disk.o
   CC  lib/efi_loader/efi_net.o
make[2]: *** No rule to make target 'lib/efi_loader/helloworld.efi',
needed by '__build'.  Stop.
make[2]: *** Waiting for unfinished jobs
   CC  lib/efi_loader/efi_smbios.o
make[1]: *** [scripts/Makefile.build:425: lib/efi_loader] Error 2
make: *** [Makefile:1279: lib] Error 2

This has been going for a while now (since ~2017.03 or so).
Anybody have ideas on how to express the dependency properly?


Hello Tuomas,

the build dependencies for *.efi files are described in
./scripts/Makefile.lib:

EFI_LDS_PATH = $(srctree)/arch/$(ARCH)/lib/$(EFI_LDS)

cmd_efi_ld = $(LD) -nostdlib -znocombreloc -T $(EFI_LDS_PATH) -shared \
 -Bsymbolic $^ -o $@

$(obj)/%_efi.so: $(obj)/%.o arch/$(ARCH)/lib/$(EFI_CRT0) \
 arch/$(ARCH)/lib/$(EFI_RELOC)
 $(call cmd,efi_ld)

$(obj)/%.efi: $(obj)/%_efi.so
 $(call cmd,efi_objcopy)


Right, but...


The target is selected in lib/efi_loader/Makefile:

ifneq ($(CONFIG_CMD_BOOTEFI_HELLO_COMPILE),)
always += helloworld.efi
endif



... as I've described in

https://lists.denx.de/pipermail/u-boot/2018-March/323624.html

, the problem is that when recursive make is building lib/efi_loader,
arch/$(ARCH)/lib/$(EFI_CRT0) might not exist yet and the rule for building
it is only known by the recursive make responsible for building
arch/arm/lib.


obj-$(CONFIG_CMD_BOOTEFI_HELLO) += helloworld_efi.o
obj-y += efi_image_loader.o efi_boottime.o efi_runtim

Does the problem ever occur if you run mrproper beforehand?



It doesn't matter if it's a clean or incremental build. By increasing
the race window with this hacky patch (the ':=' -> '=' change is important):

diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 655727f431..fb569f57f2 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -99,10 +99,10 @@ endif
 endif

 # For building EFI apps
-CFLAGS_$(EFI_CRT0) := $(CFLAGS_EFI)
+CFLAGS_$(EFI_CRT0) = $(CFLAGS_EFI) $(shell echo sleeping >&2 && sleep 60)
 CFLAGS_REMOVE_$(EFI_CRT0) := $(CFLAGS_NON_EFI)

-CFLAGS_$(EFI_RELOC) := $(CFLAGS_EFI)
+CFLAGS_$(EFI_RELOC) = $(CFLAGS_EFI) $(shell echo sleeping >&2 && sleep 60)
 CFLAGS_REMOVE_$(EFI_RELOC) := $(CFLAGS_NON_EFI)

 extra-$(CONFIG_CMD_BOOTEFI_HELLO_COMPILE) += $(EFI_CRT0) $(EFI_RELOC)


and running:

export CROSS_COMPILE=arm-linux-gnueabihf-
rm -rf build-qemu_arm
make O=build-qemu_arm qemu_arm_defconfig
make O=build-qemu_arm all -j4

... I can reproduce the problem 100% of the time, even in incremental builds.
For example:

$ make O=build-qemu_arm all -j4 V=1

make -C /home/tmtynkky/opt/u-boot/build-qemu_arm 
KBUILD_SRC=/home/tmtynkky/opt/u-boot \
-f /home/tmtynkky/opt/u-boot/Makefile all
make[1]: Entering directory '/home/tmtynkky/opt/u-boot/build-qemu_arm'
set -e; : '  CHK include/config/uboot.release'; mkdir -p include/config/;   echo 
"2018.05$(/bin/sh ../scripts/setlocalversion ..)" < include/config/auto.conf > 
include/config/uboot.release.tmp; if [ -r include/config/uboot.release ] && cmp -s 
include/config/uboot.release include/config/uboot.release.tmp; then rm -f 
include/config/uboot.release.tmp; else : '  UPD include/config/uboot.release'; mv -f 
include/config/uboot.release.tmp include/config/uboot.release; fi
ln -fsn .. source
set -e; : '  CHK include/generated/timestamp_autogenerated.h'; mkdir -p include/generated/; (if test -n "${SOURCE_DATE_EPOCH}"; then SOURCE_DATE="@${SOURCE_DATE_EPOCH}"; DATE=""; for date in gdate date.gnu date; do ${date} -u -d "${SOURCE_DATE}" 
>/dev/null 2>&1 && DATE="${date}"; done; if test -n "${DATE}"; then LC_ALL=C ${DATE} -u -d "${SOURCE_DATE}" +'#define U_BOOT_DATE "%b %d %C%y"'; LC_ALL=C ${DATE} -u -d "${SOURCE_DATE}" +'#define U_BOOT_TIME "%T"'; LC_ALL=C 
${DATE} -u -d "${SOURCE_DATE}" +'#define U_BOOT_TZ "%z"'; LC_ALL=C ${DATE} -u -d "${SOURCE_DATE}" +'#define U_BOOT_DMI_DATE "%m/%d/%Y"'; LC_ALL=C ${DATE} -u -d "${SOURCE_DATE}" +'#define U_BOOT_BUILD_DATE 0x%Y%m%d'; else return 42; fi; else LC_ALL=C 
date +'#define U_BOOT_DATE "%b %d %C%y"'; LC_ALL=C date +'#define U_BOOT_TIME "%T"'; LC_ALL=C date +'#define U_BOOT_TZ "%z"'; LC_ALL=C date +'#define U_BOOT_DMI_DATE "%m/%d/%Y"'; LC_ALL=C date +'#define U_BOOT_BUILD_DATE 0x%Y%m%d'; fi) < ../Makefile > 
include/generated/timestamp_autogenerated.h.tmp; if [ -r include/generated/timestamp_autogenerated.h ] && cmp -s include/ge

Re: [U-Boot] [PATCH 2/2] efi_loader: build CRT0 and RELOC on x86_64

2018-05-26 Thread Tuomas Tynkkynen
Hi,

On Fri, 18 May 2018 19:12:20 +0200
Heinrich Schuchardt  wrote:

> The efi selftest and the hello application require CRT0 and RELOC to be
> built.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---

While we're on the topic of EFI_CRT0 and EFI_RELOC, does anybody
happen to have an idea on how to fix parallel build failures
due to helloworld.efi getting built before EFI_{CRT0,RELOC}?
I've reported it previously at:

https://lists.denx.de/pipermail/u-boot/2018-March/323624.html

Pretty please? :)

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


Re: [U-Boot] [PATCH 1/2] rpi: Fix fdt_high & initrd_high for 64-bit builds

2018-05-24 Thread Tuomas Tynkkynen
Hi Alex,

On Thu, 24 May 2018 09:51:57 +0200
Alexander Graf <ag...@suse.de> wrote:

> On 20.04.18 12:03, Tuomas Tynkkynen wrote:
> > The magic value that disables relocation is dependent on the CPU word
> > size, so the current '' is doing the wrong thing on aarch64.
> > 
> > Signed-off-by: Tuomas Tynkkynen <tuo...@tuxera.com>  
> 
> The BCM283x series of SOCs is limited to 32bit address space, so I don't
> quite see why the current (int)-1 is wrong?
> 
> 

The comparison for the magic "don't relocate value" is done by parsing
the variable as ulong and then comparing to ~0. So on 64-bit, 
gets interpreted as literal 0x limit for the relocation (which
I think in practice is the same as not specifying initrd_high at all
since the end of DRAM is lower than that) instead.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] rpi: Adjust fdt_addr_r to a sane address

2018-05-24 Thread Tuomas Tynkkynen
Hi Alexander,

On Thu, 24 May 2018 10:12:54 +0200
Alexander Graf <ag...@suse.de> wrote:

> On 14.04.18 20:04, Tuomas Tynkkynen wrote:
> > Hi Alexander,
> > 
> > On Fri, 13 Apr 2018 17:49:00 +0200
> > Alexander Graf <ag...@suse.de> wrote:
> > 
> > [...]  
> >>
> >> diff --git a/include/configs/rpi.h b/include/configs/rpi.h
> >> index 325e52a019..fcf7e0976b 100644
> >> --- a/include/configs/rpi.h
> >> +++ b/include/configs/rpi.h
> >> @@ -124,7 +124,7 @@
> >>  #define ENV_MEM_LAYOUT_SETTINGS \
> >>"fdt_high=\0" \
> >>"initrd_high=\0" \
> >> -  "fdt_addr_r=0x0100\0" \
> >> +  "fdt_addr_r=0x01f0\0" \
> >>"pxefile_addr_r=0x0010\0" \
> >>"kernel_addr_r=0x0100\0" \
> >>"scriptaddr=0x0200\0" \  
> > 
> > Note that above the #define is a larger comment block that needs to be
> > updated as well. Also the other addresses also need updatingfor bigger
> > kernels on AArch64: https://patchwork.ozlabs.org/patch/25/
> > 
> > Though now I double-checked that the smallest possible GPU-CPU memory
> > split is actually 64MB for the CPU, not 128M. So maybe something like:
> > 
> >  "kernel_addr_r=0x0008\0" \
> >  "fdt_addr_r=0x0240\0" \
> >  "scriptaddr=0x0250\0" \
> >  "pxefile_addr_r=0x0260\0" \
> >  "ramdisk_addr_r=0x0270\0"
> > 
> > which would allow a kernel up to 36M, 1M for dtb, script and pxe files
> > each, and at least 25M for the initrd. Also I think giving up with the
> > constraint of locating the zImage high enough so that the kernel
> > decompressor doesn't need to relocate itself can be dropped. If the
> > boot speed of their Raspi matters that much, probably they wouldn't use
> > U-Boot in the first place.
> > 
> > What is the address that the RPi firmware loads its device tree to? I
> > hope that we don't have to worry about the positioning of that too...  
> 
> U-Boot> bdinfo
> arch_number = 0x
> boot_params = 0x0100
> DRAM bank   = 0x
> -> start= 0x
> -> size = 0x3B40  
> baudrate= 115200 bps
> TLB addr= 0x3B3F
> relocaddr   = 0x3B348000
> reloc off   = 0x3B2C8000
> irq_sp  = 0x3AF3E120
> sp start= 0x3AF3E120
> Early malloc usage: 138 / 2000
> fdt_blob = 3af3e130
> U-Boot> print fdt_addr
> fdt_addr=2effb300
> 
> So on boot the DT passed into U-Boot is either at ~750MB or close to the
> top. I can't quite find any code that explains the difference in the two
> variables. Either way, I guess firmware tries to put it reasonably high?

I believe fdt_addr is what is passed to the kernel and fdt_blob is what
U-Boot's device model is using.

> So as long as we keep the load addresses low enough, we should be safe.

Good.

> Also fyi, I would like to switch to CONFIG_OF_BOARD by default, once I
> added code that marks u-boot.bin as an "upstream kernel" for the RPi
> firmware, because then newer RPi firmwares will pass us a fully upstream
> compatible device tree [1] which we can then pass on to Linux as default.

Makes sense, but I guess needs some documentation. Also for existing things
like whether enable_uart=1 is needed or not.

> 
> Alex
> 
> [1] https://github.com/raspberrypi/firmware/issues/943

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


Re: [U-Boot] [PATCH 2/2] ARM: Add a new arch + board for QEMU's 'virt' machine

2018-05-14 Thread Tuomas Tynkkynen
Hi,

On Wed, 9 May 2018 12:56:46 +0200
Paulo Neves  wrote:

> Hello I have successfully built u-boot and launched qemu with the
> flags proposed by the patch. My problems start when I try to boot the
> kernel
> 
> What is the linux kernel defconfig that should be used to boot this
> machine?

multi_v7_defconfig does work at least.

> I tried the versatile one but they are different in some key
> places like the sd card. The end result is that I can only see
> Starting Kernel, and nothing else. What bootargs do you pass to the
> kernel to have the serial output in qemu?

The serial port in Linux is ttyAMA0. But I think it works without any
console= specified as well, because the QEMU-generated dtb specifies
/chosen/stdout-path already pointing to that serial port.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] PCI: Document pciauto_region_allocate()

2018-05-14 Thread Tuomas Tynkkynen
Add a doc comment for pciauto_region_allocate().

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkky...@iki.fi>
---
This patch depends on [PATCH 2/2] PCI: autoconfig: Don't allocate 64-bit
addresses to 32-bit only resources.
---
 include/pci.h | 13 +
 1 file changed, 13 insertions(+)

diff --git a/include/pci.h b/include/pci.h
index 127d3c6a6f..8e27cbfaf1 100644
--- a/include/pci.h
+++ b/include/pci.h
@@ -680,6 +680,19 @@ extern int pci_write_config_dword(pci_dev_t dev, int 
where, u32 val);
 void pciauto_region_init(struct pci_region *res);
 void pciauto_region_align(struct pci_region *res, pci_size_t size);
 void pciauto_config_init(struct pci_controller *hose);
+
+/**
+ * pciauto_region_allocate() - Allocate resources from a PCI resource region
+ *
+ * Allocates @size bytes from the PCI resource @res. If @supports_64bit is
+ * false, the result will be guaranteed to fit in 32 bits.
+ *
+ * @res:   PCI region to allocate from
+ * @size:  Amount of bytes to allocate
+ * @bar:   Returns the PCI bus address of the allocated resource
+ * @supports_64bit:Whether to allow allocations above the 32-bit boundary
+ * @return 0 if successful, -1 on failure
+ */
 int pciauto_region_allocate(struct pci_region *res, pci_size_t size,
pci_addr_t *bar, bool supports_64bit);
 
-- 
2.16.3

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


[U-Boot] [PATCH 2/2] PCI: autoconfig: Don't allocate 64-bit addresses to 32-bit only resources

2018-05-14 Thread Tuomas Tynkkynen
Currently, if we happen to allocate an address requiring 64 bits to a
device only supporting 32-bit BARs, the address eventually gets silently
truncated to 32 bits. Avoid this by adding a new flag to
pciauto_region_allocate() to bail out in such situations.

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkky...@iki.fi>
---
 drivers/pci/pci_auto.c| 6 --
 drivers/pci/pci_auto_common.c | 7 ++-
 drivers/pci/pci_auto_old.c| 5 +++--
 include/pci.h | 2 +-
 4 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/pci/pci_auto.c b/drivers/pci/pci_auto.c
index d1feb503a0..d7237f6eee 100644
--- a/drivers/pci/pci_auto.c
+++ b/drivers/pci/pci_auto.c
@@ -98,7 +98,8 @@ void dm_pciauto_setup_device(struct udevice *dev, int 
bars_num,
}
 
if (!enum_only && pciauto_region_allocate(bar_res, bar_size,
- _value) == 0) {
+ _value,
+ found_mem64) == 0) {
/* Write it out and update our limit */
dm_pci_write_config32(dev, bar, (u32)bar_value);
 
@@ -140,7 +141,8 @@ void dm_pciauto_setup_device(struct udevice *dev, int 
bars_num,
debug("PCI Autoconfig: ROM, size=%#x, ",
  (unsigned int)bar_size);
if (pciauto_region_allocate(mem, bar_size,
-   _value) == 0) {
+   _value,
+   false) == 0) {
dm_pci_write_config32(dev, rom_addr,
  bar_value);
}
diff --git a/drivers/pci/pci_auto_common.c b/drivers/pci/pci_auto_common.c
index d90dbcf91a..183787333e 100644
--- a/drivers/pci/pci_auto_common.c
+++ b/drivers/pci/pci_auto_common.c
@@ -32,7 +32,7 @@ void pciauto_region_align(struct pci_region *res, pci_size_t 
size)
 }
 
 int pciauto_region_allocate(struct pci_region *res, pci_size_t size,
-   pci_addr_t *bar)
+   pci_addr_t *bar, bool supports_64bit)
 {
pci_addr_t addr;
 
@@ -48,6 +48,11 @@ int pciauto_region_allocate(struct pci_region *res, 
pci_size_t size,
goto error;
}
 
+   if (upper_32_bits(addr) && !supports_64bit) {
+   debug("Cannot assign 64-bit address to 32-bit-only resource\n");
+   goto error;
+   }
+
res->bus_lower = addr + size;
 
debug("address=0x%llx bus_lower=0x%llx\n", (unsigned long long)addr,
diff --git a/drivers/pci/pci_auto_old.c b/drivers/pci/pci_auto_old.c
index bc119fba87..e705a3072e 100644
--- a/drivers/pci/pci_auto_old.c
+++ b/drivers/pci/pci_auto_old.c
@@ -108,7 +108,8 @@ void pciauto_setup_device(struct pci_controller *hose,
}
 
 #ifndef CONFIG_PCI_ENUM_ONLY
-   if (pciauto_region_allocate(bar_res, bar_size, _value) == 
0) {
+   if (pciauto_region_allocate(bar_res, bar_size,
+   _value, found_mem64) == 0) {
/* Write it out and update our limit */
pci_hose_write_config_dword(hose, dev, bar, 
(u32)bar_value);
 
@@ -150,7 +151,7 @@ void pciauto_setup_device(struct pci_controller *hose,
debug("PCI Autoconfig: ROM, size=%#x, ",
  (unsigned int)bar_size);
if (pciauto_region_allocate(mem, bar_size,
-   _value) == 0) {
+   _value, false) == 0) {
pci_hose_write_config_dword(hose, dev, rom_addr,
bar_value);
}
diff --git a/include/pci.h b/include/pci.h
index cda6907688..127d3c6a6f 100644
--- a/include/pci.h
+++ b/include/pci.h
@@ -681,7 +681,7 @@ void pciauto_region_init(struct pci_region *res);
 void pciauto_region_align(struct pci_region *res, pci_size_t size);
 void pciauto_config_init(struct pci_controller *hose);
 int pciauto_region_allocate(struct pci_region *res, pci_size_t size,
-   pci_addr_t *bar);
+   pci_addr_t *bar, bool supports_64bit);
 
 #if !defined(CONFIG_DM_PCI) || defined(CONFIG_DM_PCI_COMPAT)
 extern int pci_hose_read_config_byte_via_dword(struct pci_controller *hose,
-- 
2.16.3

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


[U-Boot] [PATCH 1/2] PCI: Add newlines to debug prints in pci_auto_common.c

2018-05-14 Thread Tuomas Tynkkynen
All of the debug output from this file is squished to one line. Fix
it.

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkky...@iki.fi>
---
 drivers/pci/pci_auto_common.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/pci_auto_common.c b/drivers/pci/pci_auto_common.c
index 1d202ae2ef..d90dbcf91a 100644
--- a/drivers/pci/pci_auto_common.c
+++ b/drivers/pci/pci_auto_common.c
@@ -37,7 +37,7 @@ int pciauto_region_allocate(struct pci_region *res, 
pci_size_t size,
pci_addr_t addr;
 
if (!res) {
-   debug("No resource");
+   debug("No resource\n");
goto error;
}
 
@@ -50,7 +50,7 @@ int pciauto_region_allocate(struct pci_region *res, 
pci_size_t size,
 
res->bus_lower = addr + size;
 
-   debug("address=0x%llx bus_lower=0x%llx", (unsigned long long)addr,
+   debug("address=0x%llx bus_lower=0x%llx\n", (unsigned long long)addr,
  (unsigned long long)res->bus_lower);
 
*bar = addr;
-- 
2.16.3

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


[U-Boot] [PATCH 3/3] doc: qemu-arm: Drop highmem=off references

2018-05-14 Thread Tuomas Tynkkynen
Now that U-Boot works fine with highmem enabled, there is no need to
tell users to disable highmem.

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkky...@iki.fi>
---
 doc/README.qemu-arm | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/doc/README.qemu-arm b/doc/README.qemu-arm
index 6f6f07d8bb..260165638a 100644
--- a/doc/README.qemu-arm
+++ b/doc/README.qemu-arm
@@ -39,13 +39,12 @@ Running U-Boot
 The minimal QEMU command line to get U-Boot up and running is:
 
 - For ARM:
-qemu-system-arm -machine virt,highmem=off -bios u-boot.bin
+qemu-system-arm -machine virt -bios u-boot.bin
 
 - For AArch64:
-qemu-system-aarch64 -machine virt,highmem=off -cpu cortex-a57 -bios 
u-boot.bin
+qemu-system-aarch64 -machine virt -cpu cortex-a57 -bios u-boot.bin
 
-The 'highmem=off' parameter to the 'virt' machine is required for PCI to work
-in U-Boot. Also, for some odd reason qemu-system-aarch64 needs to be explicitly
+Note that for some odd reason qemu-system-aarch64 needs to be explicitly
 told to use a 64-bit CPU or it will boot in 32-bit mode.
 
 Additional peripherals that have been tested to work in both U-Boot and Linux
-- 
2.16.3

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


[U-Boot] [PATCH 2/3] ARM: qemu-arm: Bump RAM size in AArch64 MMU table

2018-05-14 Thread Tuomas Tynkkynen
Now that PCI devices work with highmem-enabled QEMU emulation, bump up
the RAM size in the MMU tables to gain access to the full 255 GB of RAM
potential instead of the puny 3 GB.

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkky...@iki.fi>
---
 board/emulation/qemu-arm/qemu-arm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/emulation/qemu-arm/qemu-arm.c 
b/board/emulation/qemu-arm/qemu-arm.c
index 6ec4200170..085cbbef99 100644
--- a/board/emulation/qemu-arm/qemu-arm.c
+++ b/board/emulation/qemu-arm/qemu-arm.c
@@ -28,7 +28,7 @@ static struct mm_region qemu_arm64_mem_map[] = {
/* RAM */
.virt = 0x4000UL,
.phys = 0x4000UL,
-   .size = 0xc000UL,
+   .size = 255UL * SZ_1G,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
 PTE_BLOCK_INNER_SHARE
}, {
-- 
2.16.3

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


[U-Boot] [PATCH 1/3] PCI: dm: Ignore 64-bit memory regions if CONFIG_SYS_PCI_64BIT not set

2018-05-14 Thread Tuomas Tynkkynen
Currently, qemu_arm_defconfig and qemu_arm64_defconfig only work with
the 'highmem=off' parameter passed to QEMU's virt machine. The reason is
that when 'highmem' is not disabled, QEMU appends 64-bit a memory
resource to the PCI controller's regions property in DT in addition to
the 32-bit PCI memory window in low memory. And the current DT parsing
code picks the last (thus the 64-bit one) memory resource, whose address
eventually gets silently truncated to 32 bits because
CONFIG_SYS_PCI_64BIT is not set, which obviously causes PCI to break.

Avoid this problem by ignoring memory regions whose addresses are above
the 32-bit boundary when CONFIG_SYS_PCI_64BIT is not set.

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkky...@iki.fi>
---
 drivers/pci/pci-uclass.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 49be1ebdd7..1cd1e409e3 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -860,6 +860,13 @@ static int decode_regions(struct pci_controller *hose, 
ofnode parent_node,
} else {
continue;
}
+
+   if (!IS_ENABLED(CONFIG_SYS_PCI_64BIT) &&
+   type == PCI_REGION_MEM && upper_32_bits(pci_addr)) {
+   debug(" - beyond the 32-bit boundary, ignoring\n");
+   continue;
+   }
+
pos = -1;
for (i = 0; i < hose->region_count; i++) {
if (hose->regions[i].flags == type)
-- 
2.16.3

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


Re: [U-Boot] [PATCH v2 1/1] arm: print instructions pointed to by pc

2018-05-13 Thread Tuomas Tynkkynen
Hi,

On Thu, 10 May 2018 16:38:30 +0200
Heinrich Schuchardt  wrote:

> If an exception occurs in a loaded image and the relocation offset is
> unknown, it is helful to know the instructions pointed to by the
> program counter. This patch adds the missing output.
> 
> A possible output is:
> *pc: fb de f7 e7 1e ff 2f e1 01 00 50 e3 f0 4d 2d e9 01 80 a0 e1
> 
> The output can be disassembled with
> xxd -pc -r - > a.out
> $(CROSS_COMPILE)objdump -D -marm -b binary a.out
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
> v2
>   print bytes not halfwords

Note that Linux already comes with a scripts/decodecode tool where you paste the
output of an Oops and it disassembles the "Code: " line from the dump. So I'd
vote for importing scripts/decodecode from Linux and making U-Boot's output
compatible with Linux.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 1/3] net: Drop CONFIG_TSI108_ETH

2018-05-09 Thread Tuomas Tynkkynen
Last user of this driver went away in June 2015 in commit
d928664f4101e24 ("powerpc: 74xx_7xx: remove 74xx_7xx cpu support")

Signed-off-by: Tuomas Tynkkynen <tuo...@tuxera.com>
---
 drivers/net/Makefile |1 -
 drivers/net/tsi108_eth.c | 1015 --
 include/netdev.h |1 -
 scripts/config_whitelist.txt |1 -
 4 files changed, 1018 deletions(-)
 delete mode 100644 drivers/net/tsi108_eth.c

diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 851f82fb01..584bfdf2f9 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -58,7 +58,6 @@ obj-$(CONFIG_DRIVER_TI_EMAC) += davinci_emac.o
 obj-$(CONFIG_TSEC_ENET) += tsec.o fsl_mdio.o
 obj-$(CONFIG_DRIVER_TI_CPSW) += cpsw.o cpsw-common.o
 obj-$(CONFIG_FMAN_ENET) += fsl_mdio.o
-obj-$(CONFIG_TSI108_ETH) += tsi108_eth.o
 obj-$(CONFIG_ULI526X) += uli526x.o
 obj-$(CONFIG_VSC7385_ENET) += vsc7385.o
 obj-$(CONFIG_XILINX_AXIEMAC) += xilinx_axi_emac.o
diff --git a/drivers/net/tsi108_eth.c b/drivers/net/tsi108_eth.c
deleted file mode 100644
index 108cf61647..00
--- a/drivers/net/tsi108_eth.c
+++ /dev/null
@@ -1,1015 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/***
- *
- * Copyright (c) 2005 Freescale Semiconductor, Inc.
- *
- * Description:
- *   Ethernet interface for Tundra TSI108 bridge chip
- *
- ***/
-
-#include 
-
-#if !defined(CONFIG_TSI108_ETH_NUM_PORTS) || (CONFIG_TSI108_ETH_NUM_PORTS > 2)
-#error "CONFIG_TSI108_ETH_NUM_PORTS must be defined as 1 or 2"
-#endif
-
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#ifdef DEBUG
-#define TSI108_ETH_DEBUG 7
-#else
-#define TSI108_ETH_DEBUG 0
-#endif
-
-#if TSI108_ETH_DEBUG > 0
-#define debug_lev(lev, fmt, args...) \
-if (lev <= TSI108_ETH_DEBUG) \
-printf ("%s %d: " fmt, __FUNCTION__, __LINE__, ##args)
-#else
-#define debug_lev(lev, fmt, args...) do{}while(0)
-#endif
-
-#define RX_PRINT_ERRORS
-#define TX_PRINT_ERRORS
-
-#define ETH_BASE   (CONFIG_SYS_TSI108_CSR_BASE + 0x6000)
-
-#define ETH_PORT_OFFSET0x400
-
-#define __REG32(base, offset) (*((volatile u32 *)((char *)(base) + (offset
-
-#define reg_MAC_CONFIG_1(base) __REG32(base, 0x)
-#define MAC_CONFIG_1_TX_ENABLE (0x0001)
-#define MAC_CONFIG_1_SYNC_TX_ENABLE(0x0002)
-#define MAC_CONFIG_1_RX_ENABLE (0x0004)
-#define MAC_CONFIG_1_SYNC_RX_ENABLE(0x0008)
-#define MAC_CONFIG_1_TX_FLOW_CONTROL   (0x0010)
-#define MAC_CONFIG_1_RX_FLOW_CONTROL   (0x0020)
-#define MAC_CONFIG_1_LOOP_BACK (0x0100)
-#define MAC_CONFIG_1_RESET_TX_FUNCTION (0x0001)
-#define MAC_CONFIG_1_RESET_RX_FUNCTION (0x0002)
-#define MAC_CONFIG_1_RESET_TX_MAC  (0x0004)
-#define MAC_CONFIG_1_RESET_RX_MAC  (0x0008)
-#define MAC_CONFIG_1_SIM_RESET (0x4000)
-#define MAC_CONFIG_1_SOFT_RESET(0x8000)
-
-#define reg_MAC_CONFIG_2(base) __REG32(base, 0x0004)
-#define MAC_CONFIG_2_FULL_DUPLEX   (0x0001)
-#define MAC_CONFIG_2_CRC_ENABLE(0x0002)
-#define MAC_CONFIG_2_PAD_CRC   (0x0004)
-#define MAC_CONFIG_2_LENGTH_CHECK  (0x0010)
-#define MAC_CONFIG_2_HUGE_FRAME(0x0020)
-#define MAC_CONFIG_2_INTERFACE_MODE(val)   (((val) & 0x3) << 8)
-#define MAC_CONFIG_2_PREAMBLE_LENGTH(val)  (((val) & 0xf) << 12)
-#define INTERFACE_MODE_NIBBLE  1   /* 10/100 Mb/s MII) */
-#define INTERFACE_MODE_BYTE2   /* 1000 Mb/s GMII/TBI */
-
-#define reg_MAXIMUM_FRAME_LENGTH(base) __REG32(base, 0x0010)
-
-#define reg_MII_MGMT_CONFIG(base)  __REG32(base, 0x0020)
-#define MII_MGMT_CONFIG_MGMT_CLOCK_SELECT(val) ((val) & 0x7)
-#define MII_MGMT_CONFIG_NO_PREAMBLE(0x0010)
-#define MII_MGMT_CONFIG_SCAN_INCREMENT (0x0020)
-#define MII_MGMT_CONFIG_RESET_MGMT (0x8000)
-
-#define reg_MII_MGMT_COMMAND(base) __REG32(base, 0x0024)
-#define MII_MGMT_COMMAND_READ_CYCLE(0x0001)
-#define MII_MGMT_COMMAND_SCAN_CYCLE(0x0002)
-
-#define reg_MII_MGMT_ADDRESS(base) __REG32(base, 0x0028)
-#define reg_MII_MGMT_CONTROL(base) __REG32(base, 0x002c)
-#define reg_MII_MGMT_STATUS(base)  __REG32(base, 0x0030)
-
-#define reg_MII_MGMT_INDICATORS(base)  __REG32(base, 0x0034)
-#define MII_MGMT_INDICATORS_BUSY   (0x0001)
-#define MII_MGMT_INDICATORS_SCAN   (0x0002)
-#define MII_MGMT_INDICATORS_NOT_VALID  (0x0004)
-
-#define reg_INTERFACE_STATUS(base) __REG32(base, 0x003c)
-#define INTERFACE_STATUS_LINK_FAIL (0x0008)
-#define INTERFACE_STATUS_EXCESS_DEFER  (0x000

[U-Boot] [PATCH 3/3] i2c: Drop CONFIG_SH_SH7734_I2C

2018-05-09 Thread Tuomas Tynkkynen
Last user of this driver went away in May 2017 in commit
eb5ba3aefdf0f6c ("i2c: Drop use of CONFIG_I2C_HARD").

Signed-off-by: Tuomas Tynkkynen <tuo...@tuxera.com>
---
 doc/driver-model/i2c-howto.txt |   1 -
 drivers/i2c/Makefile   |   1 -
 drivers/i2c/sh_sh7734_i2c.c| 376 -
 3 files changed, 378 deletions(-)
 delete mode 100644 drivers/i2c/sh_sh7734_i2c.c

diff --git a/doc/driver-model/i2c-howto.txt b/doc/driver-model/i2c-howto.txt
index 1b2c5312c4..8ba2f6e267 100644
--- a/doc/driver-model/i2c-howto.txt
+++ b/doc/driver-model/i2c-howto.txt
@@ -14,7 +14,6 @@ ones remain:
ppc4xx_i2c
rcar_i2c
sh_i2c
-   sh_sh7734_i2c
soft_i2c
zynq_i2c
 
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index 795dd33c64..e32d65dc2f 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -9,7 +9,6 @@ obj-$(CONFIG_$(SPL_)I2C_CROS_EC_TUNNEL) += cros_ec_tunnel.o
 obj-$(CONFIG_$(SPL_)I2C_CROS_EC_LDO) += cros_ec_ldo.o
 
 obj-$(CONFIG_I2C_MV) += mv_i2c.o
-obj-$(CONFIG_SH_SH7734_I2C) += sh_sh7734_i2c.o
 obj-$(CONFIG_SYS_I2C) += i2c_core.o
 obj-$(CONFIG_SYS_I2C_ASPEED) += ast_i2c.o
 obj-$(CONFIG_SYS_I2C_AT91) += at91_i2c.o
diff --git a/drivers/i2c/sh_sh7734_i2c.c b/drivers/i2c/sh_sh7734_i2c.c
deleted file mode 100644
index 6fe356baca..00
--- a/drivers/i2c/sh_sh7734_i2c.c
+++ /dev/null
@@ -1,376 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright (C) 2012 Nobuhiro Iwamatsu <nobuhiro.iwamatsu...@renesas.com>
- * Copyright (C) 2012 Renesas Solutions Corp.
- *
- * NOTE: This driver should be converted to driver model before June 2017.
- * Please see doc/driver-model/i2c-howto.txt for instructions.
- */
-
-#include 
-#include 
-#include 
-
-struct sh_i2c {
-   u8 iccr1;
-   u8 iccr2;
-   u8 icmr;
-   u8 icier;
-   u8 icsr;
-   u8 sar;
-   u8 icdrt;
-   u8 icdrr;
-   u8 nf2cyc;
-   u8 __pad0;
-   u8 __pad1;
-};
-
-static struct sh_i2c *base;
-static u8 iccr1_cks, nf2cyc;
-
-/* ICCR1 */
-#define SH_I2C_ICCR1_ICE   (1 << 7)
-#define SH_I2C_ICCR1_RCVD  (1 << 6)
-#define SH_I2C_ICCR1_MST   (1 << 5)
-#define SH_I2C_ICCR1_TRS   (1 << 4)
-#define SH_I2C_ICCR1_MTRS  \
-   (SH_I2C_ICCR1_MST | SH_I2C_ICCR1_TRS)
-
-/* ICCR1 */
-#define SH_I2C_ICCR2_BBSY  (1 << 7)
-#define SH_I2C_ICCR2_SCP   (1 << 6)
-#define SH_I2C_ICCR2_SDAO  (1 << 5)
-#define SH_I2C_ICCR2_SDAOP (1 << 4)
-#define SH_I2C_ICCR2_SCLO  (1 << 3)
-#define SH_I2C_ICCR2_IICRST(1 << 1)
-
-#define SH_I2C_ICIER_TIE   (1 << 7)
-#define SH_I2C_ICIER_TEIE  (1 << 6)
-#define SH_I2C_ICIER_RIE   (1 << 5)
-#define SH_I2C_ICIER_NAKIE (1 << 4)
-#define SH_I2C_ICIER_STIE  (1 << 3)
-#define SH_I2C_ICIER_ACKE  (1 << 2)
-#define SH_I2C_ICIER_ACKBR (1 << 1)
-#define SH_I2C_ICIER_ACKBT (1 << 0)
-
-#define SH_I2C_ICSR_TDRE   (1 << 7)
-#define SH_I2C_ICSR_TEND   (1 << 6)
-#define SH_I2C_ICSR_RDRF   (1 << 5)
-#define SH_I2C_ICSR_NACKF  (1 << 4)
-#define SH_I2C_ICSR_STOP   (1 << 3)
-#define SH_I2C_ICSR_ALOVE  (1 << 2)
-#define SH_I2C_ICSR_AAS(1 << 1)
-#define SH_I2C_ICSR_ADZ(1 << 0)
-
-#define IRQ_WAIT 1000
-
-static void sh_i2c_send_stop(struct sh_i2c *base)
-{
-   clrbits_8(>iccr2, SH_I2C_ICCR2_BBSY | SH_I2C_ICCR2_SCP);
-}
-
-static int check_icsr_bits(struct sh_i2c *base, u8 bits)
-{
-   int i;
-
-   for (i = 0; i < IRQ_WAIT; i++) {
-   if (bits & readb(>icsr))
-   return 0;
-   udelay(10);
-   }
-
-   return 1;
-}
-
-static int check_stop(struct sh_i2c *base)
-{
-   int ret = check_icsr_bits(base, SH_I2C_ICSR_STOP);
-   clrbits_8(>icsr, SH_I2C_ICSR_STOP);
-
-   return ret;
-}
-
-static int check_tend(struct sh_i2c *base, int stop)
-{
-   int ret = check_icsr_bits(base, SH_I2C_ICSR_TEND);
-
-   if (stop) {
-   clrbits_8(>icsr, SH_I2C_ICSR_STOP);
-   sh_i2c_send_stop(base);
-   }
-
-   clrbits_8(>icsr, SH_I2C_ICSR_TEND);
-   return ret;
-}
-
-static int check_tdre(struct sh_i2c *base)
-{
-   return check_icsr_bits(base, SH_I2C_ICSR_TDRE);
-}
-
-static int check_rdrf(struct sh_i2c *base)
-{
-   return check_icsr_bits(base, SH_I2C_ICSR_RDRF);
-}
-
-static int check_bbsy(struct sh_i2c *base)
-{
-   int i;
-
-   for (i = 0 ; i < IRQ_WAIT ; i++) {
-   if (!(SH_I2C_ICCR2_BBSY & readb(>iccr2)))
-   return 0;
-   udelay(10);
-   }
-   return 1;
-}
-
-static int check_ackbr(struct sh_i2c *base)
-{
-   int i;
-
-   for (i = 0 ; i < IRQ_WAIT ; i++) {
-   if (!(SH_I2C_ICIER_ACKBR & readb(>icier)))
-

[U-Boot] [PATCH 2/3] i2c: Drop CONFIG_TSI108_I2C

2018-05-09 Thread Tuomas Tynkkynen
Last user of this driver went away in June 2015 in commit
d928664f4101e24 ("powerpc: 74xx_7xx: remove 74xx_7xx cpu support")

Signed-off-by: Tuomas Tynkkynen <tuo...@tuxera.com>
---
 doc/driver-model/i2c-howto.txt |   1 -
 drivers/i2c/Makefile   |   1 -
 drivers/i2c/tsi108_i2c.c   | 275 -
 include/tsi108.h   | 207 ---
 4 files changed, 484 deletions(-)
 delete mode 100644 drivers/i2c/tsi108_i2c.c
 delete mode 100644 include/tsi108.h

diff --git a/doc/driver-model/i2c-howto.txt b/doc/driver-model/i2c-howto.txt
index 605d3ef7ad..1b2c5312c4 100644
--- a/doc/driver-model/i2c-howto.txt
+++ b/doc/driver-model/i2c-howto.txt
@@ -16,7 +16,6 @@ ones remain:
sh_i2c
sh_sh7734_i2c
soft_i2c
-   tsi108_i2c
zynq_i2c
 
 The deadline for this work is the end of June 2017. If no one steps
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index e8bb6327fb..795dd33c64 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -9,7 +9,6 @@ obj-$(CONFIG_$(SPL_)I2C_CROS_EC_TUNNEL) += cros_ec_tunnel.o
 obj-$(CONFIG_$(SPL_)I2C_CROS_EC_LDO) += cros_ec_ldo.o
 
 obj-$(CONFIG_I2C_MV) += mv_i2c.o
-obj-$(CONFIG_TSI108_I2C) += tsi108_i2c.o
 obj-$(CONFIG_SH_SH7734_I2C) += sh_sh7734_i2c.o
 obj-$(CONFIG_SYS_I2C) += i2c_core.o
 obj-$(CONFIG_SYS_I2C_ASPEED) += ast_i2c.o
diff --git a/drivers/i2c/tsi108_i2c.c b/drivers/i2c/tsi108_i2c.c
deleted file mode 100644
index 208c0900ef..00
--- a/drivers/i2c/tsi108_i2c.c
+++ /dev/null
@@ -1,275 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * (C) Copyright 2004 Tundra Semiconductor Corp.
- * Author: Alex Bounine
- *
- * NOTE: This driver should be converted to driver model before June 2017.
- * Please see doc/driver-model/i2c-howto.txt for instructions.
- */
-
-#include 
-#include 
-
-#include 
-
-#if defined(CONFIG_CMD_I2C)
-
-#define I2C_DELAY  10
-#undef  DEBUG_I2C
-
-#ifdef DEBUG_I2C
-#define DPRINT(x) printf (x)
-#else
-#define DPRINT(x)
-#endif
-
-/* All functions assume that Tsi108 I2C block is the only master on the bus */
-/* I2C read helper function */
-
-void i2c_init(int speed, int slaveaddr)
-{
-   /*
-* The TSI108 has a fixed I2C clock rate and doesn't support slave
-* operation.  This function only exists as a stub to fit into the
-* U-Boot I2C API.
-*/
-}
-
-static int i2c_read_byte (
-   uint i2c_chan,  /* I2C channel number: 0 - main, 1 - SDC SPD */
-   uchar chip_addr,/* I2C device address on the bus */
-   uint byte_addr, /* Byte address within I2C device */
-   uchar * buffer  /* pointer to data buffer */
-   )
-{
-   u32 temp;
-   u32 to_count = I2C_DELAY;
-   u32 op_status = TSI108_I2C_TIMEOUT_ERR;
-   u32 chan_offset = TSI108_I2C_OFFSET;
-
-   DPRINT (("I2C read_byte() %d 0x%02x 0x%02x\n",
-   i2c_chan, chip_addr, byte_addr));
-
-   if (0 != i2c_chan)
-   chan_offset = TSI108_I2C_SDRAM_OFFSET;
-
-   /* Check if I2C operation is in progress */
-   temp = *(u32 *) (CONFIG_SYS_TSI108_CSR_BASE + chan_offset + I2C_CNTRL2);
-
-   if (0 == (temp & (I2C_CNTRL2_RD_STATUS | I2C_CNTRL2_WR_STATUS |
- I2C_CNTRL2_START))) {
-   /* Set device address and operation (read = 0) */
-   temp = (byte_addr << 16) | ((chip_addr & 0x07) << 8) |
-   ((chip_addr >> 3) & 0x0F);
-   *(u32 *) (CONFIG_SYS_TSI108_CSR_BASE + chan_offset + 
I2C_CNTRL1) =
-   temp;
-
-   /* Issue the read command
-* (at this moment all other parameters are 0
-* (size = 1 byte, lane = 0)
-*/
-
-   *(u32 *) (CONFIG_SYS_TSI108_CSR_BASE + chan_offset + 
I2C_CNTRL2) =
-   (I2C_CNTRL2_START);
-
-   /* Wait until operation completed */
-   do {
-   /* Read I2C operation status */
-   temp = *(u32 *) (CONFIG_SYS_TSI108_CSR_BASE + 
chan_offset + I2C_CNTRL2);
-
-   if (0 == (temp & (I2C_CNTRL2_RD_STATUS | 
I2C_CNTRL2_START))) {
-   if (0 == (temp &
-(I2C_CNTRL2_I2C_CFGERR |
- I2C_CNTRL2_I2C_TO_ERR))
-   ) {
-   op_status = TSI108_I2C_SUCCESS;
-
-   temp = *(u32 *) 
(CONFIG_SYS_TSI108_CSR_BASE +
-chan_offset +
-I2C_RD_DATA);
-
-   *buffer = (u8) (temp & 0xFF);
-   } else {
-   /* report HW error */
-  

Re: [U-Boot] [PATCH 3/3] ARM: rmobile: Contain CONFIG_ARCH_RMOBILE_BOARD_STRING

2018-05-05 Thread Tuomas Tynkkynen
On Wed,  2 May 2018 11:57:41 +0200
Marek Vasut  wrote:

> Pull the symbol from the boards and zap struct rmobile_sysinfo as they
> are rather useless. The entire purpose of that whole machinery was to
> print board name in the CONFIG_ARCH_RMOBILE_BOARD_STRING. Do that in a
> far simpler and more contained manner.
> 

Note that if your SoC/board supports DT, common/board_info.c comes with 
a common implementation for printing out the "model" property from DT,
allowing further zapping of such code. 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] rpi: Adjust fdt_addr_r to a sane address

2018-04-22 Thread Tuomas Tynkkynen
On Fri, 20 Apr 2018 13:03:47 +0300
Tuomas Tynkkynen <tuo...@tuxera.com> wrote:

> Hi Alexander,
> 
> What do you think of these patches? I haven't done testing with the
> big kernels / DTBs yet, just that my previously-working kernel still
> boots.
> 

I've now verified that these two patches work as expected. I tested:

- RPi 1 running mainline kernel
- RPi 1 running downstream kernel
- RPi 3 running mainline kernel in 64-bit mode
- RPi 3 running mainline kernel in 32-bit mode
- RPi 3 running downstream kernel in 32-bit mode
- RPi 3B+ running downstream kernel in 32-bit mode

This was with the extlinux.conf distro boot. I don't know to what
extent these variables affect EFI boot.

> Tuomas Tynkkynen (2):
>   rpi: Fix fdt_high & initrd_high for 64-bit builds
>   rpi: Change load addresses to make more room for the kernel & DTB
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 2/2] rpi: Change load addresses to make more room for the kernel & DTB

2018-04-20 Thread Tuomas Tynkkynen
As of Linux 4.16, a multiplatform AArch64 kernel with our distro config
takes 26M. The current space reservation leaves only 17M for the kernel
and if it goes over it, the initrd gets overwritten when loading the
kernel from the filesystem.

A similar problem happens on ARMv7 with the DTBs taken from the
downstream Raspberry Pi foundation kernel. I guess they compile them
with DT overlay support enabled which grows them just enough.

Fix both of these problems by rewriting the memory map, which now allows
kernels to be up to 36M and DTBs up to 1M. Also the comment block was
kind of obsolete ever since the introduction of AArch64 support and the
firmware-loaded DTB doesn't get placed at 0x100 anymore either, so that
is fixed as well.

Signed-off-by: Tuomas Tynkkynen <tuo...@tuxera.com>
---
 include/configs/rpi.h | 61 ++-
 1 file changed, 36 insertions(+), 25 deletions(-)

diff --git a/include/configs/rpi.h b/include/configs/rpi.h
index f1189a27f3..425c0c2e6d 100644
--- a/include/configs/rpi.h
+++ b/include/configs/rpi.h
@@ -104,39 +104,50 @@
  *
  * I suspect address 0 is used as the SMP pen on the RPi2, so avoid this.
  *
- * fdt_addr_r simply shouldn't overlap anything else. However, the RPi's
- *   binary firmware loads a DT to address 0x100, so we choose this address to
- *   match it. This allows custom boot scripts to pass this DT on to Linux
- *   simply by not over-writing the data at this address. When using U-Boot,
- *   U-Boot (and scripts it executes) typicaly ignore the DT loaded by the FW
- *   and loads its own DT from disk (triggered by boot.scr or extlinux.conf).
+ * Older versions of the boot firmware place the firmware-loaded DTB at 0x100,
+ * newer versions place it in high memory. So prevent U-Boot from doing its own
+ * DTB + initrd relocation so that we won't accidentally relocate the initrd
+ * over the firmware-loaded DTB and generally try to lay out things starting
+ * from the bottom of RAM.
  *
- * pxefile_addr_r can be pretty much anywhere that doesn't conflict with
- *   something else. Put it low in memory to avoid conflicts.
+ * kernel_addr_r has different constraints on ARM and Aarch64.  For 32-bit ARM,
+ * it must be within the first 128M of RAM in order for the kernel's
+ * CONFIG_AUTO_ZRELADDR option to work. The kernel itself will be decompressed
+ * to 0x8000 but the decompressor clobbers 0x4000-0x8000 as well. The
+ * decompressor also likes to relocate itself to right past the end of the
+ * decompressed kernel, so in total the sum of the compressed and and
+ * decompressed kernel needs to be reserved.
  *
- * kernel_addr_r must be within the first 128M of RAM in order for the
- *   kernel's CONFIG_AUTO_ZRELADDR option to work. Since the kernel will
- *   decompress itself to 0x8000 after the start of RAM, kernel_addr_r
- *   should not overlap that area, or the kernel will have to copy itself
- *   somewhere else before decompression. Similarly, the address of any other
- *   data passed to the kernel shouldn't overlap the start of RAM. Pushing
- *   this up to 16M allows for a sizable kernel to be decompressed below the
- *   compressed load address.
+ *   For Aarch64, the kernel image is uncompressed and must be loaded at
+ *   text_offset bytes (specified in the header of the Image) into a 2MB
+ *   boundary. The 'booti' command relocates the image if necessary. Linux uses
+ *   a default text_offset of 0x8.  In summary, loading at 0x8
+ *   satisfies all these constraints and reserving memory up to 0x0240
+ *   permits fairly large (roughly 36M) kernels.
  *
- * scriptaddr can be pretty much anywhere that doesn't conflict with something
- *   else. Choosing 32M allows for the compressed kernel to be up to 16M.
+ * scriptaddr and pxefile_addr_r can be pretty much anywhere that doesn't
+ * conflict with something else. Reserving 1M for each of them at
+ * 0x0240-0x0250 and 0x0250-0x0260 should be plenty.
  *
- * ramdisk_addr_r simply shouldn't overlap anything else. Choosing 33M allows
- *   for any boot script to be up to 1M, which is hopefully plenty.
+ * On ARM, both the DTB and any possible initrd must be loaded such that they
+ * fit inside the lowmem mapping in Linux. In practice, this usually means not
+ * more than ~700M away from the start of the kernel image but this number can
+ * be larger OR smaller depending on e.g. the 'vmalloc=xxxM' command line
+ * parameter given to the kernel. So reserving memory from low to high
+ * satisfies this constraint again. Reserving 1M at 0x0260-0x0270 for
+ * the DTB leaves rest of the free RAM to the initrd starting at 0x0270.
+ * Even with the smallest possible CPU-GPU memory split of the CPU getting
+ * only 64M, the remaining 25M starting at 0x0270 should allow quite
+ * large initrds before they start colliding with U-Boot.
  */
 #define ENV_MEM_LAYOUT_SETTINGS \
"fdt_high=" FDT_HIGH "\0&qu

[U-Boot] [PATCH 1/2] rpi: Fix fdt_high & initrd_high for 64-bit builds

2018-04-20 Thread Tuomas Tynkkynen
The magic value that disables relocation is dependent on the CPU word
size, so the current '' is doing the wrong thing on aarch64.

Signed-off-by: Tuomas Tynkkynen <tuo...@tuxera.com>
---
 include/configs/rpi.h | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/include/configs/rpi.h b/include/configs/rpi.h
index 325e52a019..f1189a27f3 100644
--- a/include/configs/rpi.h
+++ b/include/configs/rpi.h
@@ -91,6 +91,14 @@
"stdout=serial,vidconsole\0" \
"stderr=serial,vidconsole\0"
 
+#ifdef CONFIG_ARM64
+#define FDT_HIGH ""
+#define INITRD_HIGH ""
+#else
+#define FDT_HIGH ""
+#define INITRD_HIGH ""
+#endif
+
 /*
  * Memory layout for where various images get loaded by boot scripts:
  *
@@ -122,8 +130,8 @@
  *   for any boot script to be up to 1M, which is hopefully plenty.
  */
 #define ENV_MEM_LAYOUT_SETTINGS \
-   "fdt_high=\0" \
-   "initrd_high=\0" \
+   "fdt_high=" FDT_HIGH "\0" \
+   "initrd_high=" INITRD_HIGH "\0" \
"fdt_addr_r=0x0100\0" \
"pxefile_addr_r=0x0010\0" \
"kernel_addr_r=0x0100\0" \
-- 
2.16.3

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


Re: [U-Boot] [PATCH] rpi: Adjust fdt_addr_r to a sane address

2018-04-20 Thread Tuomas Tynkkynen
Hi Alexander,

What do you think of these patches? I haven't done testing with the
big kernels / DTBs yet, just that my previously-working kernel still
boots.

Tuomas Tynkkynen (2):
  rpi: Fix fdt_high & initrd_high for 64-bit builds
  rpi: Change load addresses to make more room for the kernel & DTB

 include/configs/rpi.h | 73 ---
 1 file changed, 46 insertions(+), 27 deletions(-)

-- 
2.16.3

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


Re: [U-Boot] [PATCH] rpi: Adjust fdt_addr_r to a sane address

2018-04-14 Thread Tuomas Tynkkynen
Hi Alexander,

On Fri, 13 Apr 2018 17:49:00 +0200
Alexander Graf  wrote:

[...]
> 
> diff --git a/include/configs/rpi.h b/include/configs/rpi.h
> index 325e52a019..fcf7e0976b 100644
> --- a/include/configs/rpi.h
> +++ b/include/configs/rpi.h
> @@ -124,7 +124,7 @@
>  #define ENV_MEM_LAYOUT_SETTINGS \
>   "fdt_high=\0" \
>   "initrd_high=\0" \
> - "fdt_addr_r=0x0100\0" \
> + "fdt_addr_r=0x01f0\0" \
>   "pxefile_addr_r=0x0010\0" \
>   "kernel_addr_r=0x0100\0" \
>   "scriptaddr=0x0200\0" \

Note that above the #define is a larger comment block that needs to be
updated as well. Also the other addresses also need updatingfor bigger
kernels on AArch64: https://patchwork.ozlabs.org/patch/25/

Though now I double-checked that the smallest possible GPU-CPU memory
split is actually 64MB for the CPU, not 128M. So maybe something like:

 "kernel_addr_r=0x0008\0" \
 "fdt_addr_r=0x0240\0" \
 "scriptaddr=0x0250\0" \
 "pxefile_addr_r=0x0260\0" \
 "ramdisk_addr_r=0x0270\0"

which would allow a kernel up to 36M, 1M for dtb, script and pxe files
each, and at least 25M for the initrd. Also I think giving up with the
constraint of locating the zImage high enough so that the kernel
decompressor doesn't need to relocate itself can be dropped. If the
boot speed of their Raspi matters that much, probably they wouldn't use
U-Boot in the first place.

What is the address that the RPi firmware loads its device tree to? I
hope that we don't have to worry about the positioning of that too...

- Tuomas

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


Re: [U-Boot] [RFC PATCH 03/13] arm: move SYS_ARCH_TIMER to KConfig

2018-04-11 Thread Tuomas Tynkkynen
Hi,

On Thu, 30 Nov 2017 01:25:01 +
Andre Przywara  wrote:

> SYS_ARCH_TIMER guards the usage of the ARM Generic Timer (aka arch
> timer) in U-Boot.
> At the moment it is mandatory for ARMv8 and used by two ARMv7 boards.
> Add a proper Kconfig symbol to express this dependency properly,
> allowing certain board configuration to later disable arch timer in case
> there are any problems with it.
> 
> Signed-off-by: Andre Przywara 

I was doing some SYS_ARCH_TIMER related cleanup to qemu-arm, so I took
the opportunity to test + send a rebased + resynced version of this patch
at the same time. Hope that it doesn't conflict or cause any problems
with upgrading this Nexell patchset.

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


[U-Boot] [PATCH 2/2] arm: move SYS_ARCH_TIMER to KConfig

2018-04-11 Thread Tuomas Tynkkynen
From: Andre Przywara <andre.przyw...@arm.com>

SYS_ARCH_TIMER guards the usage of the ARM Generic Timer (aka arch
timer) in U-Boot.
At the moment it is mandatory for ARMv8 and used by a few ARMv7 boards.
Add a proper Kconfig symbol to express this dependency properly,
allowing certain board configuration to later disable arch timer in case
there are any problems with it.

Signed-off-by: Andre Przywara <andre.przyw...@arm.com>
[tuomas: rebase + fix conflicts and resync with moveconfig & use select]
Signed-off-by: Tuomas Tynkkynen <tuomas.tynkky...@iki.fi>
---
 arch/arm/Kconfig | 11 +++
 arch/arm/cpu/armv8/Makefile  |  2 +-
 arch/arm/mach-imx/mx7ulp/Kconfig |  1 +
 arch/arm/mach-qemu/Kconfig   |  1 +
 arch/arm/mach-stm32mp/Kconfig|  1 +
 include/configs/mx7ulp_evk.h |  1 -
 include/configs/qemu-arm.h   |  1 -
 include/configs/stm32mp1.h   |  1 -
 include/configs/ti_armv7_keystone2.h |  1 -
 scripts/config_whitelist.txt |  1 -
 10 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 190f883aa8..421210ed46 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -242,6 +242,16 @@ config SYS_CACHELINE_SIZE
default 64 if SYS_CACHE_SHIFT_6
default 32 if SYS_CACHE_SHIFT_5
 
+config SYS_ARCH_TIMER
+   bool "ARM Generic Timer support"
+   depends on CPU_V7 || ARM64
+   default y if ARM64
+   help
+ The ARM Generic Timer (aka arch-timer) provides an architected
+ interface to a timer source on an SoC.
+ It is mandantory for ARMv8 implementation and widely available
+ on ARMv7 systems.
+
 config ARM_SMCCC
bool "Support for ARM SMC Calling Convention (SMCCC)"
depends on CPU_V7 || ARM64
@@ -583,6 +593,7 @@ config ARCH_KEYSTONE
select SUPPORT_SPL
select SYS_THUMB_BUILD
select CMD_POWEROFF
+   select SYS_ARCH_TIMER
imply CMD_MTDPARTS
imply FIT
imply CMD_SAVES
diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile
index 1249547436..d18b38eb9e 100644
--- a/arch/arm/cpu/armv8/Makefile
+++ b/arch/arm/cpu/armv8/Makefile
@@ -9,7 +9,7 @@ extra-y := start.o
 
 obj-y  += cpu.o
 ifndef CONFIG_$(SPL_TPL_)TIMER
-obj-y  += generic_timer.o
+obj-$(CONFIG_SYS_ARCH_TIMER) += generic_timer.o
 endif
 obj-y  += cache_v8.o
 obj-y  += exceptions.o
diff --git a/arch/arm/mach-imx/mx7ulp/Kconfig b/arch/arm/mach-imx/mx7ulp/Kconfig
index 1bdc85a9a0..d4b0299dbd 100644
--- a/arch/arm/mach-imx/mx7ulp/Kconfig
+++ b/arch/arm/mach-imx/mx7ulp/Kconfig
@@ -9,6 +9,7 @@ choice
 
 config TARGET_MX7ULP_EVK
 bool "Support mx7ulp EVK board"
+   select SYS_ARCH_TIMER
 
 endchoice
 
diff --git a/arch/arm/mach-qemu/Kconfig b/arch/arm/mach-qemu/Kconfig
index 133163aecf..226dfa362f 100644
--- a/arch/arm/mach-qemu/Kconfig
+++ b/arch/arm/mach-qemu/Kconfig
@@ -16,6 +16,7 @@ config TARGET_QEMU_ARM_32BIT
depends on ARCH_QEMU
select CPU_V7
select ARCH_SUPPORT_PSCI
+   select SYS_ARCH_TIMER
 
 config TARGET_QEMU_ARM_64BIT
bool "Support qemu_arm64"
diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig
index 8ca97bf0c9..4d59480c19 100644
--- a/arch/arm/mach-stm32mp/Kconfig
+++ b/arch/arm/mach-stm32mp/Kconfig
@@ -27,6 +27,7 @@ config TARGET_STM32MP1
select CPU_V7
select PINCTRL_STM32
select STM32_RESET
+   select SYS_ARCH_TIMER
select SYSRESET_SYSCON
help
target STMicroelectronics SOC STM32MP1 family
diff --git a/include/configs/mx7ulp_evk.h b/include/configs/mx7ulp_evk.h
index c2223bd858..3dcda9ea77 100644
--- a/include/configs/mx7ulp_evk.h
+++ b/include/configs/mx7ulp_evk.h
@@ -46,7 +46,6 @@
 /* Using ULP WDOG for reset */
 #define WDOG_BASE_ADDR WDG1_RBASE
 
-#define CONFIG_SYS_ARCH_TIMER
 #define CONFIG_SYS_HZ_CLOCK100 /* Fixed at 1Mhz from TSTMR */
 
 #define CONFIG_INITRD_TAG
diff --git a/include/configs/qemu-arm.h b/include/configs/qemu-arm.h
index b29a54ef89..f306b41635 100644
--- a/include/configs/qemu-arm.h
+++ b/include/configs/qemu-arm.h
@@ -20,7 +20,6 @@
 #define CONFIG_SYS_MALLOC_LEN  SZ_16M
 
 /* For timer, QEMU emulates an ARMv7/ARMv8 architected timer */
-#define CONFIG_SYS_ARCH_TIMER
 #define CONFIG_SYS_HZ   1000
 
 /* For block devices, QEMU emulates an ICH9 AHCI controller over PCI */
diff --git a/include/configs/stm32mp1.h b/include/configs/stm32mp1.h
index da0e259736..b2b654ca7a 100644
--- a/include/configs/stm32mp1.h
+++ b/include/configs/stm32mp1.h
@@ -17,7 +17,6 @@
  * Number of clock ticks in 1 sec
  */
 #define CONFIG_SYS_HZ  1000
-#define CONFIG_SYS_ARCH_TIMER
 
 /*
  * malloc() pool size
diff --git a/include/configs/ti_armv7_keystone2.h 
b/include/configs/ti_armv7_keystone2.h
index e87acca650..6f2a

[U-Boot] [PATCH 1/2] ARM: qemu-arm: Dynamically determine timer frequency

2018-04-11 Thread Tuomas Tynkkynen
After commit 46fc679ede5f69 ("arm: timer: get frequency for arch timer
armv7 in cp15 cntfrq") the ARM architected timer driver knows how to
determine the timer frequency at runtime by reading the CNTFRQ register,
so we don't need to hardcode the timer frequency anymore.

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkky...@iki.fi>
---
 include/configs/qemu-arm.h | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/include/configs/qemu-arm.h b/include/configs/qemu-arm.h
index 839bc10a18..b29a54ef89 100644
--- a/include/configs/qemu-arm.h
+++ b/include/configs/qemu-arm.h
@@ -19,11 +19,9 @@
 #define CONFIG_SYS_LOAD_ADDR   (CONFIG_SYS_SDRAM_BASE + SZ_2M)
 #define CONFIG_SYS_MALLOC_LEN  SZ_16M
 
-/* QEMU implements a 62.5MHz architected timer */
-/* FIXME: can we rely on CNTFREQ instead of hardcoding this fact here? */
+/* For timer, QEMU emulates an ARMv7/ARMv8 architected timer */
 #define CONFIG_SYS_ARCH_TIMER
 #define CONFIG_SYS_HZ   1000
-#define CONFIG_SYS_HZ_CLOCK 6250
 
 /* For block devices, QEMU emulates an ICH9 AHCI controller over PCI */
 #define CONFIG_SYS_SCSI_MAX_SCSI_ID 6
-- 
2.16.3

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


[U-Boot] [PATCH 2/2] serial: Migrate CONFIG_FSL_LINFLEXUART to Kconfig

2018-04-08 Thread Tuomas Tynkkynen
Signed-off-by: Tuomas Tynkkynen <tuo...@tuxera.com>
---
 configs/s32v234evb_defconfig| 1 +
 drivers/serial/Kconfig  | 7 +++
 drivers/serial/serial_linflexuart.c | 4 
 include/configs/s32v234evb.h| 1 -
 scripts/config_whitelist.txt| 1 -
 5 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/configs/s32v234evb_defconfig b/configs/s32v234evb_defconfig
index 5d98d15324..77e6faf146 100644
--- a/configs/s32v234evb_defconfig
+++ b/configs/s32v234evb_defconfig
@@ -10,4 +10,5 @@ CONFIG_CMD_BOOTZ=y
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_DM=y
 CONFIG_DM_SERIAL=y
+CONFIG_FSL_LINFLEXUART=y
 CONFIG_OF_LIBFDT=y
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 975e6d3d58..c32e46a0f8 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -466,6 +466,13 @@ config BCM6345_SERIAL
help
  Select this to enable UART on BCM6345 SoCs.
 
+config FSL_LINFLEXUART
+   bool "Freescale Linflex UART support"
+   depends on DM_SERIAL
+   help
+ Select this to enable the Linflex serial module found on some
+ NXP SoCs like S32V234.
+
 config FSL_LPUART
bool "Freescale LPUART support"
help
diff --git a/drivers/serial/serial_linflexuart.c 
b/drivers/serial/serial_linflexuart.c
index fbb39592d6..b706fdb398 100644
--- a/drivers/serial/serial_linflexuart.c
+++ b/drivers/serial/serial_linflexuart.c
@@ -35,10 +35,6 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-#ifndef CONFIG_DM_SERIAL
-#error "The linflex serial driver does not have non-DM support."
-#endif
-
 static void _linflex_serial_setbrg(struct linflex_fsl *base, int baudrate)
 {
u32 clk = mxc_get_clock(MXC_UART_CLK);
diff --git a/include/configs/s32v234evb.h b/include/configs/s32v234evb.h
index e5265a7362..7aa1e88a27 100644
--- a/include/configs/s32v234evb.h
+++ b/include/configs/s32v234evb.h
@@ -57,7 +57,6 @@
 #define CONFIG_SYS_MALLOC_LEN  (CONFIG_ENV_SIZE + 2 * 1024 * 1024)
 #endif
 
-#define CONFIG_FSL_LINFLEXUART
 #define LINFLEXUART_BASE   LINFLEXD0_BASE_ADDR
 
 #define CONFIG_DEBUG_UART_LINFLEXUART
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index 843e98124f..a281c12e17 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -680,7 +680,6 @@ CONFIG_FSL_IIM
 CONFIG_FSL_ISBC_KEY_EXT
 CONFIG_FSL_LAYERSCAPE
 CONFIG_FSL_LBC
-CONFIG_FSL_LINFLEXUART
 CONFIG_FSL_MC9SDZ60
 CONFIG_FSL_MEMAC
 CONFIG_FSL_NGPIXIS
-- 
2.16.3

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


[U-Boot] [PATCH 1/2] ARM: s32v234evb: Set CONFIG_DM & CONFIG_DM_SERIAL in Kconfig

2018-04-08 Thread Tuomas Tynkkynen
These symbols are declared in Kconfig, so it's wrong to set them in
header files.

Note that this is not size-neutral - some 'default y' options will now
get turned on by Kconfig, such as CONFIG_CMD_DM=y and CONFIG_DM_STDIO=y.

Signed-off-by: Tuomas Tynkkynen <tuo...@tuxera.com>
---
 configs/s32v234evb_defconfig | 3 ++-
 include/configs/s32v234evb.h | 2 --
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/configs/s32v234evb_defconfig b/configs/s32v234evb_defconfig
index a28d24ce0b..5d98d15324 100644
--- a/configs/s32v234evb_defconfig
+++ b/configs/s32v234evb_defconfig
@@ -2,11 +2,12 @@ CONFIG_ARM=y
 CONFIG_TARGET_S32V234EVB=y
 CONFIG_SYS_TEXT_BASE=0x3E80
 CONFIG_DISTRO_DEFAULTS=y
-CONFIG_SYS_MALLOC_F=y
 CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/s32v234evb/s32v234evb.cfg"
 CONFIG_USE_BOOTARGS=y
 CONFIG_BOOTARGS="console=ttyLF0 root=/dev/ram rw"
 CONFIG_BOARD_EARLY_INIT_F=y
 CONFIG_CMD_BOOTZ=y
 CONFIG_ENV_IS_IN_MMC=y
+CONFIG_DM=y
+CONFIG_DM_SERIAL=y
 CONFIG_OF_LIBFDT=y
diff --git a/include/configs/s32v234evb.h b/include/configs/s32v234evb.h
index 4dc098b828..e5265a7362 100644
--- a/include/configs/s32v234evb.h
+++ b/include/configs/s32v234evb.h
@@ -12,7 +12,6 @@
 #include 
 
 #define CONFIG_S32V234
-#define CONFIG_DM
 
 /* Config GIC */
 #define CONFIG_GICV2
@@ -58,7 +57,6 @@
 #define CONFIG_SYS_MALLOC_LEN  (CONFIG_ENV_SIZE + 2 * 1024 * 1024)
 #endif
 
-#define CONFIG_DM_SERIAL
 #define CONFIG_FSL_LINFLEXUART
 #define LINFLEXUART_BASE   LINFLEXD0_BASE_ADDR
 
-- 
2.16.3

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


[U-Boot] [PATCH 3/3] serial: Migrate CONFIG_ARM_DCC to Kconfig

2018-04-07 Thread Tuomas Tynkkynen
Signed-off-by: Tuomas Tynkkynen <tuo...@tuxera.com>
---
 arch/arm/Kconfig| 2 ++
 drivers/serial/Kconfig  | 5 +
 include/configs/xilinx_zynqmp.h | 1 -
 include/configs/zynq-common.h   | 2 --
 scripts/config_whitelist.txt| 1 -
 5 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 190f883aa8..44a4471b47 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -776,6 +776,7 @@ config ARCH_ZYNQ
select CLK
select SPL_CLK if SPL
select CLK_ZYNQ
+   imply ARM_DCC
imply CMD_CLK
imply FAT_WRITE
imply CMD_SPL
@@ -792,6 +793,7 @@ config ARCH_ZYNQMP
select SPL_BOARD_INIT if SPL
select SPL_CLK if SPL
select DM_USB if USB
+   imply ARM_DCC
imply FAT_WRITE
 
 config TEGRA
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 9387b642b3..41ce6dec8c 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -432,6 +432,11 @@ config AR933X_UART
  tree binding to operate, please refer to the document at
  doc/device-tree-bindings/serial/qca,ar9330-uart.txt.
 
+config ARM_DCC
+   bool "ARM DCC (Debug Communications Channel) serial console support"
+   help
+ Select this to enable a serial port using the ARM JTAG DCC port.
+
 config ATMEL_USART
bool "Atmel USART support"
help
diff --git a/include/configs/xilinx_zynqmp.h b/include/configs/xilinx_zynqmp.h
index 8c0b5d9c06..312a2a83ff 100644
--- a/include/configs/xilinx_zynqmp.h
+++ b/include/configs/xilinx_zynqmp.h
@@ -42,7 +42,6 @@
 #define CONFIG_SYS_MALLOC_LEN  (CONFIG_ENV_SIZE + 0x200)
 
 /* Serial setup */
-#define CONFIG_ARM_DCC
 #define CONFIG_CPU_ARMV8
 
 #define CONFIG_SYS_BAUDRATE_TABLE \
diff --git a/include/configs/zynq-common.h b/include/configs/zynq-common.h
index 554fb66634..699c91d3c5 100644
--- a/include/configs/zynq-common.h
+++ b/include/configs/zynq-common.h
@@ -32,8 +32,6 @@
 #define CONFIG_SYS_BAUDRATE_TABLE  \
{300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200, 230400}
 
-#define CONFIG_ARM_DCC
-
 /* Ethernet driver */
 #if defined(CONFIG_ZYNQ_GEM)
 # define CONFIG_MII
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index 30da0122f0..417a978f0a 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -59,7 +59,6 @@ CONFIG_ARMV7_SECURE_MAX_SIZE
 CONFIG_ARMV7_SECURE_RESERVE_SIZE
 CONFIG_ARMV8_SWITCH_TO_EL1
 CONFIG_ARM_ARCH_CP15_ERRATA
-CONFIG_ARM_DCC
 CONFIG_ARM_FREQ
 CONFIG_ARM_GIC_BASE_ADDRESS
 CONFIG_ARM_PL180_MMCI_BASE
-- 
2.16.3

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


[U-Boot] [PATCH 2/3] serial: Migrate CONFIG_MCFUART

2018-04-07 Thread Tuomas Tynkkynen
Signed-off-by: Tuomas Tynkkynen <tuo...@tuxera.com>
---
 arch/Kconfig | 1 +
 drivers/serial/Kconfig   | 5 +
 include/configs/M5208EVBE.h  | 1 -
 include/configs/M52277EVB.h  | 1 -
 include/configs/M5235EVB.h   | 1 -
 include/configs/M5249EVB.h   | 1 -
 include/configs/M5253DEMO.h  | 1 -
 include/configs/M5253EVBE.h  | 1 -
 include/configs/M5272C3.h| 1 -
 include/configs/M5275EVB.h   | 1 -
 include/configs/M5282EVB.h   | 1 -
 include/configs/M53017EVB.h  | 1 -
 include/configs/M5329EVB.h   | 1 -
 include/configs/M5373EVB.h   | 1 -
 include/configs/M54418TWR.h  | 1 -
 include/configs/M54451EVB.h  | 1 -
 include/configs/M54455EVB.h  | 1 -
 include/configs/M5475EVB.h   | 1 -
 include/configs/M5485EVB.h   | 1 -
 include/configs/amcore.h | 1 -
 include/configs/astro_mcf5373l.h | 1 -
 include/configs/cobra5272.h  | 1 -
 include/configs/eb_cpu5282.h | 1 -
 include/configs/stmark2.h| 1 -
 scripts/config_whitelist.txt | 1 -
 25 files changed, 6 insertions(+), 23 deletions(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index e599e7a39c..c9310406c7 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -28,6 +28,7 @@ config M68K
select HAVE_PRIVATE_LIBGCC
select SYS_BOOT_GET_CMDLINE
select SYS_BOOT_GET_KBD
+   imply MCFUART
 
 config MICROBLAZE
bool "MicroBlaze architecture"
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 0a01399961..9387b642b3 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -467,6 +467,11 @@ config FSL_LPUART
  Select this to enable a Low Power UART for Freescale VF610 and
  QorIQ Layerscape devices.
 
+config MCFUART
+   bool "ColdFire UART support"
+   help
+ Select this to enable UART support on some ColdFire m68k SoCs.
+
 config MVEBU_A3700_UART
bool "UART support for Armada 3700"
default n
diff --git a/include/configs/M5208EVBE.h b/include/configs/M5208EVBE.h
index 3385dcb5b7..d7d21b5708 100644
--- a/include/configs/M5208EVBE.h
+++ b/include/configs/M5208EVBE.h
@@ -14,7 +14,6 @@
  * High Level Configuration Options
  * (easy to change)
  */
-#define CONFIG_MCFUART
 #define CONFIG_SYS_UART_PORT   (0)
 
 #undef CONFIG_WATCHDOG
diff --git a/include/configs/M52277EVB.h b/include/configs/M52277EVB.h
index 7798b06625..16005f7ef5 100644
--- a/include/configs/M52277EVB.h
+++ b/include/configs/M52277EVB.h
@@ -19,7 +19,6 @@
  * (easy to change)
  */
 
-#define CONFIG_MCFUART
 #define CONFIG_SYS_UART_PORT   (0)
 
 #undef CONFIG_WATCHDOG
diff --git a/include/configs/M5235EVB.h b/include/configs/M5235EVB.h
index d221f718f0..3600418907 100644
--- a/include/configs/M5235EVB.h
+++ b/include/configs/M5235EVB.h
@@ -19,7 +19,6 @@
  * (easy to change)
  */
 
-#define CONFIG_MCFUART
 #define CONFIG_SYS_UART_PORT   (0)
 
 #undef CONFIG_WATCHDOG
diff --git a/include/configs/M5249EVB.h b/include/configs/M5249EVB.h
index 6b37e46c56..fa78918197 100644
--- a/include/configs/M5249EVB.h
+++ b/include/configs/M5249EVB.h
@@ -20,7 +20,6 @@
  */
 #define CONFIG_MCFTMR
 
-#define CONFIG_MCFUART
 #define CONFIG_SYS_UART_PORT   (0)
 
 #undef  CONFIG_WATCHDOG
diff --git a/include/configs/M5253DEMO.h b/include/configs/M5253DEMO.h
index cf10f306c7..7b21e68dd1 100644
--- a/include/configs/M5253DEMO.h
+++ b/include/configs/M5253DEMO.h
@@ -9,7 +9,6 @@
 
 #define CONFIG_MCFTMR
 
-#define CONFIG_MCFUART
 #define CONFIG_SYS_UART_PORT   (0)
 
 #undef CONFIG_WATCHDOG /* disable watchdog */
diff --git a/include/configs/M5253EVBE.h b/include/configs/M5253EVBE.h
index daa44b315b..4a23379be7 100644
--- a/include/configs/M5253EVBE.h
+++ b/include/configs/M5253EVBE.h
@@ -10,7 +10,6 @@
 
 #define CONFIG_MCFTMR
 
-#define CONFIG_MCFUART
 #define CONFIG_SYS_UART_PORT   (0)
 
 #undef CONFIG_WATCHDOG /* disable watchdog */
diff --git a/include/configs/M5272C3.h b/include/configs/M5272C3.h
index 936a91e27d..bf02282e97 100644
--- a/include/configs/M5272C3.h
+++ b/include/configs/M5272C3.h
@@ -19,7 +19,6 @@
  */
 #define CONFIG_MCFTMR
 
-#define CONFIG_MCFUART
 #define CONFIG_SYS_UART_PORT   (0)
 
 #undef CONFIG_WATCHDOG
diff --git a/include/configs/M5275EVB.h b/include/configs/M5275EVB.h
index 1babb72fd0..12836140c4 100644
--- a/include/configs/M5275EVB.h
+++ b/include/configs/M5275EVB.h
@@ -24,7 +24,6 @@
 
 #define CONFIG_MCFTMR
 
-#define CONFIG_MCFUART
 #define CONFIG_SYS_UART_PORT   (0)
 
 /* Configuration for environment
diff --git a/include/configs/M5282EVB.h b/include/configs/M5282EVB.h
index b29515077a..5a31d3d860 100644
--- a/include/configs/M5282EVB.h
+++ b/include/configs/M5282EVB.h
@@ -19,7 +19,6 @@
  */
 #define CONFIG_MCFTMR
 
-#define CONFIG_MCFUART
 #define CONFIG_SYS_UART_PORT   (0)
 
 #undef CONFIG_MONITOR_IS_IN_RAM/* define if monitor is started from a 
pre-lo

[U-Boot] [PATCH 1/3] serial: Migrate CONFIG_ARC_SERIAL to Kconfig

2018-04-07 Thread Tuomas Tynkkynen
Signed-off-by: Tuomas Tynkkynen <tuo...@tuxera.com>
---
 arch/arc/Kconfig |  1 +
 drivers/serial/Kconfig   |  7 +++
 include/configs/nsim.h   | 10 --
 scripts/config_whitelist.txt |  1 -
 4 files changed, 8 insertions(+), 11 deletions(-)

diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index aee15d5353..fb91412150 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -143,6 +143,7 @@ config TARGET_TB100
 
 config TARGET_NSIM
bool "Support standalone nSIM & Free nSIM"
+   imply ARC_SERIAL
 
 config TARGET_AXS101
bool "Support Synopsys Designware SDP board AXS101"
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 3d5b2bf15f..0a01399961 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -416,6 +416,13 @@ config ALTERA_UART
  Select this to enable an UART for Altera devices. Please find
  details on the "Embedded Peripherals IP User Guide" of Altera.
 
+config ARC_SERIAL
+   bool "ARC UART support"
+   depends on DM_SERIAL && ARC
+   help
+ Select this to enable the support for UART on some ARC (Synopsys)
+ FPGA-based boards.
+
 config AR933X_UART
bool "QCA/Atheros ar933x UART support"
depends on DM_SERIAL && SOC_AR933X
diff --git a/include/configs/nsim.h b/include/configs/nsim.h
index 58d3e5f7de..e7fb35fe3b 100644
--- a/include/configs/nsim.h
+++ b/include/configs/nsim.h
@@ -25,16 +25,6 @@
 #define CONFIG_SYS_BOOTM_LEN   SZ_32M
 #define CONFIG_SYS_LOAD_ADDR   0x8200
 
-/*
- * UART configuration
- *
- */
-#define CONFIG_ARC_SERIAL
-
-/*
- * Command line configuration
- */
-
 /*
  * Environment settings
  */
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index 997ef771c7..831b4add54 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -48,7 +48,6 @@ CONFIG_ARCH_RMOBILE_EXTRAM_BOOT
 CONFIG_ARCH_TEGRA
 CONFIG_ARCH_USE_BUILTIN_BSWAP
 CONFIG_ARC_MMU_VER
-CONFIG_ARC_SERIAL
 CONFIG_ARIES_M28_V10
 CONFIG_ARMADA100
 CONFIG_ARMADA100_FEC
-- 
2.16.3

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


[U-Boot] Depending on an .o file in other directory in Kbuild?

2018-03-23 Thread Tuomas Tynkkynen
Hi,

I finally managed to track down the parallel make issue in helloworld.efi:
(previous posting at 
https://www.mail-archive.com/u-boot@lists.denx.de/msg268726.html):

make[2]: *** No rule to make target 'lib/efi_loader/helloworld.efi', needed by 
'__build'.  Stop.

The problematic make rule seems to be this from scripts/Makefile.lib:

$(obj)/%_efi.so: $(obj)/%.o arch/$(ARCH)/lib/$(EFI_CRT0) \  
   
arch/$(ARCH)/lib/$(EFI_RELOC)   
   
$(call cmd,efi_ld)  
   

So if I understood the recursive make in Kbuild correctly, during
the build of the lib/efi_loader/ subdirectory, rules from other
makefiles aren't visible (in this case the rules in arch/arm/lib/).
That is, the build usually works because arch/arm/lib/ has been
built by the time make descends into lib/efi_loader/ and the
$(EFI_CRT0) and $(EFI_RELOC) have already been built. But
when the order is swapped around due to parallel make, the
build fails.

I have no idea how this should be done correctly in Kbuild,
so if anybody else knows how to fix this, help is appreciated!

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


[U-Boot] [PATCH] net: Drop CONFIG_ENC28J60

2018-03-19 Thread Tuomas Tynkkynen
Last user of this driver went away in October 2014 in
commit d58a9451e7339ed4 ("ppc/arm: zap EMK boards").

Signed-off-by: Tuomas Tynkkynen <tuo...@tuxera.com>
---
 drivers/net/Makefile   |   1 -
 drivers/net/enc28j60.c | 959 -
 drivers/net/enc28j60.h | 238 
 include/netdev.h   |   2 -
 4 files changed, 1200 deletions(-)
 delete mode 100644 drivers/net/enc28j60.c
 delete mode 100644 drivers/net/enc28j60.h

diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 4a16c62bac..f361c3cac1 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -23,7 +23,6 @@ obj-$(CONFIG_E1000_SPI) += e1000_spi.o
 obj-$(CONFIG_EEPRO100) += eepro100.o
 obj-$(CONFIG_SUN4I_EMAC) += sunxi_emac.o
 obj-$(CONFIG_SUN8I_EMAC) += sun8i_emac.o
-obj-$(CONFIG_ENC28J60) += enc28j60.o
 obj-$(CONFIG_EP93XX) += ep93xx_eth.o
 obj-$(CONFIG_ETHOC) += ethoc.o
 obj-$(CONFIG_FEC_MXC) += fec_mxc.o
diff --git a/drivers/net/enc28j60.c b/drivers/net/enc28j60.c
deleted file mode 100644
index 588a84d7a9..00
--- a/drivers/net/enc28j60.c
+++ /dev/null
@@ -1,959 +0,0 @@
-/*
- * (C) Copyright 2010
- * Reinhard Meyer, EMK Elektronik, reinhard.me...@emk-elektronik.de
- * Martin Krause, martin.kra...@tqs.de
- * reworked original enc28j60.c
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include "enc28j60.h"
-
-/*
- * IMPORTANT: spi_claim_bus() and spi_release_bus()
- * are called at begin and end of each of the following functions:
- * enc_miiphy_read(), enc_miiphy_write(), enc_write_hwaddr(),
- * enc_init(), enc_recv(), enc_send(), enc_halt()
- * ALL other functions assume that the bus has already been claimed!
- * Since net_process_received_packet() might call enc_send() in return, the bus
- * must be released, net_process_received_packet() called and claimed again.
- */
-
-/*
- * Controller memory layout.
- * We only allow 1 frame for transmission and reserve the rest
- * for reception to handle as many broadcast packets as possible.
- * Also use the memory from 0x for receiver buffer. See errata pt. 5
- * 0x - 0x19ff 6656 bytes receive buffer
- * 0x1a00 - 0x1fff 1536 bytes transmit buffer =
- * control(1)+frame(1518)+status(7)+reserve(10).
- */
-#define ENC_RX_BUF_START   0x
-#define ENC_RX_BUF_END 0x19ff
-#define ENC_TX_BUF_START   0x1a00
-#define ENC_TX_BUF_END 0x1fff
-#define ENC_MAX_FRM_LEN1518
-#define RX_RESET_COUNTER   1000
-
-/*
- * For non data transfer functions, like phy read/write, set hwaddr, init
- * we do not need a full, time consuming init including link ready wait.
- * This enum helps to bring the chip through the minimum necessary inits.
- */
-enum enc_initstate {none=0, setupdone, linkready};
-typedef struct enc_device {
-   struct eth_device   *dev;   /* back pointer */
-   struct spi_slave*slave;
-   int rx_reset_counter;
-   u16 next_pointer;
-   u8  bank;   /* current bank in enc28j60 */
-   enum enc_initstate  initstate;
-} enc_dev_t;
-
-/*
- * enc_bset:   set bits in a common register
- * enc_bclr:   clear bits in a common register
- *
- * making the reg parameter u8 will give a compile time warning if the
- * functions are called with a register not accessible in all Banks
- */
-static void enc_bset(enc_dev_t *enc, const u8 reg, const u8 data)
-{
-   u8 dout[2];
-
-   dout[0] = CMD_BFS(reg);
-   dout[1] = data;
-   spi_xfer(enc->slave, 2 * 8, dout, NULL,
-   SPI_XFER_BEGIN | SPI_XFER_END);
-}
-
-static void enc_bclr(enc_dev_t *enc, const u8 reg, const u8 data)
-{
-   u8 dout[2];
-
-   dout[0] = CMD_BFC(reg);
-   dout[1] = data;
-   spi_xfer(enc->slave, 2 * 8, dout, NULL,
-   SPI_XFER_BEGIN | SPI_XFER_END);
-}
-
-/*
- * high byte of the register contains bank number:
- * 0: no bank switch necessary
- * 1: switch to bank 0
- * 2: switch to bank 1
- * 3: switch to bank 2
- * 4: switch to bank 3
- */
-static void enc_set_bank(enc_dev_t *enc, const u16 reg)
-{
-   u8 newbank = reg >> 8;
-
-   if (newbank == 0 || newbank == enc->bank)
-   return;
-   switch (newbank) {
-   case 1:
-   enc_bclr(enc, CTL_REG_ECON1,
-   ENC_ECON1_BSEL0 | ENC_ECON1_BSEL1);
-   break;
-   case 2:
-   enc_bset(enc, CTL_REG_ECON1, ENC_ECON1_BSEL0);
-   enc_bclr(enc, CTL_REG_ECON1, ENC_ECON1_BSEL1);
-   break;
-   case 3:
-   enc_bclr(enc, CTL_REG_ECON1, ENC_ECON1_BSEL0);
-   enc_bset(enc, CTL_REG_ECON1, ENC_ECON1_BSEL1);
-   break;
-   case 4:
-   enc_bset(enc, CTL_REG_ECON1,
-   ENC_ECON1_BSEL0 | ENC_ECON1_BSEL1);
-   break;
-   }
- 

Re: [U-Boot] [PATCH] lan7xxx: Require phylib

2018-03-15 Thread Tuomas Tynkkynen
Hi,

On Thu, 15 Mar 2018 15:10:20 +0100
Alexander Graf  wrote:

> The lan75xx and lan78xx drivers need to drive their phy via the generic
> phylib framework. Let's reflect that dependency in Kconfig, so that we
> don't get build errors when phylib does not get selected.
> 
> Signed-off-by: Alexander Graf 
> ---
>  drivers/usb/eth/Kconfig | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/usb/eth/Kconfig b/drivers/usb/eth/Kconfig
> index 496a6d1933..2f6bfa8e71 100644
> --- a/drivers/usb/eth/Kconfig
> +++ b/drivers/usb/eth/Kconfig
> @@ -23,6 +23,7 @@ config USB_ETHER_ASIX88179
>  config USB_ETHER_LAN75XX
>   bool "Microchip LAN75XX support"
>   depends on USB_HOST_ETHER
> + depends on PHYLIB

'select PHYLIB' seems more appropriate here (and there are already 17
drivers selecting it and none using 'depends on'.)

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


[U-Boot] [PATCH] tools: Make kwboot build if HOST_TOOLS_ALL=y

2018-03-13 Thread Tuomas Tynkkynen
The kwboot tool for Marvell devices isn't currently being built even if
HOST_TOOLS_ALL is set. It doesn't appear to depend on any CONFIG_
options, so it seems appropriate to enable building it here.

Signed-off-by: Tuomas Tynkkynen <tuo...@tuxera.com>
---
 tools/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/Makefile b/tools/Makefile
index f38f68ee47..1db235036c 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -7,6 +7,7 @@
 
 # Enable all the config-independent tools
 ifneq ($(HOST_TOOLS_ALL),)
+CONFIG_KIRKWOOD = y
 CONFIG_LCD_LOGO = y
 CONFIG_CMD_LOADS = y
 CONFIG_CMD_NET = y
-- 
2.16.1

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


Re: [U-Boot] [PATCH v2 2/2] bcm283x_pl011: Flush RX queue after setting baud rate

2018-03-09 Thread Tuomas Tynkkynen
On Wed, 7 Mar 2018 22:08:25 +0100
Alexander Graf <ag...@suse.de> wrote:

> After the UART was initialized, we may still have bogus data in the
> RX queue if it was enabled with incorrect pin muxing before.
> 
> So let's flush the RX queue whenever we initialize baud rates.
> 
> This fixes a regression with the dynamic pinmuxing code when enable_uart=1
> is not set in config.txt on Raspberry Pis that use pl011 for serial.
> 
> Fixes: caf2233b28 ("bcm283x: Add pinctrl driver")
> Reported-by: Göran Lundberg <goran@lundberg.email>
> Reported-by: Peter Robinson <pbrobin...@gmail.com>
> Signed-off-by: Alexander Graf <ag...@suse.de>
> 
> ---
> 
> v1 -> v2:
> 
>   - correctly drain the queue
> ---
>  drivers/serial/serial_bcm283x_pl011.c  | 25 -
>  drivers/serial/serial_pl01x.c  | 10 +-
>  drivers/serial/serial_pl01x_internal.h |  7 ++-
>  3 files changed, 35 insertions(+), 7 deletions(-)
> 

On a RPi 1, with no enable_uart in config.txt:

Tested-by: Tuomas Tynkkynen <tuo...@tuxera.com>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 1/2] serial_bcm283x_mu: Flush RX queue after setting baud rate

2018-03-09 Thread Tuomas Tynkkynen
On Wed, 7 Mar 2018 22:08:24 +0100
Alexander Graf <ag...@suse.de> wrote:

> After the UART was initialized, we may still have bogus data in the
> RX queue if it was enabled with incorrect pin muxing before.
> 
> So let's flush the RX queue whenever we initialize baud rates.
> 
> This fixes a regression with the dynamic pinmuxing code when enable_uart=1
> is not set in config.txt.
> 
> Fixes: caf2233b28 ("bcm283x: Add pinctrl driver")
> Reported-by: Göran Lundberg <goran@lundberg.email>
> Reported-by: Peter Robinson <pbrobin...@gmail.com>
> Signed-off-by: Alexander Graf <ag...@suse.de>
> ---
>  drivers/serial/serial_bcm283x_mu.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 

On a RPi 1, with no enable_uart in config.txt:

Tested-by: Tuomas Tynkkynen <tuo...@tuxera.com>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH RFC 2/2] ARM: sunxi: Build u-boot-sunxi-with-spl.bin on ARM64 as well

2018-03-06 Thread Tuomas Tynkkynen
In README.sunxi64 we tell the user how to optionally create
u-boot-sunxi-with-spl.bin by manually running cat. Instead, have the
build system create the file automatically just like it does for 32-bit
sunxi boards.

Signed-off-by: Tuomas Tynkkynen <tuo...@tuxera.com>
---
 Makefile   | 5 +
 board/sunxi/README.sunxi64 | 3 +--
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 24a79446d8..4b203a0155 100644
--- a/Makefile
+++ b/Makefile
@@ -1191,8 +1191,13 @@ u-boot-x86-16bit.bin: u-boot FORCE
 endif
 
 ifneq ($(CONFIG_ARCH_SUNXI),)
+ifeq ($(CONFIG_ARM64),)
 u-boot-sunxi-with-spl.bin: spl/sunxi-spl.bin u-boot.img u-boot.dtb FORCE
$(call if_changed,binman)
+else
+u-boot-sunxi-with-spl.bin: spl/sunxi-spl.bin u-boot.itb FORCE
+   $(call if_changed,cat)
+endif
 endif
 
 ifneq ($(CONFIG_TEGRA),)
diff --git a/board/sunxi/README.sunxi64 b/board/sunxi/README.sunxi64
index c492f749b8..5a363d27b8 100644
--- a/board/sunxi/README.sunxi64
+++ b/board/sunxi/README.sunxi64
@@ -95,9 +95,8 @@ Transfer the SPL and the U-Boot FIT image directly to an uSD 
card:
 (replace /dev/sdx with you SD card device file name, which could be
 /dev/mmcblk[x] as well).
 
-Alternatively you can concatenate the SPL and the U-Boot FIT image into a
+Alternatively you can use the SPL and the U-Boot FIT image combined into a
 single file and transfer that instead:
-$ cat spl/sunxi-spl.bin u-boot.itb > u-boot-sunxi-with-spl.bin
 # dd if=u-boot-sunxi-with-spl.bin of=/dev/sdx bs=8k seek=1
 
 You can partition the microSD card, but leave the first MB unallocated (most
-- 
2.16.1

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


[U-Boot] [PATCH RFC 1/2] ARM: sunxi: Move u-boot-sunxi-with-spl.bin rule to Makefile

2018-03-06 Thread Tuomas Tynkkynen
We're going to need this logic for 64-bit builds as well, so move it
out from under arch/arm/cpu/armv7.

Signed-off-by: Tuomas Tynkkynen <tuo...@tuxera.com>
---
 Makefile   | 5 +
 arch/arm/cpu/armv7/sunxi/config.mk | 6 --
 2 files changed, 5 insertions(+), 6 deletions(-)
 delete mode 100644 arch/arm/cpu/armv7/sunxi/config.mk

diff --git a/Makefile b/Makefile
index c6819d5742..24a79446d8 100644
--- a/Makefile
+++ b/Makefile
@@ -800,6 +800,11 @@ ifneq ($(BUILD_ROM)$(CONFIG_BUILD_ROM),)
 ALL-$(CONFIG_X86_RESET_VECTOR) += u-boot.rom
 endif
 
+# Build a combined spl + u-boot image for sunxi
+ifeq ($(CONFIG_ARCH_SUNXI)$(CONFIG_SPL),yy)
+ALL-y += u-boot-sunxi-with-spl.bin
+endif
+
 # enable combined SPL/u-boot/dtb rules for tegra
 ifeq ($(CONFIG_TEGRA)$(CONFIG_SPL),yy)
 ALL-y += u-boot-tegra.bin u-boot-nodtb-tegra.bin
diff --git a/arch/arm/cpu/armv7/sunxi/config.mk 
b/arch/arm/cpu/armv7/sunxi/config.mk
deleted file mode 100644
index 76ffec9df6..00
--- a/arch/arm/cpu/armv7/sunxi/config.mk
+++ /dev/null
@@ -1,6 +0,0 @@
-# Build a combined spl + u-boot image
-ifdef CONFIG_SPL
-ifndef CONFIG_SPL_BUILD
-ALL-y += u-boot-sunxi-with-spl.bin
-endif
-endif
-- 
2.16.1

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


[U-Boot] [PATCH RFC 0/2] sunxi: Build u-boot-sunxi-with-spl.bin on ARM64 as well

2018-03-06 Thread Tuomas Tynkkynen
For some reason we seem to have documented how to build
u-boot-sunxi-with-spl.bin manually with cat but not have a build system
rule for it. Let's fix this to have the file built by default just like
it is on 32-bit sunxi boards.

Build-tested only.

Tuomas Tynkkynen (2):
  ARM: sunxi: Move u-boot-sunxi-with-spl.bin rule to Makefile
  ARM: sunxi: Build u-boot-sunxi-with-spl.bin on ARM64 as well

 Makefile   | 10 ++
 arch/arm/cpu/armv7/sunxi/config.mk |  6 --
 board/sunxi/README.sunxi64 |  3 +--
 3 files changed, 11 insertions(+), 8 deletions(-)
 delete mode 100644 arch/arm/cpu/armv7/sunxi/config.mk

-- 
2.16.1

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


Re: [U-Boot] Whitelist scripting

2018-03-05 Thread Tuomas Tynkkynen
Hi,

On Mon, 5 Mar 2018 14:08:20 -0600
Adam Ford  wrote:

...
> 
> What I was hoping to do was help clean the whitelist table by first
> searching for #defines that are never used anywhere and/or are dead.I
> will be the first person to admit that I am not very good with shell
> scripts, so I thought I'd solicit a favor.
> 
> Does someone have any cool scripts that we can use the scan through
> the and look for #defines that have no #ifdef, Makefile dependancy, or
> linker script attachment?  These seem like they'd be obvious chunks of
> code to eliminate.

I personally started with a lower-hanging fruit: config symbols that
are referenced exactly once. For that I use the following hacks
that I just pick from the shell history with Ctrl-R every now and then :)

rm -rf grep-counts; mkdir grep-counts; for f in $(cat 
scripts/config_whitelist.txt); do git grep $f > grep-counts/$f; done

This just builds a "database" of occurences for each symbol in the whitelist. 
Then:

for f in $(wc -l grep-counts/* | awk '$1 == 2' | tr / ' ' | awk '{print $3}'); 
do cat grep-counts/$f; done | grep ':#define'

This lists all the symbols from the database that are only #define'd exactly 
once
(it checks for '2' to account for the match in config_whitelist.txt).

Hope that helps. Don't try to remove the same symbols I removed in my latest 3
patches to the list though :)

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


[U-Boot] [PATCH 3/3] ARM: Drop unreferenced CONFIG_* defines named after boards

2018-03-05 Thread Tuomas Tynkkynen
The following config symbols are only defined once and never referenced
anywhere else:

CONFIG_AT91SAM9263EK
CONFIG_AT91SAM9RLEK
CONFIG_BARIX_IPAM390
CONFIG_BOARD_H2200
CONFIG_EP9301
CONFIG_KZM_A9_GT
CONFIG_PICOSAM
CONFIG_PLATINUM_PICON
CONFIG_PLATINUM_TITANIUM
CONFIG_PM9261
CONFIG_PM9263
CONFIG_PM9G45
CONFIG_SIEMENS_DRACO
CONFIG_SIEMENS_PXM2
CONFIG_SIEMENS_RUT
CONFIG_SMDKC100
CONFIG_SMDKV310
CONFIG_STM32F4DISCOVERY

Most of them are config symbols named after the respective boards which
seems to have been a standard practice at some point.

Signed-off-by: Tuomas Tynkkynen <tuo...@tuxera.com>
---
 include/configs/at91sam9263ek.h   |  2 --
 include/configs/at91sam9rlek.h|  2 --
 include/configs/draco.h   |  1 -
 include/configs/edb93xx.h |  1 -
 include/configs/h2200.h   |  1 -
 include/configs/ipam390.h |  1 -
 include/configs/kzm9g.h   |  1 -
 include/configs/picosam9g45.h |  2 --
 include/configs/platinum_picon.h  |  1 -
 include/configs/platinum_titanium.h   |  1 -
 include/configs/pm9261.h  |  1 -
 include/configs/pm9263.h  |  1 -
 include/configs/pm9g45.h  |  1 -
 include/configs/pxm2.h|  1 -
 include/configs/rut.h |  1 -
 include/configs/smdkc100.h|  1 -
 include/configs/smdkv310.h|  1 -
 include/configs/stm32f429-discovery.h |  2 --
 include/configs/stm32f469-discovery.h |  2 --
 scripts/config_whitelist.txt  | 18 --
 20 files changed, 42 deletions(-)

diff --git a/include/configs/at91sam9263ek.h b/include/configs/at91sam9263ek.h
index b6691feb68..7fe51c2c0b 100644
--- a/include/configs/at91sam9263ek.h
+++ b/include/configs/at91sam9263ek.h
@@ -21,8 +21,6 @@
 #define CONFIG_SYS_AT91_MAIN_CLOCK 16367660 /* 16.367 MHz crystal */
 #define CONFIG_SYS_AT91_SLOW_CLOCK 32768
 
-#define CONFIG_AT91SAM9263EK   1   /* It's an AT91SAM9263EK Board */
-
 #define CONFIG_ARCH_CPU_INIT
 
 #define CONFIG_CMDLINE_TAG 1   /* enable passing of ATAGs  */
diff --git a/include/configs/at91sam9rlek.h b/include/configs/at91sam9rlek.h
index 08c8f48bb5..6f8fd2a035 100644
--- a/include/configs/at91sam9rlek.h
+++ b/include/configs/at91sam9rlek.h
@@ -17,8 +17,6 @@
 #define CONFIG_SYS_AT91_SLOW_CLOCK 32768   /* slow clock xtal */
 #define CONFIG_SYS_AT91_MAIN_CLOCK 1200/* main clock xtal */
 
-#define CONFIG_AT91SAM9RLEK1   /* It's an AT91SAM9RLEK Board */
-
 #define CONFIG_ARCH_CPU_INIT
 #define CONFIG_SKIP_LOWLEVEL_INIT
 
diff --git a/include/configs/draco.h b/include/configs/draco.h
index 3278196b3a..c1816409a9 100644
--- a/include/configs/draco.h
+++ b/include/configs/draco.h
@@ -13,7 +13,6 @@
 #ifndef __CONFIG_DRACO_H
 #define __CONFIG_DRACO_H
 
-#define CONFIG_SIEMENS_DRACO
 #define CONFIG_SIEMENS_MACH_TYPE   MACH_TYPE_DRACO
 
 #include "siemens-am33x-common.h"
diff --git a/include/configs/edb93xx.h b/include/configs/edb93xx.h
index 6e024d1b2f..18ec6cb758 100644
--- a/include/configs/edb93xx.h
+++ b/include/configs/edb93xx.h
@@ -34,7 +34,6 @@
 #define CONFIG_SYS_LDSCRIPT"board/cirrus/edb93xx/u-boot.lds"
 
 #ifdef CONFIG_EDB9301
-#define CONFIG_EP9301
 #define CONFIG_MACH_TYPE   MACH_TYPE_EDB9301
 #define CONFIG_ENV_SECT_SIZE   0x0002
 #elif defined(CONFIG_EDB9302)
diff --git a/include/configs/h2200.h b/include/configs/h2200.h
index 608f5eec32..4b380beee2 100644
--- a/include/configs/h2200.h
+++ b/include/configs/h2200.h
@@ -12,7 +12,6 @@
 #define CONFIG_MACH_TYPE   MACH_TYPE_H2200
 
 #define CONFIG_CPU_PXA25X  1
-#define CONFIG_BOARD_H2200
 
 #define CONFIG_NR_DRAM_BANKS   1
 #define PHYS_SDRAM_1   0xa000 /* SDRAM Bank #1 */
diff --git a/include/configs/ipam390.h b/include/configs/ipam390.h
index 82ab24c688..c8e99513f0 100644
--- a/include/configs/ipam390.h
+++ b/include/configs/ipam390.h
@@ -19,7 +19,6 @@
  * Board
  */
 #define CONFIG_DRIVER_TI_EMAC
-#define CONFIG_BARIX_IPAM390
 
 /*
  * SoC Configuration
diff --git a/include/configs/kzm9g.h b/include/configs/kzm9g.h
index 0d8de370dd..82984f4d17 100644
--- a/include/configs/kzm9g.h
+++ b/include/configs/kzm9g.h
@@ -11,7 +11,6 @@
 #undef DEBUG
 
 #define CONFIG_SH73A0
-#define CONFIG_KZM_A9_GT
 #define CONFIG_ARCH_RMOBILE_BOARD_STRING   "KMC KZM-A9-GT"
 #define CONFIG_MACH_TYPE MACH_TYPE_KZM9G
 
diff --git a/include/configs/picosam9g45.h b/include/configs/picosam9g45.h
index 06ee8e7f9e..0d4fc119ac 100644
--- a/include/configs/picosam9g45.h
+++ b/include/configs/picosam9g45.h
@@ -22,8 +22,6 @@
 #define CONFIG_SYS_AT91_SLOW_CLOCK  32768
 #define CONFIG_SYS_AT91_MAIN_CLOCK  1200 /* from 12 MHz crystal */
 
-#define CONFIG_PICOSAM
-
 #define CONFIG_CMDLINE_TAG /* enable passing of ATAGs  */
 #define CONFIG_SETUP_MEMORY_TAGS
 #define CONFIG_INITRD_TAG
diff --git 

[U-Boot] [PATCH 1/3] MIPS: Drop unreferenced CONFIG_* defines

2018-03-05 Thread Tuomas Tynkkynen
The following config symbols are only defined once and never referenced
anywhere else:

CONFIG_DBAU1X00
CONFIG_PB1X00

Most of them are config symbols named after the respective boards which
seems to have been a standard practice at some point.

Signed-off-by: Tuomas Tynkkynen <tuo...@tuxera.com>
---
 include/configs/dbau1x00.h   | 1 -
 include/configs/pb1x00.h | 1 -
 scripts/config_whitelist.txt | 2 --
 3 files changed, 4 deletions(-)

diff --git a/include/configs/dbau1x00.h b/include/configs/dbau1x00.h
index ebd2c23960..f00111a8c4 100644
--- a/include/configs/dbau1x00.h
+++ b/include/configs/dbau1x00.h
@@ -12,7 +12,6 @@
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
-#define CONFIG_DBAU1X001
 #define CONFIG_SOC_AU1X00  1  /* alchemy series cpu */
 
 #ifdef CONFIG_DBAU1000
diff --git a/include/configs/pb1x00.h b/include/configs/pb1x00.h
index 972c13a625..8adb7d7cfa 100644
--- a/include/configs/pb1x00.h
+++ b/include/configs/pb1x00.h
@@ -12,7 +12,6 @@
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
-#define CONFIG_PB1X00  1
 #define CONFIG_SOC_AU1X00  1  /* alchemy series cpu */
 
 #ifdef CONFIG_PB1000
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index a42b64d209..f63d95f967 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -325,7 +325,6 @@ CONFIG_DA850_AM18X_EVM
 CONFIG_DA850_EVM_MAX_CPU_CLK
 CONFIG_DA8XX_GPIO
 CONFIG_DBAU1000
-CONFIG_DBAU1X00
 CONFIG_DBGU
 CONFIG_DBG_MONITOR
 CONFIG_DB_784MP_GP
@@ -1496,7 +1495,6 @@ CONFIG_PARAVIRT
 CONFIG_PB1000
 CONFIG_PB1100
 CONFIG_PB1500
-CONFIG_PB1X00
 CONFIG_PCA953X
 CONFIG_PCA9698
 CONFIG_PCI1
-- 
2.16.1

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


[U-Boot] [PATCH 2/3] ARM: Drop unreferenced CONFIG_* defines named after SoCs

2018-03-05 Thread Tuomas Tynkkynen
The following config symbols are only defined once and never referenced
anywhere else:

CONFIG_ARM926EJS
CONFIG_CPUAT91
CONFIG_EXYNOS5800
CONFIG_SYS_CORTEX_R4

Most of them are config symbols named after the respective SoCs which
seems to have been a standard practice at some point.

Signed-off-by: Tuomas Tynkkynen <tuo...@tuxera.com>
---
 include/configs/at91rm9200ek.h  | 1 -
 include/configs/exynos5420-common.h | 2 --
 include/configs/omapl138_lcdk.h | 1 -
 include/configs/stv0991.h   | 2 --
 scripts/config_whitelist.txt| 4 
 5 files changed, 10 deletions(-)

diff --git a/include/configs/at91rm9200ek.h b/include/configs/at91rm9200ek.h
index 9ce0a8f9bf..8c27122c00 100644
--- a/include/configs/at91rm9200ek.h
+++ b/include/configs/at91rm9200ek.h
@@ -44,7 +44,6 @@
 /* CPU configuration */
 #define CONFIG_AT91RM9200
 #define CONFIG_AT91RM9200EK
-#define CONFIG_CPUAT91
 #define USE_920T_MMU
 
 #include   /* needed for port definitions */
diff --git a/include/configs/exynos5420-common.h 
b/include/configs/exynos5420-common.h
index ae9ead53f6..e13092515a 100644
--- a/include/configs/exynos5420-common.h
+++ b/include/configs/exynos5420-common.h
@@ -10,8 +10,6 @@
 #define __CONFIG_EXYNOS5420_H
 
 #define CONFIG_EXYNOS5420
-/* A variant of Exynos5420 (Exynos5 Family) */
-#define CONFIG_EXYNOS5800
 
 #define CONFIG_EXYNOS5_DT
 
diff --git a/include/configs/omapl138_lcdk.h b/include/configs/omapl138_lcdk.h
index 837286bd78..ea7bdf133d 100644
--- a/include/configs/omapl138_lcdk.h
+++ b/include/configs/omapl138_lcdk.h
@@ -23,7 +23,6 @@
  * SoC Configuration
  */
 #define CONFIG_MACH_OMAPL138_LCDK
-#define CONFIG_ARM926EJS   /* arm926ejs CPU core */
 #define CONFIG_SYS_CLK_FREQclk_get(DAVINCI_ARM_CLKID)
 #define CONFIG_SYS_OSCIN_FREQ  2400
 #define CONFIG_SYS_TIMERBASE   DAVINCI_TIMER0_BASE
diff --git a/include/configs/stv0991.h b/include/configs/stv0991.h
index 0c08556d21..2401dbd619 100644
--- a/include/configs/stv0991.h
+++ b/include/configs/stv0991.h
@@ -10,8 +10,6 @@
 #define CONFIG_SYS_DCACHE_OFF
 #define CONFIG_SYS_EXCEPTION_VECTORS_HIGH
 
-#define CONFIG_SYS_CORTEX_R4
-
 /* ram memory-related information */
 #define CONFIG_NR_DRAM_BANKS   1
 #define PHYS_SDRAM_1   0x
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index f63d95f967..6ea78bd14e 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -50,7 +50,6 @@ CONFIG_ARCH_USE_BUILTIN_BSWAP
 CONFIG_ARC_MMU_VER
 CONFIG_ARC_SERIAL
 CONFIG_ARIES_M28_V10
-CONFIG_ARM926EJS
 CONFIG_ARMADA100
 CONFIG_ARMADA100_FEC
 CONFIG_ARMADA168
@@ -272,7 +271,6 @@ CONFIG_CORTINA_FW_LENGTH
 CONFIG_CPLD_BR_PRELIM
 CONFIG_CPLD_OR_PRELIM
 CONFIG_CPM2
-CONFIG_CPUAT91
 CONFIG_CPU_ARCHS34
 CONFIG_CPU_ARMV8
 CONFIG_CPU_CAVIUM_OCTEON
@@ -598,7 +596,6 @@ CONFIG_EXYNOS4210
 CONFIG_EXYNOS5
 CONFIG_EXYNOS5250
 CONFIG_EXYNOS5420
-CONFIG_EXYNOS5800
 CONFIG_EXYNOS5_DT
 CONFIG_EXYNOS7420
 CONFIG_EXYNOS_ACE_SHA
@@ -2255,7 +2252,6 @@ CONFIG_SYS_CMXFCR_VALUE2
 CONFIG_SYS_CMXFCR_VALUE3
 CONFIG_SYS_CORE_SRAM
 CONFIG_SYS_CORE_SRAM_SIZE
-CONFIG_SYS_CORTEX_R4
 CONFIG_SYS_CORTINA_FW_IN_MMC
 CONFIG_SYS_CORTINA_FW_IN_NAND
 CONFIG_SYS_CORTINA_FW_IN_NOR
-- 
2.16.1

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


[U-Boot] [PATCH] ARM: qemu-arm: Increase CONFIG_SYS_CBSIZE

2018-03-05 Thread Tuomas Tynkkynen
CONFIG_SYS_CBSIZE determines the maximum length of the kernel command
line, and the default value of 256 is too small for booting some Linux
images in the wild.

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkky...@iki.fi>
--
Hoping to get this in 2018.03.
---
 include/configs/qemu-arm.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/qemu-arm.h b/include/configs/qemu-arm.h
index c968aa76ac..839bc10a18 100644
--- a/include/configs/qemu-arm.h
+++ b/include/configs/qemu-arm.h
@@ -47,4 +47,6 @@
"ramdisk_addr_r=0x4400\0" \
BOOTENV
 
+#define CONFIG_SYS_CBSIZE 512
+
 #endif /* __CONFIG_H */
-- 
2.16.1

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


[U-Boot] Default CONFIG_SYS_CBSIZE too low

2018-03-05 Thread Tuomas Tynkkynen
Hi,

I was playing around with qemu_arm and qemu_arm64 and noticed some images
using the distro bootcmd infrastructure failed to boot there due to the buffer
for kernel command line arguments (which is determined by CONFIG_SYS_CBSIZE)
was too small. I found this odd given the images worked on some other boards
but turns out all of them bump it up from the default of 256:

include/configs/tegra-common.h:#define CONFIG_SYS_CBSIZE(1024 * 
2) /* Console I/O Buffer Size */
include/configs/sunxi-common.h:#define CONFIG_SYS_CBSIZE1024/* 
Console I/O Buffer Size */
include/configs/mx6_common.h:#define CONFIG_SYS_CBSIZE  512
include/configs/rpi.h:#define CONFIG_SYS_CBSIZE 1024

For 2018.03 I'll send a patch to increase it for qemu-arm too but I think
for the next release we should increase default (in config_fallbacks.h) so
that the user experience is consistent on all boards. But, I wonder how
safe it is to increase it for these boards low on RAM and stack? 
Should it perhaps be increased only for boards with CONFIG_DISTRO_DEFAULTS
that are expected to have enough resources for everything and the kitchen
sink? Or decoupling the kernel command line length from CONFIG_SYS_CBSIZE
and using malloc()? Other ideas?

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


Re: [U-Boot] Support of kernels > 16 MiB on Raspberry Pi

2018-02-23 Thread Tuomas Tynkkynen
+ agraf

On Fri, 23 Feb 2018 09:57:30 -0500
Tom Rini  wrote:

> On Fri, Feb 23, 2018 at 04:47:06PM +0900, Jaehoon Chung wrote:
> > On 02/23/2018 04:58 AM, Alexander Kurtz wrote:  
> > > Hi!
> > > 
> > > I am using U-Boot to boot Debian Buster arm64 (standard kernel with a
> > > dracut-based initramfs) via an extlinux.conf on my Raspberry Pi 3. 
> > > 
> > > Recently, the Debian kernel grew beyond 16 MiB:
> > > 
> > > 4.13: /boot/vmlinuz-4.13.0-1-arm64 == 16448000 bytes (< 16 MiB) [0]
> > > 4.14: /boot/vmlinuz-4.14.0-3-arm64 == 17539584 bytes (> 16 MiB) [1]
> > > 4.15: /boot/vmlinuz-4.15.0-1-arm64 == 17867264 bytes (> 16 MiB) [2]
> > > 
> > > https://github.com/u-boot/u-boot/blob/master/include/configs/rpi.h#L129 
> > > says:
> > > 
> > > #define ENV_MEM_LAYOUT_SETTINGS \
> > > "fdt_high=\0" \
> > > "initrd_high=\0" \
> > > "fdt_addr_r=0x0100\0" \
> > > "pxefile_addr_r=0x0010\0" \
> > > "kernel_addr_r=0x0100\0" \
> > > "scriptaddr=0x0200\0" \
> > > "ramdisk_addr_r=0x0210\0" \
> > > 
> > > Am I correct in assuming that this default configuration will break
> > > with kernels > 16 MiB? The Readme [3] seems to confirm this, but I
> > > wanted to ask for explicit confirmation here.  
> > 
> > Especially, this is occurred about arm64 kernel.
> > Because it wil be overlapped with other image address, if kernel image is 
> > over than 16MB.
> > 
> > In my case, i'm using the private boot.scr.img for booting script.
> > I had just added the kernel_addr_r=0x02d00.
> > 
> > Just Refer to below:
> > https://review.tizen.org/git/?p=platform/kernel/u-boot.git;a=commit;h=8fdfbbeb8a4b2f8c8e66824709e48d9abdb23534
> >   
> 
> I would strongly recommend setting the values here based on what
> linux/Documentation/arm/Booting and linux/Documentation/arm64/boot.txt
> describe as the maximum limits for each of these locations.  And take a
> peek at include/configs/ti_armv7_common.h in U-Boot on how I set these
> for the various TI platforms.
> 

I sent a patch for the load addresses a while ago, for which I never got
around to writing a follow-up it seems:

https://lists.denx.de/pipermail/u-boot/2017-June/295889.html

FWIW, I have my doubts of the relocation mechanism used for DTs and initrds
because on ARM, the size of the lowmem mapping in Linux (which dictates the
highest permitted address) depends on not only build-time options like
CONFIG_VMSPLIT_* but also on boot-time options like vmalloc=xxxM.

Also, at least when using the extlinux.conf boot method, because the files
(kernel, DTB, initrd) are first loaded to RAM to the addresses specified
in the environment and only then relocated, the files can still smash each
other in memory during load time. So enabling relocation doesn't actually
help, tweaking the load addresses is still required.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] script: Make the get_default_envs.sh script working with newest u-boot

2018-02-14 Thread Tuomas Tynkkynen
On Wed, 14 Feb 2018 09:50:17 +0100
Lukasz Majewski <lu...@denx.de> wrote:

> On Wed, 14 Feb 2018 03:25:58 +0200
> Tuomas Tynkkynen <tuo...@tuxera.com> wrote:
> 
> > Hi,
> > 
> > On Tue, 13 Feb 2018 23:01:13 +0100
> > Lukasz Majewski <lu...@denx.de> wrote:
> > 
> > > This commit fixes several issues:
> > > 
> > > - After moving env related code to ./env directory the env_common.o
> > > file is no longer present in the system (has been replaced with
> > > built-in.o).
> > > 
> > > - Use ${OBJCOPY} if available, fallback to system default's objcopy
> > > if not present.
> > > 
> > > - Extend the script to accept different build directory than
> > > current one. It is extremely handy with OE usage, where source code
> > > is separated from build.
> > > 
> > > Signed-off-by: Lukasz Majewski <lu...@denx.de>
> > > ---
> > > 
> > >  scripts/get_default_envs.sh | 19 ++-
> > >  1 file changed, 14 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/scripts/get_default_envs.sh
> > > b/scripts/get_default_envs.sh index 7955db60e5..bbb6d0a6ef 100755
> > > --- a/scripts/get_default_envs.sh
> > > +++ b/scripts/get_default_envs.sh
> > > @@ -6,16 +6,24 @@
> > >  #
> > >  
> > >  # This file extracts default envs from built u-boot
> > > -# usage: get_default_envs.sh > u-boot-env-default.txt
> > > +# usage: get_default_envs.sh [build dir] > u-boot-env-default.txt
> > >  set -ue
> > >  
> > > -ENV_OBJ_FILE="env_common.o"
> > > +: "${OBJCOPY:=objcopy}"  
> > 
> > Maybe "${CROSS_COMPILE}objcopy" would be a better default as that's
> > what the build system uses.
> 
> Unfortunately not with OE builds. In OE, the OBJCOPY is set to arm
> specific objcopy.
> 
> With fallback (objcopy) from your local machine - it depends if it
> supports multi arch or not.

No, I meant that instead of having a fallback of "objcopy", have a 
fallback of "${CROSS_COMPILE}objcopy". I.e. squashing this change:

diff --git a/scripts/get_default_envs.sh b/scripts/get_default_envs.sh
index 3e532d12c4..184cc19ab7 100755
--- a/scripts/get_default_envs.sh
+++ b/scripts/get_default_envs.sh
@@ -9,7 +9,7 @@
 # usage: get_default_envs.sh [build dir] > u-boot-env-default.txt
 set -ue
 
-: "${OBJCOPY:=objcopy}"
+: "${OBJCOPY:=${CROSS_COMPILE:-}objcopy}"
 
 ENV_OBJ_FILE="built-in.o"
 ENV_OBJ_FILE_COPY="copy_${ENV_OBJ_FILE}"

That way the script works out-of-the-box for people who do the usual

export CROSS_COMPILE=aarch64-linux-gnu- (or whatever)

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


Re: [U-Boot] [PATCH] script: Make the get_default_envs.sh script working with newest u-boot

2018-02-13 Thread Tuomas Tynkkynen
Hi,

On Tue, 13 Feb 2018 23:01:13 +0100
Lukasz Majewski  wrote:

> This commit fixes several issues:
> 
> - After moving env related code to ./env directory the env_common.o file
> is no longer present in the system (has been replaced with built-in.o).
> 
> - Use ${OBJCOPY} if available, fallback to system default's objcopy if not
> present.
> 
> - Extend the script to accept different build directory than current one.
> It is extremely handy with OE usage, where source code is separated from
> build.
> 
> Signed-off-by: Lukasz Majewski 
> ---
> 
>  scripts/get_default_envs.sh | 19 ++-
>  1 file changed, 14 insertions(+), 5 deletions(-)
> 
> diff --git a/scripts/get_default_envs.sh b/scripts/get_default_envs.sh
> index 7955db60e5..bbb6d0a6ef 100755
> --- a/scripts/get_default_envs.sh
> +++ b/scripts/get_default_envs.sh
> @@ -6,16 +6,24 @@
>  #
>  
>  # This file extracts default envs from built u-boot
> -# usage: get_default_envs.sh > u-boot-env-default.txt
> +# usage: get_default_envs.sh [build dir] > u-boot-env-default.txt
>  set -ue
>  
> -ENV_OBJ_FILE="env_common.o"
> +: "${OBJCOPY:=objcopy}"

Maybe "${CROSS_COMPILE}objcopy" would be a better default as that's what
the build system uses.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/1] fs: fat: avoid useless conversion when calling getcluster

2018-02-13 Thread Tuomas Tynkkynen
Hi,

On Tue, 13 Feb 2018 19:18:58 +0100
Heinrich Schuchardt  wrote:

> Parameter size of function get_cluster() is of type unsigned long. It makes
> no sense to convert actsize to int before passing it to get_cluster as
> size.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
>  fs/fat/fat.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/fat/fat.c b/fs/fat/fat.c
> index dd7888cd6d4..a3c7bf604eb 100644
> --- a/fs/fat/fat.c
> +++ b/fs/fat/fat.c
> @@ -353,7 +353,7 @@ static int get_contents(fsdata *mydata, dir_entry 
> *dentptr, loff_t pos,
>   if (pos) {
>   actsize = min(filesize, (loff_t)bytesperclust);
>   if (get_cluster(mydata, curclust, get_contents_vfatname_block,
> - (int)actsize) != 0) {
> + (unsigned long)actsize) != 0) {
>   printf("Error reading cluster\n");

If the type is unsigned long, the explicit cast here seems redundant.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 8/8] spi: Migrate CONFIG_CF_SPI to Kconfig

2018-02-06 Thread Tuomas Tynkkynen
Signed-off-by: Tuomas Tynkkynen <tuo...@tuxera.com>
---
 configs/M52277EVB_defconfig   | 1 +
 configs/M52277EVB_stmicro_defconfig   | 1 +
 configs/M54418TWR_defconfig   | 1 +
 configs/M54418TWR_nand_mii_defconfig  | 1 +
 configs/M54418TWR_nand_rmii_defconfig | 1 +
 configs/M54418TWR_nand_rmii_lowfreq_defconfig | 1 +
 configs/M54418TWR_serial_mii_defconfig| 1 +
 configs/M54418TWR_serial_rmii_defconfig   | 1 +
 configs/M54451EVB_defconfig   | 1 +
 configs/M54451EVB_stmicro_defconfig   | 1 +
 configs/M54455EVB_a66_defconfig   | 1 +
 configs/M54455EVB_defconfig   | 1 +
 configs/M54455EVB_i66_defconfig   | 1 +
 configs/M54455EVB_intel_defconfig | 1 +
 configs/M54455EVB_stm33_defconfig | 1 +
 configs/stmark2_defconfig | 1 +
 drivers/spi/Kconfig   | 6 ++
 include/configs/M52277EVB.h   | 1 -
 include/configs/M54418TWR.h   | 1 -
 include/configs/M54451EVB.h   | 1 -
 include/configs/M54455EVB.h   | 1 -
 include/configs/stmark2.h | 1 -
 scripts/config_whitelist.txt  | 1 -
 23 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/configs/M52277EVB_defconfig b/configs/M52277EVB_defconfig
index 74ea619008..2c08494e85 100644
--- a/configs/M52277EVB_defconfig
+++ b/configs/M52277EVB_defconfig
@@ -19,3 +19,4 @@ CONFIG_ENV_IS_IN_FLASH=y
 CONFIG_MTD_NOR_FLASH=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_CF_SPI=y
diff --git a/configs/M52277EVB_stmicro_defconfig 
b/configs/M52277EVB_stmicro_defconfig
index 13055c52f5..497902ae3c 100644
--- a/configs/M52277EVB_stmicro_defconfig
+++ b/configs/M52277EVB_stmicro_defconfig
@@ -18,3 +18,4 @@ CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_MTD_NOR_FLASH=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_CF_SPI=y
diff --git a/configs/M54418TWR_defconfig b/configs/M54418TWR_defconfig
index b26c94e060..eaea5d6656 100644
--- a/configs/M54418TWR_defconfig
+++ b/configs/M54418TWR_defconfig
@@ -20,3 +20,4 @@ CONFIG_CMD_CACHE=y
 CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_ATMEL=y
+CONFIG_CF_SPI=y
diff --git a/configs/M54418TWR_nand_mii_defconfig 
b/configs/M54418TWR_nand_mii_defconfig
index cf015333cd..5b54de34a4 100644
--- a/configs/M54418TWR_nand_mii_defconfig
+++ b/configs/M54418TWR_nand_mii_defconfig
@@ -19,3 +19,4 @@ CONFIG_CMD_PING=y
 CONFIG_CMD_CACHE=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_ATMEL=y
+CONFIG_CF_SPI=y
diff --git a/configs/M54418TWR_nand_rmii_defconfig 
b/configs/M54418TWR_nand_rmii_defconfig
index bd36aaabe3..01c06e4c86 100644
--- a/configs/M54418TWR_nand_rmii_defconfig
+++ b/configs/M54418TWR_nand_rmii_defconfig
@@ -19,3 +19,4 @@ CONFIG_CMD_PING=y
 CONFIG_CMD_CACHE=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_ATMEL=y
+CONFIG_CF_SPI=y
diff --git a/configs/M54418TWR_nand_rmii_lowfreq_defconfig 
b/configs/M54418TWR_nand_rmii_lowfreq_defconfig
index 2b9e539e71..1629f90499 100644
--- a/configs/M54418TWR_nand_rmii_lowfreq_defconfig
+++ b/configs/M54418TWR_nand_rmii_lowfreq_defconfig
@@ -19,3 +19,4 @@ CONFIG_CMD_PING=y
 CONFIG_CMD_CACHE=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_ATMEL=y
+CONFIG_CF_SPI=y
diff --git a/configs/M54418TWR_serial_mii_defconfig 
b/configs/M54418TWR_serial_mii_defconfig
index aa21072703..ad40f1de32 100644
--- a/configs/M54418TWR_serial_mii_defconfig
+++ b/configs/M54418TWR_serial_mii_defconfig
@@ -20,3 +20,4 @@ CONFIG_CMD_CACHE=y
 CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_ATMEL=y
+CONFIG_CF_SPI=y
diff --git a/configs/M54418TWR_serial_rmii_defconfig 
b/configs/M54418TWR_serial_rmii_defconfig
index b26c94e060..eaea5d6656 100644
--- a/configs/M54418TWR_serial_rmii_defconfig
+++ b/configs/M54418TWR_serial_rmii_defconfig
@@ -20,3 +20,4 @@ CONFIG_CMD_CACHE=y
 CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_ATMEL=y
+CONFIG_CF_SPI=y
diff --git a/configs/M54451EVB_defconfig b/configs/M54451EVB_defconfig
index d184bca011..00cfecd4e5 100644
--- a/configs/M54451EVB_defconfig
+++ b/configs/M54451EVB_defconfig
@@ -22,3 +22,4 @@ CONFIG_ENV_IS_IN_FLASH=y
 CONFIG_MTD_NOR_FLASH=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_CF_SPI=y
diff --git a/configs/M54451EVB_stmicro_defconfig 
b/configs/M54451EVB_stmicro_defconfig
index 715b2c32a2..06a7e6ac08 100644
--- a/configs/M54451EVB_stmicro_defconfig
+++ b/configs/M54451EVB_stmicro_defconfig
@@ -21,3 +21,4 @@ CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_MTD_NOR_FLASH=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_CF_SPI=y
diff --git a/configs/M54455EVB_a66_defconfig b/configs/M54455EVB_a66_defconfig
index 2027481a2b..06b9e8c56d 100644
--- a/configs/M54455EVB_a66_defconfig
+++ b/configs/M54455EVB_a66_defconfig
@@ -26,3 +26,4 @@ CONFIG_ENV_IS_IN_FLASH=y
 CONFIG_MTD_NOR_FLASH=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_

[U-Boot] [PATCH 6/8] spi: Migrate CONFIG_LPC32XX_SSP to Kconfig

2018-02-06 Thread Tuomas Tynkkynen
Signed-off-by: Tuomas Tynkkynen <tuo...@tuxera.com>
---
 configs/devkit3250_defconfig | 1 +
 configs/work_92105_defconfig | 1 +
 drivers/spi/Kconfig  | 5 +
 include/configs/devkit3250.h | 1 -
 include/configs/work_92105.h | 1 -
 scripts/config_whitelist.txt | 1 -
 6 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/configs/devkit3250_defconfig b/configs/devkit3250_defconfig
index 854ea32105..99e7cb1409 100644
--- a/configs/devkit3250_defconfig
+++ b/configs/devkit3250_defconfig
@@ -37,6 +37,7 @@ CONFIG_SPL_NAND_SIMPLE=y
 CONFIG_PHYLIB=y
 CONFIG_DM_SERIAL=y
 CONFIG_SYS_NS16550=y
+CONFIG_LPC32XX_SSP=y
 CONFIG_USB=y
 CONFIG_USB_STORAGE=y
 CONFIG_OF_LIBFDT=y
diff --git a/configs/work_92105_defconfig b/configs/work_92105_defconfig
index 1fccaacd82..e4d0fd017f 100644
--- a/configs/work_92105_defconfig
+++ b/configs/work_92105_defconfig
@@ -36,3 +36,4 @@ CONFIG_DM_GPIO=y
 CONFIG_PHYLIB=y
 CONFIG_DM_SERIAL=y
 CONFIG_SYS_NS16550=y
+CONFIG_LPC32XX_SSP=y
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index a16faa6dfb..79cd54e10c 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -257,6 +257,11 @@ config TI_QSPI
  Enable the TI Quad-SPI (QSPI) driver for DRA7xx and AM43xx evms.
  This driver support spi flash single, quad and memory reads.
 
+config LPC32XX_SSP
+   bool "LPC32XX SPI Driver"
+   help
+ Enable support for SPI on LPC32xx
+
 config MPC8XX_SPI
bool "MPC8XX SPI Driver"
depends on 8xx
diff --git a/include/configs/devkit3250.h b/include/configs/devkit3250.h
index 526a81a382..af16cbd7a5 100644
--- a/include/configs/devkit3250.h
+++ b/include/configs/devkit3250.h
@@ -64,7 +64,6 @@
 /*
  * SSP/SPI
  */
-#define CONFIG_LPC32XX_SSP
 #define CONFIG_LPC32XX_SSP_TIMEOUT 10
 
 /*
diff --git a/include/configs/work_92105.h b/include/configs/work_92105.h
index 7faab4e073..2e407cc2b6 100644
--- a/include/configs/work_92105.h
+++ b/include/configs/work_92105.h
@@ -125,7 +125,6 @@
  * SSP/SPI/DISPLAY
  */
 
-#define CONFIG_LPC32XX_SSP
 #define CONFIG_LPC32XX_SSP_TIMEOUT 10
 /*
  * Environment
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index daff47b92b..2fa4cf13e4 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -1253,7 +1253,6 @@ CONFIG_LPC32XX_NAND_SLC_WSETUP
 CONFIG_LPC32XX_NAND_SLC_WWIDTH
 CONFIG_LPC32XX_SDRAM_
 CONFIG_LPC32XX_SPL
-CONFIG_LPC32XX_SSP
 CONFIG_LPC32XX_SSP_TIMEOUT
 CONFIG_LPC_BASE
 CONFIG_LPC_IO_BASE
-- 
2.16.1

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


[U-Boot] [PATCH 4/8] spi: Migrate CONFIG_MXC_SPI to Kconfig

2018-02-06 Thread Tuomas Tynkkynen
Signed-off-by: Tuomas Tynkkynen <tuo...@tuxera.com>
---
 README| 5 -
 configs/aristainetos2_defconfig   | 1 +
 configs/aristainetos2b_defconfig  | 1 +
 configs/aristainetos_defconfig| 1 +
 configs/cgtqmx6eval_defconfig | 1 +
 configs/cl-som-imx7_defconfig | 1 +
 configs/cm_fx6_defconfig  | 1 +
 configs/dh_imx6_defconfig | 1 +
 configs/display5_defconfig| 1 +
 configs/display5_factory_defconfig| 1 +
 configs/dms-ba16-1g_defconfig | 1 +
 configs/dms-ba16_defconfig| 1 +
 configs/flea3_defconfig   | 1 +
 configs/ge_b450v3_defconfig   | 1 +
 configs/ge_b650v3_defconfig   | 1 +
 configs/ge_b850v3_defconfig   | 1 +
 configs/imx31_phycore_eet_defconfig   | 1 +
 configs/marsboard_defconfig   | 1 +
 configs/mccmon6_nor_defconfig | 1 +
 configs/mccmon6_sd_defconfig  | 1 +
 configs/mx31ads_defconfig | 1 +
 configs/mx31pdk_defconfig | 1 +
 configs/mx35pdk_defconfig | 1 +
 configs/mx51evk_defconfig | 1 +
 configs/mx6qsabrelite_defconfig   | 1 +
 configs/mx6sabreauto_defconfig| 1 +
 configs/mx6sabresd_defconfig  | 1 +
 configs/mx6slevk_defconfig| 1 +
 configs/mx6slevk_spinor_defconfig | 1 +
 configs/mx6slevk_spl_defconfig| 1 +
 configs/nitrogen6dl2g_defconfig   | 1 +
 configs/nitrogen6dl_defconfig | 1 +
 configs/nitrogen6q2g_defconfig| 1 +
 configs/nitrogen6q_defconfig  | 1 +
 configs/nitrogen6s1g_defconfig| 1 +
 configs/nitrogen6s_defconfig  | 1 +
 configs/ot1200_defconfig  | 1 +
 configs/ot1200_spl_defconfig  | 1 +
 configs/pcm058_defconfig  | 1 +
 configs/pfla02_defconfig  | 1 +
 configs/riotboard_defconfig   | 1 +
 configs/tqma6dl_mba6_mmc_defconfig| 1 +
 configs/tqma6dl_mba6_spi_defconfig| 1 +
 configs/tqma6q_mba6_mmc_defconfig | 1 +
 configs/tqma6q_mba6_spi_defconfig | 1 +
 configs/tqma6s_mba6_mmc_defconfig | 1 +
 configs/tqma6s_mba6_spi_defconfig | 1 +
 configs/ts4800_defconfig  | 1 +
 configs/woodburn_defconfig| 1 +
 configs/woodburn_sd_defconfig | 1 +
 configs/zc5202_defconfig  | 1 +
 configs/zc5601_defconfig  | 1 +
 drivers/spi/Kconfig   | 6 ++
 include/configs/advantech_dms-ba16.h  | 1 -
 include/configs/aristainetos-common.h | 1 -
 include/configs/cgtqmx6eval.h | 1 -
 include/configs/cl-som-imx7.h | 1 -
 include/configs/cm_fx6.h  | 1 -
 include/configs/dh_imx6.h | 1 -
 include/configs/display5.h| 1 -
 include/configs/el6x_common.h | 1 -
 include/configs/embestmx6boards.h | 1 -
 include/configs/flea3.h   | 1 -
 include/configs/ge_bx50v3.h   | 1 -
 include/configs/gw_ventana.h  | 1 -
 include/configs/imx31_phycore.h   | 1 -
 include/configs/mccmon6.h | 1 -
 include/configs/mx31ads.h | 1 -
 include/configs/mx31pdk.h | 1 -
 include/configs/mx35pdk.h | 1 -
 include/configs/mx51evk.h | 6 --
 include/configs/mx6sabre_common.h | 1 -
 include/configs/mx6slevk.h| 1 -
 include/configs/nitrogen6x.h  | 1 -
 include/configs/ot1200.h  | 1 -
 include/configs/pcm058.h  | 1 -
 include/configs/pfla02.h  | 1 -
 include/configs/tqma6.h   | 3 ---
 include/configs/tqma6_wru4.h  | 6 --
 include/configs/ts4800.h  | 1 -
 include/configs/woodburn_common.h | 1 -
 scripts/config_whitelist.txt  | 1 -
 82 files changed, 57 insertions(+), 46 deletions(-)

diff --git a/README b/README
index 4044e8575f..0cec47dadf 100644
--- a/README
+++ b/README
@@ -2019,11 +2019,6 @@ The following options need to be configured:
Currently supported on some MPC8xxx processors.  For an
example, see include/configs/mpc8349emds.h.
 
-   CONFIG_MXC_SPI
-
-   Enables the driver for the SPI controllers on i.MX and MXC
-   SoCs. Currently i.MX31/35/51 are supported.
-
CONFIG_SYS_SPI_MXC_WAIT
Timeout for waiting until spi transfer completed.
default: (CONFIG_SYS_HZ/100) /* 10 ms */
diff --git a/configs/aristainetos2_defconfig b/configs/aristainetos2_defconfig
index 288dab0d3c..12fbc61dd1 100644
--- a/configs/aristainetos2_defconfig
+++ b/configs/aristainetos2_defconfig
@@ -39,6 +39,7 @@ CONFIG_PHYLIB=y
 CONFIG_PHY_MICREL=y
 CONFIG_PHY_MICREL_KSZ90X1=y
 CONFIG_NETDEVICES=y
+CONFIG_MXC_SPI=y
 CONFIG_USB=y
 CONFIG_USB_STORAGE=y
 CONFIG_VIDEO=y
diff --git a/configs/aristainetos2b_defconfig b/configs/aristainetos2b_defconfig
index 115ae07ad6..d14edd8372 100644
--- a/configs/aristainetos2b_defconfig
+++ b/c

[U-Boot] [PATCH 7/8] spi: Migrate CONFIG_KIRKWOOD_SPI to Kconfig

2018-02-06 Thread Tuomas Tynkkynen
Signed-off-by: Tuomas Tynkkynen <tuo...@tuxera.com>
---
 arch/arm/mach-kirkwood/include/mach/config.h | 1 -
 arch/arm/mach-mvebu/include/mach/config.h| 1 -
 configs/clearfog_defconfig   | 1 +
 configs/controlcenterdc_defconfig| 1 +
 configs/d2net_v2_defconfig   | 1 +
 configs/db-88f6720_defconfig | 1 +
 configs/db-88f6820-amc_defconfig | 1 +
 configs/db-88f6820-gp_defconfig  | 1 +
 configs/db-mv784mp-gp_defconfig  | 1 +
 configs/dreamplug_defconfig  | 1 +
 configs/ds109_defconfig  | 1 +
 configs/ds414_defconfig  | 1 +
 configs/inetspace_v2_defconfig   | 1 +
 configs/km_kirkwood_128m16_defconfig | 1 +
 configs/km_kirkwood_defconfig| 1 +
 configs/km_kirkwood_pci_defconfig| 1 +
 configs/kmcoge5un_defconfig  | 1 +
 configs/kmnusa_defconfig | 1 +
 configs/kmsugp1_defconfig| 1 +
 configs/kmsuv31_defconfig| 1 +
 configs/lschlv2_defconfig| 1 +
 configs/lsxhl_defconfig  | 1 +
 configs/maxbcm_defconfig | 1 +
 configs/mgcoge3un_defconfig  | 1 +
 configs/mvebu_db_armada8k_defconfig  | 1 +
 configs/mvebu_mcbin-88f8040_defconfig| 1 +
 configs/net2big_v2_defconfig | 1 +
 configs/netspace_lite_v2_defconfig   | 1 +
 configs/netspace_max_v2_defconfig| 1 +
 configs/netspace_mini_v2_defconfig   | 1 +
 configs/netspace_v2_defconfig| 1 +
 configs/portl2_defconfig | 1 +
 configs/theadorable_debug_defconfig  | 1 +
 configs/turris_omnia_defconfig   | 1 +
 drivers/spi/Kconfig  | 6 ++
 include/configs/dreamplug.h  | 1 -
 include/configs/ds109.h  | 1 -
 include/configs/mvebu_armada-8k.h| 1 -
 scripts/config_whitelist.txt | 1 -
 39 files changed, 38 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-kirkwood/include/mach/config.h 
b/arch/arm/mach-kirkwood/include/mach/config.h
index efa4e7b6e2..9d6ad5387c 100644
--- a/arch/arm/mach-kirkwood/include/mach/config.h
+++ b/arch/arm/mach-kirkwood/include/mach/config.h
@@ -61,7 +61,6 @@
  */
 #ifdef CONFIG_CMD_SF
 #define CONFIG_HARD_SPI1
-#define CONFIG_KIRKWOOD_SPI1
 #ifndef CONFIG_ENV_SPI_BUS
 # define CONFIG_ENV_SPI_BUS0
 #endif
diff --git a/arch/arm/mach-mvebu/include/mach/config.h 
b/arch/arm/mach-mvebu/include/mach/config.h
index cfd0952470..a3b12eaa00 100644
--- a/arch/arm/mach-mvebu/include/mach/config.h
+++ b/arch/arm/mach-mvebu/include/mach/config.h
@@ -56,7 +56,6 @@
  * SPI Flash configuration
  */
 #ifdef CONFIG_CMD_SF
-#define CONFIG_KIRKWOOD_SPI
 #ifndef CONFIG_ENV_SPI_BUS
 # define CONFIG_ENV_SPI_BUS0
 #endif
diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig
index 7161518715..6fb4d07935 100644
--- a/configs/clearfog_defconfig
+++ b/configs/clearfog_defconfig
@@ -44,6 +44,7 @@ CONFIG_DEBUG_UART_BASE=0xd0012000
 CONFIG_DEBUG_UART_CLOCK=25000
 CONFIG_DEBUG_UART_SHIFT=2
 CONFIG_SYS_NS16550=y
+CONFIG_KIRKWOOD_SPI=y
 CONFIG_USB=y
 CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
diff --git a/configs/controlcenterdc_defconfig 
b/configs/controlcenterdc_defconfig
index 856591e2c8..786f1a21eb 100644
--- a/configs/controlcenterdc_defconfig
+++ b/configs/controlcenterdc_defconfig
@@ -53,6 +53,7 @@ CONFIG_DEBUG_UART_BASE=0xd0012000
 CONFIG_DEBUG_UART_CLOCK=25000
 CONFIG_DEBUG_UART_SHIFT=2
 CONFIG_SYS_NS16550=y
+CONFIG_KIRKWOOD_SPI=y
 CONFIG_TPM_ATMEL_TWI=y
 CONFIG_TPM_AUTH_SESSIONS=y
 CONFIG_TPM_FLUSH_RESOURCES=y
diff --git a/configs/d2net_v2_defconfig b/configs/d2net_v2_defconfig
index 61fd892005..ca377cf631 100644
--- a/configs/d2net_v2_defconfig
+++ b/configs/d2net_v2_defconfig
@@ -31,6 +31,7 @@ CONFIG_MVSATA_IDE=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SYS_NS16550=y
+CONFIG_KIRKWOOD_SPI=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_STORAGE=y
diff --git a/configs/db-88f6720_defconfig b/configs/db-88f6720_defconfig
index 0dbbe77aed..8a0c0ec25d 100644
--- a/configs/db-88f6720_defconfig
+++ b/configs/db-88f6720_defconfig
@@ -46,6 +46,7 @@ CONFIG_DEBUG_UART_BASE=0xf1012000
 CONFIG_DEBUG_UART_CLOCK=25000
 CONFIG_DEBUG_UART_SHIFT=2
 CONFIG_SYS_NS16550=y
+CONFIG_KIRKWOOD_SPI=y
 CONFIG_USB=y
 CONFIG_DM_USB=y
 CONFIG_USB_EHCI_HCD=y
diff --git a/configs/db-88f6820-amc_defconfig b/configs/db-88f6820-amc_defconfig
index abd793c2c1..e361cebd1e 100644
--- a/configs/db-88f6820-amc_defconfig
+++ b/configs/db-88f6820-amc_defconfig
@@ -53,6 +53,7 @@ CONFIG_DEBUG_UART_BASE=0xd0012000
 CONFIG_DEBUG_UART_CLOCK=2
 CONFIG_DEBUG_UART_SHIFT=2
 CONFIG_SYS_NS16550=y
+CONFIG_KIRKWOOD_SPI=y
 CONFIG_USB=y
 CONFIG_DM_USB=y
 CONFIG_USB_EH

[U-Boot] [PATCH 5/8] spi: Migrate CONFIG_MPC8XXX_SPI to Kconfig

2018-02-06 Thread Tuomas Tynkkynen
Signed-off-by: Tuomas Tynkkynen <tuo...@tuxera.com>
---
 configs/MPC8349EMDS_defconfig | 1 +
 configs/ids8313_defconfig | 1 +
 drivers/spi/Kconfig   | 5 +
 include/configs/MPC8349EMDS.h | 1 -
 include/configs/ids8313.h | 1 -
 scripts/config_whitelist.txt  | 1 -
 6 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/configs/MPC8349EMDS_defconfig b/configs/MPC8349EMDS_defconfig
index 49542ca59c..9404d41552 100644
--- a/configs/MPC8349EMDS_defconfig
+++ b/configs/MPC8349EMDS_defconfig
@@ -16,4 +16,5 @@ CONFIG_MTD_NOR_FLASH=y
 CONFIG_PHYLIB=y
 # CONFIG_PCI is not set
 CONFIG_SYS_NS16550=y
+CONFIG_MPC8XXX_SPI=y
 CONFIG_OF_LIBFDT=y
diff --git a/configs/ids8313_defconfig b/configs/ids8313_defconfig
index 839dfbac8f..362aee2e80 100644
--- a/configs/ids8313_defconfig
+++ b/configs/ids8313_defconfig
@@ -34,4 +34,5 @@ CONFIG_MTD_NOR_FLASH=y
 CONFIG_PHYLIB=y
 # CONFIG_PCI is not set
 CONFIG_SYS_NS16550=y
+CONFIG_MPC8XXX_SPI=y
 CONFIG_OF_LIBFDT=y
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index e7e1ccd73a..a16faa6dfb 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -263,6 +263,11 @@ config MPC8XX_SPI
help
  Enable support for SPI on MPC8XX
 
+config MPC8XXX_SPI
+   bool "MPC8XXX SPI Driver"
+   help
+ Enable support for SPI on the MPC8XXX PowerPC SoCs.
+
 config MXC_SPI
bool "MXC SPI Driver"
help
diff --git a/include/configs/MPC8349EMDS.h b/include/configs/MPC8349EMDS.h
index c7a5ee0aaf..411fdcc19d 100644
--- a/include/configs/MPC8349EMDS.h
+++ b/include/configs/MPC8349EMDS.h
@@ -332,7 +332,6 @@
 #define CONFIG_SYS_I2C_NOPROBES{ {0, 0x69} }
 
 /* SPI */
-#define CONFIG_MPC8XXX_SPI
 #undef CONFIG_SOFT_SPI /* SPI bit-banged */
 
 /* GPIOs.  Used as SPI chip selects */
diff --git a/include/configs/ids8313.h b/include/configs/ids8313.h
index 12eb07d1f7..0b5b4a5c75 100644
--- a/include/configs/ids8313.h
+++ b/include/configs/ids8313.h
@@ -285,7 +285,6 @@
  * SPI setup
  */
 #ifdef CONFIG_HARD_SPI
-#define CONFIG_MPC8XXX_SPI
 #define CONFIG_SYS_GPIO1_PRELIM
 #define CONFIG_SYS_GPIO1_DIR   0x0001
 #define CONFIG_SYS_GPIO1_DAT   0x0001
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index 125634e245..daff47b92b 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -1372,7 +1372,6 @@ CONFIG_MPC83XX_PCI2
 CONFIG_MPC85XX_FEC
 CONFIG_MPC85XX_FEC_NAME
 CONFIG_MPC85XX_PCI2
-CONFIG_MPC8XXX_SPI
 CONFIG_MPC8xxx_DISABLE_BPTR
 CONFIG_MPLL_FREQ
 CONFIG_MP_CLK_FREQ
-- 
2.16.1

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


[U-Boot] [PATCH 3/8] spi: Migrate CONFIG_MXS_SPI to Kconfig

2018-02-06 Thread Tuomas Tynkkynen
Signed-off-by: Tuomas Tynkkynen <tuo...@tuxera.com>
---
 configs/bg0900_defconfig| 1 +
 configs/m28evk_defconfig| 1 +
 configs/mx28evk_auart_console_defconfig | 1 +
 configs/mx28evk_defconfig   | 1 +
 configs/mx28evk_nand_defconfig  | 1 +
 configs/mx28evk_spi_defconfig   | 1 +
 drivers/spi/Kconfig | 6 ++
 include/configs/mxs.h   | 1 -
 scripts/config_whitelist.txt| 1 -
 9 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/configs/bg0900_defconfig b/configs/bg0900_defconfig
index 72616ae5e5..cf2abc6b4c 100644
--- a/configs/bg0900_defconfig
+++ b/configs/bg0900_defconfig
@@ -29,4 +29,5 @@ CONFIG_DOS_PARTITION=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_MXS_SPI=y
 CONFIG_OF_LIBFDT=y
diff --git a/configs/m28evk_defconfig b/configs/m28evk_defconfig
index 3bc6b1835f..dd2d25d251 100644
--- a/configs/m28evk_defconfig
+++ b/configs/m28evk_defconfig
@@ -43,6 +43,7 @@ CONFIG_ENV_IS_IN_NAND=y
 CONFIG_MMC_MXS=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_MXS_SPI=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_STORAGE=y
diff --git a/configs/mx28evk_auart_console_defconfig 
b/configs/mx28evk_auart_console_defconfig
index c4977564e4..c1360f1a50 100644
--- a/configs/mx28evk_auart_console_defconfig
+++ b/configs/mx28evk_auart_console_defconfig
@@ -38,6 +38,7 @@ CONFIG_ENV_IS_IN_MMC=y
 CONFIG_MMC_MXS=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_SST=y
+CONFIG_MXS_SPI=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_STORAGE=y
diff --git a/configs/mx28evk_defconfig b/configs/mx28evk_defconfig
index 40c9df2809..de739e0c37 100644
--- a/configs/mx28evk_defconfig
+++ b/configs/mx28evk_defconfig
@@ -38,6 +38,7 @@ CONFIG_ENV_IS_IN_MMC=y
 CONFIG_MMC_MXS=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_SST=y
+CONFIG_MXS_SPI=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_STORAGE=y
diff --git a/configs/mx28evk_nand_defconfig b/configs/mx28evk_nand_defconfig
index ea97f401d1..103cc8c0c7 100644
--- a/configs/mx28evk_nand_defconfig
+++ b/configs/mx28evk_nand_defconfig
@@ -37,6 +37,7 @@ CONFIG_ENV_IS_IN_NAND=y
 CONFIG_MMC_MXS=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_SST=y
+CONFIG_MXS_SPI=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_STORAGE=y
diff --git a/configs/mx28evk_spi_defconfig b/configs/mx28evk_spi_defconfig
index 34e9927c0f..17bc73030c 100644
--- a/configs/mx28evk_spi_defconfig
+++ b/configs/mx28evk_spi_defconfig
@@ -37,6 +37,7 @@ CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_MMC_MXS=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_SST=y
+CONFIG_MXS_SPI=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_STORAGE=y
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index a1f9373af1..686105c0e2 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -263,6 +263,12 @@ config MPC8XX_SPI
help
  Enable support for SPI on MPC8XX
 
+config MXS_SPI
+   bool "MXS SPI Driver"
+   help
+ Enable the MXS SPI controller driver. This driver can be used
+ on the i.MX23 and i.MX28 SoCs.
+
 config OMAP3_SPI
bool "McSPI driver for OMAP"
help
diff --git a/include/configs/mxs.h b/include/configs/mxs.h
index 3a27c15060..5beea7fcea 100644
--- a/include/configs/mxs.h
+++ b/include/configs/mxs.h
@@ -150,7 +150,6 @@
 /* SPI */
 #ifdef CONFIG_CMD_SPI
 #define CONFIG_HARD_SPI
-#define CONFIG_MXS_SPI
 #define CONFIG_SPI_HALF_DUPLEX
 #endif
 
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index 052031e1be..1b43512bc8 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -1444,7 +1444,6 @@ CONFIG_MXS_AUART
 CONFIG_MXS_AUART_BASE
 CONFIG_MXS_GPIO
 CONFIG_MXS_OCOTP
-CONFIG_MXS_SPI
 CONFIG_MX_CYCLIC
 CONFIG_MY_OPTION
 CONFIG_NANDFLASH_SIZE
-- 
2.16.1

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


[U-Boot] [PATCH 2/8] spi: Migrate CONFIG_SH_QSPI to Kconfig

2018-02-06 Thread Tuomas Tynkkynen
Signed-off-by: Tuomas Tynkkynen <tuo...@tuxera.com>
---
 configs/alt_defconfig| 1 +
 configs/gose_defconfig   | 1 +
 configs/koelsch_defconfig| 1 +
 configs/lager_defconfig  | 1 +
 configs/porter_defconfig | 1 +
 configs/silk_defconfig   | 1 +
 configs/stout_defconfig  | 1 +
 drivers/spi/Kconfig  | 6 ++
 include/configs/alt.h| 1 -
 include/configs/blanche.h| 1 -
 include/configs/gose.h   | 1 -
 include/configs/koelsch.h| 1 -
 include/configs/lager.h  | 1 -
 include/configs/porter.h | 1 -
 include/configs/silk.h   | 1 -
 include/configs/stout.h  | 1 -
 scripts/config_whitelist.txt | 1 -
 17 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/configs/alt_defconfig b/configs/alt_defconfig
index 49f838e01a..58d849073a 100644
--- a/configs/alt_defconfig
+++ b/configs/alt_defconfig
@@ -32,6 +32,7 @@ CONFIG_NETDEVICES=y
 CONFIG_SH_ETHER=y
 CONFIG_BAUDRATE=38400
 CONFIG_SCIF_CONSOLE=y
+CONFIG_SH_QSPI=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_STORAGE=y
diff --git a/configs/gose_defconfig b/configs/gose_defconfig
index 2c0fd0bee5..ea68887249 100644
--- a/configs/gose_defconfig
+++ b/configs/gose_defconfig
@@ -32,6 +32,7 @@ CONFIG_NETDEVICES=y
 CONFIG_SH_ETHER=y
 CONFIG_BAUDRATE=38400
 CONFIG_SCIF_CONSOLE=y
+CONFIG_SH_QSPI=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_STORAGE=y
diff --git a/configs/koelsch_defconfig b/configs/koelsch_defconfig
index 65e96e69de..31993b0824 100644
--- a/configs/koelsch_defconfig
+++ b/configs/koelsch_defconfig
@@ -32,6 +32,7 @@ CONFIG_NETDEVICES=y
 CONFIG_SH_ETHER=y
 CONFIG_BAUDRATE=38400
 CONFIG_SCIF_CONSOLE=y
+CONFIG_SH_QSPI=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_STORAGE=y
diff --git a/configs/lager_defconfig b/configs/lager_defconfig
index e5a6244512..3acca7a5ab 100644
--- a/configs/lager_defconfig
+++ b/configs/lager_defconfig
@@ -32,6 +32,7 @@ CONFIG_NETDEVICES=y
 CONFIG_SH_ETHER=y
 CONFIG_BAUDRATE=38400
 CONFIG_SCIF_CONSOLE=y
+CONFIG_SH_QSPI=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_STORAGE=y
diff --git a/configs/porter_defconfig b/configs/porter_defconfig
index 614ee608e7..13dd65d040 100644
--- a/configs/porter_defconfig
+++ b/configs/porter_defconfig
@@ -48,6 +48,7 @@ CONFIG_DM_REGULATOR=y
 CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_DM_REGULATOR_GPIO=y
 CONFIG_SCIF_CONSOLE=y
+CONFIG_SH_QSPI=y
 CONFIG_USB=y
 CONFIG_DM_USB=y
 CONFIG_USB_EHCI_HCD=y
diff --git a/configs/silk_defconfig b/configs/silk_defconfig
index 81d449cb98..dc898eb370 100644
--- a/configs/silk_defconfig
+++ b/configs/silk_defconfig
@@ -32,6 +32,7 @@ CONFIG_NETDEVICES=y
 CONFIG_SH_ETHER=y
 CONFIG_BAUDRATE=38400
 CONFIG_SCIF_CONSOLE=y
+CONFIG_SH_QSPI=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_STORAGE=y
diff --git a/configs/stout_defconfig b/configs/stout_defconfig
index 99574c3134..fc5f3a24c3 100644
--- a/configs/stout_defconfig
+++ b/configs/stout_defconfig
@@ -32,6 +32,7 @@ CONFIG_NETDEVICES=y
 CONFIG_SH_ETHER=y
 CONFIG_BAUDRATE=38400
 CONFIG_SCIF_CONSOLE=y
+CONFIG_SH_QSPI=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_STORAGE=y
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 3d2cd2db00..a1f9373af1 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -245,6 +245,12 @@ config SH_SPI
  Enable the SuperH SPI controller driver. This driver can be used
  on various SuperH SoCs, such as SH7757.
 
+config SH_QSPI
+   bool "Renesas Quad SPI driver"
+   help
+ Enable the Renesas Quad SPI controller driver. This driver can be
+ used on Renesas SoCs.
+
 config TI_QSPI
bool "TI QSPI driver"
help
diff --git a/include/configs/alt.h b/include/configs/alt.h
index 84fc705a04..f9926b01a3 100644
--- a/include/configs/alt.h
+++ b/include/configs/alt.h
@@ -39,7 +39,6 @@
 
 /* FLASH */
 #define CONFIG_SPI
-#define CONFIG_SH_QSPI
 #define CONFIG_SPI_FLASH_QUAD
 
 /* SH Ether */
diff --git a/include/configs/blanche.h b/include/configs/blanche.h
index 4948bbb063..f2bbfca8b8 100755
--- a/include/configs/blanche.h
+++ b/include/configs/blanche.h
@@ -40,7 +40,6 @@
 #if !defined(CONFIG_MTD_NOR_FLASH)
 #define CONFIG_SYS_TEXT_BASE   0x4000
 #define CONFIG_SPI
-#define CONFIG_SH_QSPI
 #define CONFIG_SH_QSPI_BASE0xE6B1
 #else
 #define CONFIG_SYS_TEXT_BASE   0x
diff --git a/include/configs/gose.h b/include/configs/gose.h
index dcd2130080..dccea0962f 100644
--- a/include/configs/gose.h
+++ b/include/configs/gose.h
@@ -40,7 +40,6 @@
 
 /* FLASH */
 #define CONFIG_SPI
-#define CONFIG_SH_QSPI
 
 /* SH Ether */
 #define CONFIG_SH_ETHER_USE_PORT   0
diff --git a/include/configs/koelsch.h b/include/configs/koelsch.h
index f1571a4576..ca644395f9 100644
--- a/include/configs/koelsch.h
+++ b/include/configs/koelsch.h
@@ -40,7 +40,6 @@
 
 /* FLASH */
 #define CONFIG_SPI
-#define CONFIG_SH_QSPI
 
 /* SH Ether */
 #define CONFIG_SH_ETHER_USE_PORT   0
diff --git a/include/configs/lager.h

[U-Boot] [PATCH 0/8] Migrate SPI drivers to Kconfig

2018-02-06 Thread Tuomas Tynkkynen
Hi all,

This series migrates all the SPI drivers listed in drivers/spi/Makefile
to Kconfig.

Nothing else besides the usual moveconfig.py has been done, so please
let me know if there's something to improve on.

Tuomas Tynkkynen (8):
  spi: Migrate CONFIG_SH_SPI to Kconfig
  spi: Migrate CONFIG_SH_QSPI to Kconfig
  spi: Migrate CONFIG_MXS_SPI to Kconfig
  spi: Migrate CONFIG_MXC_SPI to Kconfig
  spi: Migrate CONFIG_MPC8XXX_SPI to Kconfig
  spi: Migrate CONFIG_LPC32XX_SSP to Kconfig
  spi: Migrate CONFIG_KIRKWOOD_SPI to Kconfig
  spi: Migrate CONFIG_CF_SPI to Kconfig

 README| 10 --
 arch/arm/mach-kirkwood/include/mach/config.h  |  1 -
 arch/arm/mach-mvebu/include/mach/config.h |  1 -
 configs/M52277EVB_defconfig   |  1 +
 configs/M52277EVB_stmicro_defconfig   |  1 +
 configs/M54418TWR_defconfig   |  1 +
 configs/M54418TWR_nand_mii_defconfig  |  1 +
 configs/M54418TWR_nand_rmii_defconfig |  1 +
 configs/M54418TWR_nand_rmii_lowfreq_defconfig |  1 +
 configs/M54418TWR_serial_mii_defconfig|  1 +
 configs/M54418TWR_serial_rmii_defconfig   |  1 +
 configs/M54451EVB_defconfig   |  1 +
 configs/M54451EVB_stmicro_defconfig   |  1 +
 configs/M54455EVB_a66_defconfig   |  1 +
 configs/M54455EVB_defconfig   |  1 +
 configs/M54455EVB_i66_defconfig   |  1 +
 configs/M54455EVB_intel_defconfig |  1 +
 configs/M54455EVB_stm33_defconfig |  1 +
 configs/MPC8349EMDS_defconfig |  1 +
 configs/alt_defconfig |  1 +
 configs/aristainetos2_defconfig   |  1 +
 configs/aristainetos2b_defconfig  |  1 +
 configs/aristainetos_defconfig|  1 +
 configs/bg0900_defconfig  |  1 +
 configs/cgtqmx6eval_defconfig |  1 +
 configs/cl-som-imx7_defconfig |  1 +
 configs/clearfog_defconfig|  1 +
 configs/cm_fx6_defconfig  |  1 +
 configs/controlcenterdc_defconfig |  1 +
 configs/d2net_v2_defconfig|  1 +
 configs/db-88f6720_defconfig  |  1 +
 configs/db-88f6820-amc_defconfig  |  1 +
 configs/db-88f6820-gp_defconfig   |  1 +
 configs/db-mv784mp-gp_defconfig   |  1 +
 configs/devkit3250_defconfig  |  1 +
 configs/dh_imx6_defconfig |  1 +
 configs/display5_defconfig|  1 +
 configs/display5_factory_defconfig|  1 +
 configs/dms-ba16-1g_defconfig |  1 +
 configs/dms-ba16_defconfig|  1 +
 configs/dreamplug_defconfig   |  1 +
 configs/ds109_defconfig   |  1 +
 configs/ds414_defconfig   |  1 +
 configs/flea3_defconfig   |  1 +
 configs/ge_b450v3_defconfig   |  1 +
 configs/ge_b650v3_defconfig   |  1 +
 configs/ge_b850v3_defconfig   |  1 +
 configs/gose_defconfig|  1 +
 configs/ids8313_defconfig |  1 +
 configs/imx31_phycore_eet_defconfig   |  1 +
 configs/inetspace_v2_defconfig|  1 +
 configs/km_kirkwood_128m16_defconfig  |  1 +
 configs/km_kirkwood_defconfig |  1 +
 configs/km_kirkwood_pci_defconfig |  1 +
 configs/kmcoge5un_defconfig   |  1 +
 configs/kmnusa_defconfig  |  1 +
 configs/kmsugp1_defconfig |  1 +
 configs/kmsuv31_defconfig |  1 +
 configs/koelsch_defconfig |  1 +
 configs/lager_defconfig   |  1 +
 configs/lschlv2_defconfig |  1 +
 configs/lsxhl_defconfig   |  1 +
 configs/m28evk_defconfig  |  1 +
 configs/marsboard_defconfig   |  1 +
 configs/maxbcm_defconfig  |  1 +
 configs/mccmon6_nor_defconfig |  1 +
 configs/mccmon6_sd_defconfig  |  1 +
 configs/mgcoge3un_defconfig   |  1 +
 configs/mvebu_db_armada8k_defconfig   |  1 +
 configs/mvebu_mcbin-88f8040_defconfig |  1 +
 configs/mx28evk_auart_console_defconfig   |  1 +
 configs/mx28evk_defconfig |  1 +
 configs/mx28evk_nand_defconfig|  1 +
 configs/mx28evk_spi_defconfig |  1 +
 configs/mx31ads_defconfig |  1 +
 configs/mx31pdk_defconfig |  1 +
 configs/mx35pdk_defconfig |  1 +
 configs/mx51evk_defconfig |  1 +
 configs/mx6qsabrelite_defconfig   |  1 +
 configs/mx6sabreauto_defconfig|  1 +
 configs/mx6sabresd_defconfig  |  1 +
 configs/mx6slevk_defconfig

[U-Boot] [PATCH 1/8] spi: Migrate CONFIG_SH_SPI to Kconfig

2018-02-06 Thread Tuomas Tynkkynen
Signed-off-by: Tuomas Tynkkynen <tuo...@tuxera.com>
---
 README   | 5 -
 configs/sh7752evb_defconfig  | 1 +
 configs/sh7753evb_defconfig  | 1 +
 configs/sh7757lcr_defconfig  | 1 +
 drivers/spi/Kconfig  | 6 ++
 include/configs/sh7752evb.h  | 1 -
 include/configs/sh7753evb.h  | 1 -
 include/configs/sh7757lcr.h  | 1 -
 scripts/config_whitelist.txt | 1 -
 9 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/README b/README
index b055ae7ef2..4044e8575f 100644
--- a/README
+++ b/README
@@ -2001,11 +2001,6 @@ The following options need to be configured:
SPI EEPROM, also an instance works with Crystal A/D and
D/As on the SACSng board)
 
-   CONFIG_SH_SPI
-
-   Enables the driver for SPI controller on SuperH. Currently
-   only SH7757 is supported.
-
CONFIG_SOFT_SPI
 
Enables a software (bit-bang) SPI driver rather than
diff --git a/configs/sh7752evb_defconfig b/configs/sh7752evb_defconfig
index bbab9c06f3..d56992dc0a 100644
--- a/configs/sh7752evb_defconfig
+++ b/configs/sh7752evb_defconfig
@@ -36,4 +36,5 @@ CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_NETDEVICES=y
 CONFIG_SH_ETHER=y
 CONFIG_SCIF_CONSOLE=y
+CONFIG_SH_SPI=y
 CONFIG_USE_PRIVATE_LIBGCC=y
diff --git a/configs/sh7753evb_defconfig b/configs/sh7753evb_defconfig
index 919e00d5a4..c50285a146 100644
--- a/configs/sh7753evb_defconfig
+++ b/configs/sh7753evb_defconfig
@@ -35,4 +35,5 @@ CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_NETDEVICES=y
 CONFIG_SH_ETHER=y
 CONFIG_SCIF_CONSOLE=y
+CONFIG_SH_SPI=y
 CONFIG_USE_PRIVATE_LIBGCC=y
diff --git a/configs/sh7757lcr_defconfig b/configs/sh7757lcr_defconfig
index e47bbcf175..3a3a8c9e63 100644
--- a/configs/sh7757lcr_defconfig
+++ b/configs/sh7757lcr_defconfig
@@ -35,4 +35,5 @@ CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_NETDEVICES=y
 CONFIG_SH_ETHER=y
 CONFIG_SCIF_CONSOLE=y
+CONFIG_SH_SPI=y
 CONFIG_USE_PRIVATE_LIBGCC=y
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 1e95dc4559..3d2cd2db00 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -239,6 +239,12 @@ config DAVINCI_SPI
help
  Enable the Davinci SPI driver
 
+config SH_SPI
+   bool "SuperH SPI driver"
+   help
+ Enable the SuperH SPI controller driver. This driver can be used
+ on various SuperH SoCs, such as SH7757.
+
 config TI_QSPI
bool "TI QSPI driver"
help
diff --git a/include/configs/sh7752evb.h b/include/configs/sh7752evb.h
index ee57eb2fd1..401c2e550a 100644
--- a/include/configs/sh7752evb.h
+++ b/include/configs/sh7752evb.h
@@ -63,7 +63,6 @@
 #define SH7752EVB_ETHERNET_NUM_CH  2
 
 /* SPI */
-#define CONFIG_SH_SPI  1
 #define CONFIG_SH_SPI_BASE 0xfe002000
 
 /* MMCIF */
diff --git a/include/configs/sh7753evb.h b/include/configs/sh7753evb.h
index e7f9f61974..6db33ed41d 100644
--- a/include/configs/sh7753evb.h
+++ b/include/configs/sh7753evb.h
@@ -63,7 +63,6 @@
 #define SH7753EVB_ETHERNET_NUM_CH  2
 
 /* SPI */
-#define CONFIG_SH_SPI  1
 #define CONFIG_SH_SPI_BASE 0xfe002000
 
 /* MMCIF */
diff --git a/include/configs/sh7757lcr.h b/include/configs/sh7757lcr.h
index a2b3307804..5f720c20e2 100644
--- a/include/configs/sh7757lcr.h
+++ b/include/configs/sh7757lcr.h
@@ -65,7 +65,6 @@
 #define SH7757LCR_GIGA_ETHERNET_NUM_CH 2
 
 /* SPI */
-#define CONFIG_SH_SPI  1
 #define CONFIG_SH_SPI_BASE 0xfe002000
 
 /* MMCIF */
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index ef83c00c1b..dabc171f1e 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -1909,7 +1909,6 @@ CONFIG_SH_QSPI_BASE
 CONFIG_SH_SCIF_CLK_FREQ
 CONFIG_SH_SDHI_FREQ
 CONFIG_SH_SDRAM_OFFSET
-CONFIG_SH_SPI
 CONFIG_SH_SPI_BASE
 CONFIG_SH_TMU_CLK_FREQ
 CONFIG_SIEMENS_DRACO
-- 
2.16.1

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


Re: [U-Boot] [U-Boot, v2, 10/15] dm: mmc: sunxi: Add support for driver model

2018-02-01 Thread Tuomas Tynkkynen
Hi Heinrich,

On Wed, 2018-01-31 at 18:08 +0100, Heinrich Schuchardt wrote:
> On 07/04/2017 09:31 PM, Simon Glass wrote:
> > Add a driver-model version of this driver which mostly uses the
> > existing
> > code. The old code can be removed once all boards are switched
> > over.
> > 
> > Signed-off-by: Simon Glass 
> > ---
> > 
> > Changes in v2:
> > - Drop debugging printf() now that the card detect is working
> 
> Unfortunately card detect is not working on the BananaPi:

Most likely it's the problem of U-Boot interpreting the card detection
DT properties differently from Linux. See this thread for details:

https://patchwork.ozlabs.org/patch/850377/
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 1/2] fpga: Resync various CONFIG_FPGA_* symbols

2018-01-27 Thread Tuomas Tynkkynen
These are declared in Kconfig, but some #defines have crept in.

CONFIG_FPGA
CONFIG_FPGA_ALTERA
CONFIG_FPGA_CYCLON2
CONFIG_FPGA_SOCFPGA
CONFIG_FPGA_XILINX
CONFIG_FPGA_ZYNQMPPL

Signed-off-by: Tuomas Tynkkynen <tuo...@tuxera.com>
---
 configs/apf27_defconfig  | 1 +
 configs/astro_mcf5373l_defconfig | 2 ++
 configs/mt_ventoux_defconfig | 1 +
 configs/x600_defconfig   | 1 +
 include/configs/M54455EVB.h  | 1 -
 include/configs/apf27.h  | 4 
 include/configs/astro_mcf5373l.h | 2 --
 include/configs/mt_ventoux.h | 2 --
 include/configs/x600.h   | 2 --
 9 files changed, 5 insertions(+), 11 deletions(-)

diff --git a/configs/apf27_defconfig b/configs/apf27_defconfig
index f09c5a828b..6949b711fd 100644
--- a/configs/apf27_defconfig
+++ b/configs/apf27_defconfig
@@ -31,6 +31,7 @@ CONFIG_MTDIDS_DEFAULT="nand0=mxc_nand.0"
 
CONFIG_MTDPARTS_DEFAULT="mtdparts=mxc_nand.0:1M(u-boot)ro,512K(env),512K(env2),512K(firmware),512K(dtb),5M(kernel),-(rootfs)"
 CONFIG_CMD_UBI=y
 CONFIG_ENV_IS_IN_NAND=y
+CONFIG_FPGA_XILINX=y
 CONFIG_MMC_MXC=y
 CONFIG_NAND=y
 CONFIG_NAND_MXC=y
diff --git a/configs/astro_mcf5373l_defconfig b/configs/astro_mcf5373l_defconfig
index cababcf990..1e3708fcb5 100644
--- a/configs/astro_mcf5373l_defconfig
+++ b/configs/astro_mcf5373l_defconfig
@@ -16,4 +16,6 @@ CONFIG_CMD_CACHE=y
 CONFIG_CMD_DATE=y
 CONFIG_CMD_JFFS2=y
 CONFIG_FPGA_ALTERA=y
+CONFIG_FPGA_CYCLON2=y
+CONFIG_FPGA_XILINX=y
 CONFIG_MTD_NOR_FLASH=y
diff --git a/configs/mt_ventoux_defconfig b/configs/mt_ventoux_defconfig
index 3dd8adb5ce..c059a49576 100644
--- a/configs/mt_ventoux_defconfig
+++ b/configs/mt_ventoux_defconfig
@@ -31,6 +31,7 @@ CONFIG_MTDIDS_DEFAULT="nand0=omap2-nand.0"
 
CONFIG_MTDPARTS_DEFAULT="mtdparts=omap2-nand.0:512k(MLO),1m(u-boot),256k(env1),256k(env2),8m(ubisystem),-(rootfs)"
 CONFIG_CMD_UBI=y
 CONFIG_ENV_IS_IN_NAND=y
+CONFIG_FPGA_XILINX=y
 CONFIG_MMC_OMAP_HS=y
 CONFIG_NAND=y
 CONFIG_SYS_NAND_BUSWIDTH_16BIT=y
diff --git a/configs/x600_defconfig b/configs/x600_defconfig
index 4658f977a4..18720daafc 100644
--- a/configs/x600_defconfig
+++ b/configs/x600_defconfig
@@ -37,6 +37,7 @@ CONFIG_MTDIDS_DEFAULT="nand0=nand"
 CONFIG_MTDPARTS_DEFAULT="mtdparts=nand:64M(ubi0),64M(ubi1)"
 CONFIG_CMD_UBI=y
 CONFIG_ENV_IS_IN_FLASH=y
+CONFIG_FPGA_XILINX=y
 CONFIG_SYS_I2C_DW=y
 # CONFIG_MMC is not set
 CONFIG_MTD_NOR_FLASH=y
diff --git a/include/configs/M54455EVB.h b/include/configs/M54455EVB.h
index a709fbbf63..c5a0a0371d 100644
--- a/include/configs/M54455EVB.h
+++ b/include/configs/M54455EVB.h
@@ -182,7 +182,6 @@
 
 /* FPGA - Spartan 2 */
 /* experiment
-#define CONFIG_FPGA
 #define CONFIG_FPGA_COUNT  1
 #define CONFIG_SYS_FPGA_PROG_FEEDBACK
 #define CONFIG_SYS_FPGA_CHECK_CTRLC
diff --git a/include/configs/apf27.h b/include/configs/apf27.h
index 24afc84a02..16345ca2b5 100644
--- a/include/configs/apf27.h
+++ b/include/configs/apf27.h
@@ -215,11 +215,7 @@
 /*
  * FPGA
  */
-#ifndef CONFIG_SPL_BUILD
-#define CONFIG_FPGA
-#endif
 #define CONFIG_FPGA_COUNT  1
-#define CONFIG_FPGA_XILINX
 #define CONFIG_FPGA_SPARTAN3
 #define CONFIG_SYS_FPGA_WAIT   250 /* 250 ms */
 #define CONFIG_SYS_FPGA_PROG_FEEDBACK
diff --git a/include/configs/astro_mcf5373l.h b/include/configs/astro_mcf5373l.h
index 540db79a27..c8d5c1bd3d 100644
--- a/include/configs/astro_mcf5373l.h
+++ b/include/configs/astro_mcf5373l.h
@@ -177,9 +177,7 @@
 #define CONFIG_SYS_LONGHELP
 
 #define CONFIG_FPGA_COUNT  1
-#defineCONFIG_FPGA_XILINX
 #defineCONFIG_FPGA_SPARTAN3
-#define CONFIG_FPGA_CYCLON2
 #define CONFIG_SYS_FPGA_PROG_FEEDBACK
 #define CONFIG_SYS_FPGA_WAIT   1000
 
diff --git a/include/configs/mt_ventoux.h b/include/configs/mt_ventoux.h
index 11ba3e752a..bee8ddd4f2 100644
--- a/include/configs/mt_ventoux.h
+++ b/include/configs/mt_ventoux.h
@@ -33,8 +33,6 @@
 /*
  * FPGA
  */
-#define CONFIG_FPGA
-#define CONFIG_FPGA_XILINX
 #define CONFIG_FPGA_SPARTAN3
 #define CONFIG_SYS_FPGA_PROG_FEEDBACK
 #define CONFIG_SYS_FPGA_WAIT   1
diff --git a/include/configs/x600.h b/include/configs/x600.h
index 4aa5a2a924..cd3bd94efb 100644
--- a/include/configs/x600.h
+++ b/include/configs/x600.h
@@ -87,8 +87,6 @@
 #define CONFIG_SYS_I2C_RTC_ADDR0x68
 
 /* FPGA config options */
-#define CONFIG_FPGA
-#define CONFIG_FPGA_XILINX
 #define CONFIG_FPGA_SPARTAN3
 #define CONFIG_FPGA_COUNT  1
 
-- 
2.16.1

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


[U-Boot] [PATCH] powerpc: Drop CONFIG_WALNUT and other related dead code

2018-01-21 Thread Tuomas Tynkkynen
CONFIG_WALNUT was dropped in June 2017 in:
commit 98f705c9cefdfd ("powerpc: remove 4xx support")

While at it, the related CONFIG_MACH_SPECIFIC and the have_of
and _machine variables are unused as well, so drop them too.

Signed-off-by: Tuomas Tynkkynen <tuo...@tuxera.com>
---
 arch/powerpc/include/asm/processor.h | 14 --
 cmd/elf.c|  6 +-
 scripts/config_whitelist.txt |  1 -
 3 files changed, 1 insertion(+), 20 deletions(-)

diff --git a/arch/powerpc/include/asm/processor.h 
b/arch/powerpc/include/asm/processor.h
index baf38f8441..57b11b8365 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -1206,11 +1206,6 @@ int fsl_qoriq_dsp_core_to_cluster(unsigned int core);
 #endif
 
 
-#ifndef CONFIG_MACH_SPECIFIC
-extern int _machine;
-extern int have_of;
-#endif /* CONFIG_MACH_SPECIFIC */
-
 /* what kind of prep workstation we are */
 extern int _prep_type;
 /*
@@ -1336,15 +1331,6 @@ int prt_83xx_rsr(void);
 
 #endif /* ndef ASSEMBLY*/
 
-#ifdef CONFIG_MACH_SPECIFIC
-#if defined(CONFIG_WALNUT)
-#define _machine _MACH_walnut
-#define have_of 0
-#else
-#error "Machine not defined correctly"
-#endif
-#endif /* CONFIG_MACH_SPECIFIC */
-
 #if defined(CONFIG_MPC85xx)
  #define EPAPR_MAGIC   (0x45504150)
 #else
diff --git a/cmd/elf.c b/cmd/elf.c
index 5745a389da..5b59fc6329 100644
--- a/cmd/elf.c
+++ b/cmd/elf.c
@@ -240,11 +240,7 @@ int do_bootvx(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
 * from the VxWorks BSP header files.
 * This will vary from board to board
 */
-#if defined(CONFIG_WALNUT)
-   tmp = (char *)CONFIG_SYS_NVRAM_BASE_ADDR + 0x500;
-   eth_env_get_enetaddr("ethaddr", (uchar *)build_buf);
-   memcpy(tmp, _buf[3], 3);
-#elif defined(CONFIG_SYS_VXWORKS_MAC_PTR)
+#if defined(CONFIG_SYS_VXWORKS_MAC_PTR)
tmp = (char *)CONFIG_SYS_VXWORKS_MAC_PTR;
eth_env_get_enetaddr("ethaddr", (uchar *)build_buf);
memcpy(tmp, build_buf, 6);
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index ec1b51f9b6..9f410dec26 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -1271,7 +1271,6 @@ CONFIG_MACB3_PHY
 CONFIG_MACB_SEARCH_PHY
 CONFIG_MACH_DAVINCI_DA850_EVM
 CONFIG_MACH_OMAPL138_LCDK
-CONFIG_MACH_SPECIFIC
 CONFIG_MACH_TYPE
 CONFIG_MACH_TYPE_COMPAT_REV
 CONFIG_MACRESET_TIMEOUT
-- 
2.15.0

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


  1   2   3   >