Thomas Chou | 1 Apr 05:11 2010
Picon

[PATCH] cfi_flash: reset timer in flash status check

This patch adds reset_timer() before the flash status check
waiting loop.

Since the timer is basically running asynchronous to the cfi
code, it is possible to call get_timer(0), then only a few
_SYSCLK_ cycles later an interrupt is generated. This causes
timeout even though much less time has elapsed. So the timer
period registers should be reset before get_timer(0) is
called.

There is similar usage in nand_base.c.

Signed-off-by: Thomas Chou <thomas <at> wytron.com.tw>
---
 drivers/mtd/cfi_flash.c   |    2 ++
 include/configs/EP3C120.h |   10 +++++-----
 include/configs/NEEK.h    |   10 +++++-----
 3 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index aae93bd..99300ba 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
 <at>  <at>  -544,6 +544,7  <at>  <at>  static int flash_status_check (flash_info_t * info, flash_sect_t sector,
 #endif

 	/* Wait for command completion */
+	reset_timer();
 	start = get_timer (0);
 	while (flash_is_busy (info, sector)) {
(Continue reading)

Thomas Chou | 1 Apr 05:15 2010
Picon

[PATCH v2] cfi_flash: reset timer in flash status check

This patch adds reset_timer() before the flash status check
waiting loop.

Since the timer is basically running asynchronous to the cfi
code, it is possible to call get_timer(0), then only a few
_SYSCLK_ cycles later an interrupt is generated. This causes
timeout even though much less time has elapsed. So the timer
period registers should be reset before get_timer(0) is
called.

There is similar usage in nand_base.c.

Signed-off-by: Thomas Chou <thomas <at> wytron.com.tw>
---
Please ignore the earlier patch, which messed up when I added comments.

 drivers/mtd/cfi_flash.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index aae93bd..99300ba 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
 <at>  <at>  -544,6 +544,7  <at>  <at>  static int flash_status_check (flash_info_t * info, flash_sect_t sector,
 #endif

 	/* Wait for command completion */
+	reset_timer();
 	start = get_timer (0);
 	while (flash_is_busy (info, sector)) {
(Continue reading)

Nitin Mahajan | 1 Apr 05:43 2010
Picon

Re: Saving environment variables in MMC

Thanks Detlev,

--- On Wed, 31/3/10, Detlev Zundel <dzu <at> denx.de> wrote:

> From: Detlev Zundel <dzu <at> denx.de>
> Subject: Re: [U-Boot] Saving environment variables in MMC
> To: nitinm76 <at> yahoo.com
> Cc: "U-Boot user list" <u-boot <at> lists.denx.de>
> Date: Wednesday, 31 March, 2010, 8:04 PM
> Hi Nitin,
> 
> > Thanks for the information. I just wanted to have a
> feedback, whether
> > having a use-case of writing env variables from Linux
> User space is a
> > good idea or is not recommended?
> 
> You found tools/env/fw_env.c showing that this
> functionality is indeed
> foreseen and used.
> 
> It is rather common to write to the U-Boot environment in
> projects for
> example to switch to a new set of kernel+file system after
> an update
> from within linux for the next boot.
> 
My use case is exactly same, to switch to a new set of kernel+fs after an update for the next boot.

I also have another usecase of updating the env variable 'bootargs' if required in the field. So this
(Continue reading)

Scott McNutt | 1 Apr 06:33 2010

[PATCH] nios2: Reload timer count in reset_timer()

   When the timestamp is incremented via interrupt and the interrupt
   period is greater than 1 msec, successive calls to get_timer() can
   produce inaccurate timing since the interrupts are asynchronous
   to the timing loop. For example, with an interrupt period of 10 msec
   two successive calls to get_timer() could indicate an elapsed time
   of 10 msec after only several hundred usecs -- depending on when
   the next interrupt actually occurs. This behavior can cause
   reliability issues with components such as CFI and NAND.

   This can be remedied by calling reset_timer() prior to establishing
   the base timestamp with get_timer(0), provided reset_timer()
   resets the hardware timer (rather than simply resetting only the
   timestamp). This has the effect of synchronizing the interrupts
   (and the advance of the timestamp) with the timing loop.

Signed-off-by: Scott McNutt <smcnutt <at> psyent.com>
---
 cpu/nios2/interrupts.c |   33 +++++++++++++++++++++++++++++++++
 1 files changed, 33 insertions(+), 0 deletions(-)

diff --git a/cpu/nios2/interrupts.c b/cpu/nios2/interrupts.c
index 5c3b5e6..b552db4 100644
--- a/cpu/nios2/interrupts.c
+++ b/cpu/nios2/interrupts.c
 <at>  <at>  -56,7 +56,40  <at>  <at>  volatile ulong timestamp = 0;

 void reset_timer (void)
 {
+	nios_timer_t *tmr =(nios_timer_t *)CONFIG_SYS_NIOS_TMRBASE;
+
(Continue reading)

Nitin Mahajan | 1 Apr 07:27 2010
Picon

U-boot env variables parsing

Hi!

I am doing env settings some thing like this,

ROOT1=/dev/mmcblk0p1
ROOT2=/dev/mmcblk0p2
ROOT=${ROOT1}
bootargs1=console=ttyS0,115200n8 mem=256M noinitrd rw rootdelay=1 ${ROOT}

when I say 'setenv bootargs ${bootargs1}', ${ROOT} gets resolved to 'ROOT1', it does not get completely
resolved to '/dev/mmcblk0p1'. 

Is there something fundamentally wrong in setting the env variables this way?

What would be the right way to achieve this, as I want ROOT to be ${ROOT1} sometimes and ${ROOT2} some times?

regards

-Nitin

      Get your preferred Email name!
Now you can  <at> ymail.com and  <at> rocketmail.com. 
http://mail.promotions.yahoo.com/newdomains/aa/
Dunda, Matthias | 1 Apr 08:55 2010

Re: Booting from ext2/ext3

Good Morning Wolfgang,

> 
> 
> Dear Matthias,
> 
> In message 
> <569685F045B85741820D0265E0D2999D019CFE55 <at> tddhh01.hh.thales-na
> val.de> you wrote:
> > 
> > `get_partition_info'
> ...
> > What's the issue here?
> 
> Hm... this is U-Boot release v2009.11.1, correct?
> 

Yes correct, but it happens in 2009.08, too.

> 
> In your log you can see that the relevant source file, 
> disk/part.c, gets compiled:
> 
> Try running "nm" on the object file; you should see something 
> like this:
> 
The output of ppc_85xx-nm *.o in disk/ looks a little "weak":

part_dos.o:

(Continue reading)

Michal Simek | 1 Apr 09:09 2010
Picon

Re: [PATCH v2] net: add opencore 10/100 ethernet mac driver

Scott McNutt wrote:
> Hi Wolfgang,
> 
> Do we have a network drivers custodian? ... or should I just handle
> this patch through the nios repository? I'm guessing that this will
> only be used with nios2 in the near term. I'm not sure if any Microblaze
> (Xilinx) folks have worked with this -- perhaps Michal can comment?

It is possible to use it but we don't work with it.

Regards,
Michal

> 
> Regards,
> --Scott
> 
> Thomas Chou wrote:
>> This patch ports the opencore 10/100 ethernet mac driver ethoc.c
>> from linux kernel to u-boot.
>>
>> Signed-off-by: Thomas Chou <thomas <at> wytron.com.tw>
>> ---
>>  drivers/net/Makefile |    1 +
>>  drivers/net/ethoc.c  |  533 
>> ++++++++++++++++++++++++++++++++++++++++++++++++++
>>  include/netdev.h     |    1 +
>>  3 files changed, 535 insertions(+), 0 deletions(-)
>>  create mode 100644 drivers/net/ethoc.c
>>
(Continue reading)

Michal Simek | 1 Apr 09:17 2010
Picon

Re: [PATCH 2/5] nios2: add Altera EP2C35 board

Thomas Chou wrote:
> This patch supports the Altera CycloneII Nios dev board using
> the example FPGA design at http://nioswiki.com/Linux.
> 
> Signed-off-by: Thomas Chou <thomas <at> wytron.com.tw>
> ---
>  MAINTAINERS                          |    1 +
>  MAKEALL                              |    1 +
>  Makefile                             |    6 +
>  board/altera/nios2-generic/2c35_cf.h |  757 ++++++++++++++++++++++++++++++++++
>  include/configs/EP2C35.h             |  372 +++++++++++++++++
>  5 files changed, 1137 insertions(+), 0 deletions(-)
>  create mode 100644 board/altera/nios2-generic/2c35_cf.h
>  create mode 100644 include/configs/EP2C35.h

I am strongly against this style of adding any specific nios board to 
U-BOOT.

1. I am not convinced that all information from 2c35_cf.h are important 
for U-BOOT.
What connection has for example "#define KERNEL_REGION_BASE 0xc0000000"?
or others.
+#define PLL_COMPONENT_TYPE altera_avalon_pll
+#define PLL_COMPONENT_NAME pll
+#define PLL_BASE 0x1000020
+#define PLL_SPAN 32

It is the same situation as we solved for Xilinx boards.
Create generic nios board and then generate only parameters which are 
necessary for U-BOOT itself.
(Continue reading)

Michal Simek | 1 Apr 09:23 2010
Picon

Re: [PATCH] nios2: Set CONFIG_SYS_HZ to 1000 all nios2 boards.

Scott McNutt wrote:
>    CONFIG_SYS_HZ was being calculated (incorrectly) in nios2 configuration
>    headers. Updated comments to accurately describe timebase macros.
> 
> Signed-off-by: Scott McNutt <smcnutt <at> psyent.com>
> ---
>  include/configs/EP1C20.h  |   14 ++++++++------
>  include/configs/EP1S10.h  |   14 ++++++++------
>  include/configs/EP1S40.h  |   14 ++++++++------
>  include/configs/PCI5441.h |   14 ++++++++------
>  include/configs/PK1C20.h  |   14 ++++++++------
>  5 files changed, 40 insertions(+), 30 deletions(-)

This is the next "nice" patch around altera boards. If you do the same 
changes (because of the same reason) in 5 files it points me that 
something is wrong. Please create one generic nios2 file and move there 
these common macros. Look at ppc405/440 which use that style.

Michal

--

-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
Vipin KUMAR | 1 Apr 10:54 2010

Patch submission process

Dear Wolfgang, Tom

Although I have managed to submit my patches in the u-boot mainline in
the recent past, I am still a newbie to u-boot community.
I have a few doubts regarding the patch submission
process followed in u-boot.

I hope the answers would be beneficial not just for me but for everyone
I read the whole process on the website but what I understood from there
and what is really followed seems to be different.

After reading about the patch submission process, I felt that patches
can only be sent when the merging window is open but patches are being
continuously sent and reviewed.

Is it correct to assume that a patch can be sent at any time and will
only be applied to the mainline code during the merging window

Please let me know.

Thanks in advance 

Regards
Vipin

Gmane