Re: [U-Boot] [PATCH 12/25] dm: spi: Add documentation on how to convert over SPI drivers
Hi Simon,
On 1 September 2014 10:36, Simon Glass s...@chromium.org wrote:
Hi Jagan,
On 28 August 2014 04:32, Jagan Teki jagannadh.t...@gmail.com wrote:
On 15 July 2014 06:26, Simon Glass s...@chromium.org wrote:
This README is intended to help maintainers move their SPI drivers over to
driver model. It works through the required steps with an example.
Signed-off-by: Simon Glass s...@chromium.org
---
doc/driver-model/spi-howto.txt | 570
+
1 file changed, 570 insertions(+)
create mode 100644 doc/driver-model/spi-howto.txt
diff --git a/doc/driver-model/spi-howto.txt b/doc/driver-model/spi-howto.txt
new file mode 100644
index 000..bb64735
--- /dev/null
+++ b/doc/driver-model/spi-howto.txt
@@ -0,0 +1,570 @@
+How to port a SPI driver to driver model
+
+
+Here is a rough step-by-step guide. It is based around converting the
+exynos SPI driver to driver model (DM) and the example code is based
+around U-Boot v2014.04 (commit dda0dbf).
+
+It is quite long since it includes actual code examples.
+
+Before driver model, SPI drivers have their own private structure which
+contains 'struct spi_slave'. With driver model, 'struct spi_slave' still
+exists, but now it is 'per-child data' for the SPI bus. Each child of the
+SPI bus is a SPI slave. The information that was stored in the
+driver-specific slave structure can now be put in private data for the
+SPI bus.
Do you think spi_slave still require, I guess It's needed as some slave
members
to cs, bus are used to control the driver.
The CS and bus are purely command-line conveniences with DM. When it
gets down to the driver the bus is determined by the SPI peripheral it
is connected to, and the CS is the control that it adjusts to enable
the chip select. The numbering of buses and chip selects is not
relevant down at the driver level anymore.
Yes - I understand but let me explain my comments.
u-boot sf probe bus:cs speed mode
Unlike other buses/controllers on u-boot we're dynamically probing the
slave on bus
using bus and cs for example, we have a zynq_spi handling spi0, spi1
(bus's) and each
one has 3 chip-selects. So
u-boot sf probe 1:1
for probing bus1 (spi1) and cs 1
u-boot sf probe 0:1
for probing bus0 (spi0) and cs 1
The respective reg base (based on bus) and register chip-select (based
on cs) zynq_spi.c
will handle these in driver it self.
speed and mode settings, I'm fine with dm, where it will configure using
int spi_get_bus_and_cs(int busnum, int cs, int speed, int mode,
const char *drv_name, const char *dev_name,
struct udevice **devp, struct spi_slave **slavep)
{
.
ret = spi_set_speed_mode(bus, speed, mode);
..
}
But how can spi-uclass.c will identifies how many bus's along with cs lines does
specified controller driver support.
This what usually we're doing in driver as
int spi_cs_is_valid(unsigned int bus, unsigned int cs)
{
/* 2 bus with 3 chipselect */
return bus 2 cs 3;
}
Please let me know if you have any questions, this is what usually
doing most of drivers.
But any specific reason for removing spi_slave from exynos_spi.c?
The driver has its own private data, there is no longer a need to
store the SPI subsystem's data there also. That is what the per-child
data is for.
+
+For example, struct tegra_spi_slave looks like this:
+
+struct tegra_spi_slave {
+ struct spi_slave slave;
+ struct tegra_spi_ctrl *ctrl;
+};
+
+In this case 'slave' will be in per-child data, and 'ctrl' will be in the
+SPI bus' private data.
+
+
+0. How long does this take?
+
+Around 2.5 hours, including some allowance for figuring out the driver
+model bits.
+
+
+1. Enable driver mode for SPI and SPI flash
+
+Add these to your board config:
+
+#define CONFIG_DM_SPI
+#define CONFIG_DM_SPI_FLASH
+
+
+2. Add the skeleton
+
+Put this code at the bottom of your existing driver file:
+
+struct spi_slave *spi_setup_slave(unsigned int busnum, unsigned int cs,
+ unsigned int max_hz, unsigned int mode)
+{
+ return NULL;
+}
+
+struct spi_slave *spi_setup_slave_fdt(const void *blob, int slave_node,
+ int spi_node)
+{
+ return NULL;
+}
+
+static int exynos_spi_ofdata_to_platdata(struct udevice *dev)
+{
+ return -ENODEV;
+}
+
+static int exynos_spi_probe(struct udevice *dev)
+{
+ return -ENODEV;
+}
+
+static int exynos_spi_remove(struct udevice *dev)
+{
+ return -ENODEV;
+}
+
+static int exynos_spi_claim_bus(struct udevice *dev)
+{
+
+ return -ENODEV;
+}
+
+static int exynos_spi_release_bus(struct udevice *dev)
+{
+
+ return -ENODEV;
+}
+
+static int exynos_spi_xfer(struct udevice *dev, unsigned int bitlen,
+ const void *dout, void *din, unsigned long
flags)
+{
Re: [U-Boot] [PATCH 1/2] dfu: Provide means to find difference between dfu-util -e and -R
Hi Stephen, On 08/22/2014 08:08 AM, Lukasz Majewski wrote: This commit provides distinction between DFU device detach and reset. The -R behavior is preserved with proper handling of the dfu-util's -e switch, which detach the DFU device. By running dfu-util -e; one can force device to finish the execution of dfu command on target and execute some other scripted commands. Moreover, some naming has been changed - the dfu_reset() method now is known as dfu_detach(). New name better reflects the purpose of the code. It was also necessary to increase the number of usb_gadget_handle_interrupts() calls since we also must wait for detection of the USB reset event. Example usage: 1. -e (detach) switch dfu-util -a0 -D file1.bin;dfu-util -a3 -D uImage;dfu-util -e access to u-boot prompt. 2. -R (reset) switch dfu-util -a0 -D file1.bin;dfu-util -R -a3 -D uImage target board reset Tested-by: Stephen Warren swar...@nvidia.com Applied to u-boot-dfu. Thanks! -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: ci_udc: implement dfu_usb_get_reset
Hi Stephen,
From: Stephen Warren swar...@nvidia.com
This allows the USB code to determine whether a USB bus reset was
issued, which in turn allows the code to differentiate between a
detach (return to shell prompt) and a board reset/reboot request.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
Note that this patch relies on the following unapplied patch:
[PATCH 1/2] dfu: Provide means to find difference between dfu-util -e
and -R ---
drivers/usb/gadget/ci_udc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/usb/gadget/ci_udc.c b/drivers/usb/gadget/ci_udc.c
index 4cd19c3afd22..2572b346ebfa 100644
--- a/drivers/usb/gadget/ci_udc.c
+++ b/drivers/usb/gadget/ci_udc.c
@@ -919,3 +919,10 @@ int usb_gadget_unregister_driver(struct
usb_gadget_driver *driver)
return 0;
}
+
+bool dfu_usb_get_reset(void)
+{
+ struct ci_udc *udc = (struct ci_udc *)controller.ctrl-hcor;
+
+ return !!(readl(udc-usbsts) STS_URI);
+}
Applied to u-boot-dfu.
Thanks!
--
Best regards,
Lukasz Majewski
Samsung RD Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [patch 2/2] spl: Lightweight UBI and UBI fastmap support
On Fri, 8 Aug 2014, Tom Rini wrote:
On Sat, Jul 05, 2014 at 09:48:13AM -, Thomas Gleixner wrote:
Booting a payload out of NAND FLASH from the SPL is a crux today, as
it requires hard partioned FLASH. Not a brilliant idea with the
reliability of todays NAND FLASH chips.
[snip]
+ CONFIG_SPL_UBI
+ Support for a lightweight UBI (fastmap) scanner and
+ loader
... for the related options, please see doc/README.ubispl
Ok.
+Usage notes:
+
+In the board config file define for example:
+
+#define CONFIG_SPL_UBI
+#define CONFIG_SPL_UBI_MAX_VOL_LEBS256
+#define CONFIG_SPL_UBI_MAX_PEB_SIZE(256*1024)
+#define CONFIG_SPL_UBI_MAX_PEBS4096
+#define CONFIG_SPL_UBI_VOL_IDS 8
+
+The size requirement is roughly as follows:
+
+2k for the basic data structure
+ + CONFIG_SPL_UBI_VOL_IDS * CONFIG_SPL_UBI_MAX_VOL_LEBS * 8
+ + CONFIG_SPL_UBI_MAX_PEBS * 64
+ + CONFIG_SPL_UBI_MAX_PEB_SIZE * UBI_FM_MAX_BLOCKS
+
+The last one is big, but I really don't care in that stage. Real world
+implementations only use the first couple of blocks, but the code
+handles up to UBI_FM_MAX_BLOCKS.
+
+Given the above configuration example the requirement is about 5M
+which is usually not a problem to reserve in the RAM along with the
+other areas like the kernel/dts load address.
+
+So something like this will do the trick:
+
+#define SPL_FINFO_ADDR 0x8080
+#define SPL_DTB_LOAD_ADDR 0x8180
+#define SPL_KERNEL_LOAD_ADDR 0x8200
+
+In the board file, implement the following:
+
+static struct ubispl_load myvolumes[] = {
+ {
+ .name = Kernel,
+ .vol_id = 0,
+ .load_addr = (void *)SPL_KERNEL_LOAD_ADDR,
+ },
+ {
+ .name = DTB,
+ .vol_id = 1,
+ .load_addr = (void *)SPL_DTB_LOAD_ADDR,
+ }
+};
+
+int spl_start_uboot(void)
+{
+ struct ubispl_info info;
+
+ info.ubi = (struct ubi_scan_info *) SPL_FINFO_ADDR;
OK, so here's some problems with the example. First, we can / should
(and OK, after you posted the patch this went in) moved stack into DDR
in some cases, so in the case of wanting to use this, DDR would have to
be up in time for that to be a valid option, so we shoudl just do that.
Well, the scan data structure is rather large, so you don't want to
have it on stack.
Second, we have CONFIG_SYS_SPL_ARGS_ADDR for where the DT would go and
since Falcon supports uImages only (And if/when zImage is added, we'll
have to sort something out generically) we don't need to hard-code in a
load address for the kernel.
Well, the way how this works is a bit different from the standard
u-boot/uimage way.
The ubispl load code is oblivious of the payload. It just copies the
data from the volume to a RAM address and checks the integrity of the
payload with the UBI volume CRC.
I did this on purpose to avoid payload specific handling in the
transfer code.
If we want to have uimage support there we'd need to tell that to the
loader, e.g. by having a flag field in the volumes decriptor table.
That means, if the uImage flag is set we'd need to treat the first
FLASH page of the payload differently:
1) copy it to a separate buffer
2) decode the uImage header and extract the load address
3) copy the kernel part which is in the first flash page from
the separate buffer to the load address
4) Continue with the rest
That's doable, but I'm not sure if its worth the trouble. In my
experience the load address almost never changes, so there is nothing
wrong to hardcode it in the SPL.
+ /*
+* Bad block, unrecoverable ECC error, skip the block
+*/
+ if (res) {
+ ubi_dbg(Skipping bad or unreadable block %d, pnum);
Here and everywhere else, we have debug() please use that.
I kept the original ubi_dbg() macros in the code which I lifted from
mainline and wrapped them in the header to keep the changes minimal.
+#ifdef CHECKME
+ /*
+* If fastmap is leaking PEBs (must not happen), raise a
+* fat warning and fall back to scanning mode.
+* We do this here because in ubi_wl_init() it's too late
+* and we cannot fall back to scanning.
+*/
+ if (WARN_ON(count_fastmap_pebs(ai) != ubi-peb_count -
+ ai-bad_peb_count - fm-used_blocks))
+ goto fail_bad;
+#endif
Use DEBUG here?
That's a paranoia check in the UBI mainline code, which I can't keep
as I have to do the accounting a bit different. I kept this as a
reminder that we might revisit this if we feel paranoid enough, but we
can surely replace it with a proper comment:
/*
* The upstream code has a paranoia accounting check for leaked
* PEBs. We cannot use the upstream code as we do not account for
* all volumes. With enforced
Re: [U-Boot] [PATCH v2] sunxi: Correct typo CONFIG_FTDFILE = CONFIG_FDTFILE
Hi, On 08/31/2014 02:13 PM, Ian Campbell wrote: Patch is the result of: sed -i -e 's/FTDFILE/FDTFILE/g' board/sunxi/Kconfig configs/* include/configs/sunxi-common.h sed -i -e 's/ftdfile/fdtfile/g' board/sunxi/Kconfig Spotted-by: Vagrant Cascadian vagr...@debian.org Signed-off-by: Ian Campbell i...@hellion.org.uk --- v2: Kconfig help (lowercase) too. Looks good: Acked-by: Hans de Goede hdego...@redhat.com Regards, Hans --- board/sunxi/Kconfig | 4 ++-- configs/A10-OLinuXino-Lime_defconfig | 2 +- configs/A10s-OLinuXino-M_defconfig| 2 +- configs/A13-OLinuXinoM_defconfig | 2 +- configs/A13-OLinuXino_defconfig | 2 +- configs/A20-OLinuXino_MICRO_defconfig | 2 +- configs/Auxtek-T004_defconfig | 2 +- configs/Bananapi_defconfig| 2 +- configs/Cubieboard2_FEL_defconfig | 2 +- configs/Cubieboard2_defconfig | 2 +- configs/Cubieboard_defconfig | 2 +- configs/Cubietruck_FEL_defconfig | 2 +- configs/Cubietruck_defconfig | 2 +- configs/Linksprite_pcDuino3_defconfig | 2 +- configs/Mele_A1000G_defconfig | 2 +- configs/Mele_A1000_defconfig | 2 +- configs/Mini-X-1Gb_defconfig | 2 +- configs/Mini-X_defconfig | 2 +- configs/ba10_tv_box_defconfig | 2 +- configs/i12-tvbox_defconfig | 2 +- configs/qt840a_defconfig | 2 +- configs/r7-tv-dongle_defconfig| 2 +- include/configs/sunxi-common.h| 2 +- 23 files changed, 24 insertions(+), 24 deletions(-) diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig index c61c650..7bdf958 100644 --- a/board/sunxi/Kconfig +++ b/board/sunxi/Kconfig @@ -36,7 +36,7 @@ config SYS_SOC string default sunxi -config FTDFILE - string Default ftdfile env setting for this board +config FDTFILE + string Default fdtfile env setting for this board endif diff --git a/configs/A10-OLinuXino-Lime_defconfig b/configs/A10-OLinuXino-Lime_defconfig index b93ae7d..37dbe9c 100644 --- a/configs/A10-OLinuXino-Lime_defconfig +++ b/configs/A10-OLinuXino-Lime_defconfig @@ -1,5 +1,5 @@ CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS=A10_OLINUXINO_L,SPL,AXP209_POWER,SUNXI_EMAC,AHCI,SATAPWR=SUNXI_GPC(3),USB_EHCI -CONFIG_FTDFILE=sun4i-a10-olinuxino-lime.dtb +CONFIG_FDTFILE=sun4i-a10-olinuxino-lime.dtb +S:CONFIG_ARM=y +S:CONFIG_TARGET_SUN4I=y diff --git a/configs/A10s-OLinuXino-M_defconfig b/configs/A10s-OLinuXino-M_defconfig index f206970..8475b16 100644 --- a/configs/A10s-OLinuXino-M_defconfig +++ b/configs/A10s-OLinuXino-M_defconfig @@ -1,5 +1,5 @@ CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS=A10S_OLINUXINO_M,SPL,AXP152_POWER,SUNXI_EMAC,USB_EHCI,SUNXI_USB_VBUS0_GPIO=SUNXI_GPB(10) -CONFIG_FTDFILE=sun5i-a10s-olinuxino-micro.dtb +CONFIG_FDTFILE=sun5i-a10s-olinuxino-micro.dtb +S:CONFIG_ARM=y +S:CONFIG_TARGET_SUN5I=y diff --git a/configs/A13-OLinuXinoM_defconfig b/configs/A13-OLinuXinoM_defconfig index 8529dbe..bd135cd 100644 --- a/configs/A13-OLinuXinoM_defconfig +++ b/configs/A13-OLinuXinoM_defconfig @@ -1,5 +1,5 @@ CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS=A13_OLINUXINOM,SPL,CONS_INDEX=2,USB_EHCI,SUNXI_USB_VBUS0_GPIO=SUNXI_GPG(11) -CONFIG_FTDFILE=sun5i-a13-olinuxino-micro.dtb +CONFIG_FDTFILE=sun5i-a13-olinuxino-micro.dtb +S:CONFIG_ARM=y +S:CONFIG_TARGET_SUN5I=y diff --git a/configs/A13-OLinuXino_defconfig b/configs/A13-OLinuXino_defconfig index c3a12cc..eb3a6c0 100644 --- a/configs/A13-OLinuXino_defconfig +++ b/configs/A13-OLinuXino_defconfig @@ -1,5 +1,5 @@ CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS=A13_OLINUXINO,SPL,CONS_INDEX=2,AXP209_POWER,USB_EHCI,SUNXI_USB_VBUS0_GPIO=SUNXI_GPG(11) -CONFIG_FTDFILE=sun5i-a13-olinuxino.dtb +CONFIG_FDTFILE=sun5i-a13-olinuxino.dtb +S:CONFIG_ARM=y +S:CONFIG_TARGET_SUN5I=y diff --git a/configs/A20-OLinuXino_MICRO_defconfig b/configs/A20-OLinuXino_MICRO_defconfig index c91319d..c9170fa 100644 --- a/configs/A20-OLinuXino_MICRO_defconfig +++ b/configs/A20-OLinuXino_MICRO_defconfig @@ -1,5 +1,5 @@ CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS=A20_OLINUXINO_M,SPL,AXP209_POWER,SUNXI_GMAC,AHCI,SATAPWR=SUNXI_GPB(8),USB_EHCI -CONFIG_FTDFILE=sun7i-a20-olinuxino-micro.dtb +CONFIG_FDTFILE=sun7i-a20-olinuxino-micro.dtb +S:CONFIG_ARM=y +S:CONFIG_TARGET_SUN7I=y diff --git a/configs/Auxtek-T004_defconfig b/configs/Auxtek-T004_defconfig index 193019c..0282c08 100644 --- a/configs/Auxtek-T004_defconfig +++ b/configs/Auxtek-T004_defconfig @@ -1,5 +1,5 @@ CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS=AUXTEK_T004,SPL,AXP152_POWER,USB_EHCI,SUNXI_USB_VBUS0_GPIO=SUNXI_GPG(13) -CONFIG_FTDFILE=sun5i-a10s-auxtek-t004.dtb +CONFIG_FDTFILE=sun5i-a10s-auxtek-t004.dtb +S:CONFIG_ARM=y +S:CONFIG_TARGET_SUN5I=y diff --git a/configs/Bananapi_defconfig b/configs/Bananapi_defconfig index dc68469..b75215c 100644 --- a/configs/Bananapi_defconfig +++ b/configs/Bananapi_defconfig @@ -1,5
[U-Boot] [PATCH 0/2] SPI: mxc_spi: slave initialisation fixes
From: Markus Niebel markus.nie...@tq-group.com current implementation of the mxc_spi host driver gives issues, if using more than one slave on the same bus. These patches try to improve this use case. They were tested on a TQMa6S (i.MC6S) with a custom mainboard using two slave devices in SPI MODE 0 and 3, on of the devices uses gpio based chip select the other hardware base chip select. Markus Niebel (2): SPI: mxc_spi: remove second reset from ECSPI config handler SPI: mxc_spi: delay initialisation until claim bus drivers/spi/mxc_spi.c | 40 +--- 1 file changed, 21 insertions(+), 19 deletions(-) -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] SPI: mxc_spi: delay initialisation until claim bus
From: Markus Niebel markus.nie...@tq-group.com
it is not correct to init for a specific slave in spi_setup_slave.
instead buffer the values and delay init until spi_claim_bus.
Signed-off-by: Markus Niebel markus.nie...@tq-group.com
---
drivers/spi/mxc_spi.c | 37 +
1 file changed, 21 insertions(+), 16 deletions(-)
diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c
index 6a05d15..c741738 100644
--- a/drivers/spi/mxc_spi.c
+++ b/drivers/spi/mxc_spi.c
@@ -43,6 +43,8 @@ struct mxc_spi_slave {
#endif
int gpio;
int ss_pol;
+ unsigned intmax_hz;
+ unsigned intmode;
};
static inline struct mxc_spi_slave *to_mxc_spi_slave(struct spi_slave *slave)
@@ -77,12 +79,13 @@ u32 get_cspi_div(u32 div)
}
#ifdef MXC_CSPI
-static s32 spi_cfg_mxc(struct mxc_spi_slave *mxcs, unsigned int cs,
- unsigned int max_hz, unsigned int mode)
+static s32 spi_cfg_mxc(struct mxc_spi_slave *mxcs, unsigned int cs)
{
unsigned int ctrl_reg;
u32 clk_src;
u32 div;
+ unsigned int max_hz = mxcs-max_hz;
+ unsigned int mode = mxcs-mode;
clk_src = mxc_get_clock(MXC_CSPI_CLK);
@@ -114,19 +117,15 @@ static s32 spi_cfg_mxc(struct mxc_spi_slave *mxcs,
unsigned int cs,
#endif
#ifdef MXC_ECSPI
-static s32 spi_cfg_mxc(struct mxc_spi_slave *mxcs, unsigned int cs,
- unsigned int max_hz, unsigned int mode)
+static s32 spi_cfg_mxc(struct mxc_spi_slave *mxcs, unsigned int cs)
{
u32 clk_src = mxc_get_clock(MXC_CSPI_CLK);
s32 reg_ctrl, reg_config;
u32 ss_pol = 0, sclkpol = 0, sclkpha = 0, sclkctl = 0;
u32 pre_div = 0, post_div = 0;
struct cspi_regs *regs = (struct cspi_regs *)mxcs-base;
-
- if (max_hz == 0) {
- printf(Error: desired clock is 0\n);
- return -1;
- }
+ unsigned int max_hz = mxcs-max_hz;
+ unsigned int mode = mxcs-mode;
/*
* Reset SPI and set all CSs to master mode, if toggling
@@ -404,6 +403,11 @@ struct spi_slave *spi_setup_slave(unsigned int bus,
unsigned int cs,
if (bus = ARRAY_SIZE(spi_bases))
return NULL;
+ if (max_hz == 0) {
+ printf(Error: desired clock is 0\n);
+ return NULL;
+ }
+
mxcs = spi_alloc_slave(struct mxc_spi_slave, bus, cs);
if (!mxcs) {
puts(mxc_spi: SPI Slave not allocated !\n);
@@ -421,13 +425,9 @@ struct spi_slave *spi_setup_slave(unsigned int bus,
unsigned int cs,
cs = ret;
mxcs-base = spi_bases[bus];
+ mxcs-max_hz = max_hz;
+ mxcs-mode = mode;
- ret = spi_cfg_mxc(mxcs, cs, max_hz, mode);
- if (ret) {
- printf(mxc_spi: cannot setup SPI controller\n);
- free(mxcs);
- return NULL;
- }
return mxcs-slave;
}
@@ -440,12 +440,17 @@ void spi_free_slave(struct spi_slave *slave)
int spi_claim_bus(struct spi_slave *slave)
{
+ int ret;
struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave);
struct cspi_regs *regs = (struct cspi_regs *)mxcs-base;
reg_write(regs-rxdata, 1);
udelay(1);
- reg_write(regs-ctrl, mxcs-ctrl_reg);
+ ret = spi_cfg_mxc(mxcs, slave-cs);
+ if (ret) {
+ printf(mxc_spi: cannot setup SPI controller\n);
+ return ret;
+ }
reg_write(regs-period, MXC_CSPIPERIOD_32KHZ);
reg_write(regs-intr, 0);
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] SPI: mxc_spi: remove second reset from ECSPI config handler
From: Markus Niebel markus.nie...@tq-group.com the second reset prevents other registers to be written. This will prevent to have the correct signal levels for SCLK before writing to the config reg in spi_xchg_single. Tested with GPIO based chipselect and SPI_MODE_3 on i.MX6S Signed-off-by: Markus Niebel markus.nie...@tq-group.com --- drivers/spi/mxc_spi.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c index 2d5f385..6a05d15 100644 --- a/drivers/spi/mxc_spi.c +++ b/drivers/spi/mxc_spi.c @@ -163,9 +163,6 @@ static s32 spi_cfg_mxc(struct mxc_spi_slave *mxcs, unsigned int cs, reg_ctrl = (reg_ctrl ~MXC_CSPICTRL_POSTDIV(0x0F)) | MXC_CSPICTRL_POSTDIV(post_div); - /* We need to disable SPI before changing registers */ - reg_ctrl = ~MXC_CSPICTRL_EN; - if (mode SPI_CS_HIGH) ss_pol = 1; -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sf: Add support for flag status register on Micron chips
-Original Message-
From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
Sent: Friday, August 29, 2014 5:43 PM
To: Hou Zhiqiang-B48286
Cc: u-boot@lists.denx.de; Hu Mingkai-B21284; Sun York-R58495
Subject: Re: [U-Boot] [PATCH] sf: Add support for flag status register
on Micron chips
On 29 August 2014 12:24, Hou Zhiqiang b48...@freescale.com wrote:
Add clear flag status register operation that some Micron SPI flash
chips required after reading the flag status register to check some
operations completion.
Signed-off-by: Hou Zhiqiang b48...@freescale.com
---
Based on git://git.denx.de/u-boot.git.
It also can be applied to git://www.denx.de/git/u-boot-mpc85xx.git.
Tested on board T2080QDS and T2080RDB.
Flag status register support is been added for stmicro flashes which
are = 512MB sizes.
#ifdef CONFIG_SPI_FLASH_STMICRO
if (params-flags E_FSR)
flash-poll_cmd = CMD_FLAG_STATUS; #endif
Please check the condition on current tree bases, and let me know for
any questions.
First, this patch is generated base on the updated git://git.denx.de/u-boot.git.
Yes, the read operation of flag status register has been added, but I find the
erase operation failed for SPI flash N25Q512A due to missing to clear the flag
status register.
drivers/mtd/spi/sf_internal.h | 9 +
drivers/mtd/spi/sf_ops.c | 36 ---
-
2 files changed, 37 insertions(+), 8 deletions(-)
diff --git a/drivers/mtd/spi/sf_internal.h
b/drivers/mtd/spi/sf_internal.h index 6bcd522..162dd87 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -36,6 +36,7 @@
#define CMD_WRITE_ENABLE 0x06
#define CMD_READ_CONFIG0x35
#define CMD_FLAG_STATUS0x70
+#define CMD_CLEAR_FLAG_STATUS 0x50
/* Read commands */
#define CMD_READ_ARRAY_SLOW0x03
@@ -59,6 +60,8 @@
#define STATUS_QEB_WINSPAN (1 1)
#define STATUS_QEB_MXIC(1 6)
#define STATUS_PEC (1 7)
+#define STATUS_PROT(1 1)
+#define STATUS_ERASE (1 5)
/* Flash timeout values */
#define SPI_FLASH_PROG_TIMEOUT (2 * CONFIG_SYS_HZ)
@@ -120,6 +123,12 @@ static inline int
spi_flash_cmd_write_disable(struct spi_flash *flash)
return spi_flash_cmd(flash-spi, CMD_WRITE_DISABLE, NULL,
0); }
+/* Clear flag status register */
+static inline int spi_flash_cmd_clear_flag_status(struct spi_flash
+*flash) {
+ return spi_flash_cmd(flash-spi, CMD_CLEAR_FLAG_STATUS,
+NULL, 0); }
+
/*
* Send the read status command to the device and wait for the wip
* (write-in-progress) bit to clear itself.
diff --git a/drivers/mtd/spi/sf_ops.c b/drivers/mtd/spi/sf_ops.c
index 85cf22d..08ff1df 100644
--- a/drivers/mtd/spi/sf_ops.c
+++ b/drivers/mtd/spi/sf_ops.c
@@ -160,6 +160,7 @@ int spi_flash_cmd_wait_ready(struct spi_flash
*flash, unsigned long timeout)
unsigned long timebase;
unsigned long flags = SPI_XFER_BEGIN;
int ret;
+ int out_of_time = 1;
u8 status;
u8 check_status = 0x0;
u8 poll_bit = STATUS_WIP;
@@ -186,22 +187,41 @@ int spi_flash_cmd_wait_ready(struct spi_flash
*flash, unsigned long timeout)
WATCHDOG_RESET();
ret = spi_xfer(spi, 8, NULL, status, 0);
- if (ret)
+ if (ret) {
+ spi_xfer(spi, 0, NULL, NULL, SPI_XFER_END);
return -1;
+ }
- if ((status poll_bit) == check_status)
+ if ((status poll_bit) == check_status) {
+ out_of_time = 0;
break;
+ }
} while (get_timer(timebase) timeout);
spi_xfer(spi, 0, NULL, NULL, SPI_XFER_END);
- if ((status poll_bit) == check_status)
- return 0;
+ if (out_of_time) {
+ /* Timed out */
+ debug(SF: time out!\n);
+ ret = -1;
+ }
+#ifdef CONFIG_SPI_FLASH_STMICRO
+ else if (cmd == CMD_FLAG_STATUS) {
+ if (!(status (STATUS_PROT | STATUS_ERASE))) {
+ ret = 0;
+ } else {
+ debug(SF: flag status error);
+ ret = -1;
+ }
- /* Timed out */
- debug(SF: time out!\n);
- return -1;
+ if (spi_flash_cmd_clear_flag_status(flash) 0) {
+ debug(SF: clear flag status failed\n);
+ ret = -1;
+ }
+ }
+#endif
+ return ret;
}
int spi_flash_write_common(struct spi_flash *flash, const u8 *cmd,
@@
-234,7 +254,7
[U-Boot] [PATCH v2 1/3] SPDX: Add ISC SPDX-License-Identifier
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Wolfgang Denk w...@denx.de --- Changes in v2: - Newly added Licenses/README | 1 + Licenses/isc.txt | 17 + 2 files changed, 18 insertions(+) create mode 100644 Licenses/isc.txt diff --git a/Licenses/README b/Licenses/README index c6ff277..fe6dadc 100644 --- a/Licenses/README +++ b/Licenses/README @@ -66,3 +66,4 @@ BSD 2-Clause License BSD-2-Clause Y bsd-2-clause.txthttp://spdx.org/license BSD 3-clause New or Revised LicenseBSD-3-ClauseY bsd-3-clause.txt http://spdx.org/licenses/BSD-3-Clause#licenseText IBM PIBS (PowerPC Initialization and IBM-pibs ibm-pibs.txt Boot Software) license +ISC LicenseISC Y isc.txt https://spdx.org/licenses/ISC diff --git a/Licenses/isc.txt b/Licenses/isc.txt new file mode 100644 index 000..4b7c2ba --- /dev/null +++ b/Licenses/isc.txt @@ -0,0 +1,17 @@ +ISC License: +Copyright (c) 2004-2010 by Internet Systems Consortium, Inc. (ISC) +Copyright (c) 1995-2003 by Internet Software Consortium + +Permission to use, copy, modify, and/or distribute this software +for any purpose with or without fee is hereby granted, +provided that the above copyright notice and this permission notice +appear in all copies. + +THE SOFTWARE IS PROVIDED AS IS AND ISC DISCLAIMS ALL WARRANTIES +WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF +MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE +FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR +ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, +WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, +ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF +THIS SOFTWARE. -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/3] tools/genboardscfg.py: improve performance more with Kconfiglib
The idea of using Kconfiglib was given by Tom Rini.
It allows us to scan lots of defconfigs very quickly.
This commit also uses multiprocessing for further acceleration.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
Suggested-by: Tom Rini tr...@ti.com
---
Changes in v2:
- Do not install Kconfiglib
- Comments fixes, cleanups based on Simon's review.
tools/genboardscfg.py | 698 +++---
1 file changed, 258 insertions(+), 440 deletions(-)
diff --git a/tools/genboardscfg.py b/tools/genboardscfg.py
index e6870f5..654100b 100755
--- a/tools/genboardscfg.py
+++ b/tools/genboardscfg.py
@@ -6,34 +6,33 @@
#
-Converter from Kconfig and MAINTAINERS to boards.cfg
+Converter from Kconfig and MAINTAINERS to a board database.
-Run 'tools/genboardscfg.py' to create boards.cfg file.
+Run 'tools/genboardscfg.py' to create a board database.
Run 'tools/genboardscfg.py -h' for available options.
-This script only works on python 2.6 or later, but not python 3.x.
+Python 2.6 or later, but not Python 3.x is necessary to run this script.
import errno
import fnmatch
import glob
+import multiprocessing
import optparse
import os
-import re
-import shutil
import subprocess
import sys
import tempfile
import time
-BOARD_FILE = 'boards.cfg'
-CONFIG_DIR = 'configs'
-REFORMAT_CMD = [os.path.join('tools', 'reformat.py'),
-'-i', '-d', '-', '-s', '8']
-SHOW_GNU_MAKE = 'scripts/show-gnu-make'
-SLEEP_TIME=0.003
+sys.path.append(os.path.join(os.path.dirname(__file__), 'buildman'))
+import kconfiglib
+### constant variables ###
+OUTPUT_FILE = 'boards.cfg'
+CONFIG_DIR = 'configs'
+SLEEP_TIME = 0.03
COMMENT_BLOCK = '''#
# List of boards
# Automatically generated by %s: don't edit
@@ -43,35 +42,14 @@ COMMENT_BLOCK = '''#
''' % __file__
### helper functions ###
-def get_terminal_columns():
-Get the width of the terminal.
-
-Returns:
- The width of the terminal, or zero if the stdout is not
- associated with tty.
-
+def try_remove(f):
+Remove a file ignoring 'No such file or directory' error.
try:
-return shutil.get_terminal_size().columns # Python 3.3~
-except AttributeError:
-import fcntl
-import termios
-import struct
-arg = struct.pack('', 0, 0, 0, 0)
-try:
-ret = fcntl.ioctl(sys.stdout.fileno(), termios.TIOCGWINSZ, arg)
-except IOError as exception:
-# If 'Inappropriate ioctl for device' error occurs,
-# stdout is probably redirected. Return 0.
-return 0
-return struct.unpack('', ret)[1]
-
-def get_devnull():
-Get the file object of '/dev/null' device.
-try:
-devnull = subprocess.DEVNULL # py3k
-except AttributeError:
-devnull = open(os.devnull, 'wb')
-return devnull
+os.remove(f)
+except OSError as exception:
+# Ignore 'No such file or directory' error
+if exception.errno != errno.ENOENT:
+raise
def check_top_directory():
Exit if we are not at the top of source directory.
@@ -79,23 +57,15 @@ def check_top_directory():
if not os.path.exists(f):
sys.exit('Please run at the top of source directory.')
-def get_make_cmd():
-Get the command name of GNU Make.
-process = subprocess.Popen([SHOW_GNU_MAKE], stdout=subprocess.PIPE)
-ret = process.communicate()
-if process.returncode:
-sys.exit('GNU Make not found')
-return ret[0].rstrip()
-
-def output_is_new():
-Check if the boards.cfg file is up to date.
+def output_is_new(output):
+Check if the output file is up to date.
Returns:
- True if the boards.cfg file exists and is newer than any of
+ True if the given output file exists and is newer than any of
*_defconfig, MAINTAINERS and Kconfig*. False otherwise.
try:
-ctime = os.path.getctime(BOARD_FILE)
+ctime = os.path.getctime(output)
except OSError as exception:
if exception.errno == errno.ENOENT:
# return False on 'No such file or directory' error
@@ -121,9 +91,9 @@ def output_is_new():
if ctime os.path.getctime(filepath):
return False
-# Detect a board that has been removed since the current boards.cfg
+# Detect a board that has been removed since the current board database
# was generated
-with open(BOARD_FILE) as f:
+with open(output) as f:
for line in f:
if line[0] == '#' or line == '\n':
continue
@@ -134,6 +104,172 @@ def output_is_new():
return True
### classes ###
+class KconfigScanner:
+
+Kconfig scanner.
+
+### constant variable only used in this class ###
+_SYMBOL_TABLE = {
+'arch' : 'SYS_ARCH',
+'cpu' : 'SYS_CPU',
+'soc' : 'SYS_SOC',
+'vendor' : 'SYS_VENDOR',
+'board' : 'SYS_BOARD',
+'config' :
[U-Boot] [PATCH v2 0/3] Add ISC SPDX, import Kconfiglib and improve genboardscfg.py
Masahiro Yamada (3): SPDX: Add ISC SPDX-License-Identifier tools: Import Kconfiglib tools/genboardscfg.py: improve performance more with Kconfiglib Licenses/README |1 + Licenses/isc.txt | 17 + tools/buildman/kconfiglib.py | 3799 ++ tools/genboardscfg.py| 698 +++- 4 files changed, 4075 insertions(+), 440 deletions(-) create mode 100644 Licenses/isc.txt create mode 100644 tools/buildman/kconfiglib.py -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] kconfig: zynq: Add ZYBO board
From: Peter Crosthwaite crosthwaitepe...@gmail.com Add a defconfig and Kconfigury for the Digilent ZYBO board. Signed-off-by: Peter Crosthwaite crosthwaite.pe...@gmail.com Signed-off-by: Michal Simek michal.si...@xilinx.com Acked-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com --- Changes in v2: - Rebase on the latest u-boot master branch (Kconfig changes) arch/arm/cpu/armv7/zynq/Kconfig | 4 configs/zynq_zybo_defconfig | 4 2 files changed, 8 insertions(+) create mode 100644 configs/zynq_zybo_defconfig diff --git a/arch/arm/cpu/armv7/zynq/Kconfig b/arch/arm/cpu/armv7/zynq/Kconfig index 6b88f1841b74..8a2d4b90e3b8 100644 --- a/arch/arm/cpu/armv7/zynq/Kconfig +++ b/arch/arm/cpu/armv7/zynq/Kconfig @@ -15,6 +15,9 @@ config TARGET_ZYNQ_ZC70X config TARGET_ZYNQ_ZC770 bool Zynq ZC770 Board +config TARGET_ZYNQ_ZYBO + bool Zynq Zybo Board + endchoice config SYS_CPU @@ -39,5 +42,6 @@ config SYS_CONFIG_NAME default zynq_microzed if TARGET_ZYNQ_MICROZED default zynq_zc70x if TARGET_ZYNQ_ZC70X default zynq_zc770 if TARGET_ZYNQ_ZC770 + default zynq_zybo if TARGET_ZYNQ_ZYBO endif diff --git a/configs/zynq_zybo_defconfig b/configs/zynq_zybo_defconfig new file mode 100644 index ..a00f4fcea5b7 --- /dev/null +++ b/configs/zynq_zybo_defconfig @@ -0,0 +1,4 @@ +CONFIG_SPL=y ++S:CONFIG_ARM=y ++S:CONFIG_ZYNQ=y ++S:CONFIG_TARGET_ZYNQ_ZYBO=y -- 1.8.2.3 pgpAi3nEJLH_i.pgp Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools/genboardscfg.py: improve performance more by using Kconfiglib
Hi Simon,
On Sun, 31 Aug 2014 21:52:41 -0700
Simon Glass s...@chromium.org wrote:
One thing is that buildman doesn't really need the boards.cfg file.
After all it just reads it in board.py. If you make it so that
genboardscfg.py can be a library that returns a dictionary, then
buildman can just import it and use the data directly.
Yes, that's exactly what I was thinking.
This tool should be moved (and renamed) into tools/buildman/ directory
and become a library imported from Buildman, but I think it should be done
after MAKEALL is deleted.
(Maybe can we delete it round at the end of this year?)
After that, board.py will get much simpler or perhaps go away eventually.
The license looks fine to me - you can probably use a short form like this:
https://spdx.org/licenses/ISC
Some nits below.
I think you should include Kconfiglib in a separate patch rather than
people having to install it.
OK. Everyone will feel happy about that as long as the license is OK.
I think this should be formatted like this:
+_SYMBOL_TABLE = {
+'arch' : 'SYS_ARCH',
+'cpu' : 'SYS_CPU',
+'soc' : 'SYS_SOC',
+'vendor' : 'SYS_VENDOR',
+'board' : 'SYS_BOARD',
+'config' : 'SYS_CONFIG_NAME',
+'options' : 'SYS_EXTRA_OPTIONS'
+}
Fixed in v2.
Nice to keep the title on one line, e.g.:
Load a defconfig file to obtain board parameters
Fixed in v2.
How about:
Scan a defconfig file and queue its board parameters
Instead I used
Scan defconfig files and queue their board parameters
because this function takes multiple defconfig files.
This is shorter:
Collect board parameters for all defconfig files
Fixed in v2.
+total = len(all_defconfigs)
Would total_boards be a better name?
Fixed in v2.
+processes = []
+queues = []
+for i in range(jobs):
+defconfigs = all_defconfigs[total * i / jobs : total * (i + 1)
/jobs]
/ jobs
(add space)
Fixed in v2.
Return the status of the given board.
Returns:
- Either 'Active' or 'Orphan'
+ Either 'Active' or 'Orphan' usually.
+ Return '-' displaying a warning if something strange happens.
This refers to behaviour rather than return value, so should probably
go above the 'Returns' section.
Fixed in v2.
-This method parses MAINTAINERS and add board status and
-maintainers information to the database.
+This method parses the given MAINTAINERS file and accumulates
+board status and maintainers information.
s/This method parses/Parse/
Fixed in v2.
+def format_and_output(params_list, output):
+Columnate the board parameters, sort lines alphabetically,
+and then write them to a file.
Most of this could go into the description - the title could be shorter.
Fixed in v2.
def main():
parser = optparse.OptionParser()
# Add options here
-parser.add_option('-j', '--jobs',
- help='the number of jobs to run simultaneously')
parser.add_option('-f', '--force', action=store_true, default=False,
help='regenerate the output even if it is new')
+parser.add_option('-j', '--jobs',
+ help='the number of jobs to run simultaneously')
How about:
parser.add_option('-j', '--jobs', type='int',
default=multiprocessing.cpu_count().
help='the number of jobs to run simultaneously')
I did not this function. This is much simpler.
Great!
and avoid the checking below.
+parser.add_option('-o', '--output',
+ help='output file [default=%s]' % OUTPUT_FILE)
parser.add_option('-o', '--output', default=OUTPUT_FILE,
help='output file')
and hopefully avoid the if...then below.
Removed if...then.
I left 'output file [default=boards.cfg]' just in case.
(options, args) = parser.parse_args()
if options.jobs:
try:
jobs = int(options.jobs)
except ValueError:
-sys.exit('Option -j (--jobs) takes a number')
+sys.exit('Option -j (--jobs) takes an integer')
+if jobs = 0:
+sys.exit('Option -j (--jobs) takes a positive integer')
else:
try:
jobs = int(subprocess.Popen(['getconf', '_NPROCESSORS_ONLN'],
-
stdout=subprocess.PIPE).communicate()[0])
+
stdout=subprocess.PIPE).communicate()[0])
Does multiprocessing.cpu_count() work?
Yes it worked, but I added try ... except just in case.
Your comments are very helpful and appreciated. Thanks!!
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
Re: [U-Boot] [PATCH 3/3] kconfig: zynq: Add ZYBO board
Hi Peter and Masahiro, On 09/01/2014 04:25 AM, Masahiro Yamada wrote: Hi Peter, Sorry, this patch no longer applies on the mainline. Could you rebase and repost this patch, please? (You need to touch arch/arm/cpu/armv7/zynq/Kconfig, intead of arch/arm/Kconfig, board/xilinx/zynq/Kconfig) I have rebased that patches on the top of Tom's tree. Here is v2 patch: https://patchwork.ozlabs.org/patch/384762/ Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform 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] [PATCH v4 1/2] blackfin: convert blackfin board_f and board_r to use generic board init functions
On 09/01/2014 04:52 AM, Sonic Zhang wrote: Hi Michael, On Fri, Aug 29, 2014 at 8:20 PM, Michal Simek mon...@monstr.eu wrote: Hi Sonic On 08/07/2014 09:08 AM, Sonic Zhang wrote: From: Sonic Zhang sonic.zh...@analog.com - move blackfin specific cpu init code from blackfin board.c to cpu.c - remove blackfin specific board init code and invoke generic board_f fron cpu init entry - rename section name bss_vma to bss_start in order to match the generic board init code - add a fake relocate_code function to set up the new stack only I would like get more information about this change. I have spent some time on Microblaze to move to generic board and I need to use sort of the same approach. I will play with full reloc but as I see there will be a lot of additional code generated which increase u-boot footprint and brings nothing. That's why I would like to know why you have decided to use fake relocate_code function and what setup you are using before and after relocation (location of stack, gd, malloc areas, etc). The Blackfin u-boot start code has already done the relocation before the generic board_init_f() is invoked. But, the new stack pointer can not be set until all functions in init_sequence_f[] are done. So, the last function in init_sequence_f[] relocate_code() is used to update the stack point and jump to the generic board_init_f(). Blackfin architecture defines global static gd and bd data and set the init stack point to (CONFIG_SYS_MALLOC_BASE - 4). Ah ok. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/3] tools: Import Kconfiglib
Kconfiglib is the flexible Python Kconfig parser and library created by Ulf Magnusson. (https://github.com/ulfalizer/Kconfiglib) This commit imports kconfiglib.py from commit ce84c22e58fa59cb93679d4ead03c3cd1387965e, with ISC SPDX-License-Identifier. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Signed-off-by: Ulf Magnusson ulfali...@gmail.com Cc: Ulf Magnusson ulfali...@gmail.com Cc: Wolfgang Denk w...@denx.de --- Changes in v2: - Newly added tools/buildman/kconfiglib.py | 3799 ++ 1 file changed, 3799 insertions(+) create mode 100644 tools/buildman/kconfiglib.py diff --git a/tools/buildman/kconfiglib.py b/tools/buildman/kconfiglib.py new file mode 100644 index 000..31fd3c9 --- /dev/null +++ b/tools/buildman/kconfiglib.py @@ -0,0 +1,3799 @@ +# +# SPDX-License-Identifier: GPL-2.0+ +# +# Author: Ulf Magnusson +# https://github.com/ulfalizer/Kconfiglib + +# This is Kconfiglib, a Python library for scripting, debugging, and extracting +# information from Kconfig-based configuration systems. To view the +# documentation, run +# +# $ pydoc kconfiglib +# +# or, if you prefer HTML, +# +# $ pydoc -w kconfiglib +# +# The examples/ subdirectory contains examples, to be run with e.g. +# +# $ make scriptconfig SCRIPT=Kconfiglib/examples/print_tree.py +# +# Look in testsuite.py for the test suite. + + +Kconfiglib is a Python library for scripting and extracting information from +Kconfig-based configuration systems. Features include the following: + + - Symbol values and properties can be looked up and values assigned + programmatically. + - .config files can be read and written. + - Expressions can be evaluated in the context of a Kconfig configuration. + - Relations between symbols can be quickly determined, such as finding all + symbols that reference a particular symbol. + - Highly compatible with the scripts/kconfig/*conf utilities. The test suite + automatically compares outputs between Kconfiglib and the C implementation + for a large number of cases. + +For the Linux kernel, scripts are run using + + $ make scriptconfig SCRIPT=path to script [SCRIPT_ARG=arg] + +Running scripts via the 'scriptconfig' target ensures that required environment +variables (SRCARCH, ARCH, srctree, KERNELVERSION, etc.) are set up correctly. +Alternative architectures can be specified like for other 'make *config' +targets: + + $ make scriptconfig ARCH=mips SCRIPT=path to script [SCRIPT_ARG=arg] + +The script will receive the name of the Kconfig file to load in sys.argv[1]. +(As of Linux 3.7.0-rc8 this is always Kconfig from the kernel top-level +directory.) If an argument is provided with SCRIPT_ARG, it will appear in +sys.argv[2]. + +To get an interactive Python prompt with Kconfiglib preloaded and a Config +object 'c' created, use + + $ make iscriptconfig [ARCH=architecture] + +Kconfiglib requires Python 2. For (i)scriptconfig the command to run the Python +interpreter can be passed in the environment variable PYTHONCMD (defaults to +'python'; PyPy works too and is a bit faster). + +Look in the examples/ subdirectory for examples, which can be run with e.g. + + $ make scriptconfig SCRIPT=Kconfiglib/examples/print_tree.py + +or + + $ make scriptconfig SCRIPT=Kconfiglib/examples/help_grep.py SCRIPT_ARG=kernel + +Look in testsuite.py for the test suite. + +Credits: Written by Ulf Ulfalizer Magnusson + +Send bug reports, suggestions and other feedback to kconfig...@gmail.com . +Don't wrestle with internal APIs. Tell me what you need and I might add it in a +safe way as a client API instead. + +# If you have Psyco installed (32-bit installations, Python = 2.6 only), +# setting this to True (right here, not at runtime) might give a nice speedup. +# (22% faster for parsing arch/x86/Kconfig and 58% faster for evaluating all +# symbols in it without a .config on my Core Duo.) +use_psyco = False + +import os +import re +import string +import sys + +class Config(): + +Represents a Kconfig configuration, e.g. for i386 or ARM. This is the +set of symbols and other items appearing in the configuration together with +their values. Creating any number of Config objects -- including for +different architectures -- is safe; Kconfiglib has no global state. + +# +# Public interface +# + +def __init__(self, + filename = Kconfig, + base_dir = $srctree, + print_warnings = True, + print_undef_assign = False): +Creates a new Config object, representing a Kconfig configuration. +Raises Kconfig_Syntax_Error on syntax errors. + +filename (default: Kconfig) -- The base Kconfig file of the + configuration. For the Linux kernel, this should usually be be + Kconfig from the top-level directory, as environment + variables will make sure the right Kconfig is included from + there (usually
Re: [U-Boot] [PATCH] kbuild: force to define __UBOOT__ in all the C sources
Hello Masahiro, Am 31.08.2014 10:48, schrieb Marek Vasut: On Sunday, August 31, 2014 at 08:16:53 AM, Masahiro Yamada wrote: U-Boot has imported various source files from other projects, mostly Linux. Something like #ifdef __UBOOT__ [ modification for U-Boot ] #else [ original code ] #endif is an often used strategy for clarification of adjusted parts, that is, easier re-sync in future. Instead of defining __UBOOT__ in each source file, passing it from the top Makefile would be easier. Signed-off-by: Masahiro Yamadayamad...@jp.panasonic.com --- Nice idea, Acked-by: Marek Vasutma...@denx.de Acked-by: Heiko Schocher h...@denx.de Maybe we should add an entry in README too? bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v9 11/14] buildman: Add an option to show which boards caused which errors
On Sun, Aug 31, 2014 at 10:09:44PM -0700, Simon Glass wrote: Hi Tom, On 28 August 2014 05:51, Tom Rini tr...@ti.com wrote: On Tue, Aug 26, 2014 at 08:59:52PM -0600, Simon Glass wrote: Hi Tom, On 25 August 2014 13:14, Tom Rini tr...@ti.com wrote: On Mon, Aug 25, 2014 at 09:58:32AM -0600, Simon Glass wrote: Add a -l option to display a list of offending boards against each error/warning line. The information will be shown in brackets as below: 02: wip sandbox: + sandbox arm: + seaboard +(sandbox) arch/sandbox/cpu/cpu.c: In function 'timer_get_us': +(sandbox) arch/sandbox/cpu/cpu.c:40:9: warning: unused variable 'i' [-Wunused-variable] +(seaboard) board/nvidia/seaboard/seaboard.c: In function 'pin_mux_mmc': +(seaboard) board/nvidia/seaboard/seaboard.c:36:9: warning: unused variable 'fred' [-Wunused-variable] +(seaboard) int fred; +(seaboard) ^ Signed-off-by: Simon Glass s...@chromium.org Doing buildman ... ; buildman ... -svl (since I want to spit out the summary at once due to how LSF mangles output to file), I don't see What is -s? summary. anything for what caused powerpc failures say (where there's lot of things complaining about generic board). So something isn't right, is this something you can reproduce locally? I'm going to make sure that -e really is implied like the doc says. Thanks! ./tools/buildman/buildman -vl sandbox Building current source for 1 boards (1 thread, 4 jobs per thread) sandbox: + sandbox +(sandbox) arch/sandbox/cpu/cpu.c: In function ‘__udelay’: +(sandbox) arch/sandbox/cpu/cpu.c:36:5: error: unknown type name ‘oijew’ +(sandbox) arch/sandbox/cpu/cpu.c:37:2: error: conflicting types for ‘os_usleep’ +(sandbox) include/os.h:155:6: note: previous declaration of ‘os_usleep’ was here +(sandbox) make[2]: *** [arch/sandbox/cpu/cpu.o] Error 1 +(sandbox) make[1]: *** [arch/sandbox/cpu] Error 2 +(sandbox) make: *** [sub-make] Error 2 w+(sandbox) arch/sandbox/cpu/cpu.c: In function ‘do_reset’: w+(sandbox) arch/sandbox/cpu/cpu.c:27:13: warning: unused variable ‘i’ [-Wunused-variable] w+(sandbox) arch/sandbox/cpu/cpu.c:37:2: warning: parameter names (without types) in function declaration [enabled by default] 001 /1 sandbox This shows warnings and errors, and -e is implied (but note you should test with both series - I pushed 'buildman5' to u-boot-x86.git just in case you only have one). I might be able to repeat your problem, except for the LSF part. What command line are you using? I do: ./tools/buildman/buildman -b master -c 1 -T 1 -j 24 \ -o /tmp/trini/eldk521 -G ~/.buildman.eldk521 'arm|powerpc' ./tools/buildman/buildman -b master -c 1 -T 1 -j 24 \ -o /tmp/trini/eldk521 -G ~/.buildman.eldk521 'arm|powerpc' -svel Doing '-svl' would omit the information I expected, adding in -e worked. I do it this way since LSF only lets me log raw stdout to a file so doing a build then a summary pass gives me more easily readable output. OK I missed that you were doing two steps. -v is only meaningful *without* -s: it makes the *build* verbose. When building, -v implies -e, The summary (-s) is always verbose, so doesn't need -v. OK, but in step #2, -svl _doesn't_ give me information about what boards have what problem and -svel does. You're saying -sel should work too, but commit text (and help text?) says that -l implies -e, but it's not. -- 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] [PATCH] microblaze: Fix printf size_t format related warnings (again...)
On 08/26/2014 12:45 PM, Vasili Galka wrote: The basic idea: Define size_t using the __SIZE_TYPE__ compiler-defined type. For detailed explanation see similar patch for the nios2 arch: http://patchwork.ozlabs.org/patch/379938/ Signed-off-by: Vasili Galka vvv...@gmail.com Cc: Michal Simek mon...@monstr.eu --- arch/microblaze/include/asm/posix_types.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/microblaze/include/asm/posix_types.h b/arch/microblaze/include/asm/posix_types.h index 38dc5aa..ccc6235 100644 --- a/arch/microblaze/include/asm/posix_types.h +++ b/arch/microblaze/include/asm/posix_types.h @@ -27,7 +27,11 @@ typedef int__kernel_pid_t; typedef unsigned short __kernel_ipc_pid_t; typedef unsigned int __kernel_uid_t; typedef unsigned int __kernel_gid_t; +#ifdef __GNUC__ +typedef __SIZE_TYPE__ __kernel_size_t; +#else typedef unsigned int __kernel_size_t; +#endif typedef int __kernel_ssize_t; typedef int __kernel_ptrdiff_t; typedef long __kernel_time_t; Applied with the change that instead of patchwork link is sha1 to the nios2 commit. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v8 07/12] arm:reset: call the reset_misc() before the cpu reset
On an Odroid U3 board, the SOC is unable to reset the eMMC card
in the DWMMC mode by the cpu software reset. Manual reset of the card
by switching proper gpio pin - fixes this issue.
Such solution needs to add a call to pre reset function.
This is done by the reset_misc() function, which is called before reset_cpu().
The function reset_misc() is a weak function.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
Cc: Albert ARIBAUD albert.u.b...@aribaud.net
Cc: Tom Rini tr...@ti.com
Changes v4:
- arch/arm/reset: fix weak function attribute to proper style
---
arch/arm/lib/reset.c | 6 ++
include/common.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/arch/arm/lib/reset.c b/arch/arm/lib/reset.c
index 7a03580..9a95f08 100644
--- a/arch/arm/lib/reset.c
+++ b/arch/arm/lib/reset.c
@@ -23,6 +23,10 @@
#include common.h
+__weak void reset_misc(void)
+{
+}
+
int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
puts (resetting ...\n);
@@ -30,6 +34,8 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
udelay (5); /* wait 50 ms */
disable_interrupts();
+
+ reset_misc();
reset_cpu(0);
/*NOTREACHED*/
diff --git a/include/common.h b/include/common.h
index c7e51ca..97c04df 100644
--- a/include/common.h
+++ b/include/common.h
@@ -616,6 +616,7 @@ int checkicache (void);
intcheckdcache (void);
void upmconfig (unsigned int, unsigned int *, unsigned int);
ulong get_tbclk (void);
+void reset_misc(void);
void reset_cpu (ulong addr);
#if defined (CONFIG_OF_LIBFDT) defined (CONFIG_OF_BOARD_SETUP)
void ft_cpu_setup(void *blob, bd_t *bd);
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v8 01/12] samsung: misc: fix soc revision setting in the set_board_info()
The byte order of soc revision was inverted, now it is fixed.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
---
board/samsung/common/misc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/samsung/common/misc.c b/board/samsung/common/misc.c
index 03106fd..a453a82 100644
--- a/board/samsung/common/misc.c
+++ b/board/samsung/common/misc.c
@@ -26,8 +26,8 @@ void set_board_info(void)
{
char info[64];
- snprintf(info, ARRAY_SIZE(info), %d.%d, s5p_cpu_rev 0x0f,
-(s5p_cpu_rev 0xf0) 0x04);
+ snprintf(info, ARRAY_SIZE(info), %u.%u, (s5p_cpu_rev 0xf0) 4,
+s5p_cpu_rev 0xf);
setenv(soc_rev, info);
snprintf(info, ARRAY_SIZE(info), %x, s5p_cpu_id);
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v8 03/12] arch:exynos: boot mode: add get_boot_mode(), code cleanup
This patch introduces code clean-up for exynos boot mode check.
It includes:
- removal of typedef: boot_mode
- move the boot mode enum to arch-exynos/power.h
- add bootmode for sequence: eMMC 4.4 ch4 / SD ch2
- add new function: get_boot_mode() for OM[5:1] pin check
- update spl boot code
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Changes v5:
- exynos: boot mode: add missing bootmode (1st:EMMC 4.4 / 2nd:SD ch2)
Changes v6:
- none
changes v7:
- change boot mode name: BOOT_MODE_MMC to BOOT_MODE_SD
---
arch/arm/cpu/armv7/exynos/power.c| 7 +++
arch/arm/cpu/armv7/exynos/spl_boot.c | 7 +++
arch/arm/include/asm/arch-exynos/power.h | 21 +
arch/arm/include/asm/arch-exynos/spl.h | 17 ++---
4 files changed, 33 insertions(+), 19 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/power.c
b/arch/arm/cpu/armv7/exynos/power.c
index 638ee0b..e1ab3d6 100644
--- a/arch/arm/cpu/armv7/exynos/power.c
+++ b/arch/arm/cpu/armv7/exynos/power.c
@@ -202,3 +202,10 @@ void power_exit_wakeup(void)
else
exynos4_power_exit_wakeup();
}
+
+unsigned int get_boot_mode(void)
+{
+ unsigned int om_pin = samsung_get_base_power();
+
+ return readl(om_pin) OM_PIN_MASK;
+}
diff --git a/arch/arm/cpu/armv7/exynos/spl_boot.c
b/arch/arm/cpu/armv7/exynos/spl_boot.c
index 7916630..658e4cb 100644
--- a/arch/arm/cpu/armv7/exynos/spl_boot.c
+++ b/arch/arm/cpu/armv7/exynos/spl_boot.c
@@ -20,7 +20,6 @@
#include clock_init.h
DECLARE_GLOBAL_DATA_PTR;
-#define OM_STAT (0x1f 1)
/* Index into irom ptr table */
enum index {
@@ -184,7 +183,7 @@ static void exynos_spi_copy(unsigned int uboot_size,
unsigned int uboot_addr)
*/
void copy_uboot_to_ram(void)
{
- enum boot_mode bootmode = BOOT_MODE_OM;
+ unsigned int bootmode = BOOT_MODE_OM;
u32 (*copy_bl2)(u32 offset, u32 nblock, u32 dst) = NULL;
u32 offset = 0, size = 0;
@@ -207,7 +206,7 @@ void copy_uboot_to_ram(void)
#endif
if (bootmode == BOOT_MODE_OM)
- bootmode = readl(samsung_get_base_power()) OM_STAT;
+ bootmode = get_boot_mode();
switch (bootmode) {
#ifdef CONFIG_SPI_BOOTING
@@ -216,7 +215,7 @@ void copy_uboot_to_ram(void)
exynos_spi_copy(param-uboot_size, CONFIG_SYS_TEXT_BASE);
break;
#endif
- case BOOT_MODE_MMC:
+ case BOOT_MODE_SD:
offset = BL2_START_OFFSET;
size = BL2_SIZE_BLOC_COUNT;
copy_bl2 = get_irom_func(MMC_INDEX);
diff --git a/arch/arm/include/asm/arch-exynos/power.h
b/arch/arm/include/asm/arch-exynos/power.h
index 4f2447b..e8a98a5 100644
--- a/arch/arm/include/asm/arch-exynos/power.h
+++ b/arch/arm/include/asm/arch-exynos/power.h
@@ -1670,6 +1670,27 @@ struct exynos5420_power {
};
#endif /* __ASSEMBLY__ */
+#define OM_PIN_BITS0x1f
+#define OM_PIN_SHIFT 0x1
+#define OM_PIN_MASK(OM_PIN_BITS OM_PIN_SHIFT)
+
+enum {
+ /*
+* Assign the OM pin values for respective boot modes.
+* Exynos4 does not support spi boot and the mmc boot OM
+* pin values are the same across Exynos4 and Exynos5.
+*/
+ BOOT_MODE_SD = 4, /* SD_CH2 | USB */
+ BOOT_MODE_EMMC = 8, /* EMMC4.4 | USB */
+ BOOT_MODE_EMMC_SD = 40, /* EMMC4.4 | SD_CH2 */
+ BOOT_MODE_SERIAL = 20,
+ /* Boot based on Operating Mode pin settings */
+ BOOT_MODE_OM = 32,
+ BOOT_MODE_USB, /* Boot using USB download */
+};
+
+unsigned int get_boot_mode(void);
+
void set_mipi_phy_ctrl(unsigned int dev_index, unsigned int enable);
#define EXYNOS_MIPI_PHY_ENABLE (1 0)
diff --git a/arch/arm/include/asm/arch-exynos/spl.h
b/arch/arm/include/asm/arch-exynos/spl.h
index b1d68c3..cdcb2bc 100644
--- a/arch/arm/include/asm/arch-exynos/spl.h
+++ b/arch/arm/include/asm/arch-exynos/spl.h
@@ -8,20 +8,7 @@
#define __ASM_ARCH_EXYNOS_SPL_H__
#include asm/arch-exynos/dmc.h
-
-enum boot_mode {
- /*
-* Assign the OM pin values for respective boot modes.
-* Exynos4 does not support spi boot and the mmc boot OM
-* pin values are the same across Exynos4 and Exynos5.
-*/
- BOOT_MODE_MMC = 4,
- BOOT_MODE_EMMC = 8, /* EMMC4.4 */
- BOOT_MODE_SERIAL = 20,
- /* Boot based on Operating Mode pin settings */
- BOOT_MODE_OM = 32,
- BOOT_MODE_USB, /* Boot using USB download */
-};
+#include asm/arch/power.h
#ifndef __ASSEMBLY__
/* Parameters of early board initialization in SPL */
@@ -62,7 +49,7 @@ struct spl_machine_param {
* table only for mmc boot.
*/
u32 uboot_size;
- enum boot_mode boot_source;/* Boot device */
+ unsignedboot_source;/* Boot device */
unsignedfrequency_mhz; /* Frequency of memory in MHz */
unsignedarm_freq_mhz; /* ARM Frequency in MHz */
u32
[U-Boot] [PATCH v8 11/12] odroid: add odroid U3/X2 device tree description
This is a standard description for Odroid boards.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Tom Rini tr...@ti.com
---
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/exynos4412-odroid.dts | 70 ++
2 files changed, 72 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/exynos4412-odroid.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index c46b7be..1ccd827 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1,7 +1,8 @@
dtb-$(CONFIG_EXYNOS4) += exynos4210-origen.dtb \
exynos4210-universal_c210.dtb \
exynos4210-trats.dtb \
- exynos4412-trats2.dtb
+ exynos4412-trats2.dtb \
+ exynos4412-odroid.dtb
dtb-$(CONFIG_EXYNOS5) += exynos5250-arndale.dtb \
exynos5250-snow.dtb \
diff --git a/arch/arm/dts/exynos4412-odroid.dts
b/arch/arm/dts/exynos4412-odroid.dts
new file mode 100644
index 000..24d0bf1
--- /dev/null
+++ b/arch/arm/dts/exynos4412-odroid.dts
@@ -0,0 +1,70 @@
+/*
+ * Odroid-U3/X2 board device tree source
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/dts-v1/;
+/include/ exynos4.dtsi
+
+/ {
+ model = Odroid based on Exynos4412;
+ compatible = samsung,odroid, samsung,exynos4412;
+
+ aliases {
+ i2c0 = /i2c@1386;
+ serial0 = /serial@1380;
+ console = /serial@1381;
+ mmc2 = sdhci@1253;
+ mmc4 = dwmmc@1255;
+ };
+
+ i2c@1386 {
+ samsung,i2c-sda-delay = 100;
+ samsung,i2c-slave-addr = 0x10;
+ samsung,i2c-max-bus-freq = 10;
+ status = okay;
+
+ max77686_pmic@09 {
+ compatible = maxim,max77686_pmic;
+ interrupts = 7 0;
+ reg = 0x09 0 0;
+ #clock-cells = 1;
+ };
+ };
+
+ serial@1381 {
+ status = okay;
+ };
+
+ sdhci@1251 {
+ status = disabled;
+ };
+
+ sdhci@1252 {
+ status = disabled;
+ };
+
+ sdhci@1253 {
+ samsung,bus-width = 4;
+ samsung,timing = 1 2 3;
+ cd-gpios = gpio 0xC2 0;
+ };
+
+ sdhci@1254 {
+ status = disabled;
+ };
+
+ dwmmc@1255 {
+ samsung,bus-width = 8;
+ samsung,timing = 2 1 0;
+ samsung,removable = 0;
+ fifoth_val = 0x203f0040;
+ bus_hz = 4;
+ div = 0x3;
+ index = 4;
+ };
+};
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v8 08/12] samsung: board: enable support of multiple board types
This change adds declaration of functions:
- set_board_type() - called at board_early_init_f()
- get_board_type() - called at checkboard()
For supporting multiple board types in a one config - it is welcome
to display the current board model. This is what get_board_type()
should return.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
---
Changes v3:
- change the commit order
- include/samsung/misc.h: add new functions declaration
- update a commit message
Changes v4:
- checkboard(): remove redundant variable
Changes v5:
- board.c: move call to set_board_type() into board_early_init_f()
- misc.h: remove get_board_name() function declaration
---
board/samsung/common/board.c | 15 ++-
include/samsung/misc.h | 4
2 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index 5693813..3d1cf43 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -137,7 +137,9 @@ static int board_uart_init(void)
int board_early_init_f(void)
{
int err;
-
+#ifdef CONFIG_BOARD_TYPES
+ set_board_type();
+#endif
err = board_uart_init();
if (err) {
debug(UART init failed\n);
@@ -147,7 +149,6 @@ int board_early_init_f(void)
#ifdef CONFIG_SYS_I2C_INIT_BOARD
board_i2c_init(gd-fdt_blob);
#endif
-
return exynos_early_init_f();
}
#endif
@@ -280,11 +281,15 @@ int board_mmc_init(bd_t *bis)
#ifdef CONFIG_DISPLAY_BOARDINFO
int checkboard(void)
{
- const char *board_name;
+ const char *board_info;
- board_name = fdt_getprop(gd-fdt_blob, 0, model, NULL);
- printf(Board: %s\n, board_name ? board_name : unknown);
+ board_info = fdt_getprop(gd-fdt_blob, 0, model, NULL);
+ printf(Board: %s\n, board_info ? board_info : unknown);
+#ifdef CONFIG_BOARD_TYPES
+ board_info = get_board_type();
+ printf(Model: %s\n, board_info ? board_info : unknown);
+#endif
return 0;
}
#endif
diff --git a/include/samsung/misc.h b/include/samsung/misc.h
index e82bf32..607e8d4 100644
--- a/include/samsung/misc.h
+++ b/include/samsung/misc.h
@@ -33,5 +33,9 @@ char *get_dfu_alt_system(void);
char *get_dfu_alt_boot(void);
void set_dfu_alt_info(void);
#endif
+#ifdef CONFIG_BOARD_TYPES
+void set_board_type(void);
+const char *get_board_type(void);
+#endif
#endif /* __SAMSUNG_MISC_COMMON_H__ */
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v8 00/12] Add support to Odroid U3/X2
This patch set introduces changes to common Samsung code as a preparation of new board support: - boot device check - code cleanup - automatic init order of mmc drivers - automatic setting of dfu entities which depends on boot device - pre reset function call for board own implementation - setting board info environment for multi board support New board config: - odroid_config - Odroid U3/X2 support V8 changes: - patchset adjust to Kconfig Przemyslaw Marczak (12): samsung: misc: fix soc revision setting in the set_board_info() exynos: pinmux: fix the gpio names for exynos4x12 mmc arch:exynos: boot mode: add get_boot_mode(), code cleanup board:samsung: check the boot device and init the right mmc driver. samsung: misc: add function for setting $dfu_alt_info samsung:board: misc_init_r: call set_dfu_alt_info() arm:reset: call the reset_misc() before the cpu reset samsung: board: enable support of multiple board types samsung: misc: use board specific functions to set env board info odroid: add board file for Odroid X2/U3 based on Samsung Exynos4412 odroid: add odroid U3/X2 device tree description odroid: kconfig: add odroid_defconfig arch/arm/cpu/armv7/exynos/Kconfig| 4 + arch/arm/cpu/armv7/exynos/pinmux.c | 4 +- arch/arm/cpu/armv7/exynos/power.c| 7 + arch/arm/cpu/armv7/exynos/spl_boot.c | 7 +- arch/arm/dts/Makefile| 3 +- arch/arm/dts/exynos4412-odroid.dts | 70 + arch/arm/include/asm/arch-exynos/power.h | 21 ++ arch/arm/include/asm/arch-exynos/spl.h | 17 +- arch/arm/lib/reset.c | 6 + board/samsung/common/board.c | 55 +++- board/samsung/common/misc.c | 57 +++- board/samsung/odroid/Kconfig | 15 + board/samsung/odroid/MAINTAINERS | 6 + board/samsung/odroid/Makefile| 8 + board/samsung/odroid/odroid.c| 470 +++ board/samsung/odroid/setup.h | 255 + configs/odroid_defconfig | 3 + doc/README.odroid| 143 ++ include/common.h | 1 + include/configs/odroid.h | 216 ++ include/samsung/misc.h | 10 + 21 files changed, 1337 insertions(+), 41 deletions(-) create mode 100644 arch/arm/dts/exynos4412-odroid.dts create mode 100644 board/samsung/odroid/Kconfig create mode 100644 board/samsung/odroid/MAINTAINERS create mode 100644 board/samsung/odroid/Makefile create mode 100644 board/samsung/odroid/odroid.c create mode 100644 board/samsung/odroid/setup.h create mode 100644 configs/odroid_defconfig create mode 100644 doc/README.odroid create mode 100644 include/configs/odroid.h -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v8 12/12] odroid: kconfig: add odroid_defconfig
This config is valid for two devices: - Odroid X2, - Odroid U3. Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com Cc: Minkyu Kang mk7.k...@samsung.com Cc: Tom Rini tr...@ti.com --- Changes v2: - odroid config: add CONFIG_DFU_ALT_BOOTLOADER - odroid config: change name of CONFIG_DFU_BOOT_ALT_* to CONFIG_DFU_ALT_BOOT_* Changes v3: - odroid.h: update CONFIG_DFU_ALT_BOOT_** with required bootloader binaries - odroid.h: add multi image support (CONFIG_FIT) - odroid.h: add autoboot script for multi boot options - odroid.h: change env name: dfu_alt_info - dfu_alt_system - odroid.h: update config name: CONFIG_SET_DFU_ALT_INFO - odroid.h: reduce boot delay to 0 seconds - update: doc/README.odroid Changes v5: - odroid.h: default environment cleanup - odroid.h: remove unused definitions - odroid.h: dfu_alt_system update - odroid.h: define CONFIG_SET_DFU_ALT_BUF_LEN to 1k - odroid.h: add init ramdisk support - update: doc/README.odroid Changes v6: - odroid.h: fix ramdisk load issue Changes v8: - add Kconfig configuration for Odroid --- arch/arm/cpu/armv7/exynos/Kconfig | 4 + board/samsung/odroid/Kconfig | 15 +++ board/samsung/odroid/MAINTAINERS | 6 ++ configs/odroid_defconfig | 3 + doc/README.odroid | 143 + include/configs/odroid.h | 216 ++ 6 files changed, 387 insertions(+) create mode 100644 board/samsung/odroid/Kconfig create mode 100644 board/samsung/odroid/MAINTAINERS create mode 100644 configs/odroid_defconfig create mode 100644 doc/README.odroid create mode 100644 include/configs/odroid.h diff --git a/arch/arm/cpu/armv7/exynos/Kconfig b/arch/arm/cpu/armv7/exynos/Kconfig index f1cacdc..b6a558b 100644 --- a/arch/arm/cpu/armv7/exynos/Kconfig +++ b/arch/arm/cpu/armv7/exynos/Kconfig @@ -18,6 +18,9 @@ config TARGET_ORIGEN config TARGET_TRATS2 bool Exynos4412 Trat2 board +config TARGET_ODROID + bool Exynos4412 Odroid board + config TARGET_ARNDALE bool Exynos5250 Arndale board @@ -48,6 +51,7 @@ source board/samsung/trats/Kconfig source board/samsung/universal_c210/Kconfig source board/samsung/origen/Kconfig source board/samsung/trats2/Kconfig +source board/samsung/odroid/Kconfig source board/samsung/arndale/Kconfig source board/samsung/smdk5250/Kconfig source board/samsung/smdk5420/Kconfig diff --git a/board/samsung/odroid/Kconfig b/board/samsung/odroid/Kconfig new file mode 100644 index 000..8dcfb48 --- /dev/null +++ b/board/samsung/odroid/Kconfig @@ -0,0 +1,15 @@ +if TARGET_ODROID + +config SYS_BOARD + string + default odroid + +config SYS_VENDOR + string + default samsung + +config SYS_CONFIG_NAME + string + default odroid + +endif diff --git a/board/samsung/odroid/MAINTAINERS b/board/samsung/odroid/MAINTAINERS new file mode 100644 index 000..2131d36 --- /dev/null +++ b/board/samsung/odroid/MAINTAINERS @@ -0,0 +1,6 @@ +ODROID BOARD +M: Przemyslaw Marczak p.marc...@samsung.com +S: Maintained +F: board/samsung/odroid/ +F: include/configs/odroid.h +F: configs/odroid_defconfig diff --git a/configs/odroid_defconfig b/configs/odroid_defconfig new file mode 100644 index 000..a1c7ac5 --- /dev/null +++ b/configs/odroid_defconfig @@ -0,0 +1,3 @@ +CONFIG_ARM=y +CONFIG_ARCH_EXYNOS=y +CONFIG_TARGET_ODROID=y diff --git a/doc/README.odroid b/doc/README.odroid new file mode 100644 index 000..528bb95 --- /dev/null +++ b/doc/README.odroid @@ -0,0 +1,143 @@ + U-boot for Odroid X2/U3 + + +1. Summary +== +This is a quick instruction for setup Odroid boards based on Exynos4412. +Board config: odroid_config + +2. Supported devices + +This U-BOOT config can be used on two boards: +- Odroid U3 +- Odroid X2 +with CPU Exynos 4412 rev 2.0 and 2GB of RAM + +3. Boot sequence + +iROM-BL1-(BL2 + TrustZone)-U-BOOT + +This version of U-BOOT doesn't implement SPL but it is required(BL2) +and can be found in boot.tar.gz from here: +http://dev.odroid.com/projects/4412boot/wiki/FrontPage?action=downloadvalue=boot.tar.gz +or here: +http://odroid.in/guides/ubuntu-lfs/boot.tar.gz + +4. Boot media layout + +The table below shows SD/eMMC cards layout for U-boot. +The block offset is starting from 0 and the block size is 512B. + - +| Binary | Block offset| part type | +| name| SD | eMMC |(eMMC only)| + - +| Bl1 | 1| 0| 1 (boot) | +| Bl2 | 31 | 30 | 1 (boot) | +| U-boot| 63 | 62 | 1 (boot) | +| Tzsw | 2111 | 2110 | 1 (boot) | +| Uboot Env | 2500 | 2500 | 0 (user) | + - + +5. Prepare the SD boot card - with SD card reader += +To prepare bootable media you need boot binaries provided by hardkernel. +File boot.tar.gz (link in point 3.)
[U-Boot] [PATCH v8 05/12] samsung: misc: add function for setting $dfu_alt_info
This change introduces new common function:
- set_dfu_alt_info() - put dfu system and bootloader setting
into $dfu_alt_info.
functions declaration:
- char *get_dfu_alt_system(void)
- char *get_dfu_alt_boot(void)
- void set_dfu_alt_info(void)
and new config:
- CONFIG_SET_DFU_ALT_INFO
This function can be used for auto setting dfu configuration on boot.
Such feature is useful for multi board support by one u-boot binary.
Each board should define two functions:
- get_dfu_alt_system()
- get_dfu_alt_boot()
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
---
Changes v2:
- change config names:
CONFIG_SET_DFU_BOOT_ALT to CONFIG_DFU_ALT_BOOTLOADER and
CONFIG_DFU_BOOT_ALT_* to CONFIG_DFU_ALT_BOOT_*
- change function name: set_dfu_boot_alt() to set_dfu_alt_boot()
- remove superfluous ifdefs
Changes v3:
- set $dfu_alt_info at every boot
- new config: CONFIG_SET_DFU_ALT_INFO
- update commit msg
Changes v4:
- set_dfu_alt_info(): add checking the pointer returned by malloc
Changes v5:
- set_dfu_alt_info(): remove malloc and declare cache aligned buffer
- set_dfu_alt_info(): introduce CONFIG_SET_DFU_ALT_BUF_LEN
---
board/samsung/common/misc.c | 41 +
include/samsung/misc.h | 6 ++
2 files changed, 47 insertions(+)
diff --git a/board/samsung/common/misc.c b/board/samsung/common/misc.c
index a453a82..9e52452 100644
--- a/board/samsung/common/misc.c
+++ b/board/samsung/common/misc.c
@@ -11,6 +11,7 @@
#include samsung/misc.h
#include errno.h
#include version.h
+#include malloc.h
#include linux/sizes.h
#include asm/arch/cpu.h
#include asm/arch/gpio.h
@@ -21,6 +22,46 @@
DECLARE_GLOBAL_DATA_PTR;
+#ifdef CONFIG_SET_DFU_ALT_INFO
+void set_dfu_alt_info(void)
+{
+ size_t buf_size = CONFIG_SET_DFU_ALT_BUF_LEN;
+ ALLOC_CACHE_ALIGN_BUFFER(char, buf, buf_size);
+ char *alt_info = Settings not found!;
+ char *status = error!\n;
+ char *alt_setting;
+ char *alt_sep;
+ int offset = 0;
+
+ puts(DFU alt info setting: );
+
+ alt_setting = get_dfu_alt_boot();
+ if (alt_setting) {
+ setenv(dfu_alt_boot, alt_setting);
+ offset = snprintf(buf, buf_size, %s, alt_setting);
+ }
+
+ alt_setting = get_dfu_alt_system();
+ if (alt_setting) {
+ if (offset)
+ alt_sep = ;;
+ else
+ alt_sep = ;
+
+ offset += snprintf(buf + offset, buf_size - offset,
+ %s%s, alt_sep, alt_setting);
+ }
+
+ if (offset) {
+ alt_info = buf;
+ status = done\n;
+ }
+
+ setenv(dfu_alt_info, alt_info);
+ puts(status);
+}
+#endif
+
#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
void set_board_info(void)
{
diff --git a/include/samsung/misc.h b/include/samsung/misc.h
index 10653a1..e82bf32 100644
--- a/include/samsung/misc.h
+++ b/include/samsung/misc.h
@@ -28,4 +28,10 @@ void check_boot_mode(void);
void draw_logo(void);
#endif
+#ifdef CONFIG_SET_DFU_ALT_INFO
+char *get_dfu_alt_system(void);
+char *get_dfu_alt_boot(void);
+void set_dfu_alt_info(void);
+#endif
+
#endif /* __SAMSUNG_MISC_COMMON_H__ */
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v8 06/12] samsung:board: misc_init_r: call set_dfu_alt_info()
This change enable automatic setting of dfu alt info
on every boot. This is useful in case of booting one
u-boot binary from multiple media.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
---
board/samsung/common/board.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index 1fa0e51..5693813 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -324,6 +324,9 @@ int arch_early_init_r(void)
#ifdef CONFIG_MISC_INIT_R
int misc_init_r(void)
{
+#ifdef CONFIG_SET_DFU_ALT_INFO
+ set_dfu_alt_info();
+#endif
#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
set_board_info();
#endif
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v8 02/12] exynos: pinmux: fix the gpio names for exynos4x12 mmc
This change fixes the bad gpio configuration for the exynos dwmmc. Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com Cc: Beomho Seo beomho@samsung.com Cc: Minkyu Kang mk7.k...@samsung.com Cc: Jaehoon Chung jh80.ch...@samsung.com --- arch/arm/cpu/armv7/exynos/pinmux.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/cpu/armv7/exynos/pinmux.c b/arch/arm/cpu/armv7/exynos/pinmux.c index 86a0c75..b929486 100644 --- a/arch/arm/cpu/armv7/exynos/pinmux.c +++ b/arch/arm/cpu/armv7/exynos/pinmux.c @@ -704,8 +704,8 @@ static int exynos4x12_mmc_config(int peripheral, int flags) ext_func = S5P_GPIO_FUNC(0x3); break; case PERIPH_ID_SDMMC4: - start = EXYNOS4_GPIO_K00; - start_ext = EXYNOS4_GPIO_K13; + start = EXYNOS4X12_GPIO_K00; + start_ext = EXYNOS4X12_GPIO_K13; func = S5P_GPIO_FUNC(0x3); ext_func = S5P_GPIO_FUNC(0x4); break; -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v8 04/12] board:samsung: check the boot device and init the right mmc driver.
It is possible to boot device using a micro SD or eMMC slots.
In this situation, boot device should be registered as a block
device 0 in the MMC framework, because CONFIG_SYS_MMC_ENV_DEV
is usually set to 0 in the most config cases.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
---
Changes V3:
- separate two changes into two commits
Changes V4:
- board.c: add functions: init_mmc() and init_dwmmc()
- board_mmc_init(): call get_boot_mode()
Changes V5:
- none
Changes V6:
- update boot mode name
---
board/samsung/common/board.c | 37 +++--
1 file changed, 27 insertions(+), 10 deletions(-)
diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index 9dc7c83..1fa0e51 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -240,22 +240,39 @@ int board_eth_init(bd_t *bis)
}
#ifdef CONFIG_GENERIC_MMC
-int board_mmc_init(bd_t *bis)
+static int init_mmc(void)
+{
+#ifdef CONFIG_SDHCI
+ return exynos_mmc_init(gd-fdt_blob);
+#else
+ return 0;
+#endif
+}
+
+static int init_dwmmc(void)
{
- int ret;
#ifdef CONFIG_DWMMC
- /* dwmmc initializattion for available channels */
- ret = exynos_dwmmc_init(gd-fdt_blob);
- if (ret)
- debug(dwmmc init failed\n);
+ return exynos_dwmmc_init(gd-fdt_blob);
+#else
+ return 0;
#endif
+}
+
+int board_mmc_init(bd_t *bis)
+{
+ int ret;
+
+ if (get_boot_mode() == BOOT_MODE_SD) {
+ ret = init_mmc();
+ ret |= init_dwmmc();
+ } else {
+ ret = init_dwmmc();
+ ret |= init_mmc();
+ }
-#ifdef CONFIG_SDHCI
- /* mmc initializattion for available channels */
- ret = exynos_mmc_init(gd-fdt_blob);
if (ret)
debug(mmc init failed\n);
-#endif
+
return ret;
}
#endif
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v8 09/12] samsung: misc: use board specific functions to set env board info
This change adds setup of environmental board info using get_board_name() and get_board_type() functions for config CONFIG_BOARD_TYPES. This is useful in case of running many boards with just one config. Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com Cc: Minkyu Kang mk7.k...@samsung.com --- Changes v2: - set_board_info: move the bdtype pointer to avoid unused pointer compilation warning Changes v3: - samsung: misc: change get_board_type_fdt() to get_board_type() - samsung: misc: set env $boardname using get_board_* functions for CONFIG_BOARD_TYPES - update commit msg Changes v5: - misc.c: set_bard_info(): remove a call to get_board_name() --- board/samsung/common/misc.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/board/samsung/common/misc.c b/board/samsung/common/misc.c index 9e52452..8766f0c 100644 --- a/board/samsung/common/misc.c +++ b/board/samsung/common/misc.c @@ -79,8 +79,16 @@ void set_board_info(void) setenv(board_rev, info); #endif #ifdef CONFIG_OF_LIBFDT - snprintf(info, ARRAY_SIZE(info), %s%x-%s.dtb, -CONFIG_SYS_SOC, s5p_cpu_id, CONFIG_SYS_BOARD); + const char *bdtype = ; + const char *bdname = CONFIG_SYS_BOARD; + +#ifdef CONFIG_BOARD_TYPES + bdtype = get_board_type(); + sprintf(info, %s%s, bdname, bdtype); + setenv(boardname, info); +#endif + snprintf(info, ARRAY_SIZE(info), %s%x-%s%s.dtb, +CONFIG_SYS_SOC, s5p_cpu_id, bdname, bdtype); setenv(fdtfile, info); #endif } -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v8 10/12] odroid: add board file for Odroid X2/U3 based on Samsung Exynos4412
This board file supports standard features of Odroid X2 and U3 boards:
- Exynos4412 core clock set to 1000MHz and MPLL peripherial clock set to 800MHz,
- MAX77686 power regulator,
- USB PHY,
- enable XCL205 - power for board peripherials
- check board type: U3 or X2.
- enable Odroid U3 FAN cooler
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Tom Rini tr...@ti.com
---
Changes v2:
- enable fan on odroid U3
Changes v3:
- odroid.c: clean up board name related code
- odroid.c: remove static from set_board_type()
- odroid.c: add implementation of functions: get_dfu_alt_*
- odroid.c: include misc.h
Changes v4:
- odroid.c: dfu_get_alt_boot: add call get_boot_mode()
Changes v5:
- odroid.c: set_board_type: change mdelay to sdelay, define XCL205 GPIO config
- odroid.c: board_gpio_init(): fix OTG for Odroid U3+
- odroid.c: reserve the last 1 MB of dram for secure firmware
- odroid.c: board_clock_init(): code cleanup
- odroid.c: get_dfu_alt_boot(): remove setenv()
- odroid.c: remove get_board_name() function definition
- odroid.c: add enum ODROID_TYPES
---
board/samsung/odroid/Makefile | 8 +
board/samsung/odroid/odroid.c | 470 ++
board/samsung/odroid/setup.h | 255 +++
3 files changed, 733 insertions(+)
create mode 100644 board/samsung/odroid/Makefile
create mode 100644 board/samsung/odroid/odroid.c
create mode 100644 board/samsung/odroid/setup.h
diff --git a/board/samsung/odroid/Makefile b/board/samsung/odroid/Makefile
new file mode 100644
index 000..b98aaeb
--- /dev/null
+++ b/board/samsung/odroid/Makefile
@@ -0,0 +1,8 @@
+#
+# Copyright (c) 2014 Samsung Electronics Co., Ltd. All rights reserved.
+# Przemyslaw Marczak p.marc...@samsung.com
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y := odroid.o
diff --git a/board/samsung/odroid/odroid.c b/board/samsung/odroid/odroid.c
new file mode 100644
index 000..ac19527
--- /dev/null
+++ b/board/samsung/odroid/odroid.c
@@ -0,0 +1,470 @@
+/*
+ * Copyright (C) 2014 Samsung Electronics
+ * Przemyslaw Marczak p.marc...@samsung.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include asm/arch/pinmux.h
+#include asm/arch/power.h
+#include asm/arch/clock.h
+#include asm/arch/gpio.h
+#include asm/gpio.h
+#include asm/arch/cpu.h
+#include power/pmic.h
+#include power/max77686_pmic.h
+#include errno.h
+#include usb.h
+#include usb/s3c_udc.h
+#include samsung/misc.h
+#include setup.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#ifdef CONFIG_BOARD_TYPES
+/* Odroid board types */
+enum {
+ ODROID_TYPE_U3,
+ ODROID_TYPE_X2,
+ ODROID_TYPES,
+};
+
+void set_board_type(void)
+{
+ /* Set GPA1 pin 1 to HI - enable XCL205 output */
+ writel(XCL205_EN_GPIO_CON_CFG, XCL205_EN_GPIO_CON);
+ writel(XCL205_EN_GPIO_DAT_CFG, XCL205_EN_GPIO_CON + 0x4);
+ writel(XCL205_EN_GPIO_PUD_CFG, XCL205_EN_GPIO_CON + 0x8);
+ writel(XCL205_EN_GPIO_DRV_CFG, XCL205_EN_GPIO_CON + 0xc);
+
+ /* Set GPC1 pin 2 to IN - check XCL205 output state */
+ writel(XCL205_STATE_GPIO_CON_CFG, XCL205_STATE_GPIO_CON);
+ writel(XCL205_STATE_GPIO_PUD_CFG, XCL205_STATE_GPIO_CON + 0x8);
+
+ /* XCL205 - needs some latch time */
+ sdelay(20);
+
+ /* Check GPC1 pin2 - LED supplied by XCL205 - X2 only */
+ if (readl(XCL205_STATE_GPIO_DAT) (1 XCL205_STATE_GPIO_PIN))
+ gd-board_type = ODROID_TYPE_X2;
+ else
+ gd-board_type = ODROID_TYPE_U3;
+}
+
+const char *get_board_type(void)
+{
+ const char *board_type[] = {u3, x2};
+
+ return board_type[gd-board_type];
+}
+#endif
+
+#ifdef CONFIG_SET_DFU_ALT_INFO
+char *get_dfu_alt_system(void)
+{
+ return getenv(dfu_alt_system);
+}
+
+char *get_dfu_alt_boot(void)
+{
+ char *alt_boot;
+
+ switch (get_boot_mode()) {
+ case BOOT_MODE_SD:
+ alt_boot = CONFIG_DFU_ALT_BOOT_SD;
+ break;
+ case BOOT_MODE_EMMC:
+ case BOOT_MODE_EMMC_SD:
+ alt_boot = CONFIG_DFU_ALT_BOOT_EMMC;
+ break;
+ default:
+ alt_boot = NULL;
+ break;
+ }
+ return alt_boot;
+}
+#endif
+
+static void board_clock_init(void)
+{
+ unsigned int set, clr, clr_src_cpu, clr_pll_con0, clr_src_dmc;
+ struct exynos4x12_clock *clk = (struct exynos4x12_clock *)
+ samsung_get_base_clock();
+
+ /*
+* CMU_CPU clocks src to MPLL
+* Bit values: 0 ; 1
+* MUX_APLL_SEL:FIN_PLL ; FOUT_APLL
+* MUX_CORE_SEL:MOUT_APLL ; SCLK_MPLL
+* MUX_HPM_SEL: MOUT_APLL ; SCLK_MPLL_USER_C
+* MUX_MPLL_USER_SEL_C: FIN_PLL ; SCLK_MPLL
+ */
+ clr_src_cpu = MUX_APLL_SEL(1) | MUX_CORE_SEL(1) |
+ MUX_HPM_SEL(1) | MUX_MPLL_USER_SEL_C(1);
+ set = MUX_APLL_SEL(0) |
Re: [U-Boot] [PATCH v8 00/12] Add support to Odroid U3/X2
Hello Minkyu, On 09/01/2014 01:50 PM, Przemyslaw Marczak wrote: This patch set introduces changes to common Samsung code as a preparation of new board support: - boot device check - code cleanup - automatic init order of mmc drivers - automatic setting of dfu entities which depends on boot device - pre reset function call for board own implementation - setting board info environment for multi board support New board config: - odroid_config - Odroid U3/X2 support V8 changes: - patchset adjust to Kconfig Przemyslaw Marczak (12): samsung: misc: fix soc revision setting in the set_board_info() exynos: pinmux: fix the gpio names for exynos4x12 mmc arch:exynos: boot mode: add get_boot_mode(), code cleanup board:samsung: check the boot device and init the right mmc driver. samsung: misc: add function for setting $dfu_alt_info samsung:board: misc_init_r: call set_dfu_alt_info() arm:reset: call the reset_misc() before the cpu reset samsung: board: enable support of multiple board types samsung: misc: use board specific functions to set env board info odroid: add board file for Odroid X2/U3 based on Samsung Exynos4412 odroid: add odroid U3/X2 device tree description odroid: kconfig: add odroid_defconfig Can you please merge this patch set as a result of rebase on the top of the last Kconfig changes? Best Regards, -- Przemyslaw Marczak Samsung RD Institute Poland Samsung Electronics p.marc...@samsung.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] tools: imximage: Fix the maximum DCD size for mx53/mx6
According to mx53 and mx6 reference manuals: The maximum size of the DCD limited to 1768 bytes. As each DCD entry consists of 8 bytes, we have a total of 1768 / 8 = 221, and excluding the first entry, which is the header leads to 220 as the maximum number for DCD size. Reported-by: Jonas Karlsson jonas.d.karls...@gmail.com Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- tools/imximage.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/imximage.h b/tools/imximage.h index 01f861e..5b5ad0e 100644 --- a/tools/imximage.h +++ b/tools/imximage.h @@ -8,7 +8,7 @@ #ifndef _IMXIMAGE_H_ #define _IMXIMAGE_H_ -#define MAX_HW_CFG_SIZE_V2 121 /* Max number of registers imx can set for v2 */ +#define MAX_HW_CFG_SIZE_V2 220 /* Max number of registers imx can set for v2 */ #define MAX_HW_CFG_SIZE_V1 60 /* Max number of registers imx can set for v1 */ #define APP_CODE_BARKER0xB1 #define DCD_BARKER 0xB17219E9 -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: imximage: Fix the maximum DCD size for mx53/mx6
Acked! Regards, Nitin Garg -Original Message- From: Fabio Estevam [mailto:fabio.este...@freescale.com] Sent: Monday, September 01, 2014 7:56 AM To: sba...@denx.de Cc: u-boot@lists.denx.de; jonas.d.karls...@gmail.com; Li Ye-B37916; Garg Nitin-B37173; Estevam Fabio-R49496 Subject: [PATCH] tools: imximage: Fix the maximum DCD size for mx53/mx6 According to mx53 and mx6 reference manuals: The maximum size of the DCD limited to 1768 bytes. As each DCD entry consists of 8 bytes, we have a total of 1768 / 8 = 221, and excluding the first entry, which is the header leads to 220 as the maximum number for DCD size. Reported-by: Jonas Karlsson jonas.d.karls...@gmail.com Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- tools/imximage.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/imximage.h b/tools/imximage.h index 01f861e..5b5ad0e 100644 --- a/tools/imximage.h +++ b/tools/imximage.h @@ -8,7 +8,7 @@ #ifndef _IMXIMAGE_H_ #define _IMXIMAGE_H_ -#define MAX_HW_CFG_SIZE_V2 121 /* Max number of registers imx can set for v2 */ +#define MAX_HW_CFG_SIZE_V2 220 /* Max number of registers imx can set +for v2 */ #define MAX_HW_CFG_SIZE_V1 60 /* Max number of registers imx can set for v1 */ #define APP_CODE_BARKER0xB1 #define DCD_BARKER 0xB17219E9 -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] kgdb: Remove first_entry for kgdb
There are two ways to run into handle_exception, run command 'kgdb' and
encounter a breakpoint which triggers exception handling.
The origin source code only saves regs when first run command 'kgdb'.
Take the following for example, When run 'kgdb', regs is saved to entry_regs.
When run 'bootz', regs is not saved. However, if we set a breakpoint, then
continue. When breakpoint is reached, run `quit`, and Now return to the
instruction which follows kgdb, but not bootz.This may cause errors. So,
save regs for each handle_exception call to return to the correct place.
Example:
Target |Host
=kgdb |(gdb)b bootz
|(gdb)c
=bootz |
|(gdb)Here stop because of breakpoint
|(gdb)q
Signed-off-by: Peng Fan van.free...@gmail.com
---
common/kgdb.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/common/kgdb.c b/common/kgdb.c
index 8a621ad..d357463 100644
--- a/common/kgdb.c
+++ b/common/kgdb.c
@@ -103,7 +103,7 @@ static char remcomOutBuffer[BUFMAX];
static char remcomRegBuffer[BUFMAX];
static int initialized = 0;
-static int kgdb_active = 0, first_entry = 1;
+static int kgdb_active;
static struct pt_regs entry_regs;
static long error_jmp_buf[BUFMAX/2];
static int longjmp_on_fault = 0;
@@ -348,16 +348,7 @@ handle_exception (struct pt_regs *regs)
kgdb_enter(regs, kd);
- if (first_entry) {
- /*
-* the first time we enter kgdb, we save the processor
-* state so that we can return to the monitor if the
-* remote end quits gdb (or at least, tells us to quit
-* with the 'k' packet)
-*/
- entry_regs = *regs;
- first_entry = 0;
- }
+ entry_regs = *regs;
ptr = remcomOutBuffer;
@@ -459,7 +450,6 @@ handle_exception (struct pt_regs *regs)
case 'k':/* kill the program, actually return to monitor */
kd.extype = KGDBEXIT_KILL;
*regs = entry_regs;
- first_entry = 1;
goto doexit;
case 'C':/* CSS continue with signal SS */
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [imx PATCH v2] Add i.MX6 CPU temperature sensor support
Hi Nitin,
On Mon, Sep 1, 2014 at 12:25 AM, Nitin Garg nitin.g...@freescale.com wrote:
i.MX6 SoC has onChip temperature sensor. Add support
for this sensor.
Signed-off-by: Nitin Garg nitin.g...@freescale.com
---
arch/arm/cpu/armv7/mx6/soc.c | 142 +++-
arch/arm/imx-common/cpu.c|7 +-
arch/arm/include/asm/arch-mx6/crm_regs.h | 543
+-
arch/arm/include/asm/arch-mx6/imx-regs.h |9 +-
include/configs/mx6sabre_common.h|1 +
Looks better, but I would split this patch in 2:
1/2 that adds the mx6 temperature support
2/2 that adds the mx6 temperature support to mx6sabresd board.
+void check_cpu_temperature(void)
+{
+ int cpu_tmp = 0;
+
+ cpu_tmp = read_cpu_temperature();
+ while (cpu_tmp TEMPERATURE_MIN cpu_tmp TEMPERATURE_MAX) {
+ if (cpu_tmp = TEMPERATURE_HOT) {
+ printf(CPU is %d C, too hot to boot, waiting...\n,
+ cpu_tmp);
+ udelay(500);
+ cpu_tmp = read_cpu_temperature();
+ } else {
+ break;
+ }
+ }
+ if (cpu_tmp TEMPERATURE_MIN cpu_tmp TEMPERATURE_MAX)
+ printf(CPU: Temperature %d C, calibration data: 0x%x\n,
+ cpu_tmp, fuse);
The temperature is useful information to display, but this calibration
data is just noise to have it displayed on every boot.
Could you please change this to only print the temperature?
Thanks
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] imx: ddr: Move mx6q_4x_mt41j128.cfg to mx6sabresd board dir
Move board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg to
board/freescale/mx6sabresd/mx6q_4x_mt41j128.cfg as this is
was designed for the mx6sabresd board. This also updates the
cgtqmx6qeval which makes use of this configuration.
Signed-off-by: Nitin Garg nitin.g...@freescale.com
---
.../{imx/ddr = mx6sabresd}/mx6q_4x_mt41j128.cfg |0
configs/cgtqmx6qeval_defconfig |2 +-
configs/mx6qsabresd_defconfig |2 +-
3 files changed, 2 insertions(+), 2 deletions(-)
rename board/freescale/{imx/ddr = mx6sabresd}/mx6q_4x_mt41j128.cfg (100%)
diff --git a/board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg
b/board/freescale/mx6sabresd/mx6q_4x_mt41j128.cfg
similarity index 100%
rename from board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg
rename to board/freescale/mx6sabresd/mx6q_4x_mt41j128.cfg
diff --git a/configs/cgtqmx6qeval_defconfig b/configs/cgtqmx6qeval_defconfig
index 6699381..2f83808 100644
--- a/configs/cgtqmx6qeval_defconfig
+++ b/configs/cgtqmx6qeval_defconfig
@@ -1,3 +1,3 @@
-CONFIG_SYS_EXTRA_OPTIONS=IMX_CONFIG=board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg,MX6Q
+CONFIG_SYS_EXTRA_OPTIONS=IMX_CONFIG=board/freescale/mx6sabresd/mx6q_4x_mt41j128.cfg,MX6Q
CONFIG_ARM=y
CONFIG_TARGET_CGTQMX6EVAL=y
diff --git a/configs/mx6qsabresd_defconfig b/configs/mx6qsabresd_defconfig
index dc8e254..67c1b77 100644
--- a/configs/mx6qsabresd_defconfig
+++ b/configs/mx6qsabresd_defconfig
@@ -1,3 +1,3 @@
-CONFIG_SYS_EXTRA_OPTIONS=IMX_CONFIG=board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg,MX6Q
+CONFIG_SYS_EXTRA_OPTIONS=IMX_CONFIG=board/freescale/mx6sabresd/mx6q_4x_mt41j128.cfg,MX6Q
CONFIG_ARM=y
CONFIG_TARGET_MX6SABRESD=y
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] imx: ddr: Move mx6q_4x_mt41j128.cfg to mx6sabresd board dir
On Mon, Sep 1, 2014 at 11:20 AM, Nitin Garg nitin.g...@freescale.com wrote: Move board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg to board/freescale/mx6sabresd/mx6q_4x_mt41j128.cfg as this is was designed for the mx6sabresd board. This also updates the cgtqmx6qeval which makes use of this configuration. Signed-off-by: Nitin Garg nitin.g...@freescale.com Acked-by: Fabio Estevam fabio.este...@freescale.com Thanks ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] imx: ddr: Move mx6q_4x_mt41j128.cfg to mx6sabresd board dir
On Mon, Sep 1, 2014 at 11:24 AM, Fabio Estevam feste...@gmail.com wrote: On Mon, Sep 1, 2014 at 11:20 AM, Nitin Garg nitin.g...@freescale.com wrote: Move board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg to board/freescale/mx6sabresd/mx6q_4x_mt41j128.cfg as this is was designed for the mx6sabresd board. This also updates the cgtqmx6qeval which makes use of this configuration. Signed-off-by: Nitin Garg nitin.g...@freescale.com Acked-by: Fabio Estevam fabio.este...@freescale.com Acked-by: Otavio Salvador ota...@ossystems.com.br -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] imx: ddr: Move mx6q_4x_mt41j128.cfg to mx6sabresd board dir
Dear Nitin Garg, In message 1409581243-12695-1-git-send-email-nitin.g...@freescale.com you wrote: Move board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg to board/freescale/mx6sabresd/mx6q_4x_mt41j128.cfg as this is was designed for the mx6sabresd board. This also updates the cgtqmx6qeval which makes use of this configuration. Sorry, but I don't get it. First you say, that mx6q_4x_mt41j128.cfg is a mx6sabresd specific file, and move it to the board specific directory. But in the next sentence you state that this very file is also used by another board (cgtqmx6qeval) - so apparently it is NOT a board specific file. Actually this makes even more sense to me, as I would expect that the file is more specific to the DDR type than to the board. So why exactly do you think it would be better to move this into a board specific place? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I am more bored than you could ever possibly be. Go back to work. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] imx: ddr: Move mx6q_4x_mt41j128.cfg to mx6sabresd board dir
Wolfgang, (Dropping Leo e-mail as it bounces, adding Alex who seem to be working on BSP support at Congatec now) On Mon, Sep 1, 2014 at 2:59 PM, Wolfgang Denk w...@denx.de wrote: In message 1409581243-12695-1-git-send-email-nitin.g...@freescale.com you wrote: Move board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg to board/freescale/mx6sabresd/mx6q_4x_mt41j128.cfg as this is was designed for the mx6sabresd board. This also updates the cgtqmx6qeval which makes use of this configuration. Sorry, but I don't get it. First you say, that mx6q_4x_mt41j128.cfg is a mx6sabresd specific file, and move it to the board specific directory. But in the next sentence you state that this very file is also used by another board (cgtqmx6qeval) - so apparently it is NOT a board specific file. Actually this makes even more sense to me, as I would expect that the file is more specific to the DDR type than to the board. So why exactly do you think it would be better to move this into a board specific place? All the calibration has been done by Freescale and for the SABRE SD board. This is not guarantee it works in other boards, neither expected. Congatec opted to include this file but it is their choice and moving to the board file makes it more evident. Some vendors choose to reuse other vendors provided memory configuration (this has been done in some board using Nitrogen6X values for example). If this is good or bad ... this is a hard question to answer. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/8] ARMv8: PSCI: Fixup the device tree for PSCI v0.2
Hi,
diff --git a/arch/arm/cpu/armv8/cpu-dt.c b/arch/arm/cpu/armv8/cpu-dt.c
index 9792bc0..c2c8fe7 100644
--- a/arch/arm/cpu/armv8/cpu-dt.c
+++ b/arch/arm/cpu/armv8/cpu-dt.c
@@ -9,7 +9,69 @@
#include fdt_support.h
#ifdef CONFIG_MP
+#ifdef CONFIG_ARMV8_PSCI
+static void psci_reserve_mem(void *fdt)
+{
+#ifndef CONFIG_ARMV8_SECURE_BASE
+ /* secure code lives in RAM, keep it alive */
+ fdt_add_mem_rsv(fdt, (unsigned long)__secure_start,
+ __secure_end - __secure_start);
+#endif
+}
With PSCI I'd be worried about telling the OS about this memory at all.
If the OS maps the memory we could encounter issues with mismatched
aliases and/or unexpected hits in the D-cache, which can result in a
loss of ordering and/or visbility guarantees, which could break the PSCI
implementation.
With the KVM or trusted firmware PSCI implementations the (guest) OS
cannot map the implementation's memory, preventing such problems. The
arm64 Linux boot-wrapper is dodgy in this regard currently.
The idea here is that if there is no PSCI specific (most likely secure)
memory allocated in the system, the macro CONFIG_ARMV8_SECURE_BASE
will not be defined. In this case the PSCI vector table and its support
code will be in DDR and will be protected from Linux using memreserve.
Sure, this will prevent the OS from explicitly modifying this memory.
However, the OS will still map the memory. This renders the protection
incomplete due to the possibility of mismatched attributes and/or
unexpected cache hits resulting in nasty coherency problems. We are
likely to get away with this most of the time (if the kernel and U-Boot
use the same attributes), but it would be very easy to blow things up
accidentally.
The only way to prevent that is to completely remove a portion of the
memory from the view of the OS, such that it doesn't map the memory at
all.
If this macro is defined the assumption is that it points to some
non-ddr location, say secure OCRAM. In this case U-Boot will copy the
PSCI vector table and its support code to that region and we are hoping
that this address space is not visible to the OS in the first place.
This makes sense, but was not the issue I was referring to.
This is my understanding of the code, maybe Marc would like to comment
on if this was the thinking in ARMv7.
If we're doing this on ARMv7 then it is dodgy there too.
Marc, thoughts?
[...]
+ }
+
+ nodeoff = fdt_path_offset(fdt, /psci);
We might need to search by compatible string. All psci nodes so far have
been called /psci, but that's not guaranteed. Linux looks for nodes
compatible with arm,psci and/or arm,psci-0.2.
I see that it is called Main node in the kernel documentation. Any
reason it's name has not been fixed to psci? Is it too late to do that
and save myself some work here? :)
Unfortunately the canonical way to find the PSCI node is by compatible
string, and that's what Linux does. While we might be able to ensure all
in-tree dts follow this convention, it's not something that should be
relied upon.
Sorry :(
Cheers,
Mark.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: nitrogen6x: Replace 'fatload' by 'load' command in env settings to be filesystem independent
Hi all,
On 08/31/2014 07:24 PM, Fabio Estevam wrote:
On Tue, Aug 26, 2014 at 7:05 AM, Guillaume GARDET
guillaume.gar...@free.fr wrote:
nitrogen6x.h file defines CONFIG_CMD_FS_GENERIC, so we are able to use
generic
'load' command instead of 'fatload'. It allows to use ext filesystem and keep
compatibilty with fat filesystem.
Signed-off-by: Guillaume GARDET guillaume.gar...@free.fr
Cc: Stefano Babic sba...@denx.de
Adding Eric Nelson on Cc.
Thanks Fabio. I stopped delivery from the list while on vacation and
hadn't re-started it.
---
include/configs/nitrogen6x.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h
index b2b17ce..d4b0ac9 100644
--- a/include/configs/nitrogen6x.h
+++ b/include/configs/nitrogen6x.h
@@ -192,11 +192,11 @@
I've been wondering if anyone was using this section of nitrogen6x.h,
and I guess this answers the question.
mmcargs=setenv bootargs console=${console},${baudrate} \
root=${mmcroot}\0 \
loadbootscript= \
- fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0 \
+ load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0 \
bootscript=echo Running bootscript from mmc ...; \
source\0 \
- loaduimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr}
${uimage}\0 \
- loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0
\
+ loaduimage=load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}\0 \
+ loadfdt=load mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0 \
mmcboot=echo Booting from mmc ...; \
run mmcargs; \
if test ${boot_fdt} = yes || test ${boot_fdt} = try; then
\
--
1.8.4.5
I don't have a copy of the original e-mail, but:
Acked-By: Eric Nelson eric.nel...@boundarydevices.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] imx: ddr: Move mx6q_4x_mt41j128.cfg to mx6sabresd board dir
Dear Otavio, In message CAP9ODKonaZ9v76WAdd4k7or_kUWF=attlf+-drqgqyvgkbt...@mail.gmail.com you wrote: But in the next sentence you state that this very file is also used by another board (cgtqmx6qeval) - so apparently it is NOT a board specific file. Actually this makes even more sense to me, as I would expect that the file is more specific to the DDR type than to the board. So why exactly do you think it would be better to move this into a board specific place? All the calibration has been done by Freescale and for the SABRE SD board. This is not guarantee it works in other boards, neither expected. Congatec opted to include this file but it is their choice and moving to the board file makes it more evident. This may be all true, but nevertheless this is NOT board specific code. And you can already see it being reused by other boards, so the most natural way to handle it is to factor it out into a common directory. And actually this is what we had before. If we are going to change code, we should have a good reason for such a change, like fixing bugs, adding features, or cleaning up. What exactly is that good reason here? Moving code used by more than one board from a common place to a board-specific one make things worse, not better. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Until you walk a mile in another man's moccasins, you can't imagine the smell. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] imx: ddr: Move mx6q_4x_mt41j128.cfg to mx6sabresd board dir
Hi Il 01/set/2014 21:02 Wolfgang Denk w...@denx.de ha scritto: Dear Otavio, In message CAP9ODKonaZ9v76WAdd4k7or_kUWF= attlf+-drqgqyvgkbt...@mail.gmail.com you wrote: But in the next sentence you state that this very file is also used by another board (cgtqmx6qeval) - so apparently it is NOT a board specific file. Actually this makes even more sense to me, as I would expect that the file is more specific to the DDR type than to the board. So why exactly do you think it would be better to move this into a board specific place? All the calibration has been done by Freescale and for the SABRE SD board. This is not guarantee it works in other boards, neither expected. Congatec opted to include this file but it is their choice and moving to the board file makes it more evident. This may be all true, but nevertheless this is NOT board specific code. And you can already see it being reused by other boards, so the most natural way to handle it is to factor it out into a common directory. And actually this is what we had before. If we are going to change code, we should have a good reason for such a change, like fixing bugs, adding features, or cleaning up. What exactly is that good reason here? Moving code used by more than one board from a common place to a board-specific one make things worse, not better. Agree with Walfgang Michael Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Until you walk a mile in another man's moccasins, you can't imagine the smell. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] imx: ddr: Move mx6q_4x_mt41j128.cfg to mx6sabresd board dir
Wolfgang, On Mon, Sep 1, 2014 at 4:02 PM, Wolfgang Denk w...@denx.de wrote: In message CAP9ODKonaZ9v76WAdd4k7or_kUWF=attlf+-drqgqyvgkbt...@mail.gmail.com you wrote: But in the next sentence you state that this very file is also used by another board (cgtqmx6qeval) - so apparently it is NOT a board specific file. Actually this makes even more sense to me, as I would expect that the file is more specific to the DDR type than to the board. So why exactly do you think it would be better to move this into a board specific place? All the calibration has been done by Freescale and for the SABRE SD board. This is not guarantee it works in other boards, neither expected. Congatec opted to include this file but it is their choice and moving to the board file makes it more evident. This may be all true, but nevertheless this is NOT board specific code. And you can already see it being reused by other boards, so the most natural way to handle it is to factor it out into a common directory. And actually this is what we had before. If we are going to change code, we should have a good reason for such a change, like fixing bugs, adding features, or cleaning up. What exactly is that good reason here? Moving code used by more than one board from a common place to a board-specific one make things worse, not better. I disagree (but this is my personal view on this). The reason why I disagree is because the DDR calibration is very design dependant so if/when Freescale optimize their DDR data setting they may break any other board using it however they shouldn't be blamed by it as this is their DDR settings. Any board including this file (which can be and is done) takes the responsibility and risks. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] imx: ddr: Move mx6q_4x_mt41j128.cfg to mx6sabresd board dir
Dear Otavio, In message cap9odkrsc4o-p7+cmkkbeda8wwwxvpnpxoyoctp6wcvoj5g...@mail.gmail.com you wrote: I disagree (but this is my personal view on this). The reason why I disagree is because the DDR calibration is very design dependant so if/when Freescale optimize their DDR data setting they may break any other board using it however they shouldn't be blamed by it as this is their DDR settings. Any board including this file (which can be and is done) takes the responsibility and risks. Obviously, any changes to common code used by several boards needs to be tested on the affected boards. Also, it might be instructive for you to read the commit message for af7ec0b mx6q: Factor out common DDR3 init code. Apparently Fabio considers this common DDR3 initialization code, so what exactly are your arguments to the contrary? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de To be is to program. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] imx: ddr: Move mx6q_4x_mt41j128.cfg to mx6sabresd board dir
Dear Nitin Garg, In message 1409581243-12695-1-git-send-email-nitin.g...@freescale.com you wrote: Move board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg to board/freescale/mx6sabresd/mx6q_4x_mt41j128.cfg as this is was designed for the mx6sabresd board. This also updates the cgtqmx6qeval which makes use of this configuration. I've made my mind up. I hereby NAK this patch, as it would basically revert Fabio Estevam's commit af7ec0b which moved the originally board-specific code to a common place: commit af7ec0b0582f658873713c311497626c571f3b31 Author: Fabio Estevam fabio.este...@freescale.com Date: Thu Sep 13 03:18:19 2012 + mx6q: Factor out common DDR3 init code Factor out common DDR3 initialization code, allowing easier maintainance of such scripts. Signed-off-by: Fabio Estevam fabio.este...@freescale.com Fabio's intention was a good one, as is proven by the re-use of this code by other boards. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Once they go up, who cares where they come down? That's not my department. - Werner von Braun ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/8] xtensa: add support for the xtensa processor architecture [2/2]
Hi Simon, On Mon, Sep 1, 2014 at 9:02 AM, Simon Glass s...@chromium.org wrote: Hi Max, On 20 August 2014 10:42, Max Filippov jcmvb...@gmail.com wrote: From: Chris Zankel ch...@zankel.net The Xtensa processor architecture is a configurable, extensible, and synthesizable 32-bit RISC processor core provided by Tensilica, inc. This is the second part of the basic architecture port, adding the 'arch/xtensa' directory and a readme file. Signed-off-by: Chris Zankel ch...@zankel.net Signed-off-by: Max Filippov jcmvb...@gmail.com --- arch/Kconfig | 4 + arch/xtensa/Kconfig | 26 ++ arch/xtensa/config.mk | 13 + arch/xtensa/cpu/.gitignore| 1 + arch/xtensa/cpu/Makefile | 13 + arch/xtensa/cpu/config.mk | 9 + arch/xtensa/cpu/cpu.c | 84 + arch/xtensa/cpu/exceptions.c | 67 arch/xtensa/cpu/start.S | 672 ++ arch/xtensa/cpu/u-boot.lds.S | 107 ++ arch/xtensa/include/asm/addrspace.h | 43 +++ arch/xtensa/include/asm/asmmacro.h| 136 +++ arch/xtensa/include/asm/bitops.h | 14 + arch/xtensa/include/asm/bootparam.h | 54 +++ arch/xtensa/include/asm/byteorder.h | 81 arch/xtensa/include/asm/cache.h | 20 + arch/xtensa/include/asm/cacheasm.h| 187 ++ arch/xtensa/include/asm/config.h | 17 + arch/xtensa/include/asm/errno.h | 1 + arch/xtensa/include/asm/global_data.h | 24 ++ arch/xtensa/include/asm/io.h | 148 arch/xtensa/include/asm/ldscript.h| 220 +++ arch/xtensa/include/asm/linkage.h | 4 + arch/xtensa/include/asm/misc.h| 24 ++ arch/xtensa/include/asm/posix_types.h | 74 arch/xtensa/include/asm/processor.h | 11 + arch/xtensa/include/asm/ptrace.h | 133 +++ arch/xtensa/include/asm/regs.h| 95 + arch/xtensa/include/asm/sections.h| 15 + arch/xtensa/include/asm/string.h | 10 + arch/xtensa/include/asm/types.h | 60 +++ arch/xtensa/include/asm/u-boot.h | 43 +++ arch/xtensa/include/asm/unaligned.h | 6 + arch/xtensa/include/asm/xtensa.h | 36 ++ arch/xtensa/lib/Makefile | 9 + arch/xtensa/lib/board.c | 173 + arch/xtensa/lib/bootm.c | 202 ++ arch/xtensa/lib/misc.S| 178 + arch/xtensa/lib/time.c| 111 ++ 39 files changed, 3125 insertions(+) create mode 100644 arch/xtensa/Kconfig create mode 100644 arch/xtensa/config.mk create mode 100644 arch/xtensa/cpu/.gitignore create mode 100644 arch/xtensa/cpu/Makefile create mode 100644 arch/xtensa/cpu/config.mk create mode 100644 arch/xtensa/cpu/cpu.c create mode 100644 arch/xtensa/cpu/exceptions.c create mode 100644 arch/xtensa/cpu/start.S create mode 100644 arch/xtensa/cpu/u-boot.lds.S create mode 100644 arch/xtensa/include/asm/addrspace.h create mode 100644 arch/xtensa/include/asm/asmmacro.h create mode 100644 arch/xtensa/include/asm/bitops.h create mode 100644 arch/xtensa/include/asm/bootparam.h create mode 100644 arch/xtensa/include/asm/byteorder.h create mode 100644 arch/xtensa/include/asm/cache.h create mode 100644 arch/xtensa/include/asm/cacheasm.h create mode 100644 arch/xtensa/include/asm/config.h create mode 100644 arch/xtensa/include/asm/errno.h create mode 100644 arch/xtensa/include/asm/global_data.h create mode 100644 arch/xtensa/include/asm/io.h create mode 100644 arch/xtensa/include/asm/ldscript.h create mode 100644 arch/xtensa/include/asm/linkage.h create mode 100644 arch/xtensa/include/asm/misc.h create mode 100644 arch/xtensa/include/asm/posix_types.h create mode 100644 arch/xtensa/include/asm/processor.h create mode 100644 arch/xtensa/include/asm/ptrace.h create mode 100644 arch/xtensa/include/asm/regs.h create mode 100644 arch/xtensa/include/asm/sections.h create mode 100644 arch/xtensa/include/asm/string.h create mode 100644 arch/xtensa/include/asm/types.h create mode 100644 arch/xtensa/include/asm/u-boot.h create mode 100644 arch/xtensa/include/asm/unaligned.h create mode 100644 arch/xtensa/include/asm/xtensa.h create mode 100644 arch/xtensa/lib/Makefile create mode 100644 arch/xtensa/lib/board.c create mode 100644 arch/xtensa/lib/bootm.c create mode 100644 arch/xtensa/lib/misc.S create mode 100644 arch/xtensa/lib/time.c This all looks quite tidy, from a brief look. Thanks for your feedback. But please make sure you use generic board - CONFIG_SYS_GENERIC_BOARD. You should not need a board.c file. Will fix. Also for your do_bootm_linux() implementation, see if you can check the flags, and thus support the bootm sub-commands. Ok. If you have a microsecond timer, you could implement timer_get_us(). Ok, will add. -- Thanks. -- Max
Re: [U-Boot] [PATCH] mpc5xxx: Add stub implementation of cache functions
Dear Vasili Galka, In message 1409051131-7260-1-git-send-email-vvv...@gmail.com you wrote: Some drivers (e.g. net/e1000) reference these functions. So, this fixes the build of MVBC_P board. I'm not familiar with the MPC5xxx platform, maybe a full implementation shall be implemented instead of this stub in the future. Signed-off-by: Vasili Galka vvv...@gmail.com Cc: Wolfgang Denk w...@denx.de, Marek Vasut ma...@denx.de --- arch/powerpc/cpu/mpc5xxx/Makefile |1 + arch/powerpc/cpu/mpc5xxx/cache.c | 15 +++ 2 files changed, 16 insertions(+), 0 deletions(-) create mode 100644 arch/powerpc/cpu/mpc5xxx/cache.c Acked-by: Wolfgang Denk w...@denx.de Tom, can you please pick this up directly? Thanks! Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The number of Unix installations has grown to 10, with more expected.- The Unix Programmer's Manual, 2nd Edition, June, 1972 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot] [Patch] mtd: nand: davinci_nand: correct keystone RBL layout definition
In case when 4K page keystone RBL layout is used the compilation
error is appeared. That's because the #ifdef has to be placed under
struct name. This patch correct it.
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
---
Based on [U-boot] [Patch] keystone: usb: add support of usb xhci
https://patchwork.ozlabs.org/patch/384012/
drivers/mtd/nand/davinci_nand.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index a079b1e..02a1130 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -306,8 +306,8 @@ static struct nand_ecclayout
nand_davinci_4bit_layout_oobfirst = {
};
#if defined CONFIG_KEYSTONE_RBL_NAND
-#if defined(CONFIG_SYS_NAND_PAGE_2K)
static struct nand_ecclayout nand_keystone_rbl_4bit_layout_oobfirst = {
+#if defined(CONFIG_SYS_NAND_PAGE_2K)
.eccbytes = 40,
.eccpos = {
6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] imx: ddr: Move mx6q_4x_mt41j128.cfg to mx6sabresd board dir
Hi Wolfgang, On Mon, Sep 1, 2014 at 4:24 PM, Wolfgang Denk w...@denx.de wrote: Dear Nitin Garg, In message 1409581243-12695-1-git-send-email-nitin.g...@freescale.com you wrote: Move board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg to board/freescale/mx6sabresd/mx6q_4x_mt41j128.cfg as this is was designed for the mx6sabresd board. This also updates the cgtqmx6qeval which makes use of this configuration. I've made my mind up. I hereby NAK this patch, as it would basically revert Fabio Estevam's commit af7ec0b which moved the originally board-specific code to a common place: commit af7ec0b0582f658873713c311497626c571f3b31 Author: Fabio Estevam fabio.este...@freescale.com Date: Thu Sep 13 03:18:19 2012 + mx6q: Factor out common DDR3 init code Factor out common DDR3 initialization code, allowing easier maintainance of such scripts. Signed-off-by: Fabio Estevam fabio.este...@freescale.com Fabio's intention was a good one, as is proven by the re-use of this code by other boards. Let me provide some background on the reason I sent that patch: at that time we had the same DDR3 init code for several boards, such as mx6qsabresd, nitrogen, sabrelite, so I wanted to avoid duplicating the same init for several boards. After sometime, each board used to followed its own specific settings, as the DDR3 init is very dependant on board layout and some optimizations that are valid for one board does not apply to others. Each board developer has to be really careful about properly configuring DDR in order to achieve stability, so re-use of the DCD settings should be done really carefully. As it stands today only mx6qsabresd and congatec share the same script. I think Nitin's patch goes in the right direction, as it makes clearer for other developers that the DDR specific settings are optmized for mx6qsabresd only. Of course people can re-use it, like congatec board does today, but if in the future we find some more optimal settings for this board we should apply it to mx6sabresd, but we really don't know the consequences into other hardware. So they have been warned :-) Moving forward we should really get rid of this DCD syntax and move to SPL style. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2 v3] Add support for mx6 onchip temperature sensor
From: Nitin Garg nitin.g...@freescale.com Add support for mx6 onchip temperature sensor and enable it for all mx6sabre boards. Nitin Garg (2): Changes since v2: - Split the patch into 2: Feature impl and board enablement Changes since v1: - Make temperature sensor feature configurable - Checkpatch fixes Add i.MX6 CPU temperature sensor support Enable SoC Temperature sensor for mx6 Sabre boards. arch/arm/cpu/armv7/mx6/soc.c | 138 +++- arch/arm/imx-common/cpu.c|7 +- arch/arm/include/asm/arch-mx6/crm_regs.h | 543 +- arch/arm/include/asm/arch-mx6/imx-regs.h |9 +- include/configs/mx6sabre_common.h|1 + 5 files changed, 694 insertions(+), 4 deletions(-) -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2 v3] Enable SoC Temperature sensor for mx6 Sabre boards.
From: Nitin Garg nitin.g...@freescale.com Add CONFIG_IMX6_TEMP_SENSOR to mx6sabre_common.h file Signed-off-by: Nitin Garg nitin.g...@freescale.com --- include/configs/mx6sabre_common.h |1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/mx6sabre_common.h b/include/configs/mx6sabre_common.h index e59a3b4..fc38ede 100644 --- a/include/configs/mx6sabre_common.h +++ b/include/configs/mx6sabre_common.h @@ -33,6 +33,7 @@ #define CONFIG_BOARD_EARLY_INIT_F #define CONFIG_BOARD_LATE_INIT #define CONFIG_MXC_GPIO +#define CONFIG_IMX6_TEMP_SENSOR #define CONFIG_MXC_UART -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2 v3] Add i.MX6 CPU temperature sensor support
From: Nitin Garg nitin.g...@freescale.com
i.MX6 SoC has onChip temperature sensor. Add support
for this sensor.
Signed-off-by: Nitin Garg nitin.g...@freescale.com
---
arch/arm/cpu/armv7/mx6/soc.c | 138 +++-
arch/arm/imx-common/cpu.c|7 +-
arch/arm/include/asm/arch-mx6/crm_regs.h | 543 +-
arch/arm/include/asm/arch-mx6/imx-regs.h |9 +-
4 files changed, 693 insertions(+), 4 deletions(-)
diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
index ac84a1f..b0c1306 100644
--- a/arch/arm/cpu/armv7/mx6/soc.c
+++ b/arch/arm/cpu/armv7/mx6/soc.c
@@ -2,7 +2,7 @@
* (C) Copyright 2007
* Sascha Hauer, Pengutronix
*
- * (C) Copyright 2009 Freescale Semiconductor, Inc.
+ * (C) Copyright 2009-2014 Freescale Semiconductor, Inc.
*
* SPDX-License-Identifier:GPL-2.0+
*/
@@ -35,6 +35,16 @@ struct scu_regs {
u32 fpga_rev;
};
+#define TEMPERATURE_MIN-40
+#define TEMPERATURE_HOT80
+#define TEMPERATURE_MAX125
+#define FACTOR115976
+#define FACTOR24297157
+#define MEASURE_FREQ 327
+
+#define REG_VALUE_TO_CEL(ratio, raw) \
+ ((raw_n40c - raw) * 100 / ratio - 40)
+
u32 get_nr_cpus(void)
{
struct scu_regs *scu = (struct scu_regs *)SCU_BASE_ADDR;
@@ -218,6 +228,132 @@ static void imx_set_wdog_powerdown(bool enable)
writew(enable, wdog2-wmcr);
}
+#ifdef CONFIG_IMX6_TEMP_SENSOR
+static int read_cpu_temperature(u32 *fuse)
+{
+ int temperature;
+ unsigned int ccm_ccgr2;
+ unsigned int reg, tmp;
+ unsigned int raw_25c, raw_n40c, ratio;
+ struct anatop_regs *anatop = (struct anatop_regs *)ANATOP_BASE_ADDR;
+ struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
+ struct ocotp_regs *ocotp = (struct ocotp_regs *)OCOTP_BASE_ADDR;
+ struct fuse_bank *bank = ocotp-bank[1];
+ struct fuse_bank1_regs *fuse_bank1 =
+ (struct fuse_bank1_regs *)bank-fuse_regs;
+
+ /* need to make sure pll3 is enabled for thermal sensor */
+ if ((readl(anatop-usb1_pll_480_ctrl)
+ BM_ANADIG_USB1_PLL_480_CTRL_LOCK) == 0) {
+ /* enable pll's power */
+ writel(BM_ANADIG_USB1_PLL_480_CTRL_POWER,
+ anatop-usb1_pll_480_ctrl_set);
+ writel(0x80, anatop-ana_misc2_clr);
+ /* wait for pll lock */
+ while ((readl(anatop-usb1_pll_480_ctrl)
+ BM_ANADIG_USB1_PLL_480_CTRL_LOCK) == 0)
+ ;
+ /* disable bypass */
+ writel(BM_ANADIG_USB1_PLL_480_CTRL_BYPASS,
+ anatop-usb1_pll_480_ctrl_clr);
+ /* enable pll output */
+ writel(BM_ANADIG_USB1_PLL_480_CTRL_ENABLE,
+ anatop-usb1_pll_480_ctrl_set);
+ }
+
+ ccm_ccgr2 = readl(mxc_ccm-CCGR2);
+ /* enable OCOTP_CTRL clock in CCGR2 */
+ writel(ccm_ccgr2 | MXC_CCM_CCGR2_OCOTP_CTRL_MASK, mxc_ccm-CCGR2);
+ *fuse = readl(fuse_bank1-ana1);
+
+ /* restore CCGR2 */
+ writel(ccm_ccgr2, mxc_ccm-CCGR2);
+
+ if (*fuse == 0 || *fuse == 0x || (*fuse 0xfff0) == 0)
+ return TEMPERATURE_MIN;
+
+ /*
+* fuse data layout:
+* [31:20] sensor value @ 25C
+* [19:8] sensor value of hot
+* [7:0] hot temperature value
+*/
+ raw_25c = *fuse 20;
+
+ /*
+* The universal equation for thermal sensor
+* is slope = 0.4297157 - (0.0015976 * 25C fuse),
+* here we convert them to integer to make them
+* easy for counting, FACTOR1 is 15976,
+* FACTOR2 is 4297157. Our ratio = -100 * slope
+*/
+ ratio = ((FACTOR1 * raw_25c - FACTOR2) + 5) / 10;
+
+ debug(Thermal sensor with ratio = %d\n, ratio);
+
+ raw_n40c = raw_25c + (13 * ratio) / 20;
+
+ /*
+* now we only use single measure, every time we read
+* the temperature, we will power on/down anadig thermal
+* module
+*/
+ writel(BM_ANADIG_TEMPSENSE0_POWER_DOWN, anatop-tempsense0_clr);
+ writel(BM_ANADIG_ANA_MISC0_REFTOP_SELBIASOFF, anatop-ana_misc0_set);
+
+ /* write measure freq */
+ reg = readl(anatop-tempsense1);
+ reg = ~BM_ANADIG_TEMPSENSE1_MEASURE_FREQ;
+ reg |= MEASURE_FREQ;
+ writel(reg, anatop-tempsense1);
+
+ writel(BM_ANADIG_TEMPSENSE0_MEASURE_TEMP, anatop-tempsense0_clr);
+ writel(BM_ANADIG_TEMPSENSE0_FINISHED, anatop-tempsense0_clr);
+ writel(BM_ANADIG_TEMPSENSE0_MEASURE_TEMP, anatop-tempsense0_set);
+
+ while ((readl(anatop-tempsense0)
+ BM_ANADIG_TEMPSENSE0_FINISHED) == 0)
+ udelay(1);
+
+ reg = readl(anatop-tempsense0);
+ tmp = (reg
Re: [U-Boot] [PATCH v2] imx: ddr: Move mx6q_4x_mt41j128.cfg to mx6sabresd board dir
Hi Fabio, On 09/01/2014 03:27 PM, Fabio Estevam wrote: Hi Wolfgang, On Mon, Sep 1, 2014 at 4:24 PM, Wolfgang Denk w...@denx.de wrote: Dear Nitin Garg, In message 1409581243-12695-1-git-send-email-nitin.g...@freescale.com you wrote: Move board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg to board/freescale/mx6sabresd/mx6q_4x_mt41j128.cfg as this is was designed for the mx6sabresd board. This also updates the cgtqmx6qeval which makes use of this configuration. I've made my mind up. I hereby NAK this patch, as it would basically revert Fabio Estevam's commit af7ec0b which moved the originally board-specific code to a common place: commit af7ec0b0582f658873713c311497626c571f3b31 Author: Fabio Estevam fabio.este...@freescale.com Date: Thu Sep 13 03:18:19 2012 + mx6q: Factor out common DDR3 init code Factor out common DDR3 initialization code, allowing easier maintainance of such scripts. Signed-off-by: Fabio Estevam fabio.este...@freescale.com Fabio's intention was a good one, as is proven by the re-use of this code by other boards. Let me provide some background on the reason I sent that patch: at that time we had the same DDR3 init code for several boards, such as mx6qsabresd, nitrogen, sabrelite, so I wanted to avoid duplicating the same init for several boards. Specifically, the Nitrogen and SABRE Lite designs use a different memory layout from SABRE SD and SABRE Auto and the DDR calibration data is quite different. Boards may share the same memory arrangement, but it's unlikely that the calibration process has been performed on multiple board types and achieved the same values. It's possible that many boards copied the layout and stack-up from the SABRE SD design such that the board functions properly with the SABRE SD values, but also likely that some vendors just don't know that their calibration results will differ. After sometime, each board used to followed its own specific settings, as the DDR3 init is very dependant on board layout and some optimizations that are valid for one board does not apply to others. Each board developer has to be really careful about properly configuring DDR in order to achieve stability, so re-use of the DCD settings should be done really carefully. Note that mx6q_4x_mt41j128.cfg combines multiple things in the same config file. Separating them (especially the calibration data) as done in the nitrogen6x/ tree will help distinguish between the design-time parts of the configuration and the measured calibration. As it stands today only mx6qsabresd and congatec share the same script. I believe that the Wand board is using the configuration files from the nitrogen6x tree. I think Nitin's patch goes in the right direction, as it makes clearer for other developers that the DDR specific settings are optmized for mx6qsabresd only. Of course people can re-use it, like congatec board does today, but if in the future we find some more optimal settings for this board we should apply it to mx6sabresd, but we really don't know the consequences into other hardware. So they have been warned :-) Moving forward we should really get rid of this DCD syntax and move to SPL style. There's no way to completely get rid of the DCD. It may be possible (even beneficial) to do run-time DDR calibration, but that's off-topic in this thread. Regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] imx: ddr: Move mx6q_4x_mt41j128.cfg to mx6sabresd board dir
On Mon, Sep 1, 2014 at 8:34 PM, Eric Nelson eric.nel...@boundarydevices.com wrote: I believe that the Wand board is using the configuration files from the nitrogen6x tree. Yes, I should have said As it stands today only mx6qsabresd and congatec share the same mx6q_4x_mt41j128.cfg script. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-dm.git
Hi Tom, I have to leave off the exynos and tegra patches while I wait for feedback. But here are some GPIO enhancements that might as well go in. Next will be serial, but it needs a rev first. Should be in the next few days. The following changes since commit a1263632bb05f0a21620bad0661235fcbbe79dca: mx6: tqma6: get board support back to Kconfig build system (2014-08-31 12:01:04 -0400) are available in the git repository at: git://git.denx.de/u-boot-dm.git for you to fetch changes up to 4bc9a19324ba27eb867316d2ea0d55bba95e8724: dm: sandbox: dts: Add a GPIO bank (2014-08-31 23:21:42 -0600) Simon Glass (3): dm: gpio: Enhance gpio command to show only active GPIOs dm: gpio: Allow gpio command to adjust GPIOs that are busy dm: sandbox: dts: Add a GPIO bank arch/sandbox/dts/sandbox.dts | 8 + common/cmd_gpio.c| 110 ++-- include/asm-generic/gpio.h | 15 -- 3 files changed, 96 insertions(+), 37 deletions(-) Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v9 11/14] buildman: Add an option to show which boards caused which errors
Hi Tom, On 1 September 2014 04:23, Tom Rini tr...@ti.com wrote: On Sun, Aug 31, 2014 at 10:09:44PM -0700, Simon Glass wrote: Hi Tom, On 28 August 2014 05:51, Tom Rini tr...@ti.com wrote: On Tue, Aug 26, 2014 at 08:59:52PM -0600, Simon Glass wrote: Hi Tom, On 25 August 2014 13:14, Tom Rini tr...@ti.com wrote: On Mon, Aug 25, 2014 at 09:58:32AM -0600, Simon Glass wrote: Add a -l option to display a list of offending boards against each error/warning line. The information will be shown in brackets as below: 02: wip sandbox: + sandbox arm: + seaboard +(sandbox) arch/sandbox/cpu/cpu.c: In function 'timer_get_us': +(sandbox) arch/sandbox/cpu/cpu.c:40:9: warning: unused variable 'i' [-Wunused-variable] +(seaboard) board/nvidia/seaboard/seaboard.c: In function 'pin_mux_mmc': +(seaboard) board/nvidia/seaboard/seaboard.c:36:9: warning: unused variable 'fred' [-Wunused-variable] +(seaboard) int fred; +(seaboard) ^ Signed-off-by: Simon Glass s...@chromium.org Doing buildman ... ; buildman ... -svl (since I want to spit out the summary at once due to how LSF mangles output to file), I don't see What is -s? summary. anything for what caused powerpc failures say (where there's lot of things complaining about generic board). So something isn't right, is this something you can reproduce locally? I'm going to make sure that -e really is implied like the doc says. Thanks! ./tools/buildman/buildman -vl sandbox Building current source for 1 boards (1 thread, 4 jobs per thread) sandbox: + sandbox +(sandbox) arch/sandbox/cpu/cpu.c: In function ‘__udelay’: +(sandbox) arch/sandbox/cpu/cpu.c:36:5: error: unknown type name ‘oijew’ +(sandbox) arch/sandbox/cpu/cpu.c:37:2: error: conflicting types for ‘os_usleep’ +(sandbox) include/os.h:155:6: note: previous declaration of ‘os_usleep’ was here +(sandbox) make[2]: *** [arch/sandbox/cpu/cpu.o] Error 1 +(sandbox) make[1]: *** [arch/sandbox/cpu] Error 2 +(sandbox) make: *** [sub-make] Error 2 w+(sandbox) arch/sandbox/cpu/cpu.c: In function ‘do_reset’: w+(sandbox) arch/sandbox/cpu/cpu.c:27:13: warning: unused variable ‘i’ [-Wunused-variable] w+(sandbox) arch/sandbox/cpu/cpu.c:37:2: warning: parameter names (without types) in function declaration [enabled by default] 001 /1 sandbox This shows warnings and errors, and -e is implied (but note you should test with both series - I pushed 'buildman5' to u-boot-x86.git just in case you only have one). I might be able to repeat your problem, except for the LSF part. What command line are you using? I do: ./tools/buildman/buildman -b master -c 1 -T 1 -j 24 \ -o /tmp/trini/eldk521 -G ~/.buildman.eldk521 'arm|powerpc' ./tools/buildman/buildman -b master -c 1 -T 1 -j 24 \ -o /tmp/trini/eldk521 -G ~/.buildman.eldk521 'arm|powerpc' -svel Doing '-svl' would omit the information I expected, adding in -e worked. I do it this way since LSF only lets me log raw stdout to a file so doing a build then a summary pass gives me more easily readable output. OK I missed that you were doing two steps. -v is only meaningful *without* -s: it makes the *build* verbose. When building, -v implies -e, The summary (-s) is always verbose, so doesn't need -v. OK, but in step #2, -svl _doesn't_ give me information about what boards have what problem and -svel does. You're saying -sel should work too, but commit text (and help text?) says that -l implies -e, but it's not. -v implies -e if you are building (no -s) -v means nothing if you are not building (-s) I don't think -l implies anything. I suspect I have stuffed up something in the docs but I can't see what, so will await your response. Sorry for the trouble. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/25] dm: spi: Add documentation on how to convert over SPI drivers
Hi Jagan,
On 31 August 2014 23:45, Jagan Teki jagannadh.t...@gmail.com wrote:
Hi Simon,
On 1 September 2014 10:36, Simon Glass s...@chromium.org wrote:
Hi Jagan,
On 28 August 2014 04:32, Jagan Teki jagannadh.t...@gmail.com wrote:
On 15 July 2014 06:26, Simon Glass s...@chromium.org wrote:
This README is intended to help maintainers move their SPI drivers over to
driver model. It works through the required steps with an example.
Signed-off-by: Simon Glass s...@chromium.org
---
doc/driver-model/spi-howto.txt | 570
+
1 file changed, 570 insertions(+)
create mode 100644 doc/driver-model/spi-howto.txt
diff --git a/doc/driver-model/spi-howto.txt
b/doc/driver-model/spi-howto.txt
new file mode 100644
index 000..bb64735
--- /dev/null
+++ b/doc/driver-model/spi-howto.txt
@@ -0,0 +1,570 @@
+How to port a SPI driver to driver model
+
+
+Here is a rough step-by-step guide. It is based around converting the
+exynos SPI driver to driver model (DM) and the example code is based
+around U-Boot v2014.04 (commit dda0dbf).
+
+It is quite long since it includes actual code examples.
+
+Before driver model, SPI drivers have their own private structure which
+contains 'struct spi_slave'. With driver model, 'struct spi_slave' still
+exists, but now it is 'per-child data' for the SPI bus. Each child of the
+SPI bus is a SPI slave. The information that was stored in the
+driver-specific slave structure can now be put in private data for the
+SPI bus.
Do you think spi_slave still require, I guess It's needed as some slave
members
to cs, bus are used to control the driver.
The CS and bus are purely command-line conveniences with DM. When it
gets down to the driver the bus is determined by the SPI peripheral it
is connected to, and the CS is the control that it adjusts to enable
the chip select. The numbering of buses and chip selects is not
relevant down at the driver level anymore.
Yes - I understand but let me explain my comments.
u-boot sf probe bus:cs speed mode
Unlike other buses/controllers on u-boot we're dynamically probing the
slave on bus
using bus and cs for example, we have a zynq_spi handling spi0, spi1
(bus's) and each
one has 3 chip-selects. So
u-boot sf probe 1:1
for probing bus1 (spi1) and cs 1
u-boot sf probe 0:1
for probing bus0 (spi0) and cs 1
The respective reg base (based on bus) and register chip-select (based
on cs) zynq_spi.c
will handle these in driver it self.
speed and mode settings, I'm fine with dm, where it will configure using
int spi_get_bus_and_cs(int busnum, int cs, int speed, int mode,
const char *drv_name, const char *dev_name,
struct udevice **devp, struct spi_slave **slavep)
{
.
ret = spi_set_speed_mode(bus, speed, mode);
..
}
But how can spi-uclass.c will identifies how many bus's along with cs lines
does
specified controller driver support.
This is done with platform data or device tree. In other words we
explicitly list a driver for each chip select.
However I did anticipate problems with this approach, particularly
while so few drivers are converted. Also we need to support things
like the 'sspi' command and 'sf probe'. So I added spi_bind_device()
which is automatically called if no SPI device is found for a bus/chip
select.
This what usually we're doing in driver as
int spi_cs_is_valid(unsigned int bus, unsigned int cs)
{
/* 2 bus with 3 chipselect */
return bus 2 cs 3;
}
Please let me know if you have any questions, this is what usually
doing most of drivers.
Yes, I don't really like that - it is a fine way of doing things
before driver model, but now it is not that useful. We are trying to
bind drivers to chip selects, not just figure out which ones are
valid.
One thing I have not figured out yet (mostly since I have no driver
that needs it) is how to activate multiple SPI chip selects using
GPIOs. It shouldn't be too hard, just need a board that supports it.
[snip]
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] sun7i: Add support for Olimex A20-OLinuXino-LIME
This patch adds support for Olimex A20-OLinuXino-LIME board.
Signed-off-by: FUKAUMI Naoki nao...@gmail.com
---
Changes in v2:
- update MAINTAINERS
- remove SPL from CONFIG_SYS_EXTRA_OPTIONS
- s/FTDFILE/FDTFILE/g
board/sunxi/MAINTAINERS | 6 ++
board/sunxi/Makefile | 1 +
board/sunxi/dram_a20_olinuxino_l.c | 31 +++
configs/A20-OLinuXino-Lime_defconfig | 5 +
4 files changed, 43 insertions(+)
create mode 100644 board/sunxi/dram_a20_olinuxino_l.c
create mode 100644 configs/A20-OLinuXino-Lime_defconfig
diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
index b0b1804..4f32195 100644
--- a/board/sunxi/MAINTAINERS
+++ b/board/sunxi/MAINTAINERS
@@ -32,3 +32,9 @@ F:configs/Cubieboard2_defconfig
F: configs/Cubieboard2_FEL_defconfig
F: configs/Cubietruck_defconfig
F: configs/Cubietruck_FEL_defconfig
+
+A20-OLINUXINO-LIME BOARD
+M: FUKAUMI Naoki nao...@gmail.com
+S: Maintained
+F: board/sunxi/dram_a20_olinuxino_l.c
+F: configs/A20-OLinuXino-Lime_defconfig
diff --git a/board/sunxi/Makefile b/board/sunxi/Makefile
index cf001e7..56073a0 100644
--- a/board/sunxi/Makefile
+++ b/board/sunxi/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_A10_OLINUXINO_L) += dram_a10_olinuxino_l.o
obj-$(CONFIG_A10S_OLINUXINO_M) += dram_a10s_olinuxino_m.o
obj-$(CONFIG_A13_OLINUXINO)+= dram_a13_olinuxino.o
obj-$(CONFIG_A13_OLINUXINOM) += dram_a13_oli_micro.o
+obj-$(CONFIG_A20_OLINUXINO_L) += dram_a20_olinuxino_l.o
obj-$(CONFIG_A20_OLINUXINO_M) += dram_sun7i_384_1024_iow16.o
# This is not a typo, uses the same mem settings as the a10s-olinuxino-m
obj-$(CONFIG_AUXTEK_T004) += dram_a10s_olinuxino_m.o
diff --git a/board/sunxi/dram_a20_olinuxino_l.c
b/board/sunxi/dram_a20_olinuxino_l.c
new file mode 100644
index 000..2c74999
--- /dev/null
+++ b/board/sunxi/dram_a20_olinuxino_l.c
@@ -0,0 +1,31 @@
+/* this file is generated, don't edit it yourself */
+
+#include common.h
+#include asm/arch/dram.h
+
+static struct dram_para dram_para = {
+ .clock = 480,
+ .type = 3,
+ .rank_num = 1,
+ .density = 4096,
+ .io_width = 16,
+ .bus_width = 16,
+ .cas = 9,
+ .zq = 0x7f,
+ .odt_en = 0,
+ .size = 512,
+ .tpr0 = 0x42d899b7,
+ .tpr1 = 0xa090,
+ .tpr2 = 0x22a00,
+ .tpr3 = 0,
+ .tpr4 = 0,
+ .tpr5 = 0,
+ .emr1 = 0x4,
+ .emr2 = 0x10,
+ .emr3 = 0,
+};
+
+unsigned long sunxi_dram_init(void)
+{
+ return dramc_init(dram_para);
+}
diff --git a/configs/A20-OLinuXino-Lime_defconfig
b/configs/A20-OLinuXino-Lime_defconfig
new file mode 100644
index 000..ca79fd5
--- /dev/null
+++ b/configs/A20-OLinuXino-Lime_defconfig
@@ -0,0 +1,5 @@
+CONFIG_SPL=y
+CONFIG_SYS_EXTRA_OPTIONS=A20_OLINUXINO_L,AXP209_POWER,SUNXI_GMAC,AHCI,SATAPWR=SUNXI_GPC(3),USB_EHCI
+CONFIG_FDTFILE=sun7i-a20-olinuxino-lime.dtb
++S:CONFIG_ARM=y
++S:CONFIG_TARGET_SUN7I=y
--
2.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
