[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
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
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
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
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.
- 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.]
- 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.
- Which layer handles ECC correction?
Dunno.
- 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.
- 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
participants (4)
-
Brian Waite -
Herb Radford -
Udi Finkelstein -
Wolfgang Denk