[U-Boot-Users] Das U-Boot support for Atmel AT91SAM926x-EK (or other boards with an AT91SAM926x processor)?
Are there plans to add AT91SAM926x-EK board support to the main U-Boot repository or an appropriate custodian repository? If so, what is the anticipated time frame of this support? -- In the official U-Boot 1.3.1 release, I wasn't able to locate any boards with an AT91SAM926x processor. Are any supported? --- Comment --- I'm interested in EBI NOR booting of AT91SAM926x processors as opposed to SPI NOR (Dataflash) booting of these processors which is the usual case. If necessary, I'll use u-boot 1.2.0 as patched by Atmel to run on AT91SAM926x, but I'd prefer to use the official U-Boot code. Sincerely, Ken Fuchs - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] disable . when ext2load
U-Boot ext2load mmc 0:1 2150 vmImage
Next, many . appear on the console while the image is not
totally load on the SDRam. I don't want print this dot. So
how can I disable this?
The mmc_bread() routine in ./cpu/*/*/atmel_mci.c contains
putc('.');
You probably want to comment out or remove this line.
Cheers,
Ken Fuchs
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Pierre Savary
Sent: Monday, February 18, 2008 09:38
To: U-Boot-Users
Subject: [U-Boot-Users] disable . when ext2load
Hi all,
I use U-Boot 1.1.5 to load my Linux kernel. The image of this
kernel is on a
MMC. So, I make
U-Boot mmcinit
and after I make
U-Boot ext2load mmc 0:1 2150 vmImage
Next, many . appear on the console while the image is not
totally load on
the SDRam. I don't want print this dot. So how can I disable
this? I have
already search printf (.); or puts (.); or others
things ... but I
have not found where is this line on the source code ...
Could you help me please?
Thanks in advance
Pierre
--
---
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] drivers MMCplus for at91sam9x
Pierre Savary wrote: I use a MMCplus 4GB on my design (with at91sam9260). It's wired with 4 bits. The MCI controller on the AT91SAM926x family does not support MMCplus. There is no way to support a 4 bit bus, since the MCI controller supports only 1 bit to an MMC chip. The MCI will support a 4 bit SD chip, but I don't think it can be tricked into working with a 4 bit MMC chip (at least not via software alone). The only reasonable solution is switching to a processor that has MMCplus support. Maybe Atmel has been working on one? Currently U-boot (1.1.5) can't detect correctly the MMC and so I can't read my Linux kernel Image on the ext3 part of this MMC. If I use MMC 1GB, it works. Did you add MMCplus commands to the MCI U-Boot driver? You can do this to the extent that these changes do not require the MCI controller to be MMCplus compliant. (The MCI U-Boot driver I'm aware of contains no MMCplus support.) I suggest that you use the u-boot sources available via git. You will get very little support (if any) from the U-Boot ML for two reasons: 1) U-Boot 1.1.5 is extremely old and no one on the list is interested in supporting it. 2) The version of U-Boot 1.1.5 you are using almost certainly has an Atmel patch applied to it that was never accepted into the official U-Boot tree. However, ... It appears that someone is working on the AT91SAM9260 within the official U-Boot (git) tree, since the ./include/configs/at91sam9260ek.h file is there. Other file structures like ./cpu/arm926ejs/* seem to be missing some drivers and other support files. I know that the AT91SAM926x specific U-Boot files were never an official part of U-Boot, but that appears to be changing. It is my understanding that the AT91SAM926x support is being completely reworked and integrated with the AT91CAP9 code that has been present in git for over a month already. The AT91CAP9 and AT91SAM926x are very similar and should share a lot of code. Even if the AT91SAM9260 is not quite ready, the AT91CAP9 code should provide the basis of a current U-Boot for the AT91SAM926x family. Somebody have already use it? Or somebody have already implemented the ext_csd and high capacity with MMC on another platform? I know that the MCI controller can be used to access 1GB MMCplus chips, but I'm not sure it can be used to access MMCplus chips larger than that. There may be a special MMCplus command that will allow larger chips to be accessed. Try looking for it in your MMCplus chip's manual. Sincerely, Ken Fuchs -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pierre Savary Sent: Tuesday, April 08, 2008 09:32 To: u-boot-users@lists.sourceforge.net Cc: 'Pierre Ossman' Subject: [U-Boot-Users] drivers MMCplus for at91sam9x Hi, I use a MMCplus 4GB on my design (with at91sam9260). It's wired with 4 bits. Currently U-boot (1.1.5) can't detect correctly the MMC and so I can't read my Linux kernel Image on the ext3 part of this MMC. If I use MMC 1GB, it works. Somebody have already use it? Or somebody have already implemented the ext_csd and high capacity with MMC on another platform? I need help. Thanks in advance to help me. Regards, Pierre -- --- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java .sun.com/javaone ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] drivers MMCplus for at91sam9x
Pierre Ossman wrote: Ken Fuchs wrote: The MCI controller on the AT91SAM926x family does not support MMCplus. There is no way to support a 4 bit bus, since the MCI controller supports only 1 bit to an MMC chip. Untrue. The hardware interface is identical for 4-bit SD and 4-bit MMC. So if that part isn't working, it's because you either have a bug or because you lack 4-bit MMC support entirely in u-boot. The manual for the AT91SAM926x processors clearly states that the MCI controller supports MMC 2.2. I asked Atmel whether this controller could support 4 bits to an MMC 4.x chip and they said _no_. The answer is supposedly from their engineering group in France. 4-bit MMC support can easily be added to U-Boot, but the MCI controller is MMC 2.2, and this standard only allows for a 1-bit bus to MMC, so I'm not sure you can make it work at all. Atmel will definitely not help you, since they guarantee only MMC 2.2 compliance with the AT91SAM926x processor family. Has this changed? Pierre Ossman omitted the following part of my original response: The MCI will support a 4 bit SD chip, but I don't think it can be tricked into working with a 4 bit MMC chip (at least not via software alone). How does one program the MCI controller to send 4 bit (parallel) data an MMC 4.x chip, with or without telling it that it is communicating to a 4-bit SD chip? The only way to get 4 bits of data out of the MCI is to tell it that it is connected to a SD (1.0) chip. If you program the MCI to communicate with an MMC chip, it will send data out only on the low order bit. If you have a way around this, please let us know what it is. All compliant cards above 2 GB require special handling. They use a system identical to SDHC (except for the init). Check the specs (this part is publicly available) or the Linux code. Both ends of the communication link must considered. It may not be sufficient that the MMC chip is MMC 4.x; The fact that the MCI controller is only MMC 2.2 or SD 1.0 compliant, may or may not impact this special handling. Sincerely, Ken Fuchs - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] System hangs while starting: get clone of u-boot-at91.git - part 2 of 2
$ strace git clone http://git.denx.de/u-boot-at91.git Here is strace output of one iteration of the infinite loop. 90 3571246 [main] git-http-fetch 2780 cygwin_select: 6, 0x22C550, 0x22C530, 0x22C510, 0x22C5B0 42 3571288 [main] git-http-fetch 2780 dtable::select_write: fd 5 20 3571308 [main] git-http-fetch 2780 dtable::select_except: fd 5 19 3571327 [main] git-http-fetch 2780 cygwin_select: to-tv_sec 0, to-tv_usec 0, ms 0 19 3571346 [main] git-http-fetch 2780 cygwin_select: sel.always_ready 0 21 3571367 [main] git-http-fetch 2780 select_stuff::cleanup: calling cleanup routines 19 3571386 [main] git-http-fetch 2780 socket_cleanup: si 0x0 si-thread 0x0 19 3571405 [main] git-http-fetch 2780 socket_cleanup: returning 19 3571424 [main] git-http-fetch 2780 peek_socket: considering handle 0x5D4 20 3571444 [main] git-http-fetch 2780 peek_socket: adding write fd_set , fd 5 19 3571463 [main] git-http-fetch 2780 peek_socket: adding except fd_set , fd 5 30 3571493 [main] git-http-fetch 2780 peek_socket: WINSOCK_SELECT returned 0 20 3571513 [main] git-http-fetch 2780 select_stuff::poll: returning 0 20 3571533 [main] git-http-fetch 2780 select_stuff::cleanup: calling cleanup routines 18 3571551 [main] git-http-fetch 2780 select_stuff::~select_stuff: deleting select records 37 3571588 [main] git-http-fetch 2780 cygwin_select: 0, 0x22C748, 0x22C740, 0x22C738, 0x22C730 22 3571610 [main] git-http-fetch 2780 cygwin_select: to-tv_sec 0, to-tv_usec 5, ms 50 19 3571629 [main] git-http-fetch 2780 cygwin_select: sel.always_ready 0 50415 3622044 [main] git-http-fetch 2780 select_stuff::cleanup: calling cleanup routines 566 3622610 [main] git-http-fetch 2780 select_stuff::cleanup: calling cleanup routines 531 3623141 [main] git-http-fetch 2780 select_stuff::~select_stuff: deleting select records I usually stop it by killing the only current invocation of git-http-fetch. It leaves only an empty ./u-boot-91/.git/clone-tmp, though it does create other directories in .git temporarily. This problem has been repeatable for nearly the past 2 hours. I did a clone of the same git repository without any problems earlier today, except it wouldn't build properly. Any suggestions about what is wrong with the clone attempt and what can be done to fix it? Thanks, Ken Fuchs - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] drivers MMCplus for at91sam9x
Pierre Savary wrote: Then my MMC 4GB works with my Linux kernel but if I can't load my kernel (located on the first part of this MMC) ... it's not really interesting :( So, somebody does already use MMC v4 with U-boot??? Assuming a AT91SAM926x MCI controller: Probably. Given an MMC v2.x compliant U-Boot driver, it would be relatively easy to add support for an MMC v4.x chip. If there is an MMC v4.x compliant Linux driver, it could be ported to U-Boot (Many, if not most, U-Boot drivers are ports from the corresponding Linux driver.) Alternatively, if both an MMC v2.x compliant U-Boot driver and MMC v4.x compliant Linux driver exist, the port would be trivial; just copy the MMC v4.x Linux code into the corresponding places in the MMC v2.2 U-Boot driver until it supports your MMC v4.x chip. Such an MMC v4.x U-Boot AT91SAM926x MCI driver should be able to support any v4.x MMC chip, at least via a one bit MMC bus. (I remain unconvinced that the AT91SAM926x MCI controller can support a 4 bit MMC bus; only a working MCI driver using a 4 bit MMC bus verified by a logic analyzer or similar compliance/debugging device would be convincing enough.) If the Linux AT91SAM926x MCI driver supports a 4 bit MMC bus, then the U-Boot AT91SAM926x MCI driver can borrow the Linux driver's code and support a 4 bit bus also. Sincerely, Ken Fuchs -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Pierre Ossman Envoyé : samedi 12 avril 2008 11:28 À : [EMAIL PROTECTED] Cc : [EMAIL PROTECTED]; u-boot-users@lists.sourceforge.net Objet : Re: [U-Boot-Users] drivers MMCplus for at91sam9x On Fri, 11 Apr 2008 13:54:13 -0500 [EMAIL PROTECTED] wrote: The manual for the AT91SAM926x processors clearly states that the MCI controller supports MMC 2.2. I asked Atmel whether this controller could support 4 bits to an MMC 4.x chip and they said _no_. The answer is supposedly from their engineering group in France. What they answered was if Atmel would support such a solution, not if the hardware would. How does one program the MCI controller to send 4 bit (parallel) data an MMC 4.x chip, with or without telling it that it is communicating to a 4-bit SD chip? The only way to get 4 bits of data out of the MCI is to tell it that it is connected to a SD (1.0) chip. If you program the MCI to communicate with an MMC chip, it will send data out only on the low order bit. You tell it to use all four bits. That's it. The setting isn't MMC/SD, it's 1-bit/4-bit. Both ends of the communication link must considered. It may not be sufficient that the MMC chip is MMC 4.x; The fact that the MCI controller is only MMC 2.2 or SD 1.0 compliant, may or may not impact this special handling. It does not in the slightest. Remember that these controllers are extremely dumb. The low level behaviour of the protocol hasn't changed since the very first specs, so only software needs to be changed to support even the newest features. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org -- --- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java .sun.com/javao ne ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] drivers MMCplus for at91sam9x
Congratulations! It will be great to have MMC v4.x support in U-Boot.
The following segment of code from
linux-2.6.25-rc9/drivers/mmc/host/at91_mci.c is confusing:
if (host-board-wire4) {
if (cpu_is_at91sam9260() || cpu_is_at91sam9263())
mmc-caps |= MMC_CAP_4_BIT_DATA;
else
dev_warn(pdev-dev, 4 wire bus mode not supported
- using 1 wire\n);
}
This code seems to imply that MMC 4 bits works on the AT91SAM9260 and
AT91SAM9263, but not any of the others in this processor family,
possibly due to a hardware bug. Any comments on why the Linux AT91 MCI
driver doesn't support an 4 bit MMC bus for all AT91SAM9 processors?
I mention this because it may impact the AT91 MCI U-Boot device driver.
Sincerely,
Ken Fuchs
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Andy Fleming
Sent: Tuesday, April 15, 2008 14:25
To: Pierre Savary
Cc: u-boot-users@lists.sourceforge.net; [EMAIL PROTECTED]
Subject: Re: [U-Boot-Users] drivers MMCplus for at91sam9x
On Tue, Apr 15, 2008 at 5:18 AM, Pierre Savary
[EMAIL PROTECTED] wrote:
Then my MMC 4GB works with my Linux kernel but if I can't
load my kernel
(located on the first part of this MMC) ... it's not
really interesting :(
So, somebody does already use MMC v4 with U-boot???
I've got one that works. However, I don't have a 4GB MMC card with
v4. I thought I did, but it turned out the card just takes advantage
of the fact that older versions can address 4GB, even though the spec
says 2GB is the max.
However, I'm fairly confident in the code (it's been tested in
simulated environments, and reflects what the Linux code does). I'm
currently working on bringing it forward to the top of tree (I started
it before drivers/ got rearranged). I'm actually hoping to generalize
it some so we can share it between all MMC/SD users.
Andy
--
---
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to
save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java
.sun.com/javaone
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] What methods of software authentication does U-Boot support?
Goal: U-Boot will run only software that has been authenticated to be from the system's producer. --- A Potential Authentication Method --- The producer of the system generates a cryptographic [private-key, public-key] pair, storing the public-key on the same media as U-Boot (i.e. NOR flash; perhaps as a read-only environment variable) on all systems and keeping the private-key hidden at a secure site. A hash of the software is generated, encrypted with the private key and shipped with the software. U-Boot reads the private-key encrypted hash and decodes it with its public-key. U-Boot loads the software and generates the hash. If both hashes match, the software is authenticated and U-Boot executes the authenticated software. --- Comment --- U-Boot obviously supports loading and verification of the generated hash, but I haven't been able to locate public-key cryptographic or other authentication support in U-Boot. Perhaps, it is available as a loadable (stand-alone) module? Any comments or suggestions? Sincerely, Ken Fuchs - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] USB SUPPORT
--- Introduction ---
This thread concerns possible problems with fs/fat/fat.c
(incorrect fatls output and inaccessible files via
fatload) even when recent git patches have been applied
to fat.c. VFAT is enabled.
Michael Trimarchi wrote:
Can you give an image of it?
(He is referring to the FAT32 image where fatls usb 0:1 /
resulted in a clearly garbled/incorrect directory listing.)
Rather than that particular image, I decided to write two
scripts that do most of the work building two other FAT32
images that trigger problems with fatls usb 0:1 /. Note
that one FAT32 image is made on XP/Cygwin (mkpen) and the
other on FLOSS/Linux ..err.. GNU/Linux (mklpen). Note that
two FAT32 images they make do have exactly the same files and
file content, built in exactly the same order, but since the
filesystem code is different, the metadata will probably also
be different ... different inodes ... etc.
The attached mkpen is the XP/Cygwin build script and
u-boot-usb-bug.img.bz2 is a bzip2 compression of the
XP FAT32 image that demonstrates the problems (shown
below) when accessed by U-Boot's fatls.
The attached mklpen automates the whole process on a
Linux host, except you still need to enter the command
./mklpen and move the pen drive from host to target when
done... It makes a slightly a different FAT32 image that
reveals the same issues with fat.c a bit faster. The part
where it wipes out /dev/sda1 is commented out, so uncomment
at your risk and modify as needed for a SCSI host.
The middle of this message describes how the XP FAT32 image was
made. The latter part of this message shows the list of files
via XP/Cygwin and a different list shown via U-Boot's fatls.
--- Pen drive used ---
A 128MB USB pen drive with the following partition table
is being used (only one pen drive was used in testing):
# fdisk -l /dev/sda
Disk /dev/sda: 131 MB, 131072512 bytes
8 heads, 32 sectors/track, 1000 cylinders
Units = cylinders of 256 * 512 = 131072 bytes
Device Boot Start End Blocks Id System
/dev/sda1 11000 127984b W95 FAT32
#
--- XP/Cygwin FAT32 image build procedure ---
(For FLOSS/Linux host, just use the attached mklpen script.)
1) On Linux do:
# dd if=/dev/zero of=/dev/sda1 bs=`echo 32 * 512 | bc`
This is an attempt to reduce the effect of a bad link to
unallocated space. There is _no_ proof that this happens.
(Only null strings and null pointers can now be found here.)
2) On MS Windows XP or similar OS, format (mkfs) partition
1 with a FAT32 filesystem.
Alternative) On Linux: # mkdosfs -F 32 /dev/sda1
Warning: Linux mkdosfs and XP make different FAT32 images.
3) In a Cygwin bash shell, run the mkpen script with
cd set to /cygdrive/d (or e, f, g, etc. as appropriate):
#!/bin/bash
for char in 0 1 2 3 4 5 6 7 8 9 a b c d e f g h \
i j k l m n o p q r s t u v w x y z ; do
file=;
for (( index=0 ; index 8 ; index++ )) ; do
file=${file}${char};
done;
echo ${file} ${file}.txt
done
Alternative) On Linux, run the same script.
Warning: Linux vfat fs and XP FAT32 fs code may produce
different FAT32 images when running this script.
--- Note about building the FAT32 image with FLOSS ---
I also tested the FAT32 image that is built exclusively
via FLOSS tools (using the Linux alternatives in steps
2 3 or mklpen). The result is shown at the end of this
message.
--- ls -lU output of USB pen drive root directory ---
$ cd /pen1
$ ls -lU
total 36
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 .txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 .txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 .txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 .txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 .txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 .txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 .txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 .txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 .txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 .txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 .txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 .txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 .txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 .txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 .txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 .txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 .txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 .txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 .txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 .txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 .txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 .txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 .txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 .txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 .txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr
[U-Boot-Users] FW: USB SUPPORT get_vfatname
Michael,
I copied all files in fs/fat from git repository u-boot-at91. Made trivial
changes to compile it with my code base. Added your latest get_vfatname patch,
but it had no effect on the issue. fatls still
doesn't list filenames in some FAT32 filesystems, including the one
built via the Linux script I provided earlier in this thread.
Thus, there's no point in looking at the fat.c file I sent earlier
today. The problem remains in the git fat.c code or possibly in
the USB stack code. However, FAT16 has never failed, so the issue
is more likely to be with the FAT32 or vfat code.
Sincerely,
Ken Fuchs
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Wednesday, April 23, 2008 13:01
To: [EMAIL PROTECTED]
Cc: u-boot-users@lists.sourceforge.net
Subject: Re: [U-Boot-Users] USB SUPPORT get_vfatname
Michael,
Sorry, your latest get_vfatname patch doesn't work either.
FAT16 works perfectly, so the USB code is probably _not_ at fault. I see only
problems with FAT32, but only for _some_ long collections of files.
Thus, there may still be a problem with fs/fat/fat.c. Maybe there is something
wrong with my copy of fat.c I attached it; Perhaps you can see a problem with
it.
Sincerely,
Ken Fuchs
-Original Message-
From: michael [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 23, 2008 06:16
To: michael
Cc: Fuchs, Ken; u-boot-users@lists.sourceforge.net; Wolfgang Denk
Subject: Re: [U-Boot-Users] USB SUPPORT get_vfatname
Hi,
michael wrote:
Hi,
Can you try this one?
Revert my last one patch?
It change the test code, before the while. I use your script on a
Compact Flash and it looks fine for me (under linux).
Regards Michael
--
--
Check if the entry is a valid dir_slot entry, otherwise it
is a dentry and the
name has to be taken by the get_name function
Signed-off-by: michael trimarchi [EMAIL PROTECTED]
---
fs/fat/fat.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 49c78ed..bc37cec 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -473,8 +473,14 @@ get_vfatname(fsdata *mydata, int
curclust, __u8 *cluster,
while (slotptr2-id 0x01) {
slotptr2++;
}
+
/* Save the real directory entry */
realdent = (dir_entry*)slotptr2 + 1;
+ if (slotptr2-attr != ATTR_VFAT) {
+ get_name ((dir_entry *)realdent, l_name);
+ goto out;
+ }
+
while ((__u8*)slotptr2 = get_vfatname_block) {
slot2str(slotptr2, l_name, idx);
slotptr2--;
@@ -494,6 +500,7 @@ get_vfatname(fsdata *mydata, int
curclust, __u8 *cluster,
else if (*l_name == aRING) *l_name = 'å';
downcase(l_name);
+out:
/* Return the real directory entry */
memcpy(retdent, realdent, sizeof(dir_entry));
The scripts in this thread can be used to test the fat32
filesystem. I
do some tests using Compact Flash
device and this patchs work for me. I would like to know if is a fat
layer problem or usb layer problem.
Michael
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] USB SUPPORT get_vfatname
My include/fat.h is identical to the fat.h in both
git repository u-boot and git repository u-boot-at91,
except that I put the CHECKCLUST() macro in fat.c
rather than fat.h.
Ken
-Original Message-
From: michael [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 24, 2008 03:00
To: Fuchs, Ken
Cc: u-boot-users@lists.sourceforge.net
Subject: Re: [U-Boot-Users] USB SUPPORT get_vfatname
[EMAIL PROTECTED] wrote:
Ok,
check your fat.h and your fsdata
typedef struct {
__u8fatbuf[FATBUFSIZE]; /* Current FAT buffer */
int fatsize;/* Size of FAT in bits */
__u16 fatlength; /* Length of FAT in sectors */
__u16 fat_sect; /* Starting sector of the FAT */
__u16 rootdir_sect; /* Start sector of root directory */
__u16 clust_size; /* Size of clusters in sectors */
short data_begin; /* The sector of the first
cluster, can
be negative */
int fatbufnum; /* Used by get_fatent, init to -1 */
} fsdata;
The fatbuf is on the top?
Regards Michael
Michael,
Sorry, your latest get_vfatname patch doesn't work either.
FAT16 works perfectly, so the USB code is probably _not_ at
fault. I see only problems with FAT32, but only for _some_
long collections of files.
Thus, there may still be a problem with fs/fat/fat.c.
Maybe there is something wrong with my copy of fat.c I
attached it; Perhaps you can see a problem with it.
Sincerely,
Ken Fuchs
-Original Message-
From: michael [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 23, 2008 06:16
To: michael
Cc: Fuchs, Ken; u-boot-users@lists.sourceforge.net; Wolfgang Denk
Subject: Re: [U-Boot-Users] USB SUPPORT get_vfatname
Hi,
michael wrote:
Hi,
Can you try this one?
Revert my last one patch?
It change the test code, before the while. I use your script on a
Compact Flash and it looks fine for me (under linux).
Regards Michael
--
--
Check if the entry is a valid dir_slot entry, otherwise it
is a dentry and the
name has to be taken by the get_name function
Signed-off-by: michael trimarchi [EMAIL PROTECTED]
---
fs/fat/fat.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 49c78ed..bc37cec 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -473,8 +473,14 @@ get_vfatname(fsdata *mydata, int
curclust, __u8 *cluster,
while (slotptr2-id 0x01) {
slotptr2++;
}
+
/* Save the real directory entry */
realdent = (dir_entry*)slotptr2 + 1;
+ if (slotptr2-attr != ATTR_VFAT) {
+ get_name ((dir_entry *)realdent, l_name);
+ goto out;
+ }
+
while ((__u8*)slotptr2 = get_vfatname_block) {
slot2str(slotptr2, l_name, idx);
slotptr2--;
@@ -494,6 +500,7 @@ get_vfatname(fsdata *mydata, int
curclust, __u8 *cluster,
else if (*l_name == aRING) *l_name = 'å';
downcase(l_name);
+out:
/* Return the real directory entry */
memcpy(retdent, realdent, sizeof(dir_entry));
The scripts in this thread can be used to test the fat32
filesystem. I
do some tests using Compact Flash
device and this patchs work for me. I would like to know
if is a fat
layer problem or usb layer problem.
Michael
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] USB SUPPORT get_vfatname
USB_STOR_DEBUG log: Hit any key to stop autoboot: 0 U-Boot usb reset usb reset (Re)start USB... USB: scanning bus for devices... USB device not responding, giving up (status=20) 3 USB Device(s) found scanning bus for storage devices... i=0 i=1 USB Mass Storage device detected Transport: Bulk/Bulk/Bulk Endpoints In 1 Out 2 Int 0 BBB_reset BBB_reset result 0: status 0 reset BBB_reset result 0: status 0 clearing IN endpoint BBB_reset result 0: status 0 clearing OUT endpoint BBB_reset done address 2 COMMAND phase DATA phase STATUS phase inquiry returns 0 ISO Vers 2, Response Data 2 COMMAND phase STATUS phase FAILED COMMAND phase DATA phase STATUS phase Request Sense returned 06 28 00 COMMAND phase STATUS phase COMMAND phase DATA phase STATUS phase Read Capacity returns: 0xe80300, 0x2 Capacity = 0x3e801, blocksz = 0x200 address 2 partype: 0 usb_read: dev 0 COMMAND phase STATUS phase usb_read: dev 0 startblk 0, blccnt 1 buffer 23edbbe4 read10: start 0 blocks 1 COMMAND phase DATA phase STATUS phase usb_read: end startblk 1, blccnt 1 buffer 23edbde4 partype: 2 i=2 i=3 1 Storage Device(s) found U-Boot fatls usb 0:1 / fatls usb 0:1 / usb_read: dev 0 COMMAND phase STATUS phase usb_read: dev 0 startblk 0, blccnt 1 buffer 23edbbc8 read10: start 0 blocks 1 COMMAND phase DATA phase STATUS phase usb_read: end startblk 1, blccnt 1 buffer 23edbdc8 usb_read: dev 0 COMMAND phase STATUS phase usb_read: dev 0 startblk 0, blccnt 1 buffer 23edb998 read10: start 0 blocks 1 COMMAND phase DATA phase STATUS phase usb_read: end startblk 1, blccnt 1 buffer 23edbb98 usb_read: dev 0 COMMAND phase STATUS phase usb_read: dev 0 startblk 20, blccnt 1 buffer 23eda540 read10: start 20 blocks 1 COMMAND phase DATA phase STATUS phase usb_read: end startblk 21, blccnt 1 buffer 23eda740 usb_read: dev 0 COMMAND phase STATUS phase usb_read: dev 0 startblk fa2, blccnt 1 buffer 23f3ad78 read10: start fa2 blocks 1 COMMAND phase DATA phase STATUS phase usb_read: end startblk fa3, blccnt 1 buffer 23f3af78 9 .txt 9 .txt 9 .txt 9 .txt 9 .txt 9 .txt 9 .txt 9 .txt usb_read: dev 0 COMMAND phase STATUS phase usb_read: dev 0 startblk fa3, blccnt 1 buffer 23f3ad78 read10: start fa3 blocks 1 COMMAND phase DATA phase STATUS phase usb_read: end startblk fa4, blccnt 1 buffer 23f3af78 0 . 9 file(s), 0 dir(s) U-Boot -Original Message- From: michael [mailto:[EMAIL PROTECTED] Sent: Thursday, April 24, 2008 12:01 To: Fuchs, Ken Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] USB SUPPORT get_vfatname Hi, [EMAIL PROTECTED] wrote: My include/fat.h is identical to the fat.h in both git repository u-boot and git repository u-boot-at91, except that I put the CHECKCLUST() macro in fat.c rather than fat.h. Ken Can you put in debug the fat.c file? Try to align the temp buffer in fat.c to 32 bit and send to the list a log file during the fatls command. To do the align just put the attribute keyword. fat/fat.c: __u8 tmpbuf[FS_BLOCK_SIZE] __attribute__((aligned(4))); fat/fat.c:__u8 get_vfatname_block[MAX_CLUSTSIZE] __attribute__((aligned(4))); fat/fat.c:__u8 get_dentfromdir_block[MAX_CLUSTSIZE] __attribute__((aligned(4))); fat/fat.c:__u8 do_fat_read_block[MAX_CLUSTSIZE] __attribute__((aligned(4))); Your test in my CF card works without problem. Regards Michael - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] FW: USB SUPPORT get_vfatname
Michael Trimarchi wrote: In my spare time a try to change the do_fat_read to support the chaining. Thank you. Please let me know of anything I can do to help. Does this mean you are now able to duplicate the problem? The Microsoft Extensible Firmware Initiative FAT32 File System Specification white paper you quoted seems like a good reference document for FAT32. Is there anything better? BTW, in working with partitions = 32MB, I have used FAT12, but fs/fat/fat.c clearly doesn't support FAT12 properly. FAT12 can be useful for NOR flash devices which are often small enough for all four primary partitions to be = 32MB. Is anyone else (trying to) use FAT12 via U-Boot? My work-around for this problem has simply been force partitions = 32MB to contain FAT16 whenever U-Boot needs to read file from them. Sincerely, Ken Fuchs -Original Message- From: michael [mailto:[EMAIL PROTECTED] Sent: Friday, April 25, 2008 10:45 To: Fuchs, Ken Cc: [EMAIL PROTECTED]; u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] FW: USB SUPPORT get_vfatname Hi, [EMAIL PROTECTED] wrote: Michael Trimarchi wrote: confirm that the problem is in fat.c file and I will try to fix. It has been confirmed that fatls does _not_ list all files on FAT32 filesystems. There are _no_ reports of fatls failing to list all files on FAT16 filesystems. (There may be an unrelated bug caused by all 512 directory entries of FAT16 being used.) What additional information is needed to confirm that the problem is in fat.c? The problem is related to how fat.c manage the root directory. As reported by microsoft in FAT32, the root directory can be of variable size and is a cluster chain, just like any other directory is. The first cluster of the root directory on a FAT32 volume is stored in BPB_RootClus. Unlike other directories, the root directory itself on any FAT type does not have any date or time stamps, does not have a file name (other than the implied file name \), and does not contain . and .. files as the first two directory entries in the directory. The only other special aspect of the root directory is that it is the only directory on the FAT volume for which it is valid to have a file that has only the ATTR_VOLUME_ID attribute bit set (see below). What is your response to the debug log you requested? It was sent to the ml almost 18 hours ago and is also quoted below. In my spare time a try to change the do_fat_read to support the chaining. Regards Michael - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] drivers MMCplus for at91sam9x
I posted the following patch under a different subject line:
Re: [U-Boot-Users] [PATCH] Add eSDHC driver
--- u-boot_at91sam9260_mmc.patch (AT91 MCI driver) ---
Pierre Savary wrote:
Thanks for that... but it's my own patch ;)
Pierre
===
Pierre, I hope you like this patch better. :)
The following MMC v4 patch is for u-boot-1.1.5_atmel_1.2.
To the AT91SAM9261 MCI device driver it adds support for
MMC v4.x chips (MoviNAND in particular).
The u-boot_at91sam9260_mmc.patch, previously send to this
thread 23 April 2008 must be applied to
u-boot-1.1.5_atmel_1.2, prior to applying the patch below.
The patch includes lines /* Ignore */. These are
simply place holders for code that was not relevant
to the MCI driver or MMC code.
The patch is actually of four individual source files.
Please let me know of any serious problems applying the
patch. It should apply cleanly, but I didn't verify this.
The MCI MMC v4 features contained in this patch work perfectly
on our AT91SAM9261 board, except that I never got MMC 4 bit
bus working (that code is omitted from this patch). Anyone
know why the AT91SAM9261-EK doesn't appear to support 4 bit MMC?
This patch may not work on AT91SAM9261-EK, since we modified
the AT91SAM9261-EK board definitions rather than creating a
new configuration and files for our board.
Sincerely,
Ken Fuchs
u-boot-at91sam9261-mmc-v4.patch
===
svn diff -r21 cpu/arm926ejs/at91sam926x/atmel_mci.c
Index: cpu/arm926ejs/at91sam926x/atmel_mci.c
===
--- cpu/arm926ejs/at91sam926x/atmel_mci.c (revision 21)
+++ cpu/arm926ejs/at91sam926x/atmel_mci.c (working copy)
@@ -1,4 +1,8 @@
/*
+ * (C) Copyright 2007-2008
+ * Benchmark Electronics, Inc.
+ * Added MMC v4.x (MoviNAND) support
+ *
* Copyright (C) 2004-2006 Atmel Corporation
*
* See file CREDITS for list of people who contributed to this
@@ -34,21 +38,43 @@
#include asm/arch/hardware.h //klk
#include atmel_mci.h
-#undef DEBUG
+
+/* Ignore */
+/* Ignore */
+/* Ignore */
+
+#if 0
+#define DEBUG
+#else /* 0 */
+#undef DEBUG /* kf - was #undef */
+#endif /* 0 */
+
#ifdef DEBUG
#define pr_debug(fmt, args...) printf(fmt, ##args)
#else
#define pr_debug(...) do { } while(0)
#endif
+#undef CFG_MMC_CLK_OD
+#define CFG_MMC_CLK_OD 375000
+
#ifndef CFG_MMC_CLK_OD
#define CFG_MMC_CLK_OD 375000
#endif
+#undef CFG_MMC_CLK_PP
+#define CFG_MMC_CLK_PP 2000
+
#ifndef CFG_MMC_CLK_PP
#define CFG_MMC_CLK_PP 2000
#endif
+#undef CFG_MMC_OP_COND
+#define CFG_MMC_OP_COND0x80ff8000
+/* 0x80ff8080 works with 30+ sec. power
off req */
+/* 0x0080 works better, but write
forever? */
+/* 0x0010 works with 30+ sec. power
off req */
+
#ifndef CFG_MMC_OP_COND
#define CFG_MMC_OP_COND0x0010
#endif
@@ -74,8 +100,13 @@
bus_hz = AT91C_MASTER_CLOCK;
clkdiv = (bus_hz / hz) / 2 - 1;
+#if 1
+ printf(mmc: setting clock %lu Hz, block size %lu\n,
+hz, blklen);
+#else /* 1 */
pr_debug(mmc: setting clock %lu Hz, block size %lu\n,
hz, blklen);
+#endif /* 1 */
if (clkdiv ~255UL) {
clkdiv = 255;
@@ -84,10 +115,17 @@
}
blklen = 0xfffc;
+
+#if 1 /* AT91SAM9261 does not have RDPROOF and WRPROOF fields. */
mmci_writel(MR, (MMCI_BF(CLKDIV, clkdiv)
+| MMCI_BF(BLKLEN, blklen)));
+#else /* 1 */
+ mmci_writel(MR, (MMCI_BF(CLKDIV, clkdiv)
| MMCI_BF(BLKLEN, blklen)
| MMCI_BIT(RDPROOF)
| MMCI_BIT(WRPROOF)));
+#endif /* 1 */
+
}
#define RESP_NO_CRC1
@@ -99,6 +137,7 @@
#define NCRMMCI_BF(MAXLAT, 1)
#define TRCMD_STARTMMCI_BF(TRCMD, 1)
#define TRDIR_READ MMCI_BF(TRDIR, 1)
+#define TRDIR_WRITEMMCI_BF(TRDIR, 0)
#define TRTYP_BLOCKMMCI_BF(TRTYP, 0)
#define INIT_CMD MMCI_BF(SPCMD, 1)
#define OPEN_DRAIN MMCI_BF(OPDCMD, 1)
@@ -109,6 +148,20 @@
| MMCI_BIT(RINDE) \
| MMCI_BIT(RTOE))
+#if 0
+#define DEBUG
+#else /* 0 */
+#undef DEBUG /* kf - was #undef */
+#endif /* 0 */
+
+#undef pr_debug
+
+#ifdef DEBUG
+#define pr_debug(fmt, args...) printf(fmt, ##args)
+#else
+#define pr_debug(...) do { } while(0)
+#endif
+
static int
mmc_cmd(unsigned long cmd, unsigned long arg,
void *resp, unsigned long flags)
@@ -117,7 +170,9 @@
int i, response_words = 0;
unsigned long error_flags;
u32 status;
-
+#if 1
+ pr_debug(mmc_cmd: entry\n);
+#endif /* 1 */
AT91F_MMC_Hardware_Init();
pr_debug(mmc: CMD%lu 0x%lx (flags 0x%lx)\n,
@@ -161,12
Re: [U-Boot-Users] drivers MMCplus for at91sam9x
Pierre Savary wrote: Thanks a lot for your patch. I will test it next week. Sorry, that patch was manually constructed. I forgot about include/asm-arm/arch-at91sam926x/at91sam9261.h which includes the pin definitions used by the MCI controller. An ancillary patch for this file is appended below. Of course it is useful only for AT91SAM9261 based boards. Note that Atmel used different conventions for defining AT91SAM9261 and AT91SAM9260/AT91SAM9263 hardware (at least for GPIO pin) definitions. This will cause problems in applying the previously posted u-boot-at91sam9261-mmc-v4.patch for boards not based on the AT91SAM9261 (i.e. AT91SAM9260/AT91SAM9263). Note that I added the MMC v4.x code without access to the spec. All I had was a MoviNAND manual, which assumes access to the MMC v4.x spec. (Note that the final CMD1 arg. is the correct and recommended value for MoviNAND chips by their field eng.) The patch included a lot of commented out (/* */ '#if 0') code used to help me understand MMC v4.x, at least well enough to get the MoviNAND working reliably. I never did get multi-block read or write working; The code for it is included in the previous sent patch. As I mentioned before, I also didn't get 4 bit MMC working, but the code for that is _not_ included in the patch anyway. The Linux MMC code enables 4 bit for AT91SAM9260/AT91SAM9263 and only 1 bit for AT91SAM9261. Does anyone know why? I'd really like to get 4 bit transfers working on the 9261 via U-Boot. I may try to put together a better patch using an earlier version of my U-Boot code as a basis. I'm not so sure my previously sent patch will apply as cleanly as I had thought. Have you ever tested your U-Boot with 4GB or 8GB moviNAND? No. Sincerely, Ken Fuchs u-boot-at9261-mci-gpio-pins.patch = svn diff -r21 Index: include/asm-arm/arch-at91sam926x/at91sam9261.h === --- include/asm-arm/arch-at91sam926x/at91sam9261.h (revision 21) +++ include/asm-arm/arch-at91sam926x/at91sam9261.h (working copy) @@ -17,6 +17,10 @@ * Generated : AT91 SW Application Group 03/30/2005 (17:05:06) * * + * (C) Copyright 2007-2008 + * Benchmark Electronics, Inc. + * Added numerous GPIO pin definitions for custom AT91SAM9261 board. + * */ #ifndef AT91SAM9261_H #define AT91SAM9261_H @@ -1330,8 +1334,10 @@ /* * */ #define AT91C_PIO_PA0((unsigned int) 1 0) /* Pin Controlled by PA0 */ #define AT91C_PA0_MISO0((unsigned int) AT91C_PIO_PA0) /* SPI0 Master In Slave */ +#define AT91C_PA0_MCDA0((unsigned int) AT91C_PIO_PA0) /* MMC NAND MCDA0 */ #define AT91C_PIO_PA1((unsigned int) 1 1) /* Pin Controlled by PA1 */ #define AT91C_PA1_MOSI0((unsigned int) AT91C_PIO_PA1) /* SPI0 Master Out Slave */ +#define AT91C_PA1_MCCDA((unsigned int) AT91C_PIO_PA1) /* MMC NAND MCCDA */ #define AT91C_PIO_PA10 ((unsigned int) 1 10) /* Pin Controlled by PA10 */ #define AT91C_PA10_DTXD ((unsigned int) AT91C_PIO_PA10) /* DBGU Debug Transmit Data */ #define AT91C_PA10_LFON((unsigned int) AT91C_PIO_PA10) @@ -1346,6 +1352,7 @@ #define AT91C_PA16_NPCS15 ((unsigned int) AT91C_PIO_PA16) /* GPIO: SPI1 CS5 */ #define AT91C_PIO_PA2((unsigned int) 1 2) /* Pin Controlled by PA2 */ #define AT91C_PA2_SPCK0((unsigned int) AT91C_PIO_PA2) /* SPI0 Serial Clock */ +#define AT91C_PA2_MCCK ((unsigned int) AT91C_PIO_PA2) /* MMC NAND MCCK */ #define AT91C_PIO_PA23 ((unsigned int) 1 23) /* Pin Controlled by PA23 */ #define AT91C_PA23_NPCS14 ((unsigned int) AT91C_PIO_PA23) /* GPIO: SPI1 CS4 */ #define AT91C_PIO_PA24 ((unsigned int) 1 24) /* Pin Controlled by PA24 */ @@ -1358,10 +1365,13 @@ #define AT91C_PA3_NPCS00 ((unsigned int) AT91C_PIO_PA3) /* SPI0 Peripheral Chip Select 0 */ #define AT91C_PIO_PA4((unsigned int) 1 4) /* Pin Controlled by PA4 */ #define AT91C_PA4_NPCS01 ((unsigned int) AT91C_PIO_PA4) /* SPI0 Peripheral Chip Select 1 */ +#define AT91C_PA4_MCDA1((unsigned int) AT91C_PIO_PA4) /* MMC NAND MCDA1 */ #define AT91C_PIO_PA5((unsigned int) 1 5) /* Pin Controlled by PA5 */ #define AT91C_PA5_NPCS02 ((unsigned int) AT91C_PIO_PA5) /* SPI0 Peripheral Chip Select 2 */ +#define AT91C_PA5_MCDA2((unsigned int) AT91C_PIO_PA5) /* MMC NAND MCDA2 */ #define AT91C_PIO_PA6((unsigned int) 1 6) /* Pin Controlled by PA6 */ #define AT91C_PA6_NPCS03 ((unsigned int) AT91C_PIO_PA6) /* SPI0 Peripheral Chip Select 3 */ +#define AT91C_PA6_MCDA3((unsigned int) AT91C_PIO_PA6) /* MMC NAND MCDA3 */ #define AT91C_PIO_PA9((unsigned int) 1 9) /* Pin Controlled by PA9 */ #define AT91C_PA9_DRXD ((unsigned int) AT91C_PIO_PA9) /* DBGU Debug Receive Data */ #define
Re: [U-Boot-Users] drivers MMCplus for at91sam9x
Pierre Savary wrote:
Thanks a lot for your patch. I will test it next week.
I found it useful to modify common/cmd_mmc.c drastically
to facilitate easier testing of the AT91SAM9 MCI driver.
It replaces mmcinit with mmc init and adds raw read
(mmc read) and write (mmc write) functions.
To use it, just apply the (ancillary) patch below.
Sincerely,
Ken Fuchs
--
u-boot-at91sam9261-cmd-mmc-for-testing.patch
svn diff -r21 common/cmd_mmc.c
Index: common/cmd_mmc.c
===
--- common/cmd_mmc.c(revision 21)
+++ common/cmd_mmc.c(working copy)
@@ -1,4 +1,8 @@
/*
+ * (C) Copyright 2007-2008
+ * Benchmark Electronics, Inc.
+ * Split mmcinit into mmc init, mmc read and mmc write
+ *
* (C) Copyright 2003
* Kyle Harris, [EMAIL PROTECTED]
*
@@ -28,19 +32,100 @@
#include mmc.h
+static unsigned int subcmd;
+static unsigned int bstart;
+static unsigned int noblocks;
+static unsigned int address;
+
int do_mmc (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
{
- if (mmc_init (1) != 0) {
- printf (No MMC card found\n);
- return 1;
+unsigned int compblocks;
+
+ if ((flag CMD_FLAG_REPEAT) == 0) {
+ if (argc = 2) {
+ if ((argv[1][0] == 'I' argv[1][1] == 'N'
+ argv[1][2] == 'I' argv[1][3] == 'T')
||
+ (argv[1][0] == 'i' argv[1][1] == 'n'
+ argv[1][2] == 'i' argv[1][3] == 't'))
{
+ subcmd = 0; /* init */
+ } else if ((argv[1][0] == 'R') ||
+ (argv[1][0] == 'r')) {
+ subcmd = 1; /* block read */
+ } else if ((argv[1][0] == 'W') ||
+ (argv[1][0] == 'w')) {
+ subcmd = 2; /* block write */
+ } else if ((argv[1][0] == 'M') ||
+ (argv[1][0] == 'm')) {
+ subcmd = 3; /* multiple block write */
+ } else {
+ printf(Subcommand must be );
+ printf(init, r[ead] or w[rite]\n);
+ return 1;
+ }
+ }
+ if (argc = 3) {
+ bstart = simple_strtoul(argv[2], NULL, 16);
+ }
+ if (argc = 4) {
+ noblocks = simple_strtoul(argv[3], NULL, 16);
+ }
+ if (argc = 5) {
+ address = simple_strtoul(argv[4], NULL, 16);
+ }
}
- return 0;
+ switch (subcmd) {
+ case 0:
+ if (mmc_init(1) != 0) {
+ printf (No MMC card found\n);
+ return 1;
+ }
+ return 0;
+ break;
+ case 1:
+ compblocks = mmc_bread(0, bstart, noblocks, (ulong
*)address);
+ if (compblocks noblocks) {
+ printf(Error reading block#: 0x%08lx\n,
+ bstart + compblocks);
+ }
+ break;
+ case 2:
+ compblocks =
+ mmc_bwrite(0, bstart, noblocks, (ulong
*)address);
+ if (compblocks noblocks) {
+ printf(Error writing block#: 0x%08lx\n,
+ bstart + compblocks);
+ }
+ break;
+ case 3:
+ compblocks =
+ mmc_mbwrite(0, bstart, noblocks, (ulong
*)address);
+ if (compblocks noblocks) {
+ printf(Error writing block#: 0x%08lx\n,
+ bstart + compblocks);
+ }
+ break;
+ }
}
U_BOOT_CMD(
- mmcinit,1, 0, do_mmc,
- mmcinit - init mmc card\n,
- NULL
+ mmc,5, 1, do_mmc,
+ mmc - init, read write to the MMC NAND device\n,
+ \n\nmmc init - initialize the MMC NAND device\n
+ \nmmc r block# #blocks address - block read MMC NAND
blocks\n
+ block# - starting block # (hexidecimal) to read\n
+ #blocks - no. of (512) blocks (hexidecimal) to
read\n
+address - SDRAM/SRAM address (hex.) for read
data\n
+ \nmmc w block# #blocks address - block write MMC NAND
blocks\n
+ block# - starting block # (hexidecimal) to write\n
+ #blocks - no. of (512) blocks (hexidecimal) to
write\n
+address - SDRAM/SRAM address (hex.) of data to
write\n
+#if 0 /* Not working yet, so documentation is removed. */
+ \nmmc m block# #blocks address - multiple block write
mode\n
+ block# - starting block #
Re: [U-Boot-Users] usb write command available in u-boot??
In u-boot under common/cmd_usb.c there are commands for usb info , usb tree, usb reset, I can find usb read command also There is no command for usb write Since a bootloader loads things from boot devices as opposed writing things to boot devices, it makes sense that there would be no write command to boot devices. Is there is possibility to do a usb write command (eg .. writing some data into the flash memory stick) in u-boot level?? Absolutely, but it is potentially dangerous to do. Raw writes of disk images or individual filesystems may be a reasonable thing to do and should require only modest changes to support. Only a block write function would need to be added. This is especially useful if the device is soldered to the board and there is no other way to write the data to the device. Does anyone have a soldered-on USB storage device? Crazy data transfer idea: For simple data transfer, it may be possible to allocate a file on a FAT16 filesystem that uses exactly one cluster and determine the block address of that cluster and instruct U-Boot to write only to that cluster. This would mean that a cluster could be written in raw mode via U-Boot and on another system read as a FAT16 file. The file length would always be a full cluster in size, so the file would need to be copied and truncated to the proper length on the host system. Again, on U-Boot this would require only the addition of a block write function. Writing files to filesystems via U-Boot: The filesystem support in U-Boot is designed to function in a read-only mode, but the code is probably based on a read/write Linux driver, so it may not be that difficult to change to support write functions. The filesystems would need to support file creation, data over-write and file append functions, at a minimum. This would require more work than it would be worth, in my opinion. But a block write function would be useful for some (soldered on) devices, if not USB storage. Sincerely, Ken Fuchs - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 16/18] avr32: Fix two warnings in atmel_mci.c
Haavard Skinnemoen wrote:
The warnings are harmless but annoying. Let's fix them.
If the warnings are harmless, why are you fixing them?
The compiler has switches to turn off warnings, if they
annoy you too much.
Does this refactoring of the code do something more than
just avoid a warning or two? If not, I would reject it.
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED]
---
cpu/at32ap/atmel_mci.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/cpu/at32ap/atmel_mci.c b/cpu/at32ap/atmel_mci.c
index f59dfb5..3ce9ea5 100644
--- a/cpu/at32ap/atmel_mci.c
+++ b/cpu/at32ap/atmel_mci.c
@@ -182,12 +182,13 @@ static int mmc_acmd(unsigned long cmd,
unsigned long arg,
static unsigned long
mmc_bread(int dev, unsigned long start, lbaint_t blkcnt,
- unsigned long *buffer)
+ void *buffer)
{
int ret, i = 0;
unsigned long resp[4];
unsigned long card_status, data;
unsigned long wordcount;
+ u32 *p = buffer;
u32 status;
if (blkcnt == 0)
@@ -225,7 +226,7 @@ mmc_bread(int dev, unsigned long start,
lbaint_t blkcnt,
if (status MMCI_BIT(RXRDY)) {
data = mmci_readl(RDR);
/* pr_debug(%x\n, data); */
- *buffer++ = data;
+ *p++ = data;
wordcount++;
}
} while(wordcount (mmc_blkdev.blksz / 4));
@@ -443,6 +444,7 @@ static void mci_set_data_timeout(struct
mmc_csd *csd)
dtocyc = timeout_clks;
dtomul = 0;
+ shift = 0;
while (dtocyc 15 dtomul 8) {
dtomul++;
shift = dtomul_to_shift[dtomul];
--
1.5.5.1
Sincerely,
Ken Fuchs
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 18/18] avr32: Compile atmel_mci.oconditionally
Haavard Skinnemoen wrote:
Remove #ifdef CONFIG_MMC from the source file and use conditional
compilation in the Makefile instead.
What's wrong with the current code? Why are you doing this?
Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED]
---
cpu/at32ap/Makefile|2 +-
cpu/at32ap/atmel_mci.c |4
2 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/cpu/at32ap/Makefile b/cpu/at32ap/Makefile
index 29f9c0d..d16c58b 100644
--- a/cpu/at32ap/Makefile
+++ b/cpu/at32ap/Makefile
@@ -35,7 +35,7 @@ COBJS-y += exception.o
COBJS-y += cache.o
COBJS-y += interrupts.o
COBJS-y += pio.o
-COBJS-y += atmel_mci.o
+COBJS-$(CONFIG_MMC) += atmel_mci.o
SRCS := $(START-y:.o=.S) $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
OBJS := $(addprefix $(obj),$(SOBJS-y) $(COBJS-y))
diff --git a/cpu/at32ap/atmel_mci.c b/cpu/at32ap/atmel_mci.c
index 226b5c0..3795add 100644
--- a/cpu/at32ap/atmel_mci.c
+++ b/cpu/at32ap/atmel_mci.c
@@ -21,8 +21,6 @@
*/
#include common.h
-#ifdef CONFIG_MMC
-
#include part.h
#include mmc.h
@@ -548,5 +546,3 @@ int mmc2info(ulong addr)
{
return 0;
}
-
-#endif /* CONFIG_MMC */
--
1.5.5.1
Sincerely,
Ken Fuchs
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] boot pc with uboot
With Linux running on your system (or booted via a Live CD like Knoppix): # lspci -vvv That should reveal most of the major chips Device manager on MS Windows may provide similar information. You may have to physically identify on the smaller chips on the board, since they will not be visible in lspci output. Good luck! Sincerely, Ken Fuchs -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jerry Van Baren Sent: Wednesday, May 28, 2008 13:55 To: Soodeh Bakhshandeh Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] boot pc with uboot Soodeh Bakhshandeh wrote: Dear sir I have a problem. I want to boot my pc with uboot. Which work I shold do?what is my roadmap? thanks You need to get the data sheets of all the chips on your board, including any north bridges, south bridges, video chips (assuming you want to support video), memory (flash and SDRAM), and whatever other software programmable parts that are on your board. You need this information in order to properly initialize the hardware. The traditional BIOS does this initialization. Since you desire to replace the BIOS with u-boot, you will have to do the initialization yourself. The big problem is that full hardware documentation is hard to get. Depending on your board and the chips used on it, you might be able to get the documentation, but historically it is a show stopper problem. This may be changing with hardware becoming more open for linux drivers, or maybe you will get lucky... Once you have the documentation, you will need to figure out exactly how your hardware needs to be initialized (registers, values, sequences). Good luck, gvb -- --- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] U-boot and ethernet on a Lubbock board
Victor (pfc) wrote: I've been working last months on a lubbock board and u-boot as a bootloader to run Linux. I always loaded my kernel via serial port, because I never got u-boot to activate my ethernet (I never got the link led on, only after booting Linux). I recently read the FAQ again and found about using valid MAC addresses: * Should I recompile my u-boot with the new local-admin MAC address or just I need to write the new config on the board? To change the MAC addresses, only the environment needs to change as follows ... u-boot setenv ethaddr valid MAC address (eth0) u-boot setenv eth1addr valid MAC address1(eth1) u-boot setenv eth2addr valid MAC address2(eth2) u-boot saveenv Omit references to eth1 or eth2, if they don't exist on your specific board. There is no need to recompile U-Boot. Sincerely, Ken Fuchs - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/3] SDHC Support for AT572d940HF-EB
Signed-off-by: Antonio R. Costa [EMAIL PROTECTED] diff --git a/board/atmel/at572d940hfeb/atmel_mci.c b/board/atmel/at572d940hfeb/atmel_mci.c new file mode 100644 index 000..065a85b --- /dev/null +++ b/board/atmel/at572d940hfeb/atmel_mci.c @@ -0,0 +1,869 @@ +/* + * (C) Copyright 2008 Atmel Corporation + * + * Antonio R. Costa antonio.costa at atmel.com + * costa.antonior at gmail.com The U-Boot AT91 MCI driver is no longer the exclusive work of Atmel. So, I do not believe that a sole Atmel copyright is correct for the AT91 MCI driver. I added MMC 4.x support to the AT91 MCI driver a while back. In response to a request for AT91 MMC 4.x support, I submitted it to the list in the form of an informal patch against u-boot-1.1.5_atmel1.2 on April 29, 2008. Without much effort, I can see that much of the code that I added is still in the various files of the AT91 MCI driver, but my company's copyright has been removed. (Please note that I never removed anyone else's copyright.) I'm not implying that Antonio removed my company's copyright notice, since I don't know exactly when the copyright was removed. However, when someone adds a significant amount of code to a source file of a free software (GNU GPL licensed) project, isn't it a reasonable expectation that their copyright would be respected and thus not removed? Can someone please clarify how copyright of derivative works is handled within the U-Boot source code trees? For example, how much source code needs to be added/modified/removed to justify a copyright notice for the changes? Thanks, Ken Fuchs - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] new to U-Boot, how do I get started for Atmel at91sam9261ek
Vyas Ashish wrote: Hi Group, I have a at91sam9261ek evaluation Kit from Atmel and I want to bring up the UBoot on that. When I got the board, I also got UBoot binary which can be flashed and verified. However, I did not get the source code. The code has to be purchased seperately, which I do not want to do. I want to take up the UBoot porting on this board as a task. Jerry Van Baren wrote: If you received a u-boot binary for that board, you have the right to ask for a copy of the source that generated that u-boot binary and the company that distributed that u-boot binary (apparently Atmel) has the legal obligation to provide that at a reasonable cost to cover their distribution costs. That is all part of the GNU General Public License. http://en.wikipedia.org/wiki/Gpl There are Atmel employees on this list, perhaps they can speak to the issue more directly. Any quick pointer to start with? Do we have some other similar board already supported by UBoot code that I can clone to make things faster? Jerry Van Baren wrote: I received the following email from Ulf - it appears he is struggling with his phone/email and sent it directly to me only, not to the list. The one that really needed it was Vyas. As expected, Vyas just needed to know where to look to get the source. Ulf Samuelsson via Jerry Van Baren wrote: Atmel does not sell GPL source. Check out www.Iinux4sam.org for U-boot source. There is a typo in the above URI. It should be: http://www.linux4sam.org/ A later version will be downloaded when You run buildroot, bul that is not shipped with any systems. Has there not been SAM9261 patches sent in to the git lately? AT91SAM9261-EK should be available by now via git to the AT91 U-Boot git repository: http://git.denx.de/?p=u-boot/u-boot-at91.git;a=summary I'm sure you will be much happier with the improvements of the git at91 code than linux4sam.org whose most current code is still _appears_ to be based on U-Boot 1.2.0. (There is a reference to 1.3.0, saying the port is incomplete.) Sincerely, Ken Fuchs - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/3] SDHC Support for AT572d940HF-EB
On Fri, 13 Jun 2008 16:21:59 -0500 Ken.Fuchs wrote: The U-Boot AT91 MCI driver is no longer the exclusive work of Atmel. So, I do not believe that a sole Atmel copyright is correct for the AT91 MCI driver. I added MMC 4.x support to the AT91 MCI driver a while back. In response to a request for AT91 MMC 4.x support, I submitted it to the list in the form of an informal patch against u-boot-1.1.5_atmel1.2 on April 29, 2008. Without much effort, I can see that much of the code that I added is still in the various files of the AT91 MCI driver, but my company's copyright has been removed. (Please note that I never removed anyone else's copyright.) After further investigation, I no longer believe that my MMC 4.x MCI driver code has been committed to either the u-boot-at91 or u-boot repository. I've found a reasonable explanation for all code similarities that prompted me send my first message on this topic. My apologies to all those involved in ensuring that U-Boot source code complies with the GNU GPL and to the developers of the new U-Boot Atmel MCI driver. Haavard Skinnemoen wrote: Which driver are you talking about? I don't see any AT91 MCI driver in the u-boot tree... u-boot-1.1.5_atmel_1.2/cpu/arm926ejs/at91sam926x/atmel_mci.c On 2008-Apr-29 20:46 UTC, I sent to the u-boot-users mailing list an informal patch based on u-boot-1.1.5_atmel_1.2 and an old cpu/arm926ejs/at91sam926x/atmel_mci.c patch. My patch adds MMC 4.x support to the AT91SAM926x MCI driver in the u-boot-1.1.5_atmel_1.2 tree. However, I was mistaken about my code being committed into the official u-boot tree. Please see my response above. Sincerely, Ken Fuchs - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] eth interface (motfec) is not woring with u-boot1.1.3
vijay vijay wrote: I am using Denx u-boot 1.1.3 for MPC 870 board. I ported it for our board with mpc870 processor and I got the u-boot (-) prompt. UART interface is working fine but Ethernet interface (motfec) is not up yet. ub ping 10.10.10.4 TX timeout TX timeout ping failed; host 10.10.10.4 is not alive There are at least two problems with your U-Boot 1.1.3 configuration: #define CONFIG_ETHADDROO:11:22:33:44:55/* board MAC addr */ The first byte OO is two capital Os; perhaps 00 was the intended first byte of the MAC address?: #define CONFIG_ETHADDR00:11:22:33:44:55/* board MAC addr */ #define CONFIG_IPADDR10:10:10:2/* board IP addr */ The bytes of a v4 IP number must be separated by . (not :): #define CONFIG_IPADDR10.10.10.2/* board IP addr */ Other than the above two suggestions, please try using a U-Boot version more current than 1.1.3, such as 1.3.x. Sincerely, Ken Fuchs - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] eth interface (motfec) is not woring with u-boot1.1.3
Ken Fuchs wrote: There are at least two problems with your U-Boot 1.1.3 configuration: vijays vijays wrote: #define CONFIG_ETHADDROO:11:22:33:44:55 /* board MAC addr */ The first byte OO is two capital Os; perhaps 00 was the intended first byte of the MAC address?: Wolfgang Denx wrote: And of course even 00:11:22:33:44:55 is not a legal MAC address and MUST NOT BE USED. Please see the FAQ. Actually, 00:11:22:33:44:55 is a perfectly legal (universally administered) MAC address: http://standards.ieee.org/regauth/oui/index.shtml Just enter 00-11-22 for the OUI (Organizationally Unique Identifier). In any case, 00-11-22-33-44-55 is an often used as a _locally administered_ MAC address. Such usage is definitely illegal as can be seen by referring to: http://www.denx.de/wiki/view/DULG/WhereCanIGetAValidMACAddress No doubt this is what you were referring to when you said 00:11:22:33:44:55 is not a legal MAC address. A better, easy to remember locally administered MAC address would be 02:03:04:05:06:07. Sincerely, Ken Fuchs - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] eth interface (motfec) is not woring with u-boot1.1.3
Please stop sending HMTL encoded messages to the list.
Please use plain text. (Using plain text is a requirement
for using this mailing list.)
vijays vijays wrote:
I have updated the my configuration for the CONFIG_ETHADDR and
CONFIG_IPADDR
But still getting same TX timeout error. from function
static int fec_send(struct eth_device* dev, volatile void *packet,
int length) in defined in the cpu/mpc8xx/fec.c
-
while ((rtx-txbd[txIdx].cbd_sc BD_ENET_TX_READY)
(jTOUT_LOOP)) {
#if defined(CONFIG_ICU862)
udelay(10);
#else
udelay(100);
#endif
j++;
}
if (j=TOUT_LOOP) {
printf(TX timeout..testing.\n);
}
-
When I am running VxWorks on the same board LEDs at RJ45 connector
(Ethernet interfaces) on the board are glowing but when u-boot is up
these LED are off. It seems that ETH interface is not up yet.
Perhaps, your Ethernet driver is not properly configured. Recheck these
definitions in your include/configs/tc870.h file:
#defineCONFIG_NET_MULTI1 /* the only way to get the FEC in
*/
#defineFEC_ENET1/* eth.c needs it that way... */
#define CONFIG_FEC_ENET 1
#undef CFG_DISCOVER_PHY
#define CONFIG_MII1
#define CONFIG_RMII1 /* use RMII interface */
I would pay special attention to CFG_DISCOVER_PHY. Maybe the wrong
Phy is being configured?
Which board can be used as the reference board for the MPC870.
Maybe someone with experience with Ethernet on the MPC870 can answer?
I don't have a tc870 board or an MPC870, so this is the last
time you'll hear from me on this topic.
Good luck!
Sincerely,
Ken Fuchs
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Need Some Help
Please do not use HTML on this mailing list. All messages to this list must be in plain text. Mondesir, Alshine wrote: My latest endeavor has me cross compiling a stand alone application for MPC8548 PPC for a U-Boot Based target. There is no Operating System to run on the target to speak of, just my application. I'm building the application in Code Warrior using an 8548_init.S hardware initialization file. 1) My first thought was that this should be as simple as using the .ELF image that codewarrior produces, right? So I build a simple hello_world application and sent it down to my target. U-Boot recognizes it as an ELF image, sets up the segments, and tries to run it! But then low and behold, the U-Boot flash image comes up again. = bootelf 40 = bootm 40 How do I go about exporting my code warrior application so that I can run it as stand-alone on a U-Boot based target? Thanks so much I suspect that your application is using a device or resource that neither U-Boot nor your application have properly initialized. What is your display device for your hello_world application? Where is this device initialized? Sincerely, Ken Fuchs - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Running a application in U-Boot
No HTML allowed on this list; Please use plain text messages. Light King (Ansh) wrote: I am working on AT91SAM9263 Customised board having U-boot. I want to run some application on the top of U-boot . I found some command like go to run a application in U-boot. I m trying to run the demo program Hello_world.c provided in the U-Boot source . But after loading that to 0x4 address and executing from 0x40004 address (according to the U-Boot manual) it is not Giving proper Output . Plz any one help me How can I run a stand alone program in U-Boot ? If you don't do a better job of describing your problem, no one is likely to be motivated to help you. One terse paragraph is not enough. What output did you get? What output were you expecting? What version of U-Boot did you build? How did build Hello_world? What exact U-Boot commands did you use to load and run Hello_world? A log of the commands entered into U-Boot and output generated may be helpful. Sincerely, Ken Fuchs - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/1] Add support for ATMELAT91SAM9G20EK board
Jean-Christophe PLAGNIOL-VILLARD wrote: /* choose RMII or MII mode. This depends on the board */ #ifdef CONFIG_RMII #if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || \ -defined(CONFIG_AT91SAM9263) +defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91SAM9G20) macb_writel(macb, USRIO, MACB_BIT(RMII) | MACB_BIT(CLKEN)); #else macb_writel(macb, USRIO, 0); #endif Same comment as Haavard, Could please create a CONFIG_SOMETHING for each of this tree block of ifdef (not necessarily the same CONFIG) What do you suggest for SOMETHING in CONFIG_SOMETHING? Surely you aren't suggesting a literal CONFIG_SOMETHING. The fact that you didn't easily define a meaningful SOMETHING suggests that there isn't one that is sufficiently meaningful and that perhaps the #if condition as written above should remain as is. Code should be written for readability, not for terseness alone. Do we have to define yet another preprocessor constant for yet another purpose? U-Boot already has too many preprocessor constants and the addition of another (perhaps) dubious one merits more debate. Sincerely, Ken Fuchs - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/1] Add support for ATMELAT91SAM9G20EK board
[EMAIL PROTECTED] wrote: U-Boot already has too many preprocessor constants and the addition of another (perhaps) dubious one merits more debate. You omitted the context of this statement and hence most of its meaning. Haavard Skinnemoen wrote: I don't completely agree. U-Boot has too many #ifdefs, which isn't necessarily the same as too many #defines. And I don't think CONFIG_AT91 is dubious at all. Perhaps the CONFIG_* symbols should be defined as TRUE or FALSE rather than defined or not defined. I didn't say CONFIG_AT91 was dubious. I stated that defining CONFIG_SOMETHING where it isn't clear what SOMETHING should be is dubious. If one has to think too hard about what meaningful phrase SOMETHING should be, perhaps CONFIG_SOMETHING should not be defined at all. I'm complaining about defining new preprocessor definitions to be specific aggregations of other definitions just so a developer can type the conditions with fewer keystrokes without any improvement in code readability and maintainability. Sometimes an idiom should be left as an idiom rather than replaced by a preprocessor constant. I have nothing against defining CONFIG_AT91 if it is useful, unique and makes code that uses it easier to understand and maintain. But since we already have a CONFIG_AVR32 #define, we can clean up the mess in macb.c by simply reversing the logic. If CONFIG_AVR32 can be used in macb.c without ofuscation, why is CONFIG_AT91 needed here? However, simply reversing the logic may be too much ofuscation though; we want clear rather than clever code after all. An example of what I'd be opposed to is defining CONFIG_AT91SAM9260_OR_AT91SAM9263 where it is TRUE if either CONFIG_AT91SAM9260 or CONFIG_AT91SAM9263 are TRUE. Can you see where this might be used in the macb.c code? Sincerely, Ken Fuchs - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFC: U-Boot version numbering
Wolfgang Denk wrote: Well, the version 2 prefix is kind of already taken by Sascha Hauers alternative implementation. Should we go for 2.x.x anyway? May I suggest CC.YY.MM? VERSION = Century number PATCHLEVEL = Year number SUBLEVEL = Month number EXTRAVERSION = NULL or special purpose So this month's release number would become 20.08.08. Sincerely, Ken Fuchs - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFC: U-Boot version numbering
Wolfgang Denk wrote: Well, the version 2 prefix is kind of already taken by Sascha Hauers alternative implementation. Should we go for 2.x.x anyway? On Wed, Aug 06, 2008 at 11:47:22AM -0500, Ken Fuchs wrote: May I suggest CC.YY.MM? VERSION = Century number PATCHLEVEL = Year number SUBLEVEL = Month number EXTRAVERSION = NULL or special purpose So this month's release number would become 20.08.08. Scott Wood wrote: Why the extra dot after the century? That looks like August 20th, 2008 in certain date formats. All such date formats that list smaller units (days) before larger units (months or years) such that they don't sort properly are deprecated. And no ability to release more than once a month? The EXTRAVERSION preprocessor symbol can be defined to allow a new release every picosecond, or more often, if necessary. Of course, we *could* base the version number on RFC 2550... :-) To solve the Y10K, Y100K, Y1M, ... problems, the CC in CC.YY.MM shall be defined to be as long as necessary. -- OK, reserving VERSION for Century number may not be such a good idea after all. Here's another suggestion that most may agree with: VERSION =Year number = 2008..10**30-1 PATCHLEVEL = Month number = 1..12 SUBLEVEL = Day number = 1..31 EXTRAVERSION = NULL or special purpose A release on the opening day of the Olympics would be: 2008.08.08 Sincerely, Ken Fuchs - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
