[U-Boot] [PATCH v3] mpc83xx: update LCRR register handling
MPC8379E RM says (10-34):
Once LCRR[CLKDIV] is written, the register should be read, and then
an isync should be executed.
So update this in code.
Also define a LCRR mask for processors, which uses not all bits
in the LCRR register (as for example mpc832x did).
Signed-off-by: Heiko Schocher h...@denx.de
---
changes since v1:
- added comment from DaveLiu. moved LCRR setting to
cpu_init_r()
changes since v2:
- added comment from Kim Phillips
changed LCRR_MASK to 0x7fff
use clrsetbits()
cpu/mpc83xx/cpu_init.c | 17 +
include/mpc83xx.h |5 +
2 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/cpu/mpc83xx/cpu_init.c b/cpu/mpc83xx/cpu_init.c
index ea4f2af..c51924f 100644
--- a/cpu/mpc83xx/cpu_init.c
+++ b/cpu/mpc83xx/cpu_init.c
@@ -23,8 +23,8 @@
#include common.h
#include mpc83xx.h
#include ioports.h
-#ifdef CONFIG_USB_EHCI_FSL
#include asm/io.h
+#ifdef CONFIG_USB_EHCI_FSL
#include usb/ehci-fsl.h
#endif
@@ -193,9 +193,6 @@ void cpu_init_f (volatile immap_t * im)
*/
im-reset.rmr = (RMR_CSRE (1RMR_CSRE_SHIFT));
- /* LCRR - Clock Ratio Register (10.3.1.16) */
- im-lbus.lcrr = CONFIG_SYS_LCRR;
-
/* Enable Time Base Decrimenter ( so we will have udelay() )*/
im-sysconf.spcr |= SPCR_TBEN;
@@ -329,8 +326,20 @@ void cpu_init_f (volatile immap_t * im)
int cpu_init_r (void)
{
+ volatile immap_t *im = (volatile immap_t *)CONFIG_SYS_IMMR;
#ifdef CONFIG_QE
uint qe_base = CONFIG_SYS_IMMR + 0x0010; /* QE immr base */
+#endif
+
+ /* LCRR - Clock Ratio Register (10.3.1.16) */
+ clrsetbits_be32(im-lbus.lcrr, LCRR_MASK, CONFIG_SYS_LCRR);
+ /* MPC8379E RM 10-34 says after writting this register
+* the register should be reread and an isync should be
+* executed.
+*/
+ in_be32(im-lbus.lcrr);
+
+#ifdef CONFIG_QE
qe_init(qe_base);
qe_reset();
#endif
diff --git a/include/mpc83xx.h b/include/mpc83xx.h
index 44115c9..15440b5 100644
--- a/include/mpc83xx.h
+++ b/include/mpc83xx.h
@@ -198,6 +198,7 @@
#define SICRL_URT_CTPR 0x0600
#define SICRL_IRQ_CTPR 0x00C0
+#define LCRR_MASK 0x7fff
#elif defined(CONFIG_MPC8313)
/* SICRL bits - MPC8313 specific */
#define SICRL_LBC 0x3000
@@ -1200,6 +1201,10 @@
#define PEX_GCLK_RATIO 0x440
+#if !defined(LCRR_MASK)
+#define LCRR_MASK 0x
+#endif
+
#ifndef __ASSEMBLY__
struct pci_region;
void mpc83xx_pci_init(int num_buses, struct pci_region **reg, int warmboot);
--
1.6.0.6
--
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] [PATCH 3/7] eSPI: add eSPI controller support
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Mike Frysinger Sent: Thursday, August 27, 2009 1:54 PM To: Hu Mingkai-B21284 Cc: u-boot@lists.denx.de; Fleming Andy-AFLEMING Subject: Re: [U-Boot] [PATCH 3/7] eSPI: add eSPI controller support On Wednesday 26 August 2009 23:01:52 Hu Mingkai-B21284 wrote: From: Mike Frysinger [mailto:vap...@gentoo.org] On Monday 16 March 2009 04:56:22 Hu Mingkai-B21284 wrote: But the eSPI controller integrate the chip select into the controller itself, it use the transfer length to control the duration of the chip select signal. so you must tell the controller ahead of time how many bytes are going to be transferred ? this sounds like a retarded hardware implementation to me. how exactly do you support arbitrary transfer lengths ? IIRC every transaction byte length control every transaction. but what if you dont know the length of the transaction ahead of time ? if you look at the spi flash framework, it'll write a few bytes (like the opcode to read the status register) and then it'll just keep reading 1 byte at a time (polling the status register). there is no way of knowing the length ahead of time. most of the SPI code in u-boot operates this way. So the driver use the length passed by SPI flash read function. If the length is greater than the max value that is limited by the transaction length register's bitfiled, the driver couldn't read anything. We'll dig into this issue for the furture. The spi_flash_cmd_* function split the transfer into two steps: first the command transfer and then the data transfer. At the first step, the transfer length is set to the command length, and when transferred the command, the chip select will be negated, so the eSPI controller thinks the transfer is cancelled and doesn't transfer the data again. the transfer state is passed in via the flags parameter. this way the SPI controller knows when a transfer starts (SPI_XFER_BEGIN) and when it ends (SPI_XFER_END). As above, we can't use the start/end flags parameter. then your controller wont be able to work with most (any?) of the code in u- boot. you need to reject every transfer that snt done with both BEGIN and END flags set. Looks like now. -mike Thanks, Mingkai ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/7] eSPI: add eSPI controller support
On Thursday 27 August 2009 02:27:30 Hu Mingkai-B21284 wrote: but what if you dont know the length of the transaction ahead of time ? if you look at the spi flash framework, it'll write a few bytes (like the opcode to read the status register) and then it'll just keep reading 1 byte at a time (polling the status register). there is no way of knowing the length ahead of time. most of the SPI code in u-boot operates this way. So the driver use the length passed by SPI flash read function. If the length is greater than the max value that is limited by the transaction length register's bitfiled, the driver couldn't read anything. the length used by the first read covers just the length of the opcode, not any of the data returned by the part as long as your driver rejects all of these things, it'll be detected at runtime and it should be fine to merge -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 3/7] eSPI: add eSPI controller support
-Original Message- From: Mike Frysinger [mailto:vap...@gentoo.org] Sent: Thursday, August 27, 2009 2:43 PM To: Hu Mingkai-B21284 Cc: u-boot@lists.denx.de; Fleming Andy-AFLEMING Subject: Re: [U-Boot] [PATCH 3/7] eSPI: add eSPI controller support On Thursday 27 August 2009 02:27:30 Hu Mingkai-B21284 wrote: but what if you dont know the length of the transaction ahead of time ? if you look at the spi flash framework, it'll write a few bytes (like the opcode to read the status register) and then it'll just keep reading 1 byte at a time (polling the status register). there is no way of knowing the length ahead of time. most of the SPI code in u-boot operates this way. So the driver use the length passed by SPI flash read function. If the length is greater than the max value that is limited by the transaction length register's bitfiled, the driver couldn't read anything. the length used by the first read covers just the length of the opcode, not any of the data returned by the part as long as your driver rejects all of these things, it'll be detected at runtime and it should be fine to merge -mike So the driver combine the opcode length and the data length together, then pass to spi_xfer(for eSPI) . When return the read results, skip the first opcode length bytes. Thanks, Mingkai ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/7] eSPI: add eSPI controller support
On Thursday 27 August 2009 02:59:34 Hu Mingkai-B21284 wrote:
From: Mike Frysinger [mailto:vap...@gentoo.org]
On Thursday 27 August 2009 02:27:30 Hu Mingkai-B21284 wrote:
but what if you dont know the length of the transaction ahead of
time ? if you look at the spi flash framework, it'll write a few
bytes (like the opcode to read the status
register) and then it'll just keep reading 1 byte at a time (polling
the status register). there is no way of knowing the length ahead
of time. most of the SPI code in u-boot operates this way.
So the driver use the length passed by SPI flash read function.
If the length is greater than the max value that is limited by the
transaction length register's bitfiled, the driver couldn't read
anything.
the length used by the first read covers just the length of
the opcode, not any of the data returned by the part
as long as your driver rejects all of these things, it'll be
detected at runtime and it should be fine to merge -mike
So the driver combine the opcode length and the data length together,
then pass to spi_xfer(for eSPI) . When return the read results, skip the
first opcode length bytes.
you dont get it ... there is no data length. the code does:
spi_write(~3 bytes for opcode, BEGIN flag);
while (1) {
spi_read(read 1 data byte);
check_result();
}
end_spi_transaction();
there is no data length which means your controller cannot support the SPI
flash framework
-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] problem with read only nanad
Hi, I'm working on a system having 2 NAND chips, the first one has the U-Boot and a basic firmware, and is read only, and the second has a new firmware. when the second chip is empty, the system should boot from the first chip. but it gives me many errors, probably related to the fact that it's readonly, does the u-boot tries to write something to the nand during startup? how can i solve this issue? thanks in advance Alex -- View this message in context: http://www.nabble.com/-U-Boot--problem-with-read-only-nanad-tp25167230p25167230.html Sent from the Uboot - Users mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-BOOT quiet build
Hi All, how to do quiet U-BOOT build? Mike: I think I saw in past any command which do it. Am I right? Thanks, Michal -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-BOOT quiet build
On Thursday 27 August 2009 03:48:52 Michal Simek wrote: how to do quiet U-BOOT build? you mean quiet build like you see with Linux/busybox/uClibc/etc..., u-boot doesnt support it. Wolfgang rejected the idea. there is silent build like anything else ... use make's -s flag -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] U-BOOT quiet build
Dear Mike Frysinger, In message 200908270409.16115.vap...@gentoo.org you wrote: you mean quiet build like you see with Linux/busybox/uClibc/etc..., u-boot doesnt support it. Wolfgang rejected the idea. That's not correct. I did not reject the _idea_. I just rejected the implementation. I think it is fundamentally wrong and broken to implement this feature which seems to be high valued in many projects again and again and again in each and every project's Makefile code. Instead, it should be implemented once where it actually belongs: in the make tool itself, so that _all_ projects can benefit from it without adding complexity and increased build times to their Makefiles. But like in so many cases people rather copy paste code around without actually thinking. there is silent build like anything else ... use make's -s flag ...or run ./MAKEALL name which has the added benefit of keeping full log files in the LOG/ directory in case anything should go wrong. 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 Probably the best operating system in the world is the [operating system] made for the PDP-11 by Bell Laboratories. - Ted Nelson, October 1977 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] use common code for Matrix Vision boards
On Wed, 2009-08-26 at 21:46 +0200, Wolfgang Denk wrote:
Dear =?ISO-8859-1?Q?Andr=E9?= Schwarz,
In message 1250682092.22118.8.ca...@swa-m460 you wrote:
clean up existing boards (mvBC-P/MPC5200 and mvBL-M7/MPC8343)
by using common code.
Signed-off-by: Andr=C3=A9 Schwarz andre.schw...@matrix-vision.de
---
Wolfgang,
this is my current diff against your latest master repository - I'm
unable to split it anymore.
Unfortunately the e1000 is currently not working on the mvBC-P but this
is due to changes in drivers/net/e1000.c ... using the last released
version is working fine. Will contact the maintainer to fix it.
Hopefully you'll nevertheless apply this patch so that everybody using
the boards can get up-to-date again.
Sorry for the late reply.
...
diff --git a/board/matrix_vision/mvbc_p/mvbc_p_autoscript
b/board/matrix_vision/mvbc_p/mvbc_p_autoscript
index 5cee6c5..1102354 100644
--- a/board/matrix_vision/mvbc_p/mvbc_p_autoscript
+++ b/board/matrix_vision/mvbc_p/mvbc_p_autoscript
@@ -5,7 +5,7 @@ setenv bootdtb bootm \${kernel_boot} \
${mv_initrd_addr_ram} \${mv_dtb_addr_ram}
setenv ramkernel setenv kernel_boot \${loadaddr}
setenv flashkernel setenv kernel_boot \${mv_kernel_addr}
setenv cpird cp \${mv_initrd_addr} \${mv_initrd_addr_ram} \
${mv_initrd_length}
-setenv bootfromflash run flashkernel cpird ramparam addcons e1000para
bootdtb
+setenv bootfromflash run flashkernel cpird ramparam addcons e1000para
addprofile bootdtb
Patch is linewrapped here and elsewhere and thus cannot be applied.
bloody eMail client :-(
The patch file definitely is *not* linewrapped.
Please fix and resubmit. Make sure to use git-send-email for sending.
I'll set up git-send-email and try to send the very same patch file.
Hopefully it will work as expected - sorry for the mess ...
Regards,
André
Thanks.
Best regards,
Wolfgang Denk
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner,
Hans-Joachim Reich
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5] use common code for Matrix Vision boards
clean up existing boards (mvBC-P/MPC5200 and mvBL-M7/MPC8343) by using common code. MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5] use common code for Matrix Vision boards
diff --git a/board/matrix_vision/mvbc_p/mvbc_p.c
b/board/matrix_vision/mvbc_p/mvbc_p.c
index a300342..0cbe900 100644
--- a/board/matrix_vision/mvbc_p/mvbc_p.c
+++ b/board/matrix_vision/mvbc_p/mvbc_p.c
@@ -39,6 +39,7 @@
#include asm/io.h
#include fpga.h
#include mvbc_p.h
+#include ../common/mv_common.h
#define SDRAM_MODE 0x00CD
#define SDRAM_CONTROL 0x504F
@@ -134,23 +135,6 @@ void mvbc_init_gpio(void)
printf(sint_gpioe : 0x%08x\n, gpio-sint_gpioe);
}
-void reset_environment(void)
-{
- char *s, sernr[64];
-
- printf(\n*** RESET ENVIRONMENT ***\n);
- memset(sernr, 0, sizeof(sernr));
- s = getenv(serial#);
- if (s) {
- printf(found serial# : %s\n, s);
- strncpy(sernr, s, 64);
- }
- gd-env_valid = 0;
- env_relocate();
- if (s)
- setenv(serial#, sernr);
-}
-
int misc_init_r(void)
{
char *s = getenv(reset_env);
@@ -166,7 +150,7 @@ int misc_init_r(void)
return 0;
}
printf( === FACTORY RESET ===\n);
- reset_environment();
+ mv_reset_environment();
saveenv();
return -1;
@@ -206,19 +190,28 @@ void flash_afterinit(ulong size)
void pci_mvbc_fixup_irq(struct pci_controller *hose, pci_dev_t dev)
{
unsigned char line = 0xff;
+ char *s = getenv(pci_latency);
u32 base;
+ u8 val = 0;
+
+ if (s)
+ val = simple_strtoul(s, NULL, 16);
if (PCI_BUS(dev) == 0) {
switch (PCI_DEV (dev)) {
case 0xa: /* FPGA */
line = 3;
pci_hose_read_config_dword(hose, dev,
PCI_BASE_ADDRESS_0, base);
- printf(found FPA - enable arbitration\n);
+ printf(found FPGA - enable arbitration\n);
writel(0x03, (u32*)(base + 0x80c0));
writel(0xf0, (u32*)(base + 0x8080));
+ if (val)
+ pci_hose_write_config_byte(hose, dev,
PCI_LATENCY_TIMER, val);
break;
case 0xb: /* LAN */
line = 2;
+ if (val)
+ pci_hose_write_config_byte(hose, dev,
PCI_LATENCY_TIMER, val);
break;
case 0x1a:
break;
@@ -234,85 +227,31 @@ struct pci_controller hose = {
fixup_irq:pci_mvbc_fixup_irq
};
-int mvbc_p_load_fpga(void)
-{
- size_t data_size = 0;
- void *fpga_data = NULL;
- char *datastr = getenv(fpgadata);
- char *sizestr = getenv(fpgadatasize);
-
- if (datastr)
- fpga_data = (void *)simple_strtoul(datastr, NULL, 16);
- if (sizestr)
- data_size = (size_t)simple_strtoul(sizestr, NULL, 16);
-
- return fpga_load(0, fpga_data, data_size);
-}
-
extern void pci_mpc5xxx_init(struct pci_controller *);
void pci_init_board(void)
{
- char *s;
- int load_fpga = 1;
-
mvbc_p_init_fpga();
- s = getenv(skip_fpga);
- if (s) {
- printf(found 'skip_fpga' - FPGA _not_ loaded !\n);
- load_fpga = 0;
- }
- if (load_fpga) {
- printf(loading FPGA ... );
- mvbc_p_load_fpga();
- printf(done\n);
- }
+ mv_load_fpga();
pci_mpc5xxx_init(hose);
}
-u8 *dhcp_vendorex_prep(u8 *e)
-{
- char *ptr;
-
- /* DHCP vendor-class-identifier = 60 */
- if ((ptr = getenv(dhcp_vendor-class-identifier))) {
- *e++ = 60;
- *e++ = strlen(ptr);
- while (*ptr)
- *e++ = *ptr++;
- }
- /* DHCP_CLIENT_IDENTIFIER = 61 */
- if ((ptr = getenv(dhcp_client_id))) {
- *e++ = 61;
- *e++ = strlen(ptr);
- while (*ptr)
- *e++ = *ptr++;
- }
-
- return e;
-}
-
-u8 *dhcp_vendorex_proc (u8 *popt)
-{
- return NULL;
-}
-
void show_boot_progress(int val)
{
struct mpc5xxx_gpio *gpio = (struct mpc5xxx_gpio*)MPC5XXX_GPIO;
switch(val) {
case 0: /* FPGA ok */
- setbits_be32(gpio-simple_dvo, 0x80);
+ setbits_be32(gpio-simple_dvo, LED_G0);
break;
- case 1:
- setbits_be32(gpio-simple_dvo, 0x40);
+ case 65:
+ setbits_be32(gpio-simple_dvo, LED_G1);
break;
case 12:
- setbits_be32(gpio-simple_dvo, 0x20);
+ setbits_be32(gpio-simple_dvo, LED_Y);
break;
case 15:
- setbits_be32(gpio-simple_dvo, 0x10);
+ setbits_be32(gpio-simple_dvo, LED_R);
break;
default:
break;
diff --git a/board/matrix_vision/mvbc_p/mvbc_p.h
b/board/matrix_vision/mvbc_p/mvbc_p.h
index
Re: [U-Boot] U-BOOT quiet build
On Thursday 27 August 2009 04:45:01 Wolfgang Denk wrote: Mike Frysinger wrote: you mean quiet build like you see with Linux/busybox/uClibc/etc..., u-boot doesnt support it. Wolfgang rejected the idea. That's not correct. I did not reject the _idea_. I just rejected the implementation. I think it is fundamentally wrong and broken to implement this feature which seems to be high valued in many projects again and again and again in each and every project's Makefile code. Instead, it should be implemented once where it actually belongs: in the make tool itself, so that _all_ projects can benefit from it without adding complexity and increased build times to their Makefiles. in reality, these equate to the same thing. the make tool isnt going to implement this stuff since it's pretty much impossible to cover all cases. automake has already integrated support so all automake-based packages get support for free. -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 v5] use common code for Matrix Vision boards
On Thu, 2009-08-27 at 10:55 +0200, Andre Schwarz wrote: clean up existing boards (mvBC-P/MPC5200 and mvBL-M7/MPC8343) by using common code. huh - two eMails ... this is definitely *not* what I wanted to do. Try to change the git-send-email behaviour. Wolfgang, does the patch apply or is it still messed up ? MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM926ej, trying to serve interrupt
Wolfang, Thank you very much for your answer. I've removed printf and any other dangerous code from do_irq. But it still hangs. Only timer interrupt is enabled. Then, serial driver can't generate interrupts. I've programmed timer to count 10secs and CPU hangs just then. I think my problem is that I am assuming that when CPU is interrupted, .irq: code in start.S is executed. Unfortunately, I don't quite understand start.S code, neither ARM926 architecture. Maybe I'm missing something important. Does ARM926 u-boot code by default support interrupt handling? Is it necesary to configure it further? Freescale's MPCxxx architectures include install_hdlr in order to register an interrupt handler for a concrete source. In ARM926ej, I expect CPU to automatically jump to do_irq when it is interrupted. Maybe, I'm being too optimistic ;S The code in start.S that I expect to get executed is. irq: get_irq_stack irq_save_user_regs bl do_irq irq_restore_user_regs But I can't see why CPU would jump to that address when interrupted. In other architectures, CPU jumps to a concrete address depending on interrupt source. With install_hdlr we define where to jump after. This example makes me think I'm missing a lot of things for ARM926... Regards, Ricardo -Mensaje original- De: Wolfgang Denk [mailto:w...@denx.de] Enviado el: miércoles, 26 de agosto de 2009 20:13 Para: Ricardo Martínez CC: u-boot@lists.denx.de Asunto: Re: [U-Boot] ARM926ej, trying to serve interrupt Dear =?iso-8859-1?Q?Ricardo_Mart=EDnez?=, In message !!AAAYAJp7zGtD32xAi3bhcLYAeQ3CgAAAEOIGRX5gEblKkejr+11M kvqba...@teltronic.es you wrote: I'm trying to printf something when one timer generates an interrupt. Hm... there are certain things you can do in interrupt contect, amd certain things you cannot do. Remember that in standard C you can in a signal handler only modify vailables of type sigatomic_t - you must not call any library functions, you must noit call any system calls. Well, in praxis you will probably find tat system calls are safe to call, and most library functions can be used as well - but nly when you know their implementation well enough to understand exactly what they are (not) doing. Calling a printf() [which internally may need to allocate buffers, and thus call malloc() and a lot of other complex functions] is something you must never do ina signal handler. Why do you think you can get away with the same here in U-Boot? Even in interrupt contxt, which is probably even more restricitve? u-boot version is 1.3.4. Old. OLD. I mean: OLD!!! Please update. The problem is that when timer generates interrupt (reaches 0 after several cycles), I expect default u-boot code do_irq, called from .irq: address defined in start.S get executed. In that function is where I want to printf anything to check it is working. But the whole system hangs. When timer generates the interrupt, ARM9 hangs without printing anything and normal execution is freezed. printf and serial driver work perfectly because I've checked the steps above with prinft debugguing. Is there any chance that the serial driver might be using interrupts, too, and that you run into some nested interrupt handling which is not or not correctly supported by U-Boot? 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 After a time, you may find that having is not so pleasing a thing, after all, as wanting. It is not logical, but it is often true. -- Spock, Amok Time, stardate 3372.7 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-BOOT quiet build
Dear Mike Frysinger, In message 200908270505.16659.vap...@gentoo.org you wrote: Instead, it should be implemented once where it actually belongs: in the make tool itself, so that _all_ projects can benefit from it without adding complexity and increased build times to their Makefiles. in reality, these equate to the same thing. the make tool isnt going to implement this stuff since it's pretty much impossible to cover all cases. Really? Has such a proposal been submitted and turned down? automake has already integrated support so all automake-based packages get support for free. I don't consider this a recommendation for automake or the makers of automake. YMMV, of course. 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 POP3 server service depends on the SMTP server service, which failed to start because of the following error: The operation comple- ted successfully. -- Windows NT Server v3.51 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5] use common code for Matrix Vision boards
Dear =?ISO-8859-1?Q?Andr=E9?= Schwarz, In message 1251364503.4053.7.ca...@swa-m460 you wrote: huh - two eMails ... this is definitely *not* what I wanted to do. Try to change the git-send-email behaviour. You may want to use --dry-run initially, and then test with a private address first. Wolfgang, does the patch apply or is it still messed up ? The patch (in message 2) applies cleanly, but it has neither commit message nor Signed-off-by: line (which is also not present in message 1). 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 For those who like this sort of thing, this is the sort of thing they like. - Abraham Lincoln ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-BOOT quiet build
Mike Frysinger wrote: On Thursday 27 August 2009 03:48:52 Michal Simek wrote: how to do quiet U-BOOT build? you mean quiet build like you see with Linux/busybox/uClibc/etc..., u-boot doesnt support it. Wolfgang rejected the idea. yep, I meant quiet mode like is in linux kernel and full mode with V=1. Michal there is silent build like anything else ... use make's -s flag -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] mpc83xx: update LCRR register handling
Hi Heiko, One minor critique, I had problems parsing the comment: Heiko Schocher wrote: MPC8379E RM says (10-34): Once LCRR[CLKDIV] is written, the register should be read, and then an isync should be executed. So update this in code. Also define a LCRR mask for processors, which uses not all bits ^^^ Suggested change: Also define a LCRR mask for processors to prevent setting any reserved bits in the LCRR register (as, for example, mpc832x did). in the LCRR register (as for example mpc832x did). Signed-off-by: Heiko Schocher h...@denx.de Thanks, gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-BOOT quiet build
Dear Mike Frysinger, In message 200908270643.12310.vap...@gentoo.org you wrote: Really? Has such a proposal been submitted and turned down? no idea, but i dont believe it is technically possible, thus it's a dead end i'm not going to waste time on Where exactly do you exect technical problems? 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 As in certain cults it is possible to kill a process if you know its true name. -- Ken Thompson and Dennis M. Ritchie ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5] use common code for Matrix Vision boards
Dear =?ISO-8859-1?Q?Andr=E9?= Schwarz, In message 1251374409.4053.28.ca...@swa-m460 you wrote: ok - checked various options to my private adress. I'm not sure which options you need checking; all I usually do is $ git send-email --to u-boot@lists.denx.de /tmp/patch Although I have now a valid commit message and a Signed-off-by: git send-mail keeps sending 2 mails. The first one with the commit message and the second containing the patch itself. Any hints ? And the file you feed in is something that was created using git format-patch ? 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
[U-Boot] [PATCH v6] use common code for Matrix Vision boards
clean up existing boards (mvBC-P/MPC5200 and mvBL-M7/MPC8343) by using common
code.
Signed-off-by: André Schwarz andre.schw...@matrix-vision.de
---
Wolfgang,
hopefully this is the last try - I'm close to nervous breakdown.
Applying the changes takes longer than actually doing them.
Of course this is due to me, I know.
Thanks for your patience,
André
board/matrix_vision/mvbc_p/mvbc_p.c | 97 +-
board/matrix_vision/mvbc_p/mvbc_p.h |2 +-
board/matrix_vision/mvbc_p/mvbc_p_autoscript | 10 ++-
board/matrix_vision/mvblm7/mvblm7.c | 54 ++
board/matrix_vision/mvblm7/mvblm7.h |3 +-
board/matrix_vision/mvblm7/pci.c | 35 ++
include/configs/MVBC_P.h |2 +-
include/configs/MVBLM7.h | 49 +
8 files changed, 77 insertions(+), 175 deletions(-)
diff --git a/board/matrix_vision/mvbc_p/mvbc_p.c
b/board/matrix_vision/mvbc_p/mvbc_p.c
index a300342..0cbe900 100644
--- a/board/matrix_vision/mvbc_p/mvbc_p.c
+++ b/board/matrix_vision/mvbc_p/mvbc_p.c
@@ -39,6 +39,7 @@
#include asm/io.h
#include fpga.h
#include mvbc_p.h
+#include ../common/mv_common.h
#define SDRAM_MODE 0x00CD
#define SDRAM_CONTROL 0x504F
@@ -134,23 +135,6 @@ void mvbc_init_gpio(void)
printf(sint_gpioe : 0x%08x\n, gpio-sint_gpioe);
}
-void reset_environment(void)
-{
- char *s, sernr[64];
-
- printf(\n*** RESET ENVIRONMENT ***\n);
- memset(sernr, 0, sizeof(sernr));
- s = getenv(serial#);
- if (s) {
- printf(found serial# : %s\n, s);
- strncpy(sernr, s, 64);
- }
- gd-env_valid = 0;
- env_relocate();
- if (s)
- setenv(serial#, sernr);
-}
-
int misc_init_r(void)
{
char *s = getenv(reset_env);
@@ -166,7 +150,7 @@ int misc_init_r(void)
return 0;
}
printf( === FACTORY RESET ===\n);
- reset_environment();
+ mv_reset_environment();
saveenv();
return -1;
@@ -206,19 +190,28 @@ void flash_afterinit(ulong size)
void pci_mvbc_fixup_irq(struct pci_controller *hose, pci_dev_t dev)
{
unsigned char line = 0xff;
+ char *s = getenv(pci_latency);
u32 base;
+ u8 val = 0;
+
+ if (s)
+ val = simple_strtoul(s, NULL, 16);
if (PCI_BUS(dev) == 0) {
switch (PCI_DEV (dev)) {
case 0xa: /* FPGA */
line = 3;
pci_hose_read_config_dword(hose, dev,
PCI_BASE_ADDRESS_0, base);
- printf(found FPA - enable arbitration\n);
+ printf(found FPGA - enable arbitration\n);
writel(0x03, (u32*)(base + 0x80c0));
writel(0xf0, (u32*)(base + 0x8080));
+ if (val)
+ pci_hose_write_config_byte(hose, dev,
PCI_LATENCY_TIMER, val);
break;
case 0xb: /* LAN */
line = 2;
+ if (val)
+ pci_hose_write_config_byte(hose, dev,
PCI_LATENCY_TIMER, val);
break;
case 0x1a:
break;
@@ -234,85 +227,31 @@ struct pci_controller hose = {
fixup_irq:pci_mvbc_fixup_irq
};
-int mvbc_p_load_fpga(void)
-{
- size_t data_size = 0;
- void *fpga_data = NULL;
- char *datastr = getenv(fpgadata);
- char *sizestr = getenv(fpgadatasize);
-
- if (datastr)
- fpga_data = (void *)simple_strtoul(datastr, NULL, 16);
- if (sizestr)
- data_size = (size_t)simple_strtoul(sizestr, NULL, 16);
-
- return fpga_load(0, fpga_data, data_size);
-}
-
extern void pci_mpc5xxx_init(struct pci_controller *);
void pci_init_board(void)
{
- char *s;
- int load_fpga = 1;
-
mvbc_p_init_fpga();
- s = getenv(skip_fpga);
- if (s) {
- printf(found 'skip_fpga' - FPGA _not_ loaded !\n);
- load_fpga = 0;
- }
- if (load_fpga) {
- printf(loading FPGA ... );
- mvbc_p_load_fpga();
- printf(done\n);
- }
+ mv_load_fpga();
pci_mpc5xxx_init(hose);
}
-u8 *dhcp_vendorex_prep(u8 *e)
-{
- char *ptr;
-
- /* DHCP vendor-class-identifier = 60 */
- if ((ptr = getenv(dhcp_vendor-class-identifier))) {
- *e++ = 60;
- *e++ = strlen(ptr);
- while (*ptr)
- *e++ = *ptr++;
- }
- /* DHCP_CLIENT_IDENTIFIER = 61 */
- if ((ptr = getenv(dhcp_client_id))) {
- *e++ = 61;
- *e++ = strlen(ptr);
- while (*ptr)
- *e++ = *ptr++;
- }
-
- return e;
-}
-
-u8 *dhcp_vendorex_proc (u8 *popt)
-{
-
[U-Boot] [RFC] OMAP3: make TWL4030 optional for MMC driver
Upcoming boards may power MMC card themself without using
TWL4030, so make it optional by using define CONFIG_TWL4030_MMC.
Enable this for all existing OMAP3 boards.
Signed-off-by: Matthias Ludwig mlud...@ultratronik.de
---
Current OMAP3 MMC driver does require TWL4030 support to
be enabled as all OMAP3 boards are using this chip. I'd like
to push patches for a new board which does not has a TWL4030
and is caring about MMC power by itself.
So, my suggestion is to make the TWL4030 dependency optional.
Are there better ways to to this can using a new define
CONFIG_TWL4030_MMC?
drivers/mmc/omap3_mmc.c |4
include/configs/omap3_beagle.h |1 +
include/configs/omap3_evm.h |1 +
include/configs/omap3_overo.h |1 +
include/configs/omap3_pandora.h |1 +
include/configs/omap3_zoom1.h |1 +
include/configs/omap3_zoom2.h |1 +
7 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/omap3_mmc.c b/drivers/mmc/omap3_mmc.c
index 9e09434..0ed88cb 100644
--- a/drivers/mmc/omap3_mmc.c
+++ b/drivers/mmc/omap3_mmc.c
@@ -27,8 +27,10 @@
#include fat.h
#include mmc.h
#include part.h
+#ifdef CONFIG_TWL4030_MMC
#include i2c.h
#include twl4030.h
+#endif
#include asm/io.h
#include asm/arch/mmc.h
@@ -63,7 +65,9 @@ unsigned char mmc_board_init(void)
{
t2_t *t2_base = (t2_t *)T2_BASE;
+#ifdef CONFIG_TWL4030_MMC
twl4030_power_mmc_init();
+#endif
writel(readl(t2_base-pbias_lite) | PBIASLITEPWRDNZ1 |
PBIASSPEEDCTRL0 | PBIASLITEPWRDNZ0,
diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
index 61629f8..e1cb759 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -132,6 +132,7 @@
/*
* TWL4030
*/
+#define CONFIG_TWL4030_MMC 1
#define CONFIG_TWL4030_POWER 1
#define CONFIG_TWL4030_LED 1
diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h
index 9f0f34b..b3c64a8 100644
--- a/include/configs/omap3_evm.h
+++ b/include/configs/omap3_evm.h
@@ -130,6 +130,7 @@
/*
* TWL4030
*/
+#define CONFIG_TWL4030_MMC 1
#define CONFIG_TWL4030_POWER 1
/*
diff --git a/include/configs/omap3_overo.h b/include/configs/omap3_overo.h
index 07a031b..983832d 100644
--- a/include/configs/omap3_overo.h
+++ b/include/configs/omap3_overo.h
@@ -118,6 +118,7 @@
/*
* TWL4030
*/
+#define CONFIG_TWL4030_MMC 1
#define CONFIG_TWL4030_POWER 1
#define CONFIG_TWL4030_LED 1
diff --git a/include/configs/omap3_pandora.h b/include/configs/omap3_pandora.h
index 1cfd7e9..0d87c71 100644
--- a/include/configs/omap3_pandora.h
+++ b/include/configs/omap3_pandora.h
@@ -121,6 +121,7 @@
/*
* TWL4030
*/
+#define CONFIG_TWL4030_MMC 1
#define CONFIG_TWL4030_POWER 1
#define CONFIG_TWL4030_LED 1
diff --git a/include/configs/omap3_zoom1.h b/include/configs/omap3_zoom1.h
index 61a41e7..1140052 100644
--- a/include/configs/omap3_zoom1.h
+++ b/include/configs/omap3_zoom1.h
@@ -128,6 +128,7 @@
/*
* TWL4030
*/
+#define CONFIG_TWL4030_MMC 1
#define CONFIG_TWL4030_POWER 1
#define CONFIG_TWL4030_LED 1
diff --git a/include/configs/omap3_zoom2.h b/include/configs/omap3_zoom2.h
index 03f92f5..40add99 100644
--- a/include/configs/omap3_zoom2.h
+++ b/include/configs/omap3_zoom2.h
@@ -149,6 +149,7 @@
/*
* TWL4030
*/
+#define CONFIG_TWL4030_MMC 1
#define CONFIG_TWL4030_POWER 1
#define CONFIG_TWL4030_LED 1
--
1.6.2.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Add ability for arch code to make changes before we boot
Added a arch_preboot_os() function that cpu specific code can implement to
allow for various modifications to the state of the machine right before
we boot. This can be useful to setup register state to a specific
configuration.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
* Just renamed arch_preboot to arch_preboot_os
common/cmd_bootm.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 86c8122..365ceeb 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -166,6 +166,13 @@ void __arch_lmb_reserve(struct lmb *lmb)
}
void arch_lmb_reserve(struct lmb *lmb) __attribute__((weak,
alias(__arch_lmb_reserve)));
+/* Allow for arch specific config before we boot */
+void __arch_preboot_os(void)
+{
+ /* please define platform specific arch_preboot_os() */
+}
+void arch_preboot_os(void) __attribute__((weak, alias(__arch_preboot_os)));
+
#if defined(__ARM__)
#define IH_INITRD_ARCH IH_ARCH_ARM
#elif defined(__avr32__)
@@ -543,6 +550,7 @@ int do_bootm_subcommand (cmd_tbl_t *cmdtp, int flag, int
argc, char *argv[])
break;
case BOOTM_STATE_OS_GO:
disable_interrupts();
+ arch_preboot_os();
boot_fn(BOOTM_STATE_OS_GO, argc, argv, images);
break;
}
@@ -673,6 +681,8 @@ int do_bootm (cmd_tbl_t *cmdtp, int flag, int argc, char
*argv[])
return 1;
}
+ arch_preboot_os();
+
boot_fn(0, argc, argv, images);
show_boot_progress (-9);
--
1.6.0.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] OMAP3: make TWL4030 optional for MMC driver
Maybe it would be better if the power_init function was removed from the
common file and moved to the individual board files. What do you think ?
Tom
Matthias Ludwig wrote:
Upcoming boards may power MMC card themself without using
TWL4030, so make it optional by using define CONFIG_TWL4030_MMC.
Enable this for all existing OMAP3 boards.
Signed-off-by: Matthias Ludwig mlud...@ultratronik.de
---
Current OMAP3 MMC driver does require TWL4030 support to
be enabled as all OMAP3 boards are using this chip. I'd like
to push patches for a new board which does not has a TWL4030
and is caring about MMC power by itself.
So, my suggestion is to make the TWL4030 dependency optional.
Are there better ways to to this can using a new define
CONFIG_TWL4030_MMC?
drivers/mmc/omap3_mmc.c |4
include/configs/omap3_beagle.h |1 +
include/configs/omap3_evm.h |1 +
include/configs/omap3_overo.h |1 +
include/configs/omap3_pandora.h |1 +
include/configs/omap3_zoom1.h |1 +
include/configs/omap3_zoom2.h |1 +
7 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/omap3_mmc.c b/drivers/mmc/omap3_mmc.c
index 9e09434..0ed88cb 100644
--- a/drivers/mmc/omap3_mmc.c
+++ b/drivers/mmc/omap3_mmc.c
@@ -27,8 +27,10 @@
#include fat.h
#include mmc.h
#include part.h
+#ifdef CONFIG_TWL4030_MMC
#include i2c.h
#include twl4030.h
+#endif
#include asm/io.h
#include asm/arch/mmc.h
@@ -63,7 +65,9 @@ unsigned char mmc_board_init(void)
{
t2_t *t2_base = (t2_t *)T2_BASE;
+#ifdef CONFIG_TWL4030_MMC
twl4030_power_mmc_init();
+#endif
writel(readl(t2_base-pbias_lite) | PBIASLITEPWRDNZ1 |
PBIASSPEEDCTRL0 | PBIASLITEPWRDNZ0,
diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
index 61629f8..e1cb759 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -132,6 +132,7 @@
/*
* TWL4030
*/
+#define CONFIG_TWL4030_MMC 1
#define CONFIG_TWL4030_POWER 1
#define CONFIG_TWL4030_LED 1
diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h
index 9f0f34b..b3c64a8 100644
--- a/include/configs/omap3_evm.h
+++ b/include/configs/omap3_evm.h
@@ -130,6 +130,7 @@
/*
* TWL4030
*/
+#define CONFIG_TWL4030_MMC 1
#define CONFIG_TWL4030_POWER 1
/*
diff --git a/include/configs/omap3_overo.h b/include/configs/omap3_overo.h
index 07a031b..983832d 100644
--- a/include/configs/omap3_overo.h
+++ b/include/configs/omap3_overo.h
@@ -118,6 +118,7 @@
/*
* TWL4030
*/
+#define CONFIG_TWL4030_MMC 1
#define CONFIG_TWL4030_POWER 1
#define CONFIG_TWL4030_LED 1
diff --git a/include/configs/omap3_pandora.h b/include/configs/omap3_pandora.h
index 1cfd7e9..0d87c71 100644
--- a/include/configs/omap3_pandora.h
+++ b/include/configs/omap3_pandora.h
@@ -121,6 +121,7 @@
/*
* TWL4030
*/
+#define CONFIG_TWL4030_MMC 1
#define CONFIG_TWL4030_POWER 1
#define CONFIG_TWL4030_LED 1
diff --git a/include/configs/omap3_zoom1.h b/include/configs/omap3_zoom1.h
index 61a41e7..1140052 100644
--- a/include/configs/omap3_zoom1.h
+++ b/include/configs/omap3_zoom1.h
@@ -128,6 +128,7 @@
/*
* TWL4030
*/
+#define CONFIG_TWL4030_MMC 1
#define CONFIG_TWL4030_POWER 1
#define CONFIG_TWL4030_LED 1
diff --git a/include/configs/omap3_zoom2.h b/include/configs/omap3_zoom2.h
index 03f92f5..40add99 100644
--- a/include/configs/omap3_zoom2.h
+++ b/include/configs/omap3_zoom2.h
@@ -149,6 +149,7 @@
/*
* TWL4030
*/
+#define CONFIG_TWL4030_MMC 1
#define CONFIG_TWL4030_POWER 1
#define CONFIG_TWL4030_LED 1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] OMAP3: make TWL4030 optional for MMC driver
Maybe it would be better if the power_init function was removed from the common file and moved to the individual board files. What do you think ? Tom Yes, sounds like a good idea. I also agree, looks like the more generic approach. Do you expect any problem when moving the call to twl4030_power_mmc_init into misc_init_r (in board/omap3/*/*.c) (of course bellow I2C init)? In a quick test it seem to work (at least compiles fine), but i cannot test it at the moment due to lack of hardware. best regards, Matthias ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fsl: simplify the mac id command, improve boot-time informational message
Wolfgang? Are you okay with this part of my patch? On Wed, Aug 19, 2009 at 9:40 AM, Kumar Galaga...@kernel.crashing.org wrote: On Aug 18, 2009, at 5:28 PM, Timur Tabi wrote: The mac id command took a 4-character parameter as the identifier string. However, for any given board, only one kind of identifier is acceptable, so it makes no sense to ask the user to type it in. Instead, if the user enters mac id, the identifier (and also the version, if it's NXID) will automatically be set to the correct value. Improve the message that is displayed when EEPROM is read during boot. It now displays EEPROM: and then either an error message or the EEPROM identifier if successful. If the identifier in EEPROM is valid, then always reject a bad CRC, even if the CRC field has not been initialized. Don't force the MAC address count to MAX_NUM_PORTS or less. Forcing the value to be changed resulting in an in-memory copy that does not match what's in hardware, even though the user did not request that change. Finally, always update the CRC value in the in-memory copy after any field is changed, so that the CRC is always correct. Signed-off-by: Timur Tabi ti...@freescale.com --- board/freescale/common/sys_eeprom.c | 79 +-- lib_ppc/board.c | 1 + 2 files changed, 48 insertions(+), 32 deletions(-) [snip] diff --git a/lib_ppc/board.c b/lib_ppc/board.c index 6dd4d56..59a56d5 100644 --- a/lib_ppc/board.c +++ b/lib_ppc/board.c @@ -889,6 +889,7 @@ void board_init_r (gd_t *id, ulong dest_addr) #endif #if defined (CONFIG_ID_EEPROM) || defined (CONFIG_SYS_I2C_MAC_OFFSET) + puts(EEPROM: ); mac_read_from_eeprom(); #endif Wolfgang, Please ack this bit. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- 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] [RFC] OMAP3: make TWL4030 optional for MMC driver
Send me the patch, I will test it. Tom Matthias Ludwig wrote: Maybe it would be better if the power_init function was removed from the common file and moved to the individual board files. What do you think ? Tom Yes, sounds like a good idea. I also agree, looks like the more generic approach. Do you expect any problem when moving the call to twl4030_power_mmc_init into misc_init_r (in board/omap3/*/*.c) (of course bellow I2C init)? In a quick test it seem to work (at least compiles fine), but i cannot test it at the moment due to lack of hardware. best regards, Matthias ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] OMAP3: make TWL4030 optional for MMC driver
Hmm, i recently notice, that only EVM (which i modified for testing) initialize I2C in misc_init_r... Is there a cause why this is handled different for evm than for beagle/overo/zoom[12]/,... Matthias On Thu, Aug 27, 2009 at 09:45:48AM -0500, Tom wrote: Send me the patch, I will test it. Tom Matthias Ludwig wrote: Maybe it would be better if the power_init function was removed from the common file and moved to the individual board files. What do you think ? Tom Yes, sounds like a good idea. I also agree, looks like the more generic approach. Do you expect any problem when moving the call to twl4030_power_mmc_init into misc_init_r (in board/omap3/*/*.c) (of course bellow I2C init)? In a quick test it seem to work (at least compiles fine), but i cannot test it at the moment due to lack of hardware. best regards, Matthias -- Matthias Ludwig, Software Development Ultratronik Entwicklungs GmbH, Gewerbestrasse 52, 82211 Herrsching, Germany http://www.ultratronik.de Tel: +49 8152 3709-356 Fax: +49 8152 5183 Registergericht Muenchen, HRB 55584 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 2/3] net: add phylib implementation
On Thu, Aug 27, 2009 at 01:54:47AM -0400, Mike Frysinger wrote:
On Thursday 27 August 2009 01:11:32 Stefan Roese wrote:
On Thursday 27 August 2009 03:55:57 Mike Frysinger wrote:
+int phy_init(void)
+{
+ /* Initialize the list */
+ INIT_LIST_HEAD(phy_drvs.list);
does it really need to be dynamic ? arent there static initializers so
this can be done in .data ?
Using static initializers fails on PPC because of the somewhat broken
relocation. So this dynamic implementation is the preferred version, at
least for PPC people.
so the ppc port cant use the .data section at all ? that doesnt sound
correct
to me.
We can't have initialized pointers in .data without manual runtime fixup.
Only .text has relocation information.
Someone tried to get proper relocation working a while ago, but ran into
toolchain bugs. Maybe current toolchains are better...
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/3] net: rework the mii support
On Wed, Aug 26, 2009 at 1:13 PM, Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com wrote: this rework is done in order to add a phylib and reduce and simplify the implementation of multi net_device support for the same driver precedently we pass the device name to the miiphy_read/write co now we pass the mii_device instance of the mii bus all network driver are switch to this way we currently keep the old miiphy api by wrapping it to the new mii_device api until we have the phylib implementation and all the network driver using it Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD --- I'm not going to be able to give this stuff a thorough review for a few days. Please don't interpret silence as either ACK or NAK. Initial glance looks promising though... Definitely please clean up the grammar as Mike suggests. regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] problem with read only nanad
On Thu, Aug 27, 2009 at 12:32:50AM -0700, alex889 wrote: Hi, I'm working on a system having 2 NAND chips, the first one has the U-Boot and a basic firmware, and is read only, and the second has a new firmware. when the second chip is empty, the system should boot from the first chip. but it gives me many errors, probably related to the fact that it's readonly, does the u-boot tries to write something to the nand during startup? how can i solve this issue? Depending on what the NAND controller driver requests, it could be trying to create an on-chip bad block table. If your flash is read only, then do not set NAND_USE_FLASH_BBT in the options -- or if you want to use an existing BBT but not create one if absent, provide a BBT description that lacks the NAND_BBT_CREATE option. If that's not it, then tell us which controller it is, and what sort of errors you're getting. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 2/3] net: add phylib implementation
On Thu, 2009-08-27 at 10:38 -0500, Scott Wood wrote:
On Thu, Aug 27, 2009 at 01:54:47AM -0400, Mike Frysinger wrote:
On Thursday 27 August 2009 01:11:32 Stefan Roese wrote:
On Thursday 27 August 2009 03:55:57 Mike Frysinger wrote:
+int phy_init(void)
+{
+ /* Initialize the list */
+ INIT_LIST_HEAD(phy_drvs.list);
does it really need to be dynamic ? arent there static initializers so
this can be done in .data ?
Using static initializers fails on PPC because of the somewhat broken
relocation. So this dynamic implementation is the preferred version, at
least for PPC people.
so the ppc port cant use the .data section at all ? that doesnt sound
correct
to me.
We can't have initialized pointers in .data without manual runtime fixup.
Only .text has relocation information.
Someone tried to get proper relocation working a while ago, but ran into
toolchain bugs. Maybe current toolchains are better...
X-ES's board's in U-Boot fully relocate to SDRAM with the
CONFIG_RELOC_FIXUP_WORKS define and -mrelocatable compiler flag. This
feature has worked with gcc-4.3.1/binutils-2.18.90 and
gcc-4.2.2/binutils-2.17.50.
Does anyone have a specific example of a toolchain that doesn't work?
It'd be great to get the issue figured out and get rid of all those
gd-reloc_off references that currently litter the code...
Peter
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] PowerPC -mrelocatable
Peter Tyser wrote: On Thu, 2009-08-27 at 10:38 -0500, Scott Wood wrote: Someone tried to get proper relocation working a while ago, but ran into toolchain bugs. Maybe current toolchains are better... X-ES's board's in U-Boot fully relocate to SDRAM with the CONFIG_RELOC_FIXUP_WORKS define and -mrelocatable compiler flag. This feature has worked with gcc-4.3.1/binutils-2.18.90 and gcc-4.2.2/binutils-2.17.50. Does anyone have a specific example of a toolchain that doesn't work? It'd be great to get the issue figured out and get rid of all those gd-reloc_off references that currently litter the code... According to these e-mails: http://lists.denx.de/pipermail/u-boot/2007-October/025937.html http://lists.denx.de/pipermail/u-boot/2007-October/025941.html it worked in (at least some) 4.0, but not (at least some) 3.x or 4.1. If we're now at the point where current GCC works, and has for several releases, we should probably consider revisiting those patches. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RTC value corruption on QIL-A9G20 startup
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Albin Tonnerre Sent: Tuesday, August 25, 2009 12:49 PM To: u-boot@lists.denx.de Subject: Re: [U-Boot] RTC value corruption on QIL-A9G20 startup On Tue, Aug 25, 2009 at 08:51:56AM -0400, Stephen Caudle wrote : Hello Eric, On Tue, Aug 25, 2009 at 5:38 AM, Eric Bénarde...@eukrea.com wrote: isn't the RTC connected to the SPI chip select that the internal firmware toggle on boot to probe for a SPI Flash ? That is certainly possible. This problem went away for me when I upgraded to the next branch. Could the SPI dataflash code have been removed between v2009.06 and next? I'll look into this some more. Thanks for the hint! Using the next branch doesn't help here. Anyway, the code Eric is referring to is the firmware code the CPU executes from its internal ROM very early in the boot process, so you likely won't find anything remotely related to this in U-Boot. Regards, -- Albin Tonnerre, Free Electrons Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com Has there been any resolution on this? From what I can see (with scope and logic analyzer) the RTC seems to be corrupted by the DataFlash boot code built into the chip. [The Calao board doesn't have the DataFlash memory and used the chip select for its RTC instead...] Has anyone found a smoking gun inside U-Boot or will we have to wait for Calao to make boards with the RTC on a different chip select? Thanks, Bill Landolina Technology Atlanta Corporation 500 Sugar Mill Road, Suite 202A Atlanta, GA 30350 (404) 303-0446 (Voice) (404) 303-0448 (FAX) (678) 596-3625 (Cell) w...@techatl.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 2/3] net: add phylib implementation
Mike Frysinger wrote:
On Thursday 27 August 2009 11:38:07 Scott Wood wrote:
On Thu, Aug 27, 2009 at 01:54:47AM -0400, Mike Frysinger wrote:
On Thursday 27 August 2009 01:11:32 Stefan Roese wrote:
On Thursday 27 August 2009 03:55:57 Mike Frysinger wrote:
+int phy_init(void)
+{
+/* Initialize the list */
+INIT_LIST_HEAD(phy_drvs.list);
does it really need to be dynamic ? arent there static initializers
so this can be done in .data ?
Using static initializers fails on PPC because of the somewhat broken
relocation. So this dynamic implementation is the preferred version, at
least for PPC people.
so the ppc port cant use the .data section at all ? that doesnt sound
correct to me.
We can't have initialized pointers in .data without manual runtime fixup.
Only .text has relocation information.
we're talking about a list structure and its initialized state, it isnt
pointing to anything.
It's pointing to itself.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] mpc83xx: update LCRR register handling
On Thu, 27 Aug 2009 08:20:35 +0200 Heiko Schocher h...@denx.de wrote: MPC8379E RM says (10-34): Once LCRR[CLKDIV] is written, the register should be read, and then an isync should be executed. So update this in code. Also define a LCRR mask for processors, which uses not all bits in the LCRR register (as for example mpc832x did). Signed-off-by: Heiko Schocher h...@denx.de --- changes since v1: - added comment from DaveLiu. moved LCRR setting to cpu_init_r() changes since v2: - added comment from Kim Phillips changed LCRR_MASK to 0x7fff use clrsetbits() Heiko - let's go with the SCCR approach of setting bits in the LCRR, and have board config files only specify values for fields they're modifying from the reset value for their processor (this can be extended to 85xx-world). Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] R: R: R: USB EHCI driver
Thanks Francesco. Does your patch for 2009.03 go over another EHCI patch for that version? Reason being, when I download 2009.03 I don't see most of the files your patch applies to. I still think I am missing something. I want to try to relpicate your success by applying your patch as you did. Group: is there a particular u-boot version in which substantial ehci host support was introduced within the drivers/usb/host directory? Any history on this will help me better understand what is or is not working (well) at this point. I'm fighting a root_port_hub() reset issue on the 5121e, after taking a patch from Francesco. I wedged his patch code into 2009.06. Basically, it looks like all the cpu-specific code needs to do is map the specific ehci register set on a particular cpu to a structure for the ehci code to use. In short, there is not much to Francesco's patch by way of protocol. He kindly did the register mapping via some initialization code for the 5121e, although the patch was not a clean fit so I hand entered what I needed to add. My issue is within the detection/discovery logic, where I am detecting a high-speed device (memory stick) via high-speed handshake, but I'm failing to reset the root port hub. I have a USB 2.0 analyzer. I see the successful high speed handshake with my device (memory stick), but nothing after that due to the internal root port hub issue. On Tue, Aug 18, 2009 at 3:01 AM, Rendine Francescofrancesco.rend...@valueteam.com wrote: Hi Mike, my patch for USB2.0 on MPC5121e is for u-boot-2009.03. I released for that version, so it's reasonable that doesn't fit well on 2009.06. Regard to your problem and log, as soon as I have time, I see your problem. Regards, Francesco. -Messaggio originale- Da: Mike Timmons [mailto:michael.joseph.timm...@gmail.com] Inviato: lun 8/17/2009 4:04 A: Rendine Francesco; u-boot@lists.denx.de Cc: Detlev Zundel; Mike Timmons Oggetto: Re: [U-Boot] R: R: USB EHCI driver All, I'm having trouble resetting my USB (virtual) root port hub following high speed handshake on the 5121e using USB0+UTMI on the mpc5121e. If anyone has any idea why root port hub reset typically fails, please advise. Thanks! Francesco, Thank you for your efforts on usb for the 5121e! I took your patch last week and applied it to u-boot-2009.06 the patch wasn't a perfect fit for some reason, but it was easy enough for me to extract the code from your patch file. What version did you intend the patch for, if not u-boot-2009.06? Regardless, I'm using a custom board based off the the ADS512101 board. I complete your initialization step and it appears I get the 5121e registers mapped correctly. USB start looks for devices, and I do see debug output to the console when I have a USB memory stick plugged in. I also have a USB analyzer, so I can see some action on the bus. However... It appears I am failing to reset the root port hub after the high-speed handshake between host and device (memory stick). My degree of USB ignorance is a painful limitation at this point. I'm tripping-through specs, the register set, and getting somewhat familiar with the sequencing, but I'm grinding my gears at this point. I attach a console log dump. A snippet of the log appears below, showing where/why the reset fails. I also attach a screen snap of my USB analyzer showing that some action is occurring on the wire between the host and the device (memory stick). This root port hub reset issue appears to be killing any subsequent device discovery efforts. I DID try the hack of ignoring the reset failure to see what happens. In this case I do see 2 devices detected in the console log (root hub plus my stick I presume), but I see no additional bus traffic on the analyzer so I figure the reset failure is my smoking gun. Any ideas? console log snippet (see attached full console log dump) hub_port_reset: resetting port 0... usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x1 length 0x0 req=3 (0x3), type=35 (0x23), value=4, index=1 Len is 0 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 req=0 (0x0), type=163 (0xa3), value=0, index=1 portstatus 101, change 13, 12 Mb/s STAT_C_CONNECTION = 1 STAT_CONNECTION = 1 USB_PORT_STAT_ENABLE 0 cannot reset port 1!? port 1 reset change usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x1 length 0x 0 req=1 (0x1), type=35 (0x23), value=20, index=1 Len is 0 1 USB Device(s) found scanning bus for storage devices... i=0 i=1 0 Storage Device(s) found = On Wed, Jun 24, 2009 at 4:08 AM, Rendine Francesco francesco.rend...@valueteam.com wrote: Hi, thanks for your compliments, but I think that there is some work to do about this driver to support OTG mode and gadget mode. For now I enabled support to host mode, and from my test does it work. I'm preparing the patch, and this will carry away some
Re: [U-Boot] RTC value corruption on QIL-A9G20 startup
Hi Willian, William C. Landolina a écrit : Has there been any resolution on this? From what I can see (with scope and logic analyzer) the RTC seems to be corrupted by the DataFlash boot code built into the chip. [The Calao board doesn't have the DataFlash memory and used the chip select for its RTC instead...] Has anyone found a smoking gun inside U-Boot or will we have to wait for Calao to make boards with the RTC on a different chip select? u-boot is executed after the bootrom so there is nothing to do on the software point of view. You can connect a RTC on the I2C ... Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Reset i2c slave devices during init on mpc5xxx cpus
Reset any i2c devices that may have been interrupted during a system reset.
Normally this would be accomplished by clocking the line until SCL and SDA
are released and then sending a start condtiion (From an Atmel datasheet).
There is no direct access to the i2c pins so instead create start commands
through the i2c interface. Send a start command then delay for the SDA Hold
time, repeat this by disabling/enabling the bus a total of 9 times.
Signed-off-by: Eric Millbrandt emillbra...@dekaresearch.com
---
Heiko,
I was able to implement a i2c reset function with features common to all
mpc5xxx cpu. Nothing was left from the first implementation, so I am
submitting this as a new patch.
Thanks
Eric
README |7 ++
cpu/mpc5xxx/i2c.c| 49 ++
include/configs/galaxy5200.h |1 +
3 files changed, 57 insertions(+), 0 deletions(-)
diff --git a/README b/README
index 246ae2b..6ccb2fe 100644
--- a/README
+++ b/README
@@ -1366,6 +1366,13 @@ The following options need to be configured:
therefore be cleared to 0 (See, eg, MPC823e User's Manual
p.16-473). So, set CONFIG_SYS_I2C_SLAVE to 0.
+ CONFIG_SYS_I2C_INIT_MPC5XXX
+
+ When a board is reset during an i2c bus transfer
+ chips might think that the current transfer is still
+ in progress. Reset the slave devices by sending start
+ commands until the slave device responds.
+
That's all that's required for CONFIG_HARD_I2C.
If you use the software i2c interface (CONFIG_SOFT_I2C)
diff --git a/cpu/mpc5xxx/i2c.c b/cpu/mpc5xxx/i2c.c
index 2341932..70a46be 100644
--- a/cpu/mpc5xxx/i2c.c
+++ b/cpu/mpc5xxx/i2c.c
@@ -207,6 +207,52 @@ static int receive_bytes(uchar chip, char *buf, int len)
return 0;
}
+#if defined(CONFIG_SYS_I2C_INIT_MPC5XXX)
+
+#define FDR510(x) (u8) (((x 0x20) 3) | (x 0x3))
+#define FDR432(x) (u8) ((x 0x1C) 2)
+/*
+ * Reset any i2c devices that may have been interrupted during a system reset.
+ * Normally this would be accomplished by clocking the line until SCL and SDA
+ * are released and then sending a start condtiion (From an Atmel datasheet).
+ * There is no direct access to the i2c pins so instead create start commands
+ * through the i2c interface. Send a start command then delay for the SDA Hold
+ * time, repeat this by disabling/enabling the bus a total of 9 times.
+ */
+static void send_reset()
+{
+ struct mpc5xxx_i2c *regs = (struct mpc5xxx_i2c *)I2C_BASE;
+ int i;
+ u32 delay;
+ u8 fdr;
+ int SDA_Tap[] = { 3, 3, 4, 4, 1, 1, 2, 2};
+ struct mpc5xxx_i2c_tap scltap[] = {
+ {4, 1},
+ {4, 2},
+ {6, 4},
+ {6, 8},
+ {14, 16},
+ {30, 32},
+ {62, 64},
+ {126, 128}
+ };
+
+ fdr = (u8)mpc_reg_in(regs-mfdr);
+
+ delay = scltap[FDR432(fdr)].scl2tap + ((SDA_Tap[FDR510(fdr)] - 1) * \
+ scltap[FDR432(fdr)].tap2tap) + 3;
+
+ for (i = 0; i 9; i++) {
+ mpc_reg_out(regs-mcr, I2C_EN|I2C_STA|I2C_TX, I2C_INIT_MASK);
+ udelay(delay);
+ mpc_reg_out(regs-mcr, 0, I2C_INIT_MASK);
+ udelay(delay);
+ }
+
+ mpc_reg_out(regs-mcr, I2C_EN, I2C_INIT_MASK);
+}
+#endif /* CONFIG_SYS_I2c_INIT_MPC5XXX */
+
/ I2C API /
void i2c_init(int speed, int saddr)
@@ -225,6 +271,9 @@ void i2c_init(int speed, int saddr)
mpc_reg_out(regs-mcr, I2C_EN, I2C_INIT_MASK);
mpc_reg_out(regs-msr, 0, I2C_IF);
+#if defined(CONFIG_SYS_I2C_INIT_MPC5XXX)
+ send_reset();
+#endif
return;
}
diff --git a/include/configs/galaxy5200.h b/include/configs/galaxy5200.h
index 8d530d8..2ba5f0f 100644
--- a/include/configs/galaxy5200.h
+++ b/include/configs/galaxy5200.h
@@ -110,6 +110,7 @@
#define CONFIG_SYS_I2C_MODULE 2/* Select I2C module #1 or #2 */
#define CONFIG_SYS_I2C_SPEED 10/* 100 kHz */
#define CONFIG_SYS_I2C_SLAVE 0x7F
+#define CONFIG_SYS_I2C_INIT_MPC5XXX/* Reset devices on i2c bus */
/*
* EEPROM CAT24WC32 configuration
--
1.6.3.1
http://openwebmail.org - eem
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Add chip select region to galaxy5200
Add chip select region for an Epson S1D15313. Signed-off-by: Eric Millbrandt emillbra...@dekaresearch.com --- include/configs/galaxy5200.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/include/configs/galaxy5200.h b/include/configs/galaxy5200.h index eb2cae6..54c6b80 100644 --- a/include/configs/galaxy5200.h +++ b/include/configs/galaxy5200.h @@ -212,6 +212,11 @@ #define CONFIG_SYS_CS1_SIZE0x9 #define CONFIG_SYS_CS1_CFG 0x0002d900 +/* Chip Select configuration for Epson S1D13513 */ +#define CONFIG_SYS_CS3_START 0x1000 +#define CONFIG_SYS_CS3_SIZE0x103f +#define CONFIG_SYS_CS3_CFG 0x3d10 + /* * Ethernet configuration */ -- 1.6.3.1 http://openwebmail.org - eem ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: nand flash next
Dear Scott Wood, In message 20090826203829.ga25...@b07421-ec1.am.freescale.net you wrote: The following changes since commit d7f4d14a8b317857163ccf3d97e3b1a46ba2282e: Wolfgang Denk (1): Merge branch 'next' of git://www.denx.de/git/u-boot-coldfire into next are available in the git repository at: git://git.denx.de/u-boot-nand-flash.git next Heiko Schocher (1): 83xx, kmeter1: added NAND support Ilya Yanok (1): mxc_nand: add nand driver for MX2/MX3 Kyungmin Park (1): OneNAND: Remove unused read_spareram Matthias Kaehlcke (1): KB9202: Add NAND support Sandeep Paulraj (3): NAND: ADD page Parameter to all read_page/read_page_raw API's MTD:NAND: ADD new ECC mode NAND_ECC_HW_OOB_FIRST NAND: DaVinci: V2 Adding 4 BIT ECC support drivers/mtd/nand/Makefile|3 + drivers/mtd/nand/davinci_nand.c | 284 ++- drivers/mtd/nand/fsl_elbc_nand.c |2 +- drivers/mtd/nand/kb9202_nand.c | 150 + drivers/mtd/nand/kmeter1_nand.c | 135 + drivers/mtd/nand/mxc_nand.c | 880 ++ drivers/mtd/nand/nand_base.c | 75 +++- drivers/mtd/onenand/onenand_base.c |4 +- include/asm-arm/arch-davinci/emif_defs.h | 10 + include/configs/kmeter1.h|6 + include/linux/mtd/nand.h |5 +- include/linux/mtd/onenand.h |3 +- 12 files changed, 1540 insertions(+), 17 deletions(-) create mode 100644 drivers/mtd/nand/kb9202_nand.c create mode 100644 drivers/mtd/nand/kmeter1_nand.c create mode 100644 drivers/mtd/nand/mxc_nand.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 Memories of you remind me of you. - Karl Lehenbauer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-mpc83xx.git
Dear Kim Phillips, In message 20090826213528.ce5c76f5.kim.phill...@freescale.com you wrote: Hi Wolfgang Denk, Please pull a couple of minor fix patches for the upcoming release: The following changes since commit 85f9823cd74bd2d9a7854ca0b2244e43b5214e5a: Wolfgang Denk (1): Merge branch 'master' of git://git.denx.de/u-boot-ppc4xx are available in the git repository at: git://git.denx.de/u-boot-mpc83xx.git master Kim Phillips (2): mpc83xx: match dtb filename references to their dts equivalents in the linux kernel mpc83xx: mpc8349itx - accommodate larger kernel sizes unzero the bootdelay include/configs/MPC8349EMDS.h |2 +- include/configs/MPC8349ITX.h |6 +++--- include/configs/MPC8360ERDK.h |2 +- 3 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 Remember that Beethoven wrote his first symphony in C ... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6] use common code for Matrix Vision boards
Dear =?ISO-8859-1?Q?Andr=E9?= Schwarz, In message 1251377315.4053.39.ca...@swa-m460 you wrote: clean up existing boards (mvBC-P/MPC5200 and mvBL-M7/MPC8343) by using common code. Note (for next time): line too long. Signed-off-by: André Schwarz andre.schw...@matrix-vision.de --- Wolfgang, hopefully this is the last try - I'm close to nervous breakdown. Why? Just because one patch? Applying the changes takes longer than actually doing them. Yeah, that's true. Of course this is due to me, I know. Thanks for your patience, And yours. board/matrix_vision/mvbc_p/mvbc_p.c | 97 +--- -- board/matrix_vision/mvbc_p/mvbc_p.h |2 +- board/matrix_vision/mvbc_p/mvbc_p_autoscript | 10 ++- board/matrix_vision/mvblm7/mvblm7.c | 54 ++ board/matrix_vision/mvblm7/mvblm7.h |3 +- board/matrix_vision/mvblm7/pci.c | 35 ++ include/configs/MVBC_P.h |2 +- include/configs/MVBLM7.h | 49 + 8 files changed, 77 insertions(+), 175 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 If a packet hits a pocket on a socket on a port, And the bus is interrupted as a very last resort, And the address of the memory makes your floppy disk abort, Then the socket packet pocket has an error to report! - Ken Burchill? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add chip select region to galaxy5200
On Thu, Aug 27, 2009 at 4:11 PM, Eric Millbrandtemillbra...@coldhaus.com wrote: Add chip select region for an Epson S1D15313. Signed-off-by: Eric Millbrandt emillbra...@dekaresearch.com --- include/configs/galaxy5200.h | 5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/include/configs/galaxy5200.h b/include/configs/galaxy5200.h index eb2cae6..54c6b80 100644 --- a/include/configs/galaxy5200.h +++ b/include/configs/galaxy5200.h @@ -212,6 +212,11 @@ #define CONFIG_SYS_CS1_SIZE 0x9 #define CONFIG_SYS_CS1_CFG 0x0002d900 +/* Chip Select configuration for Epson S1D13513 */ +#define CONFIG_SYS_CS3_START 0x1000 +#define CONFIG_SYS_CS3_SIZE 0x103f +#define CONFIG_SYS_CS3_CFG 0x3d10 This doesn't look right. Shouldn't CONFIG_SYS_CS3_SIZE be 0x0040? (Compare with SYS_CS1 above) g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RTC value corruption on QIL-A9G20 startup
On Thu, Aug 27, 2009 at 1:48 PM, William C. Landolinaw...@techatl.com wrote: Has there been any resolution on this? From what I can see (with scope and logic analyzer) the RTC seems to be corrupted by the DataFlash boot code built into the chip. [The Calao board doesn't have the DataFlash memory and used the chip select for its RTC instead...] No resolution here. I am still seeing the problem (even on the next branch). This definitely seems to be caused by the processor boot ROM. Has anyone found a smoking gun inside U-Boot or will we have to wait for Calao to make boards with the RTC on a different chip select? I believe a hardware change is the only way to fix this problem. Regards, Stephen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
