Re: NAND support [was: Port U-Boot to SBC-2410X]

Dear Ladislav,

in message <20050831212122.GA32559 <at> orphique> you wrote:
> 
> I promised you to send update over a weekend, but didn't tell you which
> one . Although normaly I do not have problems explaining my boss why

I know how this goes. Been there before. Can't remember when for  the
first time 

> Patch against "testing-NAND" branch can be found here:
> ftp://ftp.linux-mips.org/pub/linux/mips/people/ladis/u-boot/u-boot-nand.diff

Can you please either send this by e-mail, or put it on a server that
actually works?

> It also contains support for new board NetStar (it is not meant to be
> included - I want to maintain it outside U-Boot, but I'd agree to put it
> into "testing-NAND" branch for reference), which shows sample

If I add it to "testing-NAND" (and it makes a lot of sense if this is
a working example) then it will go more or  less  automagically  into
the main tree as soon as I merge branches. Is this acceptable to you?

> implementation. Note that you have to define CONFIG_NEW_NAND_CODE to
> actually compile and use new code. Original <linux/mtd/nand.h> was moved
> to <linux/mtd/nand_old.h> and so has to be fixed all unconverted boards
> includes (I do not have energy to do it now and test if they still compiles).

We will have to go through this when switching the code base.

Re: Port U-Boot to SBC-2410X

Thank for your reply. 

I am sorry that I make some confusion between "xterm" and "shell" (By the way,
my english is so poor). In fact, hush in U-Boot calls function "readline"
(like that bash may use GNU readline library) to handle I/O and implement
terminal-extension, right? While terminal (usually serial driver in U-Boot) is
a minimal subset to drive I/O devices, readline can do more like command
history expansion and cmdline editing. My patch just modifys "readline"
function to use vivi's extension codes, which also means that it just consider
one line not a complete hush sentence (like "if...then...fi") as one history
item. However, I think, it is useful enough.

About the nand subsystem, I am glad to hear that there exists one fresh driver
branch. It makes sense to every user, I think. Because nor flash always works
as BOOT rom, while nand flash always works as DATA rom. In my embedded
project, I cannot do anything without a usable nand driver because the nor
flash chip is 1MB while the nand flash chip is 64MB on my board. Where to
place my kernel and the huge root filesystem? 

I will submit the three patches soon.

Best regards,

luo.jinhua

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: [PATCH 1/5][RESEND #2] CSB637 - add KB920x support

Anders Larsen wrote:
> 
> I've heard rumours there are at91rm9200 boards out there which contain
> some sort of pre-boot-loader which loads U-Boot into an initialized
> environment.

Yes (its more than a romour),
this is needed, when you store everything on atmel serial dataflash.
The pre-boot-loader (romboot) is loaded in internal SRAM by the ROM 
routines. Then romboot initializes RAM and CPU clocks, copies u-boot 
from dataflash into RAM and starts it.

Best regards
Peter

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

BDI2000 and MPC8260

Hi,

I hope this isn't considered off topic here....

I am trying to load u-boot.bin into the flash device on my PM828 board using a BDI2000 and the
config file ftp://ftp.denx.de/pub/BDI2000/pm826.cfg.  On the PM828 platform the HRW - hard reset
configuration word- is loaded into the CPU from bottom of the flash device on CS0.

The problem I am seeing is that the bdi2000 cannot communicate with the PM828 if the HRW is not
present in the flash device.  I.e. you need u-boot.bin already loaded into flash in order to load
u-boot.bin into flash!

At the moment I can work around this problem by setting some jumpers on the board to remap CS0 to a
PROM device containing u-boot, writing the HRW into flash, and returning the jumpers so that CS0 is
mapped to the flash again.  Unfortunately I will not be able to do this on our custom hardware as
there will only be a flash device and no PROM.

Here is the output from the BDI2000 session when the flash on CS0 is erased (i.e. the HRW is
0xffffffff):

- TARGET: waiting for target Vcc
- TARGET: waiting for target Vcc
- TARGET: waiting for target Vcc

	[ PM828 is switched on ]
	
- TARGET: processing power-up delay
- TARGET: processing user reset request
- BDI asserts HRESET
- Reset JTAG controller passed

Executing an application from a specific address

HI,

I have my bootloader running and i get the boot prompt.
Now i am trying to load hello_world.bin and trying to 
execute it.
1>>
I have a pxa250  (ARM)processor on Accelent board.
As per Readme.Standalone i should be loading the 
application at 0x0c100000 and executing from the
same address.But no where in the hello_world.c
i find any link which tells the application that it should
stick to the above specified address.
Then why is it that U-boot can run the application only 
if it is at that address.
I read some previous posts which say that we can
download the application anywhere other than
0x0c100000,but u boot wont execute them.
Why is it so? Where has it been specified that
u-boot should execute standalone application only 
if it is at that address

2>>The memory map for pxa250 which i received says
nCS0: 0x00000000-0x03ffffff

J77 1-2 Flash ROM (default)
J78 2-3 M-Systems Disk On Chip

nCS1: 0x04000000-0x07ffffff

J78 1-2 M-Systems Disk On Chip (default)

Re: BDI2000 and MPC8260

In message <20050901111214.457804dc.ajz <at> cambridgebroadband.com> you wrote:
> 
> The problem I am seeing is that the bdi2000 cannot communicate with the PM828 if the HRW is not
> present in the flash device.  I.e. you need u-boot.bin already loaded into flash in order to load
> u-boot.bin into flash!

This is normal; with an erased flash, the processor will read a  HRCW
which  sets external bus arbitration and CPU core disabled - there is
nothing left for the BDI to communicate with.

> At the moment I can work around this problem by setting some jumpers on the board to remap CS0 to a
> PROM device containing u-boot, writing the HRW into flash, and returning the jumpers so that CS0 is
> mapped to the flash again.  Unfortunately I will not be able to do this on our custom hardware as
> there will only be a flash device and no PROM.

Install a RCFG jumper... The PM82x modules  have  a  RCFG  jumper  to
bring up the CPU in internal default configuration.

Best regards,

Wolfgang Denk

--

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd <at> denx.de
Reader, suppose you were an idiot. And suppose you were a  member  of
Congress. But I repeat myself.                           - Mark Twain

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO

[PATCH] - request to change default debug assembly flags from stabs to dwarf2

The default for the C portion of the u-boot compile is set to dwarf-2
because the -g option for gcc 3.x defaults to dwarf-2, but the assembly
portion is not.  

If possible, I would like to see the debug formats made consistent so as
to allow the debugger to more reliably step through assembly source with
gdb and other debuggers with the more modern dwarf2 debug format.  I
have tested this change with gcc 3.4.3 on Arm9, MPC82xx, PPC85xx, PPC
40x and PPC 44x.  I also tested with ELDK 3.1.1 on all the PPC archs and
it works quite well.

Signed-off-by: Jason Wessel <jason.wessel <at> windriver.com>

diff --git a/config.mk b/config.mk
--- a/config.mk
+++ b/config.mk
 <at>  <at>  -133,7 +133,7  <at>  <at>  CFLAGS := $(CPPFLAGS) -Wall -Wno-trigrap
 endif
 endif

-AFLAGS_DEBUG := -Wa,-gstabs
+AFLAGS_DEBUG := -Wa,-gdwarf2
 AFLAGS := $(AFLAGS_DEBUG) -D__ASSEMBLY__ $(CPPFLAGS)

 LDFLAGS += -Bstatic -T $(LDSCRIPT) -Ttext $(TEXT_BASE)
$(PLATFORM_LDFLAGS)

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices

Runninng ELDK_BUILD : Pls help

RE: BDI2000 and MPC8260

> -----Original Message-----
> From: Wolfgang Denk
> Sent: Thursday, September 01, 2005 10:50
> In message 
> <20050901111214.457804dc.ajz <at> cambridgebroadband.com> you wrote:
> > 
> > The problem I am seeing is that the bdi2000 cannot 
> communicate with the PM828 if the HRW is not
> > present in the flash device.  I.e. you need u-boot.bin 
> already loaded into flash in order to load
> > u-boot.bin into flash!
> 
> This is normal; with an erased flash, the processor will read a  HRCW
> which  sets external bus arbitration and CPU core disabled - there is
> nothing left for the BDI to communicate with.

We have anoter solution working here. To initally program the HRCW into
flash we use another JTAG device (a Corellis JTAG interface) to wiggle
th pins on the 8260 to program the flash. This works, but is fairly
slow. To program 256 bytes of HRCW takes 10 - 15 seconds.

After this we switch to BDI2000 and program U-Boot.

This way we don't need yet another piece of HW on the board.

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: NAND support [was: Port U-Boot to SBC-2410X]

On Thu, Sep 01, 2005 at 01:05:54AM +0200, Wolfgang Denk wrote:
> > Patch against "testing-NAND" branch can be found here:
> > ftp://ftp.linux-mips.org/pub/linux/mips/people/ladis/u-boot/u-boot-nand.diff
> 
> Can you please either send this by e-mail, or put it on a server that
> actually works?

Hmm, something strange had happened, that server is very stable,
backuped with diesel generator... Well, it works now. You might be
interested in other patches in u-boot directory, all of them should be
in your queue anyway.

> > It also contains support for new board NetStar (it is not meant to be
> > included - I want to maintain it outside U-Boot, but I'd agree to put it
> > into "testing-NAND" branch for reference), which shows sample
> 
> If I add it to "testing-NAND" (and it makes a lot of sense if this is
> a working example) then it will go more or  less  automagically  into
> the main tree as soon as I merge branches. Is this acceptable to you?

Yes it is, but for sure I'll explain why I didn't want it to be accepted
into mainline. Code in board/netstar runs only on one of many CPUs found
in NetStar PBX. It is hardly possible to write code which will make that
piece of hw act like PBX without hardware documentation and for other
applications it is damn expensive toy. That's why I think there is no use
of it for others, more boards means more worries when maintaining code
and (nothing personal) patch acceptance speed makes it uninteresting for
me. Moreover I basicaly made U-Boot act as second stage loader to allow
safe upgrades, because one day I'd like to use yaffs2 filesystem and
U-Boot currently doesn't support that. Thus I do not see any single
advantage of integrating netstar code into mainline. Of course patch
will be still avaible to conform with GPL.

> We will have to go through this when switching the code base.
> 
> > Ideally old and new code should be able to coexist. Please let me know if you
> 
> But only one version shall be in the main branch at a time, i. e. one
> day the new code will replace the old one, and then all  boards  will
> need to be converted.

Sure. My point was to allow incremental conversion, without breaking
support for yet unconverted boards.

Best regards,
	ladis

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf