date:20150719

STM32F429 has a peculiar arrangement for flash sector size.
Starting at 0x0800, the sectors are (total flash size is 2M):
(4 x 16K) + (1 x 64K) + (7 x 128K) + (4 x 16K) + (1 x 64K) + (7 x 128K)

Current U-Boot code for STM32F429 uses the following flash layout:
- 0x0800 : U-Boot (256K)
- 0x0804 : U-Boot env (8K)
- 0x08042000 : DTB (8K)
- 0x08044000 : Linux kernel

With this layout, environment, DTB and first part of kernel are in the
same sector of 128K.
U-Boot command saveenv erases the whole sector, deleting both DTB and
kernel!

Splitting environment, DTB and kernel in independent flash sectors is
the correct way to go, but we should avoid wasting big sectors of 128K
for the tiny environment and DTB.

Since the reset entry point is fixed at 0x0800, a good solution is
to use a simple SPL to jump ahead, so the initial small sectors become
available for env and DTB.
But the new flash layout will then look a little upside-down:
- 0x0800 : SPL (16K) - almost only a goto 0x0800c000
- 0x08004000 : U-Boot env (16K)
- 0x08008000 : DTB (16K)
- 0x0800c000 : U-Boot (16K + 64K + 128K)
- 0x0804 : Linux kernel

I have already run some experiment recompiling U-Boot for the new target
address 0x0800c000.
The SPL can be as simple as extracting the first 8 bytes from the binary
of U-Boot compiled for 0x0800c000.
A more complete SPL could print a welcome msg on console, check that the
content at 0x0800c000 is reasonable for a U-Boot binary then either print
an error msg or jump to U-Boot.

Before sending patches, I would like to get confirmation that the
proposed flash layout can be accepted.
Any other target in U-Boot that has similar flash layout constraint?

Also, does it make sense to build a full SPL when a simple
   dd bs=8 count=1 if=u-boot.bin of=spl/u-boot-spl.bin
can already provide a working solution?

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

Re: [U-Boot] [PATCH v2 4/6] mmc: hi6220_dw_mmc: Add hi6220 glue code for dw_mmc controller.

2015-07-19 Thread Peter Griffin

Hi Simon,


On 8 July 2015 at 09:57, Peter Griffin peter.grif...@linaro.org wrote:
  This patch adds the glue code for hi6220 SoC which has 2x synopsis
  dw_mmc controllers. This will be used by the hikey board support
  in subsequent patches.
 
  Signed-off-by: Peter Griffin peter.grif...@linaro.org
  ---

 Reviewed-by: Simon Glass s...@chromium.org

 (see nit below - this could be moved to device tree once you have it)


Thanks for reviewing :)

My plan regarding DT was to wait for it to land in the kernel, and then
convert
over to using it in u-boot.

I saw some of your patches converting Raspberry Pi to DM and DT which
should make migrating HiKey board fairly straight forward, as it shares the
same Synopsis IP for MMC and USB :)


   arch/arm/include/asm/arch-hi6220/dwmmc.h |  8 +
   drivers/mmc/Makefile |  1 +
   drivers/mmc/hi6220_dw_mmc.c  | 56
 
   3 files changed, 65 insertions(+)
   create mode 100644 arch/arm/include/asm/arch-hi6220/dwmmc.h
   create mode 100644 drivers/mmc/hi6220_dw_mmc.c
 
  diff --git a/arch/arm/include/asm/arch-hi6220/dwmmc.h
 b/arch/arm/include/asm/arch-hi6220/dwmmc.h
  new file mode 100644
  index 000..c747383
  --- /dev/null
  +++ b/arch/arm/include/asm/arch-hi6220/dwmmc.h
  @@ -0,0 +1,8 @@
  +/*
  + * (C) Copyright 2015 Linaro
  + * Peter Griffin peter.grif...@linaro.org
  + *
  + * SPDX-License-Identifier:GPL-2.0+
  + */
  +
  +int hi6220_dwmci_add_port(int index, u32 regbase, int bus_width);
  diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
  index ed73687..81a1a8f 100644
  --- a/drivers/mmc/Makefile
  +++ b/drivers/mmc/Makefile
  @@ -11,6 +11,7 @@ obj-$(CONFIG_BFIN_SDH) += bfin_sdh.o
   obj-$(CONFIG_DAVINCI_MMC) += davinci_mmc.o
   obj-$(CONFIG_DWMMC) += dw_mmc.o
   obj-$(CONFIG_EXYNOS_DWMMC) += exynos_dw_mmc.o
  +obj-$(CONFIG_HIKEY_DWMMC) += hi6220_dw_mmc.o
   obj-$(CONFIG_FSL_ESDHC) += fsl_esdhc.o
   obj-$(CONFIG_FTSDC010) += ftsdc010_mci.o
   obj-$(CONFIG_FTSDC021) += ftsdc021_sdhci.o
  diff --git a/drivers/mmc/hi6220_dw_mmc.c b/drivers/mmc/hi6220_dw_mmc.c
  new file mode 100644
  index 000..106f673
  --- /dev/null
  +++ b/drivers/mmc/hi6220_dw_mmc.c
  @@ -0,0 +1,56 @@
  +/*
  + * (C) Copyright 2015 Linaro
  + * peter.griffin peter.grif...@linaro.org
  + *
  + * SPDX-License-Identifier:GPL-2.0+
  + */
  +
  +#include common.h
  +#include dwmmc.h
  +#include malloc.h
  +#include asm-generic/errno.h
  +
  +#defineDWMMC_MAX_CH_NUM4
  +
  +#defineDWMMC_MAX_FREQ  5000
  +#defineDWMMC_MIN_FREQ  378000
  +
  +/* Source clock is configured to 100Mhz by ATF bl1*/

 nit: MHz


Fixed in v3.

regards,

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

Re: [U-Boot] u-boot-with-spl.bin don't include the dtb image when enable CONFIG_OF_SEPARATE

2015-07-19 Thread Hans de Goede


Hi,

On 16-07-15 01:17, Simon Glass wrote:

Hi,

On 15 July 2015 at 02:42, Wang Haikun haikun.w...@freescale.com wrote:

Hi Simon,

It seems that we don't update the source image name to u-boot-dtb.bin in
case of enabling CONFIG_OF_SEPARATE when generate u-boot-with-spl.bin file.


ifdef CONFIG_TPL
SPL_PAYLOAD := tpl/u-boot-with-tpl.bin
else
SPL_PAYLOAD := u-boot.bin
endif

OBJCOPYFLAGS_u-boot-with-spl.bin = -I binary -O binary \
  --pad-to=$(CONFIG_SPL_PAD_TO)
u-boot-with-spl.bin: spl/u-boot-spl.bin $(SPL_PAYLOAD) FORCE
   $(call if_changed,pad_cat)



At least for sunxi this worked for me. But perhaps sunxi is a special
case?


Yes I believe that sunxi has special code for this since we need to run
an utility to add a header to the spl binary.

Regards,

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

Re: [U-Boot] [PATCH] musb: set MUSB speed based on CONFIG

2015-07-19 Thread Hans de Goede


Hi,

On 13-07-15 16:16, Bin Liu wrote:

Hi,

On 07/11/2015 08:04 AM, Hans de Goede wrote:

Hi,

On 10-07-15 17:31, Bin Liu wrote:

Hi,

On 07/10/2015 10:12 AM, Heiko Schocher wrote:

Hello Samuel,

Am 10.07.2015 um 16:50 schrieb Egli, Samuel:

Hi Hans,


-Original Message- From: Hans de Goede
[mailto:hdego...@redhat.com] Sent: Freitag, 10. Juli 2015 16:37
To: Egli, Samuel; ma...@denx.de Cc: u-boot@lists.denx.de;
tr...@konsulko.com; Bin Liu; Meier, Roger; Daniel Mack Subject:
Re: [U-Boot] [PATCH] musb: set MUSB speed based on CONFIG

Hi,

On 10-07-15 16:30, Hans de Goede wrote:

Hi,

On 10-07-15 15:16, Samuel Egli wrote:

From: Bin Liu b-...@ti.com

Do not config MUSB to highspeed mode if
CONFIG_USB_GADGET_DUALSPEED is not set, in which case Ether
gadget only operates in fullspeed.

Note: This patch is necessary for devices like some siemens
boards that allow only FULL SPEED USB 1.1, e.g. DFU
download.

Signed-off-by: Bin Liu b-...@ti.com Reviewed-by: Tom Rini
tr...@konsulko.com Tested-by: Samuel Egli
samuel.e...@siemens.com CC: Marek Vasut ma...@denx.de CC:
Heiko Schocher h...@denx.de CC: Daniel Mack
zon...@gmail.com CC: Roger Meier r.me...@siemens.com


Nack this breaks highspeed mode on boards which use the musb in
host mode, and thus do not set CONFIG_USB_GADGET_DUALSPEED.


My bad, I had a short thought about this when I was initially working on
this patch, but did not really think about it throughly. Thanks for
bring it up.



p.s.

Given that you want to use this as a hack to work around the
broken pcb design of your board I suggest adding a new option for
this


Well, lets not discuss the broken pcb design. It seems that
wiring protection is not that common. Unfortunately, such a
protection is too expensive for USB High speed :-(.


Agreed, we have seen many cases that have nothing to do with hardware
design, but MUSB has to work in full-speed mode.




titled: CONFIG_USB_MUSB_NO_HIGHSPEED and then do:

+#ifndef CONFIG_USB_MUSB_NO_HIGHSPEED | MUSB_POWER_HSENAB
+#endif


This would be good enough. The point is indeed to limit it to full
speed.


Using CONFIG_USB_GADGET_DUALSPEED for this seems wrong, since
this has nothing to do with enabling dualspeed mode for the
gadget code really.


I agree that the name is confusing.


Yes, I vote for Hans suggestion.


*Adding* a new macro CONFIG_USB_MUSB_NO_HIGHSPEED for musb driver causes
CONFIG_USB_GADGET_DUALSPEED redundant, because both control for
full-speed.

I suggest to *rename* CONFIG_USB_GADGET_DUALSPEED to
CONFIG_USB_FULLSPEED_ONLY. So that we can use one macro for both gadget
and musb drivers. Considering supper-speed exists and future, I think
CONFIG_USB_NO_HIGHSPEED is confusing...


Sorry I was too fast. CONFIG_USB_FULLSPEED_ONLY is IMHO not acceptable
as it is not granular enough. sunxi boards have both EHCI/OHCI usb
controller
pairs for host ports and an musb controller. One may be limited to
fullspeed
while the other is not.

Likewise I can see a case where some ports but not all ports are fullspeed
only, so we still want to build the gadged code with dual-speed
descriptors.


Good point.



I really believe that something like:

CONFIG_MUSB_FULLSPEED_ONLY


I am not sure like the idea of using two macros in config.h to control one thing. 
Please review the following patch which uses CONFIG_USB_GADGET_DUALSPEED and 
musb-board_mode instead. Beware that this patch is not tested.


The 2 macros do not control one thing, it is for example perfectly possible
to have multiple otg controllers, one which can only do fullspeed and one
which can do both high/full speed in this case one will want to build
the gadget code in dualspeed mode even though one of the usb controllers
is fullspeed only.

Regards,

Hans








diff --git a/drivers/usb/musb-new/musb_core.c b/drivers/usb/musb-new/musb_core.c
index eeaacdf..55d1c20 100644
--- a/drivers/usb/musb-new/musb_core.c
+++ b/drivers/usb/musb-new/musb_core.c
@@ -931,6 +931,7 @@ void musb_start(struct musb *musb)
  {
 void __iomem*regs = musb-mregs;
 u8  devctl = musb_readb(regs, MUSB_DEVCTL);
+   u8  power;

 dev_dbg(musb-controller, == devctl %02x\n, devctl);

@@ -942,11 +943,12 @@ void musb_start(struct musb *musb)
 musb_writeb(regs, MUSB_TESTMODE, 0);

 /* put into basic highspeed mode and start session */
-   musb_writeb(regs, MUSB_POWER, MUSB_POWER_ISOUPDATE
-   | MUSB_POWER_HSENAB
-   /* ENSUSPEND wedges tusb */
-   /* | MUSB_POWER_ENSUSPEND */
-   );
+   power = MUSB_POWER_ISOUPDATE | MUSB_POWER_HSENAB;
+#ifndef CONFIG_USB_GADGET_DUALSPEED
+   if (musb-board_mode != MUSB_HOST)
+   power = ~MUSB_POWER_HSENAB;
+#endif
+   musb_writeb(regs, MUSB_POWER, power);

 musb-is_active = 0;
 devctl =

Re: [U-Boot] [Reproducible-builds] [PATCH] build: create time and date independent binary

2015-07-19 Thread Vagrant Cascadian

On 2015-07-19, Holger Levsen wrote:
  All this said, if you send me patches, I will probably deploy them as I'm
  very curious and more reproducibility efforts are good :-) We can can
  always decide to remove or move them later.
 
 I wish to make all contributions upstream. What would really help at
 first would be to have all targets built regularly to see where work is
 needed. This is where I think the Debian infrastructure could help, in a
 similar way as what was started for Coreboot.

FWIW, I was planning on including this patch to u-boot in the next
upload to Debian:

  
https://anonscm.debian.org/cgit/collab-maint/u-boot.git/tree/debian/patches/use-date-from-debian-changelog.patch?h=experimental-2015.07

I *think* that actually makes u-boot build reproducibly with Debian's
reproducible builds toolchain when SOURCE_DATE_EPOCH is set, but I
haven't tested it fully. I might have missed some other sources of
non-determinism...


Hoping to get some armhf buildd nodes up an running soonish... although
it should also be buildable with the cross-toolchains, if the
reproducible buildds coulld be made to support that.


live well,
  vagrant


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

Re: [U-Boot] [Reproducible-builds] [PATCH] build: create time and date independent binary

2015-07-19 Thread Paul Kocialkowski

Le dimanche 19 juillet 2015 à 06:14 -0700, Vagrant Cascadian a écrit :
On 2015-07-19, Holger Levsen wrote:
All this said, if you send me patches, I will probably deploy them as I'm
very curious and more reproducibility efforts are good :-) We can can
always decide to remove or move them later.

I wish to make all contributions upstream. What would really help at
first would be to have all targets built regularly to see where work is
needed. This is where I think the Debian infrastructure could help, in a
similar way as what was started for Coreboot.

FWIW, I was planning on including this patch to u-boot in the next
upload to Debian:

https://anonscm.debian.org/cgit/collab-maint/u-boot.git/tree/debian/patches/use-date-from-debian-changelog.patch?h=experimental-2015.07

I *think* that actually makes u-boot build reproducibly with Debian's
reproducible builds toolchain when SOURCE_DATE_EPOCH is set, but I
haven't tested it fully. I might have missed some other sources of
non-determinism...

We came up with something similar last week. This is not actually
sufficient, but close. I will submit what I have to the U-Boot mailing
list soon (hopefully, later today), feel free to review it there and
import it to Debian.

Hoping to get some armhf buildd nodes up an running soonish... although
it should also be buildable with the cross-toolchains, if the
reproducible buildds coulld be made to support that.

Native builds don't seem realistic given the many different
architectures that U-Boot supports, unless done with virtualisation (see
my other email from today).

Now that I think about it, maybe virtualisation would require simply too
many VMs to setup.

Either way, we can always try to add a toolchain build script to U-Boot.

--
Paul Kocialkowski, Replicant developer

Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.

Website: http://www.replicant.us/
Blog: http://blog.replicant.us/
Wiki/tracker/forums: http://redmine.replicant.us/

signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] USB and unbinding

Hi Hans,

I've been thinking about the USB unbinding code. I know that I agreed
to go with it, but in retrospect I think that was a mistake.

I believe we should separate out the unbinding and make it an option,
so that it is not required in order to use USB. In effect this makes
one of driver model's design goals (the option to drop unused code)
useless since USB is a common interface.

If I recall the only problem the lack of unbinding caused was that the
keyboard driver broke. I suspect it broke in a way that can be fixed.
In fact I recently converted usb_ether to driver model and I'm willing
to do the keyboard side also.

I'd like the USB code to function with or without the unbinding (i.e.
it uses it if there). What do you think?

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

Re: [U-Boot] [ANN] git server, FTP server

2015-07-19 Thread Peter Robinson

 I tried to find a way to download a file with wget or a similar tool, which
 would be used by a distribution builder (like Yocto, Buildroot, OpenWrt, 
 ...).

 Why would any build environment use tarballs?  can you not just
 reference the git repository?  This is much more efficient, IMHO.

 Open Build Service uses tarballs, too. We usually specify full URLs in
 the RPM .spec file [1] both for documentation of origin and so that the
 mirrored tarball can be verified via gpg or checksum where available.
 As the actual build is intentionally done offline, at some point a
 tarball is needed. The URL could happily be a redirect to some mirror.

This is the same in Fedora, the builds are done in a constrained
environment without connectivity to the general internet.

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

Re: [U-Boot] [PATCH 3/6] dm: pci: Use complete bdf in all pci config read/write routines

On 18 July 2015 at 10:20, Bin Meng bmeng...@gmail.com wrote:
 Currently pci_bus_read_config() and pci_bus_write_config() are
 called with bus number masked off in the parameter bdf, and bus
 number is supposed to be added back in the bridge driver's pci
 config read/write ops if the device is behind a pci bridge.
 However this logic only works for a pci topology where there is
 only one bridge off the root controller. If there is addtional
 bridge in the system, the logic will create a non-existent bdf
 where its bus number gets accumulated across bridges.

 To correct this, we change all pci config read/write routines
 to use complete bdf all the way up to the root controller.

 Signed-off-by: Bin Meng bmeng...@gmail.com
 ---

  drivers/pci/pci-uclass.c | 46 +++---
  1 file changed, 23 insertions(+), 23 deletions(-)

Acked-by: Simon Glass s...@chromium.org
Tested-by: Simon Glass s...@chromium.org
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/6] dm: pci: Support bridge device configuration correctly

On 18 July 2015 at 10:20, Bin Meng bmeng...@gmail.com wrote:
 Commit aec241d dm: pci: Use the correct hose when configuring devices
 was an attempt to fix pci bridge device configuration, but unfortunately
 that does not work 100%. In pciauto_config_devices(), the fix tried to
 call pciauto_config_device() with a ctlr_hose which is supposed to be
 the root controller hose, however when walking through a pci topology
 with 2 or more pci bridges this logic simply fails.

 The call chain is: pciauto_config_devices()-pciauto_config_device()
 -dm_pci_hose_probe_bus(). Here the call to dm_pci_hose_probe_bus()
 does not make any sense as the given hose is not the bridge device's
 hose, instead it is either the root controller's hose (case#1: if it
 is the 2nd pci bridge), or the bridge's parent bridge's hose (case#2:
 if it is the 3rd pci bridge). In both cases the logic is wrong.

 For example, for failing case#1 if the bridge device to config has the
 same devfn as one of the devices under the root controller, the call
 to pci_bus_find_devfn() will return the udevice of that pci device
 under the root controller as the bus, but this is wrong as the udevice
 is not a bus which does not contain all the necessary bits associated
 with the udevice which causes further failures.

 To correctly support pci bridge device configuration, we should still
 call pciauto_config_device() with the pci bridge's hose directly.
 In order to access valid pci region information, we need to refer to
 the root controller simply by a call to pci_bus_to_hose(0) and get the
 region information there in the pciauto_prescan_setup_bridge(),
 pciauto_postscan_setup_bridge() and pciauto_config_device().

 Signed-off-by: Bin Meng bmeng...@gmail.com
 ---

  drivers/pci/pci-uclass.c |  6 +
  drivers/pci/pci_auto.c   | 66 
 +++-
  drivers/pci/pci_common.c |  7 -
  3 files changed, 61 insertions(+), 18 deletions(-)

Acked-by: Simon Glass s...@chromium.org
Tested-by: Simon Glass s...@chromium.org
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 6/6] x86: Convert to use driver model pci on queensbay/crownbay

On 18 July 2015 at 10:20, Bin Meng bmeng...@gmail.com wrote:
 Move to driver model pci for Intel queensbay/crownbay.

 Signed-off-by: Bin Meng bmeng...@gmail.com

 ---

  arch/x86/cpu/queensbay/Makefile  |  1 -
  arch/x86/cpu/queensbay/tnc.c |  5 -
  arch/x86/cpu/queensbay/tnc_pci.c | 46 
 
  arch/x86/dts/crownbay.dts|  6 +-
  configs/crownbay_defconfig   |  1 +
  5 files changed, 6 insertions(+), 53 deletions(-)
  delete mode 100644 arch/x86/cpu/queensbay/tnc_pci.c

Acked-by: Simon Glass s...@chromium.org
Tested-by: Simon Glass s...@chromium.org
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/6] dm: pci: Pass only device/function to pci_bus_find_devfn()

On 18 July 2015 at 10:20, Bin Meng bmeng...@gmail.com wrote:
 In dm_pci_hose_probe_bus(), pci_bus_find_devfn() is called with a bdf
 which includes a bus number, but it really should not as this routine
 only expects a device/function encoding.

 Signed-off-by: Bin Meng bmeng...@gmail.com
 ---

  drivers/pci/pci-uclass.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

Acked-by: Simon Glass s...@chromium.org
Tested-by: Simon Glass s...@chromium.org
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/6] dm: pci: Correct primary/secondary/subordinate bus number assignment

Hi Bin,

On 18 July 2015 at 10:20, Bin Meng bmeng...@gmail.com wrote:
 In driver model, each pci bridge device has its own hose structure.
 hose-first_busno points to the bridge device's device number, so
 we should not substract hose-first_busno before programming the
 bridge device's primary/secondary/subordinate bus number registers.

 Signed-off-by: Bin Meng bmeng...@gmail.com
 ---

  drivers/pci/pci_auto.c | 9 +
  1 file changed, 9 insertions(+)

Acked-by: Simon Glass s...@chromium.org
Tested-by: Simon Glass s...@chromium.org

I'm not happy with how each PCI bridge has its own hose structure. I
think that was a mistake. It just creates problems.

I'm thinking we should instead have a UCLASS_PCI which is strictly for
the PCI controller, and a new UCLASS_PCI_BRIDGE for bridges.

What do you think?

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

Re: [U-Boot] [PATCH 1/6] Fix incorrect comments in linker_lists.h

On 18 July 2015 at 10:20, Bin Meng bmeng...@gmail.com wrote:
 This corrects several typos in the comment block as well as some
 indentions and nits in the linker_lists.h.

 Signed-off-by: Bin Meng bmeng...@gmail.com
 ---

  include/linker_lists.h | 20 ++--
  1 file changed, 10 insertions(+), 10 deletions(-)

Acked-by: Simon Glass s...@chromium.org
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 02/10] x86: Enable DM RTC support for all x86 boards

On 18 July 2015 at 08:37, Simon Glass s...@chromium.org wrote:
 On 15 July 2015 at 02:23, Bin Meng bmeng...@gmail.com wrote:
 Add a RTC node in the device tree to enable DM RTC support.

 Signed-off-by: Bin Meng bmeng...@gmail.com
 ---

  arch/x86/dts/chromebook_link.dts| 1 +
  arch/x86/dts/chromebox_panther.dts  | 1 +
  arch/x86/dts/galileo.dts| 1 +
  arch/x86/dts/minnowmax.dts  | 1 +
  arch/x86/dts/qemu-x86_i440fx.dts| 1 +
  arch/x86/dts/qemu-x86_q35.dts   | 1 +
  configs/chromebook_link_defconfig   | 1 +
  configs/chromebox_panther_defconfig | 1 +
  configs/galileo_defconfig   | 1 +
  configs/minnowmax_defconfig | 1 +
  configs/qemu-x86_defconfig  | 1 +
  11 files changed, 11 insertions(+)

 Acked-by: Simon Glass s...@chromium.org

Applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 04/10] x86: pci: Do not assign irq 0 to pci device

On 18 July 2015 at 08:37, Simon Glass s...@chromium.org wrote:
 On 15 July 2015 at 02:23, Bin Meng bmeng...@gmail.com wrote:
 IRQ 0 is reserved and should not be assigned to pci device.

 Signed-off-by: Bin Meng bmeng...@gmail.com
 ---

  arch/x86/cpu/pci.c | 2 ++
  1 file changed, 2 insertions(+)

 Acked-by: Simon Glass s...@chromium.org

Applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 03/10] x86: pci: Assign pci irqs to all functions

On 18 July 2015 at 08:37, Simon Glass s...@chromium.org wrote:
 On 15 July 2015 at 02:23, Bin Meng bmeng...@gmail.com wrote:
 We need walk through all functions within a PCI device and assign
 their IRQs accordingly.

 Signed-off-by: Bin Meng bmeng...@gmail.com
 ---

  arch/x86/cpu/pci.c  | 27 +--
  arch/x86/include/asm/pci.h  |  3 +--
  arch/x86/lib/pirq_routing.c |  3 +--
  3 files changed, 19 insertions(+), 14 deletions(-)

 Acked-by: Simon Glass s...@chromium.org

Applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 0/3] libfdt: fix bugs

+Thierry

Hi Scott,

On 18 July 2015 at 11:42, Scott Wood scottw...@freescale.com wrote:
 On Sat, 2015-07-18 at 08:36 -0600, Simon Glass wrote:
 Hi Scott,

 On 14 July 2015 at 12:16, Scott Wood scottw...@freescale.com wrote:
  On Wed, 2015-07-15 at 01:08 +0900, Masahiro Yamada wrote:
   This series fixes bugs of libfdt.
  
   These functions were added by Thierry for U-boot only.
   So, we do not send it back to the DTC ML.
 
  If they're not part of upstream dtc, why are they in the libfdt directory?
  Have they been sent upstream but not merged?
 
  -Scott

 To avoid roadblocks we take patches in libfdt before they are merged
 upstream. I then tidy things up when I see them applied. So sometimes
 we are a little ahead of libfdt for a while. It works out OK since we
 need to sync with upstream regularly anyway.

 That's fine, but from what Masahiro said, it sounded like there was no intent
 to ever push these to upstream dtc.

I think it as just forgotten. Thierry sent it a few days ago and it
looks promising so far.

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

Re: [U-Boot] [PATCH v2 4/6] mmc: hi6220_dw_mmc: Add hi6220 glue code for dw_mmc controller.

Hi Peter,

On 19 July 2015 at 03:39, Peter Griffin peter.grif...@linaro.org wrote:
 Hi Simon,


 On 8 July 2015 at 09:57, Peter Griffin peter.grif...@linaro.org wrote:
  This patch adds the glue code for hi6220 SoC which has 2x synopsis
  dw_mmc controllers. This will be used by the hikey board support
  in subsequent patches.
 
  Signed-off-by: Peter Griffin peter.grif...@linaro.org
  ---

 Reviewed-by: Simon Glass s...@chromium.org

 (see nit below - this could be moved to device tree once you have it)


 Thanks for reviewing :)

 My plan regarding DT was to wait for it to land in the kernel, and then
 convert
 over to using it in u-boot.

 I saw some of your patches converting Raspberry Pi to DM and DT which
 should make migrating HiKey board fairly straight forward, as it shares the
 same Synopsis IP for MMC and USB :)

OK good. For MMC I sent something with the Rockchip series but have
not applied it yet. But yes it will be easier.

I'm looking forward to trying out your series, soon.

[snip]

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

Re: [U-Boot] [PATCH 2/6] dm: pci: Correct primary/secondary/subordinate bus number assignment

2015-07-19 Thread Bin Meng

Hi Simon,

On Mon, Jul 20, 2015 at 9:59 AM, Simon Glass s...@chromium.org wrote:
 Hi Bin,

 On 18 July 2015 at 10:20, Bin Meng bmeng...@gmail.com wrote:
 In driver model, each pci bridge device has its own hose structure.
 hose-first_busno points to the bridge device's device number, so
 we should not substract hose-first_busno before programming the
 bridge device's primary/secondary/subordinate bus number registers.

 Signed-off-by: Bin Meng bmeng...@gmail.com
 ---

  drivers/pci/pci_auto.c | 9 +
  1 file changed, 9 insertions(+)

 Acked-by: Simon Glass s...@chromium.org
 Tested-by: Simon Glass s...@chromium.org

 I'm not happy with how each PCI bridge has its own hose structure. I
 think that was a mistake. It just creates problems.

 I'm thinking we should instead have a UCLASS_PCI which is strictly for
 the PCI controller, and a new UCLASS_PCI_BRIDGE for bridges.

 What do you think?


I guess that may help. During the debug, I feel the dm pci codes are
really not that intuitive than the previous non-dm version. It took me
sometime to figure out where is the problem.

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

Re: [U-Boot] [PATCH 01/10] x86: Change pci option rom area MTRR setting to cacheable

On 18 July 2015 at 08:37, Simon Glass s...@chromium.org wrote:
 On 15 July 2015 at 02:23, Bin Meng bmeng...@gmail.com wrote:
 Turn on cache on the pci option rom area to improve the performance.

 Signed-off-by: Bin Meng bmeng...@gmail.com
 ---

  arch/x86/cpu/cpu.c  | 27 ---
  arch/x86/include/asm/mtrr.h |  2 ++
  2 files changed, 22 insertions(+), 7 deletions(-)

 Acked-by: Simon Glass s...@chromium.org

Applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/2] x86: Display correct CS/EIP/EFLAGS when there is an error code

On 18 July 2015 at 08:37, Simon Glass s...@chromium.org wrote:
 On 9 July 2015 at 20:38, Bin Meng bmeng...@gmail.com wrote:
 Some exceptions cause an error code to be saved on the current stack
 after the EIP value. We should extract CS/EIP/EFLAGS from different
 position on the stack based on the exception number.

 Signed-off-by: Bin Meng bmeng...@gmail.com

 ---

 Changes in v2:
 - Use enum for x86 exception numbers

  arch/x86/cpu/interrupts.c| 29 -
  arch/x86/include/asm/interrupt.h | 24 
  arch/x86/include/asm/ptrace.h| 16 +---
  3 files changed, 65 insertions(+), 4 deletions(-)

 Acked-by: Simon Glass s...@chromium.org

Applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/2] x86: Simplify architecture defined exception handling in irq_llsr()

On 9 July 2015 at 20:51, Bin Meng bmeng...@gmail.com wrote:
 Instead of using switch..case for architecture defined exceptions,
 simply unify the handling by printing a message of exception name,
 followed by registers dump then halt the CPU.

 With this unification, it also fixes the wrong exception numbers
 for #MF/#AC/#MC/#XM which should be 16/17/18/19 not 15/16/17/18.

 Signed-off-by: Bin Meng bmeng...@gmail.com
 Acked-by: Simon Glass s...@chromium.org

 ---

 Changes in v2: None

  arch/x86/cpu/interrupts.c | 151 
 ++
  1 file changed, 46 insertions(+), 105 deletions(-)

Applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] buildman: Correct '--fetch-arch' command documentation

On 18 July 2015 at 14:49, Simon Glass s...@chromium.org wrote:
 On 16 July 2015 at 20:43, Bin Meng bmeng...@gmail.com wrote:
 The doc wrongly put sandbox in the '--fetch-arch' command. Remove it.

 Signed-off-by: Bin Meng bmeng...@gmail.com
 ---

  tools/buildman/README | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 Acked-by: Simon Glass s...@chromium.org

Applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] fdt: armv8: Fix build warnings on armv8

On 26 June 2015 at 05:56, Haikun Wang haikun.w...@freescale.com wrote:
 From: Haikun Wang haikun.w...@freescale.com

 Fix below build warnings on armv8,
 drivers/spi/fsl_dspi.c: In function ‘fsl_dspi_ofdata_to_platdata’:
 drivers/spi/fsl_dspi.c:667:2:
 warning: format ‘%x’ expects argument of type ‘unsigned int’,
 but argument 2 has type ‘fdt_addr_t’ [-Wformat=]
 debug(DSPI: regs=0x%x, max-frequency=%d, endianess=%s, num-cs=%d\n,
 ^
 lib/fdtdec.c: In function ‘fdtdec_get_addr_size’:
 lib/fdtdec.c:105:4:
 warning: format ‘%lx’ expects argument of type ‘long unsigned int’,
 but argument 3 has type ‘fdt_size_t’ [-Wformat=]
 debug(addr=%08lx, size=%08lx\n,
 ^

 Signed-off-by: Haikun Wang haikun.w...@freescale.com
 ---
  drivers/spi/fsl_dspi.c | 4 ++--
  lib/fdtdec.c   | 4 ++--
  2 files changed, 4 insertions(+), 4 deletions(-)

Acked-by: Simon Glass s...@chromium.org


 diff --git a/drivers/spi/fsl_dspi.c b/drivers/spi/fsl_dspi.c
 index 6476f91..7928531 100644
 --- a/drivers/spi/fsl_dspi.c
 +++ b/drivers/spi/fsl_dspi.c
 @@ -664,8 +664,8 @@ static int fsl_dspi_ofdata_to_platdata(struct udevice 
 *bus)
 plat-speed_hz = fdtdec_get_int(blob,
 node, spi-max-frequency, FSL_DSPI_DEFAULT_SCK_FREQ);

 -   debug(DSPI: regs=0x%x, max-frequency=%d, endianess=%s, num-cs=%d\n,
 - plat-regs_addr, plat-speed_hz,
 +   debug(DSPI: regs=0x%llx, max-frequency=%d, endianess=%s, 
 num-cs=%d\n,
 + (u64)plat-regs_addr, plat-speed_hz,
   plat-flags  DSPI_FLAG_REGMAP_ENDIAN_BIG ? be : le,
   plat-num_chipselect);

 diff --git a/lib/fdtdec.c b/lib/fdtdec.c
 index 80b897a..aeb9237 100644
 --- a/lib/fdtdec.c
 +++ b/lib/fdtdec.c
 @@ -102,8 +102,8 @@ fdt_addr_t fdtdec_get_addr_size(const void *blob, int 
 node,
 size = (fdt_size_t *)((char *)cell +
 sizeof(fdt_addr_t));
 *sizep = fdt_size_to_cpu(*size);
 -   debug(addr=%08lx, size=%08x\n,
 - (ulong)addr, *sizep);
 +   debug(addr=%08lx, size=%llx\n,
 + (ulong)addr, (u64)*sizep);
 } else {
 debug(%08lx\n, (ulong)addr);
 }
 --
 1.9.1

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

[U-Boot] Kconfig for SPL

HI Masahiro,

In my fiddling with Rockchip in SPL I found that the current single
config is simple, but a little too limited. You discussed this briefly
with someone from Marvell also. At present we effectively have two
options:

1. decide for all boards that a uclass should be supported in SPL (and
put it in Makefile.spl, or not)

2. ugly #undefs to try to fix things up after the fact (i.e. #ifdef
CONFIG_SPL_BUILD...#undef CONFIG_PINCTRL)

You mentioned the idea of allowing something like this:

spl-$(CONFIG_FRED) += file.o

In practice I assume you would generate two config headers from the
same input: one for SPL and one for U-Boot proper.

Another option would be to allow several states for the same config.
At present in the .config files we have:

CONFIG_FRED=y

We could allow:

CONFIG_FRED=yyn

meaning yes for U-Boot proper, yes for SPL, no for TPL (assuming these
are enabled for the board). For this we would need a new type, similar
to tristate which allows cycling through the options.

In the Makefile we could have

obj-$(CONFIG_FRED) += file.o

and then Kbuild would do the right thing - i.e. include the file for
U-Boot proper, SPL but not TPL.

What do you think about this? I fear that we need to figure something out...

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

Re: [U-Boot] [Reproducible-builds] [PATCH] build: create time and date independent binary

2015-07-19 Thread Holger Levsen

Hi Paul,

sorry for the late reply. 

On Samstag, 13. Juni 2015, Paul Kocialkowski wrote:
  you've seen https://reproducible.debian.net/u-boot ?
 This seems very minimalistic, but it's good to see U-Boot was given some
 attention already!

:-)
 
  but maybe you can explain why u-boot needs more reproducibility testing
  than what there currently is. i'm definitly interested and not opposed,
  even though I think there shoukd be good reasons to treat some software
  specially.
 The point is to make U-Boot reproducible for all possible targets, not
 only the few ones that are supported by U-Boot. 

I think your sentence is missing some word…?!?

 I think this requires
 some extra infrastructure. In that sense, it is very similar to
 Coreboot.
 
  (also please note that we currently only have amd64 hw to run our tests
  on.)
 
 The problem is the same as Coreboot, which uses its own toolchain to
 build images. We don't need to have native armhf builds for U-Boot,
 testing with the armhf toolchain that is in Debian should be enough.

I see.
 
 I understand, this works out nicely because all the work on Coreboot
 will be inherited by Libreboot. However, on U-Boot, the work to bring
 reproducible builds has to take place initially. I know for a fact that
 parts of the code use things like __FILE__ or timestamps.

Ah.
 
 That makes sense. For U-Boot, it will certainly make sense for the
 distributions packaging it. I'm the main developer of Replicant, the
 fully free version of Android, and it would definitely be useful to have
 a smartphone on which we can trust that the bootloader can be built in a
 reproducible manner (and checked after being installed).

indeed!
 
  All this said, if you send me patches, I will probably deploy them as I'm
  very curious and more reproducibility efforts are good :-) We can can
  always decide to remove or move them later.
 
 I wish to make all contributions upstream. What would really help at
 first would be to have all targets built regularly to see where work is
 needed. This is where I think the Debian infrastructure could help, in a
 similar way as what was started for Coreboot.

can you point me to a how to explaining this or tell me those steps, starting 
with git clone...?


cheers,
Holger




signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [ANN] git server, FTP server

2015-07-19 Thread Andreas Färber

Dear Wolfgang,

Am 15.07.2015 um 14:51 schrieb Wolfgang Denk:
 In message 593aef6c47f46446852b067021a273d6fbc78...@mucse037.lantiq.com you 
 wrote:

 I tried to find a way to download a file with wget or a similar tool, which  
 would be used by a distribution builder (like Yocto, Buildroot, OpenWrt, 
 ...).
 
 Why would any build environment use tarballs?  can you not just
 reference the git repository?  This is much more efficient, IMHO.

Open Build Service uses tarballs, too. We usually specify full URLs in
the RPM .spec file [1] both for documentation of origin and so that the
mirrored tarball can be verified via gpg or checksum where available.
As the actual build is intentionally done offline, at some point a
tarball is needed. The URL could happily be a redirect to some mirror.

When developing, Git is great of course.

Regards,
Andreas

[1]
https://build.opensuse.org/package/view_file/Base:System/u-boot/u-boot.spec.in?expand=1

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
21284 (AG Nürnberg)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [Reproducible-builds] [PATCH] build: create time and date independent binary

2015-07-19 Thread Holger Levsen

Hi Paul,

On Sonntag, 19. Juli 2015, Paul Kocialkowski wrote:
  sorry for the late reply.
 
 No problem, I haven't kept you or the list posted on this either.
 
 I got a chance to discuss the issue with Lunar during RMLL 2015 and we
 came up with a nice way of doing things, using SOURCE_DATE_EPOCH.

oh, nice!

you've seen https://reproducible.debian.net/u-boot ?
 As far as I understood, this was only for the U-Boot tools.

yes

 
 There seem to be two solutions to this:
 * Including a script (e.g. the one from coreboot) to build the toolchain
 as part of the build process
 * Using native builds with visualization on the servers that run the
 builds for the reproducible task force
 
 I tend to prefer the second one since it only requires a one-time setup
 cost, while the other one, that requires to build toolchains for each
 test build, implies a considerably longer build time for each test.

these hosts also need maintenance so I actually prefer the first.
 
 The basics for building U-Boot are the following (e.g. for the
 Cubieboard2 target)
 git clone git://git.denx.de/u-boot.git
 cd u-boot
 make -C $SRC O=$DST CROSS_COMPILE=$CROSS_COMPILE Cubieboard2_defconfig
 make -C $SRC O=$DST CROSS_COMPILE=$CROSS_COMPILE

aint there a makefile with a proper target? Also how to build these cross 
compilers?
 
 Let me know if you need more indications on this.

yes, please. best a complete runnable script, aka a _working_ 5-10 liner, not 
the fancy one with variations, rebuilds and running debbindiff. Just the above 
4 lines in working - (those 4 lines dont work cause the variables are not 
defined...)


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [Reproducible-builds] [PATCH] build: create time and date independent binary

2015-07-19 Thread Holger Levsen

Hi,

On Sonntag, 19. Juli 2015, Paul Kocialkowski wrote:
  I *think* that actually makes u-boot build reproducibly with Debian's
  reproducible builds toolchain when SOURCE_DATE_EPOCH is set, but I
  haven't tested it fully. I might have missed some other sources of
  non-determinism...
 We came up with something similar last week. This is not actually
 sufficient, but close. I will submit what I have to the U-Boot mailing
 list soon (hopefully, later today), feel free to review it there and
 import it to Debian.

cool!
 
 Native builds don't seem realistic given the many different
 architectures that U-Boot supports, unless done with virtualisation (see
 my other email from today).
[...]
 Either way, we can always try to add a toolchain build script to U-Boot.

I agree, I also think we should test uboot with such a script, similar like we 
do for coreboot. That wouldnt need armhf buildds.

That said, making use of these armhf buildds Vagrant is planning to setup 
would also useful to test Debian packages (incl uboot) on armhf.


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [Reproducible-builds] [PATCH] build: create time and date independent binary

2015-07-19 Thread Paul Kocialkowski

 sorry for the late reply. 

No problem, I haven't kept you or the list posted on this either.

I got a chance to discuss the issue with Lunar during RMLL 2015 and we
came up with a nice way of doing things, using SOURCE_DATE_EPOCH.

 On Samstag, 13. Juni 2015, Paul Kocialkowski wrote:
   you've seen https://reproducible.debian.net/u-boot ?
  This seems very minimalistic, but it's good to see U-Boot was given
 some
  attention already!

As far as I understood, this was only for the U-Boot tools.

   but maybe you can explain why u-boot needs more reproducibility
 testing
   than what there currently is. i'm definitly interested and not
 opposed,
   even though I think there shoukd be good reasons to treat some
 software
   specially.
  The point is to make U-Boot reproducible for all possible targets,
 not
  only the few ones that are supported by U-Boot. 
 
 I think your sentence is missing some word…?!?

not only for the few one that are supported by U-Boot maybe?

Looks good otherwise!

  I think this requires
  some extra infrastructure. In that sense, it is very similar to
  Coreboot.
  
   (also please note that we currently only have amd64 hw to run our
 tests
   on.)
  
  The problem is the same as Coreboot, which uses its own toolchain to
  build images. We don't need to have native armhf builds for U-Boot,
  testing with the armhf toolchain that is in Debian should be enough.

 I see.

There seem to be two solutions to this:
* Including a script (e.g. the one from coreboot) to build the toolchain
as part of the build process
* Using native builds with visualization on the servers that run the
builds for the reproducible task force

I tend to prefer the second one since it only requires a one-time setup
cost, while the other one, that requires to build toolchains for each
test build, implies a considerably longer build time for each test.

  I understand, this works out nicely because all the work on Coreboot
  will be inherited by Libreboot. However, on U-Boot, the work to
 bring
  reproducible builds has to take place initially. I know for a fact
 that
  parts of the code use things like __FILE__ or timestamps.

 Ah.

Not all the targets are using that though, and the target we used during
RMLL required only timestamp changes to become reproducible (it was the
Cubieboard2 IIRC). Still, I have seen that code around, so it must be
used somewhere, so it should be fixed, too.
 
   All this said, if you send me patches, I will probably deploy them
 as I'm
   very curious and more reproducibility efforts are good :-) We can
 can
   always decide to remove or move them later.
  
  I wish to make all contributions upstream. What would really help at
  first would be to have all targets built regularly to see where work
 is
  needed. This is where I think the Debian infrastructure could help,
 in a
  similar way as what was started for Coreboot.

 can you point me to a how to explaining this or tell me those steps,
 starting 
 with git clone...?

The basics for building U-Boot are the following (e.g. for the
Cubieboard2 target)
git clone git://git.denx.de/u-boot.git
cd u-boot
make -C $SRC O=$DST CROSS_COMPILE=$CROSS_COMPILE Cubieboard2_defconfig
make -C $SRC O=$DST CROSS_COMPILE=$CROSS_COMPILE

I usually also pass ARCH=$ARCH to make but that's useless, apparently.

Let me know if you need more indications on this.

-- 
Paul Kocialkowski, Replicant developer

Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.

Website: http://www.replicant.us/
Blog: http://blog.replicant.us/
Wiki/tracker/forums: http://redmine.replicant.us/


signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/3] stm32f4: add cpu clock option for 180 MHz

While most stm32f4 run at 168 MHz, stm32f429 can work till 180 MHz.
Add option to select 180 MHz through macro CONFIG_SYS_CLK_FREQ.

Signed-off-by: Antonio Borneo borneo.anto...@gmail.com
To: Albert Aribaud albert.u.b...@aribaud.net
To: Tom Rini tr...@konsulko.com
To: Kamil Lulko re...@wp.pl
Cc: u-boot@lists.denx.de
---
 arch/arm/cpu/armv7m/stm32f4/clock.c | 34 --
 1 file changed, 24 insertions(+), 10 deletions(-)

diff --git a/arch/arm/cpu/armv7m/stm32f4/clock.c 
b/arch/arm/cpu/armv7m/stm32f4/clock.c
index 2eded1f..d520a13 100644
--- a/arch/arm/cpu/armv7m/stm32f4/clock.c
+++ b/arch/arm/cpu/armv7m/stm32f4/clock.c
@@ -92,7 +92,20 @@ struct pll_psc {
 #error CONFIG_STM32_HSE_HZ not defined!
 #else
 #if (CONFIG_STM32_HSE_HZ == 800)
-struct pll_psc pll_psc_168 = {
+#if (CONFIG_SYS_CLK_FREQ == 18000)
+/* 180 MHz */
+struct pll_psc sys_pll_psc = {
+   .pll_m = 8,
+   .pll_n = 360,
+   .pll_p = 2,
+   .pll_q = 8,
+   .ahb_psc = AHB_PSC_1,
+   .apb1_psc = APB_PSC_4,
+   .apb2_psc = APB_PSC_2
+};
+#else
+/* default 168 MHz */
+struct pll_psc sys_pll_psc = {
.pll_m = 8,
.pll_n = 336,
.pll_p = 2,
@@ -101,6 +114,7 @@ struct pll_psc pll_psc_168 = {
.apb1_psc = APB_PSC_4,
.apb2_psc = APB_PSC_2
 };
+#endif
 #else
 #error No PLL/Prescaler configuration for given CONFIG_STM32_HSE_HZ exists
 #endif
@@ -122,19 +136,19 @@ int configure_clocks(void)
while (!(readl(STM32_RCC-cr)  RCC_CR_HSERDY))
;
 
-   /* Enable high performance mode, System frequency up to 168 MHz */
+   /* Enable high performance mode, System frequency up to 180 MHz */
setbits_le32(STM32_RCC-apb1enr, RCC_APB1ENR_PWREN);
writel(PWR_CR_VOS_SCALE_MODE_1, STM32_PWR-cr);
 
setbits_le32(STM32_RCC-cfgr, ((
-   pll_psc_168.ahb_psc  RCC_CFGR_HPRE_SHIFT)
-   | (pll_psc_168.apb1_psc  RCC_CFGR_PPRE1_SHIFT)
-   | (pll_psc_168.apb2_psc  RCC_CFGR_PPRE2_SHIFT)));
-
-   writel(pll_psc_168.pll_m
-   | (pll_psc_168.pll_n  RCC_PLLCFGR_PLLN_SHIFT)
-   | (((pll_psc_168.pll_p  1) - 1)  RCC_PLLCFGR_PLLP_SHIFT)
-   | (pll_psc_168.pll_q  RCC_PLLCFGR_PLLQ_SHIFT),
+   sys_pll_psc.ahb_psc  RCC_CFGR_HPRE_SHIFT)
+   | (sys_pll_psc.apb1_psc  RCC_CFGR_PPRE1_SHIFT)
+   | (sys_pll_psc.apb2_psc  RCC_CFGR_PPRE2_SHIFT)));
+
+   writel(sys_pll_psc.pll_m
+   | (sys_pll_psc.pll_n  RCC_PLLCFGR_PLLN_SHIFT)
+   | (((sys_pll_psc.pll_p  1) - 1)  RCC_PLLCFGR_PLLP_SHIFT)
+   | (sys_pll_psc.pll_q  RCC_PLLCFGR_PLLQ_SHIFT),
STM32_RCC-pllcfgr);
setbits_le32(STM32_RCC-pllcfgr, RCC_PLLCFGR_PLLSRC);
 
-- 
2.4.6

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

Re: [U-Boot] [PATCH v1 1/2] cmd_sf: Add command sf info to show current device info

On 5/11/2015 10:59 AM, Simon Glass wrote:
 Hi,

 On 10 May 2015 at 07:04, Jagan Teki jt...@openedev.com wrote:
 On 8 May 2015 at 13:51, haikun.w...@freescale.com
 haikun.w...@freescale.com wrote:
 On 5/8/2015 1:53 PM, Jagan Teki wrote:
 On 8 May 2015 at 08:14, haikun.w...@freescale.com
 haikun.w...@freescale.com wrote:
 On 5/7/2015 7:44 PM, Jagan Teki wrote:
 On 6 May 2015 at 02:30, Simon Glass s...@chromium.org wrote:
 On 5 May 2015 at 05:37, haikun.w...@freescale.com
 haikun.w...@freescale.com wrote:
 On 5/1/2015 9:54 AM, Simon Glass wrote:
 Hi,

 On 29 April 2015 at 04:40, Haikun Wang haikun.w...@freescale.com 
 wrote:
 Add command sf info to show the information of the current SPI 
 flash device.

 Signed-off-by: Haikun Wang haikun.w...@freescale.com
 ---
 In current sf driver, we show the debug information during the flash 
 probe
 period.

 In case of without DM SPI, we need to run command sf probe to get 
 the debug
 information of the current SPI flash device. sf probe will 
 re-identify the
 device every time and it reduce the efficiency. We can get the debug 
 information
 without any re-identify process using sf info.

 So for non-dm case, sf probe and sf info does same?
 For non-dm case, sf info only show the information store in the current
 struct spi_flash, sf_probe will re-probe the SPI flash and create a new
 struct spi-flash.

 How could it be, in non-dm case sf probe will detect the flash and
 print the info
 from drivers/mtd/spi/sf_probe.c So sf probe every-time will
 re-identify the device
 and print the info.
 I approve of what you said.
 We don't have divergence about the difference between sf probe and sf
 info.
 I just want to emphasize that sf probe re-identify the device, create
 a new spi_flash and print the info, sf info only print the current info.

 BTW: regarding this patch, unlike any command in u-boot (for my 
 understanding)
 sf probe has a run-time capable detection option based on  bus:cs hz mode
 from user. So it better to skip the re-identify the same fitlash if
 the flash is identified before
 in sf probe logic and try to print the info in it instead of going
 another stale command just
 by doing print using earlier commands settings (sf probe).

 I think we get to a common view that it is unnecessary to re-identify
 the device if it has been identified.
 Divergence is that you think this should be completed through updating
 the sf probe logic and I think we should add the new command sf info.
 sf info resolves the problem in a more simpler way.
 User will be more clearly about the functions of the sf commands if we
 add a new command sf info.
   From the literal meaning of the command sf probe should identify the
 device and the command sf info show the information of current device.

 Yes, I agree that 'sf info' simply show the current device info in a
 simpler way.
 But, being with my previous statement it simply print the info which
 is derived from
 'sf probe' So why should we go and do the same thing in 'sf probe'
 with increasing
 one more command which does part of same as before.

 Yes, 'sf probe' is doing unnecessary re-identify the device so may be we can
 fix that, ie going to be a real fix other than adding new command.

 Please think in that direction, adding new command in u-boot is really a big
 step to think in whole u-boot development point of view.

 We have an 'info' command for usb, mmc, scsi, etc. and they don't have
 side-effects like re-probing the device. I think it makes sense to
 support something like this for sf, at least for driver model.

 Also, with driver model it would be good if the sf could automatically
 probe when used, rather than needing to probe it explicitly. We could
 also support more than one active flash, and a command to switch
 between them (like mmc dev and the like). Even better if we could
 specific the device in the 'sf read/write/erase' commands.

 [snip]

 Regards,
 Simon

Update my email address.

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

Re: [U-Boot] [PATCH 2/5] sf: sf_dataflash: Add error handler when flash operate fail

On 7/7/2015 1:33 AM, Simon Glass wrote:
 On 2 July 2015 at 03:12, Haikun Wang haikun.w...@freescale.com wrote:
 Add error handler when write/erase flash fail.

 Signed-off-by: Haikun Wang haikun.w...@freescale.com
 ---
   drivers/mtd/spi/sf_dataflash.c | 30 ++
   1 file changed, 22 insertions(+), 8 deletions(-)

 Reviewed-by: Simon Glass s...@chromium.org

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

Re: [U-Boot] [PATCH 3/5] sf: sf_dataflash: Remove CONFIG_SPI_DATAFLASH_WRITE_VERIFY option

On 7/7/2015 1:33 AM, Simon Glass wrote:
 Hi,

 On 2 July 2015 at 03:12, Haikun Wang haikun.w...@freescale.com wrote:
 Signed-off-by: Haikun Wang haikun.w...@freescale.com

 Missing commit message. Doesn't this mean it will always do the verify?

 ---
   drivers/mtd/spi/sf_dataflash.c | 2 --
   1 file changed, 2 deletions(-)

 diff --git a/drivers/mtd/spi/sf_dataflash.c b/drivers/mtd/spi/sf_dataflash.c
 index 8f91527..6bf628b 100644
 --- a/drivers/mtd/spi/sf_dataflash.c
 +++ b/drivers/mtd/spi/sf_dataflash.c
 @@ -371,7 +371,6 @@ int spi_dataflash_write(struct udevice *dev, u32 offset, 
 size_t len,
  goto release_bus;
  }

 -#ifdef CONFIG_SPI_DATAFLASH_WRITE_VERIFY
  /* (3) Compare to Buffer1 */
  addr = pageaddr  dataflash-page_offset;
  command[0] = OP_COMPARE_BUF1;
 @@ -404,7 +403,6 @@ int spi_dataflash_write(struct udevice *dev, u32 offset, 
 size_t len,
  status = 0;
  }

 -#endif /* CONFIG_SPI_DATAFLASH_WRITE_VERIFY */
  remaining = remaining - writelen;
  pageaddr++;
  to = 0;
 --
 2.1.0.27.g96db324


 Regards,
 Simon

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

Re: [U-Boot] [PATCH 1/5] sf: sf_dataflash: Remove inline property of function dataflash_status

On 7/2/2015 5:17 PM, Haikun Wang wrote:
 Signed-off-by: Haikun Wang haikun.w...@freescale.com
 ---
   drivers/mtd/spi/sf_dataflash.c | 3 +--
   1 file changed, 1 insertion(+), 2 deletions(-)

 diff --git a/drivers/mtd/spi/sf_dataflash.c b/drivers/mtd/spi/sf_dataflash.c
 index 3111f4f..f83f994 100644
 --- a/drivers/mtd/spi/sf_dataflash.c
 +++ b/drivers/mtd/spi/sf_dataflash.c
 @@ -67,7 +67,6 @@
   #define OP_WRITE_SECURITY_REVC  0x9A
   #define OP_WRITE_SECURITY   0x9B/* revision D */

 -
   struct dataflash {
   uint8_t command[16];
   unsigned short  page_offset;/* offset in flash address */
 @@ -76,7 +75,7 @@ struct dataflash {
   /*
* Return the status of the DataFlash device.
*/
 -static inline int dataflash_status(struct spi_slave *spi)
 +static int dataflash_status(struct spi_slave *spi)
   {
   int ret;
   u8 status;

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

Re: [U-Boot] [PATCH 5/5] sf: sf_dataflash: Update probing method of old chips which not support Device ID

On 7/2/2015 5:17 PM, Haikun Wang wrote:
 Some old dataflash chips don't have device ID,
 we should identif them using bits in the flash status byte.
 Add a variable status_byte in struct flash_info,
 and assign correct value for above old chips.
 Add those chips to the supported flash chip table
 and identify them through the new variable status_byte.

 Signed-off-by: Haikun Wang haikun.w...@freescale.com
 ---
Update my email address.

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

Re: [U-Boot] [PATCH 4/5] sf: sf_dataflash: Change the return value of jedec_probe to int

On 7/7/2015 1:33 AM, Simon Glass wrote:
 On 2 July 2015 at 03:12, Haikun Wang haikun.w...@freescale.com wrote:
 Signed-off-by: Haikun Wang haikun.w...@freescale.com
 ---
   drivers/mtd/spi/sf_dataflash.c | 28 +---
   1 file changed, 17 insertions(+), 11 deletions(-)

 Missing commit message. Otherwise:

 Reviewed-by: Simon Glass s...@chromium.org

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

[U-Boot] [PATCH 1/3] stm32f429: pass the device unique ID in DTB

Read device unique ID and set environment variable serial#.
Value would then be passed to kernel through DTB.

To read ID from DTB, kernel is required to have commit:
3f599875e5202986b350618a617527ab441bf206 (ARM: 8355/1: arch: Show
the serial number from devicetree in cpuinfo)
This commit is already mainline since v4.1-rc1.

Signed-off-by: Antonio Borneo borneo.anto...@gmail.com
To: Albert Aribaud albert.u.b...@aribaud.net
To: Tom Rini tr...@konsulko.com
To: Kamil Lulko re...@wp.pl
Cc: u-boot@lists.denx.de
---
 arch/arm/include/asm/arch-stm32f4/stm32.h  | 10 ++
 board/st/stm32f429-discovery/stm32f429-discovery.c | 19 +++
 include/configs/stm32f429-discovery.h  |  1 +
 3 files changed, 30 insertions(+)

diff --git a/arch/arm/include/asm/arch-stm32f4/stm32.h 
b/arch/arm/include/asm/arch-stm32f4/stm32.h
index a9f88db..3ed3801 100644
--- a/arch/arm/include/asm/arch-stm32f4/stm32.h
+++ b/arch/arm/include/asm/arch-stm32f4/stm32.h
@@ -14,6 +14,7 @@
 /*
  * Peripheral memory map
  */
+#define STM32_SYSMEM_BASE  0x1FFF
 #define STM32_PERIPH_BASE  0x4000
 #define STM32_APB1PERIPH_BASE  (STM32_PERIPH_BASE + 0x)
 #define STM32_APB2PERIPH_BASE  (STM32_PERIPH_BASE + 0x0001)
@@ -25,6 +26,12 @@
 /*
  * Register maps
  */
+struct stm32_u_id_regs {
+   u32 u_id_low;
+   u32 u_id_mid;
+   u32 u_id_high;
+};
+
 struct stm32_rcc_regs {
u32 cr; /* RCC clock control */
u32 pllcfgr;/* RCC PLL configuration */
@@ -78,6 +85,9 @@ struct stm32_flash_regs {
 /*
  * Registers access macros
  */
+#define STM32_U_ID_BASE(STM32_SYSMEM_BASE + 0x7A10)
+#define STM32_U_ID ((struct stm32_u_id_regs *)STM32_U_ID_BASE)
+
 #define STM32_RCC_BASE (STM32_AHB1PERIPH_BASE + 0x3800)
 #define STM32_RCC  ((struct stm32_rcc_regs *)STM32_RCC_BASE)
 
diff --git a/board/st/stm32f429-discovery/stm32f429-discovery.c 
b/board/st/stm32f429-discovery/stm32f429-discovery.c
index 2dd5d93..f418186 100644
--- a/board/st/stm32f429-discovery/stm32f429-discovery.c
+++ b/board/st/stm32f429-discovery/stm32f429-discovery.c
@@ -285,3 +285,22 @@ int board_init(void)
 
return 0;
 }
+
+#ifdef CONFIG_MISC_INIT_R
+int misc_init_r(void)
+{
+   char serialno[25];
+   uint32_t u_id_low, u_id_mid, u_id_high;
+
+   if (!getenv(serial#)) {
+   u_id_low  = readl(STM32_U_ID-u_id_low);
+   u_id_mid  = readl(STM32_U_ID-u_id_mid);
+   u_id_high = readl(STM32_U_ID-u_id_high);
+   sprintf(serialno, %08x%08x%08x,
+   u_id_high, u_id_mid, u_id_low);
+   setenv(serial#, serialno);
+   }
+
+   return 0;
+}
+#endif
diff --git a/include/configs/stm32f429-discovery.h 
b/include/configs/stm32f429-discovery.h
index 1b4fd21..4cc7324 100644
--- a/include/configs/stm32f429-discovery.h
+++ b/include/configs/stm32f429-discovery.h
@@ -15,6 +15,7 @@
 #define CONFIG_OF_LIBFDT
 
 #define CONFIG_BOARD_EARLY_INIT_F
+#define CONFIG_MISC_INIT_R
 
 #define CONFIG_SYS_FLASH_BASE  0x0800
 
-- 
2.4.6

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

[U-Boot] [PATCH 3/3] stm32f429: use 180 MHz system clock