Hello All,
I am using AMCC sequoia board.
using u-boot version U-Boot 1.3.4
Need to implement SPI based RTC chip.
I find some problem in implementing SPI, is some patch there?
Any support appreciated.
Thanks & regards,
Zaahir Khan
___
U-Boot maili
Thanks to "Errata to MPC8569E PowerQUICC III Integrated Host Processor
Family Reference Manual, Rev. 0" document, which describes all eSDHC
pins, we can add 4-bits eSDHC support for MPC8569E-MDS boards.
Signed-off-by: Anton Vorontsov
---
board/freescale/mpc8569mds/mpc8569mds.c | 14 +++
Dear Scott Wood,
In message <4b27faf1.1070...@freescale.com> you wrote:
>
> Yes, as part of the set of patches in the custodian tree. Why introduce
> conflicts by targetting an older tree? What if the new patch depends on
> previous patches that have gone into the custodian branch?
Custodians
Hello everyone. Well, this is my first post on the list and its to announce
a small bug that I've found when using JFFS2 on NAND in UBoot.
This issue was seen only once volume production was started on a new device.
However, its a simple fix and I'm including my temporary patch for it at
the end
Dear Peter Tyser,
In message <1260900647-21296-1-git-send-email-pty...@xes-inc.com> you wrote:
> The gd->cpu pointer is set to an address located in flash when the
> probecpu() function is called while U-Boot is executing from flash.
> This pointer needs to be updated to point to an address in RAM
On Tue, Dec 15, 2009 at 02:37:59PM +, Nick Thompson wrote:
> +/*
> + * Exploit the little endianness of the ARM to do multi-byte transfers
> + * per device read. This can perform over twice as quickly as individual
> + * byte transfers when buffer alignment is conducive.
> + *
> + * NOTE: This
Wolfgang Denk wrote:
> Dear Scott Wood,
>
> In message <20091215201449.ga4...@loki.buserror.net> you wrote:
>> I don't follow -- why can't people base patches on the tree they're
>> expecting them to be applied to?
>
> In the end, people expect to have their patches applied to mainline,
> which m
From: Kumar Gala [mailto:ga...@kernel.crashing.org]
> On Dec 15, 2009, at 12:10 PM, Peter Tyser wrote:
>
> > The gd->cpu pointer is set to an address located in flash when the
> > probecpu() function is called while U-Boot is executing from flash.
> > This pointer needs to be updated to point to
Dear Scott Wood,
In message <20091215201449.ga4...@loki.buserror.net> you wrote:
>
> I don't follow -- why can't people base patches on the tree they're
> expecting them to be applied to?
In the end, people expect to have their patches applied to mainline,
which means "master" or "next", right? A
On Tue, Dec 15, 2009 at 01:15:17PM +0100, Wolfgang Denk wrote:
> Dear "kevin.morf...@fearnside-systems.co.uk",
>
> In message <4b2548eb.4000...@fearnside-systems.co.uk> you wrote:
> > Cleans up the s3c24x0 header files by changing the upper case members
> > of the s3c24x0 register structures to lo
Sanjeev Premi wrote:
> This patchset adds basic support for the AM35x
> processors. It also ensures that u-boot banner
> shows correct processor at start-up.
>
> Addition of AM35x impacts existing code for OMAP3,
> most patches in this set are applicable to both
> processor families.
>
> The seri
On Dec 15, 2009, at 12:10 PM, Peter Tyser wrote:
> The gd->cpu pointer is set to an address located in flash when the
> probecpu() function is called while U-Boot is executing from flash.
> This pointer needs to be updated to point to an address in RAM after
> relocation has occurred otherwise Li
> -Original Message-
> From: Tom [mailto:tom@windriver.com]
> Sent: Tuesday, December 15, 2009 10:44 PM
> To: Premi, Sanjeev
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH 0/2] omap3: Optimize detection
> of cpu revision
>
> Sanjeev Premi wrote:
> > Each call to get_cpu_r
The function is updated to make use of the cpu related
information extracted in arch_cpu_init().
Signed-off-by: Sanjeev Premi
---
cpu/arm_cortexa8/omap3/sys_info.c | 45
1 files changed, 30 insertions(+), 15 deletions(-)
diff --git a/cpu/arm_cortexa8/omap3
The usage of get_cpu_rev() to check for cpu revision
is no longer appropriate - after updates in previous
patches.
This patch ensures correct usage.
Signed-off-by: Sanjeev Premi
---
cpu/arm_cortexa8/omap3/cache.S | 30 --
cpu/arm_cortexa8/omap3/clock.c |3 ++-
This patch identifies exact cpu in function arch_cpu_init().
It does the following:
- It consolidates all related #defines into omap3.h.
- Prefixes CTRL_ to #defines used in comparison against
contents of Control Status Register returned by the
function get_cpu_type().
- Adds new #defines to i
This patch adds support for TI's recently announced
AM35x family of devices.
It implements function is_family() to differentiate
between OMAP34x/OMAP35x and AM35x device families at
runtime.
[1] http://www.ti.com/sitara
[2] http://www.ti.com/arm
[3]
http://tiexpressdsp.com/index.php?title=
This patchset adds basic support for the AM35x
processors. It also ensures that u-boot banner
shows correct processor at start-up.
Addition of AM35x impacts existing code for OMAP3,
most patches in this set are applicable to both
processor families.
The series has been tested on the OMAP3EVM and
The gd->cpu pointer is set to an address located in flash when the
probecpu() function is called while U-Boot is executing from flash.
This pointer needs to be updated to point to an address in RAM after
relocation has occurred otherwise Linux may not be able to boot due to
"fdt board" crashing if
On Dec 15, 2009, at 11:29 AM, Peter Tyser wrote:
> On Tue, 2009-12-15 at 10:57 -0600, Kumar Gala wrote:
>> On Dec 15, 2009, at 10:17 AM, Peter Tyser wrote:
>>
>>> On Tue, 2009-12-15 at 08:49 -0600, Kumar Gala wrote:
On Dec 15, 2009, at 1:07 AM, Ed Swarthout wrote:
> The following
On Tue, 2009-12-15 at 10:57 -0600, Kumar Gala wrote:
> On Dec 15, 2009, at 10:17 AM, Peter Tyser wrote:
>
> > On Tue, 2009-12-15 at 08:49 -0600, Kumar Gala wrote:
> >> On Dec 15, 2009, at 1:07 AM, Ed Swarthout wrote:
> >>
> >>> The following debug patch shows that gd->cpu is not being relocated t
Sanjeev Premi wrote:
> Each call to get_cpu_rev() leads to repetitive
> execution of code to detect the cpu revision.
>
> This patchset ensures that mechanism to detect
> revision is not executed each time; instead a
> stored value is returned.
>
> Since, revision info is needed in s_init(),
> th
On Dec 15, 2009, at 11:01 AM, Wolfgang Denk wrote:
> Dear Kumar Gala,
>
> In message <9053d472-817a-484d-93c1-657cf15d1...@kernel.crashing.org> you
> wrote:
>>
>> I agree w/Ed that we broke the relocation of gd->cpu with commit:
>
> I was on the verge of releasing v2009.11 - shall I wait for
On Tuesday 15 December 2009 08:51:46 Daniel Hobi wrote:
> depend dep: $(TIMESTAMP_FILE) $(VERSION_FILE) $(obj)include/autoconf.mk
> - for dir in $(SUBDIRS) ; do $(MAKE) -C $$dir _depend ; done
> + for dir in $(SUBDIRS) cpu/$(CPU) $(dir $(LDSCRIPT)) ; do \
> +
The core support for NAND booting is there already, so this patch
is pretty straightforward.
There is one trick though: top level Makefile expects nand_spl to
be in nand_spl/board/$(BOARDDIR), but we can fully reuse the code
from mpc8313erdb boards, and so to not duplicate the code we just
symlink
Dear Kumar Gala,
In message <9053d472-817a-484d-93c1-657cf15d1...@kernel.crashing.org> you wrote:
>
> I agree w/Ed that we broke the relocation of gd->cpu with commit:
I was on the verge of releasing v2009.11 - shall I wait for a fix?
Best regards,
Wolfgang Denk
--
DENX Software Engineering
Dear Kevin,
in message <4b2796b7.3000...@fearnside-systems.co.uk> you wrote:
>
> All I really wanted to do was change the sc324x0 register struct members
> to lower case, but if I do that without cleaning up the white space I
> get checkpatch.pl errors, and if I don't change the code to use the
On Dec 15, 2009, at 10:17 AM, Peter Tyser wrote:
> On Tue, 2009-12-15 at 08:49 -0600, Kumar Gala wrote:
>> On Dec 15, 2009, at 1:07 AM, Ed Swarthout wrote:
>>
>>> The following debug patch shows that gd->cpu is not being relocated to
>>> ddr. Linux may not be able to boot due to "fdt board" cra
On Tue, 2009-12-15 at 08:49 -0600, Kumar Gala wrote:
> On Dec 15, 2009, at 1:07 AM, Ed Swarthout wrote:
>
> > The following debug patch shows that gd->cpu is not being relocated to
> > ddr. Linux may not be able to boot due to "fdt board" crashing if
> > flash has been erased or changed.
> >
> >
Hi,
I have been searching the archives and I've seen posts that suggest that the
bootcount feature is trivial to implement in non PPC cpu's but haven't seen
a discussion of what would be involved or ideas on how to go about it.
I have flash (where the u-boot env. vars are stored) and EEPROM via I
On Dec 15, 2009, at 1:07 AM, Ed Swarthout wrote:
> The following debug patch shows that gd->cpu is not being relocated to
> ddr. Linux may not be able to boot due to "fdt board" crashing if
> flash has been erased or changed.
>
> On mpc8572ds:
>
> => fdt board
> fdt board
> cpu_numcores gd=3fe
Introduces various optimisations that approximately triple the
read data rate from NAND when run on da830evm.
Most of these optimisations depend on the endianess of the machine
and most of them are very similar to optimisations already present
in the Linux Kernel.
Signed-off-by: Nick Thompson
--
Wolfgang Denk wrote:
> Dear "kevin.morf...@fearnside-systems.co.uk",
>
> In message <4b2548ff.6040...@fearnside-systems.co.uk> you wrote:
>> Cleans up the s3c24x0 header files by changing the upper case members
>> of the s3c24x0 register structures to lower case and changing all code
>> that use
During parallel build, the top Makefile spawns multiple sub-makes for
targets in cpu/$(CPU) and $(dir $(LDSCRIPT)). If the .depend files are
not present in these directories, the sub-makes may end up generating
these files simultaneously which leads to corrupted content.
A typical error message is
When s_init() is called, the silicon version hasn't yet
been identified. This would lead to incorrect index in
the DPLL table.
This patch ensures that silicon is identified as first
step in s_init().
When called from s_init(), the globals updated in the
function identify_cpu() lie in 'relocated'
Each call to get_cpu_rev() leads to repetitive
execution of code to detect the cpu revision.
This patchset ensures that mechanism to detect
revision is not executed each time; instead a
stored value is returned.
Since, revision info is needed in s_init(),
the function to identify cpu revision nee
The function get_cpu_rev() is called multiple times
during execution resulting in probe into the IDCODE
register to extract the revision information.
This patch does the following:
- Moves the steps to identify static cpu information
into arch_cpu_init().
- Updates configs for all omap3 boards t
Hi, Stefan
Stefan Roese wrote:
> Felix,
>
> On Tuesday 15 December 2009 08:30:26 Felix Radensky wrote:
>
>> Can I do anything else to help you identify the problem ?
>>
>
> Do you have other PPC4xx boards, in which you could test this PCI-PCI bridge
> board?
>
No, I don't.
> Some oth
Dear "kevin.morf...@fearnside-systems.co.uk",
In message <4b2548ff.6040...@fearnside-systems.co.uk> you wrote:
> Cleans up the s3c24x0 header files by changing the upper case members
> of the s3c24x0 register structures to lower case and changing all code
> that uses these register structures.
Th
Dear "kevin.morf...@fearnside-systems.co.uk",
In message <4b2548eb.4000...@fearnside-systems.co.uk> you wrote:
> Cleans up the s3c24x0 header files by changing the upper case members
> of the s3c24x0 register structures to lower case and changing all code
> that uses these register structures.
>
Dear "kevin.morf...@fearnside-systems.co.uk",
In message <4b2548f7.2060...@fearnside-systems.co.uk> you wrote:
> Cleans up the s3c24x0 header files by changing the upper case members
> of the s3c24x0 register structures to lower case and changing all code
> that uses these register structures.
>
The EMAC IP on DM365, DM646x and DA830 is slightly different
from that on DM644x. This change updates the DaVinci EMAC driver
so that EMAC becomes operational on SOCs with EMAC v2.
Signed-off-by: Nick Thompson
Signed-off-by: Sandeep Paulraj
---
Applies to: u-boot-ti
This is a combined patch wit
On Tuesday 15 December 2009 04:21:02 Daniel Hobi wrote:
> On 11.12.2009 20:25, Mike Frysinger wrote:
> > On Thursday 10 December 2009 08:41:07 Daniel Hobi wrote:
> >> During parallel build, the top Makefile spawns multiple sub-makes
> >> for targets in cpu/$(CPU). If cpu/$(CPU)/.depend is not prese
On 11.12.2009 20:25, Mike Frysinger wrote:
> On Thursday 10 December 2009 08:41:07 Daniel Hobi wrote:
>> During parallel build, the top Makefile spawns multiple sub-makes
>> for targets in cpu/$(CPU). If cpu/$(CPU)/.depend is not present, the
>> sub-makes may end up generating this file simultaneou
Felix,
On Tuesday 15 December 2009 08:30:26 Felix Radensky wrote:
> Can I do anything else to help you identify the problem ?
Do you have other PPC4xx boards, in which you could test this PCI-PCI bridge
board?
Some other comments below.
> Thanks.
>
> Felix.
>
> Felix Radensky wrote:
> > Hi,
45 matches
Mail list logo
