[U-Boot-Users] M-Systems Disk on Chip and U-boot

[U-Boot-Users] M-Systems Disk on Chip and U-boot

[Herb Radford]

We're looking at using a DoC on our next product and I was wondering how 
the drivers (obviously supplied by M-Systems) are merged into U-Boot code?

One of the newer P3 chips has an IPL section which is "execute in place" 
and would contain early initialization code for the cpu/board/SDRAM and 
then copy the body of the code into SDRAM. This idea sounds good for cost 
reasons (one device) but seems like an ugly hack to the structure of 
U-Boot. Any comments?

Regards, Herb

[U-Boot-Users] M-Systems Disk on Chip and U-boot

[Brian Waite]

On Thu, 02 Sep 2004 07:37:27 -0400, Herb Radford <herbr@magma.ca> wrote:
> We're looking at using a DoC on our next product and I was wondering how
> the drivers (obviously supplied by M-Systems) are merged into U-Boot code?

Please be cautious with merging drivers supplied my M-Systems into
U-Boot code. I have not seen thrie drivers, but I am not 100% sure
they are GPL. Including non-GPL code into U-Boot even locally can be
the cause of leagal headaches down the road. You may have to see if
you can reverse engineer the driver, or base the U-Boot driver off of
the kernel driver instead of using the vendor supplied driver. I would
be a bit cautious with this as there is no loadable module interface
loophole in U-Boot to help you avoid the GPL.
Sorry I couldn't be more help technically but I had a few spare cents
here to use.
Thanks
Brian

[U-Boot-Users] M-Systems Disk on Chip and U-boot

[Wolfgang Denk]

In message <36b714c8040902054918d4555f@mail.gmail.com> you wrote:
>
> they are GPL. Including non-GPL code into U-Boot even locally can be
> the cause of leagal headaches down the road. You may have to see if

...only if you are going to distribute the result. For  your  own  or
internal use you can do whatever you want.

> be a bit cautious with this as there is no loadable module interface
> loophole in U-Boot to help you avoid the GPL.

There is no such "loadable module interface loophole" for the  kernel
either. GPL is GPL.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
War isn't a good life, but it's life.
	-- Kirk, "A Private Little War", stardate 4211.8

[U-Boot-Users] M-Systems Disk on Chip and U-boot

[Udi Finkelstein]

Herb Radford wrote:
> We're looking at using a DoC on our next product and I was wondering how 
> the drivers (obviously supplied by M-Systems) are merged into U-Boot code?

I just began working on improving DoC support (for the RBC823 board), 
but I had a few questions. Since you have mentioned the subject of DoC I 
think its a good time to raise them here:

If I understand correctly, the Linux MTD drivers has two layers. The 
lower device level handles actual device access, while the upper layer 
(NFTL, etc.) handles wear leveling.

1. If I undersnatd correctly, u-boot only implemented the lower level, 
right? no NFTL driver is currently in U-boot.

2. Is the Linux MTD NFTL driver compatible (in terms of disk format) 
with the M-sys TrueFFS driver ? can I use the same device with both 
software stacks without corrupting it?

3. Which layer handles ECC correction?

4. What good is the current u-boot support if it has no NFTL, and hence 
no wear leveling? I assume I can't just map the FAT commands over it 
without NFTL, as it won't be reable (if written over NFTL).

5. I understand the DoC has 2 partitions (at least the 8M models) - a 
binary partition and the normal partition. what is the difference 
between them?

I plan adaptin gthe NFTL layer from the linux-MTD project into u-boot, 
and add support for the FAT commands.

thanks,
Udi

[U-Boot-Users] M-Systems Disk on Chip and U-boot

[Wolfgang Denk]

In message <4137A05B.3070304@udif.com> you wrote:
>
> If I understand correctly, the Linux MTD drivers has two layers. The 
> lower device level handles actual device access, while the upper layer 
> (NFTL, etc.) handles wear leveling.

In other words, one level is block device access, the  other  one  is
more or less filesystem related.

> 1. If I undersnatd correctly, u-boot only implemented the lower level, 
> right? no NFTL driver is currently in U-boot.

Right. The intention was to be able to load a Linux kernel image from
the "binary partition" of the DoC, but not more. See
http://www.denx.de/doc/CPU86/advanced-topics.html#DISK-ON-CHIP
for details.

[Yes, sorry, this information didn't make it into the new DULG yet. I
really wish the board manufacturers would pay a  bit  to  keep  their
documentation up to date.]

> 2. Is the Linux MTD NFTL driver compatible (in terms of disk format) 
> with the M-sys TrueFFS driver ? can I use the same device with both 
> software stacks without corrupting it?

Dunno.

> 3. Which layer handles ECC correction?

Dunno.

> 4. What good is the current u-boot support if it has no NFTL, and hence 
> no wear leveling? I assume I can't just map the FAT commands over it 
> without NFTL, as it won't be reable (if written over NFTL).

You can boot a Linux kernel from the bianry partition on the DoC.

> 5. I understand the DoC has 2 partitions (at least the 8M models) - a 
> binary partition and the normal partition. what is the difference 
> between them?

One is - umm - a binary partition without a  filesystem  on  it,  the
other one is a filesystem partition.

> I plan adaptin gthe NFTL layer from the linux-MTD project into u-boot, 
> and add support for the FAT commands.

Fine.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
It is better to marry than to burn.
                                - Bible ``I Corinthians'' ch. 7, v. 9

[U-Boot-Users] M-Systems Disk on Chip and U-boot

[Woodruff, Richard]

There are some MDOC drivers in the kernel MTD system at present. Putting
them in u-boot wouldn't be so much of a stretch.

How you use the single part in u-boot will depend on how big xip region
is and its attributes.  You might get away with folding it right in, or
you might need a sub loader like we used for our TI NAND boots for OMAP
processors.

The OMAP 16xx/17xx/24xx processor allow for booting from a RAW NAND
devices and can be made to work with u-boot.  In there case they have
microcode in the cpu which reads some blocks of nand into onchip SRAM
and executes it.

Regards,
Richard W.

> -----Original Message-----
> From: u-boot-users-admin at lists.sourceforge.net [mailto:u-boot-users-
> admin at lists.sourceforge.net] On Behalf Of Herb Radford
> Sent: Thursday, September 02, 2004 6:37 AM
> To: u-boot-users at lists.sourceforge.net
> Subject: [U-Boot-Users] M-Systems Disk on Chip and U-boot
> 
> We're looking at using a DoC on our next product and I was wondering
how
> the drivers (obviously supplied by M-Systems) are merged into U-Boot
code?
> 
> One of the newer P3 chips has an IPL section which is "execute in
place"
> and would contain early initialization code for the cpu/board/SDRAM
and
> then copy the body of the code into SDRAM. This idea sounds good for
cost
> reasons (one device) but seems like an ugly hack to the structure of
> U-Boot. Any comments?
> 
> Regards, Herb
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&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] M-Systems Disk on Chip and U-boot

[philipv at cam.org]

[U-Boot-Users] M-Systems Disk on Chip and U-boot

[Wolfgang Denk]

Dear Philip,

in message <1094135066.41372d1aaba03@webmail.cam.org> you wrote:
> 
> I think you could only use U-Boot to load a (non-GPL) loader that uses the DoC.
> It this a correct assumption?

Yes.  You  can  load  any  type  of  software,  including  completely
proprietary stuff.

> Wasn't there a section in the manual (U-Boot) about this, using U-Boot to load 
> non-GPL applications [i.e. Whatever happened to Chapter 8]

Chapter 8 is a new chapter I intended to add about building and using
Linux kernel modules. I just never found time to add any ral content.

This has nothing to do with U-Boot.

> Also, what's the status for "standalone applications", i.e the U-Boot resources 
> mentioned in 5.12 (console I/O, memory allocation, ...)?

What do you mean what is the status? It's  a  standard  feature  like
TFTP  download or serial console support... It has always been there,
and always will be.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Time is a drug. Too much of it kills you.
                                      - Terry Pratchett, _Small Gods_

[U-Boot-Users] M-Systems Disk on Chip and U-boot

[philipv at cam.org]

Quoting Wolfgang Denk <wd@denx.de>:

> 
> > Also, what's the status for "standalone applications", i.e the U-Boot
> resources 
> > mentioned in 5.12 (console I/O, memory allocation, ...)?
> 
> What do you mean what is the status? It's  a  standard  feature  like
> TFTP  download or serial console support... It has always been there,
> and always will be.
> 

Sorry for the ambiguty.

Can a "standalone application" be non-GPL? Are the u-boot resources: console 
I/O, memory allocation, viewed as LGPL like versions of libc?

Philip

[U-Boot-Users] M-Systems Disk on Chip and U-boot

[Wolfgang Denk]

In message <1094151111.41376bc7a4ed5@webmail.cam.org> you wrote:
> 
> Can a "standalone application" be non-GPL? Are the u-boot resources: console 

Yes, this has always been one of the intentions (not the  major  one,
but one of them).

> I/O, memory allocation, viewed as LGPL like versions of libc?

Good question. I have to admit that I never thought of that.  Yes,  I
think so.

Is there anyone here who is fluent enough with such  legal  stuff  to
comment?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
"If you can, help others. If you can't, at least don't hurt  others."
- the Dalai Lama