Re: [U-Boot] U-boot and JFFS2
Pillai, Manikandan said the following on 03/16/2009 01:35 PM: > Hi, > > On the OMAP3 EVM board, I have four partition on my Onenand flash of which > /dev/mtd4 is a JFFS2 partition. > > After booting up linux, I use the following command to mount the jffs2 empty > partition. > > Linux#> mount -t jffs2 /dev/mtdblock4 /mnt > > Then I do a reboot . > > When u-boot boots up it gives bad erase block for all the blocks used by > /dev/mtd4. > > The reason is the JFFS2 filesystem is putting some signature at location 0x0 > and 0x1 of OOB locations > of every block. > > Is there a way this can be avoided ? > > A) mount -t jffs2 /dev/mtdblock4 /mnt umount /mnt sync reboot this gives the garbage collector time to put the cleanmarkers in place. B) is the kernel's oob layout and ECC strategy (h/w vs s/w ecc) same as that used for u-boot? Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot and JFFS2
Pillai, Manikandan said the following on 03/16/2009 01:41 PM: > The cleanmarkers are being written in location 0x0 and 0x1 of the OOB space > And they are the problem since when u-boot comes up it does a scan and decided > That since these OOB locations do not contain 0xff, the blocks are bad. > offset 0 and 1 in a x16 large page micron device is reserved for badblock marker - u-boot is checking the correct location and if those locations dont have 0xff, it is noted as bad blocks. if cleanmarker is being written there, you'd need to fix the kernel board file etc.. Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot and JFFS2
Pillai, Manikandan said the following on 03/17/2009 06:41 AM: > with u-boot as far as I can see but on the other hand the clean markers > are also supposed to be in the same location. > Why do you say that? ooblayout free is used if I am not wrong to store cleanmarkers. have you compared the layouts of the kernel Vs u-boot? if there is a delta, I suppose a good idea is to fix the kernel board file (we've had more than enough oob discussions for omap3 gpmc i suppose on u-boot ml ;) ).. > I am not clear on the other part of the answer. Do you mean to say I need to > fix the kernel code for cleanmarker issue ? Is it like I can give an offset > for the > Cleanmarker to be written ? > I believe you can, essentially coz you can choose where the ecc region is, jffs2 should store cleanmarkers in free area. Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Build breaks on some OMAP3 configs
On Fri, Oct 30, 2009 at 6:47 PM, Dirk Behme wrote: > Gadiyar, Anand wrote: >> Hi, >> >> I was trying to build u-boot for omap3_3430sdp and >> omap3_zoom2, and the build fails with the error below. >> >> I'm on commit f2b4bc0 from the master branch. I'm >> using CodeSourcery's 2008q3 toolchain. >> The commands I ran were: >> >> make CROSS_COMPILE=arm-none-linux-gnueabi- omap3_3430sdp_config; make >> CROSS_COMPILE=arm-none-linux-gnueabi- >> >> Any ideas what I'm doing wrong? > > Not really. Maybe tool chain version? But most probably not... [...] could you point which tree you are working on? Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Build breaks on some OMAP3 configs
Gadiyar, Anand said the following on 10/30/2009 06:54 PM: >> Hi, >> >> I was trying to build u-boot for omap3_3430sdp and >> omap3_zoom2, and the build fails with the error below. >> >> I'm on commit f2b4bc0 from the master branch. I'm >> using CodeSourcery's 2008q3 toolchain. >> The commands I ran were: >> >> make CROSS_COMPILE=arm-none-linux-gnueabi- >> omap3_3430sdp_config; make CROSS_COMPILE=arm-none-linux-gnueabi- >> >> Any ideas what I'm doing wrong? >> >> make -C examples/standalone all >> make[1]: Entering directory `/data/git/denx-uboot/u-boot/examples/standalone' >> arm-none-linux-gnueabi-gcc -g -Os -fno-common -ffixed-r8 -msoft-float >> -D__KERNEL__ -DTEXT_BASE=0x80e8 -I/data/git/denx-uboot/u-boot/include >> -fno-builtin -ffreestanding -nostdinc -isystem >> /data/arm-2008q3/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.2/include -pipe >> -DCONFIG_ARM -D__ARM__ -marm -mabi=aapcs-linux -mno-thumb-interwork >> -march=armv5 -Wall -Wstrict-prototypes -fno-stack-protector -g -Os >> -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ -DTEXT_BASE=0x80e8 >> -I/data/git/denx-uboot/u-boot/include -fno-builtin -ffreestanding -nostdinc >> -isystem >> /data/arm-2008q3/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.2/include -pipe >> -DCONFIG_ARM -D__ARM__ -marm -mabi=aapcs-linux -mno-thumb-interwork >> -march=armv5 -I.. -Bstatic -T u-boot.lds -Ttext 0x80e8 -o .c >> arm-none-linux-gnueabi-gcc: no input files >> make[1]: *** [.c] Error 1 >> make[1]: Leaving directory `/data/git/denx-uboot/u-boot/examples/standalone' >> make: *** [examples/standalone] Error 2 >> > > > I took a look at examples/standalone/Makefile: > > The patch below gets things going again. So looks like something > clobbered $(ELF-y). Any ideas what it could be? > > Thanks in advance, > Anand > > diff --git a/examples/standalone/Makefile b/examples/standalone/Makefile > index 5e2f2bc..73b19e9 100644 > --- a/examples/standalone/Makefile > +++ b/examples/standalone/Makefile > @@ -39,6 +39,7 @@ ELF-ppc += sched > ELF-oxc += eepro100_eeprom > > ELF := $(ELF-y) $(ELF-$(ARCH)) $(ELF-$(BOARD)) $(ELF-$(CPU)) > +ELF := hello_world > SREC = $(addsuffix .srec,$(ELF)) > BIN = $(addsuffix .bin,$(ELF)) > The build command i use is this: alias mymake='make ARCH=ARM CROSS_COMPILE=arm-none-linux-gnueabi- V=1 -j2' though on a fresh clone, I seem to have run into a wierd issue -> MAKEALL seems to build things fine, but if I: mymake distclean rm -rvf * git reset --hard mymake omap3_sdp3430_config mymake [] arm-none-linux-gnueabi-gcc -g -Os -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ -DTEXT_BASE=0x80e8 -I/home/nmenon/Src/r/x/u-boot/include -fno-builtin -ffreestanding -nostdinc -isystem /home/opt/tools/arm-2009q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/include -pipe -march=armv5 -Wall -Wstrict-prototypes -fno-stack-protector -o hello_world.o hello_world.c -c In file included from /home/nmenon/Src/r/x/u-boot/include/common.h:113, from hello_world.c:24: /home/nmenon/Src/r/x/u-boot/include/image.h:507:3: error: #error Unknown CPU type for some wierd reason, it does not seem to take the include/config.mk file (where the defines are present).. now, if i do a local clone of the cloned directory, it builds just fine! gotta dig at it a little more.. Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Build breaks on some OMAP3 configs
Wolfgang Denk said the following on 10/30/2009 11:35 PM: > Dear Nishanth Menon, > > In message <4aeb4dc5.9040...@gmail.com> you wrote: > >> for some wierd reason, it does not seem to take the include/config.mk >> file (where the defines are present).. >> >> now, if i do a local clone of the cloned directory, it builds just fine! >> gotta dig at it a little more.. >> > > Maybe some files have been stored on or transferred through a Windoze > system which messed up the line endings with CR-LF sequences? > > Nope, I cloned(the direct clone from git.denx) direct to my linux laptop - amd64, dual core ubuntu 9.10. Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mkconfig: deny messed up ARCH definition
Refuse to setup a platform if the command
line ARCH= is not the same as the one
required for the board. This prevents
any user with prehistoric aliases from
messing up thier builds
Reported in thread:
http://old.nabble.com/-U-Boot--Build-breaks-on-some-OMAP3-configs-to26132721.html
Signed-off-by: Nishanth Menon
---
mkconfig |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/mkconfig b/mkconfig
index 4c5675b..87ac6d4 100755
--- a/mkconfig
+++ b/mkconfig
@@ -27,6 +27,11 @@ done
[ $# -lt 4 ] && exit 1
[ $# -gt 6 ] && exit 1
+if [ ! -z "$ARCH" -a "$ARCH" != "$2" ]; then
+ echo "ARCH=$ARCH while ${BOARD_NAME} arch=$2: fail"
+ exit 1
+fi
+
echo "Configuring for ${BOARD_NAME} board..."
#
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] mkconfig: deny messed up ARCH definition
Refuse to setup a platform if the command line ARCH= is not the same
as the one required for the board. This prevents any user with
prehistoric aliases from messing up their builds.
Reported in thread:
http://old.nabble.com/-U-Boot--Build-breaks-on-some-OMAP3-configs-to26132721.html
Inputs from: Mike Frysinger and Wolfgang Denk:
http://lists.denx.de/pipermail/u-boot/2009-November/063642.html
Cc: Wolfgang Denk
Cc: Mike Frysinger
Cc: Anand Gadiyar
Cc: Dirk Behme
Signed-off-by: Nishanth Menon
---
mkconfig |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/mkconfig b/mkconfig
index 4c5675b..1075510 100755
--- a/mkconfig
+++ b/mkconfig
@@ -27,6 +27,11 @@ done
[ $# -lt 4 ] && exit 1
[ $# -gt 6 ] && exit 1
+if [ "${ARCH}" -a "${ARCH}" != "$2" ]; then
+ echo "Failed: \$ARCH=${ARCH}, should be '$2' for ${BOARD_NAME}" 1>&2
+ exit 1
+fi
+
echo "Configuring for ${BOARD_NAME} board..."
#
--
1.6.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap3: allow slection of NAND GPMC settings based on board config
On Sun, Nov 15, 2009 at 10:36 AM, Tom wrote:
> Mike Rapoport wrote:
>> Any comments on this?
>>
>
> This is a good idea but..
>
> These defines are used in the TI codebase but
> it doesn't look like the samsung nand is used here.
>
> As a test I removed the samsung defines
> and reran MAKEALL arm.
> No failures.
> Also grepping the code shows that it isn't used.
>
> Do you plan on using the samsung nand ?
SDP3430 uses Samsung NAND.
>
> If not, I think a better patch would be to remove the smnand defines.
NAK.
>
> Also I think the nand and onnand initialization could be generalized. You
> may want to look at that.
>
> Thanks
> Tom
>
>> Mike Rapoport wrote:
>>> There are several presets for GPMC registers defined in
>>> include/asm-arm/arch-omap3/mem.h. Allow selection between SMNAND and
>>> M_NAND presets based on OMAP34XX_GPMC_NAND_ defines
>>>
>>> Signed-off-by: Mike Rapoport
>>> ---
>>> cpu/arm_cortexa8/omap3/mem.c | 25 -
>>> 1 files changed, 16 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/cpu/arm_cortexa8/omap3/mem.c b/cpu/arm_cortexa8/omap3/mem.c
>>> index 8b8cd6d..2bd7e1c 100644
>>> --- a/cpu/arm_cortexa8/omap3/mem.c
>>> +++ b/cpu/arm_cortexa8/omap3/mem.c
>>> @@ -44,14 +44,21 @@ volatile unsigned int boot_flash_env_addr;
>>> struct gpmc *gpmc_cfg;
>>>
>>> #if defined(CONFIG_CMD_NAND)
>>> -static const u32 gpmc_m_nand[GPMC_MAX_REG] = {
>>> - M_NAND_GPMC_CONFIG1,
>>> - M_NAND_GPMC_CONFIG2,
>>> - M_NAND_GPMC_CONFIG3,
>>> - M_NAND_GPMC_CONFIG4,
>>> - M_NAND_GPMC_CONFIG5,
>>> - M_NAND_GPMC_CONFIG6, 0
>>> -};
>>> +#define GPMC_NAND(PART) \
>>> + static const u32 gpmc_nand[GPMC_MAX_REG] = { \
>>> + PART##_GPMC_CONFIG1, \
>>> + PART##_GPMC_CONFIG2, \
>>> + PART##_GPMC_CONFIG3, \
>>> + PART##_GPMC_CONFIG4, \
>>> + PART##_GPMC_CONFIG5, \
>>> + PART##_GPMC_CONFIG6, 0 \
This is completely unnecessary implementation IMHO, where required,
the board files can register
their own NAND device timings on a need basis.
NOTE: timing values change based on L3 clk -> e..g 3630 means that ALL
the above timing values
are invalid as L3 is at 200Mhz!
>>> + };
>>> +
>>> +#ifdef OMAP34XX_GPMC_NAND_SMNAND
>>> +GPMC_NAND(SMNAND)
>>> +#else
>>> +GPMC_NAND(M_NAND)
>>> +#endif
>>>
>>> #if defined(CONFIG_ENV_IS_IN_NAND)
>>> #define GPMC_CS 0
>>> @@ -246,7 +253,7 @@ void gpmc_init(void)
>>> sdelay(1000);
>>>
>>> #if defined(CONFIG_CMD_NAND) /* CS 0 */
>>> - gpmc_config = gpmc_m_nand;
>>> + gpmc_config = gpmc_nand;
>>>
>>> base = PISMO1_NAND_BASE;
>>> size = PISMO1_NAND_SIZE;
>>
IMHO, NAK.
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TFTP on beagle board
On Tue, Nov 17, 2009 at 12:36 AM, Dirk Behme wrote: > Mai Daftedar wrote: >> >> Hi all, >> I was wondering how can we configure the u-boot with the TFTP >> capability on the beagle board at runtime.. > > For this you will need ethernet support in U-Boot. There are two (?) options > to achieve this: Add support for USB ethernet dongle in U-Boot or use a > Beagle expansion card with ethernet. > > Regarding USB ethernet dongle, there are some basic USB patches for Beagle > U-Boot on the list. But I'm not sure how much work it is to enable them to > support USB ethernet. > > For ethernet on expansion board, there is TinCanTool's Zippy board [1]. To > access ethernet on this board from U-Boot, an U-Boot OMAP3 SPI driver is > missing. > > Both options are not ready, yet, and need some development work. Any help is > greatly appreciated! A third option might be to support RNDIS or CDC usb gadget support and use the usb port with beagle.. tom might be able to comment better. > > Cheers > > Dirk > > Btw.: I added U-Boot list, it is the better place to discuss this. > > [1] > http://www.tincantools.com/product.php?productid=16147&cat=0&page=1&featured > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3EVM: Added NAND support
On Wed, Nov 18, 2009 at 12:58 AM, wrote:
> From: Vaibhav Hiremath
>
> User can now choose between NAND and ONENAND support in omap3_evm.h
>
> Signed-off-by: Vaibhav Hiremath
> ---
> include/configs/omap3_evm.h | 27 ++-
> 1 files changed, 26 insertions(+), 1 deletions(-)
>
> diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h
> index a5514ae..3434306 100644
> --- a/include/configs/omap3_evm.h
> +++ b/include/configs/omap3_evm.h
> @@ -110,7 +110,8 @@
>
> #define CONFIG_CMD_I2C /* I2C serial bus support */
> #define CONFIG_CMD_MMC /* MMC support */
> -#define CONFIG_CMD_ONENAND /* ONENAND support */
> +/*#define CONFIG_CMD_ONENAND*/ /* ONENAND support */
do you wish to use #undef instead of commented code? also adding a
comment on top saying this is an option might help..
This patch opens up a chain for me: how do we have the same build of
u-boot boot accross nand, onenand, mmc type devices?
current u-boot looks constrainted in that respect.
> +#define CONFIG_CMD_NAND /* NAND support */
> #define CONFIG_CMD_DHCP
> #define CONFIG_CMD_PING
>
> @@ -141,6 +142,7 @@
> /* to access */
> /* nand at CS0 */
>
> +
> #define CONFIG_SYS_MAX_NAND_DEVICE 1 /* Max number of */
> /* NAND devices */
> #define CONFIG_SYS_64BIT_VSPRINTF /* needed for nand_util.c */
> @@ -268,7 +270,13 @@
> #define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_FLASH_BASE
> #define CONFIG_SYS_ONENAND_BASE ONENAND_MAP
>
> +#if defined(CONFIG_CMD_NAND)
> +#define CONFIG_NAND_OMAP_GPMC
> +#define GPMC_NAND_ECC_LP_x16_LAYOUT 1
> +#define CONFIG_ENV_IS_IN_NAND 1
> +#elif defined(CONFIG_CMD_ONENAND)
> #define CONFIG_ENV_IS_IN_ONENAND 1
> +#endif
what if a user decided to enable NAND and ONENAND?
> #define ONENAND_ENV_OFFSET 0x26 /* environment starts here */
> #define SMNAND_ENV_OFFSET 0x26 /* environment starts here */
>
> @@ -300,6 +308,23 @@ extern unsigned int boot_flash_sec;
> extern unsigned int boot_flash_type;
> #endif
>
> +
> +#define WRITE_NAND_COMMAND(d, adr)\
> + writel(d, &nand_cs_base->nand_cmd)
writel? i thought u had 16 bit nand device.
> +#define WRITE_NAND_ADDRESS(d, adr)\
> + writel(d, &nand_cs_base->nand_adr)
> +#define WRITE_NAND(d, adr) writew(d, &nand_cs_base->nand_dat)
> +#define READ_NAND(adr) readl(&nand_cs_base->nand_dat)
readl?? should'nt you be using readw?
Why these functions? does'nt mtd layer handle this? look at beagle ->
it does not use that..
> +
> +/* Other NAND Access APIs */
> +#define NAND_WP_OFF() do {readl(&gpmc_cfg_base->config) |= GPMC_CONFIG_WP; }
> \
> + while (0)
> +#define NAND_WP_ON() do {readl(&gpmc_cfg_base->config) &= ~GPMC_CONFIG_WP; }
> \
> + while (0)
> +#define NAND_DISABLE_CE(nand)
> +#define NAND_ENABLE_CE(nand)
> +#define NAND_WAIT_READY(nand) udelay(10)
> +
are these really needed?
> /*
> * SMSC9115 Ethernet from SMSC9118 family
> *
> --
> 1.6.2.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] BeagleBoard: Add a comment explaining the use of "OMAP34XX" macros.
2009/11/19 Måns Rullgård : > "Robert P. J. Day" writes: > >> Make it clear to a reader that the user of OMAP34XX macros in the >> (OMAP 3530-based) beagle config file is just fine. >> >> Signed-off-by: Robert P. J. Day >> >> --- >> >> i'll let dirk be the judge as to whether this is worth adding, or if >> he'd prefer a different phrasing. >> >> diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h >> index 19a5ec9..9a03587 100644 >> --- a/include/configs/omap3_beagle.h >> +++ b/include/configs/omap3_beagle.h >> @@ -30,6 +30,9 @@ >> >> /* >> * High Level Configuration Options >> + * >> + * Note that, although the BeagleBoard incorporates an OMAP 3530, >> + * it's currently still valid to use OMAP34XX preprocessor values. >> */ >> #define CONFIG_ARMCORTEXA8 1 /* This is an ARM V7 CPU core */ >> #define CONFIG_OMAP 1 /* in a TI OMAP core */ > > Since 34xx and 35xx are in fact exactly the same silicon, saying it is > "currently" valid seems a bit odd. This sort of implies a planned > change. > I agree - I do not think there are any such plans. NAK to the patch. Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] LAN91C96: Enable NET_MULTI LAN driver
Ben Warren had written, on 12/07/2009 03:09 PM, the following: > Nishanth, > > Nishanth Menon wrote: >> This modification is NOT tested on any of the >> platforms modified as I dont have them. please >> help by testing+building+fixing >> >> Signed-off-by: Nishanth Menon >> Cc: Andrea Scian >> Cc: Ben Warren >> Cc: Dave Peverley >> Cc: George G. Davis >> Cc: Kyungmin Park >> Cc: Nishant Kamat >> Cc: Richard Woodruff >> Cc: Rishi Bhattacharya >> Cc: Sandeep Paulraj >> --- >> board/apollon/apollon.c | 12 +++- >> include/configs/B2.h |2 +- >> include/configs/apollon.h |3 ++- >> include/configs/assabet.h |3 ++- >> include/configs/gcplus.h |3 ++- >> include/configs/lubbock.h |3 ++- >> include/configs/omap1510inn.h |3 ++- >> include/configs/omap1610h2.h |3 ++- >> include/configs/omap1610inn.h |3 ++- >> include/configs/omap2420h4.h |3 ++- >> include/configs/omap5912osk.h |3 ++- >> include/configs/omap730p2.h |3 ++- >> include/configs/pleb2.h |6 -- >> 13 files changed, 32 insertions(+), 18 deletions(-) >> > You've update the config files for a bunch of boards, but have not added > board_eth_init() functions for them. Am I missing something? If this > is indeed the case, I can't push these patches upstream from the net > tree because the associated boards will break. I have added the init where they have been previously used for the old lan91c96 driver. I think the only one which was actively using it was apollon, which means the rest of the platforms probably dont use the old lan driver properly in the first place. I have maintained status quo there instead of introducing a change which may break them. -- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TI:OMAP: [ PATCH 2/4 ] Configure PRCM registers to support 720 Mhz
On Tue, Jan 5, 2010 at 10:11 AM, Khasim Syed Mohammed
wrote:
> From 1bb1a2441e6f54f3fe7d71e30da3bc22732aa7d3 Mon Sep 17 00:00:00 2001
> From: Syed Mohammed Khasim
> Date: Tue, 5 Jan 2010 20:28:01 +0530
> Subject: [PATCH] Configure PRCM registers to support 720 Mhz on Beagle
> REV C4 and Latest OMAP3530 ES version
watch the subject length ;)..
>
no commit message?
Why do you need to bump up to 720Mhz in u-boot? can't you do that as
part of dvfs in kernel? wont that be better? can't you do a standard
boot or is this device never capable of OPP3?
> Signed-off-by: Syed Mohammed Khasim
> ---
> board/ti/beagle/beagle.c | 9 +++--
> cpu/arm_cortexa8/omap3/clock.c | 22 ++
> drivers/power/twl4030.c | 21 +
> 3 files changed, 50 insertions(+), 2 deletions(-)
>
> diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
> index 17840cf..d76df30 100644
> --- a/board/ti/beagle/beagle.c
> +++ b/board/ti/beagle/beagle.c
> @@ -122,9 +122,16 @@ int misc_init_r(void)
> struct gpio *gpio5_base = (struct gpio *)OMAP34XX_GPIO5_BASE;
> struct gpio *gpio6_base = (struct gpio *)OMAP34XX_GPIO6_BASE;
>
> + beagle_identify();
> +
> twl4030_power_init();
> twl4030_led_init();
>
> + if (beagle_revision == REVISION_C4) {
> + twl4030_power_init_es3_720();
> + prcm_config_720mhz();
> + }
> +
> /* Configure GPIOs to output */
> writel(~(GPIO23 | GPIO10 | GPIO8 | GPIO2 | GPIO1), &gpio6_base->oe);
> writel(~(GPIO31 | GPIO30 | GPIO29 | GPIO28 | GPIO22 | GPIO21 |
> @@ -136,8 +143,6 @@ int misc_init_r(void)
> writel(GPIO31 | GPIO30 | GPIO29 | GPIO28 | GPIO22 | GPIO21 |
> GPIO15 | GPIO14 | GPIO13 | GPIO12, &gpio5_base->setdataout);
>
> - beagle_identify();
> -
> dieid_num_r();
>
> return 0;
> diff --git a/cpu/arm_cortexa8/omap3/clock.c b/cpu/arm_cortexa8/omap3/clock.c
> index 174c453..ab96a46 100644
> --- a/cpu/arm_cortexa8/omap3/clock.c
> +++ b/cpu/arm_cortexa8/omap3/clock.c
> @@ -402,3 +402,25 @@ void per_clocks_enable(void)
>
> sdelay(1000);
> }
> +
> +/*
> + * Configure PRCM registers to get 720 Mhz
> + *
> + * NOTE: N value doesn't change, only M gets affected
> + */
> +
unwanted EOL?
> +void prcm_config_720mhz (void)
you are assuming 3430 ONLY support here, how abt 3630 and family?
> +{
> + struct prcm *prcm_base = (struct prcm *)PRCM_BASE;
> +
> + /* Unlock MPU DPLL (slows things down, and needed later) */
> + sr32(&prcm_base->clken_pll_mpu, 0, 3, PLL_LOW_POWER_BYPASS);
> + wait_on_value(ST_MPU_CLK, 0, &prcm_base->idlest_pll_mpu, LDELAY);
> +
> + /* Set M */
> + sr32(&prcm_base->clksel1_pll_mpu, 8, 11, 0x2D0);
> +
> + /* lock mode */
> + sr32(&prcm_base->clken_pll_mpu, 0, 3, PLL_LOCK);
> + wait_on_value(ST_MPU_CLK, 1, &prcm_base->idlest_pll_mpu, LDELAY);
> +}
> diff --git a/drivers/power/twl4030.c b/drivers/power/twl4030.c
> index eb066cb..fa1c7d5 100644
> --- a/drivers/power/twl4030.c
> +++ b/drivers/power/twl4030.c
> @@ -68,6 +68,8 @@ void twl4030_power_reset_init(void)
> #define DEV_GRP_ALL 0xE0
> #define VPLL2_VSEL_18 0x05
> #define VDAC_VSEL_18 0x03
> +#define VAUX2_VSEL_18 0x05
> +#define VDD1_VSEL_14 0x40
>
> void twl4030_power_init(void)
> {
> @@ -113,3 +115,22 @@ void twl4030_power_mmc_init(void)
> twl4030_i2c_write_u8(TWL4030_CHIP_PM_RECEIVER, byte,
> TWL4030_PM_RECEIVER_VMMC1_DEDICATED);
> }
> +
> +void twl4030_power_init_es3_720(void)
naming is confusing - is it 4030 or 3530 ES you are trying to describe here?
> +{
> + unsigned char byte;
> +
> + /* VAUX2 needs to be 1.8v */
> + byte = DEV_GRP_P1;
> + twl4030_i2c_write_u8(TWL4030_CHIP_PM_RECEIVER, byte,
> + TWL4030_PM_RECEIVER_VAUX2_DEV_GRP);
> +
> + byte = VAUX2_VSEL_18;
> + twl4030_i2c_write_u8(TWL4030_CHIP_PM_RECEIVER, byte,
> + TWL4030_PM_RECEIVER_VAUX2_DEDICATED);
> +
> + /* Put VSEL for VDD1 to 1.4v to get 720Mhz */
> + byte = VDD1_VSEL_14;
> + twl4030_i2c_write_u8(TWL4030_CHIP_PM_RECEIVER, byte,
> + TWL4030_PM_RECEIVER_VDD1_VSEL);
> +}
huh? you may want to NOT do this, instead introduce a generic voltage
rail API which is called from silicon/board specific file.
> --
> 1.5.6.3
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TI:OMAP: [PATCH 3/4] Configure DSS to enable DVI-D and S-Video
generic DSS driver instead. > + > + > + > + > +/* > * Routine: misc_init_r > * Description: Configure board specific parts > */ > @@ -122,6 +219,7 @@ int misc_init_r(void) > struct gpio *gpio5_base = (struct gpio *)OMAP34XX_GPIO5_BASE; > struct gpio *gpio6_base = (struct gpio *)OMAP34XX_GPIO6_BASE; > > + dss_init(); > beagle_identify(); > > twl4030_power_init(); > @@ -144,6 +242,9 @@ int misc_init_r(void) > GPIO15 | GPIO14 | GPIO13 | GPIO12, &gpio5_base->setdataout); > > dieid_num_r(); > + > + /* Enable DSS */ > + writel(0x0001836b, 0x48050440); board file directly hitting DSS module.. not exactly the reusable type ;).. Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [beagleboard] TI:OMAP: [PATCH 3/4] Support 720Mhz configuration for OMAP35xx
c_write_u8(TWL4030_CHIP_PM_RECEIVER, byte,
> TWL4030_PM_RECEIVER_VMMC1_DEDICATED);
> }
> +
> +/*
> + * Generic function to select Device Group and Voltage
> + */
> +void twl4030_pmrecv_vsel_cfg(u8 vsel_reg, u8 vsel_val,
> + u8 dev_grp, u8 dev_grp_sel)
> +{
> + /* Select the Device Group */
> + twl4030_i2c_write_u8(TWL4030_CHIP_PM_RECEIVER, dev_grp_sel,
> + dev_grp);
> +
> + /* Select the Voltage */
> + twl4030_i2c_write_u8(TWL4030_CHIP_PM_RECEIVER, vsel_val,
> + vsel_reg);
> +}
Assumption that i2c operations work 100% successfully! is'nt serial
bus subject to noise? and cant' i2c ops fail?
> diff --git a/include/twl4030.h b/include/twl4030.h
> index f260ecb..b96c96c 100644
> --- a/include/twl4030.h
> +++ b/include/twl4030.h
> @@ -359,6 +359,22 @@
> #define TWL4030_USB_PHY_DPLL_CLK (1 << 0)
>
> /*
> + * Voltage Selection in PM Receiver Module
> + */
> +#define VAUX2_VSEL_18 0x05
> +#define VDD1_VSEL_14 0x40
> +#define VAUX3_VSEL_28 0x03
> +#define VPLL2_VSEL_18 0x05
> +#define VDAC_VSEL_18 0x03
> +#define VMMC1_VSEL_30 0x02
> +
> +/*
> + * Device Selection
> + */
> +#define DEV_GRP_P1 0x20
> +#define DEV_GRP_ALL 0xE0
> +
> +/*
> * Convience functions to read and write from TWL4030
> *
> * chip_no is the i2c address, it must be one of the chip addresses
> --
> 1.5.6.3
we should try review again after you have split the series up.
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [beagleboard] TI:OMAP: [PATCH 4/4] Minimal Display driver for OMAP3
On Fri, Jan 8, 2010 at 9:40 AM, Khasim Syed Mohammed
wrote:
> From 239c47a4180fb4d5b5217f892955524d476916cf Mon Sep 17 00:00:00 2001
> From: Syed Mohammed Khasim
> Date: Fri, 8 Jan 2010 21:01:44 +0530
> Subject: [PATCH] Minimal Display driver for OMAP3
>
> Supports dynamic configuration of Panel and Video Encoder
> Supports Background color on DVID
> Supports Color bar on S-Video
We are getting there.. thanks a bunch. if you can split this series
into two sets:
a) introducing DSS layer
b) introduce beagle support for the same
it will be better.
but NAK to this patch.
>
> Signed-off-by: Syed Mohammed Khasim
> ---
> board/ti/beagle/beagle.c | 13 +++
> board/ti/beagle/beagle.h | 73 ++
> drivers/video/Makefile | 1 +
> drivers/video/omap3_dss.c | 128 +
> include/asm-arm/arch-omap3/dss.h | 193
> ++
> include/configs/omap3_beagle.h | 1 +
> 6 files changed, 409 insertions(+), 0 deletions(-)
> create mode 100644 drivers/video/omap3_dss.c
> create mode 100644 include/asm-arm/arch-omap3/dss.h
>
[...]
> diff --git a/include/asm-arm/arch-omap3/dss.h
> b/include/asm-arm/arch-omap3/dss.h
> new file mode 100644
> index 000..08c7d8d
> --- /dev/null
> +++ b/include/asm-arm/arch-omap3/dss.h
> @@ -0,0 +1,193 @@
> +/*
> + * (C) Copyright 2010
> + * Texas Instruments,
> + * Syed Mohammed Khasim
> + *
> + * Referred to Linux DSS driver files for OMAP3
> + *
> + * 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's version 2 of
> + * the License.
> + *
> + * 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 DSS_H
> +#define DSS_H
> +
> +/* VENC Register address */
> +#define VENC_REV_ID 0x48050C00
NAK. why do you need this if you have a struct?
here is what I think:
venc_config {
}
if it is organized as the register definitions,
configure_venc(struct venc_config *values)
struct venc_config * d = BASE_ADDRESS_OF_OMAP3_VENC;
writel(values->regx, &d->regx);
refer: drivers/mtd/nand/omap_gpmc.c
> +#define VENC_STATUS 0x48050C04
> +#define VENC_F_CONTROL 0x48050C08
[...]
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [beagleboard] TI:OMAP: [PATCH 4/4] Minimal Display driver for OMAP3
Khasim Syed Mohammed said the following on 01/08/2010 09:00 PM:
> On Sat, Jan 9, 2010 at 1:31 AM, Nishanth Menon
> wrote:
>
>> On Fri, Jan 8, 2010 at 9:40 AM, Khasim Syed Mohammed
>> wrote:
>>
>>> From 239c47a4180fb4d5b5217f892955524d476916cf Mon Sep 17 00:00:00 2001
>>> From: Syed Mohammed Khasim
>>> Date: Fri, 8 Jan 2010 21:01:44 +0530
>>> Subject: [PATCH] Minimal Display driver for OMAP3
>>>
>>> Supports dynamic configuration of Panel and Video Encoder
>>> Supports Background color on DVID
>>> Supports Color bar on S-Video
>>>
>> We are getting there.. thanks a bunch. if you can split this series
>> into two sets:
>> a) introducing DSS layer
>> b) introduce beagle support for the same
>> it will be better.
>>
>
> Can you complete your review review comments here, I will take up this
> when in-corporate all review comments together.
>
>
if you can give it a week before posting again, you could probably
collate comments from various quarters. I just am a part time reviewer ;)..
> Kindly remember these patches will be tested on B4, C2, C3, C4, EVM
> before releasing.
>
great. good to know.
>
>> but NAK to this patch.
>>
>>
>>> Signed-off-by: Syed Mohammed Khasim
>>> ---
>>> board/ti/beagle/beagle.c | 13 +++
>>> board/ti/beagle/beagle.h | 73 ++
>>> drivers/video/Makefile |1 +
>>> drivers/video/omap3_dss.c| 128 +
>>> include/asm-arm/arch-omap3/dss.h | 193
>>> ++
>>> include/configs/omap3_beagle.h |1 +
>>> 6 files changed, 409 insertions(+), 0 deletions(-)
>>> create mode 100644 drivers/video/omap3_dss.c
>>> create mode 100644 include/asm-arm/arch-omap3/dss.h
>>>
>>>
>> [...]
>>
>>> diff --git a/include/asm-arm/arch-omap3/dss.h
>>> b/include/asm-arm/arch-omap3/dss.h
>>> new file mode 100644
>>> index 000..08c7d8d
>>> --- /dev/null
>>> +++ b/include/asm-arm/arch-omap3/dss.h
>>> @@ -0,0 +1,193 @@
>>> +/*
>>> + * (C) Copyright 2010
>>> + * Texas Instruments,
>>> + * Syed Mohammed Khasim
>>> + *
>>> + * Referred to Linux DSS driver files for OMAP3
>>> + *
>>> + * 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's version 2 of
>>> + * the License.
>>> + *
>>> + * 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 DSS_H
>>> +#define DSS_H
>>> +
>>> +/* VENC Register address */
>>> +#define VENC_REV_ID0x48050C00
>>>
>> NAK. why do you need this if you have a struct?
>>
>
> You need to read patch more carefully before giving NAK.
>
> Structure is used to give multiple instance of Panels or different
> VENC settings like NTSC or PAL
>
Thanks for clarifying
That is the crux of the problem. if you use struct to describe the venc
-> then you'd be staying with how the rest of u-boot accesses are:
using struct dereference. if you look at nand.c as I pointed out, Dirk
had done a great job of converting register offsets
to struct and referencing off it. This was required to get the driver
mainlined.
The recomendation here is to move from #defines to struct based register
usage. I am ok with the rest(except for need to split).
> You can add a new panel or a new tv standard with these structures
> easily. Structures are not used for register accesses.
>
>
>> here is what I think:
>> venc_config {
>> }
>>
>> if it is organized as the register definitions,
>>
>> configure_venc(struct venc_config *values)
>> struct venc_config * d = B
Re: [U-Boot] [beagleboard] TI:OMAP: [PATCH 3/4] Support 720Mhz configuration for OMAP35xx
Khasim Syed Mohammed said the following on 01/08/2010 09:21 PM:
> On Sat, Jan 9, 2010 at 1:22 AM, Nishanth Menon
> wrote:
>
>> On Fri, Jan 8, 2010 at 9:40 AM, Khasim Syed Mohammed
>> wrote:
>>
>>> From bba669562fa208d12f4c7cd8188446e8576cd6ee Mon Sep 17 00:00:00 2001
>>> From: Syed Mohammed Khasim
>>> Date: Fri, 8 Jan 2010 20:34:37 +0530
>>> Subject: [PATCH] Support 720Mhz configuration for OMAP35xx
>>>
>>> Adds a new API "twl4030_pmrecv_vsel_cfg" to select voltage and group
>>> Adds support for 720Mhz in clock.c
>>> Board file modified to use these new APIs and boot at 720Mhz
>>>
>> Could you split this into three patches please? easier to track
>> changes at a later date.
>>
>> a) introducing generic voltage setting API for twl
>> b) introduce 720mhz
>> c) beagle support for C4 with 720Mhz.
>>
>>
>>> Signed-off-by: Syed Mohammed Khasim
>>> ---
>>> board/ti/beagle/beagle.c | 20 ++--
>>> cpu/arm_cortexa8/omap3/clock.c | 21 +
>>> drivers/power/twl4030.c| 24 +++-
>>> include/twl4030.h | 16
>>> 4 files changed, 70 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
>>> index 0def5a6..7985ee9 100644
>>> --- a/board/ti/beagle/beagle.c
>>> +++ b/board/ti/beagle/beagle.c
>>> @@ -122,9 +122,27 @@ int misc_init_r(void)
>>>struct gpio *gpio5_base = (struct gpio *)OMAP34XX_GPIO5_BASE;
>>>struct gpio *gpio6_base = (struct gpio *)OMAP34XX_GPIO6_BASE;
>>>
>>> + beagle_identify();
>>> +
>>>
>>>twl4030_power_init();
>>>twl4030_led_init();
>>>
>>> + if (beagle_revision == REVISION_C4) {
>>> +
>>> + /* Select TWL4030 VSEL to support 720Mhz */
>>> + twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VAUX2_DEDICATED,
>>> + VAUX2_VSEL_18,
>>> + TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
>>> + DEV_GRP_P1);
>>> +
>>> + twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VDD1_VSEL,
>>> + VDD1_VSEL_14,
>>> + TWL4030_PM_RECEIVER_VDD1_DEV_GRP,
>>> + DEV_GRP_P1);
>>> +
>>> + prcm_config_720mhz();
>>> + }
>>> +
>>>/* Configure GPIOs to output */
>>>writel(~(GPIO23 | GPIO10 | GPIO8 | GPIO2 | GPIO1), &gpio6_base->oe);
>>>writel(~(GPIO31 | GPIO30 | GPIO29 | GPIO28 | GPIO22 | GPIO21 |
>>> @@ -136,8 +154,6 @@ int misc_init_r(void)
>>>writel(GPIO31 | GPIO30 | GPIO29 | GPIO28 | GPIO22 | GPIO21 |
>>>GPIO15 | GPIO14 | GPIO13 | GPIO12, &gpio5_base->setdataout);
>>>
>>> - beagle_identify();
>>> -
>>>dieid_num_r();
>>>
>>>return 0;
>>> diff --git a/cpu/arm_cortexa8/omap3/clock.c b/cpu/arm_cortexa8/omap3/clock.c
>>> index 174c453..d67517a 100644
>>> --- a/cpu/arm_cortexa8/omap3/clock.c
>>> +++ b/cpu/arm_cortexa8/omap3/clock.c
>>> @@ -402,3 +402,24 @@ void per_clocks_enable(void)
>>>
>>>sdelay(1000);
>>> }
>>> +
>>> +/*
>>> + * Configure PRCM registers to get 720 Mhz
>>> + *
>>> + * NOTE: N value doesn't change, only M gets affected
>>> + */
>>> +void prcm_config_720mhz(void)
>>> +{
>>> + struct prcm *prcm_base = (struct prcm *)PRCM_BASE;
>>> +
>>> + /* Unlock MPU DPLL (slows things down, and needed later) */
>>> + sr32(&prcm_base->clken_pll_mpu, 0, 3, PLL_LOW_POWER_BYPASS);
>>> + wait_on_value(ST_MPU_CLK, 0, &prcm_base->idlest_pll_mpu, LDELAY);
>>> +
>>> + /* Set M */
>>> + sr32(&prcm_base->clksel1_pll_mpu, 8, 11, 0x2D0);
>>> +
>>> + /* lock mode */
>>> + sr32(&prcm_base->clken_pll_mpu, 0, 3, PLL_LOCK);
>>> + wait_on_value(ST_MPU_CLK, 1, &prcm_base->idlest_pll_mpu, LDELAY);
>>>
>> I know of dll lock infinite loops in some other system.. but that is a
>> different topic needing a differ
Re: [U-Boot] [beagleboard] TI:OMAP: [PATCH 4/4] Minimal Display driver for OMAP3
Khasim Syed Mohammed said the following on 01/09/2010 09:16 PM:
> On Sat, Jan 9, 2010 at 8:18 PM, Nishanth Menon
> wrote:
>> Khasim Syed Mohammed said the following on 01/08/2010 09:00 PM:
>>> On Sat, Jan 9, 2010 at 1:31 AM, Nishanth Menon
>>> wrote:
>>>
>>>> On Fri, Jan 8, 2010 at 9:40 AM, Khasim Syed Mohammed
>>>> wrote:
>>>>
>>>>> From 239c47a4180fb4d5b5217f892955524d476916cf Mon Sep 17 00:00:00 2001
>>>>> From: Syed Mohammed Khasim
[...]
>> The recomendation here is to move from #defines to struct based register
>> usage. I am ok with the rest(except for need to split).
> Split is done, posted yesterday.
>
> Struct based register needs more comments, not that I am lazy to
> implement that. I need to know the reason for doing the same when no
> multiple instances are used.
>
>>> You can add a new panel or a new tv standard with these structures
>>> easily. Structures are not used for register accesses.
>>>
>>>
>>>> here is what I think:
>>>> venc_config {
>>>> }
>>>>
>>>> if it is organized as the register definitions,
>>>>
>>>> configure_venc(struct venc_config *values)
>>>> struct venc_config * d = BASE_ADDRESS_OF_OMAP3_VENC;
>>>> writel(values->regx, &d->regx);
>>>>
>>>> refer: drivers/mtd/nand/omap_gpmc.c
>>>>
>>>>
>>> GPIO, GPMC and other controllers have multiple instances in OMAP, it
>>> makes sense to organize such register set in structure mode. I did
>>> start with that but found no use for DSS as it is just one instance.
>>> Structures don't give any value here.
>>>
>> there were other reasons mentioned when nand got split -> one of them had to
>> do with the compiler or something. Dirk might remember - unfortunately, this
>> was more than a year back.. if I recollect right..
> Will try doing a google. May be some one can point me to that
> decision. It would help developing drivers which have single instance
> of controller being used.
the reference I got:
http://old.nabble.com/-U-Boot---PATCH-08-13-v4--ARM%3A-OMAP3%3A-Add-NAND-support-tp20039673p20039673.html
V5 became:
http://old.nabble.com/-U-Boot---PATCH-07-13-v5--ARM%3A-OMAP3%3A-Add-NAND-support-tp20292477p20292477.html
similar changes happend for GPMC etc..
Quote:
> >Is GPMC_BASE an integer or a pointer?
>
> Nothing. A macro:
>
> #define OMAP34XX_GPMC_BASE(0x6E00)
> #define GPMC_BASE (OMAP34XX_GPMC_BASE)
So it's an integer.
> It's then casted to volatile pointer by ARM's readx/writex.
The cast should be done by the driver, or you'll get warnings if
readx/writex ever become inline functions (as they are on other arches).
might help explain..
>
>>> More over I am introducing minimal DSS driver with minimal register
>>> set. It doesn't help any to give structure based register access for
>>> single instance drivers.
>>>
>> moving to struct based is easy and done once and improves your chance of
>> your driver getting upstreamed :).
> DSS in OMAP3 has following register domains.
>
> DSI Protocol Engine 0x4804 FC00512 bytes
> DSI_PHY 0x4804 FE00 64 bytes
> DSI PLL Controller 0x4804 FF00 32 bytes
> Display Subsystem0x4805 512 bytes
> Display Controller 0x4805 0400 1K byte
> Display Controller VID1 0x4805 0400 1K byte
> Display Controller VID2 0x4805 0400 1K byte
> RFBI 0x4805 0800256 bytes
> Video Encode0x4805 0C00 256 bytes
>
> I am not sure why one would ask me to give struct definitions for
> these 500 (approx) registers when only 50 of these are required to
> implement background and color bar. As I am saying all the way, DSS is
> not multiple instance module like GPMC (NAND) and GPIO it is just one
> module.
Aren't you extrapolating this a bit out of scope? DSI,RFBI etc.. is not
relevant to your patch.
you may need DSS, controller and VID1(and VID2 is the same). I think your
complaint is about having
to define the reg structs when multiple instances dont exist - how about
OMAP4? wont these structs
get reused there(once we get around to it)?
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [beagleboard] TI:OMAP: [PATCH 3/4] Support 720Mhz configuration for OMAP35xx
Khasim Syed Mohammed said the following on 01/09/2010 09:02 PM:
> On Sat, Jan 9, 2010 at 8:27 PM, Nishanth Menon
> wrote:
>> Khasim Syed Mohammed said the following on 01/08/2010 09:21 PM:
>>> On Sat, Jan 9, 2010 at 1:22 AM, Nishanth Menon
>>> wrote:
>>>
>>>> On Fri, Jan 8, 2010 at 9:40 AM, Khasim Syed Mohammed
>>>> wrote:
>>>>
>>>>> From bba669562fa208d12f4c7cd8188446e8576cd6ee Mon Sep 17 00:00:00 2001
>>>>> From: Syed Mohammed Khasim
>>>>> Date: Fri, 8 Jan 2010 20:34:37 +0530
>>>>> Subject: [PATCH] Support 720Mhz configuration for OMAP35xx
>>>>>
[...]
>>>>> diff --git a/drivers/power/twl4030.c b/drivers/power/twl4030.c
>>>>> index eb066cb..d68e515 100644
>>>>> --- a/drivers/power/twl4030.c
>>>>> +++ b/drivers/power/twl4030.c
>>>>> @@ -59,16 +59,9 @@ void twl4030_power_reset_init(void)
>>>>> }
>>>>> }
>>>>>
>>>>> -
>>>>> /*
>>>>> * Power Init
>>>>> */
>>>>> -#define DEV_GRP_P1 0x20
>>>>> -#define VAUX3_VSEL_28 0x03
>>>>> -#define DEV_GRP_ALL0xE0
>>>>> -#define VPLL2_VSEL_18 0x05
>>>>> -#define VDAC_VSEL_18 0x03
>>>>> -
>>>>> void twl4030_power_init(void)
>>>>> {
>>>>> unsigned char byte;
>>>>> @@ -98,8 +91,6 @@ void twl4030_power_init(void)
>>>>>TWL4030_PM_RECEIVER_VDAC_DEDICATED);
>>>>> }
>>>>>
>>>>> -#define VMMC1_VSEL_30 0x02
>>>>> -
>>>>> void twl4030_power_mmc_init(void)
>>>>> {
>>>>> unsigned char byte;
>>>>> @@ -113,3 +104,18 @@ void twl4030_power_mmc_init(void)
>>>>> twl4030_i2c_write_u8(TWL4030_CHIP_PM_RECEIVER, byte,
>>>>>TWL4030_PM_RECEIVER_VMMC1_DEDICATED);
>>>>> }
>>>>> +
>>>>> +/*
>>>>> + * Generic function to select Device Group and Voltage
>>>>> + */
>>>>> +void twl4030_pmrecv_vsel_cfg(u8 vsel_reg, u8 vsel_val,
>>>>> + u8 dev_grp, u8 dev_grp_sel)
>>>>> +{
>>>>> + /* Select the Device Group */
>>>>> + twl4030_i2c_write_u8(TWL4030_CHIP_PM_RECEIVER, dev_grp_sel,
>>>>> + dev_grp);
>>>>> +
>>>>> + /* Select the Voltage */
>>>>> + twl4030_i2c_write_u8(TWL4030_CHIP_PM_RECEIVER, vsel_val,
>>>>> + vsel_reg);
>>>>> +}
>>>>>
>>>> Assumption that i2c operations work 100% successfully! is'nt serial
>>>> bus subject to noise? and cant' i2c ops fail?
>>>>
>>> May be, such cases will be treated as system fail. Should be handled
>>> separately for "broken platforms".
>>>
>>> In beagleboard and EVMs atleast in last 4 revs we have never
>>> encountered such problems.
>>>
>>>
>> I mean never seen an i2c read/write failure? I have seen at least a couple
>> unfortunately when one of the SDP3430's had some one solder a wrong pull up
>> resistor and another where a pull up resistor was torn off by accident.
>>
>> these are broken platforms ofcourse :).
> Yeah,
>
>> sigh, seeing that the rest of the
>> file is messed up in this regards, I leave it for the community to further
>> comment on this.
>>
[...]
>>>>> +#define VAUX3_VSEL_28 0x03
>>>>> +#define VPLL2_VSEL_18 0x05
>>>>> +#define VDAC_VSEL_18 0x03
>>>>> +#define VMMC1_VSEL_30 0x02
>>>>> +
> Did you mean these lines ? When I apply the patch I don't see these
> kind of lines, they are properly arranged in TABs. I have also checked
> every patch with checkpatch.pl (from Linux). There are no such
> alignment issues.
no, I meant usage of twl4030_i2c_write_u8() without error check throughout the
file.
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Linux Kernel without Ethernet (missed MAC)
Hi Arno, On Tue, Jan 19, 2010 at 8:59 AM, Arno Steffen wrote: > > Call me stupid, I just know this access : > http://lists.denx.de/pipermail/u-boot/ > This doesn't allow a practial search (at least I don't know how) - sorry. > I am working puzzling more than a day with this - so I am not lazy with that. > I try my best. you could try http://old.nabble.com/Uboot---Users-f553.html i kind of find it easier to search on that. Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] MTD:NAND Enable nand lock, unlock feature
Enable nand lock, unlock and status of lock feature.
Not every device and platform requires this, hence,
it is under define for CONFIG_CMD_NAND_LOCK_UNLOCK
Nand unlock and status operate on block boundary instead
of page boundary. Details in:
http://www.micron.com/products/partdetail?part=MT29C2G24MAKLAJG-6%20IT
Intial solution provided by Vikram Pandita
Includes preliminary suggestions from Scott Wood
Signed-off-by: Nishanth Menon
---
common/cmd_nand.c| 96 +
drivers/mtd/nand/nand_util.c | 79 +++
2 files changed, 92 insertions(+), 83 deletions(-)
diff --git a/common/cmd_nand.c b/common/cmd_nand.c
index 0a366d3..a240c37 100644
--- a/common/cmd_nand.c
+++ b/common/cmd_nand.c
@@ -164,6 +164,47 @@ out:
return 0;
}
+#ifdef CONFIG_CMD_NAND_LOCK_UNLOCK
+static void print_status(ulong start, ulong end, ulong erasesize, int status)
+{
+ printf("%08lx - %08lx: %08lx blocks %s%s%s\n",
+ start,
+ end - 1,
+ (end - start) / erasesize,
+ ((status & NAND_LOCK_STATUS_TIGHT) ? "TIGHT " : ""),
+ ((status & NAND_LOCK_STATUS_LOCK) ? "LOCK " : ""),
+ ((status & NAND_LOCK_STATUS_UNLOCK) ? "UNLOCK " : ""));
+}
+
+static void do_nand_status(nand_info_t *nand)
+{
+ ulong block_start = 0;
+ ulong off;
+ int last_status = -1;
+
+ struct nand_chip *nand_chip = nand->priv;
+ /* check the WP bit */
+ nand_chip->cmdfunc(nand, NAND_CMD_STATUS, -1, -1);
+ printf("device is %swrite protected\n",
+ (nand_chip->read_byte(nand) & 0x80 ?
+ "NOT " : ""));
+
+ for (off = 0; off < nand->size; off += nand->erasesize) {
+ int s = nand_get_lock_status(nand, off);
+
+ /* print message only if status has changed */
+ if (s != last_status && off != 0) {
+ print_status(block_start, off, nand->erasesize,
+ last_status);
+ block_start = off;
+ }
+ last_status = s;
+ }
+ /* Print the last block info */
+ print_status(block_start, off, nand->erasesize, last_status);
+}
+#endif
+
int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char *argv[])
{
int i, dev, ret = 0;
@@ -383,8 +424,9 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char
*argv[])
return 1;
}
+#ifdef CONFIG_CMD_NAND_LOCK_UNLOCK
if (strcmp(cmd, "lock") == 0) {
- int tight = 0;
+ int tight = 0;
int status = 0;
if (argc == 3) {
if (!strcmp("tight", argv[2]))
@@ -392,44 +434,8 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char
*argv[])
if (!strcmp("status", argv[2]))
status = 1;
}
-/*
- * ! BROKEN !
- *
- * TODO: must be implemented and tested by someone with HW
- */
-#if 0
if (status) {
- ulong block_start = 0;
- ulong off;
- int last_status = -1;
-
- struct nand_chip *nand_chip = nand->priv;
- /* check the WP bit */
- nand_chip->cmdfunc (nand, NAND_CMD_STATUS, -1, -1);
- printf("device is %swrite protected\n",
- (nand_chip->read_byte(nand) & 0x80 ?
- "NOT " : ""));
-
- for (off = 0; off < nand->size; off += nand->writesize)
{
- int s = nand_get_lock_status(nand, off);
-
- /* print message only if status has changed
-* or at end of chip
-*/
- if (off == nand->size - nand->writesize
- || (s != last_status && off != 0)) {
-
- printf("%08lx - %08lx: %8d pages
%s%s%s\n",
- block_start,
- off-1,
-
(off-block_start)/nand->writesize,
- ((last_status &
NAND_LOCK_STATUS_TIGHT) ? "TIGHT " : ""),
- ((last_status &
NAND_LOCK_STATUS_LOCK) ? "LOCK " : ""),
- ((last_status &
NAND_LOCK_STATUS_UNLOCK) ? "UNLOCK &qu
Re: [U-Boot] Error in buffer data for NAND flash write, read on OMAP3430SDP.
Radha Krishna said the following on 12/24/2008 01:37 AM: > nand dua ...this commad is simple and executes nand erase,nand write and nand > read APIs. Write data and read data are like 1,2,3,4,5131072. > > For comparing byte by byte data, using two buffers write_buffer, read_buffer > both are of size 131072. > > U-boot version: > U-Boot uses a 3 level version number containing a version, a > sub-version, and a patchlevel: "U-Boot-2.34.5" means version "2", > sub-version "34", and patchlevel "4". > > I got the U-boot from the URL: > https://omapzoom.org/gf/project/bootloader/frs/ > > I think you are with a really old U-Boot if the above is the place you picked it from! if you look up the boot message it probably should be 1.1.5 or something of that revision. You can find the old revision in [1]. We are attempting to merge in patches to the very latest 1.5 release which still does not have SDP3430 support (but can be done with a little effort). You can see this new community initiative for a mainstream OMAP3 U-Boot in [2] - but note, it is still a work in progress and yet to be accepted in the mainline tree (But I guess we are getting pretty close to it now).. Regards, Nishanth Menon Ref: [1] http://git.omapzoom.org/?p=u-boot.git;a=summary [2] http://git.sakoman.net/cgi-bin/gitweb.cgi?p=u-boot-omap3.git;a=shortlog;h=refs/heads/omap3-dev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Error in buffer data for NAND flash write, read on OMAP3430SDP.
Nishanth Menon said the following on 12/24/2008 07:41 AM: > Radha Krishna said the following on 12/24/2008 01:37 AM: > >> I got the U-boot from the URL: >> https://omapzoom.org/gf/project/bootloader/frs/ >> >> >> > I think you are with a really old U-Boot if the above is the place you > picked it from! if you look up the boot message it probably should be > 1.1.5 or something of that revision. You can find the old revision in > [1]. > > [1] http://git.omapzoom.org/?p=u-boot.git;a=summary > One more minor item of interest - for the u-boot pulled from omapzoom.org, you may be interested in contacting either [1] or [2]. Regards, Nishanth Menon Ref: [1] http://vger.kernel.org/vger-lists.html#linux-omap [2] https://omapzoom.org/mailman/listinfo/omapandroid-discussion ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Bug in nand_default_bbt?
Hi Scott, A gentle question on drivers/mtd/nand/nand_bbt.c:largepage_flashbased in Micron devices, the bb marker is the first word. for a x8 device is 1 byte and x16 device it is 2 bytes. .len = 2 makes sense for an x16 device in the above variable, however the marker does a false postive detection for x8 devices. I can over ride this by using nand_chip->badblock_pattern in my board file, but from an mtd layer perspective, does it make sense to fix this for a generic usage? Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem while using u-boot for Omap 2430 sdp
Vijay Kolhal said the following on 01/02/2009 06:45 AM: > But when i instered on puts(); statement or printf(); statement in > icache_enable() function of cpu\arm1136\cpu.c file, Though it gets compile > well and it create u-boot.bin image file, It doesnt get execute on Omap > 2430 board. > There lies your problem.. icache_enable is called in the boot up sequence before serial initialization or clocks are configured, attempting a puts/printf crashes the system. Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] help
dinny said the following on 01/07/2009 03:37 AM: > >From the cpu aspect, it should be the most familiar one with your > CPUs. And try to learn more on your on-board peripherals and devices. > Probably you can find some boards that have similar device > configuration, thus you can reuse some codes, esp. in case that you > should be not familiar with these devices. > > One thing that might be different would be mmu config I would suspect.. you may want to refer to [2] instead of omapzoom as [2] is closer to mainline u-boot. you can find cortex_a8 documentation in [1]. TI OMAP3 documentation is publically available too, if you would like to see what is happening in the code.. Regards, Nishanth Menon Ref: [1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344e/index.html - there is a link to A9 also nearby.. [2] http://www.sakoman.net/cgi-bin/gitweb.cgi?p=u-boot-arm.git;a=shortlog;h=refs/heads/omap3-dev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] help
On Wed, Jan 7, 2009 at 8:12 AM, dinny wrote: >> [1] >> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344e/index.html >> - there is a link to A9 also nearby.. > > It seems A9's doc is public-restricted, and it prevents me from having > a look at A9's design. Could you make it clear what main changes on > MMU between A8 and A9 are? I have not looked at A9, so I cannot comment unfortunately. Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-v2
John Jeffers said the following on 01/20/2009 06:18 PM: > #ln -s arm cross_arch > > #ln -s > /opt/arm-v5te-linux-gnueabi/gcc-4.1.2-glibc-2.5-binutils-2.17-kernel-2.6.18/arm-v5te-linux-gnueabi/bin > \ cross_compile > > During make menuconfig the arm is not picked up as the architecture. I > appear to get sandbox. > > Obviously I am not telling the menuconfig to use my architecture. > Perhap the /board is more appropriate.' > > This is how i build for omap3 beagle platform: alias mymake='make ARCH=arm CROSS_COMPILE=arm-none-eabi- V=1' mymake omap3430_sdp3430_per_uart_defconfig mymake I could ofcourse do mymake menuconfig and go ahead.. (I use 2007q3 codesourcery compiler) Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] __FILE__ usage and and SPL limits for SRAM
Hi,
we've kind of run into an interesting situation recently, but might be
of interest for various folks trying to reduce the image sizes.
our AM335x device has a limited amount of sram.. and the SPL tries to
fit into it (a bit tricky given the restricted space we have on it on
certain class of devices).
arch/arm/mach-omap2/am33xx/u-boot-spl.lds is a bit custom tailored
around this.
Key in this is:
. = ALIGN(4);
.rodata : { *(SORT_BY_ALIGNMENT(.rodata*)) } >.sram
. = ALIGN(4);
.data : { *(SORT_BY_ALIGNMENT(.data*)) } >.sram
Now, our jenkins build system happens to use a varied build path and
uses O= path. to simplify the details:
mkdir
/tmp//b/cc
mkdir
/tmp//b/cc/b
git clone u-boot
cd u-boot
git clean -fdx
make CROSS_COMPILE=arm-linux-gnueabihf- O=../b am335x_evm_defconfig
make CROSS_COMPILE=arm-linux-gnueabihf- O=../b all
depending on depth of the path, this would fail.. a little bit of
headscratching later..
when using O= build system uses absolute paths, which translates to
__FILE__ being absolute paths as well..
in u-boot, any printf("%s", __FILE__) makes u-boot allocate this file
path in rodata.
So, depending on how deep the path is rodata size varies and ends up
pushing .data out of sram max range.
we dont really care to put a print of complete absolute path anyways,
and I am not really sure of a clean way to resolve this:
a) override __FILE__ with something.. -Wbuiltin-macro-redefined kicks in
b) replace usage of __FILE__ with something like __FILENAME__ as
recommended by [1]
What is the suggestion we do?
[1] http://stackoverflow.com/questions/8487986/file-macro-shows-full-path
--
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] __FILE__ usage and and SPL limits for SRAM
Hi Masahiro-san, On Tue, Mar 28, 2017 at 1:29 AM, Masahiro Yamada wrote: [...] > > When O= is given, the build system runs in the object tree, > not in the source tree. > (This is the same as Linux.) > > If you see the top Makefile: > > ifeq ($(KBUILD_SRC),) > # building in the source tree > srctree := . > else > ifeq ($(KBUILD_SRC)/,$(dir $(CURDIR))) > # building in a subdirectory of the source tree > srctree := .. > else > srctree := $(KBUILD_SRC) > endif > endif > > > > > If O= points to a sub-directory of the source tree, > the relative path "srctree := .." is used. > > Otherwise, the absolute path srctree := $(KBUILD_SRC) is used. > In your case, "O=../b" means the source tree and the obj tree > are siblings. So, absolute path. I did simplify this a bit with O=../b to highlight exactly what you mentioned above. in our case, the O=path points to a completely different directory path. > If you want to see a short relative path for __FILE__, > I'd recommend to use a sub-directory for O=. > > For example, your source tree is located at > ~/a/bbb//u-boot, > create a directory ~/a/bbb//u-boot/foo, > then give O=foo Typical product build such as OE recipes used (in our case) does not build into the source folder, instead, all binary builds are pointed to either a temporary location or a package build location. So, while O=source_path/build would aliviate the problem, it still does'nt really solve the root of the issue. -- --- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] __FILE__ usage and and SPL limits for SRAM
On Tue, Mar 28, 2017 at 6:47 AM, Felipe Balbi wrote: > > have you tried using __BASE_FILE__ instead of __FILE__? You could also https://gcc.gnu.org/onlinedocs/gcc-4.1.2/cpp/Common-Predefined-Macros.html __BASE_FILE__This macro expands to the name of the main input file, in the form of a C string constant. This is the source file that was specified on the command line of the preprocessor or C compiler. __FILE__ and __BASE_FILE__ are'nt the same. and further, __FILE__ is used in many places in source unfortunately. > redefine __FILE__ or __BASE_FILE__ while building SPL. As I mentioned in my original email: a) override __FILE__ with something.. -Wbuiltin-macro-redefined kicks in If we decide to deprecate usage of __FILE__ , it wont be intutive, the option i can think of is to override __FILE__ and somehow just squash warning just for __FILE__ (I have'nt investigated how).. and get a build time macro to define relative path which is provided as a replacement for __FILE__ [1] http://stackoverflow.com/questions/8487986/file-macro-shows-full-path -- --- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/2] power: regulator: lp87565: add regulator support
On 06/07/2017 08:38 AM, Keerthy wrote:
+static bool buck_get_enable(struct udevice *dev)
+{
+ bool enable = false;
+ int ret;
+
+
+ ret = lp87565_buck_enable(dev, PMIC_OP_GET, &enable);
+ if (ret)
+ return ret;
Somehow does'nt look right, why return int for a bool function? return
false perhaps?
--
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/6] arm: am57xx: reintroduce the CONFIG_AM57XX symbol
On 02/14/2017 01:20 PM, Tom Rini wrote: On Tue, Feb 14, 2017 at 01:18:20PM -0600, menon.nisha...@gmail.com wrote: On Mon, Feb 13, 2017 at 7:27 AM, Tom Rini wrote: On Mon, Feb 13, 2017 at 01:34:52PM +0200, Uri Mashiach wrote: The SOC family symbol CONFIG_AM57XX was removed by the commit 3891a54: "ARM: DRA7x/AM57xx: Get rid of CONFIG_AM57XX". The symbol is needed by the XHCI OMAP USB driver. Without the symbol all the AM57x targets symbols should be ored in the ifdef'ery. Signed-off-by: Uri Mashiach We need to introduce it into Kconfig files now, thanks! DRA7 and AM57xx are literally the same. the #ifdeffery in USB is more to do which port to use rather than having anything to do with DRA7 Vs AM57xx. Yes, agreed. And we need to solve this, and introduce some Kconfig CONFIG symbol to deal with it. Maybe the better way to look at this is, can we have DRA7xx boards configured in the way Uri wants to be able to configure the AM57xx board he's working with? And vice versa? The answer to that will help drive what the right CONFIG_xxx name is. Should'nt be ideally done via DM model instead? I have no understanding of USB integration done in u-boot to comment better. -- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] ARM: OMAP5: Add AVS support for ES2.0
Hi, OMAP5 went into production with AVS Class0 Vs pre-production configuration of AVS 1.5. Most of the current "in-the-wild" OMAP5 uEVMs are based on pre-production samples, however, the support for "production configuration" helps platforms such as pyra-handheld[1]. This original issue was reported by zmatt on #beagle freenode IRC channel, However, I donot have a email address to attribute to him/her :( (zmatt, if you are on the list, feel free to add your reported and/or tested) Series verified (with scope) on: a) 720-2644-001 OMAP5UEVM with production sample. b) 750-2628-222(A) UEVM5432G-02 with pre-production sample. build tested with: buildman -b omap5-evm omap5 [1] https://www.pyra-handheld.com/wiki/index.php?title=OMAP_5 Nishanth Menon (2): ARM: OMAP5: Remove OPP_LOW Definitions for ES2.0 ARM: OMAP5: Enable support for AVS0 for OMAP5 production devices arch/arm/include/asm/arch-omap5/clock.h | 17 +++-- arch/arm/include/asm/arch-omap5/omap.h | 4 ++-- arch/arm/mach-omap2/omap5/abb.c | 4 ++-- arch/arm/mach-omap2/omap5/hw_data.c | 9 + 4 files changed, 28 insertions(+), 6 deletions(-) -- 2.12.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] ARM: OMAP5: Enable support for AVS0 for OMAP5 production devices
OMAP5432 did go into production with AVS class0 registers which were
mutually exclusive from AVS Class 1.5 registers.
Most OMAP5-uEVM boards use the pre-production Class1.5 which has
production efuse registers set to 0. However on production devices,
these are set to valid data.
scale_vcore logic is already smart enough to detect this and use the
"Nominal voltage" on devices that do not have efuse registers populated.
On a test production device populated as follows:
MPU OPP_NOM:
=> md.l 0x04A0021C4 1
4a0021c4: 03a003e9
(0x3e9 = 1.01v) vs nom voltage of 1.06v
MPU OPP_HIGH:
=> md.l 0x04A0021C8 1
4a0021c8: 03400485 ..@.
MM OPP_NOM:
=> md.l 0x04A0021A4 1
4a0021a4: 038003d4
(0x3d4 = 980mV) vs nom voltage of 1.025v
MM OPP_OD:
=> md.l 0x04A0021A8 1
4a0021a8: 03600403 ..`.
CORE OPP_NOM:
=> md.l 0x04A0021D8 1
4a0021d8: 03cf
(0x3cf = 975mV) vs nom voltage of 1.040v
Since the efuse values are'nt currently used, we do not regress on
existing pre-production samples (they continue to use nominal voltage).
But on boards that do have production samples populated, we can leverage
the optimal voltages necessary for proper operation.
Tested on:
a) 720-2644-001 OMAP5UEVM with production sample.
b) 750-2628-222(A) UEVM5432G-02 with pre-production sample.
Data based on OMAP5432 Technical reference Manual SWPU282AF (May
2012-Revised Aug 2016)
NOTE: All collaterals on OMAP5432 silicon itself seems to have been
removed from ti.com, though EVM details are still available:
http://www.ti.com/tool/OMAP5432-EVM
Signed-off-by: Nishanth Menon
---
arch/arm/include/asm/arch-omap5/clock.h | 16
arch/arm/include/asm/arch-omap5/omap.h | 4 ++--
arch/arm/mach-omap2/omap5/abb.c | 4 ++--
arch/arm/mach-omap2/omap5/hw_data.c | 9 +
4 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/arch/arm/include/asm/arch-omap5/clock.h
b/arch/arm/include/asm/arch-omap5/clock.h
index dd05e8ba8317..dbe340d23e4f 100644
--- a/arch/arm/include/asm/arch-omap5/clock.h
+++ b/arch/arm/include/asm/arch-omap5/clock.h
@@ -236,6 +236,22 @@
#define VDD_MPU_ES2_HIGH 1250
#define VDD_MM_ES2_OD 1120
+/* Efuse register offsets for OMAP5 platform */
+#define OMAP5_ES2_EFUSE_BASE 0x4A002000
+#define OMAP5_ES2_PROD_REGBITS 16
+
+/* CONTROL_STD_FUSE_OPP_VDD_CORE_3 */
+#define OMAP5_ES2_PROD_CORE_OPNO_VMIN (OMAP5_ES2_EFUSE_BASE + 0x1D8)
+
+/* CONTROL_STD_FUSE_OPP_VDD_MM_4 */
+#define OMAP5_ES2_PROD_MM_OPNO_VMIN(OMAP5_ES2_EFUSE_BASE + 0x1A4)
+/* CONTROL_STD_FUSE_OPP_VDD_MM_5 */
+#define OMAP5_ES2_PROD_MM_OPOD_VMIN(OMAP5_ES2_EFUSE_BASE + 0x1A8)
+/* CONTROL_STD_FUSE_OPP_VDD_MPU_6 */
+#define OMAP5_ES2_PROD_MPU_OPNO_VMIN (OMAP5_ES2_EFUSE_BASE + 0x1C4)
+/* CONTROL_STD_FUSE_OPP_VDD_MPU_7 */
+#define OMAP5_ES2_PROD_MPU_OPHI_VMIN (OMAP5_ES2_EFUSE_BASE + 0x1C8)
+
/* DRA74x/75x/72x voltage settings in mv for OPP_NOM per DM */
#define VDD_MPU_DRA7_NOM 1150
#define VDD_CORE_DRA7_NOM 1150
diff --git a/arch/arm/include/asm/arch-omap5/omap.h
b/arch/arm/include/asm/arch-omap5/omap.h
index 2f005dd3ad92..b047f0d65081 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -224,8 +224,8 @@ struct s32ktimer {
#define OMAP_ABB_GPU_TXDONE_MASK (0x1 << 28)
/* ABB efuse masks */
-#define OMAP5_ABB_FUSE_VSET_MASK (0x1F << 24)
-#define OMAP5_ABB_FUSE_ENABLE_MASK (0x1 << 29)
+#define OMAP5_PROD_ABB_FUSE_VSET_MASK (0x1F << 20)
+#define OMAP5_PROD_ABB_FUSE_ENABLE_MASK(0x1 << 25)
#define DRA7_ABB_FUSE_VSET_MASK(0x1F << 20)
#define DRA7_ABB_FUSE_ENABLE_MASK (0x1 << 25)
#define OMAP5_ABB_LDOVBBMPU_MUX_CTRL_MASK (0x1 << 10)
diff --git a/arch/arm/mach-omap2/omap5/abb.c b/arch/arm/mach-omap2/omap5/abb.c
index 3bf88979e5d6..1882c49e7df6 100644
--- a/arch/arm/mach-omap2/omap5/abb.c
+++ b/arch/arm/mach-omap2/omap5/abb.c
@@ -28,8 +28,8 @@
s8 abb_setup_ldovbb(u32 fuse, u32 ldovbb)
{
u32 vset;
- u32 fuse_enable_mask = OMAP5_ABB_FUSE_ENABLE_MASK;
- u32 fuse_vset_mask = OMAP5_ABB_FUSE_VSET_MASK;
+ u32 fuse_enable_mask = OMAP5_PROD_ABB_FUSE_ENABLE_MASK;
+ u32 fuse_vset_mask = OMAP5_PROD_ABB_FUSE_VSET_MASK;
if (!is_omap54xx()) {
/* DRA7 */
diff --git a/arch/arm/mach-omap2/omap5/hw_data.c
b/arch/arm/mach-omap2/omap5/hw_data.c
index a8a6b8a869e5..4ad6b530d29c 100644
--- a/arch/arm/mach-omap2/omap5/hw_data.c
+++ b/arch/arm/mach-omap2/omap5/hw_data.c
@@ -329,6 +329,15 @@ struct vcores_data omap5430_volts_es2 = {
.mm.addr = SMPS_REG_ADDR_45_IVA,
.mm.pmic = &palmas,
.mm.abb_tx_done_mask = OMAP_ABB_MM_TXDONE_MASK,
+
+ .
[U-Boot] [PATCH 1/2] ARM: OMAP5: Remove OPP_LOW Definitions for ES2.0
ES2.0 descopes OPP_LOW definition. So remove it from macros defined. Signed-off-by: Nishanth Menon --- arch/arm/include/asm/arch-omap5/clock.h | 3 --- 1 file changed, 3 deletions(-) diff --git a/arch/arm/include/asm/arch-omap5/clock.h b/arch/arm/include/asm/arch-omap5/clock.h index 0c99bbdc9320..dd05e8ba8317 100644 --- a/arch/arm/include/asm/arch-omap5/clock.h +++ b/arch/arm/include/asm/arch-omap5/clock.h @@ -236,9 +236,6 @@ #define VDD_MPU_ES2_HIGH 1250 #define VDD_MM_ES2_OD 1120 -#define VDD_MPU_ES2_LOW 880 -#define VDD_MM_ES2_LOW 880 - /* DRA74x/75x/72x voltage settings in mv for OPP_NOM per DM */ #define VDD_MPU_DRA7_NOM 1150 #define VDD_CORE_DRA7_NOM 1150 -- 2.12.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] regulator: lp873x: Fix the return value of buck_get_enable function
On 06/11/2017 12:01 AM, Keerthy wrote:
The function wrongly returned an integer while it is supposed to
return boolean. Fix that.
Fixes: 99785de83 ("power: regulator: lp873x: Add regulator support")
Signed-off-by: Keerthy
---
drivers/power/regulator/lp873x_regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/power/regulator/lp873x_regulator.c
b/drivers/power/regulator/lp873x_regulator.c
index 149a36d..8c26baf 100644
--- a/drivers/power/regulator/lp873x_regulator.c
+++ b/drivers/power/regulator/lp873x_regulator.c
@@ -318,7 +318,7 @@ static bool buck_get_enable(struct udevice *dev)
ret = lp873x_buck_enable(dev, PMIC_OP_GET, &enable);
if (ret)
- return ret;
+ return false;
return enable;
}
just squash 2/3 and 3/3 to a single patch?
--
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/4] ARM: OMAP5/DRA7: Update ABB Configuration for all valid domains
Original intent when Adaptive Body Bias(ABB) was supported in bootloader was two fold: a) ABB is mandatory for all OMAP5/DRA7 support b) expectation was that linux kernel/Operating system will setup ABB and voltage depending on the requirements of the platform. However, over the last few years, few things changed: i) DRA7 SoCs do not permit for voltage scaling beyond the bootloader's initial settings thanks to a few silicon limitations. This implies that the bootloader has to setup the correct voltage at boot for all domains. Only the MPU voltage domain is excempt from this rule. ii) software stack evolution tied up the voltage rails and ABB setup together for obvious reasons of ABB is fundamentally related to voltage rail configuration. As a result of these, Linux and operating system just configures just the frequency using the default boot loader configured voltage can fail on many corner lot units and has been hard to debug. This specifically is a concern with DRA7 generation of SoCs since other than VDD_MPU, all other domains are only permitted to setup the voltages to required OPP only at boot. Given that OMAP5 closely matches DRA7, this series setsup ABB for all domains consistent with the voltage configuration for all domains that have need for ABB. Series is based on v2016.05-rc2 Boot Log: OMAP5uevm: http://pastebin.ubuntu.com/15971620/ AM572x-X15: http://pastebin.ubuntu.com/15971707/ Nishanth Menon (4): ARM: OMAP5/DRA7: Get rid of control_std_fuse_opp_vdd_mpu_2 ARM: OMAP5/DRA7: Move ABB TXDONE mask to voltage structure ARM: OMAP5: Enable ABB configuration for MM voltage domain ARM: DRA7: Add ABB setup for all domains arch/arm/cpu/armv7/omap-common/clocks-common.c | 41 +++--- arch/arm/cpu/armv7/omap5/hw_data.c | 10 +++ arch/arm/cpu/armv7/omap5/prcm-regs.c | 16 -- arch/arm/include/asm/arch-omap5/omap.h | 4 +++ arch/arm/include/asm/omap_common.h | 16 +- board/ti/am57xx/board.c| 4 +++ 6 files changed, 84 insertions(+), 7 deletions(-) -- 2.8.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] ARM: DRA7: Add ABB setup for all domains
ABB should be initialized for all required domains voltage domain
for DRA7: IVA, GPU, EVE in addition to the existing MPU domain. If
we do not do this, kernel configuring just the frequency using the
default boot loader configured voltage can fail on many corner lot
units and has been hard to debug. This specifically is a concern with
DRA7 generation of SoCs since other than VDD_MPU, all other domains
are only permitted to setup the voltages to required OPP only at boot.
Reported-by: Richard Woodruff
Signed-off-by: Nishanth Menon
---
arch/arm/cpu/armv7/omap-common/clocks-common.c | 24
arch/arm/cpu/armv7/omap5/hw_data.c | 6 ++
arch/arm/cpu/armv7/omap5/prcm-regs.c | 10 ++
arch/arm/include/asm/arch-omap5/omap.h | 3 +++
arch/arm/include/asm/omap_common.h | 9 +
board/ti/am57xx/board.c| 3 +++
6 files changed, 55 insertions(+)
diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c
b/arch/arm/cpu/armv7/omap-common/clocks-common.c
index da57b385c922..ef2ac982171f 100644
--- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
+++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
@@ -596,10 +596,34 @@ void scale_vcores(struct vcores_data const *vcores)
debug("gpu: %d\n", vcores->gpu.value);
do_scale_vcore(vcores->gpu.addr, vcores->gpu.value, vcores->gpu.pmic);
+ /* Configure GPU ABB LDO after scale */
+ abb_setup(vcores->gpu.efuse.reg,
+ (*ctrl)->control_wkup_ldovbb_gpu_voltage_ctrl,
+ (*prcm)->prm_abbldo_gpu_setup,
+ (*prcm)->prm_abbldo_gpu_ctrl,
+ (*prcm)->prm_irqstatus_mpu,
+ vcores->gpu.abb_tx_done_mask,
+ OMAP_ABB_FAST_OPP);
debug("eve: %d\n", vcores->eve.value);
do_scale_vcore(vcores->eve.addr, vcores->eve.value, vcores->eve.pmic);
+ /* Configure EVE ABB LDO after scale */
+ abb_setup(vcores->eve.efuse.reg,
+ (*ctrl)->control_wkup_ldovbb_eve_voltage_ctrl,
+ (*prcm)->prm_abbldo_eve_setup,
+ (*prcm)->prm_abbldo_eve_ctrl,
+ (*prcm)->prm_irqstatus_mpu,
+ vcores->eve.abb_tx_done_mask,
+ OMAP_ABB_FAST_OPP);
debug("iva: %d\n", vcores->iva.value);
do_scale_vcore(vcores->iva.addr, vcores->iva.value, vcores->iva.pmic);
+ /* Configure IVA ABB LDO after scale */
+ abb_setup(vcores->iva.efuse.reg,
+ (*ctrl)->control_wkup_ldovbb_iva_voltage_ctrl,
+ (*prcm)->prm_abbldo_iva_setup,
+ (*prcm)->prm_abbldo_iva_ctrl,
+ (*prcm)->prm_irqstatus_mpu,
+ vcores->iva.abb_tx_done_mask,
+ OMAP_ABB_FAST_OPP);
/* Might need udelay(1000) here if debug is enabled to see all prints */
#else
u32 val;
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c
b/arch/arm/cpu/armv7/omap5/hw_data.c
index dfb1df6bce30..88e8920bad31 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -377,12 +377,14 @@ struct vcores_data dra752_volts = {
.eve.efuse.reg_bits = DRA752_EFUSE_REGBITS,
.eve.addr = TPS659038_REG_ADDR_SMPS45,
.eve.pmic = &tps659038,
+ .eve.abb_tx_done_mask = OMAP_ABB_EVE_TXDONE_MASK,
.gpu.value = VDD_GPU_DRA752,
.gpu.efuse.reg = STD_FUSE_OPP_VMIN_GPU_NOM,
.gpu.efuse.reg_bits = DRA752_EFUSE_REGBITS,
.gpu.addr = TPS659038_REG_ADDR_SMPS6,
.gpu.pmic = &tps659038,
+ .gpu.abb_tx_done_mask = OMAP_ABB_GPU_TXDONE_MASK,
.core.value = VDD_CORE_DRA752,
.core.efuse.reg = STD_FUSE_OPP_VMIN_CORE_NOM,
@@ -395,6 +397,7 @@ struct vcores_data dra752_volts = {
.iva.efuse.reg_bits = DRA752_EFUSE_REGBITS,
.iva.addr = TPS659038_REG_ADDR_SMPS8,
.iva.pmic = &tps659038,
+ .iva.abb_tx_done_mask = OMAP_ABB_IVA_TXDONE_MASK,
};
struct vcores_data dra722_volts = {
@@ -420,18 +423,21 @@ struct vcores_data dra722_volts = {
.gpu.efuse.reg_bits = DRA752_EFUSE_REGBITS,
.gpu.addr = TPS65917_REG_ADDR_SMPS3,
.gpu.pmic = &tps659038,
+ .gpu.abb_tx_done_mask = OMAP_ABB_GPU_TXDONE_MASK,
.eve.value = VDD_EVE_DRA72x,
.eve.efuse.reg = STD_FUSE_OPP_VMIN_DSPEVE_NOM,
.eve.efuse.reg_bits = DRA752_EFUSE_REGBITS,
.eve.addr = TPS65917_REG_ADDR_SMPS3,
.eve.pmic = &tps659038,
+ .eve.abb_tx_done_mask = OMAP_ABB_EVE_TXDONE_MASK,
.iva.value = VDD_IVA_DRA72x,
.iva.efuse.reg = STD_FUSE_OPP_VMIN_IVA_NOM,
.iva.efuse.reg_bits = DRA752_EFUSE_REGBITS,
.iva.addr = TPS65917_REG_ADDR_SMPS3,
[U-Boot] [PATCH 2/4] ARM: OMAP5/DRA7: Move ABB TXDONE mask to voltage structure
ABB TX_DONE mask will vary depending on ABB module. For example,
3630 never had ABB on IVA domain, while OMAP5 does use ABB on MM domain,
DRA7 has it on all domains with the exception of CORE, RTC.
Hence, move the txdone mask definition over to structure describing
voltage domain.
Signed-off-by: Nishanth Menon
---
arch/arm/cpu/armv7/omap-common/clocks-common.c | 4 ++--
arch/arm/cpu/armv7/omap5/hw_data.c | 3 +++
arch/arm/include/asm/omap_common.h | 2 ++
board/ti/am57xx/board.c| 1 +
4 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c
b/arch/arm/cpu/armv7/omap-common/clocks-common.c
index 27e6871fde86..8fe695b992b1 100644
--- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
+++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
@@ -589,7 +589,7 @@ void scale_vcores(struct vcores_data const *vcores)
(*prcm)->prm_abbldo_mpu_setup,
(*prcm)->prm_abbldo_mpu_ctrl,
(*prcm)->prm_irqstatus_mpu_2,
- OMAP_ABB_MPU_TXDONE_MASK,
+ vcores->mpu.abb_tx_done_mask,
OMAP_ABB_FAST_OPP);
/* The .mm member is not used for the DRA7xx */
@@ -626,7 +626,7 @@ void scale_vcores(struct vcores_data const *vcores)
(*prcm)->prm_abbldo_mpu_setup,
(*prcm)->prm_abbldo_mpu_ctrl,
(*prcm)->prm_irqstatus_mpu_2,
- OMAP_ABB_MPU_TXDONE_MASK,
+ vcores->mpu.abb_tx_done_mask,
OMAP_ABB_FAST_OPP);
val = optimize_vcore_voltage(&vcores->mm);
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c
b/arch/arm/cpu/armv7/omap5/hw_data.c
index b69c0d13715a..a4b31e42e2c3 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -352,6 +352,7 @@ struct vcores_data omap5430_volts_es2 = {
.mpu.value = VDD_MPU_ES2,
.mpu.addr = SMPS_REG_ADDR_12_MPU,
.mpu.pmic = &palmas,
+ .mpu.abb_tx_done_mask = OMAP_ABB_MPU_TXDONE_MASK,
.core.value = VDD_CORE_ES2,
.core.addr = SMPS_REG_ADDR_8_CORE,
@@ -368,6 +369,7 @@ struct vcores_data dra752_volts = {
.mpu.efuse.reg_bits = DRA752_EFUSE_REGBITS,
.mpu.addr = TPS659038_REG_ADDR_SMPS12,
.mpu.pmic = &tps659038,
+ .mpu.abb_tx_done_mask = OMAP_ABB_MPU_TXDONE_MASK,
.eve.value = VDD_EVE_DRA752,
.eve.efuse.reg = STD_FUSE_OPP_VMIN_DSPEVE_NOM,
@@ -400,6 +402,7 @@ struct vcores_data dra722_volts = {
.mpu.efuse.reg_bits = DRA752_EFUSE_REGBITS,
.mpu.addr = TPS65917_REG_ADDR_SMPS1,
.mpu.pmic = &tps659038,
+ .mpu.abb_tx_done_mask = OMAP_ABB_MPU_TXDONE_MASK,
.core.value = VDD_CORE_DRA72x,
.core.efuse.reg = STD_FUSE_OPP_VMIN_CORE_NOM,
diff --git a/arch/arm/include/asm/omap_common.h
b/arch/arm/include/asm/omap_common.h
index 2daa440432c3..d3e841752844 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -540,6 +540,8 @@ struct volts {
u32 addr;
struct volts_efuse_data efuse;
struct pmic_data *pmic;
+
+ u32 abb_tx_done_mask;
};
struct vcores_data {
diff --git a/board/ti/am57xx/board.c b/board/ti/am57xx/board.c
index 17620896130d..2404eb586757 100644
--- a/board/ti/am57xx/board.c
+++ b/board/ti/am57xx/board.c
@@ -221,6 +221,7 @@ struct vcores_data beagle_x15_volts = {
.mpu.efuse.reg_bits = DRA752_EFUSE_REGBITS,
.mpu.addr = TPS659038_REG_ADDR_SMPS12,
.mpu.pmic = &tps659038,
+ .mpu.abb_tx_done_mask = OMAP_ABB_MPU_TXDONE_MASK,
.eve.value = VDD_EVE_DRA752,
.eve.efuse.reg = STD_FUSE_OPP_VMIN_DSPEVE_NOM,
--
2.8.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] ARM: OMAP5/DRA7: Get rid of control_std_fuse_opp_vdd_mpu_2
This information is already available under vcores->volts.efuse.reg.
There is no reason for duplicating the information since AVS Class 0
definitions are common for OMAP5 and DRA7 and defined with
STD_FUSE_OPP_* macros. This allows a central location of defining
the ABB and voltage definitions especially since they are reused.
This also makes it simpler to prevent mistakes involved when changing
the boot OPP for the device.
Signed-off-by: Nishanth Menon
---
arch/arm/cpu/armv7/omap-common/clocks-common.c | 4 ++--
arch/arm/cpu/armv7/omap5/prcm-regs.c | 2 --
arch/arm/include/asm/omap_common.h | 1 -
3 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c
b/arch/arm/cpu/armv7/omap-common/clocks-common.c
index cb41055b91e6..27e6871fde86 100644
--- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
+++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
@@ -584,7 +584,7 @@ void scale_vcores(struct vcores_data const *vcores)
debug("mpu: %d\n", vcores->mpu.value);
do_scale_vcore(vcores->mpu.addr, vcores->mpu.value, vcores->mpu.pmic);
/* Configure MPU ABB LDO after scale */
- abb_setup((*ctrl)->control_std_fuse_opp_vdd_mpu_2,
+ abb_setup(vcores->mpu.efuse.reg,
(*ctrl)->control_wkup_ldovbb_mpu_voltage_ctrl,
(*prcm)->prm_abbldo_mpu_setup,
(*prcm)->prm_abbldo_mpu_ctrl,
@@ -621,7 +621,7 @@ void scale_vcores(struct vcores_data const *vcores)
do_scale_vcore(vcores->mpu.addr, val, vcores->mpu.pmic);
/* Configure MPU ABB LDO after scale */
- abb_setup((*ctrl)->control_std_fuse_opp_vdd_mpu_2,
+ abb_setup(vcores->mpu.efuse.reg,
(*ctrl)->control_wkup_ldovbb_mpu_voltage_ctrl,
(*prcm)->prm_abbldo_mpu_setup,
(*prcm)->prm_abbldo_mpu_ctrl,
diff --git a/arch/arm/cpu/armv7/omap5/prcm-regs.c
b/arch/arm/cpu/armv7/omap5/prcm-regs.c
index cd289ddd2be3..c55c6af9e566 100644
--- a/arch/arm/cpu/armv7/omap5/prcm-regs.c
+++ b/arch/arm/cpu/armv7/omap5/prcm-regs.c
@@ -297,7 +297,6 @@ struct prcm_regs const omap5_es1_prcm = {
struct omap_sys_ctrl_regs const omap5_ctrl = {
.control_status = 0x4A002134,
- .control_std_fuse_opp_vdd_mpu_2 = 0x4A0021B4,
.control_std_fuse_die_id_0 = 0x4A002200,
.control_std_fuse_die_id_1 = 0x4A002208,
.control_std_fuse_die_id_2 = 0x4A00220C,
@@ -440,7 +439,6 @@ struct omap_sys_ctrl_regs const dra7xx_ctrl = {
.control_srcomp_code_latch = 0x4A002E84,
.control_ddr_control_ext_0 = 0x4A002E88,
.control_padconf_core_base = 0x4A003400,
- .control_std_fuse_opp_vdd_mpu_2 = 0x4A003B20,
.control_port_emif1_sdram_config= 0x4AE0C110,
.control_port_emif1_lpddr2_nvm_config = 0x4AE0C114,
.control_port_emif2_sdram_config= 0x4AE0C118,
diff --git a/arch/arm/include/asm/omap_common.h
b/arch/arm/include/asm/omap_common.h
index 8c85f46db6ef..2daa440432c3 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -363,7 +363,6 @@ struct omap_sys_ctrl_regs {
u32 control_core_mac_id_0_hi;
u32 control_core_mac_id_1_lo;
u32 control_core_mac_id_1_hi;
- u32 control_std_fuse_opp_vdd_mpu_2;
u32 control_phy_power_usb;
u32 control_core_mmr_lock1;
u32 control_core_mmr_lock2;
--
2.8.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] ARM: OMAP5: Enable ABB configuration for MM voltage domain
Since we setup the voltage and frequency for the MM domain, we *must*
setup the ABB configuration needed for the domain as well. If we do not
do this, kernel configuring just the frequency using the default boot
loader configured voltage can fail on many corner lot units.
Reported-by: Richard Woodruff
Signed-off-by: Nishanth Menon
---
arch/arm/cpu/armv7/omap-common/clocks-common.c | 9 +
arch/arm/cpu/armv7/omap5/hw_data.c | 1 +
arch/arm/cpu/armv7/omap5/prcm-regs.c | 4
arch/arm/include/asm/arch-omap5/omap.h | 1 +
arch/arm/include/asm/omap_common.h | 4
5 files changed, 19 insertions(+)
diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c
b/arch/arm/cpu/armv7/omap-common/clocks-common.c
index 8fe695b992b1..da57b385c922 100644
--- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
+++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
@@ -632,6 +632,15 @@ void scale_vcores(struct vcores_data const *vcores)
val = optimize_vcore_voltage(&vcores->mm);
do_scale_vcore(vcores->mm.addr, val, vcores->mm.pmic);
+ /* Configure MM ABB LDO after scale */
+ abb_setup(vcores->mm.efuse.reg,
+ (*ctrl)->control_wkup_ldovbb_mm_voltage_ctrl,
+ (*prcm)->prm_abbldo_mm_setup,
+ (*prcm)->prm_abbldo_mm_ctrl,
+ (*prcm)->prm_irqstatus_mpu,
+ vcores->mm.abb_tx_done_mask,
+ OMAP_ABB_FAST_OPP);
+
val = optimize_vcore_voltage(&vcores->gpu);
do_scale_vcore(vcores->gpu.addr, val, vcores->gpu.pmic);
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c
b/arch/arm/cpu/armv7/omap5/hw_data.c
index a4b31e42e2c3..dfb1df6bce30 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -361,6 +361,7 @@ struct vcores_data omap5430_volts_es2 = {
.mm.value = VDD_MM_ES2,
.mm.addr = SMPS_REG_ADDR_45_IVA,
.mm.pmic = &palmas,
+ .mm.abb_tx_done_mask = OMAP_ABB_MM_TXDONE_MASK,
};
struct vcores_data dra752_volts = {
diff --git a/arch/arm/cpu/armv7/omap5/prcm-regs.c
b/arch/arm/cpu/armv7/omap5/prcm-regs.c
index c55c6af9e566..d126a3223192 100644
--- a/arch/arm/cpu/armv7/omap5/prcm-regs.c
+++ b/arch/arm/cpu/armv7/omap5/prcm-regs.c
@@ -352,6 +352,7 @@ struct omap_sys_ctrl_regs const omap5_ctrl = {
.control_emif1_sdram_config_ext = 0x4AE0C144,
.control_emif2_sdram_config_ext = 0x4AE0C148,
.control_wkup_ldovbb_mpu_voltage_ctrl = 0x4AE0C318,
+ .control_wkup_ldovbb_mm_voltage_ctrl= 0x4AE0C314,
.control_padconf_wkup_base = 0x4AE0C800,
.control_smart1nopmio_padconf_0 = 0x4AE0CDA0,
.control_smart1nopmio_padconf_1 = 0x4AE0CDA4,
@@ -722,6 +723,7 @@ struct prcm_regs const omap5_es2_prcm = {
.cm_l3init_usb_otg_ss1_clkctrl = 0x4a0096f0,
/* prm irqstatus regs */
+ .prm_irqstatus_mpu = 0x4ae06010,
.prm_irqstatus_mpu_2 = 0x4ae06014,
/* l4 wkup regs */
@@ -751,6 +753,8 @@ struct prcm_regs const omap5_es2_prcm = {
.prm_abbldo_mpu_setup = 0x4ae07cdc,
.prm_abbldo_mpu_ctrl = 0x4ae07ce0,
+ .prm_abbldo_mm_setup = 0x4ae07ce4,
+ .prm_abbldo_mm_ctrl = 0x4ae07ce8,
/* SCRM stuff, used by some boards */
.scrm_auxclk0 = 0x4ae0a310,
diff --git a/arch/arm/include/asm/arch-omap5/omap.h
b/arch/arm/include/asm/arch-omap5/omap.h
index 1eeb8d5f626f..cfec5b063c21 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -215,6 +215,7 @@ struct s32ktimer {
/* ABB tranxdone mask */
#define OMAP_ABB_MPU_TXDONE_MASK (0x1 << 7)
+#define OMAP_ABB_MM_TXDONE_MASK(0x1 << 31)
/* ABB efuse masks */
#define OMAP5_ABB_FUSE_VSET_MASK (0x1F << 24)
diff --git a/arch/arm/include/asm/omap_common.h
b/arch/arm/include/asm/omap_common.h
index d3e841752844..14c07fab34ab 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -234,6 +234,7 @@ struct prcm_regs {
u32 cm_l3init_usb_otg_ss1_clkctrl;
u32 cm_l3init_usb_otg_ss2_clkctrl;
+ u32 prm_irqstatus_mpu;
u32 prm_irqstatus_mpu_2;
/* cm2.l4per */
@@ -321,6 +322,8 @@ struct prcm_regs {
u32 prm_vc_cfg_i2c_clk;
u32 prm_abbldo_mpu_setup;
u32 prm_abbldo_mpu_ctrl;
+ u32 prm_abbldo_mm_setup;
+ u32 prm_abbldo_mm_ctrl;
u32 cm_div_m4_dpll_core;
u32 cm_div_m5_dpll_core;
@@ -441,6 +444,7 @@ struct omap_sys_ctrl_regs {
u32 control_emif1_sdram_config_ext;
u32 control_emif2_sdram_config_ext;
u32 control_wkup_ldovbb_mpu_voltage_ctrl;
+ u32 control_wkup_ldovbb_mm_voltage_ctrl;
u32 control_smart1nopmio_padconf_0;
u32 control_smart1nopmio_padconf_1;
u32 control_padconf_mode;
Re: [U-Boot] [PATCH 1/3] SPL: Let spl_parse_image_header() return value
age_header(header); > + err = spl_parse_image_header(header); > + if (err) > + return err; > > spi_flash_read(flash, CONFIG_SYS_SPI_KERNEL_OFFS, >spl_image.size, (void *)spl_image.load_addr); > @@ -81,7 +85,9 @@ int spl_spi_load_image(void) > if (err) > return err; > > - spl_parse_image_header(header); > + err = spl_parse_image_header(header); > + if (err) > + return err; > err = spi_flash_read(flash, CONFIG_SYS_SPI_U_BOOT_OFFS, >spl_image.size, (void *)spl_image.load_addr); > } > diff --git a/include/spl.h b/include/spl.h > index de4f70a..7edfab4 100644 > --- a/include/spl.h > +++ b/include/spl.h > @@ -56,7 +56,7 @@ void preloader_console_init(void); > u32 spl_boot_device(void); > u32 spl_boot_mode(void); > void spl_set_header_raw_uboot(void); > -void spl_parse_image_header(const struct image_header *header); > +int spl_parse_image_header(const struct image_header *header); > void spl_board_prepare_for_linux(void); > void __noreturn jump_to_image_linux(void *arg); > int spl_start_uboot(void); > -- > 2.7.0 > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot -- --- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: OMAP4+: Fix DPLL programming sequence
On 05/23/2016 03:01 AM, Lokesh Vutla wrote:
> All the output clock parameters of a DPLL needs to be programmed before
> locking the DPLL. But it is being configured after locking the DPLL which
> could potentially bypass DPLL. So fixing this sequence.
>
> Reported-by: Richard Woodruff
> Signed-off-by: Lokesh Vutla
> ---
> arch/arm/cpu/armv7/omap-common/clocks-common.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c
> b/arch/arm/cpu/armv7/omap-common/clocks-common.c
> index ef2ac98..2de9935 100644
> --- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
> +++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
> @@ -236,6 +236,8 @@ static void do_setup_dpll(u32 const base, const struct
> dpll_params *params,
> /* Dpll locked with ideal values for nominal opps. */
> debug("\n %s Dpll already locked with ideal"
> "nominal opp values", dpll);
> +
> + bypass_dpll(base);
> goto setup_post_dividers;
> }
> }
> @@ -251,13 +253,13 @@ static void do_setup_dpll(u32 const base, const struct
> dpll_params *params,
>
> writel(temp, &dpll_regs->cm_clksel_dpll);
>
> +setup_post_dividers:
> + setup_post_dividers(base, params);
> +
> /* Lock */
> if (lock)
> do_lock_dpll(base);
>
> -setup_post_dividers:
> - setup_post_dividers(base, params);
> -
> /* Wait till the DPLL locks */
> if (lock)
> wait_for_lock(base);
>
LGTM
Reviewed-by: Nishanth Menon
--
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] serial: 16550: Drop OMAP1510 support
On 05/24/2016 07:13 PM, Marek Vasut wrote: > The CONFIG_OMAP1510 is no longer defined, so remove this dead code. > > Signed-off-by: Marek Vasut > Cc: Tom Rini > Cc: Simon Glass Acked-by: Nishanth Menon -- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: k2g: Configure reset mux to device reset
On 05/26/2016 08:35 AM, Lokesh Vutla wrote:
> BOOTCFG_RSTMUX8 register controls the reset mux associated with the ARM.
> Timer5(dedicated to ARM) when used as WatchDog timer, the events it
> generates are routed to the above mux.
>
> Following are the 3 events that can controlled bt the reset mux:
> - Device Reset
> - An interrupt to the ARM_GIC
> - An interrupt to the ARM_GIC followed by a device reset.
>
> Right now to give a default watchdog behaviour "Device reset" is
> being selected.
>
> Signed-off-by: Lokesh Vutla
> ---
Thanks.
Acked-by: Nishanth Menon
> arch/arm/mach-keystone/include/mach/hardware-k2g.h | 12
> board/ti/ks2_evm/board_k2g.c | 16
> 2 files changed, 28 insertions(+)
>
> diff --git a/arch/arm/mach-keystone/include/mach/hardware-k2g.h
> b/arch/arm/mach-keystone/include/mach/hardware-k2g.h
> index ca2a119..0f6bf61 100644
> --- a/arch/arm/mach-keystone/include/mach/hardware-k2g.h
> +++ b/arch/arm/mach-keystone/include/mach/hardware-k2g.h
> @@ -74,4 +74,16 @@
> #define K2G_GPIO_DIR_OFFSET 0x0
> #define K2G_GPIO_SETDATA_OFFSET 0x8
>
> +/* BOOTCFG RESETMUX8 */
> +#define KS2_RSTMUX8 (KS2_DEVICE_STATE_CTRL_BASE + 0x328)
> +
> +/* RESETMUX register definitions */
> +#define RSTMUX_LOCK8_SHIFT 0x0
> +#define RSTMUX_LOCK8_MASK(0x1 << 0)
> +#define RSTMUX_OMODE8_SHIFT 0x1
> +#define RSTMUX_OMODE8_MASK (0x7 << 1)
> +#define RSTMUX_OMODE8_DEV_RESET 0x2
> +#define RSTMUX_OMODE8_INT0x3
> +#define RSTMUX_OMODE8_INT_AND_DEV_RESET 0x4
> +
> #endif /* __ASM_ARCH_HARDWARE_K2G_H */
> diff --git a/board/ti/ks2_evm/board_k2g.c b/board/ti/ks2_evm/board_k2g.c
> index b62c412..8f16845 100644
> --- a/board/ti/ks2_evm/board_k2g.c
> +++ b/board/ti/ks2_evm/board_k2g.c
> @@ -117,12 +117,28 @@ int board_mmc_init(bd_t *bis)
> #endif
>
> #ifdef CONFIG_BOARD_EARLY_INIT_F
> +
> +static void k2g_reset_mux_config(void)
> +{
> + /* Unlock the reset mux register */
> + clrbits_le32(KS2_RSTMUX8, RSTMUX_LOCK8_MASK);
> +
> + /* Configure BOOTCFG_RSTMUX8 for WDT event to cause a device reset */
> + clrsetbits_le32(KS2_RSTMUX8, RSTMUX_OMODE8_MASK,
> + RSTMUX_OMODE8_DEV_RESET << RSTMUX_OMODE8_SHIFT);
> +
> + /* lock the reset mux register to prevent any spurious writes. */
> + setbits_le32(KS2_RSTMUX8, RSTMUX_LOCK8_MASK);
> +}
> +
> int board_early_init_f(void)
> {
> init_plls();
>
> k2g_mux_config();
>
> + k2g_reset_mux_config();
> +
> /* deassert FLASH_HOLD */
> clrbits_le32(K2G_GPIO1_BANK2_BASE + K2G_GPIO_DIR_OFFSET,
>BIT(9));
>
--
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] board: am57xx: MAINTAINERS: Update for current maintainer
Felipe Balbi has move on from TI and the current email ID is no longer valid. So, replacing with Lokesh. While at it, update missing config file which was untracked. Signed-off-by: Nishanth Menon --- board/ti/am57xx/MAINTAINERS | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/board/ti/am57xx/MAINTAINERS b/board/ti/am57xx/MAINTAINERS index b8ae0199e36c..500bb7a61277 100644 --- a/board/ti/am57xx/MAINTAINERS +++ b/board/ti/am57xx/MAINTAINERS @@ -1,7 +1,8 @@ AM57XX EVM -M: Felipe Balbi +M: Lokesh Vutla S: Maintained F: board/ti/am57xx/ F: include/configs/am57xx_evm.h F: configs/am57xx_evm_defconfig F: configs/am57xx_evm_nodt_defconfig +F: configs/am57xx_hs_evm_defconfig -- 2.9.1.200.gb1ec08f ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] board: am57xx: Fix missing check for beagle_x15
When beagleboard-X15 is booted, we see the following log:
Unidentified board claims BBRDX15_ in eeprom header
This is because of the missing check for x15 (the default) and reports
an error for a valid board configuration. fix the same.
Signed-off-by: Nishanth Menon
---
based on v2016.09-rc2
board/ti/am57xx/board.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/ti/am57xx/board.c b/board/ti/am57xx/board.c
index 927d1364fe46..3c3ec8a74e78 100644
--- a/board/ti/am57xx/board.c
+++ b/board/ti/am57xx/board.c
@@ -342,7 +342,7 @@ static void setup_board_eeprom_env(void)
name = "am57xx_evm";
else if (board_is_am572x_idk())
name = "am572x_idk";
- else
+ else if (!board_is_x15())
printf("Unidentified board claims %s in eeprom header\n",
board_ti_get_name());
--
2.9.1.200.gb1ec08f
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] board: am57xx: Fix missing check for beagle_x15
On Fri, Sep 2, 2016 at 6:04 AM, Lokesh Vutla wrote: > > > On Friday 02 September 2016 01:23 PM, Nishanth Menon wrote: [...] > Instead an entry can be added for x15 like below? So, that future rev of > x15 can be updated > > diff --git a/board/ti/am57xx/board.c b/board/ti/am57xx/board.c > index bc5ff6e..cf095ce 100644 > --- a/board/ti/am57xx/board.c > +++ b/board/ti/am57xx/board.c > @@ -308,7 +308,9 @@ static void setup_board_eeprom_env(void) > if (rc) > goto invalid_eeprom; > > - if (board_is_am572x_evm()) > + if (board_is_x15()) > + name = "beagle_x15"; > + else if (board_is_am572x_evm()) > name = "am57xx_evm"; > else if (board_is_am572x_idk()) > name = "am572x_idk"; Yeah, makes sense to prepare for what we know is incoming anyways... -- --- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] board: am57xx: Fix missing check for beagle_x15
When beagleboard-X15 is booted, we see the following log: Unidentified board claims BBRDX15_ in eeprom header This is because of the missing check for x15 (the default) and reports an error for a valid board configuration. Fix the same. Signed-off-by: Nishanth Menon --- Changes since V1: - move the x15 check higher up in the list. V1: https://patchwork.ozlabs.org/patch/665144/ board/ti/am57xx/board.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/board/ti/am57xx/board.c b/board/ti/am57xx/board.c index 927d1364fe46..64de60254136 100644 --- a/board/ti/am57xx/board.c +++ b/board/ti/am57xx/board.c @@ -338,7 +338,9 @@ static void setup_board_eeprom_env(void) if (rc) goto invalid_eeprom; - if (board_is_am572x_evm()) + if (board_is_x15()) + name = "beagle_x15"; + else if (board_is_am572x_evm()) name = "am57xx_evm"; else if (board_is_am572x_idk()) name = "am572x_idk"; -- 2.9.1.200.gb1ec08f ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/7] Adds support for secure boot on Keystone SoCs (K2E)
On 09/03/2016 11:56 AM, Lokesh Vutla wrote: [...] What is the expectation when you meant abort handler in u-boot? Do you want to clear the abort or something else? report the error and clear the error in u-boot. we should be able to catch errors generated at u-boot level OR rom code level at u-boot. we dont want to detect and hang in kernel - the debug is just painful. -- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] keystone: k2h/e/l: Fix DMA coherency for QM PDSP
On 07/18/2016 10:42 AM, Murali Karicheri wrote:
commit 1f807a9f32aa ("ARM: keystone2: Refactor MSMC macros to avoid
#ifdeffery") refactored code, however K2HKLE_MSMC_SEGMENT_QM_PDSP is
left under a macro KS2_MSMC_SEGMENT_QM_PDSP which is no longer valid.
This, in effect disabled DMA coherency for QM PDSP.
Given that msmc_k2hkle_common_setup is valid for all K2H/K/L/E SoCs,
the #ifdef should been removed in the first place. Do the same.
Signed-off-by: Murali Karicheri
Acked-by: Nishanth Menon
---
arch/arm/mach-keystone/init.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/mach-keystone/init.c b/arch/arm/mach-keystone/init.c
index 3b6d5ef..6e5a1e1 100644
--- a/arch/arm/mach-keystone/init.c
+++ b/arch/arm/mach-keystone/init.c
@@ -101,9 +101,7 @@ static void msmc_k2hkle_common_setup(void)
msmc_share_all_segments(KS2_MSMC_SEGMENT_C6X_0);
msmc_share_all_segments(K2HKLE_MSMC_SEGMENT_ARM);
msmc_share_all_segments(K2HKLE_MSMC_SEGMENT_NETCP);
-#ifdef KS2_MSMC_SEGMENT_QM_PDSP
msmc_share_all_segments(K2HKLE_MSMC_SEGMENT_QM_PDSP);
-#endif
msmc_share_all_segments(K2HKLE_MSMC_SEGMENT_PCIE0);
msmc_share_all_segments(KS2_MSMC_SEGMENT_DEBUG);
}
please add:
Fixes: 1f807a9f32aa ("ARM: keystone2: Refactor MSMC macros to avoid
ifdeffery")
--
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] ti: common: board_detect: Replace hardcoded value with macro
We should have used TI_DEAD_EEPROM_MAGIC in the first place.
Fixes: d3b98a9eb941 ("ti: common: dra7: Add standard access for board
description EEPROM")
Signed-off-by: Nishanth Menon
---
board/ti/common/board_detect.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/ti/common/board_detect.c b/board/ti/common/board_detect.c
index e0ae1a51a6a4..7c552d20656a 100644
--- a/board/ti/common/board_detect.c
+++ b/board/ti/common/board_detect.c
@@ -171,7 +171,7 @@ int __maybe_unused ti_i2c_eeprom_dra7_get(int bus_addr, int
dev_addr)
goto already_read;
/* Initialize with a known bad marker for i2c fails.. */
- ep->header = 0xADEAD12C;
+ ep->header = TI_DEAD_EEPROM_MAGIC;
ep->name[0] = 0x0;
ep->version[0] = 0x0;
ep->serial[0] = 0x0;
--
2.10.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3] ti: common: board_detect: basic fixes for blank eeprom
In some cases where eeprom has not been programmed, Brad reported issues of crash at strcmp against NULL, this series was triggered thanks to issue in manufacturing flow where the mandatory eeprom programming was missed. Nishanth Menon (3): ti: common: board_detect: Replace hardcoded value with macro ti: common: board_detect: Setup initial default value for config as well ti: common: board_detect: Return a valid empty string for un-initialized eeprom board/ti/common/board_detect.c | 16 ++-- board/ti/common/board_detect.h | 6 +++--- 2 files changed, 9 insertions(+), 13 deletions(-) -- 2.10.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] ti: common: board_detect: Setup initial default value for config as well
config should have been initialized along with others as defaults. Signed-off-by: Nishanth Menon --- board/ti/common/board_detect.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/board/ti/common/board_detect.c b/board/ti/common/board_detect.c index 7c552d20656a..13aac2f03037 100644 --- a/board/ti/common/board_detect.c +++ b/board/ti/common/board_detect.c @@ -131,6 +131,7 @@ int __maybe_unused ti_i2c_eeprom_am_get(int bus_addr, int dev_addr) ep->name[0] = 0x0; ep->version[0] = 0x0; ep->serial[0] = 0x0; + ep->config[0] = 0x0; rc = ti_i2c_eeprom_get(bus_addr, dev_addr, TI_EEPROM_HEADER_MAGIC, sizeof(am_ep), (uint8_t *)&am_ep); @@ -175,6 +176,7 @@ int __maybe_unused ti_i2c_eeprom_dra7_get(int bus_addr, int dev_addr) ep->name[0] = 0x0; ep->version[0] = 0x0; ep->serial[0] = 0x0; + ep->config[0] = 0x0; ep->emif1_size = 0; ep->emif2_size = 0; -- 2.10.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] ti: common: board_detect: Return a valid empty string for un-initialized eeprom
Current logic for query of revision, board_name, config returns
NULL. Users of these functions do a direct strncmp to compare.
Unfortunately, as per conventions require two valid strings to compare
against and the current implementation causes a crash when compared
with NULL.
We'd still like to maintain the simplistic usage of these APIs instead
of redundant if (string) res=strncmp(fn(),"cmp",n); flowing all over
the place.
Hence, since the version, name and config is already pre-initialized
with empty string, just dont check for invalid header in the first
place and return the empty string to the caller.
Reported-by: Brad Griffis
Signed-off-by: Nishanth Menon
---
board/ti/common/board_detect.c | 12 +++-
board/ti/common/board_detect.h | 6 +++---
2 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/board/ti/common/board_detect.c b/board/ti/common/board_detect.c
index 13aac2f03037..6e7ca9196d22 100644
--- a/board/ti/common/board_detect.c
+++ b/board/ti/common/board_detect.c
@@ -231,9 +231,7 @@ char * __maybe_unused board_ti_get_rev(void)
{
struct ti_common_eeprom *ep = TI_EEPROM_DATA;
- if (ep->header == TI_DEAD_EEPROM_MAGIC)
- return NULL;
-
+ /* if ep->header == TI_DEAD_EEPROM_MAGIC, this is empty already */
return ep->version;
}
@@ -241,9 +239,7 @@ char * __maybe_unused board_ti_get_config(void)
{
struct ti_common_eeprom *ep = TI_EEPROM_DATA;
- if (ep->header == TI_DEAD_EEPROM_MAGIC)
- return NULL;
-
+ /* if ep->header == TI_DEAD_EEPROM_MAGIC, this is empty already */
return ep->config;
}
@@ -251,9 +247,7 @@ char * __maybe_unused board_ti_get_name(void)
{
struct ti_common_eeprom *ep = TI_EEPROM_DATA;
- if (ep->header == TI_DEAD_EEPROM_MAGIC)
- return NULL;
-
+ /* if ep->header == TI_DEAD_EEPROM_MAGIC, this is empty already */
return ep->name;
}
diff --git a/board/ti/common/board_detect.h b/board/ti/common/board_detect.h
index eb17f6f52a12..2ded3ed7764b 100644
--- a/board/ti/common/board_detect.h
+++ b/board/ti/common/board_detect.h
@@ -141,7 +141,7 @@ bool board_ti_rev_is(char *rev_tag, int cmp_len);
/**
* board_ti_get_rev() - Get board revision for TI EVMs
*
- * Return: NULL if eeprom was'nt read.
+ * Return: Empty string if eeprom was'nt read.
*Board revision otherwise
*/
char *board_ti_get_rev(void);
@@ -149,7 +149,7 @@ char *board_ti_get_rev(void);
/**
* board_ti_get_config() - Get board config for TI EVMs
*
- * Return: NULL if eeprom was'nt read.
+ * Return: Empty string if eeprom was'nt read.
*Board config otherwise
*/
char *board_ti_get_config(void);
@@ -157,7 +157,7 @@ char *board_ti_get_config(void);
/**
* board_ti_get_name() - Get board name for TI EVMs
*
- * Return: NULL if eeprom was'nt read.
+ * Return: Empty string if eeprom was'nt read.
*Board name otherwise
*/
char *board_ti_get_name(void);
--
2.10.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] dm: part: fix missing driver name in debug print
Fixes the following warning with PART_DEBUG enabled:
disk/part.c: In function ‘get_partition_info’:
disk/part.c:372:3: warning: format ‘%s’ expects a matching ‘char *’ argument
[-Wformat]
Signed-off-by: Nishanth Menon
---
disk/part.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/disk/part.c b/disk/part.c
index 2a460503922c..0caf760f5257 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -369,7 +369,8 @@ int part_get_info(struct blk_desc *dev_desc, int part,
return -EPROTONOSUPPORT;
}
if (!drv->get_info) {
- PRINTF("## Driver %s does not have the get_info() method\n");
+ PRINTF("## Driver %s does not have the get_info() method\n",
+ drv->name);
return -ENOSYS;
}
if (drv->get_info(dev_desc, part, info) == 0) {
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: arm: Make sure to include u_boot_list_*_part_disk_*
On 03/15/2016 04:58 PM, Tom Rini wrote: > Starting with 96e5b03 we use a linker list for partition table > information. However since we use this in SPL we need to make sure that > the SPL linker scripts include these as well. > > Cc: Nishanth Menon > Cc: Michal Simek > Cc: Simon Glass > Reported-by: Nishanth Menon Tested-by: Nishanth Menon Thanks for the patch.. -- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/7] ARM: DRA7: hwdata: Update ioreg data for DRA72 SR2.0
Based on data from EMIF configuration tool 1.1.1. Expected update for
CTRL_WKUP_EMIF1_SDRAM_CONFIG_EXT in the next revision of the tool has
been incorporated as well.
Signed-off-by: Nishanth Menon
---
arch/arm/cpu/armv7/omap5/hw_data.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c
b/arch/arm/cpu/armv7/omap5/hw_data.c
index 93d1efbca17d..b69c0d13715a 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -743,6 +743,18 @@ const struct ctrl_ioregs ioregs_dra72x_es1 = {
.ctrl_ddr_ctrl_ext_0 = 0xA200,
};
+const struct ctrl_ioregs ioregs_dra72x_es2 = {
+ .ctrl_ddrch = 0x40404040,
+ .ctrl_lpddr2ch = 0x40404040,
+ .ctrl_ddr3ch = 0x60606060,
+ .ctrl_ddrio_0 = 0x00094A40,
+ .ctrl_ddrio_1 = 0x,
+ .ctrl_ddrio_2 = 0x,
+ .ctrl_emif_sdram_config_ext = 0x0001C1A7,
+ .ctrl_emif_sdram_config_ext_final = 0x0001C1A7,
+ .ctrl_ddr_ctrl_ext_0 = 0xA200,
+};
+
void __weak hw_data_init(void)
{
u32 omap_rev = omap_revision();
@@ -808,9 +820,11 @@ void get_ioregs(const struct ctrl_ioregs **regs)
*regs = &ioregs_dra7xx_es1;
break;
case DRA722_ES1_0:
- case DRA722_ES2_0:
*regs = &ioregs_dra72x_es1;
break;
+ case DRA722_ES2_0:
+ *regs = &ioregs_dra72x_es2;
+ break;
default:
printf("\n INVALID OMAP REVISION ");
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/7] board: ti: DRA72: revC evm: Update sdram timing configuration for SR2.0
From: Ravi Babu
DDR configuration has changes from SR1.1 based Rev-A/B version of evm
to the SR2.0 based Rev C of the EVM. Rev C evm now uses the higher
density MT41K512M8RH-125-AAT:E (IT) which is of size 2GB.
Update the DDR configuration based on data from EMIF configuration
tool 1.1.1. NOTE: we use eeprom information (ram_size) to update the
configuration.
Tested-by: Vishal Mahaveer
Signed-off-by: Ravi Babu
Signed-off-by: Nishanth Menon
---
board/ti/dra7xx/evm.c | 59 +
1 file changed, 55 insertions(+), 4 deletions(-)
diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index 97174c8bb812..0461b53ba2f8 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -32,8 +32,11 @@
#include "../common/board_detect.h"
#define board_is_dra74x_evm() board_ti_is("5777xCPU")
+#define board_is_dra72x_evm() board_ti_is("DRA72x-T")
#define board_is_dra74x_revh_or_later() board_is_dra74x_evm() && \
(strncmp("H", board_ti_get_rev(), 1) <= 0)
+#define board_is_dra72x_revc_or_later() board_is_dra72x_evm() && \
+ (strncmp("C", board_ti_get_rev(), 1) <= 0)
#define board_ti_get_emif_size() board_ti_get_emif1_size() + \
board_ti_get_emif2_size()
@@ -127,6 +130,31 @@ static const struct emif_regs
emif_1_regs_ddr3_666_mhz_1cs_dra_es1 = {
.emif_rd_wr_exec_thresh = 0x0305
};
+const struct emif_regs emif_1_regs_ddr3_666_mhz_1cs_dra_es2 = {
+ .sdram_config_init = 0x61862BB2,
+ .sdram_config = 0x61862BB2,
+ .sdram_config2 = 0x,
+ .ref_ctrl = 0x514D,
+ .ref_ctrl_final = 0x144A,
+ .sdram_tim1 = 0xD1137824,
+ .sdram_tim2 = 0x30B37FE3,
+ .sdram_tim3 = 0x409F8AD8,
+ .read_idle_ctrl = 0x0005,
+ .zq_config = 0x5007190B,
+ .temp_alert_config = 0x,
+ .emif_ddr_phy_ctlr_1_init = 0x0824400E,
+ .emif_ddr_phy_ctlr_1= 0x0E24400E,
+ .emif_ddr_ext_phy_ctrl_1= 0x04040100,
+ .emif_ddr_ext_phy_ctrl_2= 0x006B009F,
+ .emif_ddr_ext_phy_ctrl_3= 0x006B00A2,
+ .emif_ddr_ext_phy_ctrl_4= 0x006B00A8,
+ .emif_ddr_ext_phy_ctrl_5= 0x006B00A8,
+ .emif_rd_wr_lvl_rmp_win = 0x,
+ .emif_rd_wr_lvl_rmp_ctl = 0x8000,
+ .emif_rd_wr_lvl_ctl = 0x,
+ .emif_rd_wr_exec_thresh = 0x0305
+};
+
const struct emif_regs emif1_ddr3_532_mhz_1cs_2G = {
.sdram_config_init = 0x61851ab2,
.sdram_config = 0x61851ab2,
@@ -203,7 +231,11 @@ void emif_get_reg_dump(u32 emif_nr, const struct emif_regs
**regs)
}
break;
case DRA722_ES1_0:
- *regs = &emif_1_regs_ddr3_666_mhz_1cs_dra_es1;
+ case DRA722_ES2_0:
+ if (ram_size < CONFIG_MAX_MEM_MAPPED)
+ *regs = &emif_1_regs_ddr3_666_mhz_1cs_dra_es1;
+ else
+ *regs = &emif_1_regs_ddr3_666_mhz_1cs_dra_es2;
break;
default:
*regs = &emif1_ddr3_532_mhz_1cs;
@@ -234,6 +266,18 @@ const struct dmm_lisa_map_regs lisa_map_dra7_2GB = {
.is_ma_present = 0x1
};
+/*
+ * DRA722 EVM EMIF1 2GB CONFIGURATION
+ * EMIF1 4 devices of 512Mb x 8 Micron
+ */
+const struct dmm_lisa_map_regs lisa_map_2G_x_4 = {
+ .dmm_lisa_map_0 = 0x0,
+ .dmm_lisa_map_1 = 0x0,
+ .dmm_lisa_map_2 = 0x80700100,
+ .dmm_lisa_map_3 = 0xFF020100,
+ .is_ma_present = 0x1
+};
+
void emif_get_dmm_regs(const struct dmm_lisa_map_regs **dmm_lisa_regs)
{
u64 ram_size;
@@ -250,8 +294,13 @@ void emif_get_dmm_regs(const struct dmm_lisa_map_regs
**dmm_lisa_regs)
*dmm_lisa_regs = &lisa_map_dra7_1536MB;
break;
case DRA722_ES1_0:
+ case DRA722_ES2_0:
default:
- *dmm_lisa_regs = &lisa_map_2G_x_2;
+ if (ram_size < CONFIG_MAX_MEM_MAPPED)
+ *dmm_lisa_regs = &lisa_map_2G_x_2;
+ else
+ *dmm_lisa_regs = &lisa_map_2G_x_4;
+ break;
}
}
@@ -324,8 +373,10 @@ void do_board_detect(void)
if (board_is_dra74x_evm()) {
bname = "DRA74x EVM";
- /* If EEPROM is not populated */
+ } else if (board_is_dra72x_evm()) {
+ bname = "DRA72x EVM";
} else {
+ /* If EEPROM is not populated */
[U-Boot] [PATCH 1/7] ARM: DRA72x: Add support for detection of SR2.0
From: Ravi Babu Add support for detection of SR2.0 version of DRA72x family of processors. Signed-off-by: Ravi Babu Signed-off-by: Nishanth Menon --- arch/arm/cpu/armv7/omap5/hw_data.c |2 ++ arch/arm/cpu/armv7/omap5/hwinit.c |3 +++ arch/arm/cpu/armv7/omap5/sdram.c |2 ++ arch/arm/include/asm/arch-omap5/omap.h |1 + arch/arm/include/asm/omap_common.h |1 + 5 files changed, 9 insertions(+) diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c b/arch/arm/cpu/armv7/omap5/hw_data.c index 7f8c0a423bad..93d1efbca17d 100644 --- a/arch/arm/cpu/armv7/omap5/hw_data.c +++ b/arch/arm/cpu/armv7/omap5/hw_data.c @@ -775,6 +775,7 @@ void __weak hw_data_init(void) break; case DRA722_ES1_0: + case DRA722_ES2_0: *prcm = &dra7xx_prcm; *dplls_data = &dra72x_dplls; *omap_vcores = &dra722_volts; @@ -807,6 +808,7 @@ void get_ioregs(const struct ctrl_ioregs **regs) *regs = &ioregs_dra7xx_es1; break; case DRA722_ES1_0: + case DRA722_ES2_0: *regs = &ioregs_dra72x_es1; break; diff --git a/arch/arm/cpu/armv7/omap5/hwinit.c b/arch/arm/cpu/armv7/omap5/hwinit.c index 8f184df2abb7..e3ac8bbe9524 100644 --- a/arch/arm/cpu/armv7/omap5/hwinit.c +++ b/arch/arm/cpu/armv7/omap5/hwinit.c @@ -373,6 +373,9 @@ void init_omap_revision(void) case DRA722_CONTROL_ID_CODE_ES1_0: *omap_si_rev = DRA722_ES1_0; break; + case DRA722_CONTROL_ID_CODE_ES2_0: + *omap_si_rev = DRA722_ES2_0; + break; default: *omap_si_rev = OMAP5430_SILICON_ID_INVALID; } diff --git a/arch/arm/cpu/armv7/omap5/sdram.c b/arch/arm/cpu/armv7/omap5/sdram.c index 7dc5bb7e4a4b..5cf360c41468 100644 --- a/arch/arm/cpu/armv7/omap5/sdram.c +++ b/arch/arm/cpu/armv7/omap5/sdram.c @@ -438,6 +438,7 @@ void __weak emif_get_ext_phy_ctrl_const_regs(u32 emif_nr, } break; case DRA722_ES1_0: + case DRA722_ES2_0: *regs = dra_ddr3_ext_phy_ctrl_const_base_666MHz; *size = ARRAY_SIZE(dra_ddr3_ext_phy_ctrl_const_base_666MHz); break; @@ -670,6 +671,7 @@ const struct read_write_regs *get_bug_regs(u32 *iterations) case DRA752_ES1_1: case DRA752_ES2_0: case DRA722_ES1_0: + case DRA722_ES2_0: bug_00339_regs_ptr = dra_bug_00339_regs; *iterations = sizeof(dra_bug_00339_regs)/ sizeof(dra_bug_00339_regs[0]); diff --git a/arch/arm/include/asm/arch-omap5/omap.h b/arch/arm/include/asm/arch-omap5/omap.h index b5b3838f4500..1eeb8d5f626f 100644 --- a/arch/arm/include/asm/arch-omap5/omap.h +++ b/arch/arm/include/asm/arch-omap5/omap.h @@ -60,6 +60,7 @@ #define DRA752_CONTROL_ID_CODE_ES1_1 0x1B99002F #define DRA752_CONTROL_ID_CODE_ES2_0 0x2B99002F #define DRA722_CONTROL_ID_CODE_ES1_0 0x0B9BC02F +#define DRA722_CONTROL_ID_CODE_ES2_0 0x1B9BC02F /* UART */ #define UART1_BASE (OMAP54XX_L4_PER_BASE + 0x6a000) diff --git a/arch/arm/include/asm/omap_common.h b/arch/arm/include/asm/omap_common.h index aef31266ce9e..8c85f46db6ef 100644 --- a/arch/arm/include/asm/omap_common.h +++ b/arch/arm/include/asm/omap_common.h @@ -700,6 +700,7 @@ static inline u8 is_dra72x(void) #define DRA752_ES1_1 0x07520110 #define DRA752_ES2_0 0x07520200 #define DRA722_ES1_0 0x07220100 +#define DRA722_ES2_0 0x07220200 /* * SRAM scratch space entries -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/7] ARM: DRA72: sdram: Update sdram ext phy configuration for SR2.0
Based on data from EMIF configuration tool 1.1.1.
Signed-off-by: Nishanth Menon
---
arch/arm/cpu/armv7/omap5/sdram.c | 44 +-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/omap5/sdram.c b/arch/arm/cpu/armv7/omap5/sdram.c
index 5cf360c41468..7712923d8572 100644
--- a/arch/arm/cpu/armv7/omap5/sdram.c
+++ b/arch/arm/cpu/armv7/omap5/sdram.c
@@ -398,6 +398,45 @@ dra_ddr3_ext_phy_ctrl_const_base_666MHz[] = {
0x0
};
+const u32 dra_ddr3_ext_phy_ctrl_const_base_666MHz_es2[] = {
+ 0x04040100,
+ 0x006B009F,
+ 0x006B00A2,
+ 0x006B00A8,
+ 0x006B00A8,
+ 0x006B00B2,
+ 0x002F002F,
+ 0x002F002F,
+ 0x002F002F,
+ 0x002F002F,
+ 0x002F002F,
+ 0x00600073,
+ 0x00600071,
+ 0x0060007C,
+ 0x0060007E,
+ 0x00600084,
+ 0x00400053,
+ 0x00400051,
+ 0x0040005C,
+ 0x0040005E,
+ 0x00400064,
+ 0x00800080,
+ 0x00800080,
+ 0x40010080,
+ 0x08102040,
+ 0x005B008F,
+ 0x005B0092,
+ 0x005B0098,
+ 0x005B0098,
+ 0x005B00A2,
+ 0x00300043,
+ 0x00300041,
+ 0x0030004C,
+ 0x0030004E,
+ 0x00300054,
+ 0x0077
+};
+
const struct lpddr2_mr_regs mr_regs = {
.mr1= MR1_BL_8_BT_SEQ_WRAP_EN_NWR_8,
.mr2= 0x6,
@@ -438,10 +477,13 @@ void __weak emif_get_ext_phy_ctrl_const_regs(u32 emif_nr,
}
break;
case DRA722_ES1_0:
- case DRA722_ES2_0:
*regs = dra_ddr3_ext_phy_ctrl_const_base_666MHz;
*size = ARRAY_SIZE(dra_ddr3_ext_phy_ctrl_const_base_666MHz);
break;
+ case DRA722_ES2_0:
+ *regs = dra_ddr3_ext_phy_ctrl_const_base_666MHz_es2;
+ *size = ARRAY_SIZE(dra_ddr3_ext_phy_ctrl_const_base_666MHz_es2);
+ break;
default:
*regs = ddr3_ext_phy_ctrl_const_base_es2;
*size = ARRAY_SIZE(ddr3_ext_phy_ctrl_const_base_es2);
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/7] ARM: OMAP5/DRA7: Expose do_set_iodelay
do_set_iodelay can now be used from board files based on needs of the
platforms variation they have.
Signed-off-by: Nishanth Menon
---
arch/arm/cpu/armv7/omap5/dra7xx_iodelay.c|4 ++--
arch/arm/include/asm/arch-omap5/dra7xx_iodelay.h |2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap5/dra7xx_iodelay.c
b/arch/arm/cpu/armv7/omap5/dra7xx_iodelay.c
index 744950f01bd9..87987308aced 100644
--- a/arch/arm/cpu/armv7/omap5/dra7xx_iodelay.c
+++ b/arch/arm/cpu/armv7/omap5/dra7xx_iodelay.c
@@ -138,8 +138,8 @@ static u32 get_cfg_reg(u16 a_delay, u16 g_delay, u32 cpde,
u32 fpde)
return reg;
}
-static int do_set_iodelay(u32 base, struct iodelay_cfg_entry const *array,
- int niodelays)
+int do_set_iodelay(u32 base, struct iodelay_cfg_entry const *array,
+ int niodelays)
{
struct iodelay_cfg_entry *iodelay = (struct iodelay_cfg_entry *)array;
u32 reg, cpde, fpde, i;
diff --git a/arch/arm/include/asm/arch-omap5/dra7xx_iodelay.h
b/arch/arm/include/asm/arch-omap5/dra7xx_iodelay.h
index 0de8a800c1a2..c99700403914 100644
--- a/arch/arm/include/asm/arch-omap5/dra7xx_iodelay.h
+++ b/arch/arm/include/asm/arch-omap5/dra7xx_iodelay.h
@@ -86,4 +86,6 @@ void __recalibrate_iodelay(struct pad_conf_entry const *pad,
int npads,
int __recalibrate_iodelay_start(void);
void __recalibrate_iodelay_end(int ret);
+int do_set_iodelay(u32 base, struct iodelay_cfg_entry const *array,
+ int niodelays);
#endif
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 7/7] board: ti: DRA7: Add DRA72-rev C evm pinmux
Add the pinmux data for rev C evm. This is different from previous
revisions of the platform thanks to the deltas introduced both from
silicon side and from SoC side.
Based on J6EcoES2_EVM_Base_Config-20160309b and PCT-DRA72x-v1.3.0.7 for
SR2.0 silicon.
Signed-off-by: Nishanth Menon
---
board/ti/dra7xx/evm.c | 44 ---
board/ti/dra7xx/mux_data.h | 102 +++-
2 files changed, 110 insertions(+), 36 deletions(-)
diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index 0461b53ba2f8..d975f8c575ab 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -398,16 +398,29 @@ void set_muxconf_regs_essential(void)
#ifdef CONFIG_IODELAY_RECALIBRATION
void recalibrate_iodelay(void)
{
- struct pad_conf_entry const *pads;
+ struct pad_conf_entry const *pads, *delta_pads = NULL;
struct iodelay_cfg_entry const *iodelay;
- int npads, niodelays;
+ int npads, niodelays, delta_npads = 0;
+ int ret;
switch (omap_revision()) {
case DRA722_ES1_0:
- pads = dra72x_core_padconf_array;
- npads = ARRAY_SIZE(dra72x_core_padconf_array);
- iodelay = dra72_iodelay_cfg_array;
- niodelays = ARRAY_SIZE(dra72_iodelay_cfg_array);
+ case DRA722_ES2_0:
+ pads = dra72x_core_padconf_array_common;
+ npads = ARRAY_SIZE(dra72x_core_padconf_array_common);
+ if (board_is_dra72x_revc_or_later()) {
+ delta_pads = dra72x_rgmii_padconf_array_revc;
+ delta_npads =
+ ARRAY_SIZE(dra72x_rgmii_padconf_array_revc);
+ iodelay = dra72_iodelay_cfg_array_revc;
+ niodelays = ARRAY_SIZE(dra72_iodelay_cfg_array_revc);
+ } else {
+ delta_pads = dra72x_rgmii_padconf_array_revb;
+ delta_npads =
+ ARRAY_SIZE(dra72x_rgmii_padconf_array_revb);
+ iodelay = dra72_iodelay_cfg_array_revb;
+ niodelays = ARRAY_SIZE(dra72_iodelay_cfg_array_revb);
+ }
break;
case DRA752_ES1_0:
case DRA752_ES1_1:
@@ -427,7 +440,24 @@ void recalibrate_iodelay(void)
RGMII1_ID_MODE_N_MASK);
break;
}
- __recalibrate_iodelay(pads, npads, iodelay, niodelays);
+ /* Setup I/O isolation */
+ ret = __recalibrate_iodelay_start();
+ if (ret)
+ goto err;
+
+ /* Do the muxing here */
+ do_set_mux32((*ctrl)->control_padconf_core_base, pads, npads);
+
+ /* Now do the weird minor deltas that should be safe */
+ if (delta_npads)
+ do_set_mux32((*ctrl)->control_padconf_core_base,
+delta_pads, delta_npads);
+
+ /* Setup IOdelay configuration */
+ ret = do_set_iodelay((*ctrl)->iodelay_config_base, iodelay, niodelays);
+err:
+ /* Closeup.. remove isolation */
+ __recalibrate_iodelay_end(ret);
}
#endif
diff --git a/board/ti/dra7xx/mux_data.h b/board/ti/dra7xx/mux_data.h
index 6db11a2bbb88..34a05dd6bd86 100644
--- a/board/ti/dra7xx/mux_data.h
+++ b/board/ti/dra7xx/mux_data.h
@@ -12,7 +12,7 @@
#include
-const struct pad_conf_entry dra72x_core_padconf_array[] = {
+const struct pad_conf_entry dra72x_core_padconf_array_common[] = {
{GPMC_AD0, (M3 | PIN_INPUT)}, /* gpmc_ad0.vout3_d0 */
{GPMC_AD1, (M3 | PIN_INPUT)}, /* gpmc_ad1.vout3_d1 */
{GPMC_AD2, (M3 | PIN_INPUT)}, /* gpmc_ad2.vout3_d2 */
@@ -104,37 +104,11 @@ const struct pad_conf_entry dra72x_core_padconf_array[] =
{
{VOUT1_D23, (M0 | PIN_INPUT_PULLDOWN)}, /* vout1_d23.vout1_d23 */
{MDIO_MCLK, (M0 | PIN_INPUT_PULLUP | SLEWCONTROL)}, /*
mdio_mclk.mdio_mclk */
{MDIO_D, (M0 | PIN_INPUT_PULLUP | SLEWCONTROL)},/*
mdio_d.mdio_d */
- {RGMII0_TXC, (M0 | PIN_OUTPUT | MANUAL_MODE)}, /*
rgmii0_txc.rgmii0_txc */
- {RGMII0_TXCTL, (M0 | PIN_OUTPUT | MANUAL_MODE)},/*
rgmii0_txctl.rgmii0_txctl */
- {RGMII0_TXD3, (M0 | PIN_OUTPUT | MANUAL_MODE)}, /*
rgmii0_txd3.rgmii0_txd3 */
- {RGMII0_TXD2, (M0 | PIN_OUTPUT | MANUAL_MODE)}, /*
rgmii0_txd2.rgmii0_txd2 */
- {RGMII0_TXD1, (M0 | PIN_OUTPUT | MANUAL_MODE)}, /*
rgmii0_txd1.rgmii0_txd1 */
- {RGMII0_TXD0, (M0 | PIN_OUTPUT | MANUAL_MODE)}, /*
rgmii0_txd0.rgmii0_txd0 */
- {RGMII0_RXC, (M0 | PIN_INPUT | MANUAL_MODE)}, /*
rgmii0_rxc.rgmii0_rxc */
- {RGMII0_RXCTL, (M0 | PIN_INPUT | MANUAL_MODE)}, /*
rgmii0_rxctl.rgmii0_rxctl */
- {RGMII0_RXD3, (M0 | PIN_INPUT | MANUAL_MODE)}, /*
rgmii0_rxd3.rgmii0_rxd3 */
- {RGMII0_RXD2, (M0 | PIN_INPUT | MANUAL_MODE)}, /*
rgmii0_rxd2.rgmii0_rxd2 */
- {RGMII0_RXD1, (M0 | PIN_INPUT | MANUAL_MODE)}, /*
rgmii0_rxd1.rg
[U-Boot] [PATCH 5/7] ARM: OMAP5/DRA7: Split iodelay functionality into sub steps
Since many platforms may need different pad configuration required
depending on variation of the platform with minor deltas, it is
easier to maintain a sub step based approach to allow for pin mux
and iodelay configuration which may depend on the platform variations
and need to be done in IO isolation.
While we retain the older __recalibrate_iodelay function which provides
a ready sequencing, __recalibrate_iodelay_start and
__recalibrate_iodelay_end may be alternatively used now and the callers
will be responsible for the correct sequencing of operations.
Signed-off-by: Nishanth Menon
---
arch/arm/cpu/armv7/omap5/dra7xx_iodelay.c| 64 +-
arch/arm/include/asm/arch-omap5/dra7xx_iodelay.h |2 +
2 files changed, 52 insertions(+), 14 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap5/dra7xx_iodelay.c
b/arch/arm/cpu/armv7/omap5/dra7xx_iodelay.c
index 9fa6e6991f0e..744950f01bd9 100644
--- a/arch/arm/cpu/armv7/omap5/dra7xx_iodelay.c
+++ b/arch/arm/cpu/armv7/omap5/dra7xx_iodelay.c
@@ -166,16 +166,14 @@ static int do_set_iodelay(u32 base, struct
iodelay_cfg_entry const *array,
return 0;
}
-void __recalibrate_iodelay(struct pad_conf_entry const *pad, int npads,
- struct iodelay_cfg_entry const *iodelay,
- int niodelays)
+int __recalibrate_iodelay_start(void)
{
int ret = 0;
/* IO recalibration should be done only from SRAM */
if (OMAP_INIT_CONTEXT_SPL != omap_hw_init_context()) {
puts("IODELAY recalibration called from invalid context - use
only from SPL in SRAM\n");
- return;
+ return -1;
}
/* unlock IODELAY CONFIG registers */
@@ -191,23 +189,27 @@ void __recalibrate_iodelay(struct pad_conf_entry const
*pad, int npads,
goto err;
ret = update_delay_mechanism((*ctrl)->iodelay_config_base);
- if (ret)
- goto err;
- /* Configure Mux settings */
- do_set_mux32((*ctrl)->control_padconf_core_base, pad, npads);
+err:
+ return ret;
+}
- /* Configure Manual IO timing modes */
- ret = do_set_iodelay((*ctrl)->iodelay_config_base, iodelay, niodelays);
- if (ret)
- goto err;
+void __recalibrate_iodelay_end(int ret)
+{
- ret = isolate_io(DEISOLATE_IO);
+ /* IO recalibration should be done only from SRAM */
+ if (OMAP_INIT_CONTEXT_SPL != omap_hw_init_context()) {
+ puts("IODELAY recalibration called from invalid context - use
only from SPL in SRAM\n");
+ return;
+ }
+
+ if (!ret)
+ ret = isolate_io(DEISOLATE_IO);
-err:
/* lock IODELAY CONFIG registers */
writel(CFG_IODELAY_LOCK_KEY, (*ctrl)->iodelay_config_base +
CFG_REG_8_OFFSET);
+
/*
* UART cannot be used during IO recalibration sequence as IOs are in
* isolation. So error handling and debug prints are done after
@@ -232,7 +234,41 @@ err:
case ERR_FPDE:
puts("IODELAY: FPDE calculation failed\n");
break;
+ case -1:
+ puts("IODELAY: Wrong Context call?\n");
+ break;
default:
debug("IODELAY: IO delay recalibration successfully
completed\n");
}
+
+ return;
+}
+
+void __recalibrate_iodelay(struct pad_conf_entry const *pad, int npads,
+ struct iodelay_cfg_entry const *iodelay,
+ int niodelays)
+{
+ int ret = 0;
+
+ /* IO recalibration should be done only from SRAM */
+ if (OMAP_INIT_CONTEXT_SPL != omap_hw_init_context()) {
+ puts("IODELAY recalibration called from invalid context - use
only from SPL in SRAM\n");
+ return;
+ }
+
+ ret = __recalibrate_iodelay_start();
+ if (ret)
+ goto err;
+
+ /* Configure Mux settings */
+ do_set_mux32((*ctrl)->control_padconf_core_base, pad, npads);
+
+ /* Configure Manual IO timing modes */
+ ret = do_set_iodelay((*ctrl)->iodelay_config_base, iodelay, niodelays);
+ if (ret)
+ goto err;
+
+err:
+ __recalibrate_iodelay_end(ret);
+
}
diff --git a/arch/arm/include/asm/arch-omap5/dra7xx_iodelay.h
b/arch/arm/include/asm/arch-omap5/dra7xx_iodelay.h
index 4cd0a3cc80d0..0de8a800c1a2 100644
--- a/arch/arm/include/asm/arch-omap5/dra7xx_iodelay.h
+++ b/arch/arm/include/asm/arch-omap5/dra7xx_iodelay.h
@@ -83,5 +83,7 @@
void __recalibrate_iodelay(struct pad_conf_entry const *pad, int npads,
struct iodelay_cfg_entry const *iodelay,
int niodelays);
+int __recalibrate_iodelay_start(void);
+void __recalibrate_iodelay_end(int ret);
#endif
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/7] board: ti: DRA72: Add support for SR2.0 rev C evm
Hi, The following series adds support for DRA72x SoC and enables support for TI DRA72-evm rev C. Rev C evm has a few changes w.r.t. rev A/B (SR1.0 based SoC), including newer DDR, newer ethernet PHY(2 ports enabled), very few pin mux changes, etc. Ethernet support is a follow on series that should follow once we have base support in place. Series based on: master41bccb814285 spi: omap3: Fix multiple definition of 'priv' requires: https://patchwork.ozlabs.org/patch/597873/ for boot. Bootlog: rev C: http://pastebin.ubuntu.com/15398047/ rev B: http://pastebin.ubuntu.com/15398054/ Nishanth Menon (5): ARM: DRA7: hwdata: Update ioreg data for DRA72 SR2.0 ARM: DRA72: sdram: Update sdram ext phy configuration for SR2.0 ARM: OMAP5/DRA7: Split iodelay functionality into sub steps ARM: OMAP5/DRA7: Expose do_set_iodelay board: ti: DRA7: Add DRA72-rev C evm pinmux Ravi Babu (2): ARM: DRA72x: Add support for detection of SR2.0 board: ti: DRA72: revC evm: Update sdram timing configuration for SR2.0 arch/arm/cpu/armv7/omap5/dra7xx_iodelay.c| 68 ++ arch/arm/cpu/armv7/omap5/hw_data.c | 16 arch/arm/cpu/armv7/omap5/hwinit.c|3 + arch/arm/cpu/armv7/omap5/sdram.c | 44 + arch/arm/include/asm/arch-omap5/dra7xx_iodelay.h |4 + arch/arm/include/asm/arch-omap5/omap.h |1 + arch/arm/include/asm/omap_common.h |1 + board/ti/dra7xx/evm.c| 103 +++--- board/ti/dra7xx/mux_data.h | 102 +++-- 9 files changed, 286 insertions(+), 56 deletions(-) -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] ARM: keystone2: Fix missing privilege ID
Looks like Keystone2 platform may have quite a few missing configurations for various SoC variants. We need mark each of these id as shared in corresponding registers as well, without doing this, drivers fail inexplicably since the drivers seem to expect SoC wide coherency capability - which needs to be configured explicitly. Bootlog: k2g: http://pastebin.ubuntu.com/15480089/ k2hk: http://pastebin.ubuntu.com/15480090/ also tested on an slightly older bootloader on K2E/K2L as well: k2g: http://pastebin.ubuntu.com/15475588/ k2hk: http://pastebin.ubuntu.com/15475589/ k2l: http://pastebin.ubuntu.com/15478358/ k2e: http://pastebin.ubuntu.com/15478332/ This series is based on: master 0764f24ae6bc net: Move CONFIG_RTL8169 to Kconfig NOTE: K2G still requires additional patches for fixing NAND to prevent data abort being registered early in the boot by u-boot wrong access to GPMC. (testing was performed using out-of-tree solution for this) Nishanth Menon (2): ARM: keystone2: Refactor MSMC macros to avoid #ifdeffery ARM: keystone2: Add missing privilege ID settings arch/arm/mach-keystone/include/mach/hardware-k2e.h | 3 - arch/arm/mach-keystone/include/mach/hardware-k2l.h | 3 - arch/arm/mach-keystone/include/mach/hardware.h | 50 --- arch/arm/mach-keystone/init.c | 73 +++--- 4 files changed, 106 insertions(+), 23 deletions(-) -- 2.8.0.rc3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] ARM: keystone2: Add missing privilege ID settings
Add missing Privilege ID settings for KS2 SoCs.
Based on:
K2H/K: Table 6-7. Privilege ID Settings from SPRS866E (Nov 2013)
http://www.ti.com/lit/ds/symlink/66ak2h14.pdf (page 99)
K2L: Table 7-7. Privilege ID Settings from SPRS930 (April 2015)
http://www.ti.com/lit/ds/symlink/66ak2l06.pdf (page 71)
K2E: Table 7-7. Privilege ID Settings from SPRS865D (Mar 2015)
http://www.ti.com/lit/ds/symlink/66ak2e05.pdf (page 75)
K2G: Table 3-16. PrivIDs from SPRUHY8 (Jan 2016)
http://www.ti.com/lit/ug/spruhy8/spruhy8.pdf (page 238)
Overall mapping:
---+---+---+---+-
PrivID | KS2H/K| K2L | K2E | K2G
---+---+---+---+-
0 | C66x 0| C66x 0| C66x 0| C66x 0
1 | C66x 1| C66x 1| Reserved | ARM
2 | C66x 2| C66x 2| Reserved | ICSS0
3 | C66x 3| C66x 3| Reserved | ICSS1
4 | C66x 4| Reserved | Reserved | NETCP
5 | C66x 5| Reserved | Reserved | CPIE
6 | C66x 6| Reserved | Reserved | USB
7 | C66x 7| Reserved | Reserved | Reserved
8 | ARM | ARM | ARM | MLB
9 | NetCP | NetCP | NetCP | PMMC
10 | QM_PDSP | QM_PDSP | QM_PDSP | DSS
11 | PCIe_0| PCIe_0| PCIe_0| MMC
12 | DEBUG/DAP | DEBUG/DAP | DEBUG/DAP | DEBUG/DAP
13 | Reserved | Reserved | PCIe_1| Reserved
14 | HyperLink | PCIe_1| HyperLink | Reserved
15 | Reserved | Reserved | TSIP | Reserved
---+---+---+---+-
NOTE: Few of these might have default configurations, however,
since most are software configurable, it is better to explicitly
configure the system to have a known default state.
Without programming these, we end up seeing lack of coherency on certain
peripherals resulting in inexplicable failures (such as USB peripheral's
DMA data not appearing on ARM etc and weird workarounds being done by
drivers including cache flushes which tend to have system wide
performance impact).
By marking these segments as shared, we also ensure SoC wide coherency
is enabled.
Reported-by: Bin Liu
Signed-off-by: Nishanth Menon
---
arch/arm/mach-keystone/include/mach/hardware.h | 23 ++
arch/arm/mach-keystone/init.c | 32 +-
2 files changed, 54 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-keystone/include/mach/hardware.h
b/arch/arm/mach-keystone/include/mach/hardware.h
index dd9268fbf209..38d019056a29 100644
--- a/arch/arm/mach-keystone/include/mach/hardware.h
+++ b/arch/arm/mach-keystone/include/mach/hardware.h
@@ -216,22 +216,45 @@ typedef volatile unsigned int *dv_reg_p;
#define KS2_MSMC_CTRL_BASE 0x0bc0
#define KS2_MSMC_DATA_BASE 0x0c00
+/* KS2 Generic Privilege ID Settings for MSMC2 */
+#define KS2_MSMC_SEGMENT_C6X_0 0
+#define KS2_MSMC_SEGMENT_C6X_1 1
+#define KS2_MSMC_SEGMENT_C6X_2 2
+#define KS2_MSMC_SEGMENT_C6X_3 3
+#define KS2_MSMC_SEGMENT_C6X_4 4
+#define KS2_MSMC_SEGMENT_C6X_5 5
+#define KS2_MSMC_SEGMENT_C6X_6 6
+#define KS2_MSMC_SEGMENT_C6X_7 7
+
+#define KS2_MSMC_SEGMENT_DEBUG 12
+
/* KS2 HK/L/E MSMC PRIVIDs for MSMC2 */
#define K2HKLE_MSMC_SEGMENT_ARM8
#define K2HKLE_MSMC_SEGMENT_NETCP 9
#define K2HKLE_MSMC_SEGMENT_QM_PDSP10
#define K2HKLE_MSMC_SEGMENT_PCIE0 11
+/* K2HK specific Privilege ID Settings */
+#define K2HKE_MSMC_SEGMENT_HYPERLINK 14
+
/* K2L specific Privilege ID Settings */
#define K2L_MSMC_SEGMENT_PCIE1 14
/* K2E specific Privilege ID Settings */
#define K2E_MSMC_SEGMENT_PCIE1 13
+#define K2E_MSMC_SEGMENT_TSIP 15
/* K2G specific Privilege ID Settings */
#define K2G_MSMC_SEGMENT_ARM 1
+#define K2G_MSMC_SEGMENT_ICSS0 2
+#define K2G_MSMC_SEGMENT_ICSS1 3
#define K2G_MSMC_SEGMENT_NSS 4
#define K2G_MSMC_SEGMENT_PCIE 5
+#define K2G_MSMC_SEGMENT_USB 6
+#define K2G_MSMC_SEGMENT_MLB 8
+#define K2G_MSMC_SEGMENT_PMMC 9
+#define K2G_MSMC_SEGMENT_DSS 10
+#define K2G_MSMC_SEGMENT_MMC 11
/* MSMC segment size shift bits */
#define KS2_MSMC_SEG_SIZE_SHIFT12
diff --git a/arch/arm/mach-keystone/init.c b/arch/arm/mach-keystone/init.c
index 2368315ff68c..3b6d5efce1a1 100644
--- a/arch/arm/mach-keystone/init.c
+++ b/arch/arm/mach-keystone/init.c
@@ -98,29 +98,57 @@ static void config_pcie_mode(int pcie_port, enum pci_mode
mode)
static void msmc_k2hkle_common_setup(void)
{
+ msmc_share_all_segments(KS2_MSMC_SEGMENT_C6X_0);
msmc_share_all_segments(K2HKLE_MSMC_SEGMENT_ARM);
msmc_share_all_segments(K2HKLE_MSMC_SEGMENT_NETCP);
#ifdef KS2_MSMC_SEGMENT_QM_PDSP
msmc_share_all_segments(K2HKLE_MSMC_SEGMENT_QM_PDSP);
#endif
msmc_share_all_seg
[U-Boot] [PATCH 1/2] ARM: keystone2: Refactor MSMC macros to avoid #ifdeffery
MSMC segment Privilege ID is not consistent accross the keystone2 SoCs.
As the first step to ensure complete SoC wide coherency setup, lets
refactor the macros to remove the #if-deffery around the code which
obfuscates which IDs are actually enabled for which SoC.
As a result of this change the PCIe configuration is moved after the
msmc configuration is complete, but that should ideally have no
functional impact.
Signed-off-by: Nishanth Menon
---
arch/arm/mach-keystone/include/mach/hardware-k2e.h | 3 --
arch/arm/mach-keystone/include/mach/hardware-k2l.h | 3 --
arch/arm/mach-keystone/include/mach/hardware.h | 27 +-
arch/arm/mach-keystone/init.c | 43 ++
4 files changed, 53 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-keystone/include/mach/hardware-k2e.h
b/arch/arm/mach-keystone/include/mach/hardware-k2e.h
index df499957e54d..e6bc77caaf09 100644
--- a/arch/arm/mach-keystone/include/mach/hardware-k2e.h
+++ b/arch/arm/mach-keystone/include/mach/hardware-k2e.h
@@ -34,9 +34,6 @@
#define KS2_LPSC_PCIE_127
#define KS2_LPSC_XGE 50
-/* MSMC */
-#define KS2_MSMC_SEGMENT_PCIE1 13
-
/* Chip Interrupt Controller */
#define KS2_CIC2_DDR3_ECC_IRQ_NUM -1 /* not defined in K2E */
#define KS2_CIC2_DDR3_ECC_CHAN_NUM -1 /* not defined in K2E */
diff --git a/arch/arm/mach-keystone/include/mach/hardware-k2l.h
b/arch/arm/mach-keystone/include/mach/hardware-k2l.h
index a59e0713593f..92c17d7dd5ba 100644
--- a/arch/arm/mach-keystone/include/mach/hardware-k2l.h
+++ b/arch/arm/mach-keystone/include/mach/hardware-k2l.h
@@ -53,9 +53,6 @@
#define KS2_LPSC_FFTC_B49
#define KS2_LPSC_IQN_AIL 50
-/* MSMC */
-#define KS2_MSMC_SEGMENT_PCIE1 14
-
/* Chip Interrupt Controller */
#define KS2_CIC2_DDR3_ECC_IRQ_NUM 0x0D3
#define KS2_CIC2_DDR3_ECC_CHAN_NUM 0x01D
diff --git a/arch/arm/mach-keystone/include/mach/hardware.h
b/arch/arm/mach-keystone/include/mach/hardware.h
index 8ca19bbcdbe9..dd9268fbf209 100644
--- a/arch/arm/mach-keystone/include/mach/hardware.h
+++ b/arch/arm/mach-keystone/include/mach/hardware.h
@@ -215,16 +215,23 @@ typedef volatile unsigned int *dv_reg_p;
/* MSMC control */
#define KS2_MSMC_CTRL_BASE 0x0bc0
#define KS2_MSMC_DATA_BASE 0x0c00
-#ifndef CONFIG_SOC_K2G
-#define KS2_MSMC_SEGMENT_TETRIS8
-#define KS2_MSMC_SEGMENT_NETCP 9
-#define KS2_MSMC_SEGMENT_QM_PDSP 10
-#define KS2_MSMC_SEGMENT_PCIE0 11
-#else
-#define KS2_MSMC_SEGMENT_TETRIS1
-#define KS2_MSMC_SEGMENT_NETCP 4
-#define KS2_MSMC_SEGMENT_PCIE0 5
-#endif
+
+/* KS2 HK/L/E MSMC PRIVIDs for MSMC2 */
+#define K2HKLE_MSMC_SEGMENT_ARM8
+#define K2HKLE_MSMC_SEGMENT_NETCP 9
+#define K2HKLE_MSMC_SEGMENT_QM_PDSP10
+#define K2HKLE_MSMC_SEGMENT_PCIE0 11
+
+/* K2L specific Privilege ID Settings */
+#define K2L_MSMC_SEGMENT_PCIE1 14
+
+/* K2E specific Privilege ID Settings */
+#define K2E_MSMC_SEGMENT_PCIE1 13
+
+/* K2G specific Privilege ID Settings */
+#define K2G_MSMC_SEGMENT_ARM 1
+#define K2G_MSMC_SEGMENT_NSS 4
+#define K2G_MSMC_SEGMENT_PCIE 5
/* MSMC segment size shift bits */
#define KS2_MSMC_SEG_SIZE_SHIFT12
diff --git a/arch/arm/mach-keystone/init.c b/arch/arm/mach-keystone/init.c
index aadd10bff270..2368315ff68c 100644
--- a/arch/arm/mach-keystone/init.c
+++ b/arch/arm/mach-keystone/init.c
@@ -96,22 +96,51 @@ static void config_pcie_mode(int pcie_port, enum pci_mode
mode)
__raw_writel(val, KS2_DEVCFG);
}
+static void msmc_k2hkle_common_setup(void)
+{
+ msmc_share_all_segments(K2HKLE_MSMC_SEGMENT_ARM);
+ msmc_share_all_segments(K2HKLE_MSMC_SEGMENT_NETCP);
+#ifdef KS2_MSMC_SEGMENT_QM_PDSP
+ msmc_share_all_segments(K2HKLE_MSMC_SEGMENT_QM_PDSP);
+#endif
+ msmc_share_all_segments(K2HKLE_MSMC_SEGMENT_PCIE0);
+}
+
+static inline void msmc_k2l_setup(void)
+{
+ msmc_share_all_segments(K2L_MSMC_SEGMENT_PCIE1);
+}
+
+static inline void msmc_k2e_setup(void)
+{
+ msmc_share_all_segments(K2E_MSMC_SEGMENT_PCIE1);
+}
+
+static inline void msmc_k2g_setup(void)
+{
+ msmc_share_all_segments(K2G_MSMC_SEGMENT_ARM);
+ msmc_share_all_segments(K2G_MSMC_SEGMENT_NSS);
+ msmc_share_all_segments(K2G_MSMC_SEGMENT_PCIE);
+}
+
int arch_cpu_init(void)
{
chip_configuration_unlock();
icache_enable();
- msmc_share_all_segments(KS2_MSMC_SEGMENT_TETRIS);
- msmc_share_all_segments(KS2_MSMC_SEGMENT_NETCP);
-#ifdef KS2_MSMC_SEGMENT_QM_PDSP
- msmc_share_all_segments(KS2_MSMC_SEGMENT_QM_PDSP);
-#endif
- msmc_share_all_segments(KS2_MSMC_SEGMENT_PCIE0);
+ if (cpu_is_k2g()) {
+ msmc_k2g_setup();
+ } else {
+ msmc_k2hkle_common_setup
[U-Boot] [PATCH] board: ti: am57xx: Update EMIF SDRAM 1 and 3 Timings
From: Schuyler Patton
Update EMIF data based on recommendations from the now standard TI
EMIF tool version 1.1.1 based on 256MBx16 DDR3L Kingston D2516EC4BXGGB
data sheet
Update T_RRD from 5 to 6 based on AM57xx TRM -
Minimum number of DDR cycles from activate to ativate for a different
bank, minus 1.
Update T_CKESR from 4 to 3 based on AM57xx TRM - Minimum number of DDR
clocks cycles for which SDRAM must remain in self refresh, minus 1.
Signed-off-by: Schuyler Patton
Signed-off-by: Nishanth Menon
---
X15 BOM:
https://github.com/beagleboard/beagleboard-x15/blob/master/BeagleBoard-X15_RevA2B_BOM.xlsx
AM5728 Data sheet: http://www.ti.com/product/AM5728/datasheet
board/ti/am57xx/board.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/ti/am57xx/board.c b/board/ti/am57xx/board.c
index 18416ef64ad9..fda0ed59c6b7 100644
--- a/board/ti/am57xx/board.c
+++ b/board/ti/am57xx/board.c
@@ -131,9 +131,9 @@ static const struct emif_regs
beagle_x15_emif2_ddr3_532mhz_emif_regs = {
.sdram_config2 = 0x0800,
.ref_ctrl = 0x40F1,
.ref_ctrl_final = 0x1035,
- .sdram_tim1 = 0xcccf36ab,
+ .sdram_tim1 = 0xcccf36b3,
.sdram_tim2 = 0x308f7fda,
- .sdram_tim3 = 0x409f88a8,
+ .sdram_tim3 = 0x407f88a8,
.read_idle_ctrl = 0x0005,
.zq_config = 0x5007190b,
.temp_alert_config = 0x,
--
2.8.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] board: ti: am57xx: Add support for am572x idk in SPL
From: Steve Kipisz
The AM572x-IDK board (Industrial Dev Kit) is a board based on TI's AM5728x
SOC which has a dual core 1.5GHz A15 processor. This board is a development
platform for the Industrial market with:
- 2GB of DDR3L
- Dual 1Gbps Ethernet
- HDMI,
- PRU-ICSS
- uSD
- 16GB eMMC
- CAN
- RS-485
- PCIe
- USB3.0
- Video Input Port
- Industrial IO port and expansion connector
The link to the data sheet and TRM can be found here:
http://www.ti.com/product/AM5728
NOTE: DT support is still pending upstream kernel acceptance but we
should be able to get the base system support with this patch.
Signed-off-by: Schuyler Patton
Signed-off-by: Steve Kipisz
Signed-off-by: Nishanth Menon
---
Boot Log: http://pastebin.ubuntu.com/15699618/
board/ti/am57xx/board.c| 32 +-
board/ti/am57xx/mux_data.h | 268 -
2 files changed, 295 insertions(+), 5 deletions(-)
diff --git a/board/ti/am57xx/board.c b/board/ti/am57xx/board.c
index 18416ef64ad9..11eb524980be 100644
--- a/board/ti/am57xx/board.c
+++ b/board/ti/am57xx/board.c
@@ -35,6 +35,7 @@
#define board_is_x15() board_ti_is("BBRDX15_")
#define board_is_am572x_evm() board_ti_is("AM572PM_")
+#define board_is_am572x_idk() board_ti_is("AM572IDK")
#ifdef CONFIG_DRIVER_TI_CPSW
#include
@@ -278,6 +279,8 @@ void do_board_detect(void)
bname = "BeagleBoard X15";
else if (board_is_am572x_evm())
bname = "AM572x EVM";
+ else if (board_is_am572x_idk())
+ bname = "AM572x IDK";
if (bname)
snprintf(sysinfo.board_string, SYSINFO_BOARD_NAME_MAX_LEN,
@@ -296,6 +299,8 @@ static void setup_board_eeprom_env(void)
if (board_is_am572x_evm())
name = "am57xx_evm";
+ else if (board_is_am572x_idk())
+ name = "am572x_idk";
else
printf("Unidentified board claims %s in eeprom header\n",
board_ti_get_name());
@@ -344,9 +349,24 @@ void set_muxconf_regs(void)
#ifdef CONFIG_IODELAY_RECALIBRATION
void recalibrate_iodelay(void)
{
- __recalibrate_iodelay(core_padconf_array_essential,
- ARRAY_SIZE(core_padconf_array_essential),
- iodelay_cfg_array, ARRAY_SIZE(iodelay_cfg_array));
+ const struct pad_conf_entry *pconf;
+ const struct iodelay_cfg_entry *iod;
+ int pconf_sz, iod_sz;
+
+ if (board_is_am572x_idk()) {
+ pconf = core_padconf_array_essential_am572x_idk;
+ pconf_sz = ARRAY_SIZE(core_padconf_array_essential_am572x_idk);
+ iod = iodelay_cfg_array_am572x_idk;
+ iod_sz = ARRAY_SIZE(iodelay_cfg_array_am572x_idk);
+ } else {
+ /* Common for X15/GPEVM */
+ pconf = core_padconf_array_essential_x15;
+ pconf_sz = ARRAY_SIZE(core_padconf_array_essential_x15);
+ iod = iodelay_cfg_array_x15;
+ iod_sz = ARRAY_SIZE(iodelay_cfg_array_x15);
+ }
+
+ __recalibrate_iodelay(pconf, pconf_sz, iod, iod_sz);
}
#endif
@@ -606,6 +626,12 @@ int board_eth_init(bd_t *bis)
ctrl_val |= 0x22;
writel(ctrl_val, (*ctrl)->control_core_control_io1);
+ /* The phy address for the AM572x IDK are different than x15 */
+ if (board_is_am572x_idk()) {
+ cpsw_data.slave_data[0].phy_addr = 0;
+ cpsw_data.slave_data[1].phy_addr = 1;
+ }
+
ret = cpsw_register(&cpsw_data);
if (ret < 0)
printf("Error %d registering CPSW switch\n", ret);
diff --git a/board/ti/am57xx/mux_data.h b/board/ti/am57xx/mux_data.h
index 3c007b76dd5b..b5ea8ad7c852 100644
--- a/board/ti/am57xx/mux_data.h
+++ b/board/ti/am57xx/mux_data.h
@@ -12,7 +12,7 @@
#include
-const struct pad_conf_entry core_padconf_array_essential[] = {
+const struct pad_conf_entry core_padconf_array_essential_x15[] = {
{GPMC_AD0, (M2 | PIN_INPUT_PULLDOWN | MANUAL_MODE)},/*
gpmc_ad0.vin3a_d0 */
{GPMC_AD1, (M2 | PIN_INPUT_PULLUP | MANUAL_MODE)}, /*
gpmc_ad1.vin3a_d1 */
{GPMC_AD2, (M2 | PIN_INPUT_PULLDOWN | MANUAL_MODE)},/*
gpmc_ad2.vin3a_d2 */
@@ -264,6 +264,222 @@ const struct pad_conf_entry
core_padconf_array_essential[] = {
{RTCK, (M0 | PIN_INPUT_PULLDOWN)}, /* rtck.rtck */
};
+const struct pad_conf_entry core_padconf_array_essential_am572x_idk[] = {
+ {GPMC_A0, (M6 | PIN_INPUT_PULLDOWN | MANUAL_MODE)}, /*
gpmc_a0.vin4b_d0 */
+ {GPMC_A1, (M6 | PIN_INPUT_PULLUP | MANUAL_MODE)}, /*
gpmc_a1.vin4b_d1 */
+ {GPMC_A2, (M6 | PIN_INPUT_PULLDOWN | MANUAL_MODE)}, /*
gpmc_a2.vin4b_d2 */
+ {GPMC_A3, (M6 | PIN_INPUT_PULLDOWN | MANUAL_MODE)}, /*
gpmc_a3.vin4b_d3 */
+ {GPMC_A4, (M6 | PIN_INPUT_PULLDOWN | MAN
Re: [U-Boot] [RFC PATCH 0/2] ARM: v7: Enable basic framework for supporting bits for CVE-2017-5715
On Tue, May 22, 2018 at 9:05 AM, Fabio Estevam wrote: > On Thu, Jan 25, 2018 at 7:45 PM, Nishanth Menon wrote: >> Hi Folks, >> >> This is a follow through on the discussion we have had in [1]. >> This itself is'nt a complete solution and is based on recommendation >> This from Arm[2] for variant 2 CVE-2017-5715 >> >> The Linux kernel discussions are spread out in [3], ATF and OPTEE >> status are available in [4]. >> >> This is just an RFC series (build tested at this point) to check if >> the direction is fine and should follow the final solution once kernel >> patches get to upstream, IMHO. >> >> NOTE: As per ARM recommendations[2], and discussions in list[1] ARM >> Cortex-A9/12/17 do not need additional steps in u-boot to enable the >> OS level workarounds. >> >> Nishanth Menon (2): >> ARM: Introduce ability to enable ACR::IBE on Cortex-A8 for >> CVE-2017-5715 >> ARM: Introduce ability to enable invalidate of BTB on Cortex-A15 for >> CVE-2017-5715 > I started respinning the series, while there is definitely a use of implementing in u-boot, I am starting to wonder if we should also be doing this in kernel. -> following is an example: for OMAP5uEVM (dual A15) with next-20180612 -> Uboot does setup the IBE bit, so the CPU0 ICIALLU does get activated however, that is not true for CPU1. Further if we enter low power states, we'd also start loosing the context, wont we? Log: [0.001484] Calibrating delay loop (skipped), value calculated using timer frequency.. 12.28 BogoMIPS (lpj=61440) [0.001510] pid_max: default: 32768 minimum: 301 [0.001804] Security Framework initialized [0.001907] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes) [0.001928] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes) [0.004144] CPU: Testing write buffer coherency: ok [0.004258] CPU0: Spectre v2: using ICIALLU workaround [0.005130] /cpus/cpu@0 missing clock-frequency property [0.005159] /cpus/cpu@1 missing clock-frequency property [0.005178] CPU0: thread -1, cpu 0, socket 0, mpidr 8000 [0.006660] Setting up static identity map for 0x8010 - 0x80100078 [0.007036] rcu: Hierarchical SRCU implementation. [0.008424] smp: Bringing up secondary CPUs ... [0.010557] CPU1: thread -1, cpu 1, socket 0, mpidr 8001 [0.010566] CPU1: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable [0.011162] smp: Brought up 1 node, 2 CPUs [0.011181] SMP: Total of 2 processors activated (24.57 BogoMIPS). [0.011197] CPU: All CPU(s) started in HYP mode. [0.011211] CPU: Virtualization extensions available. [0.013729] devtmpfs: initialized [0.044497] VFP support v0.3: implementor 41 architecture 4 part 30 variant f rev 0 [0.046160] clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 1911260446275 ns [0.046201] futex hash table entries: 512 (order: 3, 32768 bytes) [0.046942] pinctrl core: initialized pinctrl subsystem [0.050282] NET: Registered protocol family 16 [0.054624] DMA: preallocated 256 KiB pool for atomic coherent allocations [0.055930] omap_hwmod: l3_main_3 using broken dt data from ocp [0.057244] omap_hwmod: l3_main_2 using broken dt data from ocp [0.167706] audit: initializing netlink subsys (disabled) [0.168044] audit: type=2000 audit(0.160:1): state=initialized audit_enabled=0 res=1 [0.168979] (NULL device *): Failed to create dummy-scm_conf@0 debugfs directory [0.169566] cpuidle: using governor menu [0.184644] OMAP GPIO hardware version 0.1 -- --- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/4] ARM: mach-omap2: omap5/dra7: Enable ACTLR[0] (Enable invalidates of BTB) to facilitate CVE_2017-5715 WA in OS
Enable CVE_2017_5715 and since we have our own v7_arch_cp15_set_acr function to setup the bits, we are able to override the settings. Without this enabled, Linux kernel reports: CPU0: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable With this enabled, Linux kernel reports: CPU0: Spectre v2: using ICIALLU workaround NOTE: This by itself does not enable the workaround for CPU1 (on OMAP5 and DRA72/AM572 SoCs) and may require additional kernel patches. Signed-off-by: Nishanth Menon --- arch/arm/mach-omap2/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 3bb1ecb58de0..77820cc8d1e4 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -53,6 +53,7 @@ config OMAP54XX bool "OMAP54XX SoC" select ARM_ERRATA_798870 select SYS_THUMB_BUILD + select ARM_CORTEX_A15_CVE_2017_5715 imply NAND_OMAP_ELM imply NAND_OMAP_GPMC imply SPL_DISPLAY_PRINT -- 2.15.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/4] ARM: mach-omap2: omap3/am335x: Enable ACR::IBE on Cortex-A8 SoCs for CVE-2017-5715
Enable CVE-2017-5715 option to set the IBE bit. This enables kernel workarounds necessary for the said CVE. With this enabled, Linux reports: CPU0: Spectre v2: using BPIALL workaround This workaround may need to be re-applied in OS environment around low power transition resume states where context of ACR would be lost (off-mode etc). Signed-off-by: Nishanth Menon --- arch/arm/mach-omap2/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 77820cc8d1e4..f4babc8d2600 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -10,6 +10,7 @@ config OMAP34XX select ARM_ERRATA_454179 select ARM_ERRATA_621766 select ARM_ERRATA_725233 + select ARM_CORTEX_A8_CVE_2017_5715 select USE_TINY_PRINTF imply NAND_OMAP_GPMC imply SPL_EXT_SUPPORT @@ -116,6 +117,7 @@ config AM43XX config AM33XX bool "AM33XX SoC" select SPECIFY_CONSOLE_INDEX + select ARM_CORTEX_A8_CVE_2017_5715 imply NAND_OMAP_ELM imply NAND_OMAP_GPMC imply SPL_NAND_AM33XX_BCH -- 2.15.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/4] ARM: Introduce ability to enable invalidate of BTB with ICIALLU on Cortex-A15 for CVE-2017-5715
As recommended by Arm in [1], ACTLR[0] (Enable invalidates of BTB)
needs to be set[2] for BTB to be invalidated on ICIALLU. This needs to
be done unconditionally for Cortex-A15 processors. Provide a config
option for platforms to enable this option based on impact analysis
for products.
NOTE: This patch in itself is NOT the final solution, this requires:
a) Implementation of v7_arch_cp15_set_acr on SoCs which may not
provide direct access to ACR register.
b) Operating Systems such as Linux to provide adequate workaround in the
right locations.
c) This workaround applies to only the boot processor. It is important
to apply workaround as necessary (context-save-restore) around low
power context loss OR additional processors as necessary in either
firmware support OR elsewhere in OS.
[1] https://developer.arm.com/support/security-update
[2] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0438c/BABGHIBG.html
Cc: Marc Zyngier
Cc: Russell King
Cc: Tony Lindgren
Cc: Robin Murphy
Cc: Florian Fainelli
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Christoffer Dall
Cc: Andre Przywara
Cc: Ard Biesheuvel
Cc: Tom Rini
Cc: Michael Nazzareno Trimarchi
Signed-off-by: Nishanth Menon
---
arch/arm/Kconfig | 4
arch/arm/cpu/armv7/start.S | 8
2 files changed, 12 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 9e32d5b43cb0..98f58fd27696 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -109,6 +109,7 @@ config SYS_ARM_MPU
# CONFIG_ARM_ERRATA_798870
# CONFIG_ARM_ERRATA_801819
# CONFIG_ARM_CORTEX_A8_CVE_2017_5715
+# CONFIG_ARM_CORTEX_A15_CVE_2017_5715
config ARM_ERRATA_430973
bool
@@ -182,6 +183,9 @@ config ARM_ERRATA_855873
config ARM_CORTEX_A8_CVE_2017_5715
bool
+config ARM_CORTEX_A15_CVE_2017_5715
+ bool
+
config CPU_ARM720T
bool
select SYS_CACHE_SHIFT_5
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index 3beaf5a93d81..81edec01bf32 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -241,6 +241,14 @@ skip_errata_798870:
skip_errata_801819:
#endif
+#ifdef CONFIG_ARM_CORTEX_A15_CVE_2017_5715
+ mrc p15, 0, r0, c1, c0, 1 @ read auxilary control register
+ orr r0, r0, #1 << 0 @ Enable invalidates of BTB
+ push{r1-r5} @ Save the cpu info registers
+ bl v7_arch_cp15_set_acr
+ pop {r1-r5} @ Restore the cpu info - fall through
+#endif
+
#ifdef CONFIG_ARM_ERRATA_454179
mrc p15, 0, r0, c1, c0, 1 @ Read ACR
--
2.15.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/4] ARM: Provide workaround setup bits for CVE-2017-5715 (A8/A15)
Hi, This is a follow on from https://marc.info/?l=u-boot&m=151691688828176&w=2 (RFC) NOTE: * As per ARM recommendations[2], and discussions in list[1] ARM Cortex-A9/12/17 do not need additional steps in u-boot to enable the OS level workarounds. * This itself is'nt a complete solution and is based on recommendation This from Arm[2] for variant 2 CVE-2017-5715 -> Kernel changes can be seen on linux next (next-20180612) or on linux master (upcoming v4.18-rc1 tag). * I think it is necessary on older SoCs without firmware support (such as older OMAPs and AM*) to have kernel support mirroring what we do in u-boot to support additional cores AND/OR low power states where contexts are lost (assuming ACR states are'nt saved). just my 2 cents. Few of the tests (with linux next-20180612): AM571-IDK: https://pastebin.ubuntu.com/p/sr5X6sN3Tr/ (single core A15) OMAP5-uEVM: https://pastebin.ubuntu.com/p/9yDM22bJ6n/ (dual core A15) OMAP3-beagle-xm: https://pastebin.ubuntu.com/p/9DfDkpyxym/ (Single A8) AM335x-Beaglebone-black: https://pastebin.ubuntu.com/p/DczT9jPMwb/ (Single A8) Nishanth Menon (4): ARM: Introduce ability to enable ACR::IBE on Cortex-A8 for CVE-2017-5715 ARM: Introduce ability to enable invalidate of BTB with ICIALLU on Cortex-A15 for CVE-2017-5715 ARM: mach-omap2: omap5/dra7: Enable ACTLR[0] (Enable invalidates of BTB) to facilitate CVE_2017-5715 WA in OS ARM: mach-omap2: omap3/am335x: Enable ACR::IBE on Cortex-A8 SoCs for CVE-2017-5715 arch/arm/Kconfig| 9 + arch/arm/cpu/armv7/start.S | 15 +-- arch/arm/mach-omap2/Kconfig | 3 +++ 3 files changed, 25 insertions(+), 2 deletions(-) [1] https://marc.info/?t=15163990652&r=1&w=2 [2] https://developer.arm.com/support/security-update [3] https://marc.info/?t=15154379047&r=1&w=2 and the latest in: https://marc.info/?l=linux-arm-kernel&m=151689379521082&w=2 [4] https://github.com/ARM-software/arm-trusted-firmware/wiki/ARM-Trusted-Firmware-Security-Advisory-TFV-6 https://www.op-tee.org/security-advisories/ https://www.linaro.org/blog/meltdown-spectre/ -- 2.15.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/4] ARM: Introduce ability to enable ACR::IBE on Cortex-A8 for CVE-2017-5715
As recommended by Arm in [1], IBE[2] has to be enabled unconditionally
for BPIALL to be functional on Cortex-A8 processors. Provide a config
option for platforms to enable this option based on impact analysis
for products.
NOTE: This patch in itself is NOT the final solution, this requires:
a) Implementation of v7_arch_cp15_set_acr on SoCs which may not
provide direct access to ACR register.
b) Operating Systems such as Linux to provide adequate workaround in the right
locations.
c) This workaround applies to only the boot processor. It is important
to apply workaround as necessary (context-save-restore) around low
power context loss OR additional processors as necessary in either
firmware support OR elsewhere in OS.
[1] https://developer.arm.com/support/security-update
[2] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0344k/Bgbffjhh.html
Cc: Marc Zyngier
Cc: Russell King
Cc: Tony Lindgren
Cc: Robin Murphy
Cc: Florian Fainelli
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Christoffer Dall
Cc: Andre Przywara
Cc: Ard Biesheuvel
Cc: Tom Rini
Cc: Michael Nazzareno Trimarchi
Signed-off-by: Nishanth Menon
---
arch/arm/Kconfig | 5 +
arch/arm/cpu/armv7/start.S | 7 +--
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index dde422bc5d53..9e32d5b43cb0 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -108,6 +108,8 @@ config SYS_ARM_MPU
# CONFIG_ARM_ERRATA_621766
# CONFIG_ARM_ERRATA_798870
# CONFIG_ARM_ERRATA_801819
+# CONFIG_ARM_CORTEX_A8_CVE_2017_5715
+
config ARM_ERRATA_430973
bool
@@ -177,6 +179,9 @@ config ARM_ERRATA_852423
config ARM_ERRATA_855873
bool
+config ARM_CORTEX_A8_CVE_2017_5715
+ bool
+
config CPU_ARM720T
bool
select SYS_CACHE_SHIFT_5
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index c996525f861e..3beaf5a93d81 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -252,12 +252,15 @@ skip_errata_801819:
pop {r1-r5} @ Restore the cpu info - fall through
#endif
-#ifdef CONFIG_ARM_ERRATA_430973
+#if defined(CONFIG_ARM_ERRATA_430973) || defined
(CONFIG_ARM_CORTEX_A8_CVE_2017_5715)
mrc p15, 0, r0, c1, c0, 1 @ Read ACR
+#ifdef CONFIG_ARM_CORTEX_A8_CVE_2017_5715
+ orr r0, r0, #(0x1 << 6) @ Set IBE bit always to enable OS WA
+#else
cmp r2, #0x21 @ Only on < r2p1
orrlt r0, r0, #(0x1 << 6) @ Set IBE bit
-
+#endif
push{r1-r5} @ Save the cpu info registers
bl v7_arch_cp15_set_acr
pop {r1-r5} @ Restore the cpu info - fall through
--
2.15.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 0/2] ARM: v7: Enable basic framework for supporting bits for CVE-2017-5715
On 21:40-20180612, Russell King - ARM Linux wrote: [...] > > I started respinning the series, while there is definitely a use of > > implementing in u-boot, > > I am starting to wonder if we should also be doing this in kernel. > > How does the kernel set the bit when the kernel is running in non-secure > mode, when the ACTLR is read-only in that mode? For OMAP5/DRA7 SMP systems, I just posted a patch that seems to resolve it: https://patchwork.kernel.org/patch/10461273/ This'd be similar in implementation to ARM erratum 801819 workaround that needs two pieces (u-boot + kernel). I am not really worried about OMAP5/DRA7 since they should'nt loose context in Low power modes. Other SoCs need to be aware of the constraints. /me wishes PSCI was a standard during ARMv7, but it was'nt... So legacy v7 SoCs have implementations that are kind of different (even smc calling conventions vary). -- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 0/2] ARM: v7: Enable basic framework for supporting bits for CVE-2017-5715
On 10:08-20180613, Russell King - ARM Linux wrote: > On Tue, Jun 12, 2018 at 04:58:34PM -0500, Nishanth Menon wrote: > > On 21:40-20180612, Russell King - ARM Linux wrote: > > [...] > > > > I started respinning the series, while there is definitely a use of > > > > implementing in u-boot, > > > > I am starting to wonder if we should also be doing this in kernel. > > > > > > How does the kernel set the bit when the kernel is running in non-secure > > > mode, when the ACTLR is read-only in that mode? > > > > For OMAP5/DRA7 SMP systems, I just posted a patch that seems to resolve > > it: > > https://patchwork.kernel.org/patch/10461273/ > > > > This'd be similar in implementation to ARM erratum 801819 workaround > > that needs two pieces (u-boot + kernel). I am not really worried about > > OMAP5/DRA7 since they should'nt loose context in Low power modes. > > Other SoCs need to be aware of the constraints. > > > > /me wishes PSCI was a standard during ARMv7, but it was'nt... So > > legacy v7 SoCs have implementations that are kind of different (even > > smc calling conventions vary). > > It may seem to be an easy way out (do everything in the kernel) but > have you considered that the secure world is also vulnerable? Yes, we have. > If the IBE bit is not set in the secure world, then the secure world > is not implementing the workarounds, and therefore the non-secure > world has the possibility to use the Spectre vulnerabilities to > exploit the secure world with enough effort and knowledge. > > You really need to _also_ fix these vulnerabilities in the secure > world, which includes setting the IBE bit there. Correct, but, unfortunately, this is NOT always the case / not necessary in some cases. Example: On General purpose (GP) devices such as in OMAP, ROM owns the secure APIs, there is no override of secure world APIs possible. In such cases, we have to see if there is anything that needs to be protected. in case of GP devices, there are no secure assets to protect and any SMC calls are just support services provided by ROM. a) updating secure side is not possible b) secure side updates is not necessary since there are no critical run time services provided by ROM. On devices such as Keystone 2 (TI) generation, yes, we do have ability to update secure side and must be done as well. -- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] ARM: Introduce ability to enable invalidate of BTB with ICIALLU on Cortex-A15 for CVE-2017-5715
On 23:05-20180612, Marek Vasut wrote: > On 06/12/2018 10:24 PM, Nishanth Menon wrote: [..] > > +#ifdef CONFIG_ARM_CORTEX_A15_CVE_2017_5715 > > + mrc p15, 0, r0, c1, c0, 1 @ read auxilary control register > > + orr r0, r0, #1 << 0 @ Enable invalidates of BTB > > Can we use BIT() macro in the assembler code too ? Probably, but just following convention in the rest of the file. Do we want to change from existing code? -- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] ARM: Introduce ability to enable invalidate of BTB with ICIALLU on Cortex-A15 for CVE-2017-5715
On 00:30-20180613, Florian Fainelli wrote: > On June 12, 2018 1:24:09 PM PDT, Nishanth Menon wrote: > >As recommended by Arm in [1], ACTLR[0] (Enable invalidates of BTB) > >needs to be set[2] for BTB to be invalidated on ICIALLU. This needs to > >be done unconditionally for Cortex-A15 processors. Provide a config > >option for platforms to enable this option based on impact analysis > >for products. > > > >NOTE: This patch in itself is NOT the final solution, this requires: > >a) Implementation of v7_arch_cp15_set_acr on SoCs which may not > > provide direct access to ACR register. > >b) Operating Systems such as Linux to provide adequate workaround in > >the > > right locations. > > This is the case as of 4.18 so you could probably reference > CONFIG_CPU_SPECTRE and CONFIG_HARDEN_BRANCH_PREDICTOR in a v2. Did'nt want to tie the description too deep to Linux specifics.. Linux documents itself and users are encouraged to read that documentation, correct? > > >c) This workaround applies to only the boot processor. It is important > > to apply workaround as necessary (context-save-restore) around low > > power context loss OR additional processors as necessary in either > > firmware support OR elsewhere in OS. > > About that, I don't know enough of uboot but are there existing PSCI or > other seemingly standard secondary core support in uboot that would make > us go through the same initialization as the boot CPU? If not, is > everything going to be largely implementation specific and > scattered between uboot and the hypervisors or kernel? in ARMV7 SoCs, unfortunately, we lived in a world of no-exact-standard. even within TI, Few of the SoCs use PSCI, others did implement custom SMC calls (since they existed in an architecture prior to PSCI). > > FWIW, this is what prompted me to submit this: > > https://patchwork.kernel.org/patch/10453643/ That wont work in a generic manner for precisely the same reason I had to do it with weak function in u-boot (some SoCs will only permit 'mcr p15, 0, r0, c1, c0, 1' in secure world and you need to make a custom smc call to make it happen). Unfortunately, IMHO, at least at this point, there'd be custom implementations per SoC and layers depending on where to implement it. -- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] ARM: mach-omap2: omap5/dra7: Enable ACTLR[0] (Enable invalidates of BTB) to facilitate CVE_2017-5715 WA in OS
On 23:06-20180612, Marek Vasut wrote: > On 06/12/2018 10:24 PM, Nishanth Menon wrote: > > Enable CVE_2017_5715 and since we have our own v7_arch_cp15_set_acr > > function to setup the bits, we are able to override the settings. > > > > Without this enabled, Linux kernel reports: > > CPU0: Spectre v2: firmware did not set auxiliary control register IBE bit, > > system vulnerable > > > > With this enabled, Linux kernel reports: > > CPU0: Spectre v2: using ICIALLU workaround > > > > NOTE: This by itself does not enable the workaround for CPU1 (on > > OMAP5 and DRA72/AM572 SoCs) and may require additional kernel patches. > > > > Signed-off-by: Nishanth Menon > > --- > > arch/arm/mach-omap2/Kconfig | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig > > index 3bb1ecb58de0..77820cc8d1e4 100644 > > --- a/arch/arm/mach-omap2/Kconfig > > +++ b/arch/arm/mach-omap2/Kconfig > > @@ -53,6 +53,7 @@ config OMAP54XX > > bool "OMAP54XX SoC" > > select ARM_ERRATA_798870 > > select SYS_THUMB_BUILD > > + select ARM_CORTEX_A15_CVE_2017_5715 > > imply NAND_OMAP_ELM > > imply NAND_OMAP_GPMC > > imply SPL_DISPLAY_PRINT > > > > Can this be enabled for all CA15 systems somehow ? I am sure there are > more that are vulnerable. I just dont know how to make smc call convention generic. This is the reason why v7_arch_cp15_set_acr is setup as a weak function. you'd have to implement it specific to SoC (in many newer SoCs, you might potentially be able to make at least few implementations generic using PSCI). NOTE: this is the same trouble with erratum 801819 implementation as well. -- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] ARM: mach-omap2: omap5/dra7: Enable ACTLR[0] (Enable invalidates of BTB) to facilitate CVE_2017-5715 WA in OS
On 20:36-20180613, Marek Vasut wrote: > On 06/13/2018 07:36 PM, Russell King - ARM Linux wrote: > > On Wed, Jun 13, 2018 at 01:06:13AM +0200, Marek Vasut wrote: > >> On 06/12/2018 10:24 PM, Nishanth Menon wrote: > >>> Enable CVE_2017_5715 and since we have our own v7_arch_cp15_set_acr > >>> function to setup the bits, we are able to override the settings. > >>> > >>> Without this enabled, Linux kernel reports: > >>> CPU0: Spectre v2: firmware did not set auxiliary control register IBE > >>> bit, system vulnerable > >>> > >>> With this enabled, Linux kernel reports: > >>> CPU0: Spectre v2: using ICIALLU workaround > >>> > >>> NOTE: This by itself does not enable the workaround for CPU1 (on > >>> OMAP5 and DRA72/AM572 SoCs) and may require additional kernel patches. > >>> > >>> Signed-off-by: Nishanth Menon > >>> --- > >>> arch/arm/mach-omap2/Kconfig | 1 + > >>> 1 file changed, 1 insertion(+) > >>> > >>> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig > >>> index 3bb1ecb58de0..77820cc8d1e4 100644 > >>> --- a/arch/arm/mach-omap2/Kconfig > >>> +++ b/arch/arm/mach-omap2/Kconfig > >>> @@ -53,6 +53,7 @@ config OMAP54XX > >>> bool "OMAP54XX SoC" > >>> select ARM_ERRATA_798870 > >>> select SYS_THUMB_BUILD > >>> + select ARM_CORTEX_A15_CVE_2017_5715 > >>> imply NAND_OMAP_ELM > >>> imply NAND_OMAP_GPMC > >>> imply SPL_DISPLAY_PRINT > >>> > >> > >> Can this be enabled for all CA15 systems somehow ? I am sure there are > >> more that are vulnerable. > > > > I think you're missing the point. > > Please read the patch again. > > This enables it only for a specific SoC. My point being, this should be > enabled for all SoCs with CA15, not just some select few. > As I had previously responded in https://marc.info/?l=u-boot&m=152889727127549&w=2 I am not disagreeing this needs to be done for all CA15 based SoCs (and A8s for previous patches ...), but.. I am not sure what you'd like me to do here -> I just dont know what the SMC convention is for all SoCs with CA15! I can help with TI SoCs for sure.. but then, Russell has a point that this is just one part of the solution -> on devices that provide secure services, there is definitely a need to lock the secure entry points down as well. But, specifically to this patch, do recommend an alternative if one exists.. will gladly follow. -- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] ARM: Introduce ability to enable invalidate of BTB with ICIALLU on Cortex-A15 for CVE-2017-5715
On 15:46-20180613, Tom Rini wrote: > On Wed, Jun 13, 2018 at 08:32:15AM -0500, Nishanth Menon wrote: > > On 23:05-20180612, Marek Vasut wrote: > > > On 06/12/2018 10:24 PM, Nishanth Menon wrote: > > [..] > > > > +#ifdef CONFIG_ARM_CORTEX_A15_CVE_2017_5715 > > > > + mrc p15, 0, r0, c1, c0, 1 @ read auxilary control register > > > > + orr r0, r0, #1 << 0 @ Enable invalidates of BTB > > > > > > Can we use BIT() macro in the assembler code too ? > > > > Probably, but just following convention in the rest of the file. Do we > > want to change from existing code? > > Agreed, we should follow the existing style (and I'm not 100% sure I > like using BIT() in asm files). OK. Will drop this feedback about BIT() macro if I have to do a v2. -- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] ARM: Introduce ability to enable invalidate of BTB with ICIALLU on Cortex-A15 for CVE-2017-5715
On 21:36-20180613, Florian Fainelli wrote: [...] > >>> c) This workaround applies to only the boot processor. It is important > >>> to apply workaround as necessary (context-save-restore) around low > >>> power context loss OR additional processors as necessary in either > >>> firmware support OR elsewhere in OS. > >> > >> About that, I don't know enough of uboot but are there existing PSCI or > >> other seemingly standard secondary core support in uboot that would make > >> us go through the same initialization as the boot CPU? If not, is > >> everything going to be largely implementation specific and > >> scattered between uboot and the hypervisors or kernel? > > > > in ARMV7 SoCs, unfortunately, we lived in a world of no-exact-standard. > > even within TI, Few of the SoCs use PSCI, others did implement custom > > SMC calls (since they existed in an architecture prior to PSCI). > > > >> > >> FWIW, this is what prompted me to submit this: > >> > >> https://patchwork.kernel.org/patch/10453643/ > > > > That wont work in a generic manner for precisely the same reason I had to do > > it with weak function in u-boot (some SoCs will only permit 'mcr > > p15, 0, r0, c1, c0, 1' in secure world and you need to make a custom smc > > call to make it happen). Unfortunately, IMHO, at least at this > > point, there'd be custom implementations per SoC and layers depending on > > where to implement it. > > It won't work in a generic manner but it will work for some platforms > where updating the firmware is impractical, and since the bits are write > ignore if your PL does not allow it, this still seems like a net win for > platforms where this is effective, and it does take care of Linux doing > the SMP bring-up of secondary cores as well. That's what we have in our > downstream tree at least, and I was hoping this could land upstream too. I think it is clear from Russell's summary that we dont want "may work" workaround in kernel/bootloaders. in case of u-boot (which this patch is about), I'd suggest adding the CONFIG_*CVE* input to the Kconfig for the SoC where you know for sure this works. Does that sound a fair tradeoff? -- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-Boot, cache speculation side channel attacks and ARM
On 01/19/2018 04:21 PM, Mark Kettenis wrote: Date: Fri, 19 Jan 2018 16:56:14 -0500 From: Tom Rini Hey all, So, now that things have quieted down a little bit in this area, I've been wondering about something. Over on the U-Boot side of things, are there changes we need to make in order to support the kernel side of the various mitigations properly? I know that for example currently https://developer.arm.com/support/security-update talks about ATF patches, in the context of AArch64 however. But on the other hand for variant 2, there's nothing listed on the Linux side for 32bit ARM, but there is for non-Linux OSes. And, in the event I'm also missing something else entirely that we need to do here, is there something that we need to be doing? Or is it still too early at this point in time to know? I think that for AArch32, the following bit advice is relevant: For Cortex-A15, set ACTLR[0]==1 from early initialization of the processor, and invalidate the branch predictor by performing an ICIALLU instruction. For now OpenBSD assumes that "the firmware" sets ACTLR[0] since this register may be read-only in non-secure mode. And unless I missed something Linux makes the same assumption. If U-Boot provides the PSCI implementation it should probably flush the BTB on affected 32-bit processors and should defenitely flush on 64-bit processors. Seeing the traffic in kernel, I think I understand these two I know of at least? A8/9/12/17: "So without IBE set, as the comments above say, the flush won't do anything." https://marc.info/?l=linux-arm-kernel&m=151566145121435&w=2 A15: ACTLR https://marc.info/?l=linux-arm-kernel&m=151562519425981&w=2 Am I misunderstanding the list we need to do in u-boot? -- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC PATCH 1/2] ARM: Introduce ability to enable ACR::IBE on Cortex-A8 for CVE-2017-5715
As recommended by Arm in [1], IBE[2] has to be enabled unconditionally
for BPIALL to be functional on Cortex-A8 processors. Provide a config
option for platforms to enable this option based on impact analysis
for products.
NOTE: This patch in itself is NOT the final solution, this requires:
a) Implementation of v7_arch_cp15_set_acr on SoCs which may not
provide direct access to ACR register.
b) Operating Systems such as Linux to provide adequate workaround in the right
locations.
[1] https://developer.arm.com/support/security-update
[2] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0344k/Bgbffjhh.html
Cc: Marc Zyngier
Cc: Russell King
Cc: Tony Lindgren
Cc: Robin Murphy
Cc: Florian Fainelli
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Christoffer Dall
Cc: Andre Przywara
Cc: Ard Biesheuvel
Cc: Tom Rini
Cc: Michael Nazzareno Trimarchi
Signed-off-by: Nishanth Menon
---
arch/arm/Kconfig | 5 +
arch/arm/cpu/armv7/start.S | 7 +--
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f6d57f5505ff..c2ac0fef9d0c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -86,6 +86,8 @@ config THUMB2_KERNEL
# CONFIG_ARM_ERRATA_621766
# CONFIG_ARM_ERRATA_798870
# CONFIG_ARM_ERRATA_801819
+# CONFIG_ARM_CORTEX_A8_CVE_2017_5715
+
config ARM_ERRATA_430973
bool
@@ -155,6 +157,9 @@ config ARM_ERRATA_852423
config ARM_ERRATA_855873
bool
+config ARM_CORTEX_A8_CVE_2017_5715
+ bool
+
config CPU_ARM720T
bool
select SYS_CACHE_SHIFT_5
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index 7e2695761e98..64c5d7598dea 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -249,12 +249,15 @@ skip_errata_801819:
pop {r1-r5} @ Restore the cpu info - fall through
#endif
-#ifdef CONFIG_ARM_ERRATA_430973
+#if defined(CONFIG_ARM_ERRATA_430973) || defined
(CONFIG_ARM_CORTEX_A8_CVE_2017_5715)
mrc p15, 0, r0, c1, c0, 1 @ Read ACR
+#ifdef CONFIG_ARM_CORTEX_A8_CVE_2017_5715
+ orr r0, r0, #(0x1 << 6) @ Set IBE bit always to enable OS WA
+#else
cmp r2, #0x21 @ Only on < r2p1
orrlt r0, r0, #(0x1 << 6) @ Set IBE bit
-
+#endif
push{r1-r5} @ Save the cpu info registers
bl v7_arch_cp15_set_acr
pop {r1-r5} @ Restore the cpu info - fall through
--
2.15.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC PATCH 2/2] ARM: Introduce ability to enable invalidate of BTB on Cortex-A15 for CVE-2017-5715
As recommended by Arm in [1], ACR needs to be set[2] to enable
invalidation of BTB. This has to be enabled unconditionally for
ICIALLU to be functional on Cortex-A15 processors. Provide a config
option for platforms to enable this option based on impact analysis
for products.
NOTE: This patch in itself is NOT the final solution, this requires:
a) Implementation of v7_arch_cp15_set_acr on SoCs which may not
provide direct access to ACR register.
b) Operating Systems such as Linux to provide adequate workaround in the
right locations.
[1] https://developer.arm.com/support/security-update
[2] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0438c/BABGHIBG.html
Cc: Marc Zyngier
Cc: Russell King
Cc: Tony Lindgren
Cc: Robin Murphy
Cc: Florian Fainelli
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Christoffer Dall
Cc: Andre Przywara
Cc: Ard Biesheuvel
Cc: Tom Rini
Cc: Michael Nazzareno Trimarchi
Signed-off-by: Nishanth Menon
---
arch/arm/Kconfig | 4
arch/arm/cpu/armv7/start.S | 8
2 files changed, 12 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index c2ac0fef9d0c..116cee559ca4 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -87,6 +87,7 @@ config THUMB2_KERNEL
# CONFIG_ARM_ERRATA_798870
# CONFIG_ARM_ERRATA_801819
# CONFIG_ARM_CORTEX_A8_CVE_2017_5715
+# CONFIG_ARM_CORTEX_A15_CVE_2017_5715
config ARM_ERRATA_430973
bool
@@ -160,6 +161,9 @@ config ARM_ERRATA_855873
config ARM_CORTEX_A8_CVE_2017_5715
bool
+config ARM_CORTEX_A15_CVE_2017_5715
+ bool
+
config CPU_ARM720T
bool
select SYS_CACHE_SHIFT_5
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index 64c5d7598dea..4835316bb37e 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -238,6 +238,14 @@ skip_errata_798870:
skip_errata_801819:
#endif
+#ifdef CONFIG_ARM_CORTEX_A15_CVE_2017_5715
+ mrc p15, 0, r0, c1, c0, 1 @ read auxilary control register
+ orr r0, r0, #1 << 0 @ Enable invalidates of BTB
+ push{r1-r5} @ Save the cpu info registers
+ bl v7_arch_cp15_set_acr
+ pop {r1-r5} @ Restore the cpu info - fall through
+#endif
+
#ifdef CONFIG_ARM_ERRATA_454179
mrc p15, 0, r0, c1, c0, 1 @ Read ACR
--
2.15.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC PATCH 0/2] ARM: v7: Enable basic framework for supporting bits for CVE-2017-5715
Hi Folks, This is a follow through on the discussion we have had in [1]. This itself is'nt a complete solution and is based on recommendation This from Arm[2] for variant 2 CVE-2017-5715 The Linux kernel discussions are spread out in [3], ATF and OPTEE status are available in [4]. This is just an RFC series (build tested at this point) to check if the direction is fine and should follow the final solution once kernel patches get to upstream, IMHO. NOTE: As per ARM recommendations[2], and discussions in list[1] ARM Cortex-A9/12/17 do not need additional steps in u-boot to enable the OS level workarounds. Nishanth Menon (2): ARM: Introduce ability to enable ACR::IBE on Cortex-A8 for CVE-2017-5715 ARM: Introduce ability to enable invalidate of BTB on Cortex-A15 for CVE-2017-5715 arch/arm/Kconfig | 9 + arch/arm/cpu/armv7/start.S | 15 +-- 2 files changed, 22 insertions(+), 2 deletions(-) [1] https://marc.info/?t=15163990652&r=1&w=2 [2] https://developer.arm.com/support/security-update [3] https://marc.info/?t=15154379047&r=1&w=2 and the latest in https://marc.info/?l=linux-arm-kernel&m=151689379521082&w=2 [4] https://github.com/ARM-software/arm-trusted-firmware/wiki/ARM-Trusted-Firmware-Security-Advisory-TFV-6 https://www.op-tee.org/security-advisories/ https://www.linaro.org/blog/meltdown-spectre/ -- 2.15.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 2/2] ARM: Introduce ability to enable invalidate of BTB on Cortex-A15 for CVE-2017-5715
On 01/26/2018 03:17 AM, Marc Zyngier wrote: On 25/01/18 21:45, Nishanth Menon wrote: As recommended by Arm in [1], ACR needs to be set[2] to enable invalidation of BTB. This has to be enabled unconditionally for ICIALLU to be functional on Cortex-A15 processors. Provide a config Not quite. ACTLR[0] (Enable invalidates of BTB) has to be set for the BTB to be invalidated on ICIALLU. ICIALLU itself is always functional (otherwise, we'd have much bigger problems). Thanks Marc. That did come out completely wrong! Sorry about that. will update once we have kernel side story complete. -- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Two U-Boot versions on same device
On Fri, Mar 5, 2010 at 1:14 PM, Rishi Dhupar wrote: > The size differences are substantial. 170 K for the regular uboot binary > and about 1.1 MB for the uboot binary with diagnostic software. > > On Fri, Mar 5, 2010 at 7:31 AM, Matthias Kaehlcke > wrote: > >> El Fri, Mar 05, 2010 at 07:09:11AM -0500 Rishi Dhupar ha dit: >> >> > Strange question but I am using an OMAP 3530 and the boot process >> currently >> > is from TI's X-Loader to U-Boot to Linux. two options: a) something called configuration header - which will allow you to boot from NAND kind of devices straight to SDRAM. b) try barebox.. I used to have something as small as 32k when it was called u-boot-v2.. Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2 09/13] arm: add Cortex A9 support
On 04/08/2010 08:43 AM, Rabin Vincent wrote:
> Add Cortex A9 support by copying the code for Cortex A8. The only
> change is a removal of some OMAP3 specific code.
Thanks :), I was hoping to help in the near future by adding OMAP4 code
in cortex a9.. ;)
>
> Acked-by: Michael Brandt
> Signed-off-by: Rabin Vincent
> ---
> cpu/{arm_cortexa8 => arm_cortexa9}/Makefile |0
> cpu/{arm_cortexa8 => arm_cortexa9}/config.mk |0
> cpu/{arm_cortexa8 => arm_cortexa9}/cpu.c |0
> cpu/{arm_cortexa8 => arm_cortexa9}/start.S| 26
> +
> cpu/{arm_cortexa8 => arm_cortexa9}/u-boot.lds |2 +-
> 5 files changed, 2 insertions(+), 26 deletions(-)
> copy cpu/{arm_cortexa8 => arm_cortexa9}/Makefile (100%)
> copy cpu/{arm_cortexa8 => arm_cortexa9}/config.mk (100%)
> copy cpu/{arm_cortexa8 => arm_cortexa9}/cpu.c (100%)
> copy cpu/{arm_cortexa8 => arm_cortexa9}/start.S (91%)
> copy cpu/{arm_cortexa8 => arm_cortexa9}/u-boot.lds (97%)
looking at the % of reuse.. for a9, cant we avoid a copy? since a9 and
a8 are both v7 instruction set anyways,
how about cpu/arm_cortexa8,a9 etc replaced by cpu/armv7 and have cortex
and soc specific code within it?
option a:
cpu/armv7/
common code.[cS..]
/cortex_a8/
/cortex_a9/
soc specific code:
option 1:
cpu/armv7/cortex_a[89]/soc
or option 2:
cpu/armv7/soc
option b:
cpu/armv7_common/
cpu/cortex_a8/
cpu/cortex_a9/
(socs thier usual place cpu/cortex_a[89]/socx
option c:
cpu/armv7
cpu/armv7/soc1
cpu/armv7/soc2
etc..
v7 has both a8 and a9 codebases..
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2 09/13] arm: add Cortex A9 support
Wolfgang Denk had written, on 04/09/2010 06:06 PM, the following: > Dear Vaibhav Bedia, > > In message > you wrote: >>> Making the folders based on ISA version would be confusing as the other ARM >> cores are not grouped that way. >> As all Cortex processors implement the ARMv7 architecture a better grouping >> IMHO would be cpu/cortex/a8 and cpu/cortex/a9. The common stuff can be under >> cpu/cortex/. > > Sounds good to me. > Ack. -- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/26] [ns16550] Enable port-mapped access
On 04/11/2010 07:43 AM, Graeme Russ wrote: > The x86 architecture exclusively uses Port-Mapped I/O (inb/outb) to access > the 16550 UARTs. This patch mimics how Linux selects between Memory-Mapped > and Port-Mapped I/O. This allows x86 boards to use CONFIG_SERIAL_MUTLI and > drop the custom serial port driver [...] > diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c > index b3bf10b..0e9beb7 100644 > --- a/drivers/serial/ns16550.c > +++ b/drivers/serial/ns16550.c > @@ -7,6 +7,8 @@ > #include > #include > #include > +#include > +#include > > #define UART_LCRVAL UART_LCR_8N1/* 8 data, 1 stop, no parity */ > #define UART_MCRVAL (UART_MCR_DTR | \ > @@ -14,28 +16,35 @@ > #define UART_FCRVAL (UART_FCR_FIFO_EN | \ >UART_FCR_RXSR |\ >UART_FCR_TXSR) /* Clear& enable FIFOs */ > +#ifdef CONFIG_X86 > +#define serial_out(x,y) outb(x,(ulong)y) > +#define serial_in(y) inb((ulong)y) > +#else > +#define serial_out(x,y) writeb(x,y) > +#define serial_in(y) readb(y) > +#endif wont it be nice if we have: CONFIG_NS16550_PORT_MAPPED CONFIG_NS16550_MEMORY_MAPPED ? rather than being tied to x86? [..] Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/26] [ns16550] Enable port-mapped access
On 04/11/2010 08:07 AM, Graeme Russ wrote: > Nishanth Menon wrote: >> On 04/11/2010 07:43 AM, Graeme Russ wrote: >>> The x86 architecture exclusively uses Port-Mapped I/O (inb/outb) to >>> access >>> the 16550 UARTs. This patch mimics how Linux selects between >>> Memory-Mapped >>> and Port-Mapped I/O. This allows x86 boards to use CONFIG_SERIAL_MUTLI >>> and >>> drop the custom serial port driver >> [...] >> > >>> +#ifdef CONFIG_X86 >>> +#define serial_out(x,y)outb(x,(ulong)y) >>> +#define serial_in(y)inb((ulong)y) >>> +#else >>> +#define serial_out(x,y) writeb(x,y) >>> +#define serial_in(y) readb(y) >>> +#endif >> >> wont it be nice if we have: >> CONFIG_NS16550_PORT_MAPPED >> CONFIG_NS16550_MEMORY_MAPPED >> ? rather than being tied to x86? > > > Hmm, true. Or maybe CONFIG_SYS_NS16550_PORT_MAPPED instead of > CONFIG_X86 so the default of memory mapped is silently retained > > I think CONFIG_SYS is more appropriate as per the README: > > * Configuration _SETTINGS_: >These depend on the hardware etc. and should not be meddled with if >you don't know what you're doing; they have names beginning with >"CONFIG_SYS_". > That does sound good.. thanks.. Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] omap4: board: change global data pointer to file scope
DECLARE_GLOBAL_DATA_PTR is currently defined within the scope
of function while it is a global pointer. Change the scope of
definition to replicate it's global scope. This seems to help
gcc 4.5 optimizations as well.
Signed-off-by: Nishanth Menon
---
arch/arm/cpu/armv7/omap4/board.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap4/board.c b/arch/arm/cpu/armv7/omap4/board.c
index 24a66f5..f967d09 100644
--- a/arch/arm/cpu/armv7/omap4/board.c
+++ b/arch/arm/cpu/armv7/omap4/board.c
@@ -32,6 +32,8 @@
#include
#include
+DECLARE_GLOBAL_DATA_PTR;
+
/*
* Routine: s_init
* Description: Does early system init of muxing and clocks.
@@ -100,7 +102,6 @@ u32 sdram_size(void)
*/
int dram_init(void)
{
- DECLARE_GLOBAL_DATA_PTR;
#if defined(CONFIG_SYS_ARM_WITHOUT_RELOC)
gd->bd->bi_dram[0].start = 0x8000;
--
1.6.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mmc: omap: timeout counter fix
Having a loop with a counter is no timing guarentee for timing
accuracy or compiler optimizations. For e.g. the same loop counter
which runs when the MPU is running at 600MHz will timeout in around
half the time when running at 1GHz. or the example where GCC 4.5
compiles with different optimization compared to GCC 4.4.
use a udelay(10) to ensure we have a predictable delay.
use an emperical number - 10 uSec ~= 1sec for a worst case timeout.
This should never happen, and is adequate imaginary condition for us
to fail with timeout.
Signed-off-by: Nishanth Menon
---
drivers/mmc/omap_hsmmc.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index 9271470..9b03ce1 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -137,7 +137,7 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd
*cmd,
{
hsmmc_t *mmc_base = (hsmmc_t *)mmc->priv;
unsigned int flags, mmc_stat;
- unsigned int retry = 0x10;
+ unsigned int retry = 10;
while ((readl(&mmc_base->pstate) & DATI_MASK) == DATI_CMDDIS)
@@ -202,6 +202,9 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd
*cmd,
do {
mmc_stat = readl(&mmc_base->stat);
+ if (!mmc_stat) {
+ udelay(10);
+ }
retry--;
} while ((mmc_stat == 0) && (retry > 0));
--
1.6.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: omap: timeout counter fix
Menon, Nishanth had written, on 10/25/2010 06:33 PM, the following:
> Having a loop with a counter is no timing guarentee for timing
> accuracy or compiler optimizations. For e.g. the same loop counter
> which runs when the MPU is running at 600MHz will timeout in around
> half the time when running at 1GHz. or the example where GCC 4.5
> compiles with different optimization compared to GCC 4.4.
> use a udelay(10) to ensure we have a predictable delay.
> use an emperical number - 10 uSec ~= 1sec for a worst case timeout.
> This should never happen, and is adequate imaginary condition for us
> to fail with timeout.
>
> Signed-off-by: Nishanth Menon
> ---
> drivers/mmc/omap_hsmmc.c |5 -
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
> index 9271470..9b03ce1 100644
> --- a/drivers/mmc/omap_hsmmc.c
> +++ b/drivers/mmc/omap_hsmmc.c
> @@ -137,7 +137,7 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd
> *cmd,
> {
> hsmmc_t *mmc_base = (hsmmc_t *)mmc->priv;
> unsigned int flags, mmc_stat;
> - unsigned int retry = 0x10;
> + unsigned int retry = 10;
>
>
> while ((readl(&mmc_base->pstate) & DATI_MASK) == DATI_CMDDIS)
> @@ -202,6 +202,9 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd
> *cmd,
>
> do {
> mmc_stat = readl(&mmc_base->stat);
> + if (!mmc_stat) {
> + udelay(10);
> + }
> retry--;
> } while ((mmc_stat == 0) && (retry > 0));
>
I am dropping this patch instead will post a major timeout cleanup for
omap_hsmmc.c -> caught a few other kickers as well :(.. darn the polling
logic is so broken in the code :(
--
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
