[U-Boot-Users] das u-boot and disc on chip

[U-Boot-Users] das u-boot and disc on chip

[Eckhard Doll]

Hello list,

currently I try to bring up a LH7A404 board with a M-Systems G3 Disc on 
Chip as the boot device. Is it possible to modify das u-boot to be used 
in such an environment? Or has anyone already made an effort in this 
direction?

The device has a 2k xip area from where an initial loader could move the 
rest of das u-boot to ram to execute it from there.

Regards,

-- 
Eckhard Doll
Messtechnik / Metrology TE-SM
ESEM Gr?nau GmbH & Co. KG
D-88677 Markdorf
Germany

Phone +49.7544.9583.27
Fax +49.7544.9583.60
mailto: doll at esem.com
http://www.esem.com

[U-Boot-Users] das u-boot and disc on chip

[Wolfgang Denk]

In message <42235801.5040600@esem.com> you wrote:
> 
> currently I try to bring up a LH7A404 board with a M-Systems G3 Disc on 
> Chip as the boot device. Is it possible to modify das u-boot to be used 
> in such an environment? Or has anyone already made an effort in this 
> direction?

I'm not exactly sure what you mean by "boot device". It is no problem
to use DoC as boot device for an OS, for  example  to  load  a  Linux
kernel from it and/or use it as filesystem later.

> The device has a 2k xip area from where an initial loader could move the 
> rest of das u-boot to ram to execute it from there.

You would have to write your own separate bootstrap loader then. IMHO
this is not woth the trouble.

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
It is more rational to sacrifice one life than six.
	-- Spock, "The Galileo Seven", stardate 2822.3

[U-Boot-Users] das u-boot and disc on chip

[Eckhard Doll]

Wolfgang Denk schrieb:
> 
> I'm not exactly sure what you mean by "boot device". It is no problem

In this case the part of the board design which appears at address 0x00 
of lh7a404 after reset.

> You would have to write your own separate bootstrap loader then. IMHO
> this is not woth the trouble.

Yes, shouldn't be. Initialise ram, move and jump.

I'm quite new to this arm and embedded linux stuff and played a bit with 
a kev7a400 board and a patched u-boot-0.45 and now I will use das u-boot 
with a 2.6-kernel on a small lh7a404-design with mentioned DoC and some 
sdram and several io's

Any hint or doc-pointer on adaption of das u-boot to this lh7a404 soc? 
As it is a SoC, there shouldn't be much board-specific stuff to be done 
for a boot-loader.

Regards,
-- 
Eckhard Doll
Messtechnik / Metrology TE-SM
ESEM Gr?nau GmbH & Co. KG
D-88677 Markdorf
Germany

Phone +49.7544.9583.27
Fax +49.7544.9583.60
mailto: doll at esem.com
http://www.esem.com

[U-Boot-Users] das u-boot and disc on chip

[Wolfgang Denk]

In message <422424F5.1060908@esem.com> you wrote:
>
> > You would have to write your own separate bootstrap loader then. IMHO
> > this is not woth the trouble.
> 
> Yes, shouldn't be. Initialise ram, move and jump.

I didn't mean to say that, but if you feel like it - ok. Anyway:
please see CanUBootBeConfiguredSuchThatItCanBeStartedInRAM.html
[Read: don't expect support]
> 
> As it is a SoC, there shouldn't be much board-specific stuff to be done 
> for a boot-loader.

Ummm... I'm afraid I have to destroy your illusions. This will  be  a
full port like any other.

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
God may be subtle, but He isn't plain mean.         - Albert Einstein

[U-Boot-Users] das u-boot and disc on chip

[Eckhard Doll]

Excuse me if its going OT now. Maybe, you can point me, out of your 
embedded experience, to a better source.

Wolfgang Denk schrieb:
> 
> I didn't mean to say that, but if you feel like it - ok. Anyway:
> please see CanUBootBeConfiguredSuchThatItCanBeStartedInRAM.html
> [Read: don't expect support]
> 
> Ummm... I'm afraid I have to destroy your illusions. This will  be  a
> full port like any other.
no illusions, maybe it sounds like, yes. I'm just thrown into this 
project with an existing design and looking for solutions. The board 
consists of an lh7a404(arm922t-core),2x64MB SDRAM,64MB Flash DoC, 
Ethernet, USB, 2xUART and extension bus, nothing else. My preferred OS 
is, of course, Linux.

If I understood you right, U-Boot is maybe not the best choice for me, 
because there are only 2KB XIP Flash available at address 0x00000000 on 
startup.

Because of the several boot-modes, the lh7a404 offers, I'm thinking in 
the meantime about to ommit the loader completely and copy the kernel 
image directly from DoC to ram and jump there.

Regards,

-- 
Eckhard Doll
Messtechnik / Metrology TE-SM
ESEM Gr?nau GmbH & Co. KG
D-88677 Markdorf
Germany

Phone +49.7544.9583.27
Fax +49.7544.9583.60
mailto: doll at esem.com
http://www.esem.com

[U-Boot-Users] das u-boot and disc on chip

[Wolfgang Denk]

In message <42248E52.8070109@esem.com> you wrote:
> 
> If I understood you right, U-Boot is maybe not the best choice for me, 
> because there are only 2KB XIP Flash available at address 0x00000000 on 
> startup.

I wouldn't put it like that. IMO your hardware is not the best choice
for you because it is missing a proper boot ROM (256 kB  flash  would
be  just  perfect)  to  allow  you using a decent boot loader without
jumping in loops.

> Because of the several boot-modes, the lh7a404 offers, I'm thinking in 
> the meantime about to ommit the loader completely and copy the kernel 
> image directly from DoC to ram and jump there.

And who will initialize the hardware for Linux?  Who  will  tell  the
Linux  kernel  how  much  memory you have, and pass all the other bot
arguments to it? And how will you get LInux into the DoC in the first
place?

It's software, so all things are possible. But  not  all  things  are
reasonable.

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
You can do this in a number of ways.     IBM chose to do all of them.
Why do you find that funny?        -- D. Taylor, Computer Science 350

[U-Boot-Users] das u-boot and disc on chip

[Tolunay Orkun]

Dear Wolfgang,

Wolfgang Denk wrote:
> In message <42248E52.8070109@esem.com> you wrote:
> 
>>If I understood you right, U-Boot is maybe not the best choice for me, 
>>because there are only 2KB XIP Flash available at address 0x00000000 on 
>>startup.
> 
> I wouldn't put it like that. IMO your hardware is not the best choice
> for you because it is missing a proper boot ROM (256 kB  flash  would
> be  just  perfect)  to  allow  you using a decent boot loader without
> jumping in loops.

I 100% agree that dealing with a separate NOR boot ROM is so much more 
easier. However, I also see booting from NAND data flash with a small 
boot readable sector is quickly becoming popular in lower cost/smaller 
footprint/less power consumption equipment.

IMHO instead of denying this reality, perhaps we (as U-Boot 
developers/users) should make some enhancements to deal with this 
situation in a formal supported way before too many forks occur.

After all it is supposed to be **Universal** boot loader. ;)

Best regards,
Tolunay

[U-Boot-Users] das u-boot and disc on chip

[Wolfgang Denk]

Dear Tolunay,

in message <42262F9B.7030509@orkun.us> you wrote:
> 
> I 100% agree that dealing with a separate NOR boot ROM is so much more 
> easier. However, I also see booting from NAND data flash with a small 
> boot readable sector is quickly becoming popular in lower cost/smaller 
> footprint/less power consumption equipment.

Yes - and you shift 90% of the problems that U-Boot  is  supposed  to
solve  (like easy debugging of the low level initialization sequence)
into this "small primary bootstrap loader".

> IMHO instead of denying this reality, perhaps we (as U-Boot 

I don't deny it. I just tend to ignore it -  like  I  ignore  systems
running (or crashing) those Windoze "software" ;-)

> developers/users) should make some enhancements to deal with this 
> situation in a formal supported way before too many forks occur.

Actually NO enhancements are needed. All is ready and in place,  it's
just  that  you  don't  get any support here for creating the primary
bootstrap loader. This is a different issue, which  is  unrelated  to
U-Boot.  U-Boot  can  live  with suh a situation fine - of course you
have to know _exactly_ what you are doing. See for  examplethe  Atmel
AT91RM9200  configuration  where  all  you  need  to  change  is  the
CONFIG_BOOTBINFUNC definition to either  use  an  external  bootstrap
loader or to have a real self-contained U-Boot image.

U-Boot was defined to solve certain problems  that  are  typical  for
board bringup; this worked pretty well - just see how many relatively
unexperienced  developers were able to port U-Boot to their hardware.
If you force U-Boot into a hostile environment, the same old problems
will have to be solved again - there is  nothing  U-Boot  can  do  to
prevent  this.  So  if you go that route, please don't expect to find
much help here on this list.

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
That was the thing about deserts. They had their  own  gravity.  They
sucked you into the centre.           - Terry Pratchett, _Small Gods_

[U-Boot-Users] das u-boot and disc on chip

[Tolunay Orkun]

Wolfgang Denk wrote:

>>developers/users) should make some enhancements to deal with this 
>>situation in a formal supported way before too many forks occur.
>>    
>>
>Actually NO enhancements are needed. All is ready and in place,  it's
>just  that  you  don't  get any support here for creating the primary
>bootstrap loader. This is a different issue, which  is  unrelated  to
>  
>
Perhaps, there could be a U-Boot project sanctioned primary boot loader 
framework. Much of the code to do that is already in U-Boot anyway (like 
common CPU initialization code). Some of the board level initialization 
code and any board specific code for retrieving U-Boot image would need 
to be there as well.

Alternatively if you do not like that idea, U-Boot project would 
formally define the guidelines of operation in a system where primary 
boot loader is required and state the requirements (state of DRAM, 
relocation etc) expected from such primary bootloader.

>U-Boot.  U-Boot  can  live  with suh a situation fine - of course you
>have to know _exactly_ what you are doing. See for  examplethe  Atmel
>AT91RM9200  configuration  where  all  you  need  to  change  is  the
>CONFIG_BOOTBINFUNC definition to either  use  an  external  bootstrap
>loader or to have a real self-contained U-Boot image.
>  
>
Yes, the developer is expected to know _exactly_ what they are doing in 
any case with or without a primary boot loader. Porting requires 
complete understanding of the hardware and software architecture. Much 
of the same concerns of developing such primary bootloader applies to 
the board level startup code anyway. There is no substitute...

Defining the guidelines, requirements and the interface would 
significantly help steer the development in the right direction. It is 
better than saying not supported but developer has to do it anyway. At 
least, such formalism would help the process.

Best regards,
Tolunay

[U-Boot-Users] das u-boot and disc on chip

[Wolfgang Denk]

In message <422641B0.50602@orkun.us> you wrote:
> 
> Perhaps, there could be a U-Boot project sanctioned primary boot loader 
> framework. Much of the code to do that is already in U-Boot anyway (like 
> common CPU initialization code). Some of the board level initialization 
> code and any board specific code for retrieving U-Boot image would need 
> to be there as well.

I seriously doubt that the existing code could be  used.  It's  build
around  the central assumption that ease debugging is most important,
so for example  a  serial  console  port  is  provided  as  early  as
possible, long before even attempting to initialize any system memory
(RAM or flash). This pulls in a serial driver, and printf, and ...

> Alternatively if you do not like that idea, U-Boot project would 
> formally define the guidelines of operation in a system where primary 
> boot loader is required and state the requirements (state of DRAM, 
> relocation etc) expected from such primary bootloader.
...
> Defining the guidelines, requirements and the interface would 
> significantly help steer the development in the right direction. It is 
> better than saying not supported but developer has to do it anyway. At 
> least, such formalism would help the process.

Please feel free to submit such a definition of guidelines,  require-
ments and interfaces.

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
A modem is a baudy house.