Re: [U-Boot-Users] [PATCH v4] Add MIMC200 board
Haavard Skinnemoen <[EMAIL PROTECTED]> wrote: > I'll apply this patch and push it upstream during the next merge > window. No need to resend the whole thing -- just send me the > signed-off-by line if you're okay with what it means, and I'll add it > to the patch. The merge window is open. Could you sign off this patch so I can push it upstream, please? Haavard - 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=100&url=/ ___ 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] Allow console input to be disabled
Wolfgang Denk <[EMAIL PROTECTED]> wrote: > Dear Haavard Skinnemoen, > > In message <[EMAIL PROTECTED]> you wrote: > > > > > It may be intended for debug, but it's available there without warning > > > for the end user. > > > > Hang on...end users can compile custom versions of u-boot now? And > > Actually yes, they can. This is what GPL software is all about: > enabling end users to do exactly that. But if it breaks, they get to keep both pieces. > > we're somehow responsible for stopping them from bricking their boards > > when they go and enable options they don't understand? > > No, we aren't. But that was not the statement. > > The problem is the same when the vendor (or whoever is responsible > for setting this option) eneables this feature in a version that will > ship to the end user. > > And that was the intention of the patch, if I understand it correctly? The intention is to allow boards to use a single serial port for two purposes: Communicating with some other device (which will get really confused if u-boot interferes) and as a debug port. The user/developer must have a way to switch between the two roles, and if the first role is selected, u-boot must stay the hell away from the serial port. The user will be able to switch between the two by means of an on-board jumper, so if he needs to interact with u-boot, he can simply flip the jumper and hook up a PC. But I guess there's another side-effect from this patch which is somewhat more nasty: The user can _also_ disable the debug port by simply setting an environment variable. That might be a bad idea, and probably not even necessary for Mark's purposes. So how about introducing a new flag, e.g. GD_FLG_DISABLE_CONSOLE, and use that instead? If set, it will disable both input and output, while GD_FLG_SILENT will just disable console output. > > The board will most likely still boot, so the "end user" can use other > > tools to fix the breakage. > > How should he, now that console access is disabled? Access the flash directly from Linux? > > Then again, maybe this thing deserves its own environment variable? > > "disable_input" or something? > > And how would you then enable it again? Without being able to input > anything? Ok, maybe controlling this via an environment variable is a bad idea. > > It certainly deserves to be mentioned in README, as I noted before. > > The more we discuss about this, the more I tend to simply reject it. We still need a solution to Mark's problem though. Haavard - 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=100&url=/ ___ 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] Allow console input to be disabled
Wolfgang Denk <[EMAIL PROTECTED]> wrote: > Dear Jerry Van Baren, > > In message <[EMAIL PROTECTED]> you wrote: > > > > For what it is worth, I'm with Haavard - it seems useful. WRT the > > dangerous part - it's intended use is for debug, so presumably it will > > It may be intended for debug, but it's available there without warning > for the end user. Hang on...end users can compile custom versions of u-boot now? And we're somehow responsible for stopping them from bricking their boards when they go and enable options they don't understand? How about CONFIG_SKIP_LOW_LEVEL_INIT then? That's _certainly_ dangerous if you don't know what you're doing. > > be the developer that locks himself out of the console and will have the > > tools to break back in. From that POV, it isn't any more dangerous than > > all the other ways a user/developer can brick a board (starting with > > erasing flash ;-). > > I think this one is a bit nastier. It's like this rope hanging out of > a black box labeled "silencer". The label doesn't mention that it > goes "KABM!" first, before there is a big silence (and a cloud of > dust and a pile of debris). The board will most likely still boot, so the "end user" can use other tools to fix the breakage. Then again, maybe this thing deserves its own environment variable? "disable_input" or something? It certainly deserves to be mentioned in README, as I noted before. Haavard - 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=100&url=/ ___ 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] Allow console input to be disabled
Mark Jackson <[EMAIL PROTECTED]> wrote: > Added CONFIG_SILENT_CONSOLE_INPUT define. > > When used (in conjunction with CONFIG_SILENT_CONSOLE) it disables all console > input. Does anyone have an opinion about this? I think it's a nice thing to have. Although you should probably update README as well, explaining what this define means. Haavard - 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=100&url=/ ___ 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 v4] Add MIMC200 board
Mark Jackson <[EMAIL PROTECTED]> wrote:
> The MIMC200 board is based on Atmel's NGW100 dev kit, but with an extra
> 8MByte FLASH and 128KByte FRAM.
Looks good to me. If you add a signed-off-by line as per
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches
I'll apply this patch and push it upstream during the next merge
window. No need to resend the whole thing -- just send me the
signed-off-by line if you're okay with what it means, and I'll add it
to the patch.
> + /* are we suppressing the console ? */
> + if (gpio_get_value(GPIO_PIN_PE21) == 1)
> + {
> + gd->flags |= GD_FLG_SILENT;
> + }
I'll remove these braces too.
Thanks,
Haavard
-
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=100&url=/
___
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 v2 1/1] avr32: add support for EarthLCD Favr-32 board
Hans-Christian Egtvedt <[EMAIL PROTECTED]> wrote: > This patch adds support for the Favr-32 board made by EarthLCD. > > This kit, which is also called ezLCD-101 when running with EarthLCD firmware, > has a 10.4" touch screen LCD panel, 16 MB 32-bit SDRAM, 8 MB parallel flash, > Ethernet, audio out, USB device, SD-card slot, USART and various other > connectors for cennecting stuff to SPI, I2C, GPIO, etc. > > Signed-off-by: Hans-Christian Egtvedt <[EMAIL PROTECTED]> > --- > The board will so far need to have a flash driver, since the CFI driver does > not work for the time being. HÃ¥vard said he might look into it soon, and this > board will be updated when the CFI driver can handle AT49BV6416 devices (and > that family). Nice and self-contained. Applied to a new "favr-32" branch and merged into the "next" branch, thanks. It obviously conflicted with the hammerhead stuff, but it was trivial to resolve. Now, I'm not entirely happy about the duplicated flash driver, but I guess removing two drivers instead of one after we fix the CFI driver isn't going to make that much of a difference. Haavard - 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=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Comments to the patch
Rafael Campos <[EMAIL PROTECTED]> wrote: > El mié, 30-07-2008 a las 14:25 +0200, Stefan Roese escribió: > > BTW: Did you test this patch with other FLASH chips too (Intel, > > Spansion ...)? > > Or only the Atmel one? > > Only with the ATMEL one (AT49BV6416), which is the only one that i have > access to. But i checked several other ATMEL flash datasheets and said > that they start in read-only mode. Of course they start in read-only mode -- it's flash after all ;-) But I don't think all Atmel flash needs this treatment. AT49BV6416 is kinda special -- the replacement, AT49BV642D does not need this. The ones using Intel command set usually do need to be unlocked, but this is standard behaviour for Intel-compatible flash I think. Btw, also note that since the CFI driver only reads the low 8 bits of the device ID, there's currently no way to tell AT49BV6416 and AT49BV642D apart. Or at least it wasn't last time I checked. So I think this needs fixing first. Oh, and you also need to reverse the erase regions reported by this chip. Haavard - 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=100&url=/ ___ 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 v2] cmd_bdinfo: Fix printf() format warning
Haavard Skinnemoen <[EMAIL PROTECTED]> wrote: > Fix the following warning on avr32 and, from the looks of it, all other > architectures except arm, blackfin and mips. > > cmd_bdinfo.c: In function 'do_bdinfo': > cmd_bdinfo.c:367: warning: format '%d' expects type 'int', but argument > 2 has type 'long unsigned int' Ah, bugger. I completely misparsed that file -- do_bdinfo is supposed to be arch-specific, but avr32 uses the same implementation as MIPS for some arbitrary reason. So this patch just makes things worse. Please ignore. I'll fix it some other way. Btw, how about moving this stuff into an arch-specific file? lib_/bdinfo.c for example? Haavard - 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=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH v2] cmd_bdinfo: Fix printf() format warning
Fix the following warning on avr32 and, from the looks of it, all other
architectures except arm, blackfin and mips.
cmd_bdinfo.c: In function 'do_bdinfo':
cmd_bdinfo.c:367: warning: format '%d' expects type 'int', but argument
2 has type 'long unsigned int'
In order to not introduce new warnings on the aforementioned three
architectures as well as i386, I changed the type of the bi_baudrate
field to be unsigned long so that all architectures are consisten. This
may break some really questionable code (highly unlikely) and/or
introduce new format warnings elsewhere (somewhat more likely), but if
so, it needs fixing anyway.
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
Cc: Jean-Christophe Plagniol-Villard <[EMAIL PROTECTED]>
Cc: Mike Frysinger <[EMAIL PROTECTED]>
Cc: Shinya Kuribayashi <[EMAIL PROTECTED]>
---
Cc'ed the maintainers of the affected architectures except i386.
Does anyone know who's in charge of the i386 port? The chances of
breakage on i386 is lower than on the other three architectures since
the field is unsigned to begin with, and is wedged between two other
unsigned longs, so it shouldn't cause any changes to the struct layout
even on x86_64.
common/cmd_bdinfo.c |2 +-
include/asm-arm/u-boot.h |2 +-
include/asm-blackfin/u-boot.h |2 +-
include/asm-i386/u-boot.h |2 +-
include/asm-mips/u-boot.h |2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/common/cmd_bdinfo.c b/common/cmd_bdinfo.c
index 24ff9b9..b38f43c 100644
--- a/common/cmd_bdinfo.c
+++ b/common/cmd_bdinfo.c
@@ -364,7 +364,7 @@ int do_bdinfo ( cmd_tbl_t *cmdtp, int flag, int argc, char
*argv[])
}
puts ("\nip_addr = ");
print_IPaddr (bd->bi_ip_addr);
- printf ("\nbaudrate= %d bps\n", bd->bi_baudrate);
+ printf ("\nbaudrate= %lu bps\n", bd->bi_baudrate);
return 0;
}
diff --git a/include/asm-arm/u-boot.h b/include/asm-arm/u-boot.h
index b11d555..8c739ff 100644
--- a/include/asm-arm/u-boot.h
+++ b/include/asm-arm/u-boot.h
@@ -37,7 +37,7 @@
#define _U_BOOT_H_ 1
typedef struct bd_info {
-intbi_baudrate;/* serial console baudrate */
+unsigned long bi_baudrate;/* serial console baudrate */
unsigned long bi_ip_addr; /* IP Address */
unsigned char bi_enetaddr[6]; /* Ethernet adress */
struct environment_s *bi_env;
diff --git a/include/asm-blackfin/u-boot.h b/include/asm-blackfin/u-boot.h
index 9d2903b..a3907ec 100644
--- a/include/asm-blackfin/u-boot.h
+++ b/include/asm-blackfin/u-boot.h
@@ -29,7 +29,7 @@
#define _U_BOOT_H_ 1
typedef struct bd_info {
- int bi_baudrate;/* serial console baudrate */
+ unsigned long bi_baudrate; /* serial console baudrate */
unsigned long bi_ip_addr; /* IP Address */
unsigned char bi_enetaddr[6]; /* Ethernet adress */
unsigned long bi_boot_params; /* where this board expects params */
diff --git a/include/asm-i386/u-boot.h b/include/asm-i386/u-boot.h
index fc5a2ae..1276e39 100644
--- a/include/asm-i386/u-boot.h
+++ b/include/asm-i386/u-boot.h
@@ -50,7 +50,7 @@ typedef struct bd_info {
unsigned short bi_ethspeed;/* Ethernet speed in Mbps */
unsigned long bi_intfreq; /* Internal Freq, in MHz */
unsigned long bi_busfreq; /* Bus Freq, in MHz */
- unsigned intbi_baudrate;/* Console Baudrate */
+ unsigned long bi_baudrate;/* Console Baudrate */
unsigned long bi_boot_params; /* where this board expects params */
struct environment_s *bi_env;
struct /* RAM configuration */
diff --git a/include/asm-mips/u-boot.h b/include/asm-mips/u-boot.h
index 9ecb9ac..c40afd7 100644
--- a/include/asm-mips/u-boot.h
+++ b/include/asm-mips/u-boot.h
@@ -32,7 +32,7 @@
#define _U_BOOT_H_ 1
typedef struct bd_info {
- int bi_baudrate;/* serial console baudrate */
+ unsigned long bi_baudrate;/* serial console baudrate */
unsigned long bi_ip_addr; /* IP Address */
unsigned char bi_enetaddr[6]; /* Ethernet adress */
unsigned long bi_arch_number; /* unique id for this board */
--
1.5.6.3
-
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=100&url=/
___
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] cmd_bdinfo: Fix printf() format warning
Wolfgang Denk <[EMAIL PROTECTED]> wrote: > > In order to not introduce new warnings on the aforementioned three > > architectures as well as i386, I added a cast to unsigned long. This > > should be safe even if bi_baudrate is declared as 'int' (assuming > > there's no such thing as negative baud rates.) > > Instead of the cast, should we not rather fix ARM, BF and MIPS to use > ulong like anybody else? Yeah, that's probably better. But I don't know what sort of side effects that kind of change might cause. There could be code somewhere that needs bi_baudrate to be signed for some obscure reason. But if you're ok with it and people are willing to test, I can certainly make that change. Haavard - 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=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] cmd_bdinfo: Fix printf() format warning
Fix the following warning on avr32 and, from the looks of it, all other
architectures except arm, blackfin and mips.
cmd_bdinfo.c: In function 'do_bdinfo':
cmd_bdinfo.c:367: warning: format '%d' expects type 'int', but argument
2 has type 'long unsigned int'
In order to not introduce new warnings on the aforementioned three
architectures as well as i386, I added a cast to unsigned long. This
should be safe even if bi_baudrate is declared as 'int' (assuming
there's no such thing as negative baud rates.)
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
common/cmd_bdinfo.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/cmd_bdinfo.c b/common/cmd_bdinfo.c
index 24ff9b9..57c673c 100644
--- a/common/cmd_bdinfo.c
+++ b/common/cmd_bdinfo.c
@@ -364,7 +364,7 @@ int do_bdinfo ( cmd_tbl_t *cmdtp, int flag, int argc, char
*argv[])
}
puts ("\nip_addr = ");
print_IPaddr (bd->bi_ip_addr);
- printf ("\nbaudrate= %d bps\n", bd->bi_baudrate);
+ printf ("\nbaudrate= %lu bps\n", (unsigned long)bd->bi_baudrate);
return 0;
}
--
1.5.6.2
-
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=100&url=/
___
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] Add support for the hammerhead (AVR32) board
Haavard Skinnemoen <[EMAIL PROTECTED]> wrote: > From: Julien May <[EMAIL PROTECTED]> > > The Hammerhead platform is built around a AVR32 32-bit microcontroller > from Atmel. It offers versatile peripherals, such as ethernet, usb > device, usb host etc. Since I didn't receive any explanation of why it's bad with two maintainers, I've applied this as-is to my 'next' branch: git://git.denx.de/u-boot-avr32.git next I intend this to be a fairly stable branch which will normally not be rebased. Since the patches aren't applied there until they have been fully reviewed, it's unlikely that anything needs fixing once it's been applied. Mistakes do of course happen, so I'm not saying that I will _never_ rebase the tree, I'm just saying that I will try my best not to. I'm also going to try out a 'topic branch' strategy so that even if the history does get mangled, the commit IDs of the unaffected topics will be stable as I just re-pull the topic branches after fixing whatever it is that needs fixing. Currently, my tree has two topic branches: 'eth-cleanup' and 'hammerhead', but I expect at least two more boards to join in before the next merge window. So if you need to pull something from 'next', please try pulling a topic branch as it is more likely to stay stable than the 'next' branch itself. When the next merge window opens, I'll pull all the topic branches into 'master'. Or perhaps it's better to just pull the 'next' branch. I'm not really sure about this. I'd appreciate some feedback from other maintainers on whether or not you think this sounds like a good plan. Haavard - 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=100&url=/ ___ 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] avr32: add support for EarthLCD Favr-32 board
"Ben Warren" <[EMAIL PROTECTED]> wrote: > > diff --git a/board/earthlcd/favr-32-ezkit/flash.c > > b/board/earthlcd/favr-32-ezkit/flash.c > > Is this flash CFI-compliant? If so, please use the CFI driver. > Otherwise, ignore me. Yeah, it should be. But I suspect it's a AT49BV6416 chip (same as on ATSTK1000), which currently doesn't work with the CFI driver. I happen to know exactly why it doesn't work, so maybe it's time to get it fixed...I don't really want to add another custom flash driver. Haavard - 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=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [GIT PULL] avr32 fixes for 1.3.4
Hi Wolfgang, Please pull my 'master' branch: git://git.denx.de/u-boot-avr32 master to receive the following fixes. Haavard Skinnemoen (5): avr32: asm/io.h needs asm/types.h avr32: Fix printf() format warnings atmel_mci: Fix printf() format warnings spi flash: Fix printf() format warnings Merge branch 'format-warnings' of git://git.denx.de/u-boot-avr32 board/atmel/atngw100/atngw100.c |2 +- board/atmel/atstk1000/atstk1000.c |2 +- board/atmel/atstk1000/flash.c |2 +- drivers/mmc/atmel_mci.c | 16 drivers/mtd/spi/atmel.c |6 +++--- include/asm-avr32/io.h|2 ++ include/asm-avr32/sysreg.h|6 -- 7 files changed, 20 insertions(+), 16 deletions(-) - 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=100&url=/ ___ 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] Re-Submit: Add support for ATMEL AT91SAM9G20EK board.
"Ben Warren" <[EMAIL PROTECTED]> wrote: > >> >> extern int macb_eth_initialize(int id, void *regs, unsigned int > >> >> phy_addr); > > > > We're getting more and more of these. Does anyone know an appropriate > > header to put it in? > > > At one point I had a netdev.h file, but removed it because it only > contained this type of definition. Maybe it's time to resurrect. Yeah, perhaps that would be nice. I get the feeling this isn't the only instance of this kind of thing: ~/work/u-boot/upstream$ find -name '*.c' | xargs grep '^extern' | wc -l 1042 All of those instances are potentially dangerous. The macb_eth_initialize() thing has certainly blown up in my face before... Btw, shouldn't board_eth_init() and cpu_eth_init() be declared in some header file as well? It might catch the wrong function definitions you've pointed out quite a few times already. Haavard - 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=100&url=/ ___ 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] Re-Submit: Add support for ATMEL AT91SAM9G20EK board.
"Hong Xu" <[EMAIL PROTECTED]> wrote: > >> or something like this. I don't know if AT91_BASE_EMAC is visible > >> from this code, so you may need to modify slightly. > > Can we do a cpu_eth_init instead? > Not all arm926ejs series have built-in ethernet controller (e.g. > AT91SAM9261 does not have). If we do it in cpu_eth_init, we may need > other more #ifdef_s to distinguish. :-) In _my_ opinion, I think it's much cleaner to just let the board code decide which and how many ethernet controllers to initialize instead of having some #ifdef maze in the CPU code. But it's not may call. Oh, and another thing... > >> extern int macb_eth_initialize(int id, void *regs, unsigned int phy_addr); We're getting more and more of these. Does anyone know an appropriate header to put it in? Haavard - 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=100&url=/ ___ 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] Add MIMC200 board - now uses board_eth_init()
Mark Jackson <[EMAIL PROTECTED]> wrote:
> The MIMC200 board is based on Atmel's NGW100 dev kit,
> but with an extra 8MByte FLASH and 128KByte FRAM.
Do you have a link with some more information about the board?
I also think your mailer mangles whitespace. Thunderbird can apparently
be fixed; please see the instructions here:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/email-clients.txt
> board/atmel/mimc200/Makefile | 40 +
> board/atmel/mimc200/config.mk |3 +
> board/atmel/mimc200/mimc200.c | 158
> board/atmel/mimc200/u-boot.lds | 73 +
Is this really an Atmel board? Note that the directory under "board" is
supposed to indicate the _board_ vendor, not the chip vendor.
> --- a/cpu/at32ap/at32ap700x/clk.c
> +++ b/cpu/at32ap/at32ap700x/clk.c
> @@ -65,4 +65,12 @@ void clk_init(void)
> /* Use PLL0 as main clock */
> sm_writel(PM_MCCTRL, SM_BIT(PLLSEL));
> #endif
> +
> +#ifdef CONFIG_MIMC200
> +// enable gclk outputs
> +//AVR32_PM.gcctrl[0] = 0x0004; /* LVDS at 10MHz */
> +sm_writel(PM_GCCTRL, 0x0004);
> +//AVR32_PM.gcctrl[1] = 0x0216; /* Ethernet at 25MHz if PLL running */
> +//sm_writel(PM_GCCTRL + 4, 0x0216);
> +#endif
Please define a gclk_init() function in your board file and move this
stuff there. That's what Hammerhead ended up doing.
The gclk_init() hook isn't in mainline yet. I'll create a "next" branch
that you can base your work on in the mean time.
> +#ifndef CONFIG_MIMC200
> gpio_select_periph_A(GPIO_PIN_PC18, 0);/* SPD*/
> #endif
> +#endif
> }
>
> void gpio_enable_macb1(void)
> @@ -129,8 +131,10 @@ void gpio_enable_macb1(void)
> gpio_select_periph_B(GPIO_PIN_PC29, 0);/* RXD2*/
> gpio_select_periph_B(GPIO_PIN_PC30, 0);/* RXD3*/
> gpio_select_periph_B(GPIO_PIN_PC24, 0);/* RXCK*/
> +#ifndef CONFIG_MIMC200
> gpio_select_periph_B(GPIO_PIN_PD15, 0);/* SPD*/
> #endif
> +#endif
I'd prefer a more generic define here...or possibly some sort of
parameter that can be passed from the board code. Let's leave that for
later though -- this is fine for now.
> +#ifdef CONFIG_MIMC200
> +// setup Data Flash chip select (NCS2)
> +hsmc3_writel(MODE2, 0x20121003);
> +hsmc3_writel(CYCLE2, 0x000a0009);
> +hsmc3_writel(PULSE2, 0x0a060806);
> +hsmc3_writel(SETUP2, 0x00030102);
> +
> +// setup FRAM chip select (NCS3)
> +hsmc3_writel(MODE3, 0x10120001);
> +hsmc3_writel(CYCLE3, 0x001e001d);
> +hsmc3_writel(PULSE3, 0x08040704);
> +hsmc3_writel(SETUP3, 0x02050204);
> +#endif
Hmm, ok, I guess you currently don't have much choice but put to those
here. Let's make a mental note that this should be improved later.
> void serial_putc(char c)
> {
> +#if defined(CONFIG_MIMC200_DBGLINK)
> +// only output serial data if DEBUG link connected
> +// this is connected to PIOE_21
> +if (gpio_get_value(GPIO_PIN_PE21) == 0)
> +{
> +#endif
As others have noted, this is pretty ugly. There must be a better way
to do this...but I don't know exactly how. Moving this test to a
separate function and providing a dummy stub for the case when
CONFIG_MIMC200_DBGLINK is not set might be a good first step. Something like
#if defined(CONFIG_MIMC200_DBGLINK)
static int usart_is_disabled(void)
{
return gpio_get_value(GPIO_PIN_PE21) != 0;
}
#else
static int usart_is_disabled(void)
{
return 0;
}
#endif
then you can simply do
void serial_putc(char c)
{
if (usart_is_disabled())
return;
/* do the usual stuff here */
}
Alternatively, we could do some tricks involving weak functions here
and move the actual test into the board code.
Thanks for posting this, but please Cc me when posting new avr32 board
patches. I think I missed you first submission.
Haavard
-
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=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
Kumar Gala <[EMAIL PROTECTED]> wrote: > But I agree, in general I would hope u-boot would be able to still > boot w/o the device tree information (might be crippled, but you could > recover). How about keeping a "fail-safe" blob around somewhere? Haavard - 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=100&url=/ ___ 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 ATMELAT91SAM9G20EKboard
"Hong Xu" <[EMAIL PROTECTED]> wrote: > The point is I'm not sure all AT91 series will behave the same way. > But since AVR32 has less cases, it's a good idea to use #else to > handle AT91 variants. So at least till now, this patch makes sense. When I said "let's stop the overengineering", I meant let's not attempt to handle cases that don't exist yet :-) If there turns out to be lots of differences within chip families, we should probably consider handling it some other way than through adding lots of #ifdefs. For example by adding a macb_set_usrio() hook in an arch/platform/chip/whatever-specific file. But until we actually _need_ that, I think we should go for the simplest solution possible. Note that AT91 boards that don't actually have ethernet, or use some other implementation, are not interesting in this context since they shouldn't enable the macb driver in the first place. Haavard - 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=100&url=/ ___ 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 ATMELAT91SAM9G20EKboard
"Hong Xu" <[EMAIL PROTECTED]> wrote: > Per J's suggestion, use CONFIG_MACB_INCLK or some other thing to > simplify the *big* ifdef in driver/net/macb.c > From the existing code, it seems that some boards (AT91CAP9, > AT91SAM926[0,3]) need the CLKEN bit of EMAC_USRIO to be set, but > others(if exist) do not need to. So in all boards that need this bit > to be set, use a new CONFIG_MACB_XXX to denote this. The problem is that CONFIG_MACB_INCLK is a completely nonsensical name. The difference isn't _only_ the CLKEN bit, it's the MII/RMII bit polarity as well. So if we want a completely "meaningful" define, we have to use something along the lines of CONFIG_MACB_HAS_CLKEN_AND_RMII_IS_ACTIVE_HIGH. Let's stop the overengineering already. How about the patch below? Haavard ===[cut here]=== >From c63fe984e1a8d18c83119bbc3c575ac5175e61af Mon Sep 17 00:00:00 2001 From: Haavard Skinnemoen <[EMAIL PROTECTED]> Date: Mon, 28 Jul 2008 11:12:33 +0200 Subject: [PATCH] macb: Simplify AT91 vs AVR32 #ifdefs The AT91 and AVR32 platforms assign different meanings to the bits in USRIO. Until now, this has been handled with two big #ifdefs listing all the various AT91 variants, with the #else branch handling AVR32. Since there's no catch-all CONFIG_AT91 define, switch the #ifdefs around and use CONFIG_AVR32 instead. The result is identical to what we already have, assuming all AT91 devices behave the same way. Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]> --- drivers/net/macb.c | 14 ++ 1 files changed, 6 insertions(+), 8 deletions(-) diff --git a/drivers/net/macb.c b/drivers/net/macb.c index aa39284..49e81d9 100644 --- a/drivers/net/macb.c +++ b/drivers/net/macb.c @@ -414,18 +414,16 @@ static int macb_init(struct eth_device *netdev, bd_t *bd) /* choose RMII or MII mode. This depends on the board */ #ifdef CONFIG_RMII -#if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || \ -defined(CONFIG_AT91SAM9263) - macb_writel(macb, USRIO, MACB_BIT(RMII) | MACB_BIT(CLKEN)); -#else +#ifdef CONFIG_AVR32 macb_writel(macb, USRIO, 0); -#endif #else -#if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || \ -defined(CONFIG_AT91SAM9263) - macb_writel(macb, USRIO, MACB_BIT(CLKEN)); + macb_writel(macb, USRIO, MACB_BIT(RMII) | MACB_BIT(CLKEN)); +#endif #else +#ifdef CONFIG_AVR32 macb_writel(macb, USRIO, MACB_BIT(MII)); +#else + macb_writel(macb, USRIO, MACB_BIT(CLKEN)); #endif #endif /* CONFIG_RMII */ -- 1.5.6.2 - 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=100&url=/ ___ 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 ATMELAT91SAM9G20EKboard
"Hong Xu" <[EMAIL PROTECTED]> wrote: > > maybe we can use config related to the functionnality or the sub-class > > CPU > > ex : > > CONFIG_MACB_INCLK > > Agree. > > We can use "#if defined(CONFIG_AT91) && defined(CONFIG_MACB)" in > net/eth.c and "#ifdef CONFIG_MACB_INCLK" in drivers/net/macb.c to > simplify the previous *big* #ifdef. > If everyone feels comfortable, I'll rewrite these parts and re-submit the > patch. What does CONFIG_MACB_INCLK mean? Haavard - 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=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Changing u-boot relocation scheme
On Sat, 26 Jul 2008 14:29:35 -0700 "J. William Campbell" <[EMAIL PROTECTED]> wrote: > Haavard Skinnemoen wrote: > > On Fri, 25 Jul 2008 22:51:09 +0200 > > kenneth johansson <[EMAIL PROTECTED]> wrote: > >> Can't see any reason for using this flag over -fPIC for a program like > >> u-boot. > >> > > > > You need both. One is a compiler flag, the other is a linker flag. The > > linker will probably barf if you try to create a PIC executable from > > modules that were not compiled with -fPIC. > > > No, it won't. On some platforms it will. Text relocations are nasty, so some platforms (e.g. avr32) just refuse to deal with them. But that's not really relevant -- each architecture should decide whether to compile with -fPIC or not. > You just get a module with a lot more relocations to do. I > have verified that all four possible combinations of the compiler -fPIC > and linker -pie work and make sense. FWIW, -fPIC code on IA32 is about > 16% larger than non-PIC code, while on the Blackfin, -fPIC code is about > 2% larger than non-PIC code. This is an average over several large C++ > applications. Right...that's counting the whole loadable image or just the .text section? Not suprising that a modern architecture like Blackfin likes -fPIC a lot better than an old beast like i386 though. > I agree with this suggestion. This is the only way to ensure a "sane" > environment, because it emulates what the compiler expects to happen. > Looping over all the relocation entries and doing the "right thing" is > architecture specific, but the process is general. The GOT entries can > also be processed this way. Effort spent on this approach will tend to > be more generic than the current PPC specific approach. Right...I think the GOT entries already are processed this way, sort of. > > Ah, of course. The strings are probably read directly from flash. > > > Maybe not. I have been looking at assembly dumps of short examples on > the IA32 built with -fPIC. It is clear that the method of addressing > static variables and static constants is DIFFERENT from the method used > for global variables. The relationship of the location of the text > segment (executable code), the GOT data, and the static > variables/constants must remain fixed. The location of the entire > program can move, but it must move in one piece. If it does move as one > piece, the lea (load effective address) instructions relative to the GOT > pointer will be relocated to the new address correctly. These references > are based totally on the offset from the point of reference. If the code > is similar on your platform (which I bet it is), then the reference will > not be to the flash but rather the "new" place where the data was > moved.. Yes, address calculations in the code should be correct, as the whole thing was compiled with -fPIC. Data references, however, are usually not. The code being discussed here is an array of pointers to strings. I'm pretty sure the pointers are still pointing to flash after relocation. > Global variables, however are referenced indirectly via 32 bit > address pointers in the GOT, and these addresses must be relocated by > the "loader". The global variables themselves are accessed through the GOT, yes. But the _value_ of a global variable is currently not relocated automatically. > The "loader" also must relocate any initialized pointers, because the > program itself does not. It would be interesting to know how this is > accomplished, via what relocation codes, but it does happen. This is what's currently being done manually by adding a fixed offset to all the pointers we "know" need to be relocated. When linking with -pie, these initialized pointers will get a dynamic relocation entry each so that we can replace all these manual fixups by simply iterating over the relocations. To summarize: Address calculations in executable code do not need to change since we already compile with -fPIC. Initialized pointers, however, are currently handled in a very suboptimal way, and linking with -pie might be one piece of the solution to this. Haavard - 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=100&url=/ ___ 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
On Fri, 25 Jul 2008 17:44:52 -0500 <[EMAIL PROTECTED]> wrote: > > 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. Reversing the logic wouldn't obfuscate anything. The code in question is a simple matter of "AT91 needs to do it this way, AVR32 needs to do it another way". Whether we check for AT91 or AVR32 is completely arbitrary. > 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. I completely agreee with this. > Can you see where this might be used in the macb.c code? Not really, no. The processors aren't _that_ different. It's a bit unfortunate that the USRIO register ended up with different behaviour on AT91 and AVR32, but fixing the silicon at this point would just make things worse, and IMO it's not a huge deal. From a CPP abuse point of view, the macb driver is IMO exceptionally clean compared to a lot of other code in u-boot. Haavard - 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=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Changing u-boot relocation scheme
On Sat, 26 Jul 2008 07:36:35 +0200 Wolfgang Denk <[EMAIL PROTECTED]> wrote: > n message <[EMAIL PROTECTED]> you wrote: > > > > Ok, I'll stop the chest-beating now. But please stop trying to tell > > people that adding a powerpc-specific option (which nobody seems to > > know how really works) to the command line will work on any other > > architectures than powerpc. > > OK - then please you explain exactly which other architectures have > problems with relocation? Well, AVR32 doesn't exactly have a _problem_ with relocation except that it relies on a handful of manual fixups for initialized pointers. >From a quick scan, Blackfin, m68k, MIPS, PPC and SPARC also rely on this. While it does work, it is somewhat fragile and requires people writing new code to know about this particular quirk if they want to use statically initialized pointers. Also, as was shown elsewhere in this thread, quite a few strings are being accessed directly from flash even after relocating to RAM. This could at least in theory interfere with the flash driver due to cache effects. So I'm a bit concerned that if PowerPC introduces its own method of relocating these data pointers, the code used on other platforms would get less exposure and therefore be more susceptible to bugs. Ideally, all platforms should do relocation the same way, and that necessarily means using standard methods like ELF dynamic relocations. Haavard - 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=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Changing u-boot relocation scheme
On Fri, 25 Jul 2008 22:51:09 +0200 kenneth johansson <[EMAIL PROTECTED]> wrote: > > Hmm...looks like linking with -pie (or --pic-executable) does > > something vaguely resembling the trick. But I don't know what vintage > > of ld you need for this to be available and actually work... > > Can't see any reason for using this flag over -fPIC for a program like > u-boot. You need both. One is a compiler flag, the other is a linker flag. The linker will probably barf if you try to create a PIC executable from modules that were not compiled with -fPIC. On the other hand, using -fPIC but not -pie takes us about 95% of the way to a fully relocatable u-boot, and is what PowerPC, AVR32 and others are doing today. The remaining cases -- static and global initialized pointers -- are fixed up manually. If we link with -pie and add a bit of code to handle the dynamic relocations, we could get rid of the manual fixups. I don't know if the result would be larger or smaller than what we have today, but it would probably be a bit more robust. > > Does this really work without any relocation? Or is it being relocated > > and I'm just too blind to see it? > > No you are right there is probably many places like this. the code just > use the old location and that works most of the time. Ah, of course. The strings are probably read directly from flash. Haavard - 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=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Changing u-boot relocation scheme
On Fri, 25 Jul 2008 11:21:12 -0400 Jerry Van Baren <[EMAIL PROTECTED]> wrote: > The relocation information is in the ELF file until and unless we remove > it. "Normal" ELF executables retain that relocation information... that > is exactly what the "L" (it) is for. The linux loader (elf loader) > loads an executable into an arbitrary memory location and relocates it > by fixing up addresses based on the relocation table. You're mixing two different relocation tables. Statically linked executables (like u-boot) normally don't have any relocation information in them after they are fully linked. Dynamically linked executables, position-independent executables (PIE) and shared libraries have dynamic relocations which are not only in the ELF file, but in a loadable segment so that they can be accessed at run time. The relocation information from the .o files are not preserved in the final executable unless you specify the --emit-relocs flags, which exists purely for debugging purposes. The relocations used by the dynamic loader come from an entirely different, simpler set of relocation types which are normally not found in .o files. Why do you think objdump has two different options for dumping normal (-r) vs. dynamic (-R) relocations? And no, Linux ELF executables can _not_ be loaded into an arbitrary memory location unless they are PIE. Shared libraries, however, can be loaded at arbitrary memory locations, though things like pre-linking might make it more optimal to try to place them at the same address everywhere. Ok, I'll stop the chest-beating now. But please stop trying to tell people that adding a powerpc-specific option (which nobody seems to know how really works) to the command line will work on any other architectures than powerpc. Haavard - 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=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Changing u-boot relocation scheme
On Fri, 25 Jul 2008 19:28:48 +0200
kenneth johansson <[EMAIL PROTECTED]> wrote:
> I was afraid that what was needed was more or less a complete linker but
> it looks like if one generate the dynamic reloc table a much simpler
> linker(relocation function) is needed. Still probably a lot more complex
> than the GOT and fixup code that is just a loop over a table. We may
> need a case also ;-)
Hmm...looks like linking with -pie (or --pic-executable) does
something vaguely resembling the trick. But I don't know what vintage
of ld you need for this to be available and actually work...
[EMAIL PROTECTED]:~/work/u-boot/master$ avr32-linux-readelf -d u-boot
Dynamic section at offset 0x1b8f0 contains 12 entries:
TagType Name/Value
0x0004 (HASH) 0x182ac
0x0005 (STRTAB) 0x18260
0x0006 (SYMTAB) 0x18150
0x000a (STRSZ) 74 (bytes)
0x000b (SYMENT) 16 (bytes)
0x0003 (PLTGOT) 0x1ae70
0x7001 (Processor Specific: 7001) 0xe6c
0x0015 (DEBUG) 0x0
0x0007 (RELA) 0x1833c
0x0008 (RELASZ) 6996 (bytes)
0x0009 (RELAENT)12 (bytes)
0x (NULL) 0x0
The dynamic relocation section became surprisingly large. I wonder if
we actually manage to manually relocate all those buggers...I checked a
couple of them and in both cases it looked like something that needed
to be relocated, but I couldn't find any code that actually did it.
One example from common/cmd_itest.c:
op_tbl_t op_table [] = {
{ "-lt", LT },
{ "<" , LT },
{ "-gt", GT },
{ ">" , GT },
{ "-eq", EQ },
{ "==" , EQ },
{ "-ne", NE },
{ "!=" , NE },
{ "<>" , NE },
{ "-ge", GE },
{ ">=" , GE },
{ "-le", LE },
{ "<=" , LE },
};
Does this really work without any relocation? Or is it being relocated
and I'm just too blind to see it?
The symbol tables can probably be made smaller with some careful
ldscript tweaking.
Haavard
-
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=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Changing u-boot relocation scheme
On Fri, 25 Jul 2008 16:33:56 +0200 kenneth johansson <[EMAIL PROTECTED]> wrote: > On Fri, 2008-07-25 at 14:19 +0200, Haavard Skinnemoen wrote: > > On Fri, 25 Jul 2008 13:55:58 +0200 > > kenneth johansson <[EMAIL PROTECTED]> wrote: > > > > > > An ELF shared library has the dynamic relocations we need. So if we > > > > build u-boot as an .so file, it should work in theory on most > > > > architectures. > > > > > > well the elf binary of u-boot obviously has everything we need > > > regardless of what options it was compiled with. If we had a full linker > > > at runtime we could just do a relink to whatever address we wanted. > > > > No we couldn't if we don't have any relocation information. Just as you > > can't relink just any ELF binary to run at a different location after > > it's been through a final link, no matter how "full" the linker is. > > Take time and READ what people write. I wrote compiler option and you go > on about some final link that removes the relocation information. My > point was that it is irrelevant if you use pic shared whatever if you > are going to use the elf relocation information anyway granted you have > less work to do if the object was compiled as PIC. Oh, you're talking about some hypothetical u-boot binary that hasn't been through the linker? How exactly do you generate it? Besides, I talked about compiler options too (in the paragraph you cut out). If you don't compile the code with -fPIC, most linkers won't be able to make the result relocatable no matter what options you specify. > > > It sounds a bit easier to just loop over a list of pointers and change > > > the values than to implement a complete linker but maybe that is just > > > me. > > > > The question remains how should that list of pointers be generated? One > > possible answer is to let the linker do it (as dynamic relocations). > > Since I have not done a linker I probably miss some information on what > makes the dynamic relocations so special ?? Yes, you probably do. Dynamic relocations are quite special as they are intended for the _runtime_ system, not the linker. Therefore, they are included in a loadable segment so that the program itself or the dynamic loader can go through them and perform fixups at runtime. Also, most platforms only allow a small handful of relocation types to be used as dynamic relocations. This makes the job of the dynamic loader much easier than that of the linker. > And could you outline how the last step in generating the binary image > would work. That's basically the question I've been trying to ask for some time. On PowerPC, I assume -mrelocatable does the trick. On other platforms, I just don't know. > now it works as follows. One final static link with all the .a files and > a specified start address for TEXT. result is a elf file with al symbols > resolved adn it can be relinked to another address if one wants but we > use objcopy to make a binary. Have you ever _tried_ to relink the final u-boot ELF file to another address? How do you do that? > here is a patch to generate dynamic relocations in the elf file. What is > the next step? objcopy -j .rela.dyn -O binary u-boot dyn_reloc_table ?? Might actually work, though we might need more linker options as well. At least -Bsymbolic comes to mind. And I'm not sure if -Bstatic goes well along with -shared... In any case, there's no next step. The dynamic relocations are included in a loadable segment, so they will end up in the .bin file after the last objcopy step. There will obviously be a fair amount of arch-specific code required to make the actual relocation work though. Haavard - 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=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Changing u-boot relocation scheme
On Fri, 25 Jul 2008 13:55:58 +0200 kenneth johansson <[EMAIL PROTECTED]> wrote: > > An ELF shared library has the dynamic relocations we need. So if we > > build u-boot as an .so file, it should work in theory on most > > architectures. > > well the elf binary of u-boot obviously has everything we need > regardless of what options it was compiled with. If we had a full linker > at runtime we could just do a relink to whatever address we wanted. No we couldn't if we don't have any relocation information. Just as you can't relink just any ELF binary to run at a different location after it's been through a final link, no matter how "full" the linker is. And if the ELF file wasn't compiled as position-independent code to begin with, there's just no way it will ever work if it's loaded at a different address than it was linked at. You can't go through and fix up all the compiler-generated address calculations when you don't even have a clue where they are! So whether or not the u-boot ELF file has everything we need depends a _lot_ on what options were used when building it. > It sounds a bit easier to just loop over a list of pointers and change > the values than to implement a complete linker but maybe that is just > me. The question remains how should that list of pointers be generated? One possible answer is to let the linker do it (as dynamic relocations). Haavard - 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=100&url=/ ___ 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
On Thu, 24 Jul 2008 13:14:02 -0500 <[EMAIL PROTECTED]> wrote: > U-Boot already has too many > preprocessor constants and the addition of another (perhaps) > dubious one merits more debate. 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. But since we already have a CONFIG_AVR32 #define, we can clean up the mess in macb.c by simply reversing the logic. Haavard - 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=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Changing u-boot relocation scheme
On Thu, 24 Jul 2008 19:12:20 +0200 Kenneth Johansson <[EMAIL PROTECTED]> wrote: > > We could build u-boot as a shared library I guess, but that feels a bit > > weird... > > What do you mean by that ? u-boot is already compiled with the -fPIC > option. If that's sufficient, why would you need the -mrelocatable option on PowerPC? -fPIC makes the compiler generate position-independent code, which is necessary but not sufficient in order to get a fully relocatable binary. The second part of the puzzle is dynamic relocations. Shared libraries have them, and apparently, PowerPC binaries have them if you link with -mrelocatable. Currently u-boot is compiled with -fPIC, so the result is almost fully relocatable. We work around the lack of dynamic relocations by manually fixing up a handful of pointers at runtime. Haavard - 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=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Changing u-boot relocation scheme
On Fri, 25 Jul 2008 06:28:16 +0200 Wolfgang Denk <[EMAIL PROTECTED]> wrote: > In message <[EMAIL PROTECTED]> you wrote: > > > > Plus it's only defined for PowerPC. What do we do on the 11 other > > architectures? > > Fix them in the first place to do reloction at all? Er. How? The only thing this thread has come up with is a powerpc-only -mrelocatable option which apparently gives the magic word to the linker to have it emit dynamic relocations. We need similar options for 11 other architectures before we can even think about starting to utilize this in a generic manner. > > We could build u-boot as a shared library I guess, but that feels a bit > > weird... > > Shared? Shared by what? An ELF shared library has the dynamic relocations we need. So if we build u-boot as an .so file, it should work in theory on most architectures. Haavard - 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=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Changing u-boot relocation scheme
Kenneth Johansson <[EMAIL PROTECTED]> wrote: > you have to > read the gcc code to understand what the -mrelocatable option really do. Plus it's only defined for PowerPC. What do we do on the 11 other architectures? We could build u-boot as a shared library I guess, but that feels a bit weird... Haavard - 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=100&url=/ ___ 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] Add support for the hammerhead (AVR32) board
Jean-Christophe PLAGNIOL-VILLARD <[EMAIL PROTECTED]> wrote:
> On 16:16 Thu 24 Jul , Haavard Skinnemoen wrote:
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index cbe5c47..bcac300 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -709,6 +709,11 @@ Haavard Skinnemoen <[EMAIL PROTECTED]>
> > ATSTK1006 AT32AP7000
> > ATNGW100AT32AP7000
> >
> > +Alex Raimondi <[EMAIL PROTECTED]>
> > +Julien May <[EMAIL PROTECTED]>
> IMHO, it's supposed to have only one board Maintainer
Doesn't hurt with two, does it? Many Linux subsystems have several
maintainers.
> > -#define SM_PM_GCCTRL 0x0060
> > +#define SM_PM_GCCTRL(x)(0x0060 + 4 * x)
> why do you modify? As I see it's never used.
It is used here:
> +void gclk_init(void)
> +{
> + /* Hammerhead boards uses GCLK3 as 25MHz output to ethernet PHY */
> +
> + /* Select GCLK3 peripheral function */
> + gpio_select_periph_A(GPIO_PIN_PB29, 0);
> +
> + /* Enable GCLK3 with no input divider, from OSC0 (crystal) */
> + sm_writel(PM_GCCTRL(3), SM_BIT(CEN));
> +}
Haavard
-
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=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] Add support for the hammerhead (AVR32) board
From: Julien May <[EMAIL PROTECTED]> The Hammerhead platform is built around a AVR32 32-bit microcontroller from Atmel. It offers versatile peripherals, such as ethernet, usb device, usb host etc. The board also incooperates a power supply and is a Power over Ethernet (PoE) Powered Device (PD). Additonally, a Cyclone III FPGA from Altera is integrated on the board. The FPGA is mapped into the 32-bit AVR memory bus. The FPGA offers two DDR2 SDRAM interfaces, which will cover even the most exceptional need of memory bandwidth. Together with the onboard video decoder the board is ready for video processing. For more information see: http:///www.miromico.com/hammerhead Signed-off-by: Julien May <[EMAIL PROTECTED]> [EMAIL PROTECTED]: various small fixes and adaptions] Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]> --- MAINTAINERS |5 + MAKEALL |1 + Makefile|3 + board/miromico/hammerhead/Makefile | 40 +++ board/miromico/hammerhead/config.mk |3 + board/miromico/hammerhead/hammerhead.c | 114 board/miromico/hammerhead/u-boot.lds| 73 + cpu/at32ap/at32ap700x/sm.h |2 +- cpu/at32ap/cpu.c|3 + include/asm-avr32/arch-at32ap700x/clk.h |1 + include/configs/hammerhead.h| 172 +++ 11 files changed, 416 insertions(+), 1 deletions(-) create mode 100644 board/miromico/hammerhead/Makefile create mode 100644 board/miromico/hammerhead/config.mk create mode 100644 board/miromico/hammerhead/hammerhead.c create mode 100644 board/miromico/hammerhead/u-boot.lds create mode 100644 include/configs/hammerhead.h diff --git a/MAINTAINERS b/MAINTAINERS index cbe5c47..bcac300 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -709,6 +709,11 @@ Haavard Skinnemoen <[EMAIL PROTECTED]> ATSTK1006 AT32AP7000 ATNGW100AT32AP7000 +Alex Raimondi <[EMAIL PROTECTED]> +Julien May <[EMAIL PROTECTED]> + + HAMMERHEAD AT32AP7000 + # # SuperH Systems: # # # diff --git a/MAKEALL b/MAKEALL index c1a9c60..729ee5d 100755 --- a/MAKEALL +++ b/MAKEALL @@ -715,6 +715,7 @@ LIST_avr32="\ atstk1004 \ atstk1006 \ atngw100\ + hammerhead \ " # diff --git a/Makefile b/Makefile index 369bbd7..5e80a09 100644 --- a/Makefile +++ b/Makefile @@ -2914,6 +2914,9 @@ atstk1004_config : unconfig atstk1006_config : unconfig @$(MKCONFIG) $(@:_config=) avr32 at32ap atstk1000 atmel at32ap700x +hammerhead_config : unconfig + @$(MKCONFIG) $(@:_config=) avr32 at32ap hammerhead miromico at32ap700x + # # SH3 (SuperH) # diff --git a/board/miromico/hammerhead/Makefile b/board/miromico/hammerhead/Makefile new file mode 100644 index 000..4b74d16 --- /dev/null +++ b/board/miromico/hammerhead/Makefile @@ -0,0 +1,40 @@ +# +# Copyright (C) 2008 Miromico AG +# +# See file CREDITS for list of people who contributed to this project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA + +include $(TOPDIR)/config.mk + +LIB:= $(obj)lib$(BOARD).a + +COBJS := $(BOARD).o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS)) + +$(LIB): $(obj).depend $(OBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/miromico/hammerhead/config.mk b/board/miromico/hammerhead/config.mk new file mode 100644 index 000..9a794e5 --- /dev/null +++ b/board/miromico/h
Re: [U-Boot-Users] [PATCH 1/1] Add support for the hammerhead (AVR32) board
Julien May <[EMAIL PROTECTED]> wrote: > Please find below the incrementel patch. This patch just fixes the eth > stuff of our board. As hopefully understood right the patch from ben > sould fix the rest. Yeah, that should do it, thanks. I think it's time to create a "next" branch for this stuff now. Haavard - 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=100&url=/ ___ 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 the hammerhead (AVR32) board
Julien May <[EMAIL PROTECTED]> wrote: > > Hmm, that's probably the "weak functions cannot be overriden by > > functions defined in their own file" crap that was discussed earlier. > > Can you try moving board_eth_init() into hammerhead.c? > > Did so and it works now. I could make for this an incremental patch and > send this to you. That would be great. > > Which reminds me...Ben posted a patch which did that for all the > > existing avr32 boards. I should probably apply it. > > Otherwise I wait until you applied bens patch and test again hammerheads > functionality in u-boot. I've applied it, but it doesn't affect hammerhead. It just does the same change you just did to a few other boards. Haavard - 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=100&url=/ ___ 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] Moved initialization of AVR32 Ethernet controllers to board_eth_init()
Ben Warren <[EMAIL PROTECTED]> wrote: > Renamed initialization functions for atngw100 and atstk1000. > Removed initializations for these boards from net/eth.c > > Signed-off-by: Ben Warren <[EMAIL PROTECTED]> Applied, thanks. It's in a separate eth-cleanup branch for now, but I think I'm going to create some sort of "next" branch eventually where it can stay along with the hammerhead board. Or is it better if I push it right away? The net/eth.c changes have a rather large potential for conflicts... Haavard - 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=100&url=/ ___ 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 the hammerhead (AVR32) board
Julien May <[EMAIL PROTECTED]> wrote:
> I am currently having problems in initializing the eth.
>
> in net/eth.c the following is defined
>
> static int __def_eth_init(bd_t *bis)
> {
> return -1;
> }
> int cpu_eth_init(bd_t *bis) __attribute((weak, alias("__def_eth_init")));
> int board_eth_init(bd_t *bis) __attribute((weak, alias("__def_eth_init")));
>
> this is not calling my implementation of board_eth_init.
> I see and like the idea behind this but do not understand why my
> implementation is not getting called...
Hmm, that's probably the "weak functions cannot be overriden by
functions defined in their own file" crap that was discussed earlier.
Can you try moving board_eth_init() into hammerhead.c?
Which reminds me...Ben posted a patch which did that for all the
existing avr32 boards. I should probably apply it.
> btw. I did update the implementation function header from void to int.
Yeah, that's probably a good idea too :-)
Haavard
-
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=100&url=/
___
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 ATMEL AT91SAM9G20EK board
Please don't drop the list from Cc. "Xu, Hong" <[EMAIL PROTECTED]> wrote: > AT91SAM9261EK board uses DM9000 Ethernet Controller, no MACB. > AT91SAM9RLEK board doesn't have Ethernet interface. What does that have to do with anything? Haavard - 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=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Changing u-boot relocation scheme
vb <[EMAIL PROTECTED]> wrote:
> > int (*pf)(struct cmd_tbl_s *, int, int, char *[]) = do_ptrt;
> >
> > int do_ptrt (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
> > {
> > printf ("pointer is %p\n", pf);
> > printf ("function is %p\n", do_ptrt);
> > return 0;
> > }
Just do this instead:
int (*pf)(struct cmd_tbl_s *, int, int, char *[]);
int do_ptrt (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
{
if (!pf)
pf = do_ptrt;
printf ("pointer is %p\n", pf);
printf ("function is %p\n", do_ptrt);
return 0;
}
IMO, it's best to avoid such pointers in the first place, especially
ones that are statically initialized.
Haavard
-
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=100&url=/
___
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 ATMEL AT91SAM9G20EK board
"Hong Xu" <[EMAIL PROTECTED]> wrote: > diff --git a/drivers/net/macb.c b/drivers/net/macb.c > index aa39284..c3dcce6 100644 > --- a/drivers/net/macb.c > +++ b/drivers/net/macb.c > @@ -415,14 +415,14 @@ static int macb_init(struct eth_device *netdev, bd_t > *bd) > /* 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) Hmm...I don't really like the direction this is going. Any chance you could have all AT91 boards define CONFIG_AT91 and check for that instead? Alternatively, we could do it the other way around and test for CONFIG_AVR32 instead, since all AVR32 boards already define that. In either case, this should probably be a separate cleanup; I don't have any objections to your patch. Haavard - 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=100&url=/ ___ 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 the hammerhead (AVR32) board
Julien May <[EMAIL PROTECTED]> wrote: > On Thu, 24 Jul 2008, Haavard Skinnemoen wrote: > > Done. I've also applied a couple of other fixes due to recent API > > changes, so it should at least build now. > > Ah great! > > Are those already committed to your hammerhead branch? Right now I > couldn't pull anything new. > > Maybe you can check those in so that I can pull and test the u-boot. Hmm...they _should_ be there: [EMAIL PROTECTED]:~/work/u-boot/hammerhead$ git remote show avr32 * remote avr32 URL: git://git.denx.de/u-boot-avr32.git Tracked remote branches atmel-1.3.0 atmel-1.3.1 format-warnings hammerhead master spiflash stk1000-lcd [EMAIL PROTECTED]:~/work/u-boot/hammerhead$ git show --stat avr32/hammerhead commit 50ca883c61c88f463fc4d8e635b7aa195fffdb65 Author: Haavard Skinnemoen <[EMAIL PROTECTED]> Date: Thu Jul 24 09:44:01 2008 +0200 hammerhead: Define CONFIG_ATMEL_MCI Since the MMC driver was moved into drivers/mmc, you now need to define CONFIG_ATMEL_MCI in addition to CONFIG_MMC to include it. Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]> include/configs/hammerhead.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) Haavard - 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=100&url=/ ___ 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 the hammerhead (AVR32) board
Haavard Skinnemoen <[EMAIL PROTECTED]> wrote: > Julien May <[EMAIL PROTECTED]> wrote: > > Currently I even cannot compile it, due to some not only to our board > > related errors. I'll check them and give you feedback asap or not > > later than tomorrow. > > Oh...right. I did fix those, but I forgot to pull them in. Done. I've also applied a couple of other fixes due to recent API changes, so it should at least build now. Haavard - 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=100&url=/ ___ 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] Remove warnings compiling serial_xuartlite.c
Grant Likely <[EMAIL PROTECTED]> wrote: > On Thu, Jul 24, 2008 at 05:18:26AM +0200, Wolfgang Denk wrote: > > In message <[EMAIL PROTECTED]> you wrote: > > > > > > I think the list engine at SourceForge converts the mail to base64 > > > whenever it feels like it. So there's not much to do about it on your > > > end except staying away from anything but 7-bit ascii. > > > > No, this is not correct. SF may be slow and doing a lot of painful > > things, but it does NOT convertany messages. That happens at the > > sender's end. > > I double checked. I'm definitely not sending base64. My copy in my > sent mailbox is in utf-8, not base64. I've seen that before too. Wolfgang yelled at me for sending base64, so I checked with some people which I had Cc'ed directly, and they received it correctly. Only people who got it through the list received it base64-encoded. So whatever it is that mangles the message, it's not a trivial problem and I think yelling at the sender is the wrong thing to do. In any case, it's probably a good idea to include whoever you want to apply the patch in the recipient list. Haavard - 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=100&url=/ ___ 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 the hammerhead (AVR32) board
Julien May <[EMAIL PROTECTED]> wrote: > Currently I even cannot compile it, due to some not only to our board > related errors. I'll check them and give you feedback asap or not > later than tomorrow. Oh...right. I did fix those, but I forgot to pull them in. - 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=100&url=/ ___ 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 the hammerhead (AVR32) board
Julien May <[EMAIL PROTECTED]> wrote: > Hi & welcome back from holiday :) Thanks :) > According to your request... This was rather more than I asked for, and it didn't apply to the hammerhead branch I already had. After resolving the conflicts, I ended up with just a change to MAINTAINERS, so I've committed only that part. The rest is already there (except the net/eth.c stuff which shouldn't be necessary anymore after Ben's patch hit mainline) Could you have a look at the result at git://git.denx.de/u-boot-avr32.git hammerhead If it looks ok to you (and still works), I'll fold it all into a single patch tomorrow. The commit messages are somewhat bogus...I'll fix it up at the same time. Haavard - 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=100&url=/ ___ 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 the hammerhead (AVR32) board
Julien May <[EMAIL PROTECTED]> wrote: > MAKEALL |1 + > Makefile |3 + > board/miromico/hammerhead/Makefile | 40 +++ > board/miromico/hammerhead/config.mk |3 + > board/miromico/hammerhead/eth.c | 37 ++ > board/miromico/hammerhead/hammerhead.c | 105 + > board/miromico/hammerhead/u-boot.lds | 73 > cpu/at32ap/at32ap700x/gpio.c | 11 ++ > cpu/at32ap/at32ap700x/sm.h |2 +- > cpu/at32ap/cpu.c |5 + > include/asm-avr32/arch-at32ap700x/clk.h |1 + > include/asm-avr32/arch-at32ap700x/gpio.h |3 + > include/configs/hammerhead.h | 179 > ++ > net/eth.c|4 + I was just going to rebase and fold the hammerhead patch to prepare it for the next merge window when I noticed that MAINTAINERS isn't updated. Can you send me a patch adding yourself to MAINTAINERS, assuming you're the one that will be maintaining this board? Haavard - 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=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH 3/4] atmel_mci: Fix printf() format warnings
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
drivers/mmc/atmel_mci.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/atmel_mci.c b/drivers/mmc/atmel_mci.c
index 61aa184..a151488 100644
--- a/drivers/mmc/atmel_mci.c
+++ b/drivers/mmc/atmel_mci.c
@@ -135,10 +135,10 @@ mmc_cmd(unsigned long cmd, unsigned long arg,
status = mmci_readl(SR);
} while (!(status & MMCI_BIT(CMDRDY)));
- pr_debug("mmc: status 0x%08lx\n", status);
+ pr_debug("mmc: status 0x%08x\n", status);
if (status & error_flags) {
- printf("mmc: command %lu failed (status: 0x%08lx)\n",
+ printf("mmc: command %lu failed (status: 0x%08x)\n",
cmd, status);
return -EIO;
}
@@ -245,7 +245,7 @@ out:
read_error:
mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16, &card_status, R1 | NCR);
- printf("mmc: bread failed, status = %08x, card status = %08x\n",
+ printf("mmc: bread failed, status = %08x, card status = %08lx\n",
status, card_status);
goto out;
}
@@ -284,13 +284,13 @@ static void sd_parse_cid(struct mmc_cid *cid, unsigned
long *resp)
static void mmc_dump_cid(const struct mmc_cid *cid)
{
- printf("Manufacturer ID: %02lX\n", cid->mid);
- printf("OEM/Application ID:%04lX\n", cid->oid);
+ printf("Manufacturer ID: %02X\n", cid->mid);
+ printf("OEM/Application ID:%04X\n", cid->oid);
printf("Product name: %s\n", cid->pnm);
- printf("Product Revision: %lu.%lu\n",
+ printf("Product Revision: %u.%u\n",
cid->prv >> 4, cid->prv & 0x0f);
printf("Product Serial Number: %lu\n", cid->psn);
- printf("Manufacturing Date:%02lu/%02lu\n",
+ printf("Manufacturing Date:%02u/%02u\n",
cid->mdt >> 4, cid->mdt & 0x0f);
}
@@ -501,7 +501,7 @@ int mmc_init(int verbose)
mmc_blkdev.part_type = PART_TYPE_DOS;
mmc_blkdev.block_read = mmc_bread;
sprintf((char *)mmc_blkdev.vendor,
- "Man %02x%04x Snr %08x",
+ "Man %02x%04x Snr %08lx",
cid.mid, cid.oid, cid.psn);
strncpy((char *)mmc_blkdev.product, cid.pnm,
sizeof(mmc_blkdev.product));
--
1.5.6.2
-
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=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH 1/4] avr32: asm/io.h needs asm/types.h
map_physmem() takes a phys_addr_t as parameter. This type is defined in asm/types.h, so we need to include that file. Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]> --- include/asm-avr32/io.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/asm-avr32/io.h b/include/asm-avr32/io.h index d030c26..06e52b1 100644 --- a/include/asm-avr32/io.h +++ b/include/asm-avr32/io.h @@ -22,6 +22,8 @@ #ifndef __ASM_AVR32_IO_H #define __ASM_AVR32_IO_H +#include + #ifdef __KERNEL__ /* -- 1.5.6.2 - 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=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH 4/4] spi flash: Fix printf() format warnings
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
drivers/mtd/spi/atmel.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/spi/atmel.c b/drivers/mtd/spi/atmel.c
index fb7a4a9..10fcf0c 100644
--- a/drivers/mtd/spi/atmel.c
+++ b/drivers/mtd/spi/atmel.c
@@ -205,7 +205,7 @@ static int dataflash_write_at45(struct spi_flash *flash,
byte_addr = 0;
}
- debug("SF: AT45: Successfully programmed %u bytes @ 0x%x\n",
+ debug("SF: AT45: Successfully programmed %zu bytes @ 0x%x\n",
len, offset);
ret = 0;
@@ -268,7 +268,7 @@ int dataflash_erase_at45(struct spi_flash *flash, u32
offset, size_t len)
page_addr++;
}
- debug("SF: AT45: Successfully erased %u bytes @ 0x%x\n",
+ debug("SF: AT45: Successfully erased %zu bytes @ 0x%x\n",
len, offset);
ret = 0;
@@ -351,7 +351,7 @@ struct spi_flash *spi_flash_probe_atmel(struct spi_slave
*spi, u8 *idcode)
* params->blocks_per_sector
* params->nr_sectors;
- debug("SF: Detected %s with page size %u, total %u bytes\n",
+ debug("SF: Detected %s with page size %lu, total %u bytes\n",
params->name, page_size, asf->flash.size);
return &asf->flash;
--
1.5.6.2
-
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=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH 2/4] avr32: Fix printf() format warnings
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
board/atmel/atngw100/atngw100.c |2 +-
board/atmel/atstk1000/atstk1000.c |2 +-
board/atmel/atstk1000/flash.c |2 +-
include/asm-avr32/sysreg.h|6 --
4 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/board/atmel/atngw100/atngw100.c b/board/atmel/atngw100/atngw100.c
index f2c3e79..4ead533 100644
--- a/board/atmel/atngw100/atngw100.c
+++ b/board/atmel/atngw100/atngw100.c
@@ -81,7 +81,7 @@ phys_size_t initdram(int board_type)
unmap_physmem(sdram_base, EBI_SDRAM_SIZE);
if (expected_size != actual_size)
- printf("Warning: Only %u of %u MiB SDRAM is working\n",
+ printf("Warning: Only %lu of %lu MiB SDRAM is working\n",
actual_size >> 20, expected_size >> 20);
return actual_size;
diff --git a/board/atmel/atstk1000/atstk1000.c
b/board/atmel/atstk1000/atstk1000.c
index 6371e2d..d284fc1 100644
--- a/board/atmel/atstk1000/atstk1000.c
+++ b/board/atmel/atstk1000/atstk1000.c
@@ -104,7 +104,7 @@ phys_size_t initdram(int board_type)
unmap_physmem(sdram_base, EBI_SDRAM_SIZE);
if (expected_size != actual_size)
- printf("Warning: Only %u of %u MiB SDRAM is working\n",
+ printf("Warning: Only %lu of %lu MiB SDRAM is working\n",
actual_size >> 20, expected_size >> 20);
return actual_size;
diff --git a/board/atmel/atstk1000/flash.c b/board/atmel/atstk1000/flash.c
index 12537f3..e2bfd4a 100644
--- a/board/atmel/atstk1000/flash.c
+++ b/board/atmel/atstk1000/flash.c
@@ -70,7 +70,7 @@ unsigned long flash_init(void)
void flash_print_info(flash_info_t *info)
{
- printf("Flash: Vendor ID: 0x%02x, Product ID: 0x%02x\n",
+ printf("Flash: Vendor ID: 0x%02lx, Product ID: 0x%02lx\n",
info->flash_id >> 16, info->flash_id & 0x);
printf("Size: %ld MB in %d sectors\n",
info->size >> 10, info->sector_count);
diff --git a/include/asm-avr32/sysreg.h b/include/asm-avr32/sysreg.h
index 72ad49e..4f69704 100644
--- a/include/asm-avr32/sysreg.h
+++ b/include/asm-avr32/sysreg.h
@@ -273,7 +273,9 @@
| SYSREG_BF(name,value))
/* Register access macros */
-#define sysreg_read(reg) __builtin_mfsr(SYSREG_##reg)
-#define sysreg_write(reg, value) __builtin_mtsr(SYSREG_##reg, value)
+#define sysreg_read(reg) \
+ ((unsigned long)__builtin_mfsr(SYSREG_##reg))
+#define sysreg_write(reg, value) \
+ __builtin_mtsr(SYSREG_##reg, value)
#endif /* __ASM_AVR32_SYSREG_H__ */
--
1.5.6.2
-
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=100&url=/
___
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] Remove warnings compiling serial_xuartlite.c
"Ricardo Ribalda Delgado" <[EMAIL PROTECTED]> wrote: > I think that I created it using the git-format-patch and I did sent > it using the git-send-email Any modifier that I should use? I think the list engine at SourceForge converts the mail to base64 whenever it feels like it. So there's not much to do about it on your end except staying away from anything but 7-bit ascii. Welcome to the seventies... Haavard - 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=100&url=/ ___ 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 0/1] Moved initialization of AVR32 Ethernet controllers to board_eth_init()
On Sat, 5 Jul 2008 00:08:47 -0700 Ben Warren <[EMAIL PROTECTED]> wrote: > More cleanup of net/eth.c, this time taking care of AVR32 boards. I got rid > of the board/eth.c files because board_eth_init() needs to be in a file where > there are other strong symbols in order to override the weak board_eth_init() > in > net/eth.c. I've compiled this code and verified that the strong > board_eth_init() symbols are linked in, but don't have hardware to test on. > If somebody can, please try out and let me know. Looks good to me, but I don't have the chance to test it. > These patches are being staged in the 'testing' branch of the net repo. Maybe someone else could give it a try? Haavard - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Release status - things to be done
[removing my private e-mail address from Cc] On Sun, 06 Jul 2008 01:05:40 +0200 Wolfgang Denk <[EMAIL PROTECTED]> wrote: > 2582 05/21 Haavard Skinnemoe [PATCH] MMC: Consolidate MMC/SD command > definitions > -> Rejected, needs to be rebased I see you applied v2 instead -- good. Please ignore v1 as it was posted before the big whitespace cleanup. > 2584 05/21 Haavard Skinnemoe [PATCH] Remove [EMAIL PROTECTED] from > MAINTAINERS > -> asked submitter for fixes / cleanup I'll send you a new patch later today...if I can find the original commit. > 3648 06/11 "Antonio R. Costa [U-Boot-Users] [PATCH 1/6] AT572D940HF-EB > Support > 3649 06/11 "Antonio R. Costa [U-Boot-Users] [PATCH 2/6] AT572D940HF-EB > Support > 3650 06/11 "Antonio R. Costa [U-Boot-Users] [PATCH 3/6] AT572D940HF-EB > Support > 3651 06/11 "Antonio R. Costa [U-Boot-Users] [PATCH 4/6] AT572D940HF-EB > Support > 3652 06/11 "Antonio R. Costa [U-Boot-Users] [PATCH 5/6] AT572D940HF-EB > Support > 3653 06/11 "Antonio R. Costa [U-Boot-Users] [PATCH 6/6] AT572D940HF-EB > Support > 3654 06/11 "Antonio R. Costa [U-Boot-Users] [PATCH 1/3] SDHC Support for > AT572d940HF-EB > 3733 06/12 "Ulf Samuelsson" Re: [U-Boot-Users] [PATCH 1/3] SDHC Support > for AT572d940HF-EB > 3735 06/12 "COSTA, Antonio" Re: [U-Boot-Users] [PATCH 1/3] SDHC Support > for AT572d940HF-EB > 3737 06/12 "Ulf Samuelsson" Re: [U-Boot-Users] [PATCH 1/3] SDHC Support > for AT572d940HF-EB > 3739 06/12 Jerry Van BarenRe: [U-Boot-Users] [PATCH 1/3] SDHC Support > for AT572d940HF-EB > 3859 06/15 Haavard Skinnemoe Re: [U-Boot-Users] [PATCH 1/3] SDHC Support > for AT572d940HF-EB > 3897 06/16 [EMAIL PROTECTED] Re: [U-Boot-Users] [PATCH 1/3] SDHC Support > for AT572d940HF-EB > 3899 06/17 Haavard Skinnemoe Re: [U-Boot-Users] [PATCH 1/3] SDHC Support > for AT572d940HF-EB > 3740 06/12 "Antonio R. Costa [U-Boot-Users] [PATCH 1/6] AT572D940HF-EB > Support v2 (board folder) > 3741 06/12 "Antonio R. Costa [U-Boot-Users] [PATCH 2/2] AT572D940HF-EB > Support v2 (SDHC support part 2) > 3742 06/12 "Antonio R. Costa [U-Boot-Users] [PATCH 1/2] AT572D940HF-EB > Support v2 (SDHC support part 1) > 3743 06/12 "Antonio R. Costa [U-Boot-Users] [PATCH 3/6] AT572D940HF-EB > Support v2 (include files part 1) > 3744 06/12 "Antonio R. Costa [U-Boot-Users] [PATCH 5/6] AT572D940HF-EB > Support v2 (ethernet files) > 3745 06/12 "Antonio R. Costa [U-Boot-Users] [PATCH 4/6] AT572D940HF-EB > Support v2 (include files part 2) > 3747 06/12 "Antonio R. Costa [U-Boot-Users] [PATCH 2/6] AT572D940HF-EB > Support v2 (cpu folder) > 3748 06/12 "Antonio R. Costa [U-Boot-Users] [PATCH 6/6] AT572D940HF-EB > Support v2 (configuration files) > 3746 06/12 "Antonio R. Costa [U-Boot-Users] [PATCH 1/1] mmc_verbosity > variable > 3764 06/12 Haavard Skinnemoe Re: [U-Boot-Users] [PATCH 1/2] AT572D940HF-EB > Support v2 (SDHC support part 1) > -> still under discussion; who is reponsible? I think Jean-Christophe should be responsible for most of this, but I obviously want to be kept in the loop with the MMC/SD/SDHC stuff and possibly other stuff that is or ought to be shared with avr32. Now that the MMC driver has been moved into drivers/mmc, I'd really like to see a patch with the minimum amount of changes needed to make the driver work on AT91 and AT57 as well. With that in place, we'll have a great baseline to add new features like SDHC and MMC+ support, and the rest of the AT57 board support can be merged independently. Haavard - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH v2] Remove [EMAIL PROTECTED] from MAINTAINERS
Mail to [EMAIL PROTECTED] bounces because the user doesn't exist anymore. You can't be a maintainer without a valid e-mail address, so move all boards that used to be maintained by Kyle Harris to the "orphaned" list. Currently, only PowerPC has a list of orphaned boards, so this patch creates one for ARM as well. Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]> --- On Sun, 06 Jul 2008 00:32:01 +0200 Wolfgang Denk <[EMAIL PROTECTED]> wrote: > ... don't jusst delete the orphaned boards, but add them to the > "Unknown / orphaned" list. I created a new Unknown/orphaned list for ARM since the existing one was located in the PowerPC section and only had PowerPC boards on it. Is that ok? MAINTAINERS | 14 -- 1 files changed, 8 insertions(+), 6 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index a3d70b1..6065e42 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -492,12 +492,6 @@ Kshitij Gupta <[EMAIL PROTECTED]> omap1510inn ARM925T omap1610inn ARM926EJS -Kyle Harris <[EMAIL PROTECTED]> - - lubbock xscale - cradle xscale - ixdp425 xscale - Gary Jennejohn <[EMAIL PROTECTED]> smdk2400ARM920T @@ -591,6 +585,14 @@ Michael Schwingen <[EMAIL PROTECTED]> actux3 xscale actux4 xscale +- + +Unknown / orphaned boards: + + cradle xscale + ixdp425 xscale + lubbock xscale + # # x86 Systems: # # # -- 1.5.4.3 - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ 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 2/3] avr32: Use CONFIG_ATMEL_MCI to select the atmel_mci driver
On Thu, 10 Jul 2008 00:05:27 +0200 Wolfgang Denk <[EMAIL PROTECTED]> wrote: > Applied, with a merge conflict include/configs/atngw100.h; please > check the result. Thanks. Looks good to me. Thanks. Ho-hum...a default ATNGW100 build seems to have gone from 0 warnings to around 20 quite recently. I'll have a look at that when I get back from vacation. Haavard - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ 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 0/3] Move atmel_mci driver into drivers/mmc
On Sun, 06 Jul 2008 00:32:03 +0200 Wolfgang Denk <[EMAIL PROTECTED]> wrote: > Will you apply this in your repo and send me a pull request, or do you > want me to pick this up directly? Please pick it up directly. I'm on vacation, so it may take some time before I get around to pushing it anywhere. Haavard - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [GIT PULL] avr32 update
Hi Wolfgang, Please pull the master branch of the avr32 tree: git://git.denx.de/u-boot-avr32.git master to receive the following updates. I consider all of them to be fixes: Having no users of the new SPI flash framework is a rather serious bug IMO, as it prevents people from testing it. All three patches were posted to the list two weeks ago. Nobody has posted any comments. Haavard Skinnemoen (2): avr32: Fix SPI portmux initialization avr32: Enable SPI flash support on ATNGW100 Peter Ma (1): avr32: Add GPIO manipulation functions board/atmel/atngw100/atngw100.c | 25 + cpu/at32ap/at32ap700x/gpio.c | 56 ++ cpu/at32ap/pio.c | 56 ++ include/asm-avr32/arch-at32ap700x/gpio.h |8 include/configs/atngw100.h |6 +++ 5 files changed, 129 insertions(+), 22 deletions(-) - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ 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] Add mechanisms for CPU and board-specific Ethernet initialization
Jean-Christophe PLAGNIOL-VILLARD <[EMAIL PROTECTED]> wrote: > > The idea is that cpu_eth_init is a default for a CPU family, and > > board_eth_init is a board override, which can of course call cpu_eth_init. > What about a section to declare the netdev? Please, let's not overdo this. The patch as it stands is a huge improvement over the current situation. > In this case we can have more than 2 eth and it more generic. You can have that now. board_eth_init() can initialize as many interfaces as it likes. Haavard - 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/1] Add support for the hammerhead (AVR32) board
On Tue, 24 Jun 2008 09:22:13 -0700 Ben Warren <[EMAIL PROTECTED]> wrote: > > ...though I'm not sure what the problem with incremental patches is, > > assuming someone is willing to merge them before they finally go > > upstream. I am willing to do that. > > > > > I personally think they're hard to follow, add unnecessary dependencies > and pollute the changelog. But that's just my opinion. I was thinking of creating some kind of "staging branch" where it could evolve until some time before the next merge window. Then I'd just do a "git rebase -i master" and suck it into my main branch as a single commit, so the changelog should end up nice and tidy. Sort of like how -mm works, except using git instead of quilt. Not sure if it's a good idea or not...I still feel my workflow isn't fully optimized ;-) The alternative is doing a few more full respins on the mailing lists. I personally think full patches get tiresome to review on the third respin or so...so I kinda prefer incremental patches once things are in reasonably good shape. > Just another fun aspect of having non-orthogonal branches and patches. > The best solution would be for Wolfgang to pull my patch into mainline > (for r1.3.4). Technically, a few rounds of the submission were posted > before the merge window closed, so maybe he'll be in a good mood after > vacation :) Otherwise, I don't care - your idea works. You can move a > few or all of the macb-using boards over and that would be cool. I think I'll create a "hammerhead" branch and pull your "next" branch into it. It will be kind of volatile anyway since I intend to rebase it at least once before doing the final merge, so if it doesn't work out, I can always drop your tree. That said, your patch paves the way for a lot of nice cleanups in net/eth.c, so IMO it would be a pity to have to wait another release cycle before starting that work. In other words, feel free to add a huge Acked-by from me and push it for 1.3.4 :-) As for the other macb-using boards...maybe it would be easier to take that through your tree? Heh, non-orthogonal patches again... Haavard - 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/1] Add support for the hammerhead (AVR32) board
Ben Warren <[EMAIL PROTECTED]> wrote: > Hi Julien, > > Julien May wrote: > > On Mon, 23 Jun 2008, Haavard Skinnemoen wrote: > > > > > >> Julien May <[EMAIL PROTECTED]> wrote: > >> > >>> Signed-off-by: Julien May <[EMAIL PROTECTED]> > >>> > >> Could you add a few lines describing the Hammerhead board, perhaps with > >> a link to your site? > >> > > > > You'll find a short desc. of the hammerhead board on top of the > > inc. patch below. > > > > > Please don't do incremental patches. Just re-submit. Sorry, my fault. See below: > >> This looks pretty good to me. I have a few comments below, and I've > >> Cc'ed u-boot-users so that more people can comment on this. Please keep > >> them in the loop whenever you post a new version of this patch. > >> > >> If you want, I can apply this to my tree as is, and you can send me > >> incremental patches fixing up the remaining issues. I'll fold > >> everything into a single patch before sending it upstream. > >> > >> > > > > Would be great if you could apply the patch to your tree. Please find > > below the incremental patch that should fix all of the remaining issues. ...though I'm not sure what the problem with incremental patches is, assuming someone is willing to merge them before they finally go upstream. I am willing to do that. > > diff --git a/net/eth.c b/net/eth.c > > index 054a9fd..2d6f15f 100644 > > --- a/net/eth.c > > +++ b/net/eth.c > > > You won't need to touch this file. Please see how it's done in the > 'next' branch of the net repo on git.denx.de. Yeah, but it you don't touch this file, it will only work in your 'next' branch. If you don't rebase your next branch, I can pull it into my tree and get everything sorted out before the merge window. Hey, I'll even fix up a few existing boards :-) The other possibility is to apply the patch with this hunk present and throw it out before I finally merge it after your changes are in. That was my initial suggestion. What do you think? Haavard - 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/1] Add support for the hammerhead (AVR32) board
Julien May <[EMAIL PROTECTED]> wrote: > > Signed-off-by: Julien May <[EMAIL PROTECTED]> Could you add a few lines describing the Hammerhead board, perhaps with a link to your site? This looks pretty good to me. I have a few comments below, and I've Cc'ed u-boot-users so that more people can comment on this. Please keep them in the loop whenever you post a new version of this patch. If you want, I can apply this to my tree as is, and you can send me incremental patches fixing up the remaining issues. I'll fold everything into a single patch before sending it upstream. > --- > MAKEALL |1 + > Makefile |3 + > board/miromico/hammerhead/Makefile | 40 +++ > board/miromico/hammerhead/config.mk |3 + > board/miromico/hammerhead/eth.c | 37 ++ > board/miromico/hammerhead/hammerhead.c | 105 + > board/miromico/hammerhead/u-boot.lds | 73 > cpu/at32ap/at32ap700x/gpio.c | 11 ++ > cpu/at32ap/at32ap700x/sm.h |2 +- > cpu/at32ap/cpu.c |5 + > include/asm-avr32/arch-at32ap700x/clk.h |1 + > include/asm-avr32/arch-at32ap700x/gpio.h |3 + > include/configs/hammerhead.h | 179 > ++ > net/eth.c|4 + > 14 files changed, 466 insertions(+), 1 deletions(-) > create mode 100644 board/miromico/hammerhead/Makefile > create mode 100644 board/miromico/hammerhead/config.mk > create mode 100644 board/miromico/hammerhead/eth.c > create mode 100644 board/miromico/hammerhead/hammerhead.c > create mode 100644 board/miromico/hammerhead/u-boot.lds > create mode 100644 include/configs/hammerhead.h > > diff --git a/MAKEALL b/MAKEALL > index f40de23..89b68a5 100755 > --- a/MAKEALL > +++ b/MAKEALL > @@ -699,6 +699,7 @@ LIST_avr32=" \ > atstk1004 \ > atstk1006 \ > atngw100\ > + hammerhead \ > " > > # > diff --git a/Makefile b/Makefile > index 154e592..09bae45 100644 > --- a/Makefile > +++ b/Makefile > @@ -2885,6 +2885,9 @@ atstk1006_config: unconfig > atngw100_config : unconfig > @$(MKCONFIG) $(@:_config=) avr32 at32ap atngw100 atmel at32ap700x > > +hammerhead_config: unconfig > + @$(MKCONFIG) $(@:_config=) avr32 at32ap hammerhead miromico at32ap700x > + > # > # > # > diff --git a/board/miromico/hammerhead/Makefile > b/board/miromico/hammerhead/Makefile > new file mode 100644 > index 000..c5fc67a > --- /dev/null > +++ b/board/miromico/hammerhead/Makefile > @@ -0,0 +1,40 @@ > +# > +# Copyright (C) 2008 Miromico AG > +# > +# See file CREDITS for list of people who contributed to this project. > +# > +# This program is free software; you can redistribute it and/or > +# modify it under the terms of the GNU General Public License as > +# published by the Free Software Foundation; either version 2 of > +# the License, or (at your option) any later version. > +# > +# This program is distributed in the hope that it will be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with this program; if not, write to the Free Software > +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, > +# MA 02111-1307 USA > + > +include $(TOPDIR)/config.mk > + > +LIB := $(obj)lib$(BOARD).a > + > +COBJS:= $(BOARD).o eth.o > + > +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) > +OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS)) > + > +$(LIB): $(obj).depend $(OBJS) > + $(AR) $(ARFLAGS) $@ $(OBJS) > + > +# > + > +# defines $(obj).depend target > +include $(SRCTREE)/rules.mk > + > +sinclude $(obj).depend > + > +# > diff --git a/board/miromico/hammerhead/config.mk > b/board/miromico/hammerhead/config.mk > new file mode 100644 > index 000..9a794e5 > --- /dev/null > +++ b/board/miromico/hammerhead/config.mk > @@ -0,0 +1,3 @@ > +TEXT_BASE= 0x > +PLATFORM_RELFLAGS+= -ffunction-sections -fdata-sections > +PLATFORM_LDFLAGS += --gc-sections > diff --git a/board/miromico/hammerhead/eth.c b/board/miromico/hammerhead/eth.c > new file mode 100644 > index 000..969c48e > --- /dev/null > +++ b/board/miromico/hammerhead/eth.c > @@ -0,0 +1,37 @@ > +/* > + * Copyright (C) 2008 Miromico A
Re: [U-Boot-Users] [PATCH] mtd: SPI Flash: Support the ST Microelectronics M25P80 and M25P40
Jason McMullan <[EMAIL PROTECTED]> wrote:
> This commit adds MTD support for the M25P80 (1Mx8) and the M25P40 (512kx8)
> SPI Flash components from ST Microelectronics.
>
> Tested with the M25P40, but should work for the M25P80 according
> to the spec sheet.
> ---
Nice. I have a few minor comments below.
Could you add some information on how to obtain data sheets for these
things? I had some difficulty finding it.
FWIW, I think it's here:
http://www.numonyx.com/en-US/MemoryProducts/NOR/Pages/M25PTechnicalDocuments.aspx
> +struct stmicro_spi_flash_params {
> + uint8_t esig;
> + /* Log2 of page size in power-of-two mode */
Do these chips support anything but power-of-two page sizes? I always
thought that was an AT45 DataFlash peculiarity...
I can't find anything in the M25P80 indicating that the page size can
be different from 256...
> + uint8_t l2_page_size;
> +/*
> + * Assemble the address part of a command for STMicro devices in
> + * non-power-of-two page size mode.
> + */
This comment is misleading. The below code only works for power-of-two
page sizes.
> +static void stmicro_build_address(struct stmicro_spi_flash *stm, u8 *cmd,
> u32 offset)
> +{
> + unsigned long page_addr;
> + unsigned long byte_addr;
> + unsigned long page_size;
> + unsigned int page_shift;
> +
> + /*
> + * The "extra" space per page is the power-of-two page size
> + * divided by 32.
> + */
This comment is misleading too. There's no "extra" space in the
calculations below...
> + page_shift = stm->params->l2_page_size;
> + page_size = (1 << page_shift);
> + page_addr = offset / page_size;
> + byte_addr = offset % page_size;
...which means that you can make these operations cheaper by using
shift and mask instead of divide and modulo. Though I suppose a clever
compiler might figure that out on its own...
> +static int stmicro_write(struct spi_flash *flash,
> + u32 offset, size_t len, const void *buf)
> +{
> + struct stmicro_spi_flash *stm = to_stmicro_spi_flash(flash);
> + unsigned long page_addr;
> + unsigned long byte_addr;
> + unsigned long page_size;
> + unsigned int page_shift;
> + size_t chunk_len;
> + size_t actual;
> + int ret;
> + u8 cmd[4];
> +
> + page_shift = stm->params->l2_page_size;
> + page_size = (1 << page_shift);
> + page_addr = offset / page_size;
> + byte_addr = offset % page_size;
Same thing here. Could you have a look at the disassembly to see if the
compiler _is_ clever enough to optimize away the divide/modulo?
Haavard
-
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
[U-Boot-Users] [PATCH 3/3] avr32: Enable SPI flash support on ATNGW100
The ATNGW100 has 8MB DataFlash on board. Give users access to it through
the new SPI flash framework.
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
board/atmel/atngw100/atngw100.c | 25 +
include/configs/atngw100.h |6 ++
2 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/board/atmel/atngw100/atngw100.c b/board/atmel/atngw100/atngw100.c
index 375f0e7..f2c3e79 100644
--- a/board/atmel/atngw100/atngw100.c
+++ b/board/atmel/atngw100/atngw100.c
@@ -60,6 +60,9 @@ int board_early_init_f(void)
#if defined(CONFIG_MMC)
gpio_enable_mmci();
#endif
+#if defined(CONFIG_ATMEL_SPI)
+ gpio_enable_spi0(1 << 0);
+#endif
return 0;
}
@@ -89,3 +92,25 @@ void board_init_info(void)
gd->bd->bi_phy_id[0] = 0x01;
gd->bd->bi_phy_id[1] = 0x03;
}
+
+/* SPI chip select control */
+#ifdef CONFIG_ATMEL_SPI
+#include
+
+#define ATNGW100_DATAFLASH_CS_PIN GPIO_PIN_PA3
+
+int spi_cs_is_valid(unsigned int bus, unsigned int cs)
+{
+ return bus == 0 && cs == 0;
+}
+
+void spi_cs_activate(struct spi_slave *slave)
+{
+ gpio_set_value(ATNGW100_DATAFLASH_CS_PIN, 0);
+}
+
+void spi_cs_deactivate(struct spi_slave *slave)
+{
+ gpio_set_value(ATNGW100_DATAFLASH_CS_PIN, 1);
+}
+#endif /* CONFIG_ATMEL_SPI */
diff --git a/include/configs/atngw100.h b/include/configs/atngw100.h
index 3fc9975..7ac51b5 100644
--- a/include/configs/atngw100.h
+++ b/include/configs/atngw100.h
@@ -114,6 +114,8 @@
#define CONFIG_CMD_FAT
#define CONFIG_CMD_JFFS2
#define CONFIG_CMD_MMC
+#define CONFIG_CMD_SF
+#define CONFIG_CMD_SPI
#undef CONFIG_CMD_AUTOSCRIPT
#undef CONFIG_CMD_FPGA
@@ -126,6 +128,10 @@
#define CFG_NR_PIOS5
#define CFG_HSDRAMC1
#define CONFIG_MMC 1
+#define CONFIG_ATMEL_SPI 1
+
+#define CONFIG_SPI_FLASH 1
+#define CONFIG_SPI_FLASH_ATMEL 1
#define CFG_DCACHE_LINESZ 32
#define CFG_ICACHE_LINESZ 32
--
1.5.5.3
-
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
[U-Boot-Users] [PATCH 1/3] avr32: Add GPIO manipulation functions
From: Peter Ma <[EMAIL PROTECTED]>
Adds GPIO manipulation functions for AVR32 AP7 platform.
Signed-off-by: Peter Ma <[EMAIL PROTECTED]>
[EMAIL PROTECTED]: coding style fixup, slight simplification]
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
This and the following two patches enables SPI flash support on
ATNGW100. I want to merge this for v1.3.4 so that the new SPI flash
code can get more exposure.
I consider all three patches very low risk, so I hope it's ok to merge
it outside the merge window. If not, please speak up.
Haavard
cpu/at32ap/pio.c | 56 ++
include/asm-avr32/arch-at32ap700x/gpio.h |8
2 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/cpu/at32ap/pio.c b/cpu/at32ap/pio.c
index 9ba0b8e..f64004b 100644
--- a/cpu/at32ap/pio.c
+++ b/cpu/at32ap/pio.c
@@ -58,3 +58,59 @@ void gpio_select_periph_B(unsigned int pin, int use_pullup)
else
pio2_writel(base, PUDR, mask);
}
+
+void gpio_select_pio(unsigned int pin, unsigned long gpiof_flags)
+{
+ void *base = gpio_pin_to_addr(pin);
+ uint32_t mask = 1 << (pin & 0x1f);
+
+ if (!base)
+ panic("Invalid GPIO pin %u\n", pin);
+
+ if (gpiof_flags & GPIOF_OUTPUT) {
+ if (gpiof_flags & GPIOF_MULTIDRV)
+ pio2_writel(base, MDER, mask);
+ else
+ pio2_writel(base, MDDR, mask);
+ pio2_writel(base, PUDR, mask);
+ pio2_writel(base, OER, mask);
+ } else {
+ if (gpiof_flags & GPIOF_PULLUP)
+ pio2_writel(base, PUER, mask);
+ else
+ pio2_writel(base, PUDR, mask);
+ if (gpiof_flags & GPIOF_DEGLITCH)
+ pio2_writel(base, IFER, mask);
+ else
+ pio2_writel(base, IFDR, mask);
+ pio2_writel(base, ODR, mask);
+ }
+
+ pio2_writel(base, PER, mask);
+}
+
+void gpio_set_value(unsigned int pin, int value)
+{
+ void *base = gpio_pin_to_addr(pin);
+ uint32_t mask = 1 << (pin & 0x1f);
+
+ if (!base)
+ panic("Invalid GPIO pin %u\n", pin);
+
+ if (value)
+ pio2_writel(base, SODR, mask);
+ else
+ pio2_writel(base, CODR, mask);
+}
+
+int gpio_get_value(unsigned int pin)
+{
+ void *base = gpio_pin_to_addr(pin);
+ int value;
+
+ if (!base)
+ panic("Invalid GPIO pin %u\n", pin);
+
+ value = pio2_readl(base, PDSR);
+ return (value >> (pin & 0x1f)) & 1;
+}
diff --git a/include/asm-avr32/arch-at32ap700x/gpio.h
b/include/asm-avr32/arch-at32ap700x/gpio.h
index ef20cea..8c922c7 100644
--- a/include/asm-avr32/arch-at32ap700x/gpio.h
+++ b/include/asm-avr32/arch-at32ap700x/gpio.h
@@ -180,6 +180,11 @@
#define GPIO_PIN_PE25 (GPIO_PIOE_BASE + 25)
#define GPIO_PIN_PE26 (GPIO_PIOE_BASE + 26)
+#define GPIOF_PULLUP 0x0001 /* (not-OUT) Enable pull-up */
+#define GPIOF_OUTPUT 0x0002 /* (OUT) Enable output driver */
+#define GPIOF_DEGLITCH 0x0004 /* (IN) Filter glitches */
+#define GPIOF_MULTIDRV 0x0008 /* Enable multidriver option */
+
static inline void *gpio_pin_to_addr(unsigned int pin)
{
switch (pin >> 5) {
@@ -200,6 +205,9 @@ static inline void *gpio_pin_to_addr(unsigned int pin)
void gpio_select_periph_A(unsigned int pin, int use_pullup);
void gpio_select_periph_B(unsigned int pin, int use_pullup);
+void gpio_select_pio(unsigned int pin, unsigned long gpiof_flags);
+void gpio_set_value(unsigned int pin, int value);
+int gpio_get_value(unsigned int pin);
void gpio_enable_ebi(void);
--
1.5.5.3
-
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
[U-Boot-Users] [PATCH 2/3] avr32: Fix SPI portmux initialization
Use the new GPIO manipulation functions to set up the chip select lines,
and make sure both busses use GPIO for chip select control.
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
cpu/at32ap/at32ap700x/gpio.c | 56 +
1 files changed, 34 insertions(+), 22 deletions(-)
diff --git a/cpu/at32ap/at32ap700x/gpio.c b/cpu/at32ap/at32ap700x/gpio.c
index 3da35d4..56ba2f9 100644
--- a/cpu/at32ap/at32ap700x/gpio.c
+++ b/cpu/at32ap/at32ap700x/gpio.c
@@ -149,24 +149,27 @@ void gpio_enable_mmci(void)
#ifdef AT32AP700x_CHIP_HAS_SPI
void gpio_enable_spi0(unsigned long cs_mask)
{
- u32 pa_mask = 0;
-
gpio_select_periph_A(GPIO_PIN_PA0, 0); /* MISO */
gpio_select_periph_A(GPIO_PIN_PA1, 0); /* MOSI */
gpio_select_periph_A(GPIO_PIN_PA2, 0); /* SCK */
- if (cs_mask & (1 << 0))
- pa_mask |= 1 << 3; /* NPCS0 */
- if (cs_mask & (1 << 1))
- pa_mask |= 1 << 4; /* NPCS1 */
- if (cs_mask & (1 << 2))
- pa_mask |= 1 << 5; /* NPCS2 */
- if (cs_mask & (1 << 3))
- pa_mask |= 1 << 20; /* NPCS3 */
-
- __raw_writel(pa_mask, PIOA_BASE + 0x00);
- __raw_writel(pa_mask, PIOA_BASE + 0x30);
- __raw_writel(pa_mask, PIOA_BASE + 0x10);
+ /* Set up NPCSx as GPIO outputs, initially high */
+ if (cs_mask & (1 << 0)) {
+ gpio_set_value(GPIO_PIN_PA3, 1);
+ gpio_select_pio(GPIO_PIN_PA3, GPIOF_OUTPUT);
+ }
+ if (cs_mask & (1 << 1)) {
+ gpio_set_value(GPIO_PIN_PA4, 1);
+ gpio_select_pio(GPIO_PIN_PA4, GPIOF_OUTPUT);
+ }
+ if (cs_mask & (1 << 2)) {
+ gpio_set_value(GPIO_PIN_PA5, 1);
+ gpio_select_pio(GPIO_PIN_PA5, GPIOF_OUTPUT);
+ }
+ if (cs_mask & (1 << 3)) {
+ gpio_set_value(GPIO_PIN_PA20, 1);
+ gpio_select_pio(GPIO_PIN_PA20, GPIOF_OUTPUT);
+ }
}
void gpio_enable_spi1(unsigned long cs_mask)
@@ -175,13 +178,22 @@ void gpio_enable_spi1(unsigned long cs_mask)
gpio_select_periph_B(GPIO_PIN_PB1, 0); /* MOSI */
gpio_select_periph_B(GPIO_PIN_PB5, 0); /* SCK */
- if (cs_mask & (1 << 0))
- gpio_select_periph_B(GPIO_PIN_PB2, 0); /* NPCS0 */
- if (cs_mask & (1 << 1))
- gpio_select_periph_B(GPIO_PIN_PB3, 0); /* NPCS1 */
- if (cs_mask & (1 << 2))
- gpio_select_periph_B(GPIO_PIN_PB4, 0); /* NPCS2 */
- if (cs_mask & (1 << 3))
- gpio_select_periph_A(GPIO_PIN_PA27, 0); /* NPCS3 */
+ /* Set up NPCSx as GPIO outputs, initially high */
+ if (cs_mask & (1 << 0)) {
+ gpio_set_value(GPIO_PIN_PB2, 1);
+ gpio_select_pio(GPIO_PIN_PB2, GPIOF_OUTPUT);
+ }
+ if (cs_mask & (1 << 1)) {
+ gpio_set_value(GPIO_PIN_PB3, 1);
+ gpio_select_pio(GPIO_PIN_PB3, GPIOF_OUTPUT);
+ }
+ if (cs_mask & (1 << 2)) {
+ gpio_set_value(GPIO_PIN_PB4, 1);
+ gpio_select_pio(GPIO_PIN_PB4, GPIOF_OUTPUT);
+ }
+ if (cs_mask & (1 << 3)) {
+ gpio_set_value(GPIO_PIN_PA27, 1);
+ gpio_select_pio(GPIO_PIN_PA27, GPIOF_OUTPUT);
+ }
}
#endif
--
1.5.5.3
-
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] Stops booting after RAM info
Andrejs Cainikovs <[EMAIL PROTECTED]> wrote: > Our boards flash driver is the same as in board/atmel/at91rm9200dk/flash.c > The only thing that was modified is the flash identification routine, as > there was no support for AT49BV642D. This chip is supported by the CFI driver (the ATNGW100 board relies on that.) > The flash organization for this chip is the same as in AT49BV6416 which > exists in the sources, so we haven't changed a lot. This chip is not yet supported by the CFI driver. It needs a fixup due to reversed erase region information, but since the CFI driver only reads the low 8 bits of the ID, there's currently no way to tell it apart from AT49BV642D, which doesn't need this fixup. If someone can figure out how to read a 16-bit ID when appropriate, I suspect we can get rid of quite a few board-specific flash drivers (including the one for ATSTK1000). Unfortunately, I don't have the time to look into this myself at the moment. Haavard - 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 Mon, 16 Jun 2008 16:13:32 -0500 <[EMAIL PROTECTED]> wrote: > However, I was mistaken about my code being committed into the > official u-boot tree. Please see my response above. Ok, I figured it must be something like that. That said, I take it this means that we have not two but _three_ drivers for the same hardware floating around in various trees, all of which are forked off the original avr32 driver. I think this is another reason to get those drivers merged together ASAP. I also hope that we can get your MMC+ support into the common driver eventually, with proper attributions and copyrights of course ;-) but I think the merge needs to happen first. I suggest we start with the three patches I posted moving the avr32 driver into drivers/mmc, then make the minimal set of changes necessary to support AT91 and Diopsis, and then start adding additional features from the other drivers, like MMC+ and SDHC support. The first two steps should certainly be doable in time for the next merge window. I suspect MMC+ and SDHC support needs more testing and review, but it may be doable as well. Does this sound like a good plan to everyone? Haavard - 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 to clean up syntax highlighting
On Fri, 13 Jun 2008 08:14:17 -0400 Jerry Van Baren <[EMAIL PROTECTED]> wrote: > Looking at the source code, its pretty ugly already. Your change > doesn't make it any more ugly and it could be argued that it is slightly > less ugly (your patch removes the duplication of the "if( (...)" > statement). I also don't see any alternative that would make the code > beautiful. :-( Actually, I think the following would be slightly cleaner: #ifdef CONFIG_HAS_UID # define HAS_UID(1) #else # define HAS_UID(0) #endif /* ... */ if (((strcmp (name, "serial#") == 0) && (!HAS_UID || (flag != 0xdeaf4add))) || ((strcmp (name, "ethaddr") == 0) (I may have miscounted the parentheses though...I certainly see the need for working syntax highlighting on this code ;-) Haavard - 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 <[EMAIL PROTECTED]> 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.) Which driver are you talking about? I don't see any AT91 MCI driver in the u-boot tree...I thought Antonio based his work on the cpu/at32ap/atmel_mci.c driver? Haavard - 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] Can't get strong symbol to override weak one
"Ben Warren" <[EMAIL PROTECTED]> wrote: > I propose to wrap both the 'board/$(BOARDDIR)/lib$(BOARD).a' and > 'cpu/$(CPU)/lib$(CPU).a' arguments to ld in > --whole-module/--no-whole-module in order to accomplish this goal. We > definitely don't want to do this across the board because image size > will increase quite a bit due to unused code. You can counter that additional size and more by adding --gc-sections to the linker command line and -ffunction-sections -fdata-sections to gcc. That will probably even get rid of the weak implementation if a strong definition is provided. There's a catch though -- if your linker script isn't prepared for this, things will break. Haavard - 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/2] AT572D940HF-EB Support v2 (SDHC support part 1)
"Ulf Samuelsson" <[EMAIL PROTECTED]> wrote: > > No, this is not the way we work. We submit patches that can be > > reviewed, not chunks of code that the reviewer has to anayze with > > additional, unnecessary efforts. > > Antonio submits a working patchset which is structured in the > same manner as existing boards. > Haavard has a different goal which is important, but less urgent than other > things. What the hell makes you think that your goals are so much more important than mine (and everyone else's for that matter)? It's much easier to get the drivers merged now rather than later. I did actually do a quick diff and I saw at least three minor fixes reverted, so the drivers have _already_ started diverging. Do you think they will somehow be _more_ similar if we just keep them in the same tree for a while? Besides, there's a very real possibility that the drivers will never be merged since we're all busy with other stuff. Btw, apart from a couple of relatively minor things, I think the diff as a whole looked very good, so that's not at all what I'm complaining about. > >> Why not get the Diopsis support in first, and then do the merge > >> afterwards. > > > > Because this is NOT the way it works. > > Please stick to the established rules. > > Which rule is you referring to? > > Since Haavard wants this merge, then I suggest that Haavard takes > the existing patches from Antonio and reworks them ASAP, > testing them out on AVR32, AT91 and Diopsis, and resubmits > the patchset so that we have a working common driver > and working AT572D940DF board support. Ulf, if you keep insisting on that attitude, you'll never get anything merged. This is _so_ not how it works. I can certainly help Antonio get the patch into an acceptable state for merging as well as test it on AVR32, but demanding that I set up toolchains and test every single Atmel board out there is just totally unreasonable. Besides, the driver was originally written by me. Isn't it fair that Diopsis gave something back by making it usable on more than just their board? Haavard - 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/2] AT572D940HF-EB Support v2 (SDHC support part 1)
On Thu, 12 Jun 2008 19:19:47 +0200 "Ulf Samuelsson" <[EMAIL PROTECTED]> wrote: > Haavard Skinnemoen wrote: > > It's a bit hard to see what your proposal is all about when you create > > a new file instead of modifying the exising one... > > > > If you want to see changes right now, > then just replace the existing file with the Diopsis file and do a diff. The whole idea about e-mail review is that someone posts a patch and someone else reviews it. > > So how about we start by introducing a new drivers/mmc directory and > > move the existing AVR32 driver there? After that, you can apply your > > changes to it and send a patch which clearly shows the differences > > from the old code. Don't worry about breaking AVR32 -- I'll help you > > test it before it gets merged upstream. > > > > Why not get the Diopsis support in first, and then do the merge afterwards. > I do agree that they should be merged, but that does not mean > that delaying the availability of Diopsis support in U-Boot is a good idea. I disagree. Why do a half-assed job when you can do it properly? Besides, the merge window is closed now, isn't it? So we have lots of time to review and test things before the next merge window. Haavard - 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
[U-Boot-Users] [PATCH 0/3] Move atmel_mci driver into drivers/mmc
> So how about we start by introducing a new drivers/mmc directory and
> move the existing AVR32 driver there?
In fact, this is so incredibly easy to do with git that I decided to
just do it. The three patches posted as a follow-up to this e-mail is
the result. I've verified that it compiles and that the driver gets
included in the final image, but I haven't actually run it.
Now, if you move your modified driver into drivers/mmc and generate a
patch against this series, it will be much easier to review your
changes. And any bug fixes done on one platform will benefit all.
To use the driver, simply add "#define CONFIG_ATMEL_MCI" to your board
config file.
Shortlog and diffstat for the whole series follows.
Haavard Skinnemoen (3):
Create drivers/mmc subdirectory
avr32: Use CONFIG_ATMEL_MCI to select the atmel_mci driver
mmc: Move atmel_mci driver into drivers/mmc
Makefile|2 +
cpu/at32ap/Makefile |1 -
drivers/mmc/Makefile| 46 +++
{cpu/at32ap => drivers/mmc}/atmel_mci.c |0
{cpu/at32ap => drivers/mmc}/atmel_mci.h |0
include/configs/atngw100.h |1 +
include/configs/atstk1002.h |1 +
include/configs/atstk1003.h |1 +
include/configs/atstk1004.h |1 +
include/configs/atstk1006.h |1 +
10 files changed, 53 insertions(+), 1 deletions(-)
create mode 100644 drivers/mmc/Makefile
rename {cpu/at32ap => drivers/mmc}/atmel_mci.c (100%)
rename {cpu/at32ap => drivers/mmc}/atmel_mci.h (100%)
-
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
[U-Boot-Users] [PATCH 2/3] avr32: Use CONFIG_ATMEL_MCI to select the atmel_mci driver
After we move the atmel_mci driver into drivers/mmc, we can't select it with CONFIG_MMC anymore. Introduce a new symbol specifically for this driver so that there's no ambiguity. Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]> --- cpu/at32ap/Makefile |2 +- include/configs/atngw100.h |1 + include/configs/atstk1002.h |1 + include/configs/atstk1003.h |1 + include/configs/atstk1004.h |1 + include/configs/atstk1006.h |1 + 6 files changed, 6 insertions(+), 1 deletions(-) diff --git a/cpu/at32ap/Makefile b/cpu/at32ap/Makefile index d16c58b..f182330 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-$(CONFIG_MMC)+= atmel_mci.o +COBJS-$(CONFIG_ATMEL_MCI) += 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/include/configs/atngw100.h b/include/configs/atngw100.h index 3fc9975..4c995ea 100644 --- a/include/configs/atngw100.h +++ b/include/configs/atngw100.h @@ -126,6 +126,7 @@ #define CFG_NR_PIOS5 #define CFG_HSDRAMC1 #define CONFIG_MMC 1 +#define CONFIG_ATMEL_MCI 1 #define CFG_DCACHE_LINESZ 32 #define CFG_ICACHE_LINESZ 32 diff --git a/include/configs/atstk1002.h b/include/configs/atstk1002.h index ba18eb6..90910bb 100644 --- a/include/configs/atstk1002.h +++ b/include/configs/atstk1002.h @@ -153,6 +153,7 @@ #define CFG_NR_PIOS5 #define CFG_HSDRAMC1 #define CONFIG_MMC 1 +#define CONFIG_ATMEL_MCI 1 #define CFG_DCACHE_LINESZ 32 #define CFG_ICACHE_LINESZ 32 diff --git a/include/configs/atstk1003.h b/include/configs/atstk1003.h index a528ddf..03472a8 100644 --- a/include/configs/atstk1003.h +++ b/include/configs/atstk1003.h @@ -136,6 +136,7 @@ #define CONFIG_PIO21 #define CFG_HSDRAMC1 #define CONFIG_MMC 1 +#define CONFIG_ATMEL_MCI 1 #define CFG_DCACHE_LINESZ 32 #define CFG_ICACHE_LINESZ 32 diff --git a/include/configs/atstk1004.h b/include/configs/atstk1004.h index fc9585e..07add82 100644 --- a/include/configs/atstk1004.h +++ b/include/configs/atstk1004.h @@ -136,6 +136,7 @@ #define CONFIG_PIO21 #define CFG_HSDRAMC1 #define CONFIG_MMC 1 +#define CONFIG_ATMEL_MCI 1 #define CFG_DCACHE_LINESZ 32 #define CFG_ICACHE_LINESZ 32 diff --git a/include/configs/atstk1006.h b/include/configs/atstk1006.h index 9fd49a5..f9af675 100644 --- a/include/configs/atstk1006.h +++ b/include/configs/atstk1006.h @@ -153,6 +153,7 @@ #define CFG_NR_PIOS5 #define CFG_HSDRAMC1 #define CONFIG_MMC 1 +#define CONFIG_ATMEL_MCI 1 #define CFG_DCACHE_LINESZ 32 #define CFG_ICACHE_LINESZ 32 -- 1.5.4.3 - 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
[U-Boot-Users] [PATCH 1/3] Create drivers/mmc subdirectory
In order to consolidate more of the various MMC drivers around the tree, we must first have a common place to put them. Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]> --- Makefile |2 ++ drivers/mmc/Makefile | 44 2 files changed, 46 insertions(+), 0 deletions(-) create mode 100644 drivers/mmc/Makefile diff --git a/Makefile b/Makefile index 8bfc891..33e45b8 100644 --- a/Makefile +++ b/Makefile @@ -220,6 +220,7 @@ LIBS += drivers/hwmon/libhwmon.a LIBS += drivers/i2c/libi2c.a LIBS += drivers/input/libinput.a LIBS += drivers/misc/libmisc.a +LIBS += drivers/mmc/libmmc.a LIBS += drivers/mtd/libmtd.a LIBS += drivers/mtd/nand/libnand.a LIBS += drivers/mtd/nand_legacy/libnand_legacy.a @@ -387,6 +388,7 @@ TAG_SUBDIRS += drivers/hwmon TAG_SUBDIRS += drivers/i2c TAG_SUBDIRS += drivers/input TAG_SUBDIRS += drivers/misc +TAG_SUBDIRS += drivers/mmc TAG_SUBDIRS += drivers/mtd TAG_SUBDIRS += drivers/mtd/nand TAG_SUBDIRS += drivers/mtd/nand_legacy diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile new file mode 100644 index 000..db92424 --- /dev/null +++ b/drivers/mmc/Makefile @@ -0,0 +1,44 @@ +# +# (C) Copyright 2006 +# Wolfgang Denk, DENX Software Engineering, [EMAIL PROTECTED] +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB:= $(obj)libmmc.a + +COBJS := $(COBJS-y) +SRCS := $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) + +all: $(LIB) + +$(LIB): $(obj).depend $(OBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# -- 1.5.4.3 - 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
[U-Boot-Users] [PATCH 3/3] mmc: Move atmel_mci driver into drivers/mmc
This makes it easier to use the driver on other platforms.
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
cpu/at32ap/Makefile |1 -
drivers/mmc/Makefile|2 ++
{cpu/at32ap => drivers/mmc}/atmel_mci.c |0
{cpu/at32ap => drivers/mmc}/atmel_mci.h |0
4 files changed, 2 insertions(+), 1 deletions(-)
rename {cpu/at32ap => drivers/mmc}/atmel_mci.c (100%)
rename {cpu/at32ap => drivers/mmc}/atmel_mci.h (100%)
diff --git a/cpu/at32ap/Makefile b/cpu/at32ap/Makefile
index f182330..33dc427 100644
--- a/cpu/at32ap/Makefile
+++ b/cpu/at32ap/Makefile
@@ -35,7 +35,6 @@ COBJS-y += exception.o
COBJS-y+= cache.o
COBJS-y+= interrupts.o
COBJS-y+= pio.o
-COBJS-$(CONFIG_ATMEL_MCI) += 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/drivers/mmc/Makefile b/drivers/mmc/Makefile
index db92424..3dc031b 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -25,6 +25,8 @@ include $(TOPDIR)/config.mk
LIB:= $(obj)libmmc.a
+COBJS-$(CONFIG_ATMEL_MCI) += atmel_mci.o
+
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS))
diff --git a/cpu/at32ap/atmel_mci.c b/drivers/mmc/atmel_mci.c
similarity index 100%
rename from cpu/at32ap/atmel_mci.c
rename to drivers/mmc/atmel_mci.c
diff --git a/cpu/at32ap/atmel_mci.h b/drivers/mmc/atmel_mci.h
similarity index 100%
rename from cpu/at32ap/atmel_mci.h
rename to drivers/mmc/atmel_mci.h
--
1.5.4.3
-
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/2] AT572D940HF-EB Support v2 (SDHC support part 1)
On Thu, 12 Jun 2008 16:14:56 +0200 "Antonio R. Costa" <[EMAIL PROTECTED]> wrote: > This patch add support for SD/SDHC cards to AT572D940HF-EB > and more generally is a proposal for all Atmel chips. > Dued to that I placed atmel_mci.c under the board directory. It's a bit hard to see what your proposal is all about when you create a new file instead of modifying the exising one... > The implementation of the CSD interpretation has been re-worked > completely. Bit fields are not portable so there were replaced by > a vector of 4 32-bit words and some macros. > > Probing process follow the schema from SD spec 2.0: > sdhc --> sd --> mmc > > Introduced IF_TYPE_SDHC to distinguish between SD and SDHC. > Maybe this is not the best method since struct block_dev_descr.priv > could point to a structure describing card properties but it was > the quickest one and I had no time to spend. > > Tested SD: > - Mediacom512 MB (spec 1.0) bare FAT16 no partition table > - Kingstone 1 GB (spec 1.0) 1 FAT16 > - Trascend 2 GB (spec 1.01) 1 FAT16 > - TakeMS4 GB (spec 1.10) 1 FAT16 > > Tested SDHC: > - Peak 8 GB (spec 2.0) 1 FAT32 Ideally, this sort of thing should go into a common MMC layer for u-boot. But at the very least, we should use the same driver on all chips that feature the same hardware (other AT91 chips and AVR32). So how about we start by introducing a new drivers/mmc directory and move the existing AVR32 driver there? After that, you can apply your changes to it and send a patch which clearly shows the differences from the old code. Don't worry about breaking AVR32 -- I'll help you test it before it gets merged upstream. Then, after that, if someone feels up to the task, he can gather all the different pieces together from the existing drivers and create a common MMC layer. Does that sound like a good plan to you? Haavard - 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 v3] ppc: Added fls, fls64, __ilog2_u64, and ffs64 to bitops
Kumar Gala <[EMAIL PROTECTED]> wrote: > fls64, __ilog2_u64, ffs64 are variants that work on an u64 and fls > is used to implement them. > > Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> > --- > > Added comment about __ilog2(0) not being generally safe from Haavard > Skinnemoen Looks good. Thanks! Haavard - 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 v2] ppc: Added fls, fls64, __ilog2_u64, and ffs64 to bitops
Kumar Gala <[EMAIL PROTECTED]> wrote:
> +/*
> + * fls: find last (most-significant) bit set.
> + * Note fls(0) = 0, fls(1) = 1, fls(0x8000) = 32.
> + */
> +static __inline__ int fls(unsigned int x)
> +{
> + return __ilog2(x) + 1;
I was sort of hoping you'd add a comment here explaining why it's safe
to rely on undefined behaviour in this particular case. Something like
/* On powerpc, __ilog2(0) returns -1, but this is not safe in general */
Haavard
-
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] ppc: Added fls, fls64, __ilog2_u64, and ffs64 to bitops
Kumar Gala <[EMAIL PROTECTED]> wrote:
>
> On Jun 11, 2008, at 5:54 AM, Haavard Skinnemoen wrote:
>
> > Kumar Gala <[EMAIL PROTECTED]> wrote:
> >> +/*
> >> + * fls: find last (most-significant) bit set.
> >> + * Note fls(0) = 0, fls(1) = 1, fls(0x8000) = 32.
> >> + */
> >> +static __inline__ int fls(unsigned int x)
> >> +{
> >> + return __ilog2(x) + 1;
> >> +}
> >
> > __ilog2(0) returns -1?
>
> it does.
In general, or just on powerpc? If it's the latter, could you add a
comment so that people won't blindly copy it into their architecture's
bitops.h?
Haavard
-
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] ppc: Added fls, fls64, __ilog2_u64, and ffs64 to bitops
Kumar Gala <[EMAIL PROTECTED]> wrote:
> +/*
> + * fls: find last (most-significant) bit set.
> + * Note fls(0) = 0, fls(1) = 1, fls(0x8000) = 32.
> + */
> +static __inline__ int fls(unsigned int x)
> +{
> + return __ilog2(x) + 1;
> +}
__ilog2(0) returns -1?
Haavard
-
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] Add mechanisms for CPU and board-specific Ethernet initialization
On Tue, 10 Jun 2008 01:29:27 -0700
Ben Warren <[EMAIL PROTECTED]> wrote:
> This patch is the first step in cleaning up net/eth.c, by moving Ethernet
> initialization to CPU or board-specific code. Initial implementation is
> only on the Freescale TSEC controller, but others will be added soon.
>
> Signed-off-by: Ben Warren <[EMAIL PROTECTED]>
Sweet!
> ---
>
> When we discussed this a few months ago, I was planning on defining the
> cpu_eth_init() and board_eth_init() functions as weak with no aliases, but in
> my testing this did not result in them being NULL, hence the default function.
Works just as well, doesn't it?
> diff --git a/net/eth.c b/net/eth.c
> index c4f24c6..e75dc43 100644
> --- a/net/eth.c
> +++ b/net/eth.c
> @@ -28,6 +28,12 @@
>
> #if defined(CONFIG_CMD_NET) && defined(CONFIG_NET_MULTI)
>
> +/* CPU and board-specific Ethernet initializations. Aliased function
> + * signals caller to move on */
> +static int __def_eth_init(bd_t *bis) {return -1;}
Just a cosmetic thing: I really think this should look like a normal
function, i.e. not cuddling everything up on one line. I've seen such
things being mistaken for macros before.
Haavard
-
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 v2] Move conditional compilation of MPC8XXX SPI driver to Makefile
Ben Warren <[EMAIL PROTECTED]> wrote: > +/* Controller-specific definitions: */ > + > +/* CONFIG_HARD_SPI triggers SPI bus initialization in PowerPC */ > +#ifdef CONFIG_MPC8XXX_SPI > +# ifndef CONFIG_HARD_SPI > +# define CONFIG_HARD_SPI > +# endif > +#endif Grumble. I'm really looking forward to that Kconfig system so we can get rid of crap like this...it won't exactly become prettier as more SPI drivers are added... Btw, I wonder if the _real_ fix is to move the stuff in spi_init() into spi_claim_bus() and just kill spi_init() altogether. This will match the u-boot design requirement about not touching hardware you don't intend to use a bit more closely. But I can certainly understand that you want to keep the existing code working before doing something like that. Haavard - 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
[U-Boot-Users] [PATCH RESEND #2] Conditionally add -fno-stack-protector to CFLAGS
From: Haavard Skinnemoen <[EMAIL PROTECTED]> When compile-testing on powerpc, I get errors like this: /home/hskinnemoen/work/git/u-boot/net/nfs.c:422: undefined reference to `__stack_chk_fail_local' This seems to be because -fstack-protector is on by default, so let's explicitly disable it on all architectures that support the option. The Ubuntu toolchain is affected by this problem, and according to Mike Frysinger, Gentoo has been running with SSP enabled for years. More and more distros are turning SSP on by default, so this problem is likely to get worse in the future. Also, powerpc just happens to be one of the arches I do compile-testing on. There may be other arches affected by this too. Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]> --- This patch was previously posted * Dec 11 2007 * May 19 2008 Doesn't anyone care about this build breakage? config.mk |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/config.mk b/config.mk index b08b7a7..1dac29b 100644 --- a/config.mk +++ b/config.mk @@ -172,6 +172,8 @@ else CFLAGS := $(CPPFLAGS) -Wall -Wstrict-prototypes endif +CFLAGS += $(call cc-option,-fno-stack-protector) + # avoid trigraph warnings while parsing pci.h (produced by NIOS gcc-2.9) # this option have to be placed behind -Wall -- that's why it is here ifeq ($(ARCH),nios) -- 1.5.5.3 - 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
[U-Boot-Users] [PATCH v2 RESEND] MMC: Consolidate MMC/SD command definitions
This moves the MMC and SD Card command definitions from
include/asm/arch/mmc.h into include/mmc.h. These definitions are given
by the MMC and SD Card standards, not by any particular architecture.
There's a lot more room for consolidation in the MMC drivers which I'm
hoping to get done eventually, but this patch is a start.
Compile-tested for all avr32 boards as well as lpc2292sodimm and
lubbock. This should cover all three mmc drivers in the tree.
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
This patch was originally posted Thu, 22 May 2008 11:09:59 +0200
Changes since v1:
* Split very long line in cpu/pxa/mmc.c
* Fix whitespace damage copied from original mmc headers prior to
the big whitespace cleanup.
cpu/at32ap/atmel_mci.c |4 ++--
cpu/pxa/mmc.c | 11 +++
include/asm-arm/arch-pxa/mmc.h | 17 -
include/asm-avr32/arch-at32ap700x/mmc.h | 19 ---
include/mmc.h | 24
5 files changed, 33 insertions(+), 42 deletions(-)
diff --git a/cpu/at32ap/atmel_mci.c b/cpu/at32ap/atmel_mci.c
index 3795add..61aa184 100644
--- a/cpu/at32ap/atmel_mci.c
+++ b/cpu/at32ap/atmel_mci.c
@@ -349,7 +349,7 @@ static int sd_init_card(struct mmc_cid *cid, int verbose)
mmc_idle_cards();
for (i = 0; i < 1000; i++) {
- ret = mmc_acmd(MMC_ACMD_SD_SEND_OP_COND, CFG_MMC_OP_COND,
+ ret = mmc_acmd(SD_CMD_APP_SEND_OP_COND, CFG_MMC_OP_COND,
resp, R3 | NID);
if (ret || (resp[0] & 0x8000))
break;
@@ -367,7 +367,7 @@ static int sd_init_card(struct mmc_cid *cid, int verbose)
mmc_dump_cid(cid);
/* Get RCA of the card that responded */
- ret = mmc_cmd(MMC_CMD_SD_SEND_RELATIVE_ADDR, 0, resp, R6 | NCR);
+ ret = mmc_cmd(SD_CMD_SEND_RELATIVE_ADDR, 0, resp, R6 | NCR);
if (ret)
return ret;
diff --git a/cpu/pxa/mmc.c b/cpu/pxa/mmc.c
index 039ce0f..4495a80 100644
--- a/cpu/pxa/mmc.c
+++ b/cpu/pxa/mmc.c
@@ -119,7 +119,7 @@ mmc_block_read(uchar * dst, ulong src, ulong len)
MMC_RDTO = 0x;
MMC_NOB = 1;
MMC_BLKLEN = len;
- mmc_cmd(MMC_CMD_READ_BLOCK, argh, argl,
+ mmc_cmd(MMC_CMD_READ_SINGLE_BLOCK, argh, argl,
MMC_CMDAT_R1 | MMC_CMDAT_READ | MMC_CMDAT_BLOCK |
MMC_CMDAT_DATA_EN);
@@ -568,7 +568,7 @@ mmc_init(int verbose)
MMC_SPI = MMC_SPI_DISABLE;
/* reset */
- mmc_cmd(MMC_CMD_RESET, 0, 0, MMC_CMDAT_INIT | MMC_CMDAT_R0);
+ mmc_cmd(MMC_CMD_GO_IDLE_STATE, 0, 0, MMC_CMDAT_INIT | MMC_CMDAT_R0);
udelay(20);
retries = 3;
while (retries--) {
@@ -578,7 +578,10 @@ mmc_init(int verbose)
break;
}
- resp = mmc_cmd(SD_CMD_APP_OP_COND, 0x0020, 0, MMC_CMDAT_R3 |
(retries < 2 ? 0 : MMC_CMDAT_INIT)); /* Select 3.2-3.3 and 3.3-3.4V */
+ /* Select 3.2-3.3 and 3.3-3.4V */
+ resp = mmc_cmd(SD_CMD_APP_SEND_OP_COND, 0x0020, 0,
+ MMC_CMDAT_R3 | (retries < 2 ? 0
+ : MMC_CMDAT_INIT));
if (resp[0] & 0x8000) {
mmc_dev.if_type = IF_TYPE_SD;
debug("Detected SD card\n");
@@ -616,7 +619,7 @@ mmc_init(int verbose)
memcpy(cid_resp, resp, sizeof(cid_resp));
/* MMC exists, get CSD too */
- resp = mmc_cmd(MMC_CMD_SET_RCA, 0, 0, MMC_CMDAT_R1);
+ resp = mmc_cmd(MMC_CMD_SET_RELATIVE_ADDR, 0, 0, MMC_CMDAT_R1);
if (IF_TYPE_SD == mmc_dev.if_type)
rca = ((resp[0] & 0x) >> 16);
resp = mmc_cmd(MMC_CMD_SEND_CSD, rca, 0, MMC_CMDAT_R2);
diff --git a/include/asm-arm/arch-pxa/mmc.h b/include/asm-arm/arch-pxa/mmc.h
index 9440d80..85e144b 100644
--- a/include/asm-arm/arch-pxa/mmc.h
+++ b/include/asm-arm/arch-pxa/mmc.h
@@ -110,23 +110,6 @@
#define MMC_DEFAULT_RCA1
#define MMC_BLOCK_SIZE 512
-#define MMC_CMD_RESET 0
-#define MMC_CMD_SEND_OP_COND 1
-#define MMC_CMD_ALL_SEND_CID 2
-#define MMC_CMD_SET_RCA3
-#define MMC_CMD_SELECT_CARD7
-#define MMC_CMD_SEND_CSD 9
-#define MMC_CMD_SEND_CID 10
-#define MMC_CMD_SEND_STATUS13
-#define MMC_CMD_SET_BLOCKLEN 16
-#define MMC_CMD_READ_BLOCK 17
-#define MMC_CMD_RD_BLK_MULTI 18
-#define MMC_CMD_WRITE_BLOCK24
-#define MMC_CMD_APP_CMD55
-
-#define SD_CMD_APP_SET_BUS_WIDTH 6
-#define SD_CMD_APP_OP_COND 41
-
#define MMC_MAX_BLOCK_SIZE 512
#
Re: [U-Boot-Users] [RFC/PATCH 6/6] Add support for environment in SPI flash
Wolfgang Denk <[EMAIL PROTECTED]> wrote: > In message <[EMAIL PROTECTED]> you wrote: > > This is pretty incomplete...it doesn't handle reading the environment > > before relocation, it doesn't support redundant environment, and it > > doesn't support embedded environment. But apart from that, it does > > seem to work. > > I suppose more patches to add the missing features will follow soon ? Yeah...I didn't actually expect you to apply it, hence the RFC. But now that it's in, I guess I should put in some effort to make it more complete. As for reading the environment before relocation, I don't really know how to do it without using writeable RAM. env_nand does not support this either -- it depends on embedded environment. Haavard - 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
[U-Boot-Users] [GIT PULL] avr32 update
Hi Wolfgang,
Please pull the 'master' branch of
git://git.denx.de/u-boot-avr32.git master
to receive the below updates.
The SPI stuff and a few other patches I've posted are not included here
since they aren't really avr32-related. I'm hoping you'll still apply
them before the merge window closes.
David Brownell (2):
avr32: stk1002 and ngw100 convergence
avr32: Disable the AP7000 internal watchdog on startup
Haavard Skinnemoen (15):
avr32: Use correct condition around macb clock accessors
avr32: Get rid of the .flashprog section
avr32: Add support for the ATSTK1006 board
avr32: Clean up the HMATRIX code
avr32: Remove unused file cpu/at32ap/pm.c
avr32: Use new-style Makefile for the at32ap platform
avr32: Rename pm_init() as clk_init() and make SoC-specific
avr32: Put memset in its own section
avr32: Use the same entry point for reset and exception handling
avr32: Do stricter stack checking in the exception handler
avr32: Rework SDRAM initialization code
avr32: Fix two warnings in atmel_mci.c
avr32: Fix wrong error flags in atmel_mci driver
avr32: Compile atmel_mci.o conditionally
avr32: Fix theoretical race in udelay()
MAINTAINERS|1 +
MAKEALL|1 +
Makefile |3 +
board/atmel/atngw100/atngw100.c| 27 ++-
board/atmel/atngw100/u-boot.lds|9 +-
board/atmel/atstk1000/atstk1000.c | 54 +-
board/atmel/atstk1000/flash.c |6 +-
board/atmel/atstk1000/u-boot.lds |9 +-
cpu/at32ap/Makefile| 20 ++-
cpu/at32ap/at32ap700x/Makefile |2 +-
cpu/at32ap/at32ap700x/clk.c| 68 +++
cpu/at32ap/{ => at32ap700x}/sm.h |0
cpu/at32ap/atmel_mci.c | 12 +-
cpu/at32ap/cpu.c | 50 +-
cpu/at32ap/entry.S | 64 ---
cpu/at32ap/exception.c |3 +-
cpu/at32ap/hsdramc.c | 102 ---
cpu/at32ap/interrupts.c| 16 +-
cpu/at32ap/pm.c| 42 -
cpu/at32ap/start.S | 129 -
include/asm-avr32/arch-at32ap700x/clk.h|4 +-
include/asm-avr32/arch-at32ap700x/hmatrix.h| 61 ++
include/asm-avr32/arch-at32ap700x/hmatrix2.h | 232
include/asm-avr32/arch-at32ap700x/memory-map.h | 20 ++
include/asm-avr32/hmatrix-common.h | 131 +
include/asm-avr32/sdram.h | 27 +++-
include/asm-avr32/sections.h |7 -
include/configs/atngw100.h | 26 +--
include/configs/atstk1002.h| 19 +-
include/configs/atstk1003.h| 15 +-
include/configs/atstk1004.h| 16 +-
include/configs/atstk1006.h| 203 +
lib_avr32/memset.S |2 +-
33 files changed, 817 insertions(+), 564 deletions(-)
create mode 100644 cpu/at32ap/at32ap700x/clk.c
rename cpu/at32ap/{ => at32ap700x}/sm.h (100%)
delete mode 100644 cpu/at32ap/entry.S
delete mode 100644 cpu/at32ap/pm.c
create mode 100644 include/asm-avr32/arch-at32ap700x/hmatrix.h
delete mode 100644 include/asm-avr32/arch-at32ap700x/hmatrix2.h
create mode 100644 include/asm-avr32/hmatrix-common.h
create mode 100644 include/configs/atstk1006.h
-
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] [AT91] Problems configuring bit-banged I2C
Sergey Lapin <[EMAIL PROTECTED]> wrote: > But I'm unable to read proper values from lines - they always > return 0s. Any ideas on fixing? > Linux i2c-gpio driver works perfectly. Please try this patch: http://www.nabble.com/-PATCH--soft_i2c%3A-Pull-SDA-high-before-reading-p17270563.html You shouldn't need to do anything in the I2C_ACTIVE and I2C_TRISTATE hooks since the PIO is properly configured in open drain mode. Haavard - 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 05/18] avr32: Get rid of the .flashprog section
Jean-Christophe PLAGNIOL-VILLARD <[EMAIL PROTECTED]> wrote:
> On 14:36 Fri 23 May , Haavard Skinnemoen wrote:
> > The .flashprog section was only needed back when we were running
> > directly from flash. Remove it on STK1000, and get rid of all the
> > associated code and annotations.
> >
> Is it possible to join patch 4 and 5 which take care of the same thing?
Yeah, splitting them up was silly. I'll join them.
The result is below, and I've also updated the for-1.3.4 branch. Thanks!
Haavard
>From 82c2cbf8b419347d62f83b6c6eb1319e1188e8e4 Mon Sep 17 00:00:00 2001
From: Haavard Skinnemoen <[EMAIL PROTECTED]>
Date: Tue, 29 Apr 2008 12:53:05 +0200
Subject: [PATCH 04/17] avr32: Get rid of the .flashprog section
The .flashprog section was only needed back when we were running
directly from flash, and it's even more useless on NGW100 since it
uses the CFI flash driver which never used this workaround in the
first place.
Remove it on STK1000 as well, and get rid of all the associated code and
annotations.
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
board/atmel/atngw100/u-boot.lds |8
board/atmel/atstk1000/flash.c|6 +++---
board/atmel/atstk1000/u-boot.lds |8
cpu/at32ap/cpu.c |6 --
include/asm-avr32/sections.h |7 ---
5 files changed, 3 insertions(+), 32 deletions(-)
diff --git a/board/atmel/atngw100/u-boot.lds b/board/atmel/atngw100/u-boot.lds
index 34e347a..3c878d8 100644
--- a/board/atmel/atngw100/u-boot.lds
+++ b/board/atmel/atngw100/u-boot.lds
@@ -32,14 +32,6 @@ SECTIONS
*(.text)
*(.text.*)
}
-
- . = ALIGN(32);
- __flashprog_start = .;
- .flashprog : {
- *(.flashprog)
- }
- . = ALIGN(32);
- __flashprog_end = .;
_etext = .;
.rodata : {
diff --git a/board/atmel/atstk1000/flash.c b/board/atmel/atstk1000/flash.c
index 4047825..12537f3 100644
--- a/board/atmel/atstk1000/flash.c
+++ b/board/atmel/atstk1000/flash.c
@@ -30,7 +30,7 @@ DECLARE_GLOBAL_DATA_PTR;
flash_info_t flash_info[1];
-static void __flashprog flash_identify(uint16_t *flash, flash_info_t *info)
+static void flash_identify(uint16_t *flash, flash_info_t *info)
{
unsigned long flags;
@@ -76,7 +76,7 @@ void flash_print_info(flash_info_t *info)
info->size >> 10, info->sector_count);
}
-int __flashprog flash_erase(flash_info_t *info, int s_first, int s_last)
+int flash_erase(flash_info_t *info, int s_first, int s_last)
{
unsigned long flags;
unsigned long start_time;
@@ -154,7 +154,7 @@ int __flashprog flash_erase(flash_info_t *info, int
s_first, int s_last)
return ERR_OK;
}
-int __flashprog write_buff(flash_info_t *info, uchar *src,
+int write_buff(flash_info_t *info, uchar *src,
ulong addr, ulong count)
{
unsigned long flags;
diff --git a/board/atmel/atstk1000/u-boot.lds b/board/atmel/atstk1000/u-boot.lds
index 247812e..f63bc4f 100644
--- a/board/atmel/atstk1000/u-boot.lds
+++ b/board/atmel/atstk1000/u-boot.lds
@@ -32,14 +32,6 @@ SECTIONS
*(.text)
*(.text.*)
}
-
- . = ALIGN(32);
- __flashprog_start = .;
- .flashprog : {
- *(.flashprog)
- }
- . = ALIGN(32);
- __flashprog_end = .;
_etext = .;
.rodata : {
diff --git a/cpu/at32ap/cpu.c b/cpu/at32ap/cpu.c
index 4542e67..a7a66cc 100644
--- a/cpu/at32ap/cpu.c
+++ b/cpu/at32ap/cpu.c
@@ -84,7 +84,6 @@ static void pm_init(void)
int cpu_init(void)
{
extern void _evba(void);
- char *p;
/* in case of soft resets, disable watchdog */
sm_writel(WDT_CTRL, SM_BF(KEY, 0x55));
@@ -104,11 +103,6 @@ int cpu_init(void)
sysreg_write(EVBA, (unsigned long)&_evba);
asm volatile("csrf %0" : : "i"(SYSREG_EM_OFFSET));
- /* Lock everything that mess with the flash in the icache */
- for (p = __flashprog_start; p <= (__flashprog_end + CFG_ICACHE_LINESZ);
-p += CFG_ICACHE_LINESZ)
- asm volatile("cache %0, 0x02" : "=m"(*p) :: "memory");
-
return 0;
}
diff --git a/include/asm-avr32/sections.h b/include/asm-avr32/sections.h
index 75373ab..fe819b2 100644
--- a/include/asm-avr32/sections.h
+++ b/include/asm-avr32/sections.h
@@ -25,15 +25,8 @@
/* References to section boundaries */
extern char _text[], _etext[];
-extern char __flashprog_start[], __flashprog_end[];
extern char _data[], __data_lma[], _edata[], __edata_lma[];
extern char __got_start[], __got_lma[], __got_end[];
extern char _end[];
-/*
- * Everything in .flashprog will be locked in the icache so it doesn't
- * get disturbed when executing flash
Re: [U-Boot-Users] [PATCH 06/18] avr32: Add support for the ATSTK1006 board
Jean-Christophe PLAGNIOL-VILLARD <[EMAIL PROTECTED]> wrote: > > +#define CFG_DCACHE_LINESZ 32 > > +#define CFG_ICACHE_LINESZ 32 > > + > > +#define CONFIG_NR_DRAM_BANKS 1 > > + > > +/* External flash on STK1000 */ > > +#if 0 > is it possible to use CFG_EXTERNAL_FLASH or something? > > +#define CFG_FLASH_CFI 1 > > +#define CFG_FLASH_CFI_DRIVER 1 > > +#endif Actually, I've been wanting to switch to the CFI driver for the STK1000 and its derivatives for a long time. However, the (obsolete) AT49BV6416 chip needs a fixup due to wrong erase region information, and there's currently no way to tell it apart from AT49BV642D, which doesn't need the fixup, since the CFI driver only reads the lower 8 bits of the device ID. So while fixing the CFI driver isn't exactly top priority right now, this #if 0 block is very much intended as a temporary thing. > > +/* Other configuration settings that shouldn't have to change all that > > often */ > > +#define CFG_PROMPT "Uboot> " > In the precedent patch you put U-Boot is possible to do it here too? Absolutely. Nice catch. I'm going to fold the below patch into this; there were a couple of other things that weren't in sync with patch #1 as well. Thanks for reviewing! Haavard --- include/configs/atstk1006.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/configs/atstk1006.h b/include/configs/atstk1006.h index c3de434..9fd49a5 100644 --- a/include/configs/atstk1006.h +++ b/include/configs/atstk1006.h @@ -141,9 +141,9 @@ #define CONFIG_CMD_FAT #define CONFIG_CMD_JFFS2 #define CONFIG_CMD_MMC -#define CONFIG_CMD_REGINFO #undef CONFIG_CMD_AUTOSCRIPT +#undef CONFIG_CMD_FPGA #undef CONFIG_CMD_SETGETDCR #undef CONFIG_CMD_XIMG @@ -190,7 +190,7 @@ #define CFG_BOOTPARAMS_LEN (16 * 1024) /* Other configuration settings that shouldn't have to change all that often */ -#define CFG_PROMPT "Uboot> " +#define CFG_PROMPT "U-Boot> " #define CFG_CBSIZE 256 #define CFG_MAXARGS16 #define CFG_PBSIZE (CFG_CBSIZE + sizeof(CFG_PROMPT) + 16) -- 1.5.5.1 - 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
<[EMAIL PROTECTED]> wrote:
> Haavard Skinnemoen wrote:
>
> > The warnings are harmless but annoying. Let's fix them.
>
> If the warnings are "harmless", why are you "fixing them"?
They are "harmless" as in "doesn't actually cause any wrong behaviour".
But as Scott points out, they may make warnings that indicate real
problems harder to catch.
For example, if someone comes along and changes the signature of the
"block_read" hook in struct block_dev_desc, I may not notice because
gcc is _already_ warning about a possible mismatch.
> The compiler has switches to turn off warnings, if they
> annoy you too much.
Well, sure. But the "assignment to incompatible pointer type" is
usually very good at catching real API violations, so even if it in
this case catches code that is merely ugly, turning it off altogether
would be the wrong thing to do IMO.
On the other hand, the "may be used uninitialized" warning tends to
come up with a lot of false positives, but there's AFAIK no way to turn
it off without also turning off the "is used uninitialized" warning,
which is very useful.
> Does this refactoring of the code do something more than
> just avoid a warning or two? If not, I would reject it.
I wouldn't call these tiny changes "refactoring". And I can't see any
downsides except _maybe_ two bytes of additional .text usage.
I have to admit I wasn't sure about this one though:
> > @@ -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];
While I'm no fan of adding spurious initializations just because gcc
can't figure out what the code is doing well enough to prove that it is
always initialized, I think that in this case, it certainly isn't
obvious, and 0 is a reasonable default.
So I decided to add it anyway, just in case later changes makes the
assumption invalid.
Haavard
-
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
[U-Boot-Users] [PATCH 10/18] avr32: Rename pm_init() as clk_init() and make SoC-specific
pm_init() was always more about clock initialization than anything
else. Dealing with PLLs, clock gating and such is also inherently
SoC-specific, so move it into a SoC-specific directory.
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
cpu/at32ap/at32ap700x/Makefile |2 +-
cpu/at32ap/at32ap700x/clk.c | 68 +++
cpu/at32ap/{ => at32ap700x}/sm.h|0
cpu/at32ap/cpu.c| 48 ++---
include/asm-avr32/arch-at32ap700x/clk.h |2 +
5 files changed, 76 insertions(+), 44 deletions(-)
create mode 100644 cpu/at32ap/at32ap700x/clk.c
rename cpu/at32ap/{ => at32ap700x}/sm.h (100%)
diff --git a/cpu/at32ap/at32ap700x/Makefile b/cpu/at32ap/at32ap700x/Makefile
index d276712..7404235 100644
--- a/cpu/at32ap/at32ap700x/Makefile
+++ b/cpu/at32ap/at32ap700x/Makefile
@@ -24,7 +24,7 @@ include $(TOPDIR)/config.mk
LIB:= $(obj)lib$(SOC).a
-COBJS := gpio.o
+COBJS := gpio.o clk.o
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS))
diff --git a/cpu/at32ap/at32ap700x/clk.c b/cpu/at32ap/at32ap700x/clk.c
new file mode 100644
index 000..b3aa034
--- /dev/null
+++ b/cpu/at32ap/at32ap700x/clk.c
@@ -0,0 +1,68 @@
+/*
+ * Copyright (C) 2005-2008 Atmel Corporation
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+#include
+
+#include
+
+#include
+#include
+
+#include "sm.h"
+
+void clk_init(void)
+{
+ uint32_t cksel;
+
+ /* in case of soft resets, disable watchdog */
+ sm_writel(WDT_CTRL, SM_BF(KEY, 0x55));
+ sm_writel(WDT_CTRL, SM_BF(KEY, 0xaa));
+
+#ifdef CONFIG_PLL
+ /* Initialize the PLL */
+ sm_writel(PM_PLL0, (SM_BF(PLLCOUNT, CFG_PLL0_SUPPRESS_CYCLES)
+ | SM_BF(PLLMUL, CFG_PLL0_MUL - 1)
+ | SM_BF(PLLDIV, CFG_PLL0_DIV - 1)
+ | SM_BF(PLLOPT, CFG_PLL0_OPT)
+ | SM_BF(PLLOSC, 0)
+ | SM_BIT(PLLEN)));
+
+ /* Wait for lock */
+ while (!(sm_readl(PM_ISR) & SM_BIT(LOCK0))) ;
+#endif
+
+ /* Set up clocks for the CPU and all peripheral buses */
+ cksel = 0;
+ if (CFG_CLKDIV_CPU)
+ cksel |= SM_BIT(CPUDIV) | SM_BF(CPUSEL, CFG_CLKDIV_CPU - 1);
+ if (CFG_CLKDIV_HSB)
+ cksel |= SM_BIT(HSBDIV) | SM_BF(HSBSEL, CFG_CLKDIV_HSB - 1);
+ if (CFG_CLKDIV_PBA)
+ cksel |= SM_BIT(PBADIV) | SM_BF(PBASEL, CFG_CLKDIV_PBA - 1);
+ if (CFG_CLKDIV_PBB)
+ cksel |= SM_BIT(PBBDIV) | SM_BF(PBBSEL, CFG_CLKDIV_PBB - 1);
+ sm_writel(PM_CKSEL, cksel);
+
+#ifdef CONFIG_PLL
+ /* Use PLL0 as main clock */
+ sm_writel(PM_MCCTRL, SM_BIT(PLLSEL));
+#endif
+}
diff --git a/cpu/at32ap/sm.h b/cpu/at32ap/at32ap700x/sm.h
similarity index 100%
rename from cpu/at32ap/sm.h
rename to cpu/at32ap/at32ap700x/sm.h
diff --git a/cpu/at32ap/cpu.c b/cpu/at32ap/cpu.c
index a7a66cc..0ba8361 100644
--- a/cpu/at32ap/cpu.c
+++ b/cpu/at32ap/cpu.c
@@ -30,7 +30,6 @@
#include
#include "hsmc3.h"
-#include "sm.h"
/* Sanity checks */
#if (CFG_CLKDIV_CPU > CFG_CLKDIV_HSB) \
@@ -44,51 +43,10 @@
DECLARE_GLOBAL_DATA_PTR;
-static void pm_init(void)
-{
- uint32_t cksel;
-
-#ifdef CONFIG_PLL
- /* Initialize the PLL */
- sm_writel(PM_PLL0, (SM_BF(PLLCOUNT, CFG_PLL0_SUPPRESS_CYCLES)
- | SM_BF(PLLMUL, CFG_PLL0_MUL - 1)
- | SM_BF(PLLDIV, CFG_PLL0_DIV - 1)
- | SM_BF(PLLOPT, CFG_PLL0_OPT)
- | SM_BF(PLLOSC, 0)
- | SM_BIT(PLLEN)));
-
- /* Wait for lock */
- while (!(sm_readl(PM_ISR) & SM_BIT(LOCK0))) ;
-#endif
-
- /* Set up clocks for the CPU and all peripheral buses */
- cksel = 0;
- if (CFG_CLKDIV_CPU)
- cksel |= SM_BIT(CPUDIV) | SM_BF(CPUSEL, CFG_CLKDIV_CPU - 1);
- if (CFG_CLKDIV_HSB)
- cksel |= SM_BIT(HSBDIV) | SM_BF(HSBSEL, CFG_CLKDIV_HSB - 1);
- if (CFG_CLKDIV_PBA)
- cksel |= SM_BIT(PBADIV) | SM_BF(PB
[U-Boot-Users] [PATCH 18/18] avr32: Compile atmel_mci.o conditionally
Remove #ifdef CONFIG_MMC from the source file and use conditional
compilation in the Makefile instead.
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
-#ifdef CONFIG_MMC
-
#include
#include
@@ -548,5 +546,3 @@ int mmc2info(ulong addr)
{
return 0;
}
-
-#endif /* CONFIG_MMC */
--
1.5.5.1
-
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
[U-Boot-Users] [PATCH 17/18] avr32: Fix wrong error flags in atmel_mci driver
Make sure we check for CRC errors when sending commands that use CRC
checking.
Reported-by: Gururaja Hebbar K R <[EMAIL PROTECTED]>
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
cpu/at32ap/atmel_mci.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cpu/at32ap/atmel_mci.c b/cpu/at32ap/atmel_mci.c
index 3ce9ea5..226b5c0 100644
--- a/cpu/at32ap/atmel_mci.c
+++ b/cpu/at32ap/atmel_mci.c
@@ -139,7 +139,7 @@ mmc_cmd(unsigned long cmd, unsigned long arg,
pr_debug("mmc: status 0x%08lx\n", status);
- if (status & ERROR_FLAGS) {
+ if (status & error_flags) {
printf("mmc: command %lu failed (status: 0x%08lx)\n",
cmd, status);
return -EIO;
--
1.5.5.1
-
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
[U-Boot-Users] [PATCH 14/18] avr32: Rework SDRAM initialization code
This cleans up the SDRAM initialization and related code a bit, and
allows faster booting.
* Add definitions for EBI and internal SRAM to asm/arch/memory-map.h
* Remove memory test from sdram_init() and make caller responsible
for verifying the SDRAM and determining its size.
* Remove base_address member from struct sdram_config (was sdram_info)
* Add data_bits member to struct sdram_config and kill CFG_SDRAM_16BIT
* Add support for a common STK1000 hack: 16MB SDRAM instead of 8.
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
board/atmel/atngw100/atngw100.c| 21 -
board/atmel/atstk1000/atstk1000.c | 42 ---
cpu/at32ap/hsdramc.c | 102 +---
include/asm-avr32/arch-at32ap700x/memory-map.h | 20 +
include/asm-avr32/sdram.h | 27 +-
include/configs/atngw100.h | 21 ++---
include/configs/atstk1002.h| 13 ++--
include/configs/atstk1003.h| 13 ++--
include/configs/atstk1004.h| 14 ++--
include/configs/atstk1006.h| 13 ++--
10 files changed, 166 insertions(+), 120 deletions(-)
diff --git a/board/atmel/atngw100/atngw100.c b/board/atmel/atngw100/atngw100.c
index 3ff6f0f..c649855 100644
--- a/board/atmel/atngw100/atngw100.c
+++ b/board/atmel/atngw100/atngw100.c
@@ -29,8 +29,8 @@
DECLARE_GLOBAL_DATA_PTR;
-static const struct sdram_info sdram = {
- .phys_addr = CFG_SDRAM_BASE,
+static const struct sdram_config sdram_config = {
+ .data_bits = SDRAM_DATA_16BIT,
.row_bits = 13,
.col_bits = 9,
.bank_bits = 2,
@@ -66,7 +66,22 @@ int board_early_init_f(void)
long int initdram(int board_type)
{
- return sdram_init(&sdram);
+ unsigned long expected_size;
+ unsigned long actual_size;
+ void *sdram_base;
+
+ sdram_base = map_physmem(EBI_SDRAM_BASE, EBI_SDRAM_SIZE, MAP_NOCACHE);
+
+ expected_size = sdram_init(sdram_base, &sdram_config);
+ actual_size = get_ram_size(sdram_base, expected_size);
+
+ unmap_physmem(sdram_base, EBI_SDRAM_SIZE);
+
+ if (expected_size != actual_size)
+ printf("Warning: Only %u of %u MiB SDRAM is working\n",
+ actual_size >> 20, expected_size >> 20);
+
+ return actual_size;
}
void board_init_info(void)
diff --git a/board/atmel/atstk1000/atstk1000.c
b/board/atmel/atstk1000/atstk1000.c
index 52fec65..33bdba6 100644
--- a/board/atmel/atstk1000/atstk1000.c
+++ b/board/atmel/atstk1000/atstk1000.c
@@ -29,10 +29,10 @@
DECLARE_GLOBAL_DATA_PTR;
-#ifdef CONFIG_ATSTK1006
-/* Dual MT48LC16M16A2-7E on daughterboard */
-static const struct sdram_info sdram = {
- .phys_addr = CFG_SDRAM_BASE,
+static const struct sdram_config sdram_config = {
+#if defined(CONFIG_ATSTK1006)
+ /* Dual MT48LC16M16A2-7E (64 MB) on daughterboard */
+ .data_bits = SDRAM_DATA_32BIT,
.row_bits = 13,
.col_bits = 9,
.bank_bits = 2,
@@ -45,12 +45,19 @@ static const struct sdram_info sdram = {
.txsr = 7,
/* 7.81 us */
.refresh_period = (781 * (SDRAMC_BUS_HZ / 1000)) / 10,
-};
#else
-/* MT48LC2M32B2-5 on motherboard */
-static const struct sdram_info sdram = {
- .phys_addr = CFG_SDRAM_BASE,
+ /* MT48LC2M32B2P-5 (8 MB) on motherboard */
+#ifdef CONFIG_ATSTK1004
+ .data_bits = SDRAM_DATA_16BIT,
+#else
+ .data_bits = SDRAM_DATA_32BIT,
+#endif
+#ifdef CONFIG_ATSTK1000_16MB_SDRAM
+ /* MT48LC4M32B2P-6 (16 MB) on mod'ed motherboard */
+ .row_bits = 12,
+#else
.row_bits = 11,
+#endif
.col_bits = 8,
.bank_bits = 2,
.cas= 3,
@@ -62,8 +69,8 @@ static const struct sdram_info sdram = {
.txsr = 5,
/* 15.6 us */
.refresh_period = (156 * (SDRAMC_BUS_HZ / 1000)) / 1,
-};
#endif
+};
int board_early_init_f(void)
{
@@ -85,7 +92,22 @@ int board_early_init_f(void)
long int initdram(int board_type)
{
- return sdram_init(&sdram);
+ unsigned long expected_size;
+ unsigned long actual_size;
+ void *sdram_base;
+
+ sdram_base = map_physmem(EBI_SDRAM_BASE, EBI_SDRAM_SIZE, MAP_NOCACHE);
+
+ expected_size = sdram_init(sdram_base, &sdram_config);
+ actual_size = get_ram_size(sdram_base, expected_size);
+
+ unmap_physmem(sdram_base, EBI_SDRAM_SIZE);
+
+ if (expected_size != actual_size)
+ printf("Warning: Only %u of %u MiB SDRAM is working\n",
+ actual_size >> 20, expected_size >> 20);
+
+ return actual_size;
}
void board_init_info(void)
diff --git a/cpu/at32ap/hsdramc.c b/cpu/at32ap/hsdramc.c
in
[U-Boot-Users] [PATCH 16/18] avr32: Fix two warnings in atmel_mci.c
The warnings are harmless but annoying. Let's fix them.
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
-
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
[U-Boot-Users] [PATCH 08/18] avr32: Remove unused file cpu/at32ap/pm.c
Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]> --- cpu/at32ap/pm.c | 42 -- 1 files changed, 0 insertions(+), 42 deletions(-) delete mode 100644 cpu/at32ap/pm.c diff --git a/cpu/at32ap/pm.c b/cpu/at32ap/pm.c deleted file mode 100644 index c78d547..000 --- a/cpu/at32ap/pm.c +++ /dev/null @@ -1,42 +0,0 @@ -/* - * Copyright (C) 2006 Atmel Corporation - * - * See file CREDITS for list of people who contributed to this - * project. - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License as - * published by the Free Software Foundation; either version 2 of - * the License, or (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, - * MA 02111-1307 USA - */ -#include - -#ifdef CFG_POWER_MANAGER -#include -#include - -#include - -#include "sm.h" - - -#ifdef CONFIG_PLL -#define MAIN_CLK_RATE ((CFG_OSC0_HZ / CFG_PLL0_DIV) * CFG_PLL0_MUL) -#else -#define MAIN_CLK_RATE (CFG_OSC0_HZ) -#endif - -DECLARE_GLOBAL_DATA_PTR; - - -#endif /* CFG_POWER_MANAGER */ -- 1.5.5.1 - 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
[U-Boot-Users] [PATCH 09/18] avr32: Use new-style Makefile for the at32ap platform
This makes it easier to avoid compiling certain files later. Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]> --- cpu/at32ap/Makefile | 21 ++--- 1 files changed, 14 insertions(+), 7 deletions(-) diff --git a/cpu/at32ap/Makefile b/cpu/at32ap/Makefile index f69b1f3..8e384c7 100644 --- a/cpu/at32ap/Makefile +++ b/cpu/at32ap/Makefile @@ -27,13 +27,20 @@ include $(TOPDIR)/config.mk LIB:= $(obj)lib$(CPU).a -START := start.o -SOBJS := entry.o -COBJS := cpu.o hsdramc.o exception.o cache.o -COBJS += interrupts.o pio.o atmel_mci.o -SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c) -OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS)) -START := $(addprefix $(obj),$(START)) +START-y+= start.o + +SOBJS-y+= entry.o +COBJS-y+= cpu.o +COBJS-y+= hsdramc.o +COBJS-y+= exception.o +COBJS-y+= cache.o +COBJS-y+= interrupts.o +COBJS-y+= pio.o +COBJS-y+= atmel_mci.o + +SRCS := $(START-y:.o=.S) $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c) +OBJS := $(addprefix $(obj),$(SOBJS-y) $(COBJS-y)) +START := $(addprefix $(obj),$(START-y)) all: $(obj).depend $(START) $(LIB) -- 1.5.5.1 - 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
