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.
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
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
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.
$ 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
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
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;
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;
--- 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
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
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:
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
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
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 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
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
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
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
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 +-
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
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
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
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
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
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
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
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
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
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
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)
[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
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
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 =
33 matches
Mail list logo
