Re: [U-Boot] [PATCH] Fix CONFIG_CMD_SHA1SUM
Le 04/01/2011 09:04, Alexander Holler a écrit : > Am 04.01.2011 08:47, schrieb Alexander Holler: > >> Only CONFIG_CMD_SHA1SUM should have been used. >> --- >>README |2 +- >>common/cmd_mem.c |4 ++-- >>2 files changed, 3 insertions(+), 3 deletions(-) >> > > Sorry, have forgotten that > > Signed-off-by: Alexander Holler > > Regards, > > Alexander Hi Alexander, Maybe a clearer patch subject, such as "Replace CONFIG_CMD_SHA1 with CONFIG_CMD_SHA1SUM"? I needed to read the actual changes to see CONFIG_CMD_SHA1 mentioned. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8] armv7: integrate cache maintenance support
Hi Albert,
On Saturday 08 January 2011 12:24 PM, Albert ARIBAUD wrote:
> Hi Aneesh,
>
> Le 22/12/2010 12:54, Aneesh V a écrit :
>> - Enable I-cache on bootup
>> - Enable MMU and D-cache immediately after relocation
>> - Do necessary initialization before enabling d-cache and MMU
>> - Changes to cleanup_before_linux()
>> - Make changes according to the new framework
>>
>> Signed-off-by: Aneesh V
>> ---
>>arch/arm/cpu/armv7/cpu.c | 47
>> +++
>>arch/arm/cpu/armv7/start.S | 18 +++-
>>arch/arm/lib/board.c |6 +
>>arch/arm/lib/cache-cp15.c |9
>>4 files changed, 53 insertions(+), 27 deletions(-)
>>
>> diff --git a/arch/arm/cpu/armv7/cpu.c b/arch/arm/cpu/armv7/cpu.c
>> index a01e0d6..b418304 100644
>> --- a/arch/arm/cpu/armv7/cpu.c
>> +++ b/arch/arm/cpu/armv7/cpu.c
>> @@ -38,13 +38,10 @@
>>#ifndef CONFIG_L2_OFF
>>#include
>>#endif
>> -
>> -static void cache_flush(void);
>> +#include
>>
>>int cleanup_before_linux(void)
>>{
>> -unsigned int i;
>> -
>> /*
>> * this function is called just before we call linux
>> * it prepares the processor for linux
>> @@ -53,31 +50,29 @@ int cleanup_before_linux(void)
>> */
>> disable_interrupts();
>>
>> -/* turn off I/D-cache */
>> +/*
>> + * Turn off I-cache and invalidate it
>> + */
>> icache_disable();
>> -dcache_disable();
>
> (1) -- see below
>
>> +invalidate_icache_all();
>>
>> -/* invalidate I-cache */
>> -cache_flush();
>
> (2) -- see below
>
>> -
>> -#ifndef CONFIG_L2_OFF
>> -/* turn off L2 cache */
>> -l2_cache_disable();
>> -/* invalidate L2 cache also */
>> -invalidate_dcache(get_device_type());
>> -#endif
>> -i = 0;
>> -/* mem barrier to sync up things */
>> -asm("mcr p15, 0, %0, c7, c10, 4": :"r"(i));
>> +/*
>> + * turn off D-cache
>> + * dcache_disable() in turn flushes the d-cache and disables MMU
>> + */
>> +dcache_disable();
>
> (3) -- see below
>
>> -#ifndef CONFIG_L2_OFF
>> -l2_cache_enable();
>> -#endif
>> +/*
>> + * After D-cache is flushed and before it is disabled there may
>> + * be some new valid entries brought into the cache. We are sure
>> + * that these lines are not dirty and will not affect our execution.
>> + * (because unwinding the call-stack and setting a bit in CP15 SCTRL
>> + * is all we did during this. We have not pushed anything on to the
>> + * stack. Neither have we affected any static data)
>> + * So just invalidate the entire d-cache again to avoid coherency
>> + * problems for kernel
>> + */
>> +invalidate_dcache_all();
>
> I'm not sure about the logic here, but I am no cache guru, so don't
> hesitate to make me... flush... with shame. If dcache_disable stayed in
> (1) instead of being moved to (3), wouldn't the cache_flush in (2)
> ensure the no new valid entries would appear in the dcache?
>Put another way, I'd have naively thought the sequence would be:
>
> - disable L2 cache
> - disable L1 I and D cache
> - invalidate L1 I cache and flush L1 D cache
> - flush L2 D cache
This is what I did too in the beginning. But I ran into problems with
it. Here is how:
1 - disable L2 cache
2 - disable L1 I and D cache
3 - invalidate L1 I cache and flush L1 D cache
4 - flush L2 D cache
- At step 3 and 4 we call the functions to flush the call. These
functions in their prologue push some registers(including r14) to the
stack.
- Please note that the cache is disabled at this point in time. So
the new stack contents go directly into the memory.
- Also, note that the stack may be already cached in L1 or L2(before
the caches were disabled). So we have a coherency issue here.
- Now when the caches are flushed the stack in the cache over-writes
the stack in memory thus losing the latest stack contents.
- When we try to return from the function there is a crash!
Conclusion:
1. If you disable first and then flush you have to be careful about
memory coherency in the period between disable and flush. You must not
write anything to the memory and you must be sure about what you read
from memory. This is difficult unless you program the entire thing in
assembly.
2. If you flush first and then disable you have to take care of the new
entries coming to the cache after the flush and before disabling. This
is what we are doing.
>
>> return 0;
>>}
>> -
>> -static void cache_flush(void)
>> -{
>> -asm ("mcr p15, 0, %0, c7, c5, 0": :"r" (0));
>> -}
>> diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
>> index 684f2d2..7d17f1e 100644
>> --- a/arch/arm/cpu/armv7/start.S
>> +++ b/arch/arm/cpu/armv7/start.S
>> @@ -241,6 +241,14 @@ clbss_l:str r2, [r0]/* clear
>> loop...*/
>> * initialization, now running from RAM.
>> */
>>jump_2_ram:
>> +/*
>> + * If I-cache is enabled invalidate it
Re: [U-Boot] [RFC PATCH 6/8] omap3_beagle: add nand_spl support
John,
On Saturday 08 January 2011 12:16 PM, John Rigby wrote:
> On Fri, Jan 7, 2011 at 11:33 PM, Aneesh V wrote:
>> Hi John,
>>
>> On Tuesday 28 December 2010 06:17 AM, John Rigby wrote:
>>>
>>> Signed-off-by: John Rigby
>>> +
>>> +void board_init_f(unsigned long bootflag)
>>> +{
>>> + nand_boot();
>>> +}
>>> +
>>
>> I see that you have added a call to nand_boot() in start.S too.
>> Which is the intended one?
>> If we jump to nand_boot() here bss will not be cleared, right?
>>
>> Also, I see potential issues in start.S that will prevent bss setup for
>> PRELOADERs. I will correct these in my patch.
>>
>> Best regards,
>> Aneesh
>>
>
> The call to nand_boot in board_init_f makes sense for platforms where
> the spl code does not need to be relocated because it has been loaded
> into SRAM by a mask boot rom. The later nand_boot called from start.S
> is for the traditional nand_spl case where you are typically running
> in a 4K nand controller buffer so the code needs to be relocated to
> dram after dram init.
>
> Of course my only testing has been on OMAP3 which fits the first case.
> I'm not sure if the second case even matters. The arm7 platforms I
> know about all have rom boot loaders and large enough SRAM to run the
> spl u-boot in (OMAP[34]) or have boot headers that can be used to init
> dram before loading a full u-boot into dram (i.mx5[13]).
>
> Also, I was thinking that BSS would not be used in PRELOADERs but of
> the large SRAM case it certainly would be useful to have BSS.
>
Agree. So, how about this?
1. Call relocate_code() in board_init_f() with destination address same
as TEXT_BASE
2. start.S skips the relocation, clears the bss(this needs to be fixed)
and calls board_init_r
3. Call nand_boot() in board_init_r
This is what I am planning to do for OMAP4 preloader.
> This is all new territory since previously all platforms using
> nand_spl were of the small sram variety.
>
> John
Thanks,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/8] armv7: cache maintenance operations for armv7
Le 08/01/2011 07:36, Albert ARIBAUD a écrit : >> --- a/arch/arm/cpu/armv7/config.mk >> +++ b/arch/arm/cpu/armv7/config.mk >> @@ -23,7 +23,7 @@ >>PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float >> >># Make ARMv5 to allow more compilers to work, even though its v7a. >> -PLATFORM_CPPFLAGS += -march=armv5 >> +PLATFORM_CPPFLAGS += -march=armv7-a > > Did you check that this does not break any board using armv7? Actually I should have said "Did you check that it does not break building with any common toolchain", considering the comment above the line. And indeed, it breaks building with ELDK 4.2 toolchain. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8] arm: minor fixes for cache and mmu handling
Hi Albert,
On Saturday 08 January 2011 12:34 PM, Albert ARIBAUD wrote:
> Hi Aneesh,
>
> Le 22/12/2010 12:54, Aneesh V a écrit :
>> 1. make sure that page table setup is not done multiple times
>> 2. flush_dcache_all() is more appropriate while disabling cache
>> than a range flush on the entire memory(flush_cache())
>>
>> Provide a default implementation for flush_dcache_all()
>> for backward compatibility and to avoid build issues.
>>
>> Signed-off-by: Aneesh V
>> ---
>>arch/arm/lib/cache-cp15.c |9 +++--
>>arch/arm/lib/cache.c | 13 -
>>2 files changed, 19 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/lib/cache-cp15.c b/arch/arm/lib/cache-cp15.c
>> index ca526fb..20aa993 100644
>> --- a/arch/arm/lib/cache-cp15.c
>> +++ b/arch/arm/lib/cache-cp15.c
>> @@ -94,13 +94,18 @@ static inline void mmu_setup(void)
>> set_cr(reg | CR_M);
>>}
>>
>> +static int mmu_enabled(void)
>> +{
>> +return get_cr()& CR_M;
>> +}
>> +
>>/* cache_bit must be either CR_I or CR_C */
>>static void cache_enable(uint32_t cache_bit)
>>{
>> uint32_t reg;
>>
>> /* The data cache is not active unless the mmu is enabled too */
>> -if (cache_bit == CR_C)
>> +if ((cache_bit == CR_C)&& !mmu_enabled())
>> mmu_setup();
>> reg = get_cr(); /* get control reg. */
>> cp_delay();
>
> Do you know why double MMU setups happen? Can we not fix the execution
> path and remove the second MMU setup call there, rather that catching t
> on the fly to ignore it?
Please note that mmu_setup() was getting called unconditionally from
dcache_enable(). I see that some drivers are calling dcache_enable()
and there are u-boot commands for enabling disabling cache.
Consequently mmu_setup() may get called multiple times.
Do we want to prevent dcache_enable() from being called multiple times?
Best regards,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] USB EHCI support
I'm working on adding EHCI support for our chips to U-Boot and I'm a bit confused. In our case I have to replace the ehci_read/writel macros since all of our EHCI registers are located starting at 0x800016F000400 (notice it's a 64-bit address). Anyway, to get back to my comment, it seems that CONFIG_EHCI_DESC_BIG_ENDIAN and CONFIG_EHCI_MMIO_BIG_ENDIAN are swapped. In our case, MMIO to our registers is always big endian but we can configure the buffer and descriptor parts to be big or little endian (and several other combinations). -Aaron ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/8] armv7: cache maintenance operations for armv7
Hi Albert,
On Saturday 08 January 2011 12:06 PM, Albert ARIBAUD wrote:
> Hi Aneesh,
>
> Le 22/12/2010 12:54, Aneesh V a écrit :
>> - Add a framework for layered cache maintenance
>> - separate out SOC specific outer cache maintenance from
>>maintenance of caches known to CPU
>>
>> - Add generic ARMv7 cache maintenance operations that affect all
>> caches known to ARMv7 CPUs. For instance in Cortex-A8 these
>> opertions will affect both L1 and L2 caches. In Cortex-A9
>> these will affect only L1 cache
>>
>> - D-cache operations supported:
>> - Invalidate entire D-cache
>> - Invalidate D-cache range
>> - Flush(clean& invalidate) entire D-cache
>> - Flush D-cache range
>> - I-cache operations supported:
>> - Invalidate entire I-cache
>>
>> - Add maintenance functions for TLB, branch predictor array etc.
>>
>> - Enable -march=armv7-a so that armv7 assembly instructions can be
>> used
>>
>> Signed-off-by: Aneesh V
>> ---
>>arch/arm/cpu/armv7/Makefile |2 +-
>>arch/arm/cpu/armv7/cache_v7.c | 359
>> +
>>arch/arm/cpu/armv7/config.mk |2 +-
>>arch/arm/include/asm/armv7.h | 63 +++
>>include/common.h |5 +-
>>5 files changed, 428 insertions(+), 3 deletions(-)
>>create mode 100644 arch/arm/cpu/armv7/cache_v7.c
>>create mode 100644 arch/arm/include/asm/armv7.h
>>
>> diff --git a/arch/arm/cpu/armv7/Makefile b/arch/arm/cpu/armv7/Makefile
>> index 8c0e915..299792a 100644
>> --- a/arch/arm/cpu/armv7/Makefile
>> +++ b/arch/arm/cpu/armv7/Makefile
>> @@ -26,7 +26,7 @@ include $(TOPDIR)/config.mk
>>LIB = $(obj)lib$(CPU).o
>>
>>START := start.o
>> -COBJS := cpu.o
>> +COBJS := cpu.o cache_v7.o
>>COBJS += syslib.o
>>
>>SRCS := $(START:.o=.S) $(COBJS:.o=.c)
>> diff --git a/arch/arm/cpu/armv7/cache_v7.c b/arch/arm/cpu/armv7/cache_v7.c
>> new file mode 100644
>> index 000..0521d66
>> --- /dev/null
>> +++ b/arch/arm/cpu/armv7/cache_v7.c
>> @@ -0,0 +1,359 @@
>> +/*
>> + * (C) Copyright 2010
>> + * Texas Instruments Incorporated - http://www.ti.com/
>> + * Aneesh V
>> + *
>> + * See file CREDITS for list of people who contributed to this
>> + * project.
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License as
>> + * published by the Free Software Foundation; either version 2 of
>> + * the License, or (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program; if not, write to the Free Software
>> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
>> + * MA 02111-1307 USA
>> + */
>> +#include
>> +#include
>> +#include
>> +
>> +#define ARMV7_DCACHE_INVAL_ALL 1
>> +#define ARMV7_DCACHE_CLEAN_INVAL_ALL2
>> +#define ARMV7_DCACHE_INVAL_RANGE3
>> +#define ARMV7_DCACHE_CLEAN_INVAL_RANGE 4
>> +
>> +struct v7_outer_cache_ops v7_outer_cache;
>> +
>> +#ifndef CONFIG_SYS_NO_DCACHE
>> +/*
>> + * Write the level and type you want to Cache Size Selection
>> Register(CSSELR)
>> + * to get size details from Current Cache Size ID Register(CCSIDR)
>> + */
>> +static void set_csselr(u32 level, u32 type)
>> +{ u32 csselr = level<< 1 | type;
>> +/* Write to Cache Size Selection Register(CSSELR) */
>> +asm volatile ("mcr p15, 2, %0, c0, c0, 0" : : "r" (csselr));
>> +}
>> +
>> +static u32 get_ccsidr(void)
>> +{
>> +u32 ccsidr;
>> +/* Read current CP15 Cache Size ID Register */
>> +asm volatile ("mrc p15, 1, %0, c0, c0, 0" : "=r" (ccsidr));
>> +return ccsidr;
>> +}
>> +
>> +static u32 get_clidr(void)
>> +{
>> +u32 clidr;
>> +/* Read current CP15 Cache Level ID Register */
>> +asm volatile ("mrc p15,1,%0,c0,c0,1" : "=r" (clidr));
>> +return clidr;
>> +}
>> +
>> +/* round up the input number to a power of 2 and get the log2 */
>> +static inline u32 log_2_round_up(u32 num)
>> +{
>> +/* count leading zeros */
>> +asm volatile ("CLZ %0, %0" : "+r" (num));
>> +
>> +/* position of most significant 1 */
>> +num = 31 - num;
>> +
>> +return num;
>> +}
>> +
>> +static void v7_inval_dcache_level_setway(u32 level, u32 num_sets,
>> + u32 num_ways, u32 way_shift,
>> + u32 log2_line_len)
>> +{
>> +int way, set, setway;
>> +/*
>> + * For optimal assembly code:
>> + * a. count down
>> + * b. have bigger loop inside
>> + */
>
> Out of curiosity, can you elaborate on why the compiler would optimize
> better in these cases?
While co
Re: [U-Boot] [PATCH RFC] armv7: fixloop: don't fixup if location is NULL
Dear Minkyu Kang, Am 27.12.2010 um 11:27 schrieb Minkyu Kang: > There is possibility that pointers set to NULL before relocation. > In this case, system is hang, because of r0 is invalid location in RAM. > > Signed-off-by: Minkyu Kang > --- > arch/arm/cpu/armv7/start.S |3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S > index 684f2d2..4eeb12a 100644 > --- a/arch/arm/cpu/armv7/start.S > +++ b/arch/arm/cpu/armv7/start.S > @@ -195,6 +195,8 @@ copy_loop: > add r3, r3, r0 /* r3 <- rel dyn end in FLASH */ > fixloop: > ldr r0, [r2]/* r0 <- location to fix up, IN FLASH! > */ > + cmp r0, #0 > + beq fixskip I doubt this is correct. In my investigations for 'NULL fixup' (-> see http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/89864/focus=89906) pointed out that only symbols in 'absolute fixup' loop could be 'NULL' if there is a not aliased/empty weakly linked symbol. I did never see a 'NULL' symbol for 'relative fixup' loop! Therefore I doubt it is correct to check the location at this place. Can you please give an example? regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] armv7: fixloop: don't fixup if location is NULL
Le 08/01/2011 11:32, Andreas Bießmann a écrit : > Dear Minkyu Kang, > > Am 27.12.2010 um 11:27 schrieb Minkyu Kang: > >> There is possibility that pointers set to NULL before relocation. >> In this case, system is hang, because of r0 is invalid location in RAM. >> >> Signed-off-by: Minkyu Kang >> --- >> arch/arm/cpu/armv7/start.S |3 +++ >> 1 files changed, 3 insertions(+), 0 deletions(-) >> >> diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S >> index 684f2d2..4eeb12a 100644 >> --- a/arch/arm/cpu/armv7/start.S >> +++ b/arch/arm/cpu/armv7/start.S >> @@ -195,6 +195,8 @@ copy_loop: >> add r3, r3, r0 /* r3<- rel dyn end in FLASH */ >> fixloop: >> ldr r0, [r2]/* r0<- location to fix up, IN FLASH! */ >> +cmp r0, #0 >> +beq fixskip > > I doubt this is correct. In my investigations for 'NULL fixup' (-> see > http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/89864/focus=89906) > pointed out that only symbols in 'absolute fixup' loop could be 'NULL' if > there is a not aliased/empty weakly linked symbol. I did never see a 'NULL' > symbol for 'relative fixup' loop! > > Therefore I doubt it is correct to check the location at this place. Can you > please give an example? > > regards > > Andreas Bießmann Oops. Thanks Andreas for pointing this out. I second the question. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] "b reset" does not work in u-boot_v2010.12-rc3 with eldk4.2
Dear "MrGates", please always keep the mailing list on cc: In message you wrote: > >> These indicate that in start.S,first instruction:b reset not jump success > > > > What do you mean by that statement? > I am sorry that i have no clear. > I mean that "b reset"statement does not jump to the lable reset at line > 104 of start.S correctly. If you want to execute machine instructions one by one you should use "stepi" instead of "step". > >> The process just go from one instruction to the next. > > > > You are running series of "step" commands - you are asking the > > debugger to "go from one instruction to the next", and this is what it > > does. What else would you expect? > Maybe i misunderstand the use of "step" command of arm-linux-gdb. > I want gdb to simulate the execution sequence of my u-boot. gdb does not simulate, it actually runs the code. And the "step" command runs the code until it reaches a new source line. If you want to step on machine instruction level you should use "stepi" instead. You may also want to read the documentation, for example this section of the DULG: http://www.denx.de/wiki/view/DULG/DebuggingTricks > >> What may be the problem?any suggestions is appreciate. > > > > Where exactly do you see a problem? > compile success.But when i burn u-boot.bin into my NOR > flash(sst39vf3201).Nothing happened. > So i would like to use arm-linux-gdb(eldk-4.2) with simulating. Debugging is indeed a good idea in such a situation. Note that gdb does not "simulate". You will need a JTAG adapter to debug on the real hardware. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The only way to learn a new programming language is by writing pro- grams in it.- Brian Kernighan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] armv7: fixloop: don't fixup if location is NULL
Le 08/01/2011 11:49, Albert ARIBAUD a écrit : >> In my investigations for 'NULL fixup' (-> see >> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/89864/focus=89906) >> pointed out that only symbols in 'absolute fixup' loop could be 'NULL' >> if there is a not aliased/empty weakly linked symbol. BTW: is such a situation normal? IIUC, it means there is a weakly linked symbol without *any* defintion, *and* it is referenced in the code. Granted, maybe it is checked before it is referenced, but we may want to check for and report at build time if possible. Would that be useful? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/8] armv7: cache maintenance operations for armv7
On Saturday 08 January 2011 12:06 PM, Albert ARIBAUD wrote:
> Hi Aneesh,
Pressed the Send button too fast last time. Missed answering the last
few questions.
>> +
>> +void invalidate_dcache_all(void)
>> +{
>> +v7_maint_dcache_all(ARMV7_DCACHE_INVAL_ALL);
>> +if (v7_outer_cache.inval_all)
>> +v7_outer_cache.inval_all();
>
> Why use pointers here rather than weak functions?
In fact, I hadn't thought about it. Maybe I was biased by the Linux
implementation.The only reason I can think of is that pointer gives the
flexibility of doing this assignment at run-time. Let's say we had a
multi-platform u-boot that detects the SOC at run-time?
>
>> +}
>> +
>> +/*
>> + * Performs a clean& invalidation of the entire data cache
>> + * at all levels
>> + */
>> +void flush_dcache_all(void)
>> +{
>> +v7_maint_dcache_all(ARMV7_DCACHE_CLEAN_INVAL_ALL);
>> +if (v7_outer_cache.flush_all)
>> +v7_outer_cache.flush_all();
>> +}
>> +
>> +/*
>> + * Invalidates range in all levels of D-cache/unified cache used:
>> + * Affects the range [start, stop - 1]
>> + */
>> +void invalidate_dcache_range(unsigned long start, unsigned long stop)
>> +{
>> +
>> +v7_dcache_maint_range(start, stop, ARMV7_DCACHE_INVAL_RANGE);
>> +if (v7_outer_cache.inval_range)
>> +/* physical address is same as virtual address */
>> +v7_outer_cache.inval_range(start, stop);
>> +}
>> +
>> +/*
>> + * Flush range(clean& invalidate) from all levels of D-cache/unified
>> + * cache used:
>> + * Affects the range [start, stop - 1]
>> + */
>> +void flush_dcache_range(unsigned long start, unsigned long stop)
>> +{
>> +v7_dcache_maint_range(start, stop, ARMV7_DCACHE_CLEAN_INVAL_RANGE);
>> +if (v7_outer_cache.flush_range)
>> +/* physical address is same as virtual address */
>> +v7_outer_cache.flush_range(start, stop);
>> +}
>> +static void __v7_setup_outer_cache_ops(void)
>> +{
>> +puts("v7_setup_outer_cache_ops: dummy implementation! "
>> + "real implementation not available!!\n");
>> +}
>> +
>> +void v7_setup_outer_cache_ops(void)
>> +__attribute__((weak, alias("__v7_setup_outer_cache_ops")));
>> +
>> +void arm_init_before_mmu(void)
>> +{
>> +v7_setup_outer_cache_ops();
>> +if (v7_outer_cache.enable)
>> +v7_outer_cache.enable();
>> +invalidate_dcache_all();
>> +v7_inval_tlb();
>> +}
>> +#else
>> +void invalidate_dcache_all(void)
>> +{
>> +}
>> +
>> +void flush_dcache_all(void)
>> +{
>> +}
>> +
>> +void invalidate_dcache_range(unsigned long start, unsigned long stop)
>> +{
>> +}
>> +
>> +void flush_dcache_range(unsigned long start, unsigned long stop)
>> +{
>> +}
>> +
>> +void arm_init_before_mmu(void)
>> +{
>> +}
>> +#endif
>> +
>> +#ifndef CONFIG_SYS_NO_ICACHE
>> +/* Invalidate entire I-cache and branch predictor array */
>> +void invalidate_icache_all(void)
>> +{
>> +/*
>> + * Invalidate all instruction caches to PoU.
>> + * Also flushes branch target cache.
>> + */
>> +asm volatile ("mcr p15, 0, %0, c7, c5, 0" : : "r" (0));
>> +
>> +/* Invalidate entire branch predictor array */
>> +asm volatile ("mcr p15, 0, %0, c7, c5, 6" : : "r" (0));
>> +
>> +/* Full system DSB - make sure that the invalidation is complete */
>> +asm volatile ("DSB");
>> +/* Full system ISB - make sure the instruction stream sees it */
>> +asm volatile ("ISB");
>> +}
>> +#else
>> +void invalidate_icache_all(void)
>> +{
>> +}
>> +#endif
>> +
>> +/*
>> + * Flush range from all levels of d-cache/unified-cache used:
>> + * Affects the range [start, start + size - 1]
>> + */
>> +void flush_cache(unsigned long start, unsigned long size)
>> +{
>> +flush_dcache_range(start, start + size);
>> +}
>
> This function is the only one which is defined to something non-empty
> when CONFIG_SYS_NO_DCACHE is defined. Why is it not in the big #ifndef
> for dcache above ?
Although this function is non-empty, flush_dcache_range() is in turn
empty. Effect will be the same, right?
>
>> diff --git a/arch/arm/cpu/armv7/config.mk b/arch/arm/cpu/armv7/config.mk
>> index 49ac9c7..7f9b171 100644
>> --- a/arch/arm/cpu/armv7/config.mk
>> +++ b/arch/arm/cpu/armv7/config.mk
>> @@ -23,7 +23,7 @@
>>PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float
>>
>># Make ARMv5 to allow more compilers to work, even though its v7a.
>> -PLATFORM_CPPFLAGS += -march=armv5
>> +PLATFORM_CPPFLAGS += -march=armv7-a
>
> Did you check that this does not break any board using armv7?
I checked only Codesourcery tool chain.
Linux kernel build for a v7 architecture processor uses armv7-a. Is it
not fair to assume that the toolchain used for bootloader also supports
it? Do we have to support those out-dated compilers?
>>#
>> =
>>#
>># Supply options according to compiler version
>> diff --git a/arch/arm/include/asm/armv7.h b/arch/arm/include/asm/armv7.h
>> new
Re: [U-Boot] [PATCH 2/8] armv7: cache maintenance operations for armv7
Le 08/01/2011 14:17, Aneesh V a écrit :
>> Why use pointers here rather than weak functions?
>
> In fact, I hadn't thought about it. Maybe I was biased by the Linux
> implementation.The only reason I can think of is that pointer gives the
> flexibility of doing this assignment at run-time. Let's say we had a
> multi-platform u-boot that detects the SOC at run-time?
I know we consider multi-board u-boot binaries when boards are variant
of a given SoC, that's one reason why we wanted relocation. I'm not sure
about multi-SoC when SoC is a variant of a given cpu, though. Wolfgang,
your opinion?
>>> +void flush_cache(unsigned long start, unsigned long size)
>>> +{
>>> + flush_dcache_range(start, start + size);
>>> +}
>>
>> This function is the only one which is defined to something non-empty
>> when CONFIG_SYS_NO_DCACHE is defined. Why is it not in the big #ifndef
>> for dcache above ?
>
> Although this function is non-empty, flush_dcache_range() is in turn
> empty. Effect will be the same, right?
Yes the effect is the same, but your patch results in a non-trivially
empty function; I'd prefer it to be visibly empty when we compile
without cache support.
>>> diff --git a/arch/arm/cpu/armv7/config.mk b/arch/arm/cpu/armv7/config.mk
>>> index 49ac9c7..7f9b171 100644
>>> --- a/arch/arm/cpu/armv7/config.mk
>>> +++ b/arch/arm/cpu/armv7/config.mk
>>> @@ -23,7 +23,7 @@
>>> PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float
>>>
>>> # Make ARMv5 to allow more compilers to work, even though its v7a.
>>> -PLATFORM_CPPFLAGS += -march=armv5
>>> +PLATFORM_CPPFLAGS += -march=armv7-a
>>
>> Did you check that this does not break any board using armv7?
>
> I checked only Codesourcery tool chain.
> Linux kernel build for a v7 architecture processor uses armv7-a. Is it
> not fair to assume that the toolchain used for bootloader also supports
> it? Do we have to support those out-dated compilers?
Just because Linux uses armv7-a for a v7 arch does not mean we must have
it for u-boot. For starters, U-boot does not always boot Linux. :)
As for out-dated compilers, that's the question I'm asking: do we
consider e.g. ELDK 4.2 as outdated or not? It won't accept armv7-a.
>>> +/* some utility macros */
>>> +#define mask(start, end) \
>>> + (((1<< ((end) - (start) + 1)) - 1)<< (start))
>>> +
>>> +#define mask_n_get(reg, start, end) \
>>> + (((reg)& mask(start, end))>> (start))
>>
>> Seeing as these functions are only used in the ARMv7 cache C file, they
>> should be moved there.
>
> I plan to use a modified version of mask_n_get() and its set couterpart
> mask_n_set() in my subsequent works in more files.
>
> Can I keep it here itself or should I move it to an OMAP specific
> header file or can I move it to a more generic header file? Please
> suggest.
They're very generic actually. I think they should go to a gereric bit
manipulation header, and be named a... bit... more explicitly. For
instance, the name 'mask' does not show that the macro creates a range
of 'one' bits from start to end.
> Best regards,
> Aneesh
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] SMDK6400:use common arm1176 u-boot.lds of cpu layer
On 01/08/2011 02:04 PM, Albert ARIBAUD wrote: > Le 07/01/2011 16:53, seedshope a écrit : >> From: seedshope >> >> Remove u-boot-nand.lds from board/samsung/smdk6400 and >> use the common u-boot.lds of arm1176 cpu layer. This >> patch also fix the building errors: >> >> arch/arm/cpu/arm1176/s3c64xx/libs3c64xx.o: In function `mem_ctrl_asm_init': >> arch/arm/cpu/arm1176/s3c64xx/cpu_init.S:32: multiple definition of >> `mem_ctrl_asm_init' >> arch/arm/cpu/arm1176/s3c64xx/cpu_init.S:32: first defined here >> arch/arm/cpu/arm1176/start.o: In function `_rel_dyn_start_ofs': >> arch/arm/cpu/arm1176/start.S:379: undefined reference to `__rel_dyn_start' >> arch/arm/cpu/arm1176/start.o: In function `_rel_dyn_end_ofs': >> arch/arm/cpu/arm1176/start.S:379: undefined reference to `__rel_dyn_end' >> arch/arm/cpu/arm1176/start.o: In function `_dynsym_start_ofs': >> arch/arm/cpu/arm1176/start.S:379: undefined reference to `__dynsym_start' >> >> Signed-off-by: seedshope > In the current u-boot-arm tree, board/samsung/smdk6400/u-boot-nand.lds > and arch/arm/cpu/arm1176/u-boot.lds are identical; I am thus ok with the > change in itself since the board lds file was useless, but I am not sure > the description is valid. Can you double-check this change wrt to the > link issue? I am sure the link issue. But I need to adjust the patch. I should be modify base on board/samsung/smdk6400/u-boot-nand.lds, Don't delete it. > Amicalement, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] SMDK6400: Fix build error for smdk6400 nand_spl support
On 01/08/2011 02:14 PM, Albert ARIBAUD wrote: > Hi seedshope, > > Le 07/01/2011 16:53, seedshope a écrit : >> From: seedshope >> >> Modify u-boot.lds from nand_spl/board/samsung/smdk6400. > You're also modifying start.S. If you mention files in the patch > summary, then please mention them all. ok >> start.o: In function `clbss_l': >> nand_spl/board/samsung/smdk6400/start.S:357: undefined reference to >> `coloured_LED_init' >> nand_spl/board/samsung/smdk6400/start.S:358: undefined reference to >> `red_LED_on' >> start.o: In function `_rel_dyn_start_ofs': >> nand_spl/board/samsung/smdk6400/start.S:366: undefined reference to >> `__rel_dyn_start' >> start.o: In function `_rel_dyn_end_ofs': >> nand_spl/board/samsung/smdk6400/start.S:366: undefined reference to >> `__rel_dyn_end' >> start.o: In function `_dynsym_start_ofs': >> nand_spl/board/samsung/smdk6400/start.S:366: undefined reference to >> `__dynsym_start' >> >> Signed-off-by: seedshope > Please limit the commit message to a simple explanation of the issue > fixed, without pasting detailed build messages int it. Here for instance > you need only indicate that you're removing references to relocation > symbols and calls to LED functions. ok Thanks, seedshope > Amicalement, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] SMDK6400: Fix CONFIG_SYS_INIT_SP_ADDR undeclared
On 01/08/2011 01:55 PM, Albert ARIBAUD wrote: > Le 07/01/2011 16:53, seedshope a écrit : >> From: seedshope >> >> CONFIG_SYS_INIT_SP_ADDR point the last PHY of IRAM >> and substract the global size. >> >> Signed-off-by: seedshope > Please fix the From: line in all patches in this set; it should not > appear in the long commit message. ok, I will send RR2. Thanks, seedshope > Amicalement, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] SMDK6400: Fix build error for smdk6400 nand_spl support
Dear seedshope, On 8 January 2011 00:53, seedshope wrote: > From: seedshope > > Modify u-boot.lds from nand_spl/board/samsung/smdk6400. > > start.o: In function `clbss_l': > nand_spl/board/samsung/smdk6400/start.S:357: undefined reference to > `coloured_LED_init' > nand_spl/board/samsung/smdk6400/start.S:358: undefined reference to > `red_LED_on' > start.o: In function `_rel_dyn_start_ofs': > nand_spl/board/samsung/smdk6400/start.S:366: undefined reference to > `__rel_dyn_start' > start.o: In function `_rel_dyn_end_ofs': > nand_spl/board/samsung/smdk6400/start.S:366: undefined reference to > `__rel_dyn_end' > start.o: In function `_dynsym_start_ofs': > nand_spl/board/samsung/smdk6400/start.S:366: undefined reference to > `__dynsym_start' > > Signed-off-by: seedshope > > diff --git a/arch/arm/cpu/arm1176/start.S b/arch/arm/cpu/arm1176/start.S > index 237dcfe..bde0357 100644 > --- a/arch/arm/cpu/arm1176/start.S > +++ b/arch/arm/cpu/arm1176/start.S > @@ -353,10 +353,11 @@ clbss_l:str r2, [r0] /* clear > loop... */ > add r0, r0, #4 > cmp r0, r1 > bne clbss_l > - > +#ifndef CONFIG_NAND_SPL CONFIG_PRELOADER is better > bl coloured_LED_init > bl red_LED_on > #endif > +#endif > > /* Thanks Minkyu Kang -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] SMDK6400: Fix CONFIG_SYS_INIT_SP_ADDR undeclared
Le 08/01/2011 16:10, seedshope a écrit : > On 01/08/2011 01:55 PM, Albert ARIBAUD wrote: >> Le 07/01/2011 16:53, seedshope a écrit : >>> From: seedshope >>> >>> CONFIG_SYS_INIT_SP_ADDR point the last PHY of IRAM >>> and substract the global size. >>> >>> Signed-off-by: seedshope >> Please fix the From: line in all patches in this set; it should not >> appear in the long commit message. > ok, I will send RR2. > > Thanks, You're welcome. Don't forget to add some history in V2, so that people can tell what you changed from V1 to V2 of the patch. > seedshope Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] armv7: fixloop: don't fixup if location is NULL
> > Le 08/01/2011 11:49, Albert ARIBAUD a écrit : > > >> In my investigations for 'NULL fixup' (-> see > >> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/89864/focus=89906) > >> pointed out that only symbols in 'absolute fixup' loop could be 'NULL' > >> if there is a not aliased/empty weakly linked symbol. > > BTW: is such a situation normal? IIUC, it means there is a weakly linked > symbol without *any* defintion, *and* it is referenced in the code. > Granted, maybe it is checked before it is referenced, but we may want to > check for and report at build time if possible. Would that be useful? Not very normal but it is a bug that should be fixed so you don't crash and burn. The behaviour should be the same on all archs. Then you could consider adding a build time failure for undef weaks if WD et. all think it is a good idea. I don't see a good reason to ban undef. weaks ATM. One day they might be needed. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] armv7: fixloop: don't fixup if location is NULL
Dear Albert ARIBAUD, Am 08.01.2011 um 13:18 schrieb Albert ARIBAUD: > Le 08/01/2011 11:49, Albert ARIBAUD a écrit : > >>> In my investigations for 'NULL fixup' (-> see >>> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/89864/focus=89906) >>> pointed out that only symbols in 'absolute fixup' loop could be 'NULL' >>> if there is a not aliased/empty weakly linked symbol. > > BTW: is such a situation normal? IIUC, it means there is a weakly linked > symbol without *any* defintion, *and* it is referenced in the code. Yes you may have a weakly linked symbol which was declared but nowhere implemented. See http://patchwork.ozlabs.org/patch/73647, this fixed such a situation for arm920t/at91 style SoC. BTW: Without the mentioned patch there was another issue with linking (-> see http://patchwork.ozlabs.org/patch/73563). The linker introduced a .plt section which could not be placed and lead to a segfault of linker. > Granted, maybe it is checked before it is referenced, but we may want to > check for and report at build time if possible. Would that be useful? AFAIR there was a statement to remove those 'undefined weakly linked symbols' from code. So it would be useful to have a tool to detect those symbols at build time. regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 6/8] omap3_beagle: add nand_spl support
On Sat, Jan 8, 2011 at 1:33 AM, Aneesh V wrote:
> John,
> On Saturday 08 January 2011 12:16 PM, John Rigby wrote:
>>
>> On Fri, Jan 7, 2011 at 11:33 PM, Aneesh V wrote:
>>>
>>> Hi John,
>>>
>>> On Tuesday 28 December 2010 06:17 AM, John Rigby wrote:
Signed-off-by: John Rigby
+
+void board_init_f(unsigned long bootflag)
+{
+ nand_boot();
+}
+
>>>
>>> I see that you have added a call to nand_boot() in start.S too.
>>> Which is the intended one?
>>> If we jump to nand_boot() here bss will not be cleared, right?
>>>
>>> Also, I see potential issues in start.S that will prevent bss setup for
>>> PRELOADERs. I will correct these in my patch.
>>>
>>> Best regards,
>>> Aneesh
>>>
>>
>> The call to nand_boot in board_init_f makes sense for platforms where
>> the spl code does not need to be relocated because it has been loaded
>> into SRAM by a mask boot rom. The later nand_boot called from start.S
>> is for the traditional nand_spl case where you are typically running
>> in a 4K nand controller buffer so the code needs to be relocated to
>> dram after dram init.
>>
>> Of course my only testing has been on OMAP3 which fits the first case.
>> I'm not sure if the second case even matters. The arm7 platforms I
>> know about all have rom boot loaders and large enough SRAM to run the
>> spl u-boot in (OMAP[34]) or have boot headers that can be used to init
>> dram before loading a full u-boot into dram (i.mx5[13]).
>>
>> Also, I was thinking that BSS would not be used in PRELOADERs but of
>> the large SRAM case it certainly would be useful to have BSS.
>>
>
> Agree. So, how about this?
> 1. Call relocate_code() in board_init_f() with destination address same
> as TEXT_BASE
> 2. start.S skips the relocation, clears the bss(this needs to be fixed)
> and calls board_init_r
> 3. Call nand_boot() in board_init_r
>
> This is what I am planning to do for OMAP4 preloader.
>
Sounds good to me.
Hopefully in the next couple of days I will have time to send a new
series of my own. Then we need to combine the two. So there is one
unified series for proposing for acceptance.
John
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] spi: add new driver for OpenCores tiny_spi
This patch adds support for OpenCores tiny_spi.
http://opencores.org/project,tiny_spi
Signed-off-by: Thomas Chou
---
drivers/spi/Makefile |1 +
drivers/spi/oc_tiny_spi.c | 241 +
2 files changed, 242 insertions(+), 0 deletions(-)
create mode 100644 drivers/spi/oc_tiny_spi.c
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index e34a124..8ad1d7f 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -35,6 +35,7 @@ COBJS-$(CONFIG_KIRKWOOD_SPI) += kirkwood_spi.o
COBJS-$(CONFIG_MPC52XX_SPI) += mpc52xx_spi.o
COBJS-$(CONFIG_MPC8XXX_SPI) += mpc8xxx_spi.o
COBJS-$(CONFIG_MXC_SPI) += mxc_spi.o
+COBJS-$(CONFIG_OC_TINY_SPI) += oc_tiny_spi.o
COBJS-$(CONFIG_OMAP3_SPI) += omap3_spi.o
COBJS-$(CONFIG_SOFT_SPI) += soft_spi.o
diff --git a/drivers/spi/oc_tiny_spi.c b/drivers/spi/oc_tiny_spi.c
new file mode 100644
index 000..c234d90
--- /dev/null
+++ b/drivers/spi/oc_tiny_spi.c
@@ -0,0 +1,241 @@
+/*
+ * Opencore tiny_spi driver
+ *
+ * http://opencores.org/project,tiny_spi
+ *
+ * based on bfin_spi.c
+ * Copyright (c) 2005-2008 Analog Devices Inc.
+ * Copyright (C) 2010 Thomas Chou
+ *
+ * Licensed under the GPL-2 or later.
+ */
+#include
+#include
+#include
+#include
+#include
+#define TINY_SPI_RXDATA 0
+#define TINY_SPI_TXDATA 4
+#define TINY_SPI_STATUS 8
+#define TINY_SPI_CONTROL 12
+#define TINY_SPI_BAUD 16
+
+#define TINY_SPI_STATUS_TXE 0x1
+#define TINY_SPI_STATUS_TXR 0x2
+
+struct tiny_spi_host {
+ ulong base;
+ uint freq;
+ uint baudwidth;
+};
+static struct tiny_spi_host tiny_spi_host_list[] = CONFIG_SYS_TINY_SPI_LIST;
+
+struct tiny_spi_slave {
+ struct spi_slave slave;
+ struct tiny_spi_host *host;
+ uint mode;
+ uint baud;
+ uint flg;
+};
+#define to_tiny_spi_slave(s) container_of(s, struct tiny_spi_slave, slave)
+
+__attribute__((weak))
+int spi_cs_is_valid(unsigned int bus, unsigned int cs)
+{
+ return bus < ARRAY_SIZE(tiny_spi_host_list) && gpio_is_valid(cs);
+}
+
+__attribute__((weak))
+void spi_cs_activate(struct spi_slave *slave)
+{
+ struct tiny_spi_slave *tiny_spi = to_tiny_spi_slave(slave);
+ unsigned int cs = slave->cs;
+ gpio_set_value(cs, tiny_spi->flg);
+ debug("%s: SPI_CS_GPIO:%x\n", __func__, gpio_get_value(cs));
+}
+
+__attribute__((weak))
+void spi_cs_deactivate(struct spi_slave *slave)
+{
+ struct tiny_spi_slave *tiny_spi = to_tiny_spi_slave(slave);
+ unsigned int cs = slave->cs;
+ gpio_set_value(cs, !tiny_spi->flg);
+ debug("%s: SPI_CS_GPIO:%x\n", __func__, gpio_get_value(cs));
+}
+
+void spi_set_speed(struct spi_slave *slave, uint hz)
+{
+ struct tiny_spi_slave *tiny_spi = to_tiny_spi_slave(slave);
+ struct tiny_spi_host *host = tiny_spi->host;
+ tiny_spi->baud = DIV_ROUND_UP(host->freq, hz * 2) - 1;
+ if (tiny_spi->baud > (1 << host->baudwidth) - 1)
+ tiny_spi->baud = (1 << host->baudwidth) - 1;
+ debug("%s: speed %u actual %u\n", __func__, hz,
+ host->freq / ((tiny_spi->baud + 1) * 2));
+}
+
+void spi_init(void)
+{
+}
+
+struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
+ unsigned int hz, unsigned int mode)
+{
+ struct tiny_spi_slave *tiny_spi;
+
+ if (!spi_cs_is_valid(bus, cs) || gpio_request(cs, "tiny_spi"))
+ return NULL;
+
+ tiny_spi = malloc(sizeof(*tiny_spi));
+ if (!tiny_spi)
+ return NULL;
+ memset(tiny_spi, 0, sizeof(*tiny_spi));
+
+ tiny_spi->slave.bus = bus;
+ tiny_spi->slave.cs = cs;
+ tiny_spi->host = &tiny_spi_host_list[bus];
+ tiny_spi->mode = mode & (SPI_CPOL | SPI_CPHA);
+ tiny_spi->flg = mode & SPI_CS_HIGH ? 1 : 0;
+ spi_set_speed(&tiny_spi->slave, hz);
+
+ debug("%s: bus:%i cs:%i base:%lx\n", __func__,
+ bus, cs, tiny_spi->host->base);
+ return &tiny_spi->slave;
+}
+
+void spi_free_slave(struct spi_slave *slave)
+{
+ struct tiny_spi_slave *tiny_spi = to_tiny_spi_slave(slave);
+ gpio_free(slave->cs);
+ free(tiny_spi);
+}
+
+int spi_claim_bus(struct spi_slave *slave)
+{
+ struct tiny_spi_slave *tiny_spi = to_tiny_spi_slave(slave);
+ struct tiny_spi_host *host = tiny_spi->host;
+ debug("%s: bus:%i cs:%i\n", __func__, slave->bus, slave->cs);
+ gpio_direction_output(slave->cs, !tiny_spi->flg);
+ writel(tiny_spi->mode, host->base + TINY_SPI_CONTROL);
+ writel(tiny_spi->baud, host->base + TINY_SPI_BAUD);
+ return 0;
+}
+
+void spi_release_bus(struct spi_slave *slave)
+{
+ debug("%s: bus:%i cs:%i\n", __func__, slave->bus, slave->cs);
+}
+
+#ifndef CONFIG_TINY_SPI_IDLE_VAL
+# define CONFIG_TINY_SPI_IDLE_VAL 0xff
+#endif
+
+int spi_xfer(struct spi_slave *slave, unsigned int bitlen, const void *dout,
+void *din, unsigned long flags)
+{
+ struct tiny_spi_host *host = to_tiny_spi_slave(slav
Re: [U-Boot] [PATCH 3/3] SMDK6400: Fix build error for smdk6400 nand_spl support
On 01/08/2011 11:15 PM, Minkyu Kang wrote: > Dear seedshope, > > On 8 January 2011 00:53, seedshope wrote: >> From: seedshope >> >> Modify u-boot.lds from nand_spl/board/samsung/smdk6400. >> >> start.o: In function `clbss_l': >> nand_spl/board/samsung/smdk6400/start.S:357: undefined reference to >> `coloured_LED_init' >> nand_spl/board/samsung/smdk6400/start.S:358: undefined reference to >> `red_LED_on' >> start.o: In function `_rel_dyn_start_ofs': >> nand_spl/board/samsung/smdk6400/start.S:366: undefined reference to >> `__rel_dyn_start' >> start.o: In function `_rel_dyn_end_ofs': >> nand_spl/board/samsung/smdk6400/start.S:366: undefined reference to >> `__rel_dyn_end' >> start.o: In function `_dynsym_start_ofs': >> nand_spl/board/samsung/smdk6400/start.S:366: undefined reference to >> `__dynsym_start' >> >> Signed-off-by: seedshope >> >> diff --git a/arch/arm/cpu/arm1176/start.S b/arch/arm/cpu/arm1176/start.S >> index 237dcfe..bde0357 100644 >> --- a/arch/arm/cpu/arm1176/start.S >> +++ b/arch/arm/cpu/arm1176/start.S >> @@ -353,10 +353,11 @@ clbss_l:str r2, [r0]/* clear >> loop...*/ >> add r0, r0, #4 >> cmp r0, r1 >> bne clbss_l >> - >> +#ifndef CONFIG_NAND_SPL > CONFIG_PRELOADER is better No, The nand_spl support can't find the define of coloured_LED_init and red_LED_on. It is base on the build error: make smdk6400_config make the error information as following: nand_spl/board/samsung/smdk6400/start.S:357: undefined reference to `coloured_LED_init' nand_spl/board/samsung/smdk6400/start.S:358: undefined reference to `red_LED_on' Thanks, seedshope >> bl coloured_LED_init >> bl red_LED_on >> #endif >> +#endif >> >> /* > Thanks > Minkyu Kang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] SMDK6400: Fix CONFIG_SYS_INIT_SP_ADDR undeclared
On 01/08/2011 11:17 PM, Albert ARIBAUD wrote: > Le 08/01/2011 16:10, seedshope a écrit : >> On 01/08/2011 01:55 PM, Albert ARIBAUD wrote: >>> Le 07/01/2011 16:53, seedshope a écrit : From: seedshope CONFIG_SYS_INIT_SP_ADDR point the last PHY of IRAM and substract the global size. Signed-off-by: seedshope >>> Please fix the From: line in all patches in this set; it should not >>> appear in the long commit message. >> ok, I will send RR2. >> >> Thanks, > > You're welcome. > > Don't forget to add some history in V2, so that people can tell what > you changed from V1 to V2 of the patch. ok, Thanks, seedshope > >> seedshope > > Amicalement, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] spi: add new driver for OpenCores tiny_spi
On Saturday, January 08, 2011 18:56:03 Thomas Chou wrote: > + */ > +#include space between comment and includes > +#include > +#define TINY_SPI_RXDATA 0 space between includes and defines > +static struct tiny_spi_host tiny_spi_host_list[] = CONFIG_SYS_TINY_SPI_LIST; i think you only read this, so you'll want to add "const" > +__attribute__((weak)) > +int spi_cs_is_valid(unsigned int bus, unsigned int cs) > + > +__attribute__((weak)) > +void spi_cs_activate(struct spi_slave *slave) > + > +__attribute__((weak)) > +void spi_cs_deactivate(struct spi_slave *slave) only reason i had these marked weak in the Blackfin SPI driver was because i didn't support GPIO CS's. now that that's fixed, i dropped the weak markings. either way is fine of course; just giving some background info. > + tiny_spi->baud = DIV_ROUND_UP(host->freq, hz * 2) - 1; > + if (tiny_spi->baud > (1 << host->baudwidth) - 1) > + tiny_spi->baud = (1 << host->baudwidth) - 1; might be simpler to use: tiny_spi->baud = max(DIV_ROUND_UP(host->freq, hz * 2), (1 << host->baudwidth)) - 1; otherwise code looks fine -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] SMDK6400: Fix build error for smdk6400 nand_spl support
Hi On 9 January 2011 10:14, seedshope wrote: > On 01/08/2011 11:15 PM, Minkyu Kang wrote: >> >> Dear seedshope, >> >> On 8 January 2011 00:53, seedshope wrote: >>> >>> From: seedshope >>> >>> Modify u-boot.lds from nand_spl/board/samsung/smdk6400. >>> >>> start.o: In function `clbss_l': >>> nand_spl/board/samsung/smdk6400/start.S:357: undefined reference to >>> `coloured_LED_init' >>> nand_spl/board/samsung/smdk6400/start.S:358: undefined reference to >>> `red_LED_on' >>> start.o: In function `_rel_dyn_start_ofs': >>> nand_spl/board/samsung/smdk6400/start.S:366: undefined reference to >>> `__rel_dyn_start' >>> start.o: In function `_rel_dyn_end_ofs': >>> nand_spl/board/samsung/smdk6400/start.S:366: undefined reference to >>> `__rel_dyn_end' >>> start.o: In function `_dynsym_start_ofs': >>> nand_spl/board/samsung/smdk6400/start.S:366: undefined reference to >>> `__dynsym_start' >>> >>> Signed-off-by: seedshope >>> >>> diff --git a/arch/arm/cpu/arm1176/start.S b/arch/arm/cpu/arm1176/start.S >>> index 237dcfe..bde0357 100644 >>> --- a/arch/arm/cpu/arm1176/start.S >>> +++ b/arch/arm/cpu/arm1176/start.S >>> @@ -353,10 +353,11 @@ clbss_l:str r2, [r0] /* clear >>> loop... */ >>> add r0, r0, #4 >>> cmp r0, r1 >>> bne clbss_l >>> - >>> +#ifndef CONFIG_NAND_SPL >> >> CONFIG_PRELOADER is better > > No, The nand_spl support can't find the define of coloured_LED_init and > red_LED_on. > It is base on the build error: > > make smdk6400_config > make > the error information as following: > > nand_spl/board/samsung/smdk6400/start.S:357: undefined reference to > `coloured_LED_init' > nand_spl/board/samsung/smdk6400/start.S:358: undefined reference to > `red_LED_on' > Please add follow define at Makefile. AFLAGS += -DCONFIG_PRELOADER -DCONFIG_NAND_SPL CFLAGS += -DCONFIG_PRELOADER -DCONFIG_NAND_SPL Thanks Minkyu Kang -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
