On 11/05/2015 06:39 PM, Steve Kipisz wrote:
[...]
> +#define TI_EEPROM_HDR_NAME_LEN 8
> +#define TI_EEPROM_HDR_REV_LEN12
> +#define TI_EEPROM_HDR_SERIAL_LEN 4
^^ minor typo here as well. Serial should be 12 and REV is 4.
[...]
--
Regards,
Nisha
me dt
overlay instead of evm dtb. I dont know about what will eventually
become in upstream. So, I suggest dropping the above change.
Also, in the future, could you cc beagleboard-x15
<beagleboard-...@googlegroups.com> for all patches that impact
beagleboard-X15 I am sure folks there will be in
> + * @rev_tag:Revision tag to check in eeprom
>>> + * @cmp_len:How many chars to compare?
>>> + *
>>> + * NOTE: revision information is often messed up (hence the str len
>>> match) :(
>>> + *
>>> + * Return: false if board information does not match OR eeprom
>>> was'nt read.
>>> + * true otherwise
>>> + */
>>> +static inline bool board_am_rev_is(char *rev_tag, int cmp_len)
>>> +{
>>> +struct ti_am_eeprom *ep = TI_AM_EEPROM_DATA;
>>> +int l;
>>> +
>>> +if (ep->header != TI_EEPROM_HEADER_MAGIC)
>>> +return false;
>>> +
>>> +l = cmp_len > TI_EEPROM_HDR_REV_LEN ? TI_EEPROM_HDR_NAME_LEN :
>>> cmp_len;
>>> +return !strncmp(ep->version, rev_tag, l);
>>> +}
>>
>> Same here.
>>
> I thought by making them static inline would save space.
I prefer that myself as well.
--
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
int rc;
> +
> + /* Incase of invalid eeprom contents */
> + p->name[0] = 0x00;
> + p->version[0] = 0x00;
> + p->serial[0] = 0x00;
> +
> + rc = ti_i2c_eeprom_am_get(bus_addr, dev_addr, );
> + if (rc)
> + return rc;
> +
> + /*
> + * Alas! we have to null terminate and cleanup the strings!
> + */
> + strlcpy(p->name, ep->name, TI_EEPROM_HDR_NAME_LEN);
> + ti_eeprom_string_cleanup(p->name);
> + strlcpy(p->version, ep->version, TI_EEPROM_HDR_NAME_LEN);
> + ti_eeprom_string_cleanup(p->version);
> + strlcpy(p->serial, ep->serial, TI_EEPROM_HDR_NAME_LEN);
> + ti_eeprom_string_cleanup(p->serial);
> + return 0;
> +}
> +
> +void __maybe_unused set_board_info_env(char *name, char *revision,
> +char *serial)
> +{
> + char *unknown = "unknown";
> +
> + if (name)
> + setenv("board_name", name);
> +
> + if (revision)
> + setenv("board_revision", revision);
> + else
> + setenv("board_revision", unknown);
> +
> + if (serial)
> + setenv("board_serial", serial);
> + else
> + setenv("board_serial", unknown);
> +}
>
I just think a single file should be sufficient here.
--
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
h.
If I attempt to apply this series on current u-boot master, I will
fail and that does not give me a good impression of the series overall.
Apologies on ranting about this, but I'd thought it might help you
give a better perspective of what, at least I, as a reviewer would
like to see in a series.
--
ve?
> AFAIK, inline places the function code inside the the caller function
> and thus spreads into each caller, no? It probably saves some branches,
> but how does that save space?
I dont think it saves space, but rather a function call overhead for
trivial code as above.
> Also, AFAIR, we try to not place code inside headers, unless the code
> is a stub.
That does not always make sense. here it is a straight forward
comparison.. why hide it a function call deep when you can inline it?
--
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
On 11/04/2015 05:43 PM, Nishanth Menon wrote:
[...]
>> index 5cd6873f5e97..9d85d31b2cf1 100644
>> --- a/board/ti/am57xx/Makefile
>> +++ b/board/ti/am57xx/Makefile
>> @@ -6,3 +6,5 @@
>> #
>>
>> obj-y := board.o
>> +obj-y += ../commo
On 11/05/2015 01:28 AM, Nishanth Menon wrote:
> When the vendor common libraries exists, then board should be able to
> reference headers located there, rather than having to do weird logic
> such as '#include "../common/xyz.h"'.
>
> Signed-off-by: Ni
/
libs-$(HAVE_VENDOR_COMMON_LIB) += board/$(VENDOR)/common/
--
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
When the vendor common libraries exists, then board should be able to
reference headers located there, rather than having to do weird logic
such as '#include "../common/xyz.h"'.
Signed-off-by: Nishanth Menon <n...@ti.com>
---
Makefile| 1 +
board/ti/am57xx/b
On 11/03/2015 03:07 PM, Igor Grinberg wrote:
> On 11/03/15 19:45, Nishanth Menon wrote:
>> On 11/03/2015 11:02 AM, Igor Grinberg wrote:
>>
>>>>>>> +
>>>>>>> +/**
>>>>>>> + * board_am_rev_is() - Compare board revision
On Thu, Nov 5, 2015 at 6:15 PM, Simon Glass <s...@chromium.org> wrote:
> Hi,
>
> On 5 November 2015 at 00:32, Nishanth Menon <n...@ti.com> wrote:
>> On 11/05/2015 01:28 AM, Nishanth Menon wrote:
>>> When the vendor common libraries exists, then board should be a
On 11/05/2015 10:50 PM, Masahiro Yamada wrote:
> 2015-11-06 12:30 GMT+09:00 Nishanth Menon <n...@ti.com>:
>> On Thu, Nov 5, 2015 at 6:15 PM, Simon Glass <s...@chromium.org> wrote:
>>> Hi,
>>>
>>> On 5 November 2015 at 00:32, Nishanth Menon <n...@t
On 11:10-20151106, Nishanth Menon wrote:
> On 11/05/2015 10:50 PM, Masahiro Yamada wrote:
> > 2015-11-06 12:30 GMT+09:00 Nishanth Menon <n...@ti.com>:
> >> On Thu, Nov 5, 2015 at 6:15 PM, Simon Glass <s...@chromium.org> wrote:
> >>> Hi,
> >>>
100%)
> rename board/ti/{beagle_x15 => am57xx}/mux_data.h (100%)
> delete mode 100644 board/ti/beagle_x15/MAINTAINERS
> rename configs/{beagle_x15_defconfig => am57xx_evm_nodt_defconfig} (100%)
> rename include/configs/{beagle_x15.h => am57xx_evm.h} (96%)
Mostly looks fine to
; > that, no - let the compiler do the gc anyways?
> The gc should work, yes. But this is also TI-centric code and should
> end up in board/ti/ similar to how the Siemens AM335x EEPROM code is
> under board/siemens/ because they didn't re-use the TI format :)
aaah
> U-Boot#
>>
>> So, if this patch has no chance for mainline, please let me
>> know it, thanks!
>>
>
> IIRC, Nishanth had posted a patch something similar but got rejected for
> some reason. Probably Nishanth can comment more here.
>
overall the feedback I rece
On Thu, Aug 27, 2015 at 10:49 AM, Simon Glass s...@chromium.org wrote:
+U-Boot
Aaah.. i missed a reply-all, did'nt I?.. Sorry about that.
On 26 August 2015 at 16:51, Nishanth Menon n...@ti.com wrote:
On Tue, Aug 25, 2015 at 9:26 PM, Simon Glass s...@chromium.org wrote:
+#include dm
Introduce dummy devices for sandbox remoteproc device and enable it by
default
Signed-off-by: Nishanth Menon n...@ti.com
---
Changes in V2:
- review comments incorporated from V1.
V1: https://patchwork.ozlabs.org/patch/510196/
arch/sandbox/dts/test.dts | 13 +
configs
Use the sandbox environment for the basic tests.
Signed-off-by: Nishanth Menon n...@ti.com
---
New patch.
test/dm/Makefile | 1 +
test/dm/remoteproc.c | 67
2 files changed, 68 insertions(+)
create mode 100644 test/dm/remoteproc.c
diff
, no
execution from external memory, or specific image format needs). This
basic framework can then (hopefully) be extensible to other complex SoC
processor support as need be.
Signed-off-by: Nishanth Menon n...@ti.com
---
Changes in V2:
- review comments incorporated from v1
V1: https
with empty hooks. Idea being to give
an approximate idea to implement own remoteproc driver using this as a
template.
Signed-off-by: Nishanth Menon n...@ti.com
---
Changes in V2:
- review comments incorporated from v1
V1: https://patchwork.ozlabs.org/patch/510197/
drivers/remoteproc
://pastebin.ubuntu.com/12212006/
Nishanth Menon (4):
drivers: Introduce a simplified remoteproc framework
remoteproc: Introduce a sandbox dummy driver
sandbox: Introduce dummy remoteproc nodes
test: Add basic tests for remoteproc
arch/sandbox/dts/test.dts | 13 +
common/Kconfig
On 21:46-20150901, Simon Glass wrote:
> On 27 August 2015 at 22:07, Nishanth Menon <n...@ti.com> wrote:
> > Use the sandbox environment for the basic tests.
> >
> > Signed-off-by: Nishanth Menon <n...@ti.com>
> > ---
> > New patch.
> >
> &g
int rproc_ping(int id);
> > +int rproc_is_running(int id);
>
> Can you move your function comments to here? This where you define
> your API, and it is the file that people will read.
Will do so as well.
--
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
On 21:46-20150901, Simon Glass wrote:
> On 27 August 2015 at 22:07, Nishanth Menon <n...@ti.com> wrote:
>
[...]
> Reviewed-by: Simon Glass <s...@chromium.org>
Thanks. will update and post the next rev with the mentioned changes
incorporated.
>
> Nit below.
[...]
&
Use the sandbox environment for the basic tests.
Reviewed-by: Simon Glass <s...@chromium.org>
Tested-by: Simon Glass <s...@chromium.org>
Signed-off-by: Nishanth Menon <n...@ti.com>
---
Changes since V1:
- Comment cleanup (dropped '..')
- Picked up Simon's Tested
, no
execution from external memory, or specific image format needs). This
basic framework can then (hopefully) be extensible to other complex SoC
processor support as need be.
Reviewed-by: Simon Glass <s...@chromium.org>
Signed-off-by: Nishanth Menon <n...@ti.com>
---
Changes since V2:(re
with empty hooks. Idea being to give
an approximate idea to implement own remoteproc driver using this as a
template.
Reviewed-by: Simon Glass <s...@chromium.org>
Signed-off-by: Nishanth Menon <n...@ti.com>
---
Changes Since V2:
- Fixed TODO message for removal of non-DT
Introduce dummy devices for sandbox remoteproc device and enable it by
default
Reviewed-by: Simon Glass <s...@chromium.org>
Signed-off-by: Nishanth Menon <n...@ti.com>
---
Changes since V2:
- Picked up Simon's reviewed-by from V2.
V2: https://patchwork.ozlabs.org/patch/51175
://marc.info/?l=u-boot=144073487701030=2
V1: http://lists.denx.de/pipermail/u-boot/2015-August/225085.html
Test Log: http://pastebin.ubuntu.com/12432507/
Nishanth Menon (4):
drivers: Introduce a simplified remoteproc framework
remoteproc: Introduce a sandbox dummy driver
sandbox: Introduce dummy
When we use the following in bootargs:
v1=abc
v2=123-${v1}
echo $v2
we get 123-${v1}
This is because we do not recursively check to see if v2 by itself has
a hidden variable. Fix the same with recursive call
Signed-off-by: Nishanth Menon <n...@ti.com>
---
Testing with sandbox
level variable
default assignment etc would not function.
Signed-off-by: Nishanth Menon <n...@ti.com>
---
For next level recursion of variables to work, this patch depends on
https://patchwork.ozlabs.org/patch/552823/
Tested on Sandbox.
common/cli_hush.c | 24
Correct the spelling for character..
Signed-off-by: Nishanth Menon <n...@ti.com>
---
common/cli_hush.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/common/cli_hush.c b/common/cli_hush.c
index a7cac4fcb9df..5a26af80c758 100644
--- a/common/cli_hush.c
+++ b/
ed to just drop the entire series.
---
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
;
Signed-off-by: Nishanth Menon <n...@ti.com>
---
Test log: http://pastebin.ubuntu.com/13591420/
drivers/remoteproc/rproc-uclass.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/remoteproc/rproc-uclass.c
b/drivers/remoteproc/rproc-uclass.c
index a421e12e5d16..2
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 <ma...@denx.de>
> Cc: Tom Rini <tr...@konsulko.com>
> Cc: Simon Glass <s...@chromium.org>
Acked-by: Nishanth Menon <
t 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 <lokeshvu...
Enable support for PMMC the TI power processor on K2G. This processor
manages all power management related activities on the SoC and and
allows the Operating Systems on compute processors such as ARM, DSP to
offload the power logic away into the power processor.
Signed-off-by: Nishanth Menon &l
These are useful for modules that need to be held in reset and are
enabled for data to be loaded on to them. Typically these are
microcontrollers or other processing entities in the system.
Signed-off-by: Nishanth Menon <n...@ti.com>
---
V2: no change
V1: https://patchwork.ozlabs.org/patch/
u-boot coding style guidance in
http://www.denx.de/wiki/U-Boot/CodingStyle clearly mentions that the
kernel doc style shall be followed for documentation in u-boot.
Current PSC documentation standard does not, so fix that.
Signed-off-by: Nishanth Menon <n...@ti.com>
---
V2: no change
V1:
'#define X a | b' is better defined as '#define X (a | b)' for obvious
reasons.
Signed-off-by: Nishanth Menon <n...@ti.com>
---
V2: No change
V1: https://patchwork.ozlabs.org/patch/510211/
arch/arm/mach-keystone/include/mach/psc_defs.h | 6 +++---
1 file changed, 3 insertions(+), 3 del
On Fri, Feb 26, 2016 at 12:16 PM, Tom Rini <tr...@konsulko.com> wrote:
> On Thu, Feb 25, 2016 at 09:52:14AM -0600, Nishanth Menon wrote:
>
>> From: Vitaly Andrianov <vita...@ti.com>
>>
>> This commit replaces hard-coded EMIF and PHY DDR3 configurations for
&
On Fri, Feb 26, 2016 at 12:18 PM, Tom Rini <tr...@konsulko.com> wrote:
> On Thu, Feb 25, 2016 at 12:53:46PM -0600, Nishanth Menon wrote:
>
>> Enable support for PMMC the TI power processor on K2G. This processor
>> manages all power management related activities on t
On Fri, Feb 26, 2016 at 12:17 PM, Tom Rini <tr...@konsulko.com> wrote:
> On Thu, Feb 25, 2016 at 12:53:43PM -0600, Nishanth Menon wrote:
>
>> '#define X a | b' is better defined as '#define X (a | b)' for obvious
>> reasons.
>>
>> Signed-off-by: Nishanth Meno
Tom,
On Fri, Feb 26, 2016 at 6:27 PM, Tom Rini <tr...@konsulko.com> wrote:
> On Fri, Feb 26, 2016 at 06:18:30PM -0600, Nishanth Menon wrote:
>> On Fri, Feb 26, 2016 at 12:18 PM, Tom Rini <tr...@konsulko.com> wrote:
>> > On Thu, Feb 25, 2016 at 12:53:46
From: Suman Anna <s-a...@ti.com>
Define a macro for the DSP GEM power domain id number and
use it instead of a hard-coded number in the code that
disables all the DSPs on various Keystone2 SoCs.
Signed-off-by: Suman Anna <s-a...@ti.com>
Signed-off-by: Nishanth Menon <n...@ti.com
Hi,
Please find various fixes for DDR, DSP and speed grade operations
w.r.t Keystone devices
Based on master 52dd704bf8ed Merge branch 'master' of
http://git.denx.de/u-boot-sunxi
Lokesh Vutla (2):
ARM: keystone2: Allow for board specific speed definitions
ARM: keystone2: K2G: Add
m>
Signed-off-by: Nishanth Menon <n...@ti.com>
---
arch/arm/mach-keystone/clock.c | 7 +++-
arch/arm/mach-keystone/include/mach/clock-k2g.h | 4 +-
arch/arm/mach-keystone/include/mach/clock.h | 4 ++
board/ti/ks2_evm/board_k2g.c| 50 ++
lation for DDR3 with 1600MHz and 1333MHz
only.
Signed-off-by: Vitaly Andrianov <vita...@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvu...@ti.com>
Signed-off-by: Nishanth Menon <n...@ti.com>
---
arch/arm/mach-keystone/Makefile| 2 +
arch/arm/mach-keystone/d
on K2G. Do note that the PSC clock domain module id for DSP on K2G
differs from that of previous Keystone2 SoCs.
Signed-off-by: Suman Anna <s-a...@ti.com>
Signed-off-by: Nishanth Menon <n...@ti.com>
---
arch/arm/mach-keystone/include/mach/hardware-k2g.h | 7 +--
1 file changed,
From: Lokesh Vutla <lokeshvu...@ti.com>
Its not compulsory that speed definition should be same on EFUSE_BOOTROM
register for all keystone 2 devices. So, allow for board specific
speed definitions.
Signed-off-by: Lokesh Vutla <lokeshvu...@ti.com>
Signed-off-by: Nishanth Menon
hat returns ddr3 size has to be
implemented. See hardware-k2l.h
Signed-off-by: Vitaly Andrianov <vita...@ti.com>
Signed-off-by: Nishanth Menon <n...@ti.com>
---
arch/arm/mach-keystone/ddr3_spd.c | 10 ++
arch/arm/mach-keystone/include/mach/ddr3.h | 1 +
ar
With commit fe772ebd285b ("ARM: keystone2: Use common definition for
clk_get_rate"), we have centralized the clock code into a common clock
logic and the redundant files, unfortunately remained... Clean that
up.
Signed-off-by: Nishanth Menon <n...@ti.com>
---
arch/arm/mach-keys
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 <n...@ti.com>
> Cc:
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 <n...@ti.com>
---
disk/part.c |3 ++-
1 file changed, 2 insertions
ration
tool 1.1.1. NOTE: we use eeprom information (ram_size) to update the
configuration.
Tested-by: Vishal Mahaveer <vish...@ti.com>
Signed-off-by: Ravi Babu <ravib...@ti.com>
Signed-off-by: Nishanth Menon <n...@ti.com>
---
boar
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 <n...@ti.com>
---
arch/arm/cpu/armv7/omap5/hw_data.c | 16 +++-
1 file chang
/
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
From: Ravi Babu <ravib...@ti.com>
Add support for detection of SR2.0 version of DRA72x family of
processors.
Signed-off-by: Ravi Babu <ravib...@ti.com>
Signed-off-by: Nishanth Menon <n...@ti.com>
---
arch/arm/cpu/armv7/omap5/hw_data.c |2 ++
arch/arm/cpu/armv7/omap5/hw
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 <n...@ti.
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 &l
do_set_iodelay can now be used from board files based on needs of the
platforms variation they have.
Signed-off-by: Nishanth Menon <n...@ti.com>
---
arch/arm/cpu/armv7/omap5/dra7xx_iodelay.c|4 ++--
arch/arm/include/asm/arch-omap5/dra7xx_iodelay.h |2 ++
2 files chan
Based on data from EMIF configuration tool 1.1.1.
Signed-off-by: Nishanth Menon <n...@ti.com>
---
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
NFS configs/|grep -v "is not set"
it might actually be nicer.. for the actual env variables to
eventually get into include/config_distro_bootcmd.h perhaps? I dont
know about that atm..
--
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
: http://pastebin.ubuntu.com/15392337/
Nishanth Menon (3):
ARM: keystone2: Convert BOOTBITMASK to static inline function
ARM: keystone2: Convert BOOT_READ_BITFIELD into static inline function
ARM: keystone2: Convert BOOT_SET_BITFIELD into static inline function
arch/arm/mach-keystone/include
Fix up BOOT_SET_BITFIELD to be a static inline function to be readable
with the same functionality.
Reported-by: Tom Rini <tr...@konsulko.com>
Signed-off-by: Nishanth Menon <n...@ti.com>
---
arch/arm/mach-keystone/include/mach/psc_defs.h | 18 +++---
1 file changed, 1
BOOTBITMASK is almost impossible to decode, so convert it into a simpler
static line functions of equivalent solution.
Reported-by: Tom Rini <tr...@konsulko.com>
Signed-off-by: Nishanth Menon <n...@ti.com>
---
arch/arm/mach-keystone/include/mach/psc_defs.h | 14 +-
1 fil
BOOT_READ_BITFIELD can easily be a static inline function and be a
little more readable with the same functionality.
Reported-by: Tom Rini <tr...@konsulko.com>
Signed-off-by: Nishanth Menon <n...@ti.com>
---
arch/arm/mach-keystone/include/mach/psc_defs.h | 25 +++--
tivate 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 <spat...@ti.com>
Signed-off-by: Nishanth Menon <n...@ti.com>
---
X15 BOM:
system support with this patch.
Signed-off-by: Schuyler Patton <spat...@ti.com>
Signed-off-by: Steve Kipisz <s-kipi...@ti.com>
Signed-off-by: Nishanth Menon <n...@ti.com>
---
Boot Log: http://pastebin.ubuntu.com/15699618/
board/ti/am57xx/board.c| 32 +-
board/ti
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
as shared, we also ensure SoC wide coherency
is enabled.
Reported-by: Bin Liu <b-...@ti.com>
Signed-off-by: Nishanth Menon <n...@ti.com>
---
arch/arm/mach-keystone/include/mach/hardware.h | 23 ++
arch/arm/mach-keystone/init.c | 32 +++
the PCIe configuration is moved after the
msmc configuration is complete, but that should ideally have no
functional impact.
Signed-off-by: Nishanth Menon <n...@ti.com>
---
arch/arm/mach-keystone/include/mach/hardware-k2e.h | 3 --
arch/arm/mach-keystone/include/mach/hardware-k2l.h | 3 --
ar
on K2G. Do note that the PSC clock domain module id for DSP on K2G
differs from that of previous Keystone2 SoCs.
Signed-off-by: Suman Anna <s-a...@ti.com>
Signed-off-by: Nishanth Menon <n...@ti.com>
Reviewed-by: Tom Rini <tr...@konsulko.com>
---
Changes in V2:
- Picked
lation for DDR3 with 1600MHz and 1333MHz
only.
Signed-off-by: Vitaly Andrianov <vita...@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvu...@ti.com>
Signed-off-by: Nishanth Menon <n...@ti.com>
---
Changes in V2:
- Updated copyright to include 2016
- remoted puts
m>
Signed-off-by: Nishanth Menon <n...@ti.com>
Reviewed-by: Tom Rini <tr...@konsulko.com>
---
Changes in V2:
- Picked up Reviewed by
V1: https://patchwork.ozlabs.org/patch/588156/
arch/arm/mach-keystone/clock.c | 7 +++-
arch/arm/mach-keystone/inclu
hat returns ddr3 size has to be
implemented. See hardware-k2l.h
Signed-off-by: Vitaly Andrianov <vita...@ti.com>
Signed-off-by: Nishanth Menon <n...@ti.com>
Reviewed-by: Tom Rini <tr...@konsulko.com>
---
Changes in V2:
- Picked up Reviewed by
V1: https://patchwork.ozlabs
From: Suman Anna <s-a...@ti.com>
Define a macro for the DSP GEM power domain id number and
use it instead of a hard-coded number in the code that
disables all the DSPs on various Keystone2 SoCs.
Signed-off-by: Suman Anna <s-a...@ti.com>
Signed-off-by: Nishanth Menon <n...@t
From: Lokesh Vutla <lokeshvu...@ti.com>
Its not compulsory that speed definition should be same on EFUSE_BOOTROM
register for all keystone 2 devices. So, allow for board specific
speed definitions.
Signed-off-by: Lokesh Vutla <lokeshvu...@ti.com>
Signed-off-by: Nishanth Menon
Hi,
Please find various fixes for DDR, DSP and speed grade operations
w.r.t Keystone devices
Based on master 52dd704bf8ed Merge branch 'master' of
http://git.denx.de/u-boot-sunxi
Changes in V2:
- updates to patch #5 (review comments)
- picked up reviewed by
V1:
ons 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 <n...@ti.com>
---
arch/arm/cpu/armv7/omap-common/clocks-common.c | 4 ++--
arch/arm/cpu/armv7/omap5/prcm-regs.c | 2
Woodruff <r-woodru...@ti.com>
Signed-off-by: Nishanth Menon <n...@ti.com>
---
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
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
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 <r-woodru...@ti.com>
Signed-off-by: Nishanth Menon <n...@ti.com>
---
arch/a
-by: Nishanth Menon <n...@ti.com>
---
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
_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)
>
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,
>
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 <m-kariche...@ti.com>
Acked-by: Nishanth Menon <n...@ti.com>
---
arch/arm/mach-keystone/init.c |
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
On Fri, Sep 2, 2016 at 6:04 AM, Lokesh Vutla <lokeshvu...@ti.com> 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/t
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 <n...@ti.com>
---
C
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
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 <n...@ti.com>
---
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 <n...@ti.com>
---
board/ti/am57xx/MAINTAINERS | 3 ++-
1 file changed, 2 insertions(+), 1 de
config should have been initialized along with others as defaults.
Signed-off-by: Nishanth Menon <n...@ti.com>
---
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..13aac2
the empty string to the caller.
Reported-by: Brad Griffis <bgrif...@ti.com>
Signed-off-by: Nishanth Menon <n...@ti.com>
---
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
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 <n...@ti.com>
---
board/ti/common/board_detect.c | 2 +-
1 file changed, 1 insertion(+), 1 d
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
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
501 - 600 of 1416 matches
Mail list logo
