Re: [U-Boot] Random problem on MPC8640D based board
Dear "Thirumalai", In message <0c0a8ed2edfb487097801b3175c0f...@itd210> you wrote: > > Sorry. Trap 200 is Machine check exception. Also sometimes we are getting > TRAP 300 which is DSI exception. It doesn't really matter which exception you are seeing. Fact is the system is not running stable. Culprit # 1 in such situations is the RAM not working stable. > > Did you try booting Linux on that board? Let me guess: if you tried, > > it crashed, right? > > No. It is not crashing. Linux is booting on this board successfully. Its a > random issue. How do you run Linux? Did you try running with root file system mounted over NFS, and adding some real load, like compiling some sources? > > I recommend to check the RAM initialization sequence. I bet you see > > memory corruption effects. > > What you meant for memory corruption effects? I mean that your RAm is not working reliably. See the FAQ: http://www.denx.de/wiki/view/DULG/UBootCrashAfterRelocation 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: w...@denx.de Mr. Cole's Axiom: The sum of the intelligence on the planet is a constant; the population is growing. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Blackfin: TWI/I2C: implement multibus support
On Wednesday 05 May 2010 02:12:18 Heiko Schocher wrote:
> Mike Frysinger wrote:
> > +/* Every register is 32bit aligned, but only 16bits in size */
> > +#define ureg(name) u16 name; u16 __pad_##name;
> > +struct twi_regs {
> > + ureg(clkdiv);
> > + ureg(control);
> > + ureg(slave_ctl);
> > + ureg(slave_stat);
> > + ureg(slave_addr);
> > + ureg(master_ctl);
> > + ureg(master_stat);
> > + ureg(master_addr);
> > + ureg(int_stat);
> > + ureg(int_mask);
> > + ureg(fifo_ctl);
> > + ureg(fifo_stat);
> > + char __pad[0x50];
> > + ureg(xmt_data8);
> > + ureg(xmt_data16);
> > + ureg(rcv_data8);
> > + ureg(rcv_data16);
> > +};
> > +#undef ureg
>
> Your commit message says only "implement multibus support"
> Please add a comment, that you also introduce the "twi_regs"
> struct, thanks.
one doesnt make much sense without the other ...
> bfin_read/write_TWI_* macros uses bfin_read/write16 ... your patch
> don;t longer use this I/O accessors. Is this OK?
in this particular instance, it's fine. there is an old anomaly on some
Blackfin parts where bfin_read/bfin_write must always be used as it includes
appropriate workarounds, but this driver cannot be used on those parts.
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Blackfin: TWI/I2C: implement multibus support
In order to do this cleanly, the register accesses have to be converted to
a C struct (base pointer), so do that in the process.
Signed-off-by: Mike Frysinger
---
v2
- extend changelog
drivers/i2c/bfin-twi_i2c.c | 169
1 files changed, 108 insertions(+), 61 deletions(-)
diff --git a/drivers/i2c/bfin-twi_i2c.c b/drivers/i2c/bfin-twi_i2c.c
index 73a78d2..b3a04d3 100644
--- a/drivers/i2c/bfin-twi_i2c.c
+++ b/drivers/i2c/bfin-twi_i2c.c
@@ -1,7 +1,7 @@
/*
* i2c.c - driver for Blackfin on-chip TWI/I2C
*
- * Copyright (c) 2006-2008 Analog Devices Inc.
+ * Copyright (c) 2006-2010 Analog Devices Inc.
*
* Licensed under the GPL-2 or later.
*/
@@ -12,6 +12,35 @@
#include
#include
+/* Every register is 32bit aligned, but only 16bits in size */
+#define ureg(name) u16 name; u16 __pad_##name;
+struct twi_regs {
+ ureg(clkdiv);
+ ureg(control);
+ ureg(slave_ctl);
+ ureg(slave_stat);
+ ureg(slave_addr);
+ ureg(master_ctl);
+ ureg(master_stat);
+ ureg(master_addr);
+ ureg(int_stat);
+ ureg(int_mask);
+ ureg(fifo_ctl);
+ ureg(fifo_stat);
+ char __pad[0x50];
+ ureg(xmt_data8);
+ ureg(xmt_data16);
+ ureg(rcv_data8);
+ ureg(rcv_data16);
+};
+#undef ureg
+
+/* U-Boot I2C framework allows only one active device at a time. */
+#ifdef TWI_CLKDIV
+#define TWI0_CLKDIV TWI_CLKDIV
+#endif
+static volatile struct twi_regs *twi = (void *)TWI0_CLKDIV;
+
#ifdef DEBUG
# define dmemset(s, c, n) memset(s, c, n)
#else
@@ -19,29 +48,10 @@
#endif
#define debugi(fmt, args...) \
debug( \
- "MSTAT:0x%03x FSTAT:0x%x ISTAT:0x%02x\t" \
- "%-20s:%-3i: " fmt "\n", \
- bfin_read_TWI_MASTER_STAT(), bfin_read_TWI_FIFO_STAT(),
bfin_read_TWI_INT_STAT(), \
+ "MSTAT:0x%03x FSTAT:0x%x ISTAT:0x%02x\t%-20s:%-3i: " fmt "\n", \
+ twi->master_stat, twi->fifo_stat, twi->int_stat, \
__func__, __LINE__, ## args)
-#ifdef TWI0_CLKDIV
-#define bfin_write_TWI_CLKDIV(val) bfin_write_TWI0_CLKDIV(val)
-#define bfin_read_TWI_CLKDIV(val)bfin_read_TWI0_CLKDIV(val)
-#define bfin_write_TWI_CONTROL(val) bfin_write_TWI0_CONTROL(val)
-#define bfin_read_TWI_CONTROL(val) bfin_read_TWI0_CONTROL(val)
-#define bfin_write_TWI_MASTER_ADDR(val) bfin_write_TWI0_MASTER_ADDR(val)
-#define bfin_write_TWI_XMT_DATA8(val)bfin_write_TWI0_XMT_DATA8(val)
-#define bfin_read_TWI_RCV_DATA8()bfin_read_TWI0_RCV_DATA8()
-#define bfin_read_TWI_INT_STAT() bfin_read_TWI0_INT_STAT()
-#define bfin_write_TWI_INT_STAT(val) bfin_write_TWI0_INT_STAT(val)
-#define bfin_read_TWI_MASTER_STAT() bfin_read_TWI0_MASTER_STAT()
-#define bfin_write_TWI_MASTER_STAT(val) bfin_write_TWI0_MASTER_STAT(val)
-#define bfin_read_TWI_MASTER_CTL() bfin_read_TWI0_MASTER_CTL()
-#define bfin_write_TWI_MASTER_CTL(val) bfin_write_TWI0_MASTER_CTL(val)
-#define bfin_write_TWI_INT_MASK(val) bfin_write_TWI0_INT_MASK(val)
-#define bfin_write_TWI_FIFO_CTL(val) bfin_write_TWI0_FIFO_CTL(val)
-#endif
-
#ifdef CONFIG_TWICLK_KHZ
# error do not define CONFIG_TWICLK_KHZ ... use CONFIG_SYS_I2C_SPEED
#endif
@@ -87,49 +97,48 @@ static int wait_for_completion(struct i2c_msg *msg)
ulong timebase = get_timer(0);
do {
- int_stat = bfin_read_TWI_INT_STAT();
+ int_stat = twi->int_stat;
if (int_stat & XMTSERV) {
debugi("processing XMTSERV");
- bfin_write_TWI_INT_STAT(XMTSERV);
+ twi->int_stat = XMTSERV;
SSYNC();
if (msg->alen) {
- bfin_write_TWI_XMT_DATA8(*(msg->abuf++));
+ twi->xmt_data8 = *(msg->abuf++);
--msg->alen;
} else if (!(msg->flags & I2C_M_COMBO) && msg->len) {
- bfin_write_TWI_XMT_DATA8(*(msg->buf++));
+ twi->xmt_data8 = *(msg->buf++);
--msg->len;
} else {
-
bfin_write_TWI_MASTER_CTL(bfin_read_TWI_MASTER_CTL() |
- (msg->flags & I2C_M_COMBO ? RSTART |
MDIR : STOP));
+ twi->master_ctl |= (msg->flags & I2C_M_COMBO) ?
RSTART | MDIR : STOP;
SSYNC();
}
}
if (int_stat & RCVSERV) {
debugi("processing RCVSERV");
- bfin_write_TWI_INT_STAT(RCVSERV);
+ twi->int_stat = RCVSERV;
SSYNC();
if (msg->len) {
- *(msg->buf++) = bfi
Re: [U-Boot] [PATCH 5/6 v3] spi_flash: support old STMicro parts with RES
ive merged this into my sf branch and will push out next merge window if Wolfgang doesnt pick it up before that -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC v2] add redundant environment for env_sf.c
ive merged this into my sf branch and will push out next merge window if Wolfgang doesnt pick it up before that -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Random problem on MPC8640D based board
Dear Denx, - Original Message - From: "Wolfgang Denk" To: "Thirumalai" Cc: Sent: Wednesday, May 05, 2010 12:38 PM Subject: Re: [U-Boot] Random problem on MPC8640D based board > Dear "Thirumalai", > > In message <0c0a8ed2edfb487097801b3175c0f...@itd210> you wrote: >> >> Sorry. Trap 200 is Machine check exception. Also sometimes we are getting >> TRAP 300 which is DSI exception. > > It doesn't really matter which exception you are seeing. Fact is the > system is not running stable. Culprit # 1 in such situations is the > RAM not working stable. > >> > Did you try booting Linux on that board? Let me guess: if you tried, >> > it crashed, right? >> >> No. It is not crashing. Linux is booting on this board successfully. Its >> a >> random issue. > > How do you run Linux? Did you try running with root file system > mounted over NFS, and adding some real load, like compiling some > sources? > We are running with rootfile system mounted over NFS. we have used lmbench and ltp for load. >> > I recommend to check the RAM initialization sequence. I bet you see >> > memory corruption effects. >> >> What you meant for memory corruption effects? > > I mean that your RAm is not working reliably. See the FAQ: > http://www.denx.de/wiki/view/DULG/UBootCrashAfterRelocation > > 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: w...@denx.de > Mr. Cole's Axiom: >The sum of the intelligence on the planet is a constant; >the population is growing. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Blackfin: TWI/I2C: implement multibus support
On Wednesday 05 May 2010 03:20:30 Mike Frysinger wrote: > In order to do this cleanly, the register accesses have to be converted to > a C struct (base pointer), so do that in the process. Stefan pointed out i was wrongly sending my i2c stuff to him instead of Heiko. so here is my prod to Heiko. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6 v3] spi_flash: support old STMicro parts with RES
On 05/05/2010 03:21 PM, Mike Frysinger wrote: > ive merged this into my sf branch and will push out next merge window if > Wolfgang doesnt pick it up before that > -mike > Hi Mike, You are so nice. Thanks again. Best regards, Thomas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Serail console interface "functions/datastructures"
Hi list I'm trying to get most simple u-boot for our custom board ported, with serail port. Could someone point to me which doc/examples I should follow, to implement serail console? I'm assuming there is a "well" defined interface, functions/datastructes one has to implement specific to a particular board. Thanks all. A ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [GIT PULL] Pull request: u-boot-imx
Hi Tom, please pull from u-boot-imx. The following changes since commit b88c5988db176a0f9de5598d5167ee2498637d40: Kim Phillips (1): configs: remove unused CONFIG_COMMAND_HISTORY are available in the git repository at: git://git.denx.de/u-boot-imx master Anatolij Gustschin (1): tx25: fix crash while booting Linux Fabio Estevam (1): MX51: Fix MX51 CPU detect message Magnus Lilja (1): i.MX31: Activate NAND support for i.MX31 Litekit board. Stefano Babic (7): MX51evk: Removed warnings MX: Added Freescale Power Management Driver MX: RTC13783 uses general function to access PMIC MX31: Add support for PMIC to the QONG module SPI: added support for MX51 to mxc_spi MX: Added definition file for MC13892 Add SPI support to mx51evk board arch/arm/cpu/arm_cortexa8/mx51/soc.c |2 +- board/davedenx/qong/qong.c | 20 +++ board/freescale/mx51evk/mx51evk.c| 143 +- board/karo/tx25/tx25.c |3 + drivers/misc/Makefile|1 + drivers/misc/fsl_pmic.c | 200 + drivers/rtc/mc13783-rtc.c| 72 +++- drivers/spi/mxc_spi.c| 231 +++--- include/configs/imx31_litekit.h | 19 +++- include/configs/mx31ads.h|8 +- include/configs/mx31pdk.h|9 +- include/configs/mx51evk.h| 15 +++ include/configs/qong.h | 14 ++ include/fsl_pmic.h | 128 +++ include/mc13892.h| 160 +++ 15 files changed, 935 insertions(+), 90 deletions(-) create mode 100644 drivers/misc/fsl_pmic.c create mode 100644 include/fsl_pmic.h create mode 100644 include/mc13892.h -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Serail console interface "functions/datastructures"
On Wednesday 05 May 2010 04:08:20 Ayewin Oung wrote:
> Could someone point to me which doc/examples I should follow, to implement
> serail console? I'm assuming there is a "well" defined interface,
> functions/datastructes one has to implement specific to a particular board.
there are no docs unfortunately. this is one thing people tend to implement
once and forget about, and so no one has bothered documenting it.
look at include/common.h. you have to implement
serial_{set_baud,setbrg,init,putc,puts,getc,tstc}.
grep the tree for those functions to find examples, but the names should be
pretty self-explanatory.
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] serial: punt unused serial_addr()
Only one file apparently defines this function, and it merely stubs it
out. So if no one is defining/calling it, punt it.
Signed-off-by: Mike Frysinger
---
board/barco/barco.c |4
include/common.h|1 -
2 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/board/barco/barco.c b/board/barco/barco.c
index d7a0078..c5fe8c4 100644
--- a/board/barco/barco.c
+++ b/board/barco/barco.c
@@ -340,10 +340,6 @@ void serial_puts (const char *c)
{
return;
}
-void serial_addr (unsigned int i)
-{
- return;
-}
int serial_getc (void)
{
return 0;
diff --git a/include/common.h b/include/common.h
index c7358a2..ef6365a 100644
--- a/include/common.h
+++ b/include/common.h
@@ -470,7 +470,6 @@ void ft_pci_setup(void *blob, bd_t *bd);
/* $(CPU)/serial.c */
intserial_init (void);
void serial_exit (void);
-void serial_addr (unsigned int);
void serial_setbrg (void);
void serial_putc (const char);
void serial_putc_raw(const char);
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Serail console interface "functions/datastructures"
Thats cool thanks.
On 5 May 2010 09:25, Mike Frysinger wrote:
> On Wednesday 05 May 2010 04:08:20 Ayewin Oung wrote:
> > Could someone point to me which doc/examples I should follow, to
> implement
> > serail console? I'm assuming there is a "well" defined interface,
> > functions/datastructes one has to implement specific to a particular
> board.
>
> there are no docs unfortunately. this is one thing people tend to
> implement
> once and forget about, and so no one has bothered documenting it.
>
> look at include/common.h. you have to implement
> serial_{set_baud,setbrg,init,putc,puts,getc,tstc}.
>
> grep the tree for those functions to find examples, but the names should be
> pretty self-explanatory.
> -mike
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Debugging into the kernel from u-boot
Hi Stefan, > > You have all the equipment you need. Use the BDI3000 to debug > the Linux > kernel. is it correct, that I can only use HARD breakpoints? Because when I set BREAK SOFT, the gdb always says it cannot access memory at c000 And even with HW breakpoints I'm not able to do clean stepping thru the code. The pointer jumps more or less arbitrarily thru the file resulting in a crash after some steps. >From the BDI3000 documentation I assume, that using MMT XLAT and setting PTBASE is only important, if I load and start the kernel directly, without the initialization from U-Boot. Am I right? For information I attach the log I read out of memory at __log_buf location... although I already posted that on the linuxppc-dev list... Do you think, that there's maybe a hardware issue because of the timing errors in the call trace? Is this the reason for the strange behaviour of the gdb when trying to step thru the code? I mean - assuming that the hardware is correct - I should be able to do "state-of-the-art" code stepping even at early stage like in early_init_devtree, right? Thanks! Matthias kernel-log.008 Description: Binary data ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Debugging into the kernel from u-boot
Dear "Dunda, Matthias", In message <569685f045b85741820d0265e0d2999d019cf...@tddhh01.hh.thales-naval.de> you wrote: > > is it correct, that I can only use HARD breakpoints? Because when I set > BREAK SOFT, the gdb always says it cannot access memory at c000 This should be a configuration issue, most probabl;y with your BDI config file. > From the BDI3000 documentation I assume, that using MMT XLAT and setting > PTBASE is only important, if I load and start the kernel directly, without > the initialization from U-Boot. Am I right? No. These are always important when you want to debug the kernel. And you need BDI support enabled in the kernel as well. > For information I attach the log I read out of memory at __log_buf > location... although I already posted that on the linuxppc-dev list... Argh.. Multiple postings on several lists :-( [Not to mention that, strictly speaking, this discussion is off topic here.] > Do you think, that there's maybe a hardware issue because of the timing > errors in the call trace? No. > Is this the reason for the strange behaviour of the gdb when trying to step > thru the code? I don't know which "strange behaviour of the gdb" you are talking about. Did you read the available documentation and FAQ's on this topic? > I mean - assuming that the hardware is correct - I should be able to do > "state-of-the-art" code stepping even at early stage like in > early_init_devtree, right? Right. 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: w...@denx.de "Spock, did you see the looks on their faces?" "Yes, Captain, a sort of vacant contentment." ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Fix for a build ?
Dear Sylvain Lamontagne, We have had a similir issue building U-Boot (1.1.6) in a server with 2 cuadcore processors that is responsible of the automated build system. GNU Make has the posibility to run several jobs simultaneously, passing the argument "-j N", where N is the number of jobs executed simultaneously. Since our server has 8 processors, we use "-j 9" arguments in the automated build (the documentation recomends using N= number of cores +1). This way, U-Boot and other software projects, sometimes build ok and sometimes fail. We solve this problem building U-Boot and failing projects passing "-j 1" argument to Make (without running simultaneous jobs), and the rest of software with "-j 9". I have seen that you are running simultaneous jobs: *[09:23:58]:* *make: *** Waiting for unfinished jobs* Hope this helps. Peace. -- Igor Luri R&D Software Department Fagor Aotek S. Coop. P. O. Box 144 E-20500 Mondragón-Arrasate Tel.++34 943 71 92 00 ++34 943 71 92 01 (Ext. 44268) Fax.++34 943 79 92 03 www.aotek.es ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC v2] add redundant environment for env_sf.c
Hi Mike, On 5 May 2010 at 3:22, Mike Frysinger wrote: > ive merged this into my sf branch and will push out next merge window if > Wolfgang doesnt pick it up before that > -mike thanks! Wolfgang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ubifsmount fails due to not initialized list
On Wed, Apr 21, 2010 at 8:47 AM, Stefano Babic wrote: > ubifsmount is not working and causes an access with > a pointer set to zero because the ubifs_fs_type > is not initialized correctly. > > Signed-off-by: Stefano Babic > --- > fs/ubifs/super.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c > index 391dea4..39e3efe 100644 > --- a/fs/ubifs/super.c > +++ b/fs/ubifs/super.c > @@ -1178,6 +1178,7 @@ int ubifs_mount(char *vol_name) >ubifs_umount(ubifs_sb->s_fs_info); > >INIT_LIST_HEAD(&ubifs_infos); > + INIT_LIST_HEAD(&ubifs_fs_type.fs_supers); > >/* > * Mount in read-only mode > -- > 1.6.3.3 > > Out of interest, how did something like this get away with only causing an occasional failure? > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot hangs after detecting DDR3 RAM and Flash.
Hi Stefan, >> No. What I meant, was that you should try the "sleep" command on the U-Boot >> prompt, to check, if the timer is working or not. Check if a "sleep 3" really >> takes 3 seconds to return to the prompt. I commented he MSR_EE in interrupt_init function in cpu/ppc4xx/interrupts.c to run the u-boot and to get u-boot prompt. when I executed "sleep 3 " command it doesn't reurns to prompt. It seems that it hangs in while loop or hangs somewhere else. what does it mean? Regards, Prakash On Tue, May 4, 2010 at 9:08 PM, Stefan Roese wrote: > Hi Prakash, > > On Tuesday 04 May 2010 17:03:40 prakash bedge wrote: > > Shall I need to add sleep() command in the interrupt_init or before it? > > No. What I meant, was that you should try the "sleep" command on the U-Boot > prompt, to check, if the timer is working or not. Check if a "sleep 3" > really > takes 3 seconds to return to the prompt. > > > I am using Samsung M391B2873EH1-CH9 series 1 GB DDR3 and Denali > controller > > is being used for driving DDR3. > > OK. It would be good if you would contribute your Denali code back to > mainline > U-Boot. > > Cheers, > Stefan > > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot hangs after detecting DDR3 RAM and Flash.
On Wednesday 05 May 2010 13:48:05 prakash bedge wrote: > I commented he MSR_EE in interrupt_init function in cpu/ppc4xx/interrupts.c > to run the u-boot and to get u-boot prompt. > > when I executed "sleep 3 " command it doesn't reurns to prompt. It seems > that it hangs in while loop or hangs somewhere else. > what does it mean? That means, that the timer is not running at all. Since you disabled the interrupts in the MSR register. You need to solve the problem with the hanging trap, most likely resulting from the DDR3 setup code. Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] WARNING: adjusting available memory to 30000000
Hi, I am using customized ppc440 based board having 4GB DDR3 memory. While running u-boot I am getting “WARNING: adjusting available memory to 3000” messege. Further debugging I came to know that CONFIG_SYS_LINUX_LOWMEM_MAX_SIZE is set to 0x3000 and my ddr size come to 0x4000 Please let me know is u-boot supports upto 0x3000 or I can modify CONFIG_SYS_LINUX_LOWMEM_MAX_SIZE macro to 0x4000. Regards,Ronny ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Compilation Problem with u-boot-2009.08
I am compiling the u-boot-2009.08.tar.bz2 code for PPC440 based Taishan board. To debug the code i put u-boot in debug mode i.e enable the debug mode by commented out DBGFLAGS= -g -DDEBUG in top level config.mk With this debug flag i am not able to compile the code. Please let me know is there any fix for this ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Help me on finding board similar to NIC card in U-bootloader
Hello, I am having a new NIC card and i have to develop U-boot Loader for that.Can any one help me which board name in U-Boot source code having similar kind of features( PHY, MAC ) for cloning that to my new NIC target card. Thank u. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] WARNING: adjusting available memory to 30000000
I am using customized ppc440 based board having 4GB DDR3 memory sorry by mistake i put DDR3 size = 4GB instead of 1GB. --- On Wed, 5/5/10, Ronny D wrote: From: Ronny D Subject: WARNING: adjusting available memory to 3000 To: "Wolfgang Denk" , "Stefan Roese" Cc: "U-boot" Date: Wednesday, 5 May, 2010, 12:28 PM Hi, I am using customized ppc440 based board having 4GB DDR3 memory. While running u-boot I am getting “WARNING: adjusting available memory to 3000” messege. Further debugging I came to know that CONFIG_SYS_LINUX_LOWMEM_MAX_SIZE is set to 0x3000 and my ddr size come to 0x4000 Please let me know is u-boot supports upto 0x3000 or I can modify CONFIG_SYS_LINUX_LOWMEM_MAX_SIZE macro to 0x4000. Regards,Ronny ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ubifsmount fails due to not initialized list
Quotient Remainder wrote: > Out of interest, how did something like this get away with only causing > an occasional failure? Well, there are some explanations. MMU is normally off and a Null Pointer does not cause an exception in u-boot. If we get a failure, it depends on the architecture we are using. On PowerPC, address 0 is accessible and then we get no failure. In this particular case (ubifsmount), the list is set but not used by the calling function. Because writing to address 0 is allowed, the bug is not noticeable. Different is on arm, where I have found the problem. Because in this case address 0 is not accessible at all, u-boot hangs and it is not possible to avoid to see that we have a problem Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Help me on finding board similar to NIC card in U-bootloader
Hi Hari, On Wednesday, May 5, 2010, Hari Babu wrote: > Hello, > I am having a new NIC card and i have to develop U-boot Loader for that.Can > any one help me which board name in U-Boot source code having similar kind > of features( PHY, MAC ) for cloning that to my new NIC target card. Thank u. > Maybe, but not without knowing anything about your hardware. Regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] remove main CHANGELOG file
Dne St 5. května 2010 08:54:01 Wolfgang Denk napsal(a):
> Dear Kim Phillips,
>
> In message <20100504192544.6506945d.kim.phill...@freescale.com> you wrote:
> > > > It is assumed that this file's only purpose is to serve non-git users
> > > > downloading u-boot project source in the form of a tarball release.
> > > > If that is the case, then the generation of the CHANGELOG file
> > > > should occur at tarball release generation time, and not consume
> > > > duplicate history,
>
> Can you recommend a way how such auto-generation / inclusion would be
> done?
>
> Currently I'm using something like this:
>
> $ V=2010.03
> $ PREFIX=u-boot-${V}
git log > CHANGELOG
> $ git archive --format=tar --prefix=${PREFIX}/ v${V} | \
>
tar -r CHANGELOG or something ?
> > bzip2 -v9 >~/tmp/${PREFIX}.tar.bz2
>
> How could this be made to include a non-git-controlled CHANGELOG?
>
> > > Slowing things down? C'me on.
> >
> > maybe not git grep performance-wise (yet), but on a
> > frequently-occurring search term, when we have to visually sift through
> > and page down through a large number of CHANGELOG hits (that invariably
> > show up first), then yes, I consider that a development-time barrier.
>
> So what about git performance? A "grep foobar CHANGELOG" is
> significantly faster than a "git log --grep=foobar", isn't it?
>
> > > NAK. My position about these files has not changed.
> >
> > Please reconsider: u-boot has no need to be 'special' in this area, and
> > this file's continued existence is a lingering harassment for
> > developers such as myself.
>
> Harassment? Strong words. I am seriously listening to your arguments,
> but so far I feel that there is a lot of emotion in your message but
> only few arguments I can follow.
Yup
>
> I can understand that you see little use in this file, and even that
> occasionally it comes into your way.
>
> On the other hand, I regularly use this file, because it speeds up my
> work.
>
> In addition to the arguments already mentioned here is another reason
> why I would like to keep this file in place: Quite often we have to
> work with copies of the U-Boot source tree that do not contain any
> good information about which version they might have been derived
> from; the CHANGELOG at least gives an idea about the time frame.
>
> How would you try such identification?
>
> Best regards,
>
> Wolfgang Denk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ubifsmount fails due to not initialized list
On Wed, May 5, 2010 at 1:59 PM, Stefano Babic wrote: > Quotient Remainder wrote: > > > Out of interest, how did something like this get away with only causing > > an occasional failure? > > Well, there are some explanations. MMU is normally off and a Null > Pointer does not cause an exception in u-boot. If we get a failure, it > depends on the architecture we are using. On PowerPC, address 0 is > accessible and then we get no failure. In this particular case > (ubifsmount), the list is set but not used by the calling function. > Because writing to address 0 is allowed, the bug is not noticeable. > > Different is on arm, where I have found the problem. Because in this > case address 0 is not accessible at all, u-boot hangs and it is not > possible to avoid to see that we have a problem > > I've been using UBIFS on arm (1136) with the v2009.11 release and it works almost all the time. Sometimes U-Boot fails to mount the UBIFS (1 in 100 boots, maybe), and in these cases I was putting it down to forgetting to do a sync in Linux before rebooting. I wonder if this was the problem all along... > Best regards, > Stefano Babic > > -- > = > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de > = > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] remove main CHANGELOG file
Dear Marek,
In message <201005051551.47704.marek.va...@gmail.com> you wrote:
>
> > Can you recommend a way how such auto-generation / inclusion would be
> > done?
> >
> > Currently I'm using something like this:
> >
> > $ V=2010.03
> > $ PREFIX=u-boot-${V}
>
> git log > CHANGELOG
>
> > $ git archive --format=tar --prefix=${PREFIX}/ v${V} | \
> >
> tar -r CHANGELOG or something ?
Using a plain "CHANGELOG" here a misses the "${PREFIX}/" part, so I
would have to create this directory first [and probably a tmp
directory to put it in first to avoid potential name conflicts], then
create the CHANGELOG file there, then append it to the archive, then
clean everything up.
Is there a more elegant way?
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: w...@denx.de
"Love your country but never trust its government."
- from a hand-painted road sign in central Pennsylvania
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 0/3] Add support for MB86R0x SoCs
This patchset adds support for MB86R0x SoC familiy from Fujitsu, its built in lcd controller and a first board using the MB86R01. Changes since V1 - Used C structs for addressing instead of base + offset - Moved offsets for assmebler code to asm-offsets.h - Moved some dublicated sections of code to functions Matthias Weisser (3): arm: Add support for MB86R0x SoCs video: add support for display controller in MB86R0x SoCs arm: Add support for jadecpu board based on MB86R01 SoC MAINTAINERS |4 + MAKEALL |1 + Makefile|4 + arch/arm/cpu/arm926ejs/mb86r0x/Makefile | 47 ++ arch/arm/cpu/arm926ejs/mb86r0x/reset.c | 40 ++ arch/arm/cpu/arm926ejs/mb86r0x/timer.c | 139 ++ arch/arm/include/asm/arch-mb86r0x/asm-offsets.h | 74 +++ arch/arm/include/asm/arch-mb86r0x/hardware.h| 31 ++ arch/arm/include/asm/arch-mb86r0x/mb86r0x.h | 561 +++ board/syteco/jadecpu/Makefile | 55 +++ board/syteco/jadecpu/config.mk |1 + board/syteco/jadecpu/jadecpu.c | 171 +++ board/syteco/jadecpu/lowlevel_init.S| 266 +++ common/serial.c |6 +- drivers/video/Makefile |1 + drivers/video/mb86r0xgdc.c | 186 include/configs/jadecpu.h | 283 include/serial.h|6 +- tools/Makefile |3 + tools/logos/syteco.bmp | Bin 0 -> 11414 bytes 20 files changed, 1875 insertions(+), 4 deletions(-) create mode 100644 arch/arm/cpu/arm926ejs/mb86r0x/Makefile create mode 100644 arch/arm/cpu/arm926ejs/mb86r0x/reset.c create mode 100644 arch/arm/cpu/arm926ejs/mb86r0x/timer.c create mode 100644 arch/arm/include/asm/arch-mb86r0x/asm-offsets.h create mode 100644 arch/arm/include/asm/arch-mb86r0x/hardware.h create mode 100644 arch/arm/include/asm/arch-mb86r0x/mb86r0x.h create mode 100644 board/syteco/jadecpu/Makefile create mode 100644 board/syteco/jadecpu/config.mk create mode 100644 board/syteco/jadecpu/jadecpu.c create mode 100644 board/syteco/jadecpu/lowlevel_init.S create mode 100644 drivers/video/mb86r0xgdc.c create mode 100644 include/configs/jadecpu.h create mode 100644 tools/logos/syteco.bmp ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 2/3] video: add support for display controller in MB86R0x SoCs
This patch adds support for the display controller in
the MB86R0x SoCs.
Signed-off-by: Matthias Weisser
---
drivers/video/Makefile |1 +
drivers/video/mb86r0xgdc.c | 186
2 files changed, 187 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/mb86r0xgdc.c
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index a5e339a..1a60ec6 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -32,6 +32,7 @@ COBJS-$(CONFIG_S6E63D6) += s6e63d6.o
COBJS-$(CONFIG_VIDEO_AMBA) += amba.o
COBJS-$(CONFIG_VIDEO_CT69000) += ct69000.o
COBJS-$(CONFIG_VIDEO_MB862xx) += mb862xx.o
+COBJS-$(CONFIG_VIDEO_MB86R0xGDC) += mb86r0xgdc.o
COBJS-$(CONFIG_VIDEO_MX3) += mx3fb.o
COBJS-$(CONFIG_VIDEO_SED13806) += sed13806.o
COBJS-$(CONFIG_SED156X) += sed156x.o
diff --git a/drivers/video/mb86r0xgdc.c b/drivers/video/mb86r0xgdc.c
new file mode 100644
index 000..3bdc1db
--- /dev/null
+++ b/drivers/video/mb86r0xgdc.c
@@ -0,0 +1,186 @@
+/*
+ * (C) Copyright 2010
+ * Matthias Weisser
+ *
+ * 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
+ */
+
+/*
+ * mb86r0xgdc.c - Graphic interface for Fujitsu MB86R0x integrated graphic
+ * controller.
+ */
+
+#include
+
+#include
+#include
+#include
+#include
+#include "videomodes.h"
+
+/*
+ * 4MB (at the end of system RAM)
+ */
+#define VIDEO_MEM_SIZE 0x40
+
+#define FB_SYNC_CLK_INV(1<<16) /* pixel clock inverted */
+
+/*
+ * Graphic Device
+ */
+static GraphicDevice mb86r0x;
+
+static void dsp_init(struct mb86r0x_gdc_dsp *dsp, char *modestr,
+ u32 *videomem)
+{
+ struct ctfb_res_modes var_mode;
+ u32 dcm1, dcm2, dcm3;
+ u16 htp, hdp, hdb, hsp, vtr, vsp, vdp;
+ u8 hsw, vsw;
+ u32 l2m, l2em, l2oa0, l2da0, l2oa1, l2da1;
+ u16 l2dx, l2dy, l2wx, l2wy, l2ww, l2wh;
+ unsigned long div;
+ int bpp;
+ u32 i;
+
+ bpp = video_get_params(&var_mode, modestr);
+
+ if (bpp == 0) {
+ var_mode.xres = 640;
+ var_mode.yres = 480;
+ var_mode.pixclock = 39721; /* 25MHz */
+ var_mode.left_margin = 48;
+ var_mode.right_margin = 16;
+ var_mode.upper_margin = 33;
+ var_mode.lower_margin = 10;
+ var_mode.hsync_len = 96;
+ var_mode.vsync_len = 2;
+ var_mode.sync = 0;
+ var_mode.vmode = 0;
+ bpp = 15;
+ }
+
+ /* Fill memory with white */
+ for (i = 0; i < var_mode.xres * var_mode.yres / 2; i++)
+ *videomem++ = 0x;
+
+ mb86r0x.winSizeX = var_mode.xres;
+ mb86r0x.winSizeY = var_mode.yres;
+
+ /* LCD base clock is ~ 660MHZ. We do calculations in kHz */
+ div = 66 / (10L / var_mode.pixclock);
+ if (div > 64)
+ div = 64;
+ if (0 == div)
+ div = 1;
+
+ dcm1 = (div - 1) << 8;
+ dcm2 = 0x;
+ if (var_mode.sync & FB_SYNC_CLK_INV)
+ dcm3 = 0x0100;
+ else
+ dcm3 = 0x;
+
+ htp = var_mode.left_margin + var_mode.xres +
+ var_mode.hsync_len + var_mode.right_margin;
+ hdp = var_mode.xres;
+ hdb = var_mode.xres;
+ hsp = var_mode.xres + var_mode.right_margin;
+ hsw = var_mode.hsync_len;
+
+ vsw = var_mode.vsync_len;
+ vtr = var_mode.upper_margin + var_mode.yres +
+ var_mode.vsync_len + var_mode.lower_margin;
+ vsp = var_mode.yres + var_mode.lower_margin;
+ vdp = var_mode.yres;
+
+ l2m = ((var_mode.yres - 1) << (0)) |
+ (((var_mode.xres * 2) / 64) << (16)) |
+ ((1) << (31));
+
+ l2em = (1 << 0) | (1 << 1);
+
+ l2oa0 = mb86r0x.frameAdrs;
+ l2da0 = mb86r0x.frameAdrs;
+ l2oa1 = mb86r0x.frameAdrs;
+ l2da1 = mb86r0x.frameAdrs;
+ l2dx = 0;
+ l2dy = 0;
+ l2wx = 0;
+ l2wy = 0;
+ l2ww = var_mode.xres;
+ l2wh = var_mode.yres - 1;
+
+ writel(dcm1, &dsp->dcm1);
+ writel(dcm2, &dsp->dcm2);
+ writel(dcm3, &dsp->dcm3);
+
+ writew(htp, &dsp->htp);
+
[U-Boot] [PATCH V2 1/3] arm: Add support for MB86R0x SoCs
This patch adds support for MB86R0x SoCs from Fujitsu
Signed-off-by: Matthias Weisser
---
arch/arm/cpu/arm926ejs/mb86r0x/Makefile | 47 ++
arch/arm/cpu/arm926ejs/mb86r0x/reset.c | 40 ++
arch/arm/cpu/arm926ejs/mb86r0x/timer.c | 139 ++
arch/arm/include/asm/arch-mb86r0x/asm-offsets.h | 74 +++
arch/arm/include/asm/arch-mb86r0x/hardware.h| 31 ++
arch/arm/include/asm/arch-mb86r0x/mb86r0x.h | 561 +++
common/serial.c |6 +-
include/serial.h|6 +-
8 files changed, 900 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/cpu/arm926ejs/mb86r0x/Makefile
create mode 100644 arch/arm/cpu/arm926ejs/mb86r0x/reset.c
create mode 100644 arch/arm/cpu/arm926ejs/mb86r0x/timer.c
create mode 100644 arch/arm/include/asm/arch-mb86r0x/asm-offsets.h
create mode 100644 arch/arm/include/asm/arch-mb86r0x/hardware.h
create mode 100644 arch/arm/include/asm/arch-mb86r0x/mb86r0x.h
diff --git a/arch/arm/cpu/arm926ejs/mb86r0x/Makefile
b/arch/arm/cpu/arm926ejs/mb86r0x/Makefile
new file mode 100644
index 000..360f046
--- /dev/null
+++ b/arch/arm/cpu/arm926ejs/mb86r0x/Makefile
@@ -0,0 +1,47 @@
+#
+# (C) Copyright 2000-2006
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# 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$(SOC).a
+
+COBJS = timer.o reset.o
+SOBJS =
+
+SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS))
+START := $(addprefix $(obj),$(START))
+
+all: $(obj).depend $(LIB)
+
+$(LIB):$(OBJS)
+ $(AR) $(ARFLAGS) $@ $(OBJS)
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/arch/arm/cpu/arm926ejs/mb86r0x/reset.c
b/arch/arm/cpu/arm926ejs/mb86r0x/reset.c
new file mode 100644
index 000..e7f0f67
--- /dev/null
+++ b/arch/arm/cpu/arm926ejs/mb86r0x/reset.c
@@ -0,0 +1,40 @@
+/*
+ * (C) Copyright 2010
+ * Matthias Weisser
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+
+/*
+ * Reset the cpu by setting software reset request bit
+ */
+void reset_cpu(ulong ignored)
+{
+ struct mb86r0x_crg * crg = (struct mb86r0x_crg *)
+ MB86R0x_CRG_BASE;
+
+ writel(MB86R0x_CRSR_SWRSTREQ, &crg->crsr);
+ while (1)
+ /* NOP */;
+ /* Never reached */
+}
diff --git a/arch/arm/cpu/arm926ejs/mb86r0x/timer.c
b/arch/arm/cpu/arm926ejs/mb86r0x/timer.c
new file mode 100644
index 000..eb6c47c
--- /dev/null
+++ b/arch/arm/cpu/arm926ejs/mb86r0x/timer.c
@@ -0,0 +1,139 @@
+/*
+ * (C) Copyright 2007-2008
+ * Stelian Pop
+ * Lead Tech Design
+ *
+ * (C) Copyright 2010
+ * Matthias Weisser, Graf-Syteco
+ *
+ * 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
+ * ME
[U-Boot] [PATCH V2 3/3] arm: Add support for jadecpu board based on MB86R01 SoC
This patch adds support for the jadecpu board using the MB86R01 'Jade' SoC from Fujitsu. Signed-off-by: Matthias Weisser --- MAINTAINERS |4 + MAKEALL |1 + Makefile |4 + board/syteco/jadecpu/Makefile| 55 +++ board/syteco/jadecpu/config.mk |1 + board/syteco/jadecpu/jadecpu.c | 171 board/syteco/jadecpu/lowlevel_init.S | 266 include/configs/jadecpu.h| 283 ++ tools/Makefile |3 + tools/logos/syteco.bmp | Bin 0 -> 11414 bytes 10 files changed, 788 insertions(+), 0 deletions(-) create mode 100644 board/syteco/jadecpu/Makefile create mode 100644 board/syteco/jadecpu/config.mk create mode 100644 board/syteco/jadecpu/jadecpu.c create mode 100644 board/syteco/jadecpu/lowlevel_init.S create mode 100644 include/configs/jadecpu.h create mode 100644 tools/logos/syteco.bmp diff --git a/MAINTAINERS b/MAINTAINERS index 04c8730..ac0ed62 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -776,6 +776,10 @@ Prafulla Wadaskar rd6281a ARM926EJS (Kirkwood SoC) sheevaplug ARM926EJS (Kirkwood SoC) +Matthias Weisser + + jadecpu ARM926EJS (MB86R01 SoC) + Richard Woodruff omap2420h4 ARM1136EJS diff --git a/MAKEALL b/MAKEALL index fb1f7a3..5ee9678 100755 --- a/MAKEALL +++ b/MAKEALL @@ -561,6 +561,7 @@ LIST_ARM9=" \ edb9315 \ edb9315a\ imx27lite \ + jadecpu \ lpd7a400\ mv88f6281gtw_ge \ mx1ads \ diff --git a/Makefile b/Makefile index 0381c81..1d7627e 100644 --- a/Makefile +++ b/Makefile @@ -203,6 +203,7 @@ LIBS += net/libnet.a LIBS += disk/libdisk.a LIBS += drivers/bios_emulator/libatibiosemu.a LIBS += drivers/block/libblock.a +LIBS += drivers/can/libcan.a LIBS += drivers/dma/libdma.a LIBS += drivers/fpga/libfpga.a LIBS += drivers/gpio/libgpio.a @@ -2834,6 +2835,9 @@ CPU9260_config: unconfig @echo "#define CONFIG_$(@:_config=) 1" >$(obj)include/config.h @$(MKCONFIG) -a cpu9260 arm arm926ejs cpu9260 eukrea at91 +jadecpu_config : unconfig + @$(MKCONFIG) $(@:_config=) arm arm926ejs jadecpu syteco mb86r0x + meesc_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm926ejs meesc esd at91 diff --git a/board/syteco/jadecpu/Makefile b/board/syteco/jadecpu/Makefile new file mode 100644 index 000..87d2234 --- /dev/null +++ b/board/syteco/jadecpu/Makefile @@ -0,0 +1,55 @@ +# +# (C) Copyright 2003-2008 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# (C) Copyright 2008 +# Stelian Pop +# Lead Tech Design +# +# 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+= jadecpu.o +SOBJS := lowlevel_init.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/syteco/jadecpu/config.mk b/board/syteco/jadecpu/config.mk new file mode 100644 index 000..c661f0b --- /dev/null +++ b/board/syteco/jadecpu/config.mk @@ -0,0 +1 @@ +TEXT_BASE = 0x4600 diff --git a/board/syteco/jadecpu/jadecpu.c b/board/syteco/jadecpu/jadecpu.c new file mode 100644 index 000..a090fed --- /dev/null +++ b/board/syteco/jadecpu/jadecpu.c @@ -0,0 +1,171 @@ +/* + * (c) 2010 Graf-Syteco, Matthias Weisser + * + * + * (C) Copyright 2007, mycable GmbH + * Carsten Schneider , Alexander Bigga + * + * This program is free software; you can redistribute it and/o
Re: [U-Boot] [PATCH 2/2] remove main CHANGELOG file
On Wed, May 5, 2010 at 9:17 AM, Wolfgang Denk wrote:
> Using a plain "CHANGELOG" here a misses the "${PREFIX}/" part, so I
> would have to create this directory first [and probably a tmp
> directory to put it in first to avoid potential name conflicts], then
> create the CHANGELOG file there, then append it to the archive, then
> clean everything up.
I can't say if there is a more elegant way of doing this, but if there
isn't, can't you automate the above steps with a script?
I agree with Kim. Is there anyone besides you who uses CHANGELOG? If
not, then maybe it should be deleted from the repository. I don't see
why you can't run a script to regenerate it when you need it.
--
Timur Tabi
Linux kernel developer at Freescale
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] remove main CHANGELOG file
Dear Timur Tabi, In message you wrote: > > I agree with Kim. Is there anyone besides you who uses CHANGELOG? If > not, then maybe it should be deleted from the repository. I don't see > why you can't run a script to regenerate it when you need it. The thing is that I use it all the time. grepping there is often more efficient for me then using git log --grep. Does it hurt you? 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: w...@denx.de I wish I had a bronze torc for every user who didn't read the manual. - Terry Pratchett, _The Light Fantastic_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Fix for a build ?
Hi Igor Luri, > We solve this problem building U-Boot and failing projects passing "-j > 1" argument to Make (without running simultaneous jobs), and the rest of > software with "-j 9". > Your suggestion solved the problem for us, thank you very much. > Hope this helps. It did :) again thank you > > Peace. Have a wonderful day Sylvain ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] remove main CHANGELOG file
Hi Wolfgang,
> In message
> you wrote:
> >
> > I agree with Kim. Is there anyone besides you who uses CHANGELOG? If
> > not, then maybe it should be deleted from the repository. I don't see
> > why you can't run a script to regenerate it when you need it.
>
> The thing is that I use it all the time. grepping there is often more
> efficient for me then using git log --grep.
Could you describe what you use CHANGELOG for? I often look at logs,
but 99% of the time its a log of a specific file or directory to trace a
bug, see why feature X was added, etc. I rarely look at the
repositories entire log, and if I do, I use 'git log'. Although 'git
log' takes longer, its guaranteed to be accurate, unlike CHANGELOG which
may be slightly out of date.
If you do prefer the speed of looking at a CHANGELOG file, its easy to
generate one when you require it.
> Does it hurt you?
'hurt' is a strong word, but it certainly annoys me too. Eg:
- Every time someone greps they have to visually ignore the CHANGELOG
file hits, or alternately make a grep wrapper script specific to u-boot
that strips out CHANGELOG hits.
- Its a duplication of data that's already stored in the repository
history. Who likes duplicated data?
- For any change that is automated via a script/grep/sed/etc one needs
to filter out the CHANGELOG files.
I don't know if this is much cleaner, but:
$ V=2010.03
$ PREFIX=u-boot-${V}
$ git archive --format=tar --prefix=${PREFIX}/ v${V} | tar -xC ~/tmp
$ git log > ~/tmp/${PREFIX}/CHANGELOG
$ tar -cj -f ~/tmp/${PREFIX}.tar.bz2 -C ~/tmp/ ${PREFIX}
$ rm -fr ~/tmp/${PREFIX}
We could also follow Linux's lead and upload the CHANGELOG as a separate
file from the source. eg there would be a CHANGELOG-{V} for each
released U-Boot version detailing only what changed since the last
release (www.kernel.org/pub/linux/kernel/v2.6/), or alternatively one
mega-CHANGELOG like we're doing now if people prefer.
Best,
Peter
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Mystery Shopper Needed Urgently(Respond Asap)
MYSTERY SHOPPER SERVICES 95 Crease Rd. Budd Lake, NJ 07828 Hello Applicant, Mystery Shopper Guide measuring the quality of retail services. We systematically gather information and analyze the data of our customers, their competitors and the market. We send mystery shoppers to 'act' as shoppers or to legitimately shop in return for some combination of cash, store credit, purchase discounts, or the goods or services purchased. Instructions to mystery shoppers can include a script of behavior, questions to ask, complaints to give, purchases to make, and measures to record, such the amount of time it takes to receive attention from an employee or receive a service, or the responses given to questions. With our research, companies can learn more about their retail operations. Why you should choose Mystery Shopper Guide? Mystery Shopper Guide is a mystery shopper company that provides hands-on evaluation with the convenience of online communications, reporting and feedback. We service clients desiring an easy and cost-effective way of improving customer satisfaction and productivity. We use only the most talented mystery shoppers in the business to analyze your automotive facility, restaurant, hotel, pub, bowling alley & more. Our team of professional mystery shoppers covers the entire US and the major cities in Canada. COMPANY PROFILE Mystery Shopper Guide offers customizable mystery shopping services for retail, hospitality and service organizations. Through its personal and consultative approach, Mystery Shopper Guide gives companies the information they need to understand their customer? perception of their business. Using web-based technologies and processes, managers are provided with third party data for use in improving staff performance and increasing customer loyalty and satisfaction. WHAT TO DO We are a company that conduct surveys and evaluate other companies. We get hired to go to other peoples companies and act like customers in order to know how the staffs are handling their services in relation to their customers. Once we have a contract you would be directed to the company or outlet and you would be given the funds you need to do the job (either purchase things or require services), after which you would write a comment on the staffs activities and give a detailed record of your experience. Examples of details you would forward to us are: 1) How long it took you to get services. 2) Smartness of the attendant 3)Customer service professionalism 4)Sometimes you might be required to upset the attendant, to see how they react to clients when they get tensed. And we turn the information over to the company executives and they would carry out their own duties in improving there services.We will pay 10% on every evaluation carried out. Give us a try with no obligation. Let us show you how our services can benefit you. If you are interested in becoming a Mystery Shopper for our company, then just fill out the below details. Full name: Address : (P.O BOX NOT ACCEPTED ) City: State: Zip Code : Nationality : Sex : Marital Status : Age : (18 and Above) Home phone number : Cell phone number : Email Address: ***Send your response to davidkh...@i12.com *** Getting back to us with the information asked above means you are ready to work and you will start in less than 7 days from today which we will contact you via e-mail. Send your response ASAP to davidkh...@i12.com Warmest Regards. Dr.Donald Anderson Evaluation Hiring Team(EHT) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] remove main CHANGELOG file
Dear Peter Tyser,
In message <1273075406.2451.4225.ca...@localhost.localdomain> you wrote:
>
> Could you describe what you use CHANGELOG for? I often look at logs,
> but 99% of the time its a log of a specific file or directory to trace a
> bug, see why feature X was added, etc. I rarely look at the
> repositories entire log, and if I do, I use 'git log'. Although 'git
> log' takes longer, its guaranteed to be accurate, unlike CHANGELOG which
> may be slightly out of date.
Most frequently I use it in combination with some form of grep command
(grep, agrep etc.); sometimes I use it in vi/view for manual searching
/ reading.
Here are a few reasons where I prefer accessing the CHANGELOG over
running "git log --grep":
1) it's faster:
-> time grep foobar CHANGELOG
real0m0.005s
user0m0.004s
sys 0m0.001s
-> time git log --grep=foobar >/dev/null
real0m0.240s
user0m0.219s
sys 0m0.021s
2) it's more efficient:
-> strace -f grep foobar CHANGELOG 2>&1 >/dev/null | wc -l
143
-> strace -f git log --grep=foobar 2>&1 >/dev/null | wc -l
2494
3) it delivers only the lines I cactually search for, while "git log
--grep" always spills out the whole commit message:
-> grep MPC512x CHANGELOG | wc -l
24
-> git log --grep=MPC512x | wc -l
272
4) I can use arbitrary grep options. I am not aware of a git
equivalent to, say:
-> grep -C2 --color string CHANGELOG
5) I can use other tools to process the messages, like agrep for fuzzy
searching; I frequently use this when checking if a specific patch
has been applied - too many times a plain text search does not work
because the committer manually edited the commit message to fix
typos etc. I am not aware of a git equivalent to, say:
-> agrep -2 -i string CHANGELOG
This is probably my most frequently used command
> If you do prefer the speed of looking at a CHANGELOG file, its easy to
> generate one when you require it.
Yes, I know. But I also want it available to those who don't use git,
so it should to be included in the release tarball, and in the
auto-generated tarballs when using the "snapshot" links on the web
interface; for example try:
-> wget -O u-boot.tgz
'http://git.denx.de/?p=u-boot.git;a=snapshot;sf=tgz'
> > Does it hurt you?
>
> 'hurt' is a strong word, but it certainly annoys me too. Eg:
> - Every time someone greps they have to visually ignore the CHANGELOG
> file hits, or alternately make a grep wrapper script specific to u-boot
> that strips out CHANGELOG hits.
Strange. If I ever run into such a problem then so infrequently that
I don't notice it. I guess this is because I usually only grep in
specific file types (like "*.[Sch]" or so).
> - Its a duplication of data that's already stored in the repository
> history. Who likes duplicated data?
In the strict sense, all the checked out files are duplicated data.
> - For any change that is automated via a script/grep/sed/etc one needs
> to filter out the CHANGELOG files.
You probably need to exclude a number of other files as well?
> We could also follow Linux's lead and upload the CHANGELOG as a separate
> file from the source. eg there would be a CHANGELOG-{V} for each
> released U-Boot version detailing only what changed since the last
> release (www.kernel.org/pub/linux/kernel/v2.6/), or alternatively one
> mega-CHANGELOG like we're doing now if people prefer.
I would like to keep the CHANGELOG as part of tarballs, including
auto-generated ones.
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: w...@denx.de
Speculation is always more interesting than facts.
- Terry Pratchett, _Making_Money_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Endless loop in cmd_log.c?
I am trying to implement CONFIG_LOGBUFFER and CONFIG_CMD_LOG on our ARM systems and I seem to have run into an endless loop. With loglevel=5 so we still see our console output, the printf at the end of logbuff_printk appears to create an endless loop. I had to replace that line with serial_puts(msg); Have I missed some other solution or do the systems that use this never set logbuffer higher than default_message_loglevel? DaR ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] remove main CHANGELOG file
On 05/05/2010 02:05 PM, Wolfgang Denk wrote: > Dear Peter Tyser, > > In message<1273075406.2451.4225.ca...@localhost.localdomain> you wrote: >> >> Could you describe what you use CHANGELOG for? I often look at logs, >> but 99% of the time its a log of a specific file or directory to trace a >> bug, see why feature X was added, etc. I rarely look at the >> repositories entire log, and if I do, I use 'git log'. Although 'git >> log' takes longer, its guaranteed to be accurate, unlike CHANGELOG which >> may be slightly out of date. > > Most frequently I use it in combination with some form of grep command > (grep, agrep etc.); sometimes I use it in vi/view for manual searching > / reading. > > Here are a few reasons where I prefer accessing the CHANGELOG over > running "git log --grep": > > 1) it's faster: > > -> time grep foobar CHANGELOG > > real0m0.005s > user0m0.004s > sys 0m0.001s > > -> time git log --grep=foobar>/dev/null > > real0m0.240s > user0m0.219s > sys 0m0.021s Surely the extra quarter second is not too significant compared to the time it takes to formulate the query and examine the results. > 2) it's more efficient: > > -> strace -f grep foobar CHANGELOG 2>&1>/dev/null | wc -l > 143 > -> strace -f git log --grep=foobar 2>&1>/dev/null | wc -l > 2494 It also requires that a cache be maintained just for this purpose. > 3) it delivers only the lines I cactually search for, while "git log > --grep" always spills out the whole commit message: > > -> grep MPC512x CHANGELOG | wc -l > 24 > -> git log --grep=MPC512x | wc -l > 272 $ git log | grep MPC512x | wc -l 24 Likewise for grep options and alternate tools. Or if you really want, you could do this locally, and put CHANGELOG in .gitignore: $ time git log > CHANGELOG real0m0.453s user0m0.350s sys 0m0.050s You could even have a cron job keep it up to date. :-) -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6 v3] spi_flash: support old STMicro parts with RES
Dear Mike Frysinger, In message <201005050321.49140.vap...@gentoo.org> you wrote: > > ive merged this into my sf branch and will push out next merge window if > Wolfgang doesnt pick it up before that Just let me know what you (and Thomas) prefer, and what exactly (which patch[es] from this series) the "it" is that should be picked up (or not). 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: w...@denx.de Gods don't like people not doing much work. People who aren't busy all the time might start to _think_. - Terry Pratchett, _Small Gods_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND:PATCH-V4] OMAP3EVM: Added NAND support
Dear hvaib...@ti.com, In message <1272034546-26041-2-git-send-email-hvaib...@ti.com> you wrote: > > diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h > index 0d99f7d..1d31731 100644 > --- a/include/configs/omap3_evm.h > +++ b/include/configs/omap3_evm.h > @@ -151,7 +151,8 @@ > > #define CONFIG_CMD_I2C /* I2C serial bus support */ > #define CONFIG_CMD_MMC /* MMC support */ > -#define CONFIG_CMD_ONENAND /* ONENAND support */ > +#undef CONFIG_CMD_ONENAND/* ONENAND support */ Please do not #undef what is not #define'd anyway. 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: w...@denx.de What is tolerance? -- it is the consequence of humanity. We are all formed of frailty and error; let us pardon reciprocally each other's folly -- that is the first law of nature. - Voltaire ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH-V2 2/4] omap3: Consolidate SDRC related operations
Dear hvaib...@ti.com,
In message <1272034546-26041-4-git-send-email-hvaib...@ti.com> you wrote:
> From: Vaibhav Hiremath
>
> Consolidated SDRC related functions into one file - sdrc.c
>
> And also replaced sdrc_init with generic memory init
> function (mem_init), this generalization of omap memory setup
> is necessary to support the new emif4 interface introduced in AM3517.
>
> Signed-off-by: Vaibhav Hiremath
> Signed-off-by: Sanjeev Premi
> diff --git a/arch/arm/cpu/arm_cortexa8/omap3/Makefile
> b/arch/arm/cpu/arm_cortexa8/omap3/Makefile
> index 136b163..8cc7802 100644
> --- a/arch/arm/cpu/arm_cortexa8/omap3/Makefile
> +++ b/arch/arm/cpu/arm_cortexa8/omap3/Makefile
> @@ -33,6 +33,9 @@ COBJS += board.o
> COBJS+= clock.o
> COBJS+= gpio.o
> COBJS+= mem.o
> +ifdefCONFIG_SDRC
> +COBJS+= sdrc.o
> +endif
Please don't use 'ifdef" here; instead, use `COBJS-$(CONFIG_SDRC)'
> diff --git a/arch/arm/include/asm/arch-omap3/cpu.h
> b/arch/arm/include/asm/arch-omap3/cpu.h
> index aa8de32..a49af10 100644
> --- a/arch/arm/include/asm/arch-omap3/cpu.h
> +++ b/arch/arm/include/asm/arch-omap3/cpu.h
> @@ -183,6 +183,7 @@ struct sms {
> /* SDRC */
> #ifndef __KERNEL_STRICT_NAMES
> #ifndef __ASSEMBLY__
> +#if defined(CONFIG_SDRC)
> struct sdrc_cs {
> u32 mcfg; /* 0x80 || 0xB0 */
> u32 mr; /* 0x84 || 0xB4 */
> @@ -215,6 +216,8 @@ struct sdrc {
> u8 res4[0xC];
> struct sdrc_cs cs[2]; /* 0x80 || 0xB0 */
> };
> +
> +#endif /* CONFIG_SDRC */
I don't like such a #ifdef here - it is absolutely necessary? Why?
> diff --git a/arch/arm/include/asm/arch-omap3/sys_proto.h
> b/arch/arm/include/asm/arch-omap3/sys_proto.h
> index 34bd515..34e4e0d 100644
> --- a/arch/arm/include/asm/arch-omap3/sys_proto.h
> +++ b/arch/arm/include/asm/arch-omap3/sys_proto.h
> @@ -31,8 +31,10 @@ void prcm_init(void);
> void per_clocks_enable(void);
>
> void memif_init(void);
> +#if defined(CONFIG_SDRC)
> void sdrc_init(void);
> void do_sdrc_init(u32, u32);
> +#endif
Ditto - please drop this #ifdef.
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: w...@denx.de
People seldom know what they want until you give them what they ask
for.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH-V2 3/4] AM35x: Add support for AM3517EVM
Dear hvaib...@ti.com, In message <1272034546-26041-5-git-send-email-hvaib...@ti.com> you wrote: > From: Vaibhav Hiremath > > This patch adds basic support for the AM3517EVM. > It includes: > - Board int file (.c and .h) > - Default configuration file > - Updates for Makefile > > Signed-off-by: Vaibhav Hiremath > Signed-off-by: Sanjeev Premi > --- > Makefile |3 + > arch/arm/include/asm/arch-omap3/mux.h | 36 +++ > board/logicpd/am3517evm/Makefile | 47 > board/logicpd/am3517evm/am3517evm.c | 76 ++ > board/logicpd/am3517evm/am3517evm.h | 405 > + > board/logicpd/am3517evm/config.mk | 30 +++ > include/configs/am3517_evm.h | 297 > 7 files changed, 894 insertions(+), 0 deletions(-) > create mode 100644 board/logicpd/am3517evm/Makefile > create mode 100644 board/logicpd/am3517evm/am3517evm.c > create mode 100644 board/logicpd/am3517evm/am3517evm.h > create mode 100644 board/logicpd/am3517evm/config.mk > create mode 100644 include/configs/am3517_evm.h Entries to MAKEALL and MAINTAINERS missing. > diff --git a/Makefile b/Makefile > index 34f10ce..487ae73 100644 > --- a/Makefile > +++ b/Makefile > @@ -3169,6 +3169,9 @@ omap3_zoom1_config :unconfig > omap3_zoom2_config : unconfig > @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 zoom2 logicpd omap3 > > +am3517_evm_config : unconfig > + @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 am3517evm logicpd omap3 > + > smdkc100_config: unconfig > @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 smdkc100 samsung s5pc1xx Please keep list sorted. > diff --git a/arch/arm/include/asm/arch-omap3/mux.h > b/arch/arm/include/asm/arch-omap3/mux.h > index 0c01c73..8ea47b6 100644 > --- a/arch/arm/include/asm/arch-omap3/mux.h > +++ b/arch/arm/include/asm/arch-omap3/mux.h > @@ -283,6 +283,7 @@ > /*Control and debug */ > #define CONTROL_PADCONF_SYS_32K 0x0A04 > #define CONTROL_PADCONF_SYS_CLKREQ 0x0A06 > +#define CONTROL_PADCONF_SYS_NRESWARM 0x0A08 > #define CONTROL_PADCONF_SYS_NIRQ 0x01E0 > #define CONTROL_PADCONF_SYS_BOOT00x0A0A > #define CONTROL_PADCONF_SYS_BOOT10x0A0C CONTROL_PADCONF_SYS_NIRQ looks out of place here. And all this asks to be converted into a proper C struct. > diff --git a/board/logicpd/am3517evm/Makefile > b/board/logicpd/am3517evm/Makefile > new file mode 100644 > index 000..3c71fef > --- /dev/null > +++ b/board/logicpd/am3517evm/Makefile ... > +include $(SRCTREE)/rules.mk > + > +sinclude $(obj).depend > + Don't add trailing empty lines. [Please check & fix globally.] 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: w...@denx.de Any sufficiently advanced technology is indistinguishable from magic. Clarke's Third Law - _Profiles of the Future_ (1962; rev. 1973) ``Hazards of Prophecy: The Failure of Imagination'' ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH-V2 4/4] AM35x: Add support for EMIF4
Dear hvaib...@ti.com, In message <1272034546-26041-6-git-send-email-hvaib...@ti.com> you wrote: > From: Vaibhav Hiremath > > This patch adds support for the EMIF4 interface > available in the AM35x processors. > > Signed-off-by: Vaibhav Hiremath > Signed-off-by: Sanjeev Premi > --- > arch/arm/cpu/arm_cortexa8/omap3/Makefile|3 + > arch/arm/cpu/arm_cortexa8/omap3/emif4.c | 168 > +++ > arch/arm/include/asm/arch-omap3/cpu.h | 24 > arch/arm/include/asm/arch-omap3/emif4.h | 79 + > arch/arm/include/asm/arch-omap3/sys_proto.h |3 + > 5 files changed, 277 insertions(+), 0 deletions(-) > create mode 100644 arch/arm/cpu/arm_cortexa8/omap3/emif4.c > create mode 100644 arch/arm/include/asm/arch-omap3/emif4.h > > diff --git a/arch/arm/cpu/arm_cortexa8/omap3/Makefile > b/arch/arm/cpu/arm_cortexa8/omap3/Makefile > index 8cc7802..0a23fa5 100644 > --- a/arch/arm/cpu/arm_cortexa8/omap3/Makefile > +++ b/arch/arm/cpu/arm_cortexa8/omap3/Makefile > @@ -36,6 +36,9 @@ COBJS += mem.o > ifdefCONFIG_SDRC > COBJS+= sdrc.o > endif > +ifdefCONFIG_EMIF4 > +COBJS+= emif4.o > +endif Don't use ifdef, use COBJS-$(CONFIG_EMIF4) instead. > diff --git a/arch/arm/include/asm/arch-omap3/sys_proto.h > b/arch/arm/include/asm/arch-omap3/sys_proto.h > index 34e4e0d..7b425be 100644 > --- a/arch/arm/include/asm/arch-omap3/sys_proto.h > +++ b/arch/arm/include/asm/arch-omap3/sys_proto.h > @@ -35,6 +35,9 @@ void memif_init(void); > void sdrc_init(void); > void do_sdrc_init(u32, u32); > #endif > +#if defined(CONFIG_EMIF4) > +void emif4_init(void); > +#endif I guess you can omit the #ifdef here, right? 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: w...@denx.de A failure will not appear until a unit has passed final inspection. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] [v2] fix print_size printing fractional gigabyte numbers on 32-bit platforms
Dear Timur Tabi, In message <1271182563-17615-1-git-send-email-ti...@freescale.com> you wrote: > In print_size(), the math that calculates the fractional remainder of a number > used the same integer size as a physical address. However, the "10 *" factor > of the algorithm means that a large number (e.g. 1.5GB) can overflow the > integer if we're running on a 32-bit system. Therefore, we need to > disassociate this function from the size of a physical address. > > Signed-off-by: Timur Tabi > --- > lib/display_options.c |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) Applied, 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: w...@denx.de I am not now, nor have I ever been, a member of the demigodic party. -- Dennis Ritchie ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] [v6] allow print_size to print large numbers on 32-bit systems
Dear Timur Tabi, In message <1271182563-17615-2-git-send-email-ti...@freescale.com> you wrote: > Modify print_size() so that it can accept numbers larger than 4GB on 32-bit > systems. > > Add support for display terabyte, petabyte, and exabyte sizes. Change the > output to use International Electrotechnical Commission binary prefix > standard. > > Signed-off-by: Timur Tabi > --- > include/common.h |2 +- > lib/display_options.c | 31 ++- > 2 files changed, 19 insertions(+), 14 deletions(-) Applied, 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: w...@denx.de The years of peak mental activity are undoubtedly between the ages of four and eighteen. At four we know all the questions, at eighteen all the answers. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] remove main CHANGELOG file
Dear Scott Wood, In message <4be1cace.6040...@freescale.com> you wrote: > > Surely the extra quarter second is not too significant compared to the > time it takes to formulate the query and examine the results. The requests are often generated by some script, and there may be tens of them - enough that the 'git log' versions takes several seconds. > > 2) it's more efficient: > > > > -> strace -f grep foobar CHANGELOG 2>&1>/dev/null | wc -l > > 143 > > -> strace -f git log --grep=foobar 2>&1>/dev/null | wc -l > > 2494 > > It also requires that a cache be maintained just for this purpose. I can't parse that. > You could even have a cron job keep it up to date. :-) Agreed. There are many, many possibilities. 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: w...@denx.de Perl itself is usually pretty good about telling you what you shouldn't do. :-) - Larry Wall in <11...@jpl-devvax.jpl.nasa.gov> ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] remove main CHANGELOG file
Hi Wolfgang, > > Could you describe what you use CHANGELOG for? I often look at logs, > > but 99% of the time its a log of a specific file or directory to trace a > > bug, see why feature X was added, etc. I rarely look at the > > repositories entire log, and if I do, I use 'git log'. Although 'git > > log' takes longer, its guaranteed to be accurate, unlike CHANGELOG which > > may be slightly out of date. > > Most frequently I use it in combination with some form of grep command > (grep, agrep etc.); sometimes I use it in vi/view for manual searching > / reading. I still don't grasp what the common use of looking at U-Boot's entire changelog is. What are some common tasks that require grepping U-Boot's entire changelog? Are these tasks performed frequently enough that the extra <1 second 'git log' requires is bothersome? > 3) it delivers only the lines I cactually search for, while "git log > 4) I can use arbitrary grep options. I am not aware of a git > 5) I can use other tools to process the messages, like agrep for fuzzy As Scott mentioned, these can be solved via 'git grep | '. > > If you do prefer the speed of looking at a CHANGELOG file, its easy to > > generate one when you require it. > > Yes, I know. But I also want it available to those who don't use git, > so it should to be included in the release tarball, and in the > auto-generated tarballs when using the "snapshot" links on the web > interface; for example try: > > -> wget -O u-boot.tgz > 'http://git.denx.de/?p=u-boot.git;a=snapshot;sf=tgz' For snapshots, the CHANGELOG file is going to be out of date though. It'll only list the changes that occurred up to the previous release. This seems worse than not having a CHANGELOG at all as its actively misleading people as to what changes their source code has. > > - For any change that is automated via a script/grep/sed/etc one needs > > to filter out the CHANGELOG files. > > You probably need to exclude a number of other files as well? I think in general you'd want to update all files other than CHANGELOG. As a concrete example, the following is a snippet from a script used for the recent directory reorganization: git grep lib_$ARCH | grep -v CHANGELOG | sed s/:.*$// | uniq | xargs perl -pi -e "s/lib_$ARCH/arch\/$ARCH\/lib/" I'll quit whining, just wanted to give my +1 for removing the changelog. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] remove main CHANGELOG file
On Wed, 5 May 2010 08:54:01 +0200
Wolfgang Denk wrote:
> Dear Kim Phillips,
>
> In message <20100504192544.6506945d.kim.phill...@freescale.com> you wrote:
> >
> > > > It is assumed that this file's only purpose is to serve non-git users
> > > > downloading u-boot project source in the form of a tarball release. If
> > > > that is the case, then the generation of the CHANGELOG file should occur
> > > > at tarball release generation time, and not consume duplicate history,
>
> Can you recommend a way how such auto-generation / inclusion would be
> done?
>
> Currently I'm using something like this:
>
> $ V=2010.03
> $ PREFIX=u-boot-${V}
> $ git archive --format=tar --prefix=${PREFIX}/ v${V} | \
> > bzip2 -v9 >~/tmp/${PREFIX}.tar.bz2
>
> How could this be made to include a non-git-controlled CHANGELOG?
(see below)
> > > Slowing things down? C'me on.
> >
> > maybe not git grep performance-wise (yet), but on a
> > frequently-occurring search term, when we have to visually sift through
> > and page down through a large number of CHANGELOG hits (that invariably
> > show up first), then yes, I consider that a development-time barrier.
>
> So what about git performance? A "grep foobar CHANGELOG" is
> significantly faster than a "git log --grep=foobar", isn't it?
true, but I find that git log runs well after it is run once and
everything is loaded in the cache.
Also, if I'm git grepping in the u-boot git tree, I want to grep
the source, not the git log.
> > > NAK. My position about these files has not changed.
> >
> > Please reconsider: u-boot has no need to be 'special' in this area, and
> > this file's continued existence is a lingering harassment for
> > developers such as myself.
>
> Harassment? Strong words. I am seriously listening to your arguments,
> but so far I feel that there is a lot of emotion in your message but
> only few arguments I can follow.
you are right; bad choice of words; I meant something milder - more
along the lines of 'annoyance'.
> In addition to the arguments already mentioned here is another reason
> why I would like to keep this file in place: Quite often we have to
> work with copies of the U-Boot source tree that do not contain any
> good information about which version they might have been derived
> from; the CHANGELOG at least gives an idea about the time frame.
>
> How would you try such identification?
it appears that the granularity of CHANGELOG updates is equal to that
of VERSION, PATCHLEVEL, and EXTRAVERSION assignments in the root
Makefile; so presumably one can refer to those instead.
For exact per-export granularity, one can do something like this:
cd u-boot
echo '$Format:%H$' > snapshot.commit
git add snapshot.commit && git commit -m 'add snapshot.commit file'
echo 'snapshot.commit' > .git/info/attributes
git archive --format=tar --prefix=${PREFIX}/ ...
...the resultant tarball's snapshot.commit file will contain the value
of the sha id representing commit .
for more info, see the gitattributes manpage and the list of
placeholders in the PRETTY FORMATS section of the git log manpage.
Kim
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] remove main CHANGELOG file
On Wed, 5 May 2010 16:06:07 -0500 Kim Phillips wrote: > echo 'snapshot.commit' > .git/info/attributes make that: echo 'snapshot.commit export-subst' > .git/info/attributes Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM1136: Fix cache_flush() error and correct cpu_init_crit() comments
The ARM1136 cache_flush() function uses the "mcr p15, 0, rn, c7, c7, 0"
instruction which means "Invalidate Both Caches" when in fact the intent
is to "Clean and Invalidate Entire Data Cache". So change the ARM1136
cache_flush() function to use the "mcr p15, 0, rn, c7, c7, 0 @ Clean &
invalidate D-Cache" instruction to insure that memory is consistent
with any dirty cache lines.
Also fix a couple of "flush v*" comments in ARM1136 cpu_init_crit() so
that they correctly describe the actual ARM1136 CP15 C7 Cache Operations
used.
Signed-off-by: George G. Davis
---
arch/arm/cpu/arm1136/cpu.c |8
arch/arm/cpu/arm1136/start.S |4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/cpu/arm1136/cpu.c b/arch/arm/cpu/arm1136/cpu.c
index ade7f46..a00698f 100644
--- a/arch/arm/cpu/arm1136/cpu.c
+++ b/arch/arm/cpu/arm1136/cpu.c
@@ -69,8 +69,8 @@ int cleanup_before_linux (void)
static void cache_flush(void)
{
- unsigned long i = 0;
-
- asm ("mcr p15, 0, %0, c7, c7, 0": :"r" (i)); /* invalidate both caches
and flush btb */
- asm ("mcr p15, 0, %0, c7, c10, 4": :"r" (i)); /* mem barrier to sync
things */
+ asm (
+ " mcr p15, 0, %0, c7, c14, 0 @ Clean & invalidate D-Cache\n"
+ " mcr p15, 0, %0, c7, c10, 4 @ DSB\n"
+ : : "r" (0) : "memory");
}
diff --git a/arch/arm/cpu/arm1136/start.S b/arch/arm/cpu/arm1136/start.S
index 957f438..922d01c 100644
--- a/arch/arm/cpu/arm1136/start.S
+++ b/arch/arm/cpu/arm1136/start.S
@@ -226,8 +226,8 @@ cpu_init_crit:
* flush v4 I/D caches
*/
mov r0, #0
- mcr p15, 0, r0, c7, c7, 0 /* flush v3/v4 cache */
- mcr p15, 0, r0, c8, c7, 0 /* flush v4 TLB */
+ mcr p15, 0, r0, c7, c7, 0 /* Invalidate I+D+BTB caches */
+ mcr p15, 0, r0, c8, c7, 0 /* Invalidate Unified TLB */
/*
* disable MMU stuff and caches
--
1.6.3.3.328.ga9ee94
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] remove main CHANGELOG file
Dear Peter Tyser, In message <1273091842.2451.4563.ca...@localhost.localdomain> you wrote: > > I still don't grasp what the common use of looking at U-Boot's entire > changelog is. What are some common tasks that require grepping U-Boot's > entire changelog? Are these tasks performed frequently enough that the > extra <1 second 'git log' requires is bothersome? I'm trying to maintain some awareness of open patches. For example, when I receive a pull request I mark all included patches as processed; sometimes this includes tracking down older versions of the patches, or commit messages that have been changed on the way. And yes, the <1 second delay is bothersome when doing this frequently enough. > > -> wget -O u-boot.tgz > > 'http://git.denx.de/?p=u-boot.git;a=snapshot;sf=tgz' > > For snapshots, the CHANGELOG file is going to be out of date though. > It'll only list the changes that occurred up to the previous release. > This seems worse than not having a CHANGELOG at all as its actively > misleading people as to what changes their source code has. I disagree here. I find myself quite frequently in the situation that I have to identify the exact version some source tree has been derived from. Companies who maintain out-of-tree ports usually don't include any SCM information either. To me, the CHANGELOG is an extremely useful resource in such cases. > I'll quit whining, just wanted to give my +1 for removing the changelog. I don't consider you whining. I am listening to the arguments. I am not convinced yet, though. 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: w...@denx.de The human race is faced with a cruel choice: work or daytime tele- vision. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] remove main CHANGELOG file
Dear Kim Phillips,
In message <20100505160607.99edd83d.kim.phill...@freescale.com> you wrote:
>
> > How would you try such identification?
>
> it appears that the granularity of CHANGELOG updates is equal to that
> of VERSION, PATCHLEVEL, and EXTRAVERSION assignments in the root
> Makefile; so presumably one can refer to those instead.
This doesn't workl reliably. Too often companies insert their own
version information there, which sometimes is completely unrelated to
what we use.
> For exact per-export granularity, one can do something like this:
>
> cd u-boot
> echo '$Format:%H$' > snapshot.commit
> git add snapshot.commit && git commit -m 'add snapshot.commit file'
> echo 'snapshot.commit' > .git/info/attributes
> git archive --format=tar --prefix=${PREFIX}/ ...
>
> ...the resultant tarball's snapshot.commit file will contain the value
> of the sha id representing commit .
>
> for more info, see the gitattributes manpage and the list of
> placeholders in the PRETTY FORMATS section of the git log manpage.
Ah! That's interesting. Another git feature I didn't know yet.
/me is reading the documentation.
Thanks a lot for this interesting tip!
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: w...@denx.de
Mandrell: "You know what I think?"
Doctor: "Ah, ah that's a catch question. With a brain your size you
don't think, right?"
- Dr. Who
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Endless loop in cmd_log.c?
I am trying to implement CONFIG_LOGBUFFER and CONFIG_CMD_LOG on our ARM systems and I seem to have run into an endless loop. With loglevel=5 so we still see our console output, the printf at the end of logbuff_printk appears to create an endless loop. I had to replace that line with serial_puts(msg); Have I missed some other solution or do the systems that use this never set logbuffer higher than default_message_loglevel? DaR ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/17] SPARC: added unaligned definitions, patch supplied by Magnus Sjalander.
Dear Daniel Hellstrom, In message <1264680996-13804-1-git-send-email-dan...@gaisler.com> you wrote: > Signed-off-by: Daniel Hellstrom > --- > include/asm-sparc/unaligned.h | 17 + > 1 files changed, 17 insertions(+), 0 deletions(-) > create mode 100644 include/asm-sparc/unaligned.h This whole patch series has been out there for many months, but I'm still waiting for a pull request from you. Do you have any such plans? 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: w...@denx.de Sorry, but my karma just ran over your dogma. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 12/17] SPEAr : i2c driver moved completely into drivers/i2c
Vipin KUMAR wrote: > On 5/3/2010 5:55 AM, Tom Rix wrote: >> Vipin KUMAR wrote: >>> The i2c IP used by spear platform is a synopsys i2c controller >> 'IP' expand. > > IP is Intellectual Property i.e peripheral hardware > Please use the term 'peripheral hardware' in place of IP IP is too generic. Tom >> What is the connection between 'synopsys' and 'designware' ? >> If the part is synopsys, that should be the string used >> instead of 'dw' or 'designware' > > Synopsys is the vendor and designware is the class of peripherals > from synopsys > >>> The earlier driver adds the driver of this controller as if it is >>> specific to >>> spear platform. >>> The driver files are now moved into drivers/i2c folder for reusability >>> by other >> Maybe something like >> 'The earlier i2c driver was specific to spear platforms. >> This driver has been moved to the common driver directory drivers/i2c >> where it can be used by other platforms' >> > OK. I would improve on this > > Regards > Vipin > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6 v3] spi_flash: support old STMicro parts with RES
On Wednesday 05 May 2010 15:57:29 Wolfgang Denk wrote: > Mike Frysinger wrote: > > ive merged this into my sf branch and will push out next merge window if > > Wolfgang doesnt pick it up before that > > Just let me know what you (and Thomas) prefer doesnt matter to me whether you pull my branch now or after the merge window: git://git.denx.de/u-boot-blackfin.git sf > and what exactly (which patch[es] from this series) the "it" is that should > be picked up (or not). there is only one patch in this thread ... referring to all the patches in my branch, none are "bugfixes" persay which is why i didnt know if you wanted to let them sit until next merge window. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM1136: Fix cache_flush() error and correct cpu_init_crit() comments
The ARM1136 cache_flush() function uses the "mcr p15, 0, rn, c7, c7, 0"
instruction which means "Invalidate Both Caches" when in fact the intent
is to "Clean and Invalidate Entire Data Cache". So change the ARM1136
cache_flush() function to use the "mcr p15, 0, rn, c7, c7, 0 @ Clean &
invalidate D-Cache" instruction to insure that memory is consistent
with any dirty cache lines.
Also fix a couple of "flush v*" comments in ARM1136 cpu_init_crit() so
that they correctly describe the actual ARM1136 CP15 C7 Cache Operations
used.
Signed-off-by: George G. Davis
---
arch/arm/cpu/arm1136/cpu.c |8
arch/arm/cpu/arm1136/start.S |4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/cpu/arm1136/cpu.c b/arch/arm/cpu/arm1136/cpu.c
index ade7f46..a00698f 100644
--- a/arch/arm/cpu/arm1136/cpu.c
+++ b/arch/arm/cpu/arm1136/cpu.c
@@ -69,8 +69,8 @@ int cleanup_before_linux (void)
static void cache_flush(void)
{
- unsigned long i = 0;
-
- asm ("mcr p15, 0, %0, c7, c7, 0": :"r" (i)); /* invalidate both caches
and flush btb */
- asm ("mcr p15, 0, %0, c7, c10, 4": :"r" (i)); /* mem barrier to sync
things */
+ asm (
+ " mcr p15, 0, %0, c7, c14, 0 @ Clean & invalidate D-Cache\n"
+ " mcr p15, 0, %0, c7, c10, 4 @ DSB\n"
+ : : "r" (0) : "memory");
}
diff --git a/arch/arm/cpu/arm1136/start.S b/arch/arm/cpu/arm1136/start.S
index 957f438..922d01c 100644
--- a/arch/arm/cpu/arm1136/start.S
+++ b/arch/arm/cpu/arm1136/start.S
@@ -226,8 +226,8 @@ cpu_init_crit:
* flush v4 I/D caches
*/
mov r0, #0
- mcr p15, 0, r0, c7, c7, 0 /* flush v3/v4 cache */
- mcr p15, 0, r0, c8, c7, 0 /* flush v4 TLB */
+ mcr p15, 0, r0, c7, c7, 0 /* Invalidate I+D+BTB caches */
+ mcr p15, 0, r0, c8, c7, 0 /* Invalidate Unified TLB */
/*
* disable MMU stuff and caches
--
1.6.3.3.328.ga9ee94
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] remove main CHANGELOG file
> > I'll quit whining, just wanted to give my +1 for removing the changelog. > > I don't consider you whining. I am listening to the arguments. > I am not convinced yet, though. Well in that case, I'll chime in again:) > > I still don't grasp what the common use of looking at U-Boot's entire > > changelog is. What are some common tasks that require grepping U-Boot's > > entire changelog? Are these tasks performed frequently enough that the > > extra <1 second 'git log' requires is bothersome? > > I'm trying to maintain some awareness of open patches. For example, > when I receive a pull request I mark all included patches as > processed; sometimes this includes tracking down older versions of > the patches, or commit messages that have been changed on the way. > And yes, the <1 second delay is bothersome when doing this frequently > enough. I see, makes sense. This seems like a problem that is unique to you, as well as potentially a few other maintainers. I imagine the vast majority of developers rarely use the CHANGELOG file though. Would having maintainers create their own CHANGELOG files and/or use something like patchwork be acceptable? > > > -> wget -O u-boot.tgz > > > 'http://git.denx.de/?p=u-boot.git;a=snapshot;sf=tgz' > > > > For snapshots, the CHANGELOG file is going to be out of date though. > > It'll only list the changes that occurred up to the previous release. > > This seems worse than not having a CHANGELOG at all as its actively > > misleading people as to what changes their source code has. > > I disagree here. I find myself quite frequently in the situation that > I have to identify the exact version some source tree has been > derived from. Companies who maintain out-of-tree ports usually don't > include any SCM information either. To me, the CHANGELOG is an > extremely useful resource in such cases. The CHANGELOG in a company's source tree won't provide any more information than the VERSION, PATCHLEVEL, and EXTRAVERSION in the Makefile though, right? Ie the CHANGELOG is only updated when the VERSION, PATCHLEVEL, and EXTRAVERSION are updated. Either way, it seems like an inexact method to determine the revision of the source code, and there should be a better solution so that you don't have to be a detective every time you get another vendor's source tree. It seems bad to have an inaccurate CHANGELOG. For example if someone got a snapshot tarball a week before the last release, their CHANGELOG would be missing over 500 changes. In this case the CHANGELOG clearly isn't serving its intended purpose and could actually mislead someone, eg "I know commit XYZ introduces a bug, but the changelog says I don't have commit XYZ in my tree, so I'm bug free!". In reality there have been 500 commits the user is unaware of, including potentially commit XYZ they were trying to avoid. OK, its a stretch, but I don't get the purpose of an inaccurate CHANGELOG in any case. Other than when the 1 commit that correlates to a tagged release is the the top-of-tree, the CHANGELOG is *never* up to date. It can only be believed if someone downloads an officially released tarball - otherwise it is most likely wrong. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] Support for TI's DA850/OMAP-L138 platform
Sudhakar Rajashekhara wrote:
> This patch series adds support for TI's DA850/OMAP-L138
> platform. This series is dependant on the following
> patch which I have submitted earlier:
>
> [U-Boot] [PATCH] da830: Move common code out of da830evm.c file
>
> Sudhakar Rajashekhara (3):
> TI: DaVinci: Prepare for da850 support
> TI: DaVinci: Add board specific code for da850 EVM
> TI: DaVinci: Create configuration file for da850 EVM
I ran into
da850evm.c:64: error: array type has incomplete element type
da850evm.c: In function 'board_init':
da850evm.c:75: warning: implicit declaration of function 'irq_init'
da850evm.c:90: warning: implicit declaration of function
'davinci_configure_lpsc_items'
Please check that this patchset still builds and rebase if necessary.
Tom
>
> MAINTAINERS |4 +
> MAKEALL |1 +
> Makefile|5 +-
> arch/arm/include/asm/arch-davinci/hardware.h|1 +
> board/davinci/{da830evm => da8xxevm}/Makefile |5 +-
> board/davinci/{da830evm => da8xxevm}/config.mk |0
> board/davinci/{da830evm => da8xxevm}/da830evm.c |0
> board/davinci/da8xxevm/da850evm.c | 111 +++
> include/configs/da850evm.h | 135
> +++
> 9 files changed, 260 insertions(+), 2 deletions(-)
> rename board/davinci/{da830evm => da8xxevm}/Makefile (91%)
> rename board/davinci/{da830evm => da8xxevm}/config.mk (100%)
> rename board/davinci/{da830evm => da8xxevm}/da830evm.c (100%)
> create mode 100644 board/davinci/da8xxevm/da850evm.c
> create mode 100644 include/configs/da850evm.h
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] remove main CHANGELOG file
Dear Peter Tyser, In message <1273095808.2451.4674.ca...@localhost.localdomain> you wrote: > > I see, makes sense. This seems like a problem that is unique to you, as > well as potentially a few other maintainers. I imagine the vast > majority of developers rarely use the CHANGELOG file though. Would > having maintainers create their own CHANGELOG files and/or use something > like patchwork be acceptable? As far as the patch processing is concerned, a dynamically generated file is perfectly good enough for me. If we can keep the "CHANGELOG" make target I have all I need here. > > I disagree here. I find myself quite frequently in the situation that > > I have to identify the exact version some source tree has been > > derived from. Companies who maintain out-of-tree ports usually don't > > include any SCM information either. To me, the CHANGELOG is an > > extremely useful resource in such cases. > > The CHANGELOG in a company's source tree won't provide any more > information than the VERSION, PATCHLEVEL, and EXTRAVERSION in the > Makefile though, right? Ie the CHANGELOG is only updated when the > VERSION, PATCHLEVEL, and EXTRAVERSION are updated. Either way, it seems > like an inexact method to determine the revision of the source code, and > there should be a better solution so that you don't have to be a > detective every time you get another vendor's source tree. Thats's not quite right. I used to update CHANGELOG more frequently in the past. > It seems bad to have an inaccurate CHANGELOG. For example if someone > got a snapshot tarball a week before the last release, their CHANGELOG > would be missing over 500 changes. In this case the CHANGELOG clearly Agreed. It was never perfect, but the best we (well, I) had. > OK, its a stretch, but I don't get the purpose of an inaccurate > CHANGELOG in any case. Other than when the 1 commit that correlates to > a tagged release is the the top-of-tree, the CHANGELOG is *never* up to > date. It can only be believed if someone downloads an officially > released tarball - otherwise it is most likely wrong. Right. Well, Kim's pointer to gitattributes is probably the solution to this issue. Please allow me for some time to let this sink in. 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: w...@denx.de He is truly wise who gains wisdom from another's mishap. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add SPI support to mx51evk board
Dear Stefano Babic, In message <1268756541-2179-1-git-send-email-sba...@denx.de> you wrote: > The patch adds SPI devices to the mx51evk board. Two devices > are supported: Atmel SPI flash and MC13892 power > controller. > > Signed-off-by: Stefano Babic > --- > board/freescale/mx51evk/mx51evk.c | 178 > + > include/configs/mx51evk.h | 17 > 2 files changed, 195 insertions(+), 0 deletions(-) It seems this patch has not been picked up yet - can you please check? 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: w...@denx.de Do you suppose the reason the ends of the `Intel Inside' logo don't match up is that it was drawn on a Pentium? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc: unused memory region too close to current stack pointer
Dear Norbert van Bolhuis,
In message <201003191434.o2jeyprf024...@linpc062.aimsys.nl> you wrote:
>
> This avoids a possible overwrite of the (end of) ramdisk by u-boot.
> The unused memory region for ppc boot currently starts 1k below the
> do_bootm->bootm_start->arch_lmb_reserve stack ptr. This isn't enough since
> do_bootm->do_bootm_linux->boot_relocate_fdt calls printf which may
> very well use more than 1k stack space.
>
> diff --git a/lib_ppc/bootm.c b/lib_ppc/bootm.c
> index 0685a93..6702df5 100644
> --- a/lib_ppc/bootm.c
> +++ b/lib_ppc/bootm.c
> @@ -163,8 +163,8 @@ void arch_lmb_reserve(struct lmb *lmb)
> sp = get_sp();
> debug ("## Current stack ends at 0x%08lx\n", sp);
>
> - /* adjust sp by 1K to be safe */
> - sp -= 1024;
> + /* adjust sp by 4K to be safe */
> + sp -= 4096;
> lmb_reserve(lmb, sp, (CONFIG_SYS_SDRAM_BASE + get_effective_memsize() -
> sp));
>
> return ;
> --
> 1.5.2.2
>
> Signed-off-by: Norbert van Bolhuis
Applied - but could you please use "git format-patch" next time? For
example, the Signed-off-by line must be part of the commit message,
and not come below the signature separator.
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: w...@denx.de
The high cost of living hasn't affected its popularity.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cmd_onenand.c: moved to standard subcommand handling
Dear Frans Meulenbroeks, In message <1269706476-20496-1-git-send-email-fransmeulenbro...@gmail.com> you wrote: > On the fly also fixed the following things: > - write help talked about a parameter oob, but that one was not used, so > removed it from the help message. > - the test command also allowed a force subcommand but didn't use it. > eliminated the code. > - do_onenand made static > - do_onenand contained > int blocksize; > ... > mtd = &onenand_mtd; > this = mtd->priv; > blocksize = (1 << this->erase_shift); > As blocksize was not used the last two statements were unneeded so > removed them. > The first statement (mtd = ) assigns to a global. Not sure if it > is needed, and since I could not test this, left the line for now > > Signed-off-by: Frans Meulenbroeks > --- > common/cmd_onenand.c | 307 > +++--- > 1 files changed, 192 insertions(+), 115 deletions(-) Applied, 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: w...@denx.de Life would be so much easier if we could just look at the source code. -- Dave Olson ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] POST: Added ECC memory test for mpc83xx.
Dear Michael Zaidman,
In message <1270654208-32319-1-git-send-email-michael.zaid...@gmail.com> you
wrote:
> Signed-off-by: Michael Zaidman
> ---
> post/cpu/mpc83xx/Makefile | 30
> post/cpu/mpc83xx/ecc.c| 167
> +
> 2 files changed, 197 insertions(+), 0 deletions(-)
> create mode 100644 post/cpu/mpc83xx/Makefile
> create mode 100644 post/cpu/mpc83xx/ecc.c
Applied, after fixing incorrect brace style:
> + /* Set bit to be injected */
> + if (errbit < 32) {
> + __raw_writel(1 << errbit, &ddr->data_err_inject_lo);
> + __raw_writel(0, &ddr->data_err_inject_hi);
> + }
> + else {
... here.
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: w...@denx.de
I can type faster than I can move a mouse, so I find menu-driven
drawing packages time consuming and frustrating. - W. R. Stevens
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: modified calculated mmc-capacity & set mmc trans_speed
Dear Andy, In message Jae hoon Chung wrote: > The patches do the following > 1. If mmc size is more than 2GB , we need to calculated using the > extended csd register. > 2. mmc_set_clock() is hard setting, that is not good solution. > > If mmc is not MMC_MODE_HS, mmc will set card's trans_speed. > > > Signed-off-by: Jaehoon Chung > > --- > drivers/mmc/mmc.c | 13 - > 1 files changed, 8 insertions(+), 5 deletions(-) Is this patch somewhere in your queue? 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: w...@denx.de "There are things that are so serious that you can only joke about them"- Heisenberg ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/3] fsl-diu: Using I/O accessor to CCSR space
Dear Kumar Gala, In message <0adf7618-d48a-4003-aba5-14d9e0084...@kernel.crashing.org> you wrote: > > On Apr 8, 2010, at 2:56 AM, Dave Liu wrote: > > > From: Jerry Huang > > > > Using PPC I/O accessor to DIU I/O space instead of directly > > read/write. It will prevent the dozen of compiler order issue > > and PPC hardware order issue for accessing I/O space. > > > > Using the toolchain(tc-fsl-x86lnx-e500-dp-4.3.74-2.i386.rpm) > > can show up the order issue of DIU driver. > > > > Signed-off-by: Dave Liu > > Signed-off-by: Jerry Huang > > --- > > * address Timur's comments > > > > board/freescale/common/fsl_diu_fb.c | 55 > > ++- > > 1 files changed, 28 insertions(+), 27 deletions(-) > > applied to mpc85xx Am I missing a pull request from you here? 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: w...@denx.de We want to create puppets that pull their own strings. - Ann Marion ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/26] [x86] 'Comming of Age'
Dear Graeme Russ, In message <1272031560-30486-1-git-send-email-graeme.r...@gmail.com> you wrote: > Hello Everyone > > Respin of a previous patch set addressing a few minor issues > including: > > Version 2: > - Resolved the PCI_BASE_ADDRESS_1 --> PCI_BASE_ADDRESS_0 modification. > It turned out to be a PCI region definition issue where the existing > code was making non-generic assumptions about the allocation of the > PCI address space. The code which defines PCI regions has been made > board specific > - Use asm-generic/unaligned.h > - Added GPLv2 copyright notice to the RAM sizer code - I contacted AMD > and asked them to modify the license on thier Code Kit containing > this code and they have happily obliged > - Fixed bug in the RAM sizer code which I noticed when comparing the > now Code Kit code to the existing code > > Version 3: > - Added CONFIG_SYS_NS16550_PORT_MAPPED instead of using CONFIG_X86 as >suggested by Nishanth Menon > > This patch series can be examined as several distinct functional changes > - Patches 1-3 are x86 specific build and core fixups > - Patches 4-11 are x86 specific functional improvements > - Patches 12-13 (*) switch the x86 port to CONFIG_SERIAL_MULTI > - Patches 14-15 provide Linux boot support > - Patch 16 is an sc520 specific patch (this one can be delayed) > - Patches 17-18 are various eNET specific patches > - Patches 19-20 make PCI region initialisation board specific > - Patch 21 enables the eNET Ethernet chips (requires patched 19-20) > - Patch 22 sets up the eNET for maximum PC/AT compatibilty to boot Linux > - Patches 23-24 are eNET 'nice to haves' > - Patch 25 updates the AMD license to GPL (I have supporting emails) > - Patch 26 fixes a minor sc520 bug > > (*) Patches 12 and 13 are the only patches which touch files outside the > x86 tree. Applied, thanks. Hm.. wouldn't it make sense to add you as custodian for x86? What do you think? 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: w...@denx.de Severe culture shock results when experts from another protocol suite [...] try to read OSI documents. The term "osified" is used to refer to such documents. [...] Any relationship to the word "ossified" is purely intentional.- Marshall T. Rose ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 74xx_7xx: CPCI750: Add ECC support on esd CPCI-CPU/750 board
Dear Stefan Roese, In message <1271145549-15224-1-git-send-email...@denx.de> you wrote: > From: Reinhard Arlt > > Add ECC support for DDR RAM for MV64360 on esd CPCI-CPU/750 board. > > This patch also adds the "pldver" command to display the CPLD > revision. > > Signed-off-by: Reinhard Arlt > Signed-off-by: Stefan Roese > --- > board/esd/cpci750/cpci750.c| 12 +++ > board/esd/cpci750/sdram_init.c | 151 > ++-- > include/configs/CPCI750.h |4 +- > 3 files changed, 159 insertions(+), 8 deletions(-) Applied, 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: w...@denx.de He'd heard her use that sweet, innocent tone of voice before. It meant that, pretty soon, there was going to be trouble. - Terry Pratchett, _Truckers_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add SPI support to mx51evk board
Wolfgang Denk wrote: > Dear Stefano Babic, > Hi Wolfgang, > In message <1268756541-2179-1-git-send-email-sba...@denx.de> you wrote: >> The patch adds SPI devices to the mx51evk board. Two devices >> are supported: Atmel SPI flash and MC13892 power >> controller. >> >> Signed-off-by: Stefano Babic >> --- >> board/freescale/mx51evk/mx51evk.c | 178 >> + >> include/configs/mx51evk.h | 17 >> 2 files changed, 195 insertions(+), 0 deletions(-) > > It seems this patch has not been picked up yet - can you please check? This is not correct. The patch was reviewed and after the review I split as suggested this patch in several patches, testing for both mx51 and mx31 targets (the original patch broke mx31 targets). You can consider this patch as obsolete and substituded by "SPI: added support for MX51 to mxc_spi". I sent today a pull request to Tom with the updated version of the patch. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/3] IGEP v2 support
Dear Enric Balletbo i Serra,
In message <1271234190-2432-4-git-send-email-eballe...@gmail.com> you wrote:
> From: Enric Balletbo i Serra
>
> This patch adds support for the IGEP v2 board.
>
> The IGEP v2 board is a low-cost, fan-less and industrial temperature
> range single board computer that unleashes laptop-like performance and
> expandability without the bulk, expense, or noise of typical desktop
> machines. Its architecture shares much in common with other OMAP3 boards.
>
> Signed-off-by: Enric Balletbo i Serra
> ---
> MAINTAINERS |4 +
> Makefile |3 +
> board/isee/igep0020/Makefile | 49 +
> board/isee/igep0020/config.mk| 34
> board/isee/igep0020/igep0020.c | 134 +
> board/isee/igep0020/igep0020.h | 399
> ++
> include/configs/omap3_igep0020.h | 245 +++
> 7 files changed, 868 insertions(+), 0 deletions(-)
> create mode 100644 board/isee/igep0020/Makefile
> create mode 100644 board/isee/igep0020/config.mk
> create mode 100644 board/isee/igep0020/igep0020.c
> create mode 100644 board/isee/igep0020/igep0020.h
> create mode 100644 include/configs/omap3_igep0020.h
MAKEALL entry missing.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 94839ce..19da604 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -525,6 +525,10 @@ Stefano Babic
> polaris xscale
> trizepsiv xscale
>
> +Enric Balletbo i Serra
> +
> + omap3_igep0020 ARM CORTEX-A8 (OMAP3530 SoC)
> +
> Dirk Behme
>
> omap3_beagleARM CORTEX-A8 (OMAP3530 SoC)
> diff --git a/Makefile b/Makefile
> index 412e359..90f8c29 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -3161,6 +3161,9 @@ omap3_overo_config :unconfig
> omap3_evm_config : unconfig
> @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 evm ti omap3
>
> +omap3_igep0020_config : unconfig
> + @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 igep0020 isee omap3
> +
> omap3_pandora_config : unconfig
> @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 pandora NULL omap3
Make target names shall be identical to board names. Please use
"igep0020_config" here. [Yes, I know, bad examples exist. Please
ignore these.]
> diff --git a/board/isee/igep0020/config.mk b/board/isee/igep0020/config.mk
> new file mode 100644
> index 000..a05f782
> --- /dev/null
> +++ b/board/isee/igep0020/config.mk
...
> +# For use with external or internal boots.
> +TEXT_BASE = 0x8ff0
> +
No trailing empty lines, please.
> diff --git a/board/isee/igep0020/igep0020.c b/board/isee/igep0020/igep0020.c
> new file mode 100644
> index 000..a9d9deb
> --- /dev/null
> +++ b/board/isee/igep0020/igep0020.c
> @@ -0,0 +1,134 @@
...
> +/*
> + * Routine: board_init
> + * Description: Early hardware init.
> + */
> +int board_init(void)
> +{
> + DECLARE_GLOBAL_DATA_PTR;
This will not work. DECLARE_GLOBAL_DATA_PTR must be on file levcel,
not on function level.
> diff --git a/board/isee/igep0020/igep0020.h b/board/isee/igep0020/igep0020.h
> new file mode 100644
> index 000..e5e0ac9
> --- /dev/null
> +++ b/board/isee/igep0020/igep0020.h
...
> +/* MUX_VAL(CP(MMC2_DAT3),(IEN | PTD | DIS | M4)) GPIO_135
> (GPIO-Based CS) */\
> + \
> + MUX_VAL(CP(CAM_HS), (IDIS | PTD | DIS | M4)) /* GPIO_94 - PDN (Rev.
> B) */\
> + MUX_VAL(CP(CAM_VS), (IDIS | PTD | DIS | M4)) /* GPIO_95 - RESET_N_W
> (Rev. B) */\
> + \
> + MUX_VAL(CP(MMC2_DAT4), (IDIS | PTD | DIS | M4)) /* GPIO_136 */\
> + MUX_VAL(CP(MMC2_DAT5), (IDIS | PTD | DIS | M4)) /* GPIO_137 -
> RESET_N_B */\
> + MUX_VAL(CP(MMC2_DAT6), (IDIS | PTD | DIS | M4)) /* GPIO_138 -
> PDN (Rev. C) */\
> + MUX_VAL(CP(MMC2_DAT7), (IDIS | PTD | DIS | M4)) /* GPIO_139 -
> RESET_N_W (Rev. C) */\
Lines too long. Please fix globally.
> diff --git a/include/configs/omap3_igep0020.h
> b/include/configs/omap3_igep0020.h
> new file mode 100644
> index 000..0b2564a
> --- /dev/null
> +++ b/include/configs/omap3_igep0020.h
File name should be include/configs/igep0020.h
> +/* Clock Defines */
> +#define V_OSCK 2600/* Clock output from T2
> */
> +#define V_SCLK (V_OSCK >> 1)
> +
> +#undef CONFIG_USE_IRQ/* no support for IRQs
> */
Please do not #undef what is not defined anyway.
> +#define CONFIG_CMD_EXT2 /* EXT2 Support */
> +#define CONFIG_CMD_FAT /* FAT support */
> +#define CONFIG_CMD_I2C /* I2C serial bus support */
> +#define CONFIG_CMD_MMC /* MMC support */
> +#define CONFIG_CMD_ONENAND /* ONENAND support */
> +#define CONFIG_CMD_NET /* bootp, tftpboot, rarpboot*/
> +#define CONFIG_CMD_DHCP
> +#define CONFIG_CMD_PING
> +#define CONFIG_CMD_NFS
Re: [U-Boot] [PATCH v3] command.c: Enable auto tab for the editenv command
Dear =?iso-8859-1?Q?Tr=FCbenbach=2C_Ralf?=, In message you wrote: > Enable the auto completion (with TAB) of the environment variable name = > > after the editenv command. > > Signed-off-by: Ralf Tr=FCbenbach > --- > Changes from v2: > > Sorry, but your patch does not apply against current mainline code: > > ... > > It seems your mailer is messing with the white space (silently > > converting TABs to spaces or so?). > Yes you are right, now it (hopefully) should work. Thank you for your > patience :) > > diff --git a/common/command.c b/common/command.c > index 0c66b7a..67ad692 100644 > --- a/common/command.c > +++ b/common/command.c Applied, 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: w...@denx.de It may be bad manners to talk with your mouth full, but it isn't too good either if you speak when your head is empty. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] compiler.h: add uint typedef
Dear Mike Frysinger, In message <1271756970-15098-1-git-send-email-vap...@gentoo.org> you wrote: > Recent crc changes started using the "uint" type in headers that are used > on the build system. This subsequently broke mingw targets as they do not > provide such a type. So add this basic typedef to compiler.h so that we > do not have to worry about this breaking again in the future. > > Signed-off-by: Mike Frysinger > --- > include/compiler.h |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) Applied, 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: w...@denx.de Anyone can count the seeds in an apple. No one can count the apples in a seed. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Move test for unnecessary memmove to memmove_wd()
Dear Larry Johnson, In message <4bcd9987.9020...@acm.org> you wrote: > Signed-off-by: Larry Johnson > --- > common/cmd_bootm.c |7 ++- > common/image.c |3 +++ > 2 files changed, 5 insertions(+), 5 deletions(-) Applied, 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: w...@denx.de You! What PLANET is this! -- McCoy, "The City on the Edge of Forever", stardate 3134.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tx25: fix crash while booting Linux
Dear Stefano Babic, In message <4bcf02b0.60...@denx.de> you wrote: > Anatolij Gustschin wrote: > > Currently booting Linux on TX25 board doesn't work > > since there is no correct mach-id and boot parameters > > setup for tx25 board. Fix it now. > > > > Signed-off-by: Anatolij Gustschin > > Cc: John Rigby > > Cc: Stefano Babic > > --- > > board/karo/tx25/tx25.c |3 +++ > > 1 files changed, 3 insertions(+), 0 deletions(-) > > > > diff --git a/board/karo/tx25/tx25.c b/board/karo/tx25/tx25.c > > index 4d6a96d..2608698 100644 > > --- a/board/karo/tx25/tx25.c > > +++ b/board/karo/tx25/tx25.c > > @@ -145,6 +145,9 @@ int board_init() > > > > mx25_uart_init_pins(); > > #endif > > + /* board id for linux */ > > + gd->bd->bi_arch_number = MACH_TYPE_TX25; > > + gd->bd->bi_boot_params = PHYS_SDRAM_1 + 0x100; > > return 0; > > } > > > > Applied to u-boot-imx, thanks. Will you send a pull request to Tom any time soon? 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: w...@denx.de It would be illogical to kill without reason -- Spock, "Journey to Babel", stardate 3842.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers/*/Makefile: fix conditional compile rule.
Dear "Ender.Dai", In message <1271921065-18704-1-git-send-email-ender@gmail.com> you wrote: > Fix conditional compile rule for twl4030.c and videomodes.c. > > Signed-off-by: Ender.Dai > --- > drivers/usb/phy/Makefile |1 - > drivers/video/Makefile |9 - > 2 files changed, 4 insertions(+), 6 deletions(-) Applied, thanks. It would have been better to split this into two commits, one for the USB and the other one for the video custodian. 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: w...@denx.de Heavier than air flying machines are impossible. -- Lord Kelvin, President, Royal Society, c. 1895 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6 v3] spi_flash: support old STMicro parts with RES
Dear Wolfgang, On 05/06/2010 03:57 AM, Wolfgang Denk wrote: > Dear Mike Frysinger, > > In message<201005050321.49140.vap...@gentoo.org> you wrote: > >> ive merged this into my sf branch and will push out next merge window if >> Wolfgang doesnt pick it up before that >> > Just let me know what you (and Thomas) prefer, and what exactly > (which patch[es] from this series) the "it" is that should be picked > up (or not). > > These patches were submitted within this merge window. I just resubmitted the outstanding patches in a series as you suggested. It would be nice if you can merge them in this release. The current u-boot supports only very old, obsolete Altera dev boards, most newer boards are not supported. I hope we can work together to let these patches merged, so that most Altera's dev boards can be supported. The drivers for gpio, altera_spi, spi_flash and mmc_spi are important as Altera includes them in their example design. Best regards, Thomas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 12/17] SPEAr : i2c driver moved completely into drivers/i2c
On 5/4/2010 11:26 PM, Scott Wood wrote: > On Tue, May 04, 2010 at 02:37:03PM +0530, Vipin KUMAR wrote: >> On 5/3/2010 5:55 AM, Tom Rix wrote: >>> Vipin KUMAR wrote: The i2c IP used by spear platform is a synopsys i2c controller >>> >>> 'IP' expand. >> >> IP is Intellectual Property i.e peripheral hardware > > So in a bazillion years when this stuff finally becomes public domain will > it suddenly be referred to by a different name? IP is just its legal status > (and a vague description of it, at that), it isn't a description of the > physical entity (however commonly it might be used as such). > > IMHO "logic", "block", etc. are better nouns for these things. > Point taken. I would use logic/block etc. I think it makes more sense Regards Vipin > -Scott > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] uboot bootm issue ...
Dear Wolfgang,
Sorry to post the 64 encode message by mail box jxnu...@163.com, now I just
convert it into plain text and re-send it, could you guys have a look at this
quick question?
BTW could you pls tell me how to join to mail list: u-b...@lists.denx.de?
Thanks again.
Denny
-
Hi all,
I tried to boot kernel fom flash by automatically, but encounter the 'hang'
problem while transfer the control to kernel
now each time I have to enter 3, and run 'bootm 0xfb40', have you even
encounter similar problem? does it relate with env?
Log:
=> printenv
AutoLoad=yes
baudrate=9600
bootargs=ip=off console=ttyS1,9600 noinitrd rootfstype=jffs2
root=/dev/mtdblock1 rw
bootcmd=setenv bootargs mem=${mem} ${OSLoadOptions};bootm 0xfb40
bootdelay=4
eth1addr=00:E0:0C:00:01:FD
eth2addr=00:E0:0C:00:02:FD
ethact=ENET0
ethaddr=00:E0:0C:00:00:FD
gatewayip=192.168.65.1
initrd_high=0x2000
ipaddr=192.168.65.233
loadaddr=20
loads_echo=1
mem=520192k
netmask=255.255.255.0
serverip=192.168.65.21
stderr=serial
stdin=serial
stdout=serial
Environment size: 475/4080 bytes
=> reset
U-Boot 1.1.3 (Apr 25 2010 - 18:01:57)
CPU: 8544_E, Version: 1.1, (0x803c0111)
Core: E500, Version: 2.2, (0x80210022)
Clock Configuration:
CPU: 800 MHz, CCB: 400 MHz,
DDR: 200 MHz, LBC: 50 MHz
L1:D-cache 32 kB enabled
I-cache 32 kB enabled
Board: CHOW48
CPU Board Revision 0.0 (0x)
PCI2: disabled
I2C: ready
DRAM: Initializing DDRSDRAM
memsize = 200
DDR: 512 MB
POST RAM test disabled.
Now running in RAM - U-Boot at: 1fb7f000
trap_init : 0x0
system inventory subsystem initialized
FLASH: 64 MB
L2 cache 256KB: enabled
PCI:
01 00 11ab db90 0580 00
0a 00 11ab db90 0580 00
In:serial
Out: serial
Err: serial
Net:
ENET0: PHY is Marvell 88E1112 (1410c97)
set_bootstatus: BS_LOAD_OS, platform_idx = 11
Hit ESC to stop autoboot: 0
## Booting image at fb40 ...
Image Name: Linux-2.6.14.2
Image Type: PowerPC Linux Multi-File Image (gzip compressed)
Data Size:2506367 Bytes = 2.4 MB
Load Address:
Entry Point:
Contents:
Image 0: 1429849 Bytes = 1.4 MB
Image 1: 1076503 Bytes = 1 MB
Uncompressing Multi-File Image ... ## Current stack ends at 0x1FB5DBD0 =>
set upper limit to 0x0080
## initrd at 0xFB55D1A8 ... 0xFB663EBE (len=1076503=0x106D17)
Loading Ramdisk to 1fa56000, end 1fb5cd17 ... OK
initrd_start = 1fa56000, initrd_end = 1fb5cd17
## Transferring control to Linux (at address ) ...
Thanks,
Denny
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tx25: fix crash while booting Linux
Hi Wolfgang, --- On Wed, 5/5/10, Wolfgang Denk wrote: > From: Wolfgang Denk > Subject: Re: [U-Boot] [PATCH] tx25: fix crash while booting Linux > To: "Stefano Babic" > Cc: u-boot@lists.denx.de, "John Rigby" > Date: Wednesday, May 5, 2010, 7:40 PM > Dear Stefano Babic, > > In message <4bcf02b0.60...@denx.de> > you wrote: > > Anatolij Gustschin wrote: > > > Currently booting Linux on TX25 board doesn't > work > > > since there is no correct mach-id and boot > parameters > > > setup for tx25 board. Fix it now. > > > > > > Signed-off-by: Anatolij Gustschin > > > Cc: John Rigby > > > Cc: Stefano Babic > > > --- > > > board/karo/tx25/tx25.c | 3 > +++ > > > 1 files changed, 3 insertions(+), 0 > deletions(-) > > > > > > diff --git a/board/karo/tx25/tx25.c > b/board/karo/tx25/tx25.c > > > index 4d6a96d..2608698 100644 > > > --- a/board/karo/tx25/tx25.c > > > +++ b/board/karo/tx25/tx25.c > > > @@ -145,6 +145,9 @@ int board_init() > > > > > > mx25_uart_init_pins(); > > > #endif > > > + /* board id for linux */ > > > + gd->bd->bi_arch_number > = MACH_TYPE_TX25; > > > + gd->bd->bi_boot_params > = PHYS_SDRAM_1 + 0x100; > > > return 0; > > > } > > > > > > > Applied to u-boot-imx, thanks. > > Will you send a pull request to Tom any time soon? Stefano sent the pull request : http://www.mail-archive.com/u-boot@lists.denx.de/msg31966.html Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 12/17] SPEAr : i2c driver moved completely into drivers/i2c
On 5/6/2010 3:07 AM, Tom Rix wrote: > Vipin KUMAR wrote: >> On 5/3/2010 5:55 AM, Tom Rix wrote: >>> Vipin KUMAR wrote: The i2c IP used by spear platform is a synopsys i2c controller >>> 'IP' expand. >> >> IP is Intellectual Property i.e peripheral hardware >> > > Please use the term 'peripheral hardware' in place of IP > IP is too generic. > OK > Tom > >>> What is the connection between 'synopsys' and 'designware' ? >>> If the part is synopsys, that should be the string used >>> instead of 'dw' or 'designware' >> >> Synopsys is the vendor and designware is the class of peripherals from >> synopsys >> The earlier driver adds the driver of this controller as if it is specific to spear platform. The driver files are now moved into drivers/i2c folder for reusability by other >>> Maybe something like >>> 'The earlier i2c driver was specific to spear platforms. >>> This driver has been moved to the common driver directory drivers/i2c >>> where it can be used by other platforms' >>> >> OK. I would improve on this >> >> Regards >> Vipin >> >> > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/26] [x86] 'Comming of Age'
Wolfgang Denk wrote: > Dear Graeme Russ, > > In message <1272031560-30486-1-git-send-email-graeme.r...@gmail.com> you > wrote: >> Hello Everyone [snip] > Applied, thanks. > > Hm.. wouldn't it make sense to add you as custodian for x86? What do > you think? > I actually mentioned that idea previously - What needs to be done to arrange this? I understand I need a PGP key at least which I need to figure out how to do Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/17] SPEAr : Placing ethaddr write and read within CONFIG_CMD_NET
On 5/4/2010 5:48 PM, Tom Rix wrote:
+#endif
} else if (!strcmp(argv[1], "print")) {
if (chip->cpufreq == -1)
@@ -274,13 +287,14 @@ int do_chip_config(cmd_tbl_t *cmdtp, int flag,
int argc, char *argv[])
else
printf("DDR Type= Not Known\n");
+#if defined(CONFIG_CMD_NET)
if (!i2c_read_mac(mac)) {
sprintf(i2c_mac, "%pM", mac);
printf("Ethaddr (from i2c mem) = %s\n", i2c_mac);
} else {
printf("Ethaddr (from i2c mem) = Not set\n");
}
>>> From misc_init_r, the mac_id is stored in the enviromement.
>>> Because the enviroment has precendence over the i2c.
>>> Reporting the i2c mac address may be inconsistent or wrong.
>>>
>> The print in the chip_config print clearly says that this mac address
>> is set in i2c memory and in fact this is also the intention.
>>
>> Probably, I should add a comment saying ethaddr in environment
>> variable may be different and it is the one used as mac id in network
>> interface
>> OR should I add a print itself that this is the mac id stored in i2c
>> memory and may be stale ?
>
> The most useful one should be printed out.
>
> If the user is setting up a network service list dhcp that depends on
> the mac address, then the mac used by the u-boot network ip should be
> returned.
>
> If this is providing some board id and the i2c mac is unique, then
> the i2c mac should be used.
>
> What you don't want to happen is to confuse the user by reporting one
> mac and using another. Just printing out the the i2c mac may or may not
> be stale will also confuse the user.
I get your point. Though, I believe, educating the user about the mac id
storage behavior is the solution in this case.
Moreover, ethaddr is not set in environment variables by default. So,
the decision remains with the user as to where he wants to store the
ethaddr environment. This command has been introduced to report and save
mac id in i2c memory.
I would add a section regarding mac id storage and reporting in README.spear
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] Support for TI's DA850/OMAP-L138 platform
Hi Tom,
> -Original Message-
> From: Tom Rix [mailto:t...@bumblecow.com]
> Sent: Thursday, May 06, 2010 3:14 AM
> To: Sudhakar Rajashekhara
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH 0/3] Support for TI's DA850/OMAP-L138 platform
>
> Sudhakar Rajashekhara wrote:
> > This patch series adds support for TI's DA850/OMAP-L138
> > platform. This series is dependant on the following
> > patch which I have submitted earlier:
> >
> > [U-Boot] [PATCH] da830: Move common code out of da830evm.c file
> >
> > Sudhakar Rajashekhara (3):
> > TI: DaVinci: Prepare for da850 support
> > TI: DaVinci: Add board specific code for da850 EVM
> > TI: DaVinci: Create configuration file for da850 EVM
>
> I ran into
>
> da850evm.c:64: error: array type has incomplete element type
> da850evm.c: In function 'board_init':
> da850evm.c:75: warning: implicit declaration of function 'irq_init'
> da850evm.c:90: warning: implicit declaration of function
> 'davinci_configure_lpsc_items'
>
> Please check that this patchset still builds and rebase if necessary.
>
This patch set depends on one patch which I had submitted earlier
(http://lists.denx.de/pipermail/u-boot/2010-April/070383.html).
This patch was Acked by Nick Thompson but not yet pulled in. I have mentioned
about this dependency in patch 0/0. Can you try after
applying this patch?
Thanks,
Sudhakar
> Tom
>
> >
> > MAINTAINERS |4 +
> > MAKEALL |1 +
> > Makefile|5 +-
> > arch/arm/include/asm/arch-davinci/hardware.h|1 +
> > board/davinci/{da830evm => da8xxevm}/Makefile |5 +-
> > board/davinci/{da830evm => da8xxevm}/config.mk |0
> > board/davinci/{da830evm => da8xxevm}/da830evm.c |0
> > board/davinci/da8xxevm/da850evm.c | 111 +++
> > include/configs/da850evm.h | 135
> > +++
> > 9 files changed, 260 insertions(+), 2 deletions(-)
> > rename board/davinci/{da830evm => da8xxevm}/Makefile (91%)
> > rename board/davinci/{da830evm => da8xxevm}/config.mk (100%)
> > rename board/davinci/{da830evm => da8xxevm}/da830evm.c (100%)
> > create mode 100644 board/davinci/da8xxevm/da850evm.c
> > create mode 100644 include/configs/da850evm.h
> >
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot
> >
> >
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Help me on finding board similar to NIC card in U-bootloader
Hello, I am having a new NIC card and i have to develop U-boot Loader for that.Can any one help me which board name in U-Boot source code having similar kind of features( PHY, MAC ) for cloning that to my new NIC target card.This NIC card is communicating through PCIe to host,my NIC card is having the following H/W details. 1.CN63xx processor(Cavium network) 2.NAND Flash device : MT29F16G08ABABA 3.NOR Flash device : JS28F320J3D75 4.EEPROM : AT24C256B, AT25F1024 5.PSRAM : MT45W1MW16PD 6.DDR3SDRAM :MT41J128M16 7.*BCM8727* dual 10 GbE SFI-to-XAUI PHY I think U-bootloader dont have Cavium support processors.so can u consider other H/W details for finding board name. Thank u. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Endless loop in cmd_log.c?
Not sure why this hasn't come through in my 2 earlier attempts... I am trying to implement CONFIG_LOGBUFFER and CONFIG_CMD_LOG on our ARM systems and I seem to have run into an endless loop. With loglevel=5 so we still see our console output, the printf at the end of logbuff_printk appears to create an endless loop. I had to replace that line with serial_puts(msg); Have I missed some other solution or do the systems that use this never set logbuffer higher than default_message_loglevel? DaR ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-i2c
Hello Wolfgang, please pull from u-boot-i2c The following changes since commit b88c5988db176a0f9de5598d5167ee2498637d40: Kim Phillips (1): configs: remove unused CONFIG_COMMAND_HISTORY are available in the git repository at: git://git.denx.de/u-boot-i2c.git master Mike Frysinger (1): Blackfin: TWI/I2C: implement multibus support drivers/i2c/bfin-twi_i2c.c | 169 1 files changed, 108 insertions(+), 61 deletions(-) bye Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND:PATCH-V4] OMAP3EVM: Added NAND support
> -Original Message- > From: Wolfgang Denk [mailto:w...@denx.de] > Sent: Thursday, May 06, 2010 1:31 AM > To: Hiremath, Vaibhav > Cc: u-boot@lists.denx.de > Subject: Re: [U-Boot] [RESEND:PATCH-V4] OMAP3EVM: Added NAND support > > Dear hvaib...@ti.com, > > In message <1272034546-26041-2-git-send-email-hvaib...@ti.com> you wrote: > > > > diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h > > index 0d99f7d..1d31731 100644 > > --- a/include/configs/omap3_evm.h > > +++ b/include/configs/omap3_evm.h > > @@ -151,7 +151,8 @@ > > > > #define CONFIG_CMD_I2C /* I2C serial bus support */ > > #define CONFIG_CMD_MMC /* MMC support */ > > -#define CONFIG_CMD_ONENAND /* ONENAND support */ > > +#undef CONFIG_CMD_ONENAND /* ONENAND support */ > > Please do not #undef what is not #define'd anyway. > [Hiremath, Vaibhav] This was the initial comment received from Nishanth Menon on very first path, and that's where I added undef line. The initial patch was something - > -#define CONFIG_CMD_ONENAND /* ONENAND support */ > +/*#define CONFIG_CMD_ONENAND*/ /* ONENAND support */ > +#define CONFIG_CMD_NAND/* NAND support */ I do agree that we don't have to undef here, but agreed to Nishant's comment only because from user point of view, if user would like to enable ONENAND support then for him it's easy he just have to comment NAND line and make change this #define. He doesn't have to dig inside code to find out whether ONENAND is supported or not. Thanks, Vaibhav > > 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: w...@denx.de > What is tolerance? -- it is the consequence of humanity. We are all > formed of frailty and error; let us pardon reciprocally each other's > folly -- that is the first law of nature. - Voltaire ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Wenn Sie unsere Dienstleistungen nutzen, dann konnen sich einen wurdigen Arbeitsplatz finden!
Hallo, Lieber Leser, entschuldigen Sie uns Bitte, aber moglich ist folgende Information fur Sie wichtig. Wir sind ein Unternehmen aus Emden Stadt (Deutschland), und wir sind seit langerer Zeit auf dem Personalkoordinierungsmarkt erfolgreich tatig. Bis Heute haben wir nach dem Auftrag unserer Kunden an die fuhrenden Gesellschaften der Europaischer Union Personal vermittelt. In dem vergangenem Monat hat die Arbeitslosigkeitsquote ca 8.5 Prozent betragen. Dem zur Folge sind im Deutschland uber 3.5 Millionen Menschen ohne Arbeit. Von der Anzahl der Arbeitslosen befindet sich die Mehrheit mit uber 2.42 Millionen in den Alten Bundeslander. Der Prozentsatz der Arbeitslosen in den Neun Bundeslander ist aber mit 13.5 Prozent fast um das Zweifache hoher. Seit uber einem Jahrzehnt bluht in Deutschland das Geschaft der Unternehmen die mit der Personalverleihung sich eine Zukunft aufbauen. Wir sind keine Leihfirma, wir koordinieren das Personal. Wenn ein Unternehmen einem Fachman sucht, dann treten wir ins Spiel. Unsere Gesellschaft verhilft Jedem bei der Suche einer Arbeitsstelle, der Bewerbung bei den richtigen Unternehmen und der Einschulung in die neue Tatigkeit. Ab Sofort sind unsere Dienste fur Jede Privatperson kostenlos. Bis zu dem Zeitpunkt an dem Sie von unserer Gesellschaft an ein Unternehmen ubergeben werden konnen Sie sich fur die Teilnahme an den Forschungstudien des Dienstleistungsmarktes melden. Die Teilnahme wird Immer entlohnt. Wenn Sie diesem Weg zu neuer Arbeitsstelle gehen mochten, oder einfach an den Forschungstudien teilnehmen mochten, dann melden Sie sich bei uns mit einer Mail. In dieser Mail bitten wir Sie hoflichst uns folgende Informationen zu ubermitteln: Vor- und Nachname, Geburtsdatum, Wohnort wie auch ihre Handy- und Festnetznummer. Bitte teilen Sie uns auch mit zu welcher Tageszeit unserer Manager Sie telefonisch erreichen kann. Wenn Sie interessiert an einer Arbeitsstelle sind, oder einfach an den Studien teilnehmen mochten, dann schreiben Sie uns Bitte eine Mail mit dem obenerlauterten Inhalt an folgende E-Mail-Adresse: i...@mail-pdl-es.com In der Hoffnung Ihnen mit unserem Projekt helfen zu konnen, PDL-SOLUTIONS ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH-V2 2/4] omap3: Consolidate SDRC related operations
> -Original Message-
> From: Wolfgang Denk [mailto:w...@denx.de]
> Sent: Thursday, May 06, 2010 1:38 AM
> To: Hiremath, Vaibhav
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH-V2 2/4] omap3: Consolidate SDRC related
> operations
>
> Dear hvaib...@ti.com,
>
[Hiremath, Vaibhav] Thanks Denk for your comments, see my response below -
> In message <1272034546-26041-4-git-send-email-hvaib...@ti.com> you wrote:
> > From: Vaibhav Hiremath
> >
> > Consolidated SDRC related functions into one file - sdrc.c
> >
> > And also replaced sdrc_init with generic memory init
> > function (mem_init), this generalization of omap memory setup
> > is necessary to support the new emif4 interface introduced in AM3517.
> >
> > Signed-off-by: Vaibhav Hiremath
> > Signed-off-by: Sanjeev Premi
>
> > diff --git a/arch/arm/cpu/arm_cortexa8/omap3/Makefile
> b/arch/arm/cpu/arm_cortexa8/omap3/Makefile
> > index 136b163..8cc7802 100644
> > --- a/arch/arm/cpu/arm_cortexa8/omap3/Makefile
> > +++ b/arch/arm/cpu/arm_cortexa8/omap3/Makefile
> > @@ -33,6 +33,9 @@ COBJS += board.o
> > COBJS += clock.o
> > COBJS += gpio.o
> > COBJS += mem.o
> > +ifdef CONFIG_SDRC
> > +COBJS += sdrc.o
> > +endif
>
> Please don't use 'ifdef" here; instead, use `COBJS-$(CONFIG_SDRC)'
[Hiremath, Vaibhav] ok, will incorporate in next version.
>
> > diff --git a/arch/arm/include/asm/arch-omap3/cpu.h
> b/arch/arm/include/asm/arch-omap3/cpu.h
> > index aa8de32..a49af10 100644
> > --- a/arch/arm/include/asm/arch-omap3/cpu.h
> > +++ b/arch/arm/include/asm/arch-omap3/cpu.h
> > @@ -183,6 +183,7 @@ struct sms {
> > /* SDRC */
> > #ifndef __KERNEL_STRICT_NAMES
> > #ifndef __ASSEMBLY__
> > +#if defined(CONFIG_SDRC)
> > struct sdrc_cs {
> > u32 mcfg; /* 0x80 || 0xB0 */
> > u32 mr; /* 0x84 || 0xB4 */
> > @@ -215,6 +216,8 @@ struct sdrc {
> > u8 res4[0xC];
> > struct sdrc_cs cs[2]; /* 0x80 || 0xB0 */
> > };
> > +
> > +#endif /* CONFIG_SDRC */
>
> I don't like such a #ifdef here - it is absolutely necessary? Why?
>
[Hiremath, Vaibhav] Denk,
This is common file being used for all OMAP series of devices (OMAP2, OMAP3 and
AM35x family) and OMAP2/3 family supports SDRC controller and AM35x family
support EMIF4.
And due to this difference we need to add this #ifdef.
> > diff --git a/arch/arm/include/asm/arch-omap3/sys_proto.h
> b/arch/arm/include/asm/arch-omap3/sys_proto.h
> > index 34bd515..34e4e0d 100644
> > --- a/arch/arm/include/asm/arch-omap3/sys_proto.h
> > +++ b/arch/arm/include/asm/arch-omap3/sys_proto.h
> > @@ -31,8 +31,10 @@ void prcm_init(void);
> > void per_clocks_enable(void);
> >
> > void memif_init(void);
> > +#if defined(CONFIG_SDRC)
> > void sdrc_init(void);
> > void do_sdrc_init(u32, u32);
> > +#endif
>
> Ditto - please drop this #ifdef.
>
[Hiremath, Vaibhav] Same as above.
Thanks,
Vaibhav
>
> 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: w...@denx.de
> People seldom know what they want until you give them what they ask
> for.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH-V2 3/4] AM35x: Add support for AM3517EVM
> -Original Message- > From: Wolfgang Denk [mailto:w...@denx.de] > Sent: Thursday, May 06, 2010 1:42 AM > To: Hiremath, Vaibhav > Cc: u-boot@lists.denx.de > Subject: Re: [U-Boot] [PATCH-V2 3/4] AM35x: Add support for AM3517EVM > > Dear hvaib...@ti.com, > > In message <1272034546-26041-5-git-send-email-hvaib...@ti.com> you wrote: > > From: Vaibhav Hiremath > > > > This patch adds basic support for the AM3517EVM. > > It includes: > > - Board int file (.c and .h) > > - Default configuration file > > - Updates for Makefile > > > > Signed-off-by: Vaibhav Hiremath > > Signed-off-by: Sanjeev Premi > > --- > > Makefile |3 + > > arch/arm/include/asm/arch-omap3/mux.h | 36 +++ > > board/logicpd/am3517evm/Makefile | 47 > > board/logicpd/am3517evm/am3517evm.c | 76 ++ > > board/logicpd/am3517evm/am3517evm.h | 405 > + > > board/logicpd/am3517evm/config.mk | 30 +++ > > include/configs/am3517_evm.h | 297 > > 7 files changed, 894 insertions(+), 0 deletions(-) > > create mode 100644 board/logicpd/am3517evm/Makefile > > create mode 100644 board/logicpd/am3517evm/am3517evm.c > > create mode 100644 board/logicpd/am3517evm/am3517evm.h > > create mode 100644 board/logicpd/am3517evm/config.mk > > create mode 100644 include/configs/am3517_evm.h > > Entries to MAKEALL and MAINTAINERS missing. [Hiremath, Vaibhav] Ok, will add this in next version. > > > diff --git a/Makefile b/Makefile > > index 34f10ce..487ae73 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -3169,6 +3169,9 @@ omap3_zoom1_config : unconfig > > omap3_zoom2_config : unconfig > > @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 zoom2 logicpd omap3 > > > > +am3517_evm_config :unconfig > > + @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 am3517evm logicpd omap3 > > + > > smdkc100_config: unconfig > > @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 smdkc100 samsung s5pc1xx > > Please keep list sorted. > [Hiremath, Vaibhav] ok, will move up. > > diff --git a/arch/arm/include/asm/arch-omap3/mux.h > b/arch/arm/include/asm/arch-omap3/mux.h > > index 0c01c73..8ea47b6 100644 > > --- a/arch/arm/include/asm/arch-omap3/mux.h > > +++ b/arch/arm/include/asm/arch-omap3/mux.h > > @@ -283,6 +283,7 @@ > > /*Control and debug */ > > #define CONTROL_PADCONF_SYS_32K0x0A04 > > #define CONTROL_PADCONF_SYS_CLKREQ 0x0A06 > > +#define CONTROL_PADCONF_SYS_NRESWARM 0x0A08 > > #define CONTROL_PADCONF_SYS_NIRQ 0x01E0 > > #define CONTROL_PADCONF_SYS_BOOT0 0x0A0A > > #define CONTROL_PADCONF_SYS_BOOT1 0x0A0C > > CONTROL_PADCONF_SYS_NIRQ looks out of place here. [Hiremath, Vaibhav] ok I will place it appropriately. > And all this asks > to be converted into a proper C struct. [Hiremath, Vaibhav] This is following up the existing way of configuration like all other OMAP devices. I do agree that we need to clean this up. Can it be done in sub-sequent series of patches on top of this? Let AM3517EVm support goes in. What's your opinion on this? > > > diff --git a/board/logicpd/am3517evm/Makefile > b/board/logicpd/am3517evm/Makefile > > new file mode 100644 > > index 000..3c71fef > > --- /dev/null > > +++ b/board/logicpd/am3517evm/Makefile > ... > > +include $(SRCTREE)/rules.mk > > + > > +sinclude $(obj).depend > > + > > Don't add trailing empty lines. [Please check & fix globally.] > [Hiremath, Vaibhav] Ok, I will cross-check and will fix in next version. Thanks, Vaibhav > > 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: w...@denx.de > Any sufficiently advanced technology is indistinguishable from magic. > Clarke's Third Law - _Profiles of the Future_ (1962; rev. 1973) > ``Hazards of Prophecy: The Failure of Imagination'' ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH-V2 4/4] AM35x: Add support for EMIF4
> -Original Message- > From: Wolfgang Denk [mailto:w...@denx.de] > Sent: Thursday, May 06, 2010 1:44 AM > To: Hiremath, Vaibhav > Cc: u-boot@lists.denx.de > Subject: Re: [U-Boot] [PATCH-V2 4/4] AM35x: Add support for EMIF4 > > Dear hvaib...@ti.com, > > In message <1272034546-26041-6-git-send-email-hvaib...@ti.com> you wrote: > > From: Vaibhav Hiremath > > > > This patch adds support for the EMIF4 interface > > available in the AM35x processors. > > > > Signed-off-by: Vaibhav Hiremath > > Signed-off-by: Sanjeev Premi > > --- > > arch/arm/cpu/arm_cortexa8/omap3/Makefile|3 + > > arch/arm/cpu/arm_cortexa8/omap3/emif4.c | 168 > +++ > > arch/arm/include/asm/arch-omap3/cpu.h | 24 > > arch/arm/include/asm/arch-omap3/emif4.h | 79 + > > arch/arm/include/asm/arch-omap3/sys_proto.h |3 + > > 5 files changed, 277 insertions(+), 0 deletions(-) > > create mode 100644 arch/arm/cpu/arm_cortexa8/omap3/emif4.c > > create mode 100644 arch/arm/include/asm/arch-omap3/emif4.h > > > > diff --git a/arch/arm/cpu/arm_cortexa8/omap3/Makefile > b/arch/arm/cpu/arm_cortexa8/omap3/Makefile > > index 8cc7802..0a23fa5 100644 > > --- a/arch/arm/cpu/arm_cortexa8/omap3/Makefile > > +++ b/arch/arm/cpu/arm_cortexa8/omap3/Makefile > > @@ -36,6 +36,9 @@ COBJS += mem.o > > ifdef CONFIG_SDRC > > COBJS += sdrc.o > > endif > > +ifdef CONFIG_EMIF4 > > +COBJS += emif4.o > > +endif > > Don't use ifdef, use COBJS-$(CONFIG_EMIF4) instead. > > > diff --git a/arch/arm/include/asm/arch-omap3/sys_proto.h > b/arch/arm/include/asm/arch-omap3/sys_proto.h > > index 34e4e0d..7b425be 100644 > > --- a/arch/arm/include/asm/arch-omap3/sys_proto.h > > +++ b/arch/arm/include/asm/arch-omap3/sys_proto.h > > @@ -35,6 +35,9 @@ void memif_init(void); > > void sdrc_init(void); > > void do_sdrc_init(u32, u32); > > #endif > > +#if defined(CONFIG_EMIF4) > > +void emif4_init(void); > > +#endif > > I guess you can omit the #ifdef here, right? > [Hiremath, Vaibhav] Denk, We have OMAP families supporting both SDRC and EMIF4 (obviously mutually exclusive), so we need to add this #ifdef. Thanks, Vaibhav > 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: w...@denx.de > A failure will not appear until a unit has passed final inspection. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
