[U-Boot-Users] Univesal bootloader in 2 stages

[U-Boot-Users] Univesal bootloader in 2 stages

[Srivatsan]

Hi all,

     I understand that uboot works in 2 stages, one before RAM is
initialized and the other after RAM is initialized.

     But my requirement is, I would like to load the First stage of
uboot into Flash, then get the second stage of the boot loader thro' a
fast Ethernet(This means that I require a Ethernet driver to run from
Flash). In addition I would also like to start a Flash File system in
first stage itself. Here's a summary

Uboot -- I stage [Running from Flash]
CPU setup. 
Ethernet driver, support for TFTP.
Flash driver.
Flash file system.

Uboot - IIstage [Running from RAM]
Other board initializations
Device initializations
CLI and booting the kernel image.

Would like to know whether the above split up of Uboot is feasible?
Thanks for all your time. CPU will be mostly powerquicc II processor and
the board is a customized board.

Regards,
C.R.Srivatsan

-----Original Message-----
From: u-boot-users-admin@lists.sourceforge.net
[mailto:u-boot-users-admin at lists.sourceforge.net] On Behalf Of
u-boot-users-request at lists.sourceforge.net
Sent: Friday, November 05, 2004 10:35 AM
To: u-boot-users at lists.sourceforge.net
Subject: U-Boot-Users digest, Vol 1 #1079 - 2 msgs

Send U-Boot-Users mailing list submissions to
	u-boot-users at lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/u-boot-users
or, via email, send a message with subject or body 'help' to
	u-boot-users-request at lists.sourceforge.net

You can reach the person managing the list at
	u-boot-users-admin at lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of U-Boot-Users digest..."


Today's Topics:

   1. Re: Timeout by U-Boot while writing to flash (Paul Ruhland)
   2. Re: HW Addr different to Vendor information (Paul Ruhland)

--__--__--

Message: 1
From: Paul Ruhland <pruhland@rochester.rr.com>
Organization: OpenPore
To: lugs at eternitytechnologies.com
Subject: Re: [U-Boot-Users] Timeout by U-Boot while writing to flash
Date: Thu, 4 Nov 2004 23:39:09 -0500
Cc: u-boot-users at lists.sourceforge.net

On Thursday 04 November 2004 20:56, Devraj Mukherjee wrote:
> Hi everyone,
>
> We finally got U-Boot up and running on our board. Many thanks to
> everyone who replied to our emails. We are having trouble writing the
> initial environment variables to the system.
>
This sounds like it may be a problem with the newer board revisions vs.
the 
current cvs.  There were changes to the cpld and the I/O buffers which
set 
the buffers in the wrong direction by default at boot.  You have to
either 
enable pcmcia (both) or set a couple gpio lines.

To check your cpld revision enter the following:

LPD7A400> md.b 0x71400000 1

The only info I have is from the boards I've been able to get.  A cpld 
revision >= 0x34 has the buffer change.  I've seen lower version numbers

mentined as have this change also but cannot confirm.

To set the gpio pins enter the following:

LPD7A400> mw 0x80000e3c 0x00000000 1
LPD7A400> mw 0x80000e38 0x00000005 1

The first command ensures portg pins are outputs (default).  The second 
command sets the necessary pins to set the buffers in the proper
direction.

I was holding off the patch for this till I got reliable info about the
the 
card engine revision vs. the buffer direction change.  I haven't gotten
any 
response yet.

--
Paul Ruhland


--__--__--

Message: 2
From: Paul Ruhland <pruhland@rochester.rr.com>
Organization: OpenPore
To: lugs at eternitytechnologies.com
Subject: Re: [U-Boot-Users] HW Addr different to Vendor information
Date: Thu, 4 Nov 2004 23:51:58 -0500
Cc: u-boot-users at lists.sourceforge.net

On Thursday 04 November 2004 23:14, Devraj Mukherjee wrote:
> Hi everyone,
>
> We are tring to get the ethernet working on our board. Here is what we
> have been trying. Our DHCP server gives addresses in the range of
10.0.1.x
>
> Our vendor has documented that our MAC address is 00:08:EE:00:41:60
and
> LogicLoader (the default bootloader) would get an IP with this MAC
> address. It's interesting to see that U-Boot with the patches thinks
> that the HW Addr is 04:04:04:33:04:04
>
> Any ideas, experiences?
>

I believe this is related to the new card version problem I mentioned in

previous post.

Let me know what version you have and if the workaround I posted fixes
these 
problems for you.

I won't have access to my board till tomorrow.  I can post a patch then
if 
this is the problem your having.



--__--__--

_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users


End of U-Boot-Users Digest




********************************DISCLAIMER**********************************

This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege of Deccanet Designs Ltd.
If you have received this message in error, please notify the originator
immediately. If you are not the intended recipient, you are notified that
you are strictly prohibited from retaining, using, copying, altering or
disclosing the contents of this message.

****************************************************************************

[U-Boot-Users] Univesal bootloader in 2 stages

[Wolfgang Denk]

In message <000401c4c30a$578db310$4501a8c0@bgcw301> you wrote:
> 
>      I understand that uboot works in 2 stages, one before RAM is
> initialized and the other after RAM is initialized.

You understand that these are just two different states of  operation
within the same code?

>      But my requirement is, I would like to load the First stage of
> uboot into Flash, then get the second stage of the boot loader thro' a
> fast Ethernet(This means that I require a Ethernet driver to run from

This is no possible with U-Boot. There are no  separate  images,  but
just  one  program which is running first in flash, and then - agfter
relocation - continues to run from RAM.

> Flash). In addition I would also like to start a Flash File system in
> first stage itself. Here's a summary
> 
> Uboot -- I stage [Running from Flash]
> CPU setup. 
> Ethernet driver, support for TFTP.
> Flash driver.
> Flash file system.
> Uboot - IIstage [Running from RAM]

That does not work. First, you cannot have an ethenret driver  before
initializing  the  ram (where would you buffer the network packets?).
Second, with most flash types  you  cannot  access  the  flash  (like
erase,  program,  or  even  read  status  information)  while you are
executing code from the same device. You MUST be  running  such  code
from some other memory.

> Would like to know whether the above split up of Uboot is feasible?

No, this is not possible.

What makes you think you need such a  configuration?  Why  can't  you
just use U-Boot as is?

Best regards,

Wolfgang Denk

-- 
See us @ Embedded/Electronica Munich, Nov 09 - 12, Hall A.6 Booth 513
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Ahead warp factor 1"                                  - Captain Kirk

[U-Boot-Users] Univesal bootloader in 2 stages

[Srivatsan]

Thanks for the answer Mr.Wolfgang Denk.

Since my hardware is customized, to run the hardware for the very first
time with a bootloader, programming 200K will take a lot more time with
a JTAG interface [Thinking from manufacturing angle]. That?s the reason
I wanted to have the bootloader to be split into 2.[So that programming
only around 10K will not take a lot of time compared to the whole
bootloader].

Do you have any suggestion for this type of a scenario?

Thanks for the answer.

Regards,
C.R.Srivatsan

-----Original Message-----
From: wd@denx.de [mailto:wd at denx.de] 
Sent: Friday, November 05, 2004 4:13 PM
To: Srivatsan
Cc: u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] Univesal bootloader in 2 stages 

In message <000401c4c30a$578db310$4501a8c0@bgcw301> you wrote:
> 
>      I understand that uboot works in 2 stages, one before RAM is
> initialized and the other after RAM is initialized.

You understand that these are just two different states of  operation
within the same code?

>      But my requirement is, I would like to load the First stage of
> uboot into Flash, then get the second stage of the boot loader thro' a
> fast Ethernet(This means that I require a Ethernet driver to run from

This is no possible with U-Boot. There are no  separate  images,  but
just  one  program which is running first in flash, and then - agfter
relocation - continues to run from RAM.

> Flash). In addition I would also like to start a Flash File system in
> first stage itself. Here's a summary
> 
> Uboot -- I stage [Running from Flash]
> CPU setup. 
> Ethernet driver, support for TFTP.
> Flash driver.
> Flash file system.
> Uboot - IIstage [Running from RAM]

That does not work. First, you cannot have an ethenret driver  before
initializing  the  ram (where would you buffer the network packets?).
Second, with most flash types  you  cannot  access  the  flash  (like
erase,  program,  or  even  read  status  information)  while you are
executing code from the same device. You MUST be  running  such  code
from some other memory.

> Would like to know whether the above split up of Uboot is feasible?

No, this is not possible.

What makes you think you need such a  configuration?  Why  can't  you
just use U-Boot as is?

Best regards,

Wolfgang Denk

-- 
See us @ Embedded/Electronica Munich, Nov 09 - 12, Hall A.6 Booth 513
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Ahead warp factor 1"                                  - Captain Kirk




********************************DISCLAIMER**********************************

This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege of Deccanet Designs Ltd.
If you have received this message in error, please notify the originator
immediately. If you are not the intended recipient, you are notified that
you are strictly prohibited from retaining, using, copying, altering or
disclosing the contents of this message.

****************************************************************************

[U-Boot-Users] Univesal bootloader in 2 stages

[VanBaren, Gerald]

> -----Original Message-----
> From: u-boot-users-admin at lists.sourceforge.net
> [mailto:u-boot-users-admin at lists.sourceforge.net] On Behalf
> Of Srivatsan
> Sent: Friday, November 05, 2004 2:38 AM
> To: u-boot-users at lists.sourceforge.net
> Subject: [U-Boot-Users] Univesal bootloader in 2 stages
> Importance: High
>
> Hi all,
>
>      I understand that uboot works in 2 stages, one before
> RAM is initialized and the other after RAM is initialized.
>
>      But my requirement is, I would like to load the First
> stage of uboot into Flash, then get the second stage of the
> boot loader thro' a fast Ethernet(This means that I require a
> Ethernet driver to run from Flash). In addition I would also
> like to start a Flash File system in first stage itself.
> Here's a summary
>
> Uboot -- I stage [Running from Flash]
> CPU setup.
> Ethernet driver, support for TFTP.
> Flash driver.
> Flash file system.
>
> Uboot - IIstage [Running from RAM]
> Other board initializations
> Device initializations
> CLI and booting the kernel image.
>
> Would like to know whether the above split up of Uboot is feasible?
> Thanks for all your time. CPU will be mostly powerquicc II
> processor and the board is a customized board.
>
> Regards,
> C.R.Srivatsan

Others have replied with more authority than I have, but I would like to
point out that your "I stage++" exactly describes u-boot (the "++" being
the running from RAM part) and your "II stage" exactly describes booting
linux.  You already have exactly what you asked for.  Pour the bits into
the board and It Just Works[tm] (after a little porting and debugging if
you have new hardware ;-).

The current boot organization is going to be hard or impossible to
improve.  If you wish to do so, feel free -- that is the beauty of Open
Source -- but you aren't likely to get a lot of help since you are
solving a problem that others have already solved and are happy with the
existing solution.

gvb

******************************************
The following messages are brought to you by the Lawyers' League of
IdioSpeak:

******************************************
The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege.  If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager.  Please do not copy it for any purpose, or disclose its contents to any other person.  The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company.  The recipient should check this e-mail and any attachments for the presence of viruses.  The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email.
******************************************

[U-Boot-Users] Univesal bootloader in 2 stages

[Wolfgang Denk]

In message <000001c4c326$64d54ad0$4501a8c0@bgcw301> you wrote:
> 
> Since my hardware is customized, to run the hardware for the very first
> time with a bootloader, programming 200K will take a lot more time with
> a JTAG interface [Thinking from manufacturing angle]. That?s the
> reason

Did you actually measure the time it takes to progam the  200  kB  of
U-Boot  using  a  BDi2000  with  an optimized config file (i. e. with
workspace enabled)?

And did you then estimate the time you  need  to  program  your  mini
loader,  to load the real image over the network, and then to program
the real image to flash?

Do you really expect this to be faster?


I will not be convinced before I see actual numbers.

> I wanted to have the bootloader to be split into 2.[So that programming
> only around 10K will not take a lot of time compared to the whole
> bootloader].

If you really manage to get a boot  loader  with  support  for  flash
programming  and  TFTP  download  in 10 kB I really would like to see
your code. I'm willing to throw out all flash and network drivers  in
U-Boot and replace them with your code.

> Do you have any suggestion for this type of a scenario?

Sorry, no. I don't know how to provide such a solution.

Best regards,

Wolfgang Denk

-- 
See us @ Embedded/Electronica Munich, Nov 09 - 12, Hall A.6 Booth 513
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Technology is dominated by those who manage what they do  not  under-
stand.

[U-Boot-Users] Univesal bootloader in 2 stages

[Brian Waite]

I would reccommend getting a stable version of u-boot and having your
FLASH chips preprogrammed. I do this and basically the initial FLASH
load will determine if this is the first time it's been run and if so
will tftp a script over that updates u-boot to the most current
shipping version and does any other mojo I might need to do.

Also, as WD suggested, using a workspace allows my BDI to xfer
~100K/second. If you are trying have so many boards that 2 seconds a
board is too long, then get your chips preprogammed.

Thanks
Brian


On Fri, 05 Nov 2004 17:22:44 +0100, Wolfgang Denk <wd@denx.de> wrote:
> In message <000001c4c326$64d54ad0$4501a8c0@bgcw301> you wrote:
> >
> > Since my hardware is customized, to run the hardware for the very first
> > time with a bootloader, programming 200K will take a lot more time with
> > a JTAG interface [Thinking from manufacturing angle]. That's the
> > reason
> 
> Did you actually measure the time it takes to progam the  200  kB  of
> U-Boot  using  a  BDi2000  with  an optimized config file (i. e. with
> workspace enabled)?
> 
> And did you then estimate the time you  need  to  program  your  mini
> loader,  to load the real image over the network, and then to program
> the real image to flash?
> 
> Do you really expect this to be faster?
> 
> I will not be convinced before I see actual numbers.
> 
> > I wanted to have the bootloader to be split into 2.[So that programming
> > only around 10K will not take a lot of time compared to the whole
> > bootloader].
> 
> If you really manage to get a boot  loader  with  support  for  flash
> programming  and  TFTP  download  in 10 kB I really would like to see
> your code. I'm willing to throw out all flash and network drivers  in
> U-Boot and replace them with your code.
> 
> > Do you have any suggestion for this type of a scenario?
> 
> Sorry, no. I don't know how to provide such a solution.
> 
> Best regards,
> 
> Wolfgang Denk
> 
> --
> See us @ Embedded/Electronica Munich, Nov 09 - 12, Hall A.6 Booth 513
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> Technology is dominated by those who manage what they do  not  under-
> stand.
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>

[U-Boot-Users] Univesal bootloader in 2 stages

[Wolfgang Denk]

In message <36b714c804110509465443975e@mail.gmail.com> you wrote:
> 
> Also, as WD suggested, using a workspace allows my BDI to xfer
> ~100K/second. If you are trying have so many boards that 2 seconds a
> board is too long, then get your chips preprogammed.

... or use 2 or 5 or more BDI2000's in parallel.

Best regards,

Wolfgang Denk

-- 
See us @ Embedded/Electronica Munich, Nov 09 - 12, Hall A.6 Booth 513
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"The combination of a number of things to make existence worthwhile."
"Yes, the philosophy of 'none,' meaning 'all.'"
	-- Spock and Lincoln, "The Savage Curtain", stardate 5906.4

[U-Boot-Users] Persistent Flash File System.

[Srivatsan]

Hi all,

    Thanks for the response. I will surely get back to you all and share
my experience once I get the appropriate numbers in hand (Regarding the
programming with JTAG). 

    There is another query (Hope this is not Off Topic]. I am required
to start a Persistent(Very important) File system at the booloader stage
and that flash file system must be present even after an OS boots up (In
our case it is Linux). 

1) Whether the above condition possible ?
2) What are all the design considerations I must keep in mind while
designing such File Systems?

Thanks everyone. 

Regards,
C.R.Srivatsan


     

-----Original Message-----
From: wd@denx.de [mailto:wd at denx.de] 
Sent: Friday, November 05, 2004 4:13 PM
To: Srivatsan
Cc: u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] Univesal bootloader in 2 stages 

In message <000401c4c30a$578db310$4501a8c0@bgcw301> you wrote:
> 
>      I understand that uboot works in 2 stages, one before RAM is
> initialized and the other after RAM is initialized.

You understand that these are just two different states of  operation
within the same code?

>      But my requirement is, I would like to load the First stage of
> uboot into Flash, then get the second stage of the boot loader thro' a
> fast Ethernet(This means that I require a Ethernet driver to run from

This is no possible with U-Boot. There are no  separate  images,  but
just  one  program which is running first in flash, and then - agfter
relocation - continues to run from RAM.

> Flash). In addition I would also like to start a Flash File system in
> first stage itself. Here's a summary
> 
> Uboot -- I stage [Running from Flash]
> CPU setup. 
> Ethernet driver, support for TFTP.
> Flash driver.
> Flash file system.
> Uboot - IIstage [Running from RAM]

That does not work. First, you cannot have an ethenret driver  before
initializing  the  ram (where would you buffer the network packets?).
Second, with most flash types  you  cannot  access  the  flash  (like
erase,  program,  or  even  read  status  information)  while you are
executing code from the same device. You MUST be  running  such  code
from some other memory.

> Would like to know whether the above split up of Uboot is feasible?

No, this is not possible.

What makes you think you need such a  configuration?  Why  can't  you
just use U-Boot as is?

Best regards,

Wolfgang Denk

-- 
See us @ Embedded/Electronica Munich, Nov 09 - 12, Hall A.6 Booth 513
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Ahead warp factor 1"                                  - Captain Kirk




********************************DISCLAIMER**********************************

This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege of Deccanet Designs Ltd.
If you have received this message in error, please notify the originator
immediately. If you are not the intended recipient, you are notified that
you are strictly prohibited from retaining, using, copying, altering or
disclosing the contents of this message.

****************************************************************************

[U-Boot-Users] Persistent Flash File System.

[Wolfgang Denk]

In message <000401c4c62c$59bdad00$4501a8c0@bgcw301> you wrote:
> 
>     There is another query (Hope this is not Off Topic]. I am required
> to start a Persistent(Very important) File system at the booloader stage
> and that flash file system must be present even after an OS boots up (In
> our case it is Linux). 
> 
> 1) Whether the above condition possible ?

Of course it is. This is software, so EVERYTHING  is  possible.  It's
just a matter of effort, and efficiency.

> 2) What are all the design considerations I must keep in mind while
> designing such File Systems?

The main issue is: don't try to reinvent the wheel.

If you don't need write support, then just use the existing JFFS2 code.

If you doneed write support, then just use the  existing  JFFS2  code
and  add  write  support  to it based on the existing Linux MTD/JFFS2
drivers.

Best regards,

Wolfgang Denk

-- 
See us @ Embedded/Electronica Munich, Nov 09 - 12, Hall A.6 Booth 513
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I've already got a female to worry about. Her name is the Enterprise.
	-- Kirk, "The Corbomite Maneuver", stardate 1514.0