Re: [U-Boot] RAM burst mode problem
Hi Mikhail,
Burst mode UPM setup is not trivial, and it is quite amount of work to
go through your table, so
I'm not surprised nobody has replied.
I assume you've verified the generated waveforms using a logic
analyzer/scope, and compared
them to the DRAMs datasheet (?). If you have access to a Windows
machine, you could try an
ancient Motorola tool called UPM860. It might be helpful when
verifying your UPM program.
Unless someone has experience with this certain DRAM I guess you're on
your own. Or.. you
could try to hire one of the engineers at Denx to do the job for you.
Good luck!
- Frank
On Wed, Sep 2, 2009 at 11:58 PM, Mikhail
Zaturenskiymzaturenskiy...@gmail.com wrote:
Hello, I am working on a board similar to the EP88xC and am having
trouble getting the sdram_table[] setup with the correct values (at
least I think that's the problem).
The board words fine if i burst-inhibit memc_or1 so I know single
read/write works, but if I remove burst-inhibit, it results in a crash
when U-Boot transfers itself from flash to RAM and jumps to the
relocated code.
My board uses the MPC875 processor and MT48LC16M16A2 for the RAM. The
following is my current SDRAM table:
static uint sdram_table[] = {
/* Single read (offset 0x00 in UPM RAM) */
0x0F03C004, 0x0FFFC004, 0x00FCC004, 0x0FFFC000,
0x0FF30004, 0x0FFFC004, 0xC005, 0xC005,
/* Burst read (offset 0x08 in UPM RAM) */
0x0F03C004, 0x0FFFC004, 0x00FCC004, 0x00FFC000,
0x00FFC000, 0x00FFC000, 0x00FFC000, 0x00FFC000,
0x00FFC000, 0x00FFC000, 0x0FF3, 0x0FFFC004,
0xC005, 0xC005, 0xC005, 0xC005,
/* Single write (offset 0x18 in UPM RAM) */
0x0F03C004, 0x0FFFC004, 0x00FC0004, 0x0FFFC002,
0x0FF30004, 0X0FFFC004, 0xC005, 0xC005,
/* Burst write (offset 0x20 in UPM RAM) */
0x0F03C004, 0x0FFFC004, 0x00FC0004, 0X00FFC000,
0x00FFC000, 0x00FFC000, 0x00FFC000, 0X00FFC000,
0x00FFC000, 0x00FFC000, 0x0FF30002, 0x0FFFC004,
0xC005, 0xC005, 0xC005, 0xC005,
/* Refresh (offset 0x30 in UPM RAM) */
0x0FF0C004, 0x0FFFC004, 0x0FFFC004, 0x0FFFC004,
0xC005, 0x0FA30004, 0x0FFFC004, 0x0FF0C084,
0x0FFFC004, 0x0FFFC004, 0x0FFFC004, 0x0FFFC084,
/* Exception (offset 0x3C in UPM RAM) */
0x0FFFC004, 0x0FF4, 0x0FFFC004, 0xC005
};
And the following is my ram init function:
phys_size_t initdram (int board_type)
{
long int msize;
volatile immap_t *immap = (volatile immap_t *)CONFIG_SYS_IMMR;
volatile memctl8xx_t *memctl = immap-im_memctl;
upmconfig(UPMA, sdram_table, sizeof(sdram_table) / sizeof(uint));
/* Configure SDRAM refresh */
memctl-memc_mptpr = MPTPR_PTP_DIV2; /* BRGCLK/2 */
memctl-memc_mamr = (65 24) | CONFIG_SYS_MAMR; /* No refresh */
udelay(100);
/* Run MRS pattern from location 0x35 */ // MZ - was 0x36
memctl-memc_mar = 0x46; // MZ - was 0x88
memctl-memc_mcr = 0x80002235; // MZ - was 0x80002236
udelay(100);
memctl-memc_mamr |= MAMR_PTAE; /* Enable refresh */
memctl-memc_or1 = ~(CONFIG_SYS_SDRAM_MAX_SIZE - 1) | OR_CSNT_SAM;
// memctl-memc_or1 = ~(CONFIG_SYS_SDRAM_MAX_SIZE - 1) | OR_CSNT_SAM
| OR_BI; // MZ - temp, burst inhibit
memctl-memc_br1 = CONFIG_SYS_SDRAM_BASE | BR_PS_16 | BR_MS_UPMA |
BR_V;
msize = get_ram_size(CONFIG_SYS_SDRAM_BASE,
CONFIG_SYS_SDRAM_MAX_SIZE);
memctl-memc_or1 |= ~(msize - 1);
return msize;
}
Also attached is a spreadsheet which illustrates the RAM timing.
Is there something wrong with my RAM table? Am I missing any flags?
Something else wrong?
Any ideas/suggestions are appreciated. Again, sorry for the first
poorly-formatted post.
Thank you,
Mikhail Zaturenskiy
Anyone?
___
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] boot linux data aboot for S3C2440A
what is wrong with me. [u-b...@s3c2440a]# nand read 0x30008000 0x0004 0x0020 NAND read: device 0 offset 0x4, size 0x20 2097152 bytes read: OK [u-b...@s3c2440a]# bootm 0x30008000 ## Booting kernel from Legacy Image at 30008000 ... Image Name: linux-2.6.30-5 Created: 2009-09-04 14:22:40 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1958132 Bytes = 1.9 MB Load Address: 30008000 Entry Point: 30008000 Verifying Checksum ... OK XIP Kernel Image ... OK OK Starting kernel ... data abort pc : [30008008]lr : [33fa36b4] sp : 33f4fcd0 ip : 33f4fce4 fp : 33f60a90 r10: 016a r9 : 0002 r8 : 33f4ffdc r7 : 33f4ffb8 r6 : r5 : r4 : r3 : 30008000 r2 : 3100 r1 : 016a r0 : Flags: nZCv IRQs off FIQs off Mode SVC_32 Resetting CPU ... 2009-09-04 fluke56512 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot environment on Sheevaplug
On Thu, 3 Sep 2009 23:20:02 -0700
Prafulla Wadaskar prafu...@marvell.com wrote:
I just wanted to check if there has been any progress on the issue
below (4-bit ECC support to read for the kernel / U-boot) during the
summer.
I am restarting work on this issue for u-boot,
Does anybody have any suggestions? Those are welcomed..
Good to hear!
I guess a starting point could be Nicolas patch for this to OpenOCD:
http://lists.berlios.de/pipermail/openocd-development/2009-May/006413.html
and/or the Reed-Solomon library in the Linux kernel,
lib/reed_solomon/{reed_solomon.c, decode_rs.c, encode_rs.c} (I guess
this will be needed to perform error correction and decoding as well).
// Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/4] tools: mkimage: Add: Kirkwood Boot Image support (kwbimage)
Hi Prafulla! I see the complications and understand that it might be difficult to get it running. On Thu, 3 Sep 2009 07:15:48 -0700 Prafulla Wadaskar prafu...@marvell.com wrote: I think it could also be useful to be able to produce just the boot header without the U-boot image. For example if you want to place U-boot at some other location on the flash or (as a developer) frequently re-flash U-boot, but don't want to write to the first block all the time (you only need to rewrite it when moving U-boot). This is not possible. Boot Header is a part of Kirkwood boot image, Header contains u-boot imagesize so for this, first block need to be written each time. Understandable. On the other hand, it should be possible to pad the U-boot image to some specific size to keep the size constant. Typically to the erase size. Secondly u-boot header is of 512bytes only whereas minimum sector size could be 4kbytes (typical), so rest part of first sector will be a waste. I'd be prepared to waste a couple of bytes :-) Also at the end of boot image checksum need to be calculated on entire image including header. This is not how I read the documentation. I thought the 32-bit checksum is for the image only, not the headers? Anyway, if it does include the headers, then I see why this would be impossible. Thanks for the explanation! // Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/4] tools: mkimage: Add: Kirkwood Boot Image support (kwbimage)
-Original Message- From: Simon Kagstrom [mailto:simon.kagst...@netinsight.net] Sent: Friday, September 04, 2009 12:00 PM To: Prafulla Wadaskar Cc: u-boot@lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik Subject: Re: [U-Boot] [PATCH v3 4/4] tools: mkimage: Add: Kirkwood Boot Image support (kwbimage) Hi Prafulla! I see the complications and understand that it might be difficult to get it running. Dear Simon So we can keep this complex enhancement for future updates, keeping this patch simpler On Thu, 3 Sep 2009 07:15:48 -0700 Prafulla Wadaskar prafu...@marvell.com wrote: I think it could also be useful to be able to produce just the boot header without the U-boot image. For example if you want to place U-boot at some other location on the flash or (as a developer) frequently re-flash U-boot, but don't want to write to the first block all the time (you only need to rewrite it when moving U-boot). This is not possible. Boot Header is a part of Kirkwood boot image, Header contains u-boot imagesize so for this, first block need to be written each time. Understandable. On the other hand, it should be possible to pad the U-boot image to some specific size to keep the size constant. Typically to the erase size. Again it would be problem it image size jumps over sector size boundary Secondly u-boot header is of 512bytes only whereas minimum sector size could be 4kbytes (typical), so rest part of first sector will be a waste. I'd be prepared to waste a couple of bytes :-) You will have to waste 128Kbytes-512bytes on sheevaplug :-) Finally you will waste one extra sector (u-boot.kwb size is ~160kb) Also at the end of boot image checksum need to be calculated on entire image including header. This is not how I read the documentation. I thought the 32-bit checksum is for the image only, not the headers? Anyway, if it does include the headers, then I see why this would be impossible. Currently it is done in the way I explained with some reference, I will do some exercise with your suggestions and let you know. Regards.. Prafulla . . Thanks for the explanation! // Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Odd value for I2C_TIMEOUT in fsl_i2c.c
Hello Timur,
Timur Tabi wrote:
Currently we define I2C_TIMEOUT like this:
#define I2C_TIMEOUT (CONFIG_SYS_HZ / 4)
I'm seeing some I2C instability on a new board I'm working on, especially
with SPD. If I change the above to
#define I2C_TIMEOUT (CONFIG_SYS_HZ / 2)
The problems go away (or at least, so far appear to). Can someone tell me
why we choose (CONFIG_SYS_HZ / 4) to begin with? The way we use I2C_TIMEOUT
is confusing:
while (readb(i2c_dev[i2c_bus_num]-sr) I2C_SR_MBB) {
if ((get_ticks() - timeval) usec2ticks(I2C_TIMEOUT))
return -1;
}
CONFIG_HZ is 1000, so I2C_TIMEOUT is equal to 250. However, the way it's
used, 250 isn't the number of ticks per second, it's used as number of
microseconds. If CONFIG_HZ is changed to 100, does that mean that we want to
call usec2ticks(25)?
This seems like a Bug to me.
I think what we should be doing is this:
#define I2C_TIMEOUT 1000
Surely, one millisecond is not too long of a timeout?
I think this should be Ok. Can you provide a patch?
Thanks for catching this.
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] [PATCH v3 4/4] tools: mkimage: Add: Kirkwood Boot Image support (kwbimage)
On Fri, 4 Sep 2009 00:17:57 -0700 Prafulla Wadaskar prafu...@marvell.com wrote: I see the complications and understand that it might be difficult to get it running. So we can keep this complex enhancement for future updates, keeping this patch simpler I agree, let's merge this patch first before thinking of some enhancements. // Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] boot linux data aboot for S3C2440A
fluke56512 a écrit : what is wrong with me. [u-b...@s3c2440a]# nand read 0x30008000 0x0004 0x0020 NAND read: device 0 offset 0x4, size 0x20 2097152 bytes read: OK Hello fluke56512, IIRC board with S3C2440A does not exist in the official versions of u-boot. Few attempts have been made[1], but without going futher. Or may be you are working on it? I planed to work on it with the cheap mini2440 board, but I am too busy for now. cheers, [1] http://lists.denx.de/pipermail/u-boot/2009-June/054887.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] License cleanup: remove all files with All Rights Reserved notices.
Dear Michal, In message c1a198be0909032328g56fa785ema485e0bd13c8a...@mail.gmail.com you wrote: drivers/net/ns9750_eth.c | 790 --- drivers/net/tigon3.c | 5697 drivers/net/tigon3.h | 3339 drivers/net/xilinx_emac.c | 464 -- This driver will be remove. I sent patch to Ben some days/week ago.Or of course you can remove. You mean the drivers/net/xilinx_emac.c driver? I've seen that patch. Thanks. drivers/net/xilinx_emaclite.c | 354 -- ... Wolfgang: It is driver in net tree. Is it going through you or Ben? I think it should go through Ben, but I can pick it up as well. The rest of xilinx files are related to ppc405/ppc440 and they don't have any connection with Microblaze. 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 universe contains any amount of horrible ways to be woken up, such as the noise of the mob breaking down the front door, the scream of fire engines, or the realization that today is the Monday which on Friday night was a comfortably long way off. - Terry Pratchett, _Moving Pictures_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/4] tools: mkimage: Add: Kirkwood Boot Image support (kwbimage)
Dear Simon Kagstrom, In message 20090904083003.3f7f0...@marrow.netinsight.se you wrote: Understandable. On the other hand, it should be possible to pad the U-boot image to some specific size to keep the size constant. Typically to the erase size. This makes no sense. Why would such padding be needed? It only adds overhead everywhere where the image needs to be processed, stored, downloaded, programmed, etc. 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 Conceptual integrity in turn dictates that the design must proceed from one mind, or from a very small number of agreeing resonant minds. - Frederick Brooks Jr., The Mythical Man Month ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] boot linux data aboot for S3C2440A
Dear fluke56512, In message 200909041501390422...@163.com you wrote: what is wrong with me. You mean, that you don't have a real name? Hm.. I'm afraid I cannot answer that. [u-b...@s3c2440a]# nand read 0x30008000 0x0004 0x0020 NAND read: device 0 offset 0x4, size 0x20 2097152 bytes read: OK [u-b...@s3c2440a]# bootm 0x30008000 ## Booting kernel from Legacy Image at 30008000 ... Image Name: linux-2.6.30-5 Created: 2009-09-04 14:22:40 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1958132 Bytes = 1.9 MB Load Address: 30008000 Entry Point: 30008000 Verifying Checksum ... OK XIP Kernel Image ... OK OK Starting kernel ... data abort Meybe you should provide a bit more information, like which versions of U-Boot and Linux you are using, how exactly you created the Linux kernel image, etc. And you should probably start and get a simple configuration (i. e. without funny stuff like XIP) running first, before you try such advanced things. 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 God is real, unless declared integer. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Odd value for I2C_TIMEOUT in fsl_i2c.c
Dear Timur Tabi, In message 4a9fdf1e.4090...@freescale.com you wrote: Currently we define I2C_TIMEOUT like this: #define I2C_TIMEOUT (CONFIG_SYS_HZ / 4) = 250, that is. CONFIG_HZ is 1000, so I2C_TIMEOUT is equal to 250. However, the way it's used, 250 isn't the number of ticks per second, it's used as number of microseconds. If CONFIG_HZ is changed to 100, does that mean that we want to call usec2ticks(25)? CONFIG_SYS_HZ is a constant of 1000. We do not change constants. Surely, one millisecond is not too long of a timeout? It definitely depends which sort of timeout this is. I guess there is some specification? 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 Don't put off for tomorrow what you can do today, because if you enjoy it today you can do it again tomorrow. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] s5pc1xx: support Samsung s5pc1xx SoC
This patch add support new SoCs that are s5pc100 and s5pc110 s5pc1xx SoC is ARM Cortex A8 processor Signed-off-by: Minkyu Kang mk7.k...@samsung.com Signed-off-by: HeungJun, Kim riverful@samsung.com --- cpu/arm_cortexa8/s5pc1xx/Makefile| 53 ++ cpu/arm_cortexa8/s5pc1xx/cache.c | 43 + cpu/arm_cortexa8/s5pc1xx/clock.c | 282 ++ cpu/arm_cortexa8/s5pc1xx/cpu_info.c | 71 cpu/arm_cortexa8/s5pc1xx/reset.S | 47 + cpu/arm_cortexa8/s5pc1xx/timer.c | 200 + include/asm-arm/arch-s5pc1xx/clk.h | 46 + include/asm-arm/arch-s5pc1xx/clock.h | 79 + include/asm-arm/arch-s5pc1xx/cpu.h | 73 include/asm-arm/arch-s5pc1xx/gpio.h | 127 ++ include/asm-arm/arch-s5pc1xx/hardware.h | 63 +++ include/asm-arm/arch-s5pc1xx/i2c.h | 43 + include/asm-arm/arch-s5pc1xx/interrupt.h | 40 + include/asm-arm/arch-s5pc1xx/keypad.h| 33 include/asm-arm/arch-s5pc1xx/mem.h | 58 ++ include/asm-arm/arch-s5pc1xx/power.h | 42 + include/asm-arm/arch-s5pc1xx/pwm.h | 65 +++ include/asm-arm/arch-s5pc1xx/uart.h | 72 18 files changed, 1437 insertions(+), 0 deletions(-) create mode 100644 cpu/arm_cortexa8/s5pc1xx/Makefile create mode 100644 cpu/arm_cortexa8/s5pc1xx/cache.c create mode 100644 cpu/arm_cortexa8/s5pc1xx/clock.c create mode 100644 cpu/arm_cortexa8/s5pc1xx/cpu_info.c create mode 100644 cpu/arm_cortexa8/s5pc1xx/reset.S create mode 100644 cpu/arm_cortexa8/s5pc1xx/timer.c create mode 100644 include/asm-arm/arch-s5pc1xx/clk.h create mode 100644 include/asm-arm/arch-s5pc1xx/clock.h create mode 100644 include/asm-arm/arch-s5pc1xx/cpu.h create mode 100644 include/asm-arm/arch-s5pc1xx/gpio.h create mode 100644 include/asm-arm/arch-s5pc1xx/hardware.h create mode 100644 include/asm-arm/arch-s5pc1xx/i2c.h create mode 100644 include/asm-arm/arch-s5pc1xx/interrupt.h create mode 100644 include/asm-arm/arch-s5pc1xx/keypad.h create mode 100644 include/asm-arm/arch-s5pc1xx/mem.h create mode 100644 include/asm-arm/arch-s5pc1xx/power.h create mode 100644 include/asm-arm/arch-s5pc1xx/pwm.h create mode 100644 include/asm-arm/arch-s5pc1xx/uart.h diff --git a/cpu/arm_cortexa8/s5pc1xx/Makefile b/cpu/arm_cortexa8/s5pc1xx/Makefile new file mode 100644 index 000..6ccb09a --- /dev/null +++ b/cpu/arm_cortexa8/s5pc1xx/Makefile @@ -0,0 +1,53 @@ +# +# (C) Copyright 2000-2003 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# (C) Copyright 2008 +# Guennadi Liakhovetki, DENX Software Engineering, l...@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 + +SOBJS = reset.o + +COBJS += timer.o +COBJS += clock.o +COBJS += cpu_info.o +COBJS += cache.o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS)) + +all:$(obj).depend $(LIB) + +$(LIB):$(OBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/cpu/arm_cortexa8/s5pc1xx/cache.c b/cpu/arm_cortexa8/s5pc1xx/cache.c new file mode 100644 index 000..8652a45 --- /dev/null +++ b/cpu/arm_cortexa8/s5pc1xx/cache.c @@ -0,0 +1,43 @@ +/* + * Copyright (C) 2009 Samsung Electronics + * Minkyu Kang mk7.k...@samsung.com + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a
[U-Boot] [PATCH 4/4] s5pc1xx: add support SMDKC100 board
Add new board SMDKC100 that uses s5pc100 SoC Signed-off-by: Minkyu Kang mk7.k...@samsung.com Signed-off-by: HeungJun, Kim riverful@samsung.com --- MAINTAINERS|4 + MAKEALL|1 + Makefile |3 + board/samsung/smdkc100/Makefile| 54 +++ board/samsung/smdkc100/config.mk | 16 ++ board/samsung/smdkc100/lowlevel_init.S | 221 + board/samsung/smdkc100/mem_setup.S | 198 ++ board/samsung/smdkc100/onenand.c | 98 + board/samsung/smdkc100/smdkc100.c | 51 +++ board/samsung/smdkc100/u-boot.lds | 63 + include/configs/smdkc100.h | 240 11 files changed, 949 insertions(+), 0 deletions(-) create mode 100644 board/samsung/smdkc100/Makefile create mode 100644 board/samsung/smdkc100/config.mk create mode 100644 board/samsung/smdkc100/lowlevel_init.S create mode 100644 board/samsung/smdkc100/mem_setup.S create mode 100644 board/samsung/smdkc100/onenand.c create mode 100644 board/samsung/smdkc100/smdkc100.c create mode 100644 board/samsung/smdkc100/u-boot.lds create mode 100644 include/configs/smdkc100.h diff --git a/MAINTAINERS b/MAINTAINERS index e4f3dee..5a93fa9 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -721,6 +721,10 @@ Alex Z lartSA1100 dnp1110 SA1110 +Minkyu Kang mk7.k...@samsung.com + + SMDKC100ARM CORTEX-A8 (S5PC100 SoC) + - Unknown / orphaned boards: diff --git a/MAKEALL b/MAKEALL index 03e8b7a..12bbbc5 100755 --- a/MAKEALL +++ b/MAKEALL @@ -587,6 +587,7 @@ LIST_ARM_CORTEX_A8=\ omap3_pandora \ omap3_zoom1 \ omap3_zoom2 \ + smdkc100\ # diff --git a/Makefile b/Makefile index 9d14210..36a94ca 100644 --- a/Makefile +++ b/Makefile @@ -3163,6 +3163,9 @@ omap3_zoom1_config : unconfig omap3_zoom2_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 zoom2 omap3 omap3 +smdkc100_config: unconfig + @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 smdkc100 samsung s5pc1xx + # ## XScale Systems # diff --git a/board/samsung/smdkc100/Makefile b/board/samsung/smdkc100/Makefile new file mode 100644 index 000..7d0b6b0 --- /dev/null +++ b/board/samsung/smdkc100/Makefile @@ -0,0 +1,54 @@ +# +# (C) Copyright 2000, 2001, 2002 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# (C) Copyright 2008 +# Guennadi Liakhovetki, DENX Software Engineering, l...@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$(BOARD).a + +COBJS-y:= smdkc100.o onenand.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 $(SOBJS) $(OBJS) + $(AR) $(ARFLAGS) $@ $(SOBJS) $(OBJS) + +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/samsung/smdkc100/config.mk b/board/samsung/smdkc100/config.mk new file mode 100644 index 000..ebab420 --- /dev/null +++ b/board/samsung/smdkc100/config.mk @@ -0,0 +1,16 @@ +# +# Copyright (C) 2008 # Samsung Elecgtronics +# Kyungmin Park kyungmin.p...@samsung.com +# + +# On S5PC100 we use the 128 MiB OneDRAM bank at +# +# 0x3000 to 0x3500 (80MiB) +# 0x3800 to 0x4000 (128MiB) +# +# On S5PC110 we use the 128 MiB OneDRAM bank at +# +# 0x3000 to 0x3500 (80MiB) +# 0x4000 to 0x4800
[U-Boot] [PATCH 2/4] s5pc1xx: support onenand driver
This patch includes the onenand driver for s5pc1xx
Signed-off-by: Minkyu Kang mk7.k...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/mtd/onenand/Makefile |2 +
drivers/mtd/onenand/samsung.c| 624 ++
include/linux/mtd/onenand.h |1 +
include/linux/mtd/onenand_regs.h |4 +
include/samsung_onenand.h| 91 ++
5 files changed, 722 insertions(+), 0 deletions(-)
create mode 100644 drivers/mtd/onenand/samsung.c
create mode 100644 include/samsung_onenand.h
diff --git a/drivers/mtd/onenand/Makefile b/drivers/mtd/onenand/Makefile
index 1d35a57..9317341 100644
--- a/drivers/mtd/onenand/Makefile
+++ b/drivers/mtd/onenand/Makefile
@@ -26,6 +26,8 @@ include $(TOPDIR)/config.mk
LIB:= $(obj)libonenand.a
COBJS-$(CONFIG_CMD_ONENAND):= onenand_uboot.o onenand_base.o onenand_bbt.o
+COBJS-$(CONFIG_S3C64XX)+= samsung.o
+COBJS-$(CONFIG_S5PC1XX)+= samsung.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/drivers/mtd/onenand/samsung.c b/drivers/mtd/onenand/samsung.c
new file mode 100644
index 000..af5d2d9
--- /dev/null
+++ b/drivers/mtd/onenand/samsung.c
@@ -0,0 +1,624 @@
+/*
+ * S3C64XX/S5PC1XX OneNAND driver at U-Boot
+ *
+ * Copyright (C) 2008-2009 Samsung Electronics
+ * Kyungmin Park kyungmin.p...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Implementation:
+ * Emulate the pseudo BufferRAM
+ */
+
+#include common.h
+#include malloc.h
+#include linux/mtd/compat.h
+#include linux/mtd/mtd.h
+#include linux/mtd/onenand.h
+
+#include samsung_onenand.h
+
+#include asm/io.h
+#include asm/errno.h
+
+#ifdef ONENAND_DEBUG
+#define DPRINTK(format, args...) \
+do { \
+ printf(%s[%d]: format \n, __func__, __LINE__, ##args); \
+} while (0)
+#else
+#define DPRINTK(...) do { } while (0)
+#endif
+
+#define ONENAND_ERASE_STATUS 0x00
+#define ONENAND_MULTI_ERASE_SET0x01
+#define ONENAND_ERASE_START0x03
+#define ONENAND_UNLOCK_START 0x08
+#define ONENAND_UNLOCK_END 0x09
+#define ONENAND_LOCK_START 0x0A
+#define ONENAND_LOCK_END 0x0B
+#define ONENAND_LOCK_TIGHT_START 0x0C
+#define ONENAND_LOCK_TIGHT_END 0x0D
+#define ONENAND_UNLOCK_ALL 0x0E
+#define ONENAND_OTP_ACCESS 0x12
+#define ONENAND_SPARE_ACCESS_ONLY 0x13
+#define ONENAND_MAIN_ACCESS_ONLY 0x14
+#define ONENAND_ERASE_VERIFY 0x15
+#define ONENAND_MAIN_SPARE_ACCESS 0x16
+#define ONENAND_PIPELINE_READ 0x4000
+
+#if defined(CONFIG_S3C64XX)
+#define AHB_ADDR 0x2000
+#define MAP_00 (0x0 24)
+#define MAP_01 (0x1 24)
+#define MAP_10 (0x2 24)
+#define MAP_11 (0x3 24)
+
+/* TODO Please verify it at s3c6400. It has different offsets */
+#define MEM_ADDR(fba, fpa, fsa)((fba) 12 | (fpa) 6 |
(fsa) 4)
+
+#elif defined(CONFIG_S5PC1XX)
+#define AHB_ADDR 0xB000
+#define MAP_00 (0x0 26)
+#define MAP_01 (0x1 26)
+#define MAP_10 (0x2 26)
+#define MAP_11 (0x3 26)
+
+#define MEM_ADDR(fba, fpa, fsa)((fba) 13 | (fpa) 7 |
(fsa) 5)
+#endif
+
+/* The 'addr' is byte address. It makes a 16-bit word */
+#define CMD_MAP_00(addr) (MAP_00 | ((addr) 1))
+#define CMD_MAP_01(mem_addr) (MAP_01 | (mem_addr))
+#define CMD_MAP_10(mem_addr) (MAP_10 | (mem_addr))
+#define CMD_MAP_11(addr) (MAP_11 | ((addr) 2))
+
+struct s3c_onenand {
+ struct mtd_info *mtd;
+
+ void __iomem*base;
+ void __iomem*ahb_addr;
+
+ int bootram_command;
+
+ void __iomem*page_buf;
+ void __iomem*oob_buf;
+
+ unsigned int(*mem_addr)(int fba, int fpa, int fsa);
+};
+
+static struct s3c_onenand *onenand;
+
+static int s3c_read_reg(int offset)
+{
+ return readl(onenand-base + offset);
+}
+
+static void s3c_write_reg(int value, int offset)
+{
+ writel(value, onenand-base + offset);
+}
+
+static int s3c_read_cmd(unsigned int cmd)
+{
+ return readl(onenand-ahb_addr + cmd);
+}
+
+static void s3c_write_cmd(int value, unsigned int cmd)
+{
+ writel(value, onenand-ahb_addr + cmd);
+}
+
+static unsigned int s5pc100_mem_addr(int fba, int fpa, int fsa)
+{
+ return (fba 13) | (fpa 7) | (fsa 5);
+}
+
+static void s3c_onenand_reset(void)
+{
+ unsigned long timeout = 0x1;
+ int stat;
+
+
Re: [U-Boot] Virtual addresses, u-boot, and the MMU
Becky Bruce wrote:
snip
This is where Detlev's comment about using the chance to define a
cache API comes into play.
Yes, we probably should create a set of functions like
enable_data_cache(address, size);
and
disable_data_cache(address, size);
which would turn on resp. off the caching attributes on the given
memory range.
snip
Using a completely different address range instead is a different
thing, and not what I have in mind. I really dislike the idea of
supporting alternate addresses in this context - even if this is
what would be easiest to implement on some architectures.
I agree, but, then, I'm coming from an architecture where doing this is
bad joo-joo. Again, it looks like AVR may actually need this -
hopefully someone who knows more about AVR will speak up here.
Although I wouldn't consider myself an AVR32 expert, I am following
this thread closely. It seems to me that the above 2 functions could be
used to support Detlev's idea as well as Haavard's map_physmem() idea.
The functions could also return (architecture dependant) a remapped
address to be used, then we could support:-
(1) AVR32-type cache which is based on different address ranges
Here the xxx_data_cache() functions would flush the cache, and return
a new address that points to the relevant cached / uncached section of
memory.
(2) Platforms with single address ranges but finer cache control
These would flush the cache, adjust the caching for the memory range as
required, and then just return the *same* address (since no address
re-mapping is required).
The functions using xxx_data_cache() would then code up as follows:-
void foo(address, size) {
uncached_address = disable_data_cache(address, size);
/*
* ... do some code using only uncached_address ...
*/
cached_address = enable_data_cache(address, size);
}
Regards
Mark
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] s5pc1xx: support serial driver
This patch includes the serial driver for s5pc1xx
Signed-off-by: Minkyu Kang mk7.k...@samsung.com
---
drivers/serial/Makefile |1 +
drivers/serial/serial_s5pc1xx.c | 250 +++
2 files changed, 251 insertions(+), 0 deletions(-)
create mode 100644 drivers/serial/serial_s5pc1xx.c
diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index 64882a2..3c77a7c 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -33,6 +33,7 @@ COBJS-$(CONFIG_NS9750_UART) += ns9750_serial.o
COBJS-$(CONFIG_SYS_NS16550) += ns16550.o
COBJS-$(CONFIG_DRIVER_S3C4510_UART) += s3c4510b_uart.o
COBJS-$(CONFIG_S3C64XX) += s3c64xx.o
+COBJS-$(CONFIG_S5PC1XX) += serial_s5pc1xx.o
COBJS-$(CONFIG_SYS_NS16550_SERIAL) += serial.o
COBJS-$(CONFIG_CLPS7111_SERIAL) += serial_clps7111.o
COBJS-$(CONFIG_IMX_SERIAL) += serial_imx.o
diff --git a/drivers/serial/serial_s5pc1xx.c b/drivers/serial/serial_s5pc1xx.c
new file mode 100644
index 000..4fd275e
--- /dev/null
+++ b/drivers/serial/serial_s5pc1xx.c
@@ -0,0 +1,250 @@
+/*
+ * (C) Copyright 2009 SAMSUNG Electronics
+ * Minkyu Kang mk7.k...@samsung.com
+ * Heungjun Kim riverful@samsung.com
+ *
+ * based on drivers/serial/s3c64xx.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include common.h
+#include asm/io.h
+#include asm/arch/uart.h
+#include asm/arch/clk.h
+
+#ifdef CONFIG_SERIAL0
+#define UART_NRS5PC1XX_UART0
+#elif defined(CONFIG_SERIAL1)
+#define UART_NRS5PC1XX_UART1
+#elif defined(CONFIG_SERIAL2)
+#define UART_NRS5PC1XX_UART2
+#elif defined(CONFIG_SERIAL3)
+#define UART_NRS5PC1XX_UART3
+#else
+#error Bad: you didn't configure serial ...
+#endif
+
+#define barrier() asm volatile( : : : memory)
+
+static inline s5pc1xx_uart_t *s5pc1xx_get_base_uart(enum s5pc1xx_uarts_nr nr)
+{
+ if (cpu_is_s5pc100())
+ return (s5pc1xx_uart_t *)(S5PC100_PA_UART + (nr * 0x400));
+ else
+ return (s5pc1xx_uart_t *)(S5PC110_PA_UART + (nr * 0x400));
+}
+
+/*
+ * The coefficient, used to calculate the baudrate on S5PC1XX UARTs is
+ * calculated as
+ * C = UBRDIV * 16 + number_of_set_bits_in_UDIVSLOT
+ * however, section 31.6.11 of the datasheet doesn't recomment using 1 for 1,
+ * 3 for 2, ... (2^n - 1) for n, instead, they suggest using these constants:
+ */
+static const int udivslot[] = {
+ 0,
+ 0x0080,
+ 0x0808,
+ 0x0888,
+ 0x,
+ 0x4924,
+ 0x4a52,
+ 0x54aa,
+ 0x,
+ 0xd555,
+ 0xd5d5,
+ 0xddd5,
+ 0x,
+ 0xdfdd,
+ 0xdfdf,
+ 0xffdf,
+};
+
+void serial_setbrg(void)
+{
+ DECLARE_GLOBAL_DATA_PTR;
+ s5pc1xx_uart_t *const uart = s5pc1xx_get_base_uart(UART_NR);
+ u32 pclk = get_pclk();
+ u32 baudrate = gd-baudrate;
+ int i;
+
+ i = (pclk / baudrate) % 16;
+
+ uart-UBRDIV = pclk / baudrate / 16 - 1;
+ uart-UDIVSLOT = udivslot[i];
+}
+
+/*
+ * Initialise the serial port with the given baudrate. The settings
+ * are always 8 data bits, no parity, 1 stop bit, no start bits.
+ */
+int serial_init(void)
+{
+ s5pc1xx_uart_t *const uart = s5pc1xx_get_base_uart(UART_NR);
+
+ /* reset and enable FIFOs, set triggers to the maximum */
+ uart-UFCON = 0;
+ uart-UMCON = 0;
+ /* 8N1 */
+ uart-ULCON = 0x3;
+ /* No interrupts, no DMA, pure polling */
+ uart-UCON = 0x245;
+
+ serial_setbrg();
+
+ return 0;
+}
+
+/*
+ * Read a single byte from the serial port. Returns 1 on success, 0
+ * otherwise. When the function is succesfull, the character read is
+ * written into its argument c.
+ */
+int serial_getc(void)
+{
+ s5pc1xx_uart_t *const uart = s5pc1xx_get_base_uart(UART_NR);
+
+ /* wait for character to arrive */
+ while (!(uart-UTRSTAT 0x1))
+ ;
+
+ return uart-URXH 0xff;
+}
+
+#ifdef CONFIG_MODEM_SUPPORT
+static int be_quiet;
+void disable_putc(void)
+{
+ be_quiet = 1;
+}
+
+void enable_putc(void)
+{
+ be_quiet = 0;
+}
+#endif
+
+
+/*
+ * Output a single byte to the serial port.
+ */
+void serial_putc(const char c)
+{
+ s5pc1xx_uart_t *const uart = s5pc1xx_get_base_uart(UART_NR);
+
+#ifdef CONFIG_MODEM_SUPPORT
+ if (be_quiet)
+
Re: [U-Boot] [PATCH v3 4/4] tools: mkimage: Add: Kirkwood Boot Image support (kwbimage)
On Fri, 04 Sep 2009 10:24:38 +0200 Wolfgang Denk w...@denx.de wrote: Dear Simon Kagstrom, In message 20090904083003.3f7f0...@marrow.netinsight.se you wrote: Understandable. On the other hand, it should be possible to pad the U-boot image to some specific size to keep the size constant. Typically to the erase size. This makes no sense. Why would such padding be needed? It only adds overhead everywhere where the image needs to be processed, stored, downloaded, programmed, etc. In this case to have keep the kirkwood boot header unchanged, and to just update the U-boot image. // Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm_cortexa8: support cache flush to other soc
Current code is supported only omap3 soc.
this patch will support s5pc1xx(s5pc100 and s5pc110) soc also.
Signed-off-by: Minkyu Kang mk7.k...@samsung.com
---
cpu/arm_cortexa8/cpu.c | 24 +++-
1 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/cpu/arm_cortexa8/cpu.c b/cpu/arm_cortexa8/cpu.c
index 5a5981e..3d430b1 100644
--- a/cpu/arm_cortexa8/cpu.c
+++ b/cpu/arm_cortexa8/cpu.c
@@ -35,9 +35,6 @@
#include command.h
#include asm/system.h
#include asm/cache.h
-#ifndef CONFIG_L2_OFF
-#include asm/arch/sys_proto.h
-#endif
static void cache_flush(void);
@@ -61,17 +58,18 @@ int cleanup_before_linux(void)
cache_flush();
#ifndef CONFIG_L2_OFF
- /* turn off L2 cache */
- l2_cache_disable();
- /* invalidate L2 cache also */
- v7_flush_dcache_all(get_device_type());
-#endif
- i = 0;
- /* mem barrier to sync up things */
- asm(mcr p15, 0, %0, c7, c10, 4: :r(i));
+ if (get_device_type() != 0xC100) {
+ /* turn off L2 cache */
+ l2_cache_disable();
+ /* invalidate L2 cache also */
+ v7_flush_dcache_all(get_device_type());
-#ifndef CONFIG_L2_OFF
- l2_cache_enable();
+ i = 0;
+ /* mem barrier to sync up things */
+ asm(mcr p15, 0, %0, c7, c10, 4: :r(i));
+
+ l2_cache_enable();
+ }
#endif
return 0;
--
1.5.4.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm_cortexa8: support cache flush to other soc
Dear Minkyu Kang,
Minkyu Kang wrote:
Current code is supported only omap3 soc.
this patch will support s5pc1xx(s5pc100 and s5pc110) soc also.
Thanks for this patch!
How is this patch related to
http://lists.denx.de/pipermail/u-boot/2009-August/058492.html
?
Signed-off-by: Minkyu Kang mk7.k...@samsung.com
---
cpu/arm_cortexa8/cpu.c | 24 +++-
1 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/cpu/arm_cortexa8/cpu.c b/cpu/arm_cortexa8/cpu.c
index 5a5981e..3d430b1 100644
--- a/cpu/arm_cortexa8/cpu.c
+++ b/cpu/arm_cortexa8/cpu.c
@@ -35,9 +35,6 @@
#include command.h
#include asm/system.h
#include asm/cache.h
-#ifndef CONFIG_L2_OFF
-#include asm/arch/sys_proto.h
-#endif
static void cache_flush(void);
@@ -61,17 +58,18 @@ int cleanup_before_linux(void)
cache_flush();
#ifndef CONFIG_L2_OFF
- /* turn off L2 cache */
- l2_cache_disable();
- /* invalidate L2 cache also */
- v7_flush_dcache_all(get_device_type());
-#endif
- i = 0;
- /* mem barrier to sync up things */
- asm(mcr p15, 0, %0, c7, c10, 4: :r(i));
+ if (get_device_type() != 0xC100) {
Hmm, what is this 0xC100 ?
+ /* turn off L2 cache */
+ l2_cache_disable();
+ /* invalidate L2 cache also */
+ v7_flush_dcache_all(get_device_type());
-#ifndef CONFIG_L2_OFF
- l2_cache_enable();
+ i = 0;
+ /* mem barrier to sync up things */
+ asm(mcr p15, 0, %0, c7, c10, 4: :r(i));
+
+ l2_cache_enable();
+ }
#endif
What's about the order of #ifndef CONFIG_L2_OFF?
While we had before
#ifndef CONFIG_L2_OFF
/* turn off L2 cache */
l2_cache_disable();
/* invalidate L2 cache also */
v7_flush_dcache_all(get_device_type());
#endif
i = 0;
/* mem barrier to sync up things */
asm(mcr p15, 0, %0, c7, c10, 4: :r(i));
#ifndef CONFIG_L2_OFF
l2_cache_enable();
#endif
after this patch we would have
#ifndef CONFIG_L2_OFF
if (get_device_type() != 0xC100) {
/* turn off L2 cache */
l2_cache_disable();
/* invalidate L2 cache also */
v7_flush_dcache_all(get_device_type());
i = 0;
/* mem barrier to sync up things */
asm(mcr p15, 0, %0, c7, c10, 4: :r(i));
l2_cache_enable();
}
#endif
Is this intended?
Best regards
Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Virtual addresses, u-boot, and the MMU
Becky Bruce becky.br...@freescale.com wrote: I'm not really deep enough in the implementation details and thus would appreciate comments for example from Becky and Stefan. In my opinion, turning on or off the cache on an address range should be implemented as outlined above, i. e. as an operation changing the caching properties of the address range. This makes sense to me. The disable function would need to flush the range from the cache, but that's the only difficulty I forsee. However, I dug up some AVR32 docs, and it looks like the whole dual cacheable/CI mapping thing may be architectural. The architecture seems to specify a virtual memory map for privileged state, and part of the VA range is not translated by the MMU, but has a default translation. There appear to be segments in the untranslated VA space that map to the same PA, one cacheable and the other not. Yes, that is correct. As Andrew pointed out, MIPS does essentially the same thing, and I _think_ some versions of SH have a similar setup as well. This makes it easy to set up uncached access on certain physical addresses without wasting any TLB entries. On the other hand, turning off the cache entirely is a quite complicated operation which involves accessing the memory-mapped dcache tag memory and marking everything as allocated and invalid. So I'd rather not do that, especially when there's a much easier way. Another alternative is to enable paging, which will allow fine-grained control over caching properties. It's probably not all that difficult to do, but it just seems so _pointless_. Also, what I don't get is that your architecture _also_ needs to remap physical to virtual addresses, but for a different reason, so what is wrong with having an API that can do both? In other words, the map_physmem() API can support the following three classes of architectures: - Architectures which don't need address remapping but do need to change caching properties: Just update the caching properties and return the physical address unchanged. - Architectures like AVR32 which change caching properties through the MMU: Return a new virtual address with the desired properties. - Architectures with PAVA: Update the caching properties if necessary and return a temporary virtual address corresponding to the given physical address, allowing the entire physical address range of the CPU to be made available to drivers utilizing this API. What is wrong with this API? Why are everyone so hell-bent on making it difficult for the last two classes of architectures? Did I get any or all of the scenarios above wrong? Using a completely different address range instead is a different thing, and not what I have in mind. I really dislike the idea of supporting alternate addresses in this context - even if this is what would be easiest to implement on some architectures. I agree, but, then, I'm coming from an architecture where doing this is bad joo-joo. Again, it looks like AVR may actually need this - hopefully someone who knows more about AVR will speak up here. I've said what I intend to say about this. I find it really hard to argue about opinions which are not backed by facts. The alternate addresses are there whether we decide use them or not, but not using them makes what should be a trivial operation really hard to do. Oh, and I'm really sorry about the tone I used a couple of days ago. I deliberately stopped posting for a few days after that...but I'm hoping we can all continue working towards a solution now. Btw, I do have a few suggestions on how to resolve this, but I'm not going to come forward with them as long as I'm being stonewalled on the VA/PA mapping issue. Haavard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc4xx: Fix PMC405DE support
This patch fixes PMC405DE support. Patch 85d6bf0b fixed out-of-tree building for this board but the loadpci object did not get linked after that. Signed-off-by: Matthias Fuchs matthias.fu...@esd.eu --- board/esd/pmc405de/Makefile |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/board/esd/pmc405de/Makefile b/board/esd/pmc405de/Makefile index 327e51e..f435495 100644 --- a/board/esd/pmc405de/Makefile +++ b/board/esd/pmc405de/Makefile @@ -22,12 +22,15 @@ # include $(TOPDIR)/config.mk +ifneq ($(OBJTREE),$(SRCTREE)) +$(shell mkdir -p $(obj)../common) +endif LIB= $(obj)lib$(BOARD).a COBJS-y= $(BOARD).o COBJS-$(CONFIG_CMD_CHIP_CONFIG) += chip_config.o -COBJS += ../common/cmd_loadpci.o +COBJS-y += ../common/cmd_loadpci.o COBJS := $(COBJS-y) SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) -- 1.6.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Virtual addresses, u-boot, and the MMU
Mark Jackson mpfj-l...@mimc.co.uk wrote: The functions could also return (architecture dependant) a remapped address to be used, then we could support:- Right, and that is the important part: If I'm allowed to return a remapped address, this API will be trivial to implement on AVR32. If not, it will be quite difficult (and make everything larger and slower). Your idea is good; it's mostly similar to what map_physmem() does today, but perhaps the name is wrong, and I suppose it should probably flush the caches in addition to just remapping the address. Haavard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][v1] ep8248: add support for device tree and secondary Ethernet interface.
Hi Peter Peter Tyser ptyser at xes-inc.com writes: Should this chunk of code should be added to your cpu's ft_cpu_setup() function instead of here? Then any mpc82xx board can leverage it instead of reinventing the wheel. Sure, I just copied it from one of the other 13 boards that do it like that (;-p). I will move it to my cpu's ft_cpu_setup() routine, fix the other boards using that cpu and post v2 of my patch. Stay tuned. Marcel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Odd value for I2C_TIMEOUT in fsl_i2c.c
Dear Heiko Schocher, In message 4aa0bec5.3010...@denx.de you wrote: CONFIG_HZ is 1000, so I2C_TIMEOUT is equal to 250. However, the way it's used, 250 isn't the number of ticks per second, it's used as number of microseconds. If CONFIG_HZ is changed to 100, does that mean that we want to call usec2ticks(25)? This seems like a Bug to me. I think what we should be doing is this: #define I2C_TIMEOUT 1000 Surely, one millisecond is not too long of a timeout? I think this should be Ok. Can you provide a patch? There are actually two parts in Timur's mail: 1) First part is the question if the timeout, which is currently set to 250 us, should be raised to 1,000 us. I cannot answer this question. I don't even understand why the i2c_wait4bus() function is needed at all. 2) The second part is if the timeout definition should be changed from being based on CONFIG_SYS_HZ to a plain numeric constant. Assuming I2C_TIMEOUT is intended to be a period of time (as the name suggests), then (CONFIG_SYS_HZ / 4) is clearly wrong as it's a frequency and not a time. In this case, a comment should be added explainign what I2C_TIMEOUT means. 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 you are afraid of loneliness, don't marry. - Chekhov ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH, RFC] Make arm926ejs use -march=armv5t to avoid problems with EABI
Make arm926ejs use -march=armv5t to avoid problems with EABI Using -march=armv5t instead of armv5te allows Marvell Kirkwood-based boards to boot with the EABI changes introduced in commit f772acf8a584067033eff1e231fcd1fb3a00d3d9 Signed-off-by: Simon Kagstrom simon.kagst...@netinsight.net --- This allows me to build with -mabi=aapcs-linux again. I still haven't found out what exactly causes the issues I had reported here http://www.mail-archive.com/u-boot@lists.denx.de/msg20517.html but with this patch it works fine again. Disassembling the binary, I see that ldrd/strd instructions are gone (as expected), although I don't know if that is the issue. cpu/arm926ejs/config.mk |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/cpu/arm926ejs/config.mk b/cpu/arm926ejs/config.mk index 90eb3c0..94f1c17 100644 --- a/cpu/arm926ejs/config.mk +++ b/cpu/arm926ejs/config.mk @@ -24,7 +24,7 @@ PLATFORM_RELFLAGS += -fno-strict-aliasing -fno-common -ffixed-r8 \ -msoft-float -PLATFORM_CPPFLAGS += -march=armv5te +PLATFORM_CPPFLAGS += -march=armv5t # = # # Supply options according to compiler version -- 1.6.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm_cortexa8: support cache flush to other soc
Hi,
As he goes to home, I reply it instead.
On Fri, Sep 4, 2009 at 5:43 PM, Dirk Behmedirk.be...@googlemail.com wrote:
Dear Minkyu Kang,
Minkyu Kang wrote:
Current code is supported only omap3 soc.
this patch will support s5pc1xx(s5pc100 and s5pc110) soc also.
Thanks for this patch!
How is this patch related to
http://lists.denx.de/pipermail/u-boot/2009-August/058492.html
It's not good idea to move invalidate_cache to omap directory. we need it.
Signed-off-by: Minkyu Kang mk7.k...@samsung.com
---
cpu/arm_cortexa8/cpu.c | 24 +++-
1 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/cpu/arm_cortexa8/cpu.c b/cpu/arm_cortexa8/cpu.c
index 5a5981e..3d430b1 100644
--- a/cpu/arm_cortexa8/cpu.c
+++ b/cpu/arm_cortexa8/cpu.c
@@ -35,9 +35,6 @@
#include command.h
#include asm/system.h
#include asm/cache.h
-#ifndef CONFIG_L2_OFF
-#include asm/arch/sys_proto.h
-#endif
static void cache_flush(void);
@@ -61,17 +58,18 @@ int cleanup_before_linux(void)
cache_flush();
#ifndef CONFIG_L2_OFF
- /* turn off L2 cache */
- l2_cache_disable();
- /* invalidate L2 cache also */
- v7_flush_dcache_all(get_device_type());
-#endif
- i = 0;
- /* mem barrier to sync up things */
- asm(mcr p15, 0, %0, c7, c10, 4: :r(i));
+ if (get_device_type() != 0xC100) {
Hmm, what is this 0xC100 ?
Now we got two cpu, s5pc100 and s5pc110. In case of s5pc100 we don't
need to turn off l2 cache. but s5pc110 needs it.
So first check the device type, actually cpu type. then determine turn
off l2 cache or not.
+ /* turn off L2 cache */
+ l2_cache_disable();
+ /* invalidate L2 cache also */
+ v7_flush_dcache_all(get_device_type());
-#ifndef CONFIG_L2_OFF
- l2_cache_enable();
+ i = 0;
+ /* mem barrier to sync up things */
+ asm(mcr p15, 0, %0, c7, c10, 4: :r(i));
+
+ l2_cache_enable();
+ }
#endif
What's about the order of #ifndef CONFIG_L2_OFF?
While we had before
#ifndef CONFIG_L2_OFF
/* turn off L2 cache */
l2_cache_disable();
/* invalidate L2 cache also */
v7_flush_dcache_all(get_device_type());
#endif
i = 0;
/* mem barrier to sync up things */
asm(mcr p15, 0, %0, c7, c10, 4: :r(i));
#ifndef CONFIG_L2_OFF
l2_cache_enable();
#endif
after this patch we would have
#ifndef CONFIG_L2_OFF
if (get_device_type() != 0xC100) {
/* turn off L2 cache */
l2_cache_disable();
/* invalidate L2 cache also */
v7_flush_dcache_all(get_device_type());
i = 0;
/* mem barrier to sync up things */
asm(mcr p15, 0, %0, c7, c10, 4: :r(i));
l2_cache_enable();
}
#endif
Is this intended?
maybe not. now we only tested the smdkc100 but actual use is internal
board for s5pc100 s5pc110.
He will be modify it.
Thank you,
Kyungmin Park
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] s5pc1xx: support Samsung s5pc1xx SoC
Dear Minkyu Kang,
In message 4aa0ce3b.7050...@samsung.com you wrote:
This patch add support new SoCs that are s5pc100 and s5pc110
s5pc1xx SoC is ARM Cortex A8 processor
Please change into:
This patch adds support for the Samsung s5pc100 and s5pc110
SoCs. The s5pc1xx SoC is an ARM Cortex A8 processor.
--- /dev/null
+++ b/cpu/arm_cortexa8/s5pc1xx/Makefile
...
+LIB = $(obj)lib$(SOC).a
+
+SOBJS= reset.o
+
+COBJS+= timer.o
+COBJS+= clock.o
+COBJS+= cpu_info.o
+COBJS+= cache.o
Please always sort such lists alphabetically.
diff --git a/cpu/arm_cortexa8/s5pc1xx/clock.c
b/cpu/arm_cortexa8/s5pc1xx/clock.c
new file mode 100644
index 000..59690d7
--- /dev/null
+++ b/cpu/arm_cortexa8/s5pc1xx/clock.c
...
+/*
+ * This code should work for both the S3C2400 and the S3C2410
+ * as they seem to have the same PLL and clock machinery inside.
+ * The different address mapping is handled by the s3c24xx.h files below.
+ */
Please check the comment. Is this for s5pc1xx or for s3c24xx?
+static int s5pc1xx_clock_read_reg(int offset)
+{
+ return readl(S5PC1XX_CLOCK_BASE + offset);
+}
NAK. This needs to be reworked. We do not allow accesses to device
registers like this. Instead of using a base address + offset (which
carries absolutley no information about the type of the accessed
register - 8, 16 or 32 bit?) we require that you describe your
peripherals as C structs, so we can strict type checking by the C
compiler.
+/* -
*/
+/*
+ * NOTE: This describes the proper use of this file.
Omit thsi comment, please.
+ * CONFIG_SYS_CLK_FREQ should be defined as the input frequency of the PLL.
CONFIG_SYS_CLK_FREQ is nowhere used in the whole file.
+unsigned long get_pll_clk(int pllreg)
+{
+ unsigned long r, m, p, s, mask, fout;
+ unsigned int freq;
+
+ switch (pllreg) {
+ case APLL:
+ if (cpu_is_s5pc110())
+ r = s5pc1xx_clock_read_reg(S5PC110_APLL_CON_OFFSET);
+ else
+ r = s5pc1xx_clock_read_reg(S5PC100_APLL_CON_OFFSET);
+ break;
I'm not sure what exactly you want to acchieve here.
I see two possibilities:
1) You want to creates some multiboot capable image, i. e. a single
U-Boot binary image that is capable of running both on s5pc100 and
on s5pc110 systems. Only in this case such a run-time test makes
sense. But then it should be written in a more flexible way, so
that it for example allows to add some (still hypothetical)
s5pc120 and s5pc130 at a later time.
2) The resulting U-Boot image will be able to run on only one type of
SoC; in this case you should make sure that all such decisions can
be performet at compile time, and no dead code gets added to the
U-Boot image.
In any case, the code as written is unacceptable, as it extremely
cumbersome to maintain, and is a nightmare to extend for further SoCs.
But I think issue will be solved automatically when you rework your
code to use C structs instead of register offsets, ans you can then
just do a single cpu_is_s5pc???() test and set a pointer to the right
type of data structure.
+ case HPLL:
+ if (cpu_is_s5pc110())
+ hang();
Arghh... It is an extremely bad idea to hang the system without any
indication about what was going on. Please add at least some error
message here.
+ r = s5pc1xx_clock_read_reg(S5PC100_HPLL_CON_OFFSET);
+ break;
+ case VPLL:
+ if (cpu_is_s5pc100())
+ hang();
Ditto.
+ default:
+ hang();
Ditto.
+
+ if (cpu_is_s5pc110()) {
+ if (pllreg == APLL || pllreg == MPLL)
+ mask = 0x3ff;
+ else
+ mask = 0x1ff;
+ } else {
+ if (pllreg == APLL)
+ mask = 0x3ff;
+ else
+ mask = 0x0ff;
Hm... all these magic numbers need some comments, and eventyally some
symbolic constants might be defined for them.
+ }
+
+ m = (r 16) mask;
+ p = (r 8) 0x3f;
+ s = r 0x7;
+
+ if (cpu_is_s5pc110()) {
+ freq = CONFIG_SYS_CLK_FREQ_C110;
+ if (pllreg == APLL) {
+ if (s 1)
+ s = 1;
+ fout = m * (freq / (p * (1 (s - 1;
+ } else
+ fout = m * (freq / (p * (1 s)));
+ } else {
+ freq = CONFIG_SYS_CLK_FREQ_C100;
+ fout = m * (freq / (p * (1 s)));
All this black magic needs to be explained. Please add comments.
...
+/* s5pc110: return HCLKs frequency */
+unsigned long get_hclk_sys(int clk)
+{
+ unsigned long hclk;
+ unsigned int div;
+ unsigned int offset;
+ unsigned int hclk_sys_ratio;
+
+ if
[U-Boot] Starting compressed win CE kernel
Hello, I use U-Boot for starting Windows CE. At the moment I take the nk.bin File and start it with the U-Boot patch of Ryan Chen. Now I will compress the nk.bin file, because in addition to that it takes much less space in the Flash memory. I have tried it with the unzip command, but it takes too much time. Can I use another compression tool from u-boot. I think a compressed linux kernel can be started with bootm. So can I use maybe only the compression tool of the bootm command? If so, how can I do this? Thanks, Andreas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] s5pc1xx: support onenand driver
Dear Minkyu Kang,
In message 4aa0ce3f.60...@samsung.com you wrote:
This patch includes the onenand driver for s5pc1xx
Signed-off-by: Minkyu Kang mk7.k...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
...
+static int s3c_read_reg(int offset)
+{
+ return readl(onenand-base + offset);
+}
+
+static void s3c_write_reg(int value, int offset)
+{
+ writel(value, onenand-base + offset);
+}
+
+static int s3c_read_cmd(unsigned int cmd)
+{
+ return readl(onenand-ahb_addr + cmd);
+}
+
+static void s3c_write_cmd(int value, unsigned int cmd)
+{
+ writel(value, onenand-ahb_addr + cmd);
+}
PLease see comments to previous patch about usage of register plus
offset versus using proper C structures.
Please change this code to use structs, too.
+static unsigned int s5pc100_mem_addr(int fba, int fpa, int fsa)
+{
+ return (fba 13) | (fpa 7) | (fsa 5);
+}
This function needs explanation. Please add a comment what it does,
and how.
...
+static int s3c_onenand_bbt_wait(struct mtd_info *mtd, int state)
+{
+ unsigned int flags = INT_ACT | LOAD_CMP;
+ unsigned int stat;
+ unsigned long timeout = 0x1;
+
+ while (1 timeout--) {
Please do not add bogus code. Remove the 1
...
+void s3c_onenand_init(struct mtd_info *mtd)
+{
+ struct onenand_chip *this = mtd-priv;
+
+ onenand = malloc(sizeof(struct s3c_onenand));
+ if (!onenand)
+ return;
+
+ onenand-page_buf = malloc(SZ_4K * sizeof(char));
+ if (!onenand-page_buf)
+ return;
+ memset(onenand-page_buf, 0xFF, SZ_4K);
+
+ onenand-oob_buf = malloc(128 * sizeof(char));
+ if (!onenand-oob_buf)
+ return;
+ memset(onenand-oob_buf, 0xFF, 128);
+
+ onenand-mtd = mtd;
+
+#ifdef CONFIG_S5PC1XX
+ /* S5PC100 specific values */
+ onenand-base = (void *) 0xE710;
+ onenand-ahb_addr = (void *) 0xB000;
+ onenand-mem_addr = s5pc100_mem_addr;
+#else
+#error Please fix it at s3c6410
+#endif
What does this mean?
diff --git a/include/samsung_onenand.h b/include/samsung_onenand.h
new file mode 100644
index 000..91b40e1
--- /dev/null
+++ b/include/samsung_onenand.h
...
+/*
+ * OneNAND Controller
+ */
+#define MEM_CFG_OFFSET 0x
+#define BURST_LEN_OFFSET 0x0010
+#define MEM_RESET_OFFSET 0x0020
+#define INT_ERR_STAT_OFFSET 0x0030
+#define INT_ERR_MASK_OFFSET 0x0040
+#define INT_ERR_ACK_OFFSET 0x0050
Please use a C struct instead.
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
Lack of skill dictates economy of style.- Joey Ramone
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm_cortexa8: support cache flush to other soc
Kyungmin Park wrote:
Hi,
As he goes to home, I reply it instead.
Nice weekend then :)
On Fri, Sep 4, 2009 at 5:43 PM, Dirk Behmedirk.be...@googlemail.com wrote:
Dear Minkyu Kang,
Minkyu Kang wrote:
Current code is supported only omap3 soc.
this patch will support s5pc1xx(s5pc100 and s5pc110) soc also.
Thanks for this patch!
How is this patch related to
http://lists.denx.de/pipermail/u-boot/2009-August/058492.html
It's not good idea to move invalidate_cache to omap directory. we need it.
Well, yes and no ;)
Most probably you (== Samsung) can't use the invalidate_dcache version
we move in above patch to omap directory, because the version we move
above is OMAP3 specific (it has calls to OMAP3 ROM code). So no, it's
a good idea to move OMAP3 specific code to omap directory.
But yes, you might need DCache flush (*). So the idea of above patch
was to have your own (or generic) implementation, but let OMAP3 use
the custom one where needed.
(*) Do you really need DCache flush? It always was Jean-Christophe's
argument that U-Boot doesn't use any DCache at all.
Signed-off-by: Minkyu Kang mk7.k...@samsung.com
---
cpu/arm_cortexa8/cpu.c | 24 +++-
1 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/cpu/arm_cortexa8/cpu.c b/cpu/arm_cortexa8/cpu.c
index 5a5981e..3d430b1 100644
--- a/cpu/arm_cortexa8/cpu.c
+++ b/cpu/arm_cortexa8/cpu.c
@@ -35,9 +35,6 @@
#include command.h
#include asm/system.h
#include asm/cache.h
-#ifndef CONFIG_L2_OFF
-#include asm/arch/sys_proto.h
-#endif
static void cache_flush(void);
@@ -61,17 +58,18 @@ int cleanup_before_linux(void)
cache_flush();
#ifndef CONFIG_L2_OFF
- /* turn off L2 cache */
- l2_cache_disable();
- /* invalidate L2 cache also */
- v7_flush_dcache_all(get_device_type());
-#endif
- i = 0;
- /* mem barrier to sync up things */
- asm(mcr p15, 0, %0, c7, c10, 4: :r(i));
+ if (get_device_type() != 0xC100) {
Hmm, what is this 0xC100 ?
Now we got two cpu, s5pc100 and s5pc110. In case of s5pc100 we don't
need to turn off l2 cache. but s5pc110 needs it.
So first check the device type, actually cpu type. then determine turn
off l2 cache or not.
0xC100 is the device type of s5pc100 then? So it should be
if (get_device_type() != S5PC100_DEVICE)
? I hear some people crying please use macro ;)
But I don't like this selection here. When we get additional similar
SoCs, we will end with something like
if (get_device_type() != 0xC100) ||
(get_device_type() != FOO) ||
(get_device_type() != BAR)) ||
... {
modifying each time cpu/arm_cortexa8/cpu.c.
I would like more that we are able to compile the functionality based
on the config file we use for compilation. E.g. provide emtpy
l2_cache_disable(); function for SoCs that don't need it, but have
functionality behind it where needed.
With above patch, this would then become something like
cpu/arm_cortexa8/s5pcxxx/dcache.S
- Implements invalidate_dcache() (or implement a Cortex A8 generic
one in cpu/arm_cortexa8/cache.S)
cpu/arm_cortexa8/s5pcxxx/cache_110.S
- Implements l2_cache_enable()/disable()
cpu/arm_cortexa8/s5pcxxx/cache_100.S
- Implements *empty* l2_cache_enable()/disable()
In cpu/arm_cortexa8/s5pcxxx/Makefile you then could have
SOBJS-y += dcache.o
SOBJS-$(CONFIG_S5PC100) += cache_100.o
SOBJS-$(CONFIG_S5PC110) += cache_110.o
What do you think about this?
+ /* turn off L2 cache */
+ l2_cache_disable();
+ /* invalidate L2 cache also */
+ v7_flush_dcache_all(get_device_type());
-#ifndef CONFIG_L2_OFF
- l2_cache_enable();
+ i = 0;
+ /* mem barrier to sync up things */
+ asm(mcr p15, 0, %0, c7, c10, 4: :r(i));
+
+ l2_cache_enable();
+ }
#endif
What's about the order of #ifndef CONFIG_L2_OFF?
While we had before
#ifndef CONFIG_L2_OFF
/* turn off L2 cache */
l2_cache_disable();
/* invalidate L2 cache also */
v7_flush_dcache_all(get_device_type());
#endif
i = 0;
/* mem barrier to sync up things */
asm(mcr p15, 0, %0, c7, c10, 4: :r(i));
#ifndef CONFIG_L2_OFF
l2_cache_enable();
#endif
after this patch we would have
#ifndef CONFIG_L2_OFF
if (get_device_type() != 0xC100) {
/* turn off L2 cache */
l2_cache_disable();
/* invalidate L2 cache also */
v7_flush_dcache_all(get_device_type());
i = 0;
/* mem barrier to sync up things */
asm(mcr p15, 0, %0, c7, c10, 4: :r(i));
l2_cache_enable();
}
#endif
Is this intended?
maybe not. now we only tested the smdkc100 but actual use is internal
board for s5pc100 s5pc110.
He will be modify it.
Ok, thanks.
Best regards
Dirk
___
U-Boot mailing list
Re: [U-Boot] [PATCH] arm_cortexa8: support cache flush to other soc
On Fri, Sep 4, 2009 at 7:45 PM, Dirk Behmedirk.be...@googlemail.com wrote:
Kyungmin Park wrote:
Hi,
As he goes to home, I reply it instead.
Nice weekend then :)
On Fri, Sep 4, 2009 at 5:43 PM, Dirk Behmedirk.be...@googlemail.com
wrote:
Dear Minkyu Kang,
Minkyu Kang wrote:
Current code is supported only omap3 soc.
this patch will support s5pc1xx(s5pc100 and s5pc110) soc also.
Thanks for this patch!
How is this patch related to
http://lists.denx.de/pipermail/u-boot/2009-August/058492.html
It's not good idea to move invalidate_cache to omap directory. we need it.
Well, yes and no ;)
Most probably you (== Samsung) can't use the invalidate_dcache version we
move in above patch to omap directory, because the version we move above is
OMAP3 specific (it has calls to OMAP3 ROM code). So no, it's a good idea to
move OMAP3 specific code to omap directory.
But yes, you might need DCache flush (*). So the idea of above patch was to
have your own (or generic) implementation, but let OMAP3 use the custom one
where needed.
(*) Do you really need DCache flush? It always was Jean-Christophe's
argument that U-Boot doesn't use any DCache at all.
Yes, We really want it. At first development time, we don't know why
the kernel is boot. almost same as s5pc100 but s5pc110 required cache
flush.
Signed-off-by: Minkyu Kang mk7.k...@samsung.com
---
cpu/arm_cortexa8/cpu.c | 24 +++-
1 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/cpu/arm_cortexa8/cpu.c b/cpu/arm_cortexa8/cpu.c
index 5a5981e..3d430b1 100644
--- a/cpu/arm_cortexa8/cpu.c
+++ b/cpu/arm_cortexa8/cpu.c
@@ -35,9 +35,6 @@
#include command.h
#include asm/system.h
#include asm/cache.h
-#ifndef CONFIG_L2_OFF
-#include asm/arch/sys_proto.h
-#endif
static void cache_flush(void);
@@ -61,17 +58,18 @@ int cleanup_before_linux(void)
cache_flush();
#ifndef CONFIG_L2_OFF
- /* turn off L2 cache */
- l2_cache_disable();
- /* invalidate L2 cache also */
- v7_flush_dcache_all(get_device_type());
-#endif
- i = 0;
- /* mem barrier to sync up things */
- asm(mcr p15, 0, %0, c7, c10, 4: :r(i));
+ if (get_device_type() != 0xC100) {
Hmm, what is this 0xC100 ?
Now we got two cpu, s5pc100 and s5pc110. In case of s5pc100 we don't
need to turn off l2 cache. but s5pc110 needs it.
So first check the device type, actually cpu type. then determine turn
off l2 cache or not.
0xC100 is the device type of s5pc100 then? So it should be
if (get_device_type() != S5PC100_DEVICE)
? I hear some people crying please use macro ;)
Agreed. DONT_NEED_CACHE_FLUSH?
But I don't like this selection here. When we get additional similar SoCs,
we will end with something like
if (get_device_type() != 0xC100) ||
(get_device_type() != FOO) ||
(get_device_type() != BAR)) ||
... {
modifying each time cpu/arm_cortexa8/cpu.c.
I would like more that we are able to compile the functionality based on the
config file we use for compilation. E.g. provide emtpy l2_cache_disable();
function for SoCs that don't need it, but have functionality behind it where
needed.
With above patch, this would then become something like
cpu/arm_cortexa8/s5pcxxx/dcache.S
- Implements invalidate_dcache() (or implement a Cortex A8 generic one in
cpu/arm_cortexa8/cache.S)
cpu/arm_cortexa8/s5pcxxx/cache_110.S
- Implements l2_cache_enable()/disable()
cpu/arm_cortexa8/s5pcxxx/cache_100.S
- Implements *empty* l2_cache_enable()/disable()
In cpu/arm_cortexa8/s5pcxxx/Makefile you then could have
SOBJS-y += dcache.o
SOBJS-$(CONFIG_S5PC100) += cache_100.o
SOBJS-$(CONFIG_S5PC110) += cache_110.o
What do you think about this?
Basically agreed, of course we can think weak attribute but now we
have to support both cpu simultaneously.
with this reason. we check the device_type at here.
Thank you,
Kyungmin Park
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] s5pc1xx: add support SMDKC100 board
Dear Minkyu Kang,
In message 4aa0ce4a.3060...@samsung.com you wrote:
Add new board SMDKC100 that uses s5pc100 SoC
...
diff --git a/board/samsung/smdkc100/mem_setup.S
b/board/samsung/smdkc100/mem_setup.S
new file mode 100644
index 000..a3e692f
--- /dev/null
+++ b/board/samsung/smdkc100/mem_setup.S
Why is this all written in assembly code?
Cannot we use C instead?
diff --git a/board/samsung/smdkc100/onenand.c
b/board/samsung/smdkc100/onenand.c
new file mode 100644
index 000..75bb8a9
--- /dev/null
+++ b/board/samsung/smdkc100/onenand.c
...
+static inline int onenand_read_reg(int offset)
+{
+ return readl(CONFIG_SYS_ONENAND_BASE + offset);
+}
+
+static inline void onenand_write_reg(int value, int offset)
+{
+ writel(value, CONFIG_SYS_ONENAND_BASE + offset);
+}
See previous comments about not using base address plus offset for
register accesses. Please change to use C structs.
...
diff --git a/board/samsung/smdkc100/smdkc100.c
b/board/samsung/smdkc100/smdkc100.c
new file mode 100644
index 000..4539ced
--- /dev/null
+++ b/board/samsung/smdkc100/smdkc100.c
...
+#include common.h
+DECLARE_GLOBAL_DATA_PTR;
+
+int board_init(void)
+{
+ gd-bd-bi_arch_number = MACH_TYPE;
Please don;t hide this information - use MACH_TYPE_SMDKC100 directly.
diff --git a/include/configs/smdkc100.h b/include/configs/smdkc100.h
new file mode 100644
index 000..ec0fd1d
--- /dev/null
+++ b/include/configs/smdkc100.h
...
+/*
+ * Architecture magic and machine type
+ */
+#define MACH_TYPE1826
Please do not do this. I recommend to omit this completely, and use
the MACH_TYPE_SMDKC100 defintion from include/asm-arm/mach-types.h
instead.
+/***
+ * Command definition
+ ***/
+#include config_cmd_default.h
+
+#undef CONFIG_CMD_LOADB
+#undef CONFIG_CMD_LOADS
+#undef CONFIG_CMD_BOOTD
+#undef CONFIG_CMD_FPGA
+#undef CONFIG_CMD_XIMG
+#undef CONFIG_CMD_NAND
+#undef CONFIG_CMD_IMLS
+#undef CONFIG_CMD_FLASH
+#undef CONFIG_CMD_IMLS
+#undef CONFIG_CMD_NET
Is there any specific reason for disabling these commands? Some of
these are extremely useful to the end user?
Also, you might want to sort such lists, and remove duplicate entries.
+#if 1
+#define CONFIG_BOOTCOMMAND run ubifsboot
+#else
+#define CONFIG_BOOTCOMMAND bootm 0x31008000
+#endif
Please do not add dead code.
...
+#define CONFIG_SYS_HZ2085900 /* at PCLK 66.75MHz */
NAK. It is a mandatory requirement that CONFIG_SYS_HZ must be 1000.
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 not underestimate the value of print statements for debugging.
Don't have aesthetic convulsions when using them, either.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/4] tools: mkimage: Add: Kirkwood Boot Image support (kwbimage)
Dear Simon Kagstrom, In message 20090904103602.7a0ec...@marrow.netinsight.se you wrote: Understandable. On the other hand, it should be possible to pad the U-boot image to some specific size to keep the size constant. Typically to the erase size. This makes no sense. Why would such padding be needed? It only adds overhead everywhere where the image needs to be processed, stored, downloaded, programmed, etc. In this case to have keep the kirkwood boot header unchanged, and to just update the U-boot image. Doesn't the header contain checksums and such? And what would that save you? Building the image with header is supposed to be a very cheap operation. 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 if is a trademark of Hewlett Packard, so stop using it in your sentences without permission, or risk being sued. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] s5pc1xx: support onenand driver
Hi,
On Fri, Sep 4, 2009 at 7:44 PM, Wolfgang Denkw...@denx.de wrote:
Dear Minkyu Kang,
In message 4aa0ce3f.60...@samsung.com you wrote:
This patch includes the onenand driver for s5pc1xx
Signed-off-by: Minkyu Kang mk7.k...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
...
+static int s3c_read_reg(int offset)
+{
+ return readl(onenand-base + offset);
+}
+
+static void s3c_write_reg(int value, int offset)
+{
+ writel(value, onenand-base + offset);
+}
+
+static int s3c_read_cmd(unsigned int cmd)
+{
+ return readl(onenand-ahb_addr + cmd);
+}
+
+static void s3c_write_cmd(int value, unsigned int cmd)
+{
+ writel(value, onenand-ahb_addr + cmd);
+}
PLease see comments to previous patch about usage of register plus
offset versus using proper C structures.
I have different opinion. How much register map is required? I mean in
case of read/write cmd, it has about 256MiB range. then how do you
cast is as C structures.
Only some small range for example. 1K or less. C structures possible.
but more than this. it's too huge to case it.
Please change this code to use structs, too.
+static unsigned int s5pc100_mem_addr(int fba, int fpa, int fsa)
+{
+ return (fba 13) | (fpa 7) | (fsa 5);
+}
This function needs explanation. Please add a comment what it does,
and how.
It's mandatory. no need to shift. It's fixed. with this reason. we
covers alomst 256MiB memory range.
...
+static int s3c_onenand_bbt_wait(struct mtd_info *mtd, int state)
+{
+ unsigned int flags = INT_ACT | LOAD_CMP;
+ unsigned int stat;
+ unsigned long timeout = 0x1;
+
+ while (1 timeout--) {
Please do not add bogus code. Remove the 1
Agreed.
...
+void s3c_onenand_init(struct mtd_info *mtd)
+{
+ struct onenand_chip *this = mtd-priv;
+
+ onenand = malloc(sizeof(struct s3c_onenand));
+ if (!onenand)
+ return;
+
+ onenand-page_buf = malloc(SZ_4K * sizeof(char));
+ if (!onenand-page_buf)
+ return;
+ memset(onenand-page_buf, 0xFF, SZ_4K);
+
+ onenand-oob_buf = malloc(128 * sizeof(char));
+ if (!onenand-oob_buf)
+ return;
+ memset(onenand-oob_buf, 0xFF, 128);
+
+ onenand-mtd = mtd;
+
+#ifdef CONFIG_S5PC1XX
+ /* S5PC100 specific values */
+ onenand-base = (void *) 0xE710;
+ onenand-ahb_addr = (void *) 0xB000;
+ onenand-mem_addr = s5pc100_mem_addr;
+#else
+#error Please fix it at s3c6410
+#endif
What does this mean?
Now we got two version of samsung.c one for s3c6410, another is this
one. No problem to add it for s3c6410
diff --git a/include/samsung_onenand.h b/include/samsung_onenand.h
new file mode 100644
index 000..91b40e1
--- /dev/null
+++ b/include/samsung_onenand.h
...
+/*
+ * OneNAND Controller
+ */
+#define MEM_CFG_OFFSET 0x
+#define BURST_LEN_OFFSET 0x0010
+#define MEM_RESET_OFFSET 0x0020
+#define INT_ERR_STAT_OFFSET 0x0030
+#define INT_ERR_MASK_OFFSET 0x0040
+#define INT_ERR_ACK_OFFSET 0x0050
Please use a C struct instead.
The end address is 0x400. Are you really need it to cast? I don't think so.
Thank you,
Kyungmin Park
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm_cortexa8: support cache flush to other soc
Dear Kyungmin Park,
In message 9c9fda240909040234m4fdd7466ybb38d0d0618cd...@mail.gmail.com you
wrote:
...
#ifndef CONFIG_L2_OFF
- /* turn off L2 cache */
- l2_cache_disable();
- /* invalidate L2 cache also */
- v7_flush_dcache_all(get_device_type());
-#endif
- i = 0;
- /* mem barrier to sync up things */
- asm(mcr p15, 0, %0, c7, c10, 4: :r(i));
+ if (get_device_type() != 0xC100) {
Hmm, what is this 0xC100 ?
Now we got two cpu, s5pc100 and s5pc110. In case of s5pc100 we don't
need to turn off l2 cache. but s5pc110 needs it.
So first check the device type, actually cpu type. then determine turn
off l2 cache or not.
Well, this definitely needs a comment, doesn;t it?
And I really dislike such board-specific parts in common code. If what
you want to check is the CPU type, then isn;t there a more direct way?
And do we need a runtime check here? I think that decision can be made
at compile time, right?
...
maybe not. now we only tested the smdkc100 but actual use is internal
board for s5pc100 s5pc110.
Do you use the very same U-Boot image on both SoCs?
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
Real Programmers always confuse Christmas and Halloween because
OCT 31 == DEC 25 ! - Andrew Rutherford (andr...@ucs.adelaide.edu.au)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/4] tools: mkimage: Add: Kirkwood Boot Image support (kwbimage)
On Fri, 04 Sep 2009 12:57:57 +0200 Wolfgang Denk w...@denx.de wrote: Dear Simon Kagstrom, In message 20090904103602.7a0ec...@marrow.netinsight.se you wrote: Understandable. On the other hand, it should be possible to pad the U-boot image to some specific size to keep the size constant. Typically to the erase size. This makes no sense. Why would such padding be needed? It only adds overhead everywhere where the image needs to be processed, stored, downloaded, programmed, etc. In this case to have keep the kirkwood boot header unchanged, and to just update the U-boot image. Doesn't the header contain checksums and such? And what would that save you? Building the image with header is supposed to be a very cheap operation. I believe the checksums are for the header and the header extension - the image itself contains a checksum in the last 4 bytes. The idea was to avoid having to rewrite the same block all the time. Anyway, Prafulla has explained why it's difficult (or maybe impossible) to use this method, so I think we can safely drop this subject for now. // Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Starting compressed win CE kernel
Dear A. Geisreiter, In message 000e01ca2d48$728b0890$57a119...@de you wrote: Dies ist eine mehrteilige Nachricht im MIME-Format. Please stop doing this. Please post plain text only. Do not post HTML. I use U-Boot for starting Windows CE. At the moment I take the nk.bin File and start it with the U-Boot patch of Ryan Chen. Now I will compress the nk.bin file, because in addition to that it takes much less space in the Flash memory. I have tried it with the unzip command, but it takes too much time. Can I use another compression tool from u-boot. I think a compressed linux kernel can be started with bootm. So can I use maybe only the compression tool of the bootm command? If so, how can I do this? What makes you think that the uncompression code used by bootm would be any faster than the one used by unzip? It ain't faster, as it is the very same code actually. 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 ATTENTION: Despite Any Other Listing of Product Contents Found Here- on, the Consumer is Advised That, in Actuality, This Product Consists Of 99.99% Empty Space. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] s5pc1xx: add support SMDKC100 board
Dear Kyungmin Park, In message 9c9fda240909040409u576a7149kd4a4666148bfa...@mail.gmail.com you wrote: +++ b/board/samsung/smdkc100/mem_setup.S Why is this all written in assembly code? Cannot we use C instead? Since it is used at OneNAND IPL. It has size limitation. So what? Do you think that equivalent C code would be inherently bigger? I am not so sure about that. ... +/*** + * Command definition + ***/ +#include config_cmd_default.h + +#undef CONFIG_CMD_LOADB +#undef CONFIG_CMD_LOADS +#undef CONFIG_CMD_BOOTD +#undef CONFIG_CMD_FPGA +#undef CONFIG_CMD_XIMG +#undef CONFIG_CMD_NAND +#undef CONFIG_CMD_IMLS +#undef CONFIG_CMD_FLASH +#undef CONFIG_CMD_IMLS +#undef CONFIG_CMD_NET Is there any specific reason for disabling these commands? Some of these are extremely useful to the end user? Since now we only tested on OneNAND. If someone or who want to use these feature just remove it at that time. This makes no sense to me. Download commands like loadb and lods, information commands like imls and network commands are completrely independent of where you boot from. It may make sense to diaable netwoirk support if you hav enot tested it yet, but disabling all the othe rdefault features makes zero sense to me. Please don't. Disable only things that really cannot be used. 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 a race of cowards; and I am not only marching in that procession but carrying a banner. - Mark Twain ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] boot linux data aboot for S3C2440A
Hi fluke56512 I was the last one to work on an s3c2440 port - I ran out of time but I hope to submit my changes for the next release. In the meantime, you can use my patches as a starting point (see the series of patches in ref 1) or if you contact me directly I can send you a single patch for the u-boot-2009.08 release that works but isn't suitable for submission to this mailing list yet. Regards Kevin abdoulaye Walsimou Gaye wrote: fluke56512 a écrit : what is wrong with me. [u-b...@s3c2440a]# nand read 0x30008000 0x0004 0x0020 NAND read: device 0 offset 0x4, size 0x20 2097152 bytes read: OK Hello fluke56512, IIRC board with S3C2440A does not exist in the official versions of u-boot. Few attempts have been made[1], but without going futher. Or may be you are working on it? I planed to work on it with the cheap mini2440 board, but I am too busy for now. cheers, [1] http://lists.denx.de/pipermail/u-boot/2009-June/054887.html ___ 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] ARM mach-types.h sync request
Hi, according to http://lists.denx.de/pipermail/u-boot/2008-September/040553.html I request an update. It is needed for MACH_TYPE_ETHERCAN2 (based on MEESC board, patch will come soon.) The last kernel source was synced on 2009-06-20, and is also outdated. So please sync against http://www.arm.linux.org.uk/developer/machines/ Best regards Daniel Gorsulowski ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm_cortexa8: support cache flush to other soc
Kyungmin Park wrote:
On Fri, Sep 4, 2009 at 7:45 PM, Dirk Behmedirk.be...@googlemail.com wrote:
Kyungmin Park wrote:
...
+ if (get_device_type() != 0xC100) {
Hmm, what is this 0xC100 ?
Now we got two cpu, s5pc100 and s5pc110. In case of s5pc100 we don't
need to turn off l2 cache. but s5pc110 needs it.
So first check the device type, actually cpu type. then determine turn
off l2 cache or not.
0xC100 is the device type of s5pc100 then? So it should be
if (get_device_type() != S5PC100_DEVICE)
? I hear some people crying please use macro ;)
Agreed. DONT_NEED_CACHE_FLUSH?
But I don't like this selection here. When we get additional similar SoCs,
we will end with something like
if (get_device_type() != 0xC100) ||
(get_device_type() != FOO) ||
(get_device_type() != BAR)) ||
... {
modifying each time cpu/arm_cortexa8/cpu.c.
I would like more that we are able to compile the functionality based on the
config file we use for compilation. E.g. provide emtpy l2_cache_disable();
function for SoCs that don't need it, but have functionality behind it where
needed.
With above patch, this would then become something like
cpu/arm_cortexa8/s5pcxxx/dcache.S
- Implements invalidate_dcache() (or implement a Cortex A8 generic one in
cpu/arm_cortexa8/cache.S)
cpu/arm_cortexa8/s5pcxxx/cache_110.S
- Implements l2_cache_enable()/disable()
cpu/arm_cortexa8/s5pcxxx/cache_100.S
- Implements *empty* l2_cache_enable()/disable()
In cpu/arm_cortexa8/s5pcxxx/Makefile you then could have
SOBJS-y += dcache.o
SOBJS-$(CONFIG_S5PC100) += cache_100.o
SOBJS-$(CONFIG_S5PC110) += cache_110.o
What do you think about this?
Basically agreed, of course we can think weak attribute but now we
have to support both cpu simultaneously.
with this reason. we check the device_type at here.
What's about having this check in SoC specific code instead of Cortex
A8 generic code, then?
E.g apply patch
http://lists.denx.de/pipermail/u-boot/2009-August/058492.html
and then create
cpu/arm_cortexa8/s5pcxxx/cache.S
with
invalidate_dcache() {
if (get_device_type() == S5PC100_DEVICE)
return();
...
l2_cache_enable() {
if (get_device_type() == S5PC100_DEVICE)
return();
...
etc.
That is, have the SoC dependent part in SoC specific directory/file.
Best regards
Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm_cortexa8: support cache flush to other soc
Dear Kyungmin Park, In message 9c9fda240909040411w468baddv9cdd59fafeab2...@mail.gmail.com you wrote: Do you use the very same U-Boot image on both SoCs? Yes. One U-Boot image support 2 different CPU and 7 different boards. We don't want to make a u-boot for each board. Ah, this explains a lot. Thanks for this explanation. Um... do you have any plans how to handle this in a clean way that will scale for additional SoCs and boards as well, and that eventually can be used for other architectures, too? I guess you will have to address the same issues in your Linux ports? Do you consider using the device tree to implement the capability to adjust the software configuration to the specifics of the current hardware? I think this would be really beneficial both for U-Boot and Linux. I have to admit that I'm pretty much stuck between a rock and a hard place. I highly appreciate the fact that Samsung starts contributing code to Linux and now also U-Boot mainline trees,. and as such I want to encourage you all as much as possible, and not put any road blocks in your way when it can be avoided. I already hesitated when I rejected all these base address plus offset things and demanded these to be changed to C structs. I am well aware that is causes a lot of effort on your side without any immediately visible benefit (your code is already running, so why change it?). On the other hand, I have to keep an eye at the overall code quality, and to make sure the coderemains maintenable. From the patches I've seen so far I fear that we weill quickly see the code copmplexity explode when it comes to handling different SoC and board combinations within a single U-Boot image. I would like to point out that we should not go the way that is currently being used in the ARM Linux kernel. We will not duplicate the MACH_ID concepts used there and the resulting code methods. Instead, when we need to add such flexible configuration, we will go the device tree way. I hope such comment still comes in time to help you taking the right turns. 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 panic: kernel trap (ignored) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [Fwd: Newest Version U-boot]
Dears, Where can I download the newest u-boot version ? I tried download from DENX FTP server, but nothing are there? Thanks, Marcos Cunha Electrical Enginner ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Starting compressed win CE kernel
Hello Mr. Denk, Please stop doing this. Please post plain text only. Do not post HTML. Sorry, I don't know it. What makes you think that the uncompression code used by bootm would be any faster than the one used by unzip? It ain't faster, as it is the very same code actually. If bootm use the same code like the unzip command, then it couldn't be faster. But I have compressed a nk.bin Windows Image file with GZIP. Then I uncompressed the 10MB File with U-Boot. It takes roughly 1 minute. And this is to much I think. What could I do to reduce the uncompression time? My hardware works with an PXA270 CPU. Thanks, Andreas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Fwd: Newest Version U-boot]
Marcos Cunha wrote: Dears, Where can I download the newest u-boot version ? http://git.denx.de/?p=u-boot.git;a=summary Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Fwd: Newest Version U-boot]
Dear Marcos Cunha, In message 4aa0fed9.1050...@atlantico.com.br you wrote: Where can I download the newest u-boot version ? See http://www.denx.de/wiki/U-Boot/SourceCode I tried download from DENX FTP server, but nothing are there? Where did you look? I can see the latest release for example here: ftp://ftp.denx.de/pub/u-boot/u-boot-2009.08.tar.bz2 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 everyone read the manual. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Starting compressed win CE kernel
Dear A. Geisreiter, In message 001701ca2d55$f30b6200$d92226...@de you wrote: What makes you think that the uncompression code used by bootm would be any faster than the one used by unzip? It ain't faster, as it is the very same code actually. If bootm use the same code like the unzip command, then it couldn't be faster. Indeed. But I have compressed a nk.bin Windows Image file with GZIP. Then I uncompressed the 10MB File with U-Boot. It takes roughly 1 minute. And this is to much I think. What could I do to reduce the uncompression time? My hardware works with an PXA270 CPU. You probably want to enable caches on your system, to get faster performance. Jean-Christophe (on Cc:) claimed several times before that he was working on such patches. Maybe you ask him when he will post this stuff. 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 On the subject of C program indentation: In My Egotistical Opinion, most people's C programs should be indented six feet downward and covered with dirt. - Blair P. Houghton ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Fwd: Newest Version U-boot]
image/gifimage/gif___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] PPC440GX: DDR ECC init time.
Hi Wouter, On Friday 04 September 2009 14:34:49 Wouter Eckhardt wrote: I'm making quite good progress porting U-Boot (2009.03) to my custom PPC440GX board. 2009.03 is already old. I suggest you use the 2009.09 release. Right now I'm trying to solve a little problem I have with board start-up time when I enable ECC on DDR RAM. The board literally takes minutes to initialize RAM. I'm guessing this is due to the fact that ecc_init() fills the entire RAM (the comments already suggest some performance enhancements can be implemented). d-cache is the solution. I've tried solving this by shortly enabling the D cache before writing RAM and disabling the D cache afterwards, using the function change_tlb(). However, if I enable the D cache using change_tlb() and supply it with the same parameters ecc_init() receives, I get an exception when change_tlb() invalidates the cache. Did you flush the caches? You need to be careful here, when changing TLB attributes. Which DDR2 init code are you using btw? A specific custom code with fixed settings? Or the 4xx common SPD code? I suggest you take a look at the common DDR2 code (44x_spd_ddr2.c). ECC handling is done there already with caches enabled. This should give you an idea. 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] [Fwd: Newest Version U-boot]
Marcos Cunha wrote: Denx, I am trying to access this FTP server ftp://ftp.denx.de/pub/u-boot/, but the connection cannot be established and it is canceled by timeout (using Firefox). I tried with Internet Explorer, but its want a username and password, Anonymous account did not work. I will try to get this at home. I will post the result as soon as possible. Thanks, Marcos Cunha Wolfgang Denk wrote: Dear Marcos Cunha, In message 4aa0fed9.1050...@atlantico.com.br you wrote: Where can I download the newest u-boot version ? See http://www.denx.de/wiki/U-Boot/SourceCode I tried download from DENX FTP server, but nothing are there? Where did you look? I can see the latest release for example here: ftp://ftp.denx.de/pub/u-boot/u-boot-2009.08.tar.bz2 Best regards, Wolfgang Denk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] PPC440GX: DDR ECC init time.
Hi Stefan, Thanks for the quick reply. 2009.03 is already old. I suggest you use the 2009.09 release. Okay, shouldn't be too much trouble. (You actually meant .08, right? :-) d-cache is the solution. That's what I thought as well. Seems that coming up with the solution was a bit easier than actually implementing it... Did you flush the caches? You need to be careful here, when changing TLB attributes. Which DDR2 init code are you using btw? A specific custom code with fixed settings? Or the 4xx common SPD code? I suggest you take a look at the common DDR2 code (44x_spd_ddr2.c). ECC handling is done there already with caches enabled. This should give you an idea. I didn't flush the cache (seemed a bit pointless since they're not in use at that point anyway, right?). I'll give it a whirl. I'll also look into the other ECC initialization. I actually thought ECC initialization was only done in sdram.c (after a quick search for CONFIG_SDRAM_ECC). That probably also answers your next question. My SDRAM initialization is the same one as is used for the ALPR board and that uses the common code, as far as I know. Kind regards, Wouter Eckhardt. Disclaimer: The information contained in this email, including any attachments is confidential and is for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender immediately by replying to this message and destroy all copies of this message and any attachments. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Fwd: Newest Version U-boot]
It is supposed to be . Denk, Marcos Cunha wrote: Marcos Cunha wrote: Denx, I am trying to access this FTP server ftp://ftp.denx.de/pub/u-boot/, but the connection cannot be established and it is canceled by timeout (using Firefox). I tried with Internet Explorer, but its want a username and password, Anonymous account did not work. I will try to get this at home. I will post the result as soon as possible. Thanks, Marcos Cunha Wolfgang Denk wrote: Dear Marcos Cunha, In message 4aa0fed9.1050...@atlantico.com.br you wrote: Where can I download the newest u-boot version ? See http://www.denx.de/wiki/U-Boot/SourceCode I tried download from DENX FTP server, but nothing are there? Where did you look? I can see the latest release for example here: ftp://ftp.denx.de/pub/u-boot/u-boot-2009.08.tar.bz2 Best regards, Wolfgang Denk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- cid:image002.gif@01C8B04F.DE139770 *Marcos Aurélio pinto cunha, PMP Engenheiro eletricista / electrical engineer *** cid:image002.gif@01C8B04F.DE139770 cid:image003.gif@01C8B04F.DE139770 Fone: +55 (85) 3216.7934 Fax: +55 (85) 3216.7864 Skype: marcos.cunha.ufc *ISO 9001 : 2000 - CMMI3*** *www.atlantico.com.br http://www.atlantico.com.br*** ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] PPC440GX: DDR ECC init time.
Hi Wouter, On Friday 04 September 2009 15:06:52 Wouter Eckhardt wrote: 2009.03 is already old. I suggest you use the 2009.09 release. Okay, shouldn't be too much trouble. (You actually meant .08, right? :-) Of course. :) d-cache is the solution. That's what I thought as well. Seems that coming up with the solution was a bit easier than actually implementing it... Did you flush the caches? You need to be careful here, when changing TLB attributes. Which DDR2 init code are you using btw? A specific custom code with fixed settings? Or the 4xx common SPD code? I suggest you take a look at the common DDR2 code (44x_spd_ddr2.c). ECC handling is done there already with caches enabled. This should give you an idea. I didn't flush the cache (seemed a bit pointless since they're not in use at that point anyway, right?). I'll give it a whirl. I'll also look into the other ECC initialization. Good. I actually thought ECC initialization was only done in sdram.c (after a quick search for CONFIG_SDRAM_ECC). That probably also answers your next question. My SDRAM initialization is the same one as is used for the ALPR board and that uses the common code, as far as I know. Right. After looking at it, the ECC init is done in this common file. But the cache handling is missing here. I suggest you try to port this stuff from the DDR2 init file I mentioned in my last mail. 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] [PATCH] arm_cortexa8: support cache flush to other soc
Dear, Dirk
2009/9/4 Dirk Behme dirk.be...@googlemail.com
Kyungmin Park wrote:
On Fri, Sep 4, 2009 at 7:45 PM, Dirk Behmedirk.be...@googlemail.com
wrote:
Kyungmin Park wrote:
...
+ if (get_device_type() != 0xC100) {
Hmm, what is this 0xC100 ?
Now we got two cpu, s5pc100 and s5pc110. In case of s5pc100 we don't
need to turn off l2 cache. but s5pc110 needs it.
So first check the device type, actually cpu type. then determine turn
off l2 cache or not.
0xC100 is the device type of s5pc100 then? So it should be
if (get_device_type() != S5PC100_DEVICE)
? I hear some people crying please use macro ;)
Agreed. DONT_NEED_CACHE_FLUSH?
But I don't like this selection here. When we get additional similar
SoCs,
we will end with something like
if (get_device_type() != 0xC100) ||
(get_device_type() != FOO) ||
(get_device_type() != BAR)) ||
... {
modifying each time cpu/arm_cortexa8/cpu.c.
I would like more that we are able to compile the functionality based on
the
config file we use for compilation. E.g. provide emtpy
l2_cache_disable();
function for SoCs that don't need it, but have functionality behind it
where
needed.
With above patch, this would then become something like
cpu/arm_cortexa8/s5pcxxx/dcache.S
- Implements invalidate_dcache() (or implement a Cortex A8 generic one
in
cpu/arm_cortexa8/cache.S)
cpu/arm_cortexa8/s5pcxxx/cache_110.S
- Implements l2_cache_enable()/disable()
cpu/arm_cortexa8/s5pcxxx/cache_100.S
- Implements *empty* l2_cache_enable()/disable()
In cpu/arm_cortexa8/s5pcxxx/Makefile you then could have
SOBJS-y += dcache.o
SOBJS-$(CONFIG_S5PC100) += cache_100.o
SOBJS-$(CONFIG_S5PC110) += cache_110.o
What do you think about this?
Basically agreed, of course we can think weak attribute but now we
have to support both cpu simultaneously.
with this reason. we check the device_type at here.
What's about having this check in SoC specific code instead of Cortex
A8 generic code, then?
E.g apply patch
http://lists.denx.de/pipermail/u-boot/2009-August/058492.html
and then create
cpu/arm_cortexa8/s5pcxxx/cache.S
with
invalidate_dcache() {
if (get_device_type() == S5PC100_DEVICE)
return();
...
l2_cache_enable() {
if (get_device_type() == S5PC100_DEVICE)
return();
...
etc.
That is, have the SoC dependent part in SoC specific directory/file.
Best regards
Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
I know about the discussion of this issue between you and Jean-Christophe.
but it is gone without resolving.
So, I want to make issue again.
anyway,,
Actually, we don't need the function of get_device_type()
I think that function is omap specific function.. isn't it?
but.. because of current code already use that function, I had to use that
function
If you have plan to move the cache routines into SoC,
I think you can remove the argument for device_type. (check device type in
omap3's cache routines)
And I want to remove CONFIG_L2_OFF also.
We can know this through device type or soc type.
How about make new function?
e.g l2_off() or need_cache_flush() etc,
Please rework for removing dependency of omap3 soc first.
And then, I'll make new patch for s5pc1xx soc.
Many thanks :)
Minkyu Kang.
--
from. prom.
www.promsoft.net
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH][v1] mpc8260: move FDT memory node fixup into common CPU code.
Move the memory node fixup of the MPC8260ADS, ids8247 and muas3001 boards into
common mpc8260 CPU code.
Remove Ethernet node fixup from muas3001 board and modify its config for the
common mpc8260 code to use generic Ethernet fixup.
Signed-off-by: Marcel Ziswiler marcel.ziswi...@noser.com
---
board/freescale/mpc8260ads/mpc8260ads.c | 13
board/ids8247/ids8247.c | 16 --
board/muas3001/muas3001.c | 51 +-
cpu/mpc8260/cpu.c |1 +
include/configs/muas3001.h |1 +
5 files changed, 4 insertions(+), 78 deletions(-)
diff --git a/board/freescale/mpc8260ads/mpc8260ads.c b/board/freescale/mpc8260ad
s/mpc8260ads.c
index 49a88bb..be55626 100644
--- a/board/freescale/mpc8260ads/mpc8260ads.c
+++ b/board/freescale/mpc8260ads/mpc8260ads.c
@@ -550,24 +550,11 @@ void pci_init_board(void)
#endif
#if defined(CONFIG_OF_LIBFDT) defined(CONFIG_OF_BOARD_SETUP)
-void ft_blob_update(void *blob, bd_t *bd)
-{
- int ret;
-
- ret = fdt_fixup_memory(blob, (u64)bd-bi_memstart, (u64)bd-bi_memsize);
-
- if (ret 0) {
- printf(ft_blob_update(): cannot set /memory/reg
- property err:%s\n, fdt_strerror(ret));
- }
-}
-
void ft_board_setup(void *blob, bd_t *bd)
{
ft_cpu_setup(blob, bd);
#ifdef CONFIG_PCI
ft_pci_setup(blob, bd);
#endif
- ft_blob_update(blob, bd);
}
#endif
diff --git a/board/ids8247/ids8247.c b/board/ids8247/ids8247.c
index 79fe9da..d621833 100644
--- a/board/ids8247/ids8247.c
+++ b/board/ids8247/ids8247.c
@@ -400,24 +400,8 @@ int board_nand_init(struct nand_chip *nand)
#endif /* CONFIG_CMD_NAND */
#if defined(CONFIG_OF_BOARD_SETUP) defined(CONFIG_OF_LIBFDT)
-/*
- * update memory property in the blob
- */
-void ft_blob_update(void *blob, bd_t *bd)
-{
- int ret;
-
- ret = fdt_fixup_memory(blob, (u64)bd-bi_memstart, (u64)bd-bi_memsize);
-
- if (ret 0) {
- printf(ft_blob_update(): cannot set /memory/reg
- property err:%s\n, fdt_strerror(ret));
- }
-}
-
void ft_board_setup(void *blob, bd_t *bd)
{
ft_cpu_setup( blob, bd);
- ft_blob_update(blob, bd);
}
#endif /* defined(CONFIG_OF_BOARD_SETUP) defined(CONFIG_OF_LIBFDT) */
diff --git a/board/muas3001/muas3001.c b/board/muas3001/muas3001.c
index 8f83dd9..79c7a4c 100644
--- a/board/muas3001/muas3001.c
+++ b/board/muas3001/muas3001.c
@@ -308,26 +308,9 @@ int board_early_init_r (void)
void ft_blob_update (void *blob, bd_t *bd)
{
int ret, nodeoffset = 0;
- ulong memory_data[2] = {0};
ulong flash_data[4] = {0};
- ulong freq = 0;
- ulong speed = 0;
+ ulong speed = 0;
- memory_data[0] = cpu_to_be32 (bd-bi_memstart);
- memory_data[1] = cpu_to_be32 (bd-bi_memsize);
-
- nodeoffset = fdt_path_offset (blob, /memory);
- if (nodeoffset = 0) {
- ret = fdt_setprop (blob, nodeoffset, reg, memory_data,
- sizeof(memory_data));
- if (ret 0)
- printf (ft_blob_update): cannot set /memory/reg
- property err:%s\n, fdt_strerror (ret));
- } else {
- /* memory node is required in dts */
- printf (ft_blob_update(): cannot find /memory node
- err:%s\n, fdt_strerror(nodeoffset));
- }
/* update Flash addr, size */
flash_data[2] = cpu_to_be32 (CONFIG_SYS_FLASH_BASE);
flash_data[3] = cpu_to_be32 (CONFIG_SYS_FLASH_SIZE);
@@ -339,40 +322,10 @@ void ft_blob_update (void *blob, bd_t *bd)
printf (ft_blob_update): cannot set /localbus/ranges
property err:%s\n, fdt_strerror(ret));
} else {
- /* memory node is required in dts */
+ /* localbus node is required in dts */
printf (ft_blob_update(): cannot find /localbus node
err:%s\n, fdt_strerror (nodeoffset));
}
- /* MAC Adresse */
- nodeoffset = fdt_path_offset (blob, /soc/cpm/ethernet);
- if (nodeoffset = 0) {
- uchar ethaddr[6];
- eth_getenv_enetaddr(ethaddr, ethaddr);
- ret = fdt_setprop (blob, nodeoffset, mac-address, ethaddr,
- sizeof (uchar) * 6);
- if (ret 0)
- printf (ft_blob_update): cannot set /soc/cpm/ethernet/mac-addre
ss
- property err:%s\n, fdt_strerror (ret));
- } else {
- /* memory node is required in dts */
- printf (ft_blob_update(): cannot find /soc/cpm/ethernet node
- err:%s\n, fdt_strerror (nodeoffset));
- }
-
- /* brg clock */
- nodeoffset = fdt_path_offset (blob, /soc/cpm/brg);
- if (nodeoffset = 0) {
- freq = cpu_to_be32 (bd-bi_brgfreq);
-
[U-Boot] [PATCH][v2] ep8248: add support for device tree and secondary Ethernet interface.
Signed-off-by: Marcel Ziswiler marcel.ziswi...@noser.com
---
board/ep8248/ep8248.c| 22 +-
include/configs/ep8248.h | 53 --
2 files changed, 43 insertions(+), 32 deletions(-)
diff --git a/board/ep8248/ep8248.c b/board/ep8248/ep8248.c
index bc20ba7..6a190fe 100644
--- a/board/ep8248/ep8248.c
+++ b/board/ep8248/ep8248.c
@@ -5,6 +5,10 @@
* Support for Embedded Planet EP8248 boards.
* Tested on EP8248E.
*
+ * Copyright (C) 2009 Noser Engineering AG
+ * Marcel Ziswiler marcel.ziswi...@noser.com
+ * Added support for device tree and secondary Ethernet interface
+ *
* See file CREDITS for list of people who contributed to this
* project.
*
@@ -28,6 +32,12 @@
#include mpc8260.h
#include ioports.h
+#if defined(CONFIG_OF_LIBFDT)
+#include libfdt.h
+#include libfdt_env.h
+#include fdt_support.h
+#endif
+
/*
* I/O Port configuration table
*
@@ -35,8 +45,8 @@
* according to the five values podr/pdir/ppar/psor/pdat for that entry
*/
-#define CONFIG_SYS_FCC1 (CONFIG_ETHER_INDEX == 1)
-#define CONFIG_SYS_FCC2 (CONFIG_ETHER_INDEX == 2)
+#define CONFIG_SYS_FCC1 (CONFIG_ETHER_ON_FCC1 == 1)
+#define CONFIG_SYS_FCC2 (CONFIG_ETHER_ON_FCC2 == 1)
const iop_conf_t iop_conf_tab[4][32] = {
@@ -261,3 +271,11 @@ int checkboard(void)
return 0;
}
+
+#if defined(CONFIG_OF_BOARD_SETUP) defined(CONFIG_OF_LIBFDT)
+void ft_board_setup(void *blob, bd_t *bd)
+{
+ ft_cpu_setup( blob, bd);
+}
+#endif /* defined(CONFIG_OF_BOARD_SETUP) defined(CONFIG_OF_LIBFDT) */
+
diff --git a/include/configs/ep8248.h b/include/configs/ep8248.h
index f7b3fde..b1dbe7d 100644
--- a/include/configs/ep8248.h
+++ b/include/configs/ep8248.h
@@ -4,6 +4,10 @@
*
* U-Boot configuration for Embedded Planet EP8248 boards.
*
+ * Copyright (C) 2009 Noser Engineering AG
+ * Marcel Ziswiler marcel.ziswi...@noser.com
+ * Added support for device tree and secondary Ethernet interface
+ *
* See file CREDITS for list of people who contributed to this
* project.
*
@@ -50,50 +54,41 @@
#define CONFIG_SYS_BCSR0xFA00
-/*
- * Select ethernet configuration
- *
- * If either CONFIG_ETHER_ON_SCC or CONFIG_ETHER_ON_FCC is selected,
- * then CONFIG_ETHER_INDEX must be set to the channel number (1-4 for
- * SCC, 1-3 for FCC)
- *
- * If CONFIG_ETHER_NONE is defined, then either the ethernet routines
- * must be defined elsewhere (as for the console), or CONFIG_CMD_NET
- * must be unset.
- */
+/* Pass open firmware flat device tree */
+#define CONFIG_OF_LIBFDT 1
+#define CONFIG_OF_BOARD_SETUP 1
+
+#define OF_TBCLK(bd-bi_busfreq / 4)
+#define OF_STDOUT_PATH /soc/cpm/ser...@11a80
+
+/* Select ethernet configuration */
#undef CONFIG_ETHER_ON_SCC /* Ethernet is not on SCC */
#define CONFIG_ETHER_ON_FCC/* Ethernet is on FCC */
#undef CONFIG_ETHER_NONE /* No external Ethernet */
-#ifdef CONFIG_ETHER_ON_FCC
-
-#define CONFIG_ETHER_INDEX 1 /* FCC1 is used for Ethernet */
-
-#if (CONFIG_ETHER_INDEX == 1)
+#define CONFIG_NET_MULTI
+#define CONFIG_SYS_CPMFCR_RAMTYPE 0
+#define CONFIG_SYS_FCC_PSMR(FCC_PSMR_FDE | FCC_PSMR_LPB)
+#define CONFIG_HAS_ETH0
+#define CONFIG_ETHER_ON_FCC1 1
/* - Rx clock is CLK10
* - Tx clock is CLK11
* - BDs/buffers on 60x bus
* - Full duplex
*/
-#define CONFIG_SYS_CMXFCR_MASK (CMXFCR_FC1 | CMXFCR_RF1CS_MSK | CMXFCR_TF1CS_MS
K)
-#define CONFIG_SYS_CMXFCR_VALUE(CMXFCR_RF1CS_CLK10 | CMXFCR_TF1CS_CLK11
)
-#define CONFIG_SYS_CPMFCR_RAMTYPE 0
-#define CONFIG_SYS_FCC_PSMR(FCC_PSMR_FDE | FCC_PSMR_LPB)
-
-#elif (CONFIG_ETHER_INDEX == 2)
+#define CONFIG_SYS_CMXFCR_MASK1(CMXFCR_FC1 | CMXFCR_RF1CS_MSK | CMXFCR_
TF1CS_MSK)
+#define CONFIG_SYS_CMXFCR_VALUE1 (CMXFCR_RF1CS_CLK10 | CMXFCR_TF1CS_CLK11
)
+#define CONFIG_HAS_ETH1
+#define CONFIG_ETHER_ON_FCC2 1
/* - Rx clock is CLK13
* - Tx clock is CLK14
* - BDs/buffers on 60x bus
* - Full duplex
*/
-#define CONFIG_SYS_CMXFCR_MASK (CMXFCR_FC2 | CMXFCR_RF2CS_MSK | CMXFCR_TF2CS_MS
K)
-#define CONFIG_SYS_CMXFCR_VALUE(CMXFCR_RF2CS_CLK13 | CMXFCR_TF2CS_CLK14
)
-#define CONFIG_SYS_CPMFCR_RAMTYPE 0
-#define CONFIG_SYS_FCC_PSMR(FCC_PSMR_FDE | FCC_PSMR_LPB)
-
-#endif /* CONFIG_ETHER_INDEX */
+#define CONFIG_SYS_CMXFCR_MASK2(CMXFCR_FC2 | CMXFCR_RF2CS_MSK | CMXFCR_
TF2CS_MSK)
+#define CONFIG_SYS_CMXFCR_VALUE2 (CMXFCR_RF2CS_CLK13 | CMXFCR_TF2CS_CLK14
)
#define CONFIG_MII /* MII PHY management*/
#define CONFIG_BITBANGMII /* Bit-banged MDIO interface */
@@ -113,8 +108,6 @@
#define MIIDELAY udelay(1)
-#endif /* CONFIG_ETHER_ON_FCC */
-
#ifndef CONFIG_8260_CLKIN
#define CONFIG_8260_CLKIN 6600/* in Hz */
#endif
--
1.4.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
Re: [U-Boot] Odd value for I2C_TIMEOUT in fsl_i2c.c
Wolfgang Denk wrote: Wrong Question. I don't know enough about the I2C protocol. Why is i2c_wait4bus necessary? Ok, why is it necessary? Kumar, any thoughts? Is there something sneaky going on here, or did you just misinterpret the value of I2C_TIMEOUT? I guess I2C_TIMEOUT might always have been misinterpeted. I think the original code was correct, because it was counting clock ticks. -- 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] Odd value for I2C_TIMEOUT in fsl_i2c.c
Dear Timur Tabi, In message ed82fe3e0909040709u16adec47id77693ed53193...@mail.gmail.com you wrote: I cannot answer this question. I don't even understand why the i2c_wait4bus() function is needed at all. Can you explain? I don't know enough about the I2C protocol. Why is i2c_wait4bus unnecessary? Wrong Question. I don't know enough about the I2C protocol. Why is i2c_wait4bus necessary? Kumar, any thoughts? Is there something sneaky going on here, or did you just misinterpret the value of I2C_TIMEOUT? I guess I2C_TIMEOUT might always have been misinterpeted. 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 Virtual means never knowing where your next byte is coming from. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Odd value for I2C_TIMEOUT in fsl_i2c.c
On Fri, 2009-09-04 at 10:12 -0500, Timur Tabi wrote: Wolfgang Denk wrote: Wrong Question. I don't know enough about the I2C protocol. Why is i2c_wait4bus necessary? Ok, why is it necessary? Freescale's I2C core supports multiple masters. I'd guess that i2c_wait4bus() is used to ensure the bus is not in use by a different master before initiating a read or write. Its polling the MBB status bit, which is automatically set/cleared when the controller sees a START/STOP which supports this. If this is the case, the timeout should be the maximum (or reasonable maximum) time an I2C transaction could take. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Odd value for I2C_TIMEOUT in fsl_i2c.c
Dear Timur Tabi, In message 4aa12e52.2080...@freescale.com you wrote: Wrong Question. I don't know enough about the I2C protocol. Why is i2c_wait4bus necessary? Ok, why is it necessary? Maybe we should remove it, when nobody knows why it's needed. Kumar, any thoughts? Is there something sneaky going on here, or did you just misinterpret the value of I2C_TIMEOUT? I guess I2C_TIMEOUT might always have been misinterpeted. I think the original code was correct, because it was counting clock ticks. It cannot have been correct. get_timer() takes an argument of milliseconds, i. e. a time. (CONFIG_SYS_HZ / 4) is a frequency, i. e. not a time, but the inverse of it. It is plain wront to write 250 per second when you mean 250 milliseconds 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've been programming for (35-9=) 24 years myself, and I find the best way to learn a new language is to *read* every example snippet I can find, with a reference book close by. Eventually, the *rhythm* of the language starts pounding in my head... and my fluency is close at hand. That's how I learned Perl, and now I'm one of the drummers. :-) -- Randal L. Schwartz in 8cvi6p2tir@gadget.cscaper.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Odd value for I2C_TIMEOUT in fsl_i2c.c
Peter Tyser wrote: If this is the case, the timeout should be the maximum (or reasonable maximum) time an I2C transaction could take. How long is that? Is one millisecond good enough? -- 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 4/4] s5pc1xx: add support SMDKC100 board
Dear Minkyu Kang, In message 1f3430fb0909040747l5ef9b87wdef31942377c4...@mail.gmail.com you wrote: Why is this all written in assembly code? Cannot we use C instead? Because of this function called by lowlevel_init (before jumping to C code). Any problem? If so, we can merge to lowlevel_init.S. No, it's not a problem. I just wanted to understand the reasons. Normally we try to avoid assembly as much as possible, so I just wanted to make sure there was a good reason for using it here. Thanks for review. You are welcome. 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 shortest unit of time in the multiverse is the News York Second, defined as the period of time between the traffic lights turning green and the cab behind you honking. - Terry Pratchett, _Lords and Ladies_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm_cortexa8: support cache flush to other soc
Minkyu Kang wrote:
Dear, Dirk
2009/9/4 Dirk Behme dirk.be...@googlemail.com
Kyungmin Park wrote:
On Fri, Sep 4, 2009 at 7:45 PM, Dirk Behmedirk.be...@googlemail.com
wrote:
Kyungmin Park wrote:
...
+ if (get_device_type() != 0xC100) {
Hmm, what is this 0xC100 ?
Now we got two cpu, s5pc100 and s5pc110. In case of s5pc100 we don't
need to turn off l2 cache. but s5pc110 needs it.
So first check the device type, actually cpu type. then determine turn
off l2 cache or not.
0xC100 is the device type of s5pc100 then? So it should be
if (get_device_type() != S5PC100_DEVICE)
? I hear some people crying please use macro ;)
Agreed. DONT_NEED_CACHE_FLUSH?
But I don't like this selection here. When we get additional similar
SoCs,
we will end with something like
if (get_device_type() != 0xC100) ||
(get_device_type() != FOO) ||
(get_device_type() != BAR)) ||
... {
modifying each time cpu/arm_cortexa8/cpu.c.
I would like more that we are able to compile the functionality based on
the
config file we use for compilation. E.g. provide emtpy
l2_cache_disable();
function for SoCs that don't need it, but have functionality behind it
where
needed.
With above patch, this would then become something like
cpu/arm_cortexa8/s5pcxxx/dcache.S
- Implements invalidate_dcache() (or implement a Cortex A8 generic one
in
cpu/arm_cortexa8/cache.S)
cpu/arm_cortexa8/s5pcxxx/cache_110.S
- Implements l2_cache_enable()/disable()
cpu/arm_cortexa8/s5pcxxx/cache_100.S
- Implements *empty* l2_cache_enable()/disable()
In cpu/arm_cortexa8/s5pcxxx/Makefile you then could have
SOBJS-y += dcache.o
SOBJS-$(CONFIG_S5PC100) += cache_100.o
SOBJS-$(CONFIG_S5PC110) += cache_110.o
What do you think about this?
Basically agreed, of course we can think weak attribute but now we
have to support both cpu simultaneously.
with this reason. we check the device_type at here.
What's about having this check in SoC specific code instead of Cortex
A8 generic code, then?
E.g apply patch
http://lists.denx.de/pipermail/u-boot/2009-August/058492.html
and then create
cpu/arm_cortexa8/s5pcxxx/cache.S
with
invalidate_dcache() {
if (get_device_type() == S5PC100_DEVICE)
return();
...
l2_cache_enable() {
if (get_device_type() == S5PC100_DEVICE)
return();
...
etc.
That is, have the SoC dependent part in SoC specific directory/file.
Best regards
Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
I know about the discussion of this issue between you and Jean-Christophe.
but it is gone without resolving.
So, I want to make issue again.
anyway,,
Actually, we don't need the function of get_device_type()
I think that function is omap specific function.. isn't it?
but.. because of current code already use that function, I had to use that
function
If you have plan to move the cache routines into SoC,
I think you can remove the argument for device_type. (check device type in
omap3's cache routines)
And I want to remove CONFIG_L2_OFF also.
We can know this through device type or soc type.
How about make new function?
e.g l2_off() or need_cache_flush() etc,
Please rework for removing dependency of omap3 soc first.
Just to clarify: It's my understanding that this is already done by
http://lists.denx.de/pipermail/u-boot/2009-August/058492.html
Do you agree? That is, when this patch is applied, then Samsung can go
on. Correct?
If not correct, what is missing in above patch?
Best regards
Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][v1] mpc8260: move FDT memory node fixup into common CPU code.
Thanks for cleaning this up Marcel. I had a few comments though. Your
patch appears to be line wrapped. Please use git to send the patch or
configure your email client not to line-wrap.
On Fri, 2009-09-04 at 14:37 +, Marcel ziswiler wrote:
Move the memory node fixup of the MPC8260ADS, ids8247 and muas3001 boards into
common mpc8260 CPU code.
Shouldn't the mgcoge board also have the same change?
Remove Ethernet node fixup from muas3001 board and modify its config for the
common mpc8260 code to use generic Ethernet fixup.
The board-specific ethernet modifications should be in a separate patch
as that change is unrelated to the general FDT memory cleanup cleanup.
Otherwise the change looks good to me.
Best,
Peter
Signed-off-by: Marcel Ziswiler marcel.ziswi...@noser.com
---
board/freescale/mpc8260ads/mpc8260ads.c | 13
board/ids8247/ids8247.c | 16 --
board/muas3001/muas3001.c | 51 +-
cpu/mpc8260/cpu.c |1 +
include/configs/muas3001.h |1 +
5 files changed, 4 insertions(+), 78 deletions(-)
diff --git a/board/freescale/mpc8260ads/mpc8260ads.c
b/board/freescale/mpc8260ad
s/mpc8260ads.c
index 49a88bb..be55626 100644
--- a/board/freescale/mpc8260ads/mpc8260ads.c
+++ b/board/freescale/mpc8260ads/mpc8260ads.c
@@ -550,24 +550,11 @@ void pci_init_board(void)
#endif
#if defined(CONFIG_OF_LIBFDT) defined(CONFIG_OF_BOARD_SETUP)
-void ft_blob_update(void *blob, bd_t *bd)
-{
- int ret;
-
- ret = fdt_fixup_memory(blob, (u64)bd-bi_memstart,
(u64)bd-bi_memsize);
-
- if (ret 0) {
- printf(ft_blob_update(): cannot set /memory/reg
- property err:%s\n, fdt_strerror(ret));
- }
-}
-
void ft_board_setup(void *blob, bd_t *bd)
{
ft_cpu_setup(blob, bd);
#ifdef CONFIG_PCI
ft_pci_setup(blob, bd);
#endif
- ft_blob_update(blob, bd);
}
#endif
diff --git a/board/ids8247/ids8247.c b/board/ids8247/ids8247.c
index 79fe9da..d621833 100644
--- a/board/ids8247/ids8247.c
+++ b/board/ids8247/ids8247.c
@@ -400,24 +400,8 @@ int board_nand_init(struct nand_chip *nand)
#endif /* CONFIG_CMD_NAND */
#if defined(CONFIG_OF_BOARD_SETUP) defined(CONFIG_OF_LIBFDT)
-/*
- * update memory property in the blob
- */
-void ft_blob_update(void *blob, bd_t *bd)
-{
- int ret;
-
- ret = fdt_fixup_memory(blob, (u64)bd-bi_memstart,
(u64)bd-bi_memsize);
-
- if (ret 0) {
- printf(ft_blob_update(): cannot set /memory/reg
- property err:%s\n, fdt_strerror(ret));
- }
-}
-
void ft_board_setup(void *blob, bd_t *bd)
{
ft_cpu_setup( blob, bd);
- ft_blob_update(blob, bd);
}
#endif /* defined(CONFIG_OF_BOARD_SETUP) defined(CONFIG_OF_LIBFDT) */
diff --git a/board/muas3001/muas3001.c b/board/muas3001/muas3001.c
index 8f83dd9..79c7a4c 100644
--- a/board/muas3001/muas3001.c
+++ b/board/muas3001/muas3001.c
@@ -308,26 +308,9 @@ int board_early_init_r (void)
void ft_blob_update (void *blob, bd_t *bd)
{
int ret, nodeoffset = 0;
- ulong memory_data[2] = {0};
ulong flash_data[4] = {0};
- ulong freq = 0;
- ulong speed = 0;
+ ulong speed = 0;
- memory_data[0] = cpu_to_be32 (bd-bi_memstart);
- memory_data[1] = cpu_to_be32 (bd-bi_memsize);
-
- nodeoffset = fdt_path_offset (blob, /memory);
- if (nodeoffset = 0) {
- ret = fdt_setprop (blob, nodeoffset, reg, memory_data,
- sizeof(memory_data));
- if (ret 0)
- printf (ft_blob_update): cannot set /memory/reg
- property err:%s\n, fdt_strerror (ret));
- } else {
- /* memory node is required in dts */
- printf (ft_blob_update(): cannot find /memory node
- err:%s\n, fdt_strerror(nodeoffset));
- }
/* update Flash addr, size */
flash_data[2] = cpu_to_be32 (CONFIG_SYS_FLASH_BASE);
flash_data[3] = cpu_to_be32 (CONFIG_SYS_FLASH_SIZE);
@@ -339,40 +322,10 @@ void ft_blob_update (void *blob, bd_t *bd)
printf (ft_blob_update): cannot set /localbus/ranges
property err:%s\n, fdt_strerror(ret));
} else {
- /* memory node is required in dts */
+ /* localbus node is required in dts */
printf (ft_blob_update(): cannot find /localbus node
err:%s\n, fdt_strerror (nodeoffset));
}
- /* MAC Adresse */
- nodeoffset = fdt_path_offset (blob, /soc/cpm/ethernet);
- if (nodeoffset = 0) {
- uchar ethaddr[6];
- eth_getenv_enetaddr(ethaddr, ethaddr);
- ret = fdt_setprop (blob, nodeoffset, mac-address, ethaddr,
-
Re: [U-Boot] [PATCH 4/4] s5pc1xx: add support SMDKC100 board
Dear Wolfgang,
2009/9/4 Wolfgang Denk w...@denx.de
Dear Minkyu Kang,
In message 4aa0ce4a.3060...@samsung.com you wrote:
Add new board SMDKC100 that uses s5pc100 SoC
...
diff --git a/board/samsung/smdkc100/mem_setup.S
b/board/samsung/smdkc100/mem_setup.S
new file mode 100644
index 000..a3e692f
--- /dev/null
+++ b/board/samsung/smdkc100/mem_setup.S
Why is this all written in assembly code?
Cannot we use C instead?
Because of this function called by lowlevel_init (before jumping to C code).
Any problem?
If so, we can merge to lowlevel_init.S.
diff --git a/board/samsung/smdkc100/onenand.c
b/board/samsung/smdkc100/onenand.c
new file mode 100644
index 000..75bb8a9
--- /dev/null
+++ b/board/samsung/smdkc100/onenand.c
...
+static inline int onenand_read_reg(int offset)
+{
+ return readl(CONFIG_SYS_ONENAND_BASE + offset);
+}
+
+static inline void onenand_write_reg(int value, int offset)
+{
+ writel(value, CONFIG_SYS_ONENAND_BASE + offset);
+}
See previous comments about not using base address plus offset for
register accesses. Please change to use C structs.
...
diff --git a/board/samsung/smdkc100/smdkc100.c
b/board/samsung/smdkc100/smdkc100.c
new file mode 100644
index 000..4539ced
--- /dev/null
+++ b/board/samsung/smdkc100/smdkc100.c
...
+#include common.h
+DECLARE_GLOBAL_DATA_PTR;
+
+int board_init(void)
+{
+ gd-bd-bi_arch_number = MACH_TYPE;
Please don;t hide this information - use MACH_TYPE_SMDKC100 directly.
diff --git a/include/configs/smdkc100.h b/include/configs/smdkc100.h
new file mode 100644
index 000..ec0fd1d
--- /dev/null
+++ b/include/configs/smdkc100.h
...
+/*
+ * Architecture magic and machine type
+ */
+#define MACH_TYPE1826
Please do not do this. I recommend to omit this completely, and use
the MACH_TYPE_SMDKC100 defintion from include/asm-arm/mach-types.h
instead.
+/***
+ * Command definition
+ ***/
+#include config_cmd_default.h
+
+#undef CONFIG_CMD_LOADB
+#undef CONFIG_CMD_LOADS
+#undef CONFIG_CMD_BOOTD
+#undef CONFIG_CMD_FPGA
+#undef CONFIG_CMD_XIMG
+#undef CONFIG_CMD_NAND
+#undef CONFIG_CMD_IMLS
+#undef CONFIG_CMD_FLASH
+#undef CONFIG_CMD_IMLS
+#undef CONFIG_CMD_NET
Is there any specific reason for disabling these commands? Some of
these are extremely useful to the end user?
Also, you might want to sort such lists, and remove duplicate entries.
+#if 1
+#define CONFIG_BOOTCOMMAND run ubifsboot
+#else
+#define CONFIG_BOOTCOMMAND bootm 0x31008000
+#endif
Please do not add dead code.
...
+#define CONFIG_SYS_HZ2085900 /* at PCLK 66.75MHz
*/
NAK. It is a mandatory requirement that CONFIG_SYS_HZ must be 1000.
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 not underestimate the value of print statements for debugging.
Don't have aesthetic convulsions when using them, either.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Thanks for review.
Minkyu Kang.
--
from. prom.
www.promsoft.net
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][v2] ep8248: add support for device tree and secondary Ethernet interface.
Hi Marcel,
This patch also appears to be line wrapped.
Best,
Peter
On Fri, 2009-09-04 at 14:41 +, Marcel ziswiler wrote:
Signed-off-by: Marcel Ziswiler marcel.ziswi...@noser.com
---
board/ep8248/ep8248.c| 22 +-
include/configs/ep8248.h | 53
--
2 files changed, 43 insertions(+), 32 deletions(-)
diff --git a/board/ep8248/ep8248.c b/board/ep8248/ep8248.c
index bc20ba7..6a190fe 100644
--- a/board/ep8248/ep8248.c
+++ b/board/ep8248/ep8248.c
@@ -5,6 +5,10 @@
* Support for Embedded Planet EP8248 boards.
* Tested on EP8248E.
*
+ * Copyright (C) 2009 Noser Engineering AG
+ * Marcel Ziswiler marcel.ziswi...@noser.com
+ * Added support for device tree and secondary Ethernet interface
+ *
* See file CREDITS for list of people who contributed to this
* project.
*
@@ -28,6 +32,12 @@
#include mpc8260.h
#include ioports.h
+#if defined(CONFIG_OF_LIBFDT)
+#include libfdt.h
+#include libfdt_env.h
+#include fdt_support.h
+#endif
+
/*
* I/O Port configuration table
*
@@ -35,8 +45,8 @@
* according to the five values podr/pdir/ppar/psor/pdat for that entry
*/
-#define CONFIG_SYS_FCC1 (CONFIG_ETHER_INDEX == 1)
-#define CONFIG_SYS_FCC2 (CONFIG_ETHER_INDEX == 2)
+#define CONFIG_SYS_FCC1 (CONFIG_ETHER_ON_FCC1 == 1)
+#define CONFIG_SYS_FCC2 (CONFIG_ETHER_ON_FCC2 == 1)
const iop_conf_t iop_conf_tab[4][32] = {
@@ -261,3 +271,11 @@ int checkboard(void)
return 0;
}
+
+#if defined(CONFIG_OF_BOARD_SETUP) defined(CONFIG_OF_LIBFDT)
+void ft_board_setup(void *blob, bd_t *bd)
+{
+ ft_cpu_setup( blob, bd);
+}
+#endif /* defined(CONFIG_OF_BOARD_SETUP) defined(CONFIG_OF_LIBFDT) */
+
diff --git a/include/configs/ep8248.h b/include/configs/ep8248.h
index f7b3fde..b1dbe7d 100644
--- a/include/configs/ep8248.h
+++ b/include/configs/ep8248.h
@@ -4,6 +4,10 @@
*
* U-Boot configuration for Embedded Planet EP8248 boards.
*
+ * Copyright (C) 2009 Noser Engineering AG
+ * Marcel Ziswiler marcel.ziswi...@noser.com
+ * Added support for device tree and secondary Ethernet interface
+ *
* See file CREDITS for list of people who contributed to this
* project.
*
@@ -50,50 +54,41 @@
#define CONFIG_SYS_BCSR0xFA00
-/*
- * Select ethernet configuration
- *
- * If either CONFIG_ETHER_ON_SCC or CONFIG_ETHER_ON_FCC is selected,
- * then CONFIG_ETHER_INDEX must be set to the channel number (1-4 for
- * SCC, 1-3 for FCC)
- *
- * If CONFIG_ETHER_NONE is defined, then either the ethernet routines
- * must be defined elsewhere (as for the console), or CONFIG_CMD_NET
- * must be unset.
- */
+/* Pass open firmware flat device tree */
+#define CONFIG_OF_LIBFDT 1
+#define CONFIG_OF_BOARD_SETUP 1
+
+#define OF_TBCLK(bd-bi_busfreq / 4)
+#define OF_STDOUT_PATH /soc/cpm/ser...@11a80
+
+/* Select ethernet configuration */
#undef CONFIG_ETHER_ON_SCC /* Ethernet is not on SCC */
#define CONFIG_ETHER_ON_FCC/* Ethernet is on FCC */
#undef CONFIG_ETHER_NONE /* No external Ethernet */
-#ifdef CONFIG_ETHER_ON_FCC
-
-#define CONFIG_ETHER_INDEX 1 /* FCC1 is used for Ethernet */
-
-#if (CONFIG_ETHER_INDEX == 1)
+#define CONFIG_NET_MULTI
+#define CONFIG_SYS_CPMFCR_RAMTYPE 0
+#define CONFIG_SYS_FCC_PSMR(FCC_PSMR_FDE | FCC_PSMR_LPB)
+#define CONFIG_HAS_ETH0
+#define CONFIG_ETHER_ON_FCC1 1
/* - Rx clock is CLK10
* - Tx clock is CLK11
* - BDs/buffers on 60x bus
* - Full duplex
*/
-#define CONFIG_SYS_CMXFCR_MASK (CMXFCR_FC1 | CMXFCR_RF1CS_MSK |
CMXFCR_TF1CS_MS
K)
-#define CONFIG_SYS_CMXFCR_VALUE(CMXFCR_RF1CS_CLK10 |
CMXFCR_TF1CS_CLK11
)
-#define CONFIG_SYS_CPMFCR_RAMTYPE 0
-#define CONFIG_SYS_FCC_PSMR(FCC_PSMR_FDE | FCC_PSMR_LPB)
-
-#elif (CONFIG_ETHER_INDEX == 2)
+#define CONFIG_SYS_CMXFCR_MASK1(CMXFCR_FC1 | CMXFCR_RF1CS_MSK |
CMXFCR_
TF1CS_MSK)
+#define CONFIG_SYS_CMXFCR_VALUE1 (CMXFCR_RF1CS_CLK10 |
CMXFCR_TF1CS_CLK11
)
+#define CONFIG_HAS_ETH1
+#define CONFIG_ETHER_ON_FCC2 1
/* - Rx clock is CLK13
* - Tx clock is CLK14
* - BDs/buffers on 60x bus
* - Full duplex
*/
-#define CONFIG_SYS_CMXFCR_MASK (CMXFCR_FC2 | CMXFCR_RF2CS_MSK |
CMXFCR_TF2CS_MS
K)
-#define CONFIG_SYS_CMXFCR_VALUE(CMXFCR_RF2CS_CLK13 |
CMXFCR_TF2CS_CLK14
)
-#define CONFIG_SYS_CPMFCR_RAMTYPE 0
-#define CONFIG_SYS_FCC_PSMR(FCC_PSMR_FDE | FCC_PSMR_LPB)
-
-#endif /* CONFIG_ETHER_INDEX */
+#define CONFIG_SYS_CMXFCR_MASK2(CMXFCR_FC2 | CMXFCR_RF2CS_MSK |
CMXFCR_
TF2CS_MSK)
+#define CONFIG_SYS_CMXFCR_VALUE2 (CMXFCR_RF2CS_CLK13 |
CMXFCR_TF2CS_CLK14
)
#define CONFIG_MII /* MII PHY management*/
#define CONFIG_BITBANGMII /* Bit-banged MDIO interface */
@@ -113,8 +108,6 @@
Re: [U-Boot] Odd value for I2C_TIMEOUT in fsl_i2c.c
On Fri, 2009-09-04 at 10:30 -0500, Timur Tabi wrote: Peter Tyser wrote: If this is the case, the timeout should be the maximum (or reasonable maximum) time an I2C transaction could take. How long is that? Is one millisecond good enough? The timeout in i2c_wait4bus() could potentially be pretty large. The I2C bus could in theory be ran at very slow speeds, 1 cycle could be many bytes, etc. You'd have to dig into the spec to get a definitive answer about how long a maximum cycle is (if there is even a value), but I think it would have to be much longer than 1ms. Looks like the linux driver has a timeout of 1 second (for the equivalent of i2c_wait4bus()). I'd be fine with that for U-Boot too. 99% of boards don't have multiple masters so a large timeout shouldn't affect them at all. As far as the I2C_TIMEOUT in general I'm not sure either:) 1ms might be OK, but for reference the SMBus has a specified timeout of minimum 25ms, max 35ms. I'd tend to lean towards the conservative side as for devices that are working correctly, they will never timeout. If i2c transactions are timing out, I'd be more concerned about why than the extra 2 seconds my board took to boot:) I guess the i2c probe command might take a while too, but that personally doesn't bother me. In any case, I'd vote for a different, very large timeout value for i2c_wait4bus() and a few millisecond (or larger) timeout for I2C_TIMEOUT. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] sh7760 platform
I'm trying to use u-boot on renesas SH7760 (demo board edosk7760). Does anybody have any suggestions? Thanks in advance L. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] License cleanup: remove all files with All Rights Reserved notices.
-Original Message- From: Michal Simek [mailto:mon...@monstr.eu] Sent: Thursday, September 03, 2009 11:28 PM To: Wolfgang Denk Cc: u-boot@lists.denx.de; Stephen Neuendorffer Subject: Re: [U-Boot] [PATCH 2/2] License cleanup: remove all files with All Rights Reserved notices. Hi Wolfgang, 2009/9/2 Wolfgang Denk w...@denx.de All Rights Reserved conflicts with the GPL. Signed-off-by: Wolfgang Denk w...@denx.de --- drivers/net/ns9750_eth.c | 790 --- drivers/net/tigon3.c | 5697 drivers/net/tigon3.h | 3339 drivers/net/xilinx_emac.c | 464 -- This driver will be remove. I sent patch to Ben some days/week ago.Or of course you can remove. drivers/net/xilinx_emaclite.c | 354 -- There is only one part which is taken from Xilinx files, there was there their license. Currently Xilinx use GPL license for their files and on the based my experiences with them will not be problem to change a license in this driver. Steve: Can you please confirm me that I can change license to GPL compatible one? Then I sent a patch which fixed it. Yes, the intention is to release this code GPL'd. Please generate a patch: Signed-off-by: Stephen Neuendorffer stephen.neuendorf...@xilinx.com Wolfgang: It is driver in net tree. Is it going through you or Ben? The rest of xilinx files are related to ppc405/ppc440 and they don't have any connection with Microblaze. Thanks, Michal This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Question AT91SAM9G20 boot from SD
Hi, I have a AT91SAM9G20 and try to boot from SD-Card. I compiled u-boot, but the CONFIG_MMC is missing in the default mode. I found the default config for this board in /include/config/at91sam9260ek.h there I added the follofing lines: #define CONFIG_CMD_MMC 1 #define CONFIG_MMC 1 now I get a compiler error with: /common/cmd_mmc.c:53: undefined reference to `mmc_legacy_init',. Any ideas? bye konne ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Question AT91SAM9G20 boot from SD
On Fri, Sep 04, 2009 at 12:08:26PM +0200, Konrad Mattheis wrote : Hi, I have a AT91SAM9G20 and try to boot from SD-Card. I compiled u-boot, but the CONFIG_MMC is missing in the default mode. I found the default config for this board in /include/config/at91sam9260ek.h there I added the follofing lines: #define CONFIG_CMD_MMC 1 #define CONFIG_MMC 1 now I get a compiler error with: /common/cmd_mmc.c:53: undefined reference to `mmc_legacy_init',. Any ideas? You need an actual SD/MMC driver. Here, the driver is atmel_mci, and you need #define CONFIG_ATMEL_MCI in your board config.h Please note, though, that using the MCI driver on AT91 is not yet supported in mainline. In particular, please see the threads starting here for further information: http://lists.denx.de/pipermail/u-boot/2009-August/059595.html http://lists.denx.de/pipermail/u-boot/2009-September/059665.html Regards, -- Albin Tonnerre, Free Electrons Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Question AT91SAM9G20 boot from SD
Hi, I have a AT91SAM9G20 and try to boot from SD-Card. I compiled u-boot, but the CONFIG_MMC is missing in the default mode. I found the default config for this board in /include/config/at91sam9260ek.h there I added the follofing lines: #define CONFIG_CMD_MMC 1 #define CONFIG_MMC 1 now I get a compiler error with: /common/cmd_mmc.c:53: undefined reference to `mmc_legacy_init',. Any ideas? You need an actual SD/MMC driver. Here, the driver is atmel_mci, and you need #define CONFIG_ATMEL_MCI in your board config.h Please note, though, that using the MCI driver on AT91 is not yet supported in mainline. What does is mean, not yet. Do you have a plan to support this. Or is this a dead-end street? bye Konne ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Question AT91SAM9G20 boot from SD
On Fri, Sep 04, 2009 at 07:38:15PM +0200, Konrad Mattheis wrote : Hi, I have a AT91SAM9G20 and try to boot from SD-Card. I compiled u-boot, but the CONFIG_MMC is missing in the default mode. I found the default config for this board in /include/config/at91sam9260ek.h there I added the follofing lines: #define CONFIG_CMD_MMC 1 #define CONFIG_MMC 1 now I get a compiler error with: /common/cmd_mmc.c:53: undefined reference to `mmc_legacy_init',. Any ideas? You need an actual SD/MMC driver. Here, the driver is atmel_mci, and you need #define CONFIG_ATMEL_MCI in your board config.h Please note, though, that using the MCI driver on AT91 is not yet supported in mainline. What does is mean, not yet. Do you have a plan to support this. Or is this a dead-end street? As per the thread I pointed[1] out to you, there is an actual plan to support it, as the first mail suggests. That's a patch which implements such support, and is currently pending review... Please note that the atmel_mci is currently buggy for little-endian architectures (that is, at91), and needs fixing in that regard. One way to fix this was posted by Sami Kantoluoto in the first mail on [2], and a second way, as explained in the first reply to [2] [1] http://lists.denx.de/pipermail/u-boot/2009-September/059665.html [2] http://lists.denx.de/pipermail/u-boot/2009-August/059595.html Regards, -- Albin Tonnerre, Free Electrons Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Odd value for I2C_TIMEOUT in fsl_i2c.c
On Fri, Sep 04, 2009 at 05:29:48PM +0200, Wolfgang Denk wrote: Kumar, any thoughts? Is there something sneaky going on here, or did you just misinterpret the value of I2C_TIMEOUT? I guess I2C_TIMEOUT might always have been misinterpeted. I think the original code was correct, because it was counting clock ticks. It cannot have been correct. get_timer() takes an argument of milliseconds, i. e. a time. (CONFIG_SYS_HZ / 4) is a frequency, i. e. not a time, but the inverse of it. It is plain wront to write 250 per second when you mean 250 milliseconds It is not a frequency, it is a number of ticks. This is a very common idiom. The milliseconds interpretation of get_timer() is not documented anywhere in the code that I can see. Neither, again as far as I can see from a quick grep, is the requirement that CONFIG_SYS_HZ be 1000, other than in some board- or arch-specific files (some actually say that CONFIG_SYS_HZ must be *less* than 1000), or in mailing list archives. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Odd value for I2C_TIMEOUT in fsl_i2c.c
On Fri, Sep 04, 2009 at 10:31:00AM +0200, Wolfgang Denk wrote: CONFIG_HZ is 1000, so I2C_TIMEOUT is equal to 250. However, the way it's used, 250 isn't the number of ticks per second, it's used as number of microseconds. If CONFIG_HZ is changed to 100, does that mean that we want to call usec2ticks(25)? CONFIG_SYS_HZ is a constant of 1000. We do not change constants. We shouldn't call them CONFIGurable, then. :-) Out of curiosity, what is the reason why CONFIG_SYS_HZ must be 1000? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Odd value for I2C_TIMEOUT in fsl_i2c.c
Wolfgang Denk wrote: Probably not. If you place a read request to a slow device it may take tens of milliseconds, or even longer - I have no idea. IIRC we had a box with a LCD display connected over I2C, which didn't ent into production as originally designed because writing the content took over 100 millisec. Well, that's an extreme case that is board-specific. Perhaps I should do this: #ifndef CONFIG_I2C_TIMEOUT #define CONFIG_I2C_TIMEOUT 1000 #endif Keep in mind that so far, the number 250 has been good enough for every board to date. Why my current board is happier with 500 is a mystery to me. Also, should we be using the same value for the timeout in i2c_wait4bus() and i2c_wait()? It looks like i2c_wait() should have a much shorter timeout than i2c_wait4bus()? -- 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] Pull request u-boot-blackfin.git
Dear Mike Frysinger, In message 1252022831-4272-1-git-send-email-vap...@gentoo.org you wrote: The following changes since commit 3aa8b68d80dbcb6829af60485c1e388b39af793d: Wolfgang Denk (1): Merge branch 'next' of ../next are available in the git repository at: git://www.denx.de/git/u-boot-blackfin.git master Harald Krapfenbauer (1): Blackfin: cm-bf537u: new board port Michael Hennerich (1): Blackfin: bf537-stamp: comment CF-Flash Card Support better Mike Frysinger (5): Blackfin: fix debug printf modifiers Blackfin: increase default console size Blackfin: use scratch pad for exception stack Blackfin: enable 64bit printf for nand Blackfin: cm-bf548: fix device-stdio_dev fallout Robin Getz (3): Blackfin: use +(filesize) to make sure we are only doing what is necessary Blackfin: enable more network commands for ADI dev boards Blackfin: change global data register from P5 to P3 MAINTAINERS|1 + MAKEALL|1 + Makefile |2 +- README |4 +- board/cm-bf537u/Makefile | 54 + board/cm-bf537u/cm-bf537u.c| 66 board/cm-bf537u/config.mk | 34 board/cm-bf537u/flash.c| 34 board/cm-bf537u/gpio_cfi_flash.c | 60 ++ board/cm-bf537u/gpio_cfi_flash.h | 10 +++ board/cm-bf548/video.c |6 +- cpu/blackfin/interrupt.S |5 + doc/README.standalone |2 +- examples/standalone/stubs.c|4 +- include/asm-blackfin/config.h | 10 +- include/asm-blackfin/global_data.h |2 +- include/configs/bf537-stamp.h | 29 ++- include/configs/bfin_adi_common.h | 17 - include/configs/cm-bf537u.h| 150 lib_blackfin/board.c | 36 lib_blackfin/config.mk |2 +- 21 files changed, 488 insertions(+), 41 deletions(-) create mode 100644 board/cm-bf537u/Makefile create mode 100644 board/cm-bf537u/cm-bf537u.c create mode 100644 board/cm-bf537u/config.mk create mode 100644 board/cm-bf537u/flash.c create mode 100644 board/cm-bf537u/gpio_cfi_flash.c create mode 100644 board/cm-bf537u/gpio_cfi_flash.h create mode 100644 include/configs/cm-bf537u.h 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 What is mind? No matter. What is matter? Never mind. -- Thomas Hewitt Key, 1799-1875 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Odd value for I2C_TIMEOUT in fsl_i2c.c
Dear Scott Wood, In message 20090904183437.ga20...@b07421-ec1.am.freescale.net you wrote: milliseconds, i. e. a time. (CONFIG_SYS_HZ / 4) is a frequency, i. e. not a time, but the inverse of it. It is plain wront to write 250 per second when you mean 250 milliseconds It is not a frequency, it is a number of ticks. This is a very common idiom. CONFIG_SYS_HZ _is_ a frequenzy. It is the number of ticks _per_ _second_. That is the _inverse_ of a time unit, not a time unit. 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 Misquotation is, in fact, the pride and privilege of the learned. A widely-read man never quotes accurately, for the rather obvious reason that he has read too widely. - Hesketh Pearson _Common Misquotations_ introduction ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Odd value for I2C_TIMEOUT in fsl_i2c.c
Wolfgang Denk wrote: Dear Scott Wood, In message 20090904183437.ga20...@b07421-ec1.am.freescale.net you wrote: milliseconds, i. e. a time. (CONFIG_SYS_HZ / 4) is a frequency, i. e. not a time, but the inverse of it. It is plain wront to write 250 per second when you mean 250 milliseconds It is not a frequency, it is a number of ticks. This is a very common idiom. CONFIG_SYS_HZ _is_ a frequenzy. It is the number of ticks _per_ _second_. That is the _inverse_ of a time unit, not a time unit. Yes, CONFIG_SYS_HZ is a frequency. And when you multiply a _frequency_, which is _ticks_ per _second_, by a number _seconds_ (in this case, 1/4 sec), you get a number of _ticks_. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Odd value for I2C_TIMEOUT in fsl_i2c.c
Dear Scott Wood, In message 20090904183645.gb20...@b07421-ec1.am.freescale.net you wrote: CONFIG_SYS_HZ is a constant of 1000. We do not change constants. We shouldn't call them CONFIGurable, then. :-) Agreed. This should never have made it into public code. But it slipped through some 9 years ago, and I cannot turn back the clocks (at least not that far). Out of curiosity, what is the reason why CONFIG_SYS_HZ must be 1000? IIRC there are a number of places which make such an assumption, incorrectly. 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 To get something done, a committee should consist of no more than three men, two of them absent. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Odd value for I2C_TIMEOUT in fsl_i2c.c
Dear Timur Tabi, In message 4aa15ede.6080...@freescale.com you wrote: Well, that's an extreme case that is board-specific. Perhaps I should do this: #ifndef CONFIG_I2C_TIMEOUT #define CONFIG_I2C_TIMEOUT1000 #endif OK. Also, should we be using the same value for the timeout in i2c_wait4bus() and i2c_wait()? It looks like i2c_wait() should have a much shorter timeout than i2c_wait4bus()? I'd follow Peter's suggestion here. It sounds sane to me. 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 biggest difference between time and space is that you can't reuse time. - Merrick Furst ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] atmel_df_pow2: standalone to convert dataflashes to pow2
Dear Mike Frysinger, In message 1248381423-29524-1-git-send-email-vap...@gentoo.org you wrote: Atmel DataFlashes by default operate with pages that are slightly bigger than normal binary sizes (i.e. many are 1056 byte pages rather than 1024 bytes). However, they also have a power of 2 mode where the pages show up with the normal binary size. The latter mode is required in order to boot with a Blackfin processor, so many people wish to convert their DataFlashes on their development systems to this mode. This standalone application does just that. Signed-off-by: Mike Frysinger vap...@gentoo.org --- examples/standalone/.gitignore |1 + examples/standalone/Makefile|4 + examples/standalone/atmel_df_pow2.c | 209 +++ 3 files changed, 214 insertions(+), 0 deletions(-) create mode 100644 examples/standalone/atmel_df_pow2.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 is better for civilization to be going down the drain than to be coming up it. - Henry Allen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/10] mkconfig: parse top level makefile target to multiple config targets
Dear Hu Mingkai-B21284, sorry for the late reply [I have to admit that I kind of loist track where we are with this discussion - too many diverging statements found]. In message 73839b4a0818e747864426270ac332c3043f5...@zmy16exm20.fsl.freescale.net you wrote: How do you think of this method? Or can we handle the different options as follows? MPC8536DS_NAND_config: unconfig @echo $(obj)include/config.h; @echo #define CONFIG_$(subst MPC8536DS_,,$(subst config,U_BOOT,$@)) \ $(obj)include/config.h @$(MKCONFIG) -a MPC8536DS ppc mpc85xx mpc8536ds freescale @echo CONFIG_$(subst MPC8536DS_,,$(subst config,U_BOOT,$@)) = y \ $(obj)include/config.mk If there's an orthogonal option, such as 36BIT, we have to handle it seperately: MPC8536DS_NAND_config \ MPC8536DS_NAND_36BIT_config: unconfig @echo $(obj)include/config.h; @if [ $(findstring _36BIT_,$@ ] ; then \ echo #define CONFIG_PHYS_64BIT $(obj)include/config.h ; \ fi @echo #define CONFIG_$(subst MPC8536DS_,,$(subst config,U_BOOT,$@)) \ $(obj)include/config.h @$(MKCONFIG) -a MPC8536DS ppc mpc85xx mpc8536ds freescale @echo CONFIG_$(subst MPC8536DS_,,$(subst config,U_BOOT,$@)) = y \ $(obj)include/config.mk I don't like either of these. It should be enough to pass the make target name to the mkconfig script resp. the board config file, i. e. in this case either CONFIG_MPC8536DS_NAND or CONFIG_MPC8536DS_NAND_36BIT. The rest of the scripting/decision making can then be done in the board config file. If you want to avoid conflicts, feel free to chose a distict prefix, say CONFIG_MK_* or CONFIG_MAKE_* or so. 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 To get something done, a committee should consist of no more than three men, two of them absent. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] Consolidate arch-specific sbrk() implementations
Dear Peter Tyser, In message 1250913921-15689-2-git-send-email-pty...@xes-inc.com you wrote: Signed-off-by: Peter Tyser pty...@xes-inc.com --- common/dlmalloc.c | 18 +- include/malloc.h |6 ++ lib_arm/board.c| 20 lib_avr32/board.c | 19 --- lib_blackfin/board.c | 20 +++- lib_i386/board.c | 21 - lib_m68k/board.c | 20 lib_microblaze/board.c | 19 --- lib_mips/board.c | 19 --- lib_nios/board.c | 20 +--- lib_nios2/board.c | 20 +--- lib_ppc/board.c| 19 --- lib_sh/board.c | 18 -- lib_sparc/board.c | 19 --- 14 files changed, 28 insertions(+), 230 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 Unsichtbar macht sich die Dummheit, indem sie immer größere Ausmaße annimmt. -- Bertold Brecht: Der Tui-Roman ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] Standardize mem_malloc_init() implementation
Dear Peter Tyser, In message 1250913921-15689-3-git-send-email-pty...@xes-inc.com you wrote: This lays the groundwork to allow architectures to share a common mem_malloc_init(). Note that the x86 implementation was not modified as it did not fit the mold of all other architectures. Signed-off-by: Peter Tyser pty...@xes-inc.com --- lib_arm/board.c| 14 +++--- lib_avr32/board.c | 17 +++-- lib_blackfin/board.c | 12 ++-- lib_m68k/board.c | 17 +++-- lib_microblaze/board.c | 13 +++-- lib_mips/board.c | 17 +++-- lib_nios/board.c | 15 +++ lib_nios2/board.c | 13 ++--- lib_ppc/board.c| 21 ++--- lib_sh/board.c | 14 +++--- lib_sparc/board.c | 14 -- 11 files changed, 79 insertions(+), 88 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 I ever needed a brain transplant, I'd choose a teenager's because I'd want a brain that had never been used. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/17] Fix regression introduced by commit 8c63d47651f7
Dear Graeme Russ, In message 1250996401-13642-4-git-send-email-graeme.r...@gmail.com you wrote: A local variable was deleted that should not have been Signed-off-by: Graeme Russ graeme.r...@gmail.com --- lib_i386/pcat_timer.c |5 + 1 files changed, 5 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 C++ was an interesting and valuable experiment, but we've learned its lessons and it's time to move on. - Peter Curran in dcqm4z@isgtec.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 04/17] Fix environment configuration for eNET board
Dear Graeme Russ, In message 1250996401-13642-5-git-send-email-graeme.r...@gmail.com you wrote: The current configuration of the Environment has the redundant copy of the environment in the Boot Flash - This was never the intent. The Environment should instead be in the first two sectors of the first Strata Flash Signed-off-by: Graeme Russ graeme.r...@gmail.com --- include/configs/eNET.h | 11 +-- 1 files changed, 5 insertions(+), 6 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 easiest way to figure the cost of living is to take your income and add ten percent. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/17] Fix sc520 timer interrupt generation
Dear Graeme Russ, In message 1250996401-13642-6-git-send-email-graeme.r...@gmail.com you wrote: The current implementation has the timer being started before the interrupt handler is installed. It the interrupt occurs before the handler is installed, the timer interrupt is never reset and the timer stops Signed-off-by: Graeme Russ graeme.r...@gmail.com --- cpu/i386/sc520/sc520_timer.c |6 +++--- 1 files changed, 3 insertions(+), 3 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 There's no honorable way to kill, no gentle way to destroy. There is nothing good in war. Except its ending. -- Abraham Lincoln, The Savage Curtain, stardate 5906.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 06/17] Misc i386 PCI fixups
Dear Graeme Russ, In message 1250996401-13642-7-git-send-email-graeme.r...@gmail.com you wrote: Change PCI_REGION_MEMORY to PCI_REGION_SYS_MEMORY (Originally done in commit ff4e66e93c1a, regressed by commit 6d7f610b09f8) Cast PCI_ROM_ADDRESS_MASK to u32 Wrap probe_pci_video() call inside #ifdef CONFIG_VIDEO Change call to pci_find_class() to pci_find_devices(). This is based on a patch submitted on 1st March 2007 (Patch that fixes the compilation errors for sc520_cdp board) by mushtaq_k This patch requires that PCI_VIDEO_VENDOR_ID and PCI_VIDEO_DEVICE_ID be specified in the board config file. Dummy values have been added for the SC520 CDP board to enable compilation, but since I do not have one of these, I do know what the values should be Signed-off-by: Graeme Russ graeme.r...@gmail.com --- board/sc520_cdp/sc520_cdp.c |1 + cpu/i386/sc520/sc520_pci.c |2 +- include/configs/sc520_cdp.h |2 ++ lib_i386/pci.c |2 +- lib_i386/video_bios.c | 18 +- 5 files changed, 14 insertions(+), 11 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 was playing poker the other night... with Tarot cards. I got a full house and 4 people died. - Steven Wright ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/17] Misc SATA fixups
Dear Graeme Russ, In message 1250996401-13642-8-git-send-email-graeme.r...@gmail.com you wrote: Cast first parameter to sata_cpy() In /drivers/block/ata_piix.h, ata_id_has_lba48(), ata_id_has_lba(), ata_id_has_dma(), ata_id_u32(), ata_id_u64() are all defined in include/libata.h which is included in ata.h which is included by all files which include ata_piix.h (only ata_piix.c) so these definitions are supurflous to (and conlict with) this in libata.h. Interestingly, my compiler complains about ata_id_u64 already being defined, but not ata_id_u32 ata_dump_id() is defined in include/libata.h and should not be static (maybe should even use ata_dump_id() in libata.c Signed-off-by: Graeme Russ graeme.r...@gmail.com --- drivers/block/ata_piix.c | 10 +- drivers/block/ata_piix.h | 15 +-- 2 files changed, 6 insertions(+), 19 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 My play was a complete success. The audience was a failure. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/17] Misc ti_pci1410a fixups
Dear Graeme Russ, In message 1250996401-13642-9-git-send-email-graeme.r...@gmail.com you wrote: Removed do_pinit() - now declared in cmd_pcmcia.c Added #define CONFIG_CMD_PCMCIA around pcmcia_off() in line with other PCMCIA drivers signed/unsigned type fixups Added semi-colon after default: label as required by newer gcc The only board that appears to use this driver is the sc520_spunk which is very old and very likely very broken anyway. I do not have one to test whether this patch breaks anything functionaly, I have can only check that it compiles without warning or error Signed-off-by: Graeme Russ graeme.r...@gmail.com --- drivers/pcmcia/ti_pci1410a.c | 62 - 1 files changed, 18 insertions(+), 44 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 Don't hit a man when he's down - kick him; it's easier. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 09/17] Misc ds1722 fixups
Dear Graeme Russ, In message 1250996401-13642-10-git-send-email-graeme.r...@gmail.com you wrote: This patch is based on a patch submitted by Jean-Christophe PLAGNIOL-VILLARD on 18th May 2008 as part of a general i386 / sc520 fixup which was never applied Signed-off-by: Graeme Russ graeme.r...@gmail.com --- drivers/hwmon/ds1722.c |3 ++- include/ds1722.h | 32 2 files changed, 34 insertions(+), 1 deletions(-) create mode 100644 include/ds1722.h 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 On the subject of C program indentation: In My Egotistical Opinion, most people's C programs should be indented six feet downward and covered with dirt. - Blair P. Houghton ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/17] Fixup sc520_spunk board
Dear Graeme Russ, In message 1250996401-13642-11-git-send-email-graeme.r...@gmail.com you wrote: Primary intent is to resolve build errors for this board which has been neglected for a very long time. I do not have one of these boards, so I cannot test functionality Signed-off-by: Graeme Russ graeme.r...@gmail.com --- board/sc520_spunk/sc520_spunk.c | 33 +++-- include/configs/sc520_spunk.h |2 ++ 2 files changed, 33 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 thought my people would grow tired of killing. But you were right, they see it is easier than trading. And it has its pleasures. I feel it myself. Like the hunt, but with richer rewards. -- Apella, A Private Little War, stardate 4211.8 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 11/17] Misc sc520 cdp fixups
Dear Graeme Russ, In message 1250996401-13642-12-git-send-email-graeme.r...@gmail.com you wrote: Now that the PCI, SATA et al compile problems have been resolved, the cludge that was applied to avoid them can be removed Signed-off-by: Graeme Russ graeme.r...@gmail.com --- include/configs/sc520_cdp.h | 22 -- 1 files changed, 0 insertions(+), 22 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 There is nothing in this world constant but inconstancy. - Swift ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/17] Replace [read, write]_mmcr_[byte, word, long] with memory mapped structure
Dear Graeme Russ, In message 1250996401-13642-13-git-send-email-graeme.r...@gmail.com you wrote: Signed-off-by: Graeme Russ graeme.r...@gmail.com --- board/eNET/eNET.c | 86 board/sc520_cdp/flash.c | 14 +- board/sc520_cdp/sc520_cdp.c | 171 board/sc520_spunk/sc520_spunk.c | 211 ++-- cpu/i386/sc520/sc520.c | 71 ++-- cpu/i386/sc520/sc520_pci.c | 66 +++--- cpu/i386/sc520/sc520_ssi.c | 28 ++-- cpu/i386/sc520/sc520_timer.c| 31 ++-- include/asm-i386/ic/sc520.h | 417 ++- 9 files changed, 550 insertions(+), 545 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 Nobody trips over mountains. It is the small pebble that causes you to stumble. Pass all the pebbles in your path and you will find you have crossed the mountain. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 13/17] Moved PCI from #ifdef to conditional compile for sc520 boards
Dear Graeme Russ, In message 1250996401-13642-14-git-send-email-graeme.r...@gmail.com you wrote: --===2050527354== Signed-off-by: Graeme Russ graeme.r...@gmail.com --- board/eNET/Makefile | 10 +- board/sc520_cdp/Makefile| 14 +- board/sc520_cdp/sc520_cdp.c | 239 -- board/sc520_cdp/sc520_cdp_pci.c | 271 + board/sc520_spunk/Makefile | 14 +- board/sc520_spunk/sc520_spunk.c | 298 board/sc520_spunk/sc520_spunk_pci.c | 323 +++ lib_i386/Makefile |4 +- lib_i386/pci.c |3 - lib_i386/pci_type1.c|5 - 10 files changed, 617 insertions(+), 564 deletions(-) create mode 100644 board/sc520_cdp/sc520_cdp_pci.c create mode 100644 board/sc520_spunk/sc520_spunk_pci.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 Certainly there are things in life that money can't buy, but it's very funny - Did you ever try buying them without money? - Ogden Nash ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 14/17] Add PCI support to eNET board
Dear Graeme Russ, In message 1250996401-13642-15-git-send-email-graeme.r...@gmail.com you wrote: --===0053267559== Signed-off-by: Graeme Russ graeme.r...@gmail.com --- board/eNET/Makefile|1 + board/eNET/eNET_pci.c | 95 include/configs/eNET.h | 14 3 files changed, 103 insertions(+), 7 deletions(-) create mode 100644 board/eNET/eNET_pci.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 IBM uses what I like to call the 'hole-in-the-ground technique' to destroy the competition. IBM digs a big HOLE in the ground and covers it with leaves. It then puts a big POT OF GOLD nearby. Then it gives the call, 'Hey, look at all this gold, get over here fast.' As soon as the competitor approaches the pot, he falls into the pit - John C. Dvorak ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] Ethernet Support for eNET Board
Dear Graeme Russ, In message 4a990ae7.2080...@gmail.com you wrote: OK, after much wailing and gnashing of teeth, I have FINALLY got the Ethernet chips on my eNET board working. In the end, the critical mod was in drivers/net/rtl8139.c, line 217 where I needed to change PCI_BASE_ADDRESS_1 to PCI_BASE_ADDRESS_0 - The big question for me now is Why? I assume this driver is working for everyone else, and this change will probably break the driver for everyone else, so now I need to know what I can do so that Ethernet works on my board WITHOUT modifying rtl8139.c I also had to move SC520_PCI_IO_PHYS from 0x1000 to 0x2000 because I have LEDs, Hex Switches and a couple of other board specific I/O at 0x1000 Anyone got any ideas? diff --git a/board/eNET/eNET.c b/board/eNET/eNET.c I understand this is not to apply yet? Signed-off-by: etc are missing... 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 In an organization, each person rises to the level of his own incom- petency - The Peter Principle ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Use different PBA value for E1000 PCI and PCIe cards
Dear Roy Zang, In message 1250884192.23342.3.ca...@rock.ap.freescale.net you wrote: From: Roy Zang tie-fei.z...@freescale.com Use different PBA value for E1000 PCI and PCIe cards. Signed-off-by: Roy Zang tie-fei.z...@freescale.com --- Andre, please help to verify it on your board. Thanks. Roy drivers/net/e1000.c | 12 ++-- 1 files changed, 10 insertions(+), 2 deletions(-) Applied, thanks. Sorry that I missed this for v2009.08 ... 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 are very flexible and learn to adjust to strange surroundings -- they can become accustomed to read Lisp and Fortran programs, for example. - Leon Sterling and Ehud Shapiro, Art of Prolog, MIT Press ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
