RGMII handling in Marvell PHY driver wrong?
Hello
Since commit 68e6ecadc551 ("net: phy: marvell 88e151x: Fix handling of
RGMII interface types") it is possible to set the Rx/Tx delays settings
of Marvell PHYs from the DTS.
The code handled all 4 possible cases ("PHY_INTERFACE_MODE_RGMII",
"PHY_INTERFACE_MODE_RGMII_ID", "PHY_INTERFACE_MODE_RGMII_RXID",
"PHY_INTERFACE_MODE_RGMII_TXID") of the Rx/Tx delay bits in the MSCR
register.
Later, commit 431be621c6cb ("net: phy: marvell 88e151x: Fix handling of
bare RGMII interface type") merged the "PHY_INTERFACE_MODE_RGMII" and
"PHY_INTERFACE_MODE_RGMII_ID" cases, effectively loosing the possibility
to specify Rx/Tx delay bits both cleared.
This looks wrong for at least two reasons:
- How does one describe a system with a Rx/Tx delay bits clear
requirement in the DTS properly?
- The Linux Marvell PHY driver does not merge the
"PHY_INTERFACE_MODE_RGMII" and "PHY_INTERFACE_MODE_RGMII_ID"
cases either.
Therefore I think commit 431be621c6cb should be reverted.
Or am I missing something here?
Re: [U-Boot] [PATCH] drivers: pci: imx: fix imx_pcie_remove function
Hi Fabio Fabio Estevam wrote: > From: Sven-Ola Tuecke > > However, at least on some i.MX6 custom boards, when calling By "some", I assume that not all i.MX6 systems are showing this behaviour. Does anyone have an idea which systems are affected and which are not? > assert_core_reset() as part of the first-time PCIe init, read access > to PCIE_PL_PFLR simply hangs. Surround this readl() with > imx_pcie_fix_dabt_handler() does not help. For this reason, the forced > LTSSM detection is only used on the second assert_core_reset() that is > called shorly before starting the Linux kernel. > > Signed-off-by: Sven-Ola Tuecke > Signed-off-by: Fabio Estevam Seems to work on our board therefore Tested-by: David Müller ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers: pci: imx: add imx_pcie_remove function
Marek Vasut wrote: > On 09/22/2017 04:00 PM, David Müller (ELSOFT AG) wrote: >> On my custom MX6Q board, the code hangs on the read of the >> "PCIE_PL_PFLR". Please note that this code sequence is not entered >> the first time after a power up; I have to execute a U-Boot reset >> to actually trigger the hang. Any ideas what is going wrong? > > MX6Q PCIe reset breakage strikes again ? I thought this piece of code was added as work-around to fix the "MX6Q PCIe reset" problem. Or are you talking about something different? Dave ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers: pci: imx: add imx_pcie_remove function
Hello
Does the code below really work?
On my custom MX6Q board, the code hangs on the read of the
"PCIE_PL_PFLR". Please note that this code sequence is not entered the
first time after a power up; I have to execute a U-Boot reset to
actually trigger the hang. Any ideas what is going wrong?
While debugging it, I also noticed the two problems below.
Tim Harvey wrote:
> + if (is_mx6dq()) {
> + u32 val, gpr1, gpr12;
> +
> + gpr1 = readl(&iomuxc_regs->gpr[1]);
> + gpr12 = readl(&iomuxc_regs->gpr[12]);
> + if ((gpr1 & IOMUXC_GPR1_PCIE_REF_CLK_EN) &&
> + (gpr12 & IOMUXC_GPR12_PCIE_CTL_2)) {
This could be (gpr12 & IOMUXC_GPR12_APPS_LTSSM_ENABLE)) {
> + val = readl(MX6_DBI_ADDR + PCIE_PL_PFLR);
> + val &= ~PCIE_PL_PFLR_LINK_STATE_MASK;
> + val |= PCIE_PL_PFLR_FORCE_LINK;
> +
> + imx_pcie_fix_dabt_handler(true);
> + writel(val, MX6_DBI_ADDR + PCIE_PL_PFLR);
> + imx_pcie_fix_dabt_handler(false);
> +
> + gpr12 &= ~IOMUXC_GPR12_PCIE_CTL_2;
> + writel(val, &iomuxc_regs->gpr[12]);
I think this should be
writel(gpr12, &iomuxc_regs->gpr[12]);
or even better
clrbits_le32(&iomuxc_regs->gpr[12],
IOMUXC_GPR12_APPS_LTSSM_ENABLE);
as in the rest of the file.
Dave
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/4] arm: Remove smdk2410 board
Simon Glass wrote: > This board has not been converted to DM_SERIAL by the deadline. > Remove it. > > Signed-off-by: Simon Glass Acked-by: David Müller ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] arm: Remove VCMA9 board
Simon Glass wrote: > This board has not been converted to DM_SERIAL by the deadline. > Remove it. > > Signed-off-by: Simon Glass Acked-by: David Müller ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/4] serial: Drop the s3c24x0 serial driver
Simon Glass wrote: > This is not used by any boards. Drop it. > > Signed-off-by: Simon Glass Acked-by: David Müller ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Samsung I2C driver
Hello I'm currently implementing DM support in the s3c24xx serial driver and activating DM support for the VCMA9 board using CONFIG_DM=y CONFIG_DM_SERIAL=y CONFIG_OF_CONTROL=y CONFIG_OF_EMBED=y CONFIG_DEFAULT_DEVICE_TREE="s3c24xx-vcma9" This results in the following problem: CC drivers/i2c/s3c24x0_i2c.o drivers/i2c/s3c24x0_i2c.c: In function 'process_nodes': drivers/i2c/s3c24x0_i2c.c:1024:12: error: 'PINMUX_FLAG_HS_MODE' undeclared (first use in this function) drivers/i2c/s3c24x0_i2c.c:1024:12: note: each undeclared identifier is reported only once for each function it appears in drivers/i2c/s3c24x0_i2c.c:1035:3: warning: implicit declaration of function 'pinmux_decode_periph_id' [-Wimplicit-function-declaration] drivers/i2c/s3c24x0_i2c.c:1041:3: warning: implicit declaration of function 'exynos_pinmux_config' [-Wimplicit-function-declaration] make[1]: *** [drivers/i2c/s3c24x0_i2c.o] Error 1 Do you have an updated version of the s3c24xx I2C driver available yet? Thanks ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] arm: make sure board_init_r() is being called using the right mode (ARM / THUMB)
Hello Tom Rini wrote: > On Tue, Feb 09, 2016 at 04:48:28PM +0100, David Müller wrote: >> /* call board_init_r */ >> +#if defined(CONFIG_SYS_THUMB_BUILD) >> +ldr lr, =board_init_r /* this is auto-relocated! */ >> +bx lr >> +#else >> ldr pc, =board_init_r /* this is auto-relocated! */ >> - >> +#endif >> /* we should not return here. */ >> #endif > > In general, my preference is always to use the thumb compatible way, can > you rework like that and explain in the commit message? Thanks! AFAIK, the "bx" instruction is undefined on non-THUMB capable architectures. I therefore don't see a way to avoid some kind of #if/#else/#endif construct. Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] CONFIG_MODEM_SUPPORT / CONFIG_HWFLOW still in use?
Hello While trying to convert the serial_s3c24x0.c driver to DM, I noticed that no offical U-Boot configuration seems to be using the CONFIG_MODEM_SUPPORT or CONFIG_HWFLOW option. Do you know if these two options are still in use somewhere else? Or can all the references to these options be removed irrevocably? > git grep CONFIG_MODEM_SUPPORT | uniq README: CONFIG_MODEM_SUPPORT arch/powerpc/cpu/mpc8xx/serial.c:#ifdef CONFIG_MODEM_SUPPORT common/Makefile:obj-$(CONFIG_MODEM_SUPPORT) += modem.o common/board_f.c:#ifdef CONFIG_MODEM_SUPPORT common/main.c:#ifdef CONFIG_MODEM_SUPPORT drivers/serial/serial_s3c24x0.c:#ifdef CONFIG_MODEM_SUPPORT include/asm-generic/global_data.h:#ifdef CONFIG_MODEM_SUPPORT > git grep CONFIG_HWFLOW | uniq README: CONFIG_HWFLOW common/modem.c:#ifdef CONFIG_HWFLOW doc/README.Modem:UART driver supports it (see CONFIG_HWFLOW compile-time flag in drivers/serial/serial_imx.c:#ifdef CONFIG_HWFLOW drivers/serial/serial_s3c24x0.c:#ifdef CONFIG_HWFLOW Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Converting serial_s3c24x0.c to driver model
Hello Simon Glass wrote: > I'm sorry if you have not heard about this before. I sent out an email > to all maintainers some months ago. > You are listed as the maintainer of a few boards which use the > serial_s3c24x0.c serial driver. We are trying to convert all of these > drivers to driver model. Please see doc/driver-model/serial-howto.txt. > > Do you have an update please? Sorry, seems that I missed your previous message somehow. Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Asymmetry in setting of "fileaddr" variable
Hello In net/net.c::net_loop(), the variables "fileaddr" and "filesize" are both set in case of a successful transfer. In fs/fs.c::do_load(), just the variable "filesize" is set in case of success. Is this asymmetry intentional or a mistake? Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Samsung I2C driver
Simon Glass wrote: > David are you able to move your board to driver model for i2c? To be frank, I don't know it (yet). Being a total DM novice, it is difficult for me to estimate the amount of effort needed to do the conversion. Is it really possible to convert just the I2C subsystem to DM and keep the rest as is? Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 08/12] board: mpl: Move common headers to board-common directory
Hello
Nishanth Menon wrote:
> Header files can be located in a generic location without needing to
> reference them with ../common/
>
> board/mpl/common/{ => include/board-common}/common_util.h (100%)
> rename board/mpl/common/{ => include/board-common}/isa.h (100%)
Correct me if I'm missing something here but I don't see the actual gain
of doing this. "board/mpl/common" contains MPL specific things which
should be kept as locally to the MPL boards directory as possible.
For example how is a potential other "isa.h" file from another vendor
and/or board handled? By using a prefix/suffix?
Dave
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] PCIe related i.MX6QP patches
Hello Do you have some PCIe related i.MX6QP patches which you could make public? I have a i.MX6QP based custom board which seems to work quite well expect for PCIe. The first access done by U-Boot to the PCIe host controller registers causes a hang. I assume a not correctly enabled clock to be the culprit. TIA Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] PATI: fix broken SPI access
Jagan Teki wrote:
> On 30 September 2014 18:41, David Müller (ELSOFT AG)
> wrote:
>> Jagan Teki wrote:
>>> On 30 September 2014 16:53, David Müller wrote:
>>>> +int board_early_init_f(void)
>>>> +{
>>>> + spi_init_f();
>>>
>>> Why you need to do this, spi_init_f is trying to call from
>>> arch/powerpc/lib/board.c
>>> any specific reason, I couldn't understand the fix you mentioned on
>>> the commit body.
>>
>> There is an EEPROM attached to the SPI channel containing vital board
>> data. Calling spi_init_f() from arch/powerpc/lib/board.c will be too late.
>
> Sorry, this looks an other issue - but anyway we're trying to remove
What kind of "other issue" do you mean?
> spi_init* stuff
> from drivers/spi/* in future and I don't think it's a good idea to use that.
In this case what is the proposed way of initializing the SPI subsystem?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] PATI: fix broken SPI access
Jagan Teki wrote:
> On 30 September 2014 16:53, David Müller wrote:
>> +int board_early_init_f(void)
>> +{
>> + spi_init_f();
>
> Why you need to do this, spi_init_f is trying to call from
> arch/powerpc/lib/board.c
> any specific reason, I couldn't understand the fix you mentioned on
> the commit body.
There is an EEPROM attached to the SPI channel containing vital board
data. Calling spi_init_f() from arch/powerpc/lib/board.c will be too late.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot hangs on imx6 pci driver
Tim Harvey wrote: > When enabling PCI support in u-boot my 3.14 kernel hangs somewhere > during PCI init or enumeration (can't tell as uart is not up yet) Enabling "earlyprintk" support may help. > David, on your board(s) do you have a PCIe switch as well? Not yet, but this (using a PEX8603) is planned for the near future. Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot hangs on imx6 pci driver
Fabio Estevam wrote:
> On Wed, May 28, 2014 at 4:40 AM, "David Müller (ELSOFT AG)"
> wrote:
>> I use an additional delay in imx6_add_pcie_port() as a workaround so far.
>
> How much of additional delay? Could you please share your patch?
diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
index ee08250..1accc0e 100644
--- a/drivers/pci/host/pci-imx6.c
+++ b/drivers/pci/host/pci-imx6.c
@@ -503,6 +532,9 @@ static int imx6_add_pcie_port(struct pcie_port *pp,
pp->root_bus_nr = -1;
pp->ops = &imx6_pcie_host_ops;
+ /* FIXME kernel hangs without this delay */
+ usleep_range(2, 25000);
+
spin_lock_init(&pp->conf_lock);
ret = dw_pcie_host_init(pp);
if (ret) {
Dave
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot hangs on imx6 pci driver
Marek Vasut wrote: > Observed Results: After some hundreds of the soft-reboot cycles, the > i210 is not recognized. This is caused by the PCI express link > failing to come up. We see "link never came up" message in the kernel > log. Just a guest but maybe this is "errata #18" of the i210. A little bit off-topic but i'm facing the problem that Linux (kernel 3.14 + some patches) hangs regularly during PCIe initialisation on our custom iMX6 / i210 board. I use an additional delay in imx6_add_pcie_port() as a workaround so far. Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot hangs on imx6 pci driver
Marek Vasut wrote: > Take a look at SR# 1-1347946851 in the FSL internal bug tracker. It > looks like the PCIe IP core implementation in the MX6 is bugged in my > opinion. Are there any publicly available info regarding this SR? Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] iMX6 PCie inbound traffic not working
Krunal Desai wrote: > Can you get a dump of config space for the 82574? What are its BARs? => pci display 1.0.0 0 40 : 10d38086 0016 0200 0010 0010: 0110 01010001 0112 0020: 8086 0030: 00c8 0100 0040: 0050: 0060: 0070: 0080: 0090: 00a0: 0011 0003 2003 00b0: 00c0: c822d001 0f002000 00d0: 0080e005 00e0: 0001a010 8cc1 00112810 04031c11 00f0: 1011 Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] iMX6 PCie inbound traffic not working
Hello I tried to use a Intel 82574 based miniPCIe NIC on a Freescale iMX6 eval board as shown below. It seems that the NIC is unable to read and/or write the descriptors in system memory. The settings of the PCIe core registers seems to be OK (according to the iMX6 RM). Any idea what i am missing? U-Boot 2014.04-00078-gadcdeac-dirty (Apr 24 2014 - 15:40:02) CPU: Freescale i.MX6Q rev1.2 at 792 MHz Reset cause: WDOG Board: MX6-SabreSD DRAM: 1 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2 *** Warning - bad CRC, using default environment 00:01.0 - 16c3:abcd - Bridge device 01:00.0- 8086:10d3 - Network controller No panel detected: default to Hannstar-XGA Display: Hannstar-XGA (1024x768) In:serial Out: serial Err: serial Net: e1000: 00:03:1d:0c:57:86 e1000#0 Warning: e1000#0 using MAC address from net device Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] e1000: remove redundant assignment
> Signed-off-by: David Mueller > Joe Hershberger Sorry, Cc missing. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] How to convert iMX6 IOMux data to U-Boot format
Hello Is there a tool or script to convert the iMX6 IOmux data generated to the Freescale IOMux tool into the format used by U-Boot? Any hints are appreciated. Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] VCMA9: Enable CONFIG_CMD_NAND_YAFFS
Tom Rini wrote: > As this board has NAND and supports YAFFS2, add CONFIG_MD_NAND_YAFFS > > Cc: David Müller > Signed-off-by: Tom Rini Acked-by: David Müller ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PING] Re: [PATCH V3] ARM: fix s3c2410 timer code
Hello Any news? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] add STM29F400BB to table of supported legacy flashs
Signed-off-by: David Mueller
diff --git a/drivers/mtd/jedec_flash.c b/drivers/mtd/jedec_flash.c
index 36d30c3..2350f36 100644
--- a/drivers/mtd/jedec_flash.c
+++ b/drivers/mtd/jedec_flash.c
@@ -69,6 +69,9 @@
#define SST39SF010A0x00B5
#define SST39SF020A0x00B6
+/* STM */
+#define STM29F400BB0x00D6
+
/* MXIC */
#define MX29LV040 0x004F
@@ -346,6 +349,23 @@ static const struct amd_flash_info jedec_table[] = {
ERASEINFO(0x1, 15),
}
},
+ {
+ .mfr_id = (u16)STM_MANUFACT,
+ .dev_id = STM29F400BB,
+ .name = "ST Micro M29F400BB",
+ .uaddr = {
+ [1] = MTD_UADDR_0x0555_0x02AA /* x16 */
+ },
+ .DevSize= SIZE_512KiB,
+ .CmdSet = CFI_CMDSET_AMD_LEGACY,
+ .NumEraseRegions= 4,
+ .regions= {
+ ERASEINFO(0x04000, 1),
+ ERASEINFO(0x02000, 2),
+ ERASEINFO(0x08000, 1),
+ ERASEINFO(0x1, 7),
+ }
+ },
#endif
};
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PING] Re: [PATCH 0/4] use CFI driver for all MPL boards
Hello Any news? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PING] Re: [PATCH] ARM: activate DISPLAY_CPUINFO for VCMA9 + SMDK2410 board
Hello Any news? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PING] Re: [PATCH V3] ARM: fix s3c2410 timer code
Hello Any news? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot maintainers: some boards are broken by recent mach-type update
Hi Albert Albert ARIBAUD wrote: > U-Boot maintainers of such boards (in Cc: of this mail) should provide a > patch to re-introduce the MACH_TYPE_XX definition in their boards' > config header file in include/configs/. Could you please apply the following patches: - http://patchwork.ozlabs.org/patch/122787/ - http://patchwork.ozlabs.org/patch/122786/ Thank you Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2011.06-rc1 released
Hello Albert ARIBAUD wrote: > In message<4dd760eb.2050...@elsoft.ch> you wrote: >> >> please also apply the following patch and friends >> >> http://patchwork.ozlabs.org/patch/93595/ >> >> this will make VCMA9 board work with current U-Boot release. > > Applied to arm tree, will send a pull request later today. Could you please also apply the second half of this patch serie: - http://patchwork.ozlabs.org/patch/93598/ - http://patchwork.ozlabs.org/patch/93599/ - http://patchwork.ozlabs.org/patch/93601/ Thank you Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2011.06-rc1 released
Hello, please also apply the following patch and friends http://patchwork.ozlabs.org/patch/93595/ this will make VCMA9 board work with current U-Boot release. Thank you Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc83xx fdt: do not adjust clock frequency of external UARTs
Tabi Timur-B04825 wrote:
> May I see it?
Please see attached file.
Dave
/*
*
* Copyright 2005, 2006 Freescale Semiconductor Inc.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
* Free Software Foundation; either version 2 of the License, or (at your
* option) any later version.
*
* Modified for MIP470
*
*/
/dts-v1/;
/ {
model = "MIP470-1";
compatible = "MIP470";
#address-cells = <1>;
#size-cells = <1>;
aliases {
ethernet0 = &enet0;
ethernet1 = &enet1;
serial0 = &serial0;
serial1 = &serial1;
serial2 = &serial2;
serial3 = &serial3;
pci0 = &pci0;
};
cpus {
#address-cells = <1>;
#size-cells = <0>;
PowerPC,8347@0 {
device_type = "cpu";
reg = <0x0>;
d-cache-line-size = <0x20>; // 32 bytes
i-cache-line-size = <0x20>; // 32 bytes
d-cache-size = <0x8000>;// L1, 32K
i-cache-size = <0x8000>;// L1, 32K
timebase-frequency = <0x0>; // from bootloader
bus-frequency = <0x0>; // from bootloader
clock-frequency = <0x0>;// from bootloader
};
};
memory {
device_type = "memory";
reg = <0x 0x2000>; // 512MB at 0
};
soc8347@ff40 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
compatible = "simple-bus";
ranges = <0x 0xff40 0x0010>;
reg = <0xff40 0x0200>;
bus-frequency = <0>;
wdt@200 {
device_type = "watchdog";
compatible = "mpc83xx_wdt";
reg = <0x200 0x100>;
};
i2c@3000 {
#address-cells = <1>;
#size-cells = <0>;
cell-index = <0>;
compatible = "fsl-i2c";
reg = <0x3000 0x100>;
interrupts = <14 0x8>;
interrupt-parent = <&ipic>;
dfsrr;
};
i2c@3100 {
#address-cells = <1>;
#size-cells = <0>;
cell-index = <1>;
compatible = "fsl-i2c";
reg = <0x3100 0x100>;
interrupts = <15 0x8>;
interrupt-parent = <&ipic>;
dfsrr;
};
dma@82a8 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,mpc8349-dma", "fsl,elo-dma";
reg = <0x82a8 4>;
ranges = <0 0x8100 0x1a8>;
interrupt-parent = <&ipic>;
interrupts = <71 8>;
cell-index = <0>;
dma-channel@0 {
compatible = "fsl,mpc8349-dma-channel",
"fsl,elo-dma-channel";
reg = <0 0x80>;
cell-index = <0>;
interrupt-parent = <&ipic>;
interrupts = <71 8>;
};
dma-channel@80 {
compatible = "fsl,mpc8349-dma-channel",
"fsl,elo-dma-channel";
reg = <0x80 0x80>;
cell-index = <1>;
interrupt-parent = <&ipic>;
interrupts = <71 8>;
};
dma-channel@100 {
compatible = "fsl,mpc8349-dma-channel",
"fsl,elo-dma-channel";
reg = <0x100 0x80>;
cell-index = <2>;
interrupt-parent = <&ipic>;
interrupts = <71 8>;
};
dma-channel@180 {
compatible = "fsl,mpc8349-dma-channel",
"fsl,elo-dma-channel";
reg = <0x180 0x28>;
cell-index = <3>;
interrupt-parent = <&ipic>;
interrupts = <71 8>;
};
};
usb@22000 {
Re: [U-Boot] [PATCH] mpc83xx fdt: do not adjust clock frequency of external UARTs
Hello Timur Tabi wrote: > Just out of curiosity -- do you have an example of a device tree with > an external UART? Yes. Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5 2/4] SMDK2410: remove unneeded config.mk
Minkyu Kang wrote: >> IMHO "Zero" should be correct with activated ARM reloc. > > Sorry but I can't understand. > Why? > Please let me know. Excerpt from doc/README.arm-relocation: maybe adapt CONFIG_SYS_TEXT_BASE (this must be checked from board maintainers) This *must* be done for boards, which boot from NOR flash The SMDK2410 is booting from NOR flash (at least it is currently configured that way) and flash is mapped at address 0. Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5 1/4] SMDK2410: activate ARM relocation feature
Minkyu Kang wrote: >> You are talking about the "#undef", right? > > Right. :) Ok, will be done. Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5 2/4] SMDK2410: remove unneeded config.mk
Minkyu Kang wrote: >> +#define CONFIG_SYS_TEXT_BASE 0x0 > > Zero is right? Maybe 0x33F8? IMHO "Zero" should be correct with activated ARM reloc. Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5 1/4] SMDK2410: activate ARM relocation feature
Minkyu Kang wrote: >> +/* additions for new relocation code, must be added to all boards */ >> +#undef CONFIG_SYS_ARM_WITHOUT_RELOC > > Please remove this define. > >> +#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 >> +#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_SDRAM_BASE + 0x1000 - \ >> + GENERATED_GBL_DATA_SIZE) You are talking about the "#undef", right? Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PING #2] Re: [PATCH V3] update VCMA9 port
Hello Anybody home? http://lists.denx.de/pipermail/u-boot/2011-January/085072.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PING #2] Re: [PATCH V3] update SMDK2410 port
Hello Anybody home? http://lists.denx.de/pipermail/u-boot/2011-January/085070.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PING #2] Re: [PATCH] add print_cpuinfo to s3c24x0
Hello Anybody home? http://lists.denx.de/pipermail/u-boot/2010-December/083032.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PING] Re: [PATCH V3] update VCMA9 port
Hello Any news? http://lists.denx.de/pipermail/u-boot/2011-January/085072.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PING] Re: [PATCH V3] update SMDK2410 port
Hello Any news? http://lists.denx.de/pipermail/u-boot/2011-January/085070.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PING] Re: [PATCH] add print_cpuinfo to s3c24x0
Hello Any news? http://lists.denx.de/pipermail/u-boot/2010-December/083032.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] update VCMA9 port
Wolfgang Denk schrieb: > Please move this line into your board config file, and drop the > config.mk file. Ok, will be done. >> - * Modified for the Samsung SMDK2410 by >> - * (C) Copyright 2002 >> + * Modified for MPL VCMA9 by >> * David Mueller, ELSOFT AG, > > I understand this file was created using copy & paste; why do you > think it is legal to remove the original copyright notice? The actual patch looks like this: - * Modified for the Samsung SMDK2410 by - * (C) Copyright 2002 + * Modified for MPL VCMA9 by * David Mueller, ELSOFT AG, + * (C) Copyright 2002, 2003, 2004, 2005 As you can see, i don't remove any copyright notice (just extending it) and i fix an obviously bad reference to SMDK2410. Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] fix s3c24x0 timer code
Hello
The attached patch fixes the s3c24x0 timer code to work with the ARM
relocation feature.
Dave
Signed-off-by: David Mueller
diff --git a/arch/arm/cpu/arm920t/s3c24x0/timer.c
b/arch/arm/cpu/arm920t/s3c24x0/timer.c
index 8cf9ff6..2903ba7 100644
--- a/arch/arm/cpu/arm920t/s3c24x0/timer.c
+++ b/arch/arm/cpu/arm920t/s3c24x0/timer.c
@@ -35,8 +35,7 @@
#include
#include
-int timer_load_val = 0;
-static ulong timer_clk;
+DECLARE_GLOBAL_DATA_PTR;
/* macro to read the 16 bit timer */
static inline ulong READ_TIMER(void)
@@ -46,9 +45,6 @@ static inline ulong READ_TIMER(void)
return readl(&timers->tcnto4) & 0x;
}
-static ulong timestamp;
-static ulong lastdec;
-
int timer_init(void)
{
struct s3c24x0_timers *timers = s3c24x0_get_base_timers();
@@ -57,27 +53,27 @@ int timer_init(void)
/* use PWM Timer 4 because it has no output */
/* prescaler for Timer 4 is 16 */
writel(0x0f00, &timers->tcfg0);
- if (timer_load_val == 0) {
+ if (gd->timer_load_val == 0) {
/*
* for 10 ms clock period @ PCLK with 4 bit divider = 1/2
* (default) and prescaler = 16. Should be 10390
* @33.25MHz and 15625 @ 50 MHz
*/
- timer_load_val = get_PCLK() / (2 * 16 * 100);
- timer_clk = get_PCLK() / (2 * 16);
+ gd->timer_load_val = get_PCLK() / (2 * 16 * 100);
+ gd->timer_clk = get_PCLK() / (2 * 16);
}
/* load value for 10 ms timeout */
- lastdec = timer_load_val;
- writel(timer_load_val, &timers->tcntb4);
+ gd->lastdec = gd->timer_load_val;
+ writel(gd->timer_load_val, &timers->tcntb4);
/* auto load, manual update of timer 4 */
tmr = (readl(&timers->tcon) & ~0x070) | 0x060;
writel(tmr, &timers->tcon);
/* auto load, start timer 4 */
tmr = (tmr & ~0x070) | 0x050;
writel(tmr, &timers->tcon);
- timestamp = 0;
+ gd->timestamp = 0;
- return (0);
+ return 0;
}
/*
@@ -96,7 +92,7 @@ ulong get_timer(ulong base)
void set_timer(ulong t)
{
- timestamp = t;
+ gd->timestamp = t;
}
void __udelay (unsigned long usec)
@@ -105,7 +101,7 @@ void __udelay (unsigned long usec)
ulong start = get_ticks();
tmo = usec / 1000;
- tmo *= (timer_load_val * 100);
+ tmo *= (gd->timer_load_val * 100);
tmo /= 1000;
while ((ulong) (get_ticks() - start) < tmo)
@@ -115,15 +111,15 @@ void __udelay (unsigned long usec)
void reset_timer_masked(void)
{
/* reset time */
- lastdec = READ_TIMER();
- timestamp = 0;
+ gd->lastdec = READ_TIMER();
+ gd->timestamp = 0;
}
ulong get_timer_masked(void)
{
ulong tmr = get_ticks();
- return tmr / (timer_clk / CONFIG_SYS_HZ);
+ return tmr / (gd->timer_clk / CONFIG_SYS_HZ);
}
void udelay_masked(unsigned long usec)
@@ -134,10 +130,10 @@ void udelay_masked(unsigned long usec)
if (usec >= 1000) {
tmo = usec / 1000;
- tmo *= (timer_load_val * 100);
+ tmo *= (gd->timer_load_val * 100);
tmo /= 1000;
} else {
- tmo = usec * (timer_load_val * 100);
+ tmo = usec * (gd->timer_load_val * 100);
tmo /= (1000 * 1000);
}
@@ -157,16 +153,16 @@ unsigned long long get_ticks(void)
{
ulong now = READ_TIMER();
- if (lastdec >= now) {
+ if (gd->lastdec >= now) {
/* normal mode */
- timestamp += lastdec - now;
+ gd->timestamp += gd->lastdec - now;
} else {
/* we have an overflow ... */
- timestamp += lastdec + timer_load_val - now;
+ gd->timestamp += gd->lastdec + gd->timer_load_val - now;
}
- lastdec = now;
+ gd->lastdec = now;
- return timestamp;
+ return gd->timestamp;
}
/*
@@ -178,7 +174,7 @@ ulong get_tbclk(void)
ulong tbclk;
#if defined(CONFIG_SMDK2400) || defined(CONFIG_TRAB)
- tbclk = timer_load_val * 100;
+ tbclk = gd->timer_load_val * 100;
#elif defined(CONFIG_SBC2410X) || \
defined(CONFIG_SMDK2410) || \
defined(CONFIG_S3C2440) || \
diff --git a/arch/arm/include/asm/global_data.h
b/arch/arm/include/asm/global_data.h
index ada3fbb..799943c 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -61,6 +61,13 @@ typedef struct global_data {
unsigned long tbu;
unsigned long long timer_reset_value;
#endif
+#ifdef CONFIG_S3C24X0
+ /* "static data" needed by s3c24x0 timer.c */
+ unsigned long timer_load_val;
+ unsigned long timer_clk;
+ unsigned long timestamp;
+ unsigned long lastdec;
+#endif
unsigned long relocaddr; /* Start address of U-Boot in RAM */
[U-Boot] [PATCH] fix s3c2410_nand timing default values
Hello The attached patch fixes wrong timing default values and adds the possibility to specify board specific timing value in the board config file. Dave Signed-off-by: David Mueller diff --git a/drivers/mtd/nand/s3c2410_nand.c b/drivers/mtd/nand/s3c2410_nand.c index f70daef..27351fb 100644 --- a/drivers/mtd/nand/s3c2410_nand.c +++ b/drivers/mtd/nand/s3c2410_nand.c @@ -133,9 +133,15 @@ int board_nand_init(struct nand_chip *nand) writel(readl(&clk_power->clkcon) | (1 << 4), &clk_power->clkcon); /* initialize hardware */ - twrph0 = 3; - twrph1 = 0; - tacls = 0; +#if defined(CONFIG_S3C24XX_CUSTOM_NAND_TIMING) + tacls = CONFIG_S3C24XX_TACLS; + twrph0 = CONFIG_S3C24XX_TWRPH0; + twrph1 = CONFIG_S3C24XX_TWRPH1; +#else + tacls = 4; + twrph0 = 8; + twrph1 = 8; +#endif cfg = S3C2410_NFCONF_EN; cfg |= S3C2410_NFCONF_TACLS(tacls - 1); ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] timer problem with new ARM relocation feature
Hello The timer implementation for s3c24xx based SoC (arch/arm/cpu/arm920t/s3c24x0/timer.c) uses several global variables. With the newly introduced ARM relocation feature, this timer code does no longer work as expected. What is the proposed fix/workaround for this? Is moving these variables to the "global data pointer area" an acceptable solution? Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] board/mpl: Remove mpl-specific memory test command
Peter Tyser schrieb: > On Wed, 2010-10-06 at 22:27 +0200, Wolfgang Denk wrote: >> I think you are right. If you have tiome, please submit patches to >> remove these, then we will see if anybody cares. > > Will do. I'm currently trying to bring the VCMA9 port in sync with the recently introduced "ARM relocation support" feature. Dave signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] VCMA9 build fails: ARM board references PPC4xx header
Wolfgang Denk schrieb: > The problem comes from board/mpl/common/memtst.c which contains an > unconditional "#include " which is obviously wrong > when the file gets compiled for an ARM board as VCMA9. > > Can you please provide a fix? The solution is to remove the include completely as it is not needed at all. Dave Signed-off-by: David Mueller diff --git a/board/mpl/common/memtst.c b/board/mpl/common/memtst.c index 9c08065..8810302 100644 --- a/board/mpl/common/memtst.c +++ b/board/mpl/common/memtst.c @@ -48,7 +48,6 @@ int testdram (void) #include #include -#include DECLARE_GLOBAL_DATA_PTR; ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
