Re: [U-Boot] [PATCH 2/2] tools/kwbimage.c: fix build on darwin
On 24.10.2014 23:39, andreas.de...@googlemail.com wrote: From: Andreas Bießmann kwbimage uses get_current_dir_name(3) which is a gnu extension and not available on darwin host. Fix this by converting to portable getcwd(3) function. This patch fixes the following error: ---8<--- HOSTCC tools/kwbimage.o tools/kwbimage.c:399:16: warning: implicit declaration of function 'get_current_dir_name' is invalid in C99 [-Wimplicit-function-declaration] char *cwd = get_current_dir_name(); ^ tools/kwbimage.c:399:10: warning: incompatible integer to pointer conversion initializing 'char *' with an expression of type 'int' [-Wint-conversion] char *cwd = get_current_dir_name(); ^ ~~ 2 warnings generated. ... Undefined symbols for architecture x86_64: "_get_current_dir_name", referenced from: _image_headersz_v1 in kwbimage.o ld: symbol(s) not found for architecture x86_64 --->8--- Signed-off-by: Andreas Bießmann Cc: Stefan Roese Acked-by: Stefan Roese Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [BUG] kwimage v0 broken
Hi! On 25.10.2014 07:59, drEagle wrote: With the latest u-boot mainline from denx git, the kirkwood image old version/format are broken; Sheevaplug u-boot.kwb is no more flahsable and brick the plug. Using an older mkimage version still work with the same u-boot binary. u-boot (in elf loading mode) still work well also. If I can help by some tests, please feel free to ask. PS: I'm not on the list, thans to cc me. Hmmm. I have no access to a mainlined Kirkwood board right now. So I can't really test right now. I added Luka to Cc, as he did some testing on this patch series a few weeks ago. And IIRC, he didn't experience any such problems with the kwimage tool. Luka, could you perhaps take another look at it? And give the current mainline version a try on your board? Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] MIPS Kconfig updates
Hi Daniel, On 26.10.2014 14:37, Daniel Schwierzeck wrote: This patch series introduce Kconfig symbols for various MIPS specific config options. It also add Kconfig symbols for board specific config options on vct and dbau1x00. With this series the option CONFIG_SYS_EXTRA_OPTIONS becomes obsolete for existing MIPS boards. This series is also available at git://git.denx.de/u-boot-mips.git mips_kconfig_v1 Daniel Schwierzeck (6): MIPS: kconfig: add options for endianess select MIPS: kconfig: add options for CPU type select MIPS: kconfig: globally define CONFIG_SYS_CPU for MIPS MIPS: kconfig: merge targets qemu_mips and qemu_mips64 MIPS: kconfig: add options for dbau1x00 board variant select MIPS: kconfig: add options for vct board variant select Thanks for working on this. Please add my: Acked-by: Stefan Roese to all VCT related patches. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8] ARMv8/fsl-lsch3: Refactor spin-table code
Hi Albert > -Original Message- > From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net] > Sent: Monday, October 27, 2014 2:36 AM > To: Basu Arnab-B45036 > Cc: marc.zyng...@arm.com; mark.rutl...@arm.com; Sun York-R58495; Yoder > Stuart-B08248; u-boot@lists.denx.de > Subject: Re: [U-Boot] [PATCH 3/8] ARMv8/fsl-lsch3: Refactor spin-table > code > > Hello Arnab, > > On Thu, 28 Aug 2014 01:59:56 +0530, Arnab Basu > wrote: > > This creates the function cpu_update_dt for ARMv8 which currently > > patches the cpu node in the device table and sets enable-method to > > spin-table. > > > > Signed-off-by: Arnab Basu > > Reviewed-by: Bhupesh Sharma > > Cc: York Sun > > --- > > This patch fails to apply cleanly. Can you please rebase the series on > top of current u-boot/master? Yes, in fact I need to rework some of the other patches in the series too. I got a little side tracked, hence the delay. I will get on this.. Thanks Arnab > > Amicalement, > -- > Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 14/20] arm: armada-xp: Add basic support for the Marvell DB-MV784MP-GP board
Hi Albert, Hi Tom! On 27.10.2014 07:32, Albert ARIBAUD wrote: Applied to u-boot/master, thanks! I am getting an error here with this board: Didn't find the file 'board/Marvell/db-mv784mp-gp/binary.0' in 'build/current/.bm-work/00/build' which is mandatory to generate the image This file generally contains the DDR3 training code, and should be extracted from an existing bootable image for your board. See 'kwbimage -x' to extract it from an existing image. Could not create image Am I missing something? Yes, we need http://patchwork.ozlabs.org/patch/402556/ and/or the follow-up that implements proper DDR config. Ok -- I guess I'll live with a broken ARM build for a while. I plan to send the patch series with full DDR support later this week, but it might take a bit until its available in mainline. I really suggest to add this patch that Tom mentioned above to fix building for now. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/1] fs: fat/ext4/sandbox: Deal with files > 2GB
Hello Suriyan, On Sun, 26 Oct 2014 21:42:52 -0700, Suriyan Ramasami wrote: > Subject: [PATCH v3 1/1] fs: fat/ext4/sandbox: Deal with files > 2GB Could you repost using the full 'negative' word instead of an abbreviation? Otherwise people looking for issues by keywords might miss this one. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: mvebu: maxbcm: Fix compilation warning and add Spansion SPI NOR support
This patch fixes the following compilation warning for maxbcm:
Building maxbcm board...
textdata bss dec hex filename
1600756596 38240 204911 3206f ./u-boot
board/maxbcm/maxbcm.c: In function 'reset_phy':
board/maxbcm/maxbcm.c:68:6: warning: unused variable 'reg' [-Wunused-variable]
u16 reg;
^
board/maxbcm/maxbcm.c:66:6: warning: unused variable 'devadr'
[-Wunused-variable]
u16 devadr = CONFIG_PHY_BASE_ADDR;
^
Additionally support Spansion SPI NOR flash is added. With larger SPI device
support via the CONFIG_SPI_FLASH_BAR define.
Signed-off-by: Stefan Roese
---
board/maxbcm/maxbcm.c| 2 --
include/configs/maxbcm.h | 2 ++
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/maxbcm/maxbcm.c b/board/maxbcm/maxbcm.c
index 7fc83ee..94c688f 100644
--- a/board/maxbcm/maxbcm.c
+++ b/board/maxbcm/maxbcm.c
@@ -63,9 +63,7 @@ int checkboard(void)
/* Configure and enable MV88E6185 switch */
void reset_phy(void)
{
- u16 devadr = CONFIG_PHY_BASE_ADDR;
char *name = "neta0";
- u16 reg;
if (miiphy_set_current_dev(name))
return;
diff --git a/include/configs/maxbcm.h b/include/configs/maxbcm.h
index 72217bd..005e136 100644
--- a/include/configs/maxbcm.h
+++ b/include/configs/maxbcm.h
@@ -43,6 +43,8 @@
#define CONFIG_SF_DEFAULT_SPEED100
#define CONFIG_SF_DEFAULT_MODE SPI_MODE_3
#define CONFIG_SPI_FLASH_STMICRO
+#define CONFIG_SPI_FLASH_SPANSION
+#define CONFIG_SPI_FLASH_BAR
/* Environment in SPI NOR flash */
#define CONFIG_ENV_IS_IN_SPI_FLASH
--
2.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] ARM: Add arch/arm/cpu/armv7/Kconfig with non-secure and virt options
Hi, On 10/27/2014 01:35 AM, Tom Rini wrote: > On Fri, Oct 24, 2014 at 08:34:15PM +0200, Hans de Goede wrote: > >> Add arch/arm/cpu/armv7/Kconfig with non-secure and virt options, so that >> we can have CONFIG_ARMV7_SEC_BY_DEFAULT as a proper Kconfig option. >> >> Signed-off-by: Hans de Goede >> --- >> arch/arm/Kconfig| 2 ++ >> arch/arm/cpu/armv7/Kconfig | 20 >> include/configs/arndale.h | 2 -- >> include/configs/sun7i.h | 2 -- >> include/configs/vexpress_ca15_tc2.h | 2 -- > > The only problem I see is you aren't also updating the defconfigs for > the boards in question, which results in a behavior change which we > don't want. The new Kconfig options have "default y", and the boards where using those settings before. Or are you referring to the fact that CONFIG_ARMV7_NONSEC is getting set for arndale and vexpress_ca15_tc2 now too ? That is intentional ARMV7_VIRT depends on CONFIG_ARMV7_NONSEC. So far this has been somewhat unelegantly solved by writing every #ifdef CONFIG_ARMV7_NONSEC as: #if defined(CONFIG_ARMV7_NONSEC) || defined(CONFIG_ARMV7_VIRT) So that setting CONFIG_ARMV7_VIRT automatically also includes all the NONSEC bits, note that after this patch we could simply these to just: #ifdef CONFIG_ARMV7_NONSEC Which would also more correctly reflect when the code should be enabled. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] power_spi.c: Rewrite pmic_reg function
Hi Tom.
On 25/10/2014 13:38, Tom Rini wrote:
> The pmic_spi_free function isn't ever used, and as the frameworks stand
> today, cannot be, so remove it.
That's right - it was originally implemented to have a symmetric
interface, but never used.
> Integrate the probe function into
> pmic_reg as it's not really a "probe" today. Finally, add an err label
> for the common failure cases.
>
> Cc: Lukasz Majewski
> Cc: Przemyslaw Marczak
> Cc: Stefano Babic
> Signed-off-by: Tom Rini
> ---
> drivers/power/power_spi.c | 33 ++---
> 1 file changed, 10 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/power/power_spi.c b/drivers/power/power_spi.c
> index fb455a00..1e55446 100644
> --- a/drivers/power/power_spi.c
> +++ b/drivers/power/power_spi.c
> @@ -17,27 +17,14 @@
>
> static struct spi_slave *slave;
>
> -void pmic_spi_free(struct spi_slave *slave)
> -{
> - if (slave)
> - spi_free_slave(slave);
> -}
> -
> -struct spi_slave *pmic_spi_probe(struct pmic *p)
> -{
> - return spi_setup_slave(p->bus,
> - p->hw.spi.cs,
> - p->hw.spi.clk,
> - p->hw.spi.mode);
> -}
> -
> static u32 pmic_reg(struct pmic *p, u32 reg, u32 *val, u32 write)
> {
> u32 pmic_tx, pmic_rx;
> u32 tmp;
>
> if (!slave) {
> - slave = pmic_spi_probe(p);
> + slave = spi_setup_slave(p->bus, p->hw.spi.cs, p->hw.spi.clk,
> + p->hw.spi.mode);
>
> if (!slave)
> return -1;
> @@ -54,25 +41,25 @@ static u32 pmic_reg(struct pmic *p, u32 reg, u32 *val,
> u32 write)
> tmp = cpu_to_be32(pmic_tx);
>
> if (spi_xfer(slave, pmic_spi_bitlen, &tmp, &pmic_rx,
> - pmic_spi_flags)) {
> - spi_release_bus(slave);
> - return -1;
> - }
> + pmic_spi_flags))
> + goto err;
>
> if (write) {
> pmic_tx = p->hw.spi.prepare_tx(reg, val, 0);
> tmp = cpu_to_be32(pmic_tx);
> if (spi_xfer(slave, pmic_spi_bitlen, &tmp, &pmic_rx,
> - pmic_spi_flags)) {
> - spi_release_bus(slave);
> - return -1;
> - }
> + pmic_spi_flags))
> + goto err;
> }
>
> spi_release_bus(slave);
> *val = cpu_to_be32(pmic_rx);
>
> return 0;
> +
> +err:
> + spi_release_bus(slave);
> + return -1;
> }
>
> int pmic_reg_write(struct pmic *p, u32 reg, u32 val)
>
Acked-by: Stefano Babic
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Buildman cookbook
Hello,
it would be nice if we could add a buildman cookbok with hints how to
get started quickly with the most frequent use cases (or add some
quickstart section to the README).
Things that I would like to have better documented include:
- dependencies on external tools:
-> tools/buildman/buildman --list-tool-chains
Traceback (most recent call last):
File "tools/buildman/buildman", line 10, in
import multiprocessing
ImportError: No module named multiprocessing
It would be nice if we could list such dependencies.
Actually we should probably provide such dependencies for U-Boot in
general - other tools have similar issues, like:
-> tools/genboardscfg.py
Traceback (most recent call last):
File "tools/genboardscfg.py", line 19, in
import fnmatch
ImportError: No module named fnmatch
- It would be nice if we could include a sample ".buildman" file,
and add documentation what the sections ("[toolchain]",
"[toolchain-alias]") and entries ("root", "rest", "eldk", "arm",
"aarch64") actually mena, which other options exist, and how the
tool selects a specific tool chain from this list if multiple
options are present.
- I work a lot with local branches, and regularly run into this:
-> tools/buildman/buildman -n -b tq-generic-board
No section: 'make-flags'
Branch 'tq-generic-board' not found or has no upstream
Can we not avoid this? Or add a default to "master"?
The README recommends to use "git branch --set-upstream ...", but
actually I don't want to do that - it is simply not needed.
Furthermore, git complains;
-> git branch --set-upstream tq-generic-board master
The --set-upstream flag is deprecated and will be removed. Consider using
--track or --set-upstream-to
Branch tq-generic-board set up to track local branch master.
Thanks.
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
Man braucht zwei Jahre, um sprechen zu lernen, und fünfzig Jahre, um
schweigen zu lernen. - Ernest Hemingway
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 19/20] tools: kwbimage: Add image version 1 support for Armada XP / 370
Dear Stefan,
In message <1413972804-24250-20-git-send-email...@denx.de> you wrote:
> This patch integrates the Barebox version of this kwbimage.c file into
> U-Boot. As this version supports the image version 1 type for the
> Armada XP / 370 SoCs.
This commit causes the following build warning on all boards:
tools/kwbimage.c: In function ‘kwbimage_set_header’:
tools/kwbimage.c:784:8: warning: ‘headersz’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
memcpy(ptr, image, headersz);
^
The problem is here:
> +static void kwbimage_set_header(void *ptr, struct stat *sbuf, int ifd,
> struct image_tool_params *params)
> {
...
> + size_t headersz;
...
> + version = image_get_version();
> + /* Fallback to version 0 is no version is provided in the cfg file */
> + if (version == -1)
> + version = 0;
> +
> + if (version == 0)
> + image = image_create_v0(&headersz, params, sbuf->st_size);
> + else if (version == 1)
> + image = image_create_v1(&headersz, params, sbuf->st_size);
If for some reason image_get_version() should return any other result
than -1, 0 or 1, then headersz will remain uninitialized.
Please fix.
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 easiest way to figure the cost of living is to take your income
and add ten percent.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] ARM: Add arch/arm/cpu/armv7/Kconfig with non-secure and virt options
On Fri, 2014-10-24 at 20:34 +0200, Hans de Goede wrote: > diff --git a/arch/arm/cpu/armv7/Kconfig b/arch/arm/cpu/armv7/Kconfig > new file mode 100644 > index 000..84e3edb > --- /dev/null > +++ b/arch/arm/cpu/armv7/Kconfig > @@ -0,0 +1,20 @@ > +# FIXME, Once overything in u-boot is properly Kconfig-ified "everything" > +# this entire file should be "if ARMV7" > +if ARCH_SUNXI Should this not be FOO_SUN7I (FOO depending on when this series lands wrt my sunxi Kconfig changes). I think we don't want this for any of the other sun?i, do we? Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/14] Set of fixes for Exynos4xxx boards
Hello, On 10/24/2014 05:44 PM, Przemyslaw Marczak wrote: Hello Simon, Tom, The last driver-model changes was merged too fast and I was not able to test it well on all my boards. It was worked well for the first look, but after deep testing - it required some additional work to do. So this is a set of fixes required for Exynos4xxx boards. I am not sure what about the Origen. The patchset was rebased on the top of u-boot-dm/master, which is now: c2ded96 serial: remove uniphier_serial_initialize() call Tested on: - Trats (E4210) - UniversalC210 (E4210) - Trats2 (E4412) - Odroid U3 (E4412) - Odroid X2 (E4412) Best Regards, Przemyslaw Marczak Przemyslaw Marczak (14): mmc: s5p: set SD detection pin as input exynos: common: enable generic fs operations exynos4/4x12: cpu: add extra gpio base addresses exynos4/4x12: gpio: use gpio extra base addresses exynos4412: dts: fix bad gpio order in pinctrl exynos4412: dts: adjust pinctrl-uboot to changed gpio order exynos4210: dts: fix gpio offset in pinctrl-uboot universal: request soft i2c gpio universal: dts: adjust gpio numbers to new api trats: dts: adjust gpio numbers to new api trats2: dts: adjust gpio numbers after gpio rework odroid: dts: adjust sd cd-gpios for SD Card odroid: dts: fix name of included dtsi odroid: adjust gpio calls to dm gpio api arch/arm/dts/exynos4210-pinctrl-uboot.dtsi | 2 +- arch/arm/dts/exynos4210-trats.dts | 4 +- arch/arm/dts/exynos4210-universal_c210.dts | 4 +- arch/arm/dts/exynos4412-odroid.dts | 4 +- arch/arm/dts/exynos4412-trats2.dts | 6 +-- arch/arm/dts/exynos4x12-pinctrl-uboot.dtsi | 5 +-- arch/arm/dts/exynos4x12-pinctrl.dtsi | 54 +-- arch/arm/include/asm/arch-exynos/cpu.h | 9 + arch/arm/include/asm/arch-exynos/gpio.h| 59 -- board/samsung/odroid/odroid.c | 17 - board/samsung/universal_c210/universal.c | 9 + drivers/mmc/s5p_sdhci.c| 2 +- include/configs/exynos-common.h| 1 + 13 files changed, 113 insertions(+), 63 deletions(-) The patchset is also available on github: https://github.com/bobenstein/u-boot.git branch: dm_exynos_gpio_fix Best regards, -- Przemyslaw Marczak Samsung R&D 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
Re: [U-Boot] [PATCH v3 4/8] common: spl: Add interactive DDR debugger support for SPL image
Hello Alison, On Fri, 17 Oct 2014 16:00:30 +0800, Alison Wang wrote: > To support interactive DDR debugger, cli_simple.o, cli.o, cli_readline.o, > command.o, s_record.o, xyzModem.o and cmd_disk.o are all needed for > drivers/ddr/fsl/interactive.c. > > In current common/Makefile, the above .o files are only produced when > CONFIG_SPL_BUILD is disabled. > > For LS102xA, interactive DDR debugger is needed in SD/NAND boot too, and > I enabled CONFIG_FSL_DDR_INTERACTIVE. But according to the current > common/Makfile, all the above .o files are not produced in SPL part > because CONFIG_SPL_BUILD is enabled in SPL part, the following error > will be shown, > > drivers/ddr/fsl/built-in.o: In function `fsl_ddr_interactive': > /home/wangh/layerscape/u-boot/drivers/ddr/fsl/interactive.c:1871: > undefined reference to `cli_readline_into_buffer' > /home/wangh/layerscape/u-boot/drivers/ddr/fsl/interactive.c:1873: > undefined reference to `cli_simple_parse_line' > make[1]: *** [spl/u-boot-spl] Error 1 > make: *** [spl/u-boot-spl] Error 2 > > So this patch fixed this issue and the above .o files will be produced > no matter CONFIG_SPL_BUILD is enabled or disabled. > > Signed-off-by: Alison Wang > --- > Change log: > v3: Gave more explaination in the commit. > v2: No change. This does not apply cleanly. Could you rebase and resubmit? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 2/3] usb: eth: add ASIX AX88179 DRIVER
Hello Andy, today I'm back from holiday. There is a lot of different work waiting for me, so I think it will be submitted by the end of next week. Did you try the V3 Patch? br René Am 06.10.2014 19:45, schrieb Andy Pont: Hello Rene, Subject: [U-Boot] [PATCH V3 2/3] usb: eth: add ASIX AX88179 DRIVER changes in v3: -added all compatible devices from linux driver -fixed issues from review changes in v2: -added usb_ether.h to change list -added 2nd patch to enable driver for arndale board Following the additional comments that came from Marek do you know when you will be submitted a v4 of this patch? Thanks for your effort on this. Regards, Andy. -- Dipl.-Ing. René Griessl Universität Bielefeld AG Kognitronik & Sensorik Exzellenzcluster Cognitive Interaction Technology (CITEC) Inspiration 1 (Zehlendorfer Damm 199) 33615 Bielefeld Telefon : +49 521-106-67362 Fax : +49 521-106-12348 eMail : rgrie...@cit-ec.uni-bielefeld.de Internet: http://www.ks.cit-ec.uni-bielefeld.de/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] ARM: HYP/non-sec: Make armv7_init_nonsec() usable before relocation
Hello Yuantian, On Thu, 16 Oct 2014 04:42:06 +, Yuantian Tang wrote: > > >> Wouldn't it be better to declare gic_dist_base as a local variable? > > >>It is only used once outside function armv7_switch_nonsec(). It could > > >>be replaced with > > >> get_gicd_base_address() call. > > >> > > >I am with you. That's what I did in the first version of this patch. > > >Patch links is at: http://patchwork.ozlabs.org/patch/391065/ > > >But Albert seems have some concerns. The attached is what we discussed. FTR, I only had concerns with the patch subject / commit summary. Regarding the patch itself, I just asked whether the global was not used as some means of coordination which would have been broken by turning it into a local, but you had checked, so that was fine. > > >Now on the second thought, I prefer the way this patch proposed because > > >if we define gic_dist_base as local variable, That means function > > >get_gicd_base_address() should be usable at any time in any mode. Can > > >we make sure of that in the future? > > > > I don't strongly object introducing a new local variable. But I don't see > > how the > > global variable is useful. Function get_gicd_base_address() should be > > available all > > the time. It reads PERIPHBASE register, or return a macro. It hasn't changed > > since the first patch added it in 2013. Not sure if the original author > > Andre > > Przywara is available to comments. > > > Thanks for your comments. > If no one objects the original patch, I like to resubmit it. > > Hi Albert, what's your opinion on this? Which 'original patch' do you mean? If it is http://patchwork.ozlabs.org/patch/391065/ then I'm fine with it and will apply it. > Regards, > Yuantian > > > York > > Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: mvebu: maxbcm: Fix compilation warning and add Spansion SPI NOR support
On 27 October 2014 14:04, Stefan Roese wrote:
> This patch fixes the following compilation warning for maxbcm:
>
> Building maxbcm board...
>textdata bss dec hex filename
> 1600756596 38240 204911 3206f ./u-boot
> board/maxbcm/maxbcm.c: In function 'reset_phy':
> board/maxbcm/maxbcm.c:68:6: warning: unused variable 'reg' [-Wunused-variable]
> u16 reg;
> ^
> board/maxbcm/maxbcm.c:66:6: warning: unused variable 'devadr'
> [-Wunused-variable]
> u16 devadr = CONFIG_PHY_BASE_ADDR;
> ^
>
> Additionally support Spansion SPI NOR flash is added. With larger SPI device
> support via the CONFIG_SPI_FLASH_BAR define.
>
> Signed-off-by: Stefan Roese
> ---
> board/maxbcm/maxbcm.c| 2 --
> include/configs/maxbcm.h | 2 ++
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/board/maxbcm/maxbcm.c b/board/maxbcm/maxbcm.c
> index 7fc83ee..94c688f 100644
> --- a/board/maxbcm/maxbcm.c
> +++ b/board/maxbcm/maxbcm.c
> @@ -63,9 +63,7 @@ int checkboard(void)
> /* Configure and enable MV88E6185 switch */
> void reset_phy(void)
> {
> - u16 devadr = CONFIG_PHY_BASE_ADDR;
> char *name = "neta0";
> - u16 reg;
>
> if (miiphy_set_current_dev(name))
> return;
> diff --git a/include/configs/maxbcm.h b/include/configs/maxbcm.h
> index 72217bd..005e136 100644
> --- a/include/configs/maxbcm.h
> +++ b/include/configs/maxbcm.h
> @@ -43,6 +43,8 @@
> #define CONFIG_SF_DEFAULT_SPEED100
> #define CONFIG_SF_DEFAULT_MODE SPI_MODE_3
> #define CONFIG_SPI_FLASH_STMICRO
> +#define CONFIG_SPI_FLASH_SPANSION
> +#define CONFIG_SPI_FLASH_BAR
>
> /* Environment in SPI NOR flash */
> #define CONFIG_ENV_IS_IN_SPI_FLASH
Reviewed-by: Jagannadha Sutradharudu Teki
thanks!
--
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] arm: odroid: usb: add support for usb host including ethernet
Hello Suriyan,
On 10/24/2014 06:08 PM, Suriyan Ramasami wrote:
Hello Minkyu Kang,
On Thu, Oct 23, 2014 at 9:58 PM, Minkyu Kang wrote:
Dear Suriyan Ramasami,
On 21/10/14 02:52, Suriyan Ramasami wrote:
This change adds support for enabling the USB host features of the board.
This includes the USB3503A hub and the SMC LAN9730 ethernet controller
as well.
Credit goes to Tushar Berara for the function set_usb_ethaddr().
Signed-off-by: Suriyan Ramasami
---
v2:
* Removed an unneeded header file from ehci-exynos.c
* Fix indentation in the dts file
---
arch/arm/dts/exynos4412-odroid.dts | 11 +++
arch/arm/include/asm/arch-exynos/cpu.h | 2 ++
arch/arm/include/asm/arch-exynos/ehci.h | 13
board/samsung/odroid/odroid.c | 55 +
drivers/usb/host/ehci-exynos.c | 51 +-
include/configs/odroid.h| 13
6 files changed, 137 insertions(+), 8 deletions(-)
diff --git a/arch/arm/dts/exynos4412-odroid.dts
b/arch/arm/dts/exynos4412-odroid.dts
index 24d0bf1..ac5fece 100644
--- a/arch/arm/dts/exynos4412-odroid.dts
+++ b/arch/arm/dts/exynos4412-odroid.dts
@@ -67,4 +67,15 @@
div = <0x3>;
index = <4>;
};
+
+ ehci@1258 {
+ compatible = "samsung,exynos-ehci";
+ reg = <0x1258 0x100>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ phy {
+ compatible = "samsung,exynos-usb-phy";
+ reg = <0x125B 0x100>;
+ };
+ };
};
diff --git a/arch/arm/include/asm/arch-exynos/cpu.h
b/arch/arm/include/asm/arch-exynos/cpu.h
index ba71714..fda21fb 100644
--- a/arch/arm/include/asm/arch-exynos/cpu.h
+++ b/arch/arm/include/asm/arch-exynos/cpu.h
@@ -18,6 +18,8 @@
#define EXYNOS4_GPIO_PART3_BASE 0x0386
#define EXYNOS4_PRO_ID 0x1000
+#define EXYNOS4_GUID_LOW 0x1014
+#define EXYNOS4_GUID_HIGH0x1018
#define EXYNOS4_SYSREG_BASE 0x1001
#define EXYNOS4_POWER_BASE 0x1002
#define EXYNOS4_SWRESET 0x10020400
diff --git a/arch/arm/include/asm/arch-exynos/ehci.h
b/arch/arm/include/asm/arch-exynos/ehci.h
index d2d70bd..3800fa9 100644
--- a/arch/arm/include/asm/arch-exynos/ehci.h
+++ b/arch/arm/include/asm/arch-exynos/ehci.h
@@ -12,6 +12,13 @@
#define CLK_24MHZ5
+#define PHYPWR_NORMAL_MASK_PHY0 (0x39 << 0)
+#define PHYPWR_NORMAL_MASK_PHY1 (0x7 << 6)
+#define PHYPWR_NORMAL_MASK_HSIC0(0x7 << 9)
+#define PHYPWR_NORMAL_MASK_HSIC1(0x7 << 12)
+#define RSTCON_HOSTPHY_SWRST(0xf << 3)
+#define RSTCON_SWRST(0x1 << 0)
+
#define HOST_CTRL0_PHYSWRSTALL (1 << 31)
#define HOST_CTRL0_COMMONON_N(1 << 9)
#define HOST_CTRL0_SIDDQ (1 << 6)
@@ -61,6 +68,12 @@ struct exynos_usb_phy {
unsigned int usbotgtune;
};
+struct exynos4412_usb_phy {
+ unsigned int usbphyctrl;
+ unsigned int usbphyclk;
+ unsigned int usbphyrstcon;
+};
+
/* Switch on the VBUS power. */
int board_usb_vbus_init(void);
diff --git a/board/samsung/odroid/odroid.c b/board/samsung/odroid/odroid.c
index 5edb250..6c78b67 100644
--- a/board/samsung/odroid/odroid.c
+++ b/board/samsung/odroid/odroid.c
@@ -453,9 +453,64 @@ struct s3c_plat_otg_data s5pc210_otg_data = {
.usb_phy_ctrl = EXYNOS4X12_USBPHY_CONTROL,
.usb_flags = PHY0_SLEEP,
};
+#endif
+
+#if defined(CONFIG_USB_GADGET) || defined(CONFIG_CMD_USB)
+
+#ifdef CONFIG_CMD_USB
+static void set_usb_ethaddr(void)
+{
+ int i;
+ uchar mac[6];
+ unsigned int guid_high = readl(EXYNOS4_GUID_HIGH);
+ unsigned int guid_low = readl(EXYNOS4_GUID_LOW);
We don't allow direct access.
Is it special register? I can't find this register on TRM.
If so you can make inline function at cpu.h instead.
This register is not in the TRM. This register is possibly documented
in the TRM for the Exynos5250. Through experimentation I found that it
behaves the same on Exynos4412 prime as well - I checked this with one
X2, 1 U2 and 2 U3s, and they do indeed do the job of being unique and
hence can be used to generate the mac address which will be unique
across all U2s/U3s/X2s and possibly other Exynos SoCs like Exynos4212
etc.
Those register addresses are not documented anywhere. So use of them is
not a good idea and can cause unpredictable results, even if was tested
on a few devices.
Regarding direct access, I am a bit confused. In odroid.c I see quite
a many places which is doing a readl() of registers. Here we are
readl(addr) into guid_* similarly, and cooking up a mac address in a
local char array.
I fail to see your point. Can you please elaborate more, so I can comprehend?
The MAC addr
Re: [U-Boot] [PATCH v2 1/3] arm: odroid: pmic77686: allow bucket voltage settings
Hello Suriyan,
On 10/24/2014 05:53 PM, Suriyan Ramasami wrote:
Hello Jaehoon Chung,
On Thu, Oct 23, 2014 at 11:52 PM, Jaehoon Chung wrote:
Hi.
On 10/21/2014 02:52 AM, Suriyan Ramasami wrote:
Allow to set the bucket voltage for the max77686.
This will be used to reset the SMC LAN9730 ethernet on the odroids.
Signed-off-by: Suriyan Ramasami
---
drivers/power/pmic/pmic_max77686.c | 48 +-
include/power/max77686_pmic.h | 3 +++
2 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/power/pmic/pmic_max77686.c
b/drivers/power/pmic/pmic_max77686.c
index df1fd91..1aeadb4 100644
--- a/drivers/power/pmic/pmic_max77686.c
+++ b/drivers/power/pmic/pmic_max77686.c
@@ -42,6 +42,25 @@ static unsigned int max77686_ldo_volt2hex(int ldo, ulong uV)
return 0;
}
+static unsigned int max77686_buck_volt2hex(int buck, ulong uV)
+{
+ unsigned int hex = 0;
+
+ if (buck < 5 || buck > 9) {
+ debug("%s: buck %d is not supported\n", __func__, buck);
+ return 0;
Here, I should return MAX77686_BUCK_VOLT_MAX_HEX + 1 instead of 0 to
signal an error condition, as 0 is a valid non error value.
He 'hex' value has at most 1 byte of len, so you can return the 'int'
value and use the negative errno numbers - and there is no value conflicts.
+ }
+
+ hex = (uV - 75) / 5;
+
+ if (hex >= 0 && hex <= MAX77686_BUCK_VOLT_MAX_HEX)
+ return hex;
+
+ debug("%s: %ld is wrong voltage value for BUCK%d\n",
+ __func__, uV, buck);
+ return MAX77686_BUCK_VOLT_MAX_HEX + 1;
+}
+
int max77686_set_ldo_voltage(struct pmic *p, int ldo, ulong uV)
{
unsigned int val, ret, hex, adr;
@@ -68,6 +87,33 @@ int max77686_set_ldo_voltage(struct pmic *p, int ldo, ulong
uV)
return ret;
}
+int max77686_set_buck_voltage(struct pmic *p, int buck, ulong uV)
+{
+ unsigned int val, ret, hex, adr;
+
+ if (buck < 5 && buck > 9) {
+ printf("%s: %d is an unsupported bucket number\n",
+__func__, buck);
+ return -1;
How about using error number instead of "-1"?
Could you please elaborate on this? This function always returns -1 on
failure just like the function max77686_set_ldo_voltate() which I have
tried to mimic as much as I can.
I am guessing that you want me to return -EINVAL in this case? Please
let me know, and I am OK to change it, just that this function will
deviate from the rest of the functions in this file.
Yes, this will be better.
+ }
+
+ adr = max77686_buck_addr[buck] + 1;
+ hex = max77686_buck_volt2hex(buck, uV);
+
if (hex < 0)
return hex;
+ if (hex == MAX77686_BUCK_VOLT_MAX_HEX + 1)
+ return -1;
Ditto.
I believe, I return -EINVAL here, but please look at my reasoning above.
+
+ ret = pmic_reg_read(p, adr, &val);
+ if (ret)
+ return ret;
+
+ val &= ~MAX77686_BUCK_VOLT_MASK;
+ val |= hex;
+ ret |= pmic_reg_write(p, adr, val);
ret |= pmic_reg_write(p, addr, val | hex); ?
OK, will change that. Again, this was done to be as close to
max77686_set_ldo_voltate()
Thanks and Regards!
- Suriyan
Best Regards,
Jaehoon Chung
+
+ return ret;
+}
+
int max77686_set_ldo_mode(struct pmic *p, int ldo, char opmode)
{
unsigned int val, ret, adr, mode;
@@ -157,7 +203,7 @@ int max77686_set_buck_mode(struct pmic *p, int buck, char
opmode)
/* mode */
switch (opmode) {
case OPMODE_OFF:
- mode = MAX77686_BUCK_MODE_OFF;
+ mode = MAX77686_BUCK_MODE_OFF << mode_shift;
break;
case OPMODE_STANDBY:
switch (buck) {
diff --git a/include/power/max77686_pmic.h b/include/power/max77686_pmic.h
index c2a772a..b0e4255 100644
--- a/include/power/max77686_pmic.h
+++ b/include/power/max77686_pmic.h
@@ -150,6 +150,7 @@ enum {
int max77686_set_ldo_voltage(struct pmic *p, int ldo, ulong uV);
int max77686_set_ldo_mode(struct pmic *p, int ldo, char opmode);
+int max77686_set_buck_voltage(struct pmic *p, int buck, ulong uV);
int max77686_set_buck_mode(struct pmic *p, int buck, char opmode);
#define MAX77686_LDO_VOLT_MAX_HEX0x3f
@@ -159,6 +160,8 @@ int max77686_set_buck_mode(struct pmic *p, int buck, char
opmode);
#define MAX77686_LDO_MODE_STANDBY(0x01 << 0x06)
#define MAX77686_LDO_MODE_LPM(0x02 << 0x06)
#define MAX77686_LDO_MODE_ON (0x03 << 0x06)
+#define MAX77686_BUCK_VOLT_MAX_HEX 0x3f
+#define MAX77686_BUCK_VOLT_MASK 0x3f
#define MAX77686_BUCK_MODE_MASK 0x03
#define MAX77686_BUCK_MODE_SHIFT_1 0x00
#define MAX77686_BUCK_MODE_SHIFT_2 0x04
Best regards,
--
Przemyslaw Marczak
Samsung R&D 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
Re: [U-Boot] [PATCH v2 7/7] sunxi: kconfig: Add %_felconfig rule to enable FEL build of sunxi platforms.
Hi,
On 10/24/2014 10:20 PM, Ian Campbell wrote:
> $ make BOARD_felconfig
> is more convenient than
> $ make BOARD_defconfig
> $ echo CONFIG_SPL_FEL=y >> .config
> $ echo CONFIG_SPL_FEL=y >> spl/.config
>
> Signed-off-by: Ian Campbell
> ---
> v2: New patch.
>
> Is this a good idea?
Yes!
All patches look good to me and are:
Reviewed-by: Hans de Goede
I've pushed this series to u-boot-sunxi/next
Regards,
Hans
> ---
> scripts/multiconfig.sh | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/scripts/multiconfig.sh b/scripts/multiconfig.sh
> index 3e3040b..70f3a5d 100644
> --- a/scripts/multiconfig.sh
> +++ b/scripts/multiconfig.sh
> @@ -162,6 +162,16 @@ do_defconfig () {
> fi
> }
>
> +do_board_felconfig () {
> +do_board_defconfig ${1%%_felconfig}_defconfig
> +if ! grep -q CONFIG_ARCH_SUNXI=y .config || ! grep -q CONFIG_SPL=y
> .config ; then
> + echo "$progname: Cannot felconfig a non-sunxi or non-SPL platform" >&2
> + exit 1
> +fi
> +sed -i -e 's/\# CONFIG_SPL_FEL is not set/CONFIG_SPL_FEL=y/g' \
> + .config spl/.config
> +}
> +
> do_savedefconfig () {
> if [ -r "$KCONFIG_CONFIG" ]; then
> subimages=$(get_enabled_subimages)
> @@ -323,6 +333,8 @@ target=$1
> case $target in
> *_defconfig)
> do_board_defconfig $target;;
> +*_felconfig)
> + do_board_felconfig $target;;
> *_config)
> # backward compatibility
> do_board_defconfig ${target%_config}_defconfig;;
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] imx: gpt: Add 24Mhz OSC clock source support for GPT
Hi Ye,
On 27/10/2014 05:10, Li Ye-B37916 wrote:
>
> The patch is used to add a choice for GPT clock source to provide high
> frequency clock. The configuration "CONFIG_MXC_GPT_HCLK" is not dependent on
> the chip version. Even it is i.MX28, it is ok to set the configuration.
Ok, thanks for clarification.
>
> The implementation has handled the differences between the chips.
> Most of i.MX6 series supports to use 24Mhz OSC as its high clock source
> (except MX6Q/D Rev 1.0 and MX6SL). So for i.MX6, the implementation uses the
> 24Mhz OSC.
> For others (the time.c only compiles for i.MX5 and i.MX6, so the other is
> i.MX5), they don't have 24Mhz OSC source for GPT. When the configuration is
> set, we use perclk instead.
It should be not bad if you check for MX5 and CONFIG_MXC_GPT_HCLK and
raise an error at compile time. This configuration is wrong and the
error should be reported and not hidden at runtime.
>
> I feel the patch subject need to modify, like "add HCLK clock source for
> GPT", then people may not confuse.
Agree, do it.
>
>>> MX6Q/D Rev 1.0 and MX6SL can't use the 24Mhz OSC clock source option,
>>> so select the perclk for them. For MX6SL, we will set the OSC 24Mhz to
>>> perclk in CCM, so eventually the clock comes from OSC 24Mhz.
>>>
>> I am trying to understand. The explanation here does not reflect in the
>> implementation. From the implementation, it is possible to set it even
>> with wrong revision.
>
> As explained above, the implementation has handled the differences. Users
> does not need to care the revision. For example, when the image runs on a
> MX6Q/D Rev 1.0 chip, the perclk will be selected not the 24Mhz OSC.
>
>> Anyway, I do not think it is correct to put it as a configuration
>> option. This makes that we need different binaries for different
>> revisions of the SOC. It should be checked at runtime if the revision is
>> correct to set this clock as source. gpt_has_clk_source_osc has a check,
>> but does it make sense that CONFIG_MXC_GPT_HCLK can be set in any case ?
> Only i.MX5 and i.MX6 uses the GPT driver. I think the CONFIG_MXC_GPT_HCLK can
> be set in any case.
Well, but if does not make sense for i.MX5, why do we have to accept it ?
>
>>> Signed-off-by: Ye.Li
>>> ---
>> Is this a second version of the patchset ? What are the changes ? Please
>> add version number to your patchset and write a history about changes. I
>> can suggest to use Simon's patman to post your patches.
>
> I met a email problem last Friday. I can't get any email from
> u-boot@lists.denx.de for a long time. So I mistakenly thought
> the first patches are failed and send out second.
Never mind ;-)
>
>>> arch/arm/imx-common/timer.c | 76
>>> +--
>>> 1 files changed, 66 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/arch/arm/imx-common/timer.c b/arch/arm/imx-common/timer.c
>>> index c63f78f..f7e49bd 100644
>>> --- a/arch/arm/imx-common/timer.c
>>> +++ b/arch/arm/imx-common/timer.c
>>> @@ -2,7 +2,7 @@
>>> * (C) Copyright 2007
>>> * Sascha Hauer, Pengutronix
>>> *
>>> - * (C) Copyright 2009 Freescale Semiconductor, Inc.
>>> + * (C) Copyright 2009-2014 Freescale Semiconductor, Inc.
>> I have already complain about this. There are a lot of commits after the
>> file was merged into u-boot, and a lot of them not directly by
>> Freescale. I do not think it is legally correct to change the Copyright.
>
> Will fix this.
Thanks
>
>>> *
>>> * SPDX-License-Identifier:GPL-2.0+
>>> */
>>> @@ -12,6 +12,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>>
>>> /* General purpose timers registers */
>>> struct mxc_gpt {
>>> @@ -26,23 +27,60 @@ static struct mxc_gpt *cur_gpt = (struct mxc_gpt
>>> *)GPT1_BASE_ADDR;
>>>
>>> /* General purpose timers bitfields */
>>> #define GPTCR_SWR (1 << 15) /* Software reset */
>>> +#define GPTCR_24MEN(1 << 10) /* Enable 24MHz clock input
>>> from crystal */
>>> #define GPTCR_FRR (1 << 9)/* Freerun / restart */
>>> -#define GPTCR_CLKSOURCE_32 (4 << 6)/* Clock source */
>>> +#define GPTCR_CLKSOURCE_32 (4 << 6)/* Clock source 32khz */
>>> +#define GPTCR_CLKSOURCE_OSC(5 << 6)/* Clock source OSC */
>>> +#define GPTCR_CLKSOURCE_PRE(1 << 6)/* Clock source PRECLK
>>> */
>>> +#define GPTCR_CLKSOURCE_MASK (0x7 << 6)
>>> #define GPTCR_TEN 1 /* Timer enable */
>>>
>>> +#define GPTPR_PRESCALER24M_SHIFT 12
>>> +#define GPTPR_PRESCALER24M_MASK (0xF << GPTPR_PRESCALER24M_SHIFT)
>>> +
>>> DECLARE_GLOBAL_DATA_PTR;
>>>
>>> +static inline int gpt_has_clk_source_osc(void)
>>> +{
>>> +#if defined(CONFIG_MX6)
>>> + if (((is_cpu_type(MXC_CPU_MX6Q) || is_cpu_type(MXC_CPU_MX6D))
>>> + && (is_soc_rev(CHIP_REV_1_0) > 0))
>>> + || is_cpu_type(MXC_CPU_MX6DL) || is_cpu_type(MXC_CPU_MX6SOLO)
>>> + || is_cpu_type(MXC_CPU_MX6SX))
>>> +
Re: [U-Boot] [PATCH v1 1/1] odroid: Turn blue LED on in u-boot
Hello Suriyan, On 10/10/2014 12:20 AM, Suriyan Ramasami wrote: To indicate that u-boot is active turn on the blue LED. Signed-off-by: Suriyan Ramasami --- board/samsung/odroid/odroid.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/board/samsung/odroid/odroid.c b/board/samsung/odroid/odroid.c index fd5d2d2..391a287 100644 --- a/board/samsung/odroid/odroid.c +++ b/board/samsung/odroid/odroid.c @@ -374,6 +374,9 @@ static void board_gpio_init(void) gpio_set_pull(EXYNOS4X12_GPIO_X31, S5P_GPIO_PULL_UP); gpio_set_drv(EXYNOS4X12_GPIO_X31, S5P_GPIO_DRV_4X); gpio_direction_input(EXYNOS4X12_GPIO_X31); + + /* Enable blue LED */ Here you will need to add gpio_request() call, e.g. http://patchwork.ozlabs.org/patch/403197/ + gpio_direction_output(EXYNOS4X12_GPIO_C10, 0); } static int pmic_init_max77686(void) This looks good, but please wait until the patch series merge: http://patchwork.ozlabs.org/patch/403186/ (starts from this commit) Best regards, -- Przemyslaw Marczak Samsung R&D 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
Re: [U-Boot] [PATCH] tools/kwbimage.c: fix parser error handling
Hello Andreas,
On 24-10-14 23:25, andreas.de...@googlemail.com wrote:
From: Andreas Bießmann
The two error checks for image_boot_mode_id and image_nand_ecc_mode_id where
wrong and would never fail, fix that!
This was detected by Apple's clang compiler:
---8<---
HOSTCC tools/kwbimage.o
tools/kwbimage.c:553:20: warning: comparison of unsigned expression < 0 is
always false [-Wtautological-compare]
if (el->bootfrom < 0) {
^ ~
tools/kwbimage.c:571:23: warning: comparison of unsigned expression < 0 is
always false [-Wtautological-compare]
if (el->nandeccmode < 0) {
~~~ ^ ~
2 warnings generated.
--->8---
Signed-off-by: Andreas Bießmann
---
tools/kwbimage.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 42870ed..8fd70ef 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -548,13 +548,14 @@ static int image_create_config_parse_oneline(char *line,
el->version = atoi(value);
} else if (!strcmp(keyword, "BOOT_FROM")) {
char *value = strtok_r(NULL, deliminiters, &saveptr);
- el->type = IMAGE_CFG_BOOT_FROM;
- el->bootfrom = image_boot_mode_id(value);
- if (el->bootfrom < 0) {
+ int ret = image_boot_mode_id(value);
+ if (ret < 0) {
fprintf(stderr,
"Invalid boot media '%s'\n", value);
return -1;
}
+ el->type = IMAGE_CFG_BOOT_FROM;
+ el->bootfrom = ret;
} else if (!strcmp(keyword, "NAND_BLKSZ")) {
char *value = strtok_r(NULL, deliminiters, &saveptr);
el->type = IMAGE_CFG_NAND_BLKSZ;
@@ -566,13 +567,14 @@ static int image_create_config_parse_oneline(char *line,
strtoul(value, NULL, 16);
} else if (!strcmp(keyword, "NAND_ECC_MODE")) {
char *value = strtok_r(NULL, deliminiters, &saveptr);
- el->type = IMAGE_CFG_NAND_ECC_MODE;
- el->nandeccmode = image_nand_ecc_mode_id(value);
- if (el->nandeccmode < 0) {
+ int ret = image_nand_ecc_mode_id(value);
Thanks for fixing this. Could you move the int ret declaration before
actual code though?
Regards,
Jeroen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/8] powerpc/mpc85xx: Add T1024/T1023 SoC support
Add support for Freescale T1024/T1023 SoC. The T1024 SoC includes the following function and features: - Two 64-bit Power architecture e5500 cores, up to 1.4GHz - private 256KB L2 cache each core and shared 256KB CoreNet platform cache (CPC) - 32-/64-bit DDR3L/DDR4 SDRAM memory controller with ECC and interleaving support - Data Path Acceleration Architecture (DPAA) incorporating acceleration - Four MAC for 1G/2.5G/10G network interfaces (RGMII, SGMII, QSGMII, XFI) - High-speed peripheral interfaces - Three PCI Express 2.0 controllers - Additional peripheral interfaces - One SATA 2.0 controller - Two USB 2.0 controllers with integrated PHY - Enhanced secure digital host controller (SD/eSDHC/eMMC) - Enhanced serial peripheral interface (eSPI) - Four I2C controllers - Four 2-pin UARTs or two 4-pin UARTs - Integrated Flash Controller supporting NAND and NOR flash - Two 8-channel DMA engines - Multicore programmable interrupt controller (PIC) - LCD interface (DIU) with 12 bit dual data rate - QUICC Engine block supporting TDM, HDLC, and UART - Deep Sleep power implementaion (wakeup from GPIO/Timer/Ethernet/USB) - Support for hardware virtualization and partitioning enforcement - QorIQ Platform's Trust Architecture 2.0 Differences between T1024 and T1023: Feature T1024 T1023 QUICC Engine: yesno DIU:yesno Deep Sleep: yesno I2C controller: 4 3 DDR:64-bit 32-bit IFC:32-bit 28-bit Signed-off-by: Shengzhou Liu --- arch/powerpc/cpu/mpc85xx/Makefile | 4 ++ arch/powerpc/cpu/mpc85xx/speed.c | 12 +++- arch/powerpc/cpu/mpc85xx/t1024_ids.c | 82 arch/powerpc/cpu/mpc85xx/t1024_serdes.c| 50 + arch/powerpc/cpu/mpc8xxx/cpu.c | 4 ++ arch/powerpc/include/asm/config_mpc85xx.h | 45 +++ arch/powerpc/include/asm/fsl_secure_boot.h | 4 +- arch/powerpc/include/asm/immap_85xx.h | 14 + arch/powerpc/include/asm/processor.h | 4 ++ drivers/net/fm/Makefile| 2 + drivers/net/fm/t1024.c | 88 ++ 11 files changed, 307 insertions(+), 2 deletions(-) create mode 100644 arch/powerpc/cpu/mpc85xx/t1024_ids.c create mode 100644 arch/powerpc/cpu/mpc85xx/t1024_serdes.c create mode 100644 drivers/net/fm/t1024.c diff --git a/arch/powerpc/cpu/mpc85xx/Makefile b/arch/powerpc/cpu/mpc85xx/Makefile index ad26b43..b93158b 100644 --- a/arch/powerpc/cpu/mpc85xx/Makefile +++ b/arch/powerpc/cpu/mpc85xx/Makefile @@ -51,6 +51,8 @@ obj-$(CONFIG_PPC_T1040) += t1040_ids.o obj-$(CONFIG_PPC_T1042)+= t1040_ids.o obj-$(CONFIG_PPC_T1020)+= t1040_ids.o obj-$(CONFIG_PPC_T1022)+= t1040_ids.o +obj-$(CONFIG_PPC_T1023) += t1024_ids.o +obj-$(CONFIG_PPC_T1024) += t1024_ids.o obj-$(CONFIG_PPC_T2080) += t2080_ids.o obj-$(CONFIG_PPC_T2081) += t2080_ids.o @@ -97,6 +99,8 @@ obj-$(CONFIG_PPC_T1040) += t1040_serdes.o obj-$(CONFIG_PPC_T1042)+= t1040_serdes.o obj-$(CONFIG_PPC_T1020)+= t1040_serdes.o obj-$(CONFIG_PPC_T1022)+= t1040_serdes.o +obj-$(CONFIG_PPC_T1023) += t1024_serdes.o +obj-$(CONFIG_PPC_T1024) += t1024_serdes.o obj-$(CONFIG_PPC_T2080) += t2080_serdes.o obj-$(CONFIG_PPC_T2081) += t2080_serdes.o diff --git a/arch/powerpc/cpu/mpc85xx/speed.c b/arch/powerpc/cpu/mpc85xx/speed.c index 3236f6a..ac46f6b 100644 --- a/arch/powerpc/cpu/mpc85xx/speed.c +++ b/arch/powerpc/cpu/mpc85xx/speed.c @@ -168,6 +168,9 @@ void get_sys_info(sys_info_t *sys_info) defined(CONFIG_PPC_T2080) || defined(CONFIG_PPC_T2081) #define FM1_CLK_SEL0xe000 #define FM1_CLK_SHIFT 29 +#elif defined(CONFIG_PPC_T1024) || defined(CONFIG_PPC_T1023) +#define FM1_CLK_SEL0x0007 +#define FM1_CLK_SHIFT 0 #else #define PME_CLK_SEL0xe000 #define PME_CLK_SHIFT 29 @@ -175,8 +178,12 @@ void get_sys_info(sys_info_t *sys_info) #define FM1_CLK_SHIFT 26 #endif #if !defined(CONFIG_FM_PLAT_CLK_DIV) || !defined(CONFIG_PME_PLAT_CLK_DIV) +#if defined(CONFIG_PPC_T1024) || defined(CONFIG_PPC_T1023) + rcw_tmp = in_be32(&gur->rcwsr[15]) - 4; +#else rcw_tmp = in_be32(&gur->rcwsr[7]); #endif +#endif #ifdef CONFIG_SYS_DPAA_PME #ifndef CONFIG_PME_PLAT_CLK_DIV @@ -213,7 +220,10 @@ void get_sys_info(sys_info_t *sys_info) #endif #ifdef CONFIG_SYS_DPAA_QBMAN - sys_info->freq_qman = sys_info->freq_systembus / 2; +#ifndef CONFIG_QBMAN_CLK_DIV +#define CONFIG_QBMAN_CLK_DIV 2 +#endif + sys_info->freq_qman = sys_info->freq_systembus / CONFIG_QBMAN_CLK_DIV; #endif #ifdef CONFIG_SYS_DPAA_FMAN diff --git a/arch/powerpc/cpu/mpc85xx/t1024_ids.c b/arch/powerpc/cpu/mpc85xx/t1024_ids.c new file mode 100644 index 000..5f24c15 --- /dev/null +++ b/arch/powerpc/cpu/mpc85xx/t1024_ids.c @@ -0,0 +1,82 @@ +/* + * Copyright 2014 Freescale Semiconductor, Inc. + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include +#include
[U-Boot] [PATCH 4/8] net/fman: tune fman 10G driver to fit different SoC
- 10GEC1 uses mEMAC1 on T1024.
- 10GEC1/10GEC2 use mEMAC9/mEMAC10 on T2080/T4240.
- 10GEC3/10GEC4 use mEMAC1/mEMAC2 on T2080.
As there are anomalous naming for 10GEC on earlier SoCs(e.g. T2080/T4240),
now we introduce macro CONFIG_FSL_FM_TGEC_NORMAL_NAMING for those SoC
(e.g. T1024) with inerratic naming for 10GEC to fit different SoC.
Signed-off-by: Shengzhou Liu
---
arch/powerpc/include/asm/config_mpc85xx.h | 1 +
arch/powerpc/include/asm/immap_85xx.h | 5 +
drivers/net/fm/eth.c | 7 +--
drivers/net/fm/init.c | 2 ++
include/fm_eth.h | 15 +++
5 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/config_mpc85xx.h
b/arch/powerpc/include/asm/config_mpc85xx.h
index 73c28da..704a388 100644
--- a/arch/powerpc/include/asm/config_mpc85xx.h
+++ b/arch/powerpc/include/asm/config_mpc85xx.h
@@ -809,6 +809,7 @@ defined(CONFIG_PPC_T1014) || defined(CONFIG_PPC_T1013)
#define CONFIG_SYS_NUM_FMAN1
#define CONFIG_SYS_NUM_FM1_DTSEC 4
#define CONFIG_SYS_NUM_FM1_10GEC 1
+#define CONFIG_FSL_FM_TGEC_NORMAL_NAMING
#define CONFIG_NUM_DDR_CONTROLLERS 1
#define CONFIG_USB_MAX_CONTROLLER_COUNT2
#define CONFIG_SYS_FSL_DDR_VER FSL_DDR_VER_5_0
diff --git a/arch/powerpc/include/asm/immap_85xx.h
b/arch/powerpc/include/asm/immap_85xx.h
index c267da9..2128999 100644
--- a/arch/powerpc/include/asm/immap_85xx.h
+++ b/arch/powerpc/include/asm/immap_85xx.h
@@ -1625,10 +1625,15 @@ typedef struct ccsr_gur {
#define FSL_CORENET_DEVDISR2_DTSEC1_6 0x0400
#define FSL_CORENET_DEVDISR2_DTSEC1_9 0x0080
#define FSL_CORENET_DEVDISR2_DTSEC1_10 0x0040
+#ifdef CONFIG_FSL_FM_TGEC_NORMAL_NAMING
+#define FSL_CORENET_DEVDISR2_10GEC1_1 0x8000
+#define FSL_CORENET_DEVDISR2_10GEC1_2 0x4000
+#else
#define FSL_CORENET_DEVDISR2_10GEC1_1 0x0080
#define FSL_CORENET_DEVDISR2_10GEC1_2 0x0040
#define FSL_CORENET_DEVDISR2_10GEC1_3 0x8000
#define FSL_CORENET_DEVDISR2_10GEC1_4 0x4000
+#endif
#define FSL_CORENET_DEVDISR2_DTSEC2_1 0x0008
#define FSL_CORENET_DEVDISR2_DTSEC2_2 0x0004
#define FSL_CORENET_DEVDISR2_DTSEC2_3 0x0002
diff --git a/drivers/net/fm/eth.c b/drivers/net/fm/eth.c
index 137886c..5ebc775 100644
--- a/drivers/net/fm/eth.c
+++ b/drivers/net/fm/eth.c
@@ -565,9 +565,11 @@ static int fm_eth_init_mac(struct fm_eth *fm_eth, struct
ccsr_fman *reg)
num = fm_eth->num;
#ifdef CONFIG_SYS_FMAN_V3
+#ifndef CONFIG_FSL_FM_TGEC_NORMAL_NAMING
if (fm_eth->type == FM_ETH_10G_E) {
- /* 10GEC1/10GEC2 use mEMAC9/mEMAC10
-* 10GEC3/10GEC4 use mEMAC1/mEMAC2
+ /* 10GEC1/10GEC2 use mEMAC9/mEMAC10 on T2080/T4240.
+* 10GEC3/10GEC4 use mEMAC1/mEMAC2 on T2080.
+* 10GEC1 uses mEMAC1 on T1024.
* so it needs to change the num.
*/
if (fm_eth->num >= 2)
@@ -575,6 +577,7 @@ static int fm_eth_init_mac(struct fm_eth *fm_eth, struct
ccsr_fman *reg)
else
num += 8;
}
+#endif
base = ®->memac[num].fm_memac;
phyregs = ®->memac[num].fm_memac_mdio;
#else
diff --git a/drivers/net/fm/init.c b/drivers/net/fm/init.c
index 6cf21c6..5d82f29 100644
--- a/drivers/net/fm/init.c
+++ b/drivers/net/fm/init.c
@@ -254,8 +254,10 @@ static void ft_fixup_port(void *blob, struct fm_eth_info
*info, char *prop)
*/
if (((info->port == FM1_DTSEC9) && (PORT_IS_ENABLED(FM1_10GEC1))) ||
((info->port == FM1_DTSEC10) && (PORT_IS_ENABLED(FM1_10GEC2))) ||
+ ((info->port == FM1_DTSEC1) && (PORT_IS_ENABLED(FM1_10GEC1))) ||
((info->port == FM1_DTSEC1) && (PORT_IS_ENABLED(FM1_10GEC3))) ||
((info->port == FM1_DTSEC2) && (PORT_IS_ENABLED(FM1_10GEC4))) ||
+ ((info->port == FM1_10GEC1) && (PORT_IS_ENABLED(FM1_DTSEC1))) ||
((info->port == FM1_10GEC1) && (PORT_IS_ENABLED(FM1_DTSEC9))) ||
((info->port == FM1_10GEC2) && (PORT_IS_ENABLED(FM1_DTSEC10))) ||
((info->port == FM1_10GEC3) && (PORT_IS_ENABLED(FM1_DTSEC1))) ||
diff --git a/include/fm_eth.h b/include/fm_eth.h
index e46a684..5cd1895 100644
--- a/include/fm_eth.h
+++ b/include/fm_eth.h
@@ -75,6 +75,20 @@ enum fm_eth_type {
offsetof(struct ccsr_fman, memac[n-1]),\
}
+#ifdef CONFIG_FSL_FM_TGEC_NORMAL_NAMING
+#define FM_TGEC_INFO_INITIALIZER(idx, n) \
+{ \
+ FM_ETH_INFO_INITIALIZER(idx, CONFIG_SYS_FM1_TGEC_MDIO_ADDR) \
+ .index = idx, \
+ .num= n - 1,\
+ .type = FM_ETH_10G_E, \
+ .port = FM##idx##_10GEC##n, \
+
[U-Boot] [PATCH 2/8] powerpc/t1024qds: Add T1024 QDS board support
T1024QDS is a high-performance computing evaluation, development and test platform for T1024 QorIQ Power Architecture processor. T1024QDS board Overview --- - T1024 SoC integrating two 64-bit e5500 cores up to 1.4GHz - CoreNet fabric supporting coherent and noncoherent transactions with prioritization and bandwidth allocation - 32-/64-bit DDR3L/DDR4 SDRAM memory controller with ECC and interleaving support - Accelerator: DPAA components consist of FMan, BMan, QMan, PME, DCE and SEC - Ethernet interfaces: - Two 10M/100M/1G RGMII ports on-board - Three 1G/2.5Gbps SGMII ports - Four 1Gbps QSGMII ports - one 10Gbps XFI or 10Base-KR interface - SerDes: 4 lanes up to 10.3125GHz Supporting SGMII/QSGMII, XFI, PCIe, SATA and Aurora - PCIe: Three PCI Express controllers with five PCIe slots. - IFC: 128MB NOR Flash, 2GB NAND Flash, PromJet debug port and Qixis FPGA - Video: DIU supports video up to 1280x1024x32 bpp. - Chrontel CH7201 for HDMI connection. - TI DS90C387R for direct LCD connection. - Raw (not encoded) video connector for testing or other encoders. - QUICC Engine block - 32-bit RISC controller for flexible support of the communications peripherals - Serial DMA channel for receive and transmit on all serial channels - Two universal communication controllers, supporting TDM, HDLC, and UART - Deep Sleep power implementaion (wakeup from GPIO/Timer/Ethernet/USB) - eSPI: Three SPI flash devices. - SATA: one SATA 2.O. - USB: Two USB2.0 ports with internal PHY (one Type-A + one micro Type mini-AB) - eSDHC: Support SD, SDHC, SDXC and MMC/eMMC. - I2C: Four I2C controllers. - UART: Two UART on board. Signed-off-by: Shengzhou Liu --- arch/powerpc/cpu/mpc85xx/Kconfig | 4 + board/freescale/t102xqds/Kconfig | 12 + board/freescale/t102xqds/MAINTAINERS | 17 + board/freescale/t102xqds/Makefile | 17 + board/freescale/t102xqds/README | 328 +++ board/freescale/t102xqds/ddr.c| 170 ++ board/freescale/t102xqds/diu.c| 217 +++ board/freescale/t102xqds/eth_t102xqds.c | 442 ++ board/freescale/t102xqds/law.c| 32 + board/freescale/t102xqds/pci.c| 23 + board/freescale/t102xqds/spl.c| 151 + board/freescale/t102xqds/t1024_pbi.cfg| 26 + board/freescale/t102xqds/t1024_rcw.cfg| 10 + board/freescale/t102xqds/t102xqds.c | 319 ++ board/freescale/t102xqds/t102xqds.h | 14 + board/freescale/t102xqds/t102xqds_qixis.h | 61 ++ board/freescale/t102xqds/tlb.c| 117 configs/T1024QDS_D4_SECURE_BOOT_defconfig | 4 + configs/T1024QDS_NAND_defconfig | 5 + configs/T1024QDS_SDCARD_defconfig | 5 + configs/T1024QDS_SECURE_BOOT_defconfig| 4 + configs/T1024QDS_SPIFLASH_defconfig | 5 + include/configs/T102xQDS.h| 935 ++ 23 files changed, 2918 insertions(+) create mode 100644 board/freescale/t102xqds/Kconfig create mode 100644 board/freescale/t102xqds/MAINTAINERS create mode 100644 board/freescale/t102xqds/Makefile create mode 100644 board/freescale/t102xqds/README create mode 100644 board/freescale/t102xqds/ddr.c create mode 100644 board/freescale/t102xqds/diu.c create mode 100644 board/freescale/t102xqds/eth_t102xqds.c create mode 100644 board/freescale/t102xqds/law.c create mode 100644 board/freescale/t102xqds/pci.c create mode 100644 board/freescale/t102xqds/spl.c create mode 100644 board/freescale/t102xqds/t1024_pbi.cfg create mode 100644 board/freescale/t102xqds/t1024_rcw.cfg create mode 100644 board/freescale/t102xqds/t102xqds.c create mode 100644 board/freescale/t102xqds/t102xqds.h create mode 100644 board/freescale/t102xqds/t102xqds_qixis.h create mode 100644 board/freescale/t102xqds/tlb.c create mode 100644 configs/T1024QDS_D4_SECURE_BOOT_defconfig create mode 100644 configs/T1024QDS_NAND_defconfig create mode 100644 configs/T1024QDS_SDCARD_defconfig create mode 100644 configs/T1024QDS_SECURE_BOOT_defconfig create mode 100644 configs/T1024QDS_SPIFLASH_defconfig create mode 100644 include/configs/T102xQDS.h diff --git a/arch/powerpc/cpu/mpc85xx/Kconfig b/arch/powerpc/cpu/mpc85xx/Kconfig index 8c1c01c..64331de 100644 --- a/arch/powerpc/cpu/mpc85xx/Kconfig +++ b/arch/powerpc/cpu/mpc85xx/Kconfig @@ -100,6 +100,9 @@ config TARGET_P2041RDB config TARGET_QEMU_PPCE500 bool "Support qemu-ppce500" +config TARGET_T102XQDS + bool "Support T102xQDS" + config TARGET_T1040QDS bool "Support T1040QDS" @@ -170,6 +173,7 @@ source "board/freescale/p2020come/Kconfig" source "board/freescale/p2020ds/Kconfig" source "board/freescale/p2041rdb/Kconfig" source "board/freescale/qemu-ppce500/Kconfig" +source "board/freescale/t102xqds/Kconfig" source "board/freescale/t1040qds/Kconfig" source "board/freescale/t104xrdb/Kconfig" source "board/freescale/t208xqds/Kconfig" diff --git a/board/fre
[U-Boot] [PATCH 7/8] t1024: increase IO drive strength
Increase IO drive strength to fix FCS error on RGMII ports
on T1024QDS and T1024RDB.
Signed-off-by: Shengzhou Liu
---
arch/powerpc/include/asm/immap_85xx.h | 3 +++
board/freescale/t102xqds/t102xqds.c | 4
board/freescale/t102xrdb/t102xrdb.c | 3 +++
3 files changed, 10 insertions(+)
diff --git a/arch/powerpc/include/asm/immap_85xx.h
b/arch/powerpc/include/asm/immap_85xx.h
index 2128999..bf3adc7 100644
--- a/arch/powerpc/include/asm/immap_85xx.h
+++ b/arch/powerpc/include/asm/immap_85xx.h
@@ -1802,6 +1802,7 @@ defined(CONFIG_PPC_T1020) || defined(CONFIG_PPC_T1022)
#define FSL_CORENET_RCWSR13_EC20x0c00
#define FSL_CORENET_RCWSR13_EC2_RGMII 0x0800
#define CONFIG_SYS_FSL_SCFG_PIXCLKCR_OFFSET0x28
+#define CONFIG_SYS_FSL_SCFG_IODSECR1_OFFSET0xd00
#define PXCKEN_MASK0x8000
#define PXCK_MASK 0x00FF
#define PXCK_BITS_START16
@@ -3051,6 +3052,8 @@ struct ccsr_sfp_regs {
(CONFIG_SYS_CCSRBAR + CONFIG_SYS_FSL_SCFG_OFFSET)
#define CONFIG_SYS_FSL_SCFG_PIXCLK_ADDR\
(CONFIG_SYS_FSL_SCFG_ADDR + CONFIG_SYS_FSL_SCFG_PIXCLKCR_OFFSET)
+#define CONFIG_SYS_FSL_SCFG_IODSECR1_ADDR \
+ (CONFIG_SYS_FSL_SCFG_ADDR + CONFIG_SYS_FSL_SCFG_IODSECR1_OFFSET)
#define CONFIG_SYS_FSL_QMAN_ADDR \
(CONFIG_SYS_IMMR + CONFIG_SYS_FSL_QMAN_OFFSET)
#define CONFIG_SYS_FSL_BMAN_ADDR \
diff --git a/board/freescale/t102xqds/t102xqds.c
b/board/freescale/t102xqds/t102xqds.c
index f7fc869..013024e 100644
--- a/board/freescale/t102xqds/t102xqds.c
+++ b/board/freescale/t102xqds/t102xqds.c
@@ -220,6 +220,10 @@ int board_early_init_r(void)
#endif
select_i2c_ch_pca9547(I2C_MUX_CH_DEFAULT);
board_mux_lane_to_slot();
+
+ /* Increase IO drive strength to address FCS error on RGMII */
+ out_be32((unsigned *)CONFIG_SYS_FSL_SCFG_IODSECR1_ADDR, 0xbfdb7800);
+
return 0;
}
diff --git a/board/freescale/t102xrdb/t102xrdb.c
b/board/freescale/t102xrdb/t102xrdb.c
index b1211d7..f1e19c4 100644
--- a/board/freescale/t102xrdb/t102xrdb.c
+++ b/board/freescale/t102xrdb/t102xrdb.c
@@ -87,6 +87,9 @@ int board_early_init_r(void)
setup_portals();
#endif
+ /* Increase IO drive strength to address FCS error on RGMII */
+ out_be32((unsigned *)CONFIG_SYS_FSL_SCFG_IODSECR1_ADDR, 0xbfdb7800);
+
return 0;
}
--
2.1.0.27.g96db324
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/8] board/t1024qds: some update for pin mux
1. add fdt_fixup_spi_mux() for spi mux between SPI flash and TDM riser.
2. if "adaptor=sdxc" is set in hwconfig, route spi pin to SDHC slot.
3. if "pin_mux=tdm" is set in hwconfig, route spi pin to TDM Riser Card.
Signed-off-by: Shengzhou Liu
Signed-off-by: Xie Xiaobo
Signed-off-by: Zhao Qiang
---
board/freescale/t102xqds/t102xqds.c | 26 ++
board/freescale/t102xqds/t102xqds_qixis.h | 7 +--
2 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/board/freescale/t102xqds/t102xqds.c
b/board/freescale/t102xqds/t102xqds.c
index f7af332..f7fc869 100644
--- a/board/freescale/t102xqds/t102xqds.c
+++ b/board/freescale/t102xqds/t102xqds.c
@@ -165,6 +165,8 @@ static void board_mux_setup(void)
/* Route QE_TDM multiplexed signals to TDM Riser slot */
QIXIS_WRITE(brdcfg[15], brdcfg15 | BRDCFG15_DIUSEL_TDM);
QIXIS_WRITE(brdcfg[13], BRDCFG13_TDM_INTERFACE << 2);
+ QIXIS_WRITE(brdcfg[5], (QIXIS_READ(brdcfg[5]) &
+ ~BRDCFG5_SPIRTE_MASK) | BRDCFG5_SPIRTE_TDM);
} else if (hwconfig_arg_cmp("pin_mux", "ucc")) {
/* to UCC (ProfiBus) interface */
QIXIS_WRITE(brdcfg[15], brdcfg15 | BRDCFG15_DIUSEL_UCC);
@@ -176,6 +178,11 @@ static void board_mux_setup(void)
QIXIS_WRITE(brdcfg[15], brdcfg15 | BRDCFG15_LCDFM |
BRDCFG15_LCDPD | BRDCFG15_DIUSEL_LCD);
}
+
+ if (hwconfig_arg_cmp("adaptor", "sdxc"))
+ /* Route SPI_CS multiplexed signals to SD slot */
+ QIXIS_WRITE(brdcfg[5], (QIXIS_READ(brdcfg[5]) &
+ ~BRDCFG5_SPIRTE_MASK) | BRDCFG5_SPIRTE_SDHC);
}
#endif
@@ -265,6 +272,24 @@ int misc_init_r(void)
return 0;
}
+void fdt_fixup_spi_mux(void *blob)
+{
+ int nodeoff = 0;
+
+ if (hwconfig_arg_cmp("pin_mux", "tdm")) {
+ while ((nodeoff = fdt_node_offset_by_compatible(blob, 0,
+ "eon,en25s64")) >= 0) {
+ fdt_del_node(blob, nodeoff);
+ }
+ } else {
+ /* remove tdm node */
+ while ((nodeoff = fdt_node_offset_by_compatible(blob, 0,
+ "maxim,ds26522")) >= 0) {
+ fdt_del_node(blob, nodeoff);
+ }
+ }
+}
+
void ft_board_setup(void *blob, bd_t *bd)
{
phys_addr_t base;
@@ -291,6 +316,7 @@ void ft_board_setup(void *blob, bd_t *bd)
fdt_fixup_fman_ethernet(blob);
fdt_fixup_board_enet(blob);
#endif
+ fdt_fixup_spi_mux(blob);
}
void qixis_dump_switch(void)
diff --git a/board/freescale/t102xqds/t102xqds_qixis.h
b/board/freescale/t102xqds/t102xqds_qixis.h
index ad83f03..a429fb7 100644
--- a/board/freescale/t102xqds/t102xqds_qixis.h
+++ b/board/freescale/t102xqds/t102xqds_qixis.h
@@ -17,6 +17,9 @@
#define BRDCFG5_IMX_MASK 0xC0
#define BRDCFG5_IMX_DIU0x80
+#define BRDCFG5_SPIRTE_MASK0x07
+#define BRDCFG5_SPIRTE_TDM 0x01
+#define BRDCFG5_SPIRTE_SDHC0x02
#define BRDCFG9_XFI_TX_DISABLE 0x10
/* BRDCFG13[0:5] TDM configuration and setup */
@@ -35,8 +38,8 @@
#define BRDCFG15_DIUSEL_MASK 0x03
#define BRDCFG15_DIUSEL_HDMI 0x00
#define BRDCFG15_DIUSEL_LCD0x01
-#define BRDCFG15_DIUSEL_UCC0x10
-#define BRDCFG15_DIUSEL_TDM0x11
+#define BRDCFG15_DIUSEL_UCC0x02
+#define BRDCFG15_DIUSEL_TDM0x03
/* SYSCLK */
#define QIXIS_SYSCLK_660x0
--
2.1.0.27.g96db324
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 8/8] board/t1024qds: add retimer support on t1024qds
Initialize retimer for XFI on t1024qds.
Signed-off-by: Shengzhou Liu
---
board/freescale/t102xqds/t102xqds.c | 57 +
include/configs/T102xQDS.h | 5 +++-
2 files changed, 61 insertions(+), 1 deletion(-)
diff --git a/board/freescale/t102xqds/t102xqds.c
b/board/freescale/t102xqds/t102xqds.c
index 013024e..1398663 100644
--- a/board/freescale/t102xqds/t102xqds.c
+++ b/board/freescale/t102xqds/t102xqds.c
@@ -186,6 +186,62 @@ static void board_mux_setup(void)
}
#endif
+void board_retimer_init(void)
+{
+ u8 reg;
+
+ /* Retimer is connected to I2C1_CH7_CH5 */
+ reg = I2C_MUX_CH7;
+ i2c_write(I2C_MUX_PCA_ADDR_PRI, 0, 1, ®, 1);
+ reg = I2C_MUX_CH5;
+ i2c_write(I2C_MUX_PCA_ADDR_SEC, 0, 1, ®, 1);
+
+ /* Access to Control/Shared register */
+ reg = 0x0;
+ i2c_write(I2C_RETIMER_ADDR, 0xff, 1, ®, 1);
+
+ /* Read device revision and ID */
+ i2c_read(I2C_RETIMER_ADDR, 1, 1, ®, 1);
+ debug("Retimer version id = 0x%x\n", reg);
+
+ /* Enable Broadcast. All writes target all channel register sets */
+ reg = 0x0c;
+ i2c_write(I2C_RETIMER_ADDR, 0xff, 1, ®, 1);
+
+ /* Reset Channel Registers */
+ i2c_read(I2C_RETIMER_ADDR, 0, 1, ®, 1);
+ reg |= 0x4;
+ i2c_write(I2C_RETIMER_ADDR, 0, 1, ®, 1);
+
+ /* Enable override divider select and Enable Override Output Mux */
+ i2c_read(I2C_RETIMER_ADDR, 9, 1, ®, 1);
+ reg |= 0x24;
+ i2c_write(I2C_RETIMER_ADDR, 9, 1, ®, 1);
+
+ /* Select VCO Divider to full rate (000) */
+ i2c_read(I2C_RETIMER_ADDR, 0x18, 1, ®, 1);
+ reg &= 0x8f;
+ i2c_write(I2C_RETIMER_ADDR, 0x18, 1, ®, 1);
+
+ /* Selects active PFD MUX Input as Re-timed Data (001) */
+ i2c_read(I2C_RETIMER_ADDR, 0x1e, 1, ®, 1);
+ reg &= 0x3f;
+ reg |= 0x20;
+ i2c_write(I2C_RETIMER_ADDR, 0x1e, 1, ®, 1);
+
+ /* Set data rate as 10.3125 Gbps */
+ reg = 0x0;
+ i2c_write(I2C_RETIMER_ADDR, 0x60, 1, ®, 1);
+ reg = 0xb2;
+ i2c_write(I2C_RETIMER_ADDR, 0x61, 1, ®, 1);
+ reg = 0x90;
+ i2c_write(I2C_RETIMER_ADDR, 0x62, 1, ®, 1);
+ reg = 0xb3;
+ i2c_write(I2C_RETIMER_ADDR, 0x63, 1, ®, 1);
+ reg = 0xcd;
+ i2c_write(I2C_RETIMER_ADDR, 0x64, 1, ®, 1);
+}
+
int board_early_init_r(void)
{
#ifdef CONFIG_SYS_FLASH_BASE
@@ -220,6 +276,7 @@ int board_early_init_r(void)
#endif
select_i2c_ch_pca9547(I2C_MUX_CH_DEFAULT);
board_mux_lane_to_slot();
+ board_retimer_init();
/* Increase IO drive strength to address FCS error on RGMII */
out_be32((unsigned *)CONFIG_SYS_FSL_SCFG_IODSECR1_ADDR, 0xbfdb7800);
diff --git a/include/configs/T102xQDS.h b/include/configs/T102xQDS.h
index 5f8f749..fe24181 100644
--- a/include/configs/T102xQDS.h
+++ b/include/configs/T102xQDS.h
@@ -554,11 +554,14 @@ unsigned long get_board_ddr_clk(void);
#define I2C_MUX_PCA_ADDR 0x77
#define I2C_MUX_PCA_ADDR_PRI 0x77 /* Primary Mux*/
-
+#define I2C_MUX_PCA_ADDR_SEC0x76 /* Secondary multiplexer */
+#define I2C_RETIMER_ADDR 0x18
/* I2C bus multiplexer */
#define I2C_MUX_CH_DEFAULT 0x8
#define I2C_MUX_CH_DIU 0xC
+#define I2C_MUX_CH50xD
+#define I2C_MUX_CH70xF
/* LDI/DVI Encoder for display */
#define CONFIG_SYS_I2C_LDI_ADDR 0x38
--
2.1.0.27.g96db324
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/8] net/phy: enable serdes autonegotiation for vsc8514 phy
QSGMII doesn't work without enabling serdes auto-negotiation. Signed-off-by: Shengzhou Liu --- drivers/net/phy/vitesse.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/net/phy/vitesse.c b/drivers/net/phy/vitesse.c index 2b29cd8..5b2e11a 100644 --- a/drivers/net/phy/vitesse.c +++ b/drivers/net/phy/vitesse.c @@ -50,6 +50,7 @@ #define MIIM_VSC8574_18G_CMDSTAT 0x8000 /* Vitesse VSC8514 control register */ +#define MIIM_VSC8514_MAC_SERDES_CON 0x10 #define MIIM_VSC8514_GENERAL18 0x12 #define MIIM_VSC8514_GENERAL19 0x13 #define MIIM_VSC8514_GENERAL23 0x17 @@ -246,6 +247,14 @@ static int vsc8514_config(struct phy_device *phydev) val = (val & 0xf8ff); phy_write(phydev, MDIO_DEVAD_NONE, MIIM_VSC8514_GENERAL23, val); + /* Enable Serdes Auto-negotiation */ + phy_write(phydev, MDIO_DEVAD_NONE, PHY_EXT_PAGE_ACCESS, + PHY_EXT_PAGE_ACCESS_EXTENDED3); + val = phy_read(phydev, MDIO_DEVAD_NONE, MIIM_VSC8514_MAC_SERDES_CON); + val = val | MIIM_VSC8574_MAC_SERDES_ANEG; + phy_write(phydev, MDIO_DEVAD_NONE, MIIM_VSC8514_MAC_SERDES_CON, val); + phy_write(phydev, MDIO_DEVAD_NONE, PHY_EXT_PAGE_ACCESS, 0); + genphy_config_aneg(phydev); return 0; -- 2.1.0.27.g96db324 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/8] powerpc/t1024rdb: Add T1024 RDB board support
T1024RDB is a Freescale Reference Design Board that hosts the T1024 SoC. T1024RDB board Overview --- - T1024 SoC integrating two 64-bit e5500 cores up to 1.4GHz - CoreNet fabric supporting coherent and noncoherent transactions with prioritization and bandwidth allocation - 32-/64-bit DDR3L SDRAM memory controller with ECC and interleaving support - Accelerator: DPAA components consist of FMan, BMan, QMan, DCE and SEC - Ethernet interfaces: - Two 10M/100M/1G RGMII ports on-board - one 10Gbps XFI interface - PCIe: Three PCIe controllers: one PCIe Slot and two Mini-PCIe connectors. - SerDes: 4 lanes up to 10.3125GHz - IFC: 128MB NOR Flash, 512MB NAND Flash and CPLD - eSPI: 64MB N25Q512 SPI flash. - Deep Sleep power implementaion (wakeup from GPIO/Timer/Ethernet/USB) - USB: Two Type-A USB2.0 ports with internal PHY - eSDHC: Support SD, SDHC, SDXC and MMC/eMMC - I2C: Four I2C controllers - UART: Two UART serial ports Signed-off-by: Shengzhou Liu --- arch/powerpc/cpu/mpc85xx/Kconfig| 4 + board/freescale/t102xrdb/Kconfig| 12 + board/freescale/t102xrdb/MAINTAINERS| 14 + board/freescale/t102xrdb/Makefile | 17 + board/freescale/t102xrdb/README | 258 + board/freescale/t102xrdb/cpld.c | 103 board/freescale/t102xrdb/cpld.h | 45 ++ board/freescale/t102xrdb/ddr.c | 154 ++ board/freescale/t102xrdb/eth_t102xrdb.c | 100 board/freescale/t102xrdb/law.c | 32 ++ board/freescale/t102xrdb/pci.c | 23 + board/freescale/t102xrdb/spl.c | 107 board/freescale/t102xrdb/t1024_pbi.cfg | 26 + board/freescale/t102xrdb/t1024_rcw.cfg | 8 + board/freescale/t102xrdb/t102xrdb.c | 142 + board/freescale/t102xrdb/t102xrdb.h | 13 + board/freescale/t102xrdb/tlb.c | 117 + configs/T1024RDB_NAND_defconfig | 5 + configs/T1024RDB_SDCARD_defconfig | 5 + configs/T1024RDB_SECURE_BOOT_defconfig | 4 + configs/T1024RDB_SPIFLASH_defconfig | 5 + configs/T1024RDB_defconfig | 4 + include/configs/T102xRDB.h | 896 23 files changed, 2094 insertions(+) create mode 100644 board/freescale/t102xrdb/Kconfig create mode 100644 board/freescale/t102xrdb/MAINTAINERS create mode 100644 board/freescale/t102xrdb/Makefile create mode 100644 board/freescale/t102xrdb/README create mode 100644 board/freescale/t102xrdb/cpld.c create mode 100644 board/freescale/t102xrdb/cpld.h create mode 100644 board/freescale/t102xrdb/ddr.c create mode 100644 board/freescale/t102xrdb/eth_t102xrdb.c create mode 100644 board/freescale/t102xrdb/law.c create mode 100644 board/freescale/t102xrdb/pci.c create mode 100644 board/freescale/t102xrdb/spl.c create mode 100644 board/freescale/t102xrdb/t1024_pbi.cfg create mode 100644 board/freescale/t102xrdb/t1024_rcw.cfg create mode 100644 board/freescale/t102xrdb/t102xrdb.c create mode 100644 board/freescale/t102xrdb/t102xrdb.h create mode 100644 board/freescale/t102xrdb/tlb.c create mode 100644 configs/T1024RDB_NAND_defconfig create mode 100644 configs/T1024RDB_SDCARD_defconfig create mode 100644 configs/T1024RDB_SECURE_BOOT_defconfig create mode 100644 configs/T1024RDB_SPIFLASH_defconfig create mode 100644 configs/T1024RDB_defconfig create mode 100644 include/configs/T102xRDB.h diff --git a/arch/powerpc/cpu/mpc85xx/Kconfig b/arch/powerpc/cpu/mpc85xx/Kconfig index 64331de..74b9b7d 100644 --- a/arch/powerpc/cpu/mpc85xx/Kconfig +++ b/arch/powerpc/cpu/mpc85xx/Kconfig @@ -103,6 +103,9 @@ config TARGET_QEMU_PPCE500 config TARGET_T102XQDS bool "Support T102xQDS" +config TARGET_T102XRDB + bool "Support T102xRDB" + config TARGET_T1040QDS bool "Support T1040QDS" @@ -174,6 +177,7 @@ source "board/freescale/p2020ds/Kconfig" source "board/freescale/p2041rdb/Kconfig" source "board/freescale/qemu-ppce500/Kconfig" source "board/freescale/t102xqds/Kconfig" +source "board/freescale/t102xrdb/Kconfig" source "board/freescale/t1040qds/Kconfig" source "board/freescale/t104xrdb/Kconfig" source "board/freescale/t208xqds/Kconfig" diff --git a/board/freescale/t102xrdb/Kconfig b/board/freescale/t102xrdb/Kconfig new file mode 100644 index 000..10d49f5 --- /dev/null +++ b/board/freescale/t102xrdb/Kconfig @@ -0,0 +1,12 @@ +if TARGET_T102XRDB + +config SYS_BOARD + default "t102xrdb" + +config SYS_VENDOR + default "freescale" + +config SYS_CONFIG_NAME + default "T102xRDB" + +endif diff --git a/board/freescale/t102xrdb/MAINTAINERS b/board/freescale/t102xrdb/MAINTAINERS new file mode 100644 index 000..ab1ecca --- /dev/null +++ b/board/freescale/t102xrdb/MAINTAINERS @@ -0,0 +1,14 @@ +T102XRDB BOARD +M: Shengzhou Liu +S: Maintained +F: board/freescale/t102xrdb/ +F: include/configs/T102xRDB.h +F: configs/T1024RDB_defconfig +F: configs/T1024RDB_NAND_defconfig +F: configs/T1024RDB_SDCARD_defco
[U-Boot] [PATCH] tools/kwbimage: Fix compilation warning
This patch fixes a compilation warning of kwbimage.c:
tools/kwbimage.c: In function ‘kwbimage_set_header’:
tools/kwbimage.c:784:8: warning: ‘headersz’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
memcpy(ptr, image, headersz);
^
Instead of using multiple if statements, use a switch statement with
a default entry. And return with error if the VERSION field is
missing in the cfg file.
Signed-off-by: Stefan Roese
---
tools/kwbimage.c | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 1120e9b..91db5d7 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -752,14 +752,26 @@ static void kwbimage_set_header(void *ptr, struct stat
*sbuf, int ifd,
}
version = image_get_version();
- /* Fallback to version 0 is no version is provided in the cfg file */
- if (version == -1)
- version = 0;
-
- if (version == 0)
+ switch (version) {
+ /*
+* Fallback to version 0 is no version is provided in the
+* cfg file
+*/
+ case -1:
+ case 0:
image = image_create_v0(&headersz, params, sbuf->st_size);
- else if (version == 1)
+ break;
+
+ case 1:
image = image_create_v1(&headersz, params, sbuf->st_size);
+ break;
+
+ default:
+ fprintf(stderr, "File %s does not have the VERSION field\n",
+ params->imagename);
+ free(image_cfg);
+ exit(EXIT_FAILURE);
+ }
if (!image) {
fprintf(stderr, "Could not create image\n");
--
2.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PULL] Please pull u-boot-imx
Hi Tom, please pull from u-boot-imx, thanks ! The following changes since commit c43fd23cf619856b0763a64a6a3bcf3663058c49: Prepare v2014.10 (2014-10-14 04:47:15 -0400) are available in the git repository at: git://www.denx.de/git/u-boot-imx.git master for you to fetch changes up to 3f97af5302ee15530411232b464d255eb2ff2ffb: ot1200: add sata support (2014-10-23 10:04:26 +0200) Christian Gmeiner (3): ot1200: remove superfluous "string" tag ot1200: fix sf detection ot1200: add sata support Eric Nelson (4): ARM: prevent compiler warnings from bootm.c ARM: i.MX6: include prototype for get_board_rev() ARM: i.MX: provide declaration for board_spi_cs_gpio ARM: i.MX video: declare displays and display_count publicly Fabio Estevam (2): mx6qsabreauto: Add HDMI support mx6sabre_common: Add HDMI config to common code arch/arm/cpu/armv7/mx6/soc.c | 1 + arch/arm/imx-common/video.c | 3 -- arch/arm/include/asm/imx-common/spi.h | 17 arch/arm/include/asm/imx-common/video.h | 5 +++ arch/arm/lib/bootm.c | 5 ++- board/bachmann/ot1200/Kconfig | 5 --- board/bachmann/ot1200/ot1200.c| 10 + board/boundary/nitrogen6x/nitrogen6x.c| 1 + board/compulab/cm_fx6/common.c| 1 + board/embest/mx6boards/mx6boards.c| 1 + board/freescale/mx6qsabreauto/mx6qsabreauto.c | 61 ++- board/freescale/mx6slevk/mx6slevk.c | 1 + board/gateworks/gw_ventana/gw_ventana.c | 1 + board/genesi/mx51_efikamx/efikamx.c | 1 + board/ttcontrol/vision2/vision2.c | 1 + drivers/spi/mxc_spi.c | 1 + include/configs/mx6sabre_common.h | 17 include/configs/mx6sabresd.h | 17 include/configs/ot1200.h | 2 +- 19 files changed, 123 insertions(+), 28 deletions(-) create mode 100644 arch/arm/include/asm/imx-common/spi.h -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/19] [RFC] Power(full) framework based on Driver Model
Hello Tom, On 10/22/2014 05:31 PM, Tom Rini wrote: On Wed, Oct 08, 2014 at 10:48:36PM +0200, Przemyslaw Marczak wrote: Hello, This piece of code was a base for prepare my presentation talk for the U-Boot Mini Summit, which taking place at ELCE2014 conference, 13-th October 2014 Dusseldorf, Germany. The tittle of talk: "Power(full) framework based on Driver Model" The presentation will be shared after the Summit. This patchset introduces the new one PMIC framework for the U-Boot. It is still under the construction, but the basic functionality was achieved and tested. Please feel free to comment and share the opinion. I think that each patch is described full enough, but for some more design details, please look into the documentation file. It includes some basic examples for the PMIC drivers. Quick summary of: Framework: - The new approach - UCLASS_PMIC - simple and designed for device I/O only - Add new uclass types: UCLASS_PMIC and UCLASS_PMIC_REGULATOR - Two uclass drivers for above types - A common regulator operations - will easy cover the real devices design Drivers: - Introduce new PMIC API for drivers - now everything base on "struct udevice" - Introduce Regulator Voltage descriptors and Operation Mode descriptors which are usually taken from the device tree (board dependent data) - Two uclass device drivers for MAX77686(PMIC+REGULATOR) User Interface: - command pmic, unchanged functionality and ported to the driver model - command regulator(NEW) for safe regulator setup from commandline, - now can check output Voltage and operation mode of the regulators, - also can check the board Voltage limits and driver available modes The future plans: - Wait for the I2c Driver Model implementation - Introduce a common way to bind pmic devices - now done by alias "pmic" - Add additional uclass types: MUIC, CHARGER, BATTERY, MFD and maybe more. - Introduce optimal operations for new uclasses - Port all U-Boot drivers to the new Framework - Remove the old drivers and the old PMIC Framework code The assumptions of this work is: - Add new code to independent files - Keep two Frameworks as independent and without conflicts - Don't mix OLD/NEW Framework code - for the readability - Port all drivers using new API - Remove the old Framework and the old drivers A disadvantage: - some parts of the present code is duplicated Need help: - After merge this, it is welcome to help with driver porting. - Everything should be tested The extra feature: The first commit introduces errno_str() function. It is a common function which I hope will be usefull for commands and not only. If any visible error says: -19 or some other magic number, then it means that this function should be used. U-Boot Mini Summit members: This code is maybe not as good as it could be, but the time was limited, and the conference is comming soon. I don't expects a code review of this now, but it would be nice if you take a look of this piece of code before our U-Boot Mini Summit. Of course it depends on you. Per the mini-summit, please add a patch adding yourself as pmic custodian (so something to doc/git-mailrc, shoot me your patchwork username and Detlev an ssh key so we can get a repo setup). For this series, I'm going to review/ack and I want Simon to pick it up for the DM tree since I think that makes the most sense, yes? Thanks! And for all the patches in the series I don't reply to, they seem fine but aren't for me to ack (being board specific stuff, that looked fine but I don't have the HW) or I just agree with Simon's comments. Ok, so this code will be rebased on to u-boot-dm/i2c-working. And I will send the required informations to you and Detlev. Best Regards, -- Przemyslaw Marczak Samsung R&D 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] gic: fixed compilation error in GICv2 wait for interrupt macro
a hexadicemal value was missing the "0x" prefix which caused assembler error Signed-off-by: Yehuda Yitschak --- arch/arm/include/asm/macro.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/include/asm/macro.h b/arch/arm/include/asm/macro.h index 541b443..1c8c425 100644 --- a/arch/arm/include/asm/macro.h +++ b/arch/arm/include/asm/macro.h @@ -193,7 +193,7 @@ lr .reqx30 0 :wfi ldr \wreg2, [\xreg1, GICC_AIAR] str \wreg2, [\xreg1, GICC_AEOIR] - and \wreg2, \wreg2, #3ff + and \wreg2, \wreg2, #0x3ff cbnz\wreg2, 0b .endm #endif -- 1.8.1.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools/kwbimage: Fix compilation warning
Dear Stefan,
In message <1414412953-25615-1-git-send-email...@denx.de> you wrote:
> This patch fixes a compilation warning of kwbimage.c:
>
> tools/kwbimage.c: In function ‘kwbimage_set_header’:
> tools/kwbimage.c:784:8: warning: ‘headersz’ may be used uninitialized in this
> function [-Wmaybe-uninitialized]
> memcpy(ptr, image, headersz);
> ^
> Instead of using multiple if statements, use a switch statement with
> a default entry. And return with error if the VERSION field is
> missing in the cfg file.
Thanks, but...
> + switch (version) {
> + /*
> + * Fallback to version 0 is no version is provided in the
> + * cfg file
> + */
> + case -1:
> + case 0:
> image = image_create_v0(&headersz, params, sbuf->st_size);
> + break;
> +
> + case 1:
> image = image_create_v1(&headersz, params, sbuf->st_size);
> + break;
> +
> + default:
> + fprintf(stderr, "File %s does not have the VERSION field\n",
> + params->imagename);
> + free(image_cfg);
> + exit(EXIT_FAILURE);
> + }
What exactly is the difference between return code -1 (no version is
provided and you fall back to using version 0), and the default case?
To me these look the same?
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
Wenn Du ein' weise Antwort verlangst, Mußt Du vernünftig fragen.
-- Goethe, Invektiven
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/8] powerpc/t1024qds: Add T1024 QDS board support
Dear Shengzhou Liu, In message <1414411583-45090-2-git-send-email-shengzhou@freescale.com> you wrote: > T1024QDS is a high-performance computing evaluation, development and > test platform for T1024 QorIQ Power Architecture processor. ... > diff --git a/board/freescale/t102xqds/MAINTAINERS > b/board/freescale/t102xqds/MAINTAINERS > new file mode 100644 > index 000..fc09c00 > --- /dev/null > +++ b/board/freescale/t102xqds/MAINTAINERS > @@ -0,0 +1,17 @@ > +T102XQDS BOARD > +M: Shengzhou Liu Please do not add trailing white space. 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 Any fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction. - Albert Einstein ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8] powerpc/t1024rdb: Add T1024 RDB board support
Dear Shengzhou Liu, In message <1414411583-45090-3-git-send-email-shengzhou@freescale.com> you wrote: > T1024RDB is a Freescale Reference Design Board that hosts the T1024 SoC. ... > --- /dev/null > +++ b/board/freescale/t102xrdb/MAINTAINERS > @@ -0,0 +1,14 @@ > +T102XRDB BOARD > +M: Shengzhou Liu Please do not add trailing white space. 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 think it's a new feature. Don't tell anyone it was an accident. :-) -- Larry Wall on s/foo/bar/eieio in <10...@jpl-devvax.jpl.nasa.gov> ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] arm: odroid: usb: add support for usb host including ethernet
Dear Suriyan Ramasami,
On 25/10/14 01:08, Suriyan Ramasami wrote:
> Hello Minkyu Kang,
>
>
> On Thu, Oct 23, 2014 at 9:58 PM, Minkyu Kang wrote:
>> Dear Suriyan Ramasami,
>>
>> On 21/10/14 02:52, Suriyan Ramasami wrote:
>>> This change adds support for enabling the USB host features of the board.
>>> This includes the USB3503A hub and the SMC LAN9730 ethernet controller
>>> as well.
>>>
>>> Credit goes to Tushar Berara for the function set_usb_ethaddr().
>>>
>>> Signed-off-by: Suriyan Ramasami
>>>
>>> ---
>>> v2:
>>> * Removed an unneeded header file from ehci-exynos.c
>>> * Fix indentation in the dts file
>>> ---
>>> arch/arm/dts/exynos4412-odroid.dts | 11 +++
>>> arch/arm/include/asm/arch-exynos/cpu.h | 2 ++
>>> arch/arm/include/asm/arch-exynos/ehci.h | 13
>>> board/samsung/odroid/odroid.c | 55
>>> +
>>> drivers/usb/host/ehci-exynos.c | 51 +-
>>> include/configs/odroid.h| 13
>>> 6 files changed, 137 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/arch/arm/dts/exynos4412-odroid.dts
>>> b/arch/arm/dts/exynos4412-odroid.dts
>>> index 24d0bf1..ac5fece 100644
>>> --- a/arch/arm/dts/exynos4412-odroid.dts
>>> +++ b/arch/arm/dts/exynos4412-odroid.dts
>>> @@ -67,4 +67,15 @@
>>> div = <0x3>;
>>> index = <4>;
>>> };
>>> +
>>> + ehci@1258 {
>>> + compatible = "samsung,exynos-ehci";
>>> + reg = <0x1258 0x100>;
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + phy {
>>> + compatible = "samsung,exynos-usb-phy";
>>> + reg = <0x125B 0x100>;
>>> + };
>>> + };
>>> };
>>> diff --git a/arch/arm/include/asm/arch-exynos/cpu.h
>>> b/arch/arm/include/asm/arch-exynos/cpu.h
>>> index ba71714..fda21fb 100644
>>> --- a/arch/arm/include/asm/arch-exynos/cpu.h
>>> +++ b/arch/arm/include/asm/arch-exynos/cpu.h
>>> @@ -18,6 +18,8 @@
>>>
>>> #define EXYNOS4_GPIO_PART3_BASE 0x0386
>>> #define EXYNOS4_PRO_ID 0x1000
>>> +#define EXYNOS4_GUID_LOW 0x1014
>>> +#define EXYNOS4_GUID_HIGH0x1018
>>> #define EXYNOS4_SYSREG_BASE 0x1001
>>> #define EXYNOS4_POWER_BASE 0x1002
>>> #define EXYNOS4_SWRESET 0x10020400
>>> diff --git a/arch/arm/include/asm/arch-exynos/ehci.h
>>> b/arch/arm/include/asm/arch-exynos/ehci.h
>>> index d2d70bd..3800fa9 100644
>>> --- a/arch/arm/include/asm/arch-exynos/ehci.h
>>> +++ b/arch/arm/include/asm/arch-exynos/ehci.h
>>> @@ -12,6 +12,13 @@
>>>
>>> #define CLK_24MHZ5
>>>
>>> +#define PHYPWR_NORMAL_MASK_PHY0 (0x39 << 0)
>>> +#define PHYPWR_NORMAL_MASK_PHY1 (0x7 << 6)
>>> +#define PHYPWR_NORMAL_MASK_HSIC0(0x7 << 9)
>>> +#define PHYPWR_NORMAL_MASK_HSIC1(0x7 << 12)
>>> +#define RSTCON_HOSTPHY_SWRST(0xf << 3)
>>> +#define RSTCON_SWRST(0x1 << 0)
>>> +
>>> #define HOST_CTRL0_PHYSWRSTALL (1 << 31)
>>> #define HOST_CTRL0_COMMONON_N(1 << 9)
>>> #define HOST_CTRL0_SIDDQ (1 << 6)
>>> @@ -61,6 +68,12 @@ struct exynos_usb_phy {
>>> unsigned int usbotgtune;
>>> };
>>>
>>> +struct exynos4412_usb_phy {
>>> + unsigned int usbphyctrl;
>>> + unsigned int usbphyclk;
>>> + unsigned int usbphyrstcon;
>>> +};
>>> +
>>> /* Switch on the VBUS power. */
>>> int board_usb_vbus_init(void);
>>>
>>> diff --git a/board/samsung/odroid/odroid.c b/board/samsung/odroid/odroid.c
>>> index 5edb250..6c78b67 100644
>>> --- a/board/samsung/odroid/odroid.c
>>> +++ b/board/samsung/odroid/odroid.c
>>> @@ -453,9 +453,64 @@ struct s3c_plat_otg_data s5pc210_otg_data = {
>>> .usb_phy_ctrl = EXYNOS4X12_USBPHY_CONTROL,
>>> .usb_flags = PHY0_SLEEP,
>>> };
>>> +#endif
>>> +
>>> +#if defined(CONFIG_USB_GADGET) || defined(CONFIG_CMD_USB)
>>> +
>>> +#ifdef CONFIG_CMD_USB
>>> +static void set_usb_ethaddr(void)
>>> +{
>>> + int i;
>>> + uchar mac[6];
>>> + unsigned int guid_high = readl(EXYNOS4_GUID_HIGH);
>>> + unsigned int guid_low = readl(EXYNOS4_GUID_LOW);
>>
>> We don't allow direct access.
>> Is it special register? I can't find this register on TRM.
>> If so you can make inline function at cpu.h instead.
>>
>
> This register is not in the TRM. This register is possibly documented
> in the TRM for the Exynos5250. Through experimentation I found that it
> behaves the same on Exynos4412 prime as well - I checked this with one
> X2, 1 U2 and 2 U3s, and they do indeed do the job of being unique and
> hence can be used to generate the mac address which will be unique
> across all U2s/U3s/X2s and possibly other Exynos SoCs like Exynos4212
> etc.
>
> Regarding direct access, I am a bit confused
Re: [U-Boot] [PATCH] gic: fixed compilation error in GICv2 wait for interrupt macro
Hello Yehuda, On Mon, 27 Oct 2014 14:07:16 +0200, Yehuda Yitschak wrote: > a hexadicemal value was missing the "0x" prefix which caused > assembler error > > Signed-off-by: Yehuda Yitschak > --- > arch/arm/include/asm/macro.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/include/asm/macro.h b/arch/arm/include/asm/macro.h > index 541b443..1c8c425 100644 > --- a/arch/arm/include/asm/macro.h > +++ b/arch/arm/include/asm/macro.h > @@ -193,7 +193,7 @@ lr.reqx30 > 0 : wfi > ldr \wreg2, [\xreg1, GICC_AIAR] > str \wreg2, [\xreg1, GICC_AEOIR] > - and \wreg2, \wreg2, #3ff > + and \wreg2, \wreg2, #0x3ff > cbnz\wreg2, 0b > .endm > #endif > -- > 1.8.1.2 Which board(s) does this error show up in? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools/kwbimage: Fix compilation warning
Hi Wolfgang,
On 27.10.2014 13:57, Wolfgang Denk wrote:
tools/kwbimage.c: In function ‘kwbimage_set_header’:
tools/kwbimage.c:784:8: warning: ‘headersz’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
memcpy(ptr, image, headersz);
^
Instead of using multiple if statements, use a switch statement with
a default entry. And return with error if the VERSION field is
missing in the cfg file.
Thanks, but...
+ switch (version) {
+ /*
+* Fallback to version 0 is no version is provided in the
+* cfg file
+*/
+ case -1:
+ case 0:
image = image_create_v0(&headersz, params, sbuf->st_size);
+ break;
+
+ case 1:
image = image_create_v1(&headersz, params, sbuf->st_size);
+ break;
+
+ default:
+ fprintf(stderr, "File %s does not have the VERSION field\n",
+ params->imagename);
+ free(image_cfg);
+ exit(EXIT_FAILURE);
+ }
What exactly is the difference between return code -1 (no version is
provided and you fall back to using version 0), and the default case?
To me these look the same?
Perhaps the error message is a bit misleading. The "default:" case is
for unsupported versions. E.g. if "VERSION 3" would have been provided
in the cfg file.
Should I rephrase the error message in the next patch version? To
something like this:
fprintf(stderr, "Unsupported VERSION %d\n", version);
Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] git-mailrc: add pmic custodian
This adds custodian to the pmic subsystem. Signed-off-by: Przemyslaw Marczak Cc: Tom Rini --- doc/git-mailrc | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/git-mailrc b/doc/git-mailrc index 35f2eb2..ad22763 100644 --- a/doc/git-mailrc +++ b/doc/git-mailrc @@ -31,6 +31,7 @@ alias masahiro Masahiro Yamada alias monstr Michal Simek alias panto Pantelis Antoniou alias prafulla Prafulla Wadaskar +alias bobenstein Przemyslaw Marczak alias prom Minkyu Kang alias rbohmerRemy Bohmer alias reinhardm Reinhard Meyer @@ -122,3 +123,4 @@ alias usbuboot, marex alias video uboot, ag alias patman uboot, sjg alias buildman uboot, sjg +alias pmic uboot, bobenstein -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] powerpc: TQM5200: convert to generic board
Signed-off-by: Wolfgang Denk --- include/configs/TQM5200.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/include/configs/TQM5200.h b/include/configs/TQM5200.h index 69c0336..cdccbef 100644 --- a/include/configs/TQM5200.h +++ b/include/configs/TQM5200.h @@ -1,5 +1,5 @@ /* - * (C) Copyright 2003-2005 + * (C) Copyright 2003-2014 * Wolfgang Denk, DENX Software Engineering, w...@denx.de. * * (C) Copyright 2004-2006 @@ -19,6 +19,8 @@ #define CONFIG_MPC5200 1 /* This is an MPC5200 CPU */ #define CONFIG_TQM5200 1 /* ... on TQM5200 module */ #undef CONFIG_TQM5200_REV100 /* define for revision 100 modules */ +#define CONFIG_SYS_GENERIC_BOARD +#define CONFIG_DISPLAY_BOARDINFO /* * Valid values for CONFIG_SYS_TEXT_BASE are: -- 1.8.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] powerpc: tqm8xx*: convert to generic board
This converts all TQM8xx boards (MPC8xx based) to generic board. Signed-off-by: Wolfgang Denk --- include/configs/TQM823L.h | 4 +++- include/configs/TQM823M.h | 4 +++- include/configs/TQM850L.h | 4 +++- include/configs/TQM850M.h | 4 +++- include/configs/TQM855L.h | 4 +++- include/configs/TQM855M.h | 4 +++- include/configs/TQM860L.h | 4 +++- include/configs/TQM860M.h | 4 +++- include/configs/TQM862L.h | 4 +++- include/configs/TQM862M.h | 4 +++- include/configs/TQM866M.h | 4 +++- include/configs/TQM885D.h | 4 +++- 12 files changed, 36 insertions(+), 12 deletions(-) diff --git a/include/configs/TQM823L.h b/include/configs/TQM823L.h index cc22045..0d5a2b9 100644 --- a/include/configs/TQM823L.h +++ b/include/configs/TQM823L.h @@ -1,5 +1,5 @@ /* - * (C) Copyright 2000-2008 + * (C) Copyright 2000-2014 * Wolfgang Denk, DENX Software Engineering, w...@denx.de. * * SPDX-License-Identifier:GPL-2.0+ @@ -19,6 +19,8 @@ #define CONFIG_MPC823 1 /* This is a MPC823 CPU */ #define CONFIG_TQM823L 1 /* ...on a TQM8xxL module */ +#define CONFIG_SYS_GENERIC_BOARD +#define CONFIG_DISPLAY_BOARDINFO #defineCONFIG_SYS_TEXT_BASE0x4000 diff --git a/include/configs/TQM823M.h b/include/configs/TQM823M.h index 4fd070f..e765a03 100644 --- a/include/configs/TQM823M.h +++ b/include/configs/TQM823M.h @@ -1,5 +1,5 @@ /* - * (C) Copyright 2000-2008 + * (C) Copyright 2000-2014 * Wolfgang Denk, DENX Software Engineering, w...@denx.de. * * SPDX-License-Identifier:GPL-2.0+ @@ -19,6 +19,8 @@ #define CONFIG_MPC823 1 /* This is a MPC823 CPU */ #define CONFIG_TQM823M 1 /* ...on a TQM8xxM module */ +#define CONFIG_SYS_GENERIC_BOARD +#define CONFIG_DISPLAY_BOARDINFO #defineCONFIG_SYS_TEXT_BASE0x4000 diff --git a/include/configs/TQM850L.h b/include/configs/TQM850L.h index ca3750d..bbdc3f8 100644 --- a/include/configs/TQM850L.h +++ b/include/configs/TQM850L.h @@ -1,5 +1,5 @@ /* - * (C) Copyright 2000-2008 + * (C) Copyright 2000-2014 * Wolfgang Denk, DENX Software Engineering, w...@denx.de. * * SPDX-License-Identifier:GPL-2.0+ @@ -19,6 +19,8 @@ #define CONFIG_MPC850 1 /* This is a MPC850 CPU */ #define CONFIG_TQM850L 1 /* ...on a TQM8xxL module */ +#define CONFIG_SYS_GENERIC_BOARD +#define CONFIG_DISPLAY_BOARDINFO #defineCONFIG_SYS_TEXT_BASE0x4000 diff --git a/include/configs/TQM850M.h b/include/configs/TQM850M.h index 659c9ad..5fc87f2 100644 --- a/include/configs/TQM850M.h +++ b/include/configs/TQM850M.h @@ -1,5 +1,5 @@ /* - * (C) Copyright 2000-2008 + * (C) Copyright 2000-2014 * Wolfgang Denk, DENX Software Engineering, w...@denx.de. * * SPDX-License-Identifier:GPL-2.0+ @@ -19,6 +19,8 @@ #define CONFIG_MPC850 1 /* This is a MPC850 CPU */ #define CONFIG_TQM850M 1 /* ...on a TQM8xxM module */ +#define CONFIG_SYS_GENERIC_BOARD +#define CONFIG_DISPLAY_BOARDINFO #defineCONFIG_SYS_TEXT_BASE0x4000 diff --git a/include/configs/TQM855L.h b/include/configs/TQM855L.h index 906d79b..589d168 100644 --- a/include/configs/TQM855L.h +++ b/include/configs/TQM855L.h @@ -1,5 +1,5 @@ /* - * (C) Copyright 2000-2008 + * (C) Copyright 2000-2014 * Wolfgang Denk, DENX Software Engineering, w...@denx.de. * * SPDX-License-Identifier:GPL-2.0+ @@ -19,6 +19,8 @@ #define CONFIG_MPC855 1 /* This is a MPC855 CPU */ #define CONFIG_TQM855L 1 /* ...on a TQM8xxL module */ +#define CONFIG_SYS_GENERIC_BOARD +#define CONFIG_DISPLAY_BOARDINFO #defineCONFIG_SYS_TEXT_BASE0x4000 diff --git a/include/configs/TQM855M.h b/include/configs/TQM855M.h index 44d456e..60acb56 100644 --- a/include/configs/TQM855M.h +++ b/include/configs/TQM855M.h @@ -1,5 +1,5 @@ /* - * (C) Copyright 2000-2008 + * (C) Copyright 2000-2014 * Wolfgang Denk, DENX Software Engineering, w...@denx.de. * * SPDX-License-Identifier:GPL-2.0+ @@ -19,6 +19,8 @@ #define CONFIG_MPC855 1 /* This is a MPC855 CPU */ #define CONFIG_TQM855M 1 /* ...on a TQM8xxM module */ +#define CONFIG_SYS_GENERIC_BOARD +#define CONFIG_DISPLAY_BOARDINFO #defineCONFIG_SYS_TEXT_BASE0x4000 diff --git a/include/configs/TQM860L.h b/include/configs/TQM860L.h index 855b0cd..ebc5571 100644 --- a/include/configs/TQM860L.h +++ b/include/configs/TQM860L.h @@ -1,5 +1,5 @@ /* - * (C) Copyright 2000-2008 + * (C) Copyright 2000-2014 * Wolfgang Denk, DENX Software Engineering, w...@denx.de. * * SPDX-License-Identifier:GPL-2.0+ @@ -19,6 +19,8 @@ #define CONFIG_MPC860 1 /* This is a MPC860 CPU */ #define CONFIG_TQM860L 1 /* ...on a TQM8xxL module */ +#define CONFIG_SYS_GENERIC_BOARD +#define CONFIG_DISPLAY_BOARDINFO #defineCONFI
Re: [U-Boot] [PATCH] tools/kwbimage: Fix compilation warning
Dear Stefan,
In message <544e4412.60...@denx.de> you wrote:
>
> >> + switch (version) {
> >> + /*
> >> + * Fallback to version 0 is no version is provided in the
> >> + * cfg file
> >> + */
> >> + case -1:
...
> > What exactly is the difference between return code -1 (no version is
> > provided and you fall back to using version 0), and the default case?
> >
> > To me these look the same?
>
> Perhaps the error message is a bit misleading. The "default:" case is
> for unsupported versions. E.g. if "VERSION 3" would have been provided
> in the cfg file.
>
> Should I rephrase the error message in the next patch version? To
> something like this:
In this case not the error message is incorrect, but the comment
above is misleading. Instead of "no version is provided" it should
probably read "if no supported version is provided" (note: please
also fix the typo, i.e. "if" instead of "is").
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
Anything free is worth what you pay for it.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] imx: gpt: Add 24Mhz OSC clock source support for GPT
Hi Stefano,
On 10/27/2014 7:18 PM, Stefano Babic wrote:
> Hi Ye,
>
> On 27/10/2014 05:10, Li Ye-B37916 wrote:
>> The patch is used to add a choice for GPT clock source to provide high
>> frequency clock. The configuration "CONFIG_MXC_GPT_HCLK" is not dependent
>> on the chip version. Even it is i.MX28, it is ok to set the configuration.
> Ok, thanks for clarification.
>
>> The implementation has handled the differences between the chips.
>> Most of i.MX6 series supports to use 24Mhz OSC as its high clock source
>> (except MX6Q/D Rev 1.0 and MX6SL). So for i.MX6, the implementation uses
>> the 24Mhz OSC.
>> For others (the time.c only compiles for i.MX5 and i.MX6, so the other is
>> i.MX5), they don't have 24Mhz OSC source for GPT. When the configuration is
>> set, we use perclk instead.
> It should be not bad if you check for MX5 and CONFIG_MXC_GPT_HCLK and
> raise an error at compile time. This configuration is wrong and the
> error should be reported and not hidden at runtime.
No, this configuration is not wrong for MX5. When it is set on MX5, the
implementation uses preclk as the clock source to generate a high frequency
GPT.
>> I feel the patch subject need to modify, like "add HCLK clock source for
>> GPT", then people may not confuse.
> Agree, do it.
>
MX6Q/D Rev 1.0 and MX6SL can't use the 24Mhz OSC clock source option,
so select the perclk for them. For MX6SL, we will set the OSC 24Mhz to
perclk in CCM, so eventually the clock comes from OSC 24Mhz.
>>> I am trying to understand. The explanation here does not reflect in the
>>> implementation. From the implementation, it is possible to set it even
>>> with wrong revision.
>> As explained above, the implementation has handled the differences. Users
>> does not need to care the revision. For example, when the image runs on a
>> MX6Q/D Rev 1.0 chip, the perclk will be selected not the 24Mhz OSC.
>>
>>> Anyway, I do not think it is correct to put it as a configuration
>>> option. This makes that we need different binaries for different
>>> revisions of the SOC. It should be checked at runtime if the revision is
>>> correct to set this clock as source. gpt_has_clk_source_osc has a check,
>>> but does it make sense that CONFIG_MXC_GPT_HCLK can be set in any case ?
>> Only i.MX5 and i.MX6 uses the GPT driver. I think the CONFIG_MXC_GPT_HCLK
>> can be set in any case.
> Well, but if does not make sense for i.MX5, why do we have to accept it ?
The MX5 can also have a high frequency GPT. The difference is it uses another
clock source "preclk" than the "24Mhz OSC" used for iMX6.
Signed-off-by: Ye.Li
---
>>> Is this a second version of the patchset ? What are the changes ? Please
>>> add version number to your patchset and write a history about changes. I
>>> can suggest to use Simon's patman to post your patches.
>> I met a email problem last Friday. I can't get any email from
>> u-boot@lists.denx.de for a long time. So I mistakenly thought
>> the first patches are failed and send out second.
> Never mind ;-)
>
arch/arm/imx-common/timer.c | 76
+--
1 files changed, 66 insertions(+), 10 deletions(-)
diff --git a/arch/arm/imx-common/timer.c b/arch/arm/imx-common/timer.c
index c63f78f..f7e49bd 100644
--- a/arch/arm/imx-common/timer.c
+++ b/arch/arm/imx-common/timer.c
@@ -2,7 +2,7 @@
* (C) Copyright 2007
* Sascha Hauer, Pengutronix
*
- * (C) Copyright 2009 Freescale Semiconductor, Inc.
+ * (C) Copyright 2009-2014 Freescale Semiconductor, Inc.
>>> I have already complain about this. There are a lot of commits after the
>>> file was merged into u-boot, and a lot of them not directly by
>>> Freescale. I do not think it is legally correct to change the Copyright.
>> Will fix this.
> Thanks
>
*
* SPDX-License-Identifier: GPL-2.0+
*/
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
/* General purpose timers registers */
struct mxc_gpt {
@@ -26,23 +27,60 @@ static struct mxc_gpt *cur_gpt = (struct mxc_gpt
*)GPT1_BASE_ADDR;
/* General purpose timers bitfields */
#define GPTCR_SWR (1 << 15) /* Software reset */
+#define GPTCR_24MEN (1 << 10) /* Enable 24MHz clock input
from crystal */
#define GPTCR_FRR (1 << 9)/* Freerun / restart */
-#define GPTCR_CLKSOURCE_32(4 << 6)/* Clock source */
+#define GPTCR_CLKSOURCE_32(4 << 6)/* Clock source 32khz */
+#define GPTCR_CLKSOURCE_OSC (5 << 6)/* Clock source OSC */
+#define GPTCR_CLKSOURCE_PRE (1 << 6)/* Clock source PRECLK
*/
+#define GPTCR_CLKSOURCE_MASK (0x7 << 6)
#define GPTCR_TEN 1 /* Timer enable */
+#define GPTPR_PRESCALER24M_SHIFT 12
+#define GPTPR
[U-Boot] Regression with ubifs initialization
Hey all, It appears that 2014.10 has some issues with UBIFS initialization (details at bottom). git-bisect results in one of the following commits being broken. Surely it is the mtd one, but its parent commit (compat.h) does not compile. [ff94bc40af3] mtd, ubi, ubifs: resync with Linux-3.14 [0c06db59836] lib, linux: move linux specific defines to linux/compat.h A little background for the errors below. My MTD table: device nor0 <0.flash>, # parts = 5 #: namesizeoffset mask_flags 0: uboot 0x0008 0x 0 1: env 0x0002 0x0008 0 2: env_redund 0x0002 0x000a 0 3: env_factory 0x0002 0x000c 0 4: data0x0040 0x000e 0 = Older (2014.07) U-Boot, I can do something like this: $ erase nor0,4 Erase Flash Partition nor0,4, bank 0, 0x000e - 0x004d done Erased 32 sectors $ ubi part data UBI: attaching mtd1 to ubi0 UBI: physical eraseblock size: 131072 bytes (128 KiB) UBI: logical eraseblock size:130944 bytes UBI: smallest flash I/O unit:1 UBI: VID header offset: 64 (aligned 64) UBI: data offset:128 UBI: empty MTD device detected UBI: create volume table (copy #1) UBI: create volume table (copy #2) UBI: attached mtd1 to ubi0 UBI: MTD device name:"mtd=4" UBI: MTD device size:4 MiB UBI: number of good PEBs:32 UBI: number of bad PEBs: 0 UBI: max. allowed volumes: 128 UBI: wear-leveling threshold:4096 UBI: number of internal volumes: 1 UBI: number of user volumes: 0 UBI: available PEBs: 28 UBI: total number of reserved PEBs: 4 UBI: number of PEBs reserved for bad PEB handling: 0 UBI: max/mean erase counter: 1/0 $ = Newer (2014.10) U-Boot, I get the following $ erase nor0,4 Erase Flash Partition nor0,4, bank 0, 0x000e - 0x004d done Erased 32 sectors $ ubi part data UBI: attaching mtd1 to ubi0 $ ubi info UBI: MTD device name:"(a" UBI: MTD device size:18446742253448744536 MiB UBI: physical eraseblock size: -443412400 bytes (-433020 KiB) UBI: logical eraseblock size:-442945536 bytes UBI: number of good PEBs:-494718944 UBI: number of bad PEBs: -444399596 UBI: smallest flash I/O unit:-452780024 UBI: VID header offset: -444391424 (aligned -390234000) UBI: data offset:-443207680 UBI: max. allowed volumes: -509550577 UBI: wear-leveling threshold:4096 UBI: number of internal volumes: 1 UBI: number of user volumes: 479 UBI: available PEBs: -443686912 UBI: total number of reserved PEBs: -450899448 UBI: number of PEBs reserved for bad PEB handling: -514859008 UBI: max/mean erase counter: -450944464/-393084916 - Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/11] fdt: Add device tree memory bindings
On Fri, Oct 24, 2014 at 02:04:00PM -0600, Simon Glass wrote: > Hi Tom, > > On 24 October 2014 12:49, Tom Rini wrote: > > On Thu, Oct 23, 2014 at 06:58:50PM -0600, Simon Glass wrote: > > > >> From: Michael Pratt > >> > >> Support a default memory bank, specified in reg, as well as > >> board-specific memory banks in subtree board-id nodes. > >> > >> This allows memory information to be provided in the device tree, > >> rather than hard-coded in, which will make it simpler to handle > >> similar devices with different memory banks, as the board-id values > >> or masks can be used to match devices. > > [snip] > >> +++ b/doc/device-tree-bindings/memory/memory.txt > >> @@ -0,0 +1,67 @@ > >> +* Memory binding > >> + > >> +The memory binding for U-Boot is as in the ePAPR with the following > >> additions: > > > > I am wary of being different from ePAPR / Linux Kernel. What do we need > > this for / when do we use it? > > This extends the existing binding. It allows the location and size of > memory to be set by a board ID. Unfortunately on sopme hardware you > get a hang if you try to access memory that doesn't exist, so this > allows the range of available memory to be defined - or at least the > maximum bound since we still probe the memory size within that range. > > This feature is used on several Exynos Chromebooks. So that you can use the same DT on several disjoint boards? How does this work with the kernel, does U-Boot then pass along only the correct map? Patches to the kernel to also deal with this? -- 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 1/5] imx: gpt: Add 24Mhz OSC clock source support for GPT
Hi Ye, On 27/10/2014 14:58, Li Ye-B37916 wrote: > Hi Stefano, > > On 10/27/2014 7:18 PM, Stefano Babic wrote: >> Hi Ye, >> >> On 27/10/2014 05:10, Li Ye-B37916 wrote: >>> The patch is used to add a choice for GPT clock source to provide high >>> frequency clock. The configuration "CONFIG_MXC_GPT_HCLK" is not dependent >>> on the chip version. Even it is i.MX28, it is ok to set the configuration. >> Ok, thanks for clarification. >> >>> The implementation has handled the differences between the chips. >>> Most of i.MX6 series supports to use 24Mhz OSC as its high clock source >>> (except MX6Q/D Rev 1.0 and MX6SL). So for i.MX6, the implementation uses >>> the 24Mhz OSC. >>> For others (the time.c only compiles for i.MX5 and i.MX6, so the other is >>> i.MX5), they don't have 24Mhz OSC source for GPT. When the configuration >>> is set, we use perclk instead. >> It should be not bad if you check for MX5 and CONFIG_MXC_GPT_HCLK and >> raise an error at compile time. This configuration is wrong and the >> error should be reported and not hidden at runtime. > > No, this configuration is not wrong for MX5. When it is set on MX5, the > implementation uses preclk as the clock source to generate a high frequency > GPT. I see - in this case you defined GPTCR_CLKSOURCE_PRE. Ok, got it. > >>> I feel the patch subject need to modify, like "add HCLK clock source for >>> GPT", then people may not confuse. >> Agree, do it. >> > MX6Q/D Rev 1.0 and MX6SL can't use the 24Mhz OSC clock source option, > so select the perclk for them. For MX6SL, we will set the OSC 24Mhz to > perclk in CCM, so eventually the clock comes from OSC 24Mhz. > I am trying to understand. The explanation here does not reflect in the implementation. From the implementation, it is possible to set it even with wrong revision. >>> As explained above, the implementation has handled the differences. Users >>> does not need to care the revision. For example, when the image runs on a >>> MX6Q/D Rev 1.0 chip, the perclk will be selected not the 24Mhz OSC. >>> Anyway, I do not think it is correct to put it as a configuration option. This makes that we need different binaries for different revisions of the SOC. It should be checked at runtime if the revision is correct to set this clock as source. gpt_has_clk_source_osc has a check, but does it make sense that CONFIG_MXC_GPT_HCLK can be set in any case ? >>> Only i.MX5 and i.MX6 uses the GPT driver. I think the CONFIG_MXC_GPT_HCLK >>> can be set in any case. >> Well, but if does not make sense for i.MX5, why do we have to accept it ? > > The MX5 can also have a high frequency GPT. The difference is it uses another > clock source "preclk" than the "24Mhz OSC" used for iMX6. Fine. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Card doesn't support part_switch
On Fri, Oct 24, 2014 at 09:44:50PM -0400, Brandon Williams wrote: > Hi there, > > I'm trying to switch to the second partition of my SD card and I'm running > into this error: > > U-Boot> mmc dev 0 2 > Card doesn't support part_switch > switch to partitions #2, ERROR > > Is this a limitation of my SD card? Is it a partition configuration > problem? I looked around and couldn't find much about it. This refers to "physical" partitions. SD cards do not have them but eMMC does. If you want to use partition 2 of your SD card, you want say 'load mmc 0:2 ...' -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PULL] u-boot-mpc5xxx / master
Dear Tom, The following changes since commit d0796defbe8eff6fc3c27c893dcbc47af59d4764: Merge http://git.denx.de/u-boot-sunxi (2014-10-26 14:13:24 -0400) are available in the git repository at: git://git.denx.de/u-boot-mpc5xxx.git master for you to fetch changes up to f06f9a1fb1cd332435b9e8660355f57d7d3f98d8: ppc: Zap TQM8272 board (2014-10-27 14:35:56 +0100) Anatolij Gustschin (8): powerpc: mpc512x: fix boot breakage powerpc: mpc5121ads: convert to generic board powerpc: pdm360ng: convert to generic board powerpc: aria: convert to generic board powerpc: ac14xx: convert to generic board powerpc: mecp5123: convert to generic board powerpc: digsy_mtc: convert to generic board powerpc: mpc5121ads: update board config info in README Marek Vasut (7): ppc: Zap ICU862 board ppc: Zap MHPC board ppc: Zap Hymod board ppc: Zap HWW1U1A board ppc: Zap IDS8247 board ppc: Zap TQM8260 board ppc: Zap TQM8272 board Wolfgang Denk (2): README.scrapyard: update commit IDs PowerPC: drop some 74xx_7xx boards and related code arch/powerpc/cpu/74xx_7xx/Kconfig | 16 - arch/powerpc/cpu/74xx_7xx/start.S | 13 +- arch/powerpc/cpu/mpc8260/Kconfig | 16 - arch/powerpc/cpu/mpc8260/ether_fcc.c | 27 +- arch/powerpc/cpu/mpc8260/interrupts.c | 10 +- arch/powerpc/cpu/mpc8260/pci.c|2 - arch/powerpc/cpu/mpc8260/start.S | 14 - arch/powerpc/cpu/mpc83xx/start.S | 11 - arch/powerpc/cpu/mpc85xx/Kconfig |4 - arch/powerpc/cpu/mpc8xx/Kconfig |8 - arch/powerpc/cpu/mpc8xx/cpu_init.c|2 - arch/powerpc/cpu/mpc8xx/fec.c | 40 +- arch/powerpc/include/asm/immap_512x.h |1 + arch/powerpc/include/asm/u-boot.h |3 - board/Marvell/common/flash.c | 1056 --- board/Marvell/common/i2c.c| 521 -- board/Marvell/common/intel_flash.c| 253 --- board/Marvell/common/misc.S | 235 --- board/Marvell/common/serial.c |8 - board/Marvell/db64360/64360.h | 36 - board/Marvell/db64360/Kconfig | 12 - board/Marvell/db64360/MAINTAINERS |6 - board/Marvell/db64360/Makefile| 13 - board/Marvell/db64360/README | 105 -- board/Marvell/db64360/db64360.c | 922 - board/Marvell/db64360/eth.h | 28 - board/Marvell/db64360/mpsc.c | 1001 -- board/Marvell/db64360/mpsc.h | 140 -- board/Marvell/db64360/mv_eth.c| 3128 --- board/Marvell/db64360/mv_eth.h| 818 board/Marvell/db64360/mv_regs.h | 1108 --- board/Marvell/db64360/pci.c | 923 - board/Marvell/db64360/sdram_init.c| 1945 --- board/Marvell/db64460/64460.h | 36 - board/Marvell/db64460/Kconfig | 12 - board/Marvell/db64460/MAINTAINERS |6 - board/Marvell/db64460/Makefile| 13 - board/Marvell/db64460/README | 105 -- board/Marvell/db64460/db64460.c | 922 - board/Marvell/db64460/eth.h | 27 - board/Marvell/db64460/mpsc.c | 1001 -- board/Marvell/db64460/mpsc.h | 140 -- board/Marvell/db64460/mv_eth.c| 3127 --- board/Marvell/db64460/mv_eth.h| 815 board/Marvell/db64460/mv_regs.h | 1108 --- board/Marvell/db64460/pci.c | 923 - board/Marvell/db64460/sdram_init.c| 1950 --- board/Marvell/include/core.h | 236 --- board/Marvell/include/mv_gen_reg.h| 2296 --- board/eltec/mhpc/Kconfig | 12 - board/eltec/mhpc/MAINTAINERS |6 - board/eltec/mhpc/Makefile |8 - board/eltec/mhpc/flash.c | 414 - board/eltec/mhpc/mhpc.c | 465 - board/eltec/mhpc/u-boot.lds.debug | 121 -- board/esd/cpci750/64360.h | 37 - board/esd/cpci750/Kconfig | 12 - board/esd/cpci750/MAINTAINERS |6 - board/esd/cpci750/Makefile| 14 - board/esd/cpci750/cpci750.c | 1088 --- board/esd/cpci750/eth.h | 28 - board/esd/cpci750/i2c.c | 475 - board/esd/cpci750/i2c.h | 16 - board/esd/cpci750/ide.c | 74 - board/esd/cpci750/local.h | 69 - board/esd/cpci750/misc.S | 245 --- board/esd/cpci750/mpsc.c | 1002 -- board/esd/cpci750/mpsc.h | 140 -- board/esd/cpci750/mv_eth.c| 3131 --- board/esd/cpci750/mv_eth.h| 819 board/esd/cpci750/mv_regs.h | 1108 --- board/esd/cpci750/pci.c | 1028 -- board/esd/cpci750/s
Re: [U-Boot] [PATCH] gic: fixed compilation error in GICv2 wait for interrupt macro
Hello Albert > -Original Message- > From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net] > Sent: Monday, October 27, 2014 15:05 > To: Yehuda Yitschak > Cc: u-boot@lists.denx.de; arnab.b...@freescale.com; > feng...@phytium.com.cn; york...@freescale.com; > scottw...@freescale.com > Subject: Re: [PATCH] gic: fixed compilation error in GICv2 wait for interrupt > macro > > Hello Yehuda, > > On Mon, 27 Oct 2014 14:07:16 +0200, Yehuda Yitschak > wrote: > > a hexadicemal value was missing the "0x" prefix which caused > > assembler error > > > > Signed-off-by: Yehuda Yitschak > > --- > > arch/arm/include/asm/macro.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/arch/arm/include/asm/macro.h > > b/arch/arm/include/asm/macro.h index 541b443..1c8c425 100644 > > --- a/arch/arm/include/asm/macro.h > > +++ b/arch/arm/include/asm/macro.h > > @@ -193,7 +193,7 @@ lr .reqx30 > > 0 :wfi > > ldr \wreg2, [\xreg1, GICC_AIAR] > > str \wreg2, [\xreg1, GICC_AEOIR] > > - and \wreg2, \wreg2, #3ff > > + and \wreg2, \wreg2, #0x3ff > > cbnz\wreg2, 0b > > .endm > > #endif > > -- > > 1.8.1.2 > > Which board(s) does this error show up in? There is no board in u-boot 2014.01 that use GICv2. I guess this is why it went under radar I use mainline u-boot for one of my platforms so I noticed the bug once I rebased to 2014.10 Yehuda > > Amicalement, > -- > Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-socfpga/master
On Mon, Oct 27, 2014 at 02:28:36AM +0100, Marek Vasut wrote: > The following changes since commit 5b3ee386fde82a1ba42ff09b95247842c9a1585e: > > kbuild: clear VENDOR variable to fix build error on tcsh (2014-10-23 > 16:35:12 > -0400) > > are available in the git repository at: > > git://git.denx.de/u-boot-socfpga.git master > > for you to fetch changes up to 20cadbbe2e0425783855f6ae90ef82aa0db63155: > > arm: socfpga: config: Add USB support example (2014-10-27 02:26:24 +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
On Thu, Oct 23, 2014 at 01:17:16PM -0400, Tom Rini wrote: > Hi me, > > The following changes since commit 68e80fdda1336068f40915388bbdacfd2b75233a: > > Merge git://git.denx.de/u-boot-dm (2014-10-22 13:51:45 -0400) > > are available in the git repository at: > > > git://git.denx.de/u-boot-ti.git master > > for you to fetch changes up to b5ff205cdb0da6eff8a02653bf5192ea8d661faa: > > omap3/am33xx: mux: fix several checkpatch issues (2014-10-23 11:53:02 -0400) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] Please pull u-boot-imx
On Mon, Oct 27, 2014 at 01:32:23PM +0100, Stefano Babic wrote: > Hi Tom, > > please pull from u-boot-imx, thanks ! > > The following changes since commit c43fd23cf619856b0763a64a6a3bcf3663058c49: > > Prepare v2014.10 (2014-10-14 04:47:15 -0400) > > are available in the git repository at: > > git://www.denx.de/git/u-boot-imx.git master > > for you to fetch changes up to 3f97af5302ee15530411232b464d255eb2ff2ffb: > > ot1200: add sata support (2014-10-23 10:04:26 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Regression with ubifs initialization
Dear Andrew, In message <20141027140241.GA7726@og3k> you wrote: > > It appears that 2014.10 has some issues with UBIFS initialization > (details at bottom). git-bisect results in one of the following commits > being broken. Surely it is the mtd one, but its parent commit > (compat.h) does not compile. Which board are you talking about? And which toolchain(s) are/have you been using to build U-Boot? 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 "Most people would like to be delivered from temptation but would like it to keep in touch." - Robert Orben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Regression with ubifs initialization
On Mon, Oct 27, 2014 at 03:33:00PM +0100, Wolfgang Denk wrote: > > It appears that 2014.10 has some issues with UBIFS initialization > > (details at bottom). git-bisect results in one of the following commits > > being broken. Surely it is the mtd one, but its parent commit > > (compat.h) does not compile. > > Which board are you talking about? I have a board with a PXA270 and NOR flash. I am happy to submit the patches which add the board support, but they aren't really ready and cleaned up for submission. > And which toolchain(s) are/have you been using to build U-Boot? A crosstools-ng compiled gcc 4.8.2. Would be interested to know if this is expected behavior: a.) erase flash partition b.) Call out erased partition as a ubi partition c.) ubi triggers a initialization. Because if so, that seems to no longer happen and it blindly attempts to use the erased flash as valid ubi data. - Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tftp: Displace check for server ip
On Sun, Oct 05, 2014 at 06:39:07PM +0200, Maxime Hadjinlian wrote:
> If for some reason, 'serverip' is not set, and you are passing the
> remote IP on the command line, the tftp command will fail, stating that
> the 'serverip' is not set.
>
> By displacing this check, it fixes the issues.
>
> Signed-off-by: Maxime Hadjinlian
> ---
>
> net/net.c | 6 --
> net/tftp.c | 4
> 2 files changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/net/net.c b/net/net.c
> index 722089f..044ee71 100644
> --- a/net/net.c
> +++ b/net/net.c
> @@ -1235,12 +1235,6 @@ static int net_check_prereq(enum proto_t protocol)
> #if defined(CONFIG_CMD_NFS)
> case NFS:
> #endif
> - case TFTPGET:
> - case TFTPPUT:
> - if (NetServerIP == 0) {
> - puts("*** ERROR: `serverip' not set\n");
> - return 1;
> - }
Moving the check to TftpServer() seems fine but right here you've also
removed the check from the NFS cmd which is wrong. This needs to be
re-worked so that the current check is under #if defined(CONFIG_CMD_NFS)
and we continue case'ing TFTPGET/TFTPPUT through the common part that
follows and so forth. Thanks!
> #if defined(CONFIG_CMD_PING) || defined(CONFIG_CMD_SNTP) || \
> defined(CONFIG_CMD_DNS)
> common:
> diff --git a/net/tftp.c b/net/tftp.c
> index 966d1cf..eb93df5 100644
> --- a/net/tftp.c
> +++ b/net/tftp.c
> @@ -736,6 +736,10 @@ void TftpStart(enum proto_t protocol)
> tftp_filename[MAX_LEN-1] = 0;
> }
> }
> + if (TftpRemoteIP == 0) {
> + printf("*** ERRROR: No server IP found.\n");
> + return;
> + }
>
> printf("Using %s device\n", eth_get_name());
> printf("TFTP %s server %pI4; our IP address is %pI4",
> --
> 2.1.1
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
--
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] tools/kwbimage: Fix compilation warning
Hi Wolfgang,
On 27.10.2014 14:34, Wolfgang Denk wrote:
+ switch (version) {
+ /*
+* Fallback to version 0 is no version is provided in the
+* cfg file
+*/
+ case -1:
...
What exactly is the difference between return code -1 (no version is
provided and you fall back to using version 0), and the default case?
To me these look the same?
Perhaps the error message is a bit misleading. The "default:" case is
for unsupported versions. E.g. if "VERSION 3" would have been provided
in the cfg file.
Should I rephrase the error message in the next patch version? To
something like this:
In this case not the error message is incorrect, but the comment
above is misleading. Instead of "no version is provided" it should
probably read "if no supported version is provided" (note: please
also fix the typo, i.e. "if" instead of "is").
The fallback in the comment above refers to "version == -1". As the
function image_get_version() returns -1 if no VERSION string is found in
the config file. So I think the comment is quite accurate.
Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] kconfig: arm: introduce symbol for ARM CPUs
Hi Georges, This patch is really appreciated, but I found some mistakes. Please see below: 2014-10-27 7:25 GMT+09:00 Georges Savoundararadj : > +config SYS_CPU > +default "arm720t" if CPU_ARM720T > +default "arm920t" if CPU_ARM920T > +default "arm926ejs" if CPU_ARM926EJS > +default "arm946es" if CPU_ARM946ES > +default "arm1136" if CPU_ARM113 > +default "arm1176" if CPU_ARM1176 > +default "armv7" if CPU_V7 > +default "pxa" if CPU_PXA > +default "sa1100" if CPU_SA1100 > + [1] Typo. s/CPU_ARM113/CPU_ARM1136/ > @@ -472,6 +664,7 @@ config TEGRA > > config TARGET_VEXPRESS_AEMV8A > bool "Support vexpress_aemv8a" > + select CPU_V7 > select ARM64 > [2] Your are changing this board from "armv8" to "armv7". Please remove "select CPU_V7". [3] I thought you were trying to add only CPU_V7 and CPU_ARM1176 but it is very nice to make extra efforts for our community. One problem is, if you add "CPU_PXA", you need to fix "common/lcd.c". Otherwise, you will get a new warning for such boards as palmld, palmtc, because CONFIG_CPU_PXA is defined and used in common/lcd.c, #if defined(CONFIG_CPU_PXA25X) || defined(CONFIG_CPU_PXA27X) || \ defined(CONFIG_CPU_MONAHANS) #define CONFIG_CPU_PXA <-- remove #include #endif I think this change will *probably* produce the same output although I have not checked it closely yet. [4] This patch is not applicable on the current master (commit d0796defbe8eff6fc3c27c893dcbc47af59d4764) You also need to add "select CPU_V7" to the new entry "TARGET_SUN6I" in arch/arm/Kconfig. Could you fix [1] thru [4], please? Before sending it, please do a quick test at least; it's very easy. 1. Check out master branch 2. Run "tools/genboardscfg.py" 3. Run "mv boards.cfg boards.cfg.org" 4. Apply your patch 5. Run "tools/genboardscfg.py" again 6. Run "diff boards.cfg.org boards.cfg" If you get code diff, something is wrong with your patch. You will easily see which board is corrupted. Tom and Albert, If Georges fixes those problems, is it possible to apply it shortly on the mainline? (directly u-boot/master? or via u-boot-arm/master?) Since this patch easily causes conflicts, it should not get stuck for a long time. -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] MW rule and its period
On Tue, Oct 21, 2014 at 09:34:11PM +0200, Wolfgang Denk wrote: > Dear Masahiro, > > In message > you > wrote: > > > > Even Linux needs 7 weeks to be stabilized > > in spite of much more commits than U-Boot. > > > > Do we really need 10 weeks? > > I think a fundamental difference between Linux and U-Boot is that in > Linux the actual core is not changing so heavily, and the individual > subsystems are much better isolated. In U-Boot, we have a large > number commits with architecture-wide impact, not to mention > system-wide ones like the Kconfig / Kbuild or DM restructuring. > So a bug introduced in Linux will often affect only a relatively small > group of developers, while the rest can continue working basically > unaffected. In U-Boot it's easy to break all ARM, which will bring > the majority of developers to a full stop. > > Also I think reducing the MW makes things indeed faster, which means > more frequent release cycles, and I'm afraid in the end the custodians > will not find their days easier, but more loaded. Well, here's what I've noticed. We have a relative flury of activity around the merge window, then we have a period of both "bending" the window and having some folks be frustrated about their patches not being anywhere followed by a release. It's true we're making changes which can break more core areas, but just how much testing are people doing on top of tree? rc releaes? I wonder about for 2015 if having some shorter merge window and release schedule might not help, especially with planning peoples time. If say releases were the last Friday of even numbered months (Feb 27, Apr 24, June 26, Aug 28, Oct 30, Dec 25 (eep, OK, re-jigger that one..)), final RC Monday 2 weeks prior, RC every 2 weeks before then, only final RC is bug fix (here's how to trigger, here's fix kind), everything else is best judgement. Or even first week of the month is for big scary changes, last week is bug fixes, rest is best judgement monthly release cycle. It wouldn't be terrible for $SOC to have patches miss the April release since May is right around the corner. Custodians would know if they can focus some time the second week of the month of U-Boot for "regular" patches they can then come around the last week of the month, run test a few boards and be Good to Go. -- 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 v3 1/4] kconfig: arm: introduce symbol for ARM CPUs
Hello Masahiro, On Tue, 28 Oct 2014 01:50:31 +0900, Masahiro YAMADA wrote: > Hi Georges, > > This patch is really appreciated, but I found some mistakes. > Please see below: > > > > 2014-10-27 7:25 GMT+09:00 Georges Savoundararadj : > > > +config SYS_CPU > > +default "arm720t" if CPU_ARM720T > > +default "arm920t" if CPU_ARM920T > > +default "arm926ejs" if CPU_ARM926EJS > > +default "arm946es" if CPU_ARM946ES > > +default "arm1136" if CPU_ARM113 > > +default "arm1176" if CPU_ARM1176 > > +default "armv7" if CPU_V7 > > +default "pxa" if CPU_PXA > > +default "sa1100" if CPU_SA1100 > > + > > > [1] Typo. > > s/CPU_ARM113/CPU_ARM1136/ > > > > @@ -472,6 +664,7 @@ config TEGRA > > > > config TARGET_VEXPRESS_AEMV8A > > bool "Support vexpress_aemv8a" > > + select CPU_V7 > > select ARM64 > > > > [2] > Your are changing this board from "armv8" to "armv7". > Please remove "select CPU_V7". > > > > [3] > I thought you were trying to add only CPU_V7 and CPU_ARM1176 > but it is very nice to make extra efforts for our community. > One problem is, if you add "CPU_PXA", you need to fix "common/lcd.c". > Otherwise, you will get a new warning for such boards as palmld, palmtc, > because CONFIG_CPU_PXA is defined and used in common/lcd.c, > > #if defined(CONFIG_CPU_PXA25X) || defined(CONFIG_CPU_PXA27X) || \ > defined(CONFIG_CPU_MONAHANS) > #define CONFIG_CPU_PXA <-- remove > #include > #endif > > I think this change will *probably* produce the same output > although I have not checked it closely yet. > > > > > > [4] > This patch is not applicable on the current master > (commit d0796defbe8eff6fc3c27c893dcbc47af59d4764) > You also need to add "select CPU_V7" to > the new entry "TARGET_SUN6I" in arch/arm/Kconfig. > > > > > Could you fix [1] thru [4], please? > > > Before sending it, please do a quick test at least; > it's very easy. > > > 1. Check out master branch > 2. Run "tools/genboardscfg.py" > 3. Run "mv boards.cfg boards.cfg.org" > 4. Apply your patch > 5. Run "tools/genboardscfg.py" again > 6. Run "diff boards.cfg.org boards.cfg" > > If you get code diff, something is wrong with your patch. > You will easily see which board is corrupted. > > > > > Tom and Albert, > > If Georges fixes those problems, is it possible to apply it shortly on > the mainline? > (directly u-boot/master? or via u-boot-arm/master?) I'm ok with this patch going in (through either tree). However: > Since this patch easily causes conflicts, it should not get stuck for > a long time. I'm not sure I'm getting this right. Do yo mean that once the patch is in, it should be easy to detect and iron out issues because if some boards are broken, their users will react promptly? > Best Regards > Masahiro Yamada Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/7] spi: altera: Move the config options to the top
On 23 October 2014 01:26, Marek Vasut wrote:
> Just move the configuration options scattered all over the driver
> to the top of the source file. No functional change.
>
> Signed-off-by: Marek Vasut
> Cc: Chin Liang See
> Cc: Dinh Nguyen
> Cc: Albert Aribaud
> Cc: Pavel Machek
> Cc: Jagannadha Sutradharudu Teki
> ---
> drivers/spi/altera_spi.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/spi/altera_spi.c b/drivers/spi/altera_spi.c
> index 93365c2..8f31507 100644
> --- a/drivers/spi/altera_spi.c
> +++ b/drivers/spi/altera_spi.c
> @@ -13,6 +13,14 @@
> #include
> #include
>
> +#ifndef CONFIG_ALTERA_SPI_IDLE_VAL
> +#define CONFIG_ALTERA_SPI_IDLE_VAL 0xff
> +#endif
> +
> +#ifndef CONFIG_SYS_ALTERA_SPI_LIST
> +#define CONFIG_SYS_ALTERA_SPI_LIST { CONFIG_SYS_SPI_BASE }
> +#endif
> +
> struct altera_spi_regs {
> u32 rxdata;
> u32 txdata;
> @@ -36,10 +44,6 @@ struct altera_spi_regs {
> #define ALTERA_SPI_CONTROL_IE_MSK (1 << 8)
> #define ALTERA_SPI_CONTROL_SSO_MSK (1 << 10)
>
> -#ifndef CONFIG_SYS_ALTERA_SPI_LIST
> -#define CONFIG_SYS_ALTERA_SPI_LIST { CONFIG_SYS_SPI_BASE }
> -#endif
> -
> static ulong altera_spi_base_list[] = CONFIG_SYS_ALTERA_SPI_LIST;
>
> struct altera_spi_slave {
> @@ -118,10 +122,6 @@ void spi_release_bus(struct spi_slave *slave)
> writel(0, &altspi->regs->slave_sel);
> }
>
> -#ifndef CONFIG_ALTERA_SPI_IDLE_VAL
> -# define CONFIG_ALTERA_SPI_IDLE_VAL 0xff
> -#endif
> -
> int spi_xfer(struct spi_slave *slave, unsigned int bitlen, const void *dout,
> void *din, unsigned long flags)
> {
> --
> 2.0.0
>
Series missing's - cover letter and v2 change log.
Applied to u-boot-spi/master
thanks!
--
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/2] SPI: mxc_spi: slave initialisation fixes
On 23 October 2014 19:39, Markus Niebel wrote: > From: Markus Niebel > > 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.MX6S) 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(-) Applied to u-boot-spi/master thanks! -- Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] gic: fixed compilation error in GICv2 wait for interrupt macro
Hello Yehuda, On Mon, 27 Oct 2014 14:29:09 +, Yehuda Yitschak wrote: > Hello Albert > > Which board(s) does this error show up in? > > There is no board in u-boot 2014.01 that use GICv2. I guess this is why it > went under radar > I use mainline u-boot for one of my platforms so I noticed the bug once I > rebased to 2014.10 Thanks for the explanation. > Yehuda Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC] How to move lots of CONFIGs from header files to Kconfig
Hi.
I've been thinking how to move so many CONFIGs to Kconfig.
First, I want to move many boolean macros such as CONFIG_CMD_*,
because it seems easier than string, int, hex configs.
Roughly, we have two options, I think.
[1] I do this work for all the boards
I will prepare many entries in Kconfigs and
also move lots of configs options by a tool.
Pros:
- Possible to move many options at one time
Cons:
- Cause lots of conflicts
- It is pointless to touch lots of unmaintained boards
that might be removed by the end of this year
- Hard work for me
[2] Each board maintainer takes care of boards he is responsible for.
Procedure:
1. I will create many entries in Kconfigs
without dependencies ("depends on" and "select")
2. Each board maintainer will move config options
from his board headers to defconfigs (*)
(I expect most of active boards will be switched at this step.)
3. Many of unmaintained boards ( = not converted to generic board)
will be removed by the end of this year.
4. I will forcibly convert left-over boards.
These boards are almost inactive, so this conversion
will not produce much conflicts.
5. Implement "depends on" and "select" correctly
(*) You can edit directly configs/foo_defconfig.
Or you can use Kconfig functions in case you may introduce a typo.
Run "make foo_defconfig"
Run "make menuconfig"
Enable config options you like
Select "Save".
Run "make savedefconfig"
Run "mv defconfig configs/foo_defconfig"
Remove unnecessay CONFIGs from your board header files
Pros:
- Reduce the possibility of significant conflicts
- Avoid needless efforts for unmaintained boards
Cons:
- Patch for each board will fly around
- Take longer time
At first, I was planning to do [1] but it would disturb the
development on SoC subsystems.
I see SUNXI custodians are touching their Kconfigs and defconfigs very often.
[1] would cause conflicts between u-boot/master and u-boot-sunxi/{master,next}.
I also many boards are being dropped these days, which increase the conflicts.
I am thinking [2] is better.
Comments are welcome.
--
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] kconfig: arm: introduce symbol for ARM CPUs
Hi Albert, 2014-10-28 2:09 GMT+09:00 Albert ARIBAUD : >> Tom and Albert, >> >> If Georges fixes those problems, is it possible to apply it shortly on >> the mainline? >> (directly u-boot/master? or via u-boot-arm/master?) > > I'm ok with this patch going in (through either tree). However: > >> Since this patch easily causes conflicts, it should not get stuck for >> a long time. > > I'm not sure I'm getting this right. Do yo mean that once the patch is > in, it should be easy to detect and iron out issues because if some > boards are broken, their users will react promptly? Yes. If some conflicts happen, CONFIG_SYS_CPU will not be set correctly and those boards will fail to build. User will notice the issue soon. -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] How to move lots of CONFIGs from header files to Kconfig
Hi Masahiro,
On 27/10/14 19:13, Masahiro YAMADA wrote:
Hi.
I've been thinking how to move so many CONFIGs to Kconfig.
First, I want to move many boolean macros such as CONFIG_CMD_*,
because it seems easier than string, int, hex configs.
Roughly, we have two options, I think.
[1] I do this work for all the boards
I will prepare many entries in Kconfigs and
also move lots of configs options by a tool.
Pros:
- Possible to move many options at one time
Cons:
- Cause lots of conflicts
- It is pointless to touch lots of unmaintained boards
that might be removed by the end of this year
- Hard work for me
[2] Each board maintainer takes care of boards he is responsible for.
Procedure:
1. I will create many entries in Kconfigs
without dependencies ("depends on" and "select")
2. Each board maintainer will move config options
from his board headers to defconfigs (*)
(I expect most of active boards will be switched at this step.)
3. Many of unmaintained boards ( = not converted to generic board)
will be removed by the end of this year.
4. I will forcibly convert left-over boards.
These boards are almost inactive, so this conversion
will not produce much conflicts.
5. Implement "depends on" and "select" correctly
(*) You can edit directly configs/foo_defconfig.
Or you can use Kconfig functions in case you may introduce a typo.
Run "make foo_defconfig"
Run "make menuconfig"
Enable config options you like
Select "Save".
Run "make savedefconfig"
Run "mv defconfig configs/foo_defconfig"
Remove unnecessay CONFIGs from your board header files
Pros:
- Reduce the possibility of significant conflicts
- Avoid needless efforts for unmaintained boards
Cons:
- Patch for each board will fly around
- Take longer time
At first, I was planning to do [1] but it would disturb the
development on SoC subsystems.
I see SUNXI custodians are touching their Kconfigs and defconfigs very often.
[1] would cause conflicts between u-boot/master and u-boot-sunxi/{master,next}.
I also many boards are being dropped these days, which increase the conflicts.
I am thinking [2] is better.
Comments are welcome.
I recently tried to do [1] for a bunch of SPL #defines, and the attempt
ended in me git stashing the whole thing and putting it off for a later
date. The amount of work this approach requires feels very prohibitive,
and I agree that it is likely to be disruptive, so I'm in favour of
[2] as well.
--
Regards,
Nikita Kiryanov
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] spi: sf: Support byte program for sst spi flash
On 23 October 2014 19:06, Bin Meng wrote:
> Currently if SST flash advertises SST_WP flag in the params table
> the word program command (ADh) with auto address increment will be
> used for the flash write op. However some SPI controllers do not
> support the word program command (like the Intel ICH 7), the byte
> programm command (02h) has to be used.
>
> A new TX operation mode SPI_OPM_TX_BP is introduced for such SPI
> controller to use byte program op for SST flash.
>
> Signed-off-by: Bin Meng
> ---
> drivers/mtd/spi/sf_internal.h | 2 ++
> drivers/mtd/spi/sf_ops.c | 31 +++
> drivers/mtd/spi/sf_probe.c| 8 ++--
> drivers/spi/ich.c | 9 +++--
> include/spi.h | 1 +
> 5 files changed, 47 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
> index 19d4914..c185e04 100644
> --- a/drivers/mtd/spi/sf_internal.h
> +++ b/drivers/mtd/spi/sf_internal.h
> @@ -77,6 +77,8 @@
>
> int sst_write_wp(struct spi_flash *flash, u32 offset, size_t len,
> const void *buf);
> +int sst_write_bp(struct spi_flash *flash, u32 offset, size_t len,
> + const void *buf);
> #endif
I believe byte write is already been used within the sst_write_wp -
please check.
>
> /* Send a single-byte command to the device and read the response */
> diff --git a/drivers/mtd/spi/sf_ops.c b/drivers/mtd/spi/sf_ops.c
> index 85cf22d..3703acb 100644
> --- a/drivers/mtd/spi/sf_ops.c
> +++ b/drivers/mtd/spi/sf_ops.c
> @@ -516,4 +516,35 @@ int sst_write_wp(struct spi_flash *flash, u32 offset,
> size_t len,
> spi_release_bus(flash->spi);
> return ret;
> }
> +
> +int sst_write_bp(struct spi_flash *flash, u32 offset, size_t len,
> + const void *buf)
This function is simply calling existing sst_byte_write().
> +{
> + size_t actual;
> + int ret;
> +
> + ret = spi_claim_bus(flash->spi);
> + if (ret) {
> + debug("SF: Unable to claim SPI bus\n");
> + return ret;
> + }
> +
> + for (actual = 0; actual < len; actual++) {
> + ret = sst_byte_write(flash, offset, buf + actual);
> + if (ret) {
> + debug("SF: sst byte program failed\n");
> + break;
> + }
> + offset++;
> + }
> +
> + if (!ret)
> + ret = spi_flash_cmd_write_disable(flash);
> +
> + debug("SF: sst: program %s %zu bytes @ 0x%zx\n",
> + ret ? "failure" : "success", len, offset - actual);
> +
> + spi_release_bus(flash->spi);
> + return ret;
> +}
> #endif
> diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
> index 4d148d1..1b48955 100644
> --- a/drivers/mtd/spi/sf_probe.c
> +++ b/drivers/mtd/spi/sf_probe.c
> @@ -138,8 +138,12 @@ static struct spi_flash
> *spi_flash_validate_params(struct spi_slave *spi,
> /* Assign spi_flash ops */
> flash->write = spi_flash_cmd_write_ops;
> #ifdef CONFIG_SPI_FLASH_SST
> - if (params->flags & SST_WP)
> - flash->write = sst_write_wp;
> + if (params->flags & SST_WP) {
> + if (flash->spi->op_mode_tx & SPI_OPM_TX_BP)
> + flash->write = sst_write_bp;
> + else
> + flash->write = sst_write_wp;
> + }
> #endif
> flash->erase = spi_flash_cmd_erase_ops;
> flash->read = spi_flash_cmd_read_ops;
> diff --git a/drivers/spi/ich.c b/drivers/spi/ich.c
> index b356411..16730ec 100644
> --- a/drivers/spi/ich.c
> +++ b/drivers/spi/ich.c
> @@ -141,9 +141,14 @@ struct spi_slave *spi_setup_slave(unsigned int bus,
> unsigned int cs,
> ich->slave.max_write_size = ctlr.databytes;
> ich->speed = max_hz;
>
> - /* ICH 7 SPI controller only supports array read command */
> - if (ctlr.ich_version == 7)
> + /*
> +* ICH 7 SPI controller only supports array read command
> +* and byte program command for SST flash
> +*/
> + if (ctlr.ich_version == 7) {
> ich->slave.op_mode_rx = SPI_OPM_RX_AS;
> + ich->slave.op_mode_tx = SPI_OPM_TX_BP;
> + }
SST commands(write) is different than normal flash commands, I don't like
to change the controller driver to know the flash command usage.
May be this part can think later, try to see above comments.
>
> return &ich->slave;
> }
> diff --git a/include/spi.h b/include/spi.h
> index ffd6647..a4d3f5f 100644
> --- a/include/spi.h
> +++ b/include/spi.h
> @@ -34,6 +34,7 @@
>
> /* SPI TX operation modes */
> #define SPI_OPM_TX_QPP 1 << 0
> +#define SPI_OPM_TX_BP 1 << 1
>
> /* SPI RX operation modes */
> #define SPI_OPM_RX_AS 1 << 0
> --
> 1.8.2.1
>
thanks!
--
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx
Re: [U-Boot] [PATCH 4/5] sf: Update SST25* flash params of supported read commands
On 23 October 2014 19:07, Bin Meng wrote:
> Explicitly list supported read commands in the flash prarmas table
> for SST25* flash parts.
>
> Signed-off-by: Bin Meng
> ---
> drivers/mtd/spi/sf_params.c | 20 ++--
> include/spi_flash.h | 3 ++-
> 2 files changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
> index 453edf0..d5f3597 100644
> --- a/drivers/mtd/spi/sf_params.c
> +++ b/drivers/mtd/spi/sf_params.c
> @@ -88,16 +88,16 @@ const struct spi_flash_params spi_flash_params_table[] = {
> {"N25Q1024A", 0x20bb21, 0x0, 64 * 1024, 2048, RD_FULL,
> WR_QPP | E_FSR | SECT_4K},
> #endif
> #ifdef CONFIG_SPI_FLASH_SST/* SST */
> - {"SST25VF040B",0xbf258d, 0x0, 64 * 1024, 8, 0,
> SECT_4K | SST_WP},
> - {"SST25VF080B",0xbf258e, 0x0, 64 * 1024,16, 0,
> SECT_4K | SST_WP},
> - {"SST25VF016B",0xbf2541, 0x0, 64 * 1024,32, 0,
> SECT_4K | SST_WP},
> - {"SST25VF032B",0xbf254a, 0x0, 64 * 1024,64, 0,
> SECT_4K | SST_WP},
> - {"SST25VF064C",0xbf254b, 0x0, 64 * 1024, 128, 0,
>SECT_4K},
> - {"SST25WF512", 0xbf2501, 0x0, 64 * 1024, 1, 0,
> SECT_4K | SST_WP},
> - {"SST25WF010", 0xbf2502, 0x0, 64 * 1024, 2, 0,
> SECT_4K | SST_WP},
> - {"SST25WF020", 0xbf2503, 0x0, 64 * 1024, 4, 0,
> SECT_4K | SST_WP},
> - {"SST25WF040", 0xbf2504, 0x0, 64 * 1024, 8, 0,
> SECT_4K | SST_WP},
> - {"SST25WF080", 0xbf2505, 0x0, 64 * 1024,16, 0,
> SECT_4K | SST_WP},
> + {"SST25VF040B",0xbf258d, 0x0, 64 * 1024, 8, RD_SLOW,
> SECT_4K | SST_WP},
> + {"SST25VF080B",0xbf258e, 0x0, 64 * 1024,16, RD_SLOW,
> SECT_4K | SST_WP},
> + {"SST25VF016B",0xbf2541, 0x0, 64 * 1024,32, RD_SLOW,
> SECT_4K | SST_WP},
> + {"SST25VF032B",0xbf254a, 0x0, 64 * 1024,64, RD_SLOW,
> SECT_4K | SST_WP},
> + {"SST25VF064C",0xbf254b, 0x0, 64 * 1024, 128, RD_EXTN,
>SECT_4K},
> + {"SST25WF512", 0xbf2501, 0x0, 64 * 1024, 1, RD_SLOW,
> SECT_4K | SST_WP},
> + {"SST25WF010", 0xbf2502, 0x0, 64 * 1024, 2, RD_SLOW,
> SECT_4K | SST_WP},
> + {"SST25WF020", 0xbf2503, 0x0, 64 * 1024, 4, RD_SLOW,
> SECT_4K | SST_WP},
> + {"SST25WF040", 0xbf2504, 0x0, 64 * 1024, 8, RD_SLOW,
> SECT_4K | SST_WP},
> + {"SST25WF080", 0xbf2505, 0x0, 64 * 1024,16, RD_SLOW,
> SECT_4K | SST_WP},
> #endif
> #ifdef CONFIG_SPI_FLASH_WINBOND/* WINBOND */
> {"W25P80", 0xef2014, 0x0, 64 * 1024,16, 0,
> 0},
> diff --git a/include/spi_flash.h b/include/spi_flash.h
> index 408a5b4..a75e030 100644
> --- a/include/spi_flash.h
> +++ b/include/spi_flash.h
> @@ -46,7 +46,8 @@ enum spi_read_cmds {
> QUAD_OUTPUT_FAST = 1 << 3,
> QUAD_IO_FAST = 1 << 4,
> };
> -#define RD_EXTNARRAY_SLOW | DUAL_OUTPUT_FAST | DUAL_IO_FAST
> +#define RD_SLOWARRAY_SLOW
> +#define RD_EXTNRD_SLOW | DUAL_OUTPUT_FAST | DUAL_IO_FAST
> #define RD_FULLRD_EXTN | QUAD_OUTPUT_FAST | QUAD_IO_FAST
>
> /* Dual SPI flash memories */
> --
> 1.8.2.1
>
What is this, by defining RD_EXTN the fastest read cmd will pick based
on controller mode_rx
Why this RD_SLOW again? does this means the specific flash part will
only support slow read?
thanks!
--
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-BOOT PATCH] zynq: Use GPLed files for SPL
The latest Xilinx tools generate ps7_init files that are explicitly available under GPL. Change the makefile to allow drop in of those files for building the SPL. Signed-off-by: Soren Brinkmann --- board/xilinx/zynq/Makefile | 6 +++--- board/xilinx/zynq/xil_io.h | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/board/xilinx/zynq/Makefile b/board/xilinx/zynq/Makefile index 71c0c351f929..f71b272e7e7c 100644 --- a/board/xilinx/zynq/Makefile +++ b/board/xilinx/zynq/Makefile @@ -7,9 +7,9 @@ obj-y := board.o -# Please copy ps7_init.c/h from hw project to this directory +# Please copy ps7_init_gpl.c/h from hw project to this directory obj-$(CONFIG_SPL_BUILD) += \ - $(if $(wildcard $(srctree)/$(src)/ps7_init.c), ps7_init.o) + $(if $(wildcard $(srctree)/$(src)/ps7_init_gpl.c), ps7_init_gpl.o) # Suppress "warning: function declaration isn't a prototype" -CFLAGS_REMOVE_ps7_init.o := -Wstrict-prototypes +CFLAGS_REMOVE_ps7_init_gpl.o := -Wstrict-prototypes diff --git a/board/xilinx/zynq/xil_io.h b/board/xilinx/zynq/xil_io.h index e59a977eb174..1eccf8d91d09 100644 --- a/board/xilinx/zynq/xil_io.h +++ b/board/xilinx/zynq/xil_io.h @@ -6,7 +6,7 @@ #define XIL_IO_H /* - * This empty file is here because ps7_init.c exported by hw project + * This empty file is here because ps7_init_gpl.c exported by hw project * has #include "xil_io.h" line. */ -- 2.1.2.1.g5e69ed6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ 1/2] tqma6: fix sf detection
On 23 October 2014 19:17, Markus Niebel wrote:
> From: Markus Niebel
>
> Commit 155fa9af95ac5be857a7327e7a968a296e60d4c8 changed the way
> to define a GPIO line, which can be used to force CS high
> across multiple transactions. In order to fix sf detection
> change board code to make use of board_spi_cs_gpio(..).
>
> Signed-off-by: Markus Niebel
> ---
> board/tqc/tqma6/tqma6.c | 10 +-
> include/configs/tqma6.h | 19 ---
> 2 files changed, 25 insertions(+), 4 deletions(-)
>
> diff --git a/board/tqc/tqma6/tqma6.c b/board/tqc/tqma6/tqma6.c
> index b552bb8..fd1bd59 100644
> --- a/board/tqc/tqma6/tqma6.c
> +++ b/board/tqc/tqma6/tqma6.c
> @@ -138,8 +138,10 @@ static iomux_v3_cfg_t const tqma6_ecspi1_pads[] = {
> NEW_PAD_CTRL(MX6_PAD_EIM_D18__ECSPI1_MOSI, SPI_PAD_CTRL),
> };
>
> +#define TQMA6_SF_CS_GPIO IMX_GPIO_NR(3, 19)
> +
> static unsigned const tqma6_ecspi1_cs[] = {
> - IMX_GPIO_NR(3, 19),
> + TQMA6_SF_CS_GPIO,
> };
>
> static void tqma6_iomuxc_spi(void)
> @@ -152,6 +154,12 @@ static void tqma6_iomuxc_spi(void)
> ARRAY_SIZE(tqma6_ecspi1_pads));
> }
>
> +int board_spi_cs_gpio(unsigned bus, unsigned cs)
> +{
> + return ((bus == CONFIG_SF_DEFAULT_BUS) &&
> + (cs == CONFIG_SF_DEFAULT_CS)) ? TQMA6_SF_CS_GPIO : -1;
> +}
> +
This always be a puzzle to me, (spi flash, here) driver controlled
stuff is validating in board entries.
Which I couldn't see a correct idea.
> static struct i2c_pads_info tqma6_i2c3_pads = {
> /* I2C3: on board LM75, M24C64, */
> .scl = {
> diff --git a/include/configs/tqma6.h b/include/configs/tqma6.h
> index 2705d2c..9ba0155 100644
> --- a/include/configs/tqma6.h
> +++ b/include/configs/tqma6.h
> @@ -9,13 +9,26 @@
> #ifndef __CONFIG_H
> #define __CONFIG_H
>
> +#define CONFIG_MX6
> +
> +/* SPL */
> +/* #if defined(CONFIG_SPL_BUILD) */
> +
> +#define CONFIG_SPL_MMC_SUPPORT
> +#define CONFIG_SPL_SPI_SUPPORT
> +#define CONFIG_SPL_FAT_SUPPORT
> +#define CONFIG_SPL_EXT_SUPPORT
> +
> +/* common IMX6 SPL configuration */
> +#include "imx6_spl.h"
> +
> +/* #endif */
> +
> #include "mx6_common.h"
> #include
> #include
> #include
>
> -#define CONFIG_MX6
> -
> #if defined(CONFIG_MX6DL) || defined(CONFIG_MX6S)
> #define PHYS_SDRAM_SIZE(512u * SZ_1M)
> #elif defined(CONFIG_MX6Q) || defined(CONFIG_MX6D)
> @@ -57,7 +70,7 @@
>
> #define CONFIG_CMD_SF
> #define CONFIG_SF_DEFAULT_BUS 0
> -#define CONFIG_SF_DEFAULT_CS (0 | (IMX_GPIO_NR(3, 19) << 8))
> +#define CONFIG_SF_DEFAULT_CS 0
> #define CONFIG_SF_DEFAULT_SPEED5000
> #define CONFIG_SF_DEFAULT_MODE (SPI_MODE_0)
>
> --
> 2.1.1
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
thanks!
--
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] mpc85xx/t208xqds: Adjust DDR timing parameters
Adjust timing for dual-rank UDIMM, verified on M3CQ-8GHS3C0E for speed of
1066, 1333, 1600, 1866MT/s. The 1866 timing is copied to 2133 timing in
case such DIMM comes available.
Also update single-rank 1866 timing. Enable interactive debugging as well.
Signed-off-by: York Sun
CC: Shengzhou Liu
---
board/freescale/t208xqds/ddr.h | 15 +++
include/configs/T208xQDS.h |2 +-
2 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/board/freescale/t208xqds/ddr.h b/board/freescale/t208xqds/ddr.h
index ed52fef6..9c26fdf 100644
--- a/board/freescale/t208xqds/ddr.h
+++ b/board/freescale/t208xqds/ddr.h
@@ -28,17 +28,16 @@ static const struct board_specific_parameters udimm0[] = {
* num| hi| rank| clk| wrlvl | wrlvl | wrlvl |
* ranks| mhz| GB |adjst| start | ctl2 | ctl3 |
*/
- {2, 1200, 0, 5, 7, 0x0808090a, 0x0b0c0c0a},
- {2, 1500, 0, 5, 6, 0x07070809, 0x0a0b0b09},
- {2, 1600, 0, 5, 8, 0x090b0b0d, 0x0d0e0f0b},
- {2, 1700, 0, 4, 7, 0x080a0a0c, 0x0c0d0e0a},
- {2, 1900, 0, 5, 9, 0x0a0b0c0e, 0x0f10120c},
- {2, 2140, 0, 4, 8, 0x090a0b0d, 0x0e0f110b},
+ {2, 1200, 0, 5, 7, 0x0708090a, 0x0b0c0d09},
+ {2, 1400, 0, 5, 7, 0x08090a0c, 0x0d0e0f0a},
+ {2, 1700, 0, 5, 8, 0x090a0b0c, 0x0e10110c},
+ {2, 1900, 0, 5, 8, 0x090b0c0f, 0x1012130d},
+ {2, 2140, 0, 5, 8, 0x090b0c0f, 0x1012130d},
{1, 1200, 0, 5, 7, 0x0808090a, 0x0b0c0c0a},
{1, 1500, 0, 5, 6, 0x07070809, 0x0a0b0b09},
{1, 1600, 0, 5, 8, 0x090b0b0d, 0x0d0e0f0b},
- {1, 1700, 0, 4, 7, 0x080a0a0c, 0x0c0d0e0a},
- {1, 1900, 0, 5, 9, 0x0a0b0c0e, 0x0f10120c},
+ {1, 1700, 0, 4, 8, 0x080a0a0c, 0x0c0d0e0a},
+ {1, 1900, 0, 5, 8, 0x090a0c0d, 0x0e0f110c},
{1, 2140, 0, 4, 8, 0x090a0b0d, 0x0e0f110b},
{}
};
diff --git a/include/configs/T208xQDS.h b/include/configs/T208xQDS.h
index 2733358..3426b55 100644
--- a/include/configs/T208xQDS.h
+++ b/include/configs/T208xQDS.h
@@ -234,7 +234,7 @@ unsigned long get_board_ddr_clk(void);
#define CONFIG_FSL_DDR_FIRST_SLOT_QUAD_CAPABLE
#define CONFIG_DDR_SPD
#define CONFIG_SYS_FSL_DDR3
-#undef CONFIG_FSL_DDR_INTERACTIVE
+#define CONFIG_FSL_DDR_INTERACTIVE
#define CONFIG_SYS_SPD_BUS_NUM 0
#define CONFIG_SYS_SDRAM_SIZE 2048/* for fixed parameter use */
#define SPD_EEPROM_ADDRESS10x51
--
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] mpc85xx/t2080: Fix parsing DDR ratio for new revision
T2080 rev 1.1 changes MEM_RAT in RCW, which requires new parsing for ratio,
the same way as T4240 rev 2.0.
Signed-off-by: York Sun
CC: Shengzhou Liu
---
arch/powerpc/cpu/mpc85xx/speed.c | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/speed.c b/arch/powerpc/cpu/mpc85xx/speed.c
index 3236f6a..9d2a3b9 100644
--- a/arch/powerpc/cpu/mpc85xx/speed.c
+++ b/arch/powerpc/cpu/mpc85xx/speed.c
@@ -37,6 +37,7 @@ void get_sys_info(sys_info_t *sys_info)
#ifdef CONFIG_SYS_FSL_QORIQ_CHASSIS2
int cc_group[12] = CONFIG_SYS_FSL_CLUSTER_CLOCKS;
#endif
+ __maybe_unused u32 svr;
const u8 core_cplx_PLL[16] = {
[ 0] = 0, /* CC1 PPL / 1 */
@@ -122,11 +123,27 @@ void get_sys_info(sys_info_t *sys_info)
/* T4240/T4160 Rev2.0 MEM_PLL_RAT uses a value which is half of
* T4240/T4160 Rev1.0. eg. It's 12 in Rev1.0, however, for Rev2.0
* it uses 6.
+* T2080 rev 1.1 and later also use half mem_pll comparing with rev 1.0
*/
#if defined(CONFIG_PPC_T4240) || defined(CONFIG_PPC_T4160) || \
- defined(CONFIG_PPC_T4080)
- if (SVR_MAJ(get_svr()) >= 2)
- mem_pll_rat *= 2;
+ defined(CONFIG_PPC_T4080) || defined(CONFIG_PPC_T2080)
+ svr = get_svr();
+ switch (SVR_SOC_VER(svr)) {
+ case SVR_T4240:
+ case SVR_T4160:
+ case SVR_T4120:
+ case SVR_T4080:
+ if (SVR_MAJ(svr) >= 2)
+ mem_pll_rat *= 2;
+ break;
+ case SVR_T2080:
+ case SVR_T2081:
+ if ((SVR_MAJ(svr) > 1) || (SVR_MIN(svr) >= 1))
+ mem_pll_rat *= 2;
+ break;
+ default:
+ break;
+ }
#endif
if (mem_pll_rat > 2)
sys_info->freq_ddrbus *= mem_pll_rat;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-spi/master
Hi Tom, Please pull this PR. thanks! -- Jagan. The following changes since commit 0ce4af99c07acebf4fce9a91f1099d2460629293: Merge branch 'master' of git://git.denx.de/u-boot-imx (2014-10-27 09:08:42 -0400) are available in the git repository at: git://git.denx.de/u-boot-spi.git master for you to fetch changes up to 027a9a002455a1175b0f5b7c7c5350afab2b4421: SPI: mxc_spi: delay initialisation until claim bus (2014-10-27 22:37:03 +0530) Marek Vasut (7): spi: altera: Use struct-based register access spi: altera: Clean up bit definitions spi: altera: Clean up most checkpatch issues spi: altera: Zap endless loop spi: altera: Clean up the use of variable d spi: altera: Add short note about EPCS/EPCQx1 spi: altera: Move the config options to the top Markus Niebel (2): SPI: mxc_spi: remove second reset from ECSPI config handler SPI: mxc_spi: delay initialisation until claim bus doc/SPI/README.altera_spi | 6 +++ drivers/spi/altera_spi.c | 132 ++ drivers/spi/mxc_spi.c | 40 +++--- 3 files changed, 101 insertions(+), 77 deletions(-) create mode 100644 doc/SPI/README.altera_spi ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/t1040qds: Update DDR option
Enable interactive debugging by default. Remove DDR controller interleaving because this SoC only has one controller. Use auto chip-select interleaving to detect number of ranks. Signed-off-by: York Sun CC: Poonam Aggrwal --- include/configs/T1040QDS.h |5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/include/configs/T1040QDS.h b/include/configs/T1040QDS.h index 1d0664d..0a82fd5 100644 --- a/include/configs/T1040QDS.h +++ b/include/configs/T1040QDS.h @@ -176,8 +176,8 @@ unsigned long get_board_ddr_clk(void); #define CONFIG_DDR_SPD #ifndef CONFIG_SYS_FSL_DDR4 #define CONFIG_SYS_FSL_DDR3 -#define CONFIG_FSL_DDR_INTERACTIVE #endif +#define CONFIG_FSL_DDR_INTERACTIVE #define CONFIG_SYS_SPD_BUS_NUM 0 #define SPD_EEPROM_ADDRESS 0x51 @@ -769,8 +769,7 @@ unsigned long get_board_ddr_clk(void); #define __USB_PHY_TYPE utmi #defineCONFIG_EXTRA_ENV_SETTINGS \ - "hwconfig=fsl_ddr:ctlr_intlv=cacheline,"\ - "bank_intlv=cs0_cs1;" \ + "hwconfig=fsl_ddr:bank_intlv=auto;" \ "usb1:dr_mode=host,phy_type=" __stringify(__USB_PHY_TYPE) "\0"\ "netdev=eth0\0" \ "video-mode=fslfb:1024x768-32@60,monitor=dvi\0" \ -- 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 00/14] Set of fixes for Exynos4xxx boards
Hi Przemyslaw, On 24 October 2014 09:44, Przemyslaw Marczak wrote: > Hello Simon, Tom, > > The last driver-model changes was merged too fast and I was not able > to test it well on all my boards. It was worked well for the first > look, but after deep testing - it required some additional work to do. > > So this is a set of fixes required for Exynos4xxx boards. > I am not sure what about the Origen. > > The patchset was rebased on the top of u-boot-dm/master, which is now: > c2ded96 serial: remove uniphier_serial_initialize() call > > Tested on: > - Trats (E4210) > - UniversalC210 (E4210) > - Trats2 (E4412) > - Odroid U3 (E4412) > - Odroid X2 (E4412) Actually I never did update the device tree numbering so I suspect this series has been incorrect since version 1! Since exynos5 was always sequential I somehow missing thinking about it. This is great, thanks for straightening it all out and testing. Particularly I am pleased about Universal since the soft SPI was a bit of a poke in the dark. I'll go through this soon. I was also planning to send a patch to clean up some of the gpio_name_num_table stuff since it shouldn't be needed any more. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/11] fdt: Add device tree memory bindings
Hi Tom, On 27 October 2014 08:24, Tom Rini wrote: > On Fri, Oct 24, 2014 at 02:04:00PM -0600, Simon Glass wrote: >> Hi Tom, >> >> On 24 October 2014 12:49, Tom Rini wrote: >> > On Thu, Oct 23, 2014 at 06:58:50PM -0600, Simon Glass wrote: >> > >> >> From: Michael Pratt >> >> >> >> Support a default memory bank, specified in reg, as well as >> >> board-specific memory banks in subtree board-id nodes. >> >> >> >> This allows memory information to be provided in the device tree, >> >> rather than hard-coded in, which will make it simpler to handle >> >> similar devices with different memory banks, as the board-id values >> >> or masks can be used to match devices. >> > [snip] >> >> +++ b/doc/device-tree-bindings/memory/memory.txt >> >> @@ -0,0 +1,67 @@ >> >> +* Memory binding >> >> + >> >> +The memory binding for U-Boot is as in the ePAPR with the following >> >> additions: >> > >> > I am wary of being different from ePAPR / Linux Kernel. What do we need >> > this for / when do we use it? >> >> This extends the existing binding. It allows the location and size of >> memory to be set by a board ID. Unfortunately on sopme hardware you >> get a hang if you try to access memory that doesn't exist, so this >> allows the range of available memory to be defined - or at least the >> maximum bound since we still probe the memory size within that range. >> >> This feature is used on several Exynos Chromebooks. > > So that you can use the same DT on several disjoint boards? How does > this work with the kernel, does U-Boot then pass along only the correct > map? Patches to the kernel to also deal with this? Typically a board may have variants with different amounts of memory, detected at run-time by GPIOs. We want the option of using the same DT for these, similar to what the Compulab people were talking about - otherwise we have something of an explosion of combinations. Yes U-Boot (already) puts the correct memory map together for the kernel, so it all works from start to finish. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Regression with ubifs initialization
On Mon, Oct 27, 2014 at 09:45:16AM -0500, Andrew Ruder wrote: > On Mon, Oct 27, 2014 at 03:33:00PM +0100, Wolfgang Denk wrote: > > > It appears that 2014.10 has some issues with UBIFS initialization > > > (details at bottom). git-bisect results in one of the following commits > > > being broken. Surely it is the mtd one, but its parent commit > > > (compat.h) does not compile. > > > > Which board are you talking about? > > I have a board with a PXA270 and NOR flash. I am happy to submit the > patches which add the board support, but they aren't really ready and > cleaned up for submission. > > > And which toolchain(s) are/have you been using to build U-Boot? > > A crosstools-ng compiled gcc 4.8.2. Wolfgang and I talked quite a bit on IRC and just catching up anyone else looking at this with a few additional details that came out of this. The problem appears to stem from 'ubi part data' completing with no errors while also not filling in any of the ubi_devices[] array. This in turn results in the global 'ubi' variable being NULL (on PXA270 this is u-boot in flash). At this point display_ubi_info() gets passed NULL and ends up printing compiler-dependent junk for all the values. That being said, I tried 4.9.1 and had the same issue (display_ubi_info() being passed NULL) with different symptoms (complete lock up because it ends up hitting data alignment issues when it starts treating opcodes as pointers). - Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/1] odroid: Turn blue LED on in u-boot
Hello Przemyslaw Marczak, On Mon, Oct 27, 2014 at 4:35 AM, Przemyslaw Marczak wrote: > Hello Suriyan, > > On 10/10/2014 12:20 AM, Suriyan Ramasami wrote: >> >> To indicate that u-boot is active turn on the blue LED. >> >> Signed-off-by: Suriyan Ramasami >> --- >> board/samsung/odroid/odroid.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/board/samsung/odroid/odroid.c b/board/samsung/odroid/odroid.c >> index fd5d2d2..391a287 100644 >> --- a/board/samsung/odroid/odroid.c >> +++ b/board/samsung/odroid/odroid.c >> @@ -374,6 +374,9 @@ static void board_gpio_init(void) >> gpio_set_pull(EXYNOS4X12_GPIO_X31, S5P_GPIO_PULL_UP); >> gpio_set_drv(EXYNOS4X12_GPIO_X31, S5P_GPIO_DRV_4X); >> gpio_direction_input(EXYNOS4X12_GPIO_X31); >> + >> + /* Enable blue LED */ > > > Here you will need to add gpio_request() call, e.g. > http://patchwork.ozlabs.org/patch/403197/ > OK, I shall do that. > >> + gpio_direction_output(EXYNOS4X12_GPIO_C10, 0); >> } >> >> static int pmic_init_max77686(void) >> > > This looks good, but please wait until the patch series merge: > http://patchwork.ozlabs.org/patch/403186/ (starts from this commit) > OK, I shall send a v2 with the gpio_request() call after the patch series you have mentioned merges. Thanks! - Suriyan > Best regards, > -- > Przemyslaw Marczak > Samsung R&D 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] MKIMAGE u-boot.imx build error
Hi, I am in the middle of upgrading u-boot-2009.08 to u-boot-2014.07. Our resident u-boot expert is on vacation and I'm running into some issues. After working through a ton of compile errors I think I'm getting close. Our system is based on the Freescale iMX53. I am able to build and run on a mx53loco development board just fine, but for some reason I'm getting the below error when building for our custom board, which is similar to the development board. I've compared the development board files to our files and I can't pinpoint why mkimage is giving a problem. LD u-boot OBJCOPY u-boot.bin CFGSboard/freescale/mx53_gogo/imximage.cfg.cfgtmp MKIMAGE u-boot.imx Usage: /home/dk/linux-upgrade/bootloader/u-boot-2014.07/tools/mkimage -l image -l ==> list image header information /home/dk/linux-upgrade/bootloader/u-boot-2014.07/tools/mkimage [-x] -A arch -O os -T type -C comp -a addr -e ep -n name -d data_file[:data_file...] image -A ==> set architecture to 'arch' -O ==> set operating system to 'os' -T ==> set image type to 'type' -C ==> set compression type 'comp' -a ==> set load address to 'addr' (hex) -e ==> set entry point to 'ep' (hex) -n ==> set image name to 'name' -d ==> use image data from 'datafile' -x ==> set XIP (execute in place) /home/dk/linux-upgrade/bootloader/u-boot-2014.07/tools/mkimage [-D dtc_options] [-f fit-image.its|-F] fit-image -D => set options for device tree compiler -f => input filename for FIT source Signing / verified boot not supported (CONFIG_FIT_SIGNATURE undefined) /home/dk/linux-upgrade/bootloader/u-boot-2014.07/tools/mkimage -V ==> print version information and exit make[1]: *** [u-boot.imx] Error 1 make: *** [u-boot.imx] Error 2 gogo build failed If I set #define CONFIG_FIT_SIGNATURE in the config file then I get a ton of other build errors so I'm not sure if that's the correct path to take. Besides, the development board doesn't have CONFIG_FIT_SIGNATURE defined in its config file. Any help would be greatly appreciated. Thanks, Dave Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] arm: odroid: pmic77686: allow bucket voltage settings
Hello Przemyslaw Marczak,
On Mon, Oct 27, 2014 at 4:08 AM, Przemyslaw Marczak
wrote:
> Hello Suriyan,
>
>
> On 10/24/2014 05:53 PM, Suriyan Ramasami wrote:
>>
>> Hello Jaehoon Chung,
>>
>>
>> On Thu, Oct 23, 2014 at 11:52 PM, Jaehoon Chung
>> wrote:
>>>
>>> Hi.
>>>
>>> On 10/21/2014 02:52 AM, Suriyan Ramasami wrote:
Allow to set the bucket voltage for the max77686.
This will be used to reset the SMC LAN9730 ethernet on the odroids.
Signed-off-by: Suriyan Ramasami
---
drivers/power/pmic/pmic_max77686.c | 48
+-
include/power/max77686_pmic.h | 3 +++
2 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/power/pmic/pmic_max77686.c
b/drivers/power/pmic/pmic_max77686.c
index df1fd91..1aeadb4 100644
--- a/drivers/power/pmic/pmic_max77686.c
+++ b/drivers/power/pmic/pmic_max77686.c
@@ -42,6 +42,25 @@ static unsigned int max77686_ldo_volt2hex(int ldo,
ulong uV)
return 0;
}
+static unsigned int max77686_buck_volt2hex(int buck, ulong uV)
+{
+ unsigned int hex = 0;
+
+ if (buck < 5 || buck > 9) {
+ debug("%s: buck %d is not supported\n", __func__, buck);
+ return 0;
>>
>>
>> Here, I should return MAX77686_BUCK_VOLT_MAX_HEX + 1 instead of 0 to
>> signal an error condition, as 0 is a valid non error value.
>>
> He 'hex' value has at most 1 byte of len, so you can return the 'int' value
> and use the negative errno numbers - and there is no value conflicts.
>
OK, Shall use negative errno values.
>
+ }
+
+ hex = (uV - 75) / 5;
+
+ if (hex >= 0 && hex <= MAX77686_BUCK_VOLT_MAX_HEX)
+ return hex;
+
+ debug("%s: %ld is wrong voltage value for BUCK%d\n",
+ __func__, uV, buck);
+ return MAX77686_BUCK_VOLT_MAX_HEX + 1;
+}
+
int max77686_set_ldo_voltage(struct pmic *p, int ldo, ulong uV)
{
unsigned int val, ret, hex, adr;
@@ -68,6 +87,33 @@ int max77686_set_ldo_voltage(struct pmic *p, int ldo,
ulong uV)
return ret;
}
+int max77686_set_buck_voltage(struct pmic *p, int buck, ulong uV)
+{
+ unsigned int val, ret, hex, adr;
+
+ if (buck < 5 && buck > 9) {
+ printf("%s: %d is an unsupported bucket number\n",
+__func__, buck);
+ return -1;
>>>
>>>
>>> How about using error number instead of "-1"?
>>
>>
>> Could you please elaborate on this? This function always returns -1 on
>> failure just like the function max77686_set_ldo_voltate() which I have
>> tried to mimic as much as I can.
>> I am guessing that you want me to return -EINVAL in this case? Please
>> let me know, and I am OK to change it, just that this function will
>> deviate from the rest of the functions in this file.
>>
> Yes, this will be better.
OK, shall do so.
>>>
>>>
+ }
+
+ adr = max77686_buck_addr[buck] + 1;
+ hex = max77686_buck_volt2hex(buck, uV);
+
>
>
> if (hex < 0)
> return hex;
>
>
OK, will do so.
+ if (hex == MAX77686_BUCK_VOLT_MAX_HEX + 1)
+ return -1;
>>>
>>>
>>> Ditto.
>>
>>
>> I believe, I return -EINVAL here, but please look at my reasoning above.
>>
>>>
+
+ ret = pmic_reg_read(p, adr, &val);
+ if (ret)
+ return ret;
+
+ val &= ~MAX77686_BUCK_VOLT_MASK;
+ val |= hex;
+ ret |= pmic_reg_write(p, adr, val);
>>>
>>>
>>> ret |= pmic_reg_write(p, addr, val | hex); ?
>>>
>>
>> OK, will change that. Again, this was done to be as close to
>> max77686_set_ldo_voltate()
>>
>> Thanks and Regards!
>> - Suriyan
>>
>>> Best Regards,
>>> Jaehoon Chung
+
+ return ret;
+}
+
int max77686_set_ldo_mode(struct pmic *p, int ldo, char opmode)
{
unsigned int val, ret, adr, mode;
@@ -157,7 +203,7 @@ int max77686_set_buck_mode(struct pmic *p, int buck,
char opmode)
/* mode */
switch (opmode) {
case OPMODE_OFF:
- mode = MAX77686_BUCK_MODE_OFF;
+ mode = MAX77686_BUCK_MODE_OFF << mode_shift;
break;
case OPMODE_STANDBY:
switch (buck) {
diff --git a/include/power/max77686_pmic.h
b/include/power/max77686_pmic.h
index c2a772a..b0e4255 100644
--- a/include/power/max77686_pmic.h
+++ b/include/power/max77686_pmic.h
@@ -150,6 +150,7 @@ enum {
int max77686_set_ldo_voltage(struct pmic *p, int ldo, ulong uV);
int max77686_set_ldo_mode(struct pmic *p, int ldo, char opmode);
+int max77686_set_buck_voltage(struct pmic *p, int buck, ulong uV);
int max77686_set_buck_mode(struct pmic *p, int buck, char opmode);
[U-Boot] [PATCH v2, rebased 0/3] reduce warnings with W=1
When compiling u-boot with W=1 there are numerous of warnings. This patchset attempts to reduce it a bit. One source of false warnings are the aliases missing a prototype, most of them are replaced with __weak functions. Others are cause by missing includes / local functions not be marked as such. At last some actual missing prototypes are added. These are (hopefully) just trivial patches, some less than trial is ahead of us. v2: - rebase on master (most of this serie is applied, so remaining patches are numbered differently. - drop "PATCH 25/49 spi: make local functions static". Tom posted a more complete cleanup. - Drop common/cmd_elf.c: add missing include (a slightly adjusted version was applied). - split i2c: use __weak (included i2c and l2_cache) - redo serial: add prototypes for init functions Jeroen Hofstee (3): i2c: use __weak arm926ejs: cache: use __weak serial: add prototypes for init functions arch/arm/cpu/arm926ejs/cache.c | 5 +- drivers/i2c/i2c_core.c | 4 +- drivers/serial/serial.c| 140 - include/serial.h | 49 +++ 4 files changed, 121 insertions(+), 77 deletions(-) -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2, rebased 1/3] i2c: use __weak
Acked-by: Heiko Schocher
Signed-off-by: Jeroen Hofstee
---
drivers/i2c/i2c_core.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/i2c/i2c_core.c b/drivers/i2c/i2c_core.c
index 18d6736..7f63987 100644
--- a/drivers/i2c/i2c_core.c
+++ b/drivers/i2c/i2c_core.c
@@ -395,9 +395,7 @@ void i2c_reg_write(uint8_t addr, uint8_t reg, uint8_t val)
i2c_write(addr, reg, 1, &val, 1);
}
-void __i2c_init(int speed, int slaveaddr)
+__weak void i2c_init(int speed, int slaveaddr)
{
i2c_init_bus(i2c_get_bus_num(), speed, slaveaddr);
}
-void i2c_init(int speed, int slaveaddr)
- __attribute__((weak, alias("__i2c_init")));
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2, rebased 2/3] arm926ejs: cache: use __weak
Cc: Albert Aribaud
Signed-off-by: Jeroen Hofstee
---
arch/arm/cpu/arm926ejs/cache.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/cache.c b/arch/arm/cpu/arm926ejs/cache.c
index e86c2ed..8d7873c 100644
--- a/arch/arm/cpu/arm926ejs/cache.c
+++ b/arch/arm/cpu/arm926ejs/cache.c
@@ -99,7 +99,4 @@ void flush_cache(unsigned long start, unsigned long size)
/*
* Stub implementations for l2 cache operations
*/
-void __l2_cache_disable(void) {}
-
-void l2_cache_disable(void)
- __attribute__((weak, alias("__l2_cache_disable")));
+__weak void l2_cache_disable(void) {}
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2, rebased 3/3] serial: add prototypes for init functions
While at it, sort them.
Cc: Tom Rini
Cc: Simon Glass
Signed-off-by: Jeroen Hofstee
---
drivers/serial/serial.c | 140
include/serial.h| 49 +
2 files changed, 119 insertions(+), 70 deletions(-)
diff --git a/drivers/serial/serial.c b/drivers/serial/serial.c
index 18e41b2..95c992a 100644
--- a/drivers/serial/serial.c
+++ b/drivers/serial/serial.c
@@ -109,54 +109,54 @@ U_BOOT_ENV_CALLBACK(baudrate, on_baudrate);
void name(void) \
__attribute__((weak, alias("serial_null")));
-serial_initfunc(mpc8xx_serial_initialize);
-serial_initfunc(ns16550_serial_initialize);
-serial_initfunc(pxa_serial_initialize);
-serial_initfunc(s3c24xx_serial_initialize);
-serial_initfunc(s5p_serial_initialize);
-serial_initfunc(zynq_serial_initialize);
-serial_initfunc(bfin_serial_initialize);
-serial_initfunc(bfin_jtag_initialize);
-serial_initfunc(mpc512x_serial_initialize);
-serial_initfunc(uartlite_serial_initialize);
-serial_initfunc(au1x00_serial_initialize);
-serial_initfunc(asc_serial_initialize);
-serial_initfunc(jz_serial_initialize);
-serial_initfunc(mpc5xx_serial_initialize);
-serial_initfunc(mpc8260_scc_serial_initialize);
-serial_initfunc(mpc8260_smc_serial_initialize);
-serial_initfunc(mpc85xx_serial_initialize);
-serial_initfunc(iop480_serial_initialize);
-serial_initfunc(leon2_serial_initialize);
-serial_initfunc(leon3_serial_initialize);
-serial_initfunc(marvell_serial_initialize);
+serial_initfunc(altera_jtag_serial_initialize);
+serial_initfunc(altera_serial_initialize);
serial_initfunc(amirix_serial_initialize);
+serial_initfunc(arc_serial_initialize);
+serial_initfunc(arm_dcc_initialize);
+serial_initfunc(asc_serial_initialize);
+serial_initfunc(atmel_serial_initialize);
+serial_initfunc(au1x00_serial_initialize);
+serial_initfunc(bfin_jtag_initialize);
+serial_initfunc(bfin_serial_initialize);
serial_initfunc(bmw_serial_initialize);
+serial_initfunc(clps7111_serial_initialize);
serial_initfunc(cogent_serial_initialize);
serial_initfunc(cpci750_serial_initialize);
serial_initfunc(evb64260_serial_initialize);
-serial_initfunc(ml2_serial_initialize);
-serial_initfunc(sconsole_serial_initialize);
-serial_initfunc(p3mx_serial_initialize);
-serial_initfunc(altera_jtag_serial_initialize);
-serial_initfunc(altera_serial_initialize);
-serial_initfunc(atmel_serial_initialize);
-serial_initfunc(lpc32xx_serial_initialize);
-serial_initfunc(mcf_serial_initialize);
-serial_initfunc(oc_serial_initialize);
-serial_initfunc(sandbox_serial_initialize);
-serial_initfunc(clps7111_serial_initialize);
serial_initfunc(imx_serial_initialize);
+serial_initfunc(iop480_serial_initialize);
+serial_initfunc(jz_serial_initialize);
serial_initfunc(ks8695_serial_initialize);
+serial_initfunc(leon2_serial_initialize);
+serial_initfunc(leon3_serial_initialize);
serial_initfunc(lh7a40x_serial_initialize);
+serial_initfunc(lpc32xx_serial_initialize);
+serial_initfunc(marvell_serial_initialize);
serial_initfunc(max3100_serial_initialize);
+serial_initfunc(mcf_serial_initialize);
+serial_initfunc(ml2_serial_initialize);
+serial_initfunc(mpc512x_serial_initialize);
+serial_initfunc(mpc5xx_serial_initialize);
+serial_initfunc(mpc8260_scc_serial_initialize);
+serial_initfunc(mpc8260_smc_serial_initialize);
+serial_initfunc(mpc85xx_serial_initialize);
+serial_initfunc(mpc8xx_serial_initialize);
serial_initfunc(mxc_serial_initialize);
+serial_initfunc(mxs_auart_initialize);
+serial_initfunc(ns16550_serial_initialize);
+serial_initfunc(oc_serial_initialize);
+serial_initfunc(p3mx_serial_initialize);
serial_initfunc(pl01x_serial_initialize);
+serial_initfunc(pxa_serial_initialize);
+serial_initfunc(s3c24xx_serial_initialize);
+serial_initfunc(s5p_serial_initialize);
serial_initfunc(sa1100_serial_initialize);
+serial_initfunc(sandbox_serial_initialize);
+serial_initfunc(sconsole_serial_initialize);
serial_initfunc(sh_serial_initialize);
-serial_initfunc(arm_dcc_initialize);
-serial_initfunc(mxs_auart_initialize);
-serial_initfunc(arc_serial_initialize);
+serial_initfunc(uartlite_serial_initialize);
+serial_initfunc(zynq_serial_initialize);
/**
* serial_register() - Register serial driver with serial driver core
@@ -202,54 +202,54 @@ void serial_register(struct serial_device *dev)
*/
void serial_initialize(void)
{
- mpc8xx_serial_initialize();
- ns16550_serial_initialize();
- pxa_serial_initialize();
- s3c24xx_serial_initialize();
- s5p_serial_initialize();
- mpc512x_serial_initialize();
- bfin_serial_initialize();
- bfin_jtag_initialize();
- uartlite_serial_initialize();
- zynq_serial_initialize();
- au1x00_serial_initialize();
- asc_serial_initialize();
- jz_serial_initialize();
- mpc5xx_serial_initialize();
- mpc8260_scc_serial_initialize();
- mpc8260_smc_serial_initialize();
- mpc85xx_seri
Re: [U-Boot] [PATCH 04/49] i2c: use __weak
Hello Tom, On 27-10-14 01:31, Tom Rini wrote: On Thu, Oct 09, 2014 at 08:14:40PM +0200, Jeroen Hofstee wrote: Hello Heiko, On 09-10-14 07:00, Heiko Schocher wrote: Am 08.10.2014 22:57, schrieb Jeroen Hofstee: Signed-off-by: Jeroen Hofstee --- arch/arm/cpu/arm926ejs/cache.c | 5 + This change seems to have nothing to do with the subject ... could you please split this? No problem, I likely accidentally squashed them. I will repost this patch with out it and append a new one. Did I miss it? Thanks! Thanks for applying most of them. I reposted the remaining ones. Regards, Jeroen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] arm: odroid: usb: add support for usb host including ethernet
Hello Przemyslaw Marczak,
On Mon, Oct 27, 2014 at 4:08 AM, Przemyslaw Marczak
wrote:
> Hello Suriyan,
>
>
> On 10/24/2014 06:08 PM, Suriyan Ramasami wrote:
>>
>> Hello Minkyu Kang,
>>
>>
>> On Thu, Oct 23, 2014 at 9:58 PM, Minkyu Kang wrote:
>>>
>>> Dear Suriyan Ramasami,
>>>
>>> On 21/10/14 02:52, Suriyan Ramasami wrote:
This change adds support for enabling the USB host features of the
board.
This includes the USB3503A hub and the SMC LAN9730 ethernet controller
as well.
Credit goes to Tushar Berara for the function set_usb_ethaddr().
Signed-off-by: Suriyan Ramasami
---
v2:
* Removed an unneeded header file from ehci-exynos.c
* Fix indentation in the dts file
---
arch/arm/dts/exynos4412-odroid.dts | 11 +++
arch/arm/include/asm/arch-exynos/cpu.h | 2 ++
arch/arm/include/asm/arch-exynos/ehci.h | 13
board/samsung/odroid/odroid.c | 55
+
drivers/usb/host/ehci-exynos.c | 51
+-
include/configs/odroid.h| 13
6 files changed, 137 insertions(+), 8 deletions(-)
diff --git a/arch/arm/dts/exynos4412-odroid.dts
b/arch/arm/dts/exynos4412-odroid.dts
index 24d0bf1..ac5fece 100644
--- a/arch/arm/dts/exynos4412-odroid.dts
+++ b/arch/arm/dts/exynos4412-odroid.dts
@@ -67,4 +67,15 @@
div = <0x3>;
index = <4>;
};
+
+ ehci@1258 {
+ compatible = "samsung,exynos-ehci";
+ reg = <0x1258 0x100>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ phy {
+ compatible = "samsung,exynos-usb-phy";
+ reg = <0x125B 0x100>;
+ };
+ };
};
diff --git a/arch/arm/include/asm/arch-exynos/cpu.h
b/arch/arm/include/asm/arch-exynos/cpu.h
index ba71714..fda21fb 100644
--- a/arch/arm/include/asm/arch-exynos/cpu.h
+++ b/arch/arm/include/asm/arch-exynos/cpu.h
@@ -18,6 +18,8 @@
#define EXYNOS4_GPIO_PART3_BASE 0x0386
#define EXYNOS4_PRO_ID 0x1000
+#define EXYNOS4_GUID_LOW 0x1014
+#define EXYNOS4_GUID_HIGH0x1018
#define EXYNOS4_SYSREG_BASE 0x1001
#define EXYNOS4_POWER_BASE 0x1002
#define EXYNOS4_SWRESET 0x10020400
diff --git a/arch/arm/include/asm/arch-exynos/ehci.h
b/arch/arm/include/asm/arch-exynos/ehci.h
index d2d70bd..3800fa9 100644
--- a/arch/arm/include/asm/arch-exynos/ehci.h
+++ b/arch/arm/include/asm/arch-exynos/ehci.h
@@ -12,6 +12,13 @@
#define CLK_24MHZ5
+#define PHYPWR_NORMAL_MASK_PHY0 (0x39 << 0)
+#define PHYPWR_NORMAL_MASK_PHY1 (0x7 << 6)
+#define PHYPWR_NORMAL_MASK_HSIC0(0x7 << 9)
+#define PHYPWR_NORMAL_MASK_HSIC1(0x7 << 12)
+#define RSTCON_HOSTPHY_SWRST(0xf << 3)
+#define RSTCON_SWRST(0x1 << 0)
+
#define HOST_CTRL0_PHYSWRSTALL (1 << 31)
#define HOST_CTRL0_COMMONON_N(1 << 9)
#define HOST_CTRL0_SIDDQ (1 << 6)
@@ -61,6 +68,12 @@ struct exynos_usb_phy {
unsigned int usbotgtune;
};
+struct exynos4412_usb_phy {
+ unsigned int usbphyctrl;
+ unsigned int usbphyclk;
+ unsigned int usbphyrstcon;
+};
+
/* Switch on the VBUS power. */
int board_usb_vbus_init(void);
diff --git a/board/samsung/odroid/odroid.c
b/board/samsung/odroid/odroid.c
index 5edb250..6c78b67 100644
--- a/board/samsung/odroid/odroid.c
+++ b/board/samsung/odroid/odroid.c
@@ -453,9 +453,64 @@ struct s3c_plat_otg_data s5pc210_otg_data = {
.usb_phy_ctrl = EXYNOS4X12_USBPHY_CONTROL,
.usb_flags = PHY0_SLEEP,
};
+#endif
+
+#if defined(CONFIG_USB_GADGET) || defined(CONFIG_CMD_USB)
+
+#ifdef CONFIG_CMD_USB
+static void set_usb_ethaddr(void)
+{
+ int i;
+ uchar mac[6];
+ unsigned int guid_high = readl(EXYNOS4_GUID_HIGH);
+ unsigned int guid_low = readl(EXYNOS4_GUID_LOW);
>>>
>>>
>>> We don't allow direct access.
>>> Is it special register? I can't find this register on TRM.
>>> If so you can make inline function at cpu.h instead.
>>>
>>
>> This register is not in the TRM. This register is possibly documented
>> in the TRM for the Exynos5250. Through experimentation I found that it
>> behaves the same on Exynos4412 prime as well - I checked this with one
>
Re: [U-Boot] [PATCH v2 3/3] arm: odroid: usb: add support for usb host including ethernet
Hello Minkyu Kang,
On Mon, Oct 27, 2014 at 6:03 AM, Minkyu Kang wrote:
> Dear Suriyan Ramasami,
>
> On 25/10/14 01:08, Suriyan Ramasami wrote:
>> Hello Minkyu Kang,
>>
>>
>> On Thu, Oct 23, 2014 at 9:58 PM, Minkyu Kang wrote:
>>> Dear Suriyan Ramasami,
>>>
>>> On 21/10/14 02:52, Suriyan Ramasami wrote:
This change adds support for enabling the USB host features of the board.
This includes the USB3503A hub and the SMC LAN9730 ethernet controller
as well.
Credit goes to Tushar Berara for the function set_usb_ethaddr().
Signed-off-by: Suriyan Ramasami
---
v2:
* Removed an unneeded header file from ehci-exynos.c
* Fix indentation in the dts file
---
arch/arm/dts/exynos4412-odroid.dts | 11 +++
arch/arm/include/asm/arch-exynos/cpu.h | 2 ++
arch/arm/include/asm/arch-exynos/ehci.h | 13
board/samsung/odroid/odroid.c | 55
+
drivers/usb/host/ehci-exynos.c | 51
+-
include/configs/odroid.h| 13
6 files changed, 137 insertions(+), 8 deletions(-)
diff --git a/arch/arm/dts/exynos4412-odroid.dts
b/arch/arm/dts/exynos4412-odroid.dts
index 24d0bf1..ac5fece 100644
--- a/arch/arm/dts/exynos4412-odroid.dts
+++ b/arch/arm/dts/exynos4412-odroid.dts
@@ -67,4 +67,15 @@
div = <0x3>;
index = <4>;
};
+
+ ehci@1258 {
+ compatible = "samsung,exynos-ehci";
+ reg = <0x1258 0x100>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ phy {
+ compatible = "samsung,exynos-usb-phy";
+ reg = <0x125B 0x100>;
+ };
+ };
};
diff --git a/arch/arm/include/asm/arch-exynos/cpu.h
b/arch/arm/include/asm/arch-exynos/cpu.h
index ba71714..fda21fb 100644
--- a/arch/arm/include/asm/arch-exynos/cpu.h
+++ b/arch/arm/include/asm/arch-exynos/cpu.h
@@ -18,6 +18,8 @@
#define EXYNOS4_GPIO_PART3_BASE 0x0386
#define EXYNOS4_PRO_ID 0x1000
+#define EXYNOS4_GUID_LOW 0x1014
+#define EXYNOS4_GUID_HIGH0x1018
#define EXYNOS4_SYSREG_BASE 0x1001
#define EXYNOS4_POWER_BASE 0x1002
#define EXYNOS4_SWRESET 0x10020400
diff --git a/arch/arm/include/asm/arch-exynos/ehci.h
b/arch/arm/include/asm/arch-exynos/ehci.h
index d2d70bd..3800fa9 100644
--- a/arch/arm/include/asm/arch-exynos/ehci.h
+++ b/arch/arm/include/asm/arch-exynos/ehci.h
@@ -12,6 +12,13 @@
#define CLK_24MHZ5
+#define PHYPWR_NORMAL_MASK_PHY0 (0x39 << 0)
+#define PHYPWR_NORMAL_MASK_PHY1 (0x7 << 6)
+#define PHYPWR_NORMAL_MASK_HSIC0(0x7 << 9)
+#define PHYPWR_NORMAL_MASK_HSIC1(0x7 << 12)
+#define RSTCON_HOSTPHY_SWRST(0xf << 3)
+#define RSTCON_SWRST(0x1 << 0)
+
#define HOST_CTRL0_PHYSWRSTALL (1 << 31)
#define HOST_CTRL0_COMMONON_N(1 << 9)
#define HOST_CTRL0_SIDDQ (1 << 6)
@@ -61,6 +68,12 @@ struct exynos_usb_phy {
unsigned int usbotgtune;
};
+struct exynos4412_usb_phy {
+ unsigned int usbphyctrl;
+ unsigned int usbphyclk;
+ unsigned int usbphyrstcon;
+};
+
/* Switch on the VBUS power. */
int board_usb_vbus_init(void);
diff --git a/board/samsung/odroid/odroid.c b/board/samsung/odroid/odroid.c
index 5edb250..6c78b67 100644
--- a/board/samsung/odroid/odroid.c
+++ b/board/samsung/odroid/odroid.c
@@ -453,9 +453,64 @@ struct s3c_plat_otg_data s5pc210_otg_data = {
.usb_phy_ctrl = EXYNOS4X12_USBPHY_CONTROL,
.usb_flags = PHY0_SLEEP,
};
+#endif
+
+#if defined(CONFIG_USB_GADGET) || defined(CONFIG_CMD_USB)
+
+#ifdef CONFIG_CMD_USB
+static void set_usb_ethaddr(void)
+{
+ int i;
+ uchar mac[6];
+ unsigned int guid_high = readl(EXYNOS4_GUID_HIGH);
+ unsigned int guid_low = readl(EXYNOS4_GUID_LOW);
>>>
>>> We don't allow direct access.
>>> Is it special register? I can't find this register on TRM.
>>> If so you can make inline function at cpu.h instead.
>>>
>>
>> This register is not in the TRM. This register is possibly documented
>> in the TRM for the Exynos5250. Through experimentation I found that it
>> behaves the same on Exynos4412 prime as well - I checked this with one
>> X2, 1 U2 and 2 U3s, and they do indeed do the job of being u
[U-Boot] [PATCH 1/2] am335x_evm: Add NOR to Kconfig
Make enabling support for NOR (and describe where it's seen) be done via Kconfig. Signed-off-by: Tom Rini --- board/ti/am335x/Kconfig |7 +++ configs/am335x_evm_nor_defconfig |3 ++- configs/am335x_evm_norboot_defconfig |3 ++- 3 files changed, 11 insertions(+), 2 deletions(-) diff --git a/board/ti/am335x/Kconfig b/board/ti/am335x/Kconfig index d8958ef..0ba00bf 100644 --- a/board/ti/am335x/Kconfig +++ b/board/ti/am335x/Kconfig @@ -25,4 +25,11 @@ config CONS_INDEX board you may want something other than UART0 as for example the IDK uses UART3 so enter 4 here. +config NOR + bool "Support for NOR flash" + help + The AM335x SoC supports having a NOR flash connected to the GPMC. + In practice this is seen as a NOR flash module connected to the + "memory cape" for the BeagleBone family. + endif diff --git a/configs/am335x_evm_nor_defconfig b/configs/am335x_evm_nor_defconfig index 41f31cc02..be90163 100644 --- a/configs/am335x_evm_nor_defconfig +++ b/configs/am335x_evm_nor_defconfig @@ -1,5 +1,6 @@ CONFIG_SPL=y -CONFIG_SYS_EXTRA_OPTIONS="NAND,NOR" +CONFIG_SYS_EXTRA_OPTIONS="NAND" CONFIG_CONS_INDEX=1 +S:CONFIG_ARM=y +S:CONFIG_TARGET_AM335X_EVM=y +CONFIG_NOR=y diff --git a/configs/am335x_evm_norboot_defconfig b/configs/am335x_evm_norboot_defconfig index 7dbfa27..d2d3ba2 100644 --- a/configs/am335x_evm_norboot_defconfig +++ b/configs/am335x_evm_norboot_defconfig @@ -1,4 +1,5 @@ -CONFIG_SYS_EXTRA_OPTIONS="NOR,NOR_BOOT" +CONFIG_SYS_EXTRA_OPTIONS="NOR_BOOT" CONFIG_CONS_INDEX=1 CONFIG_ARM=y CONFIG_TARGET_AM335X_EVM=y +CONFIG_NOR=y -- 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] am335x_evm: Convert NOR_BOOT to Kconfig
Signed-off-by: Tom Rini --- board/ti/am335x/Kconfig |8 configs/am335x_evm_norboot_defconfig |2 +- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/board/ti/am335x/Kconfig b/board/ti/am335x/Kconfig index 0ba00bf..883ff45 100644 --- a/board/ti/am335x/Kconfig +++ b/board/ti/am335x/Kconfig @@ -32,4 +32,12 @@ config NOR In practice this is seen as a NOR flash module connected to the "memory cape" for the BeagleBone family. +config NOR_BOOT + bool "Support for booting from NOR flash" + depends on NOR + help + Enabling this will make a U-Boot binary that is capable of being + booted via NOR. In this case we will enable certain pinmux early + as the ROM only partially sets up pinmux. We also default to using + NOR for environment. endif diff --git a/configs/am335x_evm_norboot_defconfig b/configs/am335x_evm_norboot_defconfig index d2d3ba2..47ff6cd 100644 --- a/configs/am335x_evm_norboot_defconfig +++ b/configs/am335x_evm_norboot_defconfig @@ -1,5 +1,5 @@ -CONFIG_SYS_EXTRA_OPTIONS="NOR_BOOT" CONFIG_CONS_INDEX=1 CONFIG_ARM=y CONFIG_TARGET_AM335X_EVM=y CONFIG_NOR=y +CONFIG_NOR_BOOT=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] e1000: fix sw fw sync on igb i210/i211
On Sun, Oct 26, 2014 at 2:57 PM, Marcel Ziswiler wrote: > On Thu, 2014-10-23 at 01:12 -0700, Tim Harvey wrote: >> I've never been able to get e1000_swfw_sync_acquire() to not timeout >> on the boards with i210 devices that I have (IMX6 with 2x i210 >> programmed as 8086:1533 using int phys). > > Ah, OK. I see. We do use them in flash less aka iNVM only mode as > 8086:157b. > >> In my case with your patch >> below as well as York's patch >> (https://patchwork.ozlabs.org/patch/400628/) I still see failures. The >> I210_SW_FW_SYNC reg returns swfw_sync=0x03, fwmask=0x2, and >> swmask=0x2 which results in: >> >> Driver can't access resource, SW_FW_SYNC timeout. >> Unable to acquire swfw sync >> Error Resetting the PHY >> e1000: e1000#0: ERROR: Hardware Initialization Failed > > As follows my results: > > unprogrammed i210 >01:00.0- 8086:1531 - Network controller > swfw_sync=0x0, fwmask=0x2, swmask=0x2 > e1000: e1000#0: ERROR: Hardware Initialization Failed > > programmed i210 >01:00.0- 8086:157b - Network controller > swfw_sync=0x0, fwmask=0x2, swmask=0x2 > working > > unprogrammed i211 >01:00.0- 8086:1532 - Network controller > swfw_sync=0x0, fwmask=0x2, swmask=0x2 > working > > programmed i211 >01:00.0- 8086:1539 - Network controller > swfw_sync=0x0, fwmask=0x2, swmask=0x2 > working > Marcel, What is the configuration of your i210 - is it using an external PHY or internal? I noticed in e1000.c SWSM is 0x5B50 which is the same reg your adding in your patch here. I think at least you should fix that (use the register definition already created). It looks like bit0 of SWSM which is set in my case and clear in yours is used as a flag in the driver in a few places and perhaps has nothing to do with hardware state. I'll have to add some debugging to see whats going on. Tim >> I've always had to ignore the return value from e1000_reset() to avoid >> this issue and use the devices. > > As mentioned before for me only the unprogrammed i210 gives me grief as > it does not assert the CFG_DONE bit in the EEMNGCTL register upon PHY > reset. However the e1000_swfw_sync_acquire() always works just fine. > >> Any ideas? > > Maybe the flash less aka iNVM only i210 behaves differently. > > Let me enquire Intel about this as well, I anyway need to ask our rep > about the latest eepromARM programming tool as we have an upcoming > production lot of a few thousand units arrive any minute now. > >> I don't have any i211's but I'll see if I can get hold of an >> unprogrammed i210 to test with. > > Sure, would be interesting to see whether yours behave equally. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/1] fs: fat/ext4/sandbox: Deal with files > 2GB
Hello Albert, On Sun, Oct 26, 2014 at 11:35 PM, Albert ARIBAUD wrote: > Hello Suriyan, > > On Sun, 26 Oct 2014 21:42:52 -0700, Suriyan Ramasami > wrote: > >> Subject: [PATCH v3 1/1] fs: fat/ext4/sandbox: Deal with files > 2GB > > Could you repost using the full 'negative' word instead of an > abbreviation? Otherwise people looking for issues by keywords might > miss this one. > I shall do so in version 4. Thanks! - Suriyan > Amicalement, > -- > Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 1/1] fs: fat/ext4/sandbox: Deal with files greater than 2GB
The commands fatls/ext4ls give negative values when dealing with files
greater than 2GB.
The commands fatsize/ext4size do not update the variable filesize for
these files.
To deal with this, the fs functions have been modified to take an additional
parameter of type "* loff_t" which is then populated. The return value of the
fs functions are used only for error contitions.
Signed-off-by: Suriyan Ramasami
---
v4:
* Support generic fs write commands
* Sync up behavior of fs load vs fatload and ext4load
* albert - change -ve to negative in commit message
v3:
* Added testcase to test writes
* Correct function set_contents() in fs/fat/fat_write.c
v2:
* Added test case for fat/ext4 in test/fs/testfs.sh
* md5sum: call map_sysmem() for buffer that md5_wd will work on
v1:
* First try.
---
arch/sandbox/cpu/os.c | 11 +-
arch/sandbox/cpu/state.c | 6 +-
common/board_f.c | 6 +-
common/cmd_ext4.c | 61 ++---
common/cmd_fat.c | 9 +-
common/cmd_fs.c | 17 +++
common/cmd_md5sum.c | 12 +-
common/env_fat.c | 4 +-
fs/ext4/ext4_common.c | 24 ++--
fs/ext4/ext4_common.h | 4 +-
fs/ext4/ext4_write.c | 32 +
fs/ext4/ext4fs.c | 37 ++---
fs/fat/fat.c | 124 +
fs/fat/fat_write.c| 59
fs/fat/file.c | 7 +-
fs/fs.c | 77 ++-
fs/sandbox/sandboxfs.c| 25 ++--
include/configs/sandbox.h | 2 +
include/ext4fs.h | 13 +-
include/fat.h | 19 +--
include/fs.h | 8 +-
include/os.h | 2 +-
include/sandboxfs.h | 8 +-
test/fs/testfs.sh | 334 ++
24 files changed, 655 insertions(+), 246 deletions(-)
create mode 100755 test/fs/testfs.sh
diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c
index 1c4aa3f..43872e8 100644
--- a/arch/sandbox/cpu/os.c
+++ b/arch/sandbox/cpu/os.c
@@ -385,7 +385,7 @@ const char *os_dirent_get_typename(enum os_dirent_t type)
return os_dirent_typename[OS_FILET_UNKNOWN];
}
-ssize_t os_get_filesize(const char *fname)
+int os_get_filesize(const char *fname, loff_t *size)
{
struct stat buf;
int ret;
@@ -393,7 +393,8 @@ ssize_t os_get_filesize(const char *fname)
ret = stat(fname, &buf);
if (ret)
return ret;
- return buf.st_size;
+ *size = buf.st_size;
+ return 0;
}
void os_putc(int ch)
@@ -427,10 +428,10 @@ int os_read_ram_buf(const char *fname)
{
struct sandbox_state *state = state_get_current();
int fd, ret;
- int size;
+ loff_t size;
- size = os_get_filesize(fname);
- if (size < 0)
+ ret = os_get_filesize(fname, &size);
+ if (ret < 0)
return -ENOENT;
if (size != state->ram_size)
return -ENOSPC;
diff --git a/arch/sandbox/cpu/state.c b/arch/sandbox/cpu/state.c
index 59adad6..07d2aea 100644
--- a/arch/sandbox/cpu/state.c
+++ b/arch/sandbox/cpu/state.c
@@ -49,12 +49,12 @@ static int state_ensure_space(int extra_size)
static int state_read_file(struct sandbox_state *state, const char *fname)
{
- int size;
+ loff_t size;
int ret;
int fd;
- size = os_get_filesize(fname);
- if (size < 0) {
+ ret = os_get_filesize(fname, &size);
+ if (ret < 0) {
printf("Cannot find sandbox state file '%s'\n", fname);
return -ENOENT;
}
diff --git a/common/board_f.c b/common/board_f.c
index b5bebc9..1fae112 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -285,7 +285,7 @@ static int read_fdt_from_file(void)
struct sandbox_state *state = state_get_current();
const char *fname = state->fdt_fname;
void *blob;
- ssize_t size;
+ loff_t size;
int err;
int fd;
@@ -298,8 +298,8 @@ static int read_fdt_from_file(void)
return -EINVAL;
}
- size = os_get_filesize(fname);
- if (size < 0) {
+ err = os_get_filesize(fname, &size);
+ if (err < 0) {
printf("Failed to file FDT file '%s'\n", fname);
return -ENOENT;
}
diff --git a/common/cmd_ext4.c b/common/cmd_ext4.c
index ecfc6d3..19423d1 100644
--- a/common/cmd_ext4.c
+++ b/common/cmd_ext4.c
@@ -61,61 +61,16 @@ int do_ext4_ls(cmd_tbl_t *cmdtp, int flag, int argc, char
*const argv[])
#if defined(CONFIG_CMD_EXT4_WRITE)
int do_ext4_write(cmd_tbl_t *cmdtp, int flag, int argc,
- char *const argv[])
+ char *const argv[])
{
- const char *filename = "/";
- int dev, part;
- unsigned long ram_address;
- unsigned long file_size;
- disk_partition_t info;
- block_dev_desc_t *dev_desc;
-
- if (argc < 6)
- return cmd_usage(cmdtp);
-
- part = get_device_and_partition(argv[1], argv[
[U-Boot] [PATCH v3 0/3] reduce warnings with W=1
When compiling u-boot with W=1 there are numerous of warnings. This patchset attempts to reduce it a bit. One source of false warnings are the aliases missing a prototype, most of them are replaced with __weak functions. Others are cause by missing includes / local functions not be marked as such. At last some actual missing prototypes are added. These are (hopefully) just trivial patches, some less than trial is ahead of us. v3: - i2c did contain another alias function, i2c_init_board. This time the correct patch is squashed with it. Only this patch resend (1/3). v2: - rebase on master (most of this serie is applied, so remaining patches are numbered differently. - drop "PATCH 25/49 spi: make local functions static". Tom posted a more complete cleanup. - Drop common/cmd_elf.c: add missing include (a slightly adjusted version was applied). - split i2c: use __weak (included i2c and l2_cache) - redo serial: add prototypes for init functions Jeroen Hofstee (3): i2c: use __weak arm926ejs: cache: use __weak serial: add prototypes for init functions arch/arm/cpu/arm926ejs/cache.c | 5 +- drivers/i2c/i2c_core.c | 8 +-- drivers/serial/serial.c| 140 - include/serial.h | 49 +++ 4 files changed, 122 insertions(+), 80 deletions(-) -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/3] i2c: use __weak
Cc: Heiko Schocher
Signed-off-by: Jeroen Hofstee
---
drivers/i2c/i2c_core.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/i2c_core.c b/drivers/i2c/i2c_core.c
index 18d6736..d34b749 100644
--- a/drivers/i2c/i2c_core.c
+++ b/drivers/i2c/i2c_core.c
@@ -229,11 +229,9 @@ static void i2c_init_bus(unsigned int bus_no, int speed,
int slaveaddr)
}
/* implement possible board specific board init */
-static void __def_i2c_init_board(void)
+__weak void i2c_init_board(void)
{
}
-void i2c_init_board(void)
- __attribute__((weak, alias("__def_i2c_init_board")));
/*
* i2c_init_all():
@@ -395,9 +393,7 @@ void i2c_reg_write(uint8_t addr, uint8_t reg, uint8_t val)
i2c_write(addr, reg, 1, &val, 1);
}
-void __i2c_init(int speed, int slaveaddr)
+__weak void i2c_init(int speed, int slaveaddr)
{
i2c_init_bus(i2c_get_bus_num(), speed, slaveaddr);
}
-void i2c_init(int speed, int slaveaddr)
- __attribute__((weak, alias("__i2c_init")));
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] e1000: add i211 and unprogrammed i210/i211 support
On Mon, Sep 08, 2014 at 12:03:50AM +0200, Marcel Ziswiler wrote: > This patch adds support for i211 as well as unprogrammed aka tools only > i210/i211 chip support. > > Signed-off-by: Marcel Ziswiler Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] stdio: staticize locally-used call-backs
On Tue, Sep 30, 2014 at 04:01:45PM -0700, Eric Nelson wrote: > The various nulldev_x and stdio_serial_x calls are only used indirectly > through the nulldev and serial devices, so make them static and > prevent the dreaded "Should it be static?" warning with "make C=1". > > Signed-off-by: Eric Nelson Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-mpc5xxx / master
On Mon, Oct 27, 2014 at 03:29:51PM +0100, Wolfgang Denk wrote: > Dear Tom, > > The following changes since commit d0796defbe8eff6fc3c27c893dcbc47af59d4764: > > Merge http://git.denx.de/u-boot-sunxi (2014-10-26 14:13:24 -0400) > > are available in the git repository at: > > > git://git.denx.de/u-boot-mpc5xxx.git master > > for you to fetch changes up to f06f9a1fb1cd332435b9e8660355f57d7d3f98d8: > > ppc: Zap TQM8272 board (2014-10-27 14:35:56 +0100) > > > Anatolij Gustschin (8): > powerpc: mpc512x: fix boot breakage > powerpc: mpc5121ads: convert to generic board > powerpc: pdm360ng: convert to generic board > powerpc: aria: convert to generic board > powerpc: ac14xx: convert to generic board > powerpc: mecp5123: convert to generic board > powerpc: digsy_mtc: convert to generic board > powerpc: mpc5121ads: update board config info in README > > Marek Vasut (7): > ppc: Zap ICU862 board > ppc: Zap MHPC board > ppc: Zap Hymod board > ppc: Zap HWW1U1A board > ppc: Zap IDS8247 board > ppc: Zap TQM8260 board > ppc: Zap TQM8272 board > > Wolfgang Denk (2): > README.scrapyard: update commit IDs > PowerPC: drop some 74xx_7xx boards and related code > > arch/powerpc/cpu/74xx_7xx/Kconfig | 16 - > arch/powerpc/cpu/74xx_7xx/start.S | 13 +- > arch/powerpc/cpu/mpc8260/Kconfig | 16 - > arch/powerpc/cpu/mpc8260/ether_fcc.c | 27 +- > arch/powerpc/cpu/mpc8260/interrupts.c | 10 +- > arch/powerpc/cpu/mpc8260/pci.c|2 - > arch/powerpc/cpu/mpc8260/start.S | 14 - > arch/powerpc/cpu/mpc83xx/start.S | 11 - > arch/powerpc/cpu/mpc85xx/Kconfig |4 - > arch/powerpc/cpu/mpc8xx/Kconfig |8 - > arch/powerpc/cpu/mpc8xx/cpu_init.c|2 - > arch/powerpc/cpu/mpc8xx/fec.c | 40 +- > arch/powerpc/include/asm/immap_512x.h |1 + > arch/powerpc/include/asm/u-boot.h |3 - > board/Marvell/common/flash.c | 1056 --- > board/Marvell/common/i2c.c| 521 -- > board/Marvell/common/intel_flash.c| 253 --- > board/Marvell/common/misc.S | 235 --- > board/Marvell/common/serial.c |8 - > board/Marvell/db64360/64360.h | 36 - > board/Marvell/db64360/Kconfig | 12 - > board/Marvell/db64360/MAINTAINERS |6 - > board/Marvell/db64360/Makefile| 13 - > board/Marvell/db64360/README | 105 -- > board/Marvell/db64360/db64360.c | 922 - > board/Marvell/db64360/eth.h | 28 - > board/Marvell/db64360/mpsc.c | 1001 -- > board/Marvell/db64360/mpsc.h | 140 -- > board/Marvell/db64360/mv_eth.c| 3128 --- > board/Marvell/db64360/mv_eth.h| 818 > board/Marvell/db64360/mv_regs.h | 1108 --- > board/Marvell/db64360/pci.c | 923 - > board/Marvell/db64360/sdram_init.c| 1945 --- > board/Marvell/db64460/64460.h | 36 - > board/Marvell/db64460/Kconfig | 12 - > board/Marvell/db64460/MAINTAINERS |6 - > board/Marvell/db64460/Makefile| 13 - > board/Marvell/db64460/README | 105 -- > board/Marvell/db64460/db64460.c | 922 - > board/Marvell/db64460/eth.h | 27 - > board/Marvell/db64460/mpsc.c | 1001 -- > board/Marvell/db64460/mpsc.h | 140 -- > board/Marvell/db64460/mv_eth.c| 3127 --- > board/Marvell/db64460/mv_eth.h| 815 > board/Marvell/db64460/mv_regs.h | 1108 --- > board/Marvell/db64460/pci.c | 923 - > board/Marvell/db64460/sdram_init.c| 1950 --- > board/Marvell/include/core.h | 236 --- > board/Marvell/include/mv_gen_reg.h| 2296 --- > board/eltec/mhpc/Kconfig | 12 - > board/eltec/mhpc/MAINTAINERS |6 - > board/eltec/mhpc/Makefile |8 - > board/eltec/mhpc/flash.c | 414 - > board/eltec/mhpc/mhpc.c | 465 - > board/eltec/mhpc/u-boot.lds.debug | 121 -- > board/esd/cpci750/64360.h | 37 - > board/esd/cpci750/Kconfig | 12 - > board/esd/cpci750/MAINTAINERS |6 - > board/esd/cpci750/Makefile| 14 - > board/esd/cpci750/cpci750.c | 1088 --- > board/esd/cpci750/eth.h | 28 - > board/esd/cpci750/i2c.c | 475 - > board/esd/cpci750/i2c.h | 16 - > board/esd/cpci750/ide.c | 74 - > board/esd/cpci750/local.h | 69 - > board/esd/cpci750/misc.S | 245 --- > board/esd/cpci750/mpsc.c | 1002 -- > board/esd/cpci750/mpsc.h
Re: [U-Boot] cli: hush: Adjust 'run' command to run each line of the env var
On Tue, Oct 07, 2014 at 01:59:43PM -0600, Simon Glass wrote: > The run command treats each argument an an environment variable. It gets the > value of each variable and executes it as a command. If an environment > variable contains a newline and the hush cli is used, it is supposed to > execute each line one after the other. > > Normally a newline signals to hush to exit - this is used in normal command > line entry - after a command is entered we want to return to allow the user > to enter the next one. But environment variables obviously need to execute > to completion. > > Add a special case for the execution of environment variables which > continues when a newline is seen, and add a few tests to check this > behaviour. > > Note: it's not impossible that this may cause regressions in other areas. > I can't think of a case but with any change of behaviour with limited test > coverage there is always a risk. From what I can tell this behaviour has > been around since at least U-Boot 2011.03, although this pre-dates sandbox > and I have not tested it on real hardware. > > Reported-by: Wolfgang Denk > Signed-off-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
