Re: [U-Boot-Users] using a flat device tree to drive u-boot config
On Sun, Aug 3, 2008 at 11:49 AM, Timur Tabi [EMAIL PROTECTED] wrote: On Sun, Aug 3, 2008 at 10:47 AM, Wolfgang Denk [EMAIL PROTECTED] wrote: If the DTB can be at any flash location, you can for example have a fall-back version which is used to bring up U-Boot in a minimal configuration for recovery mode if the new DTB fails to work. I think that a recovery DTB would have to be part of U-Boot itself to be effective. If the normal DTB is not available, then it's likely the backup one would also be unavailable. Better to just not depend on the DTB at all for basic operation. ie. don't brick the board if the DTB is unavailable. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFC: mailing list transfer
On Fri, Aug 1, 2008 at 9:17 AM, Wolfgang Denk [EMAIL PROTECTED] wrote: Hello, I would like to get your general opinion about moving the u-boot-users mailing list away from SourceForge and host it on lists.denx.de instead. There is a couple of reasons for this: SourceForge has freuently been slow; there have been reports from many users who got unsubscribed repeatedly for no clear reason; the mailing list archive at SF is painful to use; and, most of all, we have only limited ways to change the configuration, and with any other request we depend on the mercy of SF support, which is, ummm, slw. Another reason is that this would make it easier for us to cross-link between messages on the mailing list and entries in the upcoming bug and patch tracking system. If we have a majority agreeing with this change, I suggest to proceed as follows: * The new mailing list will be created as [EMAIL PROTECTED] * The mailing list archive will be transferred from SF to DENX * The archive services (gmane etc.) will be notified about the change * All currently subscribed users and their settings will be transferred from SF to DENX * After a cut-off date, all users are requested to use the new ML only [that will be the complicated part]. * The ML at SF will be set to read-only to make clear it is no longer * in use. Do you think this is a reasonable plan? Any hints, ideas, tips? Yes... but I'll take this opportunity to suggest that kernel.org hosting might provide better support with far less effort... then again, I don't need to maintain it, so I really shouldn't care. :-) g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. - 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] I2C EEPROM simulator (Resubmit) (Lindent)
On Mon, Jul 28, 2008 at 12:06:21PM +0200, Ricardo Ribalda Delgado wrote:
This driver provides access to a simulated i2c eeprom.
This simulated eeprom could be very useful in boards with
ddr2 memories and no i2c interfaces.
Using this driver the user can simulate a spd eeprom
of a ddr2 memory and use the ddr2 auto config.
User can use the macros CONFIG_EEPROM_SIMUL_LEN
and CONFIG_EEPROM_SIMUL_DATA to define the content
of the simulated eeprom
I know I'm coming in quite late to this discussion, but I really don't
like this approach. I don't like that non-human readable, pre-encoded
data is getting linked into the u-boot build so that the ddr2 driver can
be used for static DDR configuration without change the ddr2 driver.
I'd much rather see the ddr2 driver refactored to separate the i2c
reading and decoding from the configuration of the DDR controller (which
may already be the case, I don't know). Then I'd like to see the DDR
controller export an API to allow it to be configured from code or from
a static structure. I think that would be a far cleaner way to
accomplish what you are trying to do.
g.
Signed-off-by: Ricardo Ribalda Delgado [EMAIL PROTECTED]
---
-Lident run over the source to solve coding style issues remarked by Michal
Simek
drivers/i2c/Makefile |1 +
drivers/i2c/eeprom_simul.c | 69
2 files changed, 70 insertions(+), 0 deletions(-)
create mode 100644 drivers/i2c/eeprom_simul.c
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index 534c015..2aeabe5 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -30,6 +30,7 @@ COBJS-y += omap1510_i2c.o
COBJS-y += omap24xx_i2c.o
COBJS-y += tsi108_i2c.o
COBJS-y += mxc_i2c.o
+COBJS-$(CONFIG_EEPROM_SIMUL) += eeprom_simul.o
COBJS:= $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/drivers/i2c/eeprom_simul.c b/drivers/i2c/eeprom_simul.c
new file mode 100644
index 000..51794fa
--- /dev/null
+++ b/drivers/i2c/eeprom_simul.c
@@ -0,0 +1,69 @@
+/*
+(C) Copyright 2008
+Ricado Ribalda-Universidad Autonoma de [EMAIL PROTECTED]
+This work has been supported by: QTechnology http://qtec.com/
+
+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, see http://www.gnu.org/licenses/.
+*/
+
+#include common.h
+#include i2c.h
+
+#ifndef CONFIG_EEPROM_SIMUL_LEN
+#define CONFIG_EEPROM_SIMUL_LEN 256
+#endif
+
+u8 eeprom_simul_buffer[CONFIG_EEPROM_SIMUL_LEN]
+#ifdef CONFIG_EEPROM_SIMUL_DATA
+= CONFIG_EEPROM_SIMUL_DATA
+#endif
+;
+
+void i2c_init(int speed, int slaveaddr)
+{
+ return;
+}
+
+int i2c_read(uchar chip, uint addr, int alen, uchar * buffer, int len)
+{
+ int i;
+
+ if (addr + len CONFIG_EEPROM_SIMUL_LEN)
+ return -1;
+
+ for (i = 0; i len; i++) {
+ buffer[i] = eeprom_simul_buffer[i + addr];
+ }
+
+ return 0;
+}
+
+int i2c_write(uchar chip, uint addr, int alen, uchar * buffer, int len)
+{
+ int i;
+
+ if (addr + len CONFIG_EEPROM_SIMUL_LEN)
+ return -1;
+
+ for (i = 0; i len; i++) {
+ eeprom_simul_buffer[i + addr] = buffer[i];
+ }
+
+ return 0;
+}
+
+int i2c_probe(uchar chip)
+{
+ return 0;
+}
--
1.5.6.3
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=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] using a flat device tree to drive u-boot config
On Mon, Jul 28, 2008 at 10:07:49AM -0500, Kumar Gala wrote: One topic that come up during OLS in discussions and u-boot BOF was the idea of driving u-boot configuration from a device tree instead of from config.h. I was wondering if anyone has actually looked at doing this. One question I have is how does (or should) u-boot identify where to find the device tree. I think the idea would be that this area could be easily reflashed with a new blob to get a new configuration. In principle I like the idea of having configuration retrieved from the device tree blob, but the idea of reflashing the blob in the context of u-boot scares me. In particular, if u-boot depends too much on the presence of the blob, then it becomes a method of bricking a board if users are able/expected to reflash the blob. g. - 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] I2C EEPROM simulator (Resubmit)(Lindent)
On Mon, Jul 28, 2008 at 12:16 PM, Ricardo Ribalda Delgado [EMAIL PROTECTED] wrote: Hello Grant Thanks for your comment. The use for the ddr2 is just an example... I did developed it for that reason, but you can use it for anything else. I sent the patch just because I thought it will be useful for other people and the mail list response in that way. It was my first patch to the u-boot and I had problems to fit the rules. It is also my first time with git Okay, that is fine. Until there is a user of this, I recommend not merging it into mainline. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. - 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 Fri, Jul 25, 2008 at 2:50 PM, Haavard Skinnemoen [EMAIL PROTECTED] wrote: Ok, I'll stop the chest-beating now. But please stop trying to tell people that adding a powerpc-specific option (which nobody seems to know how really works) to the command line will work on any other architectures than powerpc. You are completely right. For the purposes of this discussion, this is a powerpc-centric problem. The relocation code is written in assembly and is processor specific. Let the ARM folks make sure ARM relocation works (and I think it already does). Let the MIPS folks do the same. Each arch has it's own set of CFLAGS and LDFLAGS needed to produce a sane binary. They should be picked off and fixed one arch at a time. BTW, searching for assignments to reloc_off in the source will tell you which platforms are broken. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. - 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 Sat, Jul 26, 2008 at 3:53 AM, kenneth johansson [EMAIL PROTECTED] wrote: On Sat, 2008-07-26 at 01:48 -0400, Grant Likely wrote: On Thu, Jul 24, 2008 at 2:09 PM, Kenneth Johansson [EMAIL PROTECTED] wrote: On Thu, 2008-07-24 at 10:37 -0700, vb wrote: 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. 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. Can you test against various versions of gcc? That is where I ran into trouble. Well If you have a specific version you know is not working I could test that. gcc 4.0 worked for me. Anything newer or older seemed to behave differently. Looking at the size of the .got and .fixup sections seems to be a good indication of if things are being placed correctly. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. - 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:45 AM, vb [EMAIL PROTECTED] 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: If you invest time in solving such problems, than your time willbe much better iinvested if you try to help solving the remaining issues with Grant's code. 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. The problem is that the u-boot C runtime setup is insane and must be fixed. Fix the C runtime and the problem goes away. The approach being suggested here would have us *preserve* the insane C runtime and actually depend on the runtime to remain insane in order to work. Not a good approach. The C runtime problem is solvable, but I didn't have the time or resources to properly dig into it and I got frustrated before it was fully debugged. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. - 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:09 PM, Kenneth Johansson [EMAIL PROTECTED] wrote: On Thu, 2008-07-24 at 10:37 -0700, vb wrote: 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. 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. Can you test against various versions of gcc? That is where I ran into trouble. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. - 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 Fri, Jul 25, 2008 at 1:28 PM, kenneth johansson [EMAIL PROTECTED] wrote: I was afraid that what was needed was more or less a complete linker but it looks like if one generate the dynamic reloc table a much simpler linker(relocation function) is needed. Still probably a lot more complex than the GOT and fixup code that is just a loop over a table. We may need a case also ;-) The GOT relocation works. It works really well. As long as gcc and ld put the correct GOT bits into the GOT table. It seems not all versions of gcc do it in the same way with the same flags. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. - 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
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. g. - 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] JTAG tool recommendations
On Fri, Jul 18, 2008 at 01:06:40PM -0700, Dan Batryn wrote: We are developing a set of UBOOT / Linux products based on the AMCC 440EP and 405EX PowerPC processors. They have their basis on the AMCC Yosemite and Kilauea development platforms. Are there any user's recommendations of pluses and minuses of the various JTAG development tools? The 440EP will be booting from NOR flash, so it's development is pretty straightforward. The goal in the 405EX design is to boot from NAND flash. This will be more of a challenge. Do any of the JTAG development tools offer JTAG NAND flash programming that can recognize and skip the bad blocks of NAND flash? How are other users programming the soldered down NAND flash for the initial UBOOT development and loading the NAND flash in a production environment? Thank you for any insights. Abatron BDI-3000 g. - 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
On Wed, Jul 16, 2008 at 03:01:33AM +0200, Ricardo Ribalda Delgado wrote: diff --git a/drivers/serial/serial_xuartlite.c b/drivers/serial/serial_xuartlite.c index 5c41a1c..2e6f096 100644 --- a/drivers/serial/serial_xuartlite.c +++ b/drivers/serial/serial_xuartlite.c @@ -37,9 +37,9 @@ #define SR_RX_FIFO_VALID_DATA0x01 /* data in receive FIFO */ #define SR_RX_FIFO_FULL 0x02 /* receive FIFO full */ -#define UARTLITE_STATUS (CONFIG_SERIAL_BASE + STATUS_REG_OFFSET) -#define UARTLITE_TX_FIFO (CONFIG_SERIAL_BASE + TX_FIFO_OFFSET) -#define UARTLITE_RX_FIFO (CONFIG_SERIAL_BASE + RX_FIFO_OFFSET) +#define UARTLITE_STATUS (u32*)(CONFIG_SERIAL_BASE + STATUS_REG_OFFSET) +#define UARTLITE_TX_FIFO (u32*)(CONFIG_SERIAL_BASE + TX_FIFO_OFFSET) +#define UARTLITE_RX_FIFO (u32*)(CONFIG_SERIAL_BASE + RX_FIFO_OFFSET) Nak. Fix the code instead. These constants are correct and should not be pre-cast in the macro. g. - 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
On Wed, Jul 16, 2008 at 04:22:32PM +0200, Ricardo Ribalda Delgado wrote:
Casting on in_be32 not in MACROS
Signed-off-by: Ricardo Ribalda Delgado [EMAIL PROTECTED]
Acked-by: Grant Likely [EMAIL PROTECTED]
---
serial_xuartlite.c: In function ‘serial_putc’:
serial_xuartlite.c:59: warning: passing argument 1 of ‘in_be32’ makes pointer
from integer without a cast
serial_xuartlite.c:60: warning: passing argument 1 of ‘out_be32’ makes
pointer from integer without a cast
serial_xuartlite.c: In function ‘serial_getc’:
serial_xuartlite.c:72: warning: passing argument 1 of ‘in_be32’ makes pointer
from integer without a cast
serial_xuartlite.c:73: warning: passing argument 1 of ‘in_be32’ makes pointer
from integer without a cast
serial_xuartlite.c: In function ‘serial_tstc’:
serial_xuartlite.c:78: warning: passing argument 1 of ‘in_be32’ makes pointer
from integer without a cast
Previous warnings corrected by this patch
drivers/serial/serial_xuartlite.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/serial/serial_xuartlite.c
b/drivers/serial/serial_xuartlite.c
index 5c41a1c..74546ce 100644
--- a/drivers/serial/serial_xuartlite.c
+++ b/drivers/serial/serial_xuartlite.c
@@ -56,8 +56,8 @@ void serial_putc(const char c)
{
if (c == '\n')
serial_putc('\r');
- while (in_be32(UARTLITE_STATUS) SR_TX_FIFO_FULL);
- out_be32(UARTLITE_TX_FIFO, (unsigned char) (c 0xff));
+ while (in_be32((u32 *) UARTLITE_STATUS) SR_TX_FIFO_FULL);
+ out_be32((u32 *) UARTLITE_TX_FIFO, (unsigned char) (c 0xff));
}
void serial_puts(const char * s)
@@ -69,13 +69,13 @@ void serial_puts(const char * s)
int serial_getc(void)
{
- while (!(in_be32(UARTLITE_STATUS) SR_RX_FIFO_VALID_DATA));
- return in_be32(UARTLITE_RX_FIFO) 0xff;
+ while (!(in_be32((u32 *) UARTLITE_STATUS) SR_RX_FIFO_VALID_DATA));
+ return in_be32((u32 *) UARTLITE_RX_FIFO) 0xff;
}
int serial_tstc(void)
{
- return (in_be32(UARTLITE_STATUS) SR_RX_FIFO_VALID_DATA);
+ return (in_be32((u32 *) UARTLITE_STATUS) SR_RX_FIFO_VALID_DATA);
}
#endif /* CONFIG_MICROBLZE */
--
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
-
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] Please pull u-boot-mpc5xxx.git
The following changes since commit 348753d416cd2c9e7ec6520a544c8f33cf02a560: Kumar Gala (1): Fix some more printf() format problems. are available in the git repository at: git://git.denx.de/u-boot-mpc5xxx.git master Andre Schwarz (1): mpc5xxx: Add MVBC_P board support CREDITS |2 +- MAINTAINERS |1 + MAKEALL |1 + Makefile |7 + board/matrix_vision/mvbc_p/Makefile | 50 board/matrix_vision/mvbc_p/config.mk | 30 +++ board/matrix_vision/mvbc_p/fpga.c| 177 ++ board/matrix_vision/mvbc_p/fpga.h| 34 +++ board/matrix_vision/mvbc_p/mvbc_p.c | 325 ++ board/matrix_vision/mvbc_p/mvbc_p.h | 43 board/matrix_vision/mvbc_p/mvbc_p_autoscript | 44 doc/README.mvbc_p| 74 ++ include/configs/MVBC_P.h | 316 + include/mpc5xxx.h| 29 +++ 14 files changed, 1132 insertions(+), 1 deletions(-) create mode 100644 board/matrix_vision/mvbc_p/Makefile create mode 100644 board/matrix_vision/mvbc_p/config.mk create mode 100644 board/matrix_vision/mvbc_p/fpga.c create mode 100644 board/matrix_vision/mvbc_p/fpga.h create mode 100644 board/matrix_vision/mvbc_p/mvbc_p.c create mode 100644 board/matrix_vision/mvbc_p/mvbc_p.h create mode 100644 board/matrix_vision/mvbc_p/mvbc_p_autoscript create mode 100644 doc/README.mvbc_p create mode 100644 include/configs/MVBC_P.h -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. - 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/2] microblaze: Clean uartlite driver
On Fri, Jul 11, 2008 at 10:10:31AM +0200, [EMAIL PROTECTED] wrote: From: Michal Simek [EMAIL PROTECTED] Redesign uartlite driver to in_be32 and out_be32 macros Fix missing header in io.h Signed-off-by: Michal Simek [EMAIL PROTECTED] Acked-by: Grant Likely [EMAIL PROTECTED] - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH v2] Add MVBC_P board
SIMPLE_PSC2_1 0x0020 +#define SIMPLE_PSC2_0 0x0010 +#define SIMPLE_PSC1_3 0x0008 +#define SIMPLE_PSC1_2 0x0004 +#define SIMPLE_PSC1_1 0x0002 +#define SIMPLE_PSC1_0 0x0001 + +#define SINT_PSC3_5 0x02 +#define SINT_PSC3_4 0x01 + +#define WKUP_7 0x80 +#define WKUP_6 0x40 +#define WKUP_PSC6_1 0x20 +#define WKUP_PSC6_0 0x10 +#define WKUP_ETH17 0x08 +#define WKUP_PSC3_9 0x04 +#define WKUP_PSC2_4 0x02 +#define WKUP_PSC1_4 0x01 + None of this looks like board specific values. Since they are MPC5200 specific, they probably should be moved to a new file called include/mpc5200.h. They should also be prefixed with MPC5200_ to no pollute the namespace. (There is other stuff that is 5200 specific which should be in the same file, but I'm not asking you to do that also. That would be a separate activity). +#define LED_G0 SIMPLE_PSC2_0 +#define LED_G1 SIMPLE_PSC2_1 +#define LED_Y SIMPLE_PSC2_2 +#define LED_R SIMPLE_PSC2_3 +#define ARB_X_ENWKUP_PSC2_4 + +#define FPGA_DINSIMPLE_PSC3_0 +#define FPGA_CCLK SIMPLE_PSC3_1 +#define FPGA_CONF_DONE SIMPLE_PSC3_2 +#define FPGA_CONFIG SIMPLE_PSC3_3 +#define FPGA_STATUS SINT_PSC3_4 + +#define MAN_RST WKUP_PSC6_0 +#define WD_TS WKUP_PSC6_1 +#define WD_WDI SIMPLE_PSC6_2 +#define COP_PRESENT SIMPLE_PSC6_3 +#define FACT_RSTWKUP_6 +#define FLASH_RBY WKUP_7 + +#define SIMPLE_DDR (LED_G0 | LED_G1 | LED_Y | LED_R | \ +FPGA_DIN | FPGA_CCLK | FPGA_CONFIG | WD_WDI) +#define SIMPLE_DVO (FPGA_CONFIG) +#define SIMPLE_ODE (FPGA_CONFIG) +#define SIMPLE_GPIOEN (LED_G0 | LED_G1 | LED_Y | LED_R | \ +FPGA_DIN | FPGA_CCLK | FPGA_CONF_DONE | FPGA_CONFIG |\ +WD_WDI | COP_PRESENT) + +#define SINT_ODE0 +#define SINT_DDR0 +#define SINT_DVO0 +#define SINT_INTEN 0 +#define SINT_ITYPE 0 +#define SINT_GPIOEN (FPGA_STATUS) + +#define WKUP_ODE(MAN_RST) +#define WKUP_DIR(ARB_X_EN|MAN_RST|WD_TS) +#define WKUP_DO (ARB_X_EN|MAN_RST|WD_TS) +#define WKUP_EN (ARB_X_EN|MAN_RST|WD_TS|FACT_RST|FLASH_RBY) + +#endif -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] Configuration changes for ADS5121 Rev 3
On Thu, May 29, 2008 at 12:23 PM, Martha Marx [EMAIL PROTECTED] wrote:
Signed-off-by: Martha Marx [EMAIL PROTECTED]
Acked by: Grant Likely [EMAIL PROTECTED]
---
Makefile |9 -
board/ads5121/README |9 +
board/ads5121/ads5121.c | 19 +--
cpu/mpc512x/cpu.c |8 ++--
include/configs/ads5121.h | 38 +++---
5 files changed, 67 insertions(+), 16 deletions(-)
create mode 100644 board/ads5121/README
diff --git a/Makefile b/Makefile
index 3401203..c102b55 100644
--- a/Makefile
+++ b/Makefile
@@ -746,12 +746,11 @@ motionpro_config: unconfig
## MPC512x Systems
#
ads5121_config \
-ads5121_PCI_config \
- :unconfig
+ads5121_rev2_config\
+ : unconfig
@mkdir -p $(obj)include
- @if [ $(findstring _PCI_,$@) ] ; then \
- echo #define CONFIG_PCI $(obj)include/config.h ; \
- $(XECHO) ... with PCI enabled ; \
+ @if [ $(findstring rev2,$@) ] ; then \
+ echo #define CONFIG_ADS5121_REV2 1
$(obj)include/config.h; \
fi
@$(MKCONFIG) -a ads5121 ppc mpc512x ads5121
diff --git a/board/ads5121/README b/board/ads5121/README
new file mode 100644
index 000..c5a92e8
--- /dev/null
+++ b/board/ads5121/README
@@ -0,0 +1,9 @@
+To configure for the current (Rev 3.x) ADS5121
+ make ads5121_config
+This will automatically include PCI, the Real Time CLock, add backup flash
+ability and set the correct frequency and memory configuration.
+
+To configure for the older Rev 2 ADS5121 type (this will not have PCI)
+ make ads5121_rev2_config
+
+
diff --git a/board/ads5121/ads5121.c b/board/ads5121/ads5121.c
index 2892665..95559ca 100644
--- a/board/ads5121/ads5121.c
+++ b/board/ads5121/ads5121.c
@@ -26,7 +26,9 @@
#include asm/bitops.h
#include command.h
#include fdt_support.h
-
+#ifdef CONFIG_MISC_INIT_R
+#include i2c.h
+#endif
/* Clocks in use */
#define SCCR1_CLOCKS_EN(CLOCK_SCCR1_CFG_EN |
\
CLOCK_SCCR1_LPC_EN | \
@@ -91,8 +93,21 @@ int board_early_init_f (void)
* Without this the flash identification routine fails, as it needs to
issue
* write commands in order to establish the device ID.
*/
- *((volatile u8 *)(CFG_CPLD_BASE + 0x08)) = 0xC1;
+#ifdef CONFIG_ADS5121_REV2
+ *((volatile u8 *)(CFG_CPLD_BASE + 0x08)) = 0xC1;
+#else
+ if (*((u8 *)(CFG_CPLD_BASE + 0x08)) 0x04) {
+ *((volatile u8 *)(CFG_CPLD_BASE + 0x08)) = 0xC1;
+ } else {
+ /* running from Backup flash */
+ *((volatile u8 *)(CFG_CPLD_BASE + 0x08)) = 0x32;
+ }
+#endif
+ /*
+* Configure Flash Speed
+*/
+ *((volatile u32 *)(CFG_IMMR + LPC_OFFSET + CS0_CONFIG)) = CFG_CS0_CFG;
/*
* Enable clocks
*/
diff --git a/cpu/mpc512x/cpu.c b/cpu/mpc512x/cpu.c
index bed77ac..b59f36d 100644
--- a/cpu/mpc512x/cpu.c
+++ b/cpu/mpc512x/cpu.c
@@ -133,8 +133,9 @@ void watchdog_reset (void)
#ifdef CONFIG_OF_LIBFDT
void ft_cpu_setup(void *blob, bd_t *bd)
{
- char * cpu_path = /cpus/ OF_CPU;
- char * eth_path = / OF_SOC /[EMAIL PROTECTED];
+ char *cpu_path = /cpus/ OF_CPU;
+ char *eth_path = / OF_SOC /[EMAIL PROTECTED];
+ char *eth_path_old = / OF_SOC_OLD /[EMAIL PROTECTED];
do_fixup_by_path_u32(blob, cpu_path, timebase-frequency, OF_TBCLK,
1);
do_fixup_by_path_u32(blob, cpu_path, bus-frequency, bd-bi_busfreq,
1);
@@ -144,5 +145,8 @@ void ft_cpu_setup(void *blob, bd_t *bd)
/* this is so old kernels with old device trees will boot */
do_fixup_by_path_u32(blob, / OF_SOC_OLD, bus-frequency,
bd-bi_ipsfreq, 0);
+ do_fixup_by_path(blob, eth_path_old, local-mac-address,
+ bd-bi_enetaddr, 6, 0);
+ do_fixup_by_path(blob, eth_path_old, address, bd-bi_enetaddr, 6,
0);
}
#endif
diff --git a/include/configs/ads5121.h b/include/configs/ads5121.h
index c975a24..21374e9 100644
--- a/include/configs/ads5121.h
+++ b/include/configs/ads5121.h
@@ -57,7 +57,12 @@
/* CONFIG_PCI is defined at config time */
+#ifdef CONFIG_ADS5121_REV2
#define CFG_MPC512X_CLKIN 6600/* in Hz */
+#else
+#define CFG_MPC512X_CLKIN /* in Hz */
+#define CONFIG_PCI
+#endif
#define CONFIG_BOARD_EARLY_INIT_F /* call board_early_init_f()
*/
#define CONFIG_MISC_INIT_R
@@ -71,7 +76,11 @@
/*
* DDR Setup - manually set all parameters as there's no SPD etc.
*/
+#ifdef CONFIG_ADS5121_REV2
#define CFG_DDR_SIZE 256 /* MB */
+#else
+#define CFG_DDR_SIZE 512 /* MB */
+#endif
#define
Re: [U-Boot-Users] [PATCH] Consolidates ADS5121 IO Pin configuration
On Thu, May 29, 2008 at 2:11 PM, Kenneth Johansson [EMAIL PROTECTED] wrote: On Thu, 2008-05-29 at 15:37 -0400, Martha Marx wrote: Signed-off-by: Martha Marx [EMAIL PROTECTED] Acked-by: Grant Likely [EMAIL PROTECTED] --- board/ads5121/Makefile|2 +- board/ads5121/ads5121.c | 36 +--- board/ads5121/iopin.c | 96 board/ads5121/iopin.h | 220 + cpu/mpc512x/fec.c | 15 --- include/configs/ads5121.h |1 + 6 files changed, 321 insertions(+), 49 deletions(-) create mode 100644 board/ads5121/iopin.c create mode 100644 board/ads5121/iopin.h It's good that you remove iomux setting from the drivers like fec it should not be there. It's NOT good that you now put them in another driver iopin. The pins should be in board specific files. iopin should only contain helper functions not data that everybody that do a new board needs to go in and change/add. put the table in ads5121.c and I'm happy with it. well I'm not sure we need this fancy stuff only gets harder to read but I take that over having the config spread out over different files like it's now. I think this approach is okay. For now it is isolated within the board directory, but it can be factored out into common code where there are a few more 5121 board ports. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] Changes ADS5121 splash screen from hard-coded bmp to flash bmp
registers */ diff --git a/include/configs/ads5121.h b/include/configs/ads5121.h index 21374e9..ae98359 100644 --- a/include/configs/ads5121.h +++ b/include/configs/ads5121.h @@ -45,6 +45,7 @@ */ #define CONFIG_E3001 /* E300 Family */ #define CONFIG_MPC512X 1 /* MPC512X family */ +#define CONFIG_ADS5121 1 /* ADS5121 board */ #define CONFIG_FSL_DIU_FB 1 /* FSL DIU */ /* video */ @@ -222,6 +223,7 @@ #define CFG_MONITOR_LEN(256 * 1024)/* Reserve 256 kB for Mon */ #ifdef CONFIG_FSL_DIU_FB #define CFG_MALLOC_LEN (6 * 1024 * 1024) /* Reserved for malloc */ +#define CFG_SPLASH_SIZE(2 * 1024 * 1024) #else #define CFG_MALLOC_LEN (512 * 1024) #endif -- 1.5.2.4 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Proposal for u-boot-nand-flash custodian change
On Tue, May 13, 2008 at 9:21 AM, Stefan Roese [EMAIL PROTECTED] wrote: Hi, unfortunately I found little time to take care of the NAND custodianship lately. This is partly because I am busy with other U-Boot custodian work too (ppc4xx, cfi-flash). I was looking for some time now for a candidate to take over this NAND custodianship, so that patches will hopefully get processed more quickly in the future. Now I have a candidate to propose for this custodianship: Scott Wood. He has done NAND related work in the past (U-Boot and Linux) and I think that he is very qualified for this job. Therefore I officially propose Scott Wood as new u-boot-nand-flash custodian. I would really like to get some feedback on this. Any comments or other suggestions? Acked-by: Grant Likely [EMAIL PROTECTED] :-) g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Running Linux from ARCH=powerpc on Sequoia board
On Wed, Apr 23, 2008 at 7:11 PM, Larry Johnson [EMAIL PROTECTED] wrote: Thanks Stefan, Grant, and Wolfgang for your comments. Method 2 is working for me, as it turns out that files cuImage.sequoia and zImage are identical. That is because zImage is simply linked to the first target in the image-y list (every target added to image-y is built when you do 'make zImage') fdt_chosen: FDT_ERR_NOSPACE ERROR: /chosen node create failed - must RESET the board to recover. U-Boot 1.3.2-00497-g58c5376 (Apr 23 2008 - 16:24:13) [...] /listing The file sequoia.dtb was created by $dtc dts/sequoia.dts -O dtb -o sequoia.dtb Can anyone tell me what went wrong? You're hitting a limitation of current u-boot. It doesn't know how to allocate more space in a device tree blob. Try passing -S 8192 -R 16 to dtc. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Running Linux from ARCH=powerpc on Sequoia board
On Tue, Apr 22, 2008 at 12:55 PM, Larry Johnson [EMAIL PROTECTED] wrote: Hi Stefan, Currently, I can build zImage for Sequoia using the powerpc architecture, and load it using U-Boot without a separate FDT binary. Is this the best way to run a Linux from the powerpc tree? Sorry, I don't understand what you're asking. There are two way to boot a Linux image from arch/powerpc. 1) build a uImage and get u-boot to pass a device tree blob (if your u-boot had device tree support) 2) build a cuImage which wraps the device tree in the kernel image. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH v2 3/7] add an i2c driver for mx31
On Mon, Apr 14, 2008 at 5:28 PM, Guennadi Liakhovetski [EMAIL PROTECTED] wrote: On Mon, 14 Apr 2008, Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: +#if defined(CONFIG_HARD_I2C) defined (CONFIG_I2C_MXC) Please stop to define this here, move it the Makefile Hm... While I agree with the simple standard case of a single #ifdef, I'm not so 100% sure it is a good thing to add such complex expressions to the Makefile. Aren't we just moving the #ifdef hell from one place to another? Wouldn't it be logical to assume, that if CONFIG_I2C_MXC is defined, CONFIG_HARD_I2C is meant too? So, we could just put in i2c.h #ifdef CONFIG_I2C_MXC #define CONFIG_HARD_I2C #endif And then use the simple OBJC-$(CONFIG_I2C_MXC) += ... Yes, this is the way I'd solve the problem. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 3/3] mpc83xx: cleanup System Part and Revision ID Register (SPRIDR) code
On Fri, Mar 28, 2008 at 4:41 PM, Kim Phillips [EMAIL PROTECTED] wrote: On Fri, 28 Mar 2008 21:01:30 +0100 Joakim Tjernlund [EMAIL PROTECTED] wrote: BTW, what happened to relocation stuff Grant was doing? It is still disabled, I never had any problems so perhaps time to turn it on again? it might even make u-boot smaller once all the old manuel relocation code has been properly disabled. beats me. I'm all for it, but I think we're still supposed to support a wide range of toolchain versions (the reason Grant's stuff got reverted). The main problem is not really understanding how gcc wants to handle relocation. I've got no idea what needs to be different between versions of gcc. Someone with greater gcc powers than I needs to take a look at it. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ 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] mpc5200 without fec
On Thu, Mar 13, 2008 at 6:50 AM, André Schwarz
[EMAIL PROTECTED] wrote:
include fec specific nodes in ft_cpu_setup only if CONFIG_MPC5xxx_FEC is
defined. Systems without FEC, i.e. no fec node in dtb, should be possible.
Signed-off-by: Andre Schwarz [EMAIL PROTECTED]
Hmm; if there is no fec node; then won't this just fail silently? In
which case; I'd rather avoid adding more inline #ifdefs to the code.
(correct me if I'm wrong)
Cheers,
g.
---
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht:
Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
diff --git a/cpu/mpc5xxx/cpu.c b/cpu/mpc5xxx/cpu.c
index e4d6168..dbfdd97 100644
--- a/cpu/mpc5xxx/cpu.c
+++ b/cpu/mpc5xxx/cpu.c
@@ -119,7 +119,9 @@ void ft_cpu_setup(void *blob, bd_t *bd)
{
int div = in_8((void*)CFG_MBAR + 0x204) 0x0020 ? 8 : 4;
char * cpu_path = /cpus/ OF_CPU;
+#ifdef CONFIG_MPC5xxx_FEC
char * eth_path = / OF_SOC /[EMAIL PROTECTED];
+#endif
do_fixup_by_path_u32(blob, cpu_path, timebase-frequency, OF_TBCLK,
1);
do_fixup_by_path_u32(blob, cpu_path, bus-frequency, bd-bi_busfreq,
1);
@@ -127,7 +129,9 @@ void ft_cpu_setup(void *blob, bd_t *bd)
do_fixup_by_path_u32(blob, / OF_SOC, bus-frequency,
bd-bi_ipbfreq, 1);
do_fixup_by_path_u32(blob, / OF_SOC, system-frequency,
bd-bi_busfreq*div, 1);
+#ifdef CONFIG_MPC5xxx_FEC
do_fixup_by_path(blob, eth_path, mac-address, bd-bi_enetaddr, 6,
0);
do_fixup_by_path(blob, eth_path, local-mac-address,
bd-bi_enetaddr, 6, 0);
+#endif
}
#endif
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] u-boot relocation?
On 2/4/08, Joakim Tjernlund [EMAIL PROTECTED] wrote: Hi Grant Can you tell me what happened to the relocation stuff you added and why it was disabled? Because it broke on gcc 4.0.x and gcc 4.0x. :-( And I didn't have enough time to figure out what went wrong (nor did I have any other versions of the compiler installed). g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFC: Concise Build Output
On 1/23/08, Wolfgang Denk [EMAIL PROTECTED] wrote: Dear Jon, in message [EMAIL PROTECTED] you wrote: In the spirit of the Linux and Git build systems, I have a modified U-Boot build system that supports a much more concise output! One of the primary motivations for this style of output is that it will very readily highlight build issues and problems as your build progresses. The original, complete build output is obtainable by simply supplying V=1 on the make invocation in exactly the same way as both Linux and Git do today. snip So my question is: which problem are you trying to solve that is not already solved by make -s or MAKEALL? I don't really see the need for a solution between no output and full output. YMMV, of course. Hope I didn't frustrate you - I still appreciate the effort. Hey Jon, Wolfgang; I think this is a good change myself. The biggest reason is that it makes the default output terse instead of verbose. I'd hazard to wager that most developers don't use 'make -s', MAKEALL, or anything else to trim the output (I certainly don't). By making the default output terse, with errors and warning visually distinct from progress indication, in increases the likelyhood that warnings will actually get seen and fixed (because more people will notice it). I say make this change. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] FSL: Convert board/freescale/common/Makefile to use CONFIG_
On 1/16/08, Jon Loeliger [EMAIL PROTECTED] wrote:
On Tue, 2008-01-15 at 16:59, Grant Likely wrote:
Nit: Don't do it this way; do this instead (to match the style used in
other Makefiles):
+COBJS-y:= pq-mds-pib.o
+COBJS-${CONFIG_ID_EEPROM}+= sys_eeprom.o
+COBJS-${CONFIG_FSL_DIU_FB} += fsl_diu_fb.o fsl_logo_bmp.o
+COBJS-${CONFIG_FSL_PIXIS}+= pixis.o
-SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
So, are you going to submit a patch to convert
them all to be like that then?
I looked at this one in drivers/net:
Hmm, I missed that when drivers/Makefile was split up into the
subdirectories. When I first split up the COBJS, I eliminated COBJS
entirely in favor of COBJS-y. It's not a big deal though.
However, I would at the very least change this:
COBJS := pq-mds-pib.o
to this:
COBJS=y += pq-mds-pib.o
So that all obj files are added in the same way.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] FSL: Convert board/freescale/common/Makefile to use CONFIG_
On 1/15/08, Kim Phillips [EMAIL PROTECTED] wrote:
On Tue, 15 Jan 2008 15:21:09 -0600
Jon Loeliger [EMAIL PROTECTED] wrote:
snip
-COBJS:= sys_eeprom.o \
-pixis.o \
-pq-mds-pib.o \
-fsl_logo_bmp.o \
-fsl_diu_fb.o
+COBJS:= pq-mds-pib.o
+
+COBJS-${CONFIG_ID_EEPROM}+= sys_eeprom.o
+COBJS-${CONFIG_FSL_DIU_FB} += fsl_diu_fb.o fsl_logo_bmp.o
+COBJS-${CONFIG_FSL_PIXIS}+= pixis.o
+
+COBJS+= ${COBJS-y}
Nit: Don't do it this way; do this instead (to match the style used in
other Makefiles):
+COBJS-y:= pq-mds-pib.o
+COBJS-${CONFIG_ID_EEPROM}+= sys_eeprom.o
+COBJS-${CONFIG_FSL_DIU_FB} += fsl_diu_fb.o fsl_logo_bmp.o
+COBJS-${CONFIG_FSL_PIXIS}+= pixis.o
-SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
what, no love for pq-mds-pib.o (CONFIG_PQ_MDS_PIB)?
Kim
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
