Re: [U-Boot] [PATCH] mx6: fsl_esdhc: Fix waiting for DMA operation completion
> From: Eric Nelson [eric.nel...@boundarydevices.com] > Sent: Wednesday, April 03, 2013 01:50 > To: Dirk Behme > Cc: Gabbasov, Andrew; u-boot@lists.denx.de > Subject: Re: [U-Boot] [PATCH] mx6: fsl_esdhc: Fix waiting for DMA operation > completion > > Thanks Dirk, > > On 04/02/2013 11:10 AM, Dirk Behme wrote: > > Am 02.04.2013 17:49, schrieb Eric Nelson: > >> Thanks Andrew, > >> > >> On 04/02/2013 03:04 AM, Andrew Gabbasov wrote: > >>> On iMX6 sometimes the Transfer Complete interrupt occurs earlier > >>> than the DMA part completes its operation. If immediately after that > >>> the read data is used for some data verification, those obtained data > >>> may be incomplete, which causes intermittent verification failures. > >>> > >> > >> Can you describe how to repeat this? > >> > >>> For example, when the default environment command tries to load and run > >>> boot script from FAT partition on SD/MMC card, it sometimes fails, > >>> reporting invalid partition table, or unknown partition type, or > >>> something else of that kind. Such errors disappear if the build > >>> configuration has CONFIG_SYS_FSL_ESDHC_USE_PIO, or if some delay > >>> is added after transfer completion. > >>> > >> We do this on every boot on SABRE Lite and Nitrogen6x boards, > >> and haven't seen an issue. > >> > >> What board are you testing on? > >> > >> Do you have cache enabled? > >> > >> Is this with an SD card or eMMC? > > > > Andrew will have the details, but to my understanding this implements in > > U-Boot what the Freescale kernel has in > > > > http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/drivers/mmc/host/sdhci-esdhc-imx.c?h=imx_3.0.35_12.09.01#n234 > > > > Andrew, did you trap one of these? Hi Eric, Yes, I saw that part of code in the kernel and that led me to check if the events can come out of order in my case, and after finding that they indeed do, to make that patch. So, this is the similar workaround but on U-Boot level. Thanks. Best regards, Andrew ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Makefile: fix clobber target
Remove the $(CONFIG_SPL_TARGET) from ALL-y if not set. This prevents following warning: ---8<--- abiessmann@punisher % ./MAKEALL -a arm -s omap3 rm: cannot remove `/tmp/build_test/eco5pk/': Is a directory make: *** [clobber] Error 1 rm: cannot remove `/tmp/build_test/omap3_overo/': Is a directory make: *** [clobber] Error 1 --->8--- Signed-off-by: Andreas Bießmann --- Makefile |2 ++ 1 file changed, 2 insertions(+) diff --git a/Makefile b/Makefile index d60a14b..5302c0a 100644 --- a/Makefile +++ b/Makefile @@ -406,7 +406,9 @@ ALL-y += $(obj)u-boot.srec $(obj)u-boot.bin $(obj)System.map ALL-$(CONFIG_NAND_U_BOOT) += $(obj)u-boot-nand.bin ALL-$(CONFIG_ONENAND_U_BOOT) += $(obj)u-boot-onenand.bin ALL-$(CONFIG_SPL) += $(obj)spl/u-boot-spl.bin +ifneq ($(CONFIG_SPL_TARGET),) ALL-$(CONFIG_SPL) += $(obj)$(subst ",,$(CONFIG_SPL_TARGET)) +endif ALL-$(CONFIG_OF_SEPARATE) += $(obj)u-boot.dtb $(obj)u-boot-dtb.bin # enable combined SPL/u-boot/dtb rules for tegra -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v9 18/30] nand: mxc: Switch NAND SPL to generic SPL
Hi Benoît, On Wed, 3 Apr 2013 08:30:12 +0200 (CEST), Benoît Thébaudeau wrote: > Hi Albert, > > Here is the v10 bundle for those who want to test: > http://dl.free.fr/vdXBGExyq Thanks, will build-test it ASAP. People with ARM (expecially tx25 and mx31pdk) and non-ARM boards please run-test it too. > The resulting HEAD is identical to yours, except for > board/freescale/mx31ads/u-boot.lds in which you had removed the following > unrelated line for 30/30: > __bss_end = .; > > Regarding this line, it is also present in a few other .lds, as well as the > following ones: > KEEP(*(.__bss_start)); > KEEP(*(__bss_end)); > > However, the end section is named .__bss_end in arch/arm/lib/bss.c, so there > is > perhaps something wrong here, unless you did that on purpose because of the > __bss_end test at the end of the linker script. I had noticed that, but I let > you handle it. If something needs to be changed here, please do it after my > series if possible in order to avoid a v11 because of newer rebase conflicts. > ;) Normally, defining __bss_end symbols in the ARM lds files has become unnecessary as arch/arm/lib/bss.c now defines then (and in so doing avoids generating ugly R_ARM_ABS32 relocation records) so yes, the line removal was intentional, but indeed unrelated to your series. As for the missing period in the .__bss_end input section specification, thanks for bringing this to my attention. I'll give it a look at once as this could lead to tricky bugs popping up... > I have also noticed that patman is broken in u-boot-arm/master. I don't know > if > this has already been fixed somewhere, but it fails with an internal error > while > running checkpatch, as if an incompatible API change had been made to > checkpatch > recently, and not propagated to patman. Cc:ing Simon Glass on patman. Note: u-boot-arm/master is pretty close to u-boot/master at the moment. > Best regards, > Benoît Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] u-boot boot process is broken, how do i recover?
Hi, I've got a readynas and successfully installed a recent kernel into ROM and Debian onto hard-drive. But when I tried to modify the uboot-env from uboot-console I had trouble with the ; in the vars. And did not know how to escape. So I tried to access uboot-env from linux. I applied something like this (well, not that straight forward) /etc/fw_env.config # deviceoffset size Flash sector size Number of sectors /dev/mtd1 0x0 0x2 0x2 1 Maybe there is something wrong in my config? apt-get install uboot-envtools fw_printenv bootcmd fw_setenv bootcmd.bak 'nand read.e 0x120 0x20 0x60;nand read.e 0x200 0x80 0x100;bootm 0x120 0x200' fw_setenv bootcmd 'nand read.e 0x120 0x20 0x60;bootm 0x120' fw_printenv bootcmd.bak bootcmd fw_printenv bootargs fw_setenv bootargs.bak 'console=ttyS0,115200 reason=normal mtdparts=nand_mtd:0x18@0(u-boot),0x2@0x18(u-boot-env),0x60@0x20(uImage),0x100@0x80(minirootfs),0x680@0x180(jffs2)' fw_setenv bootargs 'console=ttyS0,115200 root=/dev/sda3 mtdparts=nand_mtd:0x18@0(u-boot),0x2@0x18(u-boot-env),0x60@0x20(uImage),0x100@0x80(minirootfs),0x680@0x180(jffs2)' fw_printenv bootargs.bak bootargs btw, kernel said: Creating 5 MTD partitions on "nand_mtd": 0x-0x0018 : "u-boot" 0x0018-0x001a : "u-boot-env" 0x0020-0x0080 : "uImage" 0x0080-0x0180 : "minirootfs" 0x0180-0x0800 : "jffs2" Now the boot process is broken. I don't understand why. It stops right after the network (see below). Usually the boot countdown should appear afterwards. Is there anything I can do except unsoldering the ROM? If I have to remove the chip and burn it using an external writer... Is there any way to buy similar chip which can be mounted on a socket? It's a H27U1G8F2BTR-BC (newer version of HY27UF081G2B-TCB) which is NAND flash, 2,7-3,6V, 1Gbitx8 (128 MiB), SLC Single Die + Large Block, TSOP 48 pin. There is also a FBGA 63 PIN available. are there any sockets for FBGA I can solder to TSOP? Or do other manufacturers offer compatible chips which can be applied to a socket? thanks for any help! Jan __ __ _ _ | \/ | __ _ _ _| | | | |\/| |/ _` | '__\ \ / / _ \ | | | | | | (_| | | \ V / __/ | | |_| |_|\__,_|_|\_/ \___|_|_| _ _ _ | | | | | __ ) ___ ___ | |_ | | | |___| _ \ / _ \ / _ \| __| | |_| |___| |_) | (_) | (_) | |_ \___/|/ \___/ \___/ \__| ** MARVELL BOARD: DB-88F6282A-BP LE U-Boot 1.1.4 (Feb 6 2012 - 14:40:46) Marvell version: 3.4.27 Netgear version: Uboot-1_1_4-NetgearDUOV3-V1008 U-Boot code: 0060 -> 0067FFF0 BSS: -> 006D0120 Soc: MV88F1155 Rev 1 (DDR3) CPU running @ 1600Mhz L2 running @ 533Mhz SysClock = 533Mhz , TClock = 200Mhz DRAM unknown CAL tRP = 8 tRAS = 20 tRCD=8 DRAM CS[0] base 0x size 256MB DRAM Total size 256MB 16bit width Addresses 8M - 0M are saved for the U-Boot usage. Mem malloc Initialization (8M - 7M): Done NAND:128 MB Flash: 0 kB CPU : Marvell Feroceon (Rev 1) Streaming disabled Write allocate disabled USB 0: host mode PEX 0: PCI Express Root Complex Interface PEX interface detected Link X1 Switch On ! Net: egiga0 [PRIME] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 3/3] mx6qsabre{sd, auto}: Add boot mode select
On 16/03/2013 19:05, Otavio Salvador wrote: > Adds support for 'bmode' command which let user to choose where to > boot from; this allows U-Boot to load system from another storage > without messing with jumpers. > > Signed-off-by: Otavio Salvador > --- Applied to u-boot-imx, thanks. 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] [PATCH v5 1/3] mx6qsabresd: Document the mapping of USDHC[2-4]
On 16/03/2013 19:05, Otavio Salvador wrote: > This documents the SD card identifier so it is easier for user to spot > which card number will be used, if need. > > Signed-off-by: Otavio Salvador > --- Applied to u-boot-imx, thanks. 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] [PATCH v5 2/3] mx6qsabresd: Fix card detection for invalid card id case
On 16/03/2013 19:05, Otavio Salvador wrote: > This changes the code so in case an unkown value is passed it will > return as invalid. > > Signed-off-by: Otavio Salvador > --- Applied to u-boot-imx, thanks. 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] [PATCH v9 18/30] nand: mxc: Switch NAND SPL to generic SPL
On Wed, 3 Apr 2013 10:05:57 +0200, Albert ARIBAUD wrote: > > The resulting HEAD is identical to yours, except for > > board/freescale/mx31ads/u-boot.lds in which you had removed the following > > unrelated line for 30/30: > > __bss_end = .; > > > > Regarding this line, it is also present in a few other .lds, as well as the > > following ones: > > KEEP(*(.__bss_start)); > > KEEP(*(__bss_end)); > > > > However, the end section is named .__bss_end in arch/arm/lib/bss.c, so > > there is > > perhaps something wrong here, unless you did that on purpose because of the > > __bss_end test at the end of the linker script. I had noticed that, but I > > let > > you handle it. If something needs to be changed here, please do it after my > > series if possible in order to avoid a v11 because of newer rebase > > conflicts. ;) > > Normally, defining __bss_end symbols in the ARM lds files has become > unnecessary as arch/arm/lib/bss.c now defines then (and in so doing > avoids generating ugly R_ARM_ABS32 relocation records) so yes, the line > removal was intentional, but indeed unrelated to your series. > > As for the missing period in the .__bss_end input section specification, > thanks for bringing this to my attention. I'll give it a look at once > as this could lead to tricky bugs popping up... Alright, now that the coffee shot has reached full effect, I think I understand what is going on and indeed that has to be fixed although it most certainly did not cause any issue. In my commit 3ebd1cbc, where the whole bss.c system was put in place, the .__bss_end__ input section specification had the leading period and was thus placed correctly, as was the compiler-generated __bss_end__ symbol from bss.c. Later, when Tom's commit 0ce033d2 manually merged Simon's work turning all __bss_end__ occurrences into __bss_end, two things happened: 1) both the bss.c file and ARM *.lds files then defined __bss_end. 2) the leading period in .__bss_end__ was lost in the conversion. This led to the compiler-generated __bss_end section being mapped away from the whole BSS area -- *before* it, actually, which would have been catastrophic... if the definition for __bss_end from the lds files had not taken precedence over that from bss.c, thus preserving the correct value and semantics for the symbol. In other words, the first issue actually countered the second one, and both stayed hidden as the code continued running as expected. But this has to be fixed, because it causes __bss_end references to generate R_ARM_ABS32 relocation records again, which must be averted (it might be a good idea to add a build-time check to avoid any new R_ARM_ABS32 from creeping up in the future). I'll send out a patch to be taken in 2013.04, in which I'll reintroduce the leading periods in .__bss_end sections, and rename the linker symbols used for overlay mapping (and make them non-exported so that the code won't mistakenly reference them). ... and indeed I won't ask for a V10 rebase for it :) -- either V10 gets in first, or if my patch gets in first, I'll handle rebasing V10 myself. Thanks Benoît for spotting this! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx28evk: Introduce a new target for saving env vars to NAND
On 07/03/2013 22:28, Fabio Estevam wrote: > Introduce 'mx28evk_nand' target for saving environment variables into NAND. > > The mx28evk board does not come with a NAND flash populated from the > factory. It comes with an empty slot (U23), which allows the insertion of a > 48-pin TSOP flash device. > > Tested with a K9LBG08U0D. > > Signed-off-by: Fabio Estevam > --- Applied to u-boot-imx (Fabio, I rebased on current TOT), thanks. Best regards, Stefano -- = 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] mx6qsabrelite: README: No need to pass 'u-boot.imx'
On 20/03/2013 15:07, Fabio Estevam wrote: > From: Fabio Estevam > > The u-boot.imx binary is generated by default, so no need to pass it in the > 'make' line. > > Signed-off-by: Fabio Estevam > --- Applied to u-boot-imx, thanks. Best regards, Stefano -- = 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] u-boot boot process is broken, how do i recover?
Hi JPT, On Wed, 03 Apr 2013 10:13:02 +0200, JPT wrote: > Hi, > > I've got a readynas and successfully installed a recent kernel into ROM > and Debian onto hard-drive. > But when I tried to modify the uboot-env from uboot-console I had > trouble with the ; in the vars. And did not know how to escape. > So I tried to access uboot-env from linux. > > I applied something like this (well, not that straight forward) > > /etc/fw_env.config > # deviceoffset size Flash sector size Number of sectors > /dev/mtd1 0x0 0x2 0x2 1 > > Maybe there is something wrong in my config? Not in /etc/fw_env.config as far as I can tell, but maybe your Netgear-made u-boot is special. > apt-get install uboot-envtools > fw_printenv bootcmd No result there? There should be. > fw_setenv bootcmd.bak 'nand read.e 0x120 0x20 0x60;nand > read.e 0x200 0x80 0x100;bootm 0x120 0x200' > > fw_setenv bootcmd 'nand read.e 0x120 0x20 0x60;bootm 0x120' > > fw_printenv bootcmd.bak bootcmd > fw_printenv bootargs > fw_setenv bootargs.bak 'console=ttyS0,115200 reason=normal > mtdparts=nand_mtd:0x18@0(u-boot),0x2@0x18(u-boot-env),0x60@0x20(uImage),0x100@0x80(minirootfs),0x680@0x180(jffs2)' > > fw_setenv bootargs 'console=ttyS0,115200 root=/dev/sda3 > mtdparts=nand_mtd:0x18@0(u-boot),0x2@0x18(u-boot-env),0x60@0x20(uImage),0x100@0x80(minirootfs),0x680@0x180(jffs2)' > > fw_printenv bootargs.bak bootargs > > > btw, kernel said: > Creating 5 MTD partitions on "nand_mtd": > 0x-0x0018 : "u-boot" > 0x0018-0x001a : "u-boot-env" > 0x0020-0x0080 : "uImage" > 0x0080-0x0180 : "minirootfs" > 0x0180-0x0800 : "jffs2" > > Now the boot process is broken. I don't understand why. > It stops right after the network (see below). Usually the boot countdown > should appear afterwards. > Is there anything I can do except unsoldering the ROM? Yes: get control through JTAG. > If I have to remove the chip and burn it using an external writer... > Is there any way to buy similar chip which can be mounted on a socket? > > It's a H27U1G8F2BTR-BC (newer version of HY27UF081G2B-TCB) > which is NAND flash, 2,7-3,6V, 1Gbitx8 (128 MiB), SLC Single Die + Large > Block, TSOP 48 pin. There is also a FBGA 63 PIN available. are there any > sockets for FBGA I can solder to TSOP? > Or do other manufacturers offer compatible chips which can be applied to > a socket? Don't consider unsoldering / resoldering, all the more if sockets are involved, as long as you board has JTAG, either as a header or at least as contact points. A dumb JTAG probe and OpenOCD will cost you little and go a long way. > thanks for any help! > > Jan Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: mx6qsabrelite: fsl_esdhc: Define maximum bus width supported by SabreLite board
On 21/03/2013 12:00, Abbas Raza wrote: > From: Abbas Raza > > Maximum bus width supported by SabreLite board is not 8bit like > all other mx6q specific boards. In case where both host controller > and card support 8bit transfers, they agree to communicate on 8bit > interface while boards like the SabreLite support only 4bit interface. > Due to this reason the mmc 8bit default mode fails on the SabreLite. > To rectify this, define maximum bus width supported by this board (4bit). > If max_bus_width is not defined, it is 0 by default and 8bit width support > will be enabled in host capabilities otherwise host capabilities are modified > accordingly. > > It is tested with a MMCplus card. > > Signed-off-by: Abbas Raza > cc: stefano Babic > cc: Andy Fleming > Acked-by: Dirk Behme > Acked-by: Andrew Gabbasov > --- Applied to u-boot-imx, thanks. FYI: of course, I will merge the same fix for max_bus_width for Nitrogen6x and Wandboard if posted. 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] [PATCH] spi: mxc_spi: Fix ECSPI reset handling
On 21/03/2013 09:03, Dirk Behme wrote: > Reviewing the ECSPI reset handling shows two issues: > Hi Dirk, agree completely, only a very minor question.. > + > + reg_ctrl = reg_read(®s->ctrl); As you says, it makes no sense to read back the value of the register, also because reg_ctrl is overwritten some lines later ;-) 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] [PATCH] mx25pdk: Enable imxdi RTC
On 22/03/2013 20:30, Benoît Thébaudeau wrote: > The mx25pdk board supports the i.MX25 DryIce RTC (imxdi), so enable it. This > allows to compile-test the imxdi driver in the mainline tree. > > Signed-off-by: Benoît Thébaudeau > --- Applied to u-boot-imx, thanks. Best regards, Stefano -- = 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] mx23_olinuxino: Change definitions to use spaces instead of tabs
On 25/03/2013 03:17, Otavio Salvador wrote: > Change all "#define/ifdef" sequences into "#define/ifdef". > > Signed-off-by: Otavio Salvador > --- Applied to u-boot-imx, thanks. Best regards, Stefano -- = 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] mmc: mx6qsabrelite: fsl_esdhc: Define maximum bus width supported by SabreLite board
On 03.04.2013 11:06, Stefano Babic wrote: On 21/03/2013 12:00, Abbas Raza wrote: From: Abbas Raza Maximum bus width supported by SabreLite board is not 8bit like all other mx6q specific boards. In case where both host controller and card support 8bit transfers, they agree to communicate on 8bit interface while boards like the SabreLite support only 4bit interface. Due to this reason the mmc 8bit default mode fails on the SabreLite. To rectify this, define maximum bus width supported by this board (4bit). If max_bus_width is not defined, it is 0 by default and 8bit width support will be enabled in host capabilities otherwise host capabilities are modified accordingly. It is tested with a MMCplus card. Signed-off-by: Abbas Raza cc: stefano Babic cc: Andy Fleming Acked-by: Dirk Behme Acked-by: Andrew Gabbasov --- Applied to u-boot-imx, thanks. FYI: of course, I will merge the same fix for max_bus_width for Nitrogen6x and Wandboard if posted. Have you noticed v2 of this patch http://lists.denx.de/pipermail/u-boot/2013-March/150119.html ? Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] i.MX6: mx6qsabrelite: README: don't pass chip-select to sf probe command
On 25/03/2013 17:13, Javier Martinez Canillas wrote: > since commit "c1173bd0: sf command: allow default bus and chip selects" > the chip-select and bus arguments for the sf probe command are optional. > Hi Javier, > Even when passing the chip-select to sf probe says to be optional, it > makes "sf erase" and "sf write" to fail on a mx6qsabrelite board. e.g: > > MX6QSABRELITE U-Boot > sf probe 1 > MX6QSABRELITE U-Boot > sf erase 0 0x4 > SPI flash erase failed > MX6QSABRELITE U-Boot > sf write 0x1080 0 0x4 > SPI flash write failed Well, the real reason is that the passed chipselect is wrong. Checking in the configuration file, I see that the value to be passed should be 0x7300. I suppose (I am not testing) that "sf probe 0x7300" make sf erase and sw write working. > > But just using "sf probe" works well. So, update the mx6qsabrelite > README so the commands will work on current U-Boot. I agree with the patch, but the description is wrong. Can you rewrite it simply stating that the chipselect "1" is wrong and that it is not strictly required (but again, is not forbidden) to pass it to sf probe ? 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] [PATCH] mmc: mx6qsabrelite: fsl_esdhc: Define maximum bus width supported by SabreLite board
On 03/04/2013 11:06, Stefano Babic wrote: > On 21/03/2013 12:00, Abbas Raza wrote: >> From: Abbas Raza >> >> Maximum bus width supported by SabreLite board is not 8bit like >> all other mx6q specific boards. In case where both host controller >> and card support 8bit transfers, they agree to communicate on 8bit >> interface while boards like the SabreLite support only 4bit interface. >> Due to this reason the mmc 8bit default mode fails on the SabreLite. >> To rectify this, define maximum bus width supported by this board (4bit). >> If max_bus_width is not defined, it is 0 by default and 8bit width support >> will be enabled in host capabilities otherwise host capabilities are modified >> accordingly. >> >> It is tested with a MMCplus card. >> >> Signed-off-by: Abbas Raza >> cc: stefano Babic >> cc: Andy Fleming >> Acked-by: Dirk Behme >> Acked-by: Andrew Gabbasov >> --- > > Applied to u-boot-imx, thanks. > > FYI: of course, I will merge the same fix for max_bus_width for > Nitrogen6x and Wandboard if posted. > Sorry for noise - I have missed V2. I will apply V2, not V1, fixing all boards. 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] [PATCH v2] mx6: Fix get_board_rev() for the mx6 solo case
On 27/03/2013 18:36, Fabio Estevam wrote:
> When booting a Freescale kernel 3.0.35 on a Wandboard solo, the
> get_board_rev()
> returns 0x62xxx, which is not a value understood by the VPU
> (Video Processing Unit) library in the kernel and causes the video playback
> to
> fail.
>
> The expected values for get_board_rev are:
> 0x63xxx: For mx6quad/dual
> 0x61xxx: For mx6dual-lite/solo
>
> So adjust get_board_rev() accordingly and make it as weak function, so that we
> do not need to define it in every mx6 board file.
>
> Signed-off-by: Fabio Estevam
> ---
Hi Fabio,
> Changes since v1:
> - Avoid extra call to get_cpu_rev()
>
> arch/arm/cpu/armv7/mx6/soc.c | 12
> board/boundary/nitrogen6x/nitrogen6x.c|5 -
> board/freescale/mx6qsabrelite/mx6qsabrelite.c |5 -
> board/freescale/mx6qsabresd/mx6qsabresd.c |5 -
> board/wandboard/wandboard.c |5 -
> 5 files changed, 12 insertions(+), 20 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
> index 193ba12..4f3cd14 100644
> --- a/arch/arm/cpu/armv7/mx6/soc.c
> +++ b/arch/arm/cpu/armv7/mx6/soc.c
> @@ -61,6 +61,18 @@ u32 get_cpu_rev(void)
> return (type << 12) | (reg + 0x10);
> }
>
> +#ifdef CONFIG_REVISION_TAG
> +u32 __weak get_board_rev(void)
> +{
> + u32 cpurev = get_cpu_rev();
> + u32 type = ((cpurev >> 12) & 0xff);
> + if (type == MXC_CPU_MX6SOLO)
> + cpurev = (MXC_CPU_MX6DL) << 12 | (cpurev & 0xFFF);
> +
> + return cpurev;
> +}
> +#endif
> +
We use a cpu revision as board revision, and this seems quite perverse.
Anyway, I understand the reasons, and this seems a good way to work
around bugs in other (FSL) code without breaking U-Boot.
Applied to u-boot-imx, thanks.
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] [PATCH 1/3] wandboard: Remove duplicate 'mmc dev'
On 02/04/2013 04:03, Fabio Estevam wrote: > From: Fabio Estevam > > No need to call 'mmc dev' twice. > > Signed-off-by: Fabio Estevam > --- Applied to u-boot-imx, thanks. Best regards, Stefano -- = 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 2/3] mx6qsabrelite: Remove duplicate 'mmc dev'
On 02/04/2013 04:03, Fabio Estevam wrote: > From: Fabio Estevam > > No need to call 'mmc dev' twice. > > Signed-off-by: Fabio Estevam > --- Applied to u-boot-imx, thanks. Best regards, Stefano -- = 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 1/1] i.MX6: mx6qsabrelite: README: don't pass chip-select to sf probe command
On Wed, Apr 3, 2013 at 11:25 AM, Stefano Babic wrote:
> On 25/03/2013 17:13, Javier Martinez Canillas wrote:
>> since commit "c1173bd0: sf command: allow default bus and chip selects"
>> the chip-select and bus arguments for the sf probe command are optional.
>>
>
> Hi Javier,
>
Hi Stefano, thanks a lot for your feedback.
>> Even when passing the chip-select to sf probe says to be optional, it
>> makes "sf erase" and "sf write" to fail on a mx6qsabrelite board. e.g:
>>
>> MX6QSABRELITE U-Boot > sf probe 1
>> MX6QSABRELITE U-Boot > sf erase 0 0x4
>> SPI flash erase failed
>> MX6QSABRELITE U-Boot > sf write 0x1080 0 0x4
>> SPI flash write failed
>
> Well, the real reason is that the passed chipselect is wrong. Checking
> in the configuration file, I see that the value to be passed should be
> 0x7300. I suppose (I am not testing) that "sf probe 0x7300" make sf
> erase and sw write working.
>
Just for curiosity, in which configuration file did you see that? When
I had the issue I looked at
include/configs/{mx6qsabrelite,mx6_common}.h and
board/freescale/mx6qsabrelite/mx6qsabrelite.c but I didn't find what
chip-select was supposed to be used.
>>
>> But just using "sf probe" works well. So, update the mx6qsabrelite
>> README so the commands will work on current U-Boot.
>
> I agree with the patch, but the description is wrong. Can you rewrite it
> simply stating that the chipselect "1" is wrong and that it is not
> strictly required (but again, is not forbidden) to pass it to sf probe ?
>
I'll send a v2 of the patch with this description:
i.MX6: mx6qsabrelite: README: don't pass chip-select to sf probe command
board/freescale/mx6qsabrelite/README explain a procedure to
update the SPI-NOR on the SabreLite board without Freescale
manufacturing tool but following this procedure leads to both
"sf erase" and "sf write" failing on a mx6qsabrelite board:
MX6QSABRELITE U-Boot > sf probe 1
MX6QSABRELITE U-Boot > sf erase 0 0x4
SPI flash erase failed
MX6QSABRELITE U-Boot > sf write 0x1080 0 0x4
SPI flash write failed
This is because the chip-select 1 is wrong and according the
correct value is 0x7300.
Since commit c1173bd0 ("sf command: allow default bus and chip selects"),
the chip-select and bus arguments for the sf probe command are optional
so let's just remove it and use "sf probe" instead.
> Best regards,
> Stefano Babic
>
> --
Thanks a lot and best regards,
Javier
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] wandboard: Remove CONFIG_SYS_FSL_USDHC_NUM
On 02/04/2013 04:03, Fabio Estevam wrote: > From: Fabio Estevam > > CONFIG_SYS_FSL_USDHC_NUM is not used for wandboard. > > Signed-off-by: Fabio Estevam > --- Applied to u-boot-imx, thanks. Best regards, Stefano -- = 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] mmc: mx6qsabrelite: fsl_esdhc: Define maximum bus width supported by SabreLite board
On 03/04/2013 11:18, Dirk Behme wrote: > On 03.04.2013 11:06, Stefano Babic wrote: >> On 21/03/2013 12:00, Abbas Raza wrote: >>> From: Abbas Raza >>> >>> Maximum bus width supported by SabreLite board is not 8bit like >>> all other mx6q specific boards. In case where both host controller >>> and card support 8bit transfers, they agree to communicate on 8bit >>> interface while boards like the SabreLite support only 4bit interface. >>> Due to this reason the mmc 8bit default mode fails on the SabreLite. >>> To rectify this, define maximum bus width supported by this board >>> (4bit). >>> If max_bus_width is not defined, it is 0 by default and 8bit width >>> support >>> will be enabled in host capabilities otherwise host capabilities are >>> modified >>> accordingly. >>> >>> It is tested with a MMCplus card. >>> >>> Signed-off-by: Abbas Raza >>> cc: stefano Babic >>> cc: Andy Fleming >>> Acked-by: Dirk Behme >>> Acked-by: Andrew Gabbasov >>> --- >> >> Applied to u-boot-imx, thanks. >> >> FYI: of course, I will merge the same fix for max_bus_width for >> Nitrogen6x and Wandboard if posted. > > Have you noticed v2 of this patch > > http://lists.denx.de/pipermail/u-boot/2013-March/150119.html Right, I noted after sending the e-mail ;-) Regards, Stefano -- = 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 v10 01/30] mtd: nand: Introduce CONFIG_SYS_NAND_BUSWIDTH_16BIT
Hi Benoît, On Wed, 3 Apr 2013 08:04:23 +0200, Benoît Thébaudeau wrote: > From: Fabio Estevam > > Introduce CONFIG_SYS_NAND_BUSWIDTH_16BIT option so that other NAND controller > drivers could use it when a 16-bit NAND is deployed. > > drivers/mtd/nand/ndfc has CONFIG_SYS_NDFC_16BIT, so just rename it, so that > other NAND drivers could reuse the same symbol. > > Signed-off-by: Fabio Estevam > Reviewed-by: Benoît Thébaudeau > Acked-by: Scott Wood > --- Whole series verified against my locally-rebased v9 and build-tested across ARM, no issue detected. Let a few days go by, say, start of next week so that week-end contributors have a chance to see the series and test it on their boards, and then it'll get in. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/1] i.MX6: mx6qsabrelite: README: don't pass chip-select to sf probe command
board/freescale/mx6qsabrelite/README explain a procedure to
update the SPI-NOR on the SabreLite board without Freescale
manufacturing tool but following this procedure leads to both
"sf erase" and "sf write" failing on a mx6qsabrelite board:
MX6QSABRELITE U-Boot > sf probe 1
MX6QSABRELITE U-Boot > sf erase 0 0x4
SPI flash erase failed
MX6QSABRELITE U-Boot > sf write 0x1080 0 0x4
SPI flash write failed
This is because the chip-select 1 is wrong and the correct
value is 0x7300.
Since commit c1173bd0 ("sf command: allow default bus and chip selects")
the chip-select and bus arguments for the sf probe command are optional
so let's just remove it and use "sf probe" instead.
Signed-off-by: Javier Martinez Canillas
---
Changes since v1:
- Fix the description by explaining that the chip-select can be passed
but the value "1" is wrong and is not strictly required; suggested by
Stefano Babic.
board/freescale/mx6qsabrelite/README |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/board/freescale/mx6qsabrelite/README
b/board/freescale/mx6qsabrelite/README
index 6f2f534..324b116 100644
--- a/board/freescale/mx6qsabrelite/README
+++ b/board/freescale/mx6qsabrelite/README
@@ -40,7 +40,7 @@ enter the following commands:
MX6Q SABRELITE U-Boot > mmc dev 0
MX6Q SABRELITE U-Boot > mmc read 0x1080 0 200
- MX6Q SABRELITE U-Boot > sf probe 1
+ MX6Q SABRELITE U-Boot > sf probe
MX6Q SABRELITE U-Boot > sf erase 0 0x4
MX6Q SABRELITE U-Boot > sf write 0x1080 0 0x4
--
1.7.7.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] i.MX6: mx6qsabrelite: README: don't pass chip-select to sf probe command
On 03/04/2013 11:50, Javier Martinez Canillas wrote:
> Just for curiosity, in which configuration file did you see that? When
> I had the issue I looked at
> include/configs/{mx6qsabrelite,mx6_common}.h and
> board/freescale/mx6qsabrelite/mx6qsabrelite.c but I didn't find what
> chip-select was supposed to be used.
include/configs/mx6qsabrelite.h:
#define CONFIG_SF_DEFAULT_CS (0|(IMX_GPIO_NR(3, 19)<<8))
It should be 0x7300
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] [PATCH v2 1/1] i.MX6: mx6qsabrelite: README: don't pass chip-select to sf probe command
On 03/04/2013 11:57, Javier Martinez Canillas wrote:
> board/freescale/mx6qsabrelite/README explain a procedure to
> update the SPI-NOR on the SabreLite board without Freescale
> manufacturing tool but following this procedure leads to both
> "sf erase" and "sf write" failing on a mx6qsabrelite board:
>
> MX6QSABRELITE U-Boot > sf probe 1
> MX6QSABRELITE U-Boot > sf erase 0 0x4
> SPI flash erase failed
> MX6QSABRELITE U-Boot > sf write 0x1080 0 0x4
> SPI flash write failed
>
> This is because the chip-select 1 is wrong and the correct
> value is 0x7300.
>
> Since commit c1173bd0 ("sf command: allow default bus and chip selects")
> the chip-select and bus arguments for the sf probe command are optional
> so let's just remove it and use "sf probe" instead.
>
> Signed-off-by: Javier Martinez Canillas
> ---
Applied to u-boot-imx, thanks.
Best regards,
Stefano
--
=
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] u-boot boot process is broken, how do i recover?
hi, Am 03.04.2013 11:00, schrieb Albert ARIBAUD: > >> apt-get install uboot-envtools >> fw_printenv bootcmd > > No result there? There should be. sure. it's what I set into bootcmd.bak: >> fw_setenv bootcmd.bak 'nand read.e 0x120 0x20 0x60;nand >> read.e 0x200 0x80 0x100;bootm 0x120 0x200' the outputs all looked fine, after I changed the offset in config file to 0x0. Else I wouln't have written anything. But still I am not 100% sure about the sector size of 0x2 (128KByte) > Yes: get control through JTAG. Ok. I'll try. > Don't consider unsoldering / resoldering, all the more if sockets are > involved, as long as you board has JTAG, either as a header or at least > as contact points. A dumb JTAG probe and OpenOCD will cost you little > and go a long way. I've got the following soldering points: - a 1x3 Pin@2,54mm connector labeld J7 which could be a FAN connector. - a 2x5=10 PIN@2mm connector J1 near the ROM chip. both connectors are on this picture: http://natisbad.org/NAS/pics/NETGEAR_ReadyNAS_Duo_v2_RND2000-200EUS_J1_and_J7_provisions.jpg - 1x4 PIN @ 2,54mm connector. So which one? Do I have to guess the pins? which probe should I chose? Something like these? - Embedded Projects OpenOCD-USB Adapter - Xilinx JTAG Parallel Cable III FPGA CPLD programmer LPT - SainSmart USB Blaster Programmer Cable For FPGA CPLD JTAG Development Board - found a LPT programmer having nothing more than a 74HC244 chip. Id' prefer the USB adapter... btw, I found out there is a boot menu. When I hold the reset button during bootup, there is a boot menu offering: Normal. Factory default. I believe it loads the initrd to reformat the harddrives. OS Re-install. Installs the root fs to hard drive from JFFS rom. Skip volume check. Memory test. Performs a memory test. Disk test. Maybe Smart test. I tried most. They all freeze after printing "net: egiga..." except memory test. Won't help much, I believe, since most rely on the boot process which is broken. JPT ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3 V5] EXYNOS5: Add GPIO numbering feature
Changes in V2: - Enabled CMD_GPIO as suggested by Simon Glass and supported same for EXYNOS5 Changes in V3: - New patch added to rename S5P GPIO definitions to S5P_GPIO - GPIO Table added to calculate the base address of input gpio bank. Changes in V4: - To have consistent 0..n-1 GPIO numbering the banks are divided into different parts where ever they have holes in them. - Function and table to support gpio command moved to s5p-gpio driver - Rebased on latest u-boot-samsung tree Changes in V5: - Rebased on latest u-boot-samsung tree - Removed Exynos5 specific code in gpio driver api to get bank. - Added #define HAVE_GENERIC_GPIO in config file to remove conditinal CPU check in gpio driver. Rajeshwari Shinde (3): EXYNOS5: Add gpio pin numbering feature S5P: Rename GPIO definitions EXYNOS5: GPIO: Enable GPIO Command for EXYNOS5 arch/arm/cpu/armv7/exynos/pinmux.c | 206 ++--- arch/arm/include/asm/arch-exynos/cpu.h | 10 +- arch/arm/include/asm/arch-exynos/gpio.h | 486 ++ arch/arm/include/asm/arch-s5pc1xx/gpio.h | 26 +- board/samsung/goni/goni.c|4 +- board/samsung/origen/origen.c|8 +- board/samsung/smdk5250/smdk5250.c| 24 +- board/samsung/smdkc100/smdkc100.c|2 +- board/samsung/smdkv310/smdkv310.c| 10 +- board/samsung/trats/trats.c | 17 +- board/samsung/universal_c210/universal.c | 36 ++-- drivers/gpio/s5p_gpio.c | 111 ++- include/configs/exynos5250-dt.h |2 + 13 files changed, 683 insertions(+), 259 deletions(-) -- 1.7.4.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3 V5] S5P: Rename GPIO definitions
This patch rename GPIO definitions from GPIO_... to S5P_GPIO_...
This changes was done to enable cmd_gpio for EXYNOS and
cmd_gpio has GPIO_INPUT same as s5p_gpio driver and hence
getting a error during compilation.
Build tested for s5p_goni, origen, smdk5250, s5pc210_universal,
trats, smdkc100, smdkv310 config files.
Signed-off-by: Rajeshwari Shinde
---
Changes in V2:
- New patch
Changes in V3:
- Created a table to know the base address of input bank.
Changes in V4:
- Moved the function name_to_gpio to s5p gpio driver and
renamed to s5p_name_to_gpio.
Changes in V5:
- Rebased on latest u-boot-samsung tree
arch/arm/cpu/armv7/exynos/pinmux.c | 134 +++---
arch/arm/include/asm/arch-exynos/gpio.h | 26 +++---
arch/arm/include/asm/arch-s5pc1xx/gpio.h | 26 +++---
board/samsung/goni/goni.c|4 +-
board/samsung/origen/origen.c|8 +-
board/samsung/smdk5250/smdk5250.c|8 +-
board/samsung/smdkc100/smdkc100.c|2 +-
board/samsung/smdkv310/smdkv310.c| 10 +-
board/samsung/trats/trats.c | 17 ++--
board/samsung/universal_c210/universal.c | 36
drivers/gpio/s5p_gpio.c | 20 ++--
11 files changed, 146 insertions(+), 145 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/pinmux.c
b/arch/arm/cpu/armv7/exynos/pinmux.c
index 2fb5963..d70980b 100644
--- a/arch/arm/cpu/armv7/exynos/pinmux.c
+++ b/arch/arm/cpu/armv7/exynos/pinmux.c
@@ -50,8 +50,8 @@ static void exynos5_uart_config(int peripheral)
break;
}
for (i = start; i < start + count; i++) {
- gpio_set_pull(i, GPIO_PULL_NONE);
- gpio_cfg_pin(i, GPIO_FUNC(0x2));
+ gpio_set_pull(i, S5P_GPIO_PULL_NONE);
+ gpio_cfg_pin(i, S5P_GPIO_FUNC(0x2));
}
}
@@ -63,7 +63,7 @@ static int exynos5_mmc_config(int peripheral, int flags)
case PERIPH_ID_SDMMC0:
start = EXYNOS5_GPIO_C00;
start_ext = EXYNOS5_GPIO_C10;
- gpio_func = GPIO_FUNC(0x2);
+ gpio_func = S5P_GPIO_FUNC(0x2);
break;
case PERIPH_ID_SDMMC1:
start = EXYNOS5_GPIO_C20;
@@ -72,7 +72,7 @@ static int exynos5_mmc_config(int peripheral, int flags)
case PERIPH_ID_SDMMC2:
start = EXYNOS5_GPIO_C30;
start_ext = EXYNOS5_GPIO_C43;
- gpio_func = GPIO_FUNC(0x3);
+ gpio_func = S5P_GPIO_FUNC(0x3);
break;
case PERIPH_ID_SDMMC3:
start = EXYNOS5_GPIO_C40;
@@ -87,19 +87,19 @@ static int exynos5_mmc_config(int peripheral, int flags)
if (flags & PINMUX_FLAG_8BIT_MODE) {
for (i = start_ext; i <= (start_ext + 3); i++) {
gpio_cfg_pin(i, gpio_func);
- gpio_set_pull(i, GPIO_PULL_UP);
- gpio_set_drv(i, GPIO_DRV_4X);
+ gpio_set_pull(i, S5P_GPIO_PULL_UP);
+ gpio_set_drv(i, S5P_GPIO_DRV_4X);
}
}
for (i = 0; i < 2; i++) {
- gpio_cfg_pin(start + i, GPIO_FUNC(0x2));
- gpio_set_pull(start + i, GPIO_PULL_NONE);
- gpio_set_drv(start + i, GPIO_DRV_4X);
+ gpio_cfg_pin(start + i, S5P_GPIO_FUNC(0x2));
+ gpio_set_pull(start + i, S5P_GPIO_PULL_NONE);
+ gpio_set_drv(start + i, S5P_GPIO_DRV_4X);
}
for (i = 3; i <= 6; i++) {
- gpio_cfg_pin(start + i, GPIO_FUNC(0x2));
- gpio_set_pull(start + i, GPIO_PULL_UP);
- gpio_set_drv(start + i, GPIO_DRV_4X);
+ gpio_cfg_pin(start + i, S5P_GPIO_FUNC(0x2));
+ gpio_set_pull(start + i, S5P_GPIO_PULL_UP);
+ gpio_set_drv(start + i, S5P_GPIO_DRV_4X);
}
return 0;
@@ -125,12 +125,12 @@ static void exynos5_sromc_config(int flags)
* GPY1[3] EBI_DATA_RDn(2)
*/
gpio_cfg_pin(EXYNOS5_GPIO_Y00 + (flags & PINMUX_FLAG_BANK),
-GPIO_FUNC(2));
- gpio_cfg_pin(EXYNOS5_GPIO_Y04, GPIO_FUNC(2));
- gpio_cfg_pin(EXYNOS5_GPIO_Y05, GPIO_FUNC(2));
+S5P_GPIO_FUNC(2));
+ gpio_cfg_pin(EXYNOS5_GPIO_Y04, S5P_GPIO_FUNC(2));
+ gpio_cfg_pin(EXYNOS5_GPIO_Y05, S5P_GPIO_FUNC(2));
for (i = 0; i < 4; i++)
- gpio_cfg_pin(EXYNOS5_GPIO_Y10 + i, GPIO_FUNC(2));
+ gpio_cfg_pin(EXYNOS5_GPIO_Y10 + i, S5P_GPIO_FUNC(2));
/*
* EBI: 8 Addrss Lines
@@ -165,14 +165,14 @@ static void exynos5_sromc_config(int flags)
* GPY6[7] EBI_DATA[15](2)
*/
for (i = 0; i < 8; i++) {
- gpio_cfg_pin(EXYNOS5_GPIO_Y30 + i, GPIO_FUNC(2));
- gpio_set_pull(EXYNOS5_GPIO_Y30 + i, GPIO_PULL_UP);
+ gpio_cfg_pin(EXYNOS5_GPIO_Y30 + i, S
[U-Boot] [PATCH 1/3 V5] EXYNOS5: Add gpio pin numbering feature
This patch adds support for gpio pin numbering support on
EXYNOS5250
To have consistent 0..n-1 GPIO numbering the banks are divided
into different parts where ever they have holes in them.
Signed-off-by: Leela Krishna Amudala
Signed-off-by: Rajeshwari Shinde
---
Changes in V2:
- none.
Changes in V3:
- none.
Changes in V4:
- To have consistent 0..n-1 GPIO numbering the banks are divided
into different parts where ever they have holes in them.
- Combined previous patch 1 and 2 into single patch.
Changes in V5:
- Removed Exynos5 specific code in gpio driver api to
get bank.
- Added #define HAVE_GENERIC_GPIO in config file
to remove conditinal CPU check in gpio driver.
arch/arm/cpu/armv7/exynos/pinmux.c | 150 --
arch/arm/include/asm/arch-exynos/cpu.h | 10 +-
arch/arm/include/asm/arch-exynos/gpio.h | 452 +++
board/samsung/smdk5250/smdk5250.c | 24 +-
drivers/gpio/s5p_gpio.c | 42 +++
include/configs/exynos5250-dt.h |1 +
6 files changed, 522 insertions(+), 157 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/pinmux.c
b/arch/arm/cpu/armv7/exynos/pinmux.c
index bd499b4..2fb5963 100644
--- a/arch/arm/cpu/armv7/exynos/pinmux.c
+++ b/arch/arm/cpu/armv7/exynos/pinmux.c
@@ -29,89 +29,77 @@
static void exynos5_uart_config(int peripheral)
{
- struct exynos5_gpio_part1 *gpio1 =
- (struct exynos5_gpio_part1 *) samsung_get_base_gpio_part1();
- struct s5p_gpio_bank *bank;
int i, start, count;
switch (peripheral) {
case PERIPH_ID_UART0:
- bank = &gpio1->a0;
- start = 0;
+ start = EXYNOS5_GPIO_A00;
count = 4;
break;
case PERIPH_ID_UART1:
- bank = &gpio1->d0;
- start = 0;
+ start = EXYNOS5_GPIO_D00;
count = 4;
break;
case PERIPH_ID_UART2:
- bank = &gpio1->a1;
- start = 0;
+ start = EXYNOS5_GPIO_A10;
count = 4;
break;
case PERIPH_ID_UART3:
- bank = &gpio1->a1;
- start = 4;
+ start = EXYNOS5_GPIO_A14;
count = 2;
break;
}
for (i = start; i < start + count; i++) {
- s5p_gpio_set_pull(bank, i, GPIO_PULL_NONE);
- s5p_gpio_cfg_pin(bank, i, GPIO_FUNC(0x2));
+ gpio_set_pull(i, GPIO_PULL_NONE);
+ gpio_cfg_pin(i, GPIO_FUNC(0x2));
}
}
static int exynos5_mmc_config(int peripheral, int flags)
{
- struct exynos5_gpio_part1 *gpio1 =
- (struct exynos5_gpio_part1 *) samsung_get_base_gpio_part1();
- struct s5p_gpio_bank *bank, *bank_ext;
- int i, start = 0, gpio_func = 0;
+ int i, start, start_ext, gpio_func = 0;
switch (peripheral) {
case PERIPH_ID_SDMMC0:
- bank = &gpio1->c0;
- bank_ext = &gpio1->c1;
- start = 0;
+ start = EXYNOS5_GPIO_C00;
+ start_ext = EXYNOS5_GPIO_C10;
gpio_func = GPIO_FUNC(0x2);
break;
case PERIPH_ID_SDMMC1:
- bank = &gpio1->c2;
- bank_ext = NULL;
+ start = EXYNOS5_GPIO_C20;
+ start_ext = 0;
break;
case PERIPH_ID_SDMMC2:
- bank = &gpio1->c3;
- bank_ext = &gpio1->c4;
- start = 3;
+ start = EXYNOS5_GPIO_C30;
+ start_ext = EXYNOS5_GPIO_C43;
gpio_func = GPIO_FUNC(0x3);
break;
case PERIPH_ID_SDMMC3:
- bank = &gpio1->c4;
- bank_ext = NULL;
+ start = EXYNOS5_GPIO_C40;
+ start_ext = 0;
break;
}
- if ((flags & PINMUX_FLAG_8BIT_MODE) && !bank_ext) {
+ if ((flags & PINMUX_FLAG_8BIT_MODE) && !start_ext) {
debug("SDMMC device %d does not support 8bit mode",
peripheral);
return -1;
}
if (flags & PINMUX_FLAG_8BIT_MODE) {
- for (i = start; i <= (start + 3); i++) {
- s5p_gpio_cfg_pin(bank_ext, i, gpio_func);
- s5p_gpio_set_pull(bank_ext, i, GPIO_PULL_UP);
- s5p_gpio_set_drv(bank_ext, i, GPIO_DRV_4X);
+ for (i = start_ext; i <= (start_ext + 3); i++) {
+ gpio_cfg_pin(i, gpio_func);
+ gpio_set_pull(i, GPIO_PULL_UP);
+ gpio_set_drv(i, GPIO_DRV_4X);
}
}
for (i = 0; i < 2; i++) {
- s5p_gpio_cfg_pin(bank, i, GPIO_FUNC(0x2));
- s5p_gpio_set_pull(bank, i, GPIO_PULL_NONE);
- s5p_gpio_s
[U-Boot] [PATCH 3/3 V5] EXYNOS5: GPIO: Enable GPIO Command for EXYNOS5
This patch enables GPIO Command for EXYNOS5.
Function has been added to asm/gpio.h to decode the
input gpio name to gpio number.
example: gpio set gpa00
Signed-off-by: Rajeshwari Shinde
---
Changes in V2:
- New patch
Changes in V3:
- Created a table to know the base address of input bank.
Changes in V4:
- Moved the function name_to_gpio to s5p gpio driver and
renamed to s5p_name_to_gpio.
Changes in V5:
- Rebased on latest u-boot-samsung tree
arch/arm/include/asm/arch-exynos/gpio.h |8 +
drivers/gpio/s5p_gpio.c | 49 +++
include/configs/exynos5250-dt.h |1 +
3 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/arch-exynos/gpio.h
b/arch/arm/include/asm/arch-exynos/gpio.h
index d8000af..9b31dc2 100644
--- a/arch/arm/include/asm/arch-exynos/gpio.h
+++ b/arch/arm/include/asm/arch-exynos/gpio.h
@@ -660,6 +660,14 @@ static inline unsigned int get_bank_num(void)
return 0;
}
+struct gpio_name_num_table {
+ char bank;
+ unsigned int base;
+};
+
+int s5p_name_to_gpio(const char *name);
+#define name_to_gpio(n) s5p_name_to_gpio(n)
+
void gpio_cfg_pin(int gpio, int cfg);
void gpio_set_pull(int gpio, int mode);
void gpio_set_drv(int gpio, int mode);
diff --git a/drivers/gpio/s5p_gpio.c b/drivers/gpio/s5p_gpio.c
index d6650c3..824977b 100644
--- a/drivers/gpio/s5p_gpio.c
+++ b/drivers/gpio/s5p_gpio.c
@@ -36,6 +36,21 @@
#define RATE_MASK(x) (0x1 << (x + 16))
#define RATE_SET(x)(0x1 << (x + 16))
+struct gpio_name_num_table exynos5_gpio_table[] = {
+ { 'a', EXYNOS5_GPIO_A00 },
+ { 'b', EXYNOS5_GPIO_B00 },
+ { 'c', EXYNOS5_GPIO_C00 },
+ { 'd', EXYNOS5_GPIO_D00 },
+ { 'y', EXYNOS5_GPIO_Y00 },
+ { 'x', EXYNOS5_GPIO_X00 },
+ { 'e', EXYNOS5_GPIO_E00 },
+ { 'f', EXYNOS5_GPIO_F00 },
+ { 'g', EXYNOS5_GPIO_G00 },
+ { 'h', EXYNOS5_GPIO_H00 },
+ { 'v', EXYNOS5_GPIO_V00 },
+ { 'z', EXYNOS5_GPIO_Z0 },
+};
+
void s5p_gpio_cfg_pin(struct s5p_gpio_bank *bank, int gpio, int cfg)
{
unsigned int value;
@@ -238,3 +253,37 @@ void gpio_cfg_pin(int gpio, int cfg)
s5p_gpio_cfg_pin(s5p_gpio_get_bank(gpio),
s5p_gpio_get_pin(gpio), cfg);
}
+
+int s5p_name_to_gpio(const char *name)
+{
+ unsigned int num, i;
+
+ name++;
+
+ if (*name == 'p')
+ ++name;
+
+ for (i = 0; i < ARRAY_SIZE(exynos5_gpio_table); i++) {
+ if (*name == exynos5_gpio_table[i].bank) {
+ if (*name == 'c') {
+ name++;
+ num = simple_strtoul(name, NULL, 10);
+ if (num >= 40) {
+ num = EXYNOS5_GPIO_C40 + (num - 40);
+ } else {
+ num = simple_strtoul(name, NULL, 8);
+ num = exynos5_gpio_table[i].base + num;
+ }
+ } else {
+ name++;
+ num = simple_strtoul(name, NULL, 8);
+ num = exynos5_gpio_table[i].base + num;
+ }
+ break;
+ }
+ }
+
+ if (i == ARRAY_SIZE(exynos5_gpio_table))
+ return -1;
+ return num;
+}
diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h
index cbd1c4e..46a4e75 100644
--- a/include/configs/exynos5250-dt.h
+++ b/include/configs/exynos5250-dt.h
@@ -122,6 +122,7 @@
#define CONFIG_CMD_FAT
#define CONFIG_CMD_NET
#define CONFIG_CMD_HASH
+#define CONFIG_CMD_GPIO
#define CONFIG_BOOTDELAY 3
#define CONFIG_ZERO_BOOTDELAY_CHECK
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot boot process is broken, how do i recover?
Hi JPT, On Wed, 03 Apr 2013 13:30:46 +0200, JPT wrote: > hi, > > > Am 03.04.2013 11:00, schrieb Albert ARIBAUD: > > > >> apt-get install uboot-envtools > >> fw_printenv bootcmd > > > > No result there? There should be. > > sure. > it's what I set into bootcmd.bak: > > >> fw_setenv bootcmd.bak 'nand read.e 0x120 0x20 0x60;nand > >> read.e 0x200 0x80 0x100;bootm 0x120 0x200' Ok. > the outputs all looked fine, after I changed the offset in config file > to 0x0. Else I wouln't have written anything. But still I am not 100% > sure about the sector size of 0x2 (128KByte) Well, the exact value can only be known with the source code for the U-Boot your board is running. Speaking of which... Did you look / ask Netgear for the source code? They should provide it to you as per GPL. > > Yes: get control through JTAG. > > Ok. I'll try. > > > Don't consider unsoldering / resoldering, all the more if sockets are > > involved, as long as you board has JTAG, either as a header or at least > > as contact points. A dumb JTAG probe and OpenOCD will cost you little > > and go a long way. > > I've got the following soldering points: > > - a 1x3 Pin@2,54mm connector labeld J7 which could be a FAN connector. > > - a 2x5=10 PIN@2mm connector J1 near the ROM chip. > > both connectors are on this picture: > http://natisbad.org/NAS/pics/NETGEAR_ReadyNAS_Duo_v2_RND2000-200EUS_J1_and_J7_provisions.jpg > > - 1x4 PIN @ 2,54mm connector. > > So which one? > Do I have to guess the pins? Well, without information from Netgear, it's going to be hard to find out which is which. Considering the number of signals in a JTAG I/F, J7 and the 1x4 pin connector can be ruled out. However, it does not mean J1 is JTAG, and anyway, you'll have trouble finding the right pinout. > which probe should I chose? Something like these? > - Embedded Projects OpenOCD-USB Adapter > - Xilinx JTAG Parallel Cable III FPGA CPLD programmer LPT > - SainSmart USB Blaster Programmer Cable For FPGA CPLD JTAG Development > Board > - found a LPT programmer having nothing more than a 74HC244 chip. > > Id' prefer the USB adapter... I cannot advise on the compared merits of those. The ones I know are the BusPirate or BusBlaster (very versatile boards, no casing) and the Olimex ARM-USB-OCD[-H] (less generic than the BusPirate/Blaster but has a casing and comes with a serial port. In any case, choose a probe for which your JTAG software will work. > btw, I found out there is a boot menu. > When I hold the reset button during bootup, there is a boot menu offering: > [...] > Won't help much, I believe, since most rely on the boot process which is > broken. I think so too. For now, your best chance for recovery will be JTAG. BTW, this becomes unrelated to U-Boot per se (at most, it's a non-mainline U-Boot, which should not be discussed here). I suggest moving the discussion outside of this list unless you have generic questions left regarding U-boot. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] EXYNOS: Move includes from setup.h to tzpc_init.c
These should not be in the header since not every C file needs them. Move them to the file that needs them. Signed-off-by: Simon Glass Signed-off-by: Rajeshwari Shinde --- board/samsung/smdk5250/setup.h |3 --- board/samsung/smdk5250/tzpc_init.c |2 ++ 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/board/samsung/smdk5250/setup.h b/board/samsung/smdk5250/setup.h index 34d8bc3..68f48ea 100644 --- a/board/samsung/smdk5250/setup.h +++ b/board/samsung/smdk5250/setup.h @@ -25,9 +25,6 @@ #ifndef _SMDK5250_SETUP_H #define _SMDK5250_SETUP_H -#include -#include - /* TZPC : Register Offsets */ #define TZPC0_BASE 0x1010 #define TZPC1_BASE 0x1011 diff --git a/board/samsung/smdk5250/tzpc_init.c b/board/samsung/smdk5250/tzpc_init.c index c833541..96e5a6c 100644 --- a/board/samsung/smdk5250/tzpc_init.c +++ b/board/samsung/smdk5250/tzpc_init.c @@ -22,6 +22,8 @@ * MA 02111-1307 USA */ +#include +#include #include #include"setup.h" -- 1.7.4.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] Add initial support for AQUILA-CYGNUS
From: Enric Balletbo i Serra IGEP COM AQUILA and CYGNUS are two computer-on-module based on AM3354 and AM3352 processors. Both use SODIMM from factor and are designed for industrial range purpose. Enric Balletbo i Serra (2): Add DDR3 support for IGEP COM AQUILA/CYGNUS. ARM: Add support for IGEP COM AQUILA/CYGNUS MAINTAINERS |1 + arch/arm/include/asm/arch-am33xx/ddr_defs.h | 17 ++ board/isee/igep0033/Makefile| 46 board/isee/igep0033/board.c | 232 + board/isee/igep0033/board.h | 27 +++ board/isee/igep0033/mux.c | 89 boards.cfg |1 + include/configs/igep0033.h | 300 +++ 8 files changed, 713 insertions(+) create mode 100644 board/isee/igep0033/Makefile create mode 100644 board/isee/igep0033/board.c create mode 100644 board/isee/igep0033/board.h create mode 100644 board/isee/igep0033/mux.c create mode 100644 include/configs/igep0033.h -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] Add DDR3 support for IGEP COM AQUILA/CYGNUS.
From: Enric Balletbo i Serra These boards uses Samsung K4B2G1646E-BIH9 a 2Gb E-die DDR3 SDRAM. Signed-off-by: Enric Balletbo i Serra --- arch/arm/include/asm/arch-am33xx/ddr_defs.h | 17 + 1 file changed, 17 insertions(+) diff --git a/arch/arm/include/asm/arch-am33xx/ddr_defs.h b/arch/arm/include/asm/arch-am33xx/ddr_defs.h index 260cc34..4ebc557 100644 --- a/arch/arm/include/asm/arch-am33xx/ddr_defs.h +++ b/arch/arm/include/asm/arch-am33xx/ddr_defs.h @@ -117,6 +117,23 @@ #define MT41J512M8RH125_PHY_WR_DATA0x74 #define MT41J512M8RH125_IOCTRL_VALUE 0x18B +/* Samsung K4B2G1646E-BIH9 */ +#define K4B2G1646EBIH9_EMIF_READ_LATENCY 0x06 +#define K4B2G1646EBIH9_EMIF_TIM1 0x0888A39B +#define K4B2G1646EBIH9_EMIF_TIM2 0x2A04011A +#define K4B2G1646EBIH9_EMIF_TIM3 0x501F820F +#define K4B2G1646EBIH9_EMIF_SDCFG 0x61C24AB2 +#define K4B2G1646EBIH9_EMIF_SDREF 0x093B +#define K4B2G1646EBIH9_ZQ_CFG 0x50074BE4 +#define K4B2G1646EBIH9_DLL_LOCK_DIFF 0x1 +#define K4B2G1646EBIH9_RATIO 0x40 +#define K4B2G1646EBIH9_INVERT_CLKOUT 0x1 +#define K4B2G1646EBIH9_RD_DQS 0x3B +#define K4B2G1646EBIH9_WR_DQS 0x85 +#define K4B2G1646EBIH9_PHY_FIFO_WE 0x100 +#define K4B2G1646EBIH9_PHY_WR_DATA 0xC1 +#define K4B2G1646EBIH9_IOCTRL_VALUE0x18B + /** * Configure DMM */ -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] ARM: Add support for IGEP COM AQUILA/CYGNUS
From: Enric Balletbo i Serra
The IGEP COM AQUILA and CYGNUS are industrial processors modules with
following highlights:
o AM3352/AM3354 Texas Instruments processor
o Cortex-A8 ARM CPU
o 3.3 volts Inputs / Outputs use industrial
o 256 MB DDR3 SDRAM / 128 Megabytes FLASH
o MicroSD card reader on-board
o Ethernet controller on-board
o JTAG debug connector available
o Designed for industrial range purposes
Signed-off-by: Enric Balletbo i Serra
---
MAINTAINERS |1 +
board/isee/igep0033/Makefile | 46 +++
board/isee/igep0033/board.c | 232
board/isee/igep0033/board.h | 27
board/isee/igep0033/mux.c| 89 +
boards.cfg |1 +
include/configs/igep0033.h | 300 ++
7 files changed, 696 insertions(+)
create mode 100644 board/isee/igep0033/Makefile
create mode 100644 board/isee/igep0033/board.c
create mode 100644 board/isee/igep0033/board.h
create mode 100644 board/isee/igep0033/mux.c
create mode 100644 include/configs/igep0033.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 1614b91..6cfcf83 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -607,6 +607,7 @@ Enric Balletbo i Serra
igep0020ARM ARMV7 (OMAP3xx SoC)
igep0030ARM ARMV7 (OMAP3xx SoC)
igep0032ARM ARMV7 (OMAP3xx SoC)
+ igep0033ARM ARMV7 (AM33xx Soc)
Eric Benard
diff --git a/board/isee/igep0033/Makefile b/board/isee/igep0033/Makefile
new file mode 100644
index 000..54a4b75
--- /dev/null
+++ b/board/isee/igep0033/Makefile
@@ -0,0 +1,46 @@
+#
+# Makefile
+#
+# Copyright (C) 2013, ISEE 2007 SL - http://www.isee.biz/
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed "as is" WITHOUT ANY WARRANTY of any
+# kind, whether express or implied; without even the implied warranty
+# of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+ifdef CONFIG_SPL_BUILD
+COBJS := mux.o
+endif
+
+COBJS += board.o
+SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+SOBJS := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+ $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+clean:
+ rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+ rm -f $(LIB) core *.bak $(obj).depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/isee/igep0033/board.c b/board/isee/igep0033/board.c
new file mode 100644
index 000..d315516
--- /dev/null
+++ b/board/isee/igep0033/board.c
@@ -0,0 +1,232 @@
+/*
+ * Board functions for IGEP COM AQUILA/CYGNUS based boards
+ *
+ * Copyright (C) 2013, ISEE 2007 SL - http://www.isee.biz/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR /PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "board.h"
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static struct wd_timer *wdtimer = (struct wd_timer *)WDT_BASE;
+#ifdef CONFIG_SPL_BUILD
+static struct uart_sys *uart_base = (struct uart_sys *)DEFAULT_UART_BASE;
+#endif
+
+/* MII mode defines */
+#define RMII_MODE_ENABLE 0x4D
+
+static struct ctrl_dev *cdev = (struct ctrl_dev *)CTRL_DEVICE_BASE;
+
+/* UART Defines */
+#ifdef CONFIG_SPL_BUILD
+#define UART_RESET (0x1 << 1)
+#define UART_CLK_RUNNING_MASK 0x1
+#define UART_SMART_IDLE_EN (0x1 << 0x3)
+
+static void rtc32k_enable(void)
+{
+ struct rtc_regs *rtc = (struct rtc_regs *)RTC_BASE;
+
+ /*
+* Unlock the RTC's registers. For more details please see the
+* RTC_SS section of the TRM. In order to unlock we need to
+* write these specific values (keys) in this order.
+*/
+ writel(0x83e70b13, &rtc->kick0r);
+ writel(0x95a4f1e0, &rtc->kick1r);
+
+ /* Enable the RTC 32K OSC by setting bits 3 and 6. */
+ writel((1 << 3) | (1
Re: [U-Boot] [PATCH] mx6: fsl_esdhc: Fix waiting for DMA operation completion
Hi Andrew, On 04/02/2013 11:48 PM, Gabbasov, Andrew wrote: On 04/02/2013 03:04 AM, Andrew Gabbasov wrote: On iMX6 sometimes the Transfer Complete interrupt occurs earlier than the DMA part completes its operation. If immediately after that the read data is used for some data verification, those obtained data may be incomplete, which causes intermittent verification failures. Can you describe how to repeat this? For example, when the default environment command tries to load and run boot script from FAT partition on SD/MMC card, it sometimes fails, reporting invalid partition table, or unknown partition type, or something else of that kind. Such errors disappear if the build configuration has CONFIG_SYS_FSL_ESDHC_USE_PIO, or if some delay is added after transfer completion. >>> Looking at the code with fresh eyes, it appears that the cache invalidate is in the wrong place (after "command complete" but before "transfer complete" is checked). Andrew, can you test with this patch to see if it also addresses the issue? Hi Eric, Yes, this patch seems to fix the issue too. Thanks for testing. I think, it would be useful to have both patches. Although invalidating cache (by adding some delay) indirectly helps with waiting for DMA End event, it is probably worth having explicit DMA completion waiting patch too. I agree wholeheartedly. I do wonder if the previous loop should be re-worked though. It seems that we should be waiting for TC & (DINT|DMAE) on all processor variants and the previous loop has tests for timeout and data errors. Regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP (4) boot_params
On Apr 3, 2013, at 1:56 AM, Albert ARIBAUD wrote:
> (please wrap your line around 70 chars max)
I've never understood why this is useful. It's poor on both large
computer screens (wastes space and forces extra vertical scrolling)
AND on small screens like handheld devices (because the arbitrary width is
limit still too wide).
Your MUA seems to have handled the quoted-printable content transfer
encoding I sent (since your quoted text had no tell tail = characters
at the end of each line). Why can't it wrap the text to whatever width
*you* want? Mine does (provided the message ISN'T hard-wrapped) and I
don't much like senders forcing the rendering on my devices to be done
in ways that are counter to my preferences.
Wouldn't it be better for readers to do what's best for each device?
Imagine someone on a tablet viewing email first in portrait mode and then
rotating to landscape. Why advocate forcing one or the other to have a
demonstrably poor user experience?
The MUA controls many other elements of the presentation. HTLM aside,
does the sender control what font face, size or color all recipients
must use to view the message? Of course not, and for good reason. I fail
to see why line width should be some magical special case.
So with all due respect, I can with greater legitimately turn your
admonition around and ask that you please update or configure your MUA
to handle your display preferences on your side.
> On Tue, 2 Apr 2013 18:39:17 -0400, Michael Cashwell
> wrote:
>
>> I've been fighting with SPL passing not boot_params properly to u-boot
>> on OMAP4. There are many layers to this onion but I've tracked the bulk
>> of the problem down to the following issues.
>>
>> ...Making that:
>>
>> u32 *boot_params_ptr __attribute__ ((section(".data")));
>>
>> allows the pointer to be in SPL data section (SRAM) and still have its
>> value by the time image_entry() is called. But common/spl/spl.c is not
>> omap-specific so changes there are a concern.
>
> If I'm not mistaken, lowlevel_init() is not supposed to use BSS at all,
> as the C runtime has not been initialized yet -- precisely, the BSS
> clearing loop long after the cpu_init_crit() call belongs to the code
> that sets up this environment.
Yes, that was my thinking too. Surely clearing data after code has set
it can't be right.
> Besides, it seems like SPL does not jump directly to Linux but to
> U-Boot, so U-Boot itself should set up the boot params, not SPL, which
> can at best prepare and store values in static RAM not mapped as data
> or BSS in either SPL or U-Boot (this is normally done through GD).
OK, here we have an unfortunate name overloading. The boot_params here
is specifically an OMAP handoff from the CPU's internal boot ROM to SPL
and then from SPL to u-boot. (The same code paths are involved.) It's
totally unrelated to the the boot_params passed to the Linux kernel.
Since it's confusing maybe a renaming is called for as well.
Best regards,
-Mike
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V8 0/9] EXYNOS5: Enable DWMMC, add FDT support for DWMMC and
This patch set enables and initialises DWMMC for Exynos5250 on SMDK5250. Adds driver changes required for DWMMC. Adds FDT support for DWMMC. Adds EMMC boot support for SMDK5250. This patch set is based on: "EXYNOS: mmc: support DesignWare Controller for Samsung-SoC", which is merged in u-boot-mmc. "Exynos: clock: support get_mmc_clk for exynos". "Add DT based ethernet driver for SMDK5250". "SMDK5250: Add FDT support" present at the following link http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/149991 Changes since V1: 1)Corrected in response to review comments. 2)Created separate board files for FDT and non-FDT versions. 3)Added binding file for DWMMC device node. 4)Removed the propname 'index' from device node. 5)Prefixed the vendor name 'samsung' before propname in device node. 6)Ensured to have same signature for the function exynos_dwmci_init() for both FDT and non-FDT versions. 7)EMMC clock setting has been moved from spl_boot.c to clock_init.c. Changes since V2: 1)Updation of commit message and resubmition of proper patch set. Changes since V3: 1)Updated to use the macro DWMCI_CTRL_SEND_AS_CCSD instead of the hard coded value (1 << 10). 2)In the file exynos_dw_mmc.c, replaced the new function exynos5_mmc_set_clk_div() with the existing function set_mmc_clk(). set_mmc_clk() will do the purpose. 3)In the file exynos_dw_mmc.c, computation of FSYS block clock divisor (pre-ratio) value is added. 4)Removed the new function exynos5_mmc_set_clk_div() from clock.c. Changes since V4: 1)Updated the function dwmci_send_cmd() to use get_timer() instead of using mdelay(1). 2)Replaced the function call 'exynos_dwmmc_init(0, 8);' with the function exynos_dwmmc_add_port() in smdk5250.c. 3)The function get_irom_func(int index) has been added to avoid type casting at many places. 4)Used the generic function "mmc_boot_part_access()" instead of two functions "mmc_boot_open()" and "mmc_boot_close()". By doing so user can specify which boot partition to be accessed (opened / closed). Changes since V5: 1)Added the 'removable' flag to mmc device node. 2)Changed the mmc clock value from 50MHz to 52MHz in the function exynos_dwmci_add_port() present in file drivers/mmc/exynos_dw_mmc.c. 3)Enabled CONFIG_LCD only for non-FDT operation. 4)Removed the function call i2c_init() present inside the function board_i2c_init(). Changes since V6: 1)Re-based to the patch "SMDK5250: Add PMIC voltage settings". Changes since V7: 1)Re-based to the patch "Exynos: pwm: Remove dead code of function exynos5_get_pwm_clk". 2)In file dw_mmc.c, updated the function dwmci_setup_bus() to return 0 if (freq == 0).This is to avoid the run time exception "raise:Signal # 8 caught". 3)In the files drivers/mmc/mmc.c and common/cmd_mmc.c, the piece of code involved in EMMC open/close and resize of EMMC boot partition has been made conditional and is enabled only if the macro CONFIG_SUPPORT_EMMC_BOOT is defined. 4)The macros FSYS1_MMC0_DIV_MASK and FSYS1_MMC0_DIV_VAL are made local to file clock_init.c. Amar (9): FDT: Add compatible string for DWMMC EXYNOS5: FDT: Add DWMMC device node data DWMMC: Initialise dwmci and resolve EMMC read write issues EXYNOS5: DWMMC: Added FDT support for DWMMC EXYNOS5: DWMMC: Initialise the local variable to avoid unwanted results. SMDK5250: Initialise and Enable DWMMC, support FDT and non-FDT MMC: APIs to support resize of EMMC boot partition SMDK5250: Enable EMMC booting COMMON: MMC: Command to support EMMC booting and to resize EMMC boot partition arch/arm/cpu/armv7/exynos/clock.c | 4 +- arch/arm/dts/exynos5250.dtsi | 33 +++ arch/arm/include/asm/arch-exynos/dwmmc.h | 11 +- board/samsung/dts/exynos5250-smdk5250.dts | 24 ++ board/samsung/smdk5250/Makefile | 4 + board/samsung/smdk5250/clock_init.c | 18 ++ board/samsung/smdk5250/clock_init.h | 5 + board/samsung/smdk5250/exynos5-dt.c | 423 ++ board/samsung/smdk5250/smdk5250.c | 223 board/samsung/smdk5250/spl_boot.c | 52 +++- common/cmd_mmc.c | 110 +++- doc/device-tree-bindings/exynos/dwmmc.txt | 54 drivers/mmc/dw_mmc.c | 28 +- drivers/mmc/exynos_dw_mmc.c | 127 - drivers/mmc/mmc.c | 134 ++ drivers/video/exynos_fb.c | 4 +- include/configs/exynos5250-dt.h | 8 + include/dwmmc.h | 3 + include/fdtdec.h | 1 + include/mmc.h | 26 ++
[U-Boot] [PATCH V8 1/9] FDT: Add compatible string for DWMMC
Add required compatible information for DWMMC driver.
Signed-off-by: Vivek Gautam
Signed-off-by: Amar
Acked-by: Jaehoon Chung
---
Changes since V1:
No change.
Changes since V2:
1)Updation of commit message and resubmition of proper patch set.
Changes since V3:
No change.
Changes since V4:
No change.
Changes since V5:
No change.
Changes since V6:
No change.
Changes since V7:
No change.
include/fdtdec.h | 1 +
lib/fdtdec.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index a83b160..5ab3d59 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -89,6 +89,7 @@ enum fdt_compat_id {
COMPAT_SAMSUNG_EXYNOS5_DP, /* Exynos Display port controller */
COMPAT_MAXIM_MAX77686_PMIC, /* MAX77686 PMIC */
COMPAT_MAXIM_98095_CODEC, /* MAX98095 Codec */
+ COMPAT_SAMSUNG_EXYNOS5_DWMMC, /* Exynos5 DWMMC controller */
COMPAT_COUNT,
};
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 0f34bdc..c187133 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -64,6 +64,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
COMPAT(SAMSUNG_EXYNOS5_DP, "samsung,exynos5-dp"),
COMPAT(MAXIM_MAX77686_PMIC, "maxim,max77686_pmic"),
COMPAT(MAXIM_98095_CODEC, "maxim,max98095-codec"),
+ COMPAT(SAMSUNG_EXYNOS5_DWMMC, "samsung,exynos5250-dwmmc"),
};
const char *fdtdec_get_compatible(enum fdt_compat_id id)
--
1.8.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/5] ARM: vexpress: add support for more core tiles
This series adds support for the Cortex-A5 and Cortex-A15 core tiles for the ARM Versatile Express boards. The first three patches have been around for about one and a half years in the Linaro tree now, they refactor the A9 support and add support for A5. I kept the original commits and authors, just resolved some trivial merge conflicts and checkpatch complaints. Patch 4/5 adds support for the A15 core tile, this is actually the same as the A5 for now, but will be extended later. Patch 5/5 enables bootz and hush parser for all boards, just for convenience. Regards, Andre. -- Andre Przywara Linaro Virtualization Team ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V8 2/9] EXYNOS5: FDT: Add DWMMC device node data
This patch adds DWMMC device node data for exynos5.
This patch also adds binding file for DWMMC device node.
Signed-off-by: Vivek Gautam
Signed-off-by: Amar
Acked-by: Jaehoon Chung
Acked-by: Simon Glass
---
Changes since V1:
1)Added binding file for DWMMC device node at the location
"doc/device-tree-bindings/exynos/dwmmc.txt".
2)Removed the propname 'index' from device node.
3)Prefixed the vendor name 'samsung' before propname in device node.
Changes since V2:
1)Updation of commit message and resubmition of proper patch set.
Changes since V3:
No change.
Changes since V4:
1)Updated the doc/device-tree-bindings/exynos/dwmmc.txt with more
information regarding the property 'samsung,timing'.
2)Replaced the name 'dwmmc' with 'mmc'.
Changes since V5:
1)Added the 'removable' flag to mmc device node.
Changes since V6:
No change.
Changes since V7:
No change.
arch/arm/dts/exynos5250.dtsi | 33 +++
board/samsung/dts/exynos5250-smdk5250.dts | 24 ++
doc/device-tree-bindings/exynos/dwmmc.txt | 54 +++
3 files changed, 111 insertions(+)
create mode 100644 doc/device-tree-bindings/exynos/dwmmc.txt
diff --git a/arch/arm/dts/exynos5250.dtsi b/arch/arm/dts/exynos5250.dtsi
index df4b231..cee4fe8 100644
--- a/arch/arm/dts/exynos5250.dtsi
+++ b/arch/arm/dts/exynos5250.dtsi
@@ -169,4 +169,37 @@
#address-cells = <1>;
#size-cells = <1>;
};
+
+ mmc@1220 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "samsung,exynos5250-dwmmc";
+ reg = <0x1220 0x1000>;
+ interrupts = <0 75 0>;
+ };
+
+ mmc@1221 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "samsung,exynos5250-dwmmc";
+ reg = <0x1221 0x1000>;
+ interrupts = <0 76 0>;
+ };
+
+ mmc@1222 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "samsung,exynos5250-dwmmc";
+ reg = <0x1222 0x1000>;
+ interrupts = <0 77 0>;
+ };
+
+ mmc@1223 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "samsung,exynos5250-dwmmc";
+ reg = <0x1223 0x1000>;
+ interrupts = <0 78 0>;
+ };
+
};
diff --git a/board/samsung/dts/exynos5250-smdk5250.dts
b/board/samsung/dts/exynos5250-smdk5250.dts
index 8da973b..93375a6 100644
--- a/board/samsung/dts/exynos5250-smdk5250.dts
+++ b/board/samsung/dts/exynos5250-smdk5250.dts
@@ -30,6 +30,10 @@
spi2 = "/spi@12d4";
spi3 = "/spi@131a";
spi4 = "/spi@131b";
+ mmc0 = "/mmc@1220";
+ mmc1 = "/mmc@1221";
+ mmc2 = "/mmc@1222";
+ mmc3 = "/mmc@1223";
};
sromc@1225 {
@@ -119,4 +123,24 @@
samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
};
+
+ mmc@1220 {
+ samsung,bus-width = <8>;
+ samsung,timing = <1 3 3>;
+ samsung,removable = <0>;
+ };
+
+ mmc@1221 {
+ status = "disabled";
+ };
+
+ mmc@1222 {
+ samsung,bus-width = <4>;
+ samsung,timing = <1 2 3>;
+ samsung,removable = <1>;
+ };
+
+ mmc@1223 {
+ status = "disabled";
+ };
};
diff --git a/doc/device-tree-bindings/exynos/dwmmc.txt
b/doc/device-tree-bindings/exynos/dwmmc.txt
new file mode 100644
index 000..566da3b
--- /dev/null
+++ b/doc/device-tree-bindings/exynos/dwmmc.txt
@@ -0,0 +1,54 @@
+* Exynos 5250 DWC_mobile_storage
+
+The Exynos 5250 provides DWC_mobile_storage interface which supports
+. Embedded Multimedia Cards (EMMC-version 4.5)
+. Secure Digital memory (SD mem-version 2.0)
+. Secure Digital I/O (SDIO-version 3.0)
+. Consumer Electronics Advanced Transport Architecture (CE-ATA-version 1.1)
+
+The Exynos 5250 DWC_mobile_storage provides four channels.
+SOC specific and Board specific properties are channel specific.
+
+Required SoC Specific Properties:
+
+- compatible: should be
+ - samsung,exynos5250-dwmmc: for exynos5250 platforms
+
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+- interrupts: The interrupt number to the cpu.
+
+Required Board Specific Properties:
+
+- #address-cells: should be 1.
+- #size-cells: should be 0.
+- samsung,bus-width: The width of the bus used to interface the devices
+ supported by DWC_mobile_storage (SD-MMC/EMMC/SDIO).
+ . Typically the bus width is 4 or 8.
+- samsung,timing: The timing values to be written into the
+ Drv/sa
[U-Boot] [PATCH 2/5] ARM: vexpress: create A9 specific board config
From: Ryan Harkin This patch creates a new config for the A9 quad core tile that includes the generic config for the Versatile Express platform. Signed-off-by: Ryan Harkin Signed-off-by: Andre Przywara --- MAINTAINERS | 2 +- boards.cfg| 2 +- include/configs/vexpress_ca9x4.h | 34 ++ include/configs/vexpress_common.h | 1 - 4 files changed, 36 insertions(+), 3 deletions(-) create mode 100644 include/configs/vexpress_ca9x4.h diff --git a/MAINTAINERS b/MAINTAINERS index b4d9a35..761c36c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -960,7 +960,7 @@ Hugo Villeneuve Matt Waddel - vexpress_common ARM ARMV7 (Quad Core) + vexpress_ca9x4 ARM ARMV7 (Quad Core) Otavio Salvador diff --git a/boards.cfg b/boards.cfg index 3c971d4..908e3bc 100644 --- a/boards.cfg +++ b/boards.cfg @@ -232,7 +232,7 @@ versatilepb arm arm926ejs versatile armltd versatileqemuarm arm926ejs versatile armltd versatile versatile:ARCH_VERSATILE_QEMU,ARCH_VERSATILE_PB integratorap_cm946es arm arm946esintegrator armltd - integratorap:CM946ES integratorcp_cm946es arm arm946esintegrator armltd - integratorcp:CM946ES -vexpress_common arm armv7 vexpressarmltd +vexpress_ca9x4 arm armv7 vexpressarmltd am335x_evm arm armv7 am335x ti am33xx am335x_evm:SERIAL1,CONS_INDEX=1 am335x_evm_spiboot arm armv7 am335x ti am33xx am335x_evm:SERIAL1,CONS_INDEX=1,SPI_BOOT am335x_evm_uart1 arm armv7 am335x ti am33xx am335x_evm:SERIAL2,CONS_INDEX=2 diff --git a/include/configs/vexpress_ca9x4.h b/include/configs/vexpress_ca9x4.h new file mode 100644 index 000..c3b6986 --- /dev/null +++ b/include/configs/vexpress_ca9x4.h @@ -0,0 +1,34 @@ +/* + * (C) Copyright 2011 Linaro + * Ryan Harkin, + * + * Configuration for Versatile Express. Parts were derived from other ARM + * configurations. + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#ifndef __VEXPRESS_CA9X4_H +#define __VEXPRESS_CA9X4_H + +#define CONFIG_VEXPRESS_ORIGINAL_MEMORY_MAP +#include "vexpress_common.h" +#define CONFIG_BOOTP_VCI_STRING "U-boot.armv7.vexpress_ca9x4" + +#endif /* VEXPRESS_CA9X4_H */ diff --git a/include/configs/vexpress_common.h b/include/configs/vexpress_common.h index a7cd1d4..9a3431e 100644 --- a/include/configs/vexpress_common.h +++ b/include/configs/vexpress_common.h @@ -97,7 +97,6 @@ #define CONFIG_BOOTP_HOSTNAME #define CONFIG_BOOTP_PXE #define CONFIG_BOOTP_PXE_CLIENTARCH0x100 -#define CONFIG_BOOTP_VCI_STRING"U-boot.armv7.ca9x4_ct_vxp" /* Miscellaneous configurable options */ #undef CONFIG_SYS_CLKS_IN_HZ -- 1.7.12.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/5] ARM: vexpress: move files in preparation for adding a new platform
From: Ryan Harkin
The current ca9x4_ct_vxp platform contains support for a Versatile Express
motherboard with a quad core A9 core tile.
This patch is the first stage of making separating the Versatile Express
motherboard code and the A9 specific code, before adding support for the
dual core A5 core tile.
Signed-off-by: Ryan Harkin
Signed-off-by: Andre Przywara
---
MAINTAINERS | 2 +-
board/armltd/vexpress/Makefile | 2 +-
board/armltd/vexpress/ca9x4_ct_vxp.c| 257
board/armltd/vexpress/vexpress_common.c | 257
boards.cfg | 2 +-
include/configs/ca9x4_ct_vxp.h | 198
include/configs/vexpress_common.h | 198
7 files changed, 458 insertions(+), 458 deletions(-)
delete mode 100644 board/armltd/vexpress/ca9x4_ct_vxp.c
create mode 100644 board/armltd/vexpress/vexpress_common.c
delete mode 100644 include/configs/ca9x4_ct_vxp.h
create mode 100644 include/configs/vexpress_common.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 1614b91..b4d9a35 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -960,7 +960,7 @@ Hugo Villeneuve
Matt Waddel
- ca9x4_ct_vxpARM ARMV7 (Quad Core)
+ vexpress_common ARM ARMV7 (Quad Core)
Otavio Salvador
diff --git a/board/armltd/vexpress/Makefile b/board/armltd/vexpress/Makefile
index 8749590..6719f3d 100644
--- a/board/armltd/vexpress/Makefile
+++ b/board/armltd/vexpress/Makefile
@@ -25,7 +25,7 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(BOARD).o
-COBJS := ca9x4_ct_vxp.o
+COBJS := vexpress_common.o
SRCS := $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS))
diff --git a/board/armltd/vexpress/ca9x4_ct_vxp.c
b/board/armltd/vexpress/ca9x4_ct_vxp.c
deleted file mode 100644
index d5e109e..000
--- a/board/armltd/vexpress/ca9x4_ct_vxp.c
+++ /dev/null
@@ -1,257 +0,0 @@
-/*
- * (C) Copyright 2002
- * Sysgo Real-Time Solutions, GmbH
- * Marius Groeger
- *
- * (C) Copyright 2002
- * David Mueller, ELSOFT AG,
- *
- * (C) Copyright 2003
- * Texas Instruments,
- * Kshitij Gupta
- *
- * (C) Copyright 2004
- * ARM Ltd.
- * Philippe Robin,
- *
- * See file CREDITS for list of people who contributed to this
- * project.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- */
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include "../drivers/mmc/arm_pl180_mmci.h"
-
-static ulong timestamp;
-static ulong lastdec;
-
-static struct wdt *wdt_base = (struct wdt *)WDT_BASE;
-static struct systimer *systimer_base = (struct systimer *)SYSTIMER_BASE;
-static struct sysctrl *sysctrl_base = (struct sysctrl *)SCTL_BASE;
-
-static void flash__init(void);
-static void vexpress_timer_init(void);
-DECLARE_GLOBAL_DATA_PTR;
-
-#if defined(CONFIG_SHOW_BOOT_PROGRESS)
-void show_boot_progress(int progress)
-{
- printf("Boot reached stage %d\n", progress);
-}
-#endif
-
-static inline void delay(ulong loops)
-{
- __asm__ volatile ("1:\n"
- "subs %0, %1, #1\n"
- "bne 1b" : "=r" (loops) : "0" (loops));
-}
-
-int board_init(void)
-{
- gd->bd->bi_boot_params = LINUX_BOOT_PARAM_ADDR;
- gd->bd->bi_arch_number = MACH_TYPE_VEXPRESS;
- gd->flags = 0;
-
- icache_enable();
- flash__init();
- vexpress_timer_init();
-
- return 0;
-}
-
-int board_eth_init(bd_t *bis)
-{
- int rc = 0;
-#ifdef CONFIG_SMC911X
- rc = smc911x_initialize(0, CONFIG_SMC911X_BASE);
-#endif
- return rc;
-}
-
-int cpu_mmc_init(bd_t *bis)
-{
- int rc = 0;
- (void) bis;
-#ifdef CONFIG_ARM_PL180_MMCI
- struct pl180_mmc_host *host;
-
- host = malloc(sizeof(struct pl180_mmc_host));
- if (!host)
- return -ENOMEM;
- memset(host, 0, sizeof(*host));
-
- strcpy(host->name, "MMC");
- host->base = (struct sdi_registers *)CONFIG_ARM_PL180_MMCI_BASE;
- host->pwr_init = INIT_PWR;
- host->clkdiv_init = SDI_CLKCR_CLKDIV_INIT_V1 | SDI_CLKCR_CLKEN;
- host->voltages = VOLTAGE_WINDOW_MMC;
- host->caps = 0;
- host->clock_in = ARM_MCLK;
- host->clock_min = ARM_MCLK / (2 * (SDI_CLKCR_CLKDIV_INIT_V1 + 1));
- host->cloc
[U-Boot] [PATCH 4/5] ARM: vexpress: add support for Versatile Express Cortex-A15-TC2
This adds support for the Cortex-A15-TC2 core tile for the Versatile Express board by ARM. This is mostly a copy of the A5 support file, but will be extended later with A15 specific options. Signed-off-by: Andre Przywara --- boards.cfg | 1 + include/configs/vexpress_ca15_tc2.h | 36 2 files changed, 37 insertions(+) create mode 100644 include/configs/vexpress_ca15_tc2.h diff --git a/boards.cfg b/boards.cfg index df8d5e5..e6a86a8 100644 --- a/boards.cfg +++ b/boards.cfg @@ -232,6 +232,7 @@ versatilepb arm arm926ejs versatile armltd versatileqemuarm arm926ejs versatile armltd versatile versatile:ARCH_VERSATILE_QEMU,ARCH_VERSATILE_PB integratorap_cm946es arm arm946esintegrator armltd - integratorap:CM946ES integratorcp_cm946es arm arm946esintegrator armltd - integratorcp:CM946ES +vexpress_ca15_tc2arm armv7 vexpressarmltd vexpress_ca5x2 arm armv7 vexpressarmltd vexpress_ca9x4 arm armv7 vexpressarmltd am335x_evm arm armv7 am335x ti am33xx am335x_evm:SERIAL1,CONS_INDEX=1 diff --git a/include/configs/vexpress_ca15_tc2.h b/include/configs/vexpress_ca15_tc2.h new file mode 100644 index 000..9e230ad --- /dev/null +++ b/include/configs/vexpress_ca15_tc2.h @@ -0,0 +1,36 @@ +/* + * (C) Copyright 2013 Linaro + * Andre Przywara, + * + * Configuration for Versatile Express. Parts were derived from other ARM + * configurations. + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#ifndef __VEXPRESS_CA15X2_TC2_h +#define __VEXPRESS_CA15X2_TC2_h + +#define CONFIG_VEXPRESS_EXTENDED_MEMORY_MAP +#include "vexpress_common.h" +#define CONFIG_BOOTP_VCI_STRING "U-boot.armv7.vexpress_ca15x2_tc2" + +#define CONFIG_SYS_CLK_FREQ 2400 + +#endif -- 1.7.12.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V8 3/9] DWMMC: Initialise dwmci and resolve EMMC read write issues
This patch enumerates dwmci and set auto stop command during
dwmci initialisation.
EMMC read/write is not happening in current implementation
due to improper fifo size computation. Hence modified the fifo size
computation to resolve EMMC read write issues.
Signed-off-by: Amar
---
Changes since V1:
1)Created the macros RX_WMARK_SHIFT and RX_WMARK_MASK in header file.
Changes since V2:
1)Updation of commit message and resubmition of proper patch set.
Changes since V3:
1)Updated to use the macro DWMCI_CTRL_SEND_AS_CCSD instead of
the hard coded value (1 << 10).
Changes since V4:
1)Updated the function dwmci_send_cmd() to use get_timer() instead
of using mdelay(1).
Changes since V5:
1)Updated in response to review comments.
Changes since V6:
No change.
Changes since V7:
1)Updated the function dwmci_setup_bus() to return 0 if (freq == 0).
This is to avoid the run time exception "raise:Signal # 8 caught".
drivers/mmc/dw_mmc.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 4070d4e..963a515 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -129,13 +129,13 @@ static int dwmci_send_cmd(struct mmc *mmc, struct mmc_cmd
*cmd,
unsigned int timeout = 10;
u32 retry = 1;
u32 mask, ctrl;
+ ulong start = get_timer(0);
while (dwmci_readl(host, DWMCI_STATUS) & DWMCI_BUSY) {
- if (timeout == 0) {
+ if (get_timer(start) > timeout) {
printf("Timeout on data busy\n");
return TIMEOUT;
}
- timeout--;
}
dwmci_writel(host, DWMCI_RINTSTS, DWMCI_INTMSK_ALL);
@@ -143,7 +143,6 @@ static int dwmci_send_cmd(struct mmc *mmc, struct mmc_cmd
*cmd,
if (data)
dwmci_prepare_data(host, data);
-
dwmci_writel(host, DWMCI_CMDARG, cmd->cmdarg);
if (data)
@@ -231,9 +230,8 @@ static int dwmci_setup_bus(struct dwmci_host *host, u32
freq)
int timeout = 1;
unsigned long sclk;
- if (freq == host->clock)
+ if ((freq == host->clock) || (freq == 0))
return 0;
-
/*
* If host->mmc_clk didn't define,
* then assume that host->bus_hz is source clock value.
@@ -314,7 +312,7 @@ static void dwmci_set_ios(struct mmc *mmc)
static int dwmci_init(struct mmc *mmc)
{
struct dwmci_host *host = (struct dwmci_host *)mmc->priv;
- u32 fifo_size, fifoth_val;
+ u32 fifo_size, fifoth_val, ier;
dwmci_writel(host, DWMCI_PWREN, 1);
@@ -323,6 +321,14 @@ static int dwmci_init(struct mmc *mmc)
return -1;
}
+ /* Enumerate at 400KHz */
+ dwmci_setup_bus(host, mmc->f_min);
+
+ /* Set auto stop command */
+ ier = dwmci_readl(host, DWMCI_CTRL);
+ ier |= DWMCI_CTRL_SEND_AS_CCSD;
+ dwmci_writel(host, DWMCI_CTRL, ier);
+
dwmci_writel(host, DWMCI_RINTSTS, 0x);
dwmci_writel(host, DWMCI_INTMASK, 0);
@@ -332,11 +338,13 @@ static int dwmci_init(struct mmc *mmc)
dwmci_writel(host, DWMCI_BMOD, 1);
fifo_size = dwmci_readl(host, DWMCI_FIFOTH);
- if (host->fifoth_val)
+ fifo_size = ((fifo_size & RX_WMARK_MASK) >> RX_WMARK_SHIFT) + 1;
+ if (host->fifoth_val) {
fifoth_val = host->fifoth_val;
- else
- fifoth_val = MSIZE(0x2) | RX_WMARK(fifo_size/2 -1) |
- TX_WMARK(fifo_size/2);
+ } else {
+ fifoth_val = MSIZE(0x2) | RX_WMARK(fifo_size / 2 - 1) |
+ TX_WMARK(fifo_size / 2);
+ }
dwmci_writel(host, DWMCI_FIFOTH, fifoth_val);
dwmci_writel(host, DWMCI_CLKENA, 0);
--
1.8.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V8 5/9] EXYNOS5: DWMMC: Initialise the local variable to avoid unwanted results.
This patch initialises the local variable 'shift' to zero. The uninitialised local variable 'shift' had garbage value and was resulting in unwnated results in the functions exynos5_get_mmc_clk() and exynos4_get_mmc_clk(). Signed-off-by: Amar Acked-by: Simon Glass --- Changes since V1: 1)Updated the function exynos5_mmc_set_clk_div() to receive 'device_i'd as input parameter instead of 'index'. Changes since V2: 1)Updation of commit message and resubmition of proper patch set. Changes since V3: 1)Removed the new API exynos5_mmc_set_clk_div() from clock.c, because existing API set_mmc_clk() can be used to set mmc clock. Changes since V4: 1)Updated the subject line to reflect the changes present in this patch. 2)Changes of the file arch/arm/include/asm/arch-exynos/clk.h which were present in this patch, have been moved out of this patch. Changes since V5: No change. Changes since V6: No change. Changes since V7: No change. arch/arm/cpu/armv7/exynos/clock.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/cpu/armv7/exynos/clock.c b/arch/arm/cpu/armv7/exynos/clock.c index 223660a..cf3247a 100644 --- a/arch/arm/cpu/armv7/exynos/clock.c +++ b/arch/arm/cpu/armv7/exynos/clock.c @@ -613,7 +613,7 @@ static unsigned long exynos4_get_mmc_clk(int dev_index) (struct exynos4_clock *)samsung_get_base_clock(); unsigned long uclk, sclk; unsigned int sel, ratio, pre_ratio; - int shift; + int shift = 0; sel = readl(&clk->src_fsys); sel = (sel >> (dev_index << 2)) & 0xf; @@ -662,7 +662,7 @@ static unsigned long exynos5_get_mmc_clk(int dev_index) (struct exynos5_clock *)samsung_get_base_clock(); unsigned long uclk, sclk; unsigned int sel, ratio, pre_ratio; - int shift; + int shift = 0; sel = readl(&clk->src_fsys); sel = (sel >> (dev_index << 2)) & 0xf; -- 1.8.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/5] ARM: vexpress: enable bootz and hush parser for all VExpress boards
Signed-off-by: Andre Przywara --- include/configs/vexpress_common.h | 4 1 file changed, 4 insertions(+) diff --git a/include/configs/vexpress_common.h b/include/configs/vexpress_common.h index cd268e3..65d0ce4 100644 --- a/include/configs/vexpress_common.h +++ b/include/configs/vexpress_common.h @@ -179,6 +179,7 @@ #define CONFIG_CMD_PING #define CONFIG_CMD_SAVEENV #define CONFIG_CMD_RUN +#define CONFIG_CMD_BOOTZ #define CONFIG_CMD_FAT #define CONFIG_DOS_PARTITION 1 @@ -302,6 +303,9 @@ #define CONFIG_SYS_PROMPT "VExpress# " #define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE + \ sizeof(CONFIG_SYS_PROMPT) + 16) +#define CONFIG_SYS_HUSH_PARSER +#define CONFIG_SYS_PROMPT_HUSH_PS2 "> " + #define CONFIG_SYS_BARGSIZECONFIG_SYS_CBSIZE /* Boot args buffer */ #define CONFIG_CMD_SOURCE #define CONFIG_SYS_LONGHELP -- 1.7.12.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V8 4/9] EXYNOS5: DWMMC: Added FDT support for DWMMC
This patch adds FDT support for DWMMC, by reading the DWMMC node data
from the device tree and initialising DWMMC channels as per data
obtained from the node.
Signed-off-by: Vivek Gautam
Signed-off-by: Amar
Acked-by: Simon Glass
---
Changes since V1:
1)Updated code to have same signature for the function
exynos_dwmci_init() for both FDT and non-FDT versions.
2)Updated code to pass device_id parameter to the function
exynos5_mmc_set_clk_div() instead of index.
3)Updated code to decode the value of "samsung,width" from FDT.
4)Channel index is computed instead of getting from FDT.
Changes since V2:
1)Updation of commit message and resubmition of proper patch set.
Changes since V3:
1)Replaced the new function exynos5_mmc_set_clk_div() with the
existing function set_mmc_clk(). set_mmc_clk() will do the purpose.
2)Computation of FSYS block clock divisor (pre-ratio) is added.
Changes since V4:
1)Replaced "unsigned int exynos_dwmmc_init(int index, int bus_width)"
with
int exynos_dwmci_add_port(int, u32, inth, u32)
i)exynos_dwmmc_add_port() will be used by non-FDT boards.
ii)In FDT case, exynos_dwmmc_init(const void *blob) will use
exynos_dwmmc_add_port() for every channel enabled in device
node.
2)Changed the computation method of mmc clock divisor.
3)Updated exynos_dwmmc_init() to compute the 'clksel_val' within the
function.
Changes since V5:
1)Updated in response to review comments and changed the mmc clock value
from 50MHz to 52MHz.
Changes since V6:
No change.
Changes since V7:
No change.
arch/arm/include/asm/arch-exynos/dwmmc.h | 11 +--
drivers/mmc/exynos_dw_mmc.c | 127 ---
include/dwmmc.h | 3 +
3 files changed, 124 insertions(+), 17 deletions(-)
diff --git a/arch/arm/include/asm/arch-exynos/dwmmc.h
b/arch/arm/include/asm/arch-exynos/dwmmc.h
index 8acdf9b..3b147b8 100644
--- a/arch/arm/include/asm/arch-exynos/dwmmc.h
+++ b/arch/arm/include/asm/arch-exynos/dwmmc.h
@@ -27,10 +27,7 @@
#define DWMCI_SET_DRV_CLK(x) ((x) << 16)
#define DWMCI_SET_DIV_RATIO(x) ((x) << 24)
-int exynos_dwmci_init(u32 regbase, int bus_width, int index);
-
-static inline unsigned int exynos_dwmmc_init(int index, int bus_width)
-{
- unsigned int base = samsung_get_base_mmc() + (0x1 * index);
- return exynos_dwmci_init(base, bus_width, index);
-}
+#ifdef CONFIG_OF_CONTROL
+int exynos_dwmmc_init(const void *blob);
+#endif
+int exynos_dwmci_add_port(int index, u32 regbase, int bus_width, u32 clksel);
diff --git a/drivers/mmc/exynos_dw_mmc.c b/drivers/mmc/exynos_dw_mmc.c
index 72a31b7..4238dd9 100644
--- a/drivers/mmc/exynos_dw_mmc.c
+++ b/drivers/mmc/exynos_dw_mmc.c
@@ -19,39 +19,146 @@
*/
#include
-#include
#include
+#include
+#include
+#include
#include
#include
+#include
-static char *EXYNOS_NAME = "EXYNOS DWMMC";
+#defineDWMMC_MAX_CH_NUM4
+#defineDWMMC_MAX_FREQ 5200
+#defineDWMMC_MIN_FREQ 40
+#defineDWMMC_MMC0_CLKSEL_VAL 0x03030001
+#defineDWMMC_MMC2_CLKSEL_VAL 0x03020001
+/*
+ * Function used as callback function to initialise the
+ * CLKSEL register for every mmc channel.
+ */
static void exynos_dwmci_clksel(struct dwmci_host *host)
{
- u32 val;
- val = DWMCI_SET_SAMPLE_CLK(DWMCI_SHIFT_0) |
- DWMCI_SET_DRV_CLK(DWMCI_SHIFT_0) | DWMCI_SET_DIV_RATIO(0);
+ dwmci_writel(host, DWMCI_CLKSEL, host->clksel_val);
+}
- dwmci_writel(host, DWMCI_CLKSEL, val);
+unsigned int exynos_dwmci_get_clk(int dev_index)
+{
+ return get_mmc_clk(dev_index);
}
-int exynos_dwmci_init(u32 regbase, int bus_width, int index)
+/*
+ * This function adds the mmc channel to be registered with mmc core.
+ * index - mmc channel number.
+ * regbase - register base address of mmc channel specified in 'index'.
+ * bus_width - operating bus width of mmc channel specified in 'index'.
+ * clksel -value to be written into CLKSEL register in case of FDT.
+ * NULL in case od non-FDT.
+ */
+int exynos_dwmci_add_port(int index, u32 regbase, int bus_width, u32 clksel)
{
struct dwmci_host *host = NULL;
+ unsigned int div;
+ unsigned long freq, sclk;
host = malloc(sizeof(struct dwmci_host));
if (!host) {
printf("dwmci_host malloc fail!\n");
return 1;
}
+ /* request mmc clock vlaue of 52MHz. */
+ freq = 5200;
+ sclk = get_mmc_clk(index);
+ div = DIV_ROUND_UP(sclk, freq);
+ /* set the clock divisor for mmc */
+ set_mmc_clk(index, div);
- host->name = EXYNOS_NAME;
+ host->name = "EXYNOS DWMMC";
host->ioaddr = (void *)regbase;
host->buswid
[U-Boot] [PATCH 3/5] ARM: vexpress: create A5 specific board config
From: Ryan Harkin
This patch creates a new config for the A5 dual core tile that includes the
generic config for the Versatile Express platform.
The generic config has been modified to provide support for the Extended
Memory Map, as used on the A5 core tile. A5 does not support the legacy
memory map.
Signed-off-by: Ryan Harkin
Signed-off-by: Andre Przywara
---
MAINTAINERS | 1 +
board/armltd/vexpress/vexpress_common.c | 29 --
boards.cfg | 1 +
include/configs/vexpress_ca5x2.h| 34 +++
include/configs/vexpress_common.h | 152
5 files changed, 192 insertions(+), 25 deletions(-)
create mode 100644 include/configs/vexpress_ca5x2.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 761c36c..dccee97 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -961,6 +961,7 @@ Hugo Villeneuve
Matt Waddel
vexpress_ca9x4 ARM ARMV7 (Quad Core)
+ vexpress_ca5x2 ARM ARMV7 (Dual Core)
Otavio Salvador
diff --git a/board/armltd/vexpress/vexpress_common.c
b/board/armltd/vexpress/vexpress_common.c
index c4f2520..2c54869 100644
--- a/board/armltd/vexpress/vexpress_common.c
+++ b/board/armltd/vexpress/vexpress_common.c
@@ -45,8 +45,7 @@
static ulong timestamp;
static ulong lastdec;
-static struct wdt *wdt_base = (struct wdt *)WDT_BASE;
-static struct systimer *systimer_base = (struct systimer *)SYSTIMER_BASE;
+static struct systimer *systimer_base = (struct systimer *)V2M_TIMER01;
static struct sysctrl *sysctrl_base = (struct sysctrl *)SCTL_BASE;
static void flash__init(void);
@@ -173,13 +172,31 @@ static void vexpress_timer_init(void)
reset_timer_masked();
}
+int v2m_cfg_write(u32 devfn, u32 data)
+{
+ /* Configuration interface broken? */
+ u32 val;
+
+ devfn |= SYS_CFG_START | SYS_CFG_WRITE;
+
+ val = readl(V2M_SYS_CFGSTAT);
+ writel(val & ~SYS_CFG_COMPLETE, V2M_SYS_CFGSTAT);
+
+ writel(data, V2M_SYS_CFGDATA);
+ writel(devfn, V2M_SYS_CFGCTRL);
+
+ do {
+ val = readl(V2M_SYS_CFGSTAT);
+ } while (val == 0);
+
+ return !!(val & SYS_CFG_ERR);
+}
+
/* Use the ARM Watchdog System to cause reset */
void reset_cpu(ulong addr)
{
- writeb(WDT_EN, &wdt_base->wdogcontrol);
- writel(WDT_RESET_LOAD, &wdt_base->wdogload);
- while (1)
- ;
+ if (v2m_cfg_write(SYS_CFG_REBOOT | SYS_CFG_SITE_MB, 0))
+ printf("Unable to reboot\n");
}
/*
diff --git a/boards.cfg b/boards.cfg
index 908e3bc..df8d5e5 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -232,6 +232,7 @@ versatilepb arm arm926ejs
versatile armltd
versatileqemuarm arm926ejs versatile
armltd versatile versatile:ARCH_VERSATILE_QEMU,ARCH_VERSATILE_PB
integratorap_cm946es arm arm946esintegrator
armltd - integratorap:CM946ES
integratorcp_cm946es arm arm946esintegrator
armltd - integratorcp:CM946ES
+vexpress_ca5x2 arm armv7 vexpressarmltd
vexpress_ca9x4 arm armv7 vexpressarmltd
am335x_evm arm armv7 am335x ti
am33xx am335x_evm:SERIAL1,CONS_INDEX=1
am335x_evm_spiboot arm armv7 am335x ti
am33xx am335x_evm:SERIAL1,CONS_INDEX=1,SPI_BOOT
diff --git a/include/configs/vexpress_ca5x2.h b/include/configs/vexpress_ca5x2.h
new file mode 100644
index 000..9331134
--- /dev/null
+++ b/include/configs/vexpress_ca5x2.h
@@ -0,0 +1,34 @@
+/*
+ * (C) Copyright 2011 Linaro
+ * Ryan Harkin,
+ *
+ * Configuration for Versatile Express. Parts were derived from other ARM
+ * configurations.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef __VEXPRESS_CA5X2_h
+#define __VEXPRESS_CA5X2_h
+
+#define CONFIG_VEXPRESS_EXTENDED_MEMORY_MAP
+#include "vexpress_common.h"
+#define CONFIG_BOOTP_VCI_STRING "U-boot.armv7.vexpress_ca5x2"
+
+#endif /* __VEXPRESS_CA5X2_h */
diff --git a/inc
[U-Boot] [PATCH V8 6/9] SMDK5250: Initialise and Enable DWMMC, support FDT and non-FDT
This patch enables and initialises DWMMC for SMDK5250.
Supports both FDT and non-FDT. This patch creates a new file
'exynos5-dt.c' meant for FDT support.
exynos5-dt.c: This file shall contain all code which supports FDT.
Any addition of FDT support for any module needs to be
added in this file.
smdk5250.c: This file shall contain the code which supports non-FDT.
version. Any addition of non-FDT support for any module
needs to be added in this file.
May be, the file smdk5250.c can be removed in near
future
when non-FDT is not required.
The Makefile is updated to compile only one of the files
exynos5-dt.c / smdk5250.c based on FDT configuration.
NOTE:
Please note that all additions corresponding to FDT need to be added into the
file exynos5-dt.c.
At same time if non-FDT support is required then add the corresponding
updations into smdk5250.c.
Signed-off-by: Amar
---
Changes since V1:
1)A new file 'exynos5-dt.c' is created meant for FDT support
2)Makefile is updated to compile only one of the files
exynos5-dt.c / smdk5250.c based on FDT configuration
Changes since V2:
1)Updation of commit message and resubmition of proper patch set.
Changes since V3:
No change.
Changes since V4:
1)Replaced the function call 'exynos_dwmmc_init(0, 8);' with the
function exynos_dwmmc_add_port() in smdk5250.c.
2)dram_init() is updated to use for loop to compute the ram size.
3)dram_init_banksize() is updated to use for loop to initialise
the dram bank size.
4)board_uart_init() is updated to use for loop to initialise UARTS.
5)In non-FDT case NULL is passed as parameter to board_i2c_init().
Changes since V5:
1)Enabled CONFIG_LCD only for non-FDT operation.
Changes since V6:
1)Re-based.
Changes since V7:
1)Re-based.
2)Because of creation of new file 'exynos5-dt.c' meant for FDT support,
the exynos_fb.c had to be updated to support non-FDT and FDT for LCD.
If exynos_fb.c is not updated as per this patch the compilation fails.
3)Added the macro CONFIG_SUPPORT_EMMC_BOOT in exynos5250-dt.h.
board/samsung/smdk5250/Makefile | 4 +
board/samsung/smdk5250/exynos5-dt.c | 423
board/samsung/smdk5250/smdk5250.c | 223 +--
drivers/video/exynos_fb.c | 4 +-
include/configs/exynos5250-dt.h | 8 +
5 files changed, 493 insertions(+), 169 deletions(-)
create mode 100644 board/samsung/smdk5250/exynos5-dt.c
diff --git a/board/samsung/smdk5250/Makefile b/board/samsung/smdk5250/Makefile
index 47c6a5a..ecca9f3 100644
--- a/board/samsung/smdk5250/Makefile
+++ b/board/samsung/smdk5250/Makefile
@@ -32,8 +32,12 @@ COBJS+= tzpc_init.o
COBJS += smdk5250_spl.o
ifndef CONFIG_SPL_BUILD
+ifdef CONFIG_OF_CONTROL
+COBJS += exynos5-dt.o
+else
COBJS += smdk5250.o
endif
+endif
ifdef CONFIG_SPL_BUILD
COBJS += spl_boot.o
diff --git a/board/samsung/smdk5250/exynos5-dt.c
b/board/samsung/smdk5250/exynos5-dt.c
new file mode 100644
index 000..78ef424
--- /dev/null
+++ b/board/samsung/smdk5250/exynos5-dt.c
@@ -0,0 +1,423 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#if defined CONFIG_EXYNOS_TMU
+/*
+ * Boot Time Thermal Analysis for SoC temperature threshold breach
+ */
+static void boot_temp_check(void)
+{
+ int temp;
+
+ switch (tmu_monitor(&temp)) {
+ /* Status TRIPPED ans WARNING means corresponding threshold breach */
+ case TMU_STATUS_TRIPPED:
+ puts("EXYNOS_TMU: TRIPPING! Device power going down ...\n");
+ set_ps_hold_ctrl();
+ hang();
+ break;
+ case TMU_STATUS_WARNING:
+ puts("EXYNOS_TMU: WARNING! Temperature ver
[U-Boot] [PATCH V8 7/9] MMC: APIs to support resize of EMMC boot partition
This patch adds APIs to access(open / close) and to resize boot partiton of
EMMC.
Signed-off-by: Amar
---
Changes since V1:
New patch.
Changes since V2:
1)Updation of commit message and resubmition of proper patch set.
Changes since V3:
No change.
Changes since V4:
1)Replaced the functions mmc_boot_open() & mmc_boot_close() with a
single function mmc_boot_part_access().
Changes since V5:
1)Updated in response to review comments.
Changes since V6:
1)Added spaces around << operator, in response to review comments.
Changes since V7:
1)In the file drivers/mmc/mmc.c, the piece of code involved in
open/close and resize of EMMC boot partition has been made conditional
and is enabled only if the macro CONFIG_SUPPORT_EMMC_BOOT is defined.
drivers/mmc/mmc.c | 134 ++
include/mmc.h | 26 +++
2 files changed, 160 insertions(+)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index d732581..a6a04e6 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -1352,3 +1352,137 @@ int mmc_initialize(bd_t *bis)
return 0;
}
+
+#ifdef CONFIG_SUPPORT_EMMC_BOOT
+/*
+ * This function changes the size of boot partition and the size of rpmb
+ * partition present on EMMC devices.
+ *
+ * Input Parameters:
+ * struct *mmc: pointer for the mmc device strcuture
+ * bootsize: size of boot partition
+ * rpmbsize: size of rpmb partition
+ *
+ * Returns 0 on success.
+ */
+
+int mmc_boot_partition_size_change(struct mmc *mmc, unsigned long bootsize,
+ unsigned long rpmbsize)
+{
+ int err;
+ struct mmc_cmd cmd;
+
+ /* Only use this command for raw EMMC moviNAND. Enter backdoor mode */
+ cmd.cmdidx = MMC_CMD_RES_MAN;
+ cmd.resp_type = MMC_RSP_R1b;
+ cmd.cmdarg = MMC_CMD62_ARG1;
+
+ err = mmc_send_cmd(mmc, &cmd, NULL);
+ if (err) {
+ debug("mmc_boot_partition_size_change: Error1 = %d\n", err);
+ return err;
+ }
+
+ /* Boot partition changing mode */
+ cmd.cmdidx = MMC_CMD_RES_MAN;
+ cmd.resp_type = MMC_RSP_R1b;
+ cmd.cmdarg = MMC_CMD62_ARG2;
+
+ err = mmc_send_cmd(mmc, &cmd, NULL);
+ if (err) {
+ debug("mmc_boot_partition_size_change: Error2 = %d\n", err);
+ return err;
+ }
+ /* boot partition size is multiple of 128KB */
+ bootsize = (bootsize * 1024) / 128;
+
+ /* Arg: boot partition size */
+ cmd.cmdidx = MMC_CMD_RES_MAN;
+ cmd.resp_type = MMC_RSP_R1b;
+ cmd.cmdarg = bootsize;
+
+ err = mmc_send_cmd(mmc, &cmd, NULL);
+ if (err) {
+ debug("mmc_boot_partition_size_change: Error3 = %d\n", err);
+ return err;
+ }
+ /* RPMB partition size is multiple of 128KB */
+ rpmbsize = (rpmbsize * 1024) / 128;
+ /* Arg: RPMB partition size */
+ cmd.cmdidx = MMC_CMD_RES_MAN;
+ cmd.resp_type = MMC_RSP_R1b;
+ cmd.cmdarg = rpmbsize;
+
+ err = mmc_send_cmd(mmc, &cmd, NULL);
+ if (err) {
+ debug("mmc_boot_partition_size_change: Error4 = %d\n", err);
+ return err;
+ }
+ return 0;
+}
+
+/*
+ * This function shall form and send the commands to open / close the
+ * boot partition specified by user.
+ *
+ * Input Parameters:
+ * ack: 0x0 - No boot acknowledge sent (default)
+ * 0x1 - Boot acknowledge sent during boot operation
+ * part_num: User selects boot data that will be sent to master
+ * 0x0 - Device not boot enabled (default)
+ * 0x1 - Boot partition 1 enabled for boot
+ * 0x2 - Boot partition 2 enabled for boot
+ * access: User selects partitions to access
+ * 0x0 : No access to boot partition (default)
+ * 0x1 : R/W boot partition 1
+ * 0x2 : R/W boot partition 2
+ * 0x3 : R/W Replay Protected Memory Block (RPMB)
+ *
+ * Returns 0 on success.
+ */
+int mmc_boot_part_access(struct mmc *mmc, u32 ack, u32 part_num, u32 access)
+{
+ int err;
+ struct mmc_cmd cmd;
+
+ /* Boot ack enable, boot partition enable , boot partition access */
+ cmd.cmdidx = MMC_CMD_SWITCH;
+ cmd.resp_type = MMC_RSP_R1b;
+
+ cmd.cmdarg = (MMC_SWITCH_MODE_WRITE_BYTE << 24) |
+ (EXT_CSD_PART_CONF << 16) |
+ ((EXT_CSD_BOOT_ACK(ack) |
+ EXT_CSD_BOOT_PART_NUM(part_num) |
+ EXT_CSD_PARTITION_ACCESS(access)) << 8);
+
+ err = mmc_send_cmd(mmc, &cmd, NULL);
+ if (err) {
+ if (access) {
+ debug("mmc boot partition#%d open fail:Error1 = %d\n",
+ part_num, err);
+ } else {
+ debug("mmc boot partition#%d close fail:Error = %d\n",
+ part_num, err);
+ }
+ return err;
+
[U-Boot] [PATCH V8 8/9] SMDK5250: Enable EMMC booting
This patch adds support for EMMC booting on SMDK5250.
Signed-off-by: Amar
---
Changes since V1:
1)Updated spl_boot.c file to maintain irom pointer table
instead of using the #define values defined in header file.
Changes since V2:
1)Updation of commit message and resubmition of proper patch set.
Changes since V3:
No change.
Changes since V4:
1)The function get_irom_func(int index) has been added to avoid
type casting at many places.
2)The changes to file arch/arm/include/asm/arch-exynos/clk.h are
included in this patch file.
Changes since V5:
No change.
Changes since V6:
No change.
Changes since V7:
1)The macros FSYS1_MMC0_DIV_MASK and FSYS1_MMC0_DIV_VAL are made
local to file clock_init.c.
board/samsung/smdk5250/clock_init.c | 18 +
board/samsung/smdk5250/clock_init.h | 5
board/samsung/smdk5250/spl_boot.c | 52 -
3 files changed, 69 insertions(+), 6 deletions(-)
diff --git a/board/samsung/smdk5250/clock_init.c
b/board/samsung/smdk5250/clock_init.c
index 5b9e82f..b288e66 100644
--- a/board/samsung/smdk5250/clock_init.c
+++ b/board/samsung/smdk5250/clock_init.c
@@ -28,10 +28,14 @@
#include
#include
#include
+#include
#include "clock_init.h"
#include "setup.h"
+#define FSYS1_MMC0_DIV_MASK0xff0f
+#define FSYS1_MMC0_DIV_VAL 0x0701
+
DECLARE_GLOBAL_DATA_PTR;
struct arm_clk_ratios arm_clk_ratios[] = {
@@ -664,3 +668,17 @@ void clock_init_dp_clock(void)
/* We run DP at 267 Mhz */
setbits_le32(&clk->div_disp1_0, CLK_DIV_DISP1_0_FIMD1);
}
+
+/*
+ * Set clock divisor value for booting from EMMC.
+ * Set DWMMC channel-0 clk div to operate mmc0 device at 50MHz.
+ */
+void emmc_boot_clk_div_set(void)
+{
+ struct exynos5_clock *clk = (struct exynos5_clock *)EXYNOS5_CLOCK_BASE;
+ unsigned int div_mmc;
+
+ div_mmc = readl((unsigned int) &clk->div_fsys1) & ~FSYS1_MMC0_DIV_MASK;
+ div_mmc |= FSYS1_MMC0_DIV_VAL;
+ writel(div_mmc, (unsigned int) &clk->div_fsys1);
+}
diff --git a/board/samsung/smdk5250/clock_init.h
b/board/samsung/smdk5250/clock_init.h
index f751bcb..20a1d47 100644
--- a/board/samsung/smdk5250/clock_init.h
+++ b/board/samsung/smdk5250/clock_init.h
@@ -146,4 +146,9 @@ struct mem_timings *clock_get_mem_timings(void);
* Initialize clock for the device
*/
void system_clock_init(void);
+
+/*
+ * Set clock divisor value for booting from EMMC.
+ */
+void emmc_boot_clk_div_set(void);
#endif
diff --git a/board/samsung/smdk5250/spl_boot.c
b/board/samsung/smdk5250/spl_boot.c
index d8f3c1e..fa2c0b2 100644
--- a/board/samsung/smdk5250/spl_boot.c
+++ b/board/samsung/smdk5250/spl_boot.c
@@ -23,15 +23,42 @@
#include
#include
+#include
+#include
+#include
+
+#include "clock_init.h"
+
+/* Index into irom ptr table */
+enum index {
+ MMC_INDEX,
+ EMMC44_INDEX,
+ EMMC44_END_INDEX,
+ SPI_INDEX,
+};
+
+/* IROM Function Pointers Table */
+u32 irom_ptr_table[] = {
+ [MMC_INDEX] = 0x02020030, /* iROM Function Pointer-SDMMC boot */
+ [EMMC44_INDEX] = 0x02020044,/* iROM Function Pointer-EMMC4.4 boot*/
+ [EMMC44_END_INDEX] = 0x02020048,/* iROM Function Pointer
+ -EMMC4.4 end boot operation */
+ [SPI_INDEX] = 0x02020058, /* iROM Function Pointer-SPI boot */
+ };
+
enum boot_mode {
BOOT_MODE_MMC = 4,
BOOT_MODE_SERIAL = 20,
+ BOOT_MODE_EMMC = 8, /* EMMC4.4 */
/* Boot based on Operating Mode pin settings */
BOOT_MODE_OM = 32,
BOOT_MODE_USB, /* Boot using USB download */
};
- typedef u32 (*spi_copy_func_t)(u32 offset, u32 nblock, u32 dst);
+void *get_irom_func(int index)
+{
+ return (void *)*(u32 *)irom_ptr_table[index];
+}
/*
* Copy U-boot from mmc to RAM:
@@ -40,23 +67,36 @@ enum boot_mode {
*/
void copy_uboot_to_ram(void)
{
- spi_copy_func_t spi_copy;
enum boot_mode bootmode;
- u32 (*copy_bl2)(u32, u32, u32);
-
+ u32 (*spi_copy)(u32 offset, u32 nblock, u32 dst);
+ u32 (*copy_bl2)(u32 offset, u32 nblock, u32 dst);
+ u32 (*copy_bl2_from_emmc)(u32 nblock, u32 dst);
+ void (*end_bootop_from_emmc)(void);
+ /* read Operation Mode ststus register to find the bootmode */
bootmode = readl(EXYNOS5_POWER_BASE) & OM_STAT;
switch (bootmode) {
case BOOT_MODE_SERIAL:
- spi_copy = *(spi_copy_func_t *)EXYNOS_COPY_SPI_FNPTR_ADDR;
+ spi_copy = get_irom_func(SPI_INDEX);
spi_copy(SPI_FLASH_UBOOT_POS, CONFIG_BL2_SIZE,
CONFIG_SYS_TEXT_BASE);
break;
case BOOT_MODE_MMC:
- copy_bl2 = (void *) *(u32 *)COPY_BL2_FNPTR_ADDR;
+ copy_bl2 = get_irom_func(MMC_INDEX);
copy_bl2(BL2_START_OFFSET, BL2_SIZE_BLOC
[U-Boot] [PATCH V8 9/9] COMMON: MMC: Command to support EMMC booting and to resize EMMC boot partition
This patch adds commands to access(open/close) and resize boot partitions on
EMMC.
Signed-off-by: Amar
---
Changes since V1:
1)Combined the common piece of code between 'open' and 'close'
operations.
Changes since V2:
1)Updation of commit message and resubmition of proper patch set.
Changes since V3:
No change.
Changes since V4:
1)Added a new funtion boot_part_access() to combine the common parts of
'mmc open' and 'mmc close' functionalities.
2)Used the generic function "mmc_boot_part_access()" instead of
two functions "mmc_boot_open()" and "mmc_boot_close()". By doing so user
can specify which boot partition to be accessed (opened / closed).
Changes since V5:
1)Updated minor nits in response to review comments.
Changes since V6:
No change.
Changes since V7:
1)The piece of code involved in open/close and resize of EMMC boot
partition has been made conditional and is enabled only if the macro
CONFIG_SUPPORT_EMMC_BOOT is defined.
common/cmd_mmc.c | 110 ++-
1 file changed, 108 insertions(+), 2 deletions(-)
diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
index 8c53a10..c5f60a2 100644
--- a/common/cmd_mmc.c
+++ b/common/cmd_mmc.c
@@ -147,6 +147,36 @@ U_BOOT_CMD(
"- display info of the current MMC device"
);
+#ifdef CONFIG_SUPPORT_EMMC_BOOT
+static int boot_part_access(struct mmc *mmc, u32 ack, u32 part_num, u32 access)
+{
+ int err;
+ err = mmc_boot_part_access(mmc, ack, part_num, access);
+
+ if ((err == 0) && (access != 0)) {
+ printf("\t\t\t!!!Notice!!!\n");
+
+ printf("!You must close EMMC boot Partition");
+ printf("after all images are written\n");
+
+ printf("!EMMC boot partition has continuity");
+ printf("at image writing time.\n");
+
+ printf("!So, do not close the boot partition");
+ printf("before all images are written.\n");
+ return 0;
+ } else if ((err == 0) && (access == 0))
+ return 0;
+ else if ((err != 0) && (access != 0)) {
+ printf("EMMC boot partition-%d OPEN Failed.\n", part_num);
+ return 1;
+ } else {
+ printf("EMMC boot partition-%d CLOSE Failed.\n", part_num);
+ return 1;
+ }
+}
+#endif
+
static int do_mmcops(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
enum mmc_state state;
@@ -248,8 +278,75 @@ static int do_mmcops(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
curr_device, mmc->part_num);
return 0;
- }
+#ifdef CONFIG_SUPPORT_EMMC_BOOT
+ } else if ((strcmp(argv[1], "open") == 0) ||
+ (strcmp(argv[1], "close") == 0)) {
+ int dev;
+ struct mmc *mmc;
+ u32 ack, part_num, access = 0;
+
+ if (argc == 4) {
+ dev = simple_strtoul(argv[2], NULL, 10);
+ part_num = simple_strtoul(argv[3], NULL, 10);
+ } else {
+ return CMD_RET_USAGE;
+ }
+ mmc = find_mmc_device(dev);
+ if (!mmc) {
+ printf("no mmc device at slot %x\n", dev);
+ return 1;
+ }
+
+ if (IS_SD(mmc)) {
+ printf("SD device cannot be opened/closed\n");
+ return 1;
+ }
+
+ if ((part_num <= 0) || (part_num > MMC_NUM_BOOT_PARTITION)) {
+ printf("Invalid boot partition number:\n");
+ printf("Boot partition number cannot be <= 0\n");
+ printf("EMMC44 supports only 2 boot partitions\n");
+ return 1;
+ }
+
+ if (strcmp(argv[1], "open") == 0)
+ access = part_num; /* enable R/W access to boot part*/
+ if (strcmp(argv[1], "close") == 0)
+ access = 0; /* No access to boot partition */
+
+ /* acknowledge to be sent during boot operation */
+ ack = 1;
+ return boot_part_access(mmc, ack, part_num, access);
+
+ } else if (strcmp(argv[1], "bootpart") == 0) {
+ int dev;
+ dev = simple_strtoul(argv[2], NULL, 10);
+
+ u32 bootsize = simple_strtoul(argv[3], NULL, 10);
+ u32 rpmbsize = simple_strtoul(argv[4], NULL, 10);
+ struct mmc *mmc = find_mmc_device(dev);
+ if (!mmc) {
+ printf("no mmc device at slot %x\n", dev);
+ return 1;
+ }
+
+ if (IS_SD(mmc)) {
+ printf("It is not a EMMC device\n");
+
Re: [U-Boot] [RFC] command/cache: Add flush_cache command
I apologize for being so late with this question.
York Sun freescale.com> writes:
>
> When we need the copied code/data in the main memory, we can flush the
> cache now. It uses the existing function flush_cache. Syntax is
>
> flush_cache
>
> The addr and size are given in hexadecimal. Like memory command, there is
> no sanity check for the parameters.
>
Are there symptoms for a specific system failure you can provide?
My problem is that when a stand alone application, which is copied from NOR
flash to DDR, is started with the "go" command, it sometimes experiences a
program check (illegal instruction) after a block of 32 zero bytes "appears" in
memory.
I'm using a U-Boot for a custom Freescale P1022-based board, currently based on
the old 2010.12 U-Boot as patched by Freescale in their
SDK_V1_0_20110429_ltib.iso. Unfortunately, upgrading to a more recent version of
U-Boot is not possible at this time, no more recent version is available from
Freescale and I don't have the resources to verify all their patches apply
correctly to a release directly from DENX.
I've used Codewarrior to observe the block of zeros in memory once the program
check has happened, and I've verified that before the stand alone application
begins execution, there are no zeros. Figuring it is likely that I have an error
in my stand alone application code that corrupts the stack or writes based on an
un-initialized pointer, I've tried using the CW watchpoint to catch where the
zeros are written, but enabling the watchpoint seems to avoid the problem.
Based on later discussion on this thread, I've tried adding "flush_dcache();
invalidate_icache();" to cmd_boot.c:do_go(), just before control is passed to
the stand alone app. Based on my ad hoc testing with this change, I don't get
the program check exception.
I believe this result helps make the case that caching behavior is at the root
of my problem, but since I was not able to isolate the actual cause of that
problem, I can't be sure I've really got the solution.
(By the way, I would not leave the "flush_dcache(); invalidate_icache();" in
do_go(), I merely found that for demonstrating a possible solution, this change
easier than switching to a stand alone app that starts with bootm, or similar)
Any help or comments are very welcome.
Thanks,
Jim
> Signed-off-by: York Sun freescale.com>
> ---
> common/cmd_cache.c | 30 ++
> 1 file changed, 30 insertions(+)
>
> diff --git a/common/cmd_cache.c b/common/cmd_cache.c
> index 5512f92..93b7337 100644
> --- a/common/cmd_cache.c
> +++ b/common/cmd_cache.c
> @@ -94,6 +94,29 @@ int do_dcache(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
> return 0;
> }
>
> +void __weak flush_cache(ulong addr, ulong size)
> +{
> + puts("No arch specific flush_cache available!\n");
> + /* please define arch specific flush_cache */
> +}
> +
> +int do_flush_cache(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
> +{
> + ulong addr, size;
> +
> + switch (argc) {
> + case 3:
> + addr = simple_strtoul(argv[1], NULL, 16);
> + size = simple_strtoul(argv[2], NULL, 16);
> + flush_cache(addr, size);
> + break;
> + default:
> + return cmd_usage(cmdtp);
> + }
> + return 0;
> +
> +}
> +
> static int parse_argv(const char *s)
> {
> if (strcmp(s, "flush") == 0)
> @@ -120,3 +143,10 @@ U_BOOT_CMD(
> "[on, off, flush]\n"
> "- enable, disable, or flush data (writethrough) cache"
> );
> +
> +U_BOOT_CMD(
> + flush_cache, 3, 0, do_flush_cache,
> + "flush cache for a range",
> + " \n"
> + "- flush cache for specificed range"
> +);
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] i.MX6: mx6qsabrelite: README: don't pass chip-select to sf probe command
On 04/03/2013 02:25 AM, Stefano Babic wrote: On 25/03/2013 17:13, Javier Martinez Canillas wrote: since commit "c1173bd0: sf command: allow default bus and chip selects" the chip-select and bus arguments for the sf probe command are optional. Hi Javier, Even when passing the chip-select to sf probe says to be optional, it makes "sf erase" and "sf write" to fail on a mx6qsabrelite board. e.g: MX6QSABRELITE U-Boot > sf probe 1 MX6QSABRELITE U-Boot > sf erase 0 0x4 SPI flash erase failed MX6QSABRELITE U-Boot > sf write 0x1080 0 0x4 SPI flash write failed Well, the real reason is that the passed chipselect is wrong. Checking in the configuration file, I see that the value to be passed should be 0x7300. I suppose (I am not testing) that "sf probe 0x7300" make sf erase and sw write working. It's 0x5300 as listed in commit c1173bd0. And the SABRE Lite README definitely needs updates. Regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] i.MX6: mx6qsabrelite: README: don't pass chip-select to sf probe command
On 04/03/2013 03:13 AM, Stefano Babic wrote:
On 03/04/2013 11:50, Javier Martinez Canillas wrote:
Just for curiosity, in which configuration file did you see that? When
I had the issue I looked at
include/configs/{mx6qsabrelite,mx6_common}.h and
board/freescale/mx6qsabrelite/mx6qsabrelite.c but I didn't find what
chip-select was supposed to be used.
include/configs/mx6qsabrelite.h:
#define CONFIG_SF_DEFAULT_CS (0|(IMX_GPIO_NR(3, 19)<<8))
It should be 0x7300
0x5300?
(((3-1)*32)+19)<<8
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP (4) boot_params
Hi Michael,
On Wed, 3 Apr 2013 09:45:19 -0400, Michael Cashwell
wrote:
> On Apr 3, 2013, at 1:56 AM, Albert ARIBAUD wrote:
>
> > (please wrap your line around 70 chars max)
>
> I've never understood why this is useful. [...]
... but apparently you managed to do it, thanks.
> > On Tue, 2 Apr 2013 18:39:17 -0400, Michael Cashwell
> > wrote:
> >
> >> I've been fighting with SPL passing not boot_params properly to u-boot
> >> on OMAP4. There are many layers to this onion but I've tracked the bulk
> >> of the problem down to the following issues.
> >>
> >> ...Making that:
> >>
> >> u32 *boot_params_ptr __attribute__ ((section(".data")));
> >>
> >> allows the pointer to be in SPL data section (SRAM) and still have its
> >> value by the time image_entry() is called. But common/spl/spl.c is not
> >> omap-specific so changes there are a concern.
> >
> > If I'm not mistaken, lowlevel_init() is not supposed to use BSS at all,
> > as the C runtime has not been initialized yet -- precisely, the BSS
> > clearing loop long after the cpu_init_crit() call belongs to the code
> > that sets up this environment.
>
> Yes, that was my thinking too. Surely clearing data after code has set
> it can't be right.
With all due respect, the documentation can with greater legitimately
turn your admonition around and ask that you please refrain from
setting BSS or data variables when the C runtime environment has not
been set. :)
IOW, what is wrong here is writing to a BSS variable before you're
allowed to as per the rules under which your code is running.
> > Besides, it seems like SPL does not jump directly to Linux but to
> > U-Boot, so U-Boot itself should set up the boot params, not SPL, which
> > can at best prepare and store values in static RAM not mapped as data
> > or BSS in either SPL or U-Boot (this is normally done through GD).
>
> OK, here we have an unfortunate name overloading. The boot_params here
> is specifically an OMAP handoff from the CPU's internal boot ROM to SPL
> and then from SPL to u-boot. (The same code paths are involved.) It's
> totally unrelated to the the boot_params passed to the Linux kernel.
>
> Since it's confusing maybe a renaming is called for as well.
Indeed. Plus, if it is shared data, it should definitely be mapped at a
fixed memory location or copied from stage to stage (the latter only if
the former is impossible)
> Best regards,
> -Mike
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Subject: [PATCH 1/2] OMAP4: Add ID for OMAP4470_ES1_0
Signed-off-by: Lubomir Popov --- arch/arm/include/asm/omap_common.h |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/include/asm/omap_common.h b/arch/arm/include/asm/omap_common.h index 091ddb5..f042c10 100644 --- a/arch/arm/include/asm/omap_common.h +++ b/arch/arm/include/asm/omap_common.h @@ -573,6 +573,7 @@ static inline u32 omap_revision(void) #define OMAP4430_ES2_3 0x44300230 #define OMAP4460_ES1_0 0x44600100 #define OMAP4460_ES1_1 0x44600110 +#define OMAP4470_ES1_0 0x44700100 /* omap5 */ #define OMAP5430_SILICON_ID_INVALID0 -- 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] OMAP4: Add basic support for OMAP4470/TWL6032
H/W used for test: TI Blaze/Tablet OMAP4470 Processor Board
(750-2173-005) mounted on a custom main board (MMS benvolio4).
Fixed bug in vcores_data omap4460_volts struct referencing tps62361
instead of twl6030 for core and mm voltages.
Fixed some comments.
Signed-off-by: Lubomir Popov
---
arch/arm/cpu/armv7/omap4/hw_data.c | 53 ++--
arch/arm/cpu/armv7/omap4/hwinit.c|6 +++
arch/arm/cpu/armv7/omap4/sdram_elpida.c | 65 ++
arch/arm/include/asm/arch-omap4/clocks.h |7 +++-
arch/arm/include/asm/arch-omap4/omap.h |1 +
5 files changed, 119 insertions(+), 13 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap4/hw_data.c
b/arch/arm/cpu/armv7/omap4/hw_data.c
index 7551b98..fc4990a 100644
--- a/arch/arm/cpu/armv7/omap4/hw_data.c
+++ b/arch/arm/cpu/armv7/omap4/hw_data.c
@@ -7,6 +7,9 @@
*
* Sricharan R
*
+ * 03/2013 Lubomir Popov
+ * Added basic support for 750-2173 OMAP4470 board.
+ *
* See file CREDITS for list of people who contributed to this
* project.
*
@@ -66,6 +69,7 @@ static const struct dpll_params
mpu_dpll_params_1400mhz[NUM_SYS_CLKS] = {
/*
* dpll locked at 1600 MHz - MPU clk at 800 MHz(OPP Turbo 4430)
* OMAP4430 OPP_TURBO frequency
+ * OMAP4470 OPP_NOM frequency
*/
static const struct dpll_params mpu_dpll_params_1600mhz[NUM_SYS_CLKS] = {
{200, 2, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},/* 12 MHz */
@@ -92,6 +96,7 @@ static const struct dpll_params
mpu_dpll_params_1200mhz[NUM_SYS_CLKS] = {
};
/* OMAP4460 OPP_NOM frequency */
+/* OMAP4470 OPP_NOM (Low Power) frequency */
static const struct dpll_params core_dpll_params_1600mhz[NUM_SYS_CLKS] = {
{200, 2, 1, 5, 8, 4, 6, 5, -1, -1, -1, -1}, /* 12 MHz */
{800, 12, 1, 5, 8, 4, 6, 5, -1, -1, -1, -1},/* 13 MHz */
@@ -214,16 +219,30 @@ struct dplls omap4460_dplls = {
.ddr = NULL
};
+struct dplls omap4470_dplls = {
+ .mpu = mpu_dpll_params_1600mhz,
+ .core = core_dpll_params_1600mhz,
+ .per = per_dpll_params_1536mhz,
+ .iva = iva_dpll_params_1862mhz,
+#ifdef CONFIG_SYS_OMAP_ABE_SYSCK
+ .abe = abe_dpll_params_sysclk_196608khz,
+#else
+ .abe = &abe_dpll_params_32k_196608khz,
+#endif
+ .usb = usb_dpll_params_1920mhz,
+ .ddr = NULL
+};
+
struct pmic_data twl6030_4430es1 = {
.base_offset = PHOENIX_SMPS_BASE_VOLT_STD_MODE_UV,
- .step = 12660, /* 10 mV represented in uV */
+ .step = 12660, /* 12.7 mV represented in uV */
/* The code starts at 1 not 0 */
.start_code = 1,
};
struct pmic_data twl6030 = {
.base_offset = PHOENIX_SMPS_BASE_VOLT_STD_MODE_WITH_OFFSET_UV,
- .step = 12660, /* 10 mV represented in uV */
+ .step = 12660, /* 12.7 mV represented in uV */
/* The code starts at 1 not 0 */
.start_code = 1,
};
@@ -236,6 +255,13 @@ struct pmic_data tps62361 = {
.gpio_en = 1
};
+struct pmic_data twl6032 = {
+ .base_offset = PHOENIX_SMPS_BASE_VOLT_STD_MODE_WITH_OFFSET_UV,
+ .step = 12660, /* 12.7 mV represented in uV */
+ /* The code starts at 1 not 0 */
+ .start_code = 1,
+};
+
struct vcores_data omap4430_volts_es1 = {
.mpu.value = 1325,
.mpu.addr = SMPS_REG_ADDR_VCORE1,
@@ -271,11 +297,25 @@ struct vcores_data omap4460_volts = {
.core.value = 1200,
.core.addr = SMPS_REG_ADDR_VCORE1,
- .core.pmic = &tps62361,
+ .core.pmic = &twl6030,
.mm.value = 1200,
.mm.addr = SMPS_REG_ADDR_VCORE2,
- .mm.pmic = &tps62361,
+ .mm.pmic = &twl6030,
+};
+
+struct vcores_data omap4470_volts = {
+ .mpu.value = 1203,
+ .mpu.addr = SMPS1_REG_ADDR_MPU,
+ .mpu.pmic = &twl6032,
+
+ .core.value = 1127,
+ .core.addr = SMPS2_REG_ADDR_CORE,
+ .core.pmic = &twl6032,
+
+ .mm.value = 1139,
+ .mm.addr = SMPS5_REG_ADDR_MM,
+ .mm.pmic = &twl6032,
};
/*
@@ -483,6 +523,11 @@ void hw_data_init(void)
*omap_vcores = &omap4460_volts;
break;
+ case OMAP4470_ES1_0:
+ *dplls_data = &omap4470_dplls;
+ *omap_vcores = &omap4470_volts;
+ break;
+
default:
printf("\n INVALID OMAP REVISION ");
}
diff --git a/arch/arm/cpu/armv7/omap4/hwinit.c
b/arch/arm/cpu/armv7/omap4/hwinit.c
index 2db517b..586ffe2 100644
--- a/arch/arm/cpu/armv7/omap4/hwinit.c
+++ b/arch/arm/cpu/armv7/omap4/hwinit.c
@@ -9,6 +9,9 @@
* Aneesh V
* Steve Sakoman
*
+ * 03/2013 Lubomir Popov
+ * Added basic support for 750-2173 OMAP4470 board.
+ *
* See file CREDITS for list of people who contributed to this
* project.
*
@@ -153,6 +156,9 @@ void init_omap_revision(void)
break;
case MIDR_CORTEX_A9_R2P10:
switch (readl(CONTROL_ID_CODE)) {
+ case OMAP4470_CONTROL_ID_CODE_ES1_0:
+ *omap_si_rev = OMAP4470_ES1_0
[U-Boot] [PATCH] pcm051: Enable DDR PHY dynamic power down bit
From: Lars Poeschel
This is done already for am335x in
59dcf970d11ebff5d9f4bbbde79fda584e9e7ad4 and also applies for pcm051.
It powers down the IO receiver when not performing read which helps
reducing the overall power consuption in low power states
(suspend/standby).
Signed-off-by: Lars Poeschel
---
board/phytec/pcm051/board.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/board/phytec/pcm051/board.c b/board/phytec/pcm051/board.c
index 1708ac2..43d7b6e 100644
--- a/board/phytec/pcm051/board.c
+++ b/board/phytec/pcm051/board.c
@@ -104,7 +104,8 @@ static struct emif_regs ddr3_emif_reg_data = {
.sdram_tim2 = MT41J256M8HX15E_EMIF_TIM2,
.sdram_tim3 = MT41J256M8HX15E_EMIF_TIM3,
.zq_config = MT41J256M8HX15E_ZQ_CFG,
- .emif_ddr_phy_ctlr_1 = MT41J256M8HX15E_EMIF_READ_LATENCY,
+ .emif_ddr_phy_ctlr_1 = MT41J256M8HX15E_EMIF_READ_LATENCY |
+ PHY_EN_DYN_PWRDN,
};
#endif
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] i.MX6: mx6qsabrelite: README: don't pass chip-select to sf probe command
On 03/04/2013 16:11, Eric Nelson wrote:
> On 04/03/2013 03:13 AM, Stefano Babic wrote:
>> On 03/04/2013 11:50, Javier Martinez Canillas wrote:
>>> Just for curiosity, in which configuration file did you see that? When
>>> I had the issue I looked at
>>> include/configs/{mx6qsabrelite,mx6_common}.h and
>>> board/freescale/mx6qsabrelite/mx6qsabrelite.c but I didn't find what
>>> chip-select was supposed to be used.
>>
>> include/configs/mx6qsabrelite.h:
>>
>> #define CONFIG_SF_DEFAULT_CS (0|(IMX_GPIO_NR(3, 19)<<8))
>>
>> It should be 0x7300
>>
> 0x5300?
>
> (((3-1)*32)+19)<<8
>
Right, forget to subtract 1.
Regards,
Stefano
--
=
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] [PATCH v3 4/6] omap_gpmc: change nandecc command
With uppcoming BCH support on OMAP devices we need to decide between differnt
algorithms when switching the ECC engine. Currently we support 1-bit hammign
and 8-bit BCH on HW backend.
In order to switch between differnet ECC algorithms we need to change the
interface of omap_nand_switch_ecc() also.
Signed-off-by: Andreas Bießmann
Cc: Tom Rini
---
new in v2
since v2:
* use void omap_nand_switch_ecc(bool, uint32_t)
* print warning if unknown HW ecc strengs choosen
* fix alignment in help test
arch/arm/cpu/armv7/omap3/board.c | 31 +
arch/arm/include/asm/arch-am33xx/sys_proto.h |2 +-
arch/arm/include/asm/arch-omap3/sys_proto.h |2 +-
drivers/mtd/nand/omap_gpmc.c | 61 ++
4 files changed, 59 insertions(+), 37 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap3/board.c b/arch/arm/cpu/armv7/omap3/board.c
index c6d9a42..0150150 100644
--- a/arch/arm/cpu/armv7/omap3/board.c
+++ b/arch/arm/cpu/armv7/omap3/board.c
@@ -328,14 +328,25 @@ void abort(void)
*/
static int do_switch_ecc(cmd_tbl_t * cmdtp, int flag, int argc, char * const
argv[])
{
- if (argc != 2)
+ if (argc < 2 || argc > 3)
goto usage;
- if (strncmp(argv[1], "hw", 2) == 0)
- omap_nand_switch_ecc(1);
- else if (strncmp(argv[1], "sw", 2) == 0)
- omap_nand_switch_ecc(0);
- else
+
+ if (strncmp(argv[1], "hw", 2) == 0) {
+ if (argc == 2) {
+ omap_nand_switch_ecc(true, 1);
+ } else {
+ if (strncmp(argv[2], "hamming", 7) == 0)
+ omap_nand_switch_ecc(true, 1);
+ else if (strncmp(argv[2], "bch8", 4) == 0)
+ omap_nand_switch_ecc(true, 8);
+ else
+ goto usage;
+ }
+ } else if (strncmp(argv[1], "sw", 2) == 0) {
+ omap_nand_switch_ecc(false, 0);
+ } else {
goto usage;
+ }
return 0;
@@ -345,9 +356,13 @@ usage:
}
U_BOOT_CMD(
- nandecc, 2, 1, do_switch_ecc,
+ nandecc, 3, 1, do_switch_ecc,
"switch OMAP3 NAND ECC calculation algorithm",
- "[hw/sw] - Switch between NAND hardware (hw) or software (sw) ecc
algorithm"
+ "hw [hamming|bch8] - Switch between NAND hardware 1-bit hamming and"
+ " 8-bit BCH\n"
+ "ecc calculation (second parameter may"
+ " be omitted).\n"
+ "nandecc sw- Switch to NAND software ecc algorithm."
);
#endif /* CONFIG_NAND_OMAP_GPMC & !CONFIG_SPL_BUILD */
diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h
b/arch/arm/include/asm/arch-am33xx/sys_proto.h
index 0910a94..23a3049 100644
--- a/arch/arm/include/asm/arch-am33xx/sys_proto.h
+++ b/arch/arm/include/asm/arch-am33xx/sys_proto.h
@@ -39,5 +39,5 @@ struct gpmc_cs;
void gpmc_init(void);
void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs *cs, u32
base,
u32 size);
-void omap_nand_switch_ecc(int);
+void omap_nand_switch_ecc(bool, uint32_t);
#endif
diff --git a/arch/arm/include/asm/arch-omap3/sys_proto.h
b/arch/arm/include/asm/arch-omap3/sys_proto.h
index d60f2ad..4ca4e73 100644
--- a/arch/arm/include/asm/arch-omap3/sys_proto.h
+++ b/arch/arm/include/asm/arch-omap3/sys_proto.h
@@ -78,7 +78,7 @@ void sr32(void *, u32, u32, u32);
u32 wait_on_value(u32, u32, void *, u32);
void sdelay(unsigned long);
void make_cs1_contiguous(void);
-void omap_nand_switch_ecc(int);
+void omap_nand_switch_ecc(bool, uint32_t);
void power_init_r(void);
void dieid_num_r(void);
void do_omap3_emu_romcode_call(u32 service_id, u32 parameters);
diff --git a/drivers/mtd/nand/omap_gpmc.c b/drivers/mtd/nand/omap_gpmc.c
index c7d4999..0647828 100644
--- a/drivers/mtd/nand/omap_gpmc.c
+++ b/drivers/mtd/nand/omap_gpmc.c
@@ -604,13 +604,14 @@ static int omap_read_page_bch(struct mtd_info *mtd,
struct nand_chip *chip,
#ifndef CONFIG_SPL_BUILD
/*
- * omap_nand_switch_ecc - switch the ECC operation b/w h/w ecc and s/w ecc.
- * The default is to come up on s/w ecc
- *
- * @hardware - 1 -switch to h/w ecc, 0 - s/w ecc
+ * omap_nand_switch_ecc - switch the ECC operation between different engines
+ * (h/w and s/w) and different algorithms (hamming and BCHx)
*
+ * @hardware - true if one of the HW engines should be used
+ * @eccstrength- the number of bits that could be corrected
+ * (1 - hamming, 4 - BCH4, 8 - BCH8, 16 - BCH16)
*/
-void omap_nand_switch_ecc(int32_t hardware)
+void omap_nand_switch_ecc(bool hardware, uint32_t eccstrength)
{
struct nand_chip *nand;
struct mtd_info *mtd;
@@ -637,35 +638,41 @@ void omap_nand_switch_ecc(int32_t hardware)
nand->ecc.calculate = NULL;
/*
[U-Boot] [PATCH v3 5/6] omap_gpmc: add support for hw assisted BCH8
The kernel states:
---8<---
The OMAP3 GPMC hardware BCH engine computes remainder polynomials, it does not
provide automatic error location and correction: this step is implemented using
the BCH library.
--->8---
And we do so in u-boot.
This implementation uses the same layout for BCH8 but it is fix. The current
provided layout does only work with 64 Byte OOB.
Signed-off-by: Andreas Bießmann
Cc: Tom Rini
Cc: Ilya Yanok
Cc: Scott Wood
Cc: Mansoor Ahamed
---
since v1:
* cleanups (remove debug stuff)
* make checkpach clean (still 2 warnings which I will not fix)
* merge some code with the AM33XX implementation
since v2:
* fix all checkpatch warnings
* add more comments
* add NAND section in README.omap3
doc/README.omap3 | 19 +++
drivers/mtd/nand/omap_gpmc.c | 367 +++---
lib/Makefile |2 +-
3 files changed, 296 insertions(+), 92 deletions(-)
diff --git a/doc/README.omap3 b/doc/README.omap3
index 0a37de0..56aca8e 100644
--- a/doc/README.omap3
+++ b/doc/README.omap3
@@ -145,6 +145,25 @@ int omap3_dma_wait_for_transfer(uint32_t chan)
int omap3_dma_get_revision(uint32_t *minor, uint32_t *major)
Read silicon Revision of the DMA module
+NAND
+
+
+Ther eare some OMAP3 devices out ther with NAND attached. Due to the fact that
+OMAP3 ROM code can only handle 1-bit hamming ECC for accessing first page
+(place where SPL lives) we require this setup for u-boot at least when reading
+the second progam within SPL. A lot of newer NAND chips however require more
+than 1-bit ECC for the pages, some can live with 1-bit for the first page. To
+handle this we can switch to another ECC algorithm after reading the payload
+within SPL.
+
+BCH8
+
+
+To enable hardware assisted BCH8 (8-bit BCH [Bose, Chaudhuri, Hocquenghem]) on
+OMAP3 devices we can use the BCH library in lib/bch.c. To do so add CONFIG_BCH
+to enable the library and CONFIG_NAND_OMAP_BCH8 to your board config.
+The NAND OOB layout is the same as in linux kernel, if the linux kernel BCH8
+implementation for OMAP3 works for you so the u-boot version should also.
Acknowledgements
diff --git a/drivers/mtd/nand/omap_gpmc.c b/drivers/mtd/nand/omap_gpmc.c
index 0647828..de41e46 100644
--- a/drivers/mtd/nand/omap_gpmc.c
+++ b/drivers/mtd/nand/omap_gpmc.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
#ifdef CONFIG_AM33XX
@@ -37,6 +38,8 @@
static uint8_t cs;
static __maybe_unused struct nand_ecclayout hw_nand_oob =
GPMC_NAND_HW_ECC_LAYOUT;
+static __maybe_unused struct nand_ecclayout hw_bch8_nand_oob =
+ GPMC_NAND_HW_BCH8_ECC_LAYOUT;
/*
* omap_nand_hwcontrol - Set the address pointers corretly for the
@@ -239,13 +242,13 @@ static void __maybe_unused omap_enable_hwecc(struct
mtd_info *mtd, int32_t mode)
}
/*
- * BCH8 support (needs ELM and thus AM33xx-only)
+ * Generic BCH interface
*/
-#ifdef CONFIG_AM33XX
struct nand_bch_priv {
uint8_t mode;
uint8_t type;
uint8_t nibbles;
+ struct bch_control *control;
};
/* bch types */
@@ -253,21 +256,146 @@ struct nand_bch_priv {
#define ECC_BCH8 1
#define ECC_BCH16 2
+/* GPMC ecc engine settings */
+#define BCH_WRAPMODE_1 1 /* BCH wrap mode 1 */
+#define BCH_WRAPMODE_6 6 /* BCH wrap mode 6 */
+
/* BCH nibbles for diff bch levels */
#define NAND_ECC_HW_BCH ((uint8_t)(NAND_ECC_HW_OOB_FIRST) + 1)
#define ECC_BCH4_NIBBLES 13
#define ECC_BCH8_NIBBLES 26
#define ECC_BCH16_NIBBLES 52
-static struct nand_ecclayout hw_bch8_nand_oob = GPMC_NAND_HW_BCH8_ECC_LAYOUT;
-
-static struct nand_bch_priv bch_priv = {
+/*
+ * This can be a single instance cause all current users have only one NAND
+ * with nearly the same setup (BCH8, some with ELM and others with sw BCH
+ * library).
+ * When some users with other BCH strength will exists this have to change!
+ */
+static __maybe_unused struct nand_bch_priv bch_priv = {
.mode = NAND_ECC_HW_BCH,
.type = ECC_BCH8,
- .nibbles = ECC_BCH8_NIBBLES
+ .nibbles = ECC_BCH8_NIBBLES,
+ .control = NULL
};
/*
+ * omap_hwecc_init_bch - Initialize the BCH Hardware ECC for NAND flash in
+ * GPMC controller
+ * @mtd: MTD device structure
+ * @mode: Read/Write mode
+ */
+__maybe_unused
+static void omap_hwecc_init_bch(struct nand_chip *chip, int32_t mode)
+{
+ uint32_t val;
+ uint32_t dev_width = (chip->options & NAND_BUSWIDTH_16) >> 1;
+#ifdef CONFIG_AM33XX
+ uint32_t unused_length = 0;
+#endif
+ uint32_t wr_mode = BCH_WRAPMODE_6;
+ struct nand_bch_priv *bch = chip->priv;
+
+ /* Clear the ecc result registers, select ecc reg as 1 */
+ writel(ECCCLEAR | ECCRESULTREG1, &gpmc_cfg->ecc_control);
+
+#ifdef CONFIG_AM33XX
+ wr_mode = BCH_WRAPMODE_1;
+
+ switch (bch->nibbles) {
+ case ECC_BCH4_NIBBLES:
+
[U-Boot] [PATCH 3/4] Tegra: Plutux: Enable NAND and boot script support
Boot script support brings Plutux in line with other Tegra boards. In order to enable booting a Linux kernel with initial ramdisk, also add support for the new FIT image type. Signed-off-by: Thierry Reding --- include/configs/plutux.h | 18 +++--- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/include/configs/plutux.h b/include/configs/plutux.h index 4cfe88a..25ee83a 100644 --- a/include/configs/plutux.h +++ b/include/configs/plutux.h @@ -42,8 +42,7 @@ #define CONFIG_SYS_NS16550_COM1NV_PA_APB_UARTD_BASE #define CONFIG_BOARD_EARLY_INIT_F - -#define CONFIG_ENV_IS_NOWHERE +#define CONFIG_BOARD_LATE_INIT /* SD/MMC */ #define CONFIG_MMC @@ -51,6 +50,15 @@ #define CONFIG_TEGRA_MMC #define CONFIG_CMD_MMC +/* NAND support */ +#define CONFIG_CMD_NAND +#define CONFIG_TEGRA_NAND +#define CONFIG_SYS_MAX_NAND_DEVICE 1 + +/* Environment in NAND, aligned to start of last sector */ +#define CONFIG_ENV_IS_IN_NAND +#define CONFIG_ENV_OFFSET (SZ_512M - SZ_128K) /* 128K sectors */ + /* USB host support */ #define CONFIG_USB_EHCI #define CONFIG_USB_EHCI_TEGRA @@ -65,13 +73,9 @@ #define CONFIG_CMD_NET #define CONFIG_CMD_DHCP +/* support the new (FDT-based) image format */ #define CONFIG_FIT -#define CONFIG_BOOTCOMMAND \ - "mmc rescan;" \ - "ext2load mmc 0 0x1700 /boot/uImage;" \ - "bootm" - #include "tegra-common-post.h" #endif /* __CONFIG_H */ -- 1.8.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] Tegra: TEC: Enable boot script support
Boot script support brings TEC in line with other Tegra boards. To enable booting a Linux kernel with initial ramdisk, also include support for the new FIT image type. Signed-off-by: Thierry Reding --- include/configs/tec.h | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/include/configs/tec.h b/include/configs/tec.h index f90f5c7..f280cc0 100644 --- a/include/configs/tec.h +++ b/include/configs/tec.h @@ -73,13 +73,6 @@ #define CONFIG_CMD_NET #define CONFIG_CMD_DHCP -#define CONFIG_FIT - -#define CONFIG_BOOTCOMMAND \ - "mmc rescan;" \ - "ext2load mmc 0 0x1700 /boot/uImage;" \ - "bootm" - /* LCD support */ #define CONFIG_LCD #define CONFIG_PWM_TEGRA @@ -87,6 +80,9 @@ #define LCD_BPP LCD_COLOR16 #define CONFIG_SYS_WHITE_ON_BLACK +/* support the new (FDT-based) image format */ +#define CONFIG_FIT + #include "tegra-common-post.h" #endif /* __CONFIG_H */ -- 1.8.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] Tegra: Medcom-Wide: Enable NAND and boot script support
Boot script support brings Medcom-Wide in line with other Tegra boards. In order to enable booting a Linux kernel with initial ramdisk, also add support for the new FIT image type. Signed-off-by: Thierry Reding --- include/configs/medcom-wide.h | 21 - 1 file changed, 12 insertions(+), 9 deletions(-) diff --git a/include/configs/medcom-wide.h b/include/configs/medcom-wide.h index 57a50d7..eebf385 100644 --- a/include/configs/medcom-wide.h +++ b/include/configs/medcom-wide.h @@ -44,14 +44,21 @@ #define CONFIG_BOARD_EARLY_INIT_F #define CONFIG_BOARD_LATE_INIT -#define CONFIG_ENV_IS_NOWHERE - /* SD/MMC */ #define CONFIG_MMC #define CONFIG_GENERIC_MMC #define CONFIG_TEGRA_MMC #define CONFIG_CMD_MMC +/* NAND support */ +#define CONFIG_CMD_NAND +#define CONFIG_TEGRA_NAND +#define CONFIG_SYS_MAX_NAND_DEVICE 1 + +/* Environment in NAND, aligned to start of last sector */ +#define CONFIG_ENV_IS_IN_NAND +#define CONFIG_ENV_OFFSET (SZ_512M - SZ_128K) /* 128K sectors */ + /* USB host support */ #define CONFIG_USB_EHCI #define CONFIG_USB_EHCI_TEGRA @@ -66,13 +73,6 @@ #define CONFIG_CMD_NET #define CONFIG_CMD_DHCP -#define CONFIG_FIT - -#define CONFIG_BOOTCOMMAND \ - "mmc rescan;" \ - "ext2load mmc 0 0x1700 /boot/uImage;" \ - "bootm" - /* LCD support */ #define CONFIG_LCD #define CONFIG_PWM_TEGRA @@ -80,6 +80,9 @@ #define LCD_BPP LCD_COLOR16 #define CONFIG_SYS_WHITE_ON_BLACK +/* support the new (FDT-based) image format */ +#define CONFIG_FIT + #include "tegra-common-post.h" #endif /* __CONFIG_H */ -- 1.8.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] Tegra: All Tamonten-derived boards use onboard NAND
Move the nand-controller node to the tegra20-tamonten.dtsi so that it
can be shared between all derived boards.
Signed-off-by: Thierry Reding
---
board/avionic-design/dts/tegra20-tamonten.dtsi | 11 +++
board/avionic-design/dts/tegra20-tec.dts | 11 ---
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/board/avionic-design/dts/tegra20-tamonten.dtsi
b/board/avionic-design/dts/tegra20-tamonten.dtsi
index 86c7bab..f379622 100644
--- a/board/avionic-design/dts/tegra20-tamonten.dtsi
+++ b/board/avionic-design/dts/tegra20-tamonten.dtsi
@@ -279,6 +279,17 @@
status = "okay";
};
+ nand-controller@70008000 {
+ nvidia,wp-gpios = <&gpio 23 0>; /* PC7 */
+ nvidia,width = <8>;
+ nvidia,timing = <26 100 20 80 20 10 12 10 70>;
+
+ nand@0 {
+ reg = <0>;
+ compatible = "hynix,hy27uf4g2b", "nand-flash";
+ };
+ };
+
i2c@7000c000 {
clock-frequency = <40>;
status = "okay";
diff --git a/board/avionic-design/dts/tegra20-tec.dts
b/board/avionic-design/dts/tegra20-tec.dts
index 1d7cf89..4c1b08d 100644
--- a/board/avionic-design/dts/tegra20-tec.dts
+++ b/board/avionic-design/dts/tegra20-tec.dts
@@ -32,17 +32,6 @@
clock-frequency = <21600>;
};
- nand-controller@70008000 {
- nvidia,wp-gpios = <&gpio 23 0>; /* PC7 */
- nvidia,width = <8>;
- nvidia,timing = <26 100 20 80 20 10 12 10 70>;
-
- nand@0 {
- reg = <0>;
- compatible = "hynix,hy27uf4g2b", "nand-flash";
- };
- };
-
i2c@7000c000 {
status = "disabled";
};
--
1.8.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP (4) boot_params
On Apr 3, 2013, at 10:36 AM, Albert ARIBAUD wrote:
> Hi Michael,
>
> On Wed, 3 Apr 2013 09:45:19 -0400, Michael Cashwell
> wrote:
>
>> I've never understood why this is useful. [...]
>
> ... but apparently you managed to do it, thanks.
With extra effort that could be better applied to other work, but yes. :-)
...Making that:
u32 *boot_params_ptr __attribute__ ((section(".data")));
>>
>> Yes, that was my thinking too. Surely clearing data after code has set
>> it can't be right.
>
> With all due respect, the documentation can with greater legitimately
> turn your admonition around and ask that you please refrain from
> setting BSS or data variables when the C runtime environment has not
> been set. :)
>
> IOW, what is wrong here is writing to a BSS variable before you're
> allowed to as per the rules under which your code is running.
I think we're in agreement, but it's not my code doing it. The code,
as it exists in mainline is writing early to space in bss. My change
avoids that by moving the variable from the default bss to data:
diff --git a/common/spl/spl.c b/common/spl/spl.c
index 6715e0d..1d84535
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -42,7 +42,7 @@ DECLARE_GLOBAL_DATA_PTR;
#define CONFIG_SYS_MONITOR_LEN (200 * 1024)
#endif
-u32 *boot_params_ptr = NULL;
+u32 *boot_params_ptr __attribute__ ((section(".data")));
struct spl_image_info spl_image;
/* Define board data structure */
>> OK, here we have an unfortunate name overloading. The boot_params here
>> is specifically an OMAP handoff from the CPU's internal boot ROM to SPL
>> and then from SPL to u-boot. (The same code paths are involved.) It's
>> totally unrelated to the the boot_params passed to the Linux kernel.
>>
>> Since it's confusing maybe a renaming is called for as well.
>
> Indeed. Plus, if it is shared data, it should definitely be mapped at a
> fixed memory location or copied from stage to stage (the latter only if
> the former is impossible)
Yes, I'm exploring that now. The differences between SPL and U-boot are
subtle.
Best regards,
-Mike
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] i.MX6: mx6qsabrelite: README: don't pass chip-select to sf probe command
On 04/03/2013 07:49 AM, Stefano Babic wrote:
On 03/04/2013 16:11, Eric Nelson wrote:
On 04/03/2013 03:13 AM, Stefano Babic wrote:
On 03/04/2013 11:50, Javier Martinez Canillas wrote:
Just for curiosity, in which configuration file did you see that? When
I had the issue I looked at
include/configs/{mx6qsabrelite,mx6_common}.h and
board/freescale/mx6qsabrelite/mx6qsabrelite.c but I didn't find what
chip-select was supposed to be used.
include/configs/mx6qsabrelite.h:
#define CONFIG_SF_DEFAULT_CS (0|(IMX_GPIO_NR(3, 19)<<8))
It should be 0x7300
0x5300?
(((3-1)*32)+19)<<8
Right, forget to subtract 1.
I only remember this because I typed it in **many** times
before adding the default ;)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v11 2/2] Enable btrfs support in mx53loco config
Hi
On 02/04/13 18:03, Tom Rini wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/02/2013 11:52 AM, Robert Nelson wrote:
On Tue, Apr 2, 2013 at 10:38 AM, Adnan Ali
wrote:
On 02/04/13 16:19, Robert Nelson wrote:
On Tue, Apr 2, 2013 at 9:17 AM, Adnan Ali
wrote:
Enable btrfs support in mx53loco config
Signed-off-by: Adnan Ali ---
include/configs/mx53loco.h |4 +++- 1 file changed, 3
insertions(+), 1 deletion(-)
diff --git a/include/configs/mx53loco.h
b/include/configs/mx53loco.h index a4b610f..62e9a76 100644
--- a/include/configs/mx53loco.h +++
b/include/configs/mx53loco.h @@ -56,6 +56,8 @@ #define
CONFIG_GENERIC_MMC #define CONFIG_CMD_FAT #define
CONFIG_CMD_EXT2 +#define CONFIG_CMD_BTR +#define
CONFIG_CMD_FS_GENERIC #define CONFIG_DOS_PARTITION
/* Eth Configs */ @@ -128,7 +130,7 @@ "mmcroot=/dev/mmcblk0p3
rw rootwait\0" \ "mmcargs=setenv bootargs
console=ttymxc0,${baudrate} root=${mmcroot}\0" \
"loadbootscript=" \ - "fatload mmc
${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \ +
"btrload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0"
\
Instead of changing this to btrload for everyone, wouldn't it
make more sense to use the generic "load" command? As your
already setting "CONFIG_CMD_FS_GENERIC"
Well idea of adding that was to enable btrfs and to show its
associated commands. Yes you can use generic 'load' command.
Defaults was using fatload so i change it to btrload.
That's perfectly fine for showing the btrfs command's as an RFC
patch, but if this was heading for mainline as-is, it would be nice
to use the "load" command instead of moving from one partition
format that's been default for a couple years to a new format with
less users. (not that I don't like the btrfs format. ;) as i've
been running it on a few omap boards for a couple years now..)
Exactly. The code needs to be built somewhere, to not be considered
dead code. The next change here, to loadbootscript needs to be done
in a forward-compatible way like 'load' so now it just works for
everyone. Thanks!
- --
Don't know whether you have read my previous mail or not.
What i meant was that you can review the patch v11 and i will send the
mx53loco_config with that change later.
Thanks
Adnan Ali
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mmc: don't allow extra cmdline arguments
On Mon, Apr 01, 2013 at 11:50:28AM -, Stephen Warren wrote: > From: Stephen Warren > > The "mmc rescan" command takes no arguments. However, executing > "mmc rescan 1" succeeds, leading the user to believe that MMC device 1 > has been rescanned. In fact, the "current" MMC device has been > rescanned, and the current device may well not be 1. Add error-checking > to the "mmc" command to explicitly reject any extra command-line > arguments so that it's more obvious when U-Boot isn't doing what the > user thought they asked it to. > > Signed-off-by: Stephen Warren 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] replace last __bss_end__ occurrences with __bss_end
On Sat, Mar 30, 2013 at 12:19:53AM -, Albert ARIBAUD wrote: > Simon Glass' commit 3929fb0a141530551b3fce15ee08629f80d5ef2a, > which changed all occurrences of __bss__end__ into __bss_end, > left behind some untouched __bss_end__ occurrences in all 33 > u-boot.lds.debug files, in board/mousse/u-boot.lds.ram and > in board/mousse/u-boot.lds.rom. These are replaced here. > > Signed-off-by: Albert ARIBAUD 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] [U-Boot, V2] disk: fix unaligned access in efi partitions
On Fri, Mar 29, 2013 at 07:57:10AM -, Marc Dietrich wrote: > start_sect is not aligned to a 4 byte boundary thus causing exceptions > on ARM platforms. Access this field via the get_unaligned_le32 macro. > > Signed-off-by: Marc Dietrich 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] [U-Boot, V2] README: document the requirements for CONFIG_SYS_HZ
On Wed, Mar 27, 2013 at 05:06:41PM -, Stephen Warren wrote: > CONFIG_SYS_HZ must be 1000, and get_timer() must therefore return ms. > Document this. > > README text provided by Tom Rini. > > Signed-off-by: Stephen Warren 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] build: Fix make errors generated when building 'distclean'
On Wed, Mar 27, 2013 at 02:34:18PM -, Vadim Bendebury wrote: > It was noticed that when `make distclean' is run, the make process > terminates with error reporting something like: > > rm: cannot remove '/tmp/foobar/': Is a directory > make: *** [clobber] Error 1 > > The problem is that the list of files targeted for removal includes a > directory in case CONFIG_SPL_TARGET is not set. > > The fix has been tested as follows: > > Ran several times the following sequence of commands: > > CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- make O=/tmp/foobar > smdk5250_config > CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- make O=/tmp/foobar distclean > > it did not cause an error, it used to before this change. > > Signed-off-by: Vadim Bendebury > Acked-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
Re: [U-Boot] env: fix potential stack overflow in environment functions
On Fri, Mar 22, 2013 at 11:26:21AM -, Rob Herring wrote: > From: Rob Herring > > Most of the various environment functions create CONFIG_ENV_SIZE buffers on > the stack. At least on ARM and PPC which have 4KB stacks, this can overflow > the stack if we have large environment sizes. So move all the buffers off > the stack to static buffers. > > Signed-off-by: Rob Herring 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] MAKEALL: Fix case substitution for old bash
On Fri, Mar 22, 2013 at 07:37:03AM -, York Sun wrote: > Bash ver 3.x doesn't support the parameter expansion with case > substitution. Use tr instead. > > Signed-off-by: York Sun > Acked-by: Allen Martin 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] [U-Boot, v2] dts/Makefile: Build the user specified dts
On Thu, Feb 28, 2013 at 10:20:18AM -, Jagannadha Sutradharudu Teki wrote: > This patch provides a support to build the user specified dts. > > Signed-off-by: Jagannadha Sutradharudu Teki > Acked-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
Re: [U-Boot] biosemu: include header
On Mon, Apr 01, 2013 at 10:14:14PM -, Linus Walleij wrote: > This makes sure we have inline functions such as inb/outb that > are used in these two files by including the arch-specific > header. However the ARM version does not provide the > accessors unless the config symbol __io is also defined so add > that in front of the include. > > After this the bios emulator will compile on ARM systems. > > Signed-off-by: Linus Walleij 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] OMAP (4) boot_params
Hi Michael,
On Wed, 3 Apr 2013 10:59:23 -0400, Michael Cashwell
wrote:
> ...Making that:
>
> u32 *boot_params_ptr __attribute__ ((section(".data")));
> >>
> >> Yes, that was my thinking too. Surely clearing data after code has set
> >> it can't be right.
> >
> > With all due respect, the documentation can with greater legitimately
> > turn your admonition around and ask that you please refrain from
> > setting BSS or data variables when the C runtime environment has not
> > been set. :)
> >
> > IOW, what is wrong here is writing to a BSS variable before you're
> > allowed to as per the rules under which your code is running.
>
> I think we're in agreement, but it's not my code doing it. The code,
> as it exists in mainline is writing early to space in bss. My change
> avoids that by moving the variable from the default bss to data:
... except, as I said above, at this point your code should not write at
all, be int in BSS or data, until the C environment is set up. So...
> diff --git a/common/spl/spl.c b/common/spl/spl.c
> index 6715e0d..1d84535
> --- a/common/spl/spl.c
> +++ b/common/spl/spl.c
> @@ -42,7 +42,7 @@ DECLARE_GLOBAL_DATA_PTR;
> #define CONFIG_SYS_MONITOR_LEN (200 * 1024)
> #endif
>
> -u32 *boot_params_ptr = NULL;
> +u32 *boot_params_ptr __attribute__ ((section(".data")));
> struct spl_image_info spl_image;
... NAK. Place this in a fixed section that you'll map somewhere else
then in BSS or data.
Also: in the future, avoid pasting a diff directly in a mail to the
u-boot list if it is not a real patch submission, as our patchwork
instance at (http://patchwork.ozlabs.org/project/uboot/list/) will get
confused and record your mail as a legitimate patch.
> /* Define board data structure */
>
> >> OK, here we have an unfortunate name overloading. The boot_params here
> >> is specifically an OMAP handoff from the CPU's internal boot ROM to SPL
> >> and then from SPL to u-boot. (The same code paths are involved.) It's
> >> totally unrelated to the the boot_params passed to the Linux kernel.
> >>
> >> Since it's confusing maybe a renaming is called for as well.
> >
> > Indeed. Plus, if it is shared data, it should definitely be mapped at a
> > fixed memory location or copied from stage to stage (the latter only if
> > the former is impossible)
>
> Yes, I'm exploring that now. The differences between SPL and U-boot are
> subtle.
Actually not that subtle once you get the hang of it: SPL and U-Boot
are built on the same code base; SPL is the minimal, non-interactive,
early boot stage which can be loaded and run by ROM code, while U-Boot
is the full-featured, interactive, too big to boot directly, stage,
which SPL can chain into.
> Best regards,
> -Mike
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] biosemu: include header
On Tue, Apr 02, 2013 at 12:32:40PM +0200, Albert ARIBAUD wrote: > Hi Linus, > > On Tue, 2 Apr 2013 12:09:21 +0200, Linus Walleij > wrote: > > > On Tue, Apr 2, 2013 at 10:56 AM, Albert ARIBAUD > > wrote: > > > > > NAK -- no ARM target needs bios emulation, so basing the #define on ARM > > > requirements is incorrect. > > > > > > Actually, ARM targets build drivers/bios_emulator/libatibiosemu.o as > > > the result of an overlook in ./Makefile where this object is compiled > > > unconditionally. > > > > > > A git grep CONFIG_BIOSEMU seems to indicate only a handful of PowerPC > > > targets need bios emulation; I suggest doing a V2 of this patch > > > where the object is built only for PowerPC, and the #define is removed. > > > > So the patch was initiated by the discussion here: > > http://marc.info/?l=linux-arm-kernel&m=136399798826572&w=2 > > > > I am looking into getting biosemu up on ARM for the PCI-equipped > > ARM boards, but admittedly I have no idea where it'll go. > > > > But this can surely wait until I have a series that can be run as well. > > Indeed: when some real ARM target needs biosemu, then yes, this patch > will make sense as part of the series that introduces this target. Grr, I missed this discussion, sorry. But I don't feel this falls into the "no dead code" rule, but does fall into the "lets not make life too hard for others" rule I have at least. There's at least one board in u-boot-arm now (ti814x) which can get PCI turned on, with further work, and another that was posted recently (ti816x), and more coming down the pipe. And also what Linus has access to. -- 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] PPC4XX Custom Board - Failing to read I2C
Thanks Stefan, great suggestion, I failed to copy those configurations into
my original message.
/*---
* DDR SDRAM
*--*/
#if !defined(CONFIG_NAND_U_BOOT)
#define CONFIG_SPD_EEPROM 1 /* Use SPD
EEPROM for setup */
#define CONFIG_DDR_ECC 1 /* with ECC
support */
/* SPD i2c spd addresses */
#define SPD_EEPROM_ADDRESS {IIC0_DIMM0_ADDR}
#define IIC0_DIMM0_ADDR 0x50
#define IIC0_DIMM1_ADDR 0x52
I am questioning my bus configurations... I haven't hooked up the scope yet,
but I don't think data is hitting the bus. I don't see any areas to
configure the I2C bus besides the board configuration file. Any suggestions?
--
View this message in context:
http://u-boot.10912.n7.nabble.com/PPC4XX-Custom-Board-Failing-to-read-I2C-tp151298p151427.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Unable to build u-boot for Marvell Aspenite board
Hi all, I want to build U-Boot 2013.01.01 for my PXA168 evaluation board, called Aspenite. I have seen that this board is already supported by U-Boot. For the compilation, I use the cross-compiler submitted by Marvell : arm-marvell-linux-gnueabi-gcc 4.2.0. To compile U-Boot, I have used following commands (my OS is Ubuntu 12.04.2 LTS): make CROSS_COMPILE=/usr/local/arm-marvell-linux-gnueabi/bin/arm-marvell-linux-gnueabi- ARCH=arm aspenite_config make CROSS_COMPILE=/usr/local/arm-marvell-linux-gnueabi/bin/arm-marvell-linux-gnueabi- ARCH=arm After seconds, compilation ends with following errors: /usr/local/arm-marvell-linux-gnueabi/bin/arm-marvell-linux-gnueabi-ld: section .bss [00619c58 -> 006201fb] overlaps section .rel.dyn [00619c58 -> 0061cd77] /usr/local/arm-marvell-linux-gnueabi/bin/arm-marvell-linux-gnueabi-ld: section .dynsym [0061cd78 -> 0061ce77] overlaps section .bss [00619c58 -> 006201fb] /usr/local/arm-marvell-linux-gnueabi/bin/arm-marvell-linux-gnueabi-ld: u-boot: section .bss lma 0x619c58 overlaps previous sections make: *** [u-boot] Erreur 1 I don't understand those error messages, I don't know what I do wrong. I have found another board with PXA168 which is supported by U-Boot. This board is called dplugd, so I have tried to compile it: First, I cleared the last settings: make CROSS_COMPILE=/usr/local/arm-marvell-linux-gnueabi/bin/arm-marvell-linux-gnueabi- ARCH=arm mrproper then I configure U-Boot for the GPLUGD board make CROSS_COMPILE=/usr/local/arm-marvell-linux-gnueabi/bin/arm-marvell-linux-gnueabi- ARCH=arm gplugd_config And finally start the compilation make CROSS_COMPILE=/usr/local/arm-marvell-linux-gnueabi/bin/arm-marvell-linux-gnueabi- ARCH=arm After some seconds, the compilation is finished without any error ! I don't understand why the compilation works for the DPLUGD Board and not for the Aspenite Board. Most of the files are common. Can someone please help me to resolve this issue? Best regards Fabrice Mousset ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP (4) boot_params
On Wed, Apr 03, 2013 at 05:34:18PM +0200, Albert ARIBAUD wrote:
> Hi Michael,
>
> On Wed, 3 Apr 2013 10:59:23 -0400, Michael Cashwell
> wrote:
>
> > ...Making that:
> >
> > u32 *boot_params_ptr __attribute__ ((section(".data")));
> > >>
> > >> Yes, that was my thinking too. Surely clearing data after code has set
> > >> it can't be right.
> > >
> > > With all due respect, the documentation can with greater legitimately
> > > turn your admonition around and ask that you please refrain from
> > > setting BSS or data variables when the C runtime environment has not
> > > been set. :)
> > >
> > > IOW, what is wrong here is writing to a BSS variable before you're
> > > allowed to as per the rules under which your code is running.
> >
> > I think we're in agreement, but it's not my code doing it. The code,
> > as it exists in mainline is writing early to space in bss. My change
> > avoids that by moving the variable from the default bss to data:
>
> ... except, as I said above, at this point your code should not write at
> all, be int in BSS or data, until the C environment is set up. So...
But we have to save this ROM-passed information before we overwrite it
ourselves (by accident or purpose).
>
> > diff --git a/common/spl/spl.c b/common/spl/spl.c
> > index 6715e0d..1d84535
> > --- a/common/spl/spl.c
> > +++ b/common/spl/spl.c
> > @@ -42,7 +42,7 @@ DECLARE_GLOBAL_DATA_PTR;
> > #define CONFIG_SYS_MONITOR_LEN (200 * 1024)
> > #endif
> >
> > -u32 *boot_params_ptr = NULL;
> > +u32 *boot_params_ptr __attribute__ ((section(".data")));
> > struct spl_image_info spl_image;
>
> ... NAK. Place this in a fixed section that you'll map somewhere else
> then in BSS or data.
>
> Also: in the future, avoid pasting a diff directly in a mail to the
> u-boot list if it is not a real patch submission, as our patchwork
> instance at (http://patchwork.ozlabs.org/project/uboot/list/) will get
> confused and record your mail as a legitimate patch.
>
> > /* Define board data structure */
> >
> > >> OK, here we have an unfortunate name overloading. The boot_params here
> > >> is specifically an OMAP handoff from the CPU's internal boot ROM to SPL
> > >> and then from SPL to u-boot. (The same code paths are involved.) It's
> > >> totally unrelated to the the boot_params passed to the Linux kernel.
> > >>
> > >> Since it's confusing maybe a renaming is called for as well.
> > >
> > > Indeed. Plus, if it is shared data, it should definitely be mapped at a
> > > fixed memory location or copied from stage to stage (the latter only if
> > > the former is impossible)
> >
> > Yes, I'm exploring that now. The differences between SPL and U-boot are
> > subtle.
>
> Actually not that subtle once you get the hang of it: SPL and U-Boot
> are built on the same code base; SPL is the minimal, non-interactive,
> early boot stage which can be loaded and run by ROM code, while U-Boot
> is the full-featured, interactive, too big to boot directly, stage,
> which SPL can chain into.
Part of the confusion here is that I think some TI-isms didn't get
removed from the general code. jump_to_image_no_args() does not in fact
jump to an image without passing any arguments. It jumps to an image
passing an argument of where we may have saved some previously passed
paramters (in this case, the format the TI's ROM has defined for a
while). We also _may_ be in U-Boot without SPL having been run because
U-Boot was given a config header instead.
But I think, and need to re-read this thread a bit more, part of the
solution is to rename jump_to_image_no_args as jump_to_image_uboot, keep
it __weak and provide one that deals with this (and perhaps more cleanly
deals with VIRTIO/ZEBU image_entry). And after that we can talk about
moving things that can't be in the BSS out of the data section and into
another section.
--
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 v11 1/2] Introduced btrfs file-system with btrload command
On Tue, Apr 02, 2013 at 03:17:38PM +0100, Adnan Ali wrote: > Introduces btrfs file-system to read file from > volume/sub-volumes with btrload command. This > implementation has read-only support. > This btrfs implementation is based on syslinux btrfs > code, commit 269ebc845ebc8b46ef4b0be7fa0005c7fdb95b8d. > > v11: Mirro super block check. > v10: patch problem reworked. > v5: merged with master. > v4: btrls command added. > > Signed-off-by: Adnan Ali With ELDK 5.3 toolchain, I see: btrfs.c: In function 'insert_map': btrfs.c:144:4: warning: implicit declaration of function 'malloc' [-Wimplicit-function-declaration] btrfs.c: In function 'btrfs_read_super_block': btrfs.c:281:5: warning: unused variable 'boots' [-Wunused-variable] btrfs.c:279:6: warning: unused variable 'ret' [-Wunused-variable] btrfs.c: In function 'btrfs_read_chunk_tree': btrfs.c:507:4: warning: format '%d' expects argument of type 'int', but argument 2 has type 'uint64_t' [-Wformat] btrfs.c:503:6: warning: unused variable 'status' [-Wunused-variable] btrfs.c: In function 'btrfs_iget_by_inr': btrfs.c:563:24: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] btrfs.c:583:26: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] btrfs.c:591:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] btrfs.c: In function 'btrfs_iget': btrfs.c:607:26: warning: initialization from incompatible pointer type [enabled by default] btrfs.c:621:22: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] btrfs.c: In function 'btrfs_readlink': btrfs.c:628:34: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] btrfs.c:629:21: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] btrfs.c: In function 'btrfs_readdir': btrfs.c:637:26: warning: initialization from incompatible pointer type [enabled by default] btrfs.c: In function 'btrfs_next_extent': btrfs.c:682:26: warning: initialization from incompatible pointer type [enabled by default] btrfs.c:695:25: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] btrfs.c:720:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] btrfs.c: In function 'btrfs_getfssec': btrfs.c:729:26: warning: initialization from incompatible pointer type [enabled by default] btrfs.c:730:12: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] btrfs.c:741:8: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] btrfs.c:729:21: warning: unused variable 'fs' [-Wunused-variable] btrfs.c: In function 'put_inode': btrfs.c:844:4: warning: implicit declaration of function 'free' [-Wimplicit-function-declaration] btrfs.c: In function 'alloc_inode': btrfs.c:854:24: warning: initialization makes pointer from integer without a cast [enabled by default] btrfs.c:857:13: warning: assignment from incompatible pointer type [enabled by default] btrfs.c: In function 'btrfs_open_file': btrfs.c:952:2: warning: implicit declaration of function 'searchdir' [-Wimplicit-function-declaration] btrfs.c: In function 'searchdir': btrfs.c:1029:14: warning: assignment makes pointer from integer without a cast [enabled by default] btrfs.c:1058:17: warning: pointer targets in assignment differ in signedness [-Wpointer-sign] btrfs.c: In function 'getfssec': btrfs.c:1114:11: warning: unused variable 'handle' [-Wunused-variable] btrfs.c: In function 'generic_getfssec': btrfs.c:1132:26: warning: initialization from incompatible pointer type [enabled by default] btrfs.c:1132:21: warning: unused variable 'fs' [-Wunused-variable] fs.c:97:3: warning: initialization from incompatible pointer type [enabled by default] fs.c:97:3: warning: (near initialization for 'fstypes[2].ls') [enabled by default] And with ELDK 4.2: btrfs.c: In function 'insert_map': btrfs.c:144: warning: implicit declaration of function 'malloc' btrfs.c: In function 'btrfs_read_super_block': btrfs.c:281: warning: unused variable 'boots' btrfs.c:279: warning: unused variable 'ret' btrfs.c: In function 'btrfs_read_chunk_tree': btrfs.c:507: warning: format '%d' expects type 'int', but argument 2 has type 'uint64_t' btrfs.c:503: warning: unused variable 'status' btrfs.c: In function 'btrfs_iget': btrfs.c:607: warning: initialization from incompatible pointer type btrfs.c: In function 'btrfs_readdir': btrfs.c:637: warning: initialization from incompatible pointer type btrfs.c: In function 'btrfs_next_extent': btrfs.c:682: warning: initialization from incompatible pointer type btrfs.c: In function 'btrfs_getfssec': btrfs.c:729: warning: initialization from incompatible pointer type btrfs.c:729: warning: unused variable 'fs' btrfs.c: In function '
Re: [U-Boot] [PATCH] spi: mxc_spi: Fix ECSPI reset handling
Am 03.04.2013 11:12, schrieb Stefano Babic: On 21/03/2013 09:03, Dirk Behme wrote: Reviewing the ECSPI reset handling shows two issues: Hi Dirk, agree completely, only a very minor question.. + + reg_ctrl = reg_read(®s->ctrl); As you says, it makes no sense to read back the value of the register, also because reg_ctrl is overwritten some lines later ;-) Hmm, sorry if I overlooked something, but we have to initialize the variable 'reg_ctrl' with the recent register content because it is first used and _then_ overwritten in the next step: reg_ctrl = (reg_ctrl & ~MXC_CSPICTRL_SELCHAN(3)) | MXC_CSPICTRL_SELCHAN(cs); http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=drivers/spi/mxc_spi.c;h=d792d8d493c13c475ec8ca03694f4efd8fde0e7f;hb=HEAD#l170 (?) Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] biosemu: include header
On Wed, Apr 3, 2013 at 6:02 PM, Tom Rini wrote: > Grr, I missed this discussion, sorry. But I don't feel this falls into > the "no dead code" rule, but does fall into the "lets not make life too > hard for others" rule I have at least. There's at least one board in > u-boot-arm now (ti814x) which can get PCI turned on, with further work, > and another that was posted recently (ti816x), and more coming down the > pipe. And also what Linus has access to. Yes the Integrator has PCI support since ages, and I do have a VGA card mounted in one of the slots ... the only issue is that I need biosemu to be working to initialize it. More people will run into the same issue definately, especially with ARM servers and such things using PCI starting to appear. Yours, Linus Walleij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] PPC4XX Custom Board - Failing to read I2C
On 03.04.2013 18:15, txcotrader wrote:
> Thanks Stefan, great suggestion, I failed to copy those configurations into
> my original message.
>
> /*---
> * DDR SDRAM
> *--*/
> #if !defined(CONFIG_NAND_U_BOOT)
> #define CONFIG_SPD_EEPROM 1 /* Use SPD
> EEPROM for setup */
> #define CONFIG_DDR_ECC 1 /* with ECC
> support */
>
> /* SPD i2c spd addresses */
> #define SPD_EEPROM_ADDRESS {IIC0_DIMM0_ADDR}
> #define IIC0_DIMM0_ADDR 0x50
> #define IIC0_DIMM1_ADDR 0x52
>
> I am questioning my bus configurations... I haven't hooked up the scope yet,
> but I don't think data is hitting the bus. I don't see any areas to
> configure the I2C bus besides the board configuration file. Any suggestions?
Are you sure that 0x50 is correct? I suggest you try this instead:
#define SPD_EEPROM_ADDRESS { IIC0_DIMM0_ADDR, IIC0_DIMM1_ADDR }
Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Tegra: All Tamonten-derived boards use onboard NAND
On 04/03/2013 08:52 AM, Thierry Reding wrote: > Move the nand-controller node to the tegra20-tamonten.dtsi so that it > can be shared between all derived boards. The series, Reviewed-by: Stephen Warren ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] PPC4XX Custom Board - Failing to read I2C
After hooking the DIMM's I2C up to the o-scope, I don't see a clock signal. The board will boot with a u-boot version from 2007. Have you ever come across a missing I2C clock? -- View this message in context: http://u-boot.10912.n7.nabble.com/PPC4XX-Custom-Board-Failing-to-read-I2C-tp151298p151435.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v11 1/2] Introduced btrfs file-system with btrload command
On 03/04/13 17:50, Tom Rini wrote: On Tue, Apr 02, 2013 at 03:17:38PM +0100, Adnan Ali wrote: Introduces btrfs file-system to read file from volume/sub-volumes with btrload command. This implementation has read-only support. This btrfs implementation is based on syslinux btrfs code, commit 269ebc845ebc8b46ef4b0be7fa0005c7fdb95b8d. v11: Mirro super block check. v10: patch problem reworked. v5: merged with master. v4: btrls command added. Signed-off-by: Adnan Ali With ELDK 5.3 toolchain, I see: btrfs.c: In function 'insert_map': btrfs.c:144:4: warning: implicit declaration of function 'malloc' [-Wimplicit-function-declaration] btrfs.c: In function 'btrfs_read_super_block': btrfs.c:281:5: warning: unused variable 'boots' [-Wunused-variable] btrfs.c:279:6: warning: unused variable 'ret' [-Wunused-variable] btrfs.c: In function 'btrfs_read_chunk_tree': btrfs.c:507:4: warning: format '%d' expects argument of type 'int', but argument 2 has type 'uint64_t' [-Wformat] btrfs.c:503:6: warning: unused variable 'status' [-Wunused-variable] btrfs.c: In function 'btrfs_iget_by_inr': btrfs.c:563:24: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] btrfs.c:583:26: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] btrfs.c:591:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] btrfs.c: In function 'btrfs_iget': btrfs.c:607:26: warning: initialization from incompatible pointer type [enabled by default] btrfs.c:621:22: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] btrfs.c: In function 'btrfs_readlink': btrfs.c:628:34: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] btrfs.c:629:21: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] btrfs.c: In function 'btrfs_readdir': btrfs.c:637:26: warning: initialization from incompatible pointer type [enabled by default] btrfs.c: In function 'btrfs_next_extent': btrfs.c:682:26: warning: initialization from incompatible pointer type [enabled by default] btrfs.c:695:25: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] btrfs.c:720:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] btrfs.c: In function 'btrfs_getfssec': btrfs.c:729:26: warning: initialization from incompatible pointer type [enabled by default] btrfs.c:730:12: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] btrfs.c:741:8: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] btrfs.c:729:21: warning: unused variable 'fs' [-Wunused-variable] btrfs.c: In function 'put_inode': btrfs.c:844:4: warning: implicit declaration of function 'free' [-Wimplicit-function-declaration] btrfs.c: In function 'alloc_inode': btrfs.c:854:24: warning: initialization makes pointer from integer without a cast [enabled by default] btrfs.c:857:13: warning: assignment from incompatible pointer type [enabled by default] btrfs.c: In function 'btrfs_open_file': btrfs.c:952:2: warning: implicit declaration of function 'searchdir' [-Wimplicit-function-declaration] btrfs.c: In function 'searchdir': btrfs.c:1029:14: warning: assignment makes pointer from integer without a cast [enabled by default] btrfs.c:1058:17: warning: pointer targets in assignment differ in signedness [-Wpointer-sign] btrfs.c: In function 'getfssec': btrfs.c:1114:11: warning: unused variable 'handle' [-Wunused-variable] btrfs.c: In function 'generic_getfssec': btrfs.c:1132:26: warning: initialization from incompatible pointer type [enabled by default] btrfs.c:1132:21: warning: unused variable 'fs' [-Wunused-variable] fs.c:97:3: warning: initialization from incompatible pointer type [enabled by default] fs.c:97:3: warning: (near initialization for 'fstypes[2].ls') [enabled by default] And with ELDK 4.2: btrfs.c: In function 'insert_map': btrfs.c:144: warning: implicit declaration of function 'malloc' btrfs.c: In function 'btrfs_read_super_block': btrfs.c:281: warning: unused variable 'boots' btrfs.c:279: warning: unused variable 'ret' btrfs.c: In function 'btrfs_read_chunk_tree': btrfs.c:507: warning: format '%d' expects type 'int', but argument 2 has type 'uint64_t' btrfs.c:503: warning: unused variable 'status' btrfs.c: In function 'btrfs_iget': btrfs.c:607: warning: initialization from incompatible pointer type btrfs.c: In function 'btrfs_readdir': btrfs.c:637: warning: initialization from incompatible pointer type btrfs.c: In function 'btrfs_next_extent': btrfs.c:682: warning: initialization from incompatible pointer type btrfs.c: In function 'btrfs_getfssec': btrfs.c:729: warning: initialization from incompatible pointer type btrfs.c:729: warning: unused variable 'fs' btrfs.
Re: [U-Boot] [PATCH] mx6: fsl_esdhc: Fix waiting for DMA operation completion
> From: Eric Nelson [eric.nel...@boundarydevices.com]
> Sent: Wednesday, April 03, 2013 17:38
> To: Gabbasov, Andrew
> Cc: u-boot@lists.denx.de; Behme, Dirk - Bosch
> Subject: Re: [U-Boot] [PATCH] mx6: fsl_esdhc: Fix waiting for DMA operation
> completion
>
> Hi Andrew,
>
> On 04/02/2013 11:48 PM, Gabbasov, Andrew wrote:
>
> On 04/02/2013 03:04 AM, Andrew Gabbasov wrote:
> > On iMX6 sometimes the Transfer Complete interrupt occurs earlier
> > than the DMA part completes its operation. If immediately after that
> > the read data is used for some data verification, those obtained data
> > may be incomplete, which causes intermittent verification failures.
> >
>
> Can you describe how to repeat this?
>
> > For example, when the default environment command tries to load and run
> > boot script from FAT partition on SD/MMC card, it sometimes fails,
> > reporting invalid partition table, or unknown partition type, or
> > something else of that kind. Such errors disappear if the build
> > configuration has CONFIG_SYS_FSL_ESDHC_USE_PIO, or if some delay
> > is added after transfer completion.
> >
> >>>
> >>
> >>
> >>
> >> Looking at the code with fresh eyes, it appears that
> >> the cache invalidate is in the wrong place (after
> >> "command complete" but before "transfer complete"
> >> is checked).
> >>
> >>
> >>
> >> Andrew, can you test with this patch to see if
> >> it also addresses the issue?
> >>
> > Hi Eric,
> >
> > Yes, this patch seems to fix the issue too.
> >
>
> Thanks for testing.
>
> > I think, it would be useful to have both patches. Although invalidating
> > cache
> > (by adding some delay) indirectly helps with waiting for DMA End event,
> > it is probably worth having explicit DMA completion waiting patch too.
> >
> I agree wholeheartedly.
>
> I do wonder if the previous loop should be re-worked though.
> It seems that we should be waiting for TC & (DINT|DMAE) on
> all processor variants and the previous loop has tests for
> timeout and data errors.
>
> Regards,
>
> Eric
Hi Eric,
Do you mean making it something like
do {
irqstat = esdhc_read32(®s->irqstat);
if (irqstat & IRQSTAT_DTOE)
return TIMEOUT;
if (irqstat & (DATA_ERR | IRQSTAT_DMAE))
return COMM_ERR;
} while (!((irqstat & IRQSTAT_TC) && (irqstat & IRQSTAT_DINT)) &&
(esdhc_read32(®s->prsstat) & PRSSTAT_DLA));
The check for DMAE (DMA Error) can be combined with other data errors
and cause exit from the loop. And DINT can be checked with TC in the loop
condition.
Actually, I'm a little confused by PRSSTAT_DLA checking: currently the loop
exits
when either IRQSTAT_TC occurs _or_ PRSSTAT_DLA flag comes to 0. Is that correct?
I'm not quite familiar with using this flag, but should the loop exit when both
IRQSTAT_TC occurs _and_ PRSSTAT_DLA flag comes to 0 (i.e. in current code '&&'
should be replaced by '||')? And then the modified loop condition (with DMA
check)
would be
} while (!(irqstat & IRQSTAT_TC) || !(irqstat & IRQSTAT_DINT) ||
(esdhc_read32(®s->prsstat) & PRSSTAT_DLA));
Can you advise anything on using this flag?
Thanks.
Best regards,
Andrew
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] PPC4XX Custom Board - Failing to read I2C
Hi, On Wed, 3 Apr 2013 10:29:00 -0700 (PDT) txcotrader wrote: > After hooking the DIMM's I2C up to the o-scope, I don't see a clock signal. > The board will boot with a u-boot version from 2007. Have you ever come > across a missing I2C clock? How many I2C busses are actually used on your board ? On which bus is the SPD EEPROM ? If it is on a I2C bus other than 0, then you have to use #define CONFIG_SYS_SPD_BUS_NUM in the board config file. HTH, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v11 1/2] Introduced btrfs file-system with btrload command
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/03/2013 01:30 PM, Adnan Ali wrote: > On 03/04/13 17:50, Tom Rini wrote: >> On Tue, Apr 02, 2013 at 03:17:38PM +0100, Adnan Ali wrote: >> >>> Introduces btrfs file-system to read file from >>> volume/sub-volumes with btrload command. This implementation >>> has read-only support. This btrfs implementation is based on >>> syslinux btrfs code, commit >>> 269ebc845ebc8b46ef4b0be7fa0005c7fdb95b8d. >>> >>> v11: Mirro super block check. v10: patch problem >>> reworked. v5: merged with master. v4: btrls command >>> added. >>> >>> Signed-off-by: Adnan Ali >> With ELDK 5.3 toolchain, I see: btrfs.c: In function >> 'insert_map': btrfs.c:144:4: warning: implicit declaration of >> function 'malloc' [-Wimplicit-function-declaration] btrfs.c: In >> function 'btrfs_read_super_block': btrfs.c:281:5: warning: unused >> variable 'boots' [-Wunused-variable] btrfs.c:279:6: warning: >> unused variable 'ret' [-Wunused-variable] btrfs.c: In function >> 'btrfs_read_chunk_tree': btrfs.c:507:4: warning: format '%d' >> expects argument of type 'int', but argument 2 has type >> 'uint64_t' [-Wformat] btrfs.c:503:6: warning: unused variable >> 'status' [-Wunused-variable] btrfs.c: In function >> 'btrfs_iget_by_inr': btrfs.c:563:24: warning: dereferencing >> type-punned pointer will break strict-aliasing rules >> [-Wstrict-aliasing] btrfs.c:583:26: warning: dereferencing >> type-punned pointer will break strict-aliasing rules >> [-Wstrict-aliasing] btrfs.c:591:3: warning: dereferencing >> type-punned pointer will break strict-aliasing rules >> [-Wstrict-aliasing] btrfs.c: In function 'btrfs_iget': >> btrfs.c:607:26: warning: initialization from incompatible pointer >> type [enabled by default] btrfs.c:621:22: warning: dereferencing >> type-punned pointer will break strict-aliasing rules >> [-Wstrict-aliasing] btrfs.c: In function 'btrfs_readlink': >> btrfs.c:628:34: warning: dereferencing type-punned pointer will >> break strict-aliasing rules [-Wstrict-aliasing] btrfs.c:629:21: >> warning: dereferencing type-punned pointer will break >> strict-aliasing rules [-Wstrict-aliasing] btrfs.c: In function >> 'btrfs_readdir': btrfs.c:637:26: warning: initialization from >> incompatible pointer type [enabled by default] btrfs.c: In >> function 'btrfs_next_extent': btrfs.c:682:26: warning: >> initialization from incompatible pointer type [enabled by >> default] btrfs.c:695:25: warning: dereferencing type-punned >> pointer will break strict-aliasing rules [-Wstrict-aliasing] >> btrfs.c:720:2: warning: dereferencing type-punned pointer will >> break strict-aliasing rules [-Wstrict-aliasing] btrfs.c: In >> function 'btrfs_getfssec': btrfs.c:729:26: warning: >> initialization from incompatible pointer type [enabled by >> default] btrfs.c:730:12: warning: dereferencing type-punned >> pointer will break strict-aliasing rules [-Wstrict-aliasing] >> btrfs.c:741:8: warning: dereferencing type-punned pointer will >> break strict-aliasing rules [-Wstrict-aliasing] btrfs.c:729:21: >> warning: unused variable 'fs' [-Wunused-variable] btrfs.c: In >> function 'put_inode': btrfs.c:844:4: warning: implicit >> declaration of function 'free' [-Wimplicit-function-declaration] >> btrfs.c: In function 'alloc_inode': btrfs.c:854:24: warning: >> initialization makes pointer from integer without a cast [enabled >> by default] btrfs.c:857:13: warning: assignment from incompatible >> pointer type [enabled by default] btrfs.c: In function >> 'btrfs_open_file': btrfs.c:952:2: warning: implicit declaration >> of function 'searchdir' [-Wimplicit-function-declaration] >> btrfs.c: In function 'searchdir': btrfs.c:1029:14: warning: >> assignment makes pointer from integer without a cast [enabled by >> default] btrfs.c:1058:17: warning: pointer targets in assignment >> differ in signedness [-Wpointer-sign] btrfs.c: In function >> 'getfssec': btrfs.c:1114:11: warning: unused variable 'handle' >> [-Wunused-variable] btrfs.c: In function 'generic_getfssec': >> btrfs.c:1132:26: warning: initialization from incompatible >> pointer type [enabled by default] btrfs.c:1132:21: warning: >> unused variable 'fs' [-Wunused-variable] fs.c:97:3: warning: >> initialization from incompatible pointer type [enabled by >> default] fs.c:97:3: warning: (near initialization for >> 'fstypes[2].ls') [enabled by default] >> >> And with ELDK 4.2: btrfs.c: In function 'insert_map': >> btrfs.c:144: warning: implicit declaration of function 'malloc' >> btrfs.c: In function 'btrfs_read_super_block': btrfs.c:281: >> warning: unused variable 'boots' btrfs.c:279: warning: unused >> variable 'ret' btrfs.c: In function 'btrfs_read_chunk_tree': >> btrfs.c:507: warning: format '%d' expects type 'int', but >> argument 2 has type 'uint64_t' btrfs.c:503: warning: unused >> variable 'status' btrfs.c: In function 'btrfs_iget': btrfs.c:607: >> warning: initialization from incompatible pointer type btrfs.c: >> In function 'btrfs_readdir':
Re: [U-Boot] [PATCH v2] mmc: Split device init to decouple OCR-polling delay
Hi Andy, On Sat, Mar 16, 2013 at 1:35 PM, Simon Glass wrote: > Hi Andy, > > On Tue, Feb 12, 2013 at 7:14 PM, Jaehoon Chung > wrote: > > Hi Simon, > > > > It looks good to me. > > > > Acked-by: Jaehoon Chung > > Do you think this will be picked up this time around? > ping? Any thoughts on this one please? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] am335x: Enable MMC1 clock
We must not assume ROM has enabled the clock for MMC1. Reported-by: Koen Kooi Signed-off-by: Tom Rini --- arch/arm/cpu/armv7/am33xx/clock_am33xx.c |5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/cpu/armv7/am33xx/clock_am33xx.c b/arch/arm/cpu/armv7/am33xx/clock_am33xx.c index afc0d92..a1efc75 100644 --- a/arch/arm/cpu/armv7/am33xx/clock_am33xx.c +++ b/arch/arm/cpu/armv7/am33xx/clock_am33xx.c @@ -195,6 +195,11 @@ static void enable_per_clocks(void) while (readl(&cmper->mmc0clkctrl) != PRCM_MOD_EN) ; + /* MMC1 */ + writel(PRCM_MOD_EN, &cmper->mmc1clkctrl); + while (readl(&cmper->mmc1clkctrl) != PRCM_MOD_EN) + ; + /* i2c0 */ writel(PRCM_MOD_EN, &cmwkup->wkup_i2c0ctrl); while (readl(&cmwkup->wkup_i2c0ctrl) != PRCM_MOD_EN) -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mmc: Define a constant for the maximum block size
The number 512 appears quite a bit in the mmc code. Add a constant for this
so that it can be used here and in other parts of the code (e.g. SPL code
which loads from mmc).
Signed-off-by: Simon Glass
Reviewed-by: Vadim Bendebury
---
drivers/mmc/mmc.c | 25 +
include/mmc.h | 3 +++
2 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 109a8b8..39e58b5 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -623,7 +623,7 @@ static int mmc_send_ext_csd(struct mmc *mmc, u8 *ext_csd)
data.dest = (char *)ext_csd;
data.blocks = 1;
- data.blocksize = 512;
+ data.blocksize = MMC_MAX_BLOCK_LEN;
data.flags = MMC_DATA_READ;
err = mmc_send_cmd(mmc, &cmd, &data);
@@ -656,7 +656,7 @@ static int mmc_switch(struct mmc *mmc, u8 set, u8 index, u8
value)
static int mmc_change_freq(struct mmc *mmc)
{
- ALLOC_CACHE_ALIGN_BUFFER(u8, ext_csd, 512);
+ ALLOC_CACHE_ALIGN_BUFFER(u8, ext_csd, MMC_MAX_BLOCK_LEN);
char cardtype;
int err;
@@ -919,8 +919,8 @@ static int mmc_startup(struct mmc *mmc)
uint mult, freq;
u64 cmult, csize, capacity;
struct mmc_cmd cmd;
- ALLOC_CACHE_ALIGN_BUFFER(u8, ext_csd, 512);
- ALLOC_CACHE_ALIGN_BUFFER(u8, test_csd, 512);
+ ALLOC_CACHE_ALIGN_BUFFER(u8, ext_csd, MMC_MAX_BLOCK_LEN);
+ ALLOC_CACHE_ALIGN_BUFFER(u8, test_csd, MMC_MAX_BLOCK_LEN);
int timeout = 1000;
#ifdef CONFIG_MMC_SPI_CRC_ON
@@ -1036,11 +1036,11 @@ static int mmc_startup(struct mmc *mmc)
mmc->capacity = (csize + 1) << (cmult + 2);
mmc->capacity *= mmc->read_bl_len;
- if (mmc->read_bl_len > 512)
- mmc->read_bl_len = 512;
+ if (mmc->read_bl_len > MMC_MAX_BLOCK_LEN)
+ mmc->read_bl_len = MMC_MAX_BLOCK_LEN;
- if (mmc->write_bl_len > 512)
- mmc->write_bl_len = 512;
+ if (mmc->write_bl_len > MMC_MAX_BLOCK_LEN)
+ mmc->write_bl_len = MMC_MAX_BLOCK_LEN;
/* Select the card, and put it into Transfer Mode */
if (!mmc_host_is_spi(mmc)) { /* cmd not supported in spi */
@@ -1071,7 +1071,7 @@ static int mmc_startup(struct mmc *mmc)
| ext_csd[EXT_CSD_SEC_CNT + 1] << 8
| ext_csd[EXT_CSD_SEC_CNT + 2] << 16
| ext_csd[EXT_CSD_SEC_CNT + 3] << 24;
- capacity *= 512;
+ capacity *= MMC_MAX_BLOCK_LEN;
if ((capacity >> 20) > 2 * 1024)
mmc->capacity = capacity;
}
@@ -1081,10 +1081,11 @@ static int mmc_startup(struct mmc *mmc)
* group size from ext_csd directly, or calculate
* the group size from the csd value.
*/
- if (ext_csd[EXT_CSD_ERASE_GROUP_DEF])
+ if (ext_csd[EXT_CSD_ERASE_GROUP_DEF]) {
mmc->erase_grp_size =
- ext_csd[EXT_CSD_HC_ERASE_GRP_SIZE] * 512 * 1024;
- else {
+ ext_csd[EXT_CSD_HC_ERASE_GRP_SIZE] *
+ MMC_MAX_BLOCK_LEN * 1024;
+ } else {
int erase_gsz, erase_gmul;
erase_gsz = (mmc->csd[2] & 0x7c00) >> 10;
erase_gmul = (mmc->csd[2] & 0x03e0) >> 5;
diff --git a/include/mmc.h b/include/mmc.h
index cd5ad67..1490204 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -202,6 +202,9 @@
#define PART_ACCESS_MASK (0x7)
#define PART_SUPPORT (0x1)
+/* Maximum block size for MMC */
+#define MMC_MAX_BLOCK_LEN 512
+
struct mmc_cid {
unsigned long psn;
unsigned short oid;
--
1.8.1.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
