Re: [U-Boot] [PATCH V7 1/3] MX5: clock: Add clock config interface
Hi, Stefano,
2011/5/16 Stefano Babic sba...@denx.de:
On 05/11/2011 10:03 AM, Jason Liu wrote:
diff --git a/arch/arm/cpu/armv7/mx5/clock.c b/arch/arm/cpu/armv7/mx5/clock.c
index 0b04a88..04d9f71 100644
--- a/arch/arm/cpu/armv7/mx5/clock.c
+++ b/arch/arm/cpu/armv7/mx5/clock.c
@@ -24,6 +24,7 @@
*/
+#define AHB_CLK_ROOT 1
+#define SZ_DEC_1M 100
Is this define used only to get the value in Mhz from the PLL clock ? If
it is the case, the name is quite confusing, as it refers to a size. If
it is not the case, please explain.
I will get rid of the definition for AHB_CLK_ROOT and it's no need to
define here
since it only use once in the code.
I will rename the SZ_DEC_1M or get rid of it also.
+#define PLL_PD_MAX 16 /* Actual pd+1 */
+#define PLL_MFI_MAX 15
+#define PLL_MFI_MIN 5
+#define ARM_DIV_MAX 8
+#define IPG_DIV_MAX 4
+#define AHB_DIV_MAX 8
+#define EMI_DIV_MAX 8
+#define NFC_DIV_MAX 8
Definitions for clock registers are in the crm_regs.h file. These are
the maximum values for some fields in the registers. Should they not be
put inside the crm_regs.h ?
Yes, make sense, I will put it to crm_regs.h file.
+
+struct fixed_pll_mfd {
+ u32 ref_clk_hz;
+ u32 mfd;
+};
+
+const struct fixed_pll_mfd fixed_mfd[] = {
+ {CONFIG_SYS_MX5_HCLK, 24 * 16},
+};
Not understood the need of an array (I have not said it is wrong, simply
I have not understood !). You use in the code (this is another issue)
ref as parameter for your functions for the reference clock, but is
seems to me that the only possible value is CONFIG_SYS_MX5_HCLK.
I use array here just for the case we will have another element in the array
(currently we only have one) in the future. Currently, we use 24MHz as ref.
Are there other use case for this array, that makes sense to define and
maybe to extend it ?
Just in case the PLL ref clock is not from 24MHZ.
Can you add a reference to the manual explaining where these values are
coming from ?
Do you mean the value 24 * 16? If yes, it's just for the simpler calculation.
+
+struct pll_param {
+ u32 pd;
+ u32 mfi;
+ u32 mfn;
+ u32 mfd;
+};
+
+#define PLL_FREQ_MAX(ref_clk) (4 * (ref_clk) * PLL_MFI_MAX)
+#define PLL_FREQ_MIN(ref_clk) \
+ ((2 * (ref_clk) * (PLL_MFI_MIN - 1)) / PLL_PD_MAX)
I understand what it is done here, but only after I have finally found
where it is described in the manual. Can you add useful comments here
and reference to the manual, too ? Such as describing these values are
for the registers DP_OP, DP_MFN and DP-MFD, and a reference to the
formula (Eqn. 22-1) helps to understand it.
OK, I will add the comments here.
+#define MAX_DDR_CLK 42000
+#define NFC_CLK_MAX 3400
Where do these values come from ? I understand they are computed values,
depending on pll clock. It seems to me (at least for DDR clock) they are
absolute maximum rates, but it could be that MAX_DDR_CLK could be set to
a lower value depending on the PLL value. Is it correct ? In other words
: should be possible to set a PLL (you provide an API for changing it)
to a lower value, and then even the defines you set here do not
correspond to the real maximum value ?
Yes, this is the absolute maximum rate. When you clk_api to config
clock, it should not
exceed the max value, for example,
if (emi_clk MAX_DDR_CLK) {
printf(DDR clock should be less than
%d MHz, assuming max value \n,
...
+
/*
* The API of get mxc clockes.
*/
@@ -245,10 +369,12 @@ unsigned int mxc_get_clock(enum mxc_clock clk)
case MXC_UART_CLK:
return get_uart_clk();
case MXC_CSPI_CLK:
- return imx_get_cspiclk();
+ return get_cspi_clk();
case MXC_FEC_CLK:
return decode_pll(mxc_plls[PLL1_CLOCK],
CONFIG_SYS_MX5_HCLK);
+ case MXC_DDR_CLK:
+ return get_ddr_clk();
You extended the enum for the clocks, as I see also MXC_NFC_CLK. You
should add the MXC_NFC_CLK case, too.
OK, I will add it.
Is it worth to export the other getter functions, too (get_axi_a/b_clk,
get_ahb_clk) ?
Yes, I think it's valuable to export it and print it, thus user can
know clearly what
the axi_a/b and ahb clk rate are.
/*
+ * Clock config code start here
+ */
+
+/* precondition: m0 and n0. Let g=gcd(m,n). */
+static int gcd(int m, int n)
+{
+ int t;
+ while (m 0) {
+ if (n m) {
+ t = m;
+ m = n;
+ n = t;
+ } /* swap */
+ m -= n;
+ }
+ return n;
+}
This function has nothing to do with MX5 code. This is a general
function, and should be add to lib/. I think you have to remove it from
here and put it in a separate patch.
I don't think it should be put to lib since only
[U-Boot] Fwd: Re: [PATCH v2 10/22] omap4: utility function to identify the context of hw init
Copying to the list. Accidentally missed it last time. Original Message Subject: Re: [U-Boot] [PATCH v2 10/22] omap4: utility function to identify the context of hw init Date: Mon, 16 May 2011 20:03:52 +0530 From: Aneesh V ane...@ti.com To: Wolfgang Denk w...@denx.de Hi Wolfgang, On Monday 16 May 2011 01:29 AM, Wolfgang Denk wrote: Dear Aneesh V, In message1305472900-4004-11-git-send-email-ane...@ti.com you wrote: The basic hardware init of OMAP4(s_init()) can happen in 4 different contexts: 1. SPL running from SRAM 2. U-Boot running from FLASH 3. Non-XIP U-Boot loaded to SDRAM by SPL 4. Non-XIP U-Boot loaded to SDRAM by ROM code using the Configuration Header feature ... +if (uboot_loaded_by_spl()) +return OMAP_INIT_CONTEXT_UBOOT_LOADED_BY_SPL; +else if (running_from_sdram()) +return OMAP_INIT_CONTEXT_UBOOT_LOADED_BY_CH; For reasons of consistency, should this not better be OMAP_INIT_CONTEXT_UBOOT_LOADED_BY_ROM ? Ok. +return OMAP_INIT_CONTEXT_XIP_UBOOT; What exactly is OMAP_INIT_CONTEXT_XIP_UBOOT? Do you mean the situation when booting from NOR flash, before relocation? Yes, this is for the NOR case. Eventually the loaded by definition is not so good, as it does not really cover the NOR boot case. Please note that loaded by definition is not there for all the options. The definition is the 'context' in which the init code is executing. +/* HW Init Context */ +#define OMAP_INIT_CONTEXT_SPL 0 +#define OMAP_INIT_CONTEXT_XIP_UBOOT 1 +#define OMAP_INIT_CONTEXT_UBOOT_LOADED_BY_SPL 2 +#define OMAP_INIT_CONTEXT_UBOOT_LOADED_BY_CH3 Boot from NOR? Best regards, Wolfgang Denk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/22] mkimage: Add OMAP boot image support
Hi Mike,
On Tuesday 17 May 2011 12:12 AM, Mike Frysinger wrote:
On Monday, May 16, 2011 06:28:40 Aneesh V wrote:
On Monday 16 May 2011 08:25 AM, Mike Frysinger wrote:
On Sunday, May 15, 2011 21:52:53 Mike Frysinger wrote:
On Sunday, May 15, 2011 11:21:19 Aneesh V wrote:
+static void omapimage_print_header(const void *ptr)
+{
+ struct ch_toc *toc = (struct ch_toc *)ptr;
you're casting away the void. something is fundamentally broken here.
err, obviously i meant const instead of void ...
This is not my code.
you're submitting the patch with only your s-o-b on it. that means you're
responsible for it all.
No. both From and s-o-b are John's on this patch.
static void omapimage_print_header(const void *ptr)
{
-struct ch_toc *toc = (struct ch_toc *)ptr;
+const struct ch_toc *toc = (const struct ch_toc *)ptr;
drop the cast entirely ... this isnt C++ after all:
const struct ch_toc *toc = ptr;
ok.
best regards,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 02/22] omap4: add OMAP4430 revision check
Hi Wolfgang, On Monday 16 May 2011 09:05 PM, Wolfgang Denk wrote: Dear Aneesh V, ... 1. Please note that the above function is just for getting the string not for the revision itself. To get the revision we have omap4_revision(). Well, when you already have such a funxction, then why cannot it be made to return useful values that are well-suited for formatting? Instead of #define OMAP4430_ES1_0 1 #define OMAP4430_ES2_0 2 #define OMAP4430_ES2_1 3 #define OMAP4430_ES2_2 4 you could use #define OMAP4430_ES1_0 10 #define OMAP4430_ES2_0 20 #define OMAP4430_ES2_1 21 #define OMAP4430_ES2_2 22 And then use a plain sprintf(omap4_rev, OMAP4430 ES%d.%d, rev/10, rev%10); or similar. This is a good idea. The only minor hitch is that OMAP4460 will come into picture in near future, again having at least ES1_0. But I think that can be worked out. best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/22] omap4: save parameters passed by ROM code to SPL
Hi Wolfgang, On Monday 16 May 2011 09:07 PM, Wolfgang Denk wrote: Dear Aneesh V, In message4dd1189d.4050...@ti.com you wrote: Save this information in SPL so that we can use the same media and mode to bootload u-boot. Signed-off-by: Aneesh Vane...@ti.com ... + /* Store the boot device in omap4_boot_device */ + ldr r2, [r0, #BOOT_DEVICE_OFFSET] @ r1- value of boot device + and r2, #BOOT_DEVICE_MASK + ldr r3, =omap4_boot_device + str r2, [r3]@ omap4_boot_device- r1 Why don't you use stadard global data here? SPL has access to .data right from the beginning. Besides this is too early. global data is not initialized yet. Please keep in mind that this is a special situation then. The code will not work as intended for example when running form NOR flash. Yes, I realize that. The values passed in the ARM registers need to be saved before they are lost. At the moment only SPL needs them. We do not have a board with NOR flash yet. If there is a need in the future we may have to save it in some predefined special purpose memory such as the scratchpad memory of OMAP or some location in the internal RAM that is not used. But there is no such need at the moment. best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/22] Add generic spl infrastructure
Hi Scott,
On Tuesday 17 May 2011 12:02 AM, Scott Wood wrote:
On Sun, 15 May 2011 20:51:24 +0530
Aneesh Vane...@ti.com wrote:
diff --git a/Makefile b/Makefile
index 384a59e..d3f4bef 100644
--- a/Makefile
+++ b/Makefile
@@ -289,6 +289,22 @@ LDPPFLAGS += \
$(shell $(LD) --version | \
sed -ne 's/GNU ld version
\([0-9][0-9]*\)\.\([0-9][0-9]*\).*/-DLD_MAJOR=\1 -DLD_MINOR=\2/p')
+ifeq ($(CONFIG_NAND_U_BOOT),y)
+NAND_SPL = nand_spl
+U_BOOT_NAND = $(obj)u-boot-nand.bin
+endif
+
+ifeq ($(CONFIG_SPL),y)
+.PHONEY : SPL
+ALL += SPL
+endif
+
+ifeq ($(CONFIG_ONENAND_U_BOOT),y)
+ONENAND_IPL = onenand_ipl
+U_BOOT_ONENAND = $(obj)u-boot-onenand.bin
+ONENAND_BIN ?= $(obj)onenand_ipl/onenand-ipl-2k.bin
+endif
+
__OBJS := $(subst $(obj),,$(OBJS))
__LIBS := $(subst $(obj),,$(LIBS)) $(subst $(obj),,$(LIBBOARD))
@@ -402,8 +418,13 @@ $(obj)u-boot.lds: $(LDSCRIPT)
$(CPP) $(CPPFLAGS) $(LDPPFLAGS) -ansi -D__ASSEMBLY__ -P -$^$@
nand_spl: $(TIMESTAMP_FILE) $(VERSION_FILE) depend
+
+$(NAND_SPL):$(TIMESTAMP_FILE) $(VERSION_FILE) depend
You are reverting part of e935a374dbe5c745fdde05b2b07ced0bbe70887f. Merge
accident?
Oops! That indeed seems like a merge accident. I will correct it in the
next version.
@@ -1141,12 +1163,14 @@ clobber: clean
@rm -f $(obj)u-boot $(obj)u-boot.map $(obj)u-boot.hex $(ALL)
@rm -f $(obj)u-boot.kwb
@rm -f $(obj)u-boot.imx
+@rm -f $(obj)MLO
What is MLO?
MLO is the name of SPL created for OMAP. ROM code expects a file with
this name as the first image when it boots from FAT.
diff --git a/arch/arm/include/asm/global_data.h
b/arch/arm/include/asm/global_data.h
index 2a84d27..2ce020e 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -89,6 +89,11 @@ typedef struct global_data {
#define GD_FLG_DISABLE_CONSOLE 0x00040 /* Disable console (in out)
*/
#define GD_FLG_ENV_READY 0x00080 /* Environment imported into hash table
*/
+#ifdef CONFIG_PRELOADER
+/* SPL works from internal RAM. gd pointer can be in .data section */
+#define DECLARE_GLOBAL_DATA_PTR extern gd_t *gd
+#else
#define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm (r8)
+#endif
Is this appropriate for all ARM boards (e.g. those currently using
nand_spl)?
None of the SPL's other than this one seems to be using global data
today. If anybody wants to use it this seems to be the logical option
for me because by definition SPL runs from some kind of RAM so global
data can be placed in the .data section of SPL.
best regards,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 08/22] omap: add spl support
Hi Wolfgang, On Monday 16 May 2011 09:13 PM, Wolfgang Denk wrote: Dear Aneesh V, In message4dd13056.3000...@ti.com you wrote: Again, this appears to be not the right order. I think, in the first step of this series, we should move the existing code from nand_spl and onenand_ipl into something like spl/nand and spl/onenand, respectivly, and make sure all teh existing systems still build. The we can add more such support. IMHO, we should just have spl/board/vendor/board/ . Let spl/board/vendor/board/Makefile decide what it wants to build. There are common, board independent parts both in spl/nand and spl/onenand. How about having them at the root level in 'spl/' ? best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 09/22] omap4: add spl support for OMAP4 SDP
Hi Wolfgang, On Monday 16 May 2011 09:18 PM, Wolfgang Denk wrote: Dear Aneesh V, In message4dd134dd.6040...@ti.com you wrote: create mode 100644 spl/board/ti/omap4.mk create mode 100644 spl/board/ti/rules-omap.mk We do you introduce these files? Please omit them, and use a plain Makefile instead. I introduced them because 'spl/board/ti/sdp4430/Makefile' and 'spl/board /ti/panda/Makefile' were exactly same and wanted to re-use the make rules. But in the result, the Makefiles are still the same, aren't they? Yes, but the contents are not duplicated in two files. Easier for maintenance. I indeed wanted to abstract it out even further in future so that the make rules can be shared between OMAP3 and OMAP4 too. This way the changes needed to support a new board will be lesser and maintenance will be easier while adding new features. For instance, if I have to add NAND support today I just need to update omap4.mk instead of updating the Makefile of both panda and SDP. This re-use will be evident when you see a later patch that replicates the same Makefile for panda. Can you please rather try and move this to a common directory level, then? The top-level make rule being the following, we will need a Makefile in the board directory, right? +SPL:$(TIMESTAMP_FILE) $(VERSION_FILE) depend tools +$(MAKE) -C spl/board/$(BOARDDIR) all I have a bad feeling about this. If the Makefiles are the same, then the code is probably more or less the same, also. Eventually larger parts of the code should be moved to a common directory, too? In fact, code is already common. All OMAP code specific to SPL comes from spl/board/ti/spl-omap.c . All OMAP code shared with OMAP U-Boot comes from the respective directory within arch/arm/cpu/armv7/* In the interest of simplicity I deferred all board specific initialization of OMAP4(mainly mux) to U-Boot. So, SPL is board independent today for OMAP4. best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 10/22] omap4: utility function to identify the context of hw init
Dear Aneesh V, In message 4dd135d0.8070...@ti.com you wrote: + return OMAP_INIT_CONTEXT_XIP_UBOOT; What exactly is OMAP_INIT_CONTEXT_XIP_UBOOT? Do you mean the situation when booting from NOR flash, before relocation? Yes, this is for the NOR case. Then please call it like that. XIP has a special emaning, that may or may not be related to running from ROM. Eventually the loaded by definition is not so good, as it does not really cover the NOR boot case. Please note that loaded by definition is not there for all the options. The definition is the 'context' in which the init code is executing. So please get rid of the LOADED_BY names. 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 Today's robots are very primitive, capable of understanding only a few simple instructions such as 'go left', 'go right', and 'build car'. - John Sladek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/6] TFTP: net/tftp.c: add server mode receive
Detlev Zundel wrote: Hi Luca, Signed-off-by: Luca Ceresoliluca.ceres...@comelit.it Cc: Wolfgang Denkw...@denx.de --- Changes in v2: none. Only one comment below net/tftp.c | 72 --- net/tftp.h |6 + 2 files changed, 74 insertions(+), 4 deletions(-) diff --git a/net/tftp.c b/net/tftp.c index e166a63..87eb0b8 100644 --- a/net/tftp.c +++ b/net/tftp.c @@ -2,6 +2,8 @@ * Copyright 1994, 1995, 2000 Neil Russell. * (See License) * Copyright 2000, 2001 DENX Software Engineering, Wolfgang Denk, w...@denx.de + * Copyright 2011 Comelit Group SpA, + * Luca Ceresoliluca.ceres...@comelit.it */ #includecommon.h @@ -74,6 +76,7 @@ static short TftpNumchars; /* The number of hashes we printed */ #define STATE_TOO_LARGE3 #define STATE_BAD_MAGIC4 #define STATE_OACK 5 +#define STATE_RECV_WRQ 6 #define TFTP_BLOCK_SIZE512 /* default TFTP block size */ #define TFTP_SEQUENCE_SIZE ((ulong)(116))/* sequence number is 16 bit */ @@ -241,6 +244,10 @@ TftpSend (void) TftpBlock=ext2_find_next_zero_bit(Bitmap,(Mapsize*8),0); /*..falling..*/ #endif + +#ifdef CONFIG_CMD_TFTPSRV +case STATE_RECV_WRQ: +#endif case STATE_DATA: xp = pkt; s = (ushort *)pkt; @@ -293,7 +300,11 @@ TftpHandler(uchar *pkt, unsigned dest, IPaddr_t sip, unsigned src, #endif return; } -if (TftpState != STATE_SEND_RRQ src != TftpRemotePort) +if (TftpState != STATE_SEND_RRQ +#ifdef CONFIG_CMD_TFTPSRV +TftpState != STATE_RECV_WRQ +#endif +src != TftpRemotePort) return; Hm, I have to admit that I do not really like adding so many ifdefs into the tftp code and even into the state machine code. Can you give me a number on how much larger u-boot gets on your platform with and without the server support? If this is not too much, maybe we should include support always. If it is too much, maybe we can at least keep the state machine without ifdefs - if I see it correctly, this will only add at maximum a few bytes and STATE_RECW_WRQ will simply never be entered, correct? Here are my measurements for the dig297 board (ARMV7 OMAP3): textdata bss dec hex 3570858684 214264 580033 8d9c1 TFTPSRV on 3563278660 214264 579251 8d6b3 TFTPSRV off, without #ifs 3563558660 214268 579283 8d6d3 TFTPSRV off, with #ifs (as in PATCH v2) The TFTP server adds 730 bytes to the text, so I guess it's worth to keep it optional. To my big surprise, removing most bad-looking #ifs (all of those that save just one line) I got a *smaller* U-Boot! I repeated the test three times to be extra sure, the figures are correct: without the #ifs we save a few bytes. Obvious enough, I'm going to remove the #ifs. Luca ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 02/22] omap4: add OMAP4430 revision check
Dear Aneesh V, In message 4dd21843.4060...@ti.com you wrote: you could use #define OMAP4430_ES1_0 10 #define OMAP4430_ES2_0 20 #define OMAP4430_ES2_1 21 #define OMAP4430_ES2_2 22 And then use a plain sprintf(omap4_rev, OMAP4430 ES%d.%d, rev/10, rev%10); or similar. This is a good idea. The only minor hitch is that OMAP4460 will come into picture in near future, again having at least ES1_0. But I think that can be worked out. Then go for something like #define OMAP4430_ES1_0 0x44300100 #define OMAP4430_ES2_0 0x44300200 #define OMAP4430_ES2_1 0x44300201 #define OMAP4430_ES2_2 0x44300202 sprintf(omap4_rev, OMAP%x ES%x.%x, (rev 16) 0x, (rev 8) 0xFF, rev 0xFF); 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 The optimum committee has no members. - Norman Augustine ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/22] omap4: save parameters passed by ROM code to SPL
Dear Aneesh V, In message 4dd21961.7070...@ti.com you wrote: SPL has access to .data right from the beginning. Besides this is too early. global data is not initialized yet. Please keep in mind that this is a special situation then. The code will not work as intended for example when running form NOR flash. Yes, I realize that. The values passed in the ARM registers need to be saved before they are lost. At the moment only SPL needs them. We do not have a board with NOR flash yet. If there is a need in the future we may have to save it in some predefined special purpose memory such as the scratchpad memory of OMAP or some location in the internal RAM that is not used. But there is no such need at the moment. OK. Maybe you can add a comment that explains this situation. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It may be that our role on this planet is not to worship God but to create him. - Arthur C. Clarke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/22] Add generic spl infrastructure
Dear Aneesh V, In message 4dd21baa.6000...@ti.com you wrote: What is MLO? MLO is the name of SPL created for OMAP. ROM code expects a file with this name as the first image when it boots from FAT. What does MLO mean? +#ifdef CONFIG_PRELOADER +/* SPL works from internal RAM. gd pointer can be in .data section */ +#define DECLARE_GLOBAL_DATA_PTR extern gd_t *gd +#else #define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm (r8) +#endif Is this appropriate for all ARM boards (e.g. those currently using nand_spl)? None of the SPL's other than this one seems to be using global data today. If anybody wants to use it this seems to be the logical option for me because by definition SPL runs from some kind of RAM so global data can be placed in the .data section of SPL. But that's not what you are doing. You are not changing the storage of the global data itself, you are changing the storage of the POINTER TO the global data - and this makes no sense to me. The pointer can certainly remain in a register even if the data itself is somewhere else. This will save us this #ifdef here. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Witch! Witch! They'll burn ya! -- Hag, Tomorrow is Yesterday, stardate unknown ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 08/22] omap: add spl support
Dear Aneesh V, In message 4dd21cd8.2080...@ti.com you wrote: There are common, board independent parts both in spl/nand and spl/onenand. How about having them at the root level in 'spl/' ? Why? It seems more logical to me to group nand and onenand related files in their own subdirectories. 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 Quantum Mechanics is God's version of Trust me. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 09/22] omap4: add spl support for OMAP4 SDP
Dear Aneesh V, In message 4dd21fb9.6070...@ti.com you wrote: The top-level make rule being the following, we will need a Makefile in the board directory, right? +SPL:$(TIMESTAMP_FILE) $(VERSION_FILE) depend tools +$(MAKE) -C spl/board/$(BOARDDIR) all Maybe this needs to be tweaked to allow for boards that don;t require board specific code. In fact, code is already common. All OMAP code specific to SPL comes from spl/board/ti/spl-omap.c . All OMAP code shared with OMAP U-Boot comes from the respective directory within arch/arm/cpu/armv7/* In the interest of simplicity I deferred all board specific initialization of OMAP4(mainly mux) to U-Boot. So, SPL is board independent today for OMAP4. Then we should adapt the directory and Makefile structure and allow for such common code without need for separate spl/board/ directories. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A mouse is an elephant built by the Japanese. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] Accurate boot time measurement
Hi Simon and Wolfgang, [...] In terms of all this discussion I can see your point :-) I did have expressions of interest from two people including one I thought was at your company, which I why I went to the effort to clean up and submit this. At that time I didn't realise it would be such a touchy subject. I don't believe this topic to be touchy, it's just that Wolfgang trying to keep the whole code base in shape has a healthy inertia before introducing changes that may be difficult to keep consistent over the multitude of SoCs that we support. To throw in my personal view again, I still would like to see such an infrastructure to get into U-Boot code. I fully agree with Wolfgang that practically the printfs and timing are a method already in place to do measurements. On the other hand my experience has shown that for some reason or other this has never been widely used. So effectively, it wasn't too helpful for the project itself. So I still believe that if we _had_ an infrastructure like you propose, we would get more people interested in _actually_ measuring and improving the code base, which would certainly be a good thing. Of course we have systems that are very limited in their ressources, but this is the reason why many features of U-Boot are opt-in features not forcing any resource usage on such boards. So if some of them are so short on resources that they cannot use such a timing framework, then so be it. But as most of the probably are in the legacy code base, they should not stop us from getting getting positive effects for the currently important boards and architectures. Cheers Detlev -- A change in language can transform our appreciation of the cosmos -- Benjamin Lee Whorf -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] ARMV7: MMC SPL Boot support for SMDKV310 board
Dear Chander Kashyap,
Sorry to late review.
On 21 April 2011 16:02, Chander Kashyap chander.kash...@linaro.org wrote:
Added MMC SPL boot support for SMDKV310. This framework design is
based on nand_spl support.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
---
Makefile | 9 ++
spl/board/samsung/smdkv310/Makefile | 103
+++
spl/board/samsung/smdkv310/mmc_boot.c | 82 ++
spl/board/samsung/smdkv310/tools/mkv310_image.c | 103
+++
spl/board/samsung/smdkv310/u-boot.lds | 86 +++
5 files changed, 383 insertions(+), 0 deletions(-)
create mode 100644 spl/board/samsung/smdkv310/Makefile
create mode 100644 spl/board/samsung/smdkv310/mmc_boot.c
create mode 100644 spl/board/samsung/smdkv310/tools/mkv310_image.c
create mode 100644 spl/board/samsung/smdkv310/u-boot.lds
diff --git a/Makefile b/Makefile
index 713dba1..a298221 100644
--- a/Makefile
+++ b/Makefile
@@ -321,6 +321,10 @@ ALL += $(obj)u-boot-onenand.bin
ONENAND_BIN ?= $(obj)onenand_ipl/onenand-ipl-2k.bin
endif
+ifeq ($(CONFIG_MMC_U_BOOT),y)
+ALL += $(obj)spl/v310_mmc_spl.bin
NAK.
This naming is SoC specific.
And binary is should be located in root directory, I think..
e.g) ALL += $(obj)u-boot-mmc.bin
+endif
+
all: $(ALL)
$(obj)u-boot.hex: $(obj)u-boot
@@ -412,6 +416,11 @@ onenand_ipl: $(TIMESTAMP_FILE) $(VERSION_FILE)
$(obj)include/autoconf.mk
$(obj)u-boot-onenand.bin: onenand_ipl $(obj)u-boot.bin
cat $(ONENAND_BIN) $(obj)u-boot.bin $(obj)u-boot-onenand.bin
+spl: $(TIMESTAMP_FILE) $(VERSION_FILE) depend
mmc_spl is better.
+ $(MAKE) -C spl/board/$(BOARDDIR) all
+
+$(obj)spl/v310_mmc_spl.bin: spl
+
$(VERSION_FILE):
@( localvers='$(shell $(TOPDIR)/tools/setlocalversion
$(TOPDIR))' ; \
printf '#define PLAIN_VERSION %s%s\n' \
And you missed clean and clobber sections.
diff --git a/spl/board/samsung/smdkv310/Makefile
b/spl/board/samsung/smdkv310/Makefile
new file mode 100644
index 000..fdede6b
--- /dev/null
+++ b/spl/board/samsung/smdkv310/Makefile
@@ -0,0 +1,103 @@
+#
+# (C) Copyright 2006-2007
+# Stefan Roese, DENX Software Engineering, s...@denx.de.
+#
+# (C) Copyright 2008
+# Guennadi Liakhovetki, DENX Software Engineering, l...@denx.de
+#
+# (C) Copyright 2011
+# Chander Kashyap, Samsung Electronics, k.chan...@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 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
+#
+
+CONFIG_MMC_SPL = y
+
+include $(TOPDIR)/config.mk
+
+LDSCRIPT= $(TOPDIR)/spl/board/$(BOARDDIR)/u-boot.lds
+LDFLAGS = -Bstatic -T $(mmcobj)u-boot.lds -Ttext
$(CONFIG_SYS_TEXT_BASE) $(PLATFORM_LDFLAGS)
+AFLAGS += -DCONFIG_MMC_SPL
+CFLAGS += -DCONFIG_MMC_SPL
Please add -DCONFIG_PRELOADER also.
+
+SOBJS = start.o mem_setup.o lowlevel_init.o
+COBJS = mmc_boot.o
+
+SRCS := $(addprefix $(obj),$(SOBJS:.o=.S) $(COBJS:.o=.c))
+OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS))
+__OBJS := $(SOBJS) $(COBJS)
+LNDIR := $(OBJTREE)/spl/board/$(BOARDDIR)
+
+mmcobj := $(OBJTREE)/spl/
+
+
+MKBIN_V310_MMC_SPL_BIN = mkv310_mmc_spl_bin
+MMC_SPL_BIN = v310_mmc_spl.bin
+
+ALL = $(mmcobj)u-boot-spl $(mmcobj)u-boot-spl.bin $(mmcobj)$(MMC_SPL_BIN)
+
+all: $(obj).depend $(ALL)
+
+$(mmcobj)$(MMC_SPL_BIN): $(mmcobj)u-boot-spl.bin
tools/$(MKBIN_V310_MMC_SPL_BIN)
+ ./tools/$(MKBIN_V310_MMC_SPL_BIN) $(mmcobj)u-boot-spl.bin
$(mmcobj)$(MMC_SPL_BIN)
+
+tools/$(MKBIN_V310_MMC_SPL_BIN): tools/mkv310_image.c
+ $(HOSTCC) tools/mkv310_image.c -o tools/$(MKBIN_V310_MMC_SPL_BIN)
+
+$(mmcobj)u-boot-spl.bin: $(mmcobj)u-boot-spl
+ $(OBJCOPY) ${OBJCFLAGS} -O binary $ $@
+
+$(mmcobj)u-boot-spl: $(OBJS) $(mmcobj)u-boot.lds
+ cd $(LNDIR) $(LD) $(LDFLAGS) $(__OBJS) \
+ -Map $(mmcobj)u-boot-spl.map \
+ -o $(mmcobj)u-boot-spl
+
+$(mmcobj)u-boot.lds: $(LDSCRIPT)
+ $(CPP) $(CPPFLAGS) $(LDPPFLAGS) -ansi -D__ASSEMBLY__ -P - $^ $@
+
+# create symbolic links for common files
+
+# from cpu directory
Re: [U-Boot] [PATCHv2] sntp: avoid use of uninitialized variable
Hi Chris,
From: Luuk Paulussen luuk.paulus...@alliedtelesis.co.nz
When we use the ntpserverip environment variable argv[1] may not be set.
Printing the error message using the NetNtpServerIP variable ensures the
correct output in both cases.
Signed-off-by: Luuk Paulussen luuk.paulus...@alliedtelesis.co.nz
Acked-by: Chris Packham chris.pack...@alliedtelesis.co.nz
Cc: Ben Warren biggerbadder...@gmail.com
---
Changes since v1:
- run through checkpatch.pl, fix line 80 chars
common/cmd_net.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/common/cmd_net.c b/common/cmd_net.c
index 8c6f5c8..fae3c7f 100644
--- a/common/cmd_net.c
+++ b/common/cmd_net.c
@@ -324,7 +324,8 @@ int do_sntp (cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
else NetTimeOffset = simple_strtol (toff, NULL, 10);
if (NetLoop(SNTP) 0) {
- printf(SNTP failed: host %s not responding\n, argv[1]);
+ printf(SNTP failed: host %pI4 not responding\n,
+ NetNtpServerIP);
return 1;
}
Acked-by: Detlev Zundel d...@denx.de
Cheers
Detlev
--
Is this a private fight or can anyone join in?
-- Old Irish saying
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] S5PC2XX: add the sromc header file
Add missing header file.
Signed-off-by: Minkyu Kang mk7.k...@samsung.com
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
---
arch/arm/include/asm/arch-s5pc2xx/sromc.h | 51 +
1 files changed, 51 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/arch-s5pc2xx/sromc.h
diff --git a/arch/arm/include/asm/arch-s5pc2xx/sromc.h
b/arch/arm/include/asm/arch-s5pc2xx/sromc.h
new file mode 100644
index 000..f616bcb
--- /dev/null
+++ b/arch/arm/include/asm/arch-s5pc2xx/sromc.h
@@ -0,0 +1,51 @@
+/*
+ * (C) Copyright 2010 Samsung Electronics
+ * Naveen Krishna Ch ch.nav...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ * Note: This file contains the register description for SROMC
+ *
+ */
+
+#ifndef __ASM_ARCH_SROMC_H_
+#define __ASM_ARCH_SROMC_H_
+
+#define SROMC_DATA16_WIDTH(x)(1((x*4)+0))
+#define SROMC_BYTE_ADDR_MODE(x) (1((x*4)+1)) /* 0- Half-word base
address*/
+ /* 1- Byte base address*/
+#define SROMC_WAIT_ENABLE(x) (1((x*4)+2))
+#define SROMC_BYTE_ENABLE(x) (1((x*4)+3))
+
+#define SROMC_BC_TACS(x) (x 28) /* address set-up */
+#define SROMC_BC_TCOS(x) (x 24) /* chip selection set-up */
+#define SROMC_BC_TACC(x) (x 16) /* access cycle */
+#define SROMC_BC_TCOH(x) (x 12) /* chip selection hold */
+#define SROMC_BC_TAH(x) (x 8) /* address holding time */
+#define SROMC_BC_TACP(x) (x 4) /* page mode access cycle */
+#define SROMC_BC_PMC(x) (x 0) /* normal(1data)page mode configuration */
+
+#ifndef __ASSEMBLY__
+struct s5p_sromc {
+ unsigned intbw;
+ unsigned intbc[4];
+};
+#endif /* __ASSEMBLY__ */
+
+/* Configure the Band Width and Bank Control Regs for required SROMC Bank */
+void s5p_config_sromc(u32 srom_bank, u32 srom_bw_conf, u32 srom_bc_conf);
+
+#endif /* __ASM_ARCH_SROMC_H_ */
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] S5PC2XX: add the sromc header file
Dear Minkyu Kang, In message 4dd23309.1080...@samsung.com you wrote: Add missing header file. This should not be handled separately, but rather be squashed into the patch that now creates the problem, i. e. 04/15 Chander Kashyap[U-Boot] [PATCH] S5P:SROM config code moved to s5p-common directory http://article.gmane.org/gmane.comp.boot-loaders.u-boot/97781 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 All repairs tend to destroy the structure, to increase the entropy and disorder of the system. Less and less effort is spent on fixing original design flaws; more and more is spent on fixing flaws intro- duced by earlier fixes. - Fred Brooks, The Mythical Man Month ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] S5P:SROM config code moved to s5p-common directory
Dear Chander Kashyap, In message 1302843918-1105-1-git-send-email-chander.kash...@linaro.org you wrote: SROM config code is made common for S5P series of boards. smdkc100.c now refers to s5p-common/sromc.c for SROM related subroutines. Signed-off-by: Chander Kashyap chander.kash...@linaro.org It appears this is missing arch/arm/include/asm/arch-s5pc2xx/sromc.h Please squash with patch submitted here: 05/17 Minkyu Kang[U-Boot] [PATCH] S5PC2XX: add the sromc header file http://article.gmane.org/gmane.comp.boot-loaders.u-boot/99965 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 combination of a number of things to make existence worthwhile. Yes, the philosophy of 'none,' meaning 'all.' -- Spock and Lincoln, The Savage Curtain, stardate 5906.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 02/10] armv7: add miscellaneous utility macros
Hi Wolfgang, On Tuesday 17 May 2011 10:57 AM, Wolfgang Denk wrote: Dear Simon Glass, In messagebanlktine7bfsyousgxwg0rg3ownbpn_...@mail.gmail.com you wrote: There are a few very primitive macros in setbits and clrbits. I would very much like to see at least: Maybe we can agree to use these existing macros then instead of inventing new ones with the same functionality. - define a field once in a header in an easy format along with any enums which define allowable values if applicable - pack and unpack a value into a field: so set a bitfield to 13, for exampl= e - obtain a mask for a field (i.e. with all bits set) - equivalent of writel and readl for a bitfield (writel in fact being read/modify/write so perhaps a different name) Some of these exist, some don't. Do you know of examples of such more complex definitions in the Linux kernel code? In fact I had searched for a macro for similar needs as my set_bit_field() is addressing in Linux Kernel too but didn't find any. Please note that my requirement is not for doing IO but doing bit field operations on a C integer variable: 1. Prepare a variable field by field to be finally written to a register using writel() 2. Extract a field from a variable that typically holds the value of a register after a readl() I couldn't find any utility macros/functions for doing something like this. Please somebody correct me if I am wrong. best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 03/10] armv7: cache maintenance operations for armv7
On Monday 16 May 2011 12:21 AM, Wolfgang Denk wrote:
Dear Aneesh V,
In message1305202276-27784-4-git-send-email-ane...@ti.com you wrote:
- Add a framework for layered cache maintenance
- separate out SOC specific outer cache maintenance from
maintenance of caches known to CPU
- Add generic ARMv7 cache maintenance operations that affect all
caches known to ARMv7 CPUs. For instance in Cortex-A8 these
opertions will affect both L1 and L2 caches. In Cortex-A9
these will affect only L1 cache
- D-cache operations supported:
- Invalidate entire D-cache
Needed before enabling the caches.
- Invalidate D-cache range
Needed if you are doing DMA.
- Flush(clean invalidate) entire D-cache
Needed before Linux before disabling the caches.
- Flush D-cache range
Needed in case of DMA out.
How much of this is actually needed in the context of U-Boot?
Please see above. As far as I know OMAP doesn't do DMA in U-Boot.
...
+for (way = num_ways - 1; way= 0 ; way--)
+for (set = num_sets - 1; set= 0; set--) {
+setway = (level 1) | (set log2_line_len) |
+ (way way_shift);
+/* Invalidate data/unified cache line by set/way */
+asm volatile ( mcr p15, 0, %0, c7, c6, 2
+: : r (setway));
+}
Braces needed for multiline for(). Please fix globally.
Ok.
...
+if (operation == ARMV7_DCACHE_INVAL_ALL)
+v7_inval_dcache_level_setway(level, num_sets, num_ways,
+ way_shift, log2_line_len);
+else if (operation == ARMV7_DCACHE_CLEAN_INVAL_ALL)
+v7_clean_inval_dcache_level_setway(level, num_sets, num_ways,
+ way_shift, log2_line_len);
Braces needed for multiline statements. Please fix globally.
+for (mva = start; mva stop; mva = mva + line_len)
+/* DCCIMVAC - Clean Invalidate data cache by MVA to PoC */
+asm volatile (mcr p15, 0, %0, c7, c14, 1 : : r (mva));
And again etc. etc.
...
+void invalidate_dcache_all(void)
+{
+}
+
+void flush_dcache_all(void)
+{
+}
+
+void invalidate_dcache_range(unsigned long start, unsigned long stop)
+{
+}
+
+void flush_dcache_range(unsigned long start, unsigned long stop)
+{
+}
+
+void arm_init_before_mmu(void)
+{
+}
+
+void flush_cache(unsigned long start, unsigned long size)
+{
+}
Please do not add dead code. I consider it misleading to have
functions which promise to perform something, and actually do nothing.
These are empty only in the else part of an #ifdef. When cache support
is compiled out these need to be empty.
best regards,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 02/10] armv7: add miscellaneous utility macros
Dear Aneesh V, In message 4dd23561.70...@ti.com you wrote: In fact I had searched for a macro for similar needs as my set_bit_field() is addressing in Linux Kernel too but didn't find any. ... I couldn't find any utility macros/functions for doing something like this. Please somebody correct me if I am wrong. I am not aware of such a functionality in the Linux kernel, either. A quick search did not even show any attempts to introduce such macros to Linux. It appears they don't need such a feature ? But I may easily be overlooking something. 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 v3 03/10] armv7: cache maintenance operations for armv7
Dear Aneesh V, In message 4dd23d3a.4010...@ti.com you wrote: How much of this is actually needed in the context of U-Boot? Please see above. As far as I know OMAP doesn't do DMA in U-Boot. Devices like USB oth Ethernet don't use DMA for data transfers? Please do not add dead code. I consider it misleading to have functions which promise to perform something, and actually do nothing. These are empty only in the else part of an #ifdef. When cache support is compiled out these need to be empty. When cache support is compiled out there should be no callers to these functions, so maybe they can disappear? 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 No journaling file system can recover your data if the disk dies. - Steve Rago in d4cw1p@plc.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/6] TFTP: rename server to remote
Hi Luca, [...] I removed the checkpatch-related changes: they are now on the tftp cleanup patch series that I submitted on saturday, and on top of which v3 of the TFTP server will be based. Thanks for your persistence - it is very much appreciated! Detlev -- The proprietary-Unix players proved so ponderous, so blind, and so inept at marketing that Microsoft was able to grab away a large part of their market with the shockingly inferior technology of its Windows operating system. -- A Brief History of Hackerdom by Eric Steven Raymond -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 03/10] armv7: cache maintenance operations for armv7
On Tuesday 17 May 2011 03:01 PM, Wolfgang Denk wrote: Dear Aneesh V, In message4dd23d3a.4010...@ti.com you wrote: How much of this is actually needed in the context of U-Boot? Please see above. As far as I know OMAP doesn't do DMA in U-Boot. Devices like USB oth Ethernet don't use DMA for data transfers? Please do not add dead code. I consider it misleading to have functions which promise to perform something, and actually do nothing. These are empty only in the else part of an #ifdef. When cache support is compiled out these need to be empty. When cache support is compiled out there should be no callers to these functions, so maybe they can disappear? No, there may be callers in drivers. It will be ugly to keep all the calls in various drivers under #ifdef, right? Is it not better to have some empty functions and not worrying about the calls in various places. best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/6] TFTP: net/tftp.c: add server mode receive
Hi Luca, [...] Hm, I have to admit that I do not really like adding so many ifdefs into the tftp code and even into the state machine code. Can you give me a number on how much larger u-boot gets on your platform with and without the server support? If this is not too much, maybe we should include support always. If it is too much, maybe we can at least keep the state machine without ifdefs - if I see it correctly, this will only add at maximum a few bytes and STATE_RECW_WRQ will simply never be entered, correct? Here are my measurements for the dig297 board (ARMV7 OMAP3): textdata bss dec hex 3570858684 214264 580033 8d9c1 TFTPSRV on 3563278660 214264 579251 8d6b3 TFTPSRV off, without #ifs 3563558660 214268 579283 8d6d3 TFTPSRV off, with #ifs (as in PATCH v2) The TFTP server adds 730 bytes to the text, so I guess it's worth to keep it optional. Ok, thanks for the number. To my big surprise, removing most bad-looking #ifs (all of those that save just one line) I got a *smaller* U-Boot! I repeated the test three times to be extra sure, the figures are correct: without the #ifs we save a few bytes. Obvious enough, I'm going to remove the #ifs. :) Another instance of the difficulty to predict modern compilers. Cheers Detlev -- But in terms of creative information, information that people can use or enjoy, and that will be used and enjoyed more the more people who have it, always we should encourage the copying. -- Richard M. Stallman -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] MX31: Make get_reset_cause() static
On 05/17/2011 07:10 AM, Jason Liu wrote: Hi, Stefano, Hi Jason, But looking at the code bellow, beside we need make the function static, do we need to remove the break after the return statement? Otherwise, some complier may warn un-reachable code, IMHO. You are right, and the break statement is useless. I have not seen any warnings when I have merged, probably because I still use an older gcc version. I will fix it in the same patch and repost. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 03/10] armv7: cache maintenance operations for armv7
Hi Wolfgang, On Tuesday 17 May 2011 03:01 PM, Wolfgang Denk wrote: Dear Aneesh V, In message4dd23d3a.4010...@ti.com you wrote: How much of this is actually needed in the context of U-Boot? Please see above. As far as I know OMAP doesn't do DMA in U-Boot. Devices like USB oth Ethernet don't use DMA for data transfers? Ethernet support is not upstreamed yet. USB doesn't seem to be using DMA on a quick check. best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 04/10] armv7: replace CONFIG_L2_OFF with CONFIG_SYS_NO_L2CACHE
Hi Wolfgang, On Monday 16 May 2011 12:23 AM, Wolfgang Denk wrote: Dear Aneesh V, In message1305202276-27784-5-git-send-email-ane...@ti.com you wrote: replace all occurences of CONFIG_L2_OFF with a more appropriate CONFIG_SYS_NO_L2CACHE CONFIG_SYS_NO_L2CACHE has been chosen to be in line with CONFIG_SYS_NO_ICACHE and CONFIG_SYS_NO_DCACHE sorry, but these are ugly mis-nomers. The situation is not that there is no cache present (which NO_*CACHE suggestes), but that the cache is (kept) turned off. CONFIG_SYS_L2CACHE_OFF is a _much_ better name than CONFIG_SYS_NO_L2CACHE. Please fix all these names. Ok. Including the existing CONFIG_SYS_NO_DCACHE and CONFIG_SYS_NO_ICACHE too, right? best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 0/5] TFTP server
This patch series adds to U-Boot the ability to receive a file via TFTP acting as a server, instead of a client. I rebased v3 on top of the net/tftp.c cleanup work that I submitted recently (http://lists.denx.de/pipermail/u-boot/2011-May/092599.html) and removed all the cleanups from this patchset. Patches 1 and 2 of v2 have already been committed to master, so the remaining patches shifted back by two. Finally, I incorporated all changes requested on the ml. Description: The implementation is kept simple: - receive only (accept WRQ from remote client, not RRQ); - the Filename in the WRQ is ignored: the destination is always a user-provided memory location; - binary transfers only: the Mode in the WRQ is ignored; this is allowed by RFC1350 (section 5); - no TFTP Option Extensions (RFC2347); - no TFTP multicast. The implementation is discussed here: http://lists.denx.de/pipermail/u-boot/2011-April/090405.html Once it has started, the server is stopped like the client is: on a complete file reception, Ctrl-C and after waiting 5 seconds for 10 times. The first two patches are preliminary cleanups and extensions to the current code. The third patch implements the core TFTP server. The fourth patch adds a user command to launch the server. I also added a trailing patch (#5 in this series), a trivial typo fix requested by Detlev. Luca Luca Ceresoli (5): TFTP: replace server with remote in local variable names TFTP: rename STATE_RRQ to STATE_SEND_RRQ TFTP: net/tftp.c: add server mode receive TFTP: add tftpsrv command net/tftp.c: fix typo README |1 + common/cmd_net.c | 17 + include/net.h|3 +- net/net.c|7 +++- net/tftp.c | 98 + net/tftp.h |6 +++ 6 files changed, 108 insertions(+), 24 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/5] TFTP: replace server with remote in local variable names
With the upcoming TFTP server implementation, the remote node can be
either a client or a server, so avoid ambiguities.
Signed-off-by: Luca Ceresoli luca.ceres...@comelit.it
Cc: Wolfgang Denk w...@denx.de
---
Changes in v2:
- fixed checkpatch issues.
Changes in v3:
- rebased on top of the net/tftp.c cleanup;
- renamed also local variable ServerNet to RemoteNet in TftpStart();
- clarified commit message.
net/tftp.c | 28 ++--
1 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/net/tftp.c b/net/tftp.c
index 0f74e6b..b9d0f3b 100644
--- a/net/tftp.c
+++ b/net/tftp.c
@@ -58,9 +58,9 @@ enum {
TFTP_ERR_FILE_ALREADY_EXISTS = 6,
};
-static IPaddr_t TftpServerIP;
+static IPaddr_t TftpRemoteIP;
/* The UDP port at their end */
-static int TftpServerPort;
+static int TftpRemotePort;
/* The UDP port at our end */
static int TftpOurPort;
static int TftpTimeoutCount;
@@ -289,7 +289,7 @@ TftpSend(void)
break;
}
- NetSendUDPPacket(NetServerEther, TftpServerIP, TftpServerPort,
+ NetSendUDPPacket(NetServerEther, TftpRemoteIP, TftpRemotePort,
TftpOurPort, len);
}
@@ -309,7 +309,7 @@ TftpHandler(uchar *pkt, unsigned dest, IPaddr_t sip,
unsigned src,
#endif
return;
}
- if (TftpState != STATE_RRQ src != TftpServerPort)
+ if (TftpState != STATE_RRQ src != TftpRemotePort)
return;
if (len 2)
@@ -333,7 +333,7 @@ TftpHandler(uchar *pkt, unsigned dest, IPaddr_t sip,
unsigned src,
pkt,
pkt + strlen((char *)pkt) + 1);
TftpState = STATE_OACK;
- TftpServerPort = src;
+ TftpRemotePort = src;
/*
* Check for 'blksize' option.
* Careful: i is signed, len is unsigned, thus
@@ -405,7 +405,7 @@ TftpHandler(uchar *pkt, unsigned dest, IPaddr_t sip,
unsigned src,
if (TftpState == STATE_RRQ || TftpState == STATE_OACK) {
/* first block received */
TftpState = STATE_DATA;
- TftpServerPort = src;
+ TftpRemotePort = src;
TftpLastBlock = 0;
TftpBlockWrap = 0;
TftpBlockWrapOffset = 0;
@@ -440,7 +440,7 @@ TftpHandler(uchar *pkt, unsigned dest, IPaddr_t sip,
unsigned src,
/*
* Acknoledge the block just received, which will prompt
-* the server for the next one.
+* the remote for the next one.
*/
#ifdef CONFIG_MCAST_TFTP
/* if I am the MasterClient, actively calculate what my next
@@ -569,7 +569,7 @@ TftpStart(void)
debug(TFTP blocksize = %i, timeout = %ld ms\n,
TftpBlkSizeOption, TftpTimeoutMSecs);
- TftpServerIP = NetServerIP;
+ TftpRemoteIP = NetServerIP;
if (BootFile[0] == '\0') {
sprintf(default_filename, %02lX%02lX%02lX%02lX.img,
NetOurIP 0xFF,
@@ -589,7 +589,7 @@ TftpStart(void)
strncpy(tftp_filename, BootFile, MAX_LEN);
tftp_filename[MAX_LEN-1] = 0;
} else {
- TftpServerIP = string_to_ip(BootFile);
+ TftpRemoteIP = string_to_ip(BootFile);
strncpy(tftp_filename, p + 1, MAX_LEN);
tftp_filename[MAX_LEN-1] = 0;
}
@@ -599,14 +599,14 @@ TftpStart(void)
printf(Using %s device\n, eth_get_name());
#endif
printf(TFTP from server %pI4
- ; our IP address is %pI4, TftpServerIP, NetOurIP);
+ ; our IP address is %pI4, TftpRemoteIP, NetOurIP);
/* Check if we need to send across this subnet */
if (NetOurGatewayIP NetOurSubnetMask) {
IPaddr_t OurNet = NetOurIP NetOurSubnetMask;
- IPaddr_t ServerNet = TftpServerIP NetOurSubnetMask;
+ IPaddr_t RemoteNet = TftpRemoteIP NetOurSubnetMask;
- if (OurNet != ServerNet)
+ if (OurNet != RemoteNet)
printf(; sending through gateway %pI4,
NetOurGatewayIP);
}
@@ -630,7 +630,7 @@ TftpStart(void)
NetSetTimeout(TftpTimeoutMSecs, TftpTimeout);
NetSetHandler(TftpHandler);
- TftpServerPort = WELL_KNOWN_PORT;
+ TftpRemotePort = WELL_KNOWN_PORT;
TftpTimeoutCount = 0;
TftpState = STATE_RRQ;
/* Use a pseudo-random port unless a specific port is set */
@@ -639,7 +639,7 @@ TftpStart(void)
#ifdef CONFIG_TFTP_PORT
ep = getenv(tftpdstp);
if (ep != NULL)
- TftpServerPort = simple_strtol(ep, NULL, 10);
+ TftpRemotePort =
[U-Boot] [PATCH v3 2/5] TFTP: rename STATE_RRQ to STATE_SEND_RRQ
With the upcoming TFTP server implementation, requests can be either
outgoing or incoming, so avoid ambiguities.
Signed-off-by: Luca Ceresoli luca.ceres...@comelit.it
Cc: Wolfgang Denk w...@denx.de
---
Changes in v2: none.
Changes in v3:
- rebased on top of the net/tftp.c cleanup.
net/tftp.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/net/tftp.c b/net/tftp.c
index b9d0f3b..6386740 100644
--- a/net/tftp.c
+++ b/net/tftp.c
@@ -80,7 +80,7 @@ static intTftpTsize;
static short TftpNumchars;
#endif
-#define STATE_RRQ 1
+#define STATE_SEND_RRQ 1
#define STATE_DATA 2
#define STATE_TOO_LARGE3
#define STATE_BAD_MAGIC4
@@ -215,7 +215,7 @@ TftpSend(void)
switch (TftpState) {
- case STATE_RRQ:
+ case STATE_SEND_RRQ:
xp = pkt;
s = (ushort *)pkt;
*s++ = htons(TFTP_RRQ);
@@ -309,7 +309,7 @@ TftpHandler(uchar *pkt, unsigned dest, IPaddr_t sip,
unsigned src,
#endif
return;
}
- if (TftpState != STATE_RRQ src != TftpRemotePort)
+ if (TftpState != STATE_SEND_RRQ src != TftpRemotePort)
return;
if (len 2)
@@ -399,10 +399,10 @@ TftpHandler(uchar *pkt, unsigned dest, IPaddr_t sip,
unsigned src,
puts(\n\t );
}
- if (TftpState == STATE_RRQ)
+ if (TftpState == STATE_SEND_RRQ)
debug(Server did not acknowledge timeout option!\n);
- if (TftpState == STATE_RRQ || TftpState == STATE_OACK) {
+ if (TftpState == STATE_SEND_RRQ || TftpState == STATE_OACK) {
/* first block received */
TftpState = STATE_DATA;
TftpRemotePort = src;
@@ -632,7 +632,7 @@ TftpStart(void)
TftpRemotePort = WELL_KNOWN_PORT;
TftpTimeoutCount = 0;
- TftpState = STATE_RRQ;
+ TftpState = STATE_SEND_RRQ;
/* Use a pseudo-random port unless a specific port is set */
TftpOurPort = 1024 + (get_timer(0) % 3072);
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 4/5] TFTP: add tftpsrv command
Signed-off-by: Luca Ceresoli luca.ceres...@comelit.it
Cc: Wolfgang Denk w...@denx.de
---
Changes in v2: none.
Changes in v3:
- rebased on top of the net/tftp.c cleanup;
- made do_tftpsrv() static;
- improved tftpsrv command help;
- removed all #ifdefs that used to remove negligible amounts of compiled code,
at the cost of a much less readable source file; after measurements, it
turned out this change does not increase code size.
README |1 +
common/cmd_net.c | 17 +
include/net.h|3 ++-
net/net.c|7 ++-
4 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/README b/README
index 6f3748d..ed73981 100644
--- a/README
+++ b/README
@@ -709,6 +709,7 @@ The following options need to be configured:
(requires CONFIG_CMD_MEMORY)
CONFIG_CMD_SOURCE source command Support
CONFIG_CMD_SPI * SPI serial bus support
+ CONFIG_CMD_TFTPSRV * TFTP transfer in server mode
CONFIG_CMD_USB * USB support
CONFIG_CMD_VFD * VFD support (TRAB)
CONFIG_CMD_CDP * Cisco Discover Protocol support
diff --git a/common/cmd_net.c b/common/cmd_net.c
index 8c6f5c8..b2c9355 100644
--- a/common/cmd_net.c
+++ b/common/cmd_net.c
@@ -52,6 +52,23 @@ U_BOOT_CMD(
[loadAddress] [[hostIPaddr:]bootfilename]
);
+#ifdef CONFIG_CMD_TFTPSRV
+static int do_tftpsrv(cmd_tbl_t *cmdtp, int flag, int argc, char *const argv[])
+{
+ return netboot_common(TFTPSRV, cmdtp, argc, argv);
+}
+
+U_BOOT_CMD(
+ tftpsrv,2, 1, do_tftpsrv,
+ act as a TFTP server and boot the first received file,
+ [loadAddress]\n
+ Listen for an incoming TFTP transfer, receive a file and boot it.\n
+ The transfer is aborted if a transfer has not been started after\n
+ about 50 seconds or if Ctrl-C is pressed.
+);
+#endif
+
+
#ifdef CONFIG_CMD_RARP
int do_rarpb (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
diff --git a/include/net.h b/include/net.h
index 01f7159..018a744 100644
--- a/include/net.h
+++ b/include/net.h
@@ -364,7 +364,8 @@ extern int NetState; /* Network loop
state */
extern int NetRestartWrap; /* Tried all network devices
*/
#endif
-typedef enum { BOOTP, RARP, ARP, TFTP, DHCP, PING, DNS, NFS, CDP, NETCONS,
SNTP } proto_t;
+typedef enum { BOOTP, RARP, ARP, TFTP, DHCP, PING, DNS, NFS, CDP, NETCONS,
SNTP,
+ TFTPSRV } proto_t;
/* from net/net.c */
extern charBootFile[128]; /* Boot File name
*/
diff --git a/net/net.c b/net/net.c
index 2abf879..7a93542 100644
--- a/net/net.c
+++ b/net/net.c
@@ -423,7 +423,11 @@ restart:
/* always use ARP to get server ethernet address */
TftpStart();
break;
-
+#ifdef CONFIG_CMD_TFTPSRV
+ case TFTPSRV:
+ TftpStartServer();
+ break;
+#endif
#if defined(CONFIG_CMD_DHCP)
case DHCP:
BootpTry = 0;
@@ -1791,6 +1795,7 @@ common:
/* Fall through */
case NETCONS:
+ case TFTPSRV:
if (NetOurIP == 0) {
puts(*** ERROR: `ipaddr' not set\n);
return 1;
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 3/5] TFTP: net/tftp.c: add server mode receive
Signed-off-by: Luca Ceresoli luca.ceres...@comelit.it
Cc: Wolfgang Denk w...@denx.de
---
Changes in v2: none.
Changes in v3:
- rebased on top of the net/tftp.c cleanup;
- removed all #ifdefs that used to remove negligible amounts of compiled code,
at the cost of a much less readable source file; after measurements, it
turned out this change does not increase code size.
net/tftp.c | 62 ---
net/tftp.h |6 +
2 files changed, 64 insertions(+), 4 deletions(-)
diff --git a/net/tftp.c b/net/tftp.c
index 6386740..6d44298 100644
--- a/net/tftp.c
+++ b/net/tftp.c
@@ -2,6 +2,8 @@
* Copyright 1994, 1995, 2000 Neil Russell.
* (See License)
* Copyright 2000, 2001 DENX Software Engineering, Wolfgang Denk, w...@denx.de
+ * Copyright 2011 Comelit Group SpA,
+ *Luca Ceresoli luca.ceres...@comelit.it
*/
#include common.h
@@ -85,6 +87,7 @@ static short TftpNumchars;
#define STATE_TOO_LARGE3
#define STATE_BAD_MAGIC4
#define STATE_OACK 5
+#define STATE_RECV_WRQ 6
/* default TFTP block size */
#define TFTP_BLOCK_SIZE512
@@ -257,6 +260,8 @@ TftpSend(void)
(Mapsize*8), 0);
/*..falling..*/
#endif
+
+ case STATE_RECV_WRQ:
case STATE_DATA:
xp = pkt;
s = (ushort *)pkt;
@@ -309,7 +314,8 @@ TftpHandler(uchar *pkt, unsigned dest, IPaddr_t sip,
unsigned src,
#endif
return;
}
- if (TftpState != STATE_SEND_RRQ src != TftpRemotePort)
+ if (TftpState != STATE_SEND_RRQ src != TftpRemotePort
+ TftpState != STATE_RECV_WRQ)
return;
if (len 2)
@@ -322,12 +328,24 @@ TftpHandler(uchar *pkt, unsigned dest, IPaddr_t sip,
unsigned src,
switch (ntohs(proto)) {
case TFTP_RRQ:
- case TFTP_WRQ:
case TFTP_ACK:
break;
default:
break;
+#ifdef CONFIG_CMD_TFTPSRV
+ case TFTP_WRQ:
+ debug(Got WRQ\n);
+ TftpRemoteIP = sip;
+ TftpRemotePort = src;
+ TftpOurPort = 1024 + (get_timer(0) % 3072);
+ TftpLastBlock = 0;
+ TftpBlockWrap = 0;
+ TftpBlockWrapOffset = 0;
+ TftpSend(); /* Send ACK(0) */
+ break;
+#endif
+
case TFTP_OACK:
debug(Got OACK: %s %s\n,
pkt,
@@ -402,7 +420,8 @@ TftpHandler(uchar *pkt, unsigned dest, IPaddr_t sip,
unsigned src,
if (TftpState == STATE_SEND_RRQ)
debug(Server did not acknowledge timeout option!\n);
- if (TftpState == STATE_SEND_RRQ || TftpState == STATE_OACK) {
+ if (TftpState == STATE_SEND_RRQ || TftpState == STATE_OACK ||
+ TftpState == STATE_RECV_WRQ) {
/* first block received */
TftpState = STATE_DATA;
TftpRemotePort = src;
@@ -537,7 +556,8 @@ TftpTimeout(void)
} else {
puts(T );
NetSetTimeout(TftpTimeoutMSecs, TftpTimeout);
- TftpSend();
+ if (TftpState != STATE_RECV_WRQ)
+ TftpSend();
}
}
@@ -661,6 +681,40 @@ TftpStart(void)
TftpSend();
}
+#ifdef CONFIG_CMD_TFTPSRV
+void
+TftpStartServer(void)
+{
+ tftp_filename[0] = 0;
+
+#if defined(CONFIG_NET_MULTI)
+ printf(Using %s device\n, eth_get_name());
+#endif
+ printf(Listening for TFTP transfer on %pI4\n, NetOurIP);
+ printf(Load address: 0x%lx\n, load_addr);
+
+ puts(Loading: *\b);
+
+ TftpTimeoutCountMax = TIMEOUT_COUNT;
+ TftpTimeoutCount = 0;
+ TftpTimeoutMSecs = TIMEOUT;
+ NetSetTimeout(TftpTimeoutMSecs, TftpTimeout);
+
+ /* Revert TftpBlkSize to dflt */
+ TftpBlkSize = TFTP_BLOCK_SIZE;
+ TftpBlock = 0;
+ TftpOurPort = WELL_KNOWN_PORT;
+
+#ifdef CONFIG_TFTP_TSIZE
+ TftpTsize = 0;
+ TftpNumchars = 0;
+#endif
+
+ TftpState = STATE_RECV_WRQ;
+ NetSetHandler(TftpHandler);
+}
+#endif /* CONFIG_CMD_TFTPSRV */
+
#ifdef CONFIG_MCAST_TFTP
/* Credits: atftp project.
*/
diff --git a/net/tftp.h b/net/tftp.h
index e3dfb26..3abdf7b 100644
--- a/net/tftp.h
+++ b/net/tftp.h
@@ -2,6 +2,8 @@
* LiMon - BOOTP/TFTP.
*
* Copyright 1994, 1995, 2000 Neil Russell.
+ * Copyright 2011 Comelit Group SpA
+ *Luca Ceresoli luca.ceres...@comelit.it
* (See License)
*/
@@ -16,6 +18,10 @@
/* tftp.c */
extern voidTftpStart (void); /* Begin TFTP get */
+#ifdef CONFIG_CMD_TFTPSRV
+extern voidTftpStartServer(void); /* Wait for incoming TFTP put */
+#endif
+
/**/
#endif /* __TFTP_H__ */
--
1.7.1
[U-Boot] [PATCH v3 5/5] net/tftp.c: fix typo
Signed-off-by: Luca Ceresoli luca.ceres...@comelit.it Cc: Wolfgang Denk w...@denx.de --- Changes in v3: this patch is new in v3. net/tftp.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net/tftp.c b/net/tftp.c index 6d44298..a893e02 100644 --- a/net/tftp.c +++ b/net/tftp.c @@ -458,7 +458,7 @@ TftpHandler(uchar *pkt, unsigned dest, IPaddr_t sip, unsigned src, store_block(TftpBlock - 1, pkt + 2, len); /* -* Acknoledge the block just received, which will prompt +* Acknowledge the block just received, which will prompt * the remote for the next one. */ #ifdef CONFIG_MCAST_TFTP -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] New popular hot sale Android phone for wholesalers from DHHT Ecommerce
Hi, good day! With the buzz of Android, Android phone come to be so popular. A professional Android phone manufacturer here introduce you some quite hot now: A2000 Quad Band Smart Phone Android 2.2 OS Support GPS WIFI Analog TV 4.3 Inch Touch Screen 146usd Mozart V9 Android 2.2 Dual Sim Card 3.5 Inch Capacitive Screen A-GPS WIFI Cell Phone Coffee 163usd FG8 Quad Band Smart Phone Android 2.2 OS Support GPS WIFI Analog TV 3.6 Inch Mulit-Touch Screen 109usd Kindest regards, Pam Pan Shenzhen Danhonghaotian Ecommerce Co., Ltd. Fl.4-5,7 Longtang Industry Park, Liuyue, Henggang, Longgang, Shenzhen 518000, China. Email msn: dreamcastle2...@gmail.com Tel : 0086-755-83650148 Fax: 0086-755-28319286 Forward this email ( http://a.rs-tk.com/8707-67757/pandawill.newsletter/New_popular_hot_sale_Android_phone_for_wholesalers_from_DHHT_Ecommerce/forward.aspx ) Update Email Profile ( http://s.rs-tk.com/SubscribeFormDetail.aspx?ens=rNAzck5babS4dzSEt8q06g==type=profile ) Unsubscribe ( http://s.rs-tk.com/Unsubscribe.aspx?sub=45178362user=8707campid=67757type=h ) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 05/10] armv7: integrate cache maintenance support
Hi Wolfgang, On Monday 16 May 2011 12:25 AM, Wolfgang Denk wrote: Dear Aneesh V, In message1305202276-27784-6-git-send-email-ane...@ti.com you wrote: - Enable I-cache on bootup - Enable MMU and D-cache immediately after relocation - Do necessary initialization before enabling d-cache and MMU Would it be possible to do this even _before_ relocation, so to speed up memory accesses during relocation? Of course, proper invalidates/ flushes will be needed before jumping to the RAM address, but I guess this would save a bit of boot times? I intentionally kept it after relocation to avoid un-necessary complexities. Relocation is a case of self-modifying code. In Harvard architectures like armv7 there will be coherency issues unless we flush the entire D-cache(range based operation may be equally or more expensive) and invalidate the entire I-cache. So, in effect everything has to be flushed to memory before you jump to the new location. There may be a small advantage because flushing from cache allows for bursting to the DDR where as bursting is not possible when d-cache is disabled. But I think this is not worth the trouble. best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/22] mkimage: Add OMAP boot image support
Hi Wolfgang,
On Monday 16 May 2011 05:18 PM, Wolfgang Denk wrote:
Dear Aneesh V,
...
+struct ch_toc {
+ uint32_t section_offset;
+ uint32_t section_size;
+ uint8_t unused[12];
+ uint8_t section_name[12];
+} __attribute__ ((__packed__));
+
+struct ch_settings {
+ uint32_t section_key;
+ uint8_t valid;
+ uint8_t version;
+ uint16_t reserved;
+ uint32_t flags;
+} __attribute__ ((__packed__));
+
+struct gp_header {
+ uint32_t size;
+ uint32_t load_addr;
+} __attribute__ ((__packed__));
Is there any good reason to have these __attribute__ ((__packed__))
here? In general, these are only known to cause trouble and pain, and
I cannot see a need here.
ROM code expects the header in a precise format. I think it will not be
safe to leave it to the compiler to decide the field layout. For
instance, the compiler may align the uint8_t or uint16_t to 32 bit
boundary and that will break the Configuration Header.
No. Not in the structs listed above.
You mean __packed__ should be removed from struct gp_header alone,
not from the other structs?
best regards,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/22] Add generic spl infrastructure
Hi Aneesh, On Tuesday 17 May 2011 01:45 PM, Wolfgang Denk wrote: Dear Aneesh V, In message4dd21baa.6000...@ti.com you wrote: What is MLO? MLO is the name of SPL created for OMAP. ROM code expects a file with this name as the first image when it boots from FAT. What does MLO mean? On looking up ROM code spec, this seems to stand for MMC/SD Loader +#ifdef CONFIG_PRELOADER +/* SPL works from internal RAM. gd pointer can be in .data section */ +#define DECLARE_GLOBAL_DATA_PTR extern gd_t *gd +#else #define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm (r8) +#endif Is this appropriate for all ARM boards (e.g. those currently using nand_spl)? None of the SPL's other than this one seems to be using global data today. If anybody wants to use it this seems to be the logical option for me because by definition SPL runs from some kind of RAM so global data can be placed in the .data section of SPL. But that's not what you are doing. You are not changing the storage of the global data itself, you are changing the storage of the POINTER TO the global data - and this makes no sense to me. The pointer can certainly remain in a register even if the data itself is somewhere else. Why do we want to waste a register in the entire SPL when global data can be accessed directly from .data section? best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 04/10] armv7: replace CONFIG_L2_OFF with CONFIG_SYS_NO_L2CACHE
Dear Aneesh V, In message 4dd24715.4010...@ti.com you wrote: Please fix all these names. Ok. Including the existing CONFIG_SYS_NO_DCACHE and CONFIG_SYS_NO_ICACHE too, right? yes, please. Thanks a lot! Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A child is a person who can't understand why someone would give away a perfectly good kitten. - Doug Larson ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] Pull request u-boot-atmel.git next
Hi Rienhard, Le 16/05/2011 21:30, Reinhard Meyer a écrit : Dear Albert, Hi Reinhard, Le 13/05/2011 10:46, Reinhard Meyer a écrit : Dear Albert, The following changes since commit 2e73808ee97d75400881d1fe144b062f427cfcb9: Clint Adams (1): Enable multiple fs options for Marvell SoC family on OpenRD boards are available in the git repository at: git://git.denx.de/u-boot-atmel.git next Do you mean for me to pull this into my master branch? If so, I would prefer that you rebase your master branch on next and send a pull request for your master. I don't understand the issue here: arm:master = arm:next = atmel:master are identical already. atmel:next is all that has been added since that. Should be simple to pull that onto arm:master? Yes, it is even trivial; but I expect pull request to be from 'master' branches, which contain patches accepted by the custodian for the upcoming version, not from 'next' branches, which are a waiting queue for patches that will only go into the next merge window -- as per http://www.denx.de/wiki/view/U-Boot/CustodianGitTrees#Tips_for_maintaining_custodian_t Best Regards, Reinhard Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 05/10] armv7: integrate cache maintenance support
Dear Aneesh V, In message 4dd24bd6.5060...@ti.com you wrote: Would it be possible to do this even _before_ relocation, so to speed up memory accesses during relocation? Of course, proper invalidates/ flushes will be needed before jumping to the RAM address, but I guess this would save a bit of boot times? I intentionally kept it after relocation to avoid un-necessary complexities. Yes, I can understand this. Do you plean to extend this to include relocation n a later step? Relocation is a case of self-modifying code. In Harvard architectures like armv7 there will be coherency issues unless we flush the entire D-cache(range based operation may be equally or more expensive) and invalidate the entire I-cache. I would not call this self-modifying code. Regarding the need to flush/invalidate caches when jumping to RAM: yes, we have to flush the D-cache to make sure all data actually has hit the memory. But there should be no need to invalidate the I-cache as we have never been fetching any instructions from this address range, so there cannot be any incorrect entries in cache. Or am I missing something? So, in effect everything has to be flushed to memory before you jump to the new location. There may be a small advantage because flushing from cache allows for bursting to the DDR where as bursting is not possible when d-cache is disabled. But I think this is not worth the trouble. Well, all the data copy will also use cached writes, which are much faster. I think this will result in measurable time differences. 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 most exciting phrase to hear in science, the one that heralds new discoveries, is not Eureka! (I found it!) but That's funny ... -- Isaac Asimov ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/22] mkimage: Add OMAP boot image support
Dear Aneesh V, In message 4dd24cc2.9040...@ti.com you wrote: You mean __packed__ should be removed from struct gp_header alone, not from the other structs? From all of them. 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 An Elephant is a mouse with an Operating System. - Knuth ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V7 1/3] MX5: clock: Add clock config interface
On 05/17/2011 08:25 AM, Jason Liu wrote:
Hi, Stefano,
Hi Jason,
I use array here just for the case we will have another element in the array
(currently we only have one) in the future. Currently, we use 24MHz as ref.
Understood, thanks.
/*
+ * Clock config code start here
+ */
+
+/* precondition: m0 and n0. Let g=gcd(m,n). */
+static int gcd(int m, int n)
+{
+ int t;
+ while (m 0) {
+ if (n m) {
+ t = m;
+ m = n;
+ n = t;
+ } /* swap */
+ m -= n;
+ }
+ return n;
+}
This function has nothing to do with MX5 code. This is a general
function, and should be add to lib/. I think you have to remove it from
here and put it in a separate patch.
I don't think it should be put to lib since only the mx5 clock code use it
here.
This function computes the GCD of two numbers, and has nothing to do
with MX5 and clock. It is a general function, that others can use.
OK, I will check linux implementation. Do you know does u-boot also has such
kind of function already, I did not find it?
No, this function is not yet implemented in u-boot. However, it could be
that there is in some drivers an analog function doing the same. For
this reason and to avoid multiple instances of quite same code doing
quite the same thing, I suggest to move this function from here from
strictly related IMX code to a general lib. Let's see what Wolfgang
whinks about it.
+ * t_clk = 2*ref_freq*(mfi + mfn/(mfd+1))/(pd+1)
Where does this formula come from ?
The comments is not correct, I will fix it, it should be 4*ref_freq
not 2 * ref_req.
The reference manual: 12.2.2.3 DPLL Operation Register, elvis user guide,
Registers DP_OP, DP_MFN, and DP_MFD calculate the output frequency by
the formula:
The chapter number will not the same as you, but you still can find it
in the reference manual.
Ok. I think it is better to add a comment with the chapter title, as to
set a reference number, because this is changing.
I will check in the manual, thanks for hint.
Use defines to set registers. Or read-modify-write, as you changed only
PERIPH_APM_SEL from the reset value. However, you reset to 0
DDR_CLK_SEL. I see you switch values back at the end of the function,
but my doubt is if it is correct to set in this transition DDR_CLK_SEL
always to zero. Can it work with all boards or there are configurations
where it does not work ?
I think it should work since DDR_CLK_SEL:00 derive clock from axi a
is the default value when boot up.
Then I think it is enough you add as comment your explanation, and
mention that the code does not support if the clock is not derived from
axi-a. If someone adds a custom board with this set-up (and I do not
know if it will be a use case), he is at least warned that must adapt
this function.
+ *
+ * @param ref pll input reference clock (24MHz)
Reference clock is defined as CONFIG_SYS_MX5_HCLK. Is it really possible
to pass a parameter to this function different as CONFIG_SYS_MX5_HCLK ?
What happens if CONFIG_SYS_MX5_HCLK and the ref parameter in this
function have two different values ? It seems to me this is not a use
case, and then we must avoid it. If I am right, you should drop the ref
parameter and use CONFIG_SYS_MX5_HCLK.
As the reference manual tell, the pll can have 4 different clock
source. The most
common use case is using 24Mhz OSC as the input.
Understood, thanks.
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/22] Add generic spl infrastructure
Dear Aneesh V, In message 4dd24e63.3020...@ti.com you wrote: But that's not what you are doing. You are not changing the storage of the global data itself, you are changing the storage of the POINTER TO the global data - and this makes no sense to me. The pointer can certainly remain in a register even if the data itself is somewhere else. Why do we want to waste a register in the entire SPL when global data can be accessed directly from .data section? Because the resulting code is smaller? I did not measure it on your hardware with your compiler, but IIRC this was the result on some other processors. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It may be that your whole purpose in life is simply to serve as a warning to others. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] MX31: Make get_reset_cause() static and drop unreachable code
get_reset_cause() should not be exported. Drop code in the function
after return statement that can generate warnings due to unreachable code.
Signed-off-by: Stefano Babic sba...@denx.de
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
arch/arm/cpu/arm1136/mx31/generic.c |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/arch/arm/cpu/arm1136/mx31/generic.c
b/arch/arm/cpu/arm1136/mx31/generic.c
index fccd2cd..4ebf38d 100644
--- a/arch/arm/cpu/arm1136/mx31/generic.c
+++ b/arch/arm/cpu/arm1136/mx31/generic.c
@@ -133,7 +133,7 @@ u32 get_cpu_rev(void)
return srev | 0x8000;
}
-char *get_reset_cause(void)
+static char *get_reset_cause(void)
{
/* read RCSR register from CCM module */
struct clock_control_regs *ccm =
@@ -144,16 +144,12 @@ char *get_reset_cause(void)
switch (cause) {
case 0x:
return POR;
- break;
case 0x0001:
return RST;
- break;
case 0x0002:
return WDOG;
- break;
case 0x0006:
return JTAG;
- break;
default:
return unknown reset;
}
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 05/10] armv7: integrate cache maintenance support
Hi Wolfgang, On Tuesday 17 May 2011 04:44 PM, Wolfgang Denk wrote: Dear Aneesh V, In message4dd24bd6.5060...@ti.com you wrote: Would it be possible to do this even _before_ relocation, so to speed up memory accesses during relocation? Of course, proper invalidates/ flushes will be needed before jumping to the RAM address, but I guess this would save a bit of boot times? I intentionally kept it after relocation to avoid un-necessary complexities. Yes, I can understand this. Do you plean to extend this to include relocation n a later step? Relocation is a case of self-modifying code. In Harvard architectures like armv7 there will be coherency issues unless we flush the entire D-cache(range based operation may be equally or more expensive) and invalidate the entire I-cache. I would not call this self-modifying code. In ARM literature this kind of situations are also referred to as self- modifying. Here is an excerpt from ARM manual gloassary: Self-modifying code Is code that writes one or more instructions to memory and then executes them. Regarding the need to flush/invalidate caches when jumping to RAM: yes, we have to flush the D-cache to make sure all data actually has hit the memory. But there should be no need to invalidate the I-cache as we have never been fetching any instructions from this address range, so there cannot be any incorrect entries in cache. Or am I missing something? This should be largely ok, but not fool-proof for all processors. For processors such as Cortex-A9 that have speculative and out-of-order execution there is no guarantee that any given memory location is not cached at any given point of time as long as the cache is enabled. Here is an excerpt from the ARMv7 manual(section B2.2.2): If a memory location is marked as Cacheable there is no mechanism by which it can be guaranteed not to be allocated to an enabled cache at any time. Any application must assume that any Cacheable memory location can be allocated to any enabled cache at any time. So, in effect everything has to be flushed to memory before you jump to the new location. There may be a small advantage because flushing from cache allows for bursting to the DDR where as bursting is not possible when d-cache is disabled. But I think this is not worth the trouble. Well, all the data copy will also use cached writes, which are much You mean, you will do a range-flush on only the .text section's area? faster. I think this will result in measurable time differences. Relocation itself was not taking a huge amount of time in my measurement sometime back. It was about 16 ms for OMAP4. best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/22] mkimage: Add OMAP boot image support
Hi Wolfgang,
On Monday 16 May 2011 05:18 PM, Wolfgang Denk wrote:
Dear Aneesh V,
In message4dd0f98a.2040...@ti.com you wrote:
@@ -141,6 +141,7 @@ static const table_entry_t uimage_type[] = {
{ IH_TYPE_FLATDT, flat_dt,Flat Device Tree,
},
{ IH_TYPE_KWBIMAGE, kwbimage, Kirkwood Boot
Image,},
{ IH_TYPE_IMXIMAGE, imximage, Freescale i.MX Boot
Image,},
+ { IH_TYPE_OMAPIMAGE, omapimage, TI OMAP CH/GP Boot Image,},
{ -1, , ,
},
Please keep list sorted / sort list.
Sort by the second field(kwbimage, omapimage etc), right?
First field, but the result is the same.
+struct ch_toc {
+ uint32_t section_offset;
+ uint32_t section_size;
+ uint8_t unused[12];
+ uint8_t section_name[12];
+} __attribute__ ((__packed__));
+
+struct ch_settings {
+ uint32_t section_key;
+ uint8_t valid;
+ uint8_t version;
+ uint16_t reserved;
+ uint32_t flags;
+} __attribute__ ((__packed__));
+
+struct gp_header {
+ uint32_t size;
+ uint32_t load_addr;
+} __attribute__ ((__packed__));
Is there any good reason to have these __attribute__ ((__packed__))
here? In general, these are only known to cause trouble and pain, and
I cannot see a need here.
ROM code expects the header in a precise format. I think it will not be
safe to leave it to the compiler to decide the field layout. For
instance, the compiler may align the uint8_t or uint16_t to 32 bit
boundary and that will break the Configuration Header.
No. Not in the structs listed above.
Why do you think it will not create any problems. For instance, what if
the field uint8_t version in struct ch_settings is aligned to a 32
bit boundary by the compiler for faster access? That is not the
intended layout.
best regards,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/22] Add generic spl infrastructure
Hi Wolfgang, On Tuesday 17 May 2011 04:47 PM, Wolfgang Denk wrote: Dear Aneesh V, In message4dd24e63.3020...@ti.com you wrote: But that's not what you are doing. You are not changing the storage of the global data itself, you are changing the storage of the POINTER TO the global data - and this makes no sense to me. The pointer can certainly remain in a register even if the data itself is somewhere else. Why do we want to waste a register in the entire SPL when global data can be accessed directly from .data section? Because the resulting code is smaller? I was thinking that it may be faster. More number of registers at disposal may mean less number of pushes to the stack, right? I am not sure if this will make a significant difference. best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 05/10] armv7: integrate cache maintenance support
Dear Aneesh V, In message 4dd264b7.9060...@ti.com you wrote: In ARM literature this kind of situations are also referred to as self- modifying. Here is an excerpt from ARM manual gloassary: I see. Thanks. Well, all the data copy will also use cached writes, which are much You mean, you will do a range-flush on only the .text section's area? That should indeed be sufficient. faster. I think this will result in measurable time differences. Relocation itself was not taking a huge amount of time in my measurement sometime back. It was about 16 ms for OMAP4. I was especially talking about the loading from external storage, not primarily relocation. This will even be mnore important if we had (much) bigger images - like when loading an OS kernel as second stage payload instead of U-Boot. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I see that Microsoft's campaign to destroy all knowledge of any operating environment but its own environment-of-the-year has succeeded in creating a generation of users who don't understand the concept of a shell... -- L. Peter Deutsch in m0x5jnx-000r...@lamp.aladdin.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/22] mkimage: Add OMAP boot image support
Dear Aneesh V,
In message 4dd2657f.3020...@ti.com you wrote:
+struct ch_toc {
+uint32_t section_offset;
+uint32_t section_size;
+uint8_t unused[12];
+uint8_t section_name[12];
+} __attribute__ ((__packed__));
+
+struct ch_settings {
+uint32_t section_key;
+uint8_t valid;
+uint8_t version;
+uint16_t reserved;
+uint32_t flags;
+} __attribute__ ((__packed__));
+
+struct gp_header {
+uint32_t size;
+uint32_t load_addr;
+} __attribute__ ((__packed__));
...
No. Not in the structs listed above.
Why do you think it will not create any problems. For instance, what if
the field uint8_t version in struct ch_settings is aligned to a 32
bit boundary by the compiler for faster access? That is not the
intended layout.
If the compiler did such a thing, this would indeed be bad. But I
have never seen a compiler doing this, nor is there a reason to do so.
The naturla alignment requirement for a uint8_t is a byte; ther eis no
need to align it on 4 byte boundary.
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
Man is the best computer we can put aboard a spacecraft ... and the
only one that can be mass produced with unskilled labor.
- Wernher von Braun
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/22] Add generic spl infrastructure
Dear Aneesh V, In message 4dd26719.5090...@ti.com you wrote: I was thinking that it may be faster. More number of registers at disposal may mean less number of pushes to the stack, right? I am not sure if this will make a significant difference. It does not make a significant difference. Which is the reason I vote for avoiding the #ifdef. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Never put off until tomorrow what you can put off indefinitely. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 09/22] omap4: add spl support for OMAP4 SDP
Hi Wolfgang, On Tuesday 17 May 2011 01:49 PM, Wolfgang Denk wrote: Dear Aneesh V, In message4dd21fb9.6070...@ti.com you wrote: The top-level make rule being the following, we will need a Makefile in the board directory, right? +SPL:$(TIMESTAMP_FILE) $(VERSION_FILE) depend tools +$(MAKE) -C spl/board/$(BOARDDIR) all Maybe this needs to be tweaked to allow for boards that don;t require board specific code. And how do you distinguish between the two cases at the top level Makefile? Using a CONFIG flag or on a per platform basis? Why not just invoke the board level Makefile from the top-level Makefile and let it decide about the code-reuse by doing something like I did? In fact, code is already common. All OMAP code specific to SPL comes from spl/board/ti/spl-omap.c . All OMAP code shared with OMAP U-Boot comes from the respective directory within arch/arm/cpu/armv7/* In the interest of simplicity I deferred all board specific initialization of OMAP4(mainly mux) to U-Boot. So, SPL is board independent today for OMAP4. Then we should adapt the directory and Makefile structure and allow for such common code without need for separate spl/board/ directories. Do you have any specific proposals? I have a feeling that this may get un-necessarily complicated. Best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] arm: omap: innovator: fix compilation error
Sandeep, Any comments? On 05/01/11 13:10, Igor Grinberg wrote: CONFIG_SYS_SDRAM_BASE and CONFIG_SYS_INIT_SP_ADDR were not defined for this board thus breaking its build. Signed-off-by: Igor Grinberg grinb...@compulab.co.il Cc: Sandeep Paulraj s-paul...@ti.com Cc: Nishant Kamat nska...@ti.com Cc: Kshitij Gupta kshi...@ti.com --- include/configs/omap1610h2.h |7 +++ include/configs/omap1610inn.h |7 +++ 2 files changed, 14 insertions(+), 0 deletions(-) diff --git a/include/configs/omap1610h2.h b/include/configs/omap1610h2.h index 2936dcc..7e53ae6 100644 --- a/include/configs/omap1610h2.h +++ b/include/configs/omap1610h2.h @@ -152,6 +152,13 @@ #define PHYS_SDRAM_1 0x1000 /* SDRAM Bank #1 */ #define PHYS_SDRAM_1_SIZE0x0200 /* 32 MB */ +#define CONFIG_SYS_SDRAM_BASEPHYS_SDRAM_1 +#define CONFIG_SYS_INIT_RAM_SIZE 0x1000 +/* FIXME: the value below is taken from davinci which uses ARM926EJS cpu */ +#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE +\ + CONFIG_SYS_INIT_RAM_SIZE - \ + GENERATED_GBL_DATA_SIZE) + #define PHYS_FLASH_1_BM1 0x /* Flash Bank #1 if booting from flash */ #define PHYS_FLASH_1_BM0 0x0C00 /* Flash Bank #1 if booting from RAM */ diff --git a/include/configs/omap1610inn.h b/include/configs/omap1610inn.h index 0b41c46..be569a3 100644 --- a/include/configs/omap1610inn.h +++ b/include/configs/omap1610inn.h @@ -157,6 +157,13 @@ #define PHYS_SDRAM_1 0x1000 /* SDRAM Bank #1 */ #define PHYS_SDRAM_1_SIZE0x0200 /* 32 MB */ +#define CONFIG_SYS_SDRAM_BASEPHYS_SDRAM_1 +#define CONFIG_SYS_INIT_RAM_SIZE 0x1000 +/* FIXME: the value below is taken from davinci which uses ARM926EJS cpu */ +#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE +\ + CONFIG_SYS_INIT_RAM_SIZE - \ + GENERATED_GBL_DATA_SIZE) + #define PHYS_FLASH_1_BM1 0x /* Flash Bank #1 if booting from flash */ #define PHYS_FLASH_1_BM0 0x0C00 /* Flash Bank #1 if booting from RAM */ -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] MX5: Make the weim structure complete
On 05/17/2011 12:29 AM, Fabio Estevam wrote:
Make the weim register set complete for MX51/MX53.
While at it also add the weim chip select 1 address definition.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Changes since v1:
- Make the weim struct complete
arch/arm/include/asm/arch-mx5/imx-regs.h | 46
++
1 files changed, 40 insertions(+), 6 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx5/imx-regs.h
b/arch/arm/include/asm/arch-mx5/imx-regs.h
index a1849f8..d80e0c0 100644
--- a/arch/arm/include/asm/arch-mx5/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx5/imx-regs.h
@@ -41,6 +41,7 @@
#define CSD1_BASE_ADDR 0xB000
#define NFC_BASE_ADDR_AXI 0xF7FF
#define IRAM_BASE_ADDR 0xF800
+#define CS1_BASE_ADDR 0xF400
#else
#error CPU_TYPE not defined
#endif
@@ -231,12 +232,45 @@ struct clkctl {
/* WEIM registers */
struct weim {
- u32 csgcr1;
- u32 csgcr2;
- u32 csrcr1;
- u32 csrcr2;
- u32 cswcr1;
- u32 cswcr2;
+ u32 cs0gcr1;
The patch breaks the vision2 board. However, you set the names now
exactly how we can find in the reference manual, and this is better and
generates less confusion. Do not worry about the vision2, I will fix it
when your patch will be merged and before my pull.
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v9] Add support for Network Space v2 and parents
This patch add support for the Network Space v2 board and parents, based
on the Marvell Kirkwood 6281 SoC. This include Network Space (Max) v2
and Internet Space v2.
Additional information is available at:
http://lacie-nas.org/doku.php?id=network_space_v2
Signed-off-by: Simon Guinot sgui...@lacie.com
---
Changes for v2:
- add entries to MAINTAINERS file
- move boards from root Makefile to boards.cfg
- move MACH_TYPE definition into netspace_v2.h
- remove CONFIG_SYS_HZ redefinition
- turn PHY initialization message into debug()
Changes for v3: none
Changes for v4:
- enhance commit message: add SoC information
Changes for v5: none
Changes for v6:
- enable device tree support
- clean some #define in netspace_v2.h
- enhance commit message: provide description URL and mention SoC
family
- rebase against u-boot-{arm,marvell}/master branches
Changes for v7:
- rebase against u-boot-marvell/master branch
Changes for v8:
- update commit title (add netspace_v2 parents information).
- move GPIO button definition into header file.
- update CONFIG_IDENT_STRING with boards alias.
- handle wrong board definition.
- by default, use DHCP to get IP address.
Changes for v9:
- rebase against u-boot-marvell/master branch
MAINTAINERS |6 +
board/LaCie/netspace_v2/Makefile | 49 ++
board/LaCie/netspace_v2/kwbimage.cfg | 162 +
board/LaCie/netspace_v2/netspace_v2.c | 142 +
board/LaCie/netspace_v2/netspace_v2.h | 42 +
boards.cfg|3 +
include/configs/netspace_v2.h | 162 +
7 files changed, 566 insertions(+), 0 deletions(-)
create mode 100644 board/LaCie/netspace_v2/Makefile
create mode 100644 board/LaCie/netspace_v2/kwbimage.cfg
create mode 100644 board/LaCie/netspace_v2/netspace_v2.c
create mode 100644 board/LaCie/netspace_v2/netspace_v2.h
create mode 100644 include/configs/netspace_v2.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 24a55c2..47b724c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -645,6 +645,12 @@ Sedji Gaouaousedji.gaou...@atmel.com
at91sam9g10ek ARM926EJS (AT91SAM9G10 SoC)
at91sam9m10g45ekARM926EJS (AT91SAM9G45 SoC)
+Simon Guinot simon.gui...@sequanux.org
+
+ inetspace_v2ARM926EJS (Kirkwood SoC)
+ netspace_v2 ARM926EJS (Kirkwood SoC)
+ netspace_max_v2 ARM926EJS (Kirkwood SoC)
+
Marius Gr�ger m...@sysgo.de
impa7 ARM720T (EP7211)
diff --git a/board/LaCie/netspace_v2/Makefile b/board/LaCie/netspace_v2/Makefile
new file mode 100644
index 000..a245f2c
--- /dev/null
+++ b/board/LaCie/netspace_v2/Makefile
@@ -0,0 +1,49 @@
+#
+# Copyright (C) 2011 Simon Guinot sgui...@lacie.com
+#
+# Based on Kirkwood support:
+# (C) Copyright 2009
+# Marvell Semiconductor www.marvell.com
+# Written-by: Prafulla Wadaskar prafu...@marvell.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.
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS := netspace_v2.o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+SOBJS := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+ $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+clean:
+ rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+ rm -f $(LIB) core *.bak .depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/LaCie/netspace_v2/kwbimage.cfg
b/board/LaCie/netspace_v2/kwbimage.cfg
new file mode 100644
index 000..361feeb
--- /dev/null
+++ b/board/LaCie/netspace_v2/kwbimage.cfg
@@ -0,0 +1,162 @@
+#
+# Copyright (C) 2011 Simon Guinot sgui...@lacie.com
+#
+# Based on Kirkwood support:
+# (C) Copyright 2009
+# Marvell Semiconductor www.marvell.com
+# Written-by: Prafulla Wadaskar prafu...@marvell.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
Re: [U-Boot] [PATCH v2 1/3] MX5: Make the weim structure complete
On 05/17/2011 07:06 AM, Jason Liu wrote: Hi, Fabio, 2011/5/17 Fabio Estevam fabio.este...@freescale.com: Make the weim register set complete for MX51/MX53. While at it also add the weim chip select 1 address definition. From the code, you just add the cs for mx53 not for mx51, so, Had better specify you add the cs1 address definition for mx53, otherwise, it will make confusion. Sure ? The structure is not protected by any CONFIG_MX5x switch, and at least one mx51 board uses it. The registers have the same layout for both processor. Why do you think is only for MX53 ? Regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 09/22] omap4: add spl support for OMAP4 SDP
Dear Aneesh V, In message 4dd26b36.4050...@ti.com you wrote: And how do you distinguish between the two cases at the top level Makefile? Using a CONFIG flag or on a per platform basis? The decision should not be make in the top level makefile, but in spl/Makefile. And this can simply check if a board directory exists in the first place. Why not just invoke the board level Makefile from the top-level Makefile and let it decide about the code-reuse by doing something like I did? Because then we need board specific directories and board specific Makefiles even for those boards where no board specific code exists, and all these Makefiles will be semi-identical copies of each other. Then we should adapt the directory and Makefile structure and allow for such common code without need for separate spl/board/ directories. Do you have any specific proposals? I have a feeling that this may get un-necessarily complicated. Having to maintain multiple copies of identical Makefiles is more complicated and error prone in the long run. Let's rather spoend a few thoughts initially and solve this problem before it spreads. 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 ain't so much the things we don't know that get us in trouble. It's the things we know that ain't so. - Artemus Ward aka Charles Farrar Brown ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] MX5: Add iomux structure
On 05/17/2011 12:29 AM, Fabio Estevam wrote:
Hi Fabio,
+struct iomuxc {
+ u32 gpr0;
+ u32 gpr1;
+ u32 gpr2;
+ u32 omux0;
+ u32 omux1;
+ u32 omux2;
+ u32 omux3;
+ u32 omux4;
+};
It seems to me that the MX51 and the MX53 have a different layout, and
we cannot define the structure in this way. The MX51 have only two
General Purpose registers, and the address of IOMUX_OBSERVE_MUX_0
overlaps gpr2 on the MX53.
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] MX5: Make the weim structure complete
Hi Stefano, On 5/17/2011 9:44 AM, Stefano Babic wrote: On 05/17/2011 07:06 AM, Jason Liu wrote: Hi, Fabio, 2011/5/17 Fabio Estevam fabio.este...@freescale.com: Make the weim register set complete for MX51/MX53. While at it also add the weim chip select 1 address definition. From the code, you just add the cs for mx53 not for mx51, so, Had better specify you add the cs1 address definition for mx53, otherwise, it will make confusion. Sure ? The structure is not protected by any CONFIG_MX5x switch, and at least one mx51 board uses it. The registers have the same layout for both processor. Why do you think is only for MX53 ? I think what Jason mentions is the fact that I added: #define CS1_BASE_ADDR 0xF400 and this was only for MX53 because it is protected by elif defined(CONFIG_MX53) I can add the CS1_BASE_ADDR for MX51 as well on my v3 series. The weim layout registers are the same for MX51 and MX53. Regards, Fabi Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] RFC: porting u-boot to sequoia based nand booting board
Dear List, I am working on porting U-Boot to a sequoia based PPC440 board. It boots off NAND flash via the NDFC on the PPC440. Our NAND chip has a 16 bit bus which has presented some minor problems. The NDFC code is pretty much what we need except for a few functions that I made some changes to. In particular the two functions that I changed are board_nand_init() and board_nand_select_device(). However, I would like to use the rest of the NDFC code. All of the functions in the NDFC code are declared static so I can't access them outside of ndfc.c; is there a reason for that? Does it save code space? At the moment, in the source tree I have, I just copied ndfc.c to a different source file, made the changes I needed, and compiled that. But I don't like the idea of duplicating a significant amount of code. Any suggestions on how I should proceed with this? Likewise much of our board specific support files are copies from the sequoia code. Would it be better to symlink to the ones that are not modified? Or is it OK to just copy the relevant source files into our own board directory and make minor adjustments as needed? Regards, Alex -- Alex Waterman Computer Engineer Phone: 215-896-4920 Email: awater...@dawning.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] MX53: Add initial support for MX53ARD board
On 05/17/2011 12:29 AM, Fabio Estevam wrote:
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
Hi Fabio,
+#define ETHERNET_INT (1*32 + 31) /* GPIO2_31 */
^-- missing space
If you want to write in this form, it should be 1 * 32 + 31.
+void weim_cs1_settings()
+{
+ unsigned int reg;
+ struct weim *weim_regs = (struct weim *)WEIM_BASE_ADDR;
+ struct iomuxc *iomuxc_regs = (struct weim *)IOMUXC_BASE_ADDR;
+
+ writel(0x00020001, weim_regs-cs1gcr1);
+ writel(0x, weim_regs-cs1gcr2);
+ writel(0x16000202, weim_regs-cs1rcr1);
+ writel(0x0002, weim_regs-cs1rcr2);
+ writel(0x16002082, weim_regs-cs1wcr1);
+ writel(0x, weim_regs-cs1wcr2);
+ writel(0x, weim_regs-wcr);
Can you add #defines to describe the weim registers ? Thius is helpful
for MX51, too.
+
+ /* specify 64 MB on CS1 and CS0 */
+ reg = readl(iomuxc_regs-gpr1);
+ reg = ~0x3F;
+ reg |= 0x1B;
A macro to set the single chip select is better, something as
CS_SET_SIZE(chipselect, size), or something like that. What do you think
about it ?
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] MX5: Make the weim structure complete
On 05/17/2011 02:58 PM, Fabio Estevam wrote: I think what Jason mentions is the fact that I added: #define CS1_BASE_ADDR 0xF400 and this was only for MX53 because it is protected by elif defined(CONFIG_MX53) Ah ok, agree. I can add the CS1_BASE_ADDR for MX51 as well on my v3 series. The weim layout registers are the same for MX51 and MX53. Yes, they are. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 05/10] armv7: integrate cache maintenance support
Hi Wolfgang, On Tuesday 17 May 2011 05:58 PM, Wolfgang Denk wrote: Dear Aneesh V, In message4dd264b7.9060...@ti.com you wrote: In ARM literature this kind of situations are also referred to as self- modifying. Here is an excerpt from ARM manual gloassary: I see. Thanks. Well, all the data copy will also use cached writes, which are much You mean, you will do a range-flush on only the .text section's area? That should indeed be sufficient. faster. I think this will result in measurable time differences. Relocation itself was not taking a huge amount of time in my measurement sometime back. It was about 16 ms for OMAP4. I was especially talking about the loading from external storage, not primarily relocation. This will even be mnore important if we had (much) bigger images - like when loading an OS kernel as second stage payload instead of U-Boot. Are you talking about enabling D-cache in SPL? Technically, this should be possible as soon as DRAM is initialized(because internal RAMs typically do not have enough memory for page-tables(16KB) in addition to the SPL itself). But you might want to consider these. 1. We need to setup the page tables, invalidate the cache, enable it and before jumping to kernel flush and disable it again. Is that all worth just for speeding up the loading part? I think one must consider DMA for loading the image instead. 2. What happens if the payload is U-Boot? You still have the problem of flushing. Besides after reaching U-Boot do we setup MMU again or not? If we decide to retain the page-tables setup by SPL then U-Boot and SPL needs to align on the location of page-tables. This is difficult because U-Boot dynamically determines the memory for page-tables where as SPL doesn't have such intelligence. If we decide to do the MMU setup again, then it means setting up the page-tables twice in the bootloaders! best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 13/22] omap4: add clock support
Hi Wolfgang,
On Monday 16 May 2011 12:30 AM, Wolfgang Denk wrote:
Dear Aneesh V,
In message1305472900-4004-14-git-send-email-ane...@ti.com you wrote:
Add support for:
1. DPLL locking
2. Initialization of clock domains and clock modules
This work draws upon previous work done for x-loader mainly by:
Santosh Shilimkarsantosh.shilim...@ti.com
Rajendra Nayakrna...@ti.com
Signed-off-by: Aneesh Vane...@ti.com
---
V2:
* Use pre-calculated M N values instead of calculated ones
* Changes due to make file changes
* Some corrections
* Do all clock initialization in SPL itself instead of differing some
work to u-boot
---
arch/arm/cpu/armv7/omap4/Makefile |1 +
arch/arm/cpu/armv7/omap4/board.c|1 +
arch/arm/cpu/armv7/omap4/clocks.c | 731
+++
arch/arm/cpu/armv7/omap4/clocks_get_m_n.c | 154 ++
arch/arm/include/asm/arch-omap4/clocks.h| 506 ++
arch/arm/include/asm/arch-omap4/sys_proto.h |6 +
arch/arm/include/asm/omap_common.h |3 +
spl/board/ti/omap4.mk |7 +-
8 files changed, 1408 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/cpu/armv7/omap4/clocks.c
create mode 100644 arch/arm/cpu/armv7/omap4/clocks_get_m_n.c
create mode 100644 arch/arm/include/asm/arch-omap4/clocks.h
It appears this might be part of or taken from some bigger scope
clocks framework. Otherwise it's diffcult for me to understand why
OMAP4 needs 1400+ lines of code, when other SoCs appear to do with
considerably less. Please comment.
No. This code was written for SPL. Please note that a lot of it is
tables used for PLL locking, clock enabling etc. OMAP4 supports
different crystal frequencies. So, more entries in each table. Also,
there are some special handling based on the OMAP4 revisions because of
some frequency limitations. So, more number of tables.
diff --git a/arch/arm/cpu/armv7/omap4/Makefile
b/arch/arm/cpu/armv7/omap4/Makefile
index 987dc9d..6154e86 100644
--- a/arch/arm/cpu/armv7/omap4/Makefile
+++ b/arch/arm/cpu/armv7/omap4/Makefile
@@ -30,6 +30,7 @@ SOBJS += lowlevel_init.o
COBJS += board.o
COBJS += mem.o
COBJS += sys_info.o
+COBJS += clocks.o
Please keep lists sorted.
ok.
...
+static inline void do_bypass_dpll(u32 base)
+{
+struct dpll_regs *dpll_regs = (struct dpll_regs *)base;
+
+modify_reg_32(dpll_regs-cm_clkmode_dpll,
+ CM_CLKMODE_DPLL_DPLL_EN_SHIFT,
+ CM_CLKMODE_DPLL_DPLL_EN_MASK, DPLL_EN_FAST_RELOCK_BYPASS);
NAK, please use standard macros (see previous messages).
+static void do_setup_dpll(u32 base, const struct dpll_params *params, u8
lock)
+{
+u32 temp;
+struct dpll_regs *dpll_regs = (struct dpll_regs *)base;
+
+bypass_dpll(base);
+
+/* Set M N */
+temp = readl(dpll_regs-cm_clksel_dpll);
+set_bit_field(temp, CM_CLKSEL_DPLL_M_SHIFT, CM_CLKSEL_DPLL_M_MASK,
+params-m);
+set_bit_field(temp, CM_CLKSEL_DPLL_N_SHIFT, CM_CLKSEL_DPLL_N_MASK,
+params-n);
+writel(temp,dpll_regs-cm_clksel_dpll);
NAK, please use standard macros (see previous messages).
...
diff --git a/arch/arm/cpu/armv7/omap4/clocks_get_m_n.c
b/arch/arm/cpu/armv7/omap4/clocks_get_m_n.c
new file mode 100644
index 000..777ec11
--- /dev/null
+++ b/arch/arm/cpu/armv7/omap4/clocks_get_m_n.c
@@ -0,0 +1,154 @@
...
+void main(void)
It appears this is a host program, not part of U-Boot. I don't think
that arch/arm/cpu/armv7/omap4/ is the right place for this program.
...
...
+#define CM_CLKMODE_DPLL_DDRPHY (OMAP44XX_L4_CORE_BASE + 0x4220)
+#define CM_IDLEST_DPLL_DDRPHY (OMAP44XX_L4_CORE_BASE + 0x4224)
+#define CM_AUTOIDLE_DPLL_DDRPHY (OMAP44XX_L4_CORE_BASE + 0x4228)
+#define CM_CLKSEL_DPLL_DDRPHY (OMAP44XX_L4_CORE_BASE + 0x422c)
+#define CM_DIV_M2_DPLL_DDRPHY (OMAP44XX_L4_CORE_BASE + 0x4230)
+#define CM_DIV_M4_DPLL_DDRPHY (OMAP44XX_L4_CORE_BASE + 0x4238)
+#define CM_DIV_M5_DPLL_DDRPHY (OMAP44XX_L4_CORE_BASE + 0x423c)
+#define CM_DIV_M6_DPLL_DDRPHY (OMAP44XX_L4_CORE_BASE + 0x4240)
+#define CM_SSC_DELTAMSTEP_DPLL_DDRPHY (OMAP44XX_L4_CORE_BASE + 0x4248)
+#define CM_SHADOW_FREQ_CONFIG1 (OMAP44XX_L4_CORE_BASE + 0x4260)
NAK. We do not accept base address plus offset notation. Please
declare C structs instead.
Ok. will do.
Again just curious, what's the reasoning behind this policy? Is it just
aesthetics or something more?
best regards,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC: porting u-boot to sequoia based nand booting board
Hi Alex, On Tuesday 17 May 2011 15:00:45 Alex Waterman wrote: I am working on porting U-Boot to a sequoia based PPC440 board. It boots off NAND flash via the NDFC on the PPC440. Our NAND chip has a 16 bit bus which has presented some minor problems. Yes, until now, all 4xx boards use 8bit NAND chips. The NDFC code is pretty much what we need except for a few functions that I made some changes to. In particular the two functions that I changed are board_nand_init() and board_nand_select_device(). What changes did you have to make? Some 8/16 bit related changes? Or something else? However, I would like to use the rest of the NDFC code. It should be the goal, to use *only* the common NDFC code. If you have found some bugs, or you need some changes for 16bit devices, we should try to integrate them into the common code. All of the functions in the NDFC code are declared static so I can't access them outside of ndfc.c; is there a reason for that? Does it save code space? One idea behind the static declarations is to not pollute the namespace. At the moment, in the source tree I have, I just copied ndfc.c to a different source file, made the changes I needed, and compiled that. Ughhh! But I don't like the idea of duplicating a significant amount of code. Any suggestions on how I should proceed with this? Yes, please see above. Please explain what changes you need exactly and we will see, if we can integrate them into the common driver. Likewise much of our board specific support files are copies from the sequoia code. Would it be better to symlink to the ones that are not modified? Or is it OK to just copy the relevant source files into our own board directory and make minor adjustments as needed? Usually we copy those files into a new board directly. When the similarities are too big, then we should probably think about splitting to common parts into some other directory (arch/powerpc/cpu/ppc4xx/ppc440epx.c ???). Best regards, 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 v2 06/22] Add generic spl infrastructure
Hi Wolfgang, On Tuesday 17 May 2011 06:03 PM, Wolfgang Denk wrote: Dear Aneesh V, In message4dd26719.5090...@ti.com you wrote: I was thinking that it may be faster. More number of registers at disposal may mean less number of pushes to the stack, right? I am not sure if this will make a significant difference. It does not make a significant difference. Which is the reason I vote for avoiding the #ifdef. Ok. I shall change it. best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC: porting u-boot to sequoia based nand booting board
Stefan, On 05/17/2011 09:41 AM, Stefan Roese wrote: What changes did you have to make? Some 8/16 bit related changes? Or something else? I changed the hard coded value of EBC0_CFG; I forced the chip-options field to have the 16 bit bus width flag set; in board_nand_select_device() I modified the value written to the NDFC_CCR register; I think that's primarily it. The hard coded registers could be made into CONFIG_SYS defines I think, but the bus width setting... Could we make a CONFIG_SYS define that specifies the width of the bus since during the spl we don't have access to the nand chip table? It should be the goal, to use *only* the common NDFC code. If you have found some bugs, or you need some changes for 16bit devices, we should try to integrate them into the common code. I have seen issues with the nand_read_byte16() function in nand_base.c; it seems like the cpu_to_le16() should be the other way around: le16_to_cpu(). Other than that no bugs as far as I am aware. One idea behind the static declarations is to not pollute the namespace. Ahh, understood. Likewise much of our board specific support files are copies from the sequoia code. Would it be better to symlink to the ones that are not modified? Or is it OK to just copy the relevant source files into our own board directory and make minor adjustments as needed? Usually we copy those files into a new board directly. When the similarities are too big, then we should probably think about splitting to common parts into some other directory (arch/powerpc/cpu/ppc4xx/ppc440epx.c ???). OK, I see. Most of the code in board/amcc/sequoia is the same except for some of the sdram initialization and the sequoia.c file (which I renamed to tiger.c). Also the linker script differs slightly. How would we go about making those board files common (init.S, chip_config.c)? Regards, Alex -- Alex Waterman Computer Engineer Phone: 215-896-4920 Email: awater...@dawning.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 15/22] omap4: add sdram init support
On Monday 16 May 2011 01:31 AM, Wolfgang Denk wrote: Dear Aneesh V, In message1305472900-4004-16-git-send-email-ane...@ti.com you wrote: Add support for the SDRAM controller (EMIF). Signed-off-by: Aneesh Vane...@ti.com V2: * Changes for makefile changes * Minor corrections in do_lpddr2_init() * Minor corrections to read_idle interval calculation * Sanity test of memory after doing the initialization * Fixed warnings reported with with latest GCC compilers --- arch/arm/cpu/armv7/omap4/Makefile |3 + arch/arm/cpu/armv7/omap4/board.c|2 +- arch/arm/cpu/armv7/omap4/emif.c | 298 +++ arch/arm/cpu/armv7/omap4/sdram_elpida.c | 118 + arch/arm/include/asm/arch-omap4/emif.h | 719 +++ arch/arm/include/asm/arch-omap4/omap4.h | 11 + arch/arm/include/asm/arch-omap4/sys_proto.h |1 + include/configs/omap4_sdp4430.h |5 - spl/board/ti/omap4.mk |9 +- 9 files changed, 1159 insertions(+), 7 deletions(-) create mode 100644 arch/arm/cpu/armv7/omap4/emif.c create mode 100644 arch/arm/cpu/armv7/omap4/sdram_elpida.c create mode 100644 arch/arm/include/asm/arch-omap4/emif.h I'm really surprised to see this patch at this position in the middle of this patch series. Can you please explain why you think this is the right place for it? This is roughly the sequence I followed. 1. Make the basic infrastructure. 2. Have a working skeleton of SPL(Just boots but doesn't do the loading part yet) 3. Add mux support. 4. Add clock initialization 5. Add SDRAM initialization(clock patch is a pre-requisite for this) 6. Add support for MMC initialization and loading of U-Boot 7. Add FAT mode boot support. 8. Add support for Panda I think this will change a bit when I do some squashing as you suggested. best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 16/22] omap4: calculate EMIF register values
Hi Wolfgang, On Monday 16 May 2011 01:35 AM, Wolfgang Denk wrote: Dear Aneesh V, In message1305472900-4004-17-git-send-email-ane...@ti.com you wrote: Calculate EMIF register values based on AC timing parameters from the SDRAM datasheet and the DDR frequency rather than using the hard-coded values. For a new board the user doen't have to go through the tedious process of calculating the register values. Instead, just provide the AC timings from the device data sheet as input and the driver will automatically calculate the register values. Does it make sense to do this in the driver code? These parameters will never change, so why can we not rather perform the computation only once, at build time, and feed in the respective parameters to the driver? Some of the parameters do change. For instance on one of the OMAP4 revisions the DDR runs at 200MHz, on another one at 380MHz and for the rest at 400MHz. Also, on ES1 we have 512 MB of memory where as on others we have 1GB. This driver is also doing discovery of SDRAM geometry, type, etc. Reasons why I am concerned about such an approach are code size and boot time. Both suffer ... I had the same concerns too. So, I have provided a CONFIG option - CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS - by which the user can provide the register values, so no computation will be done. So, if somebody is concerned about the performance they can just compute the values using this driver and print them out by enabling the debug traces, fill it up in the structs provided for it and enable CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS. That should work. Also, please note that I had measured the time taken for the entire SDRAM initialization and it was not at all significant(IIRC, it was less than 1ms). best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 16/22] omap4: calculate EMIF register values
Hi Mans, On Monday 16 May 2011 02:12 AM, Måns Rullgård wrote: Wolfgang Denkw...@denx.de writes: Dear Aneesh V, In message1305472900-4004-17-git-send-email-ane...@ti.com you wrote: Calculate EMIF register values based on AC timing parameters from the SDRAM datasheet and the DDR frequency rather than using the hard-coded values. For a new board the user doen't have to go through the tedious process of calculating the register values. Instead, just provide the AC timings from the device data sheet as input and the driver will automatically calculate the register values. Does it make sense to do this in the driver code? These parameters will never change, so why can we not rather perform the computation only once, at build time, and feed in the respective parameters to the driver? I agree, there should be no reason for doing this at runtime. I would think it possible to do with some C macros. I had a C macro version earlier. But as I have mentioned in my reply to Wolfgang some of the inputs vary between different revisions of our silicon. I am doing a run-time identification of the revision and doing the settings accordingly. Besides, the forest of MACROs was really ugly. best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 17/22] omap4: automatic sdram detection
Hi Wolfgang, On Monday 16 May 2011 01:36 AM, Wolfgang Denk wrote: Dear Aneesh V, In message1305472900-4004-18-git-send-email-ane...@ti.com you wrote: Identify SDRAM devices connected to EMIF automatically: LPDDR2 devices have some Mode Registers that provide details about the device such as the type, density, bus width etc. EMIF has the capability to read these registers. If there are not devices connected to a given chip-select reading mode registers will return junk values. After reading as many such registers as possible and matching with expected ranges of values the driver can identify if there is a device connected to the respective CS. If we identify that a device is connected the values read give us complete details about the device. This along with the base AC timings specified by JESD209-2 allows us to do a complete automatic initialization of SDRAM that works on all boards. Please note that the default AC timings specified by JESD209-2 will be safe for all devices but not necessarily optimal. However, for the Elpida devices used on Panda and SDP the default timings are both safe and optimal. Signed-off-by: Aneesh Vane...@ti.com --- arch/arm/cpu/armv7/omap4/emif.c | 177 +- arch/arm/cpu/armv7/omap4/sdram_elpida.c |9 +- include/configs/omap4_sdp4430.h |1 + 3 files changed, 176 insertions(+), 11 deletions(-) How much of this is OMAP4 specific, and how much can be reused onother SoCs as well? LPDDR2 provides registers. But OMAP4 EMIF controller provides the means to read them. In that sense it is closely tied to EMIF. best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/8] keymile arm boards update, part 2
Hi Prafulla, Prafulla Wadaskar wrote: -Original Message- From: Valentin Longchamp [mailto:valentin.longch...@keymile.com] Sent: Wednesday, May 11, 2011 8:52 PM To: Prafulla Wadaskar Cc: u-boot@lists.denx.de; holger.bru...@keymile.com Subject: Re: [PATCH v3 0/8] keymile arm boards update, part 2 Hi Prafulla, Valentin Longchamp wrote: This series is the second effort of merging the Keymile boards support back into mainline. This series is a subset of the first patch series: http://lists.denx.de/pipermail/u-boot/2011-April/090013.html The first large series was split up to three independent series, which are easier to review and apply for the custodians. This series adds the km_arm specific parts of the series. All its changes concern our marvell based boards and that's why it should go through the u-boot-marvell git tree. Changes for v3: taken Prafulla's comments into account I have posted those one week ago, and I was wondering if you would be able to review/take them in you tree soon ? Yes Valentin I will review them in this week, sorry for delay. Thank you for the review. I guess now the series is ready go into mainline. With -rc1 to be freezed very soon, we really would like to see it getting pushed before this freeze. This series is the last remaining part of our effort to rationalize our code base for the Keymile boards and integrate it into mainline and thus it would help us for our current/future developments that this series goes as well to mainline for the current approaching release. Best Regards -- Valentin Longchamp Embedded Software Engineer Hardware and Chip Integration __ KEYMILE AG Schwarzenburgstr. 73 CH-3097 Liebefeld Phone +41 31 377 1318 Fax +41 31 377 1212 valentin.longch...@keymile.com www.keymile.com __ KEYMILE: A Specialist as a Partner ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] Pull request u-boot-atmel.git next
Hello Albert, Yes, it is even trivial; but I expect pull request to be from 'master' branches, which contain patches accepted by the custodian for the upcoming version, not from 'next' branches, which are a waiting queue for patches that will only go into the next merge window -- as per http://www.denx.de/wiki/view/U-Boot/CustodianGitTrees#Tips_for_maintaining_custodian_t OK, I changed the branch names accordingsly, you can now pull from u-boot-atmel.git master: The following changes since commit 2e73808ee97d75400881d1fe144b062f427cfcb9: Clint Adams (1): Enable multiple fs options for Marvell SoC family on OpenRD boards are available in the git repository at: git://git.denx.de/u-boot-atmel.git master Andreas Bießmann (19): avr32: rename memory-map.h - hardware.h avr32: fixup definitions to ATMEL_BASE_xxx avr32: fix linking avr32/config.mk: simplify PLATFORM_RELFLAGS avr32: use single linker script atngw100: fix #define 1 atstk1002: fix #define 1 atstk1003: fix #define 1 atstk1004: fix #define 1 atstk1006: fix #define 1 favr-32-ezkit: fix #define 1 hammerhead: fix #define 1 mimc200: fix #define 1 atngw100: move CONFIG_SYS_TEXT_BASE to header atstk100x: move CONFIG_SYS_TEXT_BASE to header favr-32-ezkit: move CONFIG_SYS_TEXT_BASE to header mimc200: move CONFIG_SYS_TEXT_BASE to header hammerhead: move CONFIG_SYS_TEXT_BASE to header avr32: add ATAG_BOARDINFO Daniel Gorsulowski (3): at91: fixed at91sam9263 system file at91: reworked support for meesc board at91: reworked support for otc570 board Jens Scharsig (2): at91rm9200: fix lowlevel_init() SMRDATA size remove __attribute__ ((packed)) in at91 headers Reinhard Meyer (15): AT91: rework at91sam9260.h AT91: rework at91sam9261.h AT91: rework at91sam9263.h AT91: rework at91sam9g45.h AT91: cleanup hardware.h, remove memory-map.h AT91: fix related arch-at91 header files AT91: fix related at91 system/driver files AT91: fix related at91 driver files ATMEL: fix related common atmel driver files AT91: cleanup at91sam9260_matrix.h to struct SoC access AT91: change includes from asm/arch/io.h to asm/io.h ATMEL: fix dataflash (dirty) this file should be converted to struct SoC access AT91: remove LEGACY from at91_rstc.h AT91: fix at91sam_wdt.c to reworked header files AT91: fix timer.c - remove reset_timer() Ryan Mallon (1): Add support for Bluewater Systems Snapper 9260 and 9G20 modules arch/arm/cpu/arm920t/at91/lowlevel_init.S |8 +- arch/arm/cpu/arm926ejs/at91/Makefile |1 + arch/arm/cpu/arm926ejs/at91/at91sam9260_devices.c | 47 +--- arch/arm/cpu/arm926ejs/at91/at91sam9263_devices.c | 55 ++--- arch/arm/cpu/arm926ejs/at91/clock.c|8 +- arch/arm/cpu/arm926ejs/at91/cpu.c | 11 +- arch/arm/cpu/arm926ejs/at91/eflash.c | 16 +- arch/arm/cpu/arm926ejs/at91/led.c |2 +- arch/arm/cpu/arm926ejs/at91/reset.c|4 +- arch/arm/cpu/arm926ejs/at91/timer.c| 37 ++-- arch/arm/include/asm/arch-at91/at91_common.h |3 +- arch/arm/include/asm/arch-at91/at91_mc.h | 10 +- arch/arm/include/asm/arch-at91/at91_pio.h | 19 +-- arch/arm/include/asm/arch-at91/at91_rstc.h | 25 -- arch/arm/include/asm/arch-at91/at91_st.h |2 +- arch/arm/include/asm/arch-at91/at91_tc.h |4 +- arch/arm/include/asm/arch-at91/at91sam9260.h | 252 ++- .../arm/include/asm/arch-at91/at91sam9260_matrix.h | 102 - arch/arm/include/asm/arch-at91/at91sam9261.h | 187 --- arch/arm/include/asm/arch-at91/at91sam9263.h | 218 - arch/arm/include/asm/arch-at91/at91sam9g45.h | 225 - arch/arm/include/asm/arch-at91/gpio.h | 18 +- arch/arm/include/asm/arch-at91/hardware.h | 96 +++- arch/arm/include/asm/arch-at91/io.h| 43 arch/arm/include/asm/arch-at91/memory-map.h| 36 --- arch/avr32/config.mk |6 +- arch/avr32/cpu/at32ap700x/clk.c|2 +- arch/avr32/cpu/at32ap700x/portmux.c|2 +- arch/avr32/cpu/at32ap700x/sm.h |4 +- arch/avr32/cpu/cpu.c |2 +- arch/avr32/cpu/hsdramc.c |2 +- arch/avr32/cpu/hsdramc1.h |4 +- arch/avr32/cpu/hsmc3.h |4 +- arch/avr32/cpu/interrupts.c|4 +- arch/avr32/cpu/portmux-gpio.c |2 +- arch/avr32/cpu/portmux-pio.c |2 +-
Re: [U-Boot] RFC: porting u-boot to sequoia based nand booting board
Alex, On Tuesday 17 May 2011 16:11:14 Alex Waterman wrote: What changes did you have to make? Some 8/16 bit related changes? Or something else? I changed the hard coded value of EBC0_CFG; I forced the chip-options field to have the 16 bit bus width flag set; in board_nand_select_device() I modified the value written to the NDFC_CCR register; I think that's primarily it. The hard coded registers could be made into CONFIG_SYS defines I think, but the bus width setting... Could we make a CONFIG_SYS define that specifies the width of the bus since during the spl we don't have access to the nand chip table? I see no problem with such an approach. How about CONFIG_SYS_NDFC_16BIT? If its not defined, then the currently used 8bit configuration is shall be selected. It should be the goal, to use *only* the common NDFC code. If you have found some bugs, or you need some changes for 16bit devices, we should try to integrate them into the common code. I have seen issues with the nand_read_byte16() function in nand_base.c; it seems like the cpu_to_le16() should be the other way around: le16_to_cpu(). Other than that no bugs as far as I am aware. Hmmm. Not sure here. Perhaps this is PPC4xx specific. A better solution with less impact on other platforms using nand_base.c would be to implement a nand_read_byte() function in ndfc.c when CONFIG_SYS_NDFC_16BIT is defined. This way the default implementation from nand_base will be overridden. Likewise much of our board specific support files are copies from the sequoia code. Would it be better to symlink to the ones that are not modified? Or is it OK to just copy the relevant source files into our own board directory and make minor adjustments as needed? Usually we copy those files into a new board directly. When the similarities are too big, then we should probably think about splitting to common parts into some other directory (arch/powerpc/cpu/ppc4xx/ppc440epx.c ???). OK, I see. Most of the code in board/amcc/sequoia is the same except for some of the sdram initialization and the sequoia.c file (which I renamed to tiger.c). Also the linker script differs slightly. How would we go about making those board files common (init.S, chip_config.c)? Hard to tell without being able to look at your code and the differences. I suggest that you first create a patch with the NAND changes mentioned above and with your new board support (tiger) in a separate directory. We can discuss the details then on the list: if and how the sequoia code could/should be re-used. Best regards, 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] [PULL] Pull request u-boot-atmel.git next
Hi Reinhard, Le 17/05/2011 17:34, Reinhard Meyer a écrit : Hello Albert, Yes, it is even trivial; but I expect pull request to be from 'master' branches, which contain patches accepted by the custodian for the upcoming version, not from 'next' branches, which are a waiting queue for patches that will only go into the next merge window -- as perhttp://www.denx.de/wiki/view/U-Boot/CustodianGitTrees#Tips_for_maintaining_custodian_t OK, I changed the branch names accordingsly, you can now pull from u-boot-atmel.git master: Thanks a lot! Incidentally, I see a new master-arm branch on u-boot-atmel. If it is one you created locally to track u-boot-arm/master and pushed by accident, then you can unpublish it from your public git repo by 'git push ssh://gu-at...@git.denx.de/u-boot-atmel :master-arm'. The following changes since commit 2e73808ee97d75400881d1fe144b062f427cfcb9: Clint Adams (1): Enable multiple fs options for Marvell SoC family on OpenRD boards are available in the git repository at: git://git.denx.de/u-boot-atmel.git master Applied to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] Pull request u-boot-atmel.git next
Hi Albert, Incidentally, I see a new master-arm branch on u-boot-atmel. If it is one you created locally to track u-boot-arm/master and pushed by accident, then you can unpublish it from your public git repo by 'git push ssh://gu-at...@git.denx.de/u-boot-atmel :master-arm'. No, that was on purpose. Because then one can easyly do a git request-pull master-arm git://git.denx.de/u-boot-atmel.git (I was not sure whether that would refer to the local repo or to the repo at denx, so I pushed it :) I will clean this and all rework branches etc. soon. Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/22] Add generic spl infrastructure
On Tue, 17 May 2011 12:24:34 +0530
Aneesh V ane...@ti.com wrote:
On Tuesday 17 May 2011 12:02 AM, Scott Wood wrote:
On Sun, 15 May 2011 20:51:24 +0530
Aneesh Vane...@ti.com wrote:
diff --git a/arch/arm/include/asm/global_data.h
b/arch/arm/include/asm/global_data.h
index 2a84d27..2ce020e 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -89,6 +89,11 @@ typedef struct global_data {
#define GD_FLG_DISABLE_CONSOLE 0x00040 /* Disable console (in out)
*/
#define GD_FLG_ENV_READY 0x00080 /* Environment imported into hash table
*/
+#ifdef CONFIG_PRELOADER
+/* SPL works from internal RAM. gd pointer can be in .data section */
+#define DECLARE_GLOBAL_DATA_PTR extern gd_t *gd
+#else
#define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm (r8)
+#endif
Is this appropriate for all ARM boards (e.g. those currently using
nand_spl)?
None of the SPL's other than this one seems to be using global data
today. If anybody wants to use it this seems to be the logical option
for me because by definition SPL runs from some kind of RAM so global
data can be placed in the .data section of SPL.
There is nand_spl code, including ARM, that uses gd. E.g. putc() in
board/davinci/da8xxevm/hawkboard_nand_spl.c.
This comment also applies to the other uses of CONFIG_PRELOADER -- are all
of those changes appropriate for the existing nand_spl users?
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] Accurate boot time measurement
On Tue, May 17, 2011 at 1:20 AM, Detlev Zundel d...@denx.de wrote: Hi Simon and Wolfgang, [...] In terms of all this discussion I can see your point :-) I did have expressions of interest from two people including one I thought was at your company, which I why I went to the effort to clean up and submit this. At that time I didn't realise it would be such a touchy subject. I don't believe this topic to be touchy, it's just that Wolfgang trying to keep the whole code base in shape has a healthy inertia before introducing changes that may be difficult to keep consistent over the multitude of SoCs that we support. To throw in my personal view again, I still would like to see such an infrastructure to get into U-Boot code. I fully agree with Wolfgang that practically the printfs and timing are a method already in place to do measurements. On the other hand my experience has shown that for some reason or other this has never been widely used. So effectively, it wasn't too helpful for the project itself. So I still believe that if we _had_ an infrastructure like you propose, we would get more people interested in _actually_ measuring and improving the code base, which would certainly be a good thing. Of course we have systems that are very limited in their ressources, but this is the reason why many features of U-Boot are opt-in features not forcing any resource usage on such boards. So if some of them are so short on resources that they cannot use such a timing framework, then so be it. But as most of the probably are in the legacy code base, they should not stop us from getting getting positive effects for the currently important boards and architectures. Cheers Detlev Hi Detlev and Wolfgang, Thanks for your comments. I understand a little bit of healthy inertia and do appreciate the constraints. I believe I have covered this ground very thoroughly and would like advice please on what to do next. The options I can see are: - change the code to use a fallback when a microsecond timer is not available - integrate with boot progress - something else? drop it? Regards. Simon -- A change in language can transform our appreciation of the cosmos -- Benjamin Lee Whorf -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Getting ready for -rc1
Am Montag, den 16.05.2011, 22:24 +0200 schrieb Wolfgang Denk: Hi everybody, I would like to get our -rc1 within the next 2 days or so. Please drop me (and the respective custodian) a note if you have any patches that are supposed to go in. I'd like to request the inclusion of my patchset adding a command to manually trigger an update from a FIT-image, see http://lists.denx.de/pipermail/u-boot/2011-April/090911.html http://lists.denx.de/pipermail/u-boot/2011-April/090912.html http://lists.denx.de/pipermail/u-boot/2011-April/090913.html resp. http://patchwork.ozlabs.org/bundle/apr-cn-eng/fitupd/ http://patchwork.ozlabs.org/patch/92055/ http://patchwork.ozlabs.org/patch/92056/ I suppose Mr. Jerry Van Baren as the FDT custodian is the primary contact, therefore I added him to CC. But maybe you could decide also. Discussion leading to this feature was http://lists.denx.de/pipermail/u-boot/2011-April/090202.html http://lists.denx.de/pipermail/u-boot/2011-April/090210.html http://lists.denx.de/pipermail/u-boot/2011-April/090484.html http://lists.denx.de/pipermail/u-boot/2011-April/090914.html Thanks in advance, Andreas -- carpe noctem engineering Ingenieurbuero fuer Hard- Software-Entwicklung Andreas Pretzsch Dipl.-Ing. (FH) Andreas Pretzsch Tel. +49-(0)731-5521572 Hahnengasse 3 Fax: +49-(0)731-5521573 89073 Ulm, Germanyemail: a...@cn-eng.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC: porting u-boot to sequoia based nand booting board
On Tue, 17 May 2011 10:11:14 -0400 Alex Waterman awater...@dawning.com wrote: I have seen issues with the nand_read_byte16() function in nand_base.c; it seems like the cpu_to_le16() should be the other way around: le16_to_cpu(). Other than that no bugs as far as I am aware. What is the specific problem you're seeing? The use of these endian macros is a bit abusive and ugly (what's really wanted is native-endian I/O accessors -- readw() has an implicit le16_to_cpu()), and should have been done internally to the read_word() implementation rather than made part of the API, but functionally it should be correct. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC: porting u-boot to sequoia based nand booting board
Scott,
On 05/17/2011 01:05 PM, Scott Wood wrote:
On Tue, 17 May 2011 10:11:14 -0400
Alex Waterman awater...@dawning.com wrote:
I have seen issues with the nand_read_byte16() function in nand_base.c; it
seems like the cpu_to_le16() should be the other way around: le16_to_cpu().
Other than that no bugs as far as I am aware.
What is the specific problem you're seeing? The use of these endian macros
is a bit abusive and ugly (what's really wanted is native-endian I/O
accessors -- readw() has an implicit le16_to_cpu()), and should have been
done internally to the read_word() implementation rather than made part of
the API, but functionally it should be correct.
When I was getting our NAND to work, it seemed like that function was always
returning 0. I fixed it by writing a read_byte() function like this:
/*
* Read a byte from the NDFC.
*/
static uint8_t tiger_read_byte(struct mtd_info *mtd){
uint16_t word;
struct nand_chip *chip = mtd-priv;
word = readw(chip-IO_ADDR_R);
return (uint8_t) word;
}
It looked to me like the readw() function was returning the data in the correct
CPU endianness (at least for PPC) and that the cpu_to_le16() was swapping the
bytes such that the cast down to a uint8_t was getting the unset high order
byte from the 16 bit read.
Regards,
Alex
--
Alex Waterman
Computer Engineer
Phone: 215-896-4920
Email: awater...@dawning.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: nand flash
The following changes since commit 535abb96fb665402894b820f934deaca61ce3d3e: Merge branch 'master' of git://git.denx.de/u-boot-nand-flash (2011-05-15 23:23:36 +0200) are available in the git repository at: git://git.denx.de/u-boot-nand-flash.git master Stefan Roese (1): nand_spl: nand_boot.c: Remove last CONFIG_SYS_NAND_READ_DELAY occurance nand_spl/nand_boot.c |7 ++- 1 files changed, 2 insertions(+), 5 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC: porting u-boot to sequoia based nand booting board
On Tue, 17 May 2011 13:49:44 -0400
Alex Waterman awater...@dawning.com wrote:
Scott,
On 05/17/2011 01:05 PM, Scott Wood wrote:
On Tue, 17 May 2011 10:11:14 -0400
Alex Waterman awater...@dawning.com wrote:
I have seen issues with the nand_read_byte16() function in nand_base.c; it
seems like the cpu_to_le16() should be the other way around:
le16_to_cpu(). Other than that no bugs as far as I am aware.
What is the specific problem you're seeing? The use of these endian macros
is a bit abusive and ugly (what's really wanted is native-endian I/O
accessors -- readw() has an implicit le16_to_cpu()), and should have been
done internally to the read_word() implementation rather than made part of
the API, but functionally it should be correct.
When I was getting our NAND to work, it seemed like that function was always
returning 0. I fixed it by writing a read_byte() function like this:
/*
* Read a byte from the NDFC.
*/
static uint8_t tiger_read_byte(struct mtd_info *mtd){
uint16_t word;
struct nand_chip *chip = mtd-priv;
word = readw(chip-IO_ADDR_R);
return (uint8_t) word;
}
It looked to me like the readw() function was returning the data in the
correct CPU endianness (at least for PPC) and that the cpu_to_le16() was
swapping the bytes such that the cast down to a uint8_t was getting the unset
high order byte from the 16 bit read.
If readw() is returning the bytes in the correct endianness, then that
means the register is little-endian.
It's not clear to me what the default assumption in nand_base.c is,
though. read_byte16() suggests the default is native endian, but
read_buf() and read_word() suggest it's little endian. :-(
Is there any currently working host-big-endian platform with 16-bit NAND
that doesn't override these functions?
BTW, as for read_word(), looking at its only user, I think nand_block_bad()
should be checking a 16-bit bad block marker on 16-bit NAND, rather than the
low byte. Why is there a separate mechanism for checking bad block markers
than the one in nand_bbt.c (not the bbt itself, but the code used to read
the markers to create the bbt)? As long as a BBT is used, I don't think
read_word() will ever matter.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC: porting u-boot to sequoia based nand booting board
Scott, If readw() is returning the bytes in the correct endianness, then that means the register is little-endian. It's not clear to me what the default assumption in nand_base.c is, though. read_byte16() suggests the default is native endian, but read_buf() and read_word() suggest it's little endian. :-( I am not sure either; the nand_read_byte16() function confuses me quite a bit. I really have no idea whether what I have done is wrong and an evil hack or if I found a typo or something. Is there any currently working host-big-endian platform with 16-bit NAND that doesn't override these functions? I really can't say. I haven't looked through the source of any of the other boards. As Stefan said, all previous 4xx based boards use 8 bit NAND so the possibility that there might be a problem with the 16 bit code on 4xx based boards doesn't surprise me. BTW, as for read_word(), looking at its only user, I think nand_block_bad() should be checking a 16-bit bad block marker on 16-bit NAND, rather than the low byte. Why is there a separate mechanism for checking bad block markers than the one in nand_bbt.c (not the bbt itself, but the code used to read the markers to create the bbt)? As long as a BBT is used, I don't think read_word() will ever matter. I think it may have something to do with the NAND SPL loader. Since the NDFC code is being used by the SPL, it has to be small. Pulling in the all of the nand_bbt.c code for just the code that checks if the block is actually bad may (probably) have been to much for the SPL. Thats my guess at least. If the 16 bit chips used 0x as a bad block marker then yeah, I suppose the endianness wouldn't matter. Is that something that we can do? Just choose to use 0x? Will that not potentially mess up JFFS support or what not from the Linux kernel that gets booted? Regards, Alex -- Alex Waterman Computer Engineer Phone: 215-896-4920 Email: awater...@dawning.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC: porting u-boot to sequoia based nand booting board
On Tue, 17 May 2011 17:15:50 -0400 Alex Waterman awater...@dawning.com wrote: Is there any currently working host-big-endian platform with 16-bit NAND that doesn't override these functions? I really can't say. I haven't looked through the source of any of the other boards. As Stefan said, all previous 4xx based boards use 8 bit NAND so the possibility that there might be a problem with the 16 bit code on 4xx based boards doesn't surprise me. I think the issue is broader than 4xx. BTW, as for read_word(), looking at its only user, I think nand_block_bad() should be checking a 16-bit bad block marker on 16-bit NAND, rather than the low byte. Why is there a separate mechanism for checking bad block markers than the one in nand_bbt.c (not the bbt itself, but the code used to read the markers to create the bbt)? As long as a BBT is used, I don't think read_word() will ever matter. I think it may have something to do with the NAND SPL loader. Since the NDFC code is being used by the SPL, it has to be small. Nothing in nand_base.c is used by SPL. SPL has its own code for this, which currently just does a readb() (broken on 16-bit?). Pulling in the all of the nand_bbt.c code for just the code that checks if the block is actually bad may (probably) have been to much for the SPL. Thats my guess at least. If the 16 bit chips used 0x as a bad block marker then yeah, I suppose the endianness wouldn't matter. Is that something that we can do? Just choose to use 0x? Will that not potentially mess up JFFS support or what not from the Linux kernel that gets booted? It's not really our choice, it's what the manufacturer uses (unless you want to get into rewriting the markers before first use...). The one chip datasheet I looked at claimed the bad block marker was any value other than 0x on 16-bit, so checking just one of the bytes would be wrong. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Getting ready for -rc1
Hi Andreas, Wolfgang, On 05/17/2011 11:04 AM, Andreas Pretzsch wrote: Am Montag, den 16.05.2011, 22:24 +0200 schrieb Wolfgang Denk: Hi everybody, I would like to get our -rc1 within the next 2 days or so. Please drop me (and the respective custodian) a note if you have any patches that are supposed to go in. I'd like to request the inclusion of my patchset adding a command to manually trigger an update from a FIT-image, see http://lists.denx.de/pipermail/u-boot/2011-April/090911.html http://lists.denx.de/pipermail/u-boot/2011-April/090912.html http://lists.denx.de/pipermail/u-boot/2011-April/090913.html resp. http://patchwork.ozlabs.org/bundle/apr-cn-eng/fitupd/ http://patchwork.ozlabs.org/patch/92055/ http://patchwork.ozlabs.org/patch/92056/ I suppose Mr. Jerry Van Baren as the FDT custodian is the primary contact, therefore I added him to CC. But maybe you could decide also. This is a new command that uses the FDT utilities. As such, I believe it is in Wolfgang's area. [snip] Thanks in advance, Andreas Best regards, gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 05/10] armv7: integrate cache maintenance support
Dear Aneesh V, In message 4dd27819.7010...@ti.com you wrote: I was especially talking about the loading from external storage, not primarily relocation. This will even be mnore important if we had (much) bigger images - like when loading an OS kernel as second stage payload instead of U-Boot. Are you talking about enabling D-cache in SPL? Technically, this should I + D cache, actually. be possible as soon as DRAM is initialized(because internal RAMs typically do not have enough memory for page-tables(16KB) in addition to the SPL itself). But you might want to consider these. Ah, I see. Well, you see, I have the big advantage over you that my imagination is not limited by the ugly details of the real ARM hardware in question here ;-) 1. We need to setup the page tables, invalidate the cache, enable it and before jumping to kernel flush and disable it again. Is that all worth just for speeding up the loading part? I think one must consider DMA for loading the image instead. If it's available, for sure :-) But then, for example when loading from NAND flash (which is probably the most common use case these days), would DMA help? 2. What happens if the payload is U-Boot? You still have the problem of flushing. Besides after reaching U-Boot do we setup MMU again or not? If we decide to retain the page-tables setup by SPL then U-Boot and SPL needs to align on the location of page-tables. This is difficult because U-Boot dynamically determines the memory for page-tables where as SPL doesn't have such intelligence. If we decide to do the MMU setup again, then it means setting up the page-tables twice in the bootloaders! I guess in the general case we will have to do this twice. And Linux will do it again. It would be nice if we canmake this optional, like we can avoid the copy operation of the relocation part when we know we load to the final address (all this keeping in mind the requirements for ultra short boot times). 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 Quantum Mechanics is God's version of Trust me. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 13/22] omap4: add clock support
Dear Aneesh V, In message 4dd27893.5000...@ti.com you wrote: It appears this might be part of or taken from some bigger scope clocks framework. Otherwise it's diffcult for me to understand why OMAP4 needs 1400+ lines of code, when other SoCs appear to do with considerably less. Please comment. No. This code was written for SPL. Please note that a lot of it is tables used for PLL locking, clock enabling etc. OMAP4 supports different crystal frequencies. So, more entries in each table. Also, there are some special handling based on the OMAP4 revisions because of some frequency limitations. So, more number of tables. hm... is this really a type of selection that has to be done at runtime? In the real system, the frequencies will probably pretty much fixed, and not dynamically adjusted in U-Boot. So maybe we can compile at least poarts of this at build time? NAK. We do not accept base address plus offset notation. Please declare C structs instead. Ok. will do. Again just curious, what's the reasoning behind this policy? Is it just aesthetics or something more? It's more. When using base+offset, the compiler will know nothing about the data type, so it canot warn you if you use a 32 bit accessor on a 8 bit register, or vice versa. When you pass a struct element, it can check type information. 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 How many seconds are there in a year? If I tell you there are 3.155 x 10^7, you won't even try to remember it. On the other hand, who could forget that, to within half a percent, pi seconds is a nanocentury. -- Tom Duff, Bell Labs ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 15/22] omap4: add sdram init support
Dear Aneesh V, In message 4dd28296.2060...@ti.com you wrote: Can you please explain why you think this is the right place for it? This is roughly the sequence I followed. 1. Make the basic infrastructure. 2. Have a working skeleton of SPL(Just boots but doesn't do the loading part yet) 3. Add mux support. 4. Add clock initialization 5. Add SDRAM initialization(clock patch is a pre-requisite for this) 6. Add support for MMC initialization and loading of U-Boot 7. Add FAT mode boot support. 8. Add support for Panda I think this will change a bit when I do some squashing as you suggested. Thanks for the explanation. It was really helpful. 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 Backed up the system lately? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 16/22] omap4: calculate EMIF register values
Dear Aneesh V, In message 4dd2858e.2000...@ti.com you wrote: I had the same concerns too. So, I have provided a CONFIG option - CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS - by which the user can provide the register values, so no computation will be done. Ah, great. Sorry, I have missed this. So, if somebody is concerned about the performance they can just compute the values using this driver and print them out by enabling the debug traces, fill it up in the structs provided for it and enable CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS. That should work. Will this also comment out the respective code, so we don't waste the memory for it? Also, please note that I had measured the time taken for the entire SDRAM initialization and it was not at all significant(IIRC, it was less than 1ms). 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 Mr. Cole's Axiom: The sum of the intelligence on the planet is a constant; the population is growing. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] Accurate boot time measurement
Hi Simon, Hi Detlev and Wolfgang, Thanks for your comments. I understand a little bit of healthy inertia and do appreciate the constraints. I believe I have covered this ground very thoroughly and would like advice please on what to do next. The options I can see are: - change the code to use a fallback when a microsecond timer is not available - integrate with boot progress - something else? drop it? I suggest you create a V2 of this patch series, integrating the logging into show_boot_progress() - Have a crawl through the existing code and see if you can safely use a bit in the progress number (preferably a fixed bit number across all platforms, or one defined in the config file if this is not possible) to indicate if that progress mark should be logged One day we can perhaps standardise how the parameter to show_boot_progress is treated so the same value is consistent across the entire U-Boot code. Don't worry too much about the 'pre-relocation' case for the time being. You will have to check the relocated flag stored in global data so no attempt to log is made before relocation. If there is enough support for pre-relocation logging, there can always be a V3 patch :) Make sure that the new feature has zero impact if the configuration option is not enabled (CONFIG_LOG_BOOT_PROGRESS for example). Try not to make it too ugly by littering code with #ifdef - If the bulk can be put into a file which can be selectively included in the Makefile that would be good. show_boot_progress() will naturally have some #ifdef's in it Make sure you clearly comment in each patch that it is V2 and the changes made from V1 and that you run it all through checkpatch.pl (from the Linux kernel source) Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] the processor performs an operation overflows，U-boot-based platform
unsigned long get_tbus (void)
{
unsigned long tbl=0;
unsigned long tbu1=0, tbu2=0;
unsigned long us=0;
unsigned long long tmp=0;
unsigned long tbclk = os_get_tbclk();
// get the timebase ticks
do {
__asm__ __volatile__ (mftbu %0:=r (tbu1):);
__asm__ __volatile__ (mftb %0:=r (tbl):);
__asm__ __volatile__ (mftbu %0:=r (tbu2):);
} while (tbu1 != tbu2);
// convert ticks to ms
tmp = (unsigned long long)(tbu1);
tmp = (tmp 32);
tmp += (unsigned long long)(tbl);
us = tmp / (tbclk / 100);
return us;
}
void main()
{
unsigned long uiTBusB,s_uiTBusA;
while(1)
{
s_uiTBusA = uiTBusB;
uiTBusB = (get_tbus() / 1000);
printf(uiTBusB:%d,%u\n,uiTBusB,uiTBusB);
sleep(100);
}
}
Different performance results, the code is as follows: My platform is
mpc8313, core is the e300, running 30 minutes later when there will be:
uiTBusB overflow occurred. get_tbus () = 0x8001A69B, but uiTBusB =
4292819925
but modify the function as follows:
unsigned long get_tbus (void)
{
unsigned long us =0x8001A69B
return us;
}
uiTBusB overflow does not occur,the results are normal. why only run 40
minutes later, the program will overflow, on the contrary, directly modify
the function return value, no overflow.. With the compiler set the
parameters related?
I use the compiler powerpc-e300c3-linux-gcc-4.0.2.
When powerpc perform mathematical operations, such as: get_tbus () / 1000,
the implementation of the multiplication instruction, the function return
value unsigned numbers as signed to carry out operations, resulting in
operation result overflows?
us = tmp / (tbclk / 100);
may be a source of the problem.unsigned long long and unsigned long
variables casted to each other .
I used to test the code as followed:
s_uiTBusA = uiTBusB;
uiTBusB = (get_tbus() / 1000);
printf(main:SA:%u; SB:%u; SB-SA:%d.\n, s_uiTBusA, uiTBusB,
uiTBusB-s_uiTBusA);
I know that when overflow occurs, get_tbus () the value is generally just
over 0x8000,
2.tbclk = (0x7de2900 + 3L) / 4L = 3300; us = tmp / (tbclk / 100);
I'm not sure if there are problems, but when tested for a long period of
time is no problem . tmp is unisgned long long integer, it overflow take
many years, so how can verify that the conversion is no problem? ? Function
unsigned long get_tbus (void) return value in some cases become negative,
overflow it?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCHv3] rtc: add driver for internal RTC on kirkwood SoC
From: Luuk Paulussen luuk.paulus...@alliedtelesis.co.nz
Signed-off-by: Luuk Paulussen luuk.paulus...@alliedtelesis.co.nz
Acked-by: Chris Packham chris.pack...@alliedtelesis.co.nz
Cc: Prafulla Wadaskar prafu...@marvell.com
---
Changes since v2:
- Fixed Month setting/getting. Month was off by one due to difference
between linux and u-boot time rtc time structure.
Changes since v1:
- run through checkpatch.pl and fix style issues (spaces before bracket and
lines 80 chars)
arch/arm/include/asm/arch-kirkwood/kirkwood.h |2 +
drivers/rtc/Makefile |1 +
drivers/rtc/kirkwood.c| 79 +
3 files changed, 82 insertions(+), 0 deletions(-)
create mode 100644 drivers/rtc/kirkwood.c
diff --git a/arch/arm/include/asm/arch-kirkwood/kirkwood.h
b/arch/arm/include/asm/arch-kirkwood/kirkwood.h
index 0104418..15922eb 100644
--- a/arch/arm/include/asm/arch-kirkwood/kirkwood.h
+++ b/arch/arm/include/asm/arch-kirkwood/kirkwood.h
@@ -50,6 +50,8 @@
#define KW_MPP_BASE(KW_REGISTER(0x1))
#define KW_GPIO0_BASE (KW_REGISTER(0x10100))
#define KW_GPIO1_BASE (KW_REGISTER(0x10140))
+#define KW_RTC_TIME(KW_REGISTER(0x10300))
+#define KW_RTC_DATE(KW_REGISTER(0x10304))
#define KW_NANDF_BASE (KW_REGISTER(0x10418))
#define KW_SPI_BASE(KW_REGISTER(0x10600))
#define KW_CPU_WIN_BASE(KW_REGISTER(0x2))
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index e4be4a4..ec064d9 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -43,6 +43,7 @@ COBJS-$(CONFIG_RTC_DS174x) += ds174x.o
COBJS-$(CONFIG_RTC_DS3231) += ds3231.o
COBJS-$(CONFIG_RTC_FTRTC010) += ftrtc010.o
COBJS-$(CONFIG_RTC_ISL1208) += isl1208.o
+COBJS-$(CONFIG_RTC_KIRKWOOD) += kirkwood.o
COBJS-$(CONFIG_RTC_M41T11) += m41t11.o
COBJS-$(CONFIG_RTC_M41T60) += m41t60.o
COBJS-$(CONFIG_RTC_M41T62) += m41t62.o
diff --git a/drivers/rtc/kirkwood.c b/drivers/rtc/kirkwood.c
new file mode 100644
index 000..b08fd91
--- /dev/null
+++ b/drivers/rtc/kirkwood.c
@@ -0,0 +1,79 @@
+/*
+ * Driver for the RTC in Marvell SoCs.
+ *
+ * Based on Linux Kernel driver.
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include common.h
+#include command.h
+#include rtc.h
+#include bcd.h
+#include asm/arch/kirkwood.h
+
+#if defined(CONFIG_CMD_DATE)
+
+#define RTC_TIME_REG_OFFS 0
+#define RTC_SECONDS_OFFS 0
+#define RTC_MINUTES_OFFS 8
+#define RTC_HOURS_OFFS 16
+#define RTC_WDAY_OFFS 24
+#define RTC_HOURS_12H_MODE (1 22) /* 12 hours mode */
+
+#define RTC_DATE_REG_OFFS 4
+#define RTC_MDAY_OFFS 0
+#define RTC_MONTH_OFFS 8
+#define RTC_YEAR_OFFS 16
+#define KIRKWOOD_YEAR_BASE 2000
+
+int rtc_set(struct rtc_time *tmp)
+{
+ ulong rtc_reg;
+
+ GregorianDay(tmp);
+
+ rtc_reg = (bin2bcd(tmp-tm_sec) RTC_SECONDS_OFFS) |
+ (bin2bcd(tmp-tm_min) RTC_MINUTES_OFFS) |
+ (bin2bcd(tmp-tm_hour) RTC_HOURS_OFFS) |
+ (bin2bcd(tmp-tm_wday) RTC_WDAY_OFFS);
+ writel(rtc_reg, KW_RTC_TIME);
+
+ rtc_reg = (bin2bcd(tmp-tm_mday) RTC_MDAY_OFFS) |
+ (bin2bcd(tmp-tm_mon) RTC_MONTH_OFFS) |
+ (bin2bcd(tmp-tm_year - KIRKWOOD_YEAR_BASE)
+RTC_YEAR_OFFS);
+ writel(rtc_reg, KW_RTC_DATE);
+
+ return 0;
+}
+
+int rtc_get(struct rtc_time *tmp)
+{
+ ulong rtc_time, rtc_date;
+
+ rtc_time = readl(KW_RTC_TIME);
+ rtc_date = readl(KW_RTC_DATE);
+
+ tmp-tm_sec = bcd2bin(rtc_time 0x7f);
+ tmp-tm_min = bcd2bin((rtc_time RTC_MINUTES_OFFS) 0x7f);
+ /* assume 24 hour mode */
+ tmp-tm_hour = bcd2bin((rtc_time RTC_HOURS_OFFS) 0x3f);
+ tmp-tm_mday = bcd2bin(rtc_date 0x3f);
+ tmp-tm_wday = bcd2bin((rtc_time RTC_WDAY_OFFS) 0x7);
+ tmp-tm_mon = bcd2bin((rtc_date RTC_MONTH_OFFS) 0x3f);
+ /* hw counts from year 2000, but tm_year is relative to 0 */
+ tmp-tm_year = bcd2bin((rtc_date RTC_YEAR_OFFS) 0xff)
+ + KIRKWOOD_YEAR_BASE;
+
+ return 0;
+}
+
+void rtc_reset(void)
+{
+ return;
+}
+
+#endif /* CONFIG_CMD_DATE */
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCHv2] rtc: add driver for internal RTC on kirkwood SoC
From: Luuk Paulussen luuk.paulus...@alliedtelesis.co.nz
Signed-off-by: Luuk Paulussen luuk.paulus...@alliedtelesis.co.nz
Acked-by: Chris Packham chris.pack...@alliedtelesis.co.nz
Cc: Prafulla Wadaskar prafu...@marvell.com
---
Changes since v2:
- Fixed Month setting/getting. Month was off by one due to difference
between linux and u-boot time rtc time structure.
Changes since v1:
- run through checkpatch.pl and fix style issues (spaces before bracket and
lines 80 chars)
arch/arm/include/asm/arch-kirkwood/kirkwood.h |2 +
drivers/rtc/Makefile |1 +
drivers/rtc/kirkwood.c| 79 +
3 files changed, 82 insertions(+), 0 deletions(-)
create mode 100644 drivers/rtc/kirkwood.c
diff --git a/arch/arm/include/asm/arch-kirkwood/kirkwood.h
b/arch/arm/include/asm/arch-kirkwood/kirkwood.h
index 0104418..15922eb 100644
--- a/arch/arm/include/asm/arch-kirkwood/kirkwood.h
+++ b/arch/arm/include/asm/arch-kirkwood/kirkwood.h
@@ -50,6 +50,8 @@
#define KW_MPP_BASE(KW_REGISTER(0x1))
#define KW_GPIO0_BASE (KW_REGISTER(0x10100))
#define KW_GPIO1_BASE (KW_REGISTER(0x10140))
+#define KW_RTC_TIME(KW_REGISTER(0x10300))
+#define KW_RTC_DATE(KW_REGISTER(0x10304))
#define KW_NANDF_BASE (KW_REGISTER(0x10418))
#define KW_SPI_BASE(KW_REGISTER(0x10600))
#define KW_CPU_WIN_BASE(KW_REGISTER(0x2))
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index e4be4a4..ec064d9 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -43,6 +43,7 @@ COBJS-$(CONFIG_RTC_DS174x) += ds174x.o
COBJS-$(CONFIG_RTC_DS3231) += ds3231.o
COBJS-$(CONFIG_RTC_FTRTC010) += ftrtc010.o
COBJS-$(CONFIG_RTC_ISL1208) += isl1208.o
+COBJS-$(CONFIG_RTC_KIRKWOOD) += kirkwood.o
COBJS-$(CONFIG_RTC_M41T11) += m41t11.o
COBJS-$(CONFIG_RTC_M41T60) += m41t60.o
COBJS-$(CONFIG_RTC_M41T62) += m41t62.o
diff --git a/drivers/rtc/kirkwood.c b/drivers/rtc/kirkwood.c
new file mode 100644
index 000..b08fd91
--- /dev/null
+++ b/drivers/rtc/kirkwood.c
@@ -0,0 +1,79 @@
+/*
+ * Driver for the RTC in Marvell SoCs.
+ *
+ * Based on Linux Kernel driver.
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include common.h
+#include command.h
+#include rtc.h
+#include bcd.h
+#include asm/arch/kirkwood.h
+
+#if defined(CONFIG_CMD_DATE)
+
+#define RTC_TIME_REG_OFFS 0
+#define RTC_SECONDS_OFFS 0
+#define RTC_MINUTES_OFFS 8
+#define RTC_HOURS_OFFS 16
+#define RTC_WDAY_OFFS 24
+#define RTC_HOURS_12H_MODE (1 22) /* 12 hours mode */
+
+#define RTC_DATE_REG_OFFS 4
+#define RTC_MDAY_OFFS 0
+#define RTC_MONTH_OFFS 8
+#define RTC_YEAR_OFFS 16
+#define KIRKWOOD_YEAR_BASE 2000
+
+int rtc_set(struct rtc_time *tmp)
+{
+ ulong rtc_reg;
+
+ GregorianDay(tmp);
+
+ rtc_reg = (bin2bcd(tmp-tm_sec) RTC_SECONDS_OFFS) |
+ (bin2bcd(tmp-tm_min) RTC_MINUTES_OFFS) |
+ (bin2bcd(tmp-tm_hour) RTC_HOURS_OFFS) |
+ (bin2bcd(tmp-tm_wday) RTC_WDAY_OFFS);
+ writel(rtc_reg, KW_RTC_TIME);
+
+ rtc_reg = (bin2bcd(tmp-tm_mday) RTC_MDAY_OFFS) |
+ (bin2bcd(tmp-tm_mon) RTC_MONTH_OFFS) |
+ (bin2bcd(tmp-tm_year - KIRKWOOD_YEAR_BASE)
+RTC_YEAR_OFFS);
+ writel(rtc_reg, KW_RTC_DATE);
+
+ return 0;
+}
+
+int rtc_get(struct rtc_time *tmp)
+{
+ ulong rtc_time, rtc_date;
+
+ rtc_time = readl(KW_RTC_TIME);
+ rtc_date = readl(KW_RTC_DATE);
+
+ tmp-tm_sec = bcd2bin(rtc_time 0x7f);
+ tmp-tm_min = bcd2bin((rtc_time RTC_MINUTES_OFFS) 0x7f);
+ /* assume 24 hour mode */
+ tmp-tm_hour = bcd2bin((rtc_time RTC_HOURS_OFFS) 0x3f);
+ tmp-tm_mday = bcd2bin(rtc_date 0x3f);
+ tmp-tm_wday = bcd2bin((rtc_time RTC_WDAY_OFFS) 0x7);
+ tmp-tm_mon = bcd2bin((rtc_date RTC_MONTH_OFFS) 0x3f);
+ /* hw counts from year 2000, but tm_year is relative to 0 */
+ tmp-tm_year = bcd2bin((rtc_date RTC_YEAR_OFFS) 0xff)
+ + KIRKWOOD_YEAR_BASE;
+
+ return 0;
+}
+
+void rtc_reset(void)
+{
+ return;
+}
+
+#endif /* CONFIG_CMD_DATE */
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/22] Add generic spl infrastructure
Hi Scott,
On Tuesday 17 May 2011 10:20 PM, Scott Wood wrote:
On Tue, 17 May 2011 12:24:34 +0530
Aneesh Vane...@ti.com wrote:
On Tuesday 17 May 2011 12:02 AM, Scott Wood wrote:
On Sun, 15 May 2011 20:51:24 +0530
Aneesh Vane...@ti.com wrote:
diff --git a/arch/arm/include/asm/global_data.h
b/arch/arm/include/asm/global_data.h
index 2a84d27..2ce020e 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -89,6 +89,11 @@ typedef struct global_data {
#define GD_FLG_DISABLE_CONSOLE 0x00040 /* Disable console (in out)
*/
#define GD_FLG_ENV_READY0x00080 /* Environment imported into
hash table */
+#ifdef CONFIG_PRELOADER
+/* SPL works from internal RAM. gd pointer can be in .data section */
+#define DECLARE_GLOBAL_DATA_PTR extern gd_t *gd
+#else
#define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm
(r8)
+#endif
Is this appropriate for all ARM boards (e.g. those currently using
nand_spl)?
None of the SPL's other than this one seems to be using global data
today. If anybody wants to use it this seems to be the logical option
for me because by definition SPL runs from some kind of RAM so global
data can be placed in the .data section of SPL.
There is nand_spl code, including ARM, that uses gd. E.g. putc() in
board/davinci/da8xxevm/hawkboard_nand_spl.c.
This comment also applies to the other uses of CONFIG_PRELOADER -- are all
of those changes appropriate for the existing nand_spl users?
I would probably revert the change as advised by Wolfgang.
best regards,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 16/22] omap4: calculate EMIF register values
Hi Wolfgang, On Wednesday 18 May 2011 03:24 AM, Wolfgang Denk wrote: Dear Aneesh V, In message4dd2858e.2000...@ti.com you wrote: I had the same concerns too. So, I have provided a CONFIG option - CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS - by which the user can provide the register values, so no computation will be done. Ah, great. Sorry, I have missed this. So, if somebody is concerned about the performance they can just compute the values using this driver and print them out by enabling the debug traces, fill it up in the structs provided for it and enable CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS. That should work. Will this also comment out the respective code, so we don't waste the memory for it? In SPL yes, because I am using -ffunction-sections -fdata-sections along with --gc-sections, but not in U-Boot. I shall take care of this in the next revision. BTW, I was thinking that I should enable -ffunction-sections -fdata-sections in OMAP U-Boot too. What do you think? best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Bitfield macros (was: Re: [PATCH v3 02/10] armv7: add miscellaneous utility macros)
On Mon, May 16, 2011 at 10:27 PM, Wolfgang Denk w...@denx.de wrote: Dear Simon Glass, In message banlktine7bfsyousgxwg0rg3ownbpn_...@mail.gmail.com you wrote: There are a few very primitive macros in setbits and clrbits. I would very much like to see at least: Maybe we can agree to use these existing macros then instead of inventing new ones with the same functionality. The existing macros do not have enough functionality in my view. If we seriously want people to use these then I believe they need to be enhanced to be easier to use and more powerful. - define a field once in a header in an easy format along with any enums which define allowable values if applicable - pack and unpack a value into a field: so set a bitfield to 13, for exampl= e - obtain a mask for a field (i.e. with all bits set) - equivalent of writel and readl for a bitfield (writel in fact being read/modify/write so perhaps a different name) Some of these exist, some don't. Do you know of examples of such more complex definitions in the Linux kernel code? Which complex definitions? I was suggesting adding a more powerful group of bitfield macros to U-Boot. It would be better if they were easier to use rather than more complex. Linux does not have very good bitfield macros in my view. The saving grace is that Linux typically creates such complex views of hardware that the actual SOC register access is a tiny part of the code. For example look at the clock code. All of the SOC functions are mirrored in C structures, with strings and pointers, etc. The ugliness of shifting with readl() and writel() is drowned out in the mountain of code. I happen to believe that Linux should have better bitfield access macro too but I'm not here to talk about Linux :-) U-Boot has quite a bit of hardware initialization code where there is little else but writing to SOC bitfields. I think clrbits and setbits are a start but they are primitive and we can do better. If we do better, people will use the better options. If lots of people use them then we can start requiring that people do. In the end we get a consistent way of accessing SOC registers at the bit level, as we now do at the word level. Any thoughts? I we get something in there I suspect ARM people will use it at least, and that will reduce the number of ways this gets I doubt that. You can see that even the existing macros are unknown to many, and they also do not bother to check around or asdk. It's always so much easier to invent your own new shiny macro that fits your current purpose perfectly. Well speaking for myself I wrote some USB code with the existing macros, which I found after a bit of a search, and keenly felt their shortcomings. So maybe if the built-in macros were just a little more shiny people would use them. And in any case patch review could pick this sort of thing up. done. At present the local bitfield macros are not accessible to even other SOCs, let along other architectures. As this thread shows (and some of the code I have been reviewing recently) there is a demand for something more functional. How is this problem being addressed in Linux? At the very minimum we should chose a compatible implementation. I think it is already compatible, in that we have a lowest-common-denominator solution. I would like to see a more functional option. Best regards, Wolfgang Denk Regards, Simon -- 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 Forty two. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
