Re: [U-Boot-Users] Changing u-boot relocation scheme
On Wed, Jul 23, 2008 at 10:39:00AM -0700, vb wrote: While this relocation is seamless for u-boot in its released form, it becomes a pain each time a module needs to be added (not necessarily for following release to the Open Source community, for instance used for inhouse installations which include tens of thousand units for some companies). If these added modules were not written in position independent manner (namely, using structures with multiple stage indirect pointers interleaved with data), the effort to make these modules work in u-boot is very exhausting. Note that in U-Boot-v2 we have loadable module support; code can EXPORT_SYMBOL() public APIs to other components, which, for example, can be such custom modules. The mechanism was invented for the scenario you describe above. It comes for a cost (footprint), but the overhead is not so big as one might think. You can play around with the feature by building the sandbox target, which is a user-mode-u-boot (port of u-boot to Linux userspace). rsc -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Changing u-boot relocation scheme
Wolfgang, thank you for your reply, let me try to explain myself a bit clearer:
On Wed, Jul 23, 2008 at 8:18 PM, Wolfgang Denk [EMAIL PROTECTED] wrote:
In message [EMAIL PROTECTED] you wrote:
some companies). If these added modules were not written in position
independent manner (namely, using structures with multiple stage
indirect pointers interleaved with data), the effort to make these
modules work in u-boot is very exhausting.
I don't understand what you mean. Either you link statically with the
U-Boot image, or you use standalone programs. In both situations no
such problem as described by you exists.
we talk here about modules statically linked into the u-boot image.
Allow me to illustrate the problem I am trying to solve. Consider
adding this code to a u-boot source file on a ppc460gt platform:
vvv
87a88,105
int do_ptrt (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]);
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;
}
U_BOOT_CMD(
ptrt, CFG_MAXARGS, 1, do_ptrt,
ptrt\n,
);
^^^
And this is what happens when this command is invoked:
vvv
= ptrt
pointer is fffb2754
function is 0ffb7754
So, the value of 'pf' is equal to the address of do_ptrt() *before*
relocation. The fact that there is a GOT and a sophisticated linker
script did not prevent this from happening.
Here is the suggested alternative. I will talk about recent PPC
platforms, but it could be done very similar for most of the other
platforms I believe.
I don't think so.
Admittedly I don't have experience with nearly as many different
platforms as you do, but I don't see why not, is there a specific
fundamental reason on any of the platforms? But even if this does not
work on some, it will work on most.
In general the PPC u-boot image consists of three parts: the bulk of
No, this is by far not general, not even for PPC.
I used that particular layout to emphasize that care needs to be taken
to remove the fixed address sections (the last 4k memory page in this
case) from the set of modules to link. On other architectures this
would be a different part of the image linked to the reset vector, the
idea remains the same.
Then we compare the two images and identify all locations which are
different. All these locations are 4 byte aligned, and all differ by
the same amount - equal TEXT_BASE. Now we can build a table of offsets
which need to be changed when the program is moved into a different
location, include this table in the resulting image between the bulk
and the startup page, and use this table when relocating code.
Why would we do that? The compiler already generates such a table for
free - the GOT.
well, didn't the example above show that the compiler will not do that
to an arbitrary pointer to a text object?
Basically, this implements a poor man's loader, and it will be
sufficient in case the image we are dealing with is a flat binary
(which is of course the case with u-boot). This will allow to add any
code to u-boot without much worries about being able to relocate it
properly. We would do away with storing certain structures in certain
sections, dealing with GOT, etc.
I don't see how your poor man's GOT would be any better than the
compiler generated one - except that it's horribly non-standard and
glumpsy?
Quite frankly, GOT is also clumsy and even ugly IMHO - it requires a
lot of special treatment, explicit data definitions and linker
scripts, and does not work for arbitrary data as we saw above.
I made some experiments, and this seems feasible, this could be done
as a local customization, but I would much prefer to release it to the
u-boot community and make it part of mainline - will you consider such
a patch?
I don't understand which problem you're trying to fix, and I don't see
that your solution would be any better than what we have now.
I beg to differ, the solution I am suggesting will allow to stop
worrying about placing data in special sections, and will allow to
link in third party modules which use cross segment pointers.
[snip]
because the modules are now part of u-boot, they need to be relocated
along with the rest of the image.
U-Boot does this (if statically linked) the very same way like all
other U-Boot code gets relocated.
not for pointers to functions as we saw above, right?
Why isn't it written in position independent manner?
because they come from different sources, not concerned with u-boot,
and just work and need to be ported as is.
If you want to link against U-Boot, you have
[U-Boot-Users] test
test _ 这里好多好玩的视频，用鼠标点到视频看看，有惊喜！ http://cnweb.search.live.com/video/results.aspx?q=%E5%A5%A5%E8%BF%90%E5%9C%A3%E7%81%ABmkt=zh-cnFORM=WLMTWC- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] Fix duplicated flash state
On Tue, Jul 22, 2008 at 10:09 AM, Kyungmin Park [EMAIL PROTECTED]
wrote:
Move to one place
I just compiled test. Please check other NAND users.
It fails to build, redefinition of id:
jffs2_1pass.c: In function 'put_fl_mem':
jffs2_1pass.c:466: error: redefinition of 'id'
jffs2_1pass.c:459: error: previous definition of 'id' was here
Relevant piece of code:
static inline void put_fl_mem(void *buf)
{
#if defined(CONFIG_JFFS2_NAND) \
defined(CONFIG_CMD_NAND)
struct mtdids *id = current_part-dev-id;
if (id-type == MTD_DEV_TYPE_NAND)
return put_fl_mem_nand(buf);
#endif
#if defined(CONFIG_CMD_ONENAND)
struct mtdids *id = current_part-dev-id;
if (id-type == MTD_DEV_TYPE_ONENAND)
return put_fl_mem_onenand(buf);
#endif
}
cheers,
Fathi
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/1] Add support for 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/1] Add support for 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=100url=/ ___ 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/1] Add support for ATMEL AT91SAM9G20EK board
From 81230b02610c06fdc8a175e635851346488e3bdb Mon Sep 17 00:00:00 2001 From: Hong Xu [EMAIL PROTECTED] Date: Thu, 24 Jul 2008 14:25:05 +0800 Subject: [PATCH 1/1] Add support for ATMEL AT91SAM9G20EK board This patch adds support for ATMEL AT91SAM9G20EK board. User manual for AT91SAM9G20EK board, see http://www.atmel.com/dyn/resources/prod_documents/doc6413.pdf AT91 SAM9G20 datasheet, see http://www.atmel.com/dyn/resources/prod_documents/doc6384.pdf Signed-off-by: Hong Xu [EMAIL PROTECTED] --- Makefile |3 + board/atmel/at91sam9g20ek/Makefile| 57 +++ board/atmel/at91sam9g20ek/at91sam9g20ek.c | 250 + board/atmel/at91sam9g20ek/config.mk |1 + board/atmel/at91sam9g20ek/led.c | 64 board/atmel/at91sam9g20ek/nand.c | 79 + board/atmel/at91sam9g20ek/partition.c | 40 + drivers/net/macb.c|4 +- include/asm-arm/arch-at91sam9/hardware.h |2 +- include/configs/at91sam9g20ek.h | 202 +++ net/eth.c |2 +- 11 files changed, 700 insertions(+), 4 deletions(-) create mode 100644 board/atmel/at91sam9g20ek/Makefile create mode 100644 board/atmel/at91sam9g20ek/at91sam9g20ek.c create mode 100644 board/atmel/at91sam9g20ek/config.mk create mode 100644 board/atmel/at91sam9g20ek/led.c create mode 100644 board/atmel/at91sam9g20ek/nand.c create mode 100644 board/atmel/at91sam9g20ek/partition.c create mode 100644 include/configs/at91sam9g20ek.h diff --git a/Makefile b/Makefile index 369bbd7..c7ed34d 100644 --- a/Makefile +++ b/Makefile @@ -2388,6 +2388,9 @@ at91cap9adk_config: unconfig at91sam9260ek_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm926ejs at91sam9260ek atmel at91sam9 +at91sam9g20ek_config : unconfig + @$(MKCONFIG) $(@:_config=) arm arm926ejs at91sam9g20ek atmel at91sam9 + ## ARM Integrator boards - see doc/README-integrator for more info. integratorap_config\ diff --git a/board/atmel/at91sam9g20ek/Makefile b/board/atmel/at91sam9g20ek/Makefile new file mode 100644 index 000..cdf5d34 --- /dev/null +++ b/board/atmel/at91sam9g20ek/Makefile @@ -0,0 +1,57 @@ +# +# (C) Copyright 2003-2008 +# Wolfgang Denk, DENX Software Engineering, [EMAIL PROTECTED] +# +# (C) Copyright 2008 +# Stelian Pop [EMAIL PROTECTED] +# Lead Tech Design www.leadtechdesign.com +# +# 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-y+= at91sam9g20ek.o +COBJS-y+= led.o +COBJS-y+= partition.o +COBJS-$(CONFIG_CMD_NAND) += nand.o + +SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS-y)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak $(obj).depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/atmel/at91sam9g20ek/at91sam9g20ek.c b/board/atmel/at91sam9g20ek/at91sam9g20ek.c new file mode 100644 index 000..f47b7bb --- /dev/null +++ b/board/atmel/at91sam9g20ek/at91sam9g20ek.c @@ -0,0 +1,250 @@ +/* + * (C) Copyright 2007-2008 + * Stelian Pop [EMAIL PROTECTED] + * Lead Tech Design www.leadtechdesign.com + * + * 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 +
Re: [U-Boot-Users] [PATCH 1/1] Add support for the hammerhead (AVR32) board
On Thu, 24 Jul 2008, Haavard Skinnemoen wrote: 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. 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. - Julien 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/1] Add support for 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/1] Add support for 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] Correct ARM Versatile Timer Initialization
Hi,
Sorry. Re-sending as uboot-mailing list was not properly Included last
time
Regards
Gururaja
- According to ARM Dual-Timer Module (SP804) TRM (ARM DDI0271),
--Timer Value Register @ TIMER Base + 4 is Read-only. So removed code
which writes to this register
--Prescale Value (Bits 3-2 of TIMER Control register) can only be one of
00,01,10. 11 is undefined.
So bringing Correcting the same to point to 00.
Signed-off-by: Gururaja Hebbar [EMAIL PROTECTED]
blocked::mailto:[EMAIL PROTECTED]
---
cpu/arm926ejs/versatile/timer.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/cpu/arm926ejs/versatile/timer.c
b/cpu/arm926ejs/versatile/timer.c
index 32872d2..9659b67 100644
--- a/cpu/arm926ejs/versatile/timer.c
+++ b/cpu/arm926ejs/versatile/timer.c
@@ -50,8 +50,7 @@ static ulong lastdec;
int timer_init (void)
{
*(volatile ulong *)(CFG_TIMERBASE + 0) = CFG_TIMER_RELOAD; /*
TimerLoad */
- *(volatile ulong *)(CFG_TIMERBASE + 4) = CFG_TIMER_RELOAD; /*
TimerValue */
- *(volatile ulong *)(CFG_TIMERBASE + 8) = 0x8C;
+ *(volatile ulong *)(CFG_TIMERBASE + 8) = 0x80;
/* init the timestamp and lastdec value */
reset_timer_masked();
--
1.5.6
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] 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=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/1] Add support for the hammerhead (AVR32) board
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...
btw. I did update the implementation function header from void to int.
- Julien
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/1] Add support for 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=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/1] 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/1] Add support for ATMEL AT91SAM9G20EK board
On 15:41 Thu 24 Jul , Hong Xu wrote: From 81230b02610c06fdc8a175e635851346488e3bdb Mon Sep 17 00:00:00 2001 From: Hong Xu [EMAIL PROTECTED] Date: Thu, 24 Jul 2008 14:25:05 +0800 Subject: [PATCH 1/1] Add support for ATMEL AT91SAM9G20EK board This patch adds support for ATMEL AT91SAM9G20EK board. User manual for AT91SAM9G20EK board, see http://www.atmel.com/dyn/resources/prod_documents/doc6413.pdf AT91 SAM9G20 datasheet, see http://www.atmel.com/dyn/resources/prod_documents/doc6384.pdf Signed-off-by: Hong Xu [EMAIL PROTECTED] --- Makefile |3 + board/atmel/at91sam9g20ek/Makefile| 57 +++ board/atmel/at91sam9g20ek/at91sam9g20ek.c | 250 + board/atmel/at91sam9g20ek/config.mk |1 + board/atmel/at91sam9g20ek/led.c | 64 board/atmel/at91sam9g20ek/nand.c | 79 + board/atmel/at91sam9g20ek/partition.c | 40 + drivers/net/macb.c|4 +- include/asm-arm/arch-at91sam9/hardware.h |2 +- include/configs/at91sam9g20ek.h | 202 +++ include/asm-arm/arch-at91sam9/hardware.h |2 +- include/configs/at91sam9g20ek.h | 202 +++ net/eth.c |2 +- Please rebase your code on the branch for-1.3.5 of the u-boot-at91 tree. --- 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) macb_writel(macb, USRIO, MACB_BIT(RMII) | MACB_BIT(CLKEN)); #else macb_writel(macb, USRIO, 0); #endif #else #if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || \ -defined(CONFIG_AT91SAM9263) +defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91SAM9G20) macb_writel(macb, USRIO, MACB_BIT(CLKEN)); #else macb_writel(macb, USRIO, MACB_BIT(MII)); diff --git a/net/eth.c b/net/eth.c index 38979aa..3f50e2b 100644 --- a/net/eth.c +++ b/net/eth.c @@ -287,7 +287,7 @@ int eth_initialize(bd_t *bis) mcdmafec_initialize(bis); #endif #if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || \ -defined(CONFIG_AT91SAM9263) +defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91SAM9G20) at91sam9_eth_initialize(bis); #endif at91sam9_eth_initialize(bis); #endif Same comment as Haavard, Could please create a CONFIG_SOMETHING for each of this tree block of ifdef (not neccessarely the same CONFIG) Best Regards, J. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/1] Add support for the hammerhead (AVR32) board
On Thu, 24 Jul 2008, Haavard Skinnemoen wrote:
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?
Did so and it works now. I could make for this an incremental patch and
send this to you.
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.
btw. I did update the implementation function header from void to int.
Yeah, that's probably a good idea too :-)
Haavard
- Julien
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/1] Add support for 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] (Resubmit) Added support toflash_real_protect for Atmel flash devices (tested with AT49BV6416)
Some of the flash memories produced by ATMEL start in read-only mode. We
need to unprotect it.
This patch allows the AT49BV6416 to work with cfi_flash memories. Tested
in the at91rm9200ek board.
Signed-off-by: Rafael Campos Las Heras [EMAIL PROTECTED]
---
drivers/mtd/cfi_flash.c | 40 ++--
1 files changed, 34 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index 4340b1b..8d12eb8 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -103,6 +103,10 @@
#define AMD_STATUS_TOGGLE 0x40
#define AMD_STATUS_ERROR 0x20
+#define ATM_CMD_UNLOCK_SECT0x70
+#define ATM_CMD_SOFTLOCK_START 0x80
+#define ATM_CMD_LOCK_SECT 0x40
+
#define FLASH_OFFSET_MANUFACTURER_ID 0x00
#define FLASH_OFFSET_DEVICE_ID 0x01
#define FLASH_OFFSET_DEVICE_ID20x0E
@@ -1348,12 +1352,36 @@ int flash_real_protect (flash_info_t * info,
long
sector, int prot)
{
int retcode = 0;
- flash_write_cmd (info, sector, 0, FLASH_CMD_CLEAR_STATUS);
- flash_write_cmd (info, sector, 0, FLASH_CMD_PROTECT);
- if (prot)
- flash_write_cmd (info, sector, 0,
FLASH_CMD_PROTECT_SET);
- else
- flash_write_cmd (info, sector, 0,
FLASH_CMD_PROTECT_CLEAR);
+ switch (info-vendor) {
+ case CFI_CMDSET_INTEL_PROG_REGIONS:
+ case CFI_CMDSET_INTEL_STANDARD:
+ flash_write_cmd (info, sector, 0,
FLASH_CMD_CLEAR_STATUS);
+ flash_write_cmd (info, sector, 0,
FLASH_CMD_PROTECT);
+ if (prot)
+ flash_write_cmd (info, sector, 0,
FLASH_CMD_PROTECT_SET);
+ else
+ flash_write_cmd (info, sector, 0,
FLASH_CMD_PROTECT_CLEAR);
+ break;
+ case CFI_CMDSET_AMD_EXTENDED:
+ case CFI_CMDSET_AMD_STANDARD:
+#ifdef CONFIG_FLASH_CFI_LEGACY
+ case CFI_CMDSET_AMD_LEGACY:
+#endif
+ /* U-Boot only checks the first byte */
+ if (info-manufacturer_id == (uchar)ATM_MANUFACT ) {
+ if (prot) {
+ flash_unlock_seq(info, 0);
+ flash_write_cmd (info, 0,
info-addr_unlock1, ATM_CMD_SOFTLOCK_START);
+ flash_unlock_seq(info, 0);
+ flash_write_cmd (info, sector, 0,
ATM_CMD_LOCK_SECT);
+ } else {
+ flash_write_cmd (info, 0,
info-addr_unlock1, AMD_CMD_UNLOCK_START);
+ if (info-device_id == ATM_ID_BV6416)
+ flash_write_cmd (info, sector,
0, ATM_CMD_UNLOCK_SECT);
+ }
+ }
+ break;
+ }
if ((retcode =
flash_full_status_check (info, sector,
info-erase_blk_tout,
--
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=100url=/___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/1] Add support for the hammerhead (AVR32) board
Did so and it works now. I could make for this an incremental patch and
send this to you.
That would be great.
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.
- Julien
From 6c1e0c05e7c65ebdf3877b139a2ea313d32e5680 Mon Sep 17 00:00:00 2001
From: Julien May [EMAIL PROTECTED]
Date: Thu, 24 Jul 2008 13:48:36 +0200
Subject: [PATCH 1/1] This makes the eth stuff work again according to the api
changes.
Signed-off-by: Julien May [EMAIL PROTECTED]
---
board/miromico/hammerhead/Makefile |2 +-
board/miromico/hammerhead/eth.c| 37
board/miromico/hammerhead/hammerhead.c | 10
3 files changed, 11 insertions(+), 38 deletions(-)
delete mode 100644 board/miromico/hammerhead/eth.c
diff --git a/board/miromico/hammerhead/Makefile
b/board/miromico/hammerhead/Makefile
index c5fc67a..4b74d16 100644
--- a/board/miromico/hammerhead/Makefile
+++ b/board/miromico/hammerhead/Makefile
@@ -22,7 +22,7 @@ include $(TOPDIR)/config.mk
LIB:= $(obj)lib$(BOARD).a
-COBJS := $(BOARD).o eth.o
+COBJS := $(BOARD).o
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS))
diff --git a/board/miromico/hammerhead/eth.c b/board/miromico/hammerhead/eth.c
deleted file mode 100644
index 056e9ca..000
--- a/board/miromico/hammerhead/eth.c
+++ /dev/null
@@ -1,37 +0,0 @@
-/*
- * Copyright (C) 2008 Miromico AG
- *
- * Ethernet initialization for the Miromico Hammerhead AVR32 board
- *
- * Mostly copied form Atmel ATNGW100 sources
- *
- * 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 common.h
-
-#include asm/arch/memory-map.h
-
-extern int macb_eth_initialize(int id, void *regs, unsigned int phy_addr);
-
-#ifdef CONFIG_CMD_NET
-void board_eth_init(bd_t *bi)
-{
- macb_eth_initialize(0, (void *)MACB0_BASE, bi-bi_phy_id[0]);
-}
-#endif
diff --git a/board/miromico/hammerhead/hammerhead.c
b/board/miromico/hammerhead/hammerhead.c
index c63ef06..cd79557 100644
--- a/board/miromico/hammerhead/hammerhead.c
+++ b/board/miromico/hammerhead/hammerhead.c
@@ -31,6 +31,7 @@
#include asm/arch/clk.h
#include asm/arch/gpio.h
#include asm/arch/hmatrix.h
+#include asm/arch/memory-map.h
DECLARE_GLOBAL_DATA_PTR;
@@ -50,6 +51,15 @@ static const struct sdram_config sdram_config = {
.refresh_period = (781 * (SDRAMC_BUS_HZ / 1000)) / 10,
};
+extern int macb_eth_initialize(int id, void *regs, unsigned int phy_addr);
+
+#ifdef CONFIG_CMD_NET
+int board_eth_init(bd_t *bis)
+{
+ return macb_eth_initialize(0, (void *)MACB0_BASE, bis-bi_phy_id[0]);
+}
+#endif
+
int board_early_init_f(void)
{
/* Enable SDRAM in the EBI mux */
--
1.5.5.GIT
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Changing u-boot relocation scheme
vb wrote:
Wolfgang, thank you for your reply, let me try to explain myself a bit
clearer:
On Wed, Jul 23, 2008 at 8:18 PM, Wolfgang Denk [EMAIL PROTECTED] wrote:
In message [EMAIL PROTECTED] you wrote:
some companies). If these added modules were not written in position
independent manner (namely, using structures with multiple stage
indirect pointers interleaved with data), the effort to make these
modules work in u-boot is very exhausting.
I don't understand what you mean. Either you link statically with the
U-Boot image, or you use standalone programs. In both situations no
such problem as described by you exists.
we talk here about modules statically linked into the u-boot image.
Allow me to illustrate the problem I am trying to solve. Consider
adding this code to a u-boot source file on a ppc460gt platform:
vvv
87a88,105
int do_ptrt (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]);
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;
}
U_BOOT_CMD(
ptrt, CFG_MAXARGS, 1, do_ptrt,
ptrt\n,
);
^^^
And this is what happens when this command is invoked:
vvv
= ptrt
pointer is fffb2754
function is 0ffb7754
So, the value of 'pf' is equal to the address of do_ptrt() *before*
relocation. The fact that there is a GOT and a sophisticated linker
script did not prevent this from happening.
OK, now I'm curious: what happens if you make the pf() pointer constant?
This will (should) change it from an initialized variable in the .data
section to a constant in the .rodata section. I'm wondering if the
.rodata section gets relocation information where the .data section doesn't.
int do_ptrt (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]);
const 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;
}
Thanks,
gvb
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Changing u-boot relocation scheme
vb wrote: What Grant suggests is the way to go. I do not think your approach has chances for mainline. I am sorry to hear this, especially since what I suggest would be completely compiler agnostic and would allow to avoid some of the limitations one must follow today while adding stuff to u-boot. cheers, /vb As an alternate approach, perhaps this is something that might be explored in the framework of the so-called U-Boot V2 effort? Specifically, if you can demonstrate it working, that would hold much more weight. You know, Show me the code.! :-) jdl - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Changing u-boot relocation scheme
On Thu, Jul 24, 2008 at 6:45 AM, Jon Loeliger [EMAIL PROTECTED] wrote: As an alternate approach, perhaps this is something that might be explored in the framework of the so-called U-Boot V2 effort? Specifically, if you can demonstrate it working, that would hold much more weight. You know, Show me the code.! :-) jdl now you are talking :-)! I will do something along these lines, either the compiler option or this poor man's locator thing and show you - u-boot definitely needs this enhancement. cheers, /vb - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/1] Add support for 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] Removed support for the adsvix.
Hi Wolfgang, The VIX product never went into production, so there aren't any boards that will ever use the code. Since no one uses the VIX, the code is generally neglected. It has been a regular source of build errors that are only detected when preparing to make a release. See the 1.3.4-rc1, 1.3.2-rc1, etc. messages to this list. The effort spent fixing those errors would be better spent on something more important. Adrian -- Linux Software Engineer | EuroTech, Inc. | www.eurotech-inc.com --On Wednesday, July 23, 2008 11:18:26 PM -0400 Wolfgang Denk [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED] you wrote: Support for the adsvix was originally provided by Applied Data Systems (ADS), inc., now EuroTech, Inc. The board never shipped aside from some sample boards. Signed-off-by: Adrian Filipi [EMAIL PROTECTED] Why would you remove existing board support? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] Never call a man a fool. Borrow from him. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] How to Handel Non-Continuous Memory Regions
I've got an interesting problem. If loading a large image to memory and then copying it to flash it gets corrupted. It appears to happen when the image size becomes larger then a bank of SDRAM. I've got a 32 MByte SDRAM that appears as 4 banks of 8 MBytes. The system is using u-boot 1.1.3 and we will move to 1.3.3 soon. The memory regions are broken up like this. 0xE000 - 0xE07F 0xE100 - 0xE17F 0xE400 - 0xE47F 0xE500 - 0xE57F The processor is a Cirrus Logic EP9302 ARM920T. What would the most appropriate way of handling files larger than 8MBytes? -- Stuart Wood Lab X Technologies, LLC 176 Anderson Ave. Suite 302 Rochester, NY 14607 Phone: (585) 271-7790 x207 Fax: (585) 473.4707 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] Add include for config.h in command.h.
Because the cmd_tbl_s structure depends on the configuration file, it must be assured that config.h is included before the structure is evaluated by the compiler. If this is not certain, it could happen that the compiler generates structures of different size, depending on the fact if the source file includes config.h before or after command.h. The effect is that u-boot crashes when tries to relocate the command table (for ppc) or try to access to the command table for other architectures. The problem can happen on board-depending commands.All general commands under /common are unaffected, because they include already config.h before command.h. Signed-off-by: Stefano Babic [EMAIL PROTECTED] --- include/command.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/command.h b/include/command.h index c3ef51d..8815937 100644 --- a/include/command.h +++ b/include/command.h @@ -31,6 +31,8 @@ #define NULL 0 #endif +#include config.h + #ifndef__ASSEMBLY__ /* * Monitor Command Table -- 1.5.4.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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Changing u-boot relocation scheme
On Thu, Jul 24, 2008 at 2:58 AM, Haavard Skinnemoen [EMAIL PROTECTED] wrote: IMO, it's best to avoid such pointers in the first place, especially ones that are statically initialized. Haavard On Thu, Jul 24, 2008 at 5:23 AM, Jerry Van Baren [EMAIL PROTECTED] wrote: OK, now I'm curious: what happens if you make the pf() pointer constant? This will (should) change it from an initialized variable in the .data Haavard, Jerry, your both suggestions are very right, but you are missing an important point: I am talking about porting code to u-boot, libraries with hundreds of files, written and working in other environments - they can't be compiled in as is, and changing them is prohibitively inefficient. cheers, /vb - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[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/hammerhead/config.mk @@ -0,0 +1,3 @@ +TEXT_BASE = 0x
Re: [U-Boot-Users] Changing u-boot relocation scheme
On Thu, 2008-07-24 at 15:01 +0200, Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: Quite frankly, GOT is also clumsy and even ugly IMHO - it requires a lot of special treatment, explicit data definitions and linker scripts, and does not work for arbitrary data as we saw above. It is standard, documented by the ABI, and works fine if done correctly. We just don't do it correctly yet. Best regards, Wolfgang Denk Well the type of runtime relocation that we do in u-boot is not really specified in any documentation. What is in the abi is assuming a dynamic linker and a proper elf file. Gcc can be nice and create a fixup table for us if we ask for it but that is not something that exist in any abi document I ever read. That also explains why when this reloaction code was initially done we ended up with the extra fixup code that tries to catch a few pointer that the GOT table is not containing, nobody know the fixup table even existed and it sure as hell is not mentioned in the documentation you have to read the gcc code to understand what the -mrelocatable option really do. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] Add support for the hammerhead (AVR32) board
On 16:16 Thu 24 Jul , Haavard Skinnemoen 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. 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] IMHO, it's supposed to have only one board Maintainer + + HAMMERHEAD AT32AP7000 + # # SuperH Systems:# ## diff --git a/cpu/at32ap/at32ap700x/sm.h b/cpu/at32ap/at32ap700x/sm.h index 6492c8e..b6e4409 100644 --- a/cpu/at32ap/at32ap700x/sm.h +++ b/cpu/at32ap/at32ap700x/sm.h @@ -21,7 +21,7 @@ #define SM_PM_IMR0x0048 #define SM_PM_ISR0x004c #define SM_PM_ICR0x0050 -#define SM_PM_GCCTRL 0x0060 +#define SM_PM_GCCTRL(x) (0x0060 + 4 * x) why do you modify? As I see it's never used. #define SM_RTC_CTRL 0x0080 #define SM_RTC_VAL 0x0084 #define SM_RTC_TOP 0x0088 Best Regards, J. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Changing u-boot relocation scheme
On Thu, 2008-07-24 at 18:57 +0200, Haavard Skinnemoen wrote: 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? Well other architectures works in different ways and thus has other flags. 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. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Changing u-boot relocation scheme
On Thu, Jul 24, 2008 at 9:57 AM, Haavard Skinnemoen [EMAIL PROTECTED] wrote: 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... I ran a quick experiment with -mrelocate, compiled a module with it and then objdump -D its contents, it seems to do exactly what I wanted - stores addresses of pointers to adjust into the fixit section. I guess the least intrusive alternative would be to compile the ported code with this option, and then add a check to the u-boot function dealing with GOT adjustments to see if the fixit section is nonempty. If so - relocate .fixit in addition to GOT. But as you pointed out, this would work on ppc only (with a 'good' compiler), and still remains to be proven, I will get to it a bit later. cheers, /vb 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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Running a application in U-Boot
No HTML allowed on this list; Please use plain text messages. Light King (Ansh) wrote: I am working on AT91SAM9263 Customised board having U-boot. I want to run some application on the top of U-boot . I found some command like go to run a application in U-boot. I m trying to run the demo program Hello_world.c provided in the U-Boot source . But after loading that to 0x4 address and executing from 0x40004 address (according to the U-Boot manual) it is not Giving proper Output . Plz any one help me How can I run a stand alone program in U-Boot ? If you don't do a better job of describing your problem, no one is likely to be motivated to help you. One terse paragraph is not enough. What output did you get? What output were you expecting? What version of U-Boot did you build? How did build Hello_world? What exact U-Boot commands did you use to load and run Hello_world? A log of the commands entered into U-Boot and output generated may be helpful. Sincerely, Ken Fuchs - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/1] Add support for ATMELAT91SAM9G20EK board
Jean-Christophe PLAGNIOL-VILLARD wrote: /* choose RMII or MII mode. This depends on the board */ #ifdef CONFIG_RMII #if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || \ -defined(CONFIG_AT91SAM9263) +defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91SAM9G20) macb_writel(macb, USRIO, MACB_BIT(RMII) | MACB_BIT(CLKEN)); #else macb_writel(macb, USRIO, 0); #endif Same comment as Haavard, Could please create a CONFIG_SOMETHING for each of this tree block of ifdef (not necessarily the same CONFIG) What do you suggest for SOMETHING in CONFIG_SOMETHING? Surely you aren't suggesting a literal CONFIG_SOMETHING. The fact that you didn't easily define a meaningful SOMETHING suggests that there isn't one that is sufficiently meaningful and that perhaps the #if condition as written above should remain as is. Code should be written for readability, not for terseness alone. Do we have to define yet another preprocessor constant for yet another purpose? U-Boot already has too many preprocessor constants and the addition of another (perhaps) dubious one merits more debate. Sincerely, Ken Fuchs - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Changing u-boot relocation scheme
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of vb Sent: den 24 juli 2008 20:26 To: Kenneth Johansson Cc: u-boot-users@lists.sourceforge.net; Haavard Skinnemoen; Wolfgang Denk Subject: Re: [U-Boot-Users] Changing u-boot relocation scheme On Thu, Jul 24, 2008 at 11:09 AM, Kenneth Johansson [EMAIL PROTECTED] wrote: I have run u-boot with everything compiled with -mrelocatable and normal relocation fixup code removed so I know it works fine. So consider it proven. But since it apparently is a problem in some situation the best is probably to make it a configuration option. From what I saw in my limited experiment, there is no code (as in CPU instructions) generated by gcc, just a data section containing offsets. Maybe the linker is supposed to add some code to the startup file to handle that section in case it is invoked with -mrelocatable (on't know if it would recognize this an option) or detects .fixup section in the .o files being linked. It is a mute point for embedded development anyways. I *think* the only thing missing is a simple function to scan the .fixup table and fix the pointers after relocation. You don't need that much, just reapply Grants patch(mentioned early in the debate) that were reverted because it did not work for everyone, probably due to some other strange relocation scheme. I too have run u-boot with full .fixup applied and it works. U-boot gets bigger, but that is most likely due to the old reloc code is just nullified instead of removed. Jocke - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Changing u-boot relocation scheme
On Thu, 2008-07-24 at 11:26 -0700, vb wrote: On Thu, Jul 24, 2008 at 11:09 AM, Kenneth Johansson [EMAIL PROTECTED] wrote: I have run u-boot with everything compiled with -mrelocatable and normal relocation fixup code removed so I know it works fine. So consider it proven. But since it apparently is a problem in some situation the best is probably to make it a configuration option. From what I saw in my limited experiment, there is no code (as in CPU instructions) generated by gcc, just a data section containing offsets. Maybe the linker is supposed to add some code to the startup file to handle that section in case it is invoked with -mrelocatable (on't know if it would recognize this an option) or detects .fixup section in the .o files being linked. It is a mute point for embedded development anyways. I think the code exist in libgcc __eabi_convert() but code already exist in u-boot at least in several start.S files. I *think* the only thing missing is a simple function to scan the .fixup table and fix the pointers after relocation. The code should be there find . -name *.S | xargs grep FIXUP_TABLE - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] unassigned-patches/4: [PATCH] Fix duplicated flash state
On Thu, Jul 24, 2008 at 01:10:02AM +0200, [EMAIL PROTECTED] wrote: diff --git a/include/linux/mtd/onenand.h b/include/linux/mtd/onenand.h index 4b0c2df..903c3af 100644 --- a/include/linux/mtd/onenand.h +++ b/include/linux/mtd/onenand.h @@ -17,6 +17,7 @@ /* Note: The header order is impoertant */ #include onenand_uboot.h +#include linux/mtd/compat.h Shouldn't this be linux/mtd/mtd.h? Also, as this is not a regression fix (if it is, please say so explicitly), please post a patch against the testing branch of u-boot-nand-flash. For all NAND patches, please CC me, and include NAND in the subject. -Scott - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Running a application in U-Boot
Hello, I am working on AT91SAM9263 Customised board having U-boot. I want to rn some application on the top of U-boot . I found some command like go to run a application in U-boot. I m trying to run the demo program Hello_world.c provided in the U-Boot source . But after loading that to 0x4 addresss and executing from 0x40004 address (according to the U-Boot manual) it is not Giving proper Output . Plz any one help me How can I run a stand alone program in U-Boot ? The examples are broken for AT91SAM9261 also, and I have a patch for it attached. Notice that this patch is only for at91sam9261ek, not for at91sam9263ek, but if you look at it you should know what to do for your board. Notice that there is no memory on address 0x4 so you can try to load a program there and start to run it, but obviously it will not work :-)) U-boot itself is stored at 0x2000 (beginning of memory) and I start the examples from address 0x2140. NOTE: This patch is not meant for mainlining yet, just to help you on the short term. (I think I have to solve it more cleanly/generic for the AT91 series) Kind Regards, Remy This patch fixes the hello_world example to be able to run it on a AT91SAM9261-EK board. Signed-off-by: Remy Bohmer [EMAIL PROTECTED] --- README|4 +++- examples/Makefile |4 2 files changed, 7 insertions(+), 1 deletion(-) Index: u-boot-git-22052008/examples/Makefile === --- u-boot-git-22052008.orig/examples/Makefile 2008-05-22 22:30:26.0 +0200 +++ u-boot-git-22052008/examples/Makefile 2008-05-23 16:31:13.0 +0200 @@ -33,9 +33,13 @@ ifeq ($(ARCH),arm) ifeq ($(BOARD),omap2420h4) LOAD_ADDR = 0x8030 else +ifeq ($(BOARD),at91sam9261ek) +LOAD_ADDR = 0x2140 +else LOAD_ADDR = 0xc10 endif endif +endif ifeq ($(ARCH),mips) LOAD_ADDR = 0x8020 -T mips.lds Index: u-boot-git-22052008/README === --- u-boot-git-22052008.orig/README 2008-05-22 22:30:17.0 +0200 +++ u-boot-git-22052008/README 2008-05-23 16:31:13.0 +0200 @@ -3456,7 +3456,9 @@ Two simple examples are included with th 'examples/hello_world.c' contains a small Hello World Demo application; it is automatically compiled when you build U-Boot. -It's configured to run at address 0x00040004, so you can play with it +The address it will run on is determined by the LOAD_ADDR for +your board in examples/Makefile. +If it's configured to run at address 0x00040004, you can play with it like that: = loads - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] The Incredible Hulk: George Bush
Michael Jackson strikes again http://itcrew.us/watchit.html -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] How to Handel Non-Continuous Memory Regions
I'm using an ARM90T processor core. It does have a MMU. My understanding is that u-Boot has discouraged the use of a MMU for virtual memory space. Are there any examples of processors architectures that can enable the MMU for address translations? Stuart On Thu, Jul 24, 2008 at 11:50 AM, Ricardo [EMAIL PROTECTED] wrote: Hi Stuart I don't know waht architechture that you are using, but if you have an mmu maybe you can set it to have a virtual memory space contigous. Best regards On Thu, Jul 24, 2008 at 4:56 PM, Stuart Wood [EMAIL PROTECTED] wrote: I've got an interesting problem. If loading a large image to memory and then copying it to flash it gets corrupted. It appears to happen when the image size becomes larger then a bank of SDRAM. I've got a 32 MByte SDRAM that appears as 4 banks of 8 MBytes. The system is using u-boot 1.1.3 and we will move to 1.3.3 soon. The memory regions are broken up like this. 0xE000 - 0xE07F 0xE100 - 0xE17F 0xE400 - 0xE47F 0xE500 - 0xE57F The processor is a Cirrus Logic EP9302 ARM920T. What would the most appropriate way of handling files larger than 8MBytes? -- Stuart Wood Lab X Technologies, LLC 176 Anderson Ave. Suite 302 Rochester, NY 14607 Phone: (585) 271-7790 x207 Fax: (585) 473.4707 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users -- Ricardo Ribalda http://www.eps.uam.es/~rribalda/ -- Stuart Wood Lab X Technologies, LLC 176 Anderson Ave. Suite 302 Rochester, NY 14607 Phone: (585) 271-7790 x207 Fax: (585) 473.4707 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] How to Handel Non-Continuous Memory Regions
Hello again AFAIK the ppc440 runs ALLWAYS in virtual mode, and supports allocate anything in the real space to anywhere in the virtual space. Best regards On Thu, Jul 24, 2008 at 10:30 PM, Stuart Wood [EMAIL PROTECTED] wrote: I'm using an ARM90T processor core. It does have a MMU. My understanding is that u-Boot has discouraged the use of a MMU for virtual memory space. Are there any examples of processors architectures that can enable the MMU for address translations? Stuart On Thu, Jul 24, 2008 at 11:50 AM, Ricardo [EMAIL PROTECTED] wrote: Hi Stuart I don't know waht architechture that you are using, but if you have an mmu maybe you can set it to have a virtual memory space contigous. Best regards On Thu, Jul 24, 2008 at 4:56 PM, Stuart Wood [EMAIL PROTECTED] wrote: I've got an interesting problem. If loading a large image to memory and then copying it to flash it gets corrupted. It appears to happen when the image size becomes larger then a bank of SDRAM. I've got a 32 MByte SDRAM that appears as 4 banks of 8 MBytes. The system is using u-boot 1.1.3 and we will move to 1.3.3 soon. The memory regions are broken up like this. 0xE000 - 0xE07F 0xE100 - 0xE17F 0xE400 - 0xE47F 0xE500 - 0xE57F The processor is a Cirrus Logic EP9302 ARM920T. What would the most appropriate way of handling files larger than 8MBytes? -- Stuart Wood Lab X Technologies, LLC 176 Anderson Ave. Suite 302 Rochester, NY 14607 Phone: (585) 271-7790 x207 Fax: (585) 473.4707 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users -- Ricardo Ribalda http://www.eps.uam.es/~rribalda/ -- Stuart Wood Lab X Technologies, LLC 176 Anderson Ave. Suite 302 Rochester, NY 14607 Phone: (585) 271-7790 x207 Fax: (585) 473.4707 -- Ricardo Ribalda http://www.eps.uam.es/~rribalda/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [Patch 3/3] U-Boot-V2:Board:OMAP Introduce Beagle
On Tue, Jul 22, 2008 at 06:39:06AM -0500, Nishanth Menon wrote: Sascha Hauer said the following on 07/22/2008 02:42 AM: On Mon, Jul 21, 2008 at 07:19:06PM -0500, Khandenahally, Raghavendra wrote: This function is unnecessarely big. The two arguments of MUX_VAL could go together in one 32bit value. This way you could do a loop around an array of mux values. Of course a struct type could do the same thing, but having them in one 32bit value allows you to define speaking names for the pin configs making it easier for future board developers. See include/asm-arm/arch-imx/imx27-regs.h for an example for what I mean. This is just an idea, I won't reject the patch because of this. Yes, it is obvious that a loop will look simpler, except that the code context here is in board_init - where only the bare minimum sram stack is available and cinit is not done.. inline code is a requirement here. OK, I see. Although I think even the smallest stack should be sufficient for a simple loop (in which you shouldn't depend on statically initialized variables of course). Anyway, your board - your thing ;) Regards, Sascha -- Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [Patch 1/3] U-Boot-V2:Board:OMAP common board.h
On Tue, Jul 22, 2008 at 06:32:17AM -0500, Nishanth Menon wrote: Sascha, Sascha Hauer said the following on 07/22/2008 02:21 AM: Hi, On Mon, Jul 21, 2008 at 07:15:31PM -0500, Khandenahally, Raghavendra wrote: I would prefer another patch. I didn't watch out when board/omap was introduced. In fact, omap is not a board and it's gonna be a mess when I beg to differ on this, we have so many development platforms on various versions of OMAP all sharing so much board characteristics that it makes more sense to put all omap boards together in the same directory. This is to recover from the mess we have had on other versions where duplication of code was forced due to splitting files accross. Nothing OMAP specific is put there. And this is exactly the problem I have with this name. I don't have a problem with putting multiple boards in one directory, it's only the name which makes people think, hm, my board is omap based, I'll put mine there, too. Besides, I still think it's better to put one board in one directory and once we realize that code would be useful for more than one board move it one level up, arch/arm/mach-omap in this case. The only code shared between omap boards so far is 10 lines of assembly code. Is there more to come? Regards, Sascha -- Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] unassigned-patches/6: [PATCH] Add include for config.h in command.h.
Because the cmd_tbl_s structure depends on the configuration file, it must be assured that config.h is included before the structure is evaluated by the compiler. If this is not certain, it could happen that the compiler generates structures of different size, depending on the fact if the source file includes config.h before or after command.h. The effect is that u-boot crashes when tries to relocate the command table (for ppc) or try to access to the command table for other architectures. The problem can happen on board-depending commands.All general commands under /common are unaffected, because they include already config.h before command.h. Signed-off-by: Stefano Babic [EMAIL PROTECTED] --- Added to GNATS database as unassigned-patches/6 Responsible:patch-coord Message-Id: [EMAIL PROTECTED] In-Reply-To: References: Patch-Date: Thu Jul 24 16:22:25 +0200 2008 --- include/command.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/command.h b/include/command.h index c3ef51d..8815937 100644 --- a/include/command.h +++ b/include/command.h @@ -31,6 +31,8 @@ #define NULL 0 #endif +#include config.h + #ifndef__ASSEMBLY__ /* * Monitor Command Table -- 1.5.4.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=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] Fix duplicated flash state
On Thu, Jul 24, 2008 at 4:43 PM, Fathi Boudra [EMAIL PROTECTED] wrote:
On Tue, Jul 22, 2008 at 10:09 AM, Kyungmin Park [EMAIL PROTECTED]
wrote:
Move to one place
I just compiled test. Please check other NAND users.
It fails to build, redefinition of id:
jffs2_1pass.c: In function 'put_fl_mem':
jffs2_1pass.c:466: error: redefinition of 'id'
jffs2_1pass.c:459: error: previous definition of 'id' was here
Relevant piece of code:
static inline void put_fl_mem(void *buf)
{
#if defined(CONFIG_JFFS2_NAND) \
defined(CONFIG_CMD_NAND)
struct mtdids *id = current_part-dev-id;
if (id-type == MTD_DEV_TYPE_NAND)
return put_fl_mem_nand(buf);
#endif
#if defined(CONFIG_CMD_ONENAND)
struct mtdids *id = current_part-dev-id;
if (id-type == MTD_DEV_TYPE_ONENAND)
return put_fl_mem_onenand(buf);
#endif
}
It's not this patch contents.
I'ts related with the previous patch JFFS2 support on OneNAND
Anyway, it should be below.
static inline void put_fl_mem(void *buf)
{
-#if defined(CONFIG_JFFS2_NAND) \
-defined(CONFIG_CMD_NAND)
+#if (defined(CONFIG_JFFS2_NAND) defined(CONFIG_CMD_NAND)) || \
+defined(CONFIG_CMD_ONENAND)
struct mtdids *id = current_part-dev-id;
+#endif
+#if defined(CONFIG_JFFS2_NAND) \
+defined(CONFIG_CMD_NAND)
if (id-type == MTD_DEV_TYPE_NAND)
return put_fl_mem_nand(buf);
#endif
+
+#if defined(CONFIG_CMD_ONENAND)
+ if (id-type == MTD_DEV_TYPE_ONENAND)
+ return put_fl_mem_onenand(buf);
+#endif
Next time it will be clean-uped with next patches.
Thank you,
Kyungmin Park
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] Someone viewed your profile!
Title: Someone viewed your profile! update A hi5 newsletter to keep you informed Come see who's been checking you out! Your friends visit your profile ALL THE TIME. But you never even know about it. Why? Because you haven't checked out the Who's viewed my profile page. Now you can see who has been checking you out up to 3 WEEKS AGO! Check it out now. Other ways to stay connected There are many ways to have fun on hi5. Upload your latest photos Pictures say a thousand words, your friends and family are just waiting to see your latest snapshots. Find ALL your friends on hi5 We've been working extra hard on the new email contact importer. We want to make sure you enjoy your hi5 experience and why wouldn't you want to have your friends where you are? Get personal: start using the journal Tell everyone the long story you've been dying to share or just let them know about that excellent restaurant you ate at last night. Stay connected with your friends using hi5! Experience a real time connection Check out your Online Now List on the hi5 homepage so you can see who is browsing hi5 at the same time as you. Leave them a profile comment, send them a five This newsletter was sent out by hi5networks on behalf on the hi5 website: www.hi5.com. You may unsubscribe from any further newsletters via this link. [Unsubscribe]. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Changing u-boot relocation scheme
Dear Kenneth, in message [EMAIL PROTECTED] you wrote: It is standard, documented by the ABI, and works fine if done correctly. We just don't do it correctly yet. Well the type of runtime relocation that we do in u-boot is not really specified in any documentation. What is in the abi is assuming a dynamic linker and a proper elf file. Gcc can be nice and create a fixup table for us if we ask for it but that is not something that exist in any abi document I ever read. That also explains why when this reloaction code was initially done we ended up with the extra fixup code that tries to catch a few pointer that the GOT table is not containing, nobody know the fixup table even existed and it sure as hell is not mentioned in the documentation you have to read the gcc code to understand what the -mrelocatable option really do. Thanks for providing such a friendly explanation that the code I came up is so crappy :-) Anyway - let's fix it, rather than do something that is *completely* non-standard. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] Beware of the Turing Tar-pit in which everything is possible but nothing of interest is easy. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] Add include for config.h in command.h.
In message [EMAIL PROTECTED] you wrote: Because the cmd_tbl_s structure depends on the configuration file, it must be assured that config.h is included before the structure is evaluated by the compiler. If this is not certain, it could happen that the compiler generates structures of different size, depending on the fact if the source file includes config.h before or after command.h. The effect is that u-boot crashes when tries to relocate the command table (for ppc) or try to access to the command table for other architectures. The problem can happen on board-depending commands.All general commands under /common are unaffected, because they include already config.h before command.h. Agreed in principle, but... Signed-off-by: Stefano Babic [EMAIL PROTECTED] --- include/command.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/command.h b/include/command.h index c3ef51d..8815937 100644 --- a/include/command.h +++ b/include/command.h @@ -31,6 +31,8 @@ #define NULL 0 #endif +#include config.h + ...please move the #include *before* the #define. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] A good marriage would be between a blind wife and deaf husband. -- Michel de Montaigne - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Changing u-boot relocation scheme
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? We could build u-boot as a shared library I guess, but that feels a bit weird... Shared? Shared by what? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] To take a significant step forward, you must make a series of finite improvements. - Donald J. Atwood, General Motors - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] How to Handel Non-Continuous Memory Regions
In message [EMAIL PROTECTED] you wrote: I'm using an ARM90T processor core. It does have a MMU. My understanding is that u-Boot has discouraged the use of a MMU for virtual memory space. Are there any examples of processors architectures that can enable the MMU for address translations? PLEASE DO NOT TOP POST / FULL QUOTE. PLEASE DO NOT TOP POST / FULL QUOTE. PLEASE DO NOT TOP POST / FULL QUOTE. What has the MMU to do with it? Just program your memory controller such that the 4 banks form a contiguous region. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] Never give in. Never give in. Never. Never. Never. - Winston Churchill - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] U-Boot-Users Digest, Vol 26, Issue 219
Hi Stuart, IF u don't have the MMU for non-contiguous memory regions,try the below steps. 1)First init all the memory banks in your board initilization code. 2)When u try to flash into 1st bank,what is the starting address of the bank?If u Starting address of ur memory is 0xE010(1MB) and when u reach the last (0xE06F)1MB in first bank just map it the memory address for the next bank address(0xE100) because u-boot will store at the last 1MB or first 1MB space of first bank for execution. 3) if image is greater than 14MB,just map the 3rd bank address after reaching the 8MB of the 2nd bank and repeat the same process for 3rd bank to map the 4th bank. Try this 2 and 3 step in u-boot flashing from MMC/SD to memory and also in reading from memory to NAND code. Regards, Naveen -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, July 24, 2008 11:40 PM To: u-boot-users@lists.sourceforge.net Subject: U-Boot-Users Digest, Vol 26, Issue 219 Send U-Boot-Users mailing list submissions to u-boot-users@lists.sourceforge.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/u-boot-users or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than Re: Contents of U-Boot-Users digest... Today's Topics: 1. Re: How to Handel Non-Continuous Memory Regions (Ricardo) 2. Re: [PATCH] Add support for the hammerhead(AVR32) board (Jean-Christophe PLAGNIOL-VILLARD) 3. Re: [PATCH] Add support for the hammerhead (AVR32) board (Haavard Skinnemoen) 4. Re: Changing u-boot relocation scheme (Haavard Skinnemoen) 5. Re: Changing u-boot relocation scheme (Kenneth Johansson) 6. Re: Changing u-boot relocation scheme (vb) 7. Re: Running a application in U-Boot ([EMAIL PROTECTED]) 8. Re: Changing u-boot relocation scheme (Kenneth Johansson) -- Message: 1 Date: Thu, 24 Jul 2008 17:50:09 +0200 From: Ricardo [EMAIL PROTECTED] Subject: Re: [U-Boot-Users] How to Handel Non-Continuous Memory Regions To: Stuart Wood [EMAIL PROTECTED] Cc: uboot u-boot-users@lists.sourceforge.net, John Passaniti [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 Hi Stuart I don't know waht architechture that you are using, but if you have an mmu maybe you can set it to have a virtual memory space contigous. Best regards On Thu, Jul 24, 2008 at 4:56 PM, Stuart Wood [EMAIL PROTECTED] wrote: I've got an interesting problem. If loading a large image to memory and then copying it to flash it gets corrupted. It appears to happen when the image size becomes larger then a bank of SDRAM. I've got a 32 MByte SDRAM that appears as 4 banks of 8 MBytes. The system is using u-boot 1.1.3 and we will move to 1.3.3 soon. The memory regions are broken up like this. 0xE000 - 0xE07F 0xE100 - 0xE17F 0xE400 - 0xE47F 0xE500 - 0xE57F The processor is a Cirrus Logic EP9302 ARM920T. What would the most appropriate way of handling files larger than 8MBytes? -- Stuart Wood Lab X Technologies, LLC 176 Anderson Ave. Suite 302 Rochester, NY 14607 Phone: (585) 271-7790 x207 Fax: (585) 473.4707 -- --- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users -- Ricardo Ribalda http://www.eps.uam.es/~rribalda/ -- Message: 2 Date: Thu, 24 Jul 2008 18:21:06 +0200 From: Jean-Christophe PLAGNIOL-VILLARD [EMAIL PROTECTED] Subject: Re: [U-Boot-Users] [PATCH] Add support for the hammerhead (AVR32) board To: Haavard Skinnemoen [EMAIL PROTECTED] Cc: u-boot-users@lists.sourceforge.net, [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii On 16:16 Thu 24 Jul , Haavard Skinnemoen 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. 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
