Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support
Hi Stefan/Siva/Mugunthan/Vikas/Others On 15 February 2016 at 02:16, Jagan Teki wrote: > Compared to previous patch series this series adds spi-nor > core with spi-nor controller drivers are of "mtd uclass" > > This is whole series for all spi-nor related changes, and while > series tested on spansion spi-nor chip. > > Know issue: > - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix. > > Why this framework: > > Some of the SPI device drivers at drivers/spi not a real > spi controllers, Unlike normal/generic SPI controllers they > operates only with SPI-NOR flash devices. these were technically > termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c > > The problem with these were resides at drivers/spi is entire > SPI layer becomes SPI-NOR flash oriented which is absolutely > a wrong indication where SPI layer getting effected more with > flash operations - So this SPI-NOR core will resolve this issue > by separating all SPI-NOR flash operations from spi layer and > creats a generic layer called SPI-NOR core which can be used to > interact SPI-NOR to SPI driver interface layer and the SPI-NOR > controller driver. The idea is taken from Linux spi-nor framework. > > Before SPI-NOR: > > --- > cmd/sf.c > --- > spi_flash.c > --- > sf_probe.c > --- > spi-uclass > --- > spi drivers > --- > SPI NOR chip > --- > > After SPI-NOR: > > -- > cmd/sf.c > -- > spi-nor.c > --- > m25p80.cspi nor drivers > --- > spi-uclass SPI NOR chip > --- > spi drivers > --- > SPI NOR chip > --- > > SPI-NOR with MTD: > > -- > cmd/sf.c > -- > MTD core > -- > spi-nor.c > --- > m25p80.cspi nor drivers > --- > spi-uclass SPI NOR chip > --- > spi drivers > --- > SPI NOR chip > --- > > drivers/mtd/spi-nor/spi-nor.c: spi-nor core > drivers/mtd/spi-nor/m25p80.c: mtd uclass driver > which is an interface layer b/w spi-nor core drivers/spi > drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass) > > Changes for v6: > - Fixed git bisectable issues, with buildman. > - Fixed spi-nor compilation issues > - newly designed changes. > > Changes for v5: > - newly designed changes > > Testing: > $ git clone git://git.denx.de/u-boot-spi.git > $ cd u-boot-spi > $ git checkout -b spi-nor origin/spi-nor Please test this series? thanks! -- Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: if MMCSD_MODE_RAW fails, try MMCSD_MODE_FS, if available
Hi Tom, Guillaume,
On Wed, Feb 17, 2016 at 03:27:22PM -0500, Tom Rini wrote:
> On Wed, Feb 17, 2016 at 09:09:27AM +0100, Guillaume GARDET wrote:
>
> > Since commit fd61d39970b9901217efc7536d9f3a61b4e1752a:
> > spl: mmc: add break statements in spl_mmc_load_image()
> > RAW and FS boot modes are now exclusive again. So, if MMCSD_MODE_RAW fails,
> > the
> > board hangs. This patch allows to try MMCSD_MODE_FS then, if available.
> >
> > It has been tested on a beaglebone black to boot on an EXT partition.
> >
> > Signed-off-by: Guillaume GARDET
> > Cc: Tom Rini
> > Cc: Nikita Kiryanov
> > Cc: Igor Grinberg
> > Cc: Paul Kocialkowski
> > Cc: Pantelis Antoniou
> > Cc: Simon Glass
> > Cc: Matwey V. Kornilov
> >
> > ---
> > common/spl/spl_mmc.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> > index c3931c6..2eef0f2 100644
> > --- a/common/spl/spl_mmc.c
> > +++ b/common/spl/spl_mmc.c
> > @@ -284,7 +284,7 @@ int spl_mmc_load_image(u32 boot_device)
> > if (!err)
> > return err;
> > #endif
> > - break;
> > + /* Fall through */
> > case MMCSD_MODE_FS:
> > debug("spl: mmc boot mode: fs\n");
>
> This also essentially reverts fd61d399. So Nikita, was there a specific
> use case that was broken before, or was the code just unclear in
> intentions here? Thanks!
There was no broken use case that I'm aware of. The change was made as
part of a code improvement series and was meant to address what I
consider to be bad and problematic design. Instead of reverting it
though, how about implementing something similar to what I did in the
main common/spl/spl.c:board_init_r()? You would have a weak function
that will default to the original spl_boot_mode() if not overridden,
and allow the user to define a sequence of boot modes otherwise.
>
> --
> Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Issue with USB mass storage (thumb drives)
On 04.02.2016 12:28, Marek Vasut wrote: > On Thursday, February 04, 2016 at 09:21:08 AM, Schrempf Frieder wrote: >> On 03.02.2016 20:16, Sergei Temerkhanov wrote: >>> On Wed, Feb 3, 2016 at 8:40 AM, Marek Vasut wrote: On Wednesday, February 03, 2016 at 12:49:20 PM, Schrempf Frieder wrote: > On 03.02.2016 12:12, Marek Vasut wrote: >> On Wednesday, February 03, 2016 at 11:15:00 AM, Schrempf Frieder wrote: >>> On 03.02.2016 10:55, Fabio Estevam wrote: On Wed, Feb 3, 2016 at 7:40 AM, Marek Vasut wrote: > In that case, debug time. > > Usual problems are bad routing of the tracks on the board , so try > with USB 1.1 hub and if that works, that's your problem. Another suggestion would be to try the 100MB transfer in Linux and see if this works or not. That would help us to narrow down whether this is a hardware or software problem. >>> Another thing to try may be limiting the value of USB_MAX_XFER_BLK in >>> common/usb_storage.c >> This was a really helpful hint! Thank you Sergei! >> >> I just tried to limit USB_MAX_XFER_BLK to 1/8 of the original value >> (65535 -> 8191) and this time the transfer works without timeouts. >> >> As we have a customer who needs this working as soon as possible my >> question now is how to properly solve this. >> Should I generally limit USB_MAX_XFER_BLK in my u-boot to avoid these >> errors? Which value to choose? > Nice! Can you share which sticks are those, ideally brand/type and USB IDs ? At the moment I have two sticks with the same chip around for which setting USB_MAX_XFER_BLK from 65535 to 32767 fixed the file transfer. Also one of our customers tested a few non-working sticks with this change and reported, that it fixed it for him. Here's a list of those devices, but I guess there are a lot more: 1. Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) Flash Drive, VID: 0x090c, PID: 0x1000 2. Freecom Technologies, VID: 0x07ab, PID: 0xfcf1 3. Newron, VID: 0x8644, PID: 0x800e 4. GEMBIRD PhotoFrame PF-15-1, VID: 0x1908, PID: 0x1320 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: if MMCSD_MODE_RAW fails, try MMCSD_MODE_FS, if available
Hi Tom, Nikita ,
Le 18/02/2016 10:19, Nikita Kiryanov a écrit :
Hi Tom, Guillaume,
On Wed, Feb 17, 2016 at 03:27:22PM -0500, Tom Rini wrote:
On Wed, Feb 17, 2016 at 09:09:27AM +0100, Guillaume GARDET wrote:
Since commit fd61d39970b9901217efc7536d9f3a61b4e1752a:
spl: mmc: add break statements in spl_mmc_load_image()
RAW and FS boot modes are now exclusive again. So, if MMCSD_MODE_RAW fails, the
board hangs. This patch allows to try MMCSD_MODE_FS then, if available.
It has been tested on a beaglebone black to boot on an EXT partition.
Signed-off-by: Guillaume GARDET
Cc: Tom Rini
Cc: Nikita Kiryanov
Cc: Igor Grinberg
Cc: Paul Kocialkowski
Cc: Pantelis Antoniou
Cc: Simon Glass
Cc: Matwey V. Kornilov
---
common/spl/spl_mmc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index c3931c6..2eef0f2 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -284,7 +284,7 @@ int spl_mmc_load_image(u32 boot_device)
if (!err)
return err;
#endif
- break;
+ /* Fall through */
case MMCSD_MODE_FS:
debug("spl: mmc boot mode: fs\n");
This also essentially reverts fd61d399. So Nikita, was there a specific
use case that was broken before, or was the code just unclear in
intentions here? Thanks!
There was no broken use case that I'm aware of. The change was made as
part of a code improvement series and was meant to address what I
consider to be bad and problematic design. Instead of reverting it
though, how about implementing something similar to what I did in the
main common/spl/spl.c:board_init_r()? You would have a weak function
that will default to the original spl_boot_mode() if not overridden,
and allow the user to define a sequence of boot modes otherwise.
The thing is you broke a wanted behavior currently in use. So, the priority is
to come back to the previous behavior.
Then, if someone (you, me or someone else) wants to improve this code, the way
you suggested, it would be very nice.
But it will need a lot more work, tests and reviews.
Guillaume
--
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fix m88e1111s PHY auto negotiation timeout
> On 16.02.2016 07:54, Thomas Chou wrote:
> > After commit a058052c358c
> > ("net: phy: do not read configuration register on reset")
> >
> > both 3c120 and 10m50 devboard which use Marvel m88es PHY got this
> > error message,
> >
> > Net: eth0: ethernet@400
> > => ping 192.168.1.5
> > ethernet@400 Waiting for PHY auto negotiation to complete TIMEOUT !
> > Using ethernet@400 device
> > host 192.168.1.5 is alive
> >
> > This is because the auto negotiation control bit was cleared by the
> > new phy_reset(). But the m88es_config() does the soft-reset
> > already, there is no need to reset twice. The extra phy_reset() should
> > be removed.
> >
> > Signed-off-by: Thomas Chou
> > ---
> > drivers/net/phy/marvell.c | 2 --
> > 1 file changed, 2 deletions(-)
> >
> > diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
> > index eab1558..5badfac 100644
> > --- a/drivers/net/phy/marvell.c
> > +++ b/drivers/net/phy/marvell.c
> > @@ -271,8 +271,6 @@ static int m88es_config(struct phy_device
> > *phydev)
> >
> > genphy_config_aneg(phydev);
> >
> > - phy_reset(phydev);
> > -
> > return 0;
> > }
> >
> >
>
> I've also stumbled over this problem on some boards equipped with the
> Marvell PHY. Could you please take a look at these patches instead:
>
> http://patchwork.ozlabs.org/patch/581316/
> http://patchwork.ozlabs.org/patch/581317/
>
> Do they work for you?
>
> Joe, could you please make sure to push these for this release? As its a
> real bugfix.
>
>
[Alison Wang]
After commit a058052c358c
("net: phy: do not read configuration register on reset")
I find auto negotiation timeout error also occurs on Atheros's PHY AR8033 too.
:(
Best Regards,
Alison Wang
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 0/3] UniPhier SD/eMMC controller driver
Changes in v4: - Add some comments about HOST_MODE register - Rename uniphier_sd_wait_irq() to uniphier_sd_wait_for_irq() Changes in v3: - Use dev_err/dev_dbg instead of pr_err/pr_debug - Tidy up uniphier_sd_set_ios() - Allow to use DMA even in SPL if the target address is DMA'able Changes in v2: - Fix the divisor bug on the older IP (on PH1-LD4, PH1-sLD8, PH1-Pro4) - Increase time out because "mmc erase" can sometimes take long - Move HOST_MODE register setting to uniphier_sd_init() because this register does not need setting multipule times. Masahiro Yamada (3): mmc: uniphier: add driver for UniPhier SD/MMC host controller ARM: uniphier: enable UniPhier SD/MMC host driver ARM: dts: uniphier: add SD/MMC host controller nodes arch/arm/Kconfig | 1 + arch/arm/dts/uniphier-ph1-ld4-ref.dts| 4 + arch/arm/dts/uniphier-ph1-ld4.dtsi | 25 + arch/arm/dts/uniphier-ph1-ld6b-ref.dts | 4 + arch/arm/dts/uniphier-ph1-pro4-ace.dts | 4 + arch/arm/dts/uniphier-ph1-pro4-ref.dts | 8 + arch/arm/dts/uniphier-ph1-pro4-sanji.dts | 4 + arch/arm/dts/uniphier-ph1-pro4.dtsi | 37 ++ arch/arm/dts/uniphier-ph1-pro5-4kbox.dts | 8 + arch/arm/dts/uniphier-ph1-pro5.dtsi | 24 + arch/arm/dts/uniphier-ph1-sld3-ref.dts | 4 + arch/arm/dts/uniphier-ph1-sld3.dtsi | 19 + arch/arm/dts/uniphier-ph1-sld8-ref.dts | 4 + arch/arm/dts/uniphier-ph1-sld8.dtsi | 25 + arch/arm/dts/uniphier-pinctrl.dtsi | 15 + arch/arm/dts/uniphier-proxstream2-gentil.dts | 4 + arch/arm/dts/uniphier-proxstream2-vodka.dts | 4 + arch/arm/dts/uniphier-proxstream2.dtsi | 24 + configs/uniphier_ld4_sld8_defconfig | 1 + configs/uniphier_pro4_defconfig | 1 + configs/uniphier_pro5_defconfig | 1 + configs/uniphier_pxs2_ld6b_defconfig | 1 + configs/uniphier_sld3_defconfig | 1 + doc/README.uniphier | 1 + drivers/mmc/Kconfig | 6 + drivers/mmc/Makefile | 1 + drivers/mmc/uniphier-sd.c| 751 +++ include/configs/uniphier.h | 4 + 28 files changed, 986 insertions(+) create mode 100644 drivers/mmc/uniphier-sd.c -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 3/3] ARM: dts: uniphier: add SD/MMC host controller nodes
This host controller is available for all UniPhier SoCs.
Signed-off-by: Masahiro Yamada
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
arch/arm/dts/uniphier-ph1-ld4-ref.dts| 4 +++
arch/arm/dts/uniphier-ph1-ld4.dtsi | 25 +++
arch/arm/dts/uniphier-ph1-ld6b-ref.dts | 4 +++
arch/arm/dts/uniphier-ph1-pro4-ace.dts | 4 +++
arch/arm/dts/uniphier-ph1-pro4-ref.dts | 8 ++
arch/arm/dts/uniphier-ph1-pro4-sanji.dts | 4 +++
arch/arm/dts/uniphier-ph1-pro4.dtsi | 37
arch/arm/dts/uniphier-ph1-pro5-4kbox.dts | 8 ++
arch/arm/dts/uniphier-ph1-pro5.dtsi | 24 ++
arch/arm/dts/uniphier-ph1-sld3-ref.dts | 4 +++
arch/arm/dts/uniphier-ph1-sld3.dtsi | 19 ++
arch/arm/dts/uniphier-ph1-sld8-ref.dts | 4 +++
arch/arm/dts/uniphier-ph1-sld8.dtsi | 25 +++
arch/arm/dts/uniphier-pinctrl.dtsi | 15 +++
arch/arm/dts/uniphier-proxstream2-gentil.dts | 4 +++
arch/arm/dts/uniphier-proxstream2-vodka.dts | 4 +++
arch/arm/dts/uniphier-proxstream2.dtsi | 24 ++
17 files changed, 217 insertions(+)
diff --git a/arch/arm/dts/uniphier-ph1-ld4-ref.dts
b/arch/arm/dts/uniphier-ph1-ld4-ref.dts
index f62916d..d7b0007 100644
--- a/arch/arm/dts/uniphier-ph1-ld4-ref.dts
+++ b/arch/arm/dts/uniphier-ph1-ld4-ref.dts
@@ -51,6 +51,10 @@
status = "okay";
};
+&sd {
+ status = "okay";
+};
+
&usb0 {
status = "okay";
};
diff --git a/arch/arm/dts/uniphier-ph1-ld4.dtsi
b/arch/arm/dts/uniphier-ph1-ld4.dtsi
index f13c6db..5ae029e 100644
--- a/arch/arm/dts/uniphier-ph1-ld4.dtsi
+++ b/arch/arm/dts/uniphier-ph1-ld4.dtsi
@@ -220,6 +220,31 @@
clock-frequency = <10>;
};
+ sd: sdhc@5a40 {
+ compatible = "socionext,uniphier-sdhc";
+ status = "disabled";
+ reg = <0x5a40 0x200>;
+ interrupts = <0 76 4>;
+ pinctrl-names = "default", "1.8v";
+ pinctrl-0 = <&pinctrl_sd>;
+ pinctrl-1 = <&pinctrl_sd_1v8>;
+ clocks = <&mio 0>;
+ bus-width = <4>;
+ };
+
+ emmc: sdhc@5a50 {
+ compatible = "socionext,uniphier-sdhc";
+ status = "disabled";
+ reg = <0x5a50 0x200>;
+ interrupts = <0 78 4>;
+ pinctrl-names = "default", "1.8v";
+ pinctrl-0 = <&pinctrl_emmc>;
+ pinctrl-1 = <&pinctrl_emmc_1v8>;
+ clocks = <&mio 1>;
+ bus-width = <8>;
+ non-removable;
+ };
+
usb0: usb@5a800100 {
compatible = "socionext,uniphier-ehci", "generic-ehci";
status = "disabled";
diff --git a/arch/arm/dts/uniphier-ph1-ld6b-ref.dts
b/arch/arm/dts/uniphier-ph1-ld6b-ref.dts
index dca408b..13a29fd 100644
--- a/arch/arm/dts/uniphier-ph1-ld6b-ref.dts
+++ b/arch/arm/dts/uniphier-ph1-ld6b-ref.dts
@@ -53,6 +53,10 @@
status = "okay";
};
+&sd {
+ status = "okay";
+};
+
&usb0 {
status = "okay";
};
diff --git a/arch/arm/dts/uniphier-ph1-pro4-ace.dts
b/arch/arm/dts/uniphier-ph1-pro4-ace.dts
index 6e741ea..37e0853 100644
--- a/arch/arm/dts/uniphier-ph1-pro4-ace.dts
+++ b/arch/arm/dts/uniphier-ph1-pro4-ace.dts
@@ -69,6 +69,10 @@
status = "okay";
};
+&sd {
+ status = "okay";
+};
+
&usb0 {
status = "okay";
};
diff --git a/arch/arm/dts/uniphier-ph1-pro4-ref.dts
b/arch/arm/dts/uniphier-ph1-pro4-ref.dts
index 202a642..07a9783 100644
--- a/arch/arm/dts/uniphier-ph1-pro4-ref.dts
+++ b/arch/arm/dts/uniphier-ph1-pro4-ref.dts
@@ -54,6 +54,14 @@
status = "okay";
};
+&sd {
+ status = "okay";
+};
+
+&sd1 {
+ status = "okay";
+};
+
&usb0 {
status = "okay";
};
diff --git a/arch/arm/dts/uniphier-ph1-pro4-sanji.dts
b/arch/arm/dts/uniphier-ph1-pro4-sanji.dts
index 91a71ef..1ca1042 100644
--- a/arch/arm/dts/uniphier-ph1-pro4-sanji.dts
+++ b/arch/arm/dts/uniphier-ph1-pro4-sanji.dts
@@ -64,6 +64,10 @@
status = "okay";
};
+&emmc {
+ status = "okay";
+};
+
&usb0 {
status = "okay";
};
diff --git a/arch/arm/dts/uniphier-ph1-pro4.dtsi
b/arch/arm/dts/uniphier-ph1-pro4.dtsi
index 6637aea..d5767b6 100644
--- a/arch/arm/dts/uniphier-ph1-pro4.dtsi
+++ b/arch/arm/dts/uniphier-ph1-pro4.dtsi
@@ -343,6 +343,43 @@
clock-frequency = <40>;
};
+ sd: sdhc@5a40 {
+ compatible = "socionext,uniphier-sdhc";
+ status = "disabled";
+ reg = <0x5a40 0x200>;
+ interrupts = <0 76 4>;
+ pinctrl-names = "default", "1.8v";
+ pinctrl-0 = <&pinctrl_sd>;
+ pinctrl-1 = <&pinctrl_sd_1v8>;
+ clocks = <&mio 0>;
+ bus-width = <4>;
+ };
+
+ em
[U-Boot] [PATCH v4 2/3] ARM: uniphier: enable UniPhier SD/MMC host driver
Enable the driver in all UniPhier defconfig files and add some needed defines to the common files. Signed-off-by: Masahiro Yamada --- Changes in v4: None Changes in v3: None Changes in v2: None arch/arm/Kconfig | 1 + configs/uniphier_ld4_sld8_defconfig | 1 + configs/uniphier_pro4_defconfig | 1 + configs/uniphier_pro5_defconfig | 1 + configs/uniphier_pxs2_ld6b_defconfig | 1 + configs/uniphier_sld3_defconfig | 1 + include/configs/uniphier.h | 4 7 files changed, 10 insertions(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 94bd7ec..37b20ff 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -700,6 +700,7 @@ config ARCH_UNIPHIER select DM_GPIO select DM_SERIAL select DM_I2C + select DM_MMC help Support for UniPhier SoC family developed by Socionext Inc. (formerly, System LSI Business Division of Panasonic Corporation) diff --git a/configs/uniphier_ld4_sld8_defconfig b/configs/uniphier_ld4_sld8_defconfig index dbee08e..892bccc 100644 --- a/configs/uniphier_ld4_sld8_defconfig +++ b/configs/uniphier_ld4_sld8_defconfig @@ -21,6 +21,7 @@ CONFIG_CMD_TIME=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_SPL_SIMPLE_BUS=y CONFIG_GPIO_UNIPHIER=y +CONFIG_MMC_UNIPHIER=y CONFIG_NAND_DENALI=y CONFIG_SYS_NAND_DENALI_64BIT=y CONFIG_NAND_DENALI_SPARE_AREA_SKIP_BYTES=8 diff --git a/configs/uniphier_pro4_defconfig b/configs/uniphier_pro4_defconfig index 3c2f7b0..45ef883 100644 --- a/configs/uniphier_pro4_defconfig +++ b/configs/uniphier_pro4_defconfig @@ -20,6 +20,7 @@ CONFIG_CMD_TIME=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_SPL_SIMPLE_BUS=y CONFIG_GPIO_UNIPHIER=y +CONFIG_MMC_UNIPHIER=y CONFIG_NAND_DENALI=y CONFIG_SYS_NAND_DENALI_64BIT=y CONFIG_NAND_DENALI_SPARE_AREA_SKIP_BYTES=8 diff --git a/configs/uniphier_pro5_defconfig b/configs/uniphier_pro5_defconfig index cf5f1ce..0029cd3 100644 --- a/configs/uniphier_pro5_defconfig +++ b/configs/uniphier_pro5_defconfig @@ -20,6 +20,7 @@ CONFIG_CMD_TIME=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_SPL_SIMPLE_BUS=y CONFIG_GPIO_UNIPHIER=y +CONFIG_MMC_UNIPHIER=y CONFIG_NAND_DENALI=y CONFIG_SYS_NAND_DENALI_64BIT=y CONFIG_NAND_DENALI_SPARE_AREA_SKIP_BYTES=8 diff --git a/configs/uniphier_pxs2_ld6b_defconfig b/configs/uniphier_pxs2_ld6b_defconfig index 00a2900..0115c21 100644 --- a/configs/uniphier_pxs2_ld6b_defconfig +++ b/configs/uniphier_pxs2_ld6b_defconfig @@ -21,6 +21,7 @@ CONFIG_CMD_TIME=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_SPL_SIMPLE_BUS=y CONFIG_GPIO_UNIPHIER=y +CONFIG_MMC_UNIPHIER=y CONFIG_NAND_DENALI=y CONFIG_SYS_NAND_DENALI_64BIT=y CONFIG_NAND_DENALI_SPARE_AREA_SKIP_BYTES=8 diff --git a/configs/uniphier_sld3_defconfig b/configs/uniphier_sld3_defconfig index 013fc8a..5f0d678 100644 --- a/configs/uniphier_sld3_defconfig +++ b/configs/uniphier_sld3_defconfig @@ -18,6 +18,7 @@ CONFIG_CMD_TIME=y # CONFIG_CMD_MISC is not set CONFIG_NET_RANDOM_ETHADDR=y CONFIG_GPIO_UNIPHIER=y +CONFIG_MMC_UNIPHIER=y CONFIG_NAND_DENALI=y CONFIG_SYS_NAND_DENALI_64BIT=y CONFIG_NAND_DENALI_SPARE_AREA_SKIP_BYTES=8 diff --git a/include/configs/uniphier.h b/include/configs/uniphier.h index fcec0c0..9d14155 100644 --- a/include/configs/uniphier.h +++ b/include/configs/uniphier.h @@ -146,6 +146,10 @@ #define CONFIG_FAT_WRITE #define CONFIG_DOS_PARTITION +/* SD/MMC */ +#define CONFIG_CMD_MMC +#define CONFIG_GENERIC_MMC + /* memtest works on */ #define CONFIG_SYS_MEMTEST_START CONFIG_SYS_SDRAM_BASE #define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_SDRAM_BASE + 0x0100) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 1/3] mmc: uniphier: add driver for UniPhier SD/MMC host controller
Add a driver for the on-chip SD/eMMC host controller used by UniPhier SoC family. Signed-off-by: Masahiro Yamada --- Changes in v4: - Add some comments about HOST_MODE register - Rename uniphier_sd_wait_irq() to uniphier_sd_wait_for_irq() Changes in v3: - Use dev_err/dev_dbg instead of pr_err/pr_debug - Tidy up uniphier_sd_set_ios() - Allow to use DMA even in SPL if the target address is DMA'able Changes in v2: - Fix the divisor bug on the older IP (on PH1-LD4, PH1-sLD8, PH1-Pro4) - Increase time out because "mmc erase" can sometimes take long - Move HOST_MODE register setting to uniphier_sd_init() because this register does not need setting multipule times. doc/README.uniphier | 1 + drivers/mmc/Kconfig | 6 + drivers/mmc/Makefile | 1 + drivers/mmc/uniphier-sd.c | 751 ++ 4 files changed, 759 insertions(+) create mode 100644 drivers/mmc/uniphier-sd.c diff --git a/doc/README.uniphier b/doc/README.uniphier index f03c207..c270ecb 100644 --- a/doc/README.uniphier +++ b/doc/README.uniphier @@ -93,6 +93,7 @@ Supported devices - UART (on-chip) - NAND + - SD/eMMC - USB 2.0 (EHCI) - USB 3.0 (xHCI) - GPIO diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig index 9f4b766..faffefd 100644 --- a/drivers/mmc/Kconfig +++ b/drivers/mmc/Kconfig @@ -37,4 +37,10 @@ config PIC32_SDHCI help Support for Microchip PIC32 SDHCI controller. +config MMC_UNIPHIER + bool "UniPhier SD/MMC Host Controller support" + depends on ARCH_UNIPHIER + help + This selects support for the SD/MMC Host Controller on UniPhier SoCs. + endmenu diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile index c9c3e3e..b85e4bf 100644 --- a/drivers/mmc/Makefile +++ b/drivers/mmc/Makefile @@ -41,6 +41,7 @@ obj-$(CONFIG_SH_SDHI) += sh_sdhi.o obj-$(CONFIG_SOCFPGA_DWMMC) += socfpga_dw_mmc.o obj-$(CONFIG_SPEAR_SDHCI) += spear_sdhci.o obj-$(CONFIG_TEGRA_MMC) += tegra_mmc.o +obj-$(CONFIG_MMC_UNIPHIER) += uniphier-sd.o obj-$(CONFIG_ZYNQ_SDHCI) += zynq_sdhci.o ifdef CONFIG_SPL_BUILD diff --git a/drivers/mmc/uniphier-sd.c b/drivers/mmc/uniphier-sd.c new file mode 100644 index 000..3bc4d94 --- /dev/null +++ b/drivers/mmc/uniphier-sd.c @@ -0,0 +1,751 @@ +/* + * Copyright (C) 2016 Masahiro Yamada + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +DECLARE_GLOBAL_DATA_PTR; + +#define UNIPHIER_SD_CMD0x000 /* command */ +#define UNIPHIER_SD_CMD_NOSTOP BIT(14) /* No automatic CMD12 issue */ +#define UNIPHIER_SD_CMD_MULTIBIT(13) /* multiple block transfer */ +#define UNIPHIER_SD_CMD_RD BIT(12) /* 1: read, 0: write */ +#define UNIPHIER_SD_CMD_DATA BIT(11) /* data transfer */ +#define UNIPHIER_SD_CMD_APP BIT(6) /* ACMD preceded by CMD55 */ +#define UNIPHIER_SD_CMD_NORMAL (0 << 8)/* auto-detect of resp-type */ +#define UNIPHIER_SD_CMD_RSP_NONE (3 << 8)/* response: none */ +#define UNIPHIER_SD_CMD_RSP_R1 (4 << 8)/* response: R1, R5, R6, R7 */ +#define UNIPHIER_SD_CMD_RSP_R1B (5 << 8)/* response: R1b, R5b */ +#define UNIPHIER_SD_CMD_RSP_R2 (6 << 8)/* response: R2 */ +#define UNIPHIER_SD_CMD_RSP_R3 (7 << 8)/* response: R3, R4 */ +#define UNIPHIER_SD_ARG0x008 /* command argument */ +#define UNIPHIER_SD_STOP 0x010 /* stop action control */ +#define UNIPHIER_SD_STOP_SEC BIT(8) /* use sector count */ +#define UNIPHIER_SD_STOP_STP BIT(0) /* issue CMD12 */ +#define UNIPHIER_SD_SECCNT 0x014 /* sector counter */ +#define UNIPHIER_SD_RSP10 0x018 /* response[39:8] */ +#define UNIPHIER_SD_RSP32 0x020 /* response[71:40] */ +#define UNIPHIER_SD_RSP54 0x028 /* response[103:72] */ +#define UNIPHIER_SD_RSP76 0x030 /* response[127:104] */ +#define UNIPHIER_SD_INFO1 0x038 /* IRQ status 1 */ +#define UNIPHIER_SD_INFO1_CD BIT(5) /* state of card detect */ +#define UNIPHIER_SD_INFO1_INSERT BIT(4) /* card inserted */ +#define UNIPHIER_SD_INFO1_REMOVE BIT(3) /* card removed */ +#define UNIPHIER_SD_INFO1_CMPBIT(2) /* data complete */ +#define UNIPHIER_SD_INFO1_RSPBIT(0) /* response complete */ +#define UNIPHIER_SD_INFO2 0x03c /* IRQ status 2 */ +#define UNIPHIER_SD_INFO2_ERR_ILABIT(15) /* illegal access err */ +#define UNIPHIER_SD_INFO2_CBSY BIT(14) /* command busy */ +#define UNIPHIER_SD_INFO2_BWEBIT(9) /* write buffer ready */ +#define UNIPHIER_SD_INFO2_BREBIT(8) /* read buffer ready */ +#define UNIPHIER_SD_INFO2_DAT0 BIT(7) /* SDDAT0 */ +#define UNIPHIER_SD_INFO2_ERR_RTOBIT(6) /* response time out */
[U-Boot] NAND bad block checking policy
Hello, I'm using U-Boot 2013.01.01, and I've noticed an odd behaviour when the system is checking for bad blocks on my Micron NAND. Let's say we have a NAND memory with the following features: Memory Size 128 MB Sector size 128 KiB Page size 2048 b OOB size 64 b Erase size 131072 b If I try and mark a block as bad manually (via nand markbad), the following happens: U-Boot@UCC3# nand markbad 0x429 block 0x0429 successfully marked as bad U-Boot@UCC3# nand bad Device 0 bad blocks: 0428 Everything seems fine. However, after a reboot, the system loses the information. Sifting through the code, I found the it is only checking the first two pages OOB. Note however that the block that gets marked as bad is block 0x428, which is aligned in memory with the eraseblock size (1st page in the eraseblock). Also, if I dump the oob info from 0x428000, it is not flagged as bad, but in 0x429000, the first byte is still 0x00, indicating it as bad. If I mark the 1st or 2nd page in an erase block as bad, then the information persists through boot cycles. Also, I've verified that we are not using a NAND based bbt. My main concern is that, because this checking shared between functionalities, everytime we erase a block, we keep losing bad block information, because inner pages (i.e. not the 1st or 2nd in an eraseblock), are flagged as good, which, in my point of view, is a bad thing. If this is indeed the intended behaviour, it seems to me that it is due to performance reasons. So, in this case, should we mark the whole eraseblock as bad (by writing 0x00 to the 1st or 2nd pages) if we find a single bad page in a block? Isn't this also a bad solution, since we will be marking 128kiB as bad due to a single page? Shouldn't this control be made at a finer level (i.e. page level)? Regards, Guilherme Esta mensagem e qualquer anexo a ela s?o documentos confidenciais e direcionados exclusivamente ao(s) destinat?rio(s). Qualquer uso, desvio, sonega??o, supress?o, revela??o ou divulga??o n?o autorizada ? proibida e sujeita ?s san??es e/ou repara??es legais por ato il?cito (C?digo Penal, Artigos 151 e 152). Caso n?o seja um dos destinat?rios expressamente indicados, por favor entre em contato com o remetente, respondendo este e-mail e destrua quaisquer c?pias da mensagem original. Qualquer opini?o, cr?tica ou an?lise descrita nesta mensagem ? de responsabilidade ?nica do remetente, a menos quando estiver explicitamente expresso que seja da empresa remetente. This message and any attachment are confidential information for the sole use of the intended recipients. Any unauthorized use, deviation, withholdment, suppression, disclosure or distribution is prohibited and is subjected to legal sanctions and/or compensations per illicit act (Penal Code, articles 151 and 152). If you are not one of the intended recipients, please contact the sender by reply e-mail and destroy any copy of the original message. Any view, comment or analysis expressed in this message is sole responsibility from the sender, except when it's specifically expressed that it's the view, comment or analysis of the company. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] uboot fdt commands
Hi This question is regarding to uboot commands I use the uboot "fdt mknode" command to create two nodes as below uboot> fdt resize uboot> fdt mknode /my_light_pinctrl uboot> fdt set /my_light_pintrl fsl,pins <1 2 3 4 5 6> uboot> fdt mknode /my_light uboot> fdt /my_light pinctrl-names default uboot> fdt /my_light pinctrl-0 but I don't know to write and get the last line working in uboot, because I don't know the phandle of the newly created node "my_light_pinctrl". Can someone help? Cheers, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: uniphier: remove unused umc_polling()
This function is unused.
Signed-off-by: Masahiro Yamada
---
arch/arm/mach-uniphier/dram/umc-regs.h | 9 -
1 file changed, 9 deletions(-)
diff --git a/arch/arm/mach-uniphier/dram/umc-regs.h
b/arch/arm/mach-uniphier/dram/umc-regs.h
index a6957a4..b33e2da 100644
--- a/arch/arm/mach-uniphier/dram/umc-regs.h
+++ b/arch/arm/mach-uniphier/dram/umc-regs.h
@@ -120,15 +120,6 @@
#include
-static inline void umc_polling(u32 address, u32 expval, u32 mask)
-{
- u32 nmask = ~mask;
- u32 data;
- do {
- data = readl(address) & nmask;
- } while (data != expval);
-}
-
static inline void umc_dram_init_start(void __iomem *dramcont)
{
writel(0x0002, dramcont + UMC_INITSET);
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: if MMCSD_MODE_RAW fails, try MMCSD_MODE_FS, if available
On Thu, Feb 18, 2016 at 11:06:32AM +0100, Guillaume Gardet wrote:
> Hi Tom, Nikita ,
>
> Le 18/02/2016 10:19, Nikita Kiryanov a écrit :
> >Hi Tom, Guillaume,
> >
> >On Wed, Feb 17, 2016 at 03:27:22PM -0500, Tom Rini wrote:
> >>On Wed, Feb 17, 2016 at 09:09:27AM +0100, Guillaume GARDET wrote:
> >>
> >>>Since commit fd61d39970b9901217efc7536d9f3a61b4e1752a:
> >>> spl: mmc: add break statements in spl_mmc_load_image()
> >>>RAW and FS boot modes are now exclusive again. So, if MMCSD_MODE_RAW
> >>>fails, the
> >>>board hangs. This patch allows to try MMCSD_MODE_FS then, if available.
> >>>
> >>>It has been tested on a beaglebone black to boot on an EXT partition.
> >>>
> >>>Signed-off-by: Guillaume GARDET
> >>>Cc: Tom Rini
> >>>Cc: Nikita Kiryanov
> >>>Cc: Igor Grinberg
> >>>Cc: Paul Kocialkowski
> >>>Cc: Pantelis Antoniou
> >>>Cc: Simon Glass
> >>>Cc: Matwey V. Kornilov
> >>>
> >>>---
> >>> common/spl/spl_mmc.c | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>>diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> >>>index c3931c6..2eef0f2 100644
> >>>--- a/common/spl/spl_mmc.c
> >>>+++ b/common/spl/spl_mmc.c
> >>>@@ -284,7 +284,7 @@ int spl_mmc_load_image(u32 boot_device)
> >>> if (!err)
> >>> return err;
> >>> #endif
> >>>- break;
> >>>+ /* Fall through */
> >>> case MMCSD_MODE_FS:
> >>> debug("spl: mmc boot mode: fs\n");
> >>This also essentially reverts fd61d399. So Nikita, was there a specific
> >>use case that was broken before, or was the code just unclear in
> >>intentions here? Thanks!
> >There was no broken use case that I'm aware of. The change was made as
> >part of a code improvement series and was meant to address what I
> >consider to be bad and problematic design. Instead of reverting it
> >though, how about implementing something similar to what I did in the
> >main common/spl/spl.c:board_init_r()? You would have a weak function
> >that will default to the original spl_boot_mode() if not overridden,
> >and allow the user to define a sequence of boot modes otherwise.
>
> The thing is you broke a wanted behavior currently in use. So, the priority
> is to come back to the previous behavior.
Could you add a comment indicating that this is wanted behavior that
has a user, and who the user is?
> Then, if someone (you, me or someone else) wants to improve this code, the
> way you suggested, it would be very nice.
> But it will need a lot more work, tests and reviews.
>
>
> Guillaume
>
> >
> >>--
> >>Tom
> >
> >
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: if MMCSD_MODE_RAW fails, try MMCSD_MODE_FS, if available
Le 18/02/2016 14:07, Nikita Kiryanov a écrit :
On Thu, Feb 18, 2016 at 11:06:32AM +0100, Guillaume Gardet wrote:
Hi Tom, Nikita ,
Le 18/02/2016 10:19, Nikita Kiryanov a écrit :
Hi Tom, Guillaume,
On Wed, Feb 17, 2016 at 03:27:22PM -0500, Tom Rini wrote:
On Wed, Feb 17, 2016 at 09:09:27AM +0100, Guillaume GARDET wrote:
Since commit fd61d39970b9901217efc7536d9f3a61b4e1752a:
spl: mmc: add break statements in spl_mmc_load_image()
RAW and FS boot modes are now exclusive again. So, if MMCSD_MODE_RAW fails, the
board hangs. This patch allows to try MMCSD_MODE_FS then, if available.
It has been tested on a beaglebone black to boot on an EXT partition.
Signed-off-by: Guillaume GARDET
Cc: Tom Rini
Cc: Nikita Kiryanov
Cc: Igor Grinberg
Cc: Paul Kocialkowski
Cc: Pantelis Antoniou
Cc: Simon Glass
Cc: Matwey V. Kornilov
---
common/spl/spl_mmc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index c3931c6..2eef0f2 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -284,7 +284,7 @@ int spl_mmc_load_image(u32 boot_device)
if (!err)
return err;
#endif
- break;
+ /* Fall through */
case MMCSD_MODE_FS:
debug("spl: mmc boot mode: fs\n");
This also essentially reverts fd61d399. So Nikita, was there a specific
use case that was broken before, or was the code just unclear in
intentions here? Thanks!
There was no broken use case that I'm aware of. The change was made as
part of a code improvement series and was meant to address what I
consider to be bad and problematic design. Instead of reverting it
though, how about implementing something similar to what I did in the
main common/spl/spl.c:board_init_r()? You would have a weak function
that will default to the original spl_boot_mode() if not overridden,
and allow the user to define a sequence of boot modes otherwise.
The thing is you broke a wanted behavior currently in use. So, the priority is
to come back to the previous behavior.
Could you add a comment indicating that this is wanted behavior that
has a user, and who the user is?
Not sure what you mean.
I think, "Fall through" code comment explains it (as you done with
MMCSD_MODE_EMMCBOOT).
I (and openSUSE ARM) do not pretend to be the only user(s) of this feature, so
I won't add my name there.
If you mean commit message, I think the current one is enough.
Guillaume
Then, if someone (you, me or someone else) wants to improve this code, the way
you suggested, it would be very nice.
But it will need a lot more work, tests and reviews.
Guillaume
--
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: if MMCSD_MODE_RAW fails, try MMCSD_MODE_FS, if available
On Thu, Feb 18, 2016 at 02:31:08PM +0100, Guillaume Gardet wrote:
>
>
> Le 18/02/2016 14:07, Nikita Kiryanov a écrit :
> >On Thu, Feb 18, 2016 at 11:06:32AM +0100, Guillaume Gardet wrote:
> >>Hi Tom, Nikita ,
> >>
> >>Le 18/02/2016 10:19, Nikita Kiryanov a écrit :
> >>>Hi Tom, Guillaume,
> >>>
> >>>On Wed, Feb 17, 2016 at 03:27:22PM -0500, Tom Rini wrote:
> On Wed, Feb 17, 2016 at 09:09:27AM +0100, Guillaume GARDET wrote:
>
> >Since commit fd61d39970b9901217efc7536d9f3a61b4e1752a:
> > spl: mmc: add break statements in spl_mmc_load_image()
> >RAW and FS boot modes are now exclusive again. So, if MMCSD_MODE_RAW
> >fails, the
> >board hangs. This patch allows to try MMCSD_MODE_FS then, if available.
> >
> >It has been tested on a beaglebone black to boot on an EXT partition.
> >
> >Signed-off-by: Guillaume GARDET
> >Cc: Tom Rini
> >Cc: Nikita Kiryanov
> >Cc: Igor Grinberg
> >Cc: Paul Kocialkowski
> >Cc: Pantelis Antoniou
> >Cc: Simon Glass
> >Cc: Matwey V. Kornilov
> >
> >---
> > common/spl/spl_mmc.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> >index c3931c6..2eef0f2 100644
> >--- a/common/spl/spl_mmc.c
> >+++ b/common/spl/spl_mmc.c
> >@@ -284,7 +284,7 @@ int spl_mmc_load_image(u32 boot_device)
> > if (!err)
> > return err;
> > #endif
> >-break;
> >+/* Fall through */
> > case MMCSD_MODE_FS:
> > debug("spl: mmc boot mode: fs\n");
> This also essentially reverts fd61d399. So Nikita, was there a specific
> use case that was broken before, or was the code just unclear in
> intentions here? Thanks!
> >>>There was no broken use case that I'm aware of. The change was made as
> >>>part of a code improvement series and was meant to address what I
> >>>consider to be bad and problematic design. Instead of reverting it
> >>>though, how about implementing something similar to what I did in the
> >>>main common/spl/spl.c:board_init_r()? You would have a weak function
> >>>that will default to the original spl_boot_mode() if not overridden,
> >>>and allow the user to define a sequence of boot modes otherwise.
> >>The thing is you broke a wanted behavior currently in use. So, the priority
> >>is to come back to the previous behavior.
> >Could you add a comment indicating that this is wanted behavior that
> >has a user, and who the user is?
>
> Not sure what you mean.
I mean something like:
/* If raw mode fails, try fs mode. Some boards, such as beaglebone black,
* depend on this funcitonality.
*/
> I think, "Fall through" code comment explains it (as you done with
> MMCSD_MODE_EMMCBOOT).
That was meant to communicate a very different type of coupling between
the two cases though..
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: if MMCSD_MODE_RAW fails, try MMCSD_MODE_FS, if available
On Thu, Feb 18, 2016 at 04:25:29PM +0200, Nikita Kiryanov wrote:
> On Thu, Feb 18, 2016 at 02:31:08PM +0100, Guillaume Gardet wrote:
> >
> >
> > Le 18/02/2016 14:07, Nikita Kiryanov a écrit :
> > >On Thu, Feb 18, 2016 at 11:06:32AM +0100, Guillaume Gardet wrote:
> > >>Hi Tom, Nikita ,
> > >>
> > >>Le 18/02/2016 10:19, Nikita Kiryanov a écrit :
> > >>>Hi Tom, Guillaume,
> > >>>
> > >>>On Wed, Feb 17, 2016 at 03:27:22PM -0500, Tom Rini wrote:
> > On Wed, Feb 17, 2016 at 09:09:27AM +0100, Guillaume GARDET wrote:
> >
> > >Since commit fd61d39970b9901217efc7536d9f3a61b4e1752a:
> > > spl: mmc: add break statements in spl_mmc_load_image()
> > >RAW and FS boot modes are now exclusive again. So, if MMCSD_MODE_RAW
> > >fails, the
> > >board hangs. This patch allows to try MMCSD_MODE_FS then, if available.
> > >
> > >It has been tested on a beaglebone black to boot on an EXT partition.
> > >
> > >Signed-off-by: Guillaume GARDET
> > >Cc: Tom Rini
> > >Cc: Nikita Kiryanov
> > >Cc: Igor Grinberg
> > >Cc: Paul Kocialkowski
> > >Cc: Pantelis Antoniou
> > >Cc: Simon Glass
> > >Cc: Matwey V. Kornilov
> > >
> > >---
> > > common/spl/spl_mmc.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > >diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> > >index c3931c6..2eef0f2 100644
> > >--- a/common/spl/spl_mmc.c
> > >+++ b/common/spl/spl_mmc.c
> > >@@ -284,7 +284,7 @@ int spl_mmc_load_image(u32 boot_device)
> > > if (!err)
> > > return err;
> > > #endif
> > >- break;
> > >+ /* Fall through */
> > > case MMCSD_MODE_FS:
> > > debug("spl: mmc boot mode: fs\n");
> > This also essentially reverts fd61d399. So Nikita, was there a specific
> > use case that was broken before, or was the code just unclear in
> > intentions here? Thanks!
> > >>>There was no broken use case that I'm aware of. The change was made as
> > >>>part of a code improvement series and was meant to address what I
> > >>>consider to be bad and problematic design. Instead of reverting it
> > >>>though, how about implementing something similar to what I did in the
> > >>>main common/spl/spl.c:board_init_r()? You would have a weak function
> > >>>that will default to the original spl_boot_mode() if not overridden,
> > >>>and allow the user to define a sequence of boot modes otherwise.
> > >>The thing is you broke a wanted behavior currently in use. So, the
> > >>priority is to come back to the previous behavior.
> > >Could you add a comment indicating that this is wanted behavior that
> > >has a user, and who the user is?
> >
> > Not sure what you mean.
>
> I mean something like:
> /* If raw mode fails, try fs mode. Some boards, such as beaglebone black,
> * depend on this funcitonality.
> */
But it's not board specific, it's use-case specific. It's saying that
instead of shoving both SPL and U-Boot into the correct magic raw
location, just shove SPL there and let U-Boot itself be in the /boot
partition. This is just as applicable on say imx6 as it is on TI parts.
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Issue with USB mass storage (thumb drives)
On 02/18/2016 11:05 AM, Schrempf Frieder wrote: > On 04.02.2016 12:28, Marek Vasut wrote: >> On Thursday, February 04, 2016 at 09:21:08 AM, Schrempf Frieder wrote: >>> On 03.02.2016 20:16, Sergei Temerkhanov wrote: On Wed, Feb 3, 2016 at 8:40 AM, Marek Vasut wrote: > On Wednesday, February 03, 2016 at 12:49:20 PM, Schrempf Frieder wrote: >> On 03.02.2016 12:12, Marek Vasut wrote: >>> On Wednesday, February 03, 2016 at 11:15:00 AM, Schrempf Frieder wrote: On 03.02.2016 10:55, Fabio Estevam wrote: > On Wed, Feb 3, 2016 at 7:40 AM, Marek Vasut wrote: >> In that case, debug time. >> >> Usual problems are bad routing of the tracks on the board , so try >> with USB 1.1 hub and if that works, that's your problem. > Another suggestion would be to try the 100MB transfer in Linux and > see if this works or not. > > That would help us to narrow down whether this is a hardware or > software problem. Another thing to try may be limiting the value of USB_MAX_XFER_BLK in common/usb_storage.c >>> This was a really helpful hint! Thank you Sergei! >>> >>> I just tried to limit USB_MAX_XFER_BLK to 1/8 of the original value >>> (65535 -> 8191) and this time the transfer works without timeouts. >>> >>> As we have a customer who needs this working as soon as possible my >>> question now is how to properly solve this. >>> Should I generally limit USB_MAX_XFER_BLK in my u-boot to avoid these >>> errors? Which value to choose? >> Nice! Can you share which sticks are those, ideally brand/type and USB IDs ? > At the moment I have two sticks with the same chip around for which > setting USB_MAX_XFER_BLK from 65535 to 32767 fixed the file transfer. > Also one of our customers tested a few non-working sticks with this > change and reported, that it fixed it for him. > Here's a list of those devices, but I guess there are a lot more: > > 1. Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) Flash > Drive, VID: 0x090c, PID: 0x1000 > 2. Freecom Technologies, VID: 0x07ab, PID: 0xfcf1 > 3. Newron, VID: 0x8644, PID: 0x800e > 4. GEMBIRD PhotoFrame PF-15-1, VID: 0x1908, PID: 0x1320 > Maybe we need a quirk table then ? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] ARM: zynq: zynqmp: Enable DCC serial driver by default
Compile DCC serial driver by default.
Signed-off-by: Michal Simek
---
include/configs/xilinx_zynqmp.h | 9 +++--
include/configs/zynq-common.h | 8 ++--
2 files changed, 5 insertions(+), 12 deletions(-)
diff --git a/include/configs/xilinx_zynqmp.h b/include/configs/xilinx_zynqmp.h
index 28622dec1882..8a9ad03cb102 100644
--- a/include/configs/xilinx_zynqmp.h
+++ b/include/configs/xilinx_zynqmp.h
@@ -53,12 +53,9 @@
#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + 0x200)
/* Serial setup */
-#if defined(CONFIG_ZYNQMP_DCC)
-# define CONFIG_ARM_DCC
-# define CONFIG_CPU_ARMV8
-#else
-# define CONFIG_ZYNQ_SERIAL
-#endif
+#define CONFIG_ARM_DCC
+#define CONFIG_CPU_ARMV8
+#define CONFIG_ZYNQ_SERIAL
#define CONFIG_CONS_INDEX 0
#define CONFIG_BAUDRATE115200
diff --git a/include/configs/zynq-common.h b/include/configs/zynq-common.h
index e8c3ef0c3872..ec4884878165 100644
--- a/include/configs/zynq-common.h
+++ b/include/configs/zynq-common.h
@@ -36,12 +36,8 @@
#define CONFIG_SYS_BAUDRATE_TABLE \
{300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200, 230400}
-/* DCC driver */
-#if defined(CONFIG_ZYNQ_DCC)
-# define CONFIG_ARM_DCC
-#else
-# define CONFIG_ZYNQ_SERIAL
-#endif
+#define CONFIG_ARM_DCC
+#define CONFIG_ZYNQ_SERIAL
#define CONFIG_ZYNQ_GPIO
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] serial: dcc: Move driver to DM
Enabling this driver requires some DT changes.
Adding DCC to root or main bus:
dcc: dcc {
compatible = "arm,dcc";
u-boot,dm-pre-reloc;
};
Extend alias list to link DCC:
serial0 = &uart0;
serial1 = &uart1;
serial2 = &dcc;
Change stdout-path to point to dcc port.
stdout-path = "serial2:115200n8";
Also add support for debug uart to help with early debug.
Signed-off-by: Michal Simek
---
drivers/serial/Kconfig | 5
drivers/serial/arm_dcc.c | 63 +---
2 files changed, 43 insertions(+), 25 deletions(-)
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index fac317610e2a..7c18a6218b1f 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -119,6 +119,11 @@ config DEBUG_UART_UARTLITE
You will need to provide parameters to make this work. The driver will
be available until the real driver-model serial is running.
+config DEBUG_UART_ARM_DCC
+ bool "ARM DCC"
+ help
+ Select this to enable a debug UART using the ARM DCC port.
+
config DEBUG_UART_ZYNQ
bool "Xilinx Zynq"
help
diff --git a/drivers/serial/arm_dcc.c b/drivers/serial/arm_dcc.c
index 4624666e8a2c..07981e18ee49 100644
--- a/drivers/serial/arm_dcc.c
+++ b/drivers/serial/arm_dcc.c
@@ -1,6 +1,7 @@
/*
* Copyright (C) 2004-2007 ARM Limited.
* Copyright (C) 2008 Jean-Christophe PLAGNIOL-VILLARD
+ * Copyright (C) 2015 - 2016 Xilinx, Inc, Michal Simek
*
* SPDX-License-Identifier:GPL-2.0
*
@@ -16,6 +17,7 @@
*/
#include
+#include
#include
#if defined(CONFIG_CPU_V6) || defined(CONFIG_CPU_V7)
@@ -94,12 +96,7 @@
#define TIMEOUT_COUNT 0x400
-static int arm_dcc_init(void)
-{
- return 0;
-}
-
-static int arm_dcc_getc(void)
+static int arm_dcc_getc(struct udevice *dev)
{
int ch;
register unsigned int reg;
@@ -112,7 +109,7 @@ static int arm_dcc_getc(void)
return ch;
}
-static void arm_dcc_putc(char ch)
+static int arm_dcc_putc(struct udevice *dev, char ch)
{
register unsigned int reg;
unsigned int timeout_count = TIMEOUT_COUNT;
@@ -123,41 +120,57 @@ static void arm_dcc_putc(char ch)
break;
}
if (timeout_count == 0)
- return;
+ return -EAGAIN;
else
write_dcc(ch);
+
+ return 0;
}
-static int arm_dcc_tstc(void)
+static int arm_dcc_pending(struct udevice *dev, bool input)
{
register unsigned int reg;
- can_read_dcc(reg);
+ if (input) {
+ can_read_dcc(reg);
+ } else {
+ can_write_dcc(reg);
+ }
return reg;
}
-static void arm_dcc_setbrg(void)
-{
-}
+static const struct dm_serial_ops arm_dcc_ops = {
+ .putc = arm_dcc_putc,
+ .pending = arm_dcc_pending,
+ .getc = arm_dcc_getc,
+};
+
+static const struct udevice_id arm_dcc_ids[] = {
+ { .compatible = "arm,dcc", },
+ { }
+};
-static struct serial_device arm_dcc_drv = {
+U_BOOT_DRIVER(serial_dcc) = {
.name = "arm_dcc",
- .start = arm_dcc_init,
- .stop = NULL,
- .setbrg = arm_dcc_setbrg,
- .putc = arm_dcc_putc,
- .puts = default_serial_puts,
- .getc = arm_dcc_getc,
- .tstc = arm_dcc_tstc,
+ .id = UCLASS_SERIAL,
+ .of_match = arm_dcc_ids,
+ .ops= &arm_dcc_ops,
+ .flags = DM_FLAG_PRE_RELOC,
};
-void arm_dcc_initialize(void)
+#ifdef CONFIG_DEBUG_UART_ARM_DCC
+
+#include
+
+static inline void _debug_uart_init(void)
{
- serial_register(&arm_dcc_drv);
}
-__weak struct serial_device *default_serial_console(void)
+static inline void _debug_uart_putc(int ch)
{
- return &arm_dcc_drv;
+ arm_dcc_putc(NULL, ch);
}
+
+DEBUG_UART_FUNCS
+#endif
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: if MMCSD_MODE_RAW fails, try MMCSD_MODE_FS, if available
On Thu, Feb 18, 2016 at 09:36:01AM -0500, Tom Rini wrote:
> On Thu, Feb 18, 2016 at 04:25:29PM +0200, Nikita Kiryanov wrote:
> > On Thu, Feb 18, 2016 at 02:31:08PM +0100, Guillaume Gardet wrote:
> > >
> > >
> > > Le 18/02/2016 14:07, Nikita Kiryanov a écrit :
> > > >On Thu, Feb 18, 2016 at 11:06:32AM +0100, Guillaume Gardet wrote:
> > > >>Hi Tom, Nikita ,
> > > >>
> > > >>Le 18/02/2016 10:19, Nikita Kiryanov a écrit :
> > > >>>Hi Tom, Guillaume,
> > > >>>
> > > >>>On Wed, Feb 17, 2016 at 03:27:22PM -0500, Tom Rini wrote:
> > > On Wed, Feb 17, 2016 at 09:09:27AM +0100, Guillaume GARDET wrote:
> > >
> > > >Since commit fd61d39970b9901217efc7536d9f3a61b4e1752a:
> > > > spl: mmc: add break statements in spl_mmc_load_image()
> > > >RAW and FS boot modes are now exclusive again. So, if MMCSD_MODE_RAW
> > > >fails, the
> > > >board hangs. This patch allows to try MMCSD_MODE_FS then, if
> > > >available.
> > > >
> > > >It has been tested on a beaglebone black to boot on an EXT partition.
> > > >
> > > >Signed-off-by: Guillaume GARDET
> > > >Cc: Tom Rini
> > > >Cc: Nikita Kiryanov
> > > >Cc: Igor Grinberg
> > > >Cc: Paul Kocialkowski
> > > >Cc: Pantelis Antoniou
> > > >Cc: Simon Glass
> > > >Cc: Matwey V. Kornilov
> > > >
> > > >---
> > > > common/spl/spl_mmc.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > >diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> > > >index c3931c6..2eef0f2 100644
> > > >--- a/common/spl/spl_mmc.c
> > > >+++ b/common/spl/spl_mmc.c
> > > >@@ -284,7 +284,7 @@ int spl_mmc_load_image(u32 boot_device)
> > > > if (!err)
> > > > return err;
> > > > #endif
> > > >-break;
> > > >+/* Fall through */
> > > > case MMCSD_MODE_FS:
> > > > debug("spl: mmc boot mode: fs\n");
> > > This also essentially reverts fd61d399. So Nikita, was there a
> > > specific
> > > use case that was broken before, or was the code just unclear in
> > > intentions here? Thanks!
> > > >>>There was no broken use case that I'm aware of. The change was made as
> > > >>>part of a code improvement series and was meant to address what I
> > > >>>consider to be bad and problematic design. Instead of reverting it
> > > >>>though, how about implementing something similar to what I did in the
> > > >>>main common/spl/spl.c:board_init_r()? You would have a weak function
> > > >>>that will default to the original spl_boot_mode() if not overridden,
> > > >>>and allow the user to define a sequence of boot modes otherwise.
> > > >>The thing is you broke a wanted behavior currently in use. So, the
> > > >>priority is to come back to the previous behavior.
> > > >Could you add a comment indicating that this is wanted behavior that
> > > >has a user, and who the user is?
> > >
> > > Not sure what you mean.
> >
> > I mean something like:
> > /* If raw mode fails, try fs mode. Some boards, such as beaglebone black,
> > * depend on this funcitonality.
> > */
>
> But it's not board specific, it's use-case specific.
The comment I proposed does not suggest it's board specific, just that
this specific use case is used by someone.
> instead of shoving both SPL and U-Boot into the correct magic raw
> location, just shove SPL there and let U-Boot itself be in the /boot
> partition. This is just as applicable on say imx6 as it is on TI parts.
I don't think that's clear enough that this is the purpose of the
missing break statement. It's a little too implicit. What I'm suggesting
is that we make it a bit more explicit, barring a rewrite.
>
> --
> Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: if MMCSD_MODE_RAW fails, try MMCSD_MODE_FS, if available
Le 18/02/2016 17:07, Nikita Kiryanov a écrit :
On Thu, Feb 18, 2016 at 09:36:01AM -0500, Tom Rini wrote:
On Thu, Feb 18, 2016 at 04:25:29PM +0200, Nikita Kiryanov wrote:
On Thu, Feb 18, 2016 at 02:31:08PM +0100, Guillaume Gardet wrote:
Le 18/02/2016 14:07, Nikita Kiryanov a écrit :
On Thu, Feb 18, 2016 at 11:06:32AM +0100, Guillaume Gardet wrote:
Hi Tom, Nikita ,
Le 18/02/2016 10:19, Nikita Kiryanov a écrit :
Hi Tom, Guillaume,
On Wed, Feb 17, 2016 at 03:27:22PM -0500, Tom Rini wrote:
On Wed, Feb 17, 2016 at 09:09:27AM +0100, Guillaume GARDET wrote:
Since commit fd61d39970b9901217efc7536d9f3a61b4e1752a:
spl: mmc: add break statements in spl_mmc_load_image()
RAW and FS boot modes are now exclusive again. So, if MMCSD_MODE_RAW fails, the
board hangs. This patch allows to try MMCSD_MODE_FS then, if available.
It has been tested on a beaglebone black to boot on an EXT partition.
Signed-off-by: Guillaume GARDET
Cc: Tom Rini
Cc: Nikita Kiryanov
Cc: Igor Grinberg
Cc: Paul Kocialkowski
Cc: Pantelis Antoniou
Cc: Simon Glass
Cc: Matwey V. Kornilov
---
common/spl/spl_mmc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index c3931c6..2eef0f2 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -284,7 +284,7 @@ int spl_mmc_load_image(u32 boot_device)
if (!err)
return err;
#endif
- break;
+ /* Fall through */
case MMCSD_MODE_FS:
debug("spl: mmc boot mode: fs\n");
This also essentially reverts fd61d399. So Nikita, was there a specific
use case that was broken before, or was the code just unclear in
intentions here? Thanks!
There was no broken use case that I'm aware of. The change was made as
part of a code improvement series and was meant to address what I
consider to be bad and problematic design. Instead of reverting it
though, how about implementing something similar to what I did in the
main common/spl/spl.c:board_init_r()? You would have a weak function
that will default to the original spl_boot_mode() if not overridden,
and allow the user to define a sequence of boot modes otherwise.
The thing is you broke a wanted behavior currently in use. So, the priority is
to come back to the previous behavior.
Could you add a comment indicating that this is wanted behavior that
has a user, and who the user is?
Not sure what you mean.
I mean something like:
/* If raw mode fails, try fs mode. Some boards, such as beaglebone black,
* depend on this funcitonality.
*/
But it's not board specific, it's use-case specific.
The comment I proposed does not suggest it's board specific, just that
this specific use case is used by someone.
instead of shoving both SPL and U-Boot into the correct magic raw
location, just shove SPL there and let U-Boot itself be in the /boot
partition. This is just as applicable on say imx6 as it is on TI parts.
I don't think that's clear enough that this is the purpose of the
missing break statement. It's a little too implicit. What I'm suggesting
is that we make it a bit more explicit, barring a rewrite.
So, maybe just:
/* If raw mode fails, try fs mode. */
?
Guillaume
--
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: if MMCSD_MODE_RAW fails, try MMCSD_MODE_FS, if available
On Thu, Feb 18, 2016 at 05:11:46PM +0100, Guillaume Gardet wrote:
>
>
> Le 18/02/2016 17:07, Nikita Kiryanov a écrit :
> >On Thu, Feb 18, 2016 at 09:36:01AM -0500, Tom Rini wrote:
> >>On Thu, Feb 18, 2016 at 04:25:29PM +0200, Nikita Kiryanov wrote:
> >>>On Thu, Feb 18, 2016 at 02:31:08PM +0100, Guillaume Gardet wrote:
>
> Le 18/02/2016 14:07, Nikita Kiryanov a écrit :
> >On Thu, Feb 18, 2016 at 11:06:32AM +0100, Guillaume Gardet wrote:
> >>Hi Tom, Nikita ,
> >>
> >>Le 18/02/2016 10:19, Nikita Kiryanov a écrit :
> >>>Hi Tom, Guillaume,
> >>>
> >>>On Wed, Feb 17, 2016 at 03:27:22PM -0500, Tom Rini wrote:
> On Wed, Feb 17, 2016 at 09:09:27AM +0100, Guillaume GARDET wrote:
>
> >Since commit fd61d39970b9901217efc7536d9f3a61b4e1752a:
> > spl: mmc: add break statements in spl_mmc_load_image()
> >RAW and FS boot modes are now exclusive again. So, if MMCSD_MODE_RAW
> >fails, the
> >board hangs. This patch allows to try MMCSD_MODE_FS then, if
> >available.
> >
> >It has been tested on a beaglebone black to boot on an EXT partition.
> >
> >Signed-off-by: Guillaume GARDET
> >Cc: Tom Rini
> >Cc: Nikita Kiryanov
> >Cc: Igor Grinberg
> >Cc: Paul Kocialkowski
> >Cc: Pantelis Antoniou
> >Cc: Simon Glass
> >Cc: Matwey V. Kornilov
> >
> >---
> > common/spl/spl_mmc.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> >index c3931c6..2eef0f2 100644
> >--- a/common/spl/spl_mmc.c
> >+++ b/common/spl/spl_mmc.c
> >@@ -284,7 +284,7 @@ int spl_mmc_load_image(u32 boot_device)
> > if (!err)
> > return err;
> > #endif
> >-break;
> >+/* Fall through */
> > case MMCSD_MODE_FS:
> > debug("spl: mmc boot mode: fs\n");
> This also essentially reverts fd61d399. So Nikita, was there a
> specific
> use case that was broken before, or was the code just unclear in
> intentions here? Thanks!
> >>>There was no broken use case that I'm aware of. The change was made as
> >>>part of a code improvement series and was meant to address what I
> >>>consider to be bad and problematic design. Instead of reverting it
> >>>though, how about implementing something similar to what I did in the
> >>>main common/spl/spl.c:board_init_r()? You would have a weak function
> >>>that will default to the original spl_boot_mode() if not overridden,
> >>>and allow the user to define a sequence of boot modes otherwise.
> >>The thing is you broke a wanted behavior currently in use. So, the
> >>priority is to come back to the previous behavior.
> >Could you add a comment indicating that this is wanted behavior that
> >has a user, and who the user is?
> Not sure what you mean.
> >>>I mean something like:
> >>>/* If raw mode fails, try fs mode. Some boards, such as beaglebone black,
> >>> * depend on this funcitonality.
> >>> */
> >>But it's not board specific, it's use-case specific.
> >The comment I proposed does not suggest it's board specific, just that
> >this specific use case is used by someone.
> >
> >>instead of shoving both SPL and U-Boot into the correct magic raw
> >>location, just shove SPL there and let U-Boot itself be in the /boot
> >>partition. This is just as applicable on say imx6 as it is on TI parts.
> >I don't think that's clear enough that this is the purpose of the
> >missing break statement. It's a little too implicit. What I'm suggesting
> >is that we make it a bit more explicit, barring a rewrite.
>
> So, maybe just:
> /* If raw mode fails, try fs mode. */
> ?
That'll work too.
>
>
> Guillaume
>
> >
> >>--
> >>Tom
> >
> >
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: if MMCSD_MODE_RAW fails, try MMCSD_MODE_FS, if available
Le 18/02/2016 17:38, Nikita Kiryanov a écrit :
On Thu, Feb 18, 2016 at 05:11:46PM +0100, Guillaume Gardet wrote:
Le 18/02/2016 17:07, Nikita Kiryanov a écrit :
On Thu, Feb 18, 2016 at 09:36:01AM -0500, Tom Rini wrote:
On Thu, Feb 18, 2016 at 04:25:29PM +0200, Nikita Kiryanov wrote:
On Thu, Feb 18, 2016 at 02:31:08PM +0100, Guillaume Gardet wrote:
Le 18/02/2016 14:07, Nikita Kiryanov a écrit :
On Thu, Feb 18, 2016 at 11:06:32AM +0100, Guillaume Gardet wrote:
Hi Tom, Nikita ,
Le 18/02/2016 10:19, Nikita Kiryanov a écrit :
Hi Tom, Guillaume,
On Wed, Feb 17, 2016 at 03:27:22PM -0500, Tom Rini wrote:
On Wed, Feb 17, 2016 at 09:09:27AM +0100, Guillaume GARDET wrote:
Since commit fd61d39970b9901217efc7536d9f3a61b4e1752a:
spl: mmc: add break statements in spl_mmc_load_image()
RAW and FS boot modes are now exclusive again. So, if MMCSD_MODE_RAW fails, the
board hangs. This patch allows to try MMCSD_MODE_FS then, if available.
It has been tested on a beaglebone black to boot on an EXT partition.
Signed-off-by: Guillaume GARDET
Cc: Tom Rini
Cc: Nikita Kiryanov
Cc: Igor Grinberg
Cc: Paul Kocialkowski
Cc: Pantelis Antoniou
Cc: Simon Glass
Cc: Matwey V. Kornilov
---
common/spl/spl_mmc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index c3931c6..2eef0f2 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -284,7 +284,7 @@ int spl_mmc_load_image(u32 boot_device)
if (!err)
return err;
#endif
- break;
+ /* Fall through */
case MMCSD_MODE_FS:
debug("spl: mmc boot mode: fs\n");
This also essentially reverts fd61d399. So Nikita, was there a specific
use case that was broken before, or was the code just unclear in
intentions here? Thanks!
There was no broken use case that I'm aware of. The change was made as
part of a code improvement series and was meant to address what I
consider to be bad and problematic design. Instead of reverting it
though, how about implementing something similar to what I did in the
main common/spl/spl.c:board_init_r()? You would have a weak function
that will default to the original spl_boot_mode() if not overridden,
and allow the user to define a sequence of boot modes otherwise.
The thing is you broke a wanted behavior currently in use. So, the priority is
to come back to the previous behavior.
Could you add a comment indicating that this is wanted behavior that
has a user, and who the user is?
Not sure what you mean.
I mean something like:
/* If raw mode fails, try fs mode. Some boards, such as beaglebone black,
* depend on this funcitonality.
*/
But it's not board specific, it's use-case specific.
The comment I proposed does not suggest it's board specific, just that
this specific use case is used by someone.
instead of shoving both SPL and U-Boot into the correct magic raw
location, just shove SPL there and let U-Boot itself be in the /boot
partition. This is just as applicable on say imx6 as it is on TI parts.
I don't think that's clear enough that this is the purpose of the
missing break statement. It's a little too implicit. What I'm suggesting
is that we make it a bit more explicit, barring a rewrite.
So, maybe just:
/* If raw mode fails, try fs mode. */
?
That'll work too.
If Tom is ok, I will send a V2.
Guillaume
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: if MMCSD_MODE_RAW fails, try MMCSD_MODE_FS, if available
On Thu, Feb 18, 2016 at 05:42:29PM +0100, Guillaume Gardet wrote:
>
>
> Le 18/02/2016 17:38, Nikita Kiryanov a écrit :
> >On Thu, Feb 18, 2016 at 05:11:46PM +0100, Guillaume Gardet wrote:
> >>
> >>Le 18/02/2016 17:07, Nikita Kiryanov a écrit :
> >>>On Thu, Feb 18, 2016 at 09:36:01AM -0500, Tom Rini wrote:
> On Thu, Feb 18, 2016 at 04:25:29PM +0200, Nikita Kiryanov wrote:
> >On Thu, Feb 18, 2016 at 02:31:08PM +0100, Guillaume Gardet wrote:
> >>Le 18/02/2016 14:07, Nikita Kiryanov a écrit :
> >>>On Thu, Feb 18, 2016 at 11:06:32AM +0100, Guillaume Gardet wrote:
> Hi Tom, Nikita ,
>
> Le 18/02/2016 10:19, Nikita Kiryanov a écrit :
> >Hi Tom, Guillaume,
> >
> >On Wed, Feb 17, 2016 at 03:27:22PM -0500, Tom Rini wrote:
> >>On Wed, Feb 17, 2016 at 09:09:27AM +0100, Guillaume GARDET wrote:
> >>
> >>>Since commit fd61d39970b9901217efc7536d9f3a61b4e1752a:
> >>> spl: mmc: add break statements in spl_mmc_load_image()
> >>>RAW and FS boot modes are now exclusive again. So, if
> >>>MMCSD_MODE_RAW fails, the
> >>>board hangs. This patch allows to try MMCSD_MODE_FS then, if
> >>>available.
> >>>
> >>>It has been tested on a beaglebone black to boot on an EXT
> >>>partition.
> >>>
> >>>Signed-off-by: Guillaume GARDET
> >>>Cc: Tom Rini
> >>>Cc: Nikita Kiryanov
> >>>Cc: Igor Grinberg
> >>>Cc: Paul Kocialkowski
> >>>Cc: Pantelis Antoniou
> >>>Cc: Simon Glass
> >>>Cc: Matwey V. Kornilov
> >>>
> >>>---
> >>> common/spl/spl_mmc.c | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>>diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> >>>index c3931c6..2eef0f2 100644
> >>>--- a/common/spl/spl_mmc.c
> >>>+++ b/common/spl/spl_mmc.c
> >>>@@ -284,7 +284,7 @@ int spl_mmc_load_image(u32 boot_device)
> >>> if (!err)
> >>> return err;
> >>> #endif
> >>>- break;
> >>>+ /* Fall through */
> >>> case MMCSD_MODE_FS:
> >>> debug("spl: mmc boot mode: fs\n");
> >>This also essentially reverts fd61d399. So Nikita, was there a
> >>specific
> >>use case that was broken before, or was the code just unclear in
> >>intentions here? Thanks!
> >There was no broken use case that I'm aware of. The change was made
> >as
> >part of a code improvement series and was meant to address what I
> >consider to be bad and problematic design. Instead of reverting it
> >though, how about implementing something similar to what I did in the
> >main common/spl/spl.c:board_init_r()? You would have a weak function
> >that will default to the original spl_boot_mode() if not overridden,
> >and allow the user to define a sequence of boot modes otherwise.
> The thing is you broke a wanted behavior currently in use. So, the
> priority is to come back to the previous behavior.
> >>>Could you add a comment indicating that this is wanted behavior that
> >>>has a user, and who the user is?
> >>Not sure what you mean.
> >I mean something like:
> >/* If raw mode fails, try fs mode. Some boards, such as beaglebone black,
> > * depend on this funcitonality.
> > */
> But it's not board specific, it's use-case specific.
> >>>The comment I proposed does not suggest it's board specific, just that
> >>>this specific use case is used by someone.
> >>>
> instead of shoving both SPL and U-Boot into the correct magic raw
> location, just shove SPL there and let U-Boot itself be in the /boot
> partition. This is just as applicable on say imx6 as it is on TI parts.
> >>>I don't think that's clear enough that this is the purpose of the
> >>>missing break statement. It's a little too implicit. What I'm suggesting
> >>>is that we make it a bit more explicit, barring a rewrite.
> >>So, maybe just:
> >> /* If raw mode fails, try fs mode. */
> >>?
> >That'll work too.
>
> If Tom is ok, I will send a V2.
OK with me, thanks!
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Issue with USB mass storage (thumb drives)
On Thu, Feb 18, 2016 at 1:32 PM, Marek Vasut wrote: >> Also one of our customers tested a few non-working sticks with this >> change and reported, that it fixed it for him. >> Here's a list of those devices, but I guess there are a lot more: >> >> 1. Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) Flash >> Drive, VID: 0x090c, PID: 0x1000 >> 2. Freecom Technologies, VID: 0x07ab, PID: 0xfcf1 >> 3. Newron, VID: 0x8644, PID: 0x800e >> 4. GEMBIRD PhotoFrame PF-15-1, VID: 0x1908, PID: 0x1320 >> > Maybe we need a quirk table then ? It seems the list of affected devices is unknown. What would be the impact of changing USB_MAX_XFER_BLK from 65535 to 32767? Would this impact the USB transfer rate? Frieder, do you know? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] spl: if MMCSD_MODE_RAW fails, try MMCSD_MODE_FS
Since commit fd61d39970b9901217efc7536d9f3a61b4e1752a:
spl: mmc: add break statements in spl_mmc_load_image()
RAW and FS boot modes are now exclusive again. So, if MMCSD_MODE_RAW fails, the
board hangs. This patch allows to try MMCSD_MODE_FS then.
It has been tested on a beaglebone black to boot on an EXT partition.
Signed-off-by: Guillaume GARDET
Cc: Tom Rini
Cc: Nikita Kiryanov
Cc: Igor Grinberg
Cc: Paul Kocialkowski
Cc: Pantelis Antoniou
Cc: Simon Glass
Cc: Matwey V. Kornilov
---
Changes in V2:
- Replace "/* Fall through */" comment by:
"/* If RAW mode fails, try FS mode. */"
common/spl/spl_mmc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index c3931c6..c27a250 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -284,7 +284,7 @@ int spl_mmc_load_image(u32 boot_device)
if (!err)
return err;
#endif
- break;
+ /* If RAW mode fails, try FS mode. */
case MMCSD_MODE_FS:
debug("spl: mmc boot mode: fs\n");
--
1.8.4.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-net.git master
Bug fixes. The following changes since commit 727a25b2418031e1b94ba603e0eb61657024091b: Prepare v2016.03-rc2 (2016-02-15 21:44:30 +) are available in the git repository at: git://git.denx.de/u-boot-net.git master for you to fetch changes up to a8c3eca43393cffef16a40e683f7a4d45b37e6ed: net: phy: marvell: Fix problem with phy_reset() clearing BMCR (2016-02-18 11:32:03 -0600) Stefan Roese (2): net: phy: marvell: Call phy_reset() where possible net: phy: marvell: Fix problem with phy_reset() clearing BMCR drivers/net/phy/marvell.c | 26 +++--- 1 file changed, 3 insertions(+), 23 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] net: phy: marvell: Call phy_reset() where possible
Hi Stefan, https://patchwork.ozlabs.org/patch/581317/ was applied to u-boot-net.git. Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] net: phy: marvell: Fix problem with phy_reset() clearing BMCR
Hi Stefan, https://patchwork.ozlabs.org/patch/581316/ was applied to u-boot-net.git. Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 1/4] ARM: at91: clock: add UTMI PLL enable/disable function
On Tue, Feb 02, 2016 at 11:11:51AM +0800, Wenyou Yang wrote:
> To avoid the duplicated code, add the UTMI PLL handle functions,
> and add PMC_USB init function too.
>
> Signed-off-by: Wenyou Yang
> Tested-by: Heiko Schocher
Reviewed-by: Andreas Bießmann
> ---
>
> Changes in v3: None
> Changes in v2: None
>
> arch/arm/mach-at91/clock.c| 48
> +
> arch/arm/mach-at91/include/mach/clk.h |3 +++
> 2 files changed, 51 insertions(+)
>
> diff --git a/arch/arm/mach-at91/clock.c b/arch/arm/mach-at91/clock.c
> index d1c4b76..6d115c9 100644
> --- a/arch/arm/mach-at91/clock.c
> +++ b/arch/arm/mach-at91/clock.c
> @@ -10,6 +10,8 @@
> #include
> #include
>
> +#define EN_UPLL_TIMEOUT 500
> +
> void at91_periph_clk_enable(int id)
> {
> struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
> @@ -70,3 +72,49 @@ void at91_system_clk_disable(int sys_clk)
>
> writel(sys_clk, &pmc->scdr);
> }
> +
> +int at91_upll_clk_enable(void)
> +{
> + struct at91_pmc *pmc = (at91_pmc_t *)ATMEL_BASE_PMC;
> + ulong start_time, tmp_time;
> +
> + if ((readl(&pmc->uckr) & AT91_PMC_UPLLEN) == AT91_PMC_UPLLEN)
> + return 0;
> +
> + start_time = get_timer(0);
> + writel(AT91_PMC_UPLLEN | AT91_PMC_BIASEN, &pmc->uckr);
> + while ((readl(&pmc->sr) & AT91_PMC_LOCKU) != AT91_PMC_LOCKU) {
> + tmp_time = get_timer(0);
> + if ((tmp_time - start_time) > EN_UPLL_TIMEOUT) {
> + printf("ERROR: failed to enable UPLL\n");
> + return -1;
> + }
> + }
> +
> + return 0;
> +}
> +
> +int at91_upll_clk_disable(void)
> +{
> + struct at91_pmc *pmc = (at91_pmc_t *)ATMEL_BASE_PMC;
> + ulong start_time, tmp_time;
> +
> + start_time = get_timer(0);
> + writel(readl(&pmc->uckr) & ~AT91_PMC_UPLLEN, &pmc->uckr);
> + while ((readl(&pmc->sr) & AT91_PMC_LOCKU) == AT91_PMC_LOCKU) {
> + tmp_time = get_timer(0);
> + if ((tmp_time - start_time) > EN_UPLL_TIMEOUT) {
> + printf("ERROR: failed to stop UPLL\n");
> + return -1;
> + }
> + }
> +
> + return 0;
> +}
> +
> +void at91_usb_clk_init(u32 value)
> +{
> + struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
> +
> + writel(value, &pmc->usb);
> +}
> diff --git a/arch/arm/mach-at91/include/mach/clk.h
> b/arch/arm/mach-at91/include/mach/clk.h
> index bef4e1c..b2604ef 100644
> --- a/arch/arm/mach-at91/include/mach/clk.h
> +++ b/arch/arm/mach-at91/include/mach/clk.h
> @@ -130,5 +130,8 @@ int at91_enable_periph_generated_clk(u32 id, u32
> clk_source, u32 div);
> u32 at91_get_periph_generated_clk(u32 id);
> void at91_system_clk_enable(int sys_clk);
> void at91_system_clk_disable(int sys_clk);
> +int at91_upll_clk_enable(void);
> +int at91_upll_clk_disable(void);
> +void at91_usb_clk_init(u32 value);
>
> #endif /* __ASM_ARM_ARCH_CLK_H__ */
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 2/4] ARM: at91: armv7: clean up UTMI PLL handle code
On Tue, Feb 02, 2016 at 11:11:52AM +0800, Wenyou Yang wrote:
> Due to introducing the UTMI PLL enable function, use this function
> to reduce the duplicated code.
>
> Signed-off-by: Wenyou Yang
> Tested-by: Heiko Schocher
Reviewed-by: Andreas Bießmann
> ---
>
> Changes in v3: None
> Changes in v2: None
>
> arch/arm/mach-at91/armv7/sama5d2_devices.c |5 +
> arch/arm/mach-at91/armv7/sama5d3_devices.c |5 +
> arch/arm/mach-at91/armv7/sama5d4_devices.c |5 +
> 3 files changed, 3 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/mach-at91/armv7/sama5d2_devices.c
> b/arch/arm/mach-at91/armv7/sama5d2_devices.c
> index 88f8f2c..978eac2 100644
> --- a/arch/arm/mach-at91/armv7/sama5d2_devices.c
> +++ b/arch/arm/mach-at91/armv7/sama5d2_devices.c
> @@ -7,7 +7,6 @@
>
> #include
> #include
> -#include
> #include
> #include
>
> @@ -48,9 +47,7 @@ char *get_cpu_name()
> #ifdef CONFIG_USB_GADGET_ATMEL_USBA
> void at91_udp_hw_init(void)
> {
> - struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
> -
> - writel(AT91_PMC_UPLLEN | AT91_PMC_BIASEN, &pmc->uckr);
> + at91_upll_clk_enable();
>
> at91_periph_clk_enable(ATMEL_ID_UDPHS);
> }
> diff --git a/arch/arm/mach-at91/armv7/sama5d3_devices.c
> b/arch/arm/mach-at91/armv7/sama5d3_devices.c
> index 78ecfc8..64ac262 100644
> --- a/arch/arm/mach-at91/armv7/sama5d3_devices.c
> +++ b/arch/arm/mach-at91/armv7/sama5d3_devices.c
> @@ -8,7 +8,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -208,10 +207,8 @@ void at91_lcd_hw_init(void)
> #ifdef CONFIG_USB_GADGET_ATMEL_USBA
> void at91_udp_hw_init(void)
> {
> - struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
> -
> /* Enable UPLL clock */
> - writel(AT91_PMC_UPLLEN | AT91_PMC_BIASEN, &pmc->uckr);
> + at91_upll_clk_enable();
> /* Enable UDPHS clock */
> at91_periph_clk_enable(ATMEL_ID_UDPHS);
> }
> diff --git a/arch/arm/mach-at91/armv7/sama5d4_devices.c
> b/arch/arm/mach-at91/armv7/sama5d4_devices.c
> index ce33cd4..ebb779e 100644
> --- a/arch/arm/mach-at91/armv7/sama5d4_devices.c
> +++ b/arch/arm/mach-at91/armv7/sama5d4_devices.c
> @@ -8,7 +8,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -37,10 +36,8 @@ char *get_cpu_name()
> #ifdef CONFIG_USB_GADGET_ATMEL_USBA
> void at91_udp_hw_init(void)
> {
> - struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
> -
> /* Enable UPLL clock */
> - writel(AT91_PMC_UPLLEN | AT91_PMC_BIASEN, &pmc->uckr);
> + at91_upll_clk_enable();
> /* Enable UDPHS clock */
> at91_periph_clk_enable(ATMEL_ID_UDPHS);
> }
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request, u-boot-tegra/master
Tom, Please pull u-boot-tegra/master into U-Boot/master. Thanks! All tegra builds are OK (32-bit and 64-bit). The following changes since commit 727a25b2418031e1b94ba603e0eb61657024091b: Prepare v2016.03-rc2 (2016-02-15 21:44:30 +) are available in the git repository at: git://git.denx.de/u-boot-tegra.git master for you to fetch changes up to 5589bc2770a7d7fe346f5972596f26d1ddf57bba: ARM: tegra: enable USB device mode port on Dalmore (2016-02-18 10:02:19 -0700) Simon Glass (24): tegra: keyboard: Fix the init order dm: video: Flush the cache after a puts() tegra: mmc: Fix comments in the MMC driver init tegra: dts: Sync up the tegra124 device tree files with Linux tegra: dts: Sync up nyan-big files with Linux tegra: gpio: Show the GPIO value for outputs tegra: pwm: Add a driver for the tegra PWM tegra: lcd: Merge tegra124-lcd.c into display.c tegra: Allow driver model to be used for the PWM tegra: Allow CONFIG_DM_VIDEO to be used as well as CONFIG_LCD tegra: nyan-big: Move the LCD driver to driver model tegra: video: Rename CONFIG_VIDEO_TEGRA to CONFIG_VIDEO_TEGRA20 tegra: dts: Sync tegra20.dtsi with Linux v4.4 tegra: video: Merge the display driver into one file tegra: video: Move the check for CONFIG_OF_CONTROL to Kconfig tegra: video: Merge the two config structures together tegra: video: Convert tegra20 LCD driver to driver model tegra: video: Remove the static variables tegra: video: Move LCD enums into the driver tegra: video: Move all fdt-decoding into a single function tegra: Convert CONFIG_PWM_TEGRA to Kconfig tegra: video: Move LCD driver to use the DM PWM driver tegra: video: Clean up the old LCD/PWM driver code video: tegra: Correct a Kconfig warning with VIDCONSOLE_AS_LCD Stephen Warren (2): ARM: tegra: don't set CONFIG_USB_MAX_CONTROLLER_COUNT ARM: tegra: enable USB device mode port on Dalmore arch/arm/dts/tegra114-dalmore.dts |9 +- arch/arm/dts/tegra124-jetson-tk1.dts| 13 + arch/arm/dts/tegra124-nyan-big.dts | 1676 ++- arch/arm/dts/tegra124-nyan.dtsi | 718 ++ arch/arm/dts/tegra124-venice2.dts | 14 + arch/arm/dts/tegra124.dtsi | 693 -- arch/arm/dts/tegra20-colibri.dts| 22 +- arch/arm/dts/tegra20-harmony.dts| 44 +- arch/arm/dts/tegra20-medcom-wide.dts| 26 +- arch/arm/dts/tegra20-paz00.dts | 43 +- arch/arm/dts/tegra20-plutux.dts |8 - arch/arm/dts/tegra20-seaboard.dts | 36 +- arch/arm/dts/tegra20-tamonten.dtsi | 15 +- arch/arm/dts/tegra20-tec.dts| 10 +- arch/arm/dts/tegra20-trimslice.dts | 34 +- arch/arm/dts/tegra20-ventana.dts| 43 +- arch/arm/dts/tegra20-whistler.dts | 35 +- arch/arm/dts/tegra20.dtsi | 541 ++-- arch/arm/include/asm/arch-tegra/dc.h|5 - arch/arm/include/asm/arch-tegra/pwm.h | 30 - arch/arm/include/asm/arch-tegra20/display.h | 108 -- arch/arm/mach-tegra/Kconfig |3 +- arch/arm/mach-tegra/Makefile|1 - arch/arm/mach-tegra/board2.c| 24 +- arch/arm/mach-tegra/pwm.c | 89 -- arch/arm/mach-tegra/tegra20/Makefile|2 - arch/arm/mach-tegra/tegra20/display.c | 378 - board/compal/paz00/paz00.c |2 +- board/toradex/colibri_t20/colibri_t20.c |2 +- configs/colibri_t20_defconfig |6 + configs/harmony_defconfig |6 + configs/medcom-wide_defconfig |6 + configs/nyan-big_defconfig | 10 + configs/paz00_defconfig |6 + configs/seaboard_defconfig |6 + configs/tec_defconfig |6 + configs/ventana_defconfig |6 + drivers/gpio/tegra_gpio.c |5 +- drivers/input/tegra-kbc.c |2 +- drivers/mmc/tegra_mmc.c |4 +- drivers/pwm/Kconfig |9 + drivers/pwm/Makefile|3 + drivers/pwm/tegra_pwm.c | 85 ++ drivers/video/Kconfig | 10 + drivers/video/Makefile |2 +- drivers/video/simple_panel.c|1 + drivers/video/tegra.c | 658 +++-- drivers/video/tegra124/Makefile |1 - drivers/video/tegra124/display.c| 18
Re: [U-Boot] [U-Boot, v3, 3/4] drivers: usb: atmel: clean up the UTMI PLL code
On Tue, Feb 02, 2016 at 11:11:53AM +0800, Wenyou Yang wrote:
> Due to introducing the new UTMI PLL clock handle functions,
> use these function to reduce the duplicated code.
>
> Signed-off-by: Wenyou Yang
> Tested-by: Heiko Schocher
Reviewed-by: Andreas Bießmann
> ---
>
> Changes in v3: None
> Changes in v2:
> - remain asm/io.h include.
>
> drivers/usb/host/ehci-atmel.c | 38 --
> drivers/usb/host/ohci-at91.c | 20 +++-
> 2 files changed, 11 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-atmel.c b/drivers/usb/host/ehci-atmel.c
> index a33fb49..1d7d280 100644
> --- a/drivers/usb/host/ehci-atmel.c
> +++ b/drivers/usb/host/ehci-atmel.c
> @@ -7,37 +7,18 @@
> */
>
> #include
> -#include
> #include
> #include
> -#include
> -#include
> #include
>
> #include "ehci.h"
>
> -/* Enable UTMI PLL time out 500us
> - * 10 times as datasheet specified
> - */
> -#define EN_UPLL_TIMEOUT 500UL
> -
> int ehci_hcd_init(int index, enum usb_init_type init,
> struct ehci_hccr **hccr, struct ehci_hcor **hcor)
> {
> - at91_pmc_t *pmc = (at91_pmc_t *)ATMEL_BASE_PMC;
> - ulong start_time, tmp_time;
> -
> - start_time = get_timer(0);
> /* Enable UTMI PLL */
> - writel(AT91_PMC_UPLLEN | AT91_PMC_BIASEN, &pmc->uckr);
> - while ((readl(&pmc->sr) & AT91_PMC_LOCKU) != AT91_PMC_LOCKU) {
> - WATCHDOG_RESET();
> - tmp_time = get_timer(0);
> - if ((tmp_time - start_time) > EN_UPLL_TIMEOUT) {
> - printf("ERROR: failed to enable UPLL\n");
> - return -1;
> - }
> - }
> + if (at91_upll_clk_enable())
> + return -1;
>
> /* Enable USB Host clock */
> at91_periph_clk_enable(ATMEL_ID_UHPHS);
> @@ -51,23 +32,12 @@ int ehci_hcd_init(int index, enum usb_init_type init,
>
> int ehci_hcd_stop(int index)
> {
> - at91_pmc_t *pmc = (at91_pmc_t *)ATMEL_BASE_PMC;
> - ulong start_time, tmp_time;
> -
> /* Disable USB Host Clock */
> at91_periph_clk_disable(ATMEL_ID_UHPHS);
>
> - start_time = get_timer(0);
> /* Disable UTMI PLL */
> - writel(readl(&pmc->uckr) & ~AT91_PMC_UPLLEN, &pmc->uckr);
> - while ((readl(&pmc->sr) & AT91_PMC_LOCKU) == AT91_PMC_LOCKU) {
> - WATCHDOG_RESET();
> - tmp_time = get_timer(0);
> - if ((tmp_time - start_time) > EN_UPLL_TIMEOUT) {
> - printf("ERROR: failed to stop UPLL\n");
> - return -1;
> - }
> - }
> + if (at91_upll_clk_disable())
> + return -1;
>
> return 0;
> }
> diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
> index da85111..6ae6959 100644
> --- a/drivers/usb/host/ohci-at91.c
> +++ b/drivers/usb/host/ohci-at91.c
> @@ -24,17 +24,13 @@ int usb_cpu_init(void)
> while ((readl(&pmc->sr) & AT91_PMC_LOCKB) != AT91_PMC_LOCKB)
> ;
> #ifdef CONFIG_AT91SAM9N12
> - writel(AT91_PMC_USBS_USB_PLLB | AT91_PMC_USB_DIV_2, &pmc->usb);
> + at91_usb_clk_init(AT91_PMC_USBS_USB_PLLB | AT91_PMC_USB_DIV_2);
> #endif
> #elif defined(CONFIG_USB_ATMEL_CLK_SEL_UPLL)
> - /* Enable UPLL */
> - writel(readl(&pmc->uckr) | AT91_PMC_UPLLEN | AT91_PMC_BIASEN,
> - &pmc->uckr);
> - while ((readl(&pmc->sr) & AT91_PMC_LOCKU) != AT91_PMC_LOCKU)
> - ;
> + if (at91_upll_clk_enable())
> + return -1;
>
> - /* Select PLLA as input clock of OHCI */
> - writel(AT91_PMC_USBS_USB_UPLL | AT91_PMC_USBDIV_10, &pmc->usb);
> + at91_usb_clk_init(AT91_PMC_USBS_USB_UPLL | AT91_PMC_USBDIV_10);
> #endif
>
> at91_periph_clk_enable(ATMEL_ID_UHP);
> @@ -60,17 +56,15 @@ int usb_cpu_stop(void)
>
> #ifdef CONFIG_USB_ATMEL_CLK_SEL_PLLB
> #ifdef CONFIG_AT91SAM9N12
> - writel(0, &pmc->usb);
> + at91_usb_clk_init(0);
> #endif
> /* Disable PLLB */
> writel(0, &pmc->pllbr);
> while ((readl(&pmc->sr) & AT91_PMC_LOCKB) != 0)
> ;
> #elif defined(CONFIG_USB_ATMEL_CLK_SEL_UPLL)
> - /* Disable UPLL */
> - writel(readl(&pmc->uckr) & (~AT91_PMC_UPLLEN), &pmc->uckr);
> - while ((readl(&pmc->sr) & AT91_PMC_LOCKU) == AT91_PMC_LOCKU)
> - ;
> + if (at91_upll_clk_disable())
> + return -1;
> #endif
>
> return 0;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 4/4] board: atmel: siemens: clean up UTMI PLL code
On Tue, Feb 02, 2016 at 11:11:54AM +0800, Wenyou Yang wrote:
> Due to introducing the new UTMI PLL clock handle functions,
> use the functions to reduce the duplicated code.
>
> Signed-off-by: Wenyou Yang
> Tested-by: Heiko Schocher
Reviewed-by: Andreas Bießmann
> ---
>
> Changes in v3:
> - collect Tested-by from Heiko Schocher.
>
> Changes in v2: None
>
> board/siemens/corvus/board.c |4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/board/siemens/corvus/board.c b/board/siemens/corvus/board.c
> index 8729fe9..658e029 100644
> --- a/board/siemens/corvus/board.c
> +++ b/board/siemens/corvus/board.c
> @@ -207,10 +207,8 @@ int board_early_init_f(void)
> /* from ./arch/arm/mach-at91/armv7/sama5d3_devices.c */
> void at91_udp_hw_init(void)
> {
> - struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
> -
> /* Enable UPLL clock */
> - writel(AT91_PMC_UPLLEN | AT91_PMC_BIASEN, &pmc->uckr);
> + at91_upll_clk_enable();
>
> /* Enable UDPHS clock */
> at91_periph_clk_enable(ATMEL_ID_UDPHS);
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 1/3] ARM: at91: clock: add PMC_PLLICPR init function
On Tue, Feb 02, 2016 at 12:46:12PM +0800, Wenyou Yang wrote:
> To avoid the duplicated code, add the PMC_PLLICPR init function.
>
> Signed-off-by: Wenyou Yang
> Tested-by: Heiko Schocher
Reviewed-by: Andreas Bießmann
> ---
>
> Changes in v3: None
> Changes in v2:
> - move at91_pllicpr_init() definition to the common file, clock.c.
> - fix checkpatch errors.
>
> arch/arm/mach-at91/clock.c |7 +++
> arch/arm/mach-at91/include/mach/at91_pmc.h |7 +++
> arch/arm/mach-at91/include/mach/clk.h |1 +
> 3 files changed, 15 insertions(+)
>
> diff --git a/arch/arm/mach-at91/clock.c b/arch/arm/mach-at91/clock.c
> index 6d115c9..8a6149e 100644
> --- a/arch/arm/mach-at91/clock.c
> +++ b/arch/arm/mach-at91/clock.c
> @@ -118,3 +118,10 @@ void at91_usb_clk_init(u32 value)
>
> writel(value, &pmc->usb);
> }
> +
> +void at91_pllicpr_init(u32 icpr)
> +{
> + struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
> +
> + writel(icpr, &pmc->pllicpr);
> +}
> diff --git a/arch/arm/mach-at91/include/mach/at91_pmc.h
> b/arch/arm/mach-at91/include/mach/at91_pmc.h
> index eb40194..7684f09 100644
> --- a/arch/arm/mach-at91/include/mach/at91_pmc.h
> +++ b/arch/arm/mach-at91/include/mach/at91_pmc.h
> @@ -246,4 +246,11 @@ typedef struct at91_pmc {
> #define AT91_PMC_GCKRDY (1 << 24)
>
> #define AT91_PMC_PROTKEY0x504d4301 /* Activation
> Code */
> +
> +/* PLL Charge Pump Current Register (PMC_PLLICPR) */
> +#define AT91_PMC_ICP_PLLA(x) (((x) & 0x3) << 0)
> +#define AT91_PMC_IPLL_PLLA(x)(((x) & 0x7) << 8)
> +#define AT91_PMC_ICP_PLLU(x) (((x) & 0x3) << 16)
> +#define AT91_PMC_IVCO_PLLU(x)(((x) & 0x3) << 24)
> +
> #endif
> diff --git a/arch/arm/mach-at91/include/mach/clk.h
> b/arch/arm/mach-at91/include/mach/clk.h
> index 64dec52..8577c74 100644
> --- a/arch/arm/mach-at91/include/mach/clk.h
> +++ b/arch/arm/mach-at91/include/mach/clk.h
> @@ -135,5 +135,6 @@ int at91_upll_clk_disable(void);
> void at91_usb_clk_init(u32 value);
> int at91_pllb_clk_enable(u32 pllbr);
> int at91_pllb_clk_disable(void);
> +void at91_pllicpr_init(u32 icpr);
>
> #endif /* __ASM_ARM_ARCH_CLK_H__ */
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 2/3] ARM: at91: clean up the PMC_PLLICPR init code
On Tue, Feb 02, 2016 at 12:46:13PM +0800, Wenyou Yang wrote:
> Due to introducing the PMC_PLLICPR init function, use this
> function to clean up the code.
>
> Signed-off-by: Wenyou Yang
> Tested-by: Heiko Schocher
Reviewed-by: Andreas Bießmann
> ---
>
> Changes in v3: None
> Changes in v2: None
>
> arch/arm/mach-at91/spl_at91.c |5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-at91/spl_at91.c b/arch/arm/mach-at91/spl_at91.c
> index b19f95b..cc3341a 100644
> --- a/arch/arm/mach-at91/spl_at91.c
> +++ b/arch/arm/mach-at91/spl_at91.c
> @@ -14,7 +14,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -77,8 +76,6 @@ void __weak spl_board_init(void)
>
> void board_init_f(ulong dummy)
> {
> - struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
> -
> lowlevel_clock_init();
> at91_disable_wdt();
>
> @@ -86,7 +83,7 @@ void board_init_f(ulong dummy)
>* At this stage the main oscillator is supposed to be enabled
>* PCK = MCK = MOSC
>*/
> - writel(0x00, &pmc->pllicpr);
> + at91_pllicpr_init(0x00);
>
> /* Configure PLLA = MOSC * (PLL_MULA + 1) / PLL_DIVA */
> at91_plla_init(CONFIG_SYS_AT91_PLLA);
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 3/3] board: atmel: clean up the PMC_PLLICPR init code
On Tue, Feb 02, 2016 at 12:46:14PM +0800, Wenyou Yang wrote:
> Due to introducing the PMC_PLLICPR init function, use this
> function to clean up the code.
>
> Signed-off-by: Wenyou Yang
> Tested-by: Heiko Schocher
Reviewed-by: Andreas Bießmann
> ---
>
> Changes in v3:
> - collect Tested-by from Heiko Schocher.
>
> Changes in v2: None
>
> board/atmel/sama5d3_xplained/sama5d3_xplained.c |4 +---
> board/atmel/sama5d3xek/sama5d3xek.c |4 +---
> board/atmel/sama5d4_xplained/sama5d4_xplained.c |4 +---
> board/atmel/sama5d4ek/sama5d4ek.c |4 +---
> 4 files changed, 4 insertions(+), 12 deletions(-)
>
> diff --git a/board/atmel/sama5d3_xplained/sama5d3_xplained.c
> b/board/atmel/sama5d3_xplained/sama5d3_xplained.c
> index d180b41..6532970 100644
> --- a/board/atmel/sama5d3_xplained/sama5d3_xplained.c
> +++ b/board/atmel/sama5d3_xplained/sama5d3_xplained.c
> @@ -10,7 +10,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -198,7 +197,6 @@ void mem_init(void)
>
> void at91_pmc_init(void)
> {
> - struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
> u32 tmp;
>
> tmp = AT91_PMC_PLLAR_29 |
> @@ -207,7 +205,7 @@ void at91_pmc_init(void)
> AT91_PMC_PLLXR_DIV(1);
> at91_plla_init(tmp);
>
> - writel(0x3 << 8, &pmc->pllicpr);
> + at91_pllicpr_init(AT91_PMC_IPLL_PLLA(0x3));
>
> tmp = AT91_PMC_MCKR_MDIV_4 |
> AT91_PMC_MCKR_CSS_PLLA;
> diff --git a/board/atmel/sama5d3xek/sama5d3xek.c
> b/board/atmel/sama5d3xek/sama5d3xek.c
> index 777e57e..7a804e8 100644
> --- a/board/atmel/sama5d3xek/sama5d3xek.c
> +++ b/board/atmel/sama5d3xek/sama5d3xek.c
> @@ -10,7 +10,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -457,7 +456,6 @@ void mem_init(void)
>
> void at91_pmc_init(void)
> {
> - struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
> u32 tmp;
>
> tmp = AT91_PMC_PLLAR_29 |
> @@ -466,7 +464,7 @@ void at91_pmc_init(void)
> AT91_PMC_PLLXR_DIV(1);
> at91_plla_init(tmp);
>
> - writel(0x3 << 8, &pmc->pllicpr);
> + at91_pllicpr_init(AT91_PMC_IPLL_PLLA(0x3));
>
> tmp = AT91_PMC_MCKR_MDIV_4 |
> AT91_PMC_MCKR_CSS_PLLA;
> diff --git a/board/atmel/sama5d4_xplained/sama5d4_xplained.c
> b/board/atmel/sama5d4_xplained/sama5d4_xplained.c
> index e95310c..3fec662 100644
> --- a/board/atmel/sama5d4_xplained/sama5d4_xplained.c
> +++ b/board/atmel/sama5d4_xplained/sama5d4_xplained.c
> @@ -8,7 +8,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -397,7 +396,6 @@ void mem_init(void)
>
> void at91_pmc_init(void)
> {
> - struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
> u32 tmp;
>
> tmp = AT91_PMC_PLLAR_29 |
> @@ -406,7 +404,7 @@ void at91_pmc_init(void)
> AT91_PMC_PLLXR_DIV(1);
> at91_plla_init(tmp);
>
> - writel(0x0 << 8, &pmc->pllicpr);
> + at91_pllicpr_init(AT91_PMC_IPLL_PLLA(0x0));
>
> tmp = AT91_PMC_MCKR_H32MXDIV |
> AT91_PMC_MCKR_PLLADIV_2 |
> diff --git a/board/atmel/sama5d4ek/sama5d4ek.c
> b/board/atmel/sama5d4ek/sama5d4ek.c
> index c92e2588..6ccbc64 100644
> --- a/board/atmel/sama5d4ek/sama5d4ek.c
> +++ b/board/atmel/sama5d4ek/sama5d4ek.c
> @@ -8,7 +8,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -393,7 +392,6 @@ void mem_init(void)
>
> void at91_pmc_init(void)
> {
> - struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
> u32 tmp;
>
> tmp = AT91_PMC_PLLAR_29 |
> @@ -402,7 +400,7 @@ void at91_pmc_init(void)
> AT91_PMC_PLLXR_DIV(1);
> at91_plla_init(tmp);
>
> - writel(0x0 << 8, &pmc->pllicpr);
> + at91_pllicpr_init(AT91_PMC_IPLL_PLLA(0x0));
>
> tmp = AT91_PMC_MCKR_H32MXDIV |
> AT91_PMC_MCKR_PLLADIV_2 |
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 2/5] ARM: at91: clock: add a new file to handle clock
On Wed, Feb 03, 2016 at 10:16:48AM +0800, Wenyou Yang wrote:
> To reduce the duplicated code, add a new file to accommodate
> the peripheral's and system's clock handle code, shared with
> the SoCs with different ARM core.
>
> Signed-off-by: Wenyou Yang
> Tested-by: Heiko Schocher
Reviewed-by: Andreas Bießmann
> ---
>
> Changes in v4:
> - due to PMC_PECR1 avaiable when has CPU_HAS_PCR, remove
>&pmc->pcer1 and &pmc->pcdr1.
>
> Changes in v3:
> - fix incorrectly used the indicator '&' to achieve the variable
>pointer of pmc->pcer and pmc->pcdr.
>
> Changes in v2: None
>
> arch/arm/mach-at91/Makefile |1 +
> arch/arm/mach-at91/arm926ejs/clock.c |7
> arch/arm/mach-at91/armv7/clock.c | 26 -
> arch/arm/mach-at91/clock.c| 66
> +
> arch/arm/mach-at91/include/mach/clk.h |2 +
> 5 files changed, 69 insertions(+), 33 deletions(-)
> create mode 100644 arch/arm/mach-at91/clock.c
>
> diff --git a/arch/arm/mach-at91/Makefile b/arch/arm/mach-at91/Makefile
> index 5b89617..d071072 100644
> --- a/arch/arm/mach-at91/Makefile
> +++ b/arch/arm/mach-at91/Makefile
> @@ -14,6 +14,7 @@ obj-$(CONFIG_SAMA5D4) += mpddrc.o spl_atmel.o matrix.o
> atmel_sfr.o
> obj-y += spl.o
> endif
>
> +obj-y += clock.o
> obj-$(CONFIG_CPU_ARM920T)+= arm920t/
> obj-$(CONFIG_CPU_ARM926EJS) += arm926ejs/
> obj-$(CONFIG_CPU_V7) += armv7/
> diff --git a/arch/arm/mach-at91/arm926ejs/clock.c
> b/arch/arm/mach-at91/arm926ejs/clock.c
> index 8d6934e..c8b5e10 100644
> --- a/arch/arm/mach-at91/arm926ejs/clock.c
> +++ b/arch/arm/mach-at91/arm926ejs/clock.c
> @@ -242,10 +242,3 @@ void at91_mck_init(u32 mckr)
> while (!(readl(&pmc->sr) & AT91_PMC_MCKRDY))
> ;
> }
> -
> -void at91_periph_clk_enable(int id)
> -{
> - struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
> -
> - writel(1 << id, &pmc->pcer);
> -}
> diff --git a/arch/arm/mach-at91/armv7/clock.c
> b/arch/arm/mach-at91/armv7/clock.c
> index 41dbf16..81e9f69 100644
> --- a/arch/arm/mach-at91/armv7/clock.c
> +++ b/arch/arm/mach-at91/armv7/clock.c
> @@ -150,32 +150,6 @@ void at91_mck_init(u32 mckr)
> ;
> }
>
> -void at91_periph_clk_enable(int id)
> -{
> - struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
> - u32 regval;
> -
> - if (id > AT91_PMC_PCR_PID_MASK)
> - return;
> -
> - regval = AT91_PMC_PCR_EN | AT91_PMC_PCR_CMD_WRITE | id;
> -
> - writel(regval, &pmc->pcr);
> -}
> -
> -void at91_periph_clk_disable(int id)
> -{
> - struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
> - u32 regval;
> -
> - if (id > AT91_PMC_PCR_PID_MASK)
> - return;
> -
> - regval = AT91_PMC_PCR_CMD_WRITE | id;
> -
> - writel(regval, &pmc->pcr);
> -}
> -
> int at91_enable_periph_generated_clk(u32 id, u32 clk_source, u32 div)
> {
> struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
> diff --git a/arch/arm/mach-at91/clock.c b/arch/arm/mach-at91/clock.c
> new file mode 100644
> index 000..2a0308f
> --- /dev/null
> +++ b/arch/arm/mach-at91/clock.c
> @@ -0,0 +1,66 @@
> +/*
> + * Copyright (C) 2015 Atmel Corporation
> + * Wenyou Yang
> + *
> + * SPDX-License-Identifier: GPL-2.0+
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +void at91_periph_clk_enable(int id)
> +{
> + struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
> +
> +#ifdef CPU_HAS_PCR
> + u32 regval;
> + u32 div_value;
> +
> + if (id > AT91_PMC_PCR_PID_MASK)
> + return;
> +
> + writel(id, &pmc->pcr);
> +
> + div_value = readl(&pmc->pcr) & AT91_PMC_PCR_DIV;
> +
> + regval = AT91_PMC_PCR_EN | AT91_PMC_PCR_CMD_WRITE | id | div_value;
> +
> + writel(regval, &pmc->pcr);
> +#else
> + writel(0x01 << id, &pmc->pcer);
> +#endif
> +}
> +
> +void at91_periph_clk_disable(int id)
> +{
> + struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
> +
> +#ifdef CPU_HAS_PCR
> + u32 regval;
> +
> + if (id > AT91_PMC_PCR_PID_MASK)
> + return;
> +
> + regval = AT91_PMC_PCR_CMD_WRITE | id;
> +
> + writel(regval, &pmc->pcr);
> +#else
> + writel(0x01 << id, &pmc->pcdr);
> +#endif
> +}
> +
> +void at91_system_clk_enable(int sys_clk)
> +{
> + struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
> +
> + writel(sys_clk, &pmc->scer);
> +}
> +
> +void at91_system_clk_disable(int sys_clk)
> +{
> + struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
> +
> + writel(sys_clk, &pmc->scdr);
> +}
> diff --git a/arch/arm/mach-at91/include/mach/clk.h
> b/arch/arm/mach-at91/include/mach/clk.h
> index ad83927..bef4e1c 100644
> --- a/arch/arm/mach-at91/include/mach/clk.h
> +++ b/arch/arm/mach-at91/include/mach/clk.h
> @@ -128,5 +128,7 @@ void at91_periph_clk_enable(int id);
> void at91_periph_clk_disable(int id);
> int at91_enable_periph_generated_clk(u32 id, u32 clk_source,
Re: [U-Boot] [U-Boot,v3] ARM: Add Support for the VInCo platform
Dear Gregory CLEMENT, Gregory CLEMENT writes: >The Versatile Industrial Communication platform is a community oriented >board from Landis + Gyr. It comes with: >- an RS-485 port >- 2 Ethernet ports >- a wireless M-BUS >- a 4G modem >- a 4MB SPI flash >- a 4GB eMMC > >Signed-off-by: Gregory CLEMENT >Acked-by: Nicolas Ferre >[rebase on current TOT] >Signed-off-by: Andreas Bießmann >--- > arch/arm/mach-at91/Kconfig | 6 ++ > board/l+g/vinco/Kconfig| 12 +++ > board/l+g/vinco/Makefile | 1 + > board/l+g/vinco/vinco.c| 212 + > configs/vinco_defconfig| 13 +++ > include/configs/vinco.h| 168 +++ > 6 files changed, 412 insertions(+) > create mode 100644 board/l+g/vinco/Kconfig > create mode 100644 board/l+g/vinco/Makefile > create mode 100644 board/l+g/vinco/vinco.c > create mode 100644 configs/vinco_defconfig > create mode 100644 include/configs/vinco.h applied to u-boot-atmel/master, thanks! I had to rebase and remove an empty newline at EOF in vinco.h. Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 2/5] ARM: at91: clock: add a new file to handle clock
Dear Wenyou Yang, Wenyou Yang writes: >To reduce the duplicated code, add a new file to accommodate >the peripheral's and system's clock handle code, shared with >the SoCs with different ARM core. > >Signed-off-by: Wenyou Yang >Tested-by: Heiko Schocher >Reviewed-by: Andreas Bießmann >--- > >Changes in v4: > - due to PMC_PECR1 avaiable when has CPU_HAS_PCR, remove > &pmc->pcer1 and &pmc->pcdr1. > >Changes in v3: > - fix incorrectly used the indicator '&' to achieve the variable > pointer of pmc->pcer and pmc->pcdr. > >Changes in v2: None > > arch/arm/mach-at91/Makefile |1 + > arch/arm/mach-at91/arm926ejs/clock.c |7 > arch/arm/mach-at91/armv7/clock.c | 26 - > arch/arm/mach-at91/clock.c| 66 + > arch/arm/mach-at91/include/mach/clk.h |2 + > 5 files changed, 69 insertions(+), 33 deletions(-) > create mode 100644 arch/arm/mach-at91/clock.c applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 1/4] ARM: at91: clock: add UTMI PLL enable/disable function
Dear Wenyou Yang, Wenyou Yang writes: >To avoid the duplicated code, add the UTMI PLL handle functions, >and add PMC_USB init function too. > >Signed-off-by: Wenyou Yang >Tested-by: Heiko Schocher >Reviewed-by: Andreas Bießmann >--- > >Changes in v3: None >Changes in v2: None > > arch/arm/mach-at91/clock.c| 48 + > arch/arm/mach-at91/include/mach/clk.h |3 +++ > 2 files changed, 51 insertions(+) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 4/5] board: atmel: clean up peripheral clock code
Dear Wenyou Yang, Wenyou Yang writes: >Due to introducing the new peripheral clock handle functions, >use these functions to reduce duplicated code. > >Signed-off-by: Wenyou Yang >Tested-by: Heiko Schocher >[Rebased on current master, fixup for at91rm9200ek] >Signed-off-by: Andreas Bießmann >--- > board/atmel/at91rm9200ek/at91rm9200ek.c | 1 - > board/atmel/at91rm9200ek/led.c | 6 ++ > board/atmel/at91sam9260ek/at91sam9260ek.c | 15 +-- > board/atmel/at91sam9261ek/at91sam9261ek.c | 8 ++-- > board/atmel/at91sam9261ek/led.c | 6 ++ > board/atmel/at91sam9263ek/at91sam9263ek.c | 23 +++ > board/atmel/at91sam9263ek/led.c | 9 +++-- > board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c | 20 +--- > board/atmel/at91sam9m10g45ek/led.c | 7 ++- > board/atmel/at91sam9n12ek/at91sam9n12ek.c | 6 ++ > board/atmel/at91sam9rlek/at91sam9rlek.c | 18 ++ > board/atmel/at91sam9rlek/led.c | 7 ++- > board/atmel/at91sam9x5ek/at91sam9x5ek.c | 10 +++--- > board/atmel/sama5d2_xplained/sama5d2_xplained.c | 1 - > board/atmel/sama5d3_xplained/sama5d3_xplained.c | 5 ++--- > board/atmel/sama5d3xek/sama5d3xek.c | 5 ++--- > board/atmel/sama5d4_xplained/sama5d4_xplained.c | 5 ++--- > board/atmel/sama5d4ek/sama5d4ek.c | 5 ++--- > board/bluewater/snapper9260/snapper9260.c | 15 +-- > board/calao/usb_a9263/usb_a9263.c | 11 --- > board/egnite/ethernut5/ethernut5.c | 20 > board/esd/meesc/meesc.c | 15 ++- > board/mini-box/picosam9g45/led.c| 7 ++- > board/mini-box/picosam9g45/picosam9g45.c| 17 - > board/ronetix/pm9261/led.c | 7 ++- > board/ronetix/pm9261/pm9261.c | 22 ++ > board/ronetix/pm9263/led.c | 7 ++- > board/ronetix/pm9263/pm9263.c | 19 +-- > board/ronetix/pm9g45/pm9g45.c | 20 ++-- > board/siemens/corvus/board.c| 6 ++ > board/siemens/smartweb/smartweb.c | 3 +-- > board/siemens/taurus/taurus.c | 3 +-- > 32 files changed, 103 insertions(+), 226 deletions(-) applied to u-boot-atmel/master, thanks! I had to rebase and fix some includes for at91rm9200ek board files. Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 2/3] ARM: at91: clean up the PMC_PLLICPR init code
Dear Wenyou Yang, Wenyou Yang writes: >Due to introducing the PMC_PLLICPR init function, use this >function to clean up the code. > >Signed-off-by: Wenyou Yang >Tested-by: Heiko Schocher >Reviewed-by: Andreas Bießmann >--- > >Changes in v3: None >Changes in v2: None > > arch/arm/mach-at91/spl_at91.c |5 + > 1 file changed, 1 insertion(+), 4 deletions(-) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 1/5] ARM: at91: asm/at91_pmc.h: fix trival register offset
Dear Wenyou Yang, Wenyou Yang writes: >Remove unnecessary #ifdef CPU_HAS_PCR. > >Signed-off-by: Wenyou Yang >Tested-by: Heiko Schocher >Reviewed-by: Andreas Bießmann >--- > >Changes in v4: None >Changes in v3: None >Changes in v2: None > > arch/arm/mach-at91/include/mach/at91_pmc.h |8 ++-- > 1 file changed, 2 insertions(+), 6 deletions(-) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 3/5] ARM: cpu: at91: clean up peripheral clock code
Dear Wenyou Yang, Wenyou Yang writes: >Due to introducing the new peripheral clock handle functions, >use these functions to clean up the duplicated code. > >Meanwhile, remove unneeded header file include, at91_pmc.h. > >Signed-off-by: Wenyou Yang >Tested-by: Heiko Schocher >Reviewed-by: Andreas Bießmann >[fixup for arm920t code] >Signed-off-by: Andreas Bießmann >--- > arch/arm/mach-at91/arm920t/at91rm9200_devices.c| 14 +++- > arch/arm/mach-at91/arm920t/timer.c | 6 ++-- > arch/arm/mach-at91/arm926ejs/at91sam9260_devices.c | 36 +-- > arch/arm/mach-at91/arm926ejs/at91sam9261_devices.c | 28 --- > arch/arm/mach-at91/arm926ejs/at91sam9263_devices.c | 37 +--- > .../mach-at91/arm926ejs/at91sam9m10g45_devices.c | 33 +- > arch/arm/mach-at91/arm926ejs/at91sam9n12_devices.c | 40 ++ > arch/arm/mach-at91/arm926ejs/at91sam9rl_devices.c | 28 --- > arch/arm/mach-at91/arm926ejs/at91sam9x5_devices.c | 38 ++-- > arch/arm/mach-at91/arm926ejs/cpu.c | 1 - > arch/arm/mach-at91/arm926ejs/timer.c | 5 +-- > arch/arm/mach-at91/armv7/cpu.c | 1 - > arch/arm/mach-at91/armv7/timer.c | 1 - > arch/arm/mach-at91/phy.c | 1 - > arch/arm/mach-at91/sdram.c | 1 - > 15 files changed, 67 insertions(+), 203 deletions(-) applied to u-boot-atmel/master, thanks! I had to fix the arm920t code for clean build of at91rm9200ek boards. Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 3/3] board: atmel: siemens: clean up PLLB code
Dear Wenyou Yang, Wenyou Yang writes: >Due to introducing the new PLLB clock handle functions, >use these functions to clean up the PLLB enable code. > >Signed-off-by: Wenyou Yang >Reviewed-by: Andreas Bießmann >Tested-by: Heiko Schocher >--- > >Changes in v4: > - collect Tested-by from Heiko Schocher. > >Changes in v3: None >Changes in v2: > - collect Reviewed-by from Andreas. > > board/siemens/smartweb/smartweb.c |6 +- > board/siemens/taurus/taurus.c |6 +- > 2 files changed, 2 insertions(+), 10 deletions(-) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 3/3] board: atmel: clean up the PMC_PLLICPR init code
Dear Wenyou Yang, Wenyou Yang writes: >Due to introducing the PMC_PLLICPR init function, use this >function to clean up the code. > >Signed-off-by: Wenyou Yang >Tested-by: Heiko Schocher >Reviewed-by: Andreas Bießmann >--- > >Changes in v3: > - collect Tested-by from Heiko Schocher. > >Changes in v2: None > > board/atmel/sama5d3_xplained/sama5d3_xplained.c |4 +--- > board/atmel/sama5d3xek/sama5d3xek.c |4 +--- > board/atmel/sama5d4_xplained/sama5d4_xplained.c |4 +--- > board/atmel/sama5d4ek/sama5d4ek.c |4 +--- > 4 files changed, 4 insertions(+), 12 deletions(-) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2] ARM: at91: sama5d2: configure the L2 cache memory
Dear Samuel Mescoff, Samuel Mescoff writes: >The SAMA5D2 has a second internal SRAM that can be reassigned as a L2 >cache memory. >Make sure it is configured as a L2 cache memory when booting from a SPL >image. > >Based on the commit b5ea95ef2b5b from the at91bootstrap repository. > >Signed-off-by: Samuel Mescoff >Reviewed-by: Wenyou Yang >Reviewed-by: Andreas Bießmann >--- > >Changes for v2: > - removed useless #ifdef CONFIG_SAMA5D2 > > arch/arm/mach-at91/atmel_sfr.c| 7 +++ > arch/arm/mach-at91/include/mach/at91_common.h | 1 + > arch/arm/mach-at91/include/mach/sama5_sfr.h | 1 + > arch/arm/mach-at91/spl_atmel.c| 4 > 4 files changed, 13 insertions(+) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 1/3] ARM: at91: clock: add PLLB enable/disable functions
Dear Wenyou Yang, Wenyou Yang writes: >To avoid the duplicated code, add the PLLB handle functions. > >Signed-off-by: Wenyou Yang >Reviewed-by: Andreas Bießmann >Tested-by: Heiko Schocher >[add enable/disable functions to arm920t] >Signed-off-by: Andreas Bießmann >--- > arch/arm/mach-at91/arm920t/clock.c| 38 +++ > arch/arm/mach-at91/arm926ejs/clock.c | 38 +++ > arch/arm/mach-at91/include/mach/clk.h | 2 ++ > 3 files changed, 78 insertions(+) applied to u-boot-atmel/master, thanks! I had to add the newly introduced enable/disable functions for arm920t for clean build of later patches. Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 4/4] board: atmel: siemens: clean up UTMI PLL code
Dear Wenyou Yang, Wenyou Yang writes: >Due to introducing the new UTMI PLL clock handle functions, >use the functions to reduce the duplicated code. > >Signed-off-by: Wenyou Yang >Tested-by: Heiko Schocher >Reviewed-by: Andreas Bießmann >--- > >Changes in v3: > - collect Tested-by from Heiko Schocher. > >Changes in v2: None > > board/siemens/corvus/board.c |4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 2/3] drivers: usb: ohci-at91: clean up the PLLB code
Dear Wenyou Yang, Wenyou Yang writes: >Due to introducing the new PLLB clock handle functions, >use these functions to clean up the PLLB enable/disable code. > >Signed-off-by: Wenyou Yang >Reviewed-by: Andreas Bießmann >Tested-by: Heiko Schocher >--- > >Changes in v4: None >Changes in v3: > - collect Reviewed-by from Andreas. > >Changes in v2: > - add return value for timeout checking at91_pllb_clk_enable/disable(). > > drivers/usb/host/ohci-at91.c | 22 +++--- > 1 file changed, 7 insertions(+), 15 deletions(-) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PULL] u-boot-atmel/master -> u-boot/master
Hi Tom, Please pull into u-boot/master. buildman for arm has a warning in one patch which is repaired some patches later in this pull. I think this is Ok since it is an unused variable warning for some boards which do not declare a specific define. The later patch will remove the warning line completely. Andreas The following changes since commit 727a25b2418031e1b94ba603e0eb61657024091b: Prepare v2016.03-rc2 (2016-02-15 21:44:30 +) are available in the git repository at: git://git.denx.de/u-boot-atmel.git master for you to fetch changes up to bb21ae82b27aa51254f32f0238d3bf60874646dd: ARM: Add Support for the VInCo platform (2016-02-18 21:46:20 +0100) Gregory CLEMENT (1): ARM: Add Support for the VInCo platform Marek Vasut (1): arm: at91: Add support for DENX MA5D4 SoM and EVK Matthias Michel (1): siemens,at91: enable features for smartweb Samuel Mescoff (1): ARM: at91: sama5d2: configure the L2 cache memory Wenyou Yang (15): ARM: at91: asm/at91_pmc.h: fix trival register offset ARM: at91: clock: add a new file to handle clock ARM: cpu: at91: clean up peripheral clock code board: atmel: clean up peripheral clock code drivers: at91: clean up peripheral clock code ARM: at91: clock: add UTMI PLL enable/disable function ARM: at91: armv7: clean up UTMI PLL handle code drivers: usb: atmel: clean up the UTMI PLL code board: atmel: siemens: clean up UTMI PLL code ARM: at91: clock: add PLLB enable/disable functions drivers: usb: ohci-at91: clean up the PLLB code board: atmel: siemens: clean up PLLB code ARM: at91: clock: add PMC_PLLICPR init function ARM: at91: clean up the PMC_PLLICPR init code board: atmel: clean up the PMC_PLLICPR init code arch/arm/mach-at91/Kconfig | 12 + arch/arm/mach-at91/Makefile| 1 + arch/arm/mach-at91/arm920t/at91rm9200_devices.c| 14 +- arch/arm/mach-at91/arm920t/clock.c | 38 ++ arch/arm/mach-at91/arm920t/timer.c | 6 +- arch/arm/mach-at91/arm926ejs/at91sam9260_devices.c | 36 +- arch/arm/mach-at91/arm926ejs/at91sam9261_devices.c | 28 +- arch/arm/mach-at91/arm926ejs/at91sam9263_devices.c | 37 +- .../mach-at91/arm926ejs/at91sam9m10g45_devices.c | 33 +- arch/arm/mach-at91/arm926ejs/at91sam9n12_devices.c | 40 +- arch/arm/mach-at91/arm926ejs/at91sam9rl_devices.c | 28 +- arch/arm/mach-at91/arm926ejs/at91sam9x5_devices.c | 38 +- arch/arm/mach-at91/arm926ejs/clock.c | 37 +- arch/arm/mach-at91/arm926ejs/cpu.c | 1 - arch/arm/mach-at91/arm926ejs/timer.c | 5 +- arch/arm/mach-at91/armv7/clock.c | 26 -- arch/arm/mach-at91/armv7/cpu.c | 1 - arch/arm/mach-at91/armv7/sama5d2_devices.c | 5 +- arch/arm/mach-at91/armv7/sama5d3_devices.c | 5 +- arch/arm/mach-at91/armv7/sama5d4_devices.c | 5 +- arch/arm/mach-at91/armv7/timer.c | 1 - arch/arm/mach-at91/atmel_sfr.c | 7 + arch/arm/mach-at91/clock.c | 121 ++ arch/arm/mach-at91/include/mach/at91_common.h | 1 + arch/arm/mach-at91/include/mach/at91_pmc.h | 15 +- arch/arm/mach-at91/include/mach/clk.h | 8 + arch/arm/mach-at91/include/mach/sama5_sfr.h| 1 + arch/arm/mach-at91/phy.c | 1 - arch/arm/mach-at91/sdram.c | 1 - arch/arm/mach-at91/spl_at91.c | 5 +- arch/arm/mach-at91/spl_atmel.c | 4 + board/atmel/at91rm9200ek/at91rm9200ek.c| 1 - board/atmel/at91rm9200ek/led.c | 6 +- board/atmel/at91sam9260ek/at91sam9260ek.c | 15 +- board/atmel/at91sam9261ek/at91sam9261ek.c | 8 +- board/atmel/at91sam9261ek/led.c| 6 +- board/atmel/at91sam9263ek/at91sam9263ek.c | 23 +- board/atmel/at91sam9263ek/led.c| 9 +- board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c| 20 +- board/atmel/at91sam9m10g45ek/led.c | 7 +- board/atmel/at91sam9n12ek/at91sam9n12ek.c | 6 +- board/atmel/at91sam9rlek/at91sam9rlek.c| 18 +- board/atmel/at91sam9rlek/led.c | 7 +- board/atmel/at91sam9x5ek/at91sam9x5ek.c| 10 +- board/atmel/sama5d2_xplained/sama5d2_xplained.c| 1 - board/atmel/sama5d3_xplained/sama5d3_xplained.c| 9 +- board/atmel/sama5d3xek/sama5d3xek.c| 9 +- board/atmel/sama5d4_xplained/sama5d4_xplained.c| 9 +- board/atmel/sama5d4ek/sama5d4ek.c | 9 +- board/bluewater/snapper9260/snapper9260.c | 15 +- board/calao/usb_a9263/usb_a9263.c | 11 +- board/denx/ma5d4evk/Kconfig
Re: [U-Boot] [U-Boot, v3, 3/4] drivers: usb: atmel: clean up the UTMI PLL code
Dear Wenyou Yang, Wenyou Yang writes: >Due to introducing the new UTMI PLL clock handle functions, >use these function to reduce the duplicated code. > >Signed-off-by: Wenyou Yang >Tested-by: Heiko Schocher >Reviewed-by: Andreas Bießmann >--- > >Changes in v3: None >Changes in v2: > - remain asm/io.h include. > > drivers/usb/host/ehci-atmel.c | 38 -- > drivers/usb/host/ohci-at91.c | 20 +++- > 2 files changed, 11 insertions(+), 47 deletions(-) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] siemens,at91: enable features for smartweb
Dear "Egli, Samuel", Samuel Egli writes: >From: Matthias Michel > >New features for smartweb: >* switch to hush command parser >* change autoboot stop to >* allow to write ethaddr > >Signed-off-by: Matthias Michel >Reviewed-by: Samuel Egli >Cc: Roger Meier >Cc: Heiko Schocher >Reviewed-by: Heiko Schocher >Reviewed-by: Andreas Bießmann >--- > configs/smartweb_defconfig | 5 - > include/configs/smartweb.h | 14 ++ > 2 files changed, 14 insertions(+), 5 deletions(-) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 2/4] ARM: at91: armv7: clean up UTMI PLL handle code
Dear Wenyou Yang, Wenyou Yang writes: >Due to introducing the UTMI PLL enable function, use this function >to reduce the duplicated code. > >Signed-off-by: Wenyou Yang >Tested-by: Heiko Schocher >Reviewed-by: Andreas Bießmann >--- > >Changes in v3: None >Changes in v2: None > > arch/arm/mach-at91/armv7/sama5d2_devices.c |5 + > arch/arm/mach-at91/armv7/sama5d3_devices.c |5 + > arch/arm/mach-at91/armv7/sama5d4_devices.c |5 + > 3 files changed, 3 insertions(+), 12 deletions(-) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 5/5] drivers: at91: clean up peripheral clock code
Dear Wenyou Yang, Wenyou Yang writes: >Due to introducing the new peripheral clock handle functions, >use these functions to reduce the duplicated code. > >Signed-off-by: Wenyou Yang >Tested-by: Heiko Schocher >[fixup for missing clk.h in at91_emac.c] >Signed-off-by: Andreas Bießmann >--- > drivers/net/at91_emac.c | 10 +- > drivers/usb/host/ehci-atmel.c | 8 > drivers/usb/host/ohci-at91.c | 20 > 3 files changed, 9 insertions(+), 29 deletions(-) applied to u-boot-atmel/master, thanks! I had to add the asm/arch/clk.h in at91_emac.c for clean build of this patch. Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 1/3] ARM: at91: clock: add PMC_PLLICPR init function
Dear Wenyou Yang, Wenyou Yang writes: >To avoid the duplicated code, add the PMC_PLLICPR init function. > >Signed-off-by: Wenyou Yang >Tested-by: Heiko Schocher >Reviewed-by: Andreas Bießmann >--- > >Changes in v3: None >Changes in v2: > - move at91_pllicpr_init() definition to the common file, clock.c. > - fix checkpatch errors. > > arch/arm/mach-at91/clock.c |7 +++ > arch/arm/mach-at91/include/mach/at91_pmc.h |7 +++ > arch/arm/mach-at91/include/mach/clk.h |1 + > 3 files changed, 15 insertions(+) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm: at91: Add support for DENX MA5D4 SoM and EVK
Dear Marek Vasut, Marek Vasut writes: >Add support for DENX MA5D4 SoM and MA5D4EVK board, based on the >Atmel SAMA5D4 SoC. The SoM contains the SoC, eMMC, SPI NOR, SPI >CAN controllers and DRAM, the baseboard contains UART connectors, >ethernet port, microSD slot, LCD header, 2x CAN connector and a >lot of expansion headers. > >Signed-off-by: Marek Vasut >Cc: Andreas Bießmann >Reviewed-by: Heiko Schocher >Reviewed-by: Andreas Bießmann >--- >V2: Remove the BDI commands, that was just a development remnant >--- > arch/arm/mach-at91/Kconfig | 6 + > board/denx/ma5d4evk/Kconfig | 12 ++ > board/denx/ma5d4evk/MAINTAINERS | 6 + > board/denx/ma5d4evk/Makefile| 7 + > board/denx/ma5d4evk/ma5d4evk.c | 412 > configs/ma5d4evk_defconfig | 11 ++ > include/configs/ma5d4evk.h | 255 + > 7 files changed, 709 insertions(+) > create mode 100644 board/denx/ma5d4evk/Kconfig > create mode 100644 board/denx/ma5d4evk/MAINTAINERS > create mode 100644 board/denx/ma5d4evk/Makefile > create mode 100644 board/denx/ma5d4evk/ma5d4evk.c > create mode 100644 configs/ma5d4evk_defconfig > create mode 100644 include/configs/ma5d4evk.h applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Intel Braswell support
Hi Stefan, I see Intel has released FSP package for Intel Braswell, the successor of Intel BayTrail. Actually on the FSP website, they released 3 new FSP packages, which are: Braswell, Broadwell and Broadwell-DE. I remember you got a customer who wanted Braswell support. Will you plan to add that support to U-Boot? Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] where is malloc()?
I can find malloc.h describing that it uses a specific malloc. But I can't seem to find where the u-boot source keeps the malloc implementation. I see that in include/_exports.h it is defined: EXPORT_FUNC(malloc) Also there seems to be a dlmalloc.c that should define a void* malloc(size) function but I can't seem to find it in here. Is there some macro magic here? -- View this message in context: http://u-boot.10912.n7.nabble.com/where-is-malloc-tp246389.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-Boot loading kernel from mmc question
I am trying to figure out how the bootm command in U-Boot works. It seems to be a state machine that goes from start->findos->findother (fdt)->loados etc. However I am having trouble understanding how, since my linux image is stored in some partition on the device (eMMC), does that get loaded into memory? Originally I thought this was what bootm_find_os and bootm_load_os does, but they don't seem to access the block devices or filesystem or contain code that reads in the linux and fdt images into memory. Am I missing a step here? -- View this message in context: http://u-boot.10912.n7.nabble.com/U-Boot-loading-kernel-from-mmc-question-tp246390.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot loading kernel from mmc question
Dear quantumlight, In message <1455856589187-246390.p...@n7.nabble.com> you wrote: > I am trying to figure out how the bootm command in U-Boot works. It seems to > be a state machine that goes from start->findos->findother (fdt)->loados > etc. > > However I am having trouble understanding how, since my linux image is > stored in some partition on the device (eMMC), does that get loaded into > memory? No, it doesn't. The 'm' inte "bootm" command name stands for "memory", i. e. "boot from memory". Bootm is used on images that can be found somewhere in the processor's memor address space. So unless you have parallel NOR flash or similar, booting is always a two step procedure: in the first step you load the image from MMC into RAM, then you use bootm. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Q: What do you get when you cross an ethernet with an income statement? A: A local area networth. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] where is malloc()?
depending on your config it's either in common/malloc_simple.c (#define malloc malloc_simple) or in common/dlmalloc.c (Void_t* mALLOc(size_t bytes) and # define mALLOc malloc). Michael On Fri, Feb 19, 2016 at 2:52 AM, quantumlight wrote: > I can find malloc.h describing that it uses a specific malloc. But I can't > seem to find where the u-boot source keeps the malloc implementation. > > I see that in include/_exports.h it is defined: > >EXPORT_FUNC(malloc) > > Also there seems to be a dlmalloc.c that should define a void* malloc(size) > function but I can't seem to find it in here. Is there some macro magic > here? > > > > > -- > View this message in context: > http://u-boot.10912.n7.nabble.com/where-is-malloc-tp246389.html > Sent from the U-Boot mailing list archive at Nabble.com. > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] where is malloc()?
Thanks I see it now. -- View this message in context: http://u-boot.10912.n7.nabble.com/where-is-malloc-tp246389p246393.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
