[U-Boot] Bug in netconsole?
I think there might be a bug in this commit:
http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commitdiff;h=2c8fe5120f8da013cbd789be2f10cce880972836
The commit makes "the netconsole buffer size configurable". It adds
CONFIG_NETCONSOLE_BUFFER_SIZE and maintains the original 512 default value used
to define the length of input_buffer[]. nc_input_packet uses sizeof this to
read packet data into input_buffer[]. This appears fine.
The commit also adds to following in the output chain:
@@ -214,7 +218,7 @@ static void nc_puts(const char *s)
len = strlen(s);
while (len) {
- int send_len = min(len, 512);
+ int send_len = min(len, sizeof(input_buffer));
nc_send_packet(s, send_len);
len -= send_len;
s += send_len;
I can't see how this code relates to the sizeof input_buffer. The nc_puts data
is written directly into NetTxPacket (plus header offsets) which is set to 1536
+ alignment bytes long. If input_buffer is bigger than this, a buffer overflow
will occur. Obviously the default value of 512 will not trigger the problem.
The 512 magic number possibly ought to be derived from PKTSIZE_ALIGN (net.h),
but I don't think sizeof(input_buffer) is appropriate here.
Regards,
Nick.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 01/15] arm, davinci: Move pinmux functions from board to arch tree
Christian, On 25/11/11 12:37, Christian Riesch wrote: > Signed-off-by: Christian Riesch > Cc: Sandeep Paulraj > Cc: Heiko Schocher > Cc: Sudhakar Rajashekhara > Cc: Syed Mohammed Khasim > Cc: Sughosh Ganu > Cc: Nick Thompson > Cc: Stefano Babic > --- > arch/arm/cpu/arm926ejs/davinci/Makefile|2 +- > .../arm/cpu/arm926ejs/davinci/pinmux.c |0 > arch/arm/include/asm/arch-davinci/hardware.h |2 ++ > board/davinci/common/Makefile |2 +- > board/davinci/da8xxevm/da830evm.c |2 -- > board/davinci/da8xxevm/da850evm.c |2 -- > board/davinci/da8xxevm/hawkboard_nand_spl.c|2 -- > board/davinci/ea20/ea20.c |2 -- > nand_spl/board/davinci/da8xxevm/Makefile |6 +++--- > 9 files changed, 7 insertions(+), 13 deletions(-) > rename board/davinci/common/davinci_pinmux.c => > arch/arm/cpu/arm926ejs/davinci/pinmux.c (100%) The da830 parts of the complete patch set are pretty minor, but FWIW: Acked-by: Nick Thompson ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] da830: add support for NAND boot mode
On 30/09/11 13:29, nagabhushana.netagu...@ti.com wrote: > From: Nagabhushana Netagunte > > Add support for enabling NAND boot mode in configuration file and > add correspanding pinmux support, nand initialize function in board file. > Since the environment variable are stored in first block > CONFIG_ENV_OFFSET is set to offset 0 from (512 << 10) and also the > size required for environment variables not more than 10KB > the CONFIG_ENV_SIZE is set to 10KB from (512 << 10). > > Signed-off-by: Sudhakar Rajashekhara > Signed-off-by: Nagabhushana Netagunte > --- > board/davinci/da8xxevm/da830evm.c | 63 > + > include/configs/da830evm.h|4 ++- > 2 files changed, 66 insertions(+), 1 deletions(-) > No further comments from me: Acked-by: Nick Thompson ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] da830: add support to read mac addr from EEPROM
On 30/09/11 12:39, nagabhushana.netagu...@ti.com wrote:
> From: Nagabhushana Netagunte
>
> da830 boards have mac address stored in I2C EEPROM. This patch
> adds support to restore mac address from EEPROM if environment variable
> 'ethaddr' is not set.
>
> Signed-off-by: Sudhakar Rajashekhara
> Signed-off-by: Nagabhushana Netagunte
> ---
> board/davinci/da8xxevm/da830evm.c | 20
> include/configs/da830evm.h|1 +
> 2 files changed, 21 insertions(+), 0 deletions(-)
>
> diff --git a/board/davinci/da8xxevm/da830evm.c
> b/board/davinci/da8xxevm/da830evm.c
> index 0650653..69ed293 100644
> --- a/board/davinci/da8xxevm/da830evm.c
> +++ b/board/davinci/da8xxevm/da830evm.c
> @@ -188,6 +188,26 @@ int board_init(void)
>
> #define PHY_SW_I2C_ADDR 0x5f /* Address of PHY on i2c bus */
>
> +int misc_init_r(void)
> +{
> + uint8_t eeprom_enetaddr[6];
> + uint8_t val[2];
> +
> + if (!eth_getenv_enetaddr("ethaddr", eeprom_enetaddr)) {
> + /* Read Ethernet MAC address from EEPROM if available. */
> + if (dvevm_read_mac_address(eeprom_enetaddr))
> + /* Set Ethernet MAC address from EEPROM */
> + davinci_sync_env_enetaddr(eeprom_enetaddr);
> + }
> +
> + val[0] = 0x01;
> + val[1] = 0x23;
> +
> + if (i2c_write(PHY_SW_I2C_ADDR, 0, 0, val, 2))
> + printf("Ethernet switch start failed!\n");
> +
> +}
> +
There is already code to do this, in the same file, in board_eth_init(). Why
the new code?
Nick.
> /*
> * Initializes on-board ethernet controllers.
> */
> diff --git a/include/configs/da830evm.h b/include/configs/da830evm.h
> index 66fdea2..a451513 100644
> --- a/include/configs/da830evm.h
> +++ b/include/configs/da830evm.h
> @@ -160,6 +160,7 @@
> /*
> * U-Boot general configuration
> */
> +#define CONFIG_MISC_INIT_R
> #undef CONFIG_USE_IRQ/* No IRQ/FIQ in U-Boot */
> #undef CONFIG_MISC_INIT_R
> #undef CONFIG_BOOTDELAY
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: Convert {in, out}s[bwl] to inline functions
On 27/09/11 11:21, Marek Vasut wrote: > On Tuesday, September 27, 2011 11:31:15 AM Wolfgang Denk wrote: >> Dear Marek Vasut, >> >> In message <1317062895-3847-1-git-send-email-marek.va...@gmail.com> you >> wrote: >>> The size of uboot binary grows by a few bytes, but the gain (better type >>> checking) is worth it. >> And what _exactly_ are "a few bytes" ? > Nevermind, it must have been some kind of a fluctuation yesterday. Right now, > I > made a new measurement and the size didn't change with/without the patch > (this > is more what I'd expect to happen). > > Cheers Pure speculation on my part, but /could/ this be because ARM drivers don't tend to use these macros/functions. write[bwl] and the like are much more common. I don't know this to be a fact though. Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: Convert {in, out}s[bwl] to inline functions
On 26/09/11 19:48, Marek Vasut wrote:
> The size of uboot binary grows by a few bytes, but the gain (better type
> checking) is worth it.
>
> Signed-off-by: Marek Vasut
> Cc: Wolfgang Denk
> Cc: Nick Thompson
> Cc: Simon Glass
Do you want to cc: Albert ARIBAUD as well?
> ---
> arch/arm/include/asm/io.h | 34 --
> 1 files changed, 28 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
> index 61f4987..d22325d 100644
> --- a/arch/arm/include/asm/io.h
> +++ b/arch/arm/include/asm/io.h
> @@ -255,13 +255,35 @@ extern inline void __raw_readsl(unsigned int addr, void
> *data, int longlen)
> #define inw(p) ({ unsigned int __v =
> le16_to_cpu(__raw_readw(__io(p))); __v; })
> #define inl(p) ({ unsigned int __v =
> le32_to_cpu(__raw_readl(__io(p))); __v; })
>
> -#define outsb(p,d,l) __raw_writesb(__io(p),d,l)
> -#define outsw(p,d,l) __raw_writesw(__io(p),d,l)
> -#define outsl(p,d,l) __raw_writesl(__io(p),d,l)
These changes are clearly related, but we started out talking about
'__arch_putb',
which is in the same file of course. Did I miss something?
This specific patch looks reasonable to me though.
Reviewed-by: Nick Thompson
> +extern inline void outsb(unsigned int addr, const void *data, int bytelen)
> +{
> + __raw_writesb(addr, data, bytelen);
> +}
> +
> +extern inline void outsw(unsigned int addr, const void *data, int wordlen)
> +{
> + __raw_writesw(addr, data, wordlen);
> +}
> +
> +extern inline void outsl(unsigned int addr, const void *data, int longlen)
> +{
> + __raw_writesl(addr, data, longlen);
> +}
>
> -#define insb(p,d,l) __raw_readsb(__io(p),d,l)
> -#define insw(p,d,l) __raw_readsw(__io(p),d,l)
> -#define insl(p,d,l) __raw_readsl(__io(p),d,l)
> +extern inline void insb(unsigned int addr, void *data, int bytelen)
> +{
> + __raw_readsb(addr, data, bytelen);
> +}
> +
> +extern inline void insw(unsigned int addr, void *data, int wordlen)
> +{
> + __raw_readsw(addr, data, wordlen);
> +}
> +
> +extern inline void insl(unsigned int addr, void *data, int longlen)
> +{
> + __raw_readsl(addr, data, longlen);
> +}
> #endif
>
> #define outb_p(val,port) outb((val),(port))
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] GCC4.4: Squash multiple warnings due to strict aliasing
On 26/09/11 10:32, Marek Vasut wrote:
> On Monday, September 26, 2011 11:26:51 AM Nick Thompson wrote:
>> On 26/09/11 03:06, Marek Vasut wrote:
>>> Signed-off-by: Marek Vasut
>>> ---
>>>
>>> arch/arm/include/asm/io.h | 30 ++
>>> 1 files changed, 18 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
>>> index 1fbc531..61f4987 100644
>>> --- a/arch/arm/include/asm/io.h
>>> +++ b/arch/arm/include/asm/io.h
>>> @@ -78,43 +78,49 @@ static inline phys_addr_t virt_to_phys(void * vaddr)
>>>
>>> extern inline void __raw_writesb(unsigned int addr, const void *data,
>>> int bytelen) {
>>>
>>> uint8_t *buf = (uint8_t *)data;
>>>
>>> - while(bytelen--)
>>> - __arch_putb(*buf++, addr);
>>> + int i;
>>> + for (i = 0; i < bytelen; i++)
>>> + __arch_putb(buf[i], addr);
>>>
>>> }
>> This fixes the problem in these use cases, but leaves the door open.
>>
>> Would it be better to change the __arch_putb macro into an extern inline
>> function instead which would catch these and future cases?
> Yes, but you'll need to do that on a much larger scale. Is anyone up for
> doing
> it ?
>
I don't follow that. I found only three (identical) definitions in arm, sparc
and sh. In
those three cases __raw_writeb were also (identical) macro 'aliases' for
__arch_putb.
I guess you are referring to the testing required for all the boards in those
three
arches, or even just arm, with changes to all the (get|set)(b|w|l) cases? Maybe
I
see your point now...
Nick.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] GCC4.4: Squash multiple warnings due to strict aliasing
On 26/09/11 03:06, Marek Vasut wrote:
> Signed-off-by: Marek Vasut
> ---
> arch/arm/include/asm/io.h | 30 ++
> 1 files changed, 18 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
> index 1fbc531..61f4987 100644
> --- a/arch/arm/include/asm/io.h
> +++ b/arch/arm/include/asm/io.h
> @@ -78,43 +78,49 @@ static inline phys_addr_t virt_to_phys(void * vaddr)
> extern inline void __raw_writesb(unsigned int addr, const void *data, int
> bytelen)
> {
> uint8_t *buf = (uint8_t *)data;
> - while(bytelen--)
> - __arch_putb(*buf++, addr);
> + int i;
> + for (i = 0; i < bytelen; i++)
> + __arch_putb(buf[i], addr);
> }
>
This fixes the problem in these use cases, but leaves the door open.
Would it be better to change the __arch_putb macro into an extern inline
function
instead which would catch these and future cases?
Nick.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Instruction WFI gives error at build time.
On 22/09/11 10:17, Sandeep Kumar wrote: > Hi, > > > > I am adding support for a MPcore SoC in Uboot. For that secondary cores > need to execute WFI (wait for interrupt) instruction. > > But while building the source I am getting the following error: > > > > arm-none-eabi-gcc -D__ASSEMBLY__ -g -Os -fno-common -ffixed-r8 > -msoft-float -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x6080 > -I/media/disk/work/u-boot_ct11mpc_osi_evs/include -fno-builtin > -ffreestanding -nostdinc -isystem > /home/sandeepk/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-ea > bi/4.5.2/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mabi=aapcs-linux > -mno-thumb-interwork -march=armv5 -o lowlevel_init.o lowlevel_init.S > -c > > lowlevel_init.S: Assembler messages: > > lowlevel_init.S:92: Error: missing expression -- `swi' I'm not sure this is a u-boot question and you didn't show your code (I assume you changed the file). 'swi' is not a WFI. swi takes a expression - the software interrupt number you want to pass to the software interrupt exception routine. Your routine is free to ignore that number, but a 'swi' must have one to have the correct syntax. WFI on ARM SoC's is usually some kind of register write, specific to that SoC. Nick. > make[1]: *** [lowlevel_init.o] Error 1 > > make[1]: Leaving directory > `/media/disk/work/u-boot_ct11mpc_osi_evs/board/armltd/versatile_11mpc' > > make: *** [board/armltd/versatile_11mpc/libversatile_11mpc.o] Error 2 > > > > How can I implement this instruction or how can I directly insert the > hex code for this instruction. > > > > Regards, > > Sandeep > > > > > > > > > ___ > 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 1/5] da830: disable cache usage due to coherency issues
On 14/09/11 06:54, Netagunte, Nagabhushana wrote: > Nick, > > I am seeing this issue on da830/da850/dm36x/dm644x. Strange that I have seen no issue with da830 (OMAP-L137 v1.0 & v1.1 - don't have any v2.0 yet) when tftp'ing the kernel. I do get very occasional errors, but have put this down to network packet loss. The v1.0 and v1.1 parts do have a d-cache errata, so we only get to use the d-cache in write through mode. This would mean that TCP packet data writes by the processor would never have a coherency problem. Reads could still have an issue, but I think the explanation provided so far referred to TCP packet sending...? This vintage of da830 will always have to use write trough mode, so there should be no issue...? > I agree that u-boot will be faster with cache enabled. And also, TI wants it > to be enabled soon. Since so many patches are lined u, we don't up-streaming > them to get hampered because of this issue. So, we are trying to push this > Patch. We are committed come up with appropriate patch to fix the EMAC and > coherency issue. > > Meanwhile, we are trying to gather info about earlier patch/changes which > disabled cache so that community understands the known issue. Boot time is critical to us. I can't ship without cache enabled. I can use my own _config.h of course to work around it I think, but I don't understand why you think there is an issue to fix on da830 yet. With a working d-cache I can imagine such a problem though. > Also, one more engineer observed the issue with EMAC, I will send his mail to > you. > > Regards, > Nag > On Wed, Aug 31, 2011 at 15:09:35, Nick Thompson wrote: >> On 31/08/11 06:40, Netagunte, Nagabhushana wrote: >>> Mike, >>> >>> We will address cache coherency issues soon after these patches. >>> Earlier also, chache was disabled. Only due to new cache management >>> Framework which was added recently, it is explicitly needed to be indicated >>> to turn off cache. >>> >>> Since fixing the cache coherency issues with EMAC will take some time, I >>> want this patch to go in mainline so that issue doesn't crop up for People >>> who use u-boot. >>> >>> Regards, >>> Nag >>> >> Which device(s) does this occur on? I have a lot of OMAP-L137 (EVM and >> custom) boards with cache enabled and no problems tftp'ing the kernel. >> >> On the other hand tftp and kernel CRC checking are much faster with cache >> enabled. >> >> Nick. >> ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] ARM: Update mach-types
On 12/09/11 15:53, Stefano Babic wrote: > On 09/12/2011 04:48 PM, Nick Thompson wrote: >>> Maybe the best way, if you want to have your board maintained in u-boot >>> but not in kernel (however, why ?) >> Maybe a board that uses some other OS? > Well, but then why is it required a MACH-ID ? Or are there other OSes > stealing the same mechanism from the Linux kernel (I am not aware of it, > I am curious...) ? > > Best regards, > Stefano Babic > Good point. I believe all U-Boot internal uses of machine id are now removed. Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] ARM: Update mach-types
On 12/09/11 15:14, Stefano Babic wrote: > On 09/12/2011 04:04 PM, Holger Brunck wrote: >> Hi, >> >> On 09/12/2011 03:54 PM, Stefano Babic wrote: >>> On 09/12/2011 03:36 PM, Marek Vasut wrote: > Have you checked that the removed boards are not supported in U-Boot? No, but then the respective maintainers will get a warning and will be forced to fix their boards in both linux and uboot. >>> Maybe the simplest way to catch these boards (if any) is to run MAKEALL >>> on arm targets with your mach-types file. If no board is broken, we have >>> not to worry about. >>> >> sorry, I didn't follow the whole discussion, but this patch will remove the >> mach type for our km_kirkwood board. >> >> -#define MACH_TYPE_KM_KIRKWOOD 2255 >> >> This board is supported in u-boot but not mainlined in linux. So how should >> we >> handle this? > Well, I think we cannot check for each update of this file which board > are dropped - this requires too much effort. The way we currently use > (Linux is the master of this file, and we update it directly from the > kernel) is IMHO the right way to get it in sync. > > Maybe the best way, if you want to have your board maintained in u-boot > but not in kernel (however, why ?) Maybe a board that uses some other OS? > is to define your MACH in the board > configuration file. > > Best regards, > Stefano Babic > Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Bottleneck of NAND copy speed
On 12/09/11 12:21, Simon Schwarz wrote: > Hi List, > > ATM I'm working on a DMA transfer from NAND to RAM of the Linux-image in > my SPL. > > I’m searching for the speed bottleneck of the MT29F1G16ABBHC-ET > NAND-Flash on the devkit8000 (OMAP3). > > From the timings I set on the GPMC I calced a max. speed of around 26 > MiB/s. In my measurements I have a speed of around 10 MiB/s. > > Here is the image of my the calculation: > https://docs.google.com/leaf?id=0B_wpO5K0MQSlYTcxMWVlOGEtY2FmYy00ODMyLWE1MTUtN2ZiZGViOWVhMzYw&hl=en_US > > tcmd: The time for the initial read command > twr: time to write the address > tDn: Time for a 16bit read of Data > > Does anyone has an idea where the bottleneck could be? Is my calculation > wrong? > (ecc is done parallel to the DMA transfer). I only had a quick look at your calculation, but didn't notice anything to account for the NAND copy to read cache (data ready) time of the NAND device. Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] da830: add support for NAND boot mode
On 05/09/11 09:26, Netagunte, Nagabhushana wrote: > I am just curious, since this patch adds NAND boot mode for the > First time in denx git, how this affects you? Are you storing > ENV variables in NAND during some other boot mode? In fact we are > Adding other boot mode in this patch set. How come you are using > Denx tree to flash bios on your da830 board? > > Regards, > Nag We use SPI boot to load dspais and then a modified UBL from FLASH. Our UBL is then capable of loading u-boot from either SPI or NAND depending on a switch setting. Both U-Boot images can be different or the same. Either way the env settings are in nand. U-boot can already handle NAND env if configured correctly. U-Boot already has NAND support too of course and can load the kernel from a variety of sources, including NAND. 'nboot' and 'nand read' can both be used for that. All the above can work on da830evm with a NAND board connected to the expansion bus connectors. Nothing has changed in U-Boot other than in our (not yet published) _config file. Defining CONFIG_USE_NAND in there is enough to turn NAND support on and our UBL configures *all* the pinmuxes fof the board. Using the UBL always used to be the TI recommended way to configure pinmuxes AFAIK. Of course pinmux set up can also be added in the board file, though we have not bothered, since UBL *must* have already done it if it loads U-Boot from NAND. Note that the end of the config file also has: #ifdef CONFIG_MTD_PARTITIONS #define MTDIDS_DEFAULT"nand0=davinci_nand.1" #define PART_BOOT"512k(bootloader)ro," #define PART_PARAMS"512k(params)ro," #define PART_KERNEL"4m(kernel)," #define PART_REST"-(filesystem)" #define MTDPARTS_DEFAULT\ "mtdparts=davinci_nand.1:" PART_BOOT PART_PARAMS PART_KERNEL PART_REST #endif ...where params is (for U-Boot) used for env and bootloader typically relates to U-Boot. I don't know what 'bios' refers to in your question. I'm also a bit unsure what you mean by 'adds NAND boot mode for the first time', given that the processor boot mode has little say on where U-Boot or Linux are loaded from and we've been using standard U-Boot features to load data from NAND for nearly two years now. Nick. > On Wed, Aug 31, 2011 at 14:26:42, Nick Thompson wrote: >> On 30/08/11 13:15, nagabhushana.netagu...@ti.com wrote: >>> From: Nagabhushana Netagunte >>> >>> Add support for enabling NAND boot mode in configuration file and add >>> correspanding pinmux support, nand initialize function in board file. >>> Since the environment variable are stored in first block >> My environment variables are not stored in the first block. Where does your >> assumption stem from? >> >> If I use this patch on my boards here, they will all "loose" their >> environment. >> >> By moving env you are creating a compatibility issue for boards that already >> use NAND. >> >>> CONFIG_ENV_OFFSET is set to offset 0 from (512 << 10) and also the >>> size required for environment variables not more than 10KB the >>> CONFIG_ENV_SIZE is set to 10KB from (512 << 10). >>> >> ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] da830: disable cache usage due to coherency issues
On 31/08/11 06:40, Netagunte, Nagabhushana wrote: > Mike, > > We will address cache coherency issues soon after these patches. > Earlier also, chache was disabled. Only due to new cache management Framework > which was added recently, it is explicitly needed to be indicated to turn off > cache. > > Since fixing the cache coherency issues with EMAC will take some time, I want > this patch to go in mainline so that issue doesn't crop up for People who use > u-boot. > > Regards, > Nag > Which device(s) does this occur on? I have a lot of OMAP-L137 (EVM and custom) boards with cache enabled and no problems tftp'ing the kernel. On the other hand tftp and kernel CRC checking are much faster with cache enabled. Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] da830: add support for NAND boot mode
On 30/08/11 13:15, nagabhushana.netagu...@ti.com wrote: > From: Nagabhushana Netagunte > > Add support for enabling NAND boot mode in configuration file and > add correspanding pinmux support, nand initialize function in board file. > Since the environment variable are stored in first block My environment variables are not stored in the first block. Where does your assumption stem from? If I use this patch on my boards here, they will all "loose" their environment. By moving env you are creating a compatibility issue for boards that already use NAND. > CONFIG_ENV_OFFSET is set to offset 0 from (512 << 10) and also the > size required for environment variables not more than 10KB > the CONFIG_ENV_SIZE is set to 10KB from (512 << 10). > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot using UART1
Don, Please ask u-boot questions on the u-boot mailing list. On 22/07/11 01:03, Don McCune wrote: > > We are bringing up a board based on the OMAPL137 processor. The board is > similar to the Spectrum Digital Evm board; however it has used UART2 for > something else, so we need to make UAR1 the console line for u-boot. Could > you tell us how to modify u-boot to use UART1 for its console? > $ grep UART include/configs/da830evm.h #define CONFIG_SYS_NS16550_COM1 DAVINCI_UART2_BASE /* Base address of UART2 */ #define CONFIG_SYS_NS16550_CLK clk_get(DAVINCI_UART2_CLKID) #define CONFIG_CONS_INDEX 1 /* use UART0 for console */ Just change DAVINCI_UART2_BASE to DAVINCI_UART1_BASE. (and make sure your boot loader enables the pinmux for UART1) > > > Please reply-to-all with any questions or answers. If you wish to contact us > directly, please call Tim Orling at 805 269 0767. > > > > Thank you. > > > > Regards, > > Don McCune > > Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] debugging with XDS100v2 Omap 3530
On 02/07/11 14:47, Amit kumar wrote: > Hi, > I am new to U-Boot and my task involves porting U-Boot to Omap3530. I have > XDS100v2 but I don't have a JTAG Software to support this on Ubuntu host PC. > > Please, suggest an open source Jtag Software for this. TI's debugger CCSv5.1.x (not open source) plugs into Eclipse (which is) and, I understand, comes with a license to use XDS100. So it is free to use, but not 100% open source. I've only used it on OMAP-L137. And I have and XDS510 not XDS100 because the 100 is very slow. We have 3530s also but most people are still using CCSv4 here. Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] I2C: OMAP: spurious i2c probe addresses
On 26/05/11 12:38, Michael Jones wrote: > On 05/26/2011 11:23 AM, Nick Thompson wrote: >> On 26/05/11 08:03, Michael Jones wrote: >>> On 05/25/2011 05:38 PM, Michael Jones wrote: >>>> While running v2011.06-rc1, I noticed some new behavior on my OMAP3 i2c >>>> bus. I tracked it to commit 0e57968a215d1b, "I2C: OMAP: detect more >>>> devices when probing an i2c bus". It detects more devices indeed, such >>>> as some that don't even exist. Even better than that, it detects >>>> different devices every time. It looks like just false positives, the >>>> existent devices seem to always be found among the ghost devices. >>>> >>>> Here's the behavior I see: >>>> -- >>>> # i2c probe >>>> Valid chip addresses: 05 18 30 49 50 51 5E 7A >>>> # i2c probe >>>> Valid chip addresses: 02 06 0B 18 1D 24 25 30 35 50 51 57 5D 6F 7C >>>> # i2c probe >>>> Valid chip addresses: 18 2E 30 33 35 50 51 62 6F >>>> # i2c probe >>>> Valid chip addresses: 18 1B 1F 2D 30 46 50 51 5C 5D >>>> # i2c probe >>>> Valid chip addresses: 0A 18 21 26 2B 30 32 50 51 60 66 69 6D 79 >>>> # i2c probe >>>> Valid chip addresses: 08 09 18 1B 30 50 51 5E 6C >>>> >>>> >>>> Here's what it looks like after reverting the commit: >>>> -- >>>> # i2c probe >>>> Valid chip addresses: 18 30 50 51 >>>> # i2c probe >>>> Valid chip addresses: 18 30 50 51 >>>> # i2c probe >>>> Valid chip addresses: 18 30 50 51 >>>> # i2c probe >>>> Valid chip addresses: 18 30 50 51 >>>> >>>> >>>> -Michael >>> >>> Sorry- relevant point here: I have a device with a 2-byte subaddress, >>> which I suspect is the culprit here. As Nick mentioned in his commit >>> message, such devices are unsupported by the current OMAP i2c driver. >>> I'm in the process of adding support for 2-byte subaddresses to the >>> driver. In light of the above, I now realize that such changes will >>> probably have to involve i2c_probe() as well. >>> >>> -Michael >> > > Hi Nick, > >> Hi Michael, >> >> What do you mean by sub-address? The address within the device or an >> extended chip address? > > I mean the address within the device. > >> >> The change I made aborts the write after sending the 7 bit chip >> address and 1 write bit, so a device's internal address shouldn't be >> relevant. > > Mmm, OK. I only jumped to that conclusion because your comment in the > commit message mentions that the driver only supports devices with > single-byte subaddresses. That appears to true. The Davinci driver supports two byte addresses. You might be able to use that as a template for your changes. > >> >> Extended chip addressing devices would not be supported as it stands. >> I can imagine NACK may not be occur for a device waiting for more >> chip address bits, though I would have thought it wouldn't drive the bus >> low until the full address is received. > > Curious. It sounds like you would've expected it to work with my device. Yes. I've made a similar change to Davinci's probe and it works with a 25x256 (Spansion) device (and more stubborn Analog Devices DACs and ADCs, as well as temperature and current sensors). The probe always returns the same results, much like our OMAP boards. > >> >> Can you tell us what device this is? Even better a link to the data >> sheet. > > It's a 128 Kbit EEPROM. > http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00259167.pdf > > >> >> Does your bus have only one master (the OMAP)? There could be an issue >> if bus arbitration failures occur. > > OMAP is the only master. Okay. > >> >> I guess your bus pull-ups are strong enough to assert the NAK...? >> If not, you probably you would have seen other issues before now. > > Right- I assume this is not the problem because I haven't had other > issues before now. Hmm, I'm a bit stumped then. I'm still playing with I2C on Davinci, so more ideas may come out of that. The bus pull-ups on our boards are 2k-ohm to 3v3 rail, if it helps. > >> >> Nick. > > I am going to focus on getting proper reads and writes working > with my device before looking into this myself. If you have > suggestions in the meantime, I'm all ears. Otherwise I'll be > in touch when I get around to looking at probe again. Okay, let me know how you get on. > > -Michael Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] I2C: OMAP: spurious i2c probe addresses
On 26/05/11 08:03, Michael Jones wrote: > On 05/25/2011 05:38 PM, Michael Jones wrote: >> While running v2011.06-rc1, I noticed some new behavior on my OMAP3 i2c >> bus. I tracked it to commit 0e57968a215d1b, "I2C: OMAP: detect more >> devices when probing an i2c bus". It detects more devices indeed, such >> as some that don't even exist. Even better than that, it detects >> different devices every time. It looks like just false positives, the >> existent devices seem to always be found among the ghost devices. >> >> Here's the behavior I see: >> -- >> # i2c probe >> Valid chip addresses: 05 18 30 49 50 51 5E 7A >> # i2c probe >> Valid chip addresses: 02 06 0B 18 1D 24 25 30 35 50 51 57 5D 6F 7C >> # i2c probe >> Valid chip addresses: 18 2E 30 33 35 50 51 62 6F >> # i2c probe >> Valid chip addresses: 18 1B 1F 2D 30 46 50 51 5C 5D >> # i2c probe >> Valid chip addresses: 0A 18 21 26 2B 30 32 50 51 60 66 69 6D 79 >> # i2c probe >> Valid chip addresses: 08 09 18 1B 30 50 51 5E 6C >> >> >> Here's what it looks like after reverting the commit: >> -- >> # i2c probe >> Valid chip addresses: 18 30 50 51 >> # i2c probe >> Valid chip addresses: 18 30 50 51 >> # i2c probe >> Valid chip addresses: 18 30 50 51 >> # i2c probe >> Valid chip addresses: 18 30 50 51 >> >> >> -Michael > > Sorry- relevant point here: I have a device with a 2-byte subaddress, > which I suspect is the culprit here. As Nick mentioned in his commit > message, such devices are unsupported by the current OMAP i2c driver. > I'm in the process of adding support for 2-byte subaddresses to the > driver. In light of the above, I now realize that such changes will > probably have to involve i2c_probe() as well. > > -Michael Hi Michael, What do you mean by sub-address? The address within the device or an extended chip address? The change I made aborts the write after sending the 7 bit chip address and 1 write bit, so a device's internal address shouldn't be relevant. Extended chip addressing devices would not be supported as it stands. I can imagine NACK may not be occur for a device waiting for more chip address bits, though I would have thought it wouldn't drive the bus low until the full address is received. Can you tell us what device this is? Even better a link to the data sheet. Does your bus have only one master (the OMAP)? There could be an issue if bus arbitration failures occur. I guess your bus pull-ups are strong enough to assert the NAK...? If not, you probably you would have seen other issues before now. Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Issues in U-BOOT for OMAPL137
Please don't top post, it really breaks up the flow of the conversation
when people look at it later on. And please keep the list on CC.
On 13/05/11 06:31, shilpa jadav wrote:
> Hi,
>
>I tried latest U-BOOT release from
> git://git.denx.de/u-boot.git or http://git.denx.de/u-boot.git
>
> I am unable to compile it, i think da830/omapl137 support is not their in
> u-boot. I got the error as mentioned below when i give the command
>
> u-boot# make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-
> da830_omapl137_config
The target you are after is da830evm_config. I know its there because
I'm the board maintainer ;-)
$ grep da830evm boards.cfg
da830evm arm arm926ejs da8xxevm
davincidavinci
da830 is the name fo the omap-l137 which is not an OMAP but a Davinci
device. omap-l137 is its TI marketing name.
Nick.
>
> I get the error as:---
>
> awk '(NF && $1 !~ /^#/) { print $1 ": " $1 "_config; $(MAKE)" }' boards.cfg
>> .boards.depend
> make: *** No rule to make target `da830_omapl137_config'. Stop.
> make: *** [da830_omapl137_config] Error 1
>
> Can you tell the release which is supporting da830/omapl137 with USB
> support.
>
> Thanks,
> Shilpa
>
>
> On Thu, May 12, 2011 at 2:30 PM, Nick Thompson wrote:
>
>> On 11/05/11 10:15, shilpa jadav wrote:
>>> Hi ,
>>> When i am trying to compile u-boot for omapL137 by issuing the following
>>> command
>>> make da830_omapl137_evm_config CROSS_COMPILE=arm-none-linux-gnueabi-
>>>
>>> Our goal is to get USB up on the uboot . We are trying to boot OMAPL137
>> Evm
>>> using USB mass storage device(Pen drive)
>>> I have added the following macros in the /include/configs/da830_evm.h
>>> (followed the instructions from CHANGELOG file)
>>> #define CONFIG_CMD_USB 1
>>> #define CONFIG_USB_STORAGE 1
>>> #define CONFIG_USB_EHCI
>>> #define CONFIG_USB_EHCI_IXP4XX 1
>>> #define CONFIG_EHCI_IS_TDI 1
>>> #define CONFIG_EHCI_DESC_BIG_ENDIAN 1
>>> #define CONFIG_EHCI_MMIO_BIG_ENDIAN 1
>>> #define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 1
>>> #define CONFIG_LEGACY_USB_INIT_SEQ 1
>>>
>>> This is the error i am seeing consistently.
>>>
>>> make[1]: Leaving directory
>>>
>> `/home/dataway/linux_bkup/kalyan/omapl137/DaVinci-PSP-SDK-03.20.00.08/src/u-boot/uboot-03.20.00.08/drivers/usb/musb'
>>> make -C drivers/usb/host/
>>> make[1]: Entering directory
>>>
>> `/home/dataway/linux_bkup/kalyan/omapl137/DaVinci-PSP-SDK-03.20.00.08/src/u-boot/uboot-03.20.00.08/drivers/usb/host'
>>> make[1]: *** No rule to make target `.depend', needed by `libusb_host.a'.
>>> Stop.
>>> make[1]: Leaving directory
>>>
>> `/home/dataway/linux_bkup/kalyan/omapl137/DaVinci-PSP-SDK-03.20.00.08/src/u-boot/uboot-03.20.00.08/drivers/usb/host'
>>> make: *** [drivers/usb/host/libusb_host.a] Error 2
>>>
>>> Please help us solving this issue as this is very critical for our
>>> development
>>
>> This u-boot version (from the DaVinci-PSP) is quite old now (2009.08)
>> and, I believe, its da830/l137 code was never added to the community
>> tree: community support started in Nov 2009 and USB support was added
>> in Dec 2009. As such it can't be supported here.
>>
>> As mentioned da830 EVM is supported by the community tree and I would
>> encourage you to used the latest release from
>> git://git.denx.de/u-boot.git or http://git.denx.de/u-boot.git
>>
>> You can download snapshots, with a browser, from:
>> http://git.denx.de/?p=u-boot.git;a=summary
>>
>> Nick.
>>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Issues in U-BOOT for OMAPL137
On 11/05/11 10:15, shilpa jadav wrote: > Hi , > When i am trying to compile u-boot for omapL137 by issuing the following > command > make da830_omapl137_evm_config CROSS_COMPILE=arm-none-linux-gnueabi- > > Our goal is to get USB up on the uboot . We are trying to boot OMAPL137 Evm > using USB mass storage device(Pen drive) > I have added the following macros in the /include/configs/da830_evm.h > (followed the instructions from CHANGELOG file) > #define CONFIG_CMD_USB 1 > #define CONFIG_USB_STORAGE 1 > #define CONFIG_USB_EHCI > #define CONFIG_USB_EHCI_IXP4XX 1 > #define CONFIG_EHCI_IS_TDI 1 > #define CONFIG_EHCI_DESC_BIG_ENDIAN 1 > #define CONFIG_EHCI_MMIO_BIG_ENDIAN 1 > #define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 1 > #define CONFIG_LEGACY_USB_INIT_SEQ 1 > > This is the error i am seeing consistently. > > make[1]: Leaving directory > `/home/dataway/linux_bkup/kalyan/omapl137/DaVinci-PSP-SDK-03.20.00.08/src/u-boot/uboot-03.20.00.08/drivers/usb/musb' > make -C drivers/usb/host/ > make[1]: Entering directory > `/home/dataway/linux_bkup/kalyan/omapl137/DaVinci-PSP-SDK-03.20.00.08/src/u-boot/uboot-03.20.00.08/drivers/usb/host' > make[1]: *** No rule to make target `.depend', needed by `libusb_host.a'. > Stop. > make[1]: Leaving directory > `/home/dataway/linux_bkup/kalyan/omapl137/DaVinci-PSP-SDK-03.20.00.08/src/u-boot/uboot-03.20.00.08/drivers/usb/host' > make: *** [drivers/usb/host/libusb_host.a] Error 2 > > Please help us solving this issue as this is very critical for our > development This u-boot version (from the DaVinci-PSP) is quite old now (2009.08) and, I believe, its da830/l137 code was never added to the community tree: community support started in Nov 2009 and USB support was added in Dec 2009. As such it can't be supported here. As mentioned da830 EVM is supported by the community tree and I would encourage you to used the latest release from git://git.denx.de/u-boot.git or http://git.denx.de/u-boot.git You can download snapshots, with a browser, from: http://git.denx.de/?p=u-boot.git;a=summary Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] I2C: OMAP: detect more devices when probing an i2c bus
The omap24xx driver only seems to support devices that have a single subaddress
byte. With these types of devices, the first access in a bus transaction is
usually a write (writes the subaddress) followed by either a read or write to
access the devices registers.
Many such devices will respond to a read as the first access, but there are at
least some that will NACK such a read. (e.g. ADV7180.)
The probe function attempts to detect a devices ACK to a read access only and
fails to find devices that NACK a read.
This commit modifies the probe function to start a write instead. This detects
devices that respond to reads (since they must also respond to writes) as well
as those that only respond to writes. The bus is immediately set to idle after a
(N)ACK avoiding actually writing anything to the device.
Signed-off-by: Nick Thompson
---
Tested on OMAP3530 with an ADV7180 video ADC.
Detection of a device takes the same time as failing to find a device, so the
probe is slightly faster.
V2 Changes:
Removed two checkpatch errors (space prohibited between function name and open
parenthesis)
drivers/i2c/omap24xx_i2c.c | 42 +++---
1 files changed, 11 insertions(+), 31 deletions(-)
diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c
index 215be34..71251d8 100644
--- a/drivers/i2c/omap24xx_i2c.c
+++ b/drivers/i2c/omap24xx_i2c.c
@@ -321,43 +321,23 @@ int i2c_probe (uchar chip)
/* wait until bus not busy */
wait_for_bb ();
- /* try to read one byte */
+ /* try to write one byte */
writew (1, &i2c_base->cnt);
/* set slave address */
writew (chip, &i2c_base->sa);
/* stop bit needed here */
- writew (I2C_CON_EN | I2C_CON_MST | I2C_CON_STT | I2C_CON_STP,
&i2c_base->con);
+ writew(I2C_CON_EN | I2C_CON_MST | I2C_CON_STT | I2C_CON_TRX |
+ I2C_CON_STP, &i2c_base->con);
- while (1) {
- status = wait_for_pin();
- if (status == 0 || status & I2C_STAT_AL) {
- res = 1;
- goto probe_exit;
- }
- if (status & I2C_STAT_NACK) {
- res = 1;
- writew(0xff, &i2c_base->stat);
- writew (readw (&i2c_base->con) | I2C_CON_STP,
&i2c_base->con);
- wait_for_bb ();
- break;
- }
- if (status & I2C_STAT_ARDY) {
- writew(I2C_STAT_ARDY, &i2c_base->stat);
- break;
- }
- if (status & I2C_STAT_RRDY) {
- res = 0;
-#if defined(CONFIG_OMAP243X) || defined(CONFIG_OMAP34XX) || \
-defined(CONFIG_OMAP44XX)
- readb(&i2c_base->data);
-#else
- readw(&i2c_base->data);
-#endif
- writew(I2C_STAT_RRDY, &i2c_base->stat);
- }
- }
+ status = wait_for_pin();
+
+ /* check for ACK (!NAK) */
+ if (!(status & I2C_STAT_NACK))
+ res = 0;
+
+ /* abort transfer (force idle state) */
+ writew(0, &i2c_base->con);
-probe_exit:
flush_fifo();
writew (0, &i2c_base->cnt); /* don't allow any more data in...we don't
want it.*/
writew(0x, &i2c_base->stat);
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] I2C: OMAP: detect more devices when probing an i2c bus
The omap24xx driver only seems to support devices that have a single subaddress
byte. With these types of devices, the first access in a bus transaction is
usually a write (writes the subaddress) followed by either a read or write to
access the devices registers.
Many such devices will respond to a read as the first access, but there are at
least some that will NACK such a read. (e.g. ADV7180.)
The probe function attempts to detect a devices ACK to a read access only and
fails to find devices that NACK a read.
This commit modifies the probe function to start a write instead. This detects
devices that respond to reads (since they must also respond to writes) as well
as those that only respond to writes. The bus is immediately set to idle after a
(N)ACK avoiding actually writing anything to the device.
Signed-off-by: Nick Thompson
---
Tested on OMAP3530 with an ADV7180 video ADC.
Detection of a device takes the same time as failing to find a device, so the
probe is slightly faster.
drivers/i2c/omap24xx_i2c.c | 42 +++---
1 files changed, 11 insertions(+), 31 deletions(-)
diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c
index 215be34..bc637bc 100644
--- a/drivers/i2c/omap24xx_i2c.c
+++ b/drivers/i2c/omap24xx_i2c.c
@@ -321,43 +321,23 @@ int i2c_probe (uchar chip)
/* wait until bus not busy */
wait_for_bb ();
-/* try to read one byte */
+/* try to write one byte */
writew (1, &i2c_base->cnt);
/* set slave address */
writew (chip, &i2c_base->sa);
/* stop bit needed here */
-writew (I2C_CON_EN | I2C_CON_MST | I2C_CON_STT | I2C_CON_STP,
&i2c_base->con);
+writew (I2C_CON_EN | I2C_CON_MST | I2C_CON_STT | I2C_CON_TRX |
+I2C_CON_STP, &i2c_base->con);
-while (1) {
-status = wait_for_pin();
-if (status == 0 || status & I2C_STAT_AL) {
-res = 1;
-goto probe_exit;
-}
-if (status & I2C_STAT_NACK) {
-res = 1;
-writew(0xff, &i2c_base->stat);
-writew (readw (&i2c_base->con) | I2C_CON_STP, &i2c_base->con);
-wait_for_bb ();
-break;
-}
-if (status & I2C_STAT_ARDY) {
-writew(I2C_STAT_ARDY, &i2c_base->stat);
-break;
-}
-if (status & I2C_STAT_RRDY) {
-res = 0;
-#if defined(CONFIG_OMAP243X) || defined(CONFIG_OMAP34XX) || \
-defined(CONFIG_OMAP44XX)
-readb(&i2c_base->data);
-#else
-readw(&i2c_base->data);
-#endif
-writew(I2C_STAT_RRDY, &i2c_base->stat);
-}
-}
+status = wait_for_pin();
+
+/* check for ACK (!NAK) */
+if (!(status & I2C_STAT_NACK))
+res = 0;
+
+/* abort transfer (force idle state) */
+writew (0, &i2c_base->con);
-probe_exit:
flush_fifo();
writew (0, &i2c_base->cnt); /* don't allow any more data in...we don't
want it.*/
writew(0x, &i2c_base->stat);
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] CONFIG_SILENT_CONSOLE not working with NAND env
On 06/04/11 10:22, Wolfgang Denk wrote: > Dear Nick Thompson, > > In message <4d9c2274.3080...@ge.com> you wrote: >> That might be a good reason to consider dropping the UBL though. I believe >> TI are moving to U-Boot SPL themselves. > Are they? Do you have any pointers? There have been some SPL submissions from TI people, for example: http://www.mail-archive.com/u-boot@lists.denx.de/msg48557.html I believe the work is focused on OMAP4, with OMAP3 as a later addition. I notice there is already something in repo for da8xx, though not from TI. I think I need to take a look at that. Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] CONFIG_SILENT_CONSOLE not working with NAND env
On 05/04/11 18:46, Scott Wood wrote:
> On Tue, 5 Apr 2011 17:07:13 +0100
> Nick Thompson wrote:
>
>> On 05/04/11 16:52, Mike Frysinger wrote:
>>> On Tue, Apr 5, 2011 at 10:07 AM, Nick Thompson wrote:
>>>> common/console.c has this function:
>>>>
>>>> /* Called before relocation - use serial functions */
>>>> int console_init_f(void)
>>>> {
>>>>gd->have_console = 1;
>>>>
>>>> #ifdef CONFIG_SILENT_CONSOLE
>>>>if (getenv("silent") != NULL)
>>>>gd->flags |= GD_FLG_SILENT;
>>>> #endif
>>>>
>>>>return 0;
>>>> }
>>>>
>>>> I have defined CONFIG_SILENT_CONSOLE and set "silent" in my NAND env,
>>>> but the SILENT flag doesn't get set.
>>>>
>>>> I suspect this function is called way too early for NAND env to be
>>>> available.
>>> NAND isnt the only one with this problem (SPI does too last i looked).
>>> during early boot, you only have the default env available. so if
>>> you want silent console, i'd suggest you enable that in your default
>>> env.
>>> -mike
>> Yes, that's what I intend to do, I think, though I'd have liked it to be
>> configurable at run time.
> Try enabling CONFIG_NAND_ENV_DST to have the environment be loaded by the
> SPL along with the main U-Boot image. You didn't say what board/chip
> you're using, so if you're using something other than the common
> nand_boot.c you may need to add support for this (it's just a couple
> lines), and silence any output from the SPL itself.
>
> -Scott
>
Thanks Scott,
That's interesting. I'm using a TI board (da830evm). Unfortunately it has its
own UBL, so I don't have the SPL to configure that way.
That might be a good reason to consider dropping the UBL though. I believe
TI are moving to U-Boot SPL themselves.
I'll add it to my TODO list.
Thanks,
Nick.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] CONFIG_SILENT_CONSOLE not working with NAND env
On 05/04/11 16:52, Mike Frysinger wrote:
> On Tue, Apr 5, 2011 at 10:07 AM, Nick Thompson wrote:
>> common/console.c has this function:
>>
>> /* Called before relocation - use serial functions */
>> int console_init_f(void)
>> {
>>gd->have_console = 1;
>>
>> #ifdef CONFIG_SILENT_CONSOLE
>>if (getenv("silent") != NULL)
>>gd->flags |= GD_FLG_SILENT;
>> #endif
>>
>>return 0;
>> }
>>
>> I have defined CONFIG_SILENT_CONSOLE and set "silent" in my NAND env,
>> but the SILENT flag doesn't get set.
>>
>> I suspect this function is called way too early for NAND env to be available.
> NAND isnt the only one with this problem (SPI does too last i looked).
> during early boot, you only have the default env available. so if
> you want silent console, i'd suggest you enable that in your default
> env.
> -mike
Yes, that's what I intend to do, I think, though I'd have liked it to be
configurable at run time.
Thanks for the info,
Nick.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] CONFIG_SILENT_CONSOLE not working with NAND env
common/console.c has this function:
/* Called before relocation - use serial functions */
int console_init_f(void)
{
gd->have_console = 1;
#ifdef CONFIG_SILENT_CONSOLE
if (getenv("silent") != NULL)
gd->flags |= GD_FLG_SILENT;
#endif
return 0;
}
I have defined CONFIG_SILENT_CONSOLE and set "silent" in my NAND env,
but the SILENT flag doesn't get set.
I suspect this function is called way too early for NAND env to be available.
I can set the flag unconditionally and that works fine, but I don't think that
that will make a patch worthy of submission...?
Any thoughts?
Thanks,
Nick.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND on Davinci boards
Stefano, On 16/03/11 12:36, Stefano Babic wrote: > It looks like Linux has not written the ECCs at all > So I'll leave you to look into that problem. You could still be correct about Kernel compatibilities, though I hope not. I'm encouraged that the zeros where in the "correct" place, but the ECC nibbles could be still be packed differently. Good luck, Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND on Davinci boards
On 16/03/11 12:01, Stefano Babic wrote: > On 03/16/2011 11:01 AM, Nick Thompson wrote: > > Hi Nick, > >> I'm using da830evm (OMAP-L137) with more or less up-to-date U-Boot, but >> quite old 2.6.18+ kernel from Montavista. >> >>> >>> #define CONFIG_SYS_NAND_4BIT_HW_ECC_OOBFIRST >>> #define CONFIG_SYS_NAND_USE_FLASH_BBT >> >> I don't have BBT enabled. > > Thanks, I have tried to disable it. No improvement, I got always ECC errors. > >> >> Neither ;) >> >> I think the U-Boot NAND driver for davinci has always been setup to be >> compatible with the TI & Montavista Kernels. > > This is probably the problem. I cannot check the montavista sources (I > do not use them, but it seems that the old source.mvista.com went > offline), but if u-boot sticks to mvista kernel is surely not aligned to > the kernel mainline. > >> What I'm not sure about is if >> those Kernels are compatible with mainline Linux and in particular the >> very latest mainline kernels. In fact I'm not sure if it is compatible with >> the very latest TI Kernels. > > I think I can answer: no. I checked PSP_3.20 from Texas, and even on the > arago project. TI went from their 2.x version of PSP tools to 3.x from > mvista kernel to mainline kernel, and probably at that point u-boot and > kernel were not anymore compatible. I have not seen patches in > drivers/mtd/davinci_nand.c related to make it suitable for newer kernels. You may be correct, but maybe you have another problem first... > >> >> Have you tried "nand dump" of a Linux programmed Kernel and compared it with >> "nand dump" of a U-Boot programmed Kernel? > > I have tried now to get the first page (=2048 bytes) from both and I > have compared byte-per-byte. They are identical, inclusive the oob part. > >> You would be able to see >> identical data in each case, but you will be able to compare the differences >> in the OOB. You only need to look at the first page to see if the OOB data >> or position of the OOB data differs. > > No differences at all. For both, I get in the oob: > > OOB: > ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff > 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 Is this really from the OOB for the first _kernel_ page. It looks wrong. I see: > nand dump 0x10 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 9a ea 40 97 85 bc 5f f5 2e 15 91 c2 c6 93 14 c0 03 e3 b6 4c 35 40 2d 8f 7e 74 10 13 59 47 cf 09 24 10 6a 0a 8b e2 f1 b0 The part after all the ff's is the ECC. IIRC a zero ECC implies all the data in the page is zero also. That would be an odd start to a Kernel image. Can you confirm what it is you dumped? > > However, u-boot complain about it: > > nand read kernel_addr_r 0 800 > > NAND read: device 0 offset 0x0, size 0x800 > Getting too many errors > Getting too many errors > Getting too many errors > Getting too many errors > 2048 bytes read: OK > > >> >> You errors all seem to be in the BBT handling. I don't use BBT here. > > Rather it is not enough - already tried to disable, same errors. It > seems I can exclude errors by writing or reading raw data from the NAND. > It seems the problem is related to a different interpretation of ECC > results. > > Stefano > Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND on Davinci boards
On 16/03/11 08:22, Stefano Babic wrote: > Hi all, > > I have seen an incompatibility between the NAND driver in u-boot for the > davinci boards and the linux driver (kernel 2.6.38, mainline). > > I think it is not related to the specific board I use. In any case, I am > using the ea20 board (OMAP-L138 based, in u-boot mainline), and I have > added NAND support setting for the driver: I'm using da830evm (OMAP-L137) with more or less up-to-date U-Boot, but quite old 2.6.18+ kernel from Montavista. > > #define CONFIG_SYS_NAND_4BIT_HW_ECC_OOBFIRST > #define CONFIG_SYS_NAND_USE_FLASH_BBT I don't have BBT enabled. > > This is done in the linux driver, too. Both drivers are using ECC in > Hardware, the number of bits for ECC is set to 4, the OOB is set first, > and the oob layout is the same. > > The NAND driver under u-boot works flawless. The kernel is stored on > NAND (the board boots from a SPI-Flash), and everything seems correct. > > The same thing under linux. In Linux I am able to set up a root > filesystem with UBIfs, everything ok. Problems arises when u-boot tries > to access to data written from Linux and viceversa. It seems to me that > the management of ECC is different in u-boot and in kernel. I almost always update my NAND kernel image from within Linux. U-Boot reads this with no errors and can reboot the system correctly. > > If I write under Linux a kernel Image in a NAND partition, after a reset > I am not able to read that partition from u-boot. > Setting MTDDEBUG and a couple of printf, I see that nand_do_read_ops() > report an error: > >if (mtd->ecc_stats.failed - stats.failed) > return -EBADMSG; > > This is the output of my board: > > nboot aKernel > > Loading from nand0, offset 0x0 > Bad block table found at page 262080, version 0x01 > Bad block table found at page 262016, version 0x01 > Returning error 4 0 > nand_bbt: ECC error while reading bad block table > nand_read_bbt: Bad block at 0x0222 > nand_read_bbt: Bad block at 0x0b12 > nand_read_bbt: Bad block at 0x1f10 > nand_isbad_bbt(): bbt info for offs 0x: (block 0) 0x00 > Returning error 8 4 > NAND read from offset 0 failed -74 > ** Read error > > Checking the two drivers, it seems to me that they are doing different > things. However, I do not know which one is correct. I would think that > the driver in u-boot is old and must be synchronized with the Linux's > driver, but after checking how u-boot gets the ecc's error from Hardware > it seems to me it is correct. > > Has anyone seen the same issue or have proposal, which driver should be > modified ? Neither ;) I think the U-Boot NAND driver for davinci has always been setup to be compatible with the TI & Montavista Kernels. What I'm not sure about is if those Kernels are compatible with mainline Linux and in particular the very latest mainline kernels. In fact I'm not sure if it is compatible with the very latest TI Kernels. Have you tried "nand dump" of a Linux programmed Kernel and compared it with "nand dump" of a U-Boot programmed Kernel? You would be able to see identical data in each case, but you will be able to compare the differences in the OOB. You only need to look at the first page to see if the OOB data or position of the OOB data differs. You errors all seem to be in the BBT handling. I don't use BBT here. Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm926ejs, timer:
On 10/12/10 08:16, Heiko Schocher wrote: > Hello, > > just looked in the timer implementation for arm926ejs based boards, and > found that there is just the at91, davinci, nomadik timer implementation > fixed in actual u-boot. I want to cleanup this timers too, but > there are kirkwood, mb86r0x, orion5x, spear, versatile archs which use > a lastdec var, which is not in global_data.h defined. So the question > is should we add a lastdec to global_data.h or is it Ok, if I use > lastinc for cleaning up? > > Or are there pending patches, which fix this issues for some (all) > arm926ejs architectures? There is an outstanding patch for davinci: http://patchwork.ozlabs.org/patch/74860/ Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] davinci: Rewrite timer.c to use tbl/tbu emulation variables in gd
On 09/12/10 09:32, Nick Thompson wrote: > This change allows the davinci timer functions to be used before > relocation since it avoids using static variables prior to BSS being > made available. > > The code is based on that used in the at91 timers, modified to use > a davinci specific hardware timer. It also maintains reset_timer() > to allow deprecated timer usage to continue to work (for example, > in nand_base.c) > > Signed-off-by: Nick Thompson Also: Tested-by: Ben Gardiner Tested-by: Sudhakar Rajashekhara (see: v1 patch @ http://patchwork.ozlabs.org/patch/73973/) Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] davinci: Rewrite timer.c to use tbl/tbu emulation variables in gd
This change allows the davinci timer functions to be used before
relocation since it avoids using static variables prior to BSS being
made available.
The code is based on that used in the at91 timers, modified to use
a davinci specific hardware timer. It also maintains reset_timer()
to allow deprecated timer usage to continue to work (for example,
in nand_base.c)
Signed-off-by: Nick Thompson
---
This patch relies on http://patchwork.ozlabs.org/patch/73758/ which has been
applied to the ARM tree.
Changes since v1:
checkpatch extra space in cast
arch/arm/cpu/arm926ejs/davinci/timer.c | 77
1 files changed, 28 insertions(+), 49 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/davinci/timer.c
b/arch/arm/cpu/arm926ejs/davinci/timer.c
index 9da7443..1c6fa4a 100644
--- a/arch/arm/cpu/arm926ejs/davinci/timer.c
+++ b/arch/arm/cpu/arm926ejs/davinci/timer.c
@@ -40,6 +40,8 @@
#include
#include
+DECLARE_GLOBAL_DATA_PTR;
+
struct davinci_timer {
u_int32_t pid12;
u_int32_t emumgt;
@@ -57,11 +59,9 @@ struct davinci_timer {
static struct davinci_timer * const timer =
(struct davinci_timer *)CONFIG_SYS_TIMERBASE;
-#define TIMER_LOAD_VAL (CONFIG_SYS_HZ_CLOCK / CONFIG_SYS_HZ)
-#define TIM_CLK_DIV16
+#define TIMER_LOAD_VAL 0x
-static ulong timestamp;
-static ulong lastinc;
+#define TIM_CLK_DIV16
int timer_init(void)
{
@@ -71,72 +71,51 @@ int timer_init(void)
writel(0x06 | ((TIM_CLK_DIV - 1) << 8), &timer->tgcr);
writel(0x0, &timer->tim34);
writel(TIMER_LOAD_VAL, &timer->prd34);
- lastinc = 0;
- timestamp = 0;
writel(2 << 22, &timer->tcr);
+ gd->timer_rate_hz = CONFIG_SYS_HZ_CLOCK / TIM_CLK_DIV;
+ gd->timer_reset_value = 0;
return(0);
}
void reset_timer(void)
{
- writel(0x0, &timer->tcr);
- writel(0x0, &timer->tim34);
- lastinc = 0;
- timestamp = 0;
- writel(2 << 22, &timer->tcr);
+ gd->timer_reset_value = get_ticks();
}
-static ulong get_timer_raw(void)
+/*
+ * Get the current 64 bit timer tick count
+ */
+unsigned long long get_ticks(void)
{
- ulong now = readl(&timer->tim34);
-
- if (now >= lastinc) {
- /* normal mode */
- timestamp += now - lastinc;
- } else {
- /* overflow ... */
- timestamp += now + TIMER_LOAD_VAL - lastinc;
- }
- lastinc = now;
- return timestamp;
+ unsigned long now = readl(&timer->tim34);
+
+ /* increment tbu if tbl has rolled over */
+ if (now < gd->tbl)
+ gd->tbu++;
+ gd->tbl = now;
+
+ return (((unsigned long long)gd->tbu) << 32) | gd->tbl;
}
ulong get_timer(ulong base)
{
- return((get_timer_raw() / (TIMER_LOAD_VAL / TIM_CLK_DIV)) - base);
-}
+ unsigned long long timer_diff;
-void set_timer(ulong t)
-{
- timestamp = t;
+ timer_diff = get_ticks() - gd->timer_reset_value;
+
+ return (timer_diff / (gd->timer_rate_hz / CONFIG_SYS_HZ)) - base;
}
void __udelay(unsigned long usec)
{
- ulong tmo;
- ulong endtime;
- signed long diff;
-
- tmo = CONFIG_SYS_HZ_CLOCK / 1000;
- tmo *= usec;
- tmo /= (1000 * TIM_CLK_DIV);
-
- endtime = get_timer_raw() + tmo;
+ unsigned long long endtime;
- do {
- ulong now = get_timer_raw();
- diff = endtime - now;
- } while (diff >= 0);
-}
+ endtime = ((unsigned long long)usec * gd->timer_rate_hz) / 100UL;
+ endtime += get_ticks();
-/*
- * This function is derived from PowerPC code (read timebase as long long).
- * On ARM it just returns the timer value.
- */
-unsigned long long get_ticks(void)
-{
- return(get_timer(0));
+ while (get_ticks() < endtime)
+ ;
}
/*
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] davinci: Rewrite timer.c to use tbl/tbu emulation variables in gd
On 02/12/10 14:18, Ben Gardiner wrote: > Hi Nick, > > On Thu, Dec 2, 2010 at 8:57 AM, Nick Thompson wrote: >> This change allows the davinci timer functions to be used before >> relocation since it avoids using static variables prior to BSS being >> made available. >> Signed-off-by: Nick Thompson >> --- >> This patch relies on http://patchwork.ozlabs.org/patch/73758/ which has not >> been >> accepted yet. I have made a comment on it, suggesting that it should be >> changed: >> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/90040/focus=90162 > > Applies cleanly to v2010.12-rc2 on top of > http://patchwork.ozlabs.org/patch/73758/ > > Tested on da850evm w/o any config changes. This fixes the freeze on > boot: 10/10 times. > > You're awesome, Nick! > > Tested-by: Ben Gardiner I thought it sounded like the problem you where having. Glad it helps. Thanks for the Tested-by. >> + endtime = ((unsigned long long )usec * gd->timer_rate_hz) / >> 100UL; > > just one minor checkpatch.pl warning; should be (unsigned long long) > -- no space before ')' Good spot. I've fixed that locally and will submit a v2 if the depending patch finds favour - Alternative approaches have been suggested, this one is *my* short-term favourite. Thanks, Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] davinci: Rewrite timer.c to use tbl/tbu emulation variables in gd
This change allows the davinci timer functions to be used before
relocation since it avoids using static variables prior to BSS being
made available.
The code is based on that used in the at91 timers, modified to use
a davinci specific hardware timer. It also maintains reset_timer()
to allow deprecated timer usage to continue to work (for example,
in nand_base.c)
Signed-off-by: Nick Thompson
---
This patch relies on http://patchwork.ozlabs.org/patch/73758/ which has not been
accepted yet. I have made a comment on it, suggesting that it should be changed:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/90040/focus=90162
arch/arm/cpu/arm926ejs/davinci/timer.c | 77
1 files changed, 28 insertions(+), 49 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/davinci/timer.c
b/arch/arm/cpu/arm926ejs/davinci/timer.c
index 9da7443..bfc6b40 100644
--- a/arch/arm/cpu/arm926ejs/davinci/timer.c
+++ b/arch/arm/cpu/arm926ejs/davinci/timer.c
@@ -40,6 +40,8 @@
#include
#include
+DECLARE_GLOBAL_DATA_PTR;
+
struct davinci_timer {
u_int32_t pid12;
u_int32_t emumgt;
@@ -57,11 +59,9 @@ struct davinci_timer {
static struct davinci_timer * const timer =
(struct davinci_timer *)CONFIG_SYS_TIMERBASE;
-#define TIMER_LOAD_VAL (CONFIG_SYS_HZ_CLOCK / CONFIG_SYS_HZ)
-#define TIM_CLK_DIV16
+#define TIMER_LOAD_VAL 0x
-static ulong timestamp;
-static ulong lastinc;
+#define TIM_CLK_DIV16
int timer_init(void)
{
@@ -71,72 +71,51 @@ int timer_init(void)
writel(0x06 | ((TIM_CLK_DIV - 1) << 8), &timer->tgcr);
writel(0x0, &timer->tim34);
writel(TIMER_LOAD_VAL, &timer->prd34);
- lastinc = 0;
- timestamp = 0;
writel(2 << 22, &timer->tcr);
+ gd->timer_rate_hz = CONFIG_SYS_HZ_CLOCK / TIM_CLK_DIV;
+ gd->timer_reset_value = 0;
return(0);
}
void reset_timer(void)
{
- writel(0x0, &timer->tcr);
- writel(0x0, &timer->tim34);
- lastinc = 0;
- timestamp = 0;
- writel(2 << 22, &timer->tcr);
+ gd->timer_reset_value = get_ticks();
}
-static ulong get_timer_raw(void)
+/*
+ * Get the current 64 bit timer tick count
+ */
+unsigned long long get_ticks(void)
{
- ulong now = readl(&timer->tim34);
-
- if (now >= lastinc) {
- /* normal mode */
- timestamp += now - lastinc;
- } else {
- /* overflow ... */
- timestamp += now + TIMER_LOAD_VAL - lastinc;
- }
- lastinc = now;
- return timestamp;
+ unsigned long now = readl(&timer->tim34);
+
+ /* increment tbu if tbl has rolled over */
+ if (now < gd->tbl)
+ gd->tbu++;
+ gd->tbl = now;
+
+ return (((unsigned long long)gd->tbu) << 32) | gd->tbl;
}
ulong get_timer(ulong base)
{
- return((get_timer_raw() / (TIMER_LOAD_VAL / TIM_CLK_DIV)) - base);
-}
+ unsigned long long timer_diff;
-void set_timer(ulong t)
-{
- timestamp = t;
+ timer_diff = get_ticks() - gd->timer_reset_value;
+
+ return (timer_diff / (gd->timer_rate_hz / CONFIG_SYS_HZ)) - base;
}
void __udelay(unsigned long usec)
{
- ulong tmo;
- ulong endtime;
- signed long diff;
-
- tmo = CONFIG_SYS_HZ_CLOCK / 1000;
- tmo *= usec;
- tmo /= (1000 * TIM_CLK_DIV);
-
- endtime = get_timer_raw() + tmo;
+ unsigned long long endtime;
- do {
- ulong now = get_timer_raw();
- diff = endtime - now;
- } while (diff >= 0);
-}
+ endtime = ((unsigned long long )usec * gd->timer_rate_hz) / 100UL;
+ endtime += get_ticks();
-/*
- * This function is derived from PowerPC code (read timebase as long long).
- * On ARM it just returns the timer value.
- */
-unsigned long long get_ticks(void)
-{
- return(get_timer(0));
+ while (get_ticks() < endtime)
+ ;
}
/*
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: make timer variables in gt_t available for all ARM platforms
On 01/12/10 12:16, Prafulla Wadaskar wrote:
> After ARM relocation,
> any code executed directly or indirectly by board_init_f() have
> global (BSS) variables need to be fixed. mostly timer.c needs to
> fix on most of the ARM platforms.
>
> This patch makes timer related variables in gd_t available for
> all ARM implementation
>
> Signed-off-by: Prafulla Wadaskar
> ---
> arch/arm/include/asm/global_data.h |4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/include/asm/global_data.h
> b/arch/arm/include/asm/global_data.h
> index ada3fbb..efb502e 100644
> --- a/arch/arm/include/asm/global_data.h
> +++ b/arch/arm/include/asm/global_data.h
> @@ -55,7 +55,9 @@ typedef struct global_data {
> unsigned long plla_rate_hz;
> unsigned long pllb_rate_hz;
> unsigned long at91_pllb_usb_init;
> - /* "static data" needed by at91's timer.c */
> +#endif
> +#ifdef CONFIG_ARM
> + /* "static data" needed by most of timer.c on ARM platforms */
> unsigned long timer_rate_hz;
> unsigned long tbl;
> unsigned long tbu;
This file is ARM specific. Doesn't this mean CONFIG_ARM is always defined here?
Regards,
Nick.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [ARM] [davinci] timer.c changes
I have changed the davinci timer code to work with the, originally at91 only, gd variables: unsigned long timer_rate_hz; unsigned long tbl; unsigned long tbu; unsigned long long timer_reset_value; It does use the timer_reset_value to keep compatibility with places where timers are not used correctly. I have tested it on da830evm and it my board now boots correctly. Has it been agreed on the way forward for these timer fixes? Is it worth me posting the patch? It does seem to me that there would be room for a common layer and a arch specific tbl/tbu emulation layer as suggested here: http://lists.denx.de/pipermail/u-boot/2010-November/081377.html but maybe it would be good to get more boards working prior to release and then look at how they can be made more common later? Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4] da830: fixup ARM relocation support
Fixes build breakage in da830evm after commit 97003756249bd790910417eb66f0039bbf06a02c "da8xx: fixup ARM relocation support" The da8xx fixup commit changed da830/da850 common code to make relocation work in da850, but didn't add the required defines to da830evm_config.h resulting in build failure in the common code. This patch adds those defines for da830, but makes no sense without also referring to the commit mentioned above. Signed-off-by: Nick Thompson Reviewed-by: Ben Gardiner --- Changes since v1: removed CONFIG_SKIP_RELOCATE_UBOOT Changes since v2: removed "#undef CONFIG_SYS_ARM_WITHOUT_RELOC" as it is not defined in the first place. Changes since v3: Rebased to lastest include/configs/da830evm.h | 10 -- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/include/configs/da830evm.h b/include/configs/da830evm.h index 1feada9..3a2631b 100644 --- a/include/configs/da830evm.h +++ b/include/configs/da830evm.h @@ -47,8 +47,7 @@ * Memory Info */ #define CONFIG_SYS_MALLOC_LEN (0x1 + 1*1024*1024) /* malloc() len */ -#define PHYS_SDRAM_1 DAVINCI_DDR_EMIF_DATA_BASE /* DDR Start */ -#define PHYS_SDRAM_1_SIZE (64 << 20) /* SDRAM size 64MB */ +#define PHYS_SDRAM_1 0xc000 /* SDRAM Start */ #define CONFIG_SYS_MEMTEST_START PHYS_SDRAM_1 /* memtest start addr */ #define CONFIG_SYS_MEMTEST_END (PHYS_SDRAM_1 + 16*1024*1024) /* 16MB test */ #define CONFIG_NR_DRAM_BANKS 1 /* we have 1 bank of DRAM */ @@ -280,4 +279,11 @@ "mtdparts=davinci_nand.1:" PART_BOOT PART_PARAMS PART_KERNEL PART_REST #endif +#define CONFIG_MAX_RAM_BANK_SIZE (512 << 20) /* max size from SPRS586*/ + +/* additions for new relocation code, must be added to all boards */ +#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 +#define CONFIG_SYS_INIT_SP_ADDR\ + (CONFIG_SYS_SDRAM_BASE + 0x1000 - GENERATED_GBL_DATA_SIZE) + #endif /* __CONFIG_H */ -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] [NEXT] da830: fixup ARM relocation support
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/84921 There have been no further comments since I posted v3 of this patch 4 weeks ago. It still applies cleanly to my newly updated tree of u-boot. da830evm will not build without it. Can this patch be commited? Thanks, Nick. On 23/09/10 10:32, Nick Thompson wrote: > Fixes build breakage in da830evm after commit > 97003756249bd790910417eb66f0039bbf06a02c "da8xx: fixup ARM > relocation support" > > The da8xx fixup commit changed da830/da850 common code to make > relocation work in da850, but didn't add the required defines > to da830evm_config.h resulting in build failure in the common code. > > This patch adds those defines for da830, but makes no sense without > also referring to the commit mentioned above. > > Signed-off-by: Nick Thompson > Reviewed-by: Ben Gardiner > --- > Changes since v1: > removed CONFIG_SKIP_RELOCATE_UBOOT > > Changes since v2: > removed "#undef CONFIG_SYS_ARM_WITHOUT_RELOC" as it is not defined > in the first place. > > include/configs/da830evm.h | 11 --- > 1 files changed, 8 insertions(+), 3 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] [NEXT] da830: fixup ARM relocation support
On 23/09/10 10:32, Nick Thompson wrote: > Fixes build breakage in da830evm after commit > 97003756249bd790910417eb66f0039bbf06a02c "da8xx: fixup ARM > relocation support" > > The da8xx fixup commit changed da830/da850 common code to make > relocation work in da850, but didn't add the required defines > to da830evm_config.h resulting in build failure in the common code. > > This patch adds those defines for da830, but makes no sense without > also referring to the commit mentioned above. > > Signed-off-by: Nick Thompson > Reviewed-by: Ben Gardiner > --- > Changes since v1: > removed CONFIG_SKIP_RELOCATE_UBOOT > > Changes since v2: > removed "#undef CONFIG_SYS_ARM_WITHOUT_RELOC" as it is not defined > in the first place. > > include/configs/da830evm.h | 11 --- > 1 files changed, 8 insertions(+), 3 deletions(-) Hi Sandeep, Does this patch need to go through the TI tree? It brings da830 in line with da850. Thanks, Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 1/2][NEXT] davinci_emac: davinci_eth_set_mac_addr to ->write_hwaddr
On 23/09/10 14:33, Ben Gardiner wrote: > This patch proposes to migrate the davinci_emac driver to using the > eth_device->write_hwaddr function pointer as suggested by Ben Warren. > > All the davinci boards had the behaviour, prior to this patch, of > sync'ing the environment variable enetaddr with the MAC address read > from non-volatile storage on boot -- when the two locations disagreed, > the environment variable value took precendence. This patch keeps the > same behaviour but lets eth_initialize take care of it. > > This patch refactors davinci_emac setup in the boards so that the MAC > address is read from non-volatile storage into the environment variable > and then the environment variable value is use in eth_intialize. The > only exception is the direct call to davinci_eth_set_mac_addr made by > the da830evm board init which was changed into an assignment of the > enetaddr field. > > Signed-off-by: Ben Gardiner > CC: Ben Warren > CC: Nick Thompson > > -- > V5: > * don't check return code of write_hwaddr in da830 board setup > V4: > * No change > V3: > * rebased to u-boot/next, removed additional direct call of > davinci_eth_set_mac_addr added to board_init_r by Heiko's > relocation patches > V2: > * introduced this patch > --- Shouldn't this version information go below the '---' line. As it is, it appears in the log message after using 'git am' to apply. Sorry, I should have noticed that earlier. Patch works correctly on da830evm. Tested-by: Nick Thompson Thanks, Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] [NEXT] da830: fixup ARM relocation support
Fixes build breakage in da830evm after commit 97003756249bd790910417eb66f0039bbf06a02c "da8xx: fixup ARM relocation support" The da8xx fixup commit changed da830/da850 common code to make relocation work in da850, but didn't add the required defines to da830evm_config.h resulting in build failure in the common code. This patch adds those defines for da830, but makes no sense without also referring to the commit mentioned above. Signed-off-by: Nick Thompson Reviewed-by: Ben Gardiner --- Changes since v1: removed CONFIG_SKIP_RELOCATE_UBOOT Changes since v2: removed "#undef CONFIG_SYS_ARM_WITHOUT_RELOC" as it is not defined in the first place. include/configs/da830evm.h | 11 --- 1 files changed, 8 insertions(+), 3 deletions(-) diff --git a/include/configs/da830evm.h b/include/configs/da830evm.h index 160ece2..b87e90c 100644 --- a/include/configs/da830evm.h +++ b/include/configs/da830evm.h @@ -41,15 +41,13 @@ #define CONFIG_SYS_HZ_CLOCKclk_get(DAVINCI_AUXCLK_CLKID) #define CONFIG_SYS_HZ 1000 #define CONFIG_SKIP_LOWLEVEL_INIT -#define CONFIG_SKIP_RELOCATE_UBOOT /* to a proper address, init done */ /* * Memory Info */ #define CONFIG_SYS_MALLOC_LEN (0x1 + 1*1024*1024) /* malloc() len */ #define CONFIG_SYS_GBL_DATA_SIZE 128 /* reserved for initial data */ -#define PHYS_SDRAM_1 DAVINCI_DDR_EMIF_DATA_BASE /* DDR Start */ -#define PHYS_SDRAM_1_SIZE (64 << 20) /* SDRAM size 64MB */ +#define PHYS_SDRAM_1 0xc000 /* SDRAM Start */ #define CONFIG_SYS_MEMTEST_START PHYS_SDRAM_1 /* memtest start addr */ #define CONFIG_SYS_MEMTEST_END (PHYS_SDRAM_1 + 16*1024*1024) /* 16MB test */ #define CONFIG_NR_DRAM_BANKS 1 /* we have 1 bank of DRAM */ @@ -281,4 +279,11 @@ "mtdparts=davinci_nand.1:" PART_BOOT PART_PARAMS PART_KERNEL PART_REST #endif +#define CONFIG_MAX_RAM_BANK_SIZE (512 << 20) /* max size from SPRS586*/ + +/* additions for new relocation code, must be added to all boards */ +#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 +#define CONFIG_SYS_INIT_SP_ADDR \ + (CONFIG_SYS_SDRAM_BASE + 0x1000 - CONFIG_SYS_GBL_DATA_SIZE) + #endif /* __CONFIG_H */ -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/2][NEXT] davinci_emac: davinci_eth_set_mac_addr to ->write_hwaddr
On 22/09/10 19:44, Ben Gardiner wrote:
> This patch proposes to migrate the davinci_emac driver to using the
> eth_device->write_hwaddr function pointer as suggested by Ben Warren.
>
> All the davinci boards had the behaviour, prior to this patch, of
> sync'ing the environment variable enetaddr with the MAC address read
> from non-volatile storage on boot -- when the two locations disagreed,
> the environment variable value took precendence. This patch keeps the
> same behaviour but lets eth_initialize take care of it.
>
> This patch refactors davinci_emac setup in the boards so that the MAC
> address is read from non-volatile storage into the environment variable
> and then the environment variable value is use in eth_intialize. The
> only exception is the direct call to davinci_eth_set_mac_addr made by
> the da830evm board init which was changed into an assignment of the
> enetaddr field.
>
> Signed-off-by: Ben Gardiner
> CC: Ben Warren
> CC: Nick Thompson
>
> --
>
> V4:
> * no changes
> V3:
> * rebased to u-boot/next, removed additional direct call of
> davinci_eth_set_mac_addr added to board_init_r by Heiko's
> relocation patches
> V2:
> * introduced this patch
> ---
> arch/arm/include/asm/arch-davinci/emac_defs.h |1 -
> arch/arm/lib/board.c | 19 --
> board/davinci/common/misc.c | 41 +++--
> board/davinci/common/misc.h |2 +-
> board/davinci/da8xxevm/da830evm.c | 15 -
> board/davinci/dm365evm/dm365evm.c |2 +-
> board/davinci/dvevm/dvevm.c |2 +-
> board/davinci/sffsdr/sffsdr.c |2 +-
> board/davinci/sonata/sonata.c |2 +-
> drivers/net/davinci_emac.c| 80
> -
> 10 files changed, 64 insertions(+), 102 deletions(-)
>
[snip]
> diff --git a/board/davinci/da8xxevm/da830evm.c
> b/board/davinci/da8xxevm/da830evm.c
> index 6baa860..d5a228f 100644
> --- a/board/davinci/da8xxevm/da830evm.c
> +++ b/board/davinci/da8xxevm/da830evm.c
> @@ -196,19 +196,17 @@ int board_eth_init(bd_t *bis)
> {
> u_int8_t mac_addr[6];
> u_int8_t switch_start_cmd[2] = { 0x01, 0x23 };
> + struct eth_device *dev;
>
> /* Read Ethernet MAC address from EEPROM */
> if (dvevm_read_mac_address(mac_addr))
> /* set address env if not already set */
> - dv_configure_mac_address(mac_addr);
> + davinci_sync_env_enetaddr(mac_addr);
>
> /* read the address back from env */
> if (!eth_getenv_enetaddr("ethaddr", mac_addr))
> return -1;
>
> - /* provide the resulting addr to the driver */
> - davinci_eth_set_mac_addr(mac_addr);
> -
> /* enable the Ethernet switch in the 3 port PHY */
> if (i2c_write(PHY_SW_I2C_ADDR, 0, 0,
> switch_start_cmd, sizeof(switch_start_cmd))) {
> @@ -222,6 +220,15 @@ int board_eth_init(bd_t *bis)
> return -1;
> }
>
> + dev = eth_get_dev();
> +
> + /* provide the resulting addr to the driver */
> + memcpy(dev->enetaddr, mac_addr, 6);
> + if (!dev->write_hwaddr(dev)) {
> + printf("Error: Could not set MAC address\n");
> + return -1;
> + }
> +
> return 0;
> }
> #endif /* CONFIG_DRIVER_TI_EMAC */
Hi Ben,
davinci_eth_set_mac_addr() always returns zero, so "if
(!dev->write_hwaddr(dev))"
always appears to fail here.
In net/eth.c the return code is not checked, so da830 should probably ignore it
to:
diff --git a/board/davinci/da8xxevm/da830evm.c
b/board/davinci/da8xxevm/da830evm.c
index d5a228f..8a9f988 100644
--- a/board/davinci/da8xxevm/da830evm.c
+++ b/board/davinci/da8xxevm/da830evm.c
@@ -224,10 +224,7 @@ int board_eth_init(bd_t *bis)
/* provide the resulting addr to the driver */
memcpy(dev->enetaddr, mac_addr, 6);
- if (!dev->write_hwaddr(dev)) {
- printf("Error: Could not set MAC address\n");
- return -1;
- }
+ dev->write_hwaddr(dev);
return 0;
}
With this change, this patch works on da830. I'll retest when you resubmit.
Nick.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [NEXT] da830: fixup ARM relocation support
On 22/09/10 16:07, Ben Gardiner wrote: > On Wed, Sep 22, 2010 at 10:15 AM, Nick Thompson wrote: >> On 22/09/10 14:43, Ben Gardiner wrote: >>> What about removing "#define CONFIG_SKIP_RELOCATE_UBOOT" as in commit >>> ab86f72c354f9b2572340f72b74ca0a258c451bd ? >> >> Hmmm. It wouldn't hurt I guess. The UBL copies the code to the correct >> address though doesn't it? The copy is not executed and so the code is >> redundant - or did I miss something? > > Yeah, good point. UBL does copy the code to the correct address -- but > I also remember that I needed to remove that define in my testing of > Heiko's patches on the da850. > > I'll get around to testing -next again soon and I'll try with > CONFIG_SKIP_RELOCATE_UBOOT defined. No, don't do that. I just did some testing myself. The relocation address is calculated at run time and includes the size of u-boot itself. I got away with it once in my debugger (I was trying to dodge the extra copy), but it broke once I added more code. You would have to change the UBL on more or less every build of u-boot to skip the copy, which is clearly impractical. I have removed CONFIG_SKIP_RELOCATE_UBOOT as you suggested and now everything takes care of itself. I've already sent a v2 patch. Thanks for pointing me in the right direction. Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] [NEXT] da830: fixup ARM relocation support
Fixes build breakage in da830evm after commit 97003756249bd790910417eb66f0039bbf06a02c "da8xx: fixup ARM relocation support" The da8xx fixup commit changed da830/da850 common code to make relocation work in da850, but didn't add the required defines to da830evm_config.h resulting in build failure in the common code. This patch adds those defines for da830, but makes no sense without also referring to the commit mentioned above. Signed-off-by: Nick Thompson --- Changes since v1: removed CONFIG_SKIP_RELOCATE_UBOOT include/configs/da830evm.h | 12 +--- 1 files changed, 9 insertions(+), 3 deletions(-) diff --git a/include/configs/da830evm.h b/include/configs/da830evm.h index 160ece2..ca44e09 100644 --- a/include/configs/da830evm.h +++ b/include/configs/da830evm.h @@ -41,15 +41,13 @@ #define CONFIG_SYS_HZ_CLOCKclk_get(DAVINCI_AUXCLK_CLKID) #define CONFIG_SYS_HZ 1000 #define CONFIG_SKIP_LOWLEVEL_INIT -#define CONFIG_SKIP_RELOCATE_UBOOT /* to a proper address, init done */ /* * Memory Info */ #define CONFIG_SYS_MALLOC_LEN (0x1 + 1*1024*1024) /* malloc() len */ #define CONFIG_SYS_GBL_DATA_SIZE 128 /* reserved for initial data */ -#define PHYS_SDRAM_1 DAVINCI_DDR_EMIF_DATA_BASE /* DDR Start */ -#define PHYS_SDRAM_1_SIZE (64 << 20) /* SDRAM size 64MB */ +#define PHYS_SDRAM_1 0xc000 /* SDRAM Start */ #define CONFIG_SYS_MEMTEST_START PHYS_SDRAM_1 /* memtest start addr */ #define CONFIG_SYS_MEMTEST_END (PHYS_SDRAM_1 + 16*1024*1024) /* 16MB test */ #define CONFIG_NR_DRAM_BANKS 1 /* we have 1 bank of DRAM */ @@ -281,4 +279,12 @@ "mtdparts=davinci_nand.1:" PART_BOOT PART_PARAMS PART_KERNEL PART_REST #endif +#define CONFIG_MAX_RAM_BANK_SIZE (512 << 20) /* max size from SPRS586*/ + +/* additions for new relocation code, must be added to all boards */ +#undef CONFIG_SYS_ARM_WITHOUT_RELOC +#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 +#define CONFIG_SYS_INIT_SP_ADDR \ + (CONFIG_SYS_SDRAM_BASE + 0x1000 - CONFIG_SYS_GBL_DATA_SIZE) + #endif /* __CONFIG_H */ -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [NEXT] da830: fixup ARM relocation support
On 22/09/10 14:43, Ben Gardiner wrote: > On Wed, Sep 22, 2010 at 9:16 AM, Nick Thompson wrote: >> Fixes build breakage in da830evm after commit >> 97003756249bd790910417eb66f0039bbf06a02c "da8xx: fixup ARM >> relocation support" >> >> The da8xx fixup commit changed da830/da850 common code to make >> relocation work in da850, but didn't add the required defines >> to da830evm_config.h resulting in build failure in the common code. >> >> This patch adds those defines for da830, but makes no sense without >> also referring to the commit mentioned above. >> >> Signed-off-by: Nick Thompson > > Sorry that was my fault for not adding the needed changes to the da830 > config also when I submitted that patch. It's not a problem - at least you laid the ground work for a fix that had to be done anyway. I only mentioned it to put the patch in context. > What about removing "#define CONFIG_SKIP_RELOCATE_UBOOT" as in commit > ab86f72c354f9b2572340f72b74ca0a258c451bd ? Hmmm. It wouldn't hurt I guess. The UBL copies the code to the correct address though doesn't it? The copy is not executed and so the code is redundant - or did I miss something? Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] [NEXT] da830: fixup ARM relocation support
Fixes build breakage in da830evm after commit 97003756249bd790910417eb66f0039bbf06a02c "da8xx: fixup ARM relocation support" The da8xx fixup commit changed da830/da850 common code to make relocation work in da850, but didn't add the required defines to da830evm_config.h resulting in build failure in the common code. This patch adds those defines for da830, but makes no sense without also referring to the commit mentioned above. Signed-off-by: Nick Thompson --- include/configs/da830evm.h | 11 +-- 1 files changed, 9 insertions(+), 2 deletions(-) diff --git a/include/configs/da830evm.h b/include/configs/da830evm.h index 160ece2..b281e5f 100644 --- a/include/configs/da830evm.h +++ b/include/configs/da830evm.h @@ -48,8 +48,7 @@ */ #define CONFIG_SYS_MALLOC_LEN (0x1 + 1*1024*1024) /* malloc() len */ #define CONFIG_SYS_GBL_DATA_SIZE 128 /* reserved for initial data */ -#define PHYS_SDRAM_1 DAVINCI_DDR_EMIF_DATA_BASE /* DDR Start */ -#define PHYS_SDRAM_1_SIZE (64 << 20) /* SDRAM size 64MB */ +#define PHYS_SDRAM_1 0xc000 /* SDRAM Start */ #define CONFIG_SYS_MEMTEST_START PHYS_SDRAM_1 /* memtest start addr */ #define CONFIG_SYS_MEMTEST_END (PHYS_SDRAM_1 + 16*1024*1024) /* 16MB test */ #define CONFIG_NR_DRAM_BANKS 1 /* we have 1 bank of DRAM */ @@ -281,4 +280,12 @@ "mtdparts=davinci_nand.1:" PART_BOOT PART_PARAMS PART_KERNEL PART_REST #endif +#define CONFIG_MAX_RAM_BANK_SIZE (512 << 20) /* max size from SPRS586*/ + +/* additions for new relocation code, must be added to all boards */ +#undef CONFIG_SYS_ARM_WITHOUT_RELOC +#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 +#define CONFIG_SYS_INIT_SP_ADDR \ + (CONFIG_SYS_SDRAM_BASE + 0x1000 - CONFIG_SYS_GBL_DATA_SIZE) + #endif /* __CONFIG_H */ -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] davinci_emac: davinci_eth_set_mac_addr to ->write_hwaddr
On 13/09/10 22:04, Ben Gardiner wrote: > This patch proposes to migrate the davinci_emac driver to using the > eth_device->write_hwaddr function pointer as suggested by Ben Warren. > > All the davinci boards had the behaviour, prior to this patch, of > sync'ing the environment variable enetaddr with the MAC address read > from non-volatile storage on boot -- when the two locations disagreed, > the environment variable value took precendence. This patch keeps the > same behaviour but makes eth_initialize take care of it. > > This patch refactors davinci_emac setup in the boards so that the MAC > address is read from non-volatile storage into the environment variable > and then the environment variable value is use in eth_intialize. The > only exception is the direct call to davinci_eth_set_mac_addr made by > the da830evm board init which was changed into an assignment of the > enetaddr field. > > Signed-off-by: Ben Gardiner > CC: Ben Warren > CC: Nick Thompson This change seem reasonable to me from the da830evm point of view. I don't have access to hardware for the next week or so, so I can't test it now, but the da830 specific changes are minor. Reviewed-by: Nick Thompson ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH 17/19] arm cp15: setup mmu and enable dcache
On 30/07/10 10:32, Heiko Schocher wrote:
> Nick Thompson wrote:
>> On 29/07/10 11:45, Heiko Schocher wrote:
>>> +i++) {
>>> + page_table[i] = i << 20 | (3 << 10) | 0x1e;
>>
>> These numbers ought to be defines, no?
>>
>> The 0x1e will not work on da8xx as the data cache is broken. The d-cache can
>> still be used in write back mode, so the value 0x1a should be used. It would
Here, I should have said write-thru' can still be used...
>> be good to have symbols to define the caching modes: none, wr-thru', wr-back
>> or some such, similar to Linux.
>
> Ah, Ok, good hint!
>
> What with:
>
> if !defined(CONFIG_SYS_ARM_CACHE_SETUP)
> #define CONFIG_SYS_ARM_CACHE_SETUP0x1e
> #endif
>
> page_table[i] = i << 20 | (3 << 10) |
> CONFIG_SYS_ARM_CACHE_SETUP;
>
> So boards/architectures can define there own values?
How about:
#if defined(CONFIG_SYS_ARM_CACHE_WRITETHROUGH)
#define CACHE_SETUP 0x1a
#else
#define CACHE_SETUP 0x1e
#endif
page_table[i] = i << 20 | (3 << 10) | CACHE_SETUP;
This would avoid people having to look up the appropriate value(s).
This follows the Linux model, but there the symbol CPU_CACHE_WRITETHROUGH
is used. Ideally, I would suggest we use the CPU form as well, but it
would imply an effect beyond ARM.
--
Nick
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH 17/19] arm cp15: setup mmu and enable dcache
On 29/07/10 11:45, Heiko Schocher wrote:
> This has been tested on at91sam9263 and STN8815.
> Again, I didn't check if it has bad effects
> on non-arm926 cores.
>
> Initially I had a "done" bit to only set up page tables
> at the beginning. However, since the aligmnent requirement
> was for the whole object file, this extra integer tool 16kB
> in BSS, so I chose to remove it.
>
> Also, note not all boards use PHYS_SDRAM, but it looks like
> it's the most used name (more than CONFIG_SYS_DRAM_BASE for
> example).
>
> rebased for full arm relocation from Heiko Schocher
>
> Signed-off-by: Alessandro Rubini
> ---
> arch/arm/lib/cache-cp15.c | 38 ++
> 1 files changed, 38 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/lib/cache-cp15.c b/arch/arm/lib/cache-cp15.c
> index 62ed54f..11e64d8 100644
> --- a/arch/arm/lib/cache-cp15.c
> +++ b/arch/arm/lib/cache-cp15.c
> @@ -32,6 +32,36 @@ static void cp_delay (void)
> /* copro seems to need some delay between reading and writing */
> for (i = 0; i < 100; i++)
> nop();
> + asm volatile("" : : : "memory");
> +}
> +
> +/* to activate the MMU we need to set up virtual memory: use 1M areas in bss
> */
> +static inline void mmu_setup(void)
> +{
> + static u32 __attribute__((aligned(16384))) page_table[4096];
> + int i;
> + u32 reg;
> +
> + /* Set up an identity-mapping for all 4GB, rw for everyone */
> + for (i = 0; i < 4096; i++)
> + page_table[i] = i << 20 | (3 << 10) | 0x12;
> + /* Then, enable cacheable and bufferable for RAM only */
> + for (i = PHYS_SDRAM >> 20;
> + i < ( PHYS_SDRAM + PHYS_SDRAM_SIZE) >> 20;
As you noted, not all boards define these two symbols. I don't see where you
have added them in the config.h files. You do seem to have created a new
symbol CONFIG_SYS_SDRAM_BASE which you could use, but you would still need
a CONFIG_SYS_SDRAM_SIZE wouldn't you?
> + i++) {
> + page_table[i] = i << 20 | (3 << 10) | 0x1e;
These numbers ought to be defines, no?
The 0x1e will not work on da8xx as the data cache is broken. The d-cache can
still be used in write back mode, so the value 0x1a should be used. It would
be good to have symbols to define the caching modes: none, wr-thru', wr-back
or some such, similar to Linux.
> + }
> + /* Copy the page table address to cp15 */
> + asm volatile("mcr p15, 0, %0, c2, c0, 0"
> + : : "r" (page_table) : "memory");
> + /* Set the access control to all-supervisor */
> + asm volatile("mcr p15, 0, %0, c3, c0, 0"
> + : : "r" (~0));
> + /* and enable the mmu */
> + reg = get_cr(); /* get control reg. */
> + cp_delay();
> + set_cr(reg | CR_M);
> +
> }
I have previously tested this patch on da830 and it works fine, bar the two
issues above.
Nick.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Davinci: SPI: add the missing v2 patch changes
Two Indentation fixes.
Catch requests for full-duplex transfers when driver configured for
half-duplex operation only.
Signed-off-by: Nick Thompson
---
drivers/spi/davinci_spi.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c
index 4518ecb..13aca52 100644
--- a/drivers/spi/davinci_spi.c
+++ b/drivers/spi/davinci_spi.c
@@ -173,7 +173,7 @@ static int davinci_spi_read(struct spi_slave *slave,
unsigned int len,
}
static int davinci_spi_write(struct spi_slave *slave, unsigned int len,
- const u8 *txp, unsigned long flags)
+const u8 *txp, unsigned long flags)
{
struct davinci_spi_slave *ds = to_davinci_spi(slave);
unsigned int data1_reg_val;
@@ -237,7 +237,7 @@ static int davinci_spi_read_write(struct spi_slave *slave,
unsigned int len,
#endif
int spi_xfer(struct spi_slave *slave, unsigned int bitlen,
- const void *dout, void *din, unsigned long flags)
+const void *dout, void *din, unsigned long flags)
{
unsigned int len;
@@ -266,6 +266,10 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen,
#ifndef CONFIG_SPI_HALF_DUPLEX
else
return davinci_spi_read_write(slave, len, din, dout, flags);
+#else
+ printf("SPI full duplex transaction requested with "
+ "CONFIG_SPI_HALF_DUPLEX defined.\n");
+ flags |= SPI_XFER_END;
#endif
out:
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Davinci: SPI performance enhancements
On 22/06/10 16:27, Paulraj, Sandeep wrote: > >> The following restructuring and optimisations increase the SPI >> read performance from 1.3MiB/s (on da850) to 2.87MiB/s (on da830): >> >> Remove continual revaluation of driver state from the core of the >> copy loop. State can not change during the copy loop, so it is >> possible to move these evaluations to before the copy loop. >> >> Cost is more code space as loop variants are required for each set >> of possible configurations. The loops are simpler however, so the >> extra is only 128bytes on da830 with CONFIG_SPI_HALF_DUPLEX >> defined. >> >> Unrolling the first copy loop iteration allows the TX buffer to be >> pre-loaded reducing SPI clock starvation. >> >> Unrolling the last copy loop iteration removes testing for the >> final loop iteration every time round the loop. >> >> Using the RX buffer empty flag as a transfer throttle allows the >> assumption that it is always safe to write to the TX buffer, so >> polling of TX buffer full flag can be removed. >> >> Signed-off-by: Nick Thompson >> --- >> da850 and da830 are similar devices. The SPI module is common to >> both, but da850 uses DDR and da830 uses SDRAM. The EVM's might >> not actually be comparable, but they appear to be at least similar. >> >> The speed was tested with a 8MiB transfer from SPI FLASH using: >> >> sf read 0xc0008000 0 0x80 >> >> drivers/spi/davinci_spi.c | 195 +--- > > Applied to u-boot-ti/next Sandeep, You're too quick for me :-) I was going to do a v2 patch to cover a couple of Delio's points. They are not critical issues though, so I think we can let the pull request go through and I will submit a new patch once it hits u-boot/next: On 21/06/10 19:38, Delio Brignoli wrote: >> +if (!dout) >> +return davinci_spi_read(slave, len, din, flags); >> +else if (!din) >> +return davinci_spi_write(slave, len, dout, flags); >> +#ifndef CONFIG_SPI_HALF_DUPLEX >> +else >> +return davinci_spi_read_write(slave, len, din, dout, flags); >> +#endif > > I think there should always be an else branch at the end even if > CONFIG_SPI_HALF_DUPLEX is not defined. Something like: > > #else > flags |= SPI_XFER_END; > #endif > > to terminate the transfer instead of failing silently. > In fact it should signal the error condition somehow, but > I do not know enough about u-boot to provide an advice on this. Its a non issue if the driver is called correctly in the first place, but we can't be sure of that. Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Davinci: SPI performance enhancements
On 21/06/10 19:38, Delio Brignoli wrote: > Hello Nick, > > On 21/06/2010, at 11:27, Nick Thompson wrote: >> The following restructuring and optimisations increase the SPI >> read performance from 1.3MiB/s (on da850) to 2.87MiB/s (on da830): > > Using this patch I get 2.21MiB/s on my L138 EVM (da850), quite > an improvement! I would like to see how much my original patch can > be improved using some of your changes without splitting the code > to handle the three cases. I will try later this week. Not testing the txp and rxp pointers in the loop was a significant gain for me and pipe-lining the TX and RX operations is going to be a little trickier, but give it a go by all means. > > [...] >> +if (!dout) >> +return davinci_spi_read(slave, len, din, flags); >> +else if (!din) >> +return davinci_spi_write(slave, len, dout, flags); >> +#ifndef CONFIG_SPI_HALF_DUPLEX >> +else >> +return davinci_spi_read_write(slave, len, din, dout, flags); >> +#endif > > I think there should always be an else branch at the end even if > CONFIG_SPI_HALF_DUPLEX is not defined. Something like: > > #else > flags |= SPI_XFER_END; > #endif Hmmm, yes, you are correct. That must be added, else in the unexpected case, the transaction will be opened and left open. I'll fix that. > > to terminate the transfer instead of failing silently. > In fact it should signal the error condition somehow, but > I do not know enough about u-boot to provide an advice on this. I think maybe a printk(KERN_ERR ...) will do it. I'll add that too. > > Thanks > -- > Delio Thanks for the review. Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Davinci: SPI performance enhancements
On 21/06/10 15:41, Paulraj, Sandeep wrote: > > >> >> The following restructuring and optimisations increase the SPI >> read performance from 1.3MiB/s (on da850) to 2.87MiB/s (on da830): >> >> Remove continual revaluation of driver state from the core of the >> copy loop. State can not change during the copy loop, so it is >> possible to move these evaluations to before the copy loop. >> >> Cost is more code space as loop variants are required for each set >> of possible configurations. The loops are simpler however, so the >> extra is only 128bytes on da830 with CONFIG_SPI_HALF_DUPLEX >> defined. >> >> Unrolling the first copy loop iteration allows the TX buffer to be >> pre-loaded reducing SPI clock starvation. >> >> Unrolling the last copy loop iteration removes testing for the >> final loop iteration every time round the loop. >> >> Using the RX buffer empty flag as a transfer throttle allows the >> assumption that it is always safe to write to the TX buffer, so >> polling of TX buffer full flag can be removed. >> >> Signed-off-by: Nick Thompson >> --- >> da850 and da830 are similar devices. The SPI module is common to >> both, but da850 uses DDR and da830 uses SDRAM. The EVM's might >> not actually be comparable, but they appear to be at least similar. >> >> The speed was tested with a 8MiB transfer from SPI FLASH using: >> >> sf read 0xc0008000 0 0x80 >> >> drivers/spi/davinci_spi.c | 195 +--- > > This patch does not apply against Wolfgang's next. > The patch should be against u-boot/next. It looks like Delio's patch ended up being pulled into main via Tom's tree and yours. On u-boot I see 9268236529161312c877e638a14c011fd3c883e1, but the same commit has id 23911740486c59851df57521c49bfd81ce1865ec on on u-boot-ti. I guess this is the source of the confusion? My patch was against u-boot, not u-boot-ti. Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Davinci: SPI performance enhancements
On 21/06/10 15:41, Paulraj, Sandeep wrote: > > >> >> The following restructuring and optimisations increase the SPI >> read performance from 1.3MiB/s (on da850) to 2.87MiB/s (on da830): >> >> Remove continual revaluation of driver state from the core of the >> copy loop. State can not change during the copy loop, so it is >> possible to move these evaluations to before the copy loop. >> >> Cost is more code space as loop variants are required for each set >> of possible configurations. The loops are simpler however, so the >> extra is only 128bytes on da830 with CONFIG_SPI_HALF_DUPLEX >> defined. >> >> Unrolling the first copy loop iteration allows the TX buffer to be >> pre-loaded reducing SPI clock starvation. >> >> Unrolling the last copy loop iteration removes testing for the >> final loop iteration every time round the loop. >> >> Using the RX buffer empty flag as a transfer throttle allows the >> assumption that it is always safe to write to the TX buffer, so >> polling of TX buffer full flag can be removed. >> >> Signed-off-by: Nick Thompson >> --- >> da850 and da830 are similar devices. The SPI module is common to >> both, but da850 uses DDR and da830 uses SDRAM. The EVM's might >> not actually be comparable, but they appear to be at least similar. >> >> The speed was tested with a 8MiB transfer from SPI FLASH using: >> >> sf read 0xc0008000 0 0x80 >> >> drivers/spi/davinci_spi.c | 195 +--- > > This patch does not apply against Wolfgang's next. > The patch should be against u-boot/next. The patch is based on u-boot as updated this morning. It applies directly after Delio's patch, which is in u-boot/next, and the last change to this file. u-boot/next is at the tip and is three days old. I don't understand why it doesn't apply. What failure do you see? $ git log drivers/spi/davinci_spi.c commit 15c4e0802caed209ca021de25ec607658ae35720 Author: Nick Thompson Date: Mon Jun 21 09:48:22 2010 +0100 Davinci: SPI performance enhancements The following restructuring and optimisations increase the SPI [...skip to next log...] commit 9268236529161312c877e638a14c011fd3c883e1 Author: Delio Brignoli Date: Mon Jun 7 17:16:13 2010 -0400 DaVinci: Improve DaVinci SPI speed. I have updated this patch based on the comments [1] by Wolfgang Denk and ... Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Davinci: SPI performance enhancements
The following restructuring and optimisations increase the SPI
read performance from 1.3MiB/s (on da850) to 2.87MiB/s (on da830):
Remove continual revaluation of driver state from the core of the
copy loop. State can not change during the copy loop, so it is
possible to move these evaluations to before the copy loop.
Cost is more code space as loop variants are required for each set
of possible configurations. The loops are simpler however, so the
extra is only 128bytes on da830 with CONFIG_SPI_HALF_DUPLEX
defined.
Unrolling the first copy loop iteration allows the TX buffer to be
pre-loaded reducing SPI clock starvation.
Unrolling the last copy loop iteration removes testing for the
final loop iteration every time round the loop.
Using the RX buffer empty flag as a transfer throttle allows the
assumption that it is always safe to write to the TX buffer, so
polling of TX buffer full flag can be removed.
Signed-off-by: Nick Thompson
---
da850 and da830 are similar devices. The SPI module is common to
both, but da850 uses DDR and da830 uses SDRAM. The EVM's might
not actually be comparable, but they appear to be at least similar.
The speed was tested with a 8MiB transfer from SPI FLASH using:
sf read 0xc0008000 0 0x80
drivers/spi/davinci_spi.c | 195 +---
1 files changed, 128 insertions(+), 67 deletions(-)
diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c
index 08f837b..4518ecb 100644
--- a/drivers/spi/davinci_spi.c
+++ b/drivers/spi/davinci_spi.c
@@ -66,7 +66,7 @@ void spi_free_slave(struct spi_slave *slave)
int spi_claim_bus(struct spi_slave *slave)
{
struct davinci_spi_slave *ds = to_davinci_spi(slave);
- unsigned int scalar, data1_reg_val = 0;
+ unsigned int scalar;
/* Enable the SPI hardware */
writel(SPIGCR0_SPIRST_MASK, &ds->regs->gcr0);
@@ -93,11 +93,6 @@ int spi_claim_bus(struct spi_slave *slave)
writel(8 | (scalar << SPIFMT_PRESCALE_SHIFT) |
(1 << SPIFMT_PHASE_SHIFT), &ds->regs->fmt0);
- /* hold cs active at end of transfer until explicitly de-asserted */
- data1_reg_val = (1 << SPIDAT1_CSHOLD_SHIFT) |
- (slave->cs << SPIDAT1_CSNR_SHIFT);
- writel(data1_reg_val, &ds->regs->dat1);
-
/*
* Including a minor delay. No science here. Should be good even with
* no delay
@@ -113,8 +108,7 @@ int spi_claim_bus(struct spi_slave *slave)
writel(0, &ds->regs->lvl);
/* enable SPI */
- writel((readl(&ds->regs->gcr1) |
- SPIGCR1_SPIENA_MASK), &ds->regs->gcr1);
+ writel((readl(&ds->regs->gcr1) | SPIGCR1_SPIENA_MASK), &ds->regs->gcr1);
return 0;
}
@@ -127,14 +121,125 @@ void spi_release_bus(struct spi_slave *slave)
writel(SPIGCR0_SPIRST_MASK, &ds->regs->gcr0);
}
+/*
+ * This functions needs to act like a macro to avoid pipeline reloads in the
+ * loops below. Use always_inline. This gains us about 160KiB/s and the bloat
+ * appears to be zero bytes (da830).
+ */
+__attribute__((always_inline))
+static inline u32 davinci_spi_xfer_data(struct davinci_spi_slave *ds, u32 data)
+{
+ u32 buf_reg_val;
+
+ /* send out data */
+ writel(data, &ds->regs->dat1);
+
+ /* wait for the data to clock in/out */
+ while ((buf_reg_val = readl(&ds->regs->buf)) & SPIBUF_RXEMPTY_MASK)
+ ;
+
+ return buf_reg_val;
+}
+
+static int davinci_spi_read(struct spi_slave *slave, unsigned int len,
+ u8 *rxp, unsigned long flags)
+{
+ struct davinci_spi_slave *ds = to_davinci_spi(slave);
+ unsigned int data1_reg_val;
+
+ /* enable CS hold, CS[n] and clear the data bits */
+ data1_reg_val = ((1 << SPIDAT1_CSHOLD_SHIFT) |
+(slave->cs << SPIDAT1_CSNR_SHIFT));
+
+ /* wait till TXFULL is deasserted */
+ while (readl(&ds->regs->buf) & SPIBUF_TXFULL_MASK)
+ ;
+
+ /* preload the TX buffer to avoid clock starvation */
+ writel(data1_reg_val, &ds->regs->dat1);
+
+ /* keep reading 1 byte until only 1 byte left */
+ while ((len--) > 1)
+ *rxp++ = davinci_spi_xfer_data(ds, data1_reg_val);
+
+ /* clear CS hold when we reach the end */
+ if (flags & SPI_XFER_END)
+ data1_reg_val &= ~(1 << SPIDAT1_CSHOLD_SHIFT);
+
+ /* read the last byte */
+ *rxp = davinci_spi_xfer_data(ds, data1_reg_val);
+
+ return 0;
+}
+
+static int davinci_spi_write(struct spi_slave *slave, unsigned int len,
+ const u8 *txp, unsigned long flags)
+{
+ struct davinci_spi_slave *ds = to_davinci_spi(slave);
+ unsigned int data1_reg_val;
+
+ /* enable CS hold and clea
Re: [U-Boot] [PATCH] DaVinci: Improve DaVinci SPI speed.
On 17/06/10 18:38, Delio Brignoli wrote: > Hello Nick, > > On 17/06/2010, at 17:02, Nick Thompson wrote: >> On 01/06/10 12:36, Delio Brignoli wrote: >>> I have updated this patch based on the comments [1] by Wolfgang Denk and >>> removed unused variables. >>> [1][http://lists.denx.de/pipermail/u-boot/2010-May/071728.html] > [...] >> I have an alternative patch that tries to be even quicker, but I >> don't have the same platform as Delio, so can't compare like with >> like. > > I will test your patch on my L138 and let you know. That would be great, thanks - I'm using a SPANSION FLASH, though I don't think that makes any difference. It your results are consistent I will be more confident with my L137 platform as a comparison. > >> In essence, it splits up read and write operations to avoid testing >> pointers in every loop iteration. It also unrolls the last iteration >> so that it doesn't have to test for loop ending twice each time >> round. Finally it avoids bit setting/clearing on each iteration when >> the results would only turn out to be the same anyway. > > I am wondering if it is OK to split reading and writing: when I wrote > the patch I assumed that spi_xfer() was supposed to be able to read and > write to two distinct buffers at the same time. As I understand it, your > patch allows spi_xfer() to be either a read or a write operation but not both > and I do not know if this semantic change is acceptable. Maybe Sekhar or > Sandeep can clarify this. I wondered about that too. I don't think it matters for SPI FLASH, but I guess it could for other SPI devices (Audio?). I was thinking I could add a third routine 'read_write' that does both, which only gets called if a bi-direction transfer is requested. This would make the code even bigger, though it could be conditional on a CONFIG option so it could be excluded if only FLASH support is required. (I'm not sure if U-Boot uses SPI for anything else anyway...) In the mean time, I have reads working at 1.76MiB/s. I need to read the SPI manual carefully before I let that change into the wild though. Basically, I've added an assumption that by the time the RX buffer is ready with the returned bits, the TXer must have completed since they run to the same clock: so no need to test for TX not full in the loop. Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] DaVinci: Improve DaVinci SPI speed.
On 17/06/10 16:10, Paulraj, Sandeep wrote: > > >> >> On 01/06/10 12:36, Delio Brignoli wrote: >>> I have updated this patch based on the comments [1] by Wolfgang Denk and >>> removed unused variables. >>> [1][http://lists.denx.de/pipermail/u-boot/2010-May/071728.html] >>> >>> Reduce the number of reads per byte transferred on the BUF register from >> 2 to 1 and >>> take advantage of the TX buffer in the SPI module. On LogicPD OMAP-L138 >> EVM, >>> SPI read throughput goes up from ~0.8Mbyte/s to ~1.3Mbyte/s. Tested with >> a 2Mbyte image file. >>> Remove unused variables in the spi_xfer() function. >>> >>> Signed-off-by: Delio Brignoli >>> Tested-by: Ben Gardiner >> >> Sorry, I'm a bit late to the party on this. > > It is late. Pull request already sent to Wolfgang >> >> I have an alternative patch that tries to be even quicker, but I >> don't have the same platform as Delio, so can't compare like with >> like. > > Compare it on your platform. I believe you have the OMAP L137. > And post the results. I don't have a scope to get an accurate measure. The best I can do right now is use a serial snooper to time between me pressing return and the next prompt turning up. To try and drown out inaccuracies and delays, I ran: sf read 0xc0008000 0 0x80 So 8MiB in a reasonably consistent 5.62 - 5.63 seconds, which is about 1.49MiB/s by my reckoning. A bit faster, but way short of 6.25MiB/s. Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] DaVinci: Improve DaVinci SPI speed.
On 01/06/10 12:36, Delio Brignoli wrote:
> I have updated this patch based on the comments [1] by Wolfgang Denk and
> removed unused variables.
> [1][http://lists.denx.de/pipermail/u-boot/2010-May/071728.html]
>
> Reduce the number of reads per byte transferred on the BUF register from 2 to
> 1 and
> take advantage of the TX buffer in the SPI module. On LogicPD OMAP-L138 EVM,
> SPI read throughput goes up from ~0.8Mbyte/s to ~1.3Mbyte/s. Tested with a
> 2Mbyte image file.
> Remove unused variables in the spi_xfer() function.
>
> Signed-off-by: Delio Brignoli
> Tested-by: Ben Gardiner
Sorry, I'm a bit late to the party on this.
I have an alternative patch that tries to be even quicker, but I
don't have the same platform as Delio, so can't compare like with
like.
This diff applies before Delio's patch. If it is any faster I am
prepared to create a proper patch. If nobody can test it for speed
I'll probably just drop it, since it produces a slightly bigger
executable and I don't know that it is actually any faster...
In essence, it splits up read and write operations to avoid testing
pointers in every loop iteration. It also unrolls the last iteration
so that it doesn't have to test for loop ending twice each time
round. Finally it avoids bit setting/clearing on each iteration when
the results would only turn out to be the same anyway.
Here's the diff:
diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c
index 60ba007..a90d2f4 100644
--- a/drivers/spi/davinci_spi.c
+++ b/drivers/spi/davinci_spi.c
@@ -126,16 +126,98 @@ void spi_release_bus(struct spi_slave *slave)
writel(SPIGCR0_SPIRST_MASK, &ds->regs->gcr0);
}
-int spi_xfer(struct spi_slave *slave, unsigned int bitlen,
- const void *dout, void *din, unsigned long flags)
+static inline u8 davinci_spi_read_data(struct davinci_spi_slave *ds, u32 data)
+{
+ unsigned intbuf_reg_val;
+ /* wait till TXFULL is deasserted */
+ while (readl(&ds->regs->buf) & SPIBUF_TXFULL_MASK)
+ ;
+ writel(data, &ds->regs->dat1);
+
+ /* read the data - wait for data availability */
+ while ((buf_reg_val = readl(&ds->regs->buf)) & SPIBUF_RXEMPTY_MASK)
+ ;
+ return buf_reg_val & 0xFF;
+}
+
+static int davinci_spi_read(struct spi_slave *slave, unsigned int len,
+ u8 *rxp, unsigned long flags)
{
struct davinci_spi_slave *ds = to_davinci_spi(slave);
- unsigned intlen, data1_reg_val = readl(&ds->regs->dat1);
- int ret, i;
- const u8*txp = dout; /* dout can be NULL for read operation */
- u8 *rxp = din; /* din can be NULL for write operation */
+ unsigned int data1_reg_val = readl(&ds->regs->dat1);
+
+ /* do an empty read to clear the current contents */
+ (void)readl(&ds->regs->buf);
+
+ /* enable CS hold */
+ data1_reg_val |= ((1 << SPIDAT1_CSHOLD_SHIFT) |
+ (slave->cs << SPIDAT1_CSNR_SHIFT));
+ data1_reg_val &= ~0x;
+
+ /* keep writing and reading 1 byte until only 1 byte left to read */
+ while ((len--) > 1) {
+ *rxp++ = davinci_spi_read_data(ds, data1_reg_val);
+ }
- ret = 0;
+ /*
+* clear CS hold when we reach the end.
+*/
+ if (flags & SPI_XFER_END)
+ data1_reg_val &= ~(1 << SPIDAT1_CSHOLD_SHIFT);
+
+ *rxp = davinci_spi_read_data(ds, data1_reg_val);
+
+ return 0;
+}
+
+static inline void davinci_spi_write_data(struct davinci_spi_slave *ds, u32
data)
+{
+ /* wait till TXFULL is deasserted */
+ while (readl(&ds->regs->buf) & SPIBUF_TXFULL_MASK)
+ ;
+ writel(data, &ds->regs->dat1);
+
+ /* wait for read data availability */
+ while (readl(&ds->regs->buf) & SPIBUF_RXEMPTY_MASK)
+ ;
+}
+
+static int davinci_spi_write(struct spi_slave *slave, unsigned int len,
+ const u8 *txp, unsigned long flags)
+{
+ struct davinci_spi_slave *ds = to_davinci_spi(slave);
+ unsigned int data1_reg_val = readl(&ds->regs->dat1);
+
+ /* do an empty read to clear the current contents */
+ (void)readl(&ds->regs->buf);
+
+ /* enable CS hold */
+ data1_reg_val |= ((1 << SPIDAT1_CSHOLD_SHIFT) |
+ (slave->cs << SPIDAT1_CSNR_SHIFT));
+ data1_reg_val &= ~0x;
+
+ /* keep writing and reading 1 byte until only 1 byte left to write */
+ while ((len--) > 1) {
+ /* write the data */
+ davinci_spi_write_data(ds, data1_reg_val | *txp++);
+ }
+
+ /*
+* clear CS hold when we reach the end.
+*/
+ if (flags & SPI_XFER_END)
+ data1_reg_val &= ~(1 << SPIDAT1_CSHOLD_SHIFT);
+
+ /* write the data */
+ davinci_spi_write_data(ds, data1_reg_val | *txp);
+
+ return 0;
+}
+
+int spi_xfer(struct spi_slave *slave, unsigned int
Re: [U-Boot] [PATCH v4] da830: Move common code out of da830evm.c file
On 04/06/10 15:26, Ben Gardiner wrote:
> On Thu, Jun 3, 2010 at 8:58 AM, Sudhakar Rajashekhara
> wrote:
>> On Thu, Jun 03, 2010 at 16:23:36, Nick Thompson wrote:
>>> On 03/06/10 05:25, Sudhakar Rajashekhara wrote:
>>>> TI's DA850/OMAP-L138 platform is similar to DA830/OMAP-L137
>>>> in many aspects. So instead of repeating the same code in
>>>> multiple files, move the common code to a different file
>>>> and call those functions from the respective da830/da850
>>>> files.
>>>>
>>>> Signed-off-by: Sudhakar Rajashekhara
>>>> Acked-by: Nick Thompson
>>>> Acked-by: Ben Gardiner
>>>> ---
>>>> Since v3:
>>>> Fixes the following compiler error for other davinci targets:
>>>>
>>>> misc.c: In function 'irq_init':
>>>> misc.c:51: error: 'davinci_aintc_regs' undeclared (first use in this
>>>> function)
>>>> misc.c:51: error: (Each undeclared identifier is reported only once
>>>> misc.c:51: error: for each function it appears in.)
>>>> make[1]: *** [.../build/board/davinci/common/misc.o] Error 1
>>>> make: *** [.../build/board/davinci/common/libdavinci.a] Error 2
>>>> make: *** Waiting for unfinished jobs
>>>>
>>>> board/davinci/common/misc.c | 32
>>>> board/davinci/common/misc.h |7 +++
>>>> board/davinci/da830evm/da830evm.c | 28 +++-
>>>> 3 files changed, 50 insertions(+), 17 deletions(-)
>>>>
>>>> diff --git a/board/davinci/common/misc.c b/board/davinci/common/misc.c
>>>> index 25ca326..dcf3cf2 100644
>>>> --- a/board/davinci/common/misc.c
>>>> +++ b/board/davinci/common/misc.c
>>>> @@ -41,6 +41,24 @@ int dram_init(void)
>>>> return(0);
>>>> }
>>>>
>>>> +#ifdef CONFIG_SOC_DA8XX
>>>> +void irq_init(void)
>>>> +{
>>>> + /*
>>>> +* Mask all IRQs by clearing the global enable and setting
>>>> +* the enable clear for all the 90 interrupts.
>>>> +*/
>>>> +
>>>> + writel(0, &davinci_aintc_regs->ger);
>>>> +
>>>> + writel(0, &davinci_aintc_regs->hier);
>>>> +
>>>> + writel(0x, &davinci_aintc_regs->ecr1);
>>>> + writel(0x, &davinci_aintc_regs->ecr2);
>>>> + writel(0x, &davinci_aintc_regs->ecr3);
>>>> +}
>>>> +#endif
>>>
>>> In the current code base, this code is not included in the da830 compilation
>>> if IRQs are not used. With this patch the code is included, but not called
>>> if IRQs are not used. IRQs are often not used, so this change causes bloat.
>>>
>>> Could you please make this conditional on IRQs?
>>>
>>
>> I added the code between CONFIG_SOC_DA8XX macro because davinci_aintc_regs
>> declaration is in between this macro in hardware.h file. So they'll not be
>> available for targets other than DA830 and DA850. Also, AINTC register
>> mapping is different on DM644x, DM646x, DM355 and DM365. Shall I consider
>> moving the irq_init function out of misc.c?
Just to be clear on my part: I meant that it should be conditional on both
DA8XX *and* IRQs.
>
> Since it is da8XX specific, irq_init might be best placed somewhere in
> the board/davinci/da8xxevm directory that is being introduced in the
> da850 support series? Perhaps for this patch it could be extracted to
> board/davinci/da830evm/common.c ?
Agreed.
Also if the register mappings are different across all platforms, maybe
davinci_aintc_regs should be renamed as da8xx_aintc_regs (and the struct
definition name changed as well)?
Nick.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] da830: Move common code out of da830evm.c file
On 03/06/10 05:25, Sudhakar Rajashekhara wrote:
> TI's DA850/OMAP-L138 platform is similar to DA830/OMAP-L137
> in many aspects. So instead of repeating the same code in
> multiple files, move the common code to a different file
> and call those functions from the respective da830/da850
> files.
>
> Signed-off-by: Sudhakar Rajashekhara
> Acked-by: Nick Thompson
> Acked-by: Ben Gardiner
> ---
> Since v3:
> Fixes the following compiler error for other davinci targets:
>
> misc.c: In function 'irq_init':
> misc.c:51: error: 'davinci_aintc_regs' undeclared (first use in this function)
> misc.c:51: error: (Each undeclared identifier is reported only once
> misc.c:51: error: for each function it appears in.)
> make[1]: *** [.../build/board/davinci/common/misc.o] Error 1
> make: *** [.../build/board/davinci/common/libdavinci.a] Error 2
> make: *** Waiting for unfinished jobs
>
> board/davinci/common/misc.c | 32
> board/davinci/common/misc.h |7 +++
> board/davinci/da830evm/da830evm.c | 28 +++-
> 3 files changed, 50 insertions(+), 17 deletions(-)
>
> diff --git a/board/davinci/common/misc.c b/board/davinci/common/misc.c
> index 25ca326..dcf3cf2 100644
> --- a/board/davinci/common/misc.c
> +++ b/board/davinci/common/misc.c
> @@ -41,6 +41,24 @@ int dram_init(void)
> return(0);
> }
>
> +#ifdef CONFIG_SOC_DA8XX
> +void irq_init(void)
> +{
> + /*
> + * Mask all IRQs by clearing the global enable and setting
> + * the enable clear for all the 90 interrupts.
> + */
> +
> + writel(0, &davinci_aintc_regs->ger);
> +
> + writel(0, &davinci_aintc_regs->hier);
> +
> + writel(0x, &davinci_aintc_regs->ecr1);
> + writel(0x, &davinci_aintc_regs->ecr2);
> + writel(0x, &davinci_aintc_regs->ecr3);
> +}
> +#endif
In the current code base, this code is not included in the da830 compilation
if IRQs are not used. With this patch the code is included, but not called
if IRQs are not used. IRQs are often not used, so this change causes bloat.
Could you please make this conditional on IRQs?
> diff --git a/board/davinci/common/misc.h b/board/davinci/common/misc.h
> index 329c369..ee35f01 100644
> --- a/board/davinci/common/misc.h
> +++ b/board/davinci/common/misc.h
> @@ -45,10 +45,17 @@ struct pinmux_resource {
> .n_pins = ARRAY_SIZE(item) \
> }
>
> +struct lpsc_resource {
> + const int lpsc_no;
> +};
> +
> +void irq_init(void);
See comment below...
> int dvevm_read_mac_address(uint8_t *buf);
> void dv_configure_mac_address(uint8_t *rom_enetaddr);
> int davinci_configure_pin_mux(const struct pinmux_config *pins, int n_pins);
> int davinci_configure_pin_mux_items(const struct pinmux_resource *item,
> int n_items);
> +int davinci_configure_lpsc_items(const struct lpsc_resource *item,
> + int n_items);
>
> #endif /* __MISC_H */
> diff --git a/board/davinci/da830evm/da830evm.c
> b/board/davinci/da830evm/da830evm.c
> index 6385443..ed89473 100644
> --- a/board/davinci/da830evm/da830evm.c
> +++ b/board/davinci/da830evm/da830evm.c
> @@ -120,21 +120,18 @@ static const struct pinmux_resource pinmuxes[] = {
> #endif
> };
>
> +static const struct lpsc_resource lpsc[] = {
> + { DAVINCI_LPSC_AEMIF }, /* NAND, NOR */
> + { DAVINCI_LPSC_SPI0 }, /* Serial Flash */
> + { DAVINCI_LPSC_EMAC }, /* image download */
> + { DAVINCI_LPSC_UART2 }, /* console */
> + { DAVINCI_LPSC_GPIO },
> +};
> +
> int board_init(void)
> {
> #ifndef CONFIG_USE_IRQ
> - /*
> - * Mask all IRQs by clearing the global enable and setting
> - * the enable clear for all the 90 interrupts.
> - */
> -
> - writel(0, &davinci_aintc_regs->ger);
> -
> - writel(0, &davinci_aintc_regs->hier);
> -
> - writel(0x, &davinci_aintc_regs->ecr1);
> - writel(0x, &davinci_aintc_regs->ecr2);
> - writel(0x, &davinci_aintc_regs->ecr3);
> + irq_init();
> #endif
I'm okay with this part, but does it make sense to have a weak declaration
(above)
and remove the IRQ ifdef from here?
Nick.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] *** Warning - bad CRC, using default environment
On 20/05/10 04:43, anup behare wrote: > Hi Nick, > > > I observed that when i used saveenv the warning never occurred, but when i > used to erase the flash and burn the u-boot that warning comes again hence I > will have to use saveenv on u-boot command prompt. > > > ~Anup Yes, indeed! The warning was trying to let you know that your work flow is wrong. Flash can be eased in sectors. The env should be in a sector(s) on it's own. There is no need to erase that sector(s) to re-flash U-Boot. Erase only U-Boot before re-flashing U-Boot. This will keep all you env data (which is valuable) intact and the warning will not reappear. If it does reappear you've done /something/ wrong and the warning will catch that for you again. It's a good warning, honestly. Hang on to it. Learn to love it. Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] *** Warning - bad CRC, using default environment
On 18/05/10 08:11, anup behare wrote: > Hi, > > While using u-boot for ppc440 based board we are getting "*** Warning - bad > CRC, using default environment" message. > On denx site we came to know that message is printed because the flash > sector or ERPROM containing the environment variables has never been > initialized yet. That is not quite true. It is one reason, true, but it could also occur if your data has become corrupted and your CRC no longer matches. In the latter case you will be glad of the warning because either your H/W is flaking out or you have accidentally overwritten the env area while writing to FLASH/EEPROM/Whatever. You need to know when these things happen and that's what the warning is for. Just do a saveenv and hope you never see the warning again :) Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot guruplug fails to compile - __aeabi_unwind_cpp_pr0
On 13/05/10 03:09, M.A.E.M. Hanson wrote: > /home/mihanson/CodeSourcery/Sourcery_G++_Lite/u-boot-marvell.git/arch/arm/lib/eabi_compat.o > > -L > /home/mihanson/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1 > > -lgcc -Map u-boot.map -o u-boot > /home/mihanson/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/libgcc.a(bpabi.o):(.ARM.exidx+0x0): > > undefined reference to `__aeabi_unwind_cpp_pr0' > /home/mihanson/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/libgcc.a(_divdi3.o):(.ARM.exidx+0x0): > > undefined reference to `__aeabi_unwind_cpp_pr0' > /home/mihanson/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/libgcc.a(_udivdi3.o):(.ARM.exidx+0x0): > > undefined reference to `__aeabi_unwind_cpp_pr0' > make: *** [u-boot] Error 1 Please have a quick look in the archives of this mailing list. This issue came up in the last week. A patch has already been submitted that you might want to try. Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Building for da830 fails
On 11/05/10 11:39, Wolfgang Denk wrote:
> Dear Nick,
>
> In message <4be91c64.9050...@ge.com> you wrote:
>>
>> True, but the extra library (and abi workaround) bloat is not necessary in
>> this particular case.
>
> I agree that we can avoid the 64 bit division here - at the cost of
> code that becomes much more difficult to read and understand.
>
> Look at code like this:
Yes, I wrote (some of) it :-)
>
> + f = size & ((1ULL << d) - 1);
> ...
> - if(size % d) {
> - m = (10 * (size - (n * d)) + (d / 2) ) / d;
> + if (f) {
> + m = (10ULL * f + (1 << (d - 1))) >> d;
>
>
> We make things more easy for the compiler at the cost of making it
> way more difficult for us humans. I think this is a move in the wrong
> direction. Normally we try to go exactly the opposite direction.
I've certainly made your point here. It's taken me 3 version to make it work,
but, maybe with with a little commenting, I think that's readable. I'm not
sure that:
n = size / d;
if(size % d) {
m = (10 * (size - (n * d)) + (d / 2) ) / d;
...
is really any more readable is it?
Me: What is '(size - (n * d))'? Oh, its just '(size % d)'. Why is it
calculating that twice???
Maybe I'm just allergic to divides - especially when working with variables
containing powers of two. That's what I get for working on ARM processors for
so long...
How about:
n = size >> d
f = size & ((1ULL << d) - 1);
/* If there's a remainder, deal with it */
if (f) {
roundup = 1 << (d - 1); /* 0.5 << d */
m = (10ULL * f + roundup) >> d;
...
?
[...]
>> or avoid using features not available in all toolchains that you wish to
>> support.
>
> We never claimed to support "all toolchains" - for example, recent
> versions of U-Boot cannot be compiled any more with gcc-2.95.x - but
> is this really an issue? I don't think so.
I didn't say "all toolchains", but "all toolchains that you wish to support".
In this case, both MontaVista and CodeSourcery's latest ARM compilers don't
work.
Should you treat the cause or the symptom? Personally, I prefer the former. The
eabi compat function feels more like the latter.
In the interests of not holding back other CPU's though, I guess I can live with
it.
[...]
>> The eabi stub you submitted is only good as long as C++ and exceptions are
>> not
>> used by U-Boot. Exceptions in particular are a powerful way to clean up error
>> handling code - can we ever say never?
>
> No, we cannot. But we do :-)
>
>
>
Blimey. I can hear the chafing from here ;-)
Regards,
Nick.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] Avoid use of divides in print_size
Modification of print_size to avoid use of divides and especially
long long divides. Keep the binary scale factor in terms of bit
shifts instead. This should be faster, since the previous code
gave the compiler no clues that the divides where always powers
of two, preventing optimisation.
Signed-off-by: Nick Thompson
---
Since v1:
Removed misplaced brackets that resulted in round-up value of
5 rather than the intended 0.5. Now passes Timur Tabi's test.
Since v2:
Fix overflow in calculation of 0.5 rounding value for numbers
with engineered factional parts representing values >4GiB
lib/display_options.c | 14 --
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/lib/display_options.c b/lib/display_options.c
index 86df05d..a711425 100644
--- a/lib/display_options.c
+++ b/lib/display_options.c
@@ -46,13 +46,14 @@ int display_options (void)
void print_size(unsigned long long size, const char *s)
{
unsigned long m = 0, n;
+ unsigned long long f;
static const char names[] = {'E', 'P', 'T', 'G', 'M', 'K'};
- unsigned long long d = 1ULL << (10 * ARRAY_SIZE(names));
+ unsigned long d = 10 * ARRAY_SIZE(names);
char c = 0;
unsigned int i;
- for (i = 0; i < ARRAY_SIZE(names); i++, d >>= 10) {
- if (size >= d) {
+ for (i = 0; i < ARRAY_SIZE(names); i++, d -= 10) {
+ if (size >> d) {
c = names[i];
break;
}
@@ -63,11 +64,12 @@ void print_size(unsigned long long size, const char *s)
return;
}
- n = size / d;
+ n = size >> d;
+ f = size & ((1ULL << d) - 1);
/* If there's a remainder, deal with it */
- if(size % d) {
- m = (10 * (size - (n * d)) + (d / 2) ) / d;
+ if (f) {
+ m = (10ULL * f + (1ULL << (d - 1))) >> d;
if (m >= 10) {
m -= 10;
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Building for da830 fails
On 10/05/10 22:17, Wolfgang Denk wrote: > In message <4be43218.2060...@freescale.com> you wrote: >> which means that in order to support support printing 64-bit numbers on ARM, >> we might need to completely rewrite print_size() to avoid division on 64-bit >> numbers. > > This actually makes little sense to me. Avoiding this here will just > make the problem pop up somewhare else later. True, but the extra library (and abi workaround) bloat is not necessary in this particular case. The proper fix is to either insist on a toolchain that supports 64bit divides, or avoid using features not available in all toolchains that you wish to support. In the later case, rewriting the function would be a good idea wouldn't it? The eabi stub you submitted is only good as long as C++ and exceptions are not used by U-Boot. Exceptions in particular are a powerful way to clean up error handling code - can we ever say never? Regards, Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Avoid use of divides in print_size.
On 10/05/10 20:25, Timur Tabi wrote:
> Here's a more revealing test:
>
> unsigned int i;
>
> for (i = 0; i < 60; i++) {
> unsigned long long l = 45ULL << i;
> printf("%llu - ", l);
> print_size(l, "\n");
> }
>
> prints:
>
> 45 - 45 Bytes
> 90 - 90 Bytes
> 180 - 180 Bytes
> 360 - 360 Bytes
> 720 - 720 Bytes
> 1440 - 1.9 KiB
> 2880 - 3.3 KiB
> 5760 - 6.1 KiB
[snip]
Ahh, your testing foo is strong. That is a better test than mine. I have
submitted a new patch which, with your test, gives (value - old new):
45 - 45 Bytes 45 Bytes
90 - 90 Bytes 90 Bytes
180 - 180 Bytes 180 Bytes
360 - 360 Bytes 360 Bytes
720 - 720 Bytes 720 Bytes
1440 - 1.4 KiB 1.4 KiB
2880 - 2.8 KiB 2.8 KiB
5760 - 5.6 KiB 5.6 KiB
11520 - 11.3 KiB 11.3 KiB
23040 - 22.5 KiB 22.5 KiB
46080 - 45 KiB 45 KiB
92160 - 90 KiB 90 KiB
184320 - 180 KiB 180 KiB
368640 - 360 KiB 360 KiB
737280 - 720 KiB 720 KiB
1474560 - 1.4 MiB 1.4 MiB
2949120 - 2.8 MiB 2.8 MiB
5898240 - 5.6 MiB 5.6 MiB
11796480 - 11.3 MiB 11.3 MiB
23592960 - 22.5 MiB 22.5 MiB
47185920 - 45 MiB 45 MiB
94371840 - 90 MiB 90 MiB
188743680 - 180 MiB 180 MiB
377487360 - 360 MiB 360 MiB
754974720 - 720 MiB 720 MiB
1509949440 - 1.4 GiB 1.4 GiB
3019898880 - 2.8 GiB 2.8 GiB
6039797760 - 5.6 GiB 5.6 GiB
12079595520 - 11.3 GiB 11.3 GiB
24159191040 - 22.5 GiB 22.5 GiB
48318382080 - 45 GiB 45 GiB
96636764160 - 90 GiB 90 GiB
193273528320 - 180 GiB 180 GiB
386547056640 - 360 GiB 360 GiB
773094113280 - 720 GiB 720 GiB
1546188226560 - 1.4 TiB 1.4 TiB
3092376453120 - 2.8 TiB 2.8 TiB
6184752906240 - 5.6 TiB 5.6 TiB
12369505812480 - 11.3 TiB 11.2 TiB
24739011624960 - 22.5 TiB 22.5 TiB
49478023249920 - 45 TiB 45 TiB
98956046499840 - 90 TiB 90 TiB
197912092999680 - 180 TiB 180 TiB
395824185999360 - 360 TiB 360 TiB
791648371998720 - 720 TiB 720 TiB
1583296743997440 - 1.4 PiB 1.4 PiB
3166593487994880 - 2.8 PiB 2.8 PiB
6333186975989760 - 5.6 PiB 5.6 PiB
12666373951979520 - 11.3 PiB 11.2 PiB
25332747903959040 - 22.5 PiB 22.5 PiB
50665495807918080 - 45 PiB 45 PiB
101330991615836160 - 90 PiB 90 PiB
202661983231672320 - 180 PiB 180 PiB
405323966463344640 - 360 PiB 360 PiB
810647932926689280 - 720 PiB 720 PiB
1621295865853378560 - 1.4 EiB 1.4 EiB
3242591731706757120 - 2.8 EiB 2.8 EiB
6485183463413514240 - 5.6 EiB 5.6 EiB
12970366926827028480 - 11.3 EiB 11.2 EiB
7493989779944505344 - 6.5 EiB 6.5 EiB
I was using 5 as a round-up rather than 0.5 due to some extraneous ()'s.
(10 * 0.5)...
>
> That last one is probably an overflow.
I believe so, yes.
Thank you for supplying the test code.
Regards,
Nick.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Avoid use of divides in print_size
Modification of print_size to avoid use of divides and especially
long long divides. Keep the binary scale factor in terms of bit
shifts instead. This should be faster, since the previous code
gave the compiler no clues that the divides where always powers
of two, preventing optimisation.
Signed-off-by: Nick Thompson
---
Since v1:
Removed misplaced brackets that resulted in round-up value of
5 rather than the intended 0.5. Now passes Timur Tabi's test.
lib/display_options.c | 14 --
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/lib/display_options.c b/lib/display_options.c
index 86df05d..14a2da5 100644
--- a/lib/display_options.c
+++ b/lib/display_options.c
@@ -46,13 +46,14 @@ int display_options (void)
void print_size(unsigned long long size, const char *s)
{
unsigned long m = 0, n;
+ unsigned long long f;
static const char names[] = {'E', 'P', 'T', 'G', 'M', 'K'};
- unsigned long long d = 1ULL << (10 * ARRAY_SIZE(names));
+ unsigned long d = 10 * ARRAY_SIZE(names);
char c = 0;
unsigned int i;
- for (i = 0; i < ARRAY_SIZE(names); i++, d >>= 10) {
- if (size >= d) {
+ for (i = 0; i < ARRAY_SIZE(names); i++, d -= 10) {
+ if (size >> d) {
c = names[i];
break;
}
@@ -63,11 +64,12 @@ void print_size(unsigned long long size, const char *s)
return;
}
- n = size / d;
+ n = size >> d;
+ f = size & ((1ULL << d) - 1);
/* If there's a remainder, deal with it */
- if(size % d) {
- m = (10 * (size - (n * d)) + (d / 2) ) / d;
+ if (f) {
+ m = (10ULL * f + (1 << (d - 1))) >> d;
if (m >= 10) {
m -= 10;
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Building for da830 fails
On 07/05/10 16:30, Timur Tabi wrote: > Scott McNutt wrote: >> lib/libgeneric.a(display_options.o): In function `print_size': >> /home/smcnutt/27xx/u-boot.git/lib/display_options.c:66: undefined >> reference to `__udivdi3' >> /home/smcnutt/27xx/u-boot.git/lib/display_options.c:69: undefined >> reference to `__umoddi3' >> /home/smcnutt/27xx/u-boot.git/lib/display_options.c:70: undefined >> reference to `__udivdi3' > > Man, I knew ARM sucked, but I didn't know it was this bad :-) > > I was going to suggestion replacing the division operations with calls to > lldiv(), but we're actually doing a 64-by-64 bit division here: > > n = size / d; > > which means that in order to support support printing 64-bit numbers on ARM, > we might need to completely rewrite print_size() to avoid division on 64-bit > numbers. > > Wolfgang, do you have any suggestions? > I'm not sure if it is the correct way to "fix" this issue, But I have submitted a patch in "[U-Boot] [PATCH] Avoid use of divides in print_size." It allows ARM to rebuild again (here at least), but really it modifies the function to use bit shifts as an optimisation over calling lengthy div library functions. This side steps the linker issue. It you have chance to test or review it I would be grateful. I tested the code on x86 Linux PC, not by running it in U-Boot. Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Avoid use of divides in print_size.
Modification of print_size to avoid use of divides and especially
long long divides. Keep the binary scale factor in terms of bit
shifts instead. This should be faster, since the previous code
gave the compiler no clues that the divides where always powers
of two, preventing optimisation.
Signed-off-by: Nick Thompson
---
This patch should make print_size a little faster, but perhaps
nobody cares about that too much. What it also does though is
reenable U-Boot linking for ARM with standard toolchains.
(e.g. CodeSourcery and MontaVista).
lib/display_options.c | 14 --
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/lib/display_options.c b/lib/display_options.c
index 86df05d..636916d 100644
--- a/lib/display_options.c
+++ b/lib/display_options.c
@@ -46,13 +46,14 @@ int display_options (void)
void print_size(unsigned long long size, const char *s)
{
unsigned long m = 0, n;
+ unsigned long long f;
static const char names[] = {'E', 'P', 'T', 'G', 'M', 'K'};
- unsigned long long d = 1ULL << (10 * ARRAY_SIZE(names));
+ unsigned long d = 10 * ARRAY_SIZE(names);
char c = 0;
unsigned int i;
- for (i = 0; i < ARRAY_SIZE(names); i++, d >>= 10) {
- if (size >= d) {
+ for (i = 0; i < ARRAY_SIZE(names); i++, d -= 10) {
+ if (size >> d) {
c = names[i];
break;
}
@@ -63,11 +64,12 @@ void print_size(unsigned long long size, const char *s)
return;
}
- n = size / d;
+ n = size >> d;
+ f = size & ((1ULL << d) - 1);
/* If there's a remainder, deal with it */
- if(size % d) {
- m = (10 * (size - (n * d)) + (d / 2) ) / d;
+ if (f) {
+ m = (10ULL * (f + (1 << (d - 1 >> d;
if (m >= 10) {
m -= 10;
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Building for da830 fails
On 07/05/10 15:14, Nick Thompson wrote: > On 07/05/10 12:57, Sudhakar Rajashekhara wrote: >> Hi, >> >> I am using U-Boot from http://git.denx.de/?p=u-boot.git;a=summary and trying >> to build for da830. But my build fails with following >> error: >> >> [...] >> /../lib/gcc/arm-none-linux-gnueabi/4.4.1 -lgcc -Map u-boot.map -o u-boot >> ../lib/gcc/arm-none-linux-gnueabi/4.4.1/libgcc.a(bpabi.o):(.ARM.exidx+0x0): >> undefined reference to `__aeabi_unwind_cpp_pr0' >> ../lib/gcc/arm-none-linux-gnueabi/4.4.1/libgcc.a(_divdi3.o):(.ARM.exidx+0x0): >> undefined reference to `__aeabi_unwind_cpp_pr0' >> ../lib/gcc/arm-none-linux-gnueabi/4.4.1/libgcc.a(_udivdi3.o):(.ARM.exidx+0x0): >> undefined reference to `__aeabi_unwind_cpp_pr0' >> >> I am using gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202). I also tried >> with gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203), but >> there also I am seeing the same error. I am using "da830evm_config" as the >> configuration for building. >> >> Has anyone seen this kind of error while building U-Boot for ARM based >> architecture? > > I just pulled the latest main line source and ran: > > % CROSS_COMPILE=arm-none-linux-gnueabi- ./MAKEALL da830evm > Configuring for da830evm board... > /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/libgcc.a(bpabi.o):(.ARM.exidx+0x0): > undefined reference to `__aeabi_unwind_cpp_pr0' > /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/libgcc.a(_divdi3.o):(.ARM.exidx+0x0): > undefined reference to `__aeabi_unwind_cpp_pr0' > /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/libgcc.a(_udivdi3.o):(.ARM.exidx+0x0): > undefined reference to `__aeabi_unwind_cpp_pr0' > make: *** [u-boot] Error 1 > /opt/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi-size: > './u-boot': No such file > > This did not happen when I last updated on March 22nd and > I have not updated my tools at all. Sorry to reply to self. I ran a git bisect session and I get: 52dbac69c27dee67a4c051b1055d93b0ac4e2062 is the first bad commit commit 52dbac69c27dee67a4c051b1055d93b0ac4e2062 Author: Timur Tabi Date: Tue Apr 13 13:16:02 2010 -0500 fix print_size printing fractional gigabyte numbers on 32-bit platforms In print_size(), the math that calculates the fractional remainder of a number used the same integer size as a physical address. However, the "10 *" factor of the algorithm means that a large number (e.g. 1.5GB) can overflow the integer if we're running on a 32-bit system. Therefore, we need to disassociate this function from the size of a physical address. Signed-off-by: Timur Tabi :04 04 2469aed20d27e8d444f749bea2d99fb85d66a52a fee73c34d4eb4d9db3b8640909e519131e5222bf M lib Is this the first use of long long on ARM...? Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Building for da830 fails
On 07/05/10 12:57, Sudhakar Rajashekhara wrote: > Hi, > > I am using U-Boot from http://git.denx.de/?p=u-boot.git;a=summary and trying > to build for da830. But my build fails with following > error: > > [...] > /../lib/gcc/arm-none-linux-gnueabi/4.4.1 -lgcc -Map u-boot.map -o u-boot > ../lib/gcc/arm-none-linux-gnueabi/4.4.1/libgcc.a(bpabi.o):(.ARM.exidx+0x0): > undefined reference to `__aeabi_unwind_cpp_pr0' > ../lib/gcc/arm-none-linux-gnueabi/4.4.1/libgcc.a(_divdi3.o):(.ARM.exidx+0x0): > undefined reference to `__aeabi_unwind_cpp_pr0' > ../lib/gcc/arm-none-linux-gnueabi/4.4.1/libgcc.a(_udivdi3.o):(.ARM.exidx+0x0): > undefined reference to `__aeabi_unwind_cpp_pr0' > > I am using gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202). I also tried > with gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203), but > there also I am seeing the same error. I am using "da830evm_config" as the > configuration for building. > > Has anyone seen this kind of error while building U-Boot for ARM based > architecture? I just pulled the latest main line source and ran: % CROSS_COMPILE=arm-none-linux-gnueabi- ./MAKEALL da830evm Configuring for da830evm board... /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/libgcc.a(bpabi.o):(.ARM.exidx+0x0): undefined reference to `__aeabi_unwind_cpp_pr0' /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/libgcc.a(_divdi3.o):(.ARM.exidx+0x0): undefined reference to `__aeabi_unwind_cpp_pr0' /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/libgcc.a(_udivdi3.o):(.ARM.exidx+0x0): undefined reference to `__aeabi_unwind_cpp_pr0' make: *** [u-boot] Error 1 /opt/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi-size: './u-boot': No such file This did not happen when I last updated on March 22nd and I have not updated my tools at all. Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] da830: Move common code out of da830evm.c file
On 21/04/10 12:58, Sudhakar Rajashekhara wrote: > TI's DA850/OMAP-L138 platform is similar to DA830/OMAP-L137 > in many aspects. So instead of repeating the same code in > multiple files, move the common code to a different file > and call those functions from the respective da830/da850 > files. > > Signed-off-by: Sudhakar Rajashekhara > --- > board/davinci/common/misc.c | 30 ++ > board/davinci/common/misc.h |6 ++ > board/davinci/da830evm/da830evm.c | 28 +++- > 3 files changed, 47 insertions(+), 17 deletions(-) > As this patch mainly effects da830evm: Acked-by: Nick Thompson ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] allow print_size to print large numbers on 32-bit systems
On 12/04/10 17:21, Timur Tabi wrote: > Nick Thompson wrote: > >> To differentiate from "K", which means 1000, rather than 1024. > > I don't think that's correct. I understand the 1000/1024 debate, but my > understanding is that > > KB = 1000 bytes > KiB = 1024 bytes > > (personally, I think the whole kibi-byte thing is stupid, and we should just > say that K=1024 when talking about memory sizes, but whatever) > > I've never seen K=1000 and k=1024. Then why don't we do "mB" instead of MB? > By your logical, M=100 and m=1048576 > Hmm, yes, my bad. http://physics.nist.gov/cuu/Units/prefixes.html lists SI prefixes and "k" = 1000. "m" is milli of course. "K" is not used by SI, so might be free for 1024...? Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] allow print_size to print large numbers on 32-bit systems
On 12/04/10 17:12, Timur Tabi wrote: > On Fri, Apr 9, 2010 at 3:40 PM, Wolfgang Denk wrote: > >> If we make this change, we can probably use this function as well to >> print the size of storage devices like NAND, USB Mass Storage, hard >> disk drives, etc. Eventually we can clean up some pieces of code >> then... > > I'm working on it now. I did notice something odd, though. The > strings for sizes are GB, MB, and kB. Why is the "k" lowercase? > To differentiate from "K", which means 1000, rather than 1024. Example Kg = 1000 grammes. kB = 1024 Bytes Nick ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/1] TI: Davinci: NAND Driver Cleanup
On 16/03/10 18:51, Cyril Chemparathy wrote: > #define davinci_emif_regs \ > - ((struct davinci_emif_regs *)DAVINCI_ASYNC_EMIF_CNTRL_BASE) > + ((struct davinci_emif_regs *)DAVINCI_ASYNC_EMIF_CNTRL_BASE) > + I didn't check, but I would assume checkpatch would complain about the spaces that have crept in here? Can you please restore the original tab? Mainly this would remove these lines from your patch, which cause a small confusion as to what exactly has changed and why. If you haven't already done so, it would be a good idea to run checkpatch to check for any other formatting violations. Other than that, the patch looks good to me. Thanks, Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] TI: Davinci: NAND Driver Cleanup
On 14/03/10 21:14, s-paul...@ti.com wrote:
> From: Cyril Chemparathy
>
> Modified to use IO accessor routines consistently. Eliminated volatile usage
> to keep checkpatch.pl happy.
> Patch was tested on DM355, DM365 and DM6446 EVMs
>
> Signed-off-by: Cyril Chemparathy
> Tested-by: Sandeep Paulraj
> ---
> drivers/mtd/nand/davinci_nand.c | 126
> --
> include/asm-arm/arch-davinci/emif_defs.h | 80 +--
> 2 files changed, 104 insertions(+), 102 deletions(-)
>
> diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
> index bfc2acf..61cba14 100644
> --- a/drivers/mtd/nand/davinci_nand.c
> +++ b/drivers/mtd/nand/davinci_nand.c
> @@ -57,7 +57,8 @@
> #define ECC_STATE_ERR_CORR_COMP_P0x2
> #define ECC_STATE_ERR_CORR_COMP_N0x3
>
> -static emif_registers *const emif_regs = (void *)
> DAVINCI_ASYNC_EMIF_CNTRL_BASE;
> +static struct davinci_emif_regs *emif_regs =
> + (struct davinci_emif_regs *) DAVINCI_ASYNC_EMIF_CNTRL_BASE;
Since this is really just a constant, why setup a variable locally where
ever EMIF registers are accessed? What's wrong with the define you removed
below? ...
> diff --git a/include/asm-arm/arch-davinci/emif_defs.h
> b/include/asm-arm/arch-davinci/emif_defs.h
> index aa57703..3d77bfc 100644
> --- a/include/asm-arm/arch-davinci/emif_defs.h
> +++ b/include/asm-arm/arch-davinci/emif_defs.h
> @@ -24,50 +24,42 @@
>
> #include
>
> -typedef struct davinci_emif_regs {
> - dv_reg ERCSR;
> - dv_reg AWCCR;
> - dv_reg SDBCR;
> - dv_reg SDRCR;
> - dv_reg AB1CR;
> - dv_reg AB2CR;
> - dv_reg AB3CR;
> - dv_reg AB4CR;
> - dv_reg SDTIMR;
> - dv_reg DDRSR;
> - dv_reg DDRPHYCR;
> - dv_reg DDRPHYSR;
> - dv_reg TOTAR;
> - dv_reg TOTACTR;
> - dv_reg DDRPHYID_REV;
> - dv_reg SDSRETR;
> - dv_reg EIRR;
> - dv_reg EIMR;
> - dv_reg EIMSR;
> - dv_reg EIMCR;
> - dv_reg IOCTRLR;
> - dv_reg IOSTATR;
> - u_int8_tRSVD0[8];
> - dv_reg NANDFCR;
> - dv_reg NANDFSR;
> - u_int8_tRSVD1[8];
> - dv_reg NANDFECC[4];
> - u_int8_tRSVD2[60];
> - dv_reg NAND4BITECCLOAD;
> - dv_reg NAND4BITECC1;
> - dv_reg NAND4BITECC2;
> - dv_reg NAND4BITECC3;
> - dv_reg NAND4BITECC4;
> - dv_reg NANDERRADD1;
> - dv_reg NANDERRADD2;
> - dv_reg NANDERRVAL1;
> - dv_reg NANDERRVAL2;
> -} emif_registers;
> -
> -typedef emif_registers *emifregs;
> -
> -#define davinci_emif_regs \
> - ((struct davinci_emif_regs *)DAVINCI_ASYNC_EMIF_CNTRL_BASE)
...This one.
Nick.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] EMAC failure and SPI support for TI DaVinci DM365
On 23/02/10 20:14, Paulraj, Sandeep wrote: > Ian Jeffray wrote: >> I do notice that the "Net: " line above has no further detail, wheras >> the TI PSP binary version says "Ethernet PHY: GENERIC @ 0x00" >> (I've not managed to get a 2009.03 build of my own to run on DM365 >> to compare yet... that's the version TI supplied as binary somehow) > The other issue might be the updates tot eh EMAC driver. The version that > finally was accepted by Ben was submitted by Nick Thompson. It worked fine > for me but I'm not sure if something small was missed. > I tested on da830evm, but only in my private tree. The changes needed by da830 are still filtering up to main (currently in the arm tree). Once it hits main, I will be retesting. In the mean time, I will be following this thread in case there is an issue. Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] da830evm: Add support for TI EMAC
On 09/02/10 16:47, Paulraj, Sandeep wrote: >> Adds support for ethernet networking on the da830evm platform. >> >> This platform uses an SoC EMAC interface and a 3 port ethernet >> switch as a PHY with an RMII interface. The PHY also has a i2c >> interface for configuring the switch functions. >> >> Signed-off-by: Nick Thompson >> --- >> board/davinci/da830evm/da830evm.c| 65 >> +- >> include/asm-arm/arch-davinci/emac_defs.h |1 + >> include/configs/da830evm.h |1 + >> 3 files changed, 65 insertions(+), 2 deletions(-) > > > Did you test this after integrating the EMAC driver patch in your tree? > That patch ack'ed by Ben is not yet in my tree. > > I've not yet done a rebase with wd's tree as most of the TI patches are only > in the ARM tree. Hmm, yes. Maybe it's too early to put this in yet. I have the EMAC patch here as Ben added to his tree, so it is tested correctly, but there is no way it will work for anybody else :( Since I only just submitted, its too early to add this to your tree anyway, but feel free to wait until you tree is updated with the EMAC patch, or else just NAK it and I'll resubmit later. Its a minor point really: the da830 build is not broken by this patch, but its presence implies functionality that doesn't yet work and it might cause undefined behaviour. Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] da830evm: Add support for TI EMAC
Adds support for ethernet networking on the da830evm platform.
This platform uses an SoC EMAC interface and a 3 port ethernet
switch as a PHY with an RMII interface. The PHY also has a i2c
interface for configuring the switch functions.
Signed-off-by: Nick Thompson
---
board/davinci/da830evm/da830evm.c| 65 +-
include/asm-arm/arch-davinci/emac_defs.h |1 +
include/configs/da830evm.h |1 +
3 files changed, 65 insertions(+), 2 deletions(-)
diff --git a/board/davinci/da830evm/da830evm.c
b/board/davinci/da830evm/da830evm.c
index aac5c5c..ed668af 100644
--- a/board/davinci/da830evm/da830evm.c
+++ b/board/davinci/da830evm/da830evm.c
@@ -34,8 +34,11 @@
#include
#include
+#include
+#include
#include
#include
+#include
#include
#include "../common/misc.h"
@@ -69,6 +72,20 @@ static const struct pinmux_config emifa_nand_pins[] = {
{ pinmux[18], 1, 5 },
};
+/* EMAC PHY interface pins */
+static const struct pinmux_config emac_pins[] = {
+ { pinmux[9], 0, 5 },
+ { pinmux[10], 2, 1 },
+ { pinmux[10], 2, 2 },
+ { pinmux[10], 2, 3 },
+ { pinmux[10], 2, 4 },
+ { pinmux[10], 2, 5 },
+ { pinmux[10], 2, 6 },
+ { pinmux[10], 2, 7 },
+ { pinmux[11], 2, 0 },
+ { pinmux[11], 2, 1 },
+};
+
/* UART pin muxer settings */
static const struct pinmux_config uart_pins[] = {
{ pinmux[8], 2, 7 },
@@ -77,8 +94,8 @@ static const struct pinmux_config uart_pins[] = {
/* I2C pin muxer settings */
static const struct pinmux_config i2c_pins[] = {
- { pinmux[9], 2, 3 },
- { pinmux[9], 2, 4 }
+ { pinmux[8], 2, 3 },
+ { pinmux[8], 2, 4 }
};
/* USB0_DRVVBUS pin muxer settings */
@@ -98,6 +115,9 @@ static const struct pinmux_resource pinmuxes[] = {
#ifdef CONFIG_USE_NAND
PINMUX_ITEM(emifa_nand_pins),
#endif
+#if defined(CONFIG_DRIVER_TI_EMAC)
+ PINMUX_ITEM(emac_pins),
+#endif
};
int board_init(void)
@@ -169,3 +189,44 @@ int board_init(void)
return(0);
}
+
+#if defined(CONFIG_DRIVER_TI_EMAC)
+
+#define PHY_SW_I2C_ADDR0x5f /* Address of PHY on i2c bus */
+
+/*
+ * Initializes on-board ethernet controllers.
+ */
+int board_eth_init(bd_t *bis)
+{
+ u_int8_t mac_addr[6];
+ u_int8_t switch_start_cmd[2] = { 0x01, 0x23 };
+
+ /* Read Ethernet MAC address from EEPROM */
+ if (dvevm_read_mac_address(mac_addr))
+ /* set address env if not already set */
+ dv_configure_mac_address(mac_addr);
+
+ /* read the address back from env */
+ if (!eth_getenv_enetaddr("ethaddr", mac_addr))
+ return -1;
+
+ /* provide the resulting addr to the driver */
+ davinci_eth_set_mac_addr(mac_addr);
+
+ /* enable the Ethernet switch in the 3 port PHY */
+ if (i2c_write(PHY_SW_I2C_ADDR, 0, 0,
+ switch_start_cmd, sizeof(switch_start_cmd))) {
+ printf("Ethernet switch start failed!\n");
+ return -1;
+ }
+
+ /* finally, initialise the driver */
+ if (!davinci_emac_initialize()) {
+ printf("Error: Ethernet init failed!\n");
+ return -1;
+ }
+
+ return 0;
+}
+#endif /* CONFIG_DRIVER_TI_EMAC */
diff --git a/include/asm-arm/arch-davinci/emac_defs.h
b/include/asm-arm/arch-davinci/emac_defs.h
index 96bc80e..75b8bf6 100644
--- a/include/asm-arm/arch-davinci/emac_defs.h
+++ b/include/asm-arm/arch-davinci/emac_defs.h
@@ -316,6 +316,7 @@ typedef struct {
int davinci_eth_phy_read(u_int8_t phy_addr, u_int8_t reg_num, u_int16_t *data);
int davinci_eth_phy_write(u_int8_t phy_addr, u_int8_t reg_num, u_int16_t data);
+void davinci_eth_set_mac_addr(const u_int8_t *addr);
typedef struct
{
diff --git a/include/configs/da830evm.h b/include/configs/da830evm.h
index 65747fb..0f58e11 100644
--- a/include/configs/da830evm.h
+++ b/include/configs/da830evm.h
@@ -27,6 +27,7 @@
/*
* Board
*/
+#define CONFIG_DRIVER_TI_EMAC
/*
* SoC Configuration
--
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] da830evm: Add support for TI EMAC
On 09/02/10 16:20, Nick Thompson wrote: > Adds support for ethernet networking on the da830evm platform. > > This platform uses an SoC EMAC interface and a 3 port ethernet > switch as a PHY with an RMII interface. The PHY also has a i2c > interface for configuring the switch functions. > > Signed-off-by: Nick Thompson This patch adds a new warning - sorry missed that during testing A V2 patch is on the way ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] da830evm: Add support for TI EMAC
Adds support for ethernet networking on the da830evm platform.
This platform uses an SoC EMAC interface and a 3 port ethernet
switch as a PHY with an RMII interface. The PHY also has a i2c
interface for configuring the switch functions.
Signed-off-by: Nick Thompson
---
board/davinci/da830evm/da830evm.c| 64 +-
include/asm-arm/arch-davinci/emac_defs.h |1 +
include/configs/da830evm.h |1 +
3 files changed, 64 insertions(+), 2 deletions(-)
diff --git a/board/davinci/da830evm/da830evm.c
b/board/davinci/da830evm/da830evm.c
index aac5c5c..389753c 100644
--- a/board/davinci/da830evm/da830evm.c
+++ b/board/davinci/da830evm/da830evm.c
@@ -34,6 +34,8 @@
#include
#include
+#include
+#include
#include
#include
#include
@@ -69,6 +71,20 @@ static const struct pinmux_config emifa_nand_pins[] = {
{ pinmux[18], 1, 5 },
};
+/* EMAC PHY interface pins */
+static const struct pinmux_config emac_pins[] = {
+ { pinmux[9], 0, 5 },
+ { pinmux[10], 2, 1 },
+ { pinmux[10], 2, 2 },
+ { pinmux[10], 2, 3 },
+ { pinmux[10], 2, 4 },
+ { pinmux[10], 2, 5 },
+ { pinmux[10], 2, 6 },
+ { pinmux[10], 2, 7 },
+ { pinmux[11], 2, 0 },
+ { pinmux[11], 2, 1 },
+};
+
/* UART pin muxer settings */
static const struct pinmux_config uart_pins[] = {
{ pinmux[8], 2, 7 },
@@ -77,8 +93,8 @@ static const struct pinmux_config uart_pins[] = {
/* I2C pin muxer settings */
static const struct pinmux_config i2c_pins[] = {
- { pinmux[9], 2, 3 },
- { pinmux[9], 2, 4 }
+ { pinmux[8], 2, 3 },
+ { pinmux[8], 2, 4 }
};
/* USB0_DRVVBUS pin muxer settings */
@@ -98,6 +114,9 @@ static const struct pinmux_resource pinmuxes[] = {
#ifdef CONFIG_USE_NAND
PINMUX_ITEM(emifa_nand_pins),
#endif
+#if defined(CONFIG_DRIVER_TI_EMAC)
+ PINMUX_ITEM(emac_pins),
+#endif
};
int board_init(void)
@@ -169,3 +188,44 @@ int board_init(void)
return(0);
}
+
+#if defined(CONFIG_DRIVER_TI_EMAC)
+
+#define PHY_SW_I2C_ADDR0x5f /* Address of PHY on i2c bus */
+
+/*
+ * Initializes on-board ethernet controllers.
+ */
+int board_eth_init(bd_t *bis)
+{
+ u_int8_t mac_addr[6];
+ u_int8_t switch_start_cmd[2] = { 0x01, 0x23 };
+
+ /* Read Ethernet MAC address from EEPROM */
+ if (dvevm_read_mac_address(mac_addr))
+ /* set address env if not already set */
+ dv_configure_mac_address(mac_addr);
+
+ /* read the address back from env */
+ if (!eth_getenv_enetaddr("ethaddr", mac_addr))
+ return -1;
+
+ /* provide the resulting addr to the driver */
+ davinci_eth_set_mac_addr(mac_addr);
+
+ /* enable the Ethernet switch in the 3 port PHY */
+ if (i2c_write(PHY_SW_I2C_ADDR, 0, 0,
+ switch_start_cmd, sizeof(switch_start_cmd))) {
+ printf("Ethernet switch start failed!\n");
+ return -1;
+ }
+
+ /* finally, initialise the driver */
+ if (!davinci_emac_initialize()) {
+ printf("Error: Ethernet init failed!\n");
+ return -1;
+ }
+
+ return 0;
+}
+#endif /* CONFIG_DRIVER_TI_EMAC */
diff --git a/include/asm-arm/arch-davinci/emac_defs.h
b/include/asm-arm/arch-davinci/emac_defs.h
index 96bc80e..75b8bf6 100644
--- a/include/asm-arm/arch-davinci/emac_defs.h
+++ b/include/asm-arm/arch-davinci/emac_defs.h
@@ -316,6 +316,7 @@ typedef struct {
int davinci_eth_phy_read(u_int8_t phy_addr, u_int8_t reg_num, u_int16_t *data);
int davinci_eth_phy_write(u_int8_t phy_addr, u_int8_t reg_num, u_int16_t data);
+void davinci_eth_set_mac_addr(const u_int8_t *addr);
typedef struct
{
diff --git a/include/configs/da830evm.h b/include/configs/da830evm.h
index 65747fb..0f58e11 100644
--- a/include/configs/da830evm.h
+++ b/include/configs/da830evm.h
@@ -27,6 +27,7 @@
/*
* Board
*/
+#define CONFIG_DRIVER_TI_EMAC
/*
* SoC Configuration
--
1.6.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] DA830 EVM: Enable NAND support on Spectrum Digital EVM
The EVM UI extender card has a NAND device. This change will enable
saveenv to work with NAND and Linux to be booted using:
mtdparts default
nboot kernel
bootm
Signed-off-by: Nick Thompson
---
board/davinci/da830evm/da830evm.c | 37 +
include/configs/da830evm.h| 21 -
2 files changed, 53 insertions(+), 5 deletions(-)
diff --git a/board/davinci/da830evm/da830evm.c
b/board/davinci/da830evm/da830evm.c
index 12df1f8..aac5c5c 100644
--- a/board/davinci/da830evm/da830evm.c
+++ b/board/davinci/da830evm/da830evm.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include "../common/misc.h"
@@ -51,6 +52,23 @@ static const struct pinmux_config spi0_pins[] = {
{ pinmux[7], 1, 7 }
};
+/* EMIF-A bus pins for 8-bit NAND support on CS3 */
+static const struct pinmux_config emifa_nand_pins[] = {
+ { pinmux[13], 1, 6 },
+ { pinmux[13], 1, 7 },
+ { pinmux[14], 1, 0 },
+ { pinmux[14], 1, 1 },
+ { pinmux[14], 1, 2 },
+ { pinmux[14], 1, 3 },
+ { pinmux[14], 1, 4 },
+ { pinmux[14], 1, 5 },
+ { pinmux[15], 1, 7 },
+ { pinmux[16], 1, 0 },
+ { pinmux[18], 1, 1 },
+ { pinmux[18], 1, 4 },
+ { pinmux[18], 1, 5 },
+};
+
/* UART pin muxer settings */
static const struct pinmux_config uart_pins[] = {
{ pinmux[8], 2, 7 },
@@ -77,6 +95,9 @@ static const struct pinmux_resource pinmuxes[] = {
#ifdef CONFIG_USB_DA8XX
PINMUX_ITEM(usb_pins),
#endif
+#ifdef CONFIG_USE_NAND
+ PINMUX_ITEM(emifa_nand_pins),
+#endif
};
int board_init(void)
@@ -96,6 +117,22 @@ int board_init(void)
writel(0x, &davinci_aintc_regs->ecr3);
#endif
+#ifdef CONFIG_NAND_DAVINCI
+ /* EMIFA 100MHz clock select */
+ writel(readl(&davinci_syscfg_regs->cfgchip3) & ~2,
+ &davinci_syscfg_regs->cfgchip3);
+ /* NAND CS setup */
+ writel((DAVINCI_ABCR_WSETUP(0) |
+ DAVINCI_ABCR_WSTROBE(2) |
+ DAVINCI_ABCR_WHOLD(0) |
+ DAVINCI_ABCR_RSETUP(0) |
+ DAVINCI_ABCR_RSTROBE(2) |
+ DAVINCI_ABCR_RHOLD(0) |
+ DAVINCI_ABCR_TA(2) |
+ DAVINCI_ABCR_ASIZE_8BIT),
+ &davinci_emif_regs->AB2CR);
+#endif
+
/* arch number of the board */
gd->bd->bi_arch_number = MACH_TYPE_DAVINCI_DA830_EVM;
diff --git a/include/configs/da830evm.h b/include/configs/da830evm.h
index 432cd57..65747fb 100644
--- a/include/configs/da830evm.h
+++ b/include/configs/da830evm.h
@@ -103,14 +103,15 @@
#define CONFIG_NAND_DAVINCI
#define CONFIG_SYS_NO_FLASH
#define CONFIG_ENV_IS_IN_NAND /* U-Boot env in NAND Flash */
-#define CONFIG_ENV_OFFSET 0x0 /* Block 0--not used by bootcode */
-#define CONFIG_ENV_SIZE(128 << 10)
+#define CONFIG_ENV_OFFSET (512 << 10)
+#define CONFIG_ENV_SIZE(512 << 10)
#define CONFIG_SYS_NAND_4BIT_HW_ECC_OOBFIRST
#define CONFIG_SYS_NAND_CS 3
#define CONFIG_SYS_NAND_BASE DAVINCI_ASYNC_EMIF_DATA_CE3_BASE
+#define CONFIG_SYS_NAND_PAGE_2K
+#define CONFIG_SYS_64BIT_VSPRINTF /* needed for nand_util.c */
#define CONFIG_SYS_CLE_MASK0x10
#define CONFIG_SYS_ALE_MASK0x8
-#define CONFIG_SYS_NAND_HW_ECC
#define CONFIG_SYS_MAX_NAND_DEVICE 1 /* Max number of NAND devices */
#define NAND_MAX_CHIPS 1
#define DEF_BOOTM ""
@@ -216,8 +217,7 @@
#define CONFIG_CMD_NAND
#define CONFIG_CMD_MTDPARTS
#define CONFIG_MTD_PARTITIONS
-#define CONFIG_CMD_UBI
-#define CONFIG_RBTREE
+#define CONFIG_MTD_DEVICE
#endif
#ifdef CONFIG_USE_SPIFLASH
@@ -268,4 +268,15 @@
#endif /* CONFIG_MUSB_UDC */
#endif /* CONFIG_USB_DA8XX */
+
+#ifdef CONFIG_MTD_PARTITIONS
+#define MTDIDS_DEFAULT "nand0=davinci_nand.1"
+#define PART_BOOT "512k(bootloader)ro,"
+#define PART_PARAMS"512k(params)ro,"
+#define PART_KERNEL"4m(kernel),"
+#define PART_REST "-(filesystem)"
+#define MTDPARTS_DEFAULT\
+ "mtdparts=davinci_nand.1:" PART_BOOT PART_PARAMS PART_KERNEL PART_REST
+#endif
+
#endif /* __CONFIG_H */
--
1.6.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] Davinci: Add EMIF-A macros for setting chip select parameters
Signed-off-by: Nick Thompson
---
include/asm-arm/arch-davinci/emif_defs.h | 18 +-
1 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/include/asm-arm/arch-davinci/emif_defs.h
b/include/asm-arm/arch-davinci/emif_defs.h
index 8fd4e01..aa57703 100644
--- a/include/asm-arm/arch-davinci/emif_defs.h
+++ b/include/asm-arm/arch-davinci/emif_defs.h
@@ -24,7 +24,7 @@
#include
-typedef struct {
+typedef struct davinci_emif_regs {
dv_reg ERCSR;
dv_reg AWCCR;
dv_reg SDBCR;
@@ -66,6 +66,9 @@ typedef struct {
typedef emif_registers *emifregs;
+#define davinci_emif_regs \
+ ((struct davinci_emif_regs *)DAVINCI_ASYNC_EMIF_CNTRL_BASE)
+
#define DAVINCI_NANDFCR_NAND_ENABLE(n) (1 << (n-2))
#define DAVINCI_NANDFCR_4BIT_ECC_SEL_MASK (3 << 4)
#define DAVINCI_NANDFCR_4BIT_ECC_SEL(n)((n-2) << 4)
@@ -73,4 +76,17 @@ typedef emif_registers *emifregs;
#define DAVINCI_NANDFCR_4BIT_ECC_START (1 << 12)
#define DAVINCI_NANDFCR_4BIT_CALC_START(1 << 13)
+/* Chip Select setup */
+#define DAVINCI_ABCR_STROBE_SELECT (1 << 31)
+#define DAVINCI_ABCR_EXT_WAIT (1 << 30)
+#define DAVINCI_ABCR_WSETUP(n) (n << 26)
+#define DAVINCI_ABCR_WSTROBE(n)(n << 20)
+#define DAVINCI_ABCR_WHOLD(n) (n << 17)
+#define DAVINCI_ABCR_RSETUP(n) (n << 13)
+#define DAVINCI_ABCR_RSTROBE(n)(n << 7)
+#define DAVINCI_ABCR_RHOLD(n) (n << 4)
+#define DAVINCI_ABCR_TA(n) (n << 2)
+#define DAVINCI_ABCR_ASIZE_16BIT 1
+#define DAVINCI_ABCR_ASIZE_8BIT0
+
#endif
--
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 RFC 0/2] dcache on ARM
On 26/01/10 16:16, Alessandro Rubini wrote: > These patches enable the dcache for ARM9. It's mainly an RFC, as some > details are still to be sorted out, but they work fine (and the speed > increase is noticeable for kernel boots and cp.b -- didn't make more > tests. I'm all for speed increases :-) On TI DA830, the 1.0 & 1.1 revision of the silicon have a data caching bug. You can use data caching, but only in write thru' mode. This is fixed in the very latest 2.0 silicon. Even still it is better than no caching as proved in Linux. Is it simple for you to enable different levels of caching by config? Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Patch status update
On 25/01/10 22:44, Wolfgang Denk wrote: > 5369 12/08 Nick Thompson [U-Boot] [PATCH RFC] NAND: Improve read > performance from Large Page NAND devices > http://article.gmane.org/gmane.comp.boot-loaders.u-boot/72491 This one is not ready yet, some other drivers need updating. > 5446 12/10 Nick Thompson [U-Boot] [PATCH] da830evm: Use table driven > pin mux configuration > http://article.gmane.org/gmane.comp.boot-loaders.u-boot/72566 Obsoleted by a v2 patch below. > 5809 12/18 Nick Thompson [U-Boot] [PATCH v3] TI: DaVinci: Updating > EMAC driver for DM365, DM646x and DA8XX > http://article.gmane.org/gmane.comp.boot-loaders.u-boot/72929 Ben has said today that he is picking this one up. > 6783 01/18 Nick Thompson [U-Boot] [PATCH v2] da830evm: Use table > driven pin mux configuration > http://article.gmane.org/gmane.comp.boot-loaders.u-boot/73933 This was applied to u-boot-ti a few days ago. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot fails to read from nand flash in omap3
On 19/01/10 08:21, fgd wrote:
>
> Hi everyone,
> I've recently been playing with an omap3 beagle board and I've found a
> problem that I think involves the reading of nand memory...
> I have recompiled u-boot for the beagle board (I just changed its prompt, as
> a simple test to check that it's my u-boot and not the one that was there
> before, and I used the default configs for the beagle), then I have loaded
> u-boot and the x-loader into flash, and I have succesfully rebooted and seen
> 'my' u-boot prompt...
> after that, I wanted to load a linux kernel and a file system into nand
> flash, instead of using the external memory card (if I boot a kernel stored
> there, it works), so I go and load an uImage into flash, then read it back
> to RAM, and boot from there, and it still works, BUT, as soon as I reset the
Maybe you do this after running Linux and Linux has configured the SoC
to access the NAND? Can you use u-boot to write to NAND after a reset, but
before Linux boots?
> OMAP, when it tries to copy the kernel data stored in flash into RAM to boot
> from it, the nand reading operation will fail, and if I try to boot that
> kernel it will complain about a CRC checksum error...
After a reset, I guess your UBL (and u-boot) is not enabling NAND accesses?
I added some code to the Davinci nand driver to fix a similar issue on that
arch.
> the exact error looks like this:
> # nand read ${loadaddr} 28 40
u-boot's nboot command can read the uImage header and copy from NAND only the
required amount of data. It only copies to RAM, so you still need to bootm...
>
> NAND read: device 0 offset 0x28, size 0x40
> NAND read from offset 28 failed -74
>
> note that this just happens after I reset the board... I thought it could be
> a hardware problem with my board, but I've tried in a different board (an
> omap3 evm) and I'm getting the same thing, so I think I might be missing
> something...
> has anyone of you tried something like this or has encountered any similar
> problem? any help will be greatly appreciated, if you need any extra info
> about what I have done just tell me...
> thanks a lot in advance, regards
>
> Fernando
Nick
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] da830evm: Use table driven pin mux configuration
Tidyup the pin muxer configuration using the Davinci table driven
pinmux configuration function and data tables.
Signed-off-by: Nick Thompson
---
Applies to master
Changes:
Rebased after USB patch
board/davinci/da830evm/da830evm.c | 35 +--
1 files changed, 17 insertions(+), 18 deletions(-)
diff --git a/board/davinci/da830evm/da830evm.c
b/board/davinci/da830evm/da830evm.c
index 7cf6013..12df1f8 100644
--- a/board/davinci/da830evm/da830evm.c
+++ b/board/davinci/da830evm/da830evm.c
@@ -42,34 +42,43 @@ DECLARE_GLOBAL_DATA_PTR;
#define pinmux &davinci_syscfg_regs->pinmux
-#ifdef CONFIG_SPI_FLASH
/* SPI0 pin muxer settings */
-const struct pinmux_config spi0_pins[] = {
+static const struct pinmux_config spi0_pins[] = {
{ pinmux[7], 1, 3 },
{ pinmux[7], 1, 4 },
{ pinmux[7], 1, 5 },
{ pinmux[7], 1, 6 },
{ pinmux[7], 1, 7 }
};
-#endif
/* UART pin muxer settings */
-const struct pinmux_config uart_pins[] = {
+static const struct pinmux_config uart_pins[] = {
{ pinmux[8], 2, 7 },
{ pinmux[9], 2, 0 }
};
/* I2C pin muxer settings */
-const struct pinmux_config i2c_pins[] = {
+static const struct pinmux_config i2c_pins[] = {
{ pinmux[9], 2, 3 },
{ pinmux[9], 2, 4 }
};
/* USB0_DRVVBUS pin muxer settings */
-const struct pinmux_config usb_pins[] = {
+static const struct pinmux_config usb_pins[] = {
{ pinmux[9], 1, 1 }
};
+static const struct pinmux_resource pinmuxes[] = {
+#ifdef CONFIG_SPI_FLASH
+ PINMUX_ITEM(spi0_pins),
+#endif
+ PINMUX_ITEM(uart_pins),
+ PINMUX_ITEM(i2c_pins),
+#ifdef CONFIG_USB_DA8XX
+ PINMUX_ITEM(usb_pins),
+#endif
+};
+
int board_init(void)
{
#ifndef CONFIG_USE_IRQ
@@ -112,18 +121,8 @@ int board_init(void)
DAVINCI_SYSCFG_SUSPSRC_UART2),
&davinci_syscfg_regs->suspsrc);
-#ifdef CONFIG_SPI_FLASH
- if (davinci_configure_pin_mux(spi0_pins, ARRAY_SIZE(spi0_pins)) != 0)
- return 1;
-#endif
-
- if (davinci_configure_pin_mux(uart_pins, ARRAY_SIZE(uart_pins)) != 0)
- return 1;
-
- if (davinci_configure_pin_mux(i2c_pins, ARRAY_SIZE(i2c_pins)) != 0)
- return 1;
-
- if (davinci_configure_pin_mux(usb_pins, ARRAY_SIZE(usb_pins)) != 0)
+ /* configure pinmux settings */
+ if (davinci_configure_pin_mux_items(pinmuxes, ARRAY_SIZE(pinmuxes)))
return 1;
/* enable the console UART */
--
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 RFC] NAND: Improve read performance from Large Page NAND devices
On 16/01/10 01:51, Josh Gelinske wrote: > > What kind of CPU usage are you seeing? I am throughput of ~1.9MBs for writes > on a Samsung K9WBG08U1M 4GB with 4K page but with high cpu usage. > I'm not sure what you are asking here. There is no idle loop to measure so CPU is running at 100%. The code does poll the NAND device for data ready, but in my case the NAND loads its cache faster than the CPU can finish sorting out ECC checks (despite ECC H/W assistance). The result is the CPU never actually on the NAND. This patch (not yet formally submitted) removes this potential waiting time that was present - plus some redundant command sequences due to incorrect function levelling. Most of my performance gain comes from optimising the data transfer (to and) from the NAND - see drivers/mtd/nand/davinci_nand.c - which is already in the mainline. Apologies if that doesn't answer your question. Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] TI DaVinci: Driver for the davinci SPI controller
On 05/01/10 04:47, Sudhakar Rajashekhara wrote: > From: Sekhar Nori > > This adds a driver for the SPI controller found on davinci > based SoCs from Texas Instruments. > > Signed-off-by: Sekhar Nori > Signed-off-by: Sudhakar Rajashekhara > --- > From the previous version following have been modified: > 1. Sorted the entries in drivers/spi/Makefile alphabetically. > 2. Implemented dummy functions for spi_cs_is_valid(), > spi_cs_activate() and spi_cs_deactivate(). > 3. Added GPL header for drivers/spi/davinci_spi.h file. > 4. Added protection against multiple inclusion of SPI header > file. > 5. Replaced the macro based register offsets in SPI header > file with structure. > 6. Replaced the spi_readl and spi_writel functions with > readl and writel respectively. > > drivers/spi/Makefile |1 + > drivers/spi/davinci_spi.c | 221 > > drivers/spi/davinci_spi.h | 102 > include/configs/da830evm.h |2 +- No sign of this file in the patch set. Is this intentional? > 4 files changed, 325 insertions(+), 1 deletions(-) > create mode 100644 drivers/spi/davinci_spi.c > create mode 100644 drivers/spi/davinci_spi.h ... > diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c > new file mode 100644 > index 000..c3f1810 > --- /dev/null > +++ b/drivers/spi/davinci_spi.c > @@ -0,0 +1,221 @@ ... > + > + /* CS, CLK, SIMO and SOMI are functional pins */ > + writel((SPIPC0_EN0FUN_MASK) | (SPIPC0_CLKFUN_MASK) | > + (SPIPC0_DOFUN_MASK) | (SPIPC0_DIFUN_MASK), &ds->regs->pc0); There seem to be numerous cases, here and elsewhere in the file where bare defines are referenced within parenthesis for no obvious reason. If they are needed they should be in the #define statement. I think in all cases they are, so the above lines should be something like... /* CS, CLK, SIMO and SOMI are functional pins */ writel((SPIPC0_EN0FUN_MASK | SPIPC0_CLKFUN_MASK | SPIPC0_DOFUN_MASK | SPIPC0_DIFUN_MASK), &ds->regs->pc0); ...which also corrects the alignment of the last line. Regards, Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] TI DaVinci: Driver for the davinci SPI controller
On 23/12/09 07:44, Sudhakar Rajashekhara wrote:
> From: Sekhar Nori
>
> This adds a driver for the SPI controller found on davinci
> based SoCs from Texas Instruments.
>
> Signed-off-by: Sekhar Nori
> Signed-off-by: Sudhakar Rajashekhara
> ---
> drivers/spi/Makefile |1 +
> drivers/spi/davinci_spi.c | 205
> +
> drivers/spi/davinci_spi.h | 84 ++
> 3 files changed, 290 insertions(+), 0 deletions(-)
> create mode 100644 drivers/spi/davinci_spi.c
> create mode 100644 drivers/spi/davinci_spi.h
...
> diff --git a/drivers/spi/davinci_spi.h b/drivers/spi/davinci_spi.h
> new file mode 100644
> index 000..b3bf916
> --- /dev/null
> +++ b/drivers/spi/davinci_spi.h
> @@ -0,0 +1,84 @@
> +/*
> + * Register definitions for the DaVinci SPI Controller
> + */
> +
> +/* Register offsets */
> +#define DAVINCI_SPI_GCR0 0x
> +#define DAVINCI_SPI_GCR1 0x0004
> +#define DAVINCI_SPI_INT0 0x0008
> +#define DAVINCI_SPI_LVL 0x000c
> +#define DAVINCI_SPI_FLG 0x0010
> +#define DAVINCI_SPI_PC0 0x0014
> +#define DAVINCI_SPI_PC1 0x0018
> +#define DAVINCI_SPI_PC2 0x001c
> +#define DAVINCI_SPI_PC3 0x0020
> +#define DAVINCI_SPI_PC4 0x0024
> +#define DAVINCI_SPI_PC5 0x0028
> +#define DAVINCI_SPI_DAT0 0x0038
> +#define DAVINCI_SPI_DAT1 0x003c
> +#define DAVINCI_SPI_BUF 0x0040
> +#define DAVINCI_SPI_EMU 0x0044
> +#define DAVINCI_SPI_DELAY0x0048
> +#define DAVINCI_SPI_DEF 0x004c
> +#define DAVINCI_SPI_FMT0 0x0050
> +#define DAVINCI_SPI_FMT1 0x0054
> +#define DAVINCI_SPI_FMT2 0x0058
> +#define DAVINCI_SPI_FMT3 0x005c
> +#define DAVINCI_SPI_INTVEC0 0x0060
> +#define DAVINCI_SPI_INTVEC1 0x0064
I think this ought to be a C structure, rather than register offsets?
...
> +
> +struct davinci_spi_slave {
> + struct spi_slave slave;
> + void*regs;
This should have the type of the C structure to be defined above.
> + u32 mr;
> + unsigned int freq;
> +};
> +
...
> +
> +#define spi_readl(ds, reg) \
> + readl(ds->regs + DAVINCI_SPI_##reg)
> +#define spi_writel(ds, reg, value) \
> + writel(value, ds->regs + DAVINCI_SPI_##reg)
These can be rewritten (and the usages changed slightly) to access via the
structure.
You will then not be circumventing any type checking.
Maybe these defs then become too trivial and can be dropped altogether?
Regards,
Nick.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] Add board specific code for da850 EVM
On 18/12/09 10:23, Sudhakar Rajashekhar wrote: > Nick Thompson ge.com> writes: > >> >> On 16/12/09 10:24, Sudhakar Rajashekhara wrote: >>> Provides initial support for TI OMAP-L138/DA850 SoC devices on >>> a Logic PD EVM board. >>> >>> Provides: >>> Initial boot and configuration. >>> Support for i2c. >>> UART support (console). >>> >>> Signed-off-by: Sudhakar Rajashekhara ti.com> >>> --- >>> board/davinci/da8xxevm/Makefile |1 + >>> board/davinci/da8xxevm/da850evm.c | 124 > +++ >>> include/asm-arm/arch-davinci/hardware.h |1 + >>> 3 files changed, 126 insertions(+), 0 deletions(-) >>> create mode 100644 board/davinci/da8xxevm/da850evm.c >>> >> >> [...] >> >>> diff --git a/board/davinci/da8xxevm/da850evm.c > b/board/davinci/da8xxevm/da850evm.c >>> new file mode 100644 >>> index 000..92548e2 >>> --- /dev/null >>> +++ b/board/davinci/da8xxevm/da850evm.c >>> @@ -0,0 +1,124 @@ >>> +/* >>> + * (C) Copyright 2009, Texas Instruments, Inc. http://www.ti.com/ >>> + * >>> + * Based on da830evm.c >> >> At this point, this seem to be a copy of da830evm.c (well except the first > few lines above). >> > > I don't think you have observed that the PINMUX registers are different on > da850. So we are at risk of adding many ifdefs now itself if we combine da830 > and da850. Also, there are few things which differ between da830 and da850, > for > example, MAC address is stored in I2C eeprom on da830 and in SPI eeprom on > da850. You can have a look at http://www.arago-project.org/git/people/? > p=sekhar/u-boot-omapl1.git;a=summary to understand how the da830 and da850 > files look later when support for most peripherals are added. > > To avoid code cluttering, I prefer using two separate files for da830 and > da850. Yes, the pinmux table definitions are different, but I don't see how this requires duplicating code. In the latest patches for da830, the pinmux setup is table driven. It would be very simple to pull out the two tables into da830 and da850 specific files (selected by the build system) and use common pinmux code to setup the pins appropriately. The code part for this is simply: /* configure pinmux settings */ if (davinci_configure_pin_mux_items(pinmuxes, ARRAY_SIZE(pinmuxes))) return 1; That would be exactly the same line of code for both devices. It should be possible to put i2c (da830) and spi (da850) equivalent functions into that same file to read the MAC address. Abstractions of this form are also likely to make the code more readable. [In fact the function is already abstracted into misc.c, but it only provides for i2c currently] There might be an issue with functions supported on one platform that are not supported on the other, but these could also be abstracted out. They also ought to be few because of the similarities of the devices. Not doing so puts us at risk of increasing commmits and maintenance. There is no need to clutter the code - it can be layered and abstracted to handle differences cleanly. Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] TI: DaVinci: Updating EMAC driver for DM365, DM646x and DA8XX
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
---
v2 was messed up, these changes are relative to the original patch
CHANGES:
Move ;'s from the end of all empty while loops to next line.
Gig enable function has no ifdefs on body.
Gig enable doesn't change the ET1011C PHY SYSCLK reg as this
is board specific (to the DM6467 HD EVM).
All struct register overlay accesses now use writel/readl.
MDIO startup delay is not specific to emac_v2.
Fixed some over-long lines and bad indents.
UNCHANGED:
Gig enable called whenever phy link is checked since link
may have dropped out and come back. I can't test
if removing these calls is acceptable.
Legacy register definitions are uppercase - new definitions
are lowercase.
drivers/net/davinci_emac.c | 266 +++---
include/asm-arm/arch-davinci/emac_defs.h | 59 ++-
2 files changed, 226 insertions(+), 99 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index fa8cee4..02bbb8c 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -42,10 +42,17 @@
#include
#include
#include
+#include
unsigned int emac_dbg = 0;
#define debug_emac(fmt,args...)if (emac_dbg) printf(fmt,##args)
+#ifdef DAVINCI_EMAC_GIG_ENABLE
+#define emac_gigabit_enable() davinci_eth_gigabit_enable()
+#else
+#define emac_gigabit_enable() /* no gigabit to enable */
+#endif
+
static void davinci_eth_mdio_enable(void);
static int gen_init_phy(int phy_addr);
@@ -99,12 +106,14 @@ static void davinci_eth_mdio_enable(void)
clkdiv = (EMAC_MDIO_BUS_FREQ / EMAC_MDIO_CLOCK_FREQ) - 1;
- adap_mdio->CONTROL = (clkdiv & 0xff) |
- MDIO_CONTROL_ENABLE |
- MDIO_CONTROL_FAULT |
- MDIO_CONTROL_FAULT_ENABLE;
+ writel((clkdiv & 0xff) |
+ MDIO_CONTROL_ENABLE |
+ MDIO_CONTROL_FAULT |
+ MDIO_CONTROL_FAULT_ENABLE,
+ &adap_mdio->CONTROL);
- while (adap_mdio->CONTROL & MDIO_CONTROL_IDLE) {;}
+ while (readl(&adap_mdio->CONTROL) & MDIO_CONTROL_IDLE)
+ ;
}
/*
@@ -119,7 +128,8 @@ static int davinci_eth_phy_detect(void)
active_phy_addr = 0xff;
- if ((phy_act_state = adap_mdio->ALIVE) == 0)
+ phy_act_state = readl(&adap_mdio->ALIVE) & EMAC_MDIO_PHY_MASK;
+ if (phy_act_state == 0)
return(0); /* No active PHYs */
debug_emac("davinci_eth_phy_detect(), ALIVE = 0x%08x\n", phy_act_state);
@@ -144,15 +154,18 @@ int davinci_eth_phy_read(u_int8_t phy_addr, u_int8_t
reg_num, u_int16_t *data)
{
int tmp;
- while (adap_mdio->USERACCESS0 & MDIO_USERACCESS0_GO) {;}
+ while (readl(&adap_mdio->USERACCESS0) & MDIO_USERACCESS0_GO)
+ ;
- adap_mdio->USERACCESS0 = MDIO_USERACCESS0_GO |
- MDIO_USERACCESS0_WRITE_READ |
- ((reg_num & 0x1f) << 21) |
- ((phy_addr & 0x1f) << 16);
+ writel(MDIO_USERACCESS0_GO |
+ MDIO_USERACCESS0_WRITE_READ |
+ ((reg_num & 0x1f) << 21) |
+ ((phy_addr & 0x1f) << 16),
+ &adap_mdio->USERACCESS0);
/* Wait for command to complete */
- while ((tmp = adap_mdio->USERACCESS0) & MDIO_USERACCESS0_GO) {;}
+ while ((tmp = readl(&adap_mdio->USERACCESS0)) & MDIO_USERACCESS0_GO)
+ ;
if (tmp & MDIO_USERACCESS0_ACK) {
*data = tmp & 0x;
@@ -167,16 +180,19 @@ int davinci_eth_phy_read(u_int8_t phy_addr, u_int8_t
reg_num, u_int16_t *data)
int davinci_eth_phy_write(u_int8_t phy_addr, u_int8_t reg_num, u_int16_t data)
{
- while (adap_mdio->USERACCESS0 & MDIO_USERACCESS0_GO) {;}
+ while (readl(&adap_mdio->USERACCESS0) & MDIO_USERACCESS0_GO)
+ ;
- adap_mdio->USERACCESS0 = MDIO_USERACCESS0_GO |
- MDIO_USERACCESS0_WRITE_WRITE |
- ((reg_num & 0x1f) << 21) |
- ((phy_addr & 0x1f) << 16) |
- (data & 0x);
+ writel(MDIO_USERACCESS0_GO |
+ MDIO_USERACCESS0_WRITE_WRITE |
+ ((reg_num & 0x1f) << 21) |
+ ((phy_addr & 0x1f) << 16) |
+ (data & 0x),
+ &adap_mdio->USERACCESS0);
Re: [U-Boot] [PATCH v2] TI: DaVinci: Updating EMAC driver for DM365, DM646x and DA8XX
On 18/12/09 12:57, Nick Thompson wrote: > 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. Please ignore this patch... The patch is incorrectly formatted due to an e-mail issue. v3 will be posted shortly. Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] TI: DaVinci: Updating EMAC driver for DM365, DM646x and DA8XX
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
---
CHANGES:
Move ;'s from the end of all empty while loops to next line.
Gig enable function has no ifdefs on body.
Gig enable doesn't change the ET1011C PHY SYSCLK reg as this
is board specific (to the DM6467 HD EVM).
All struct register overlay accesses now use writel/readl.
MDIO startup delay is not specific to emac_v2
UNCHANGED:
Gig enable called whenever phy link is checked since link
may have dropped out and come back. I can't test
if removing these calls is acceptable.
Legacy register definitions are uppercase - new definitions
are lowercase.
drivers/net/davinci_emac.c | 226 +++---
include/asm-arm/arch-davinci/emac_defs.h | 59 +++-
2 files changed, 202 insertions(+), 83 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index fa8cee4..4c3b185 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -42,10 +42,17 @@
#include
#include
#include
+#include
unsigned int emac_dbg = 0;
#define debug_emac(fmt,args...)if (emac_dbg) printf(fmt,##args)
+#ifdef DAVINCI_EMAC_GIG_ENABLE
+#define emac_gigabit_enable() davinci_eth_gigabit_enable()
+#else
+#define emac_gigabit_enable() /* no gigabit to enable */
+#endif
+
static void davinci_eth_mdio_enable(void);
static int gen_init_phy(int phy_addr);
@@ -99,12 +106,14 @@ static void davinci_eth_mdio_enable(void)
clkdiv = (EMAC_MDIO_BUS_FREQ / EMAC_MDIO_CLOCK_FREQ) - 1;
- adap_mdio->CONTROL = (clkdiv & 0xff) |
- MDIO_CONTROL_ENABLE |
- MDIO_CONTROL_FAULT |
- MDIO_CONTROL_FAULT_ENABLE;
+ writel((clkdiv & 0xff) |
+ MDIO_CONTROL_ENABLE |
+ MDIO_CONTROL_FAULT |
+ MDIO_CONTROL_FAULT_ENABLE,
+ &adap_mdio->CONTROL);
- while (adap_mdio->CONTROL & MDIO_CONTROL_IDLE) {;}
+ while (readl(&adap_mdio->CONTROL) & MDIO_CONTROL_IDLE)
+ ;
}
/*
@@ -119,7 +128,8 @@ static int davinci_eth_phy_detect(void)
active_phy_addr = 0xff;
- if ((phy_act_state = adap_mdio->ALIVE) == 0)
+ phy_act_state = readl(&adap_mdio->ALIVE) & EMAC_MDIO_PHY_MASK;
+ if (phy_act_state == 0)
return(0); /* No active PHYs */
debug_emac("davinci_eth_phy_detect(), ALIVE = 0x%08x\n", phy_act_state);
@@ -144,15 +154,18 @@ int davinci_eth_phy_read(u_int8_t phy_addr, u_int8_t
reg_num, u_int16_t *data)
{
int tmp;
- while (adap_mdio->USERACCESS0 & MDIO_USERACCESS0_GO) {;}
+ while (readl(&adap_mdio->USERACCESS0) & MDIO_USERACCESS0_GO)
+ ;
- adap_mdio->USERACCESS0 = MDIO_USERACCESS0_GO |
- MDIO_USERACCESS0_WRITE_READ |
- ((reg_num & 0x1f) << 21) |
- ((phy_addr & 0x1f) << 16);
+ writel(MDIO_USERACCESS0_GO |
+ MDIO_USERACCESS0_WRITE_READ |
+ ((reg_num & 0x1f) << 21) |
+ ((phy_addr & 0x1f) << 16),
+ &adap_mdio->USERACCESS0);
/* Wait for command to complete */
- while ((tmp = adap_mdio->USERACCESS0) & MDIO_USERACCESS0_GO) {;}
+ while ((tmp = readl(&adap_mdio->USERACCESS0)) & MDIO_USERACCESS0_GO)
+ ;
if (tmp & MDIO_USERACCESS0_ACK) {
*data = tmp & 0x;
@@ -167,16 +180,19 @@ int davinci_eth_phy_read(u_int8_t phy_addr, u_int8_t
reg_num, u_int16_t *data)
int davinci_eth_phy_write(u_int8_t phy_addr, u_int8_t reg_num, u_int16_t data)
{
- while (adap_mdio->USERACCESS0 & MDIO_USERACCESS0_GO) {;}
+ while (readl(&adap_mdio->USERACCESS0) & MDIO_USERACCESS0_GO)
+ ;
- adap_mdio->USERACCESS0 = MDIO_USERACCESS0_GO |
- MDIO_USERACCESS0_WRITE_WRITE |
- ((reg_num & 0x1f) << 21) |
- ((phy_addr & 0x1f) << 16) |
- (data & 0x);
+ writel(MDIO_USERACCESS0_GO |
+ MDIO_USERACCESS0_WRITE_WRITE |
+ ((reg_num & 0x1f) << 21) |
+ ((phy_addr & 0x1f) << 16) |
+ (data & 0x),
+ &adap_mdio->USERACCESS0);
/* Wait for command to complete */
- while (adap_mdio->USERACCESS0 & MDIO_USERACCESS0_GO) {;}
+ while (readl(&a
Re: [U-Boot] [PATCH] TI: DaVinci: Updating EMAC driver for DM365, DM646x and DA8XX
On 16/12/09 22:00, Wolfgang Denk wrote:
> Dear Nick Thompson,
>
> In message <4b2770f8.5090...@ge.com> you wrote:
>> 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 with Sandeep's DM365 and DM646x changes
>> and additional changes for DA830. It replaces previous submissions
>> for EMAC support on these devices.
>>
>> drivers/net/davinci_emac.c | 131
>> -
>> include/asm-arm/arch-davinci/emac_defs.h | 60 +-
>> 2 files changed, 164 insertions(+), 27 deletions(-)
>>
>> diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
>> index fa8cee4..dbf94d2 100644
>> --- a/drivers/net/davinci_emac.c
>> +++ b/drivers/net/davinci_emac.c
>> @@ -42,6 +42,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> unsigned intemac_dbg = 0;
>> #define debug_emac(fmt,args...) if (emac_dbg) printf(fmt,##args)
>> @@ -107,6 +108,35 @@ static void davinci_eth_mdio_enable(void)
>> while (adap_mdio->CONTROL & MDIO_CONTROL_IDLE) {;}
>
> Please fix this as well while we are here. Please make this:
>
> while (adap_mdio->CONTROL & MDIO_CONTROL_IDLE)
> ;
Yes, will do, here and elsewhere in the file. I will also change
all these cases to use readl().
>
>
>> +/* Wait for command to complete */
>> +while (readl(&adap_mdio->USERACCESS0) & MDIO_USERACCESS0_GO);
>
> Please make this:
>
> while (readl(&adap_mdio->USERACCESS0) & MDIO_USERACCESS0_GO)
> ;
Done.
>
>
>> +static void emac_gigabit_enable(void)
>> +{
>> +#ifdef DAVINCI_EMAC_GIG_ENABLE
>> +int temp
>> +
>> +if (mdio_read(EMAC_MDIO_PHY_NUM, 0) & (1 << 6)) {
>> +/*
>> + * Check if link detected is giga-bit
>> + * If Gigabit mode detected, enable gigbit in MAC and PHY
>> + */
>> +writel(EMAC_MACCONTROL_GIGFORCE |
>> + EMAC_MACCONTROL_GIGABIT_ENABLE,
>> + &adap_emac->MACCONTROL);
>> +
>> +/*
>> + * The SYS_CLK which feeds the SOC for giga-bit operation
>> + * does not seem to be enabled after reset as expected.
>> + * Force enabling SYS_CLK by writing to the PHY
>> + */
>> +temp = mdio_read(EMAC_MDIO_PHY_NUM, 22);
>> +temp |= (1 << 4);
>> +mdio_write(EMAC_MDIO_PHY_NUM, 22, temp);
>> +}
>> +#endif
>> +}
>
> Can we - instead of providing an empty function when
> DAVINCI_EMAC_GIG_ENABLE is not set - either omit this function
> completely, or use a weak implementation instead?
I don't want to use weak as it implies the function maybe replaced. This is
not the intention here. To avoid ifdefs all over the place I have added:
#ifdef DAVINCI_EMAC_GIG_ENABLE
#define mdio_gigabit_detect(phy)(mdio_read(phy, 0) & (1 << 6))
#else
#define mdio_gigabit_detect(phy)0
#endif
and changed the if in the above function to:
if (mdio_gigabit_detect(EMAC_MDIO_PHY_NUM)) {
int temp;
...
The function is always present, but optimised away if there is a 0 method for
detecting gigabit in the phy. Is that acceptable?
>
>> if (!phy.get_link_speed(active_phy_addr))
>> return(0);
>> +else
>> +emac_gigabit_enable();
>
> No "else" is needed here. Remove it, and un-indent the
> emac_gigabit_enable() call.
Ahh yes - removed in all three cases.
I will submit a new patch tomorrow.
Thanks,
Nick.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] Add board specific code for da850 EVM
On 16/12/09 10:24, Sudhakar Rajashekhara wrote: > Provides initial support for TI OMAP-L138/DA850 SoC devices on > a Logic PD EVM board. > > Provides: > Initial boot and configuration. > Support for i2c. > UART support (console). > > Signed-off-by: Sudhakar Rajashekhara > --- > board/davinci/da8xxevm/Makefile |1 + > board/davinci/da8xxevm/da850evm.c | 124 > +++ > include/asm-arm/arch-davinci/hardware.h |1 + > 3 files changed, 126 insertions(+), 0 deletions(-) > create mode 100644 board/davinci/da8xxevm/da850evm.c > [...] > diff --git a/board/davinci/da8xxevm/da850evm.c > b/board/davinci/da8xxevm/da850evm.c > new file mode 100644 > index 000..92548e2 > --- /dev/null > +++ b/board/davinci/da8xxevm/da850evm.c > @@ -0,0 +1,124 @@ > +/* > + * (C) Copyright 2009, Texas Instruments, Inc. http://www.ti.com/ > + * > + * Based on da830evm.c At this point, this seem to be a copy of da830evm.c (well except the first few lines above). Copied code is not good. I have changes still in the pipe line for da830evm.c for adding support for NAND and Ethernet and there is a USB patch out there IIRC. Since the da850 is so similar, I suspect we can at least factor out the common parts so that we don't have to edit two files to add NAND support for example. I think it is the case that the only difference is DDR instead of SDRAM and the UBL will handle that for us. Is that true for the device *and* the EVM? If so, then possibly da830evm.c could be renamed to da8xxevm.c and the code kept completely common - at the risk of adding a few ifdefs later. Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Davinci: davinci_nand.c performance enhancments
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
---
Changes:
Cleaned up based on Scott Wood's comments:
read/write_buf slightly faster and catches more cases.
Removed unnecessary and/or badly named variables.
drivers/mtd/nand/davinci_nand.c | 200 ---
1 files changed, 146 insertions(+), 54 deletions(-)
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index 90e038e..bfc2acf 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -59,14 +59,111 @@
static emif_registers *const emif_regs = (void *)
DAVINCI_ASYNC_EMIF_CNTRL_BASE;
+/*
+ * 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 only works if the NAND is not connected to the 2 LSBs of
+ * the address bus. On Davinci EVM platforms this has always been true.
+ */
+static void nand_davinci_read_buf(struct mtd_info *mtd, uint8_t *buf, int len)
+{
+ struct nand_chip *chip = mtd->priv;
+ const u32 *nand = chip->IO_ADDR_R;
+
+ /* Make sure that buf is 32 bit aligned */
+ if (((int)buf & 0x3) != 0) {
+ if (((int)buf & 0x1) != 0) {
+ if (len) {
+ *buf = readb(nand);
+ buf += 1;
+ len--;
+ }
+ }
+
+ if (((int)buf & 0x3) != 0) {
+ if (len >= 2) {
+ *(u16 *)buf = readw(nand);
+ buf += 2;
+ len -= 2;
+ }
+ }
+ }
+
+ /* copy aligned data */
+ while (len >= 4) {
+ *(u32 *)buf = readl(nand);
+ buf += 4;
+ len -= 4;
+ }
+
+ /* mop up any remaining bytes */
+ if (len) {
+ if (len >= 2) {
+ *(u16 *)buf = readw(nand);
+ buf += 2;
+ len -= 2;
+ }
+
+ if (len)
+ *buf = readb(nand);
+ }
+}
+
+static void nand_davinci_write_buf(struct mtd_info *mtd, const uint8_t *buf,
+ int len)
+{
+ struct nand_chip *chip = mtd->priv;
+ const u32 *nand = chip->IO_ADDR_W;
+
+ /* Make sure that buf is 32 bit aligned */
+ if (((int)buf & 0x3) != 0) {
+ if (((int)buf & 0x1) != 0) {
+ if (len) {
+ writeb(*buf, nand);
+ buf += 1;
+ len--;
+ }
+ }
+
+ if (((int)buf & 0x3) != 0) {
+ if (len >= 2) {
+ writew(*(u16 *)buf, nand);
+ buf += 2;
+ len -= 2;
+ }
+ }
+ }
+
+ /* copy aligned data */
+ while (len >= 4) {
+ writel(*(u32 *)buf, nand);
+ buf += 4;
+ len -= 4;
+ }
+
+ /* mop up any remaining bytes */
+ if (len) {
+ if (len >= 2) {
+ writew(*(u16 *)buf, nand);
+ buf += 2;
+ len -= 2;
+ }
+
+ if (len)
+ writeb(*buf, nand);
+ }
+}
+
static void nand_davinci_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int
ctrl)
{
struct nand_chip *this = mtd->priv;
u_int32_t IO_ADDR_W = (u_int32_t)this->IO_ADDR_W;
- IO_ADDR_W &= ~(MASK_ALE|MASK_CLE);
-
if (ctrl & NAND_CTRL_CHANGE) {
+ IO_ADDR_W &= ~(MASK_ALE|MASK_CLE);
+
if ( ctrl & NAND_CLE )
IO_ADDR_W |= MASK_CLE;
if ( ctrl & NAND_ALE )
@@ -75,7 +172,7 @@ static void nand_davinci_hwcontrol(struct mtd_info *mtd, int
cmd, unsigned int c
}
if (cmd != NAND_CMD_NONE)
- writeb(cmd, this->IO_ADDR_W);
+ writeb(cmd, IO_ADDR_W);
}
#ifdef CONFIG_SYS_NAND_HW_ECC
@@ -247,59 +344,55 @@ static int nand_davinci_4bit_calculate_ecc(struct
mtd_info *mtd,
const uint8_t *dat,
uint8_t *ecc_code)
{
- unsigned int hw_4ecc[4] = { 0, 0, 0, 0 };
- unsigned int
