Re: [U-Boot] [PATCH] MMC S5P: Fix typo
Dear Dirk Behme, On 16 May 2011 00:39, Dirk Behme wrote: > From: Dirk Behme > > Fix typo resulting in the compilation error > > s5p_mmc.c: In function 's5p_mmc_initialize': > s5p_mmc.c:469: error: 'struct mmc' has no member named 'm_bmax' > > introduced by commit "MMC: make b_max unconditional" > (8feafcc49c0b7a9c541904f95a43dbef2fecc38b) > > Signed-off-by: Dirk Behme > CC: John Rigby > CC: Andy Fleming > > --- > > Found while building 's5p_goni' > > drivers/mmc/s5p_mmc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > applied to u-boot-samsung Thanks Minkyu Kang -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] MX5: clock: Add clock config interface
Hi, Stefano, 2011/5/16 Stefano Babic : > On 05/16/2011 08:04 AM, Jason Liu wrote: >> Hi, Stefano, >> > > Hi Jason, > >> The clock code has been submitted to mail-list for more than one >> month, any comments for it? >> Since you are the imx custodian, you need quick review the patch >> related to imx, right? > > Because the clock patch was part of a patchset where I have already sent > comments to you asking for changing (due to dialog pmic), and the > patchset is not merged as it is in mainline, the patch you mentioned is > not very urgent, because it adds functions not used anymore in code. Of > course, a review is needed and I have already asked to you to give me > more time a couple of days ago. I think the normal process should be if you have comments, you need give it as early as possible. > > Anyway, I will send today my comments on this patch. Thanks, Jason > > 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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8] Add support for Network Space v2 and parents
> -Original Message-
> From: Simon Guinot [mailto:simon.gui...@sequanux.org]
> Sent: Sunday, May 15, 2011 6:02 PM
> To: Prafulla Wadaskar
> Cc: u-boot@lists.denx.de; Simon Guinot
> Subject: [PATCH v8] 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
> ---
> 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.
Hi Simon,
This patch looks okay to me.
I will pull it once u-boot-arm.git get rebased with master for dependency patch
named "netconsole: remove `serverip' check"
Regards..
Prafulla ..
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8] Add support for Network Space v2 and parents
> -Original Message- > From: Simon Guinot [mailto:si...@sequanux.org] > Sent: Sunday, May 15, 2011 7:33 PM > To: Wolfgang Denk > Cc: Simon Guinot; Prafulla Wadaskar; u-boot@lists.denx.de > Subject: Re: [U-Boot] [PATCH v8] Add support for Network Space v2 and > parents > ...snip... > The patch has been sent using git-send-email 1.7.5.1 which seems to > handle differently email content encoding. This time, I was really > hopping to get this patch into the patchwork system :( > > I realize now this patch has been built from my working branch which is > rebased on the top of the u-boot-marvell/master, u-boot-arm/master and > u-boot-blackfin/sf branches... > > A correct patch should have been built only against branch > u-boot-marvell/master (as version 8523 was). Hi Simon I tired to apply your latest patch on u-boot-marvell.git/master but failed to apply cleanly. You need to rebase your development with latest u-boot-marvell.git/master and generate the patch again. > > It is a huge mistake and I truly apologize about that and about the > resulting noise. > > Prafulla, please ignore patches 8522 and 8554. Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: a320: enable tagged list support
From: Po-Yu Chuang Signed-off-by: Po-Yu Chuang --- include/configs/a320evb.h |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/include/configs/a320evb.h b/include/configs/a320evb.h index 0527822..f12977b 100644 --- a/include/configs/a320evb.h +++ b/include/configs/a320evb.h @@ -25,6 +25,12 @@ #include /*--- + * Linux kernel tagged list + */ +#define CONFIG_CMDLINE_TAG +#define CONFIG_SETUP_MEMORY_TAGS + +/*--- * CPU and Board Configuration Options */ #undef CONFIG_USE_IRQ /* we don't need IRQ/FIQ stuff */ -- 1.6.3.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] get free samples
Dear sir or madam, Good news for you, our company open new product this month, LED bulbs. Do you want to get led bulbs (CE certificate approve) with high quality and special price? Come on, hoping you lose no time! By the way, kindly enclosed the specification of Led bulbs. Please contact me without any hesitate if you need more detailed. Looking forward to further contacts upcoming days! Best regards. Jary Foreign Trade Department Shanghai Shengxing Electronics Co.,Ltd. Tel:0086-21-67679507 Fax:0086-21-67679507 Mobile: 13564363811 MSN: pjl...@hotmail.com http://sxlled.gmc.globalmarket.com www.sxlled.com Address: Building 2, No.100, block 651, dong xue Rd., Songjiang District Shanghai China post code 201600 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Issues in U-BOOT for OMAPL137
Please don't top post, it really breaks up the flow of the conversation
when people look at it later on. And please keep the list on CC.
On 13/05/11 06:31, shilpa jadav wrote:
> Hi,
>
>I tried latest U-BOOT release from
> git://git.denx.de/u-boot.git or http://git.denx.de/u-boot.git
>
> I am unable to compile it, i think da830/omapl137 support is not their in
> u-boot. I got the error as mentioned below when i give the command
>
> u-boot# make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-
> da830_omapl137_config
The target you are after is da830evm_config. I know its there because
I'm the board maintainer ;-)
$ grep da830evm boards.cfg
da830evm arm arm926ejs da8xxevm
davincidavinci
da830 is the name fo the omap-l137 which is not an OMAP but a Davinci
device. omap-l137 is its TI marketing name.
Nick.
>
> I get the error as:---
>
> awk '(NF && $1 !~ /^#/) { print $1 ": " $1 "_config; $(MAKE)" }' boards.cfg
>> .boards.depend
> make: *** No rule to make target `da830_omapl137_config'. Stop.
> make: *** [da830_omapl137_config] Error 1
>
> Can you tell the release which is supporting da830/omapl137 with USB
> support.
>
> Thanks,
> Shilpa
>
>
> On Thu, May 12, 2011 at 2:30 PM, Nick Thompson wrote:
>
>> On 11/05/11 10:15, shilpa jadav wrote:
>>> Hi ,
>>> When i am trying to compile u-boot for omapL137 by issuing the following
>>> command
>>> make da830_omapl137_evm_config CROSS_COMPILE=arm-none-linux-gnueabi-
>>>
>>> Our goal is to get USB up on the uboot . We are trying to boot OMAPL137
>> Evm
>>> using USB mass storage device(Pen drive)
>>> I have added the following macros in the /include/configs/da830_evm.h
>>> (followed the instructions from CHANGELOG file)
>>> #define CONFIG_CMD_USB 1
>>> #define CONFIG_USB_STORAGE 1
>>> #define CONFIG_USB_EHCI
>>> #define CONFIG_USB_EHCI_IXP4XX 1
>>> #define CONFIG_EHCI_IS_TDI 1
>>> #define CONFIG_EHCI_DESC_BIG_ENDIAN 1
>>> #define CONFIG_EHCI_MMIO_BIG_ENDIAN 1
>>> #define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 1
>>> #define CONFIG_LEGACY_USB_INIT_SEQ 1
>>>
>>> This is the error i am seeing consistently.
>>>
>>> make[1]: Leaving directory
>>>
>> `/home/dataway/linux_bkup/kalyan/omapl137/DaVinci-PSP-SDK-03.20.00.08/src/u-boot/uboot-03.20.00.08/drivers/usb/musb'
>>> make -C drivers/usb/host/
>>> make[1]: Entering directory
>>>
>> `/home/dataway/linux_bkup/kalyan/omapl137/DaVinci-PSP-SDK-03.20.00.08/src/u-boot/uboot-03.20.00.08/drivers/usb/host'
>>> make[1]: *** No rule to make target `.depend', needed by `libusb_host.a'.
>>> Stop.
>>> make[1]: Leaving directory
>>>
>> `/home/dataway/linux_bkup/kalyan/omapl137/DaVinci-PSP-SDK-03.20.00.08/src/u-boot/uboot-03.20.00.08/drivers/usb/host'
>>> make: *** [drivers/usb/host/libusb_host.a] Error 2
>>>
>>> Please help us solving this issue as this is very critical for our
>>> development
>>
>> This u-boot version (from the DaVinci-PSP) is quite old now (2009.08)
>> and, I believe, its da830/l137 code was never added to the community
>> tree: community support started in Nov 2009 and USB support was added
>> in Dec 2009. As such it can't be supported here.
>>
>> As mentioned da830 EVM is supported by the community tree and I would
>> encourage you to used the latest release from
>> git://git.denx.de/u-boot.git or http://git.denx.de/u-boot.git
>>
>> You can download snapshots, with a browser, from:
>> http://git.denx.de/?p=u-boot.git;a=summary
>>
>> Nick.
>>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] S5P: add set_mmc_clk for external clock control
This patch added set_mmc_clk for external clock control.
c210 didn't support host clock control.
So We need external_clock_control function for c210.
Signed-off-by: Jaehoon Chung
signed-off-by: Minkyu Kang
Signed-off-by: Kyungmin Park
---
arch/arm/cpu/armv7/s5pc1xx/clock.c |5
arch/arm/cpu/armv7/s5pc2xx/clock.c | 32 +++
arch/arm/include/asm/arch-s5pc1xx/clk.h |1 +
arch/arm/include/asm/arch-s5pc1xx/mmc.h |1 +
arch/arm/include/asm/arch-s5pc2xx/clk.h |1 +
arch/arm/include/asm/arch-s5pc2xx/mmc.h |1 +
drivers/mmc/s5p_mmc.c |3 ++
7 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/armv7/s5pc1xx/clock.c
b/arch/arm/cpu/armv7/s5pc1xx/clock.c
index e92647c..1c87e8f 100644
--- a/arch/arm/cpu/armv7/s5pc1xx/clock.c
+++ b/arch/arm/cpu/armv7/s5pc1xx/clock.c
@@ -336,3 +336,8 @@ unsigned long get_uart_clk(int dev_index)
{
return s5pc1xx_get_uart_clk(dev_index);
}
+
+void set_mmc_clk(int dev_index, unsigned int div)
+{
+ /* Do NOTHING */
+}
diff --git a/arch/arm/cpu/armv7/s5pc2xx/clock.c
b/arch/arm/cpu/armv7/s5pc2xx/clock.c
index 450a630..624de62 100644
--- a/arch/arm/cpu/armv7/s5pc2xx/clock.c
+++ b/arch/arm/cpu/armv7/s5pc2xx/clock.c
@@ -199,6 +199,33 @@ static unsigned long s5pc210_get_uart_clk(int dev_index)
return uclk;
}
+/* s5pc210: set the mmc clock */
+static void s5pc210_set_mmc_clk(int dev_index, unsigned int div)
+{
+ struct s5pc210_clock *clk =
+ (struct s5pc210_clock *)samsung_get_base_clock();
+ unsigned int addr;
+ unsigned int val;
+
+ /*
+* CLK_DIV_FSYS1
+* MMC0_PRE_RATIO [15:8], MMC1_PRE_RATIO [31:24]
+* CLK_DIV_FSYS2
+* MMC2_PRE_RATIO [15:8], MMC3_PRE_RATIO [31:24]
+*/
+ if (dev_index < 2) {
+ addr = (unsigned int)&clk->div_fsys1;
+ } else {
+ addr = (unsigned int)&clk->div_fsys2;
+ dev_index -= 2;
+ }
+
+ val = readl(addr);
+ val &= ~(0xff << ((dev_index << 4) + 8));
+ val |= (div & 0xff) << ((dev_index << 4) + 8);
+ writel(val, addr);
+}
+
unsigned long get_pll_clk(int pllreg)
{
return s5pc210_get_pll_clk(pllreg);
@@ -218,3 +245,8 @@ unsigned long get_uart_clk(int dev_index)
{
return s5pc210_get_uart_clk(dev_index);
}
+
+void set_mmc_clk(int dev_index, unsigned int div)
+{
+ s5pc210_set_mmc_clk(dev_index, div);
+}
diff --git a/arch/arm/include/asm/arch-s5pc1xx/clk.h
b/arch/arm/include/asm/arch-s5pc1xx/clk.h
index 4c389c1..692dfe0 100644
--- a/arch/arm/include/asm/arch-s5pc1xx/clk.h
+++ b/arch/arm/include/asm/arch-s5pc1xx/clk.h
@@ -33,5 +33,6 @@ unsigned long get_pll_clk(int pllreg);
unsigned long get_arm_clk(void);
unsigned long get_pwm_clk(void);
unsigned long get_uart_clk(int dev_index);
+void set_mmc_clk(int dev_index, unsigned int div);
#endif
diff --git a/arch/arm/include/asm/arch-s5pc1xx/mmc.h
b/arch/arm/include/asm/arch-s5pc1xx/mmc.h
index d458d3b..adef4ee 100644
--- a/arch/arm/include/asm/arch-s5pc1xx/mmc.h
+++ b/arch/arm/include/asm/arch-s5pc1xx/mmc.h
@@ -64,6 +64,7 @@ struct mmc_host {
struct s5p_mmc *reg;
unsigned int version; /* SDHCI spec. version */
unsigned int clock; /* Current clock (MHz) */
+ int dev_index;
};
int s5p_mmc_init(int dev_index, int bus_width);
diff --git a/arch/arm/include/asm/arch-s5pc2xx/clk.h
b/arch/arm/include/asm/arch-s5pc2xx/clk.h
index 5a1cdf1..ff0f641 100644
--- a/arch/arm/include/asm/arch-s5pc2xx/clk.h
+++ b/arch/arm/include/asm/arch-s5pc2xx/clk.h
@@ -32,5 +32,6 @@ unsigned long get_pll_clk(int pllreg);
unsigned long get_arm_clk(void);
unsigned long get_pwm_clk(void);
unsigned long get_uart_clk(int dev_index);
+void set_mmc_clk(int dev_index, unsigned int div);
#endif
diff --git a/arch/arm/include/asm/arch-s5pc2xx/mmc.h
b/arch/arm/include/asm/arch-s5pc2xx/mmc.h
index 04827ca..30f82b8 100644
--- a/arch/arm/include/asm/arch-s5pc2xx/mmc.h
+++ b/arch/arm/include/asm/arch-s5pc2xx/mmc.h
@@ -64,6 +64,7 @@ struct mmc_host {
struct s5p_mmc *reg;
unsigned int version; /* SDHCI spec. version */
unsigned int clock; /* Current clock (MHz) */
+ int dev_index;
};
int s5p_mmc_init(int dev_index, int bus_width);
diff --git a/drivers/mmc/s5p_mmc.c b/drivers/mmc/s5p_mmc.c
index 86447e0..c05ee9d 100644
--- a/drivers/mmc/s5p_mmc.c
+++ b/drivers/mmc/s5p_mmc.c
@@ -291,6 +291,8 @@ static void mmc_change_clock(struct mmc_host *host, uint
clock)
clk = (div << 8) | (1 << 0);
writew(clk, &host->reg->clkcon);
+ set_mmc_clk(host->dev_index, div);
+
/* Wait max 10 ms */
timeout = 10;
while (!(readw(&host->reg->clkcon) & (1 << 1))) {
@@ -464,6 +466,7 @@ static int s5p_mmc_initialize(int dev_index, int bus_width)
mmc->f_min = 40;
mmc->f_max = 5200;
+ mmc_host[dev_index].dev_index = dev_in
Re: [U-Boot] [PATCH V7 1/3] MX5: clock: Add clock config interface
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_ROOT1
> +#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.
> +#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 ?
> +
> +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.
Are there other use case for this array, that makes sense to define and
maybe to extend it ?
Can you add a reference to the manual explaining where these values are
coming from ?
> +
> +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.
> +#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 ?
> +
> /*
> * 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.
Is it worth to export the other getter functions, too (get_axi_a/b_clk,
get_ahb_clk) ?
> /*
> + * Clock config code start here
> + */
> +
> +/* precondition: m>0 and n>0. 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.
Add a comment to explain you are computing the greatest common divisor.
Why do you not have taken the implementation from linux ? It uses the
Euclid method (using a reminder) and it takes less iterations to get the
result as this implementation.
> +
> +/*
> + * This is to calculate various parameters based on reference clock and
> + * targeted clock based on the equation:
> + * t_clk = 2*ref_freq*(mfi + mfn/(mfd+1))/(pd+1)
Where does this formula come from ?
> + * This calculation is based on a fixed MFD value for simplicity.
> + *
> + * @param ref reference clock freq in Hz
> + * @param targettargeted clock in Hz
> + * @param pll pll_param structure.
> + *
> + * @return 0 if successful; non-zero otherwise.
> + */
> +static int calc_pll_params(u32 ref, u32 target, struct pll_param *pll)
> +{
> + u64 pd, mfi = 1, mfn, mfd, t1;
> + u32 n_target = target;
> + u32 n_ref = ref, i;
In your code you pass always a struct pll_param *pll previously filled
with zeroes. Yo
Re: [U-Boot] [PATCH v2] MX53: Handle silicon revision 2.1 case
On 04/26/2011 10:50 PM, Fabio Estevam wrote: > Signed-off-by: Fabio Estevam > --- > Changes since v1: > - Make the revision detection logic simpler as suggested by Stefano > > arch/arm/cpu/armv7/mx5/soc.c | 10 +++--- > 1 files changed, 3 insertions(+), 7 deletions(-) > Applied to u-boot-imx, 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
[U-Boot] [u-boot-arm] E-mail provider issues
Hi all, my e-mail provider experienced issues which made me unable to access my e-mail for the last few days. I have just now recovered access to my mail, and am now rewinding my backlog, first going through pull requests, then bugfix submissions, then non-bugfix resubmissions, then the rest. Sorry for the inconvenience. Amicalement, -- Albert. ___ 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 Aneesh,
I recently started to work on a similar topic: omap3 (devkit8000) nand_spl
support. So I'am really interested in your OMAP4/common work here ;)
In this patch comment you say its common for OMAP3/4 but in
preloader_console_init() is a call to omap4_rev_string()):
> printf("Texas Instruments %s\n", omap4_rev_string());
Regards
Simon
2011/5/15 Aneesh V
> Add the basic spl framework and linker script common for OMAP3/4
> platforms.
>
> Signed-off-by: Aneesh V
> ---
> spl/board/ti/spl-omap.c | 47 ++
> spl/board/ti/spl-omap.lds | 62
> +
> 2 files changed, 109 insertions(+), 0 deletions(-)
> create mode 100644 spl/board/ti/spl-omap.c
> create mode 100644 spl/board/ti/spl-omap.lds
>
> diff --git a/spl/board/ti/spl-omap.c b/spl/board/ti/spl-omap.c
> new file mode 100644
> index 000..0e08f4f
> --- /dev/null
> +++ b/spl/board/ti/spl-omap.c
> @@ -0,0 +1,47 @@
> +/*
> + *
> + * Clock initialization for OMAP4
> + *
> + * (C) Copyright 2010
> + * Texas Instruments,
> + *
> + * Aneesh V
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +#include
> +#include
> +#include
> +#include
> +
> +/* Define global data structure pointer to it*/
> +gd_t gdata __attribute__ ((section(".data")));
> +bd_t bdata __attribute__ ((section(".data")));
> +gd_t *gd = &gdata;
> +
> +void board_init_f(ulong dummy)
> +{
> + relocate_code(CONFIG_SYS_SPL_STACK, &gdata,
> CONFIG_SYS_SPL_TEXT_BASE);
> +}
> +
> +void board_init_r(gd_t *id, ulong dummy)
> +{
> + for (;;)
> + ;
> +}
> diff --git a/spl/board/ti/spl-omap.lds b/spl/board/ti/spl-omap.lds
> new file mode 100644
> index 000..674ef05
> --- /dev/null
> +++ b/spl/board/ti/spl-omap.lds
> @@ -0,0 +1,62 @@
> +/*
> + * (C) Copyright 2002
> + * Gary Jennejohn, DENX Software Engineering,
> + *
> + * (C) Copyright 2010
> + * Texas Instruments,
> + * Aneesh V
> + *
> + * 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
> + */
> +
> +MEMORY { .sram : ORIGIN = CONFIG_SYS_SPL_TEXT_BASE,\
> +LENGTH = CONFIG_SYS_SPL_MAX_SIZE }
> +MEMORY { .sdram : ORIGIN = CONFIG_SYS_SPL_BSS_START_ADDR, \
> + LENGTH = CONFIG_SYS_SPL_BSS_MAX_SIZE }
> +
> +OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
> +OUTPUT_ARCH(arm)
> +ENTRY(_start)
> +SECTIONS
> +{
> + .text :
> + {
> + __start = .;
> + start.o (.text)
> + *(.text*)
> + } >.sram
> +
> + . = ALIGN(4);
> + .rodata : { *(SORT_BY_ALIGNMENT(.rodata*)) } >.sram
> +
> + . = ALIGN(4);
> + .data : { *(SORT_BY_ALIGNMENT(.data*)) } >.sram
> + . = ALIGN(4);
> + __image_copy_end = .;
> + _end = .;
> +
> + .bss :
> + {
> + . = ALIGN(4);
> + __bss_start = .;
> + *(.bss*)
> + . = ALIGN(4);
> + __bss_end__ = .;
> + } >.sdram
> +}
> --
> 1.7.0.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] MX31: Make get_reset_cause() static
Signed-off-by: Fabio Estevam
Signed-off-by: Stefano Babic
---
Changes since V1:
- as get_cpu_rev is exported, only get_reset_cause
is set to static.
arch/arm/cpu/arm1136/mx31/generic.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/cpu/arm1136/mx31/generic.c
b/arch/arm/cpu/arm1136/mx31/generic.c
index fccd2cd..fb01013 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 =
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MX53: Remove CONFIG_SYS_BOOTMAPSZ from mx53 config files.
On 05/16/2011 12:58 AM, Fabio Estevam wrote: > commit ed59e58 (Remove device tree booting dependency on > CONFIG_SYS_BOOTMAPSZ) made the > definition of CONFIG_SYS_BOOTMAPSZ unnecessary. > > Signed-off-by: Fabio Estevam > > #define CONFIG_OF_LIBFDT > -#define CONFIG_SYS_BOOTMAPSZ 0x80 We have already discussed about it, I think I can safely apply it as fix. 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] Add _end for the end of u-boot image for SMDK6400
Dear Zhong Hongbo, On 2 May 2011 15:28, Zhong Hongbo wrote: > On 05/02/2011 02:49 AM, Wolfgang Denk wrote: >> Dear seedshope, >> >> In message <1304268966-25640-1-git-send-email-bocui...@gmail.com> you wrote: >>> From: seedshope >>> >>> Since we rename _end to __bss_end__, But we need add _end symbol for >>> the end of u-boot image. >>> >>> Signed-off-by: Zhong Hongbo >> applied to u-boot-samsung Thanks Minkyu Kang -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/22] mkimage: Add OMAP boot image support
Hi Wolfgang,
On Monday 16 May 2011 12:36 AM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<1305472900-4004-2-git-send-email-ane...@ti.com> you wrote:
>> From: John Rigby
>>
>> Signed-off-by: John Rigby
>> ---
>> common/image.c|1 +
>> include/image.h |1 +
>> tools/Makefile|2 +
>> tools/mkimage.c |2 +
>> tools/mkimage.h |1 +
>> tools/omapimage.c | 229
>> +
>> tools/omapimage.h | 50
>> 7 files changed, 286 insertions(+), 0 deletions(-)
>> create mode 100644 tools/omapimage.c
>> create mode 100644 tools/omapimage.h
>>
>> diff --git a/common/image.c b/common/image.c
>> index e542a57..7f6fe1c 100644
>> --- a/common/image.c
>> +++ b/common/image.c
>> @@ -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?
>
>> diff --git a/tools/Makefile b/tools/Makefile
>> index 623f908..a1c4ed7 100644
>> --- a/tools/Makefile
>> +++ b/tools/Makefile
>> @@ -84,6 +84,7 @@ OBJ_FILES-$(CONFIG_CMD_LOADS) += img2srec.o
>> OBJ_FILES-$(CONFIG_INCA_IP) += inca-swap-bytes.o
>> NOPED_OBJ_FILES-y += kwbimage.o
>> NOPED_OBJ_FILES-y += imximage.o
>> +NOPED_OBJ_FILES-y += omapimage.o
>> NOPED_OBJ_FILES-y += mkimage.o
>> OBJ_FILES-$(CONFIG_NETCONSOLE) += ncb.o
>> NOPED_OBJ_FILES-y += os_support.o
>> @@ -180,6 +181,7 @@ $(obj)mkimage$(SFX): $(obj)crc32.o \
>> $(obj)fit_image.o \
>> $(obj)image.o \
>> $(obj)imximage.o \
>> +$(obj)omapimage.o \
>> $(obj)kwbimage.o \
>> $(obj)md5.o \
>> $(obj)mkimage.o \
>
> Please keep lists sorted.
Ok.
>
>> --- /dev/null
>> +++ b/tools/omapimage.c
>> @@ -0,0 +1,229 @@
...
>> +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.
Just curious, what are the issues caused by "__packed__"?
>
> 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 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" ...
> -mike
This is not my code. But I don't think it was intentional. The
following didn't seem to cause any trouble. I shall add this fix in the
next revision if this looks ok.
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;
>
>
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MX53: Remove CONFIG_SYS_BOOTMAPSZ from mx53 config files.
Hi, Stefano, 2011/5/16 Stefano Babic : > On 05/16/2011 12:58 AM, Fabio Estevam wrote: >> commit ed59e58 (Remove device tree booting dependency on >> CONFIG_SYS_BOOTMAPSZ) made the >> definition of CONFIG_SYS_BOOTMAPSZ unnecessary. >> >> Signed-off-by: Fabio Estevam >> >> #define CONFIG_OF_LIBFDT >> -#define CONFIG_SYS_BOOTMAPSZ 0x80 > > We have already discussed about it, I think I can safely apply it as fix. When I did mx53loco board and DT support for linaro, grant's patch is not there. But now, we can remove it. Acked-by: Jason Liu for mx53loco part. Jason > > 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] S5PC2XX: Support the cpu revision
S5PC210 SoC have two cpu revisions, and have some difference.
So, support the cpu revision for each revision.
Signed-off-by: Minkyu Kang
Signed-off-by: Kyungmin Park
---
arch/arm/cpu/armv7/s5p-common/cpu_info.c |2 ++
arch/arm/include/asm/arch-s5pc2xx/cpu.h | 12 +++-
2 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/arch/arm/cpu/armv7/s5p-common/cpu_info.c
b/arch/arm/cpu/armv7/s5p-common/cpu_info.c
index c8a543a..527f32d 100644
--- a/arch/arm/cpu/armv7/s5p-common/cpu_info.c
+++ b/arch/arm/cpu/armv7/s5p-common/cpu_info.c
@@ -26,6 +26,8 @@
/* Default is s5pc100 */
unsigned int s5p_cpu_id = 0xC100;
+/* Default is EVT1 */
+unsigned int s5p_cpu_rev = 1;
#ifdef CONFIG_ARCH_CPU_INIT
int arch_cpu_init(void)
diff --git a/arch/arm/include/asm/arch-s5pc2xx/cpu.h
b/arch/arm/include/asm/arch-s5pc2xx/cpu.h
index d56ee80..f9015c7 100644
--- a/arch/arm/include/asm/arch-s5pc2xx/cpu.h
+++ b/arch/arm/include/asm/arch-s5pc2xx/cpu.h
@@ -51,6 +51,12 @@
#include
/* CPU detection macros */
extern unsigned int s5p_cpu_id;
+extern unsigned int s5p_cpu_rev;
+
+static inline int s5p_get_cpu_rev(void)
+{
+ return s5p_cpu_rev;
+}
static inline void s5p_set_cpu_id(void)
{
@@ -61,8 +67,12 @@ static inline void s5p_set_cpu_id(void)
* 0xC200: S5PC210 EVT0
* 0xC210: S5PC210 EVT1
*/
- if (s5p_cpu_id == 0xC200)
+ if (s5p_cpu_id == 0xC200) {
s5p_cpu_id |= 0x10;
+ s5p_cpu_rev = 0;
+ } else if (s5p_cpu_id == 0xC210) {
+ s5p_cpu_rev = 1;
+ }
}
#define IS_SAMSUNG_TYPE(type, id) \
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] nand_spl: nand_boot.c: Remove last CONFIG_SYS_NAND_READ_DELAY occurance
Remove the last CONFIG_SYS_NAND_READ_DELAY occurance from nand_boot.c. I missed this one in patch a9c847cb [nand_spl: nand_boot.c: Remove CONFIG_SYS_NAND_READ_DELAY]. This fixes a compile breakage on kilauea_nand for example. Signed-off-by: Stefan Roese Cc: Scott Wood --- nand_spl/nand_boot.c |7 ++- 1 files changed, 2 insertions(+), 5 deletions(-) diff --git a/nand_spl/nand_boot.c b/nand_spl/nand_boot.c index 00df2a0..9545a9a 100644 --- a/nand_spl/nand_boot.c +++ b/nand_spl/nand_boot.c @@ -33,11 +33,8 @@ static int nand_command(struct mtd_info *mtd, int block, int page, int offs, u8 struct nand_chip *this = mtd->priv; int page_addr = page + block * CONFIG_SYS_NAND_PAGE_COUNT; - if (this->dev_ready) - while (!this->dev_ready(mtd)) - ; - else - CONFIG_SYS_NAND_READ_DELAY; + while (!this->dev_ready(mtd)) + ; /* Begin command latch cycle */ this->cmd_ctrl(mtd, cmd, NAND_CTRL_CLE | NAND_CTRL_CHANGE); -- 1.7.5.1 ___ 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
Dear Graeme Russ, In message you wrote: > > > time-stamping console output is not restricted to the serial port. It > > works as well with tty over USB, or netconsole, or even netconsole > > over USB. > > My point is, if the device reboots in the field, you cannot recover the > boot timing analysis as once it is streamed out it is gone forever Agreed. But so far I have never seen a need to perform boot time measurements on devices in the field without access to the console (serial, or usb or netconsole). In all my experience, such behaviour is pretty much deterministic and can be done in the lab, before shipping systems. The only way where I can imagine that the boot ime depends on the actual user environment is when booting from the network, but then again you can also run a network sniffer to measure this impact. I really wonder what the benefit of adding such code to U-Boot is. 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 Genitiv ins Wasser, weil's Dativ ist! ___ 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 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. Amicalement, -- Albert. ___ 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
Dear Graeme Russ,
In message you wrote:
>
> > As we can trivially use regular expressions, the effort to implement a
> > "timing parser" can be ignored. And it is independet of what sort of
> > boot device we are using.
>
> Fine if your running Linux - What if the only tool tyou have is
> Hyperterminal?
AFAICT tcl is also available under Windoze...
> I've seen many instances where everything works well 'in the lab' and as
> soon as you put it in the field, things go pear shaped. Often you need to
We all have seen this, and we all appreciate any tool that is
available then.
> > But you need storage for the timing events, and you don't have this
> > before relocation. So you miss some really interesting parts of the
> > boot procedure.
>
> Maybe a limited amount can be stored in global data by testing the
> relocated flag
I don't think so.
> > OK, not needing a console port during boot is indeed an advantage. It
> > comes at the cost of needing log space, which is not available before
> > relocation, so we miss some interesting parts of the boot procedure.
>
> Can use global data for a limited number of pre-relocation records. And I
> don't think pre-location is where a lot of problems will occur anyway
> unless you have flaky/misconfigured hardware
I smell a bloated implementation which works on one specific system or
two. This doesn't sound attractive to me.
> >> 5. It allows timing of things which don't result in serial output.
> >
> > But to do so, you need to insert trace points. With the same effort
> > we can insert a printf().
>
> Which increase code/data size - If you don't care about having pretty
> messages in you boot profile (you can always look up source or
> documentation) the size impact per 'mark' is less
What makes you think a call to printf()/puts()/putc() would increase
the code size worse than a call to the trace function? If I don't
care about pretty messages (and use silent console otherwise) my
serial console based messages consist of a plain "putc('a')" or
similar - certainly not more overhead than the call to the trace
function.
> I think my refined suggestion has a far smaller impact than first thought
> and you can get pre-relocation information if you are willing to use
> some global data storage
It's not about willing or not. If willing or wanting would help, we
had an ideal world. But in reality, we have a world full of
restrictions.
GD is definitely not buffer space for arbitrary amounts of log data.
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 little suffering is good for the soul.
-- Kirk, "The Corbomite Maneuver", stardate 1514.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: a320: enable tagged list support
Dear Po-Yu Chuang, In message <1305531660-1595-1-git-send-email-ratbert.chu...@gmail.com> you wrote: > From: Po-Yu Chuang > > > Signed-off-by: Po-Yu Chuang > --- > include/configs/a320evb.h |6 ++ > 1 files changed, 6 insertions(+), 0 deletions(-) > > diff --git a/include/configs/a320evb.h b/include/configs/a320evb.h > index 0527822..f12977b 100644 > --- a/include/configs/a320evb.h > +++ b/include/configs/a320evb.h > @@ -25,6 +25,12 @@ > #include > > /*--- > + * Linux kernel tagged list > + */ > +#define CONFIG_CMDLINE_TAG > +#define CONFIG_SETUP_MEMORY_TAGS > + > +/*--- Please also fix the incorrect multiline comment style while modifying this code. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Memories of you remind me of you. - Karl Lehenbauer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/22] mkimage: Add OMAP boot image support
Dear Aneesh V,
In message <4dd0f98a.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.
> Just curious, what are the issues caused by "__packed__"?
For example, 32 bit data may be accessed in 4 8-bit operations which
may be fatal when accessing device registers.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
God may be subtle, but He isn't plain mean. - Albert Einstein
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2] bootp: add ntpserver option to bootp request
Hello. On 16-05-2011 6:24, Chris Packham wrote: > From: Luuk Paulussen > Signed-off-by: Luuk Paulussen > Acked-by: Chris Packham > Cc: Ben Warren [...] > diff --git a/net/bootp.c b/net/bootp.c > index 4db63cb..18c743e 100644 > --- a/net/bootp.c > +++ b/net/bootp.c > @@ -228,6 +228,11 @@ static void BootpVendorFieldProcess (u8 * ext) > NetOurNISDomain[size] = 0; > } > break; > +#if defined(CONFIG_CMD_SNTP)&& defined(CONFIG_BOOTP_NTPSERVER) > + case 42:/* NTP server IP */ > + NetCopyIP (&NetNtpServerIP, (IPaddr_t *) (ext + 2)); There should be no space between function name and (. You're now supposed to run your patch thru scripts/checkpatch.pl (from Linux source tree). > + break; > +#endif > /* Application layer fields */ > case 43:/* Vendor specific info - Not yet supported > */ > /* > @@ -538,6 +548,11 @@ static int BootpExtended (u8 * e) > *e++ = 32; > e += 32; > #endif > +#if defined(CONFIG_BOOTP_NTPSERVER) > + *e++ = 42; Too many spaces... > + *e++ = 4; > + e += 4; > +#endif WBR, Sergei ___ 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 12:39 AM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<1305472900-4004-3-git-send-email-ane...@ti.com> you wrote:
>> Signed-off-by: Aneesh V
>> ---
>> V2:
>> * Added a revision string in addition to the revision number
>>Helps in printing out the OMAP revision at bootup
> ...
>> +const char *omap4_rev_string(void)
>> +{
>> +const char *omap4_rev = NULL;
>> +switch (omap4_revision()) {
>> +case OMAP4430_ES1_0:
>> +omap4_rev = "OMAP4430 ES1.0";
>> +break;
>> +case OMAP4430_ES2_0:
>> +omap4_rev = "OMAP4430 ES2.0";
>> +break;
>> +case OMAP4430_ES2_1:
>> +omap4_rev = "OMAP4430 ES2.1";
>> +break;
>> +case OMAP4430_ES2_2:
>> +omap4_rev = "OMAP4430 ES2.2";
>> +break;
>
> Such code does not really scale well. Can this not be improved? I
> think we just had similar discussions for i.MX5x - please check what
> the result of these was.
Are you referring to this one?
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/98522
If so, it may not work for us:
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().
2. In our case we do not have a 1:1 mapping between the
revisions(monotonically increasing numbers) we need in the U-Boot and
the value obtained from the ID_CODE register. So, a translation is
inevitable.
3. We need increasing numbers for subsequent revisions so that we can
have something like:
if (omap4_revision() >= OMAP4430_ES2_0)
do_something();
>
>> +default:
>> +omap4_rev = "OMAP4 - Unknown Rev";
>> +break;
>
> Please also output what the unknown revision was - this saves at least
> one debug round if you ever run into this case.
This function should be in sync with omap4_revision() function(unless
there is a bug). So, the rev will be OMAP4430_SILICON_ID_INVALID in
that case.
I shall print out the ARM revision and OMAP revision registers when I
get into OMAP4430_SILICON_ID_INVALID situation in omap4_revision()
>
>> +}
>> diff --git a/arch/arm/include/asm/arch-omap4/omap4.h
>> b/arch/arm/include/asm/arch-omap4/omap4.h
>> index a30bb33..1f88732 100644
>> --- a/arch/arm/include/asm/arch-omap4/omap4.h
>> +++ b/arch/arm/include/asm/arch-omap4/omap4.h
>> @@ -51,6 +51,11 @@
>> #define CONTROL_PADCONF_CORE (OMAP44XX_L4_CORE_BASE + 0x10)
>> #define CONTROL_PADCONF_WKUP (OMAP44XX_L4_CORE_BASE + 0x31E000)
>>
>> +/* CONTROL_ID_CODE */
>> +#define CONTROL_ID_CODE (CTRL_BASE + 0x204)
>
> C struct?
Ok. I shall convert defines to C structs globally for register
addressing.
>
>
> 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 04/22] omap4: save parameters passed by ROM code to SPL
Hi Wolfgang, On Monday 16 May 2011 12:44 AM, Wolfgang Denk wrote: > Dear Aneesh V, > > In message<1305472900-4004-5-git-send-email-ane...@ti.com> you wrote: >> Save boot device information passed by OMAP4 rom code >> >> ROM code in OMAP4 passes information such as the media from >> which it picked up the first boot image(SPL in our case), >> the mode(raw mode/FAT mode) etc. >> >> Save this information in SPL so that we can use the same media >> and mode to bootload u-boot. >> >> Signed-off-by: Aneesh V > ... >> +/* 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. 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 Monday 16 May 2011 01:18 AM, Wolfgang Denk wrote: > Dear Aneesh V, > > In message<1305472900-4004-7-git-send-email-ane...@ti.com> you wrote: >> Define a new type of SPL that is not tied to any particular media. >> - Create a top level directory 'spl' that has a structure similar >>to the existing 'nand_spl' >> - Make necessary changes to top-level Makefile to build such an spl >> >> Rationale for this approach: >> - There may be SPLs(like the OMAP x-loader) that support booting from >>multiple media. >> - Also, there is no harm in keeping SPLs specific to a particular media >>also under this directory. In fact it makes sense to merge all the >>different spl directories into this one. > > Thanks a lot for addressing this. This is an area that has long been > on my mind, and I'm really happy to see someone starting to work on > this. > > In addition to booting from different types of media, I see at least > two more topics that scould and should addressed by this work: > > - Get rid of xloader. I cannot see any good reasons why we need it, >i. e. which functions if performs that cannot be as well (and >eventually even more efficiently) be performed in the U-Boot SPL >code. Indeed, SPL is seen as a replacement for x-loader. > > - Become more flexible regarding the kind of second stage payload. >It is definitely very powerful and convenient during development to >be able to load U-Boot with all it's capabilities as payload of the >SPL, but then, except for image size and parameter passing, there is >little or no difference to loading a Linux kernel directly instead >(and actually this is what most of the super-fast booting approaches >do). If done right, we may even have the flexibility to do both, >just by providing different images as payload. > How do we handle the differences you just mentioned, namely the size, parameter passing etc. Maybe, we should have special handling for each and define config flags like CONFIG_SPL_PAYLOAD_UBOOT, CONFIG_SPL_PAYLOAD_LINUX_KERNEL etc? > >> Signed-off-by: Aneesh V >> --- >> This patch generates 1 checkpatch warning due to declaration >> of DECLARE_GLOBAL_DATA_PTR. This is un-avoidable >> --- >> Makefile | 24 >> arch/arm/include/asm/global_data.h |5 + >> 2 files changed, 29 insertions(+), 0 deletions(-) > > Here the commit message and the implementation do not agree. You > wrote "Create a top level directory 'spl'" - but I don't see any of > that here? In this patch, I just created the makefile infrastructure that expects this directory structure. The files are created later in an OMAP specific patch. I think I should have used something like "define a directory structure" instead of "create". > > I think this should be split into a separate patch series, and care > should be taken that commit messages and implementaiton match. Ok. > > 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 3/3] arm: at91: ether: Prepare for mach-types.h changes
ping!
It has been two weeks...
On 05/02/11 15:49, Igor Grinberg wrote:
> at91 ethernet module used machine_is_cbs337() macro for board specific
> Linux compatibility issue.
> Remove this, as no such board exist in current U-Boot tree.
>
> Signed-off-by: Igor Grinberg
> ---
> arch/arm/cpu/arm920t/at91rm9200/ether.c | 18 +++---
> 1 files changed, 3 insertions(+), 15 deletions(-)
>
> diff --git a/arch/arm/cpu/arm920t/at91rm9200/ether.c
> b/arch/arm/cpu/arm920t/at91rm9200/ether.c
> index e1cdeba..2015e13 100644
> --- a/arch/arm/cpu/arm920t/at91rm9200/ether.c
> +++ b/arch/arm/cpu/arm920t/at91rm9200/ether.c
> @@ -195,21 +195,9 @@ int eth_init (bd_t * bd)
>
> eth_getenv_enetaddr("ethaddr", enetaddr);
>
> - /* The CSB337 originally used a version of the MicroMonitor bootloader
> - * which saved Ethernet addresses in the "wrong" order. Operating
> - * systems (like Linux) know this, and apply a workaround. Replicate
> - * that MicroMonitor behavior so we avoid needing to make such OS code
> - * care about which bootloader was used.
> - */
> - if (machine_is_csb337()) {
> - p_mac->EMAC_SA2H = (enetaddr[0] << 8) | (enetaddr[1]);
> - p_mac->EMAC_SA2L = (enetaddr[2] << 24) | (enetaddr[3] << 16)
> - | (enetaddr[4] << 8) | (enetaddr[5]);
> - } else {
> - p_mac->EMAC_SA2L = (enetaddr[3] << 24) | (enetaddr[2] << 16)
> - | (enetaddr[1] << 8) | (enetaddr[0]);
> - p_mac->EMAC_SA2H = (enetaddr[5] << 8) | (enetaddr[4]);
> - }
> + p_mac->EMAC_SA2L = (enetaddr[3] << 24) | (enetaddr[2] << 16)
> + | (enetaddr[1] << 8) | (enetaddr[0]);
> + p_mac->EMAC_SA2H = (enetaddr[5] << 8) | (enetaddr[4]);
>
> p_mac->EMAC_RBQP = (long) (&rbfdt[0]);
> p_mac->EMAC_RSR &= ~(AT91C_EMAC_RSR_OVR | AT91C_EMAC_REC |
> AT91C_EMAC_BNA);
--
Regards,
Igor.
___
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 01:22 AM, Wolfgang Denk wrote: > Dear Aneesh V, > > In message<1305472900-4004-9-git-send-email-ane...@ti.com> you wrote: >> Add the basic spl framework and linker script common for OMAP3/4 >> platforms. >> >> Signed-off-by: Aneesh V >> --- >> spl/board/ti/spl-omap.c | 47 ++ >> spl/board/ti/spl-omap.lds | 62 >> + >> 2 files changed, 109 insertions(+), 0 deletions(-) >> create mode 100644 spl/board/ti/spl-omap.c >> create mode 100644 spl/board/ti/spl-omap.lds > > 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/// . Let spl/board///Makefile decide what it wants to build. I mean something like this(similar changes for ONENAND): +.PHONEY : SPL +SPL:$(TIMESTAMP_FILE) $(VERSION_FILE) depend tools + $(MAKE) -C spl/board/$(BOARDDIR) all + +ifeq ($(CONFIG_SPL),y) +ALL += SPL +endif + __OBJS := $(subst $(obj),,$(OBJS)) __LIBS := $(subst $(obj),,$(LIBS)) $(subst $(obj),,$(LIBBOARD)) @@ -401,11 +409,8 @@ $(LDSCRIPT): depend $(obj)u-boot.lds: $(LDSCRIPT) $(CPP) $(CPPFLAGS) $(LDPPFLAGS) -ansi -D__ASSEMBLY__ -P - <$^ >$@ -nand_spl: $(TIMESTAMP_FILE) $(VERSION_FILE) depend - $(MAKE) -C nand_spl/board/$(BOARDDIR) all - -$(obj)u-boot-nand.bin: nand_spl $(obj)u-boot.bin - cat $(obj)nand_spl/u-boot-spl-16k.bin $(obj)u-boot.bin > $(obj)u-boot-nand.bin +$(obj)u-boot-nand.bin: SPL $(obj)u-boot.bin + cat $(obj)spl/u-boot-spl-16k.bin $(obj)u-boot.bin > $(obj)u-boot-nand.bin > > 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 08/22] omap: add spl support
Hi Wolfgang,
On Monday 16 May 2011 01:23 AM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<1305472900-4004-9-git-send-email-ane...@ti.com> you wrote:
>> Add the basic spl framework and linker script common for OMAP3/4
>> platforms.
>>
>> Signed-off-by: Aneesh V
> ...
>> +void board_init_r(gd_t *id, ulong dummy)
>> +{
>> +for (;;)
>> +;
>> +}
>
> Also, this cannot be right.
I added the features one by one in the subsequent patches and removed
that loop. Maybe I should squash some patches here too.
>
> 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 0/4] Accurate boot time measurement
> -Original Message- > From: u-boot-boun...@lists.denx.de > [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Graeme Russ > Sent: Monday, May 16, 2011 11:54 AM > To: Wolfgang Denk > Cc: U-Boot Mailing List; Simon Schwarz > Subject: Re: [U-Boot] [PATCH 0/4] Accurate boot time measurement > > On Mon, May 16, 2011 at 3:48 PM, Wolfgang Denk wrote: > > Dear Simon Glass, > > [snip]...[snip] > > Well, the "timing parser", as you callit, can be written in 10 lines > > or less of your scripting language of choice. See for example here > > for a solution in expect/tcl: ftp://ftp.denx.de/pub/tools/time_log > > We've been using this for about 10 years by now (see for > example this > > 7 year old boot time analysis: > > http://www.denx.de/wiki/DULG/AN2004_11_BootTimeOptimization). > > > > As we can trivially use regular expressions, the effort to > implement a > > "timing parser" can be ignored. And it is independet of what sort of > > boot device we are using. > > > > Fine if your running Linux - What if the only tool tyou have is > Hyperterminal? [sp] I have personally found Realterm quite good specifically for for attaching timing info to the prints received. It is available at: http://realterm.sourceforge.net/ For measurement, I send the output directly to a log file - not displayed on the screen. BTW, Teraterm is my choice for regular use. ~sanjeev [snip]...[snip] ___ 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 Simon,
On Monday 16 May 2011 03:18 PM, Simon Schwarz wrote:
> Hi Aneesh,
>
> I recently started to work on a similar topic: omap3 (devkit8000)
> nand_spl support. So I'am really interested in your OMAP4/common work
> here ;)
>
> In this patch comment you say its common for OMAP3/4 but in
> preloader_console_init() is a call to omap4_rev_string()):
> > printf("Texas Instruments %s\n", omap4_rev_string());
Thank you for pointing it out. I will change it to omap_rev_string()
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 12:03 AM, Wolfgang Denk wrote: > Dear Aneesh V, > > In message<1305472900-4004-10-git-send-email-ane...@ti.com> you wrote: >> Adapted from: nand_spl/board/samsung/smdk6400/Makefile >> >> - Add the SPL makefile for OMAP4430 SDP >> - Add the necessary CONFIG flags in the board config file >> >> Signed-off-by: Aneesh V >> --- >> V2: >> * Changed CONFIG_SYS_SPL_TEXT_BASE to 0x40304350 from >> 0x40304360. This exact address is needed for EMU >> devices. >> * Removed un-necessary compiler options from CFLAGS and AFLAGS. >> These are already set by .mk files in U-Boot >> * Reorganize the make files to re-use common rules between >> boards >> --- >> board/ti/sdp4430/config.mk |3 +- >> include/configs/omap4_sdp4430.h| 19 + >> spl/board/ti/omap4.mk | 77 >> >> spl/board/ti/rules-omap.mk | 74 >> +++ >> .../config.mk => spl/board/ti/sdp4430/Makefile | 21 +++--- >> 5 files changed, 183 insertions(+), 11 deletions(-) >> 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. 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. > >> diff --git a/board/ti/sdp4430/config.mk b/board/ti/sdp4430/config.mk >> index 33901a7..c62965d 100644 >> --- a/board/ti/sdp4430/config.mk >> +++ b/board/ti/sdp4430/config.mk >> @@ -28,4 +28,5 @@ >> # Linux-Kernel is expected to be at 8000'8000, entry 8000'8000 >> # (mem base + reserved) >> >> -CONFIG_SYS_TEXT_BASE = 0x80e8 >> +# 1MB into the SDRAM to allow for SPL's bss at the beginning of SDRAM >> +CONFIG_SYS_TEXT_BASE = 0x8010 > > NAK. Please define in board config header, and get rid of the > config.mk file. 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 v3 02/10] armv7: add miscellaneous utility macros
On Sun, May 15, 2011 at 7:23 PM, Eric Cooper wrote: > On Sun, May 15, 2011 at 03:15:46PM -0700, Simon Glass wrote: > > I believe that this problem is getting worse - e.g. USB on Tegra2 writes > > various fields of about 20 registers to get things up and running. I find > > translating SOC datasheet register definitions into C code with shifts > and > > masks to be slow and error-prone work. Also we do need to maintain this > > code, and it gets reused for new SOC variants, etc. So it is not as if it > is > > written once and then buried and forgotten. There is also a tendency to > use > > 'magic' constants rather than #define values or something with a sensible > > name, then hopefully add a half-hearted comment. This requires constant > > return looks at the datasheet to see what bits were chosen. > > I have nothing against helper functions like this (although I think they > should be inline functions, not macros, to guard against bugs > due to side-effects in arguments). > This does limits the functionality unfortunately. With macros it is possible to (for example) derive a shift and mask from a single base token. > > But wouldn't it be even better to define the registers as C structures > containing bitfields, so the C compiler can do the error-prone > shifting and masking? Well-commented structure definitions for these > registers also eliminate the need to refer back to the datasheet when > working on the code. > I believe the problem here is the read/modify/write behaviour which is not well-defined in C. One ends up using volatile to ensure the right behaviour, and then this doesn't necessarily work either. Where one write must happen before the next read the compiler must have barriers to indicate this, which would then have to be inserted manually (rather than just in the writel() macro). The opposite problem is that if you update several fields at once the compiler may or may not optimise these into a single access, and this is not under programmer control. So writel() and readl() are preferred. Perhaps in newer compilers bitfield semantics have been improved? > > -- > Eric Cooper e c c @ c m u . e d u > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 02/10] armv7: add miscellaneous utility macros
On Monday 16 May 2011 12:14 AM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<1305202276-27784-3-git-send-email-ane...@ti.com> you wrote:
>> add utility macros for:
>> * bit field operations
>> * log2n functions
> ...
>
>> +/* extract a bit field from a bit vector */
>> +#define get_bit_field(nr, start, mask)\
>> +(((nr)& (mask))>> (start))
>> +
>> +/* Set a field in a bit vector */
>> +#define set_bit_field(nr, start, mask, val)\
>> +do { \
>> +(nr) = ((nr)& ~(mask)) | (((val)<< (start))& (mask));\
>> +} while (0);
>
> I really dislike such "useful" helpers, because they make the code
> unreadable. Being nonstandrd, nbody knows what they are doing, so you
> always will have to look up the implementation before you can continue
> reading the code. It's a waste of time an resources.
>
I will be very happy to use a standard one if one exists. I checked in
bitops.h but couldn't find something that's equivalent to the above. Can
you point me to a standard one that does something equivalent.
Yes, you may have to look-up the implementation, but maybe just once.
That goes with any API, right?
On the other hand, doing shifting ORing, ANDing etc directly in the
code is less readable in my opinion.
>> +/*
>> + * Utility macro for read-modify-write of a hardware register
>> + * addr - address of the register
>> + * shift - starting bit position of the field to be modified
>> + * msk - mask for the field
>> + * val - value to be shifted masked and written to the field
>> + */
>> +#define modify_reg_32(addr, shift, msk, val) \
>> +do {\
>> +writel(((readl(addr)& ~(msk))|(((val)<< (shift))& (msk))),\
>> + (addr));\
>> +} while (0);
>
> NAK again, for the same reasons.
>
> Note that there are some semi-standardized I/O accessro macros
> available, at least for some architectures, like clrbits.*(),
> setbits_(), or clrsetbits().
>
> See for example "arch/arm/include/asm/io.h",
> "arch/powerpc/include/asm/io.h" for reference.
>
> Instead of reinventing the wheel (just differently shaped) we should
> rather try and use a single, standardized set of such helpers.
>
> So please use the existing macros instead of inventing new,
> non-standard ones.
clrsetbits will work for this need albeit not as clean as the above
one. I will use that.
>
> 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 02/22] omap4: add OMAP4430 revision check
Dear Aneesh V,
In message <4dd11511.1060...@ti.com> you wrote:
>
> >> + const char *omap4_rev = NULL;
> >> + switch (omap4_revision()) {
> >> + case OMAP4430_ES1_0:
> >> + omap4_rev = "OMAP4430 ES1.0";
> >> + break;
> >> + case OMAP4430_ES2_0:
> >> + omap4_rev = "OMAP4430 ES2.0";
> >> + break;
> >> + case OMAP4430_ES2_1:
> >> + omap4_rev = "OMAP4430 ES2.1";
> >> + break;
> >> + case OMAP4430_ES2_2:
> >> + omap4_rev = "OMAP4430 ES2.2";
> >> + break;
> >
> > Such code does not really scale well. Can this not be improved? I
> > think we just had similar discussions for i.MX5x - please check what
> > the result of these was.
>
> Are you referring to this one?
> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/98522
>
> If so, it may not work for us:
>
> 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.
> 2. In our case we do not have a 1:1 mapping between the
> revisions(monotonically increasing numbers) we need in the U-Boot and
> the value obtained from the ID_CODE register. So, a translation is
> inevitable.
This is not needed. See above. Any form of table driven approach
would be suitable, too.
> 3. We need increasing numbers for subsequent revisions so that we can
> have something like:
Should be no problem, see above. Just define your number scheme.
Instead of decimal packing you could also adapt something like the
major/minor numbers for devices, and use the existing macros to
extract the parts.
There are tons of existing solutions for this type of problem, just
pick one that fits.
> >> + default:
> >> + omap4_rev = "OMAP4 - Unknown Rev";
> >> + break;
> >
> > Please also output what the unknown revision was - this saves at least
> > one debug round if you ever run into this case.
>
> This function should be in sync with omap4_revision() function(unless
> there is a bug). So, the rev will be OMAP4430_SILICON_ID_INVALID in
> that case.
In this case omap4_revision() should print the value it is reading.
Whenever you are reading "unexpected? numbers the first thing you will
do during debugging is to check _what_ exactly you are reawding - so
you can help and safe one step by just printing thei information which
you have ready in your hands.
> I shall print out the ARM revision and OMAP revision registers when I
> get into OMAP4430_SILICON_ID_INVALID situation in omap4_revision()
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
"We have the right to survive!"
"Not be killing others."
-- Deela and Kirk, "Wink of An Eye", stardate 5710.5
___
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 <4dd1189d.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 V > > ... > >> + /* 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. 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 Good manners are the settled medium of social, as specie is of commercial, life; returns are equally expected for both. - Lord Chesterfield _Letters to his Son_, 25 December 1753 ___ 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 <4dd11d1f.8020...@ti.com> you wrote: > > > - Get rid of xloader. I cannot see any good reasons why we need it, > >i. e. which functions if performs that cannot be as well (and > >eventually even more efficiently) be performed in the U-Boot SPL > >code. > > Indeed, SPL is seen as a replacement for x-loader. Excellent. > How do we handle the differences you just mentioned, namely the size, > parameter passing etc. Maybe, we should have special handling for each > and define config flags like CONFIG_SPL_PAYLOAD_UBOOT, > CONFIG_SPL_PAYLOAD_LINUX_KERNEL etc? None of this. Ideally, the code should not even see such a difference. U-Boot does not need any special arguments for booting, so we calways pass Linux-compatible args. And things like image size should be read from the image itself, or form other available meta information (like file size when reading from a FAT file system, etc.). > >> Makefile | 24 > >> arch/arm/include/asm/global_data.h |5 + > >> 2 files changed, 29 insertions(+), 0 deletions(-) > > > > Here the commit message and the implementation do not agree. You > > wrote "Create a top level directory 'spl'" - but I don't see any of > > that here? > > In this patch, I just created the makefile infrastructure that expects > this directory structure. The files are created later in an OMAP > specific patch. Such a definition should include the rename / moving of the other, already existing code. 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 Computers are not intelligent. They only think they are. ___ 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 <4dd13056.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/// .
>
> Let spl/board///Makefile decide what it wants to
> build.
There are common, board independent parts both in spl/nand and
spl/onenand.
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
[Doctors and Bartenders], We both get the same two kinds of customers
-- the living and the dying.
-- Dr. Boyce, "The Menagerie" ("The Cage"), stardate unknown
___
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 <4dd134dd.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?
> 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?
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?
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 man either lives life as it happens to him, meets it head-on and
licks it, or he turns his back on it and starts to wither away.
-- Dr. Boyce, "The Menagerie" ("The Cage"), stardate unknown
___
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 Simon Glass, In message you wrote: > > I believe the problem here is the read/modify/write behaviour which is not > well-defined in C. One ends up using volatile to ensure the right behaviour, > and then this doesn't necessarily work either. Where one write must happen volatile does not help anything here. You MUST always make sure to use proper I/O accessors. Even in ARM code this has become mandatory by now, even if older ARM cores and compilers have been forgiving enough for a long time. > Perhaps in newer compilers bitfield semantics have been improved? Bitfields have always been a mess, and should be avoided like hell. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There are three things I always forget. Names, faces - the third I can't remember. - Italo Svevo ___ 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 Wolfgang,
Such a lot of text about such a small patch. It is clear to me that you are
used to doing things one way, and this is a different approach. As I said
there is more than one way to skin this cat and I think there are advantages
to having internal self-contained timing. I will try to address some of your
comments below.
On Sun, May 15, 2011 at 10:48 PM, Wolfgang Denk wrote:
> Dear Simon Glass,
>
> In message you wrote:
> >
> > This is 100us which is pretty good although you are assuming that there
> is
> > no FIFO holding things. Also on modern ARM CPUs the 'processing' part of
>
> I don't see that we use any FIFOs in the output direction.
>
Yes we do, and in fact they do improve boot performance slightly when the
console is muted.
>
> > U-Boot (where it is not just waiting on a device) can be over in under
> > 100ms, and if you are wanting to reduce this, a little more resolution
> > doesn't hurt.
>
> Sorry, I cannot parse the "over in under 100 millisecond" part.
>
finished in under 100ms, the point being that if the time taken to load the
kernel is fixed, and you want to work on the other stuff, the total run-time
of it is under 100ms on some platforms.
> > > - It requires zero code changes. You can run the production code and
> > > time it. You can use it without rebuilding / reinstalling the
> > > software, yes even without access to the source code.
> > >
> >
> > Are you not ignoring the timing parser on the serial port which must be
> > written and changed to cope with the different output of U-Boot (net
> boot,
> > USB boot, MMC boot, SD boot, etc.)? We have a lot of boot paths,
> different
> > architectures, etc. We want a simple solution.
>
> Well, the "timing parser", as you callit, can be written in 10 lines
> or less of your scripting language of choice. See for example here
> for a solution in expect/tcl: ftp://ftp.denx.de/pub/tools/time_log
> We've been using this for about 10 years by now (see for example this
> 7 year old boot time analysis:
> http://www.denx.de/wiki/DULG/AN2004_11_BootTimeOptimization).
>
> As we can trivially use regular expressions, the effort to implement a
> "timing parser" can be ignored. And it is independet of what sort of
> boot device we are using.
>
It looks great, I wish we could use it on our platform, but for the reasons
I have given it is not suitable.
>
>
> You write: "We want a simple solution." I agree 100%.
>
> Isn;t a 10 line script code solution that does not require ANY changes
> to the U-Boot code _much_ simpler than your approach?
>
> This is why I was asking if your solution had any significant
> advantages.
>
OK fair enough, of course we want the simplest solution that covers the
requirements.
>
> > In our case the console is silent on boot, so this solution does not
> work.
>
> Point taken. But, you need to output the timing information, don't you?
>
We need to record it - generally this is done by Linux later (along with all
the boot performance stats from Linux).
>
> > Secondly it requires a listener on the serial port which we often don't
> > have. Thirdly we want to log this information and record it in the field
> so
>
> You must have one to rea the time logs, right?
>
See above - there is no serial port listener.
>
> > that we track boot time. This means that it has to be done by the device
> > itself.
>
> Did you see cases where the boot time in the field differs from that
> in your lab? Can you please explain what is causing such differecnes?
>
We have a verified boot which can taken different paths when it sees an
update image, or corruption, for example. These paths can substantially
change the boot time. Changing boot times have often led us to bugs in the
past. Also the device itself can change. For example the performance of an
eMMC device changes over time and we want to track that.
> > > - It is completely platform, SoC and board idependent - we do not need
> > > to provide any specific timer servcies etc. which are inherently
> > > platform-dependent.
> >
> > Is this really an advantage?
>
> Don't you think so?
>
> Will you provide the code to implement your solution for all currently
> supported BlackFin, ColdFire, MicroBlaze, MIPS, NIOS, PPC, SH, SPARC
> or x86 CPUs? Or even for all currently supported ARMN SoCs?
>
Here is the entire extent of the platform-specific code for Tegra2:
unsigned long timer_get_us(void)
{
struct timerus *timer_base = (struct timerus *)NV_PA_TMRUS_BASE;
return readl(&timer_base->cntr_1us);
}
I agree it is unfortunate to have features which require platform-specific
features. Perhaps we should define a microsecond timer as a requirement of a
U-Boot port? Or perhaps an option which opens up new features?
>
> > Write to the serial port costs about 30ms on our platform at minimum. I
> > have't looked at why, but the serial FIFO is only so big so I assume that
> is
>
> I think this can (and should) be fixed. It makes little sense to use a
> FIFO in the tr
Re: [U-Boot] [PATCH 0/4] Accurate boot time measurement
On Mon, 16 May 2011 13:40:20 +0200
Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message you wrote:
> >
> > > As we can trivially use regular expressions, the effort to implement a
> > > "timing parser" can be ignored. And it is independet of what sort of
> > > boot device we are using.
> >
> > Fine if your running Linux - What if the only tool tyou have is
> > Hyperterminal?
>
> AFAICT tcl is also available under Windoze...
What about a board farm with a networked serial port server, adding
unpredictable latency? Even if you have direct access to the host serial
port, there's not just the host FIFO distorting things, but the scheduling
latency of the application. I suspect the useful precision of this
approach is significantly higher than 100 us.
> What makes you think a call to printf()/puts()/putc() would increase
> the code size worse than a call to the trace function? If I don't
> care about pretty messages (and use silent console otherwise) my
> serial console based messages consist of a plain "putc('a')" or
> similar - certainly not more overhead than the call to the trace
> function.
The size impact minor in either case, but in terms of time overhead (i.e.
the thing being measured), waiting for previous output to go
over the wire and the THR to empty is less overhead than putting a
timestamp in a log? Even if THR is already empty, those I/O accesses tend
to be much more expensive than reading from an CPU-internal time source and
writing to a cached data structure.
> It's not about willing or not. If willing or wanting would help, we
> had an ideal world. But in reality, we have a world full of
> restrictions.
And requiring that debugging infrastructure for such a low-level piece of
software be universally applicable is a pretty big
self-imposed restriction...
How many targets are so short on pre-relocation memory that they can't
spare a couple hundred bytes for debugging, lacking a suitable time
source, etc.? It seems like the concept would be usable on more than just
a handful of boards, even if not necessarily all of them.
> GD is definitely not buffer space for arbitrary amounts of log data.
When did "limited" become "arbitrary"?
-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
Dear Simon Glass, In message you wrote: > > Such a lot of text about such a small patch. It is clear to me that you are > used to doing things one way, and this is a different approach. As I said You can tell many things about me, but this one certainly is not the case. > > I don't see that we use any FIFOs in the output direction. > > Yes we do, and in fact they do improve boot performance slightly when the > console is muted. Do you have an explanation how that works? When there is no output on the console, the use of a FIFO in tx direction should not matter at all? > I agree it is unfortunate to have features which require platform-specific > features. Perhaps we should define a microsecond timer as a requirement of a > U-Boot port? Or perhaps an option which opens up new features? We already have that, or better. The problem is that it depends on the architecture. On PPC systems for example you always have the time base, a 64 bit counter which is clocked with something like 1/4 or 1/16 of the CPU clock. And whe have the timer that gettime() is based on - which is in milliseocnd resolution (hence the demand that CONFIG_SYS_HZ must always be defined as 1000). The problem comes with the multitude of different architectures and SoCs we support - there is no concept of timebase registers on ARM, on some systems we need interrupts to implement timer services so these are available only after relocation, etc. > > But you need storage for the timing events, and you don't have this > > before relocation. So you miss some really interesting parts of the > > boot procedure. > > It is easy enough to get storage if we want it - you can maintain a > pre-reloc table which is copied over afterwards. I notice that some Where will you store this "pre-reloc" table? Yes, there are some systems with plenty of on-chip-memory or huge caches that can beused for this. But there are also systems where we barely can find the room for the most vital global data before relocation. Even worse - if you take this seriously, you will probably also get timing information from early boot stages, like how long it's taking to load the U-Boot image from NAND - but on some systems this loader code has to fit in as little as 2 KiB. > I believe it compares favourably. It has a more friendly display, doesn't > require a serial port, is more accurate, can run self-hosted, etc. With the > TCL script you need to add a new line before you will get a new time. Well, the display format is trivial to adapt, as well as the trigger criteria. Keep in mind that this is just an example script that covers the most common use case we've seen so far. > > But to do so, you need to insert trace points. With the same effort > > we can insert a printf(). > > Fair enough. If you have your heart set on the TCL script I'm really not > going to get very far! I haven't my heart set on it. It is just one example of solutions which cover a large percentage of the potential use cases. I am trying to understand the ration of advanatges versus effort, that's all. > 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. Where is the problem? If you are convinced of you idea you should be ready to defend it. If you are not, it's not wort it at all. And if you see a voting result of 2:1 pro this is pretty good, isn't it? > But if you really don't want this in U-Boot then please accept my apologies > for wasting so much time on the list. I don't consider this discussion a waste of time. I hope you don't do, either. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Life would be so much easier if we could just look at the source code. -- Dave Olson ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/22] Add generic spl infrastructure
On Sun, 15 May 2011 20:51:24 +0530
Aneesh V 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?
> @@ -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?
> 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 @@ typedefstruct 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)?
-Scott
___
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
On Mon, 16 May 2011 19:40:30 +0530 Aneesh V wrote: > Hi Wolfgang, > > On Monday 16 May 2011 01:22 AM, Wolfgang Denk wrote: > > 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/// . > > Let spl/board///Makefile decide what it wants to > build. That's what we do in nand_spl/onenand_spl -- the common files are more like libraries that the board makefile may or may not pull in (e.g. many Freescale boards use nand_boot_fsl_elbc.c or nand_boot_fsl_nfc.c instead of nand_boot.c). Renaming nand_spl seems like it should be the first step. > I mean something like this(similar changes for ONENAND): > > +.PHONEY : SPL .PHONY -Scott ___ 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
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.
> 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;
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 18/22] armv7: embed u-boot size within u-boot for use from SPL
On Sun, 15 May 2011 20:51:36 +0530 Aneesh V wrote: > Embed the u-boot flash image size at a known offset from the > start of u-boot so that SPL can use it while loading u-boot > from a non-XIP media. > > Signed-off-by: Aneesh V > V2: > * Removed the linker script label '__flash_image_end' and its usage. > Instead '_end' is used now > --- > arch/arm/cpu/armv7/start.S |6 +- > 1 files changed, 5 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S > index f92c6d9..f676d7d 100644 > --- a/arch/arm/cpu/armv7/start.S > +++ b/arch/arm/cpu/armv7/start.S > @@ -64,8 +64,12 @@ _pad: .word 0x12345678 /* now 16*4=64 > */ > > .global _end_vect > _end_vect: > +.global _u_boot_size > +_u_boot_size: > + .word 0xDEADBEEF > + .word _end - _start 0xdeadbeef does not seem like a good magic value to identify this header format -- especially since it looks like that may have been the value present in the older images that don't have this header (depending on whether the .balignl needed to pad). -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] nand_spl: nand_boot.c: Remove last CONFIG_SYS_NAND_READ_DELAY occurance
On Mon, May 16, 2011 at 01:04:00PM +0200, Stefan Roese wrote: > Remove the last CONFIG_SYS_NAND_READ_DELAY occurance from nand_boot.c. > I missed this one in patch a9c847cb [nand_spl: nand_boot.c: Remove > CONFIG_SYS_NAND_READ_DELAY]. > > This fixes a compile breakage on kilauea_nand for example. > > Signed-off-by: Stefan Roese > Cc: Scott Wood > --- > nand_spl/nand_boot.c |7 ++- > 1 files changed, 2 insertions(+), 5 deletions(-) Applied to u-boot-nand-flash -Scott ___ 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
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? Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Multi threading or IRQ handler
Hi, Is there any multithreading support or interrupt handler register mechanism in u-boot for mpc85xx based boards ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multi threading or IRQ handler
On Mon, 16 May 2011 23:20:30 +0530 asar wrote: > Hi, > > > > Is there any multithreading support or interrupt handler register mechanism > in u-boot for mpc85xx based boards > No. -Scott ___ 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"
Mike Frysinger wrote: > On Monday, April 18, 2011 12:19:51 Luca Ceresoli wrote: >> With the upcoming TFTP server implementation, the remote node can be >> either a client or a server, so avoid ambiguities. > the summary made me worried because i thought you were going to rename the env > var "server" to "remote". could you tweak the summary to avoid this ambiguity > in what you're actually doing ? how about: > TFTP: use "remote" in local variable names instead of "server" Improved commit message in v3. >> -IPaddr_t ServerNet = TftpServerIP& NetOurSubnetMask; >> +IPaddr_t ServerNet = TftpRemoteIP& NetOurSubnetMask; > shouldnt that now be RemoteNet ? Done for v3. Luca ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multi threading or IRQ handler
Dear "asar", In message <01cc13f1$c3d42c90$4b7c85b0$@nucleodyne.us> you wrote: > > Is there any multithreading support or interrupt handler register mechanism > in u-boot for mpc85xx based boards We do have interrupt support on PowerPC, but U-Boot is strictly single-threaded. And most drivers use polling only. Sounds what you are looking for is an operating system, not a boot loader. 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 "Text processing has made it possible to right-justify any idea, even one which cannot be justified on any other grounds." -- J. Finnegan, USC. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [STATUS] Getting ready for -rc1
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. Custodians: if there is unmerged stuff in your queues, then please send your pull requests within the next few days. 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 "Tell the truth and run." - Yugoslav proverb ___ 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"
Luca Ceresoli wrote:
> Il 19/04/2011 16:18, Detlev Zundel ha scritto:
>> Hi Luca,
>>
>>> 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
>>> Cc: Wolfgang Denk
>>> ---
>>> Changes in v2:
>>> - fixed checkpatch issues.
>>>
>>> net/tftp.c | 42 +-
>>> 1 files changed, 21 insertions(+), 21 deletions(-)
>>>
>>> diff --git a/net/tftp.c b/net/tftp.c
>>> index 00abec3..da545c6 100644
>>> --- a/net/tftp.c
>>> +++ b/net/tftp.c
>>> @@ -55,18 +55,18 @@ enum {
>>> TFTP_ERR_FILE_ALREADY_EXISTS = 6,
>>> };
>>>
>>> -static IPaddr_t TftpServerIP;
>>> -static intTftpServerPort;/* The UDP port at their
>>> end*/
>>> -static intTftpOurPort;/* The UDP port at our end*/
>>> +static IPaddr_t TftpRemoteIP;
>>> +static intTftpRemotePort;/* The UDP port at their
>>> end*/
>>> +static intTftpOurPort;/* The UDP port at our end*/
>>> static intTftpTimeoutCount;
>>> -static ulongTftpBlock;/* packet sequence number*/
>>> -static ulongTftpLastBlock;/* last packet sequence
>>> number received */
>>> -static ulongTftpBlockWrap;/* count of sequence number
>>> wraparounds */
>>> -static ulongTftpBlockWrapOffset;/* memory offset due to
>>> wrapping*/
>>> +static ulongTftpBlock;/* packet sequence number*/
>>> +static ulongTftpLastBlock;/* last packet sequence number
>>> received */
>>> +static ulongTftpBlockWrap;/* count of sequence number
>>> wraparounds */
>>> +static ulongTftpBlockWrapOffset; /* memory offset due to
>>> wrapping*/
>> These changes are indentation only changes, so they should be in a
>> separate patch.
>
> It's needed for checkpatch compliance.
>
>
>>> static intTftpState;
>>> #ifdef CONFIG_TFTP_TSIZE
>>> -static intTftpTsize;/* The file size reported by the
>>> server */
>>> -static shortTftpNumchars;/* The number of hashes we
>>> printed */
>>> +static intTftpTsize;/* The file size reported by the server */
>>> +static shortTftpNumchars;/* The number of hashes we
>>> printed */
>> dito.
>>
>> [...]
>>
>>> @@ -421,7 +421,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.
>> Hey, while you're at it, please fix the "Acknoledge" typo ;)
>
> Will do.
Done for v3.
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.
Luca
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Act as a TFTP server
Wolfgang Denk wrote: > Dear Luca Ceresoli, > > In message<4dbff3af.4040...@comelit.it> you wrote: >>> So assuming we never see any incoming packets - how long will we wait? >> Once it has started, the server is stopped like the client is: >> - on a complete file reception >> - pressing Ctrl-C >> - after waiting 5 seconds for 10 times. > OK, fine. Can you please document thisn, then. Thanks. Incorporating also Mike's suggestion for the one-line help, I propose this: 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." ); Comments? Luca ___ 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 Mon, May 16, 2011 at 11:32 AM, Wolfgang Denk wrote: > Dear Simon Glass, >... >> Yes we do, and in fact they do improve boot performance slightly when the >> console is muted. > > Do you have an explanation how that works? When there is no output on > the console, the use of a FIFO in tx direction should not matter at > all? Hi Wolfgang, That's right, but when output is not muted, the FIFO allows for some characters to be output before stalling the CPU. > >> I agree it is unfortunate to have features which require platform-specific >> features. Perhaps we should define a microsecond timer as a requirement of a >> U-Boot port? Or perhaps an option which opens up new features? > > We already have that, or better. The problem is that it depends on > the architecture. The implementation, maybe (not the interface which can be common), but by expressing things in microseconds it is normally possible to convert, and when this isn't available people will understand that some rounding is going on. > > On PPC systems for example you always have the time base, a 64 bit > counter which is clocked with something like 1/4 or 1/16 of the CPU > clock. > > And whe have the timer that gettime() is based on - which is in > milliseocnd resolution (hence the demand that CONFIG_SYS_HZ must > always be defined as 1000). > > The problem comes with the multitude of different architectures and > SoCs we support - there is no concept of timebase registers on ARM, on > some systems we need interrupts to implement timer services so these > are available only after relocation, etc. On several ARM SOCs there is a monotonic timer - it's not always a microsecond timer but is typically good enough for this sort of purpose. In some cases this doesn't require interrupts (e.g. Tegra). > >> > But you need storage for the timing events, and you don't have this >> > before relocation. So you miss some really interesting parts of the >> > boot procedure. >> >> It is easy enough to get storage if we want it - you can maintain a >> pre-reloc table which is copied over afterwards. I notice that some > > Where will you store this "pre-reloc" table? Yes, there are some > systems with plenty of on-chip-memory or huge caches that can beused > for this. But there are also systems where we barely can find the > room for the most vital global data before relocation. I would rather discuss this once we get agreement on the first part of this, which is the concept of using a timer at all! But it is not hard to store data pre-reloc and move it later. This is what happens with the global data at the moment. > > Even worse - if you take this seriously, you will probably also get > timing information from early boot stages, like how long it's taking > to load the U-Boot image from NAND - but on some systems this loader > code has to fit in as little as 2 KiB. SOC boot ROMs are changing this, but even so I don't see this as a serious limitation. If you don't have room for boot timing in your pre-boot loader, don't add it. > >> I believe it compares favourably. It has a more friendly display, doesn't >> require a serial port, is more accurate, can run self-hosted, etc. With the >> TCL script you need to add a new line before you will get a new time. > > Well, the display format is trivial to adapt, as well as the trigger > criteria. Keep in mind that this is just an example script that > covers the most common use case we've seen so far. OK > >> > But to do so, you need to insert trace points. With the same effort >> > we can insert a printf(). >> >> Fair enough. If you have your heart set on the TCL script I'm really not >> going to get very far! > > I haven't my heart set on it. It is just one example of solutions > which cover a large percentage of the potential use cases. I am > trying to understand the ration of advanatges versus effort, that's > all. In that case will you consider the inclusion of this as a different way of doing things? > >> 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. > > Where is the problem? If you are convinced of you idea you should be > ready to defend it. If you are not, it's not wort it at all. And if > you see a voting result of 2:1 pro this is pretty good, isn't it? I think I have mounted a robust defense. In fact I haven't written so much on one topic for a week :-) > >> But if you really don't want this in U-Boot then please accept my apologies >> for wasting so much time on the list. > > I don't consider this discussion a waste of time. I hope you don't do, > either. Regards, Simon > > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
[U-Boot] [PATCH 1/1] Fix hang when entering udelay after GPTIMER2 overflows (about 22 minutes on AM37x)
Signed-off-by: Rick Bronson
---
arch/arm/cpu/armv7/omap-common/timer.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/timer.c
b/arch/arm/cpu/armv7/omap-common/timer.c
index 9beebb1..3c9d488 100644
--- a/arch/arm/cpu/armv7/omap-common/timer.c
+++ b/arch/arm/cpu/armv7/omap-common/timer.c
@@ -44,7 +44,7 @@ static struct gptimer *timer_base = (struct gptimer
*)CONFIG_SYS_TIMERBASE;
*/
#define TIMER_CLOCK(V_SCLK / (2 << CONFIG_SYS_PTV))
-#define TIMER_LOAD_VAL 0x
+#define TIMER_LOAD_VAL 0 /* counter starts from 0 on reload */
int timer_init(void)
{
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/3] MX5: Make the weim structure complete
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
---
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;
+ u32 cs0gcr2;
+ u32 cs0rcr1;
+ u32 cs0rcr2;
+ u32 cs0wcr1;
+ u32 cs0wcr2;
+ u32 cs1gcr1;
+ u32 cs1gcr2;
+ u32 cs1rcr1;
+ u32 cs1rcr2;
+ u32 cs1wcr1;
+ u32 cs1wcr2;
+ u32 cs2gcr1;
+ u32 cs2gcr2;
+ u32 cs2rcr1;
+ u32 cs2rcr2;
+ u32 cs2wcr1;
+ u32 cs2wcr2;
+ u32 cs3gcr1;
+ u32 cs3gcr2;
+ u32 cs3rcr1;
+ u32 cs3rcr2;
+ u32 cs3wcr1;
+ u32 cs3wcr2;
+ u32 cs4gcr1;
+ u32 cs4gcr2;
+ u32 cs4rcr1;
+ u32 cs4rcr2;
+ u32 cs4wcr1;
+ u32 cs4wcr2;
+ u32 cs5gcr1;
+ u32 cs5gcr2;
+ u32 cs5rcr1;
+ u32 cs5rcr2;
+ u32 cs5wcr1;
+ u32 cs5wcr2;
+ u32 wcr;
+ u32 wiar;
+ u32 ear;
};
/* GPIO Registers */
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/3] MX5: Add iomux structure
Signed-off-by: Fabio Estevam
---
Changes since v1:
- iomuxc was accessed directly in v1, so create a iomux struct
so that we can use io accessors
arch/arm/include/asm/arch-mx5/imx-regs.h | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx5/imx-regs.h
b/arch/arm/include/asm/arch-mx5/imx-regs.h
index d80e0c0..eb690ec 100644
--- a/arch/arm/include/asm/arch-mx5/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx5/imx-regs.h
@@ -273,6 +273,17 @@ struct weim {
u32 ear;
};
+struct iomuxc {
+ u32 gpr0;
+ u32 gpr1;
+ u32 gpr2;
+ u32 omux0;
+ u32 omux1;
+ u32 omux2;
+ u32 omux3;
+ u32 omux4;
+};
+
/* GPIO Registers */
struct gpio_regs {
u32 gpio_dr;
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/3] MX53: Add initial support for MX53ARD board
Signed-off-by: Fabio Estevam --- Changes since v1: - Use io accessors to access weim and iomuxc - Initialize the 2 esdhc controllers - Configure the 2 banks of DDR memory - Fix typo on machine_id - Remove CONFIG_SYS_BOOTMAPSZ from config file MAINTAINERS |1 + board/freescale/mx53ard/Makefile | 48 + board/freescale/mx53ard/imximage.cfg | 96 +++ board/freescale/mx53ard/mx53ard.c| 314 ++ boards.cfg |1 + include/configs/mx53ard.h| 193 + 6 files changed, 653 insertions(+), 0 deletions(-) create mode 100644 board/freescale/mx53ard/Makefile create mode 100644 board/freescale/mx53ard/imximage.cfg create mode 100644 board/freescale/mx53ard/mx53ard.c create mode 100644 include/configs/mx53ard.h diff --git a/MAINTAINERS b/MAINTAINERS index 07237e3..b63f53f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -639,6 +639,7 @@ Kristoffer Ericson Fabio Estevam mx31pdk i.MX31 + mx53ard i.MX53 mx53smd i.MX53 Peter Figuli diff --git a/board/freescale/mx53ard/Makefile b/board/freescale/mx53ard/Makefile new file mode 100644 index 000..c48ece8 --- /dev/null +++ b/board/freescale/mx53ard/Makefile @@ -0,0 +1,48 @@ +# +# Copyright (C) 2007, Guennadi Liakhovetski +# +# (C) Copyright 2011 Freescale Semiconductor, Inc. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).o + +COBJS := mx53ard.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/freescale/mx53ard/imximage.cfg b/board/freescale/mx53ard/imximage.cfg new file mode 100644 index 000..0f298ab --- /dev/null +++ b/board/freescale/mx53ard/imximage.cfg @@ -0,0 +1,96 @@ +# +# (C) Copyright 2009 +# Stefano Babic DENX Software Engineering sba...@denx.de. +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not write to the Free Software +# Foundation Inc. 51 Franklin Street Fifth Floor Boston, +# MA 02110-1301 USA +# +# Refer docs/README.imxmage for more details about how-to configure +# and create imximage boot image +# +# The syntax is taken as close as possible with the kwbimage + +# image version + +IMAGE_VERSION 2 + +# Boot Device : one of +# spi, sd (the board has no nand neither onenand) + +BOOT_FROM sd + +# Device Configuration Data (DCD) +# +# Each entry must have the format: +# Addr-type AddressValue +# +# where: +# Addr-type register length (1,2 or 4 bytes) +# Address absolute address of the register +# value value to be stored in the register +DATA 4 0x53fa8554 0x0030 +DATA 4 0x53fa8558 0x00300040 +DATA 4 0x53fa8560 0x0030 +DATA 4 0x53fa8564 0x00300040 +DATA 4 0x53fa8568 0x00300040 +DATA 4 0x53fa8570 0x0030 +DATA 4 0x53fa8574 0x0030 +DATA 4 0x53fa8578 0x0030 +DATA 4 0x53fa857c 0x00300040 +DATA 4 0x53fa8580 0x00300040 +DATA 4 0x53fa8584 0x0030 +DATA 4 0x53fa8588 0x0030 +DATA 4 0x53fa8590 0x00300040 +DATA 4 0x53fa8594 0x0030 +DATA 4 0x53fa86f0 0x0030 +DATA 4 0x53fa86f4 0x +DATA 4 0x53fa86fc 0x +D
Re: [U-Boot] [PATCH 0/4] Accurate boot time measurement
On Mon, May 16, 2011 at 9:40 PM, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message you wrote:
>>
>> > As we can trivially use regular expressions, the effort to implement a
>> > "timing parser" can be ignored. And it is independet of what sort of
>> > boot device we are using.
>>
>> Fine if your running Linux - What if the only tool tyou have is
>> Hyperterminal?
>
> AFAICT tcl is also available under Windoze...
>
>> I've seen many instances where everything works well 'in the lab' and as
>> soon as you put it in the field, things go pear shaped. Often you need to
>
> We all have seen this, and we all appreciate any tool that is
> available then.
>
>> > But you need storage for the timing events, and you don't have this
>> > before relocation. So you miss some really interesting parts of the
>> > boot procedure.
>>
>> Maybe a limited amount can be stored in global data by testing the
>> relocated flag
>
> I don't think so.
As I said before, the timing aberation per-boot in pre-relocation code is
going to be pretty minimal. 'In The Lab' you can easily use putc() and
your favourite terminal/script to do the timing analysis when you are
trying to trim micro-seconds (optimising SDRAM init/sizing etc, NAND
loading, NOR wait states)
My particular interest in the boot timing analysis is where it is being
affected by factors such as:
- Device initialisation (peripherals via I2C, FPGAs etc)
- Network (DHCP/TFTP requests)
- Storage device access (HDDs, NAND etc)
- Physical Environment (temperature etc)
These factors are not as reproducible 'In The Lab' and in the field may
be very transient.
>> > OK, not needing a console port during boot is indeed an advantage. It
>> > comes at the cost of needing log space, which is not available before
>> > relocation, so we miss some interesting parts of the boot procedure.
>>
>> Can use global data for a limited number of pre-relocation records. And I
>> don't think pre-location is where a lot of problems will occur anyway
>> unless you have flaky/misconfigured hardware
>
> I smell a bloated implementation which works on one specific system or
> two. This doesn't sound attractive to me.
>
>> >> 5. It allows timing of things which don't result in serial output.
>> >
>> > But to do so, you need to insert trace points. With the same effort
>> > we can insert a printf().
>>
>> Which increase code/data size - If you don't care about having pretty
>> messages in you boot profile (you can always look up source or
>> documentation) the size impact per 'mark' is less
>
> What makes you think a call to printf()/puts()/putc() would increase
> the code size worse than a call to the trace function? If I don't
> care about pretty messages (and use silent console otherwise) my
> serial console based messages consist of a plain "putc('a')" or
> similar - certainly not more overhead than the call to the trace
> function.
Another 'In The Field' scenario is where you do not have a free console
port available because thay are all used for communicating to other
devices. We have devices with five serial ports and at times we still run
out of ports
>> I think my refined suggestion has a far smaller impact than first thought
>> and you can get pre-relocation information if you are willing to use
>> some global data storage
>
> It's not about willing or not. If willing or wanting would help, we
> had an ideal world. But in reality, we have a world full of
> restrictions.
Yes, and some of those restrictions limit your ability to use a serial
port to debug boot times
> GD is definitely not buffer space for arbitrary amounts of log data.
Agreed, but:
a) Pre-relocation logging may not strictly be needed because boot-times
up to relocation can be fine tuned in the lab using putc()
b) A few dozen bytes in GD in a debug build to isolate some stupid random
issue onyl seen in the field can save hundreds (if not thousands) of
of engineering time
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Nios Pull Request
Dear Wolfgang, The following changes since commit 535abb96fb665402894b820f934deaca61ce3d3e: Wolfgang Denk (1): Merge branch 'master' of git://git.denx.de/u-boot-nand-flash are available in the git repository at: git://git.denx.de/u-boot-nios.git next Thomas Chou (1): nios2: Make STANDALONE_LOAD_ADDR configurable per board arch/nios2/config.mk |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: a320: enable tagged list support
Dear Wolfgang, On Mon, May 16, 2011 at 7:42 PM, Wolfgang Denk wrote: > Dear Po-Yu Chuang, > > In message <1305531660-1595-1-git-send-email-ratbert.chu...@gmail.com> you > wrote: >> From: Po-Yu Chuang >> >> >> Signed-off-by: Po-Yu Chuang >> --- >> include/configs/a320evb.h | 6 ++ >> 1 files changed, 6 insertions(+), 0 deletions(-) >> >> diff --git a/include/configs/a320evb.h b/include/configs/a320evb.h >> index 0527822..f12977b 100644 >> --- a/include/configs/a320evb.h >> +++ b/include/configs/a320evb.h >> @@ -25,6 +25,12 @@ >> #include >> >> /*--- >> + * Linux kernel tagged list >> + */ >> +#define CONFIG_CMDLINE_TAG >> +#define CONFIG_SETUP_MEMORY_TAGS >> + >> +/*--- > > Please also fix the incorrect multiline comment style while modifying > this code. Thanks. OK, I will resubmit this patch with a preceding clean patch. Best regards, Po-Yu Chuang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] arm: a320: fix multiline comment style
From: Po-Yu Chuang
Signed-off-by: Po-Yu Chuang
---
include/configs/a320evb.h | 32 ++--
1 files changed, 14 insertions(+), 18 deletions(-)
diff --git a/include/configs/a320evb.h b/include/configs/a320evb.h
index 0527822..f832d52 100644
--- a/include/configs/a320evb.h
+++ b/include/configs/a320evb.h
@@ -24,29 +24,29 @@
#include
-/*---
+/*
* CPU and Board Configuration Options
*/
#undef CONFIG_USE_IRQ /* we don't need IRQ/FIQ stuff */
#undef CONFIG_SKIP_LOWLEVEL_INIT
-/*---
+/*
* Power Management Unit
*/
#define CONFIG_FTPMU010_POWER
-/*---
+/*
* Timer
*/
#define CONFIG_SYS_HZ 1000/* timer ticks per second */
-/*---
+/*
* Real Time Clock
*/
#define CONFIG_RTC_FTRTC010
-/*---
+/*
* Serial console configuration
*/
@@ -62,7 +62,7 @@
/* valid baudrates */
#define CONFIG_SYS_BAUDRATE_TABLE { 9600, 19200, 38400, 57600, 115200 }
-/*---
+/*
* Ethernet
*/
#define CONFIG_NET_MULTI
@@ -70,7 +70,7 @@
#define CONFIG_BOOTDELAY 3
-/*---
+/*
* Command line configuration.
*/
#include
@@ -79,7 +79,7 @@
#define CONFIG_CMD_DATE
#define CONFIG_CMD_PING
-/*---
+/*
* Miscellaneous configurable options
*/
#define CONFIG_SYS_LONGHELP/* undef to save memory */
@@ -96,7 +96,7 @@
/* Boot Argument Buffer Size */
#define CONFIG_SYS_BARGSIZECONFIG_SYS_CBSIZE
-/*---
+/*
* Stack sizes
*
* The stack sizes are set up in start.S using the settings below
@@ -107,16 +107,12 @@
#define CONFIG_STACKSIZE_FIQ (4 * 1024) /* FIQ stack */
#endif
-/*---
+/*
* Size of malloc() pool
*/
#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + 128 * 1024)
-/*---
- * size in bytes reserved for initial data
-*/
-
-/*---
+/*
* SDRAM controller configuration
*/
#define CONFIG_SYS_FTSDMC020_TP0 (FTSDMC020_TP0_TRAS(2) |\
@@ -136,7 +132,7 @@
FTSDMC020_BANK_MBW_32 | \
FTSDMC020_BANK_SIZE_64M)
-/*---
+/*
* Physical Memory Map
*/
#define CONFIG_NR_DRAM_BANKS 1 /* we have 1 bank of DRAM */
@@ -159,7 +155,7 @@
#define CONFIG_SYS_TEXT_BASE 0
-/*---
+/*
* Static memory controller configuration
*/
@@ -198,7 +194,7 @@
{ FTSMC020_BANK1_CONFIG, FTSMC020_BANK1_TIMING, }, \
}
-/*---
+/*
* FLASH and environment organization
*/
--
1.6.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] arm: a320: enable tagged list support
From: Po-Yu Chuang Signed-off-by: Po-Yu Chuang --- include/configs/a320evb.h |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/include/configs/a320evb.h b/include/configs/a320evb.h index f832d52..62913b5 100644 --- a/include/configs/a320evb.h +++ b/include/configs/a320evb.h @@ -25,6 +25,12 @@ #include /* + * Linux kernel tagged list + */ +#define CONFIG_CMDLINE_TAG +#define CONFIG_SETUP_MEMORY_TAGS + +/* * CPU and Board Configuration Options */ #undef CONFIG_USE_IRQ /* we don't need IRQ/FIQ stuff */ -- 1.6.3.3 ___ 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
On Sun, May 15, 2011 at 10:51 PM, Wolfgang Denk wrote: > Dear Simon Glass, > > In message you wrote: >> >> Being a boot loader, charged with basic hardware initialisation, I believe >> bitfield access primitives should be well-supported by U-Boot. > > I agree, and they are. Hi Wolfgang, Well there is something there, but we can always do better. > >> Would you consider an RFC patch to add pan-U-Boot bitfield operations? >> Failing that, how about just for ARM? > > I fail to understand what you mean. We already have such > implementations in place. I just oobject against adding new, > non-standard ones when the existing ones perform the same purpose. There are a few very primitive macros in setbits and clrbits. I would very much like to see at least: - 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 example - 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. 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 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. Regards, Simon > > 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 think it's a new feature. Don't tell anyone it was an accident. :-) > -- Larry Wall on s/foo/bar/eieio in <10...@jpl-devvax.jpl.nasa.gov> > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2] bootp: add ntpserver option to bootp request
Hi Sergei, On Mon, May 16, 2011 at 11:57 PM, Sergei Shtylyov wrote: > Hello. > > On 16-05-2011 6:24, Chris Packham wrote: > >> From: Luuk Paulussen > >> Signed-off-by: Luuk Paulussen >> Acked-by: Chris Packham >> Cc: Ben Warren > > [...] > >> diff --git a/net/bootp.c b/net/bootp.c >> index 4db63cb..18c743e 100644 >> --- a/net/bootp.c >> +++ b/net/bootp.c >> @@ -228,6 +228,11 @@ static void BootpVendorFieldProcess (u8 * ext) >> NetOurNISDomain[size] = 0; >> } >> break; >> +#if defined(CONFIG_CMD_SNTP)&& defined(CONFIG_BOOTP_NTPSERVER) >> + case 42: /* NTP server IP */ >> + NetCopyIP (&NetNtpServerIP, (IPaddr_t *) (ext + 2)); > > There should be no space between function name and (. You're now supposed > to run your patch thru scripts/checkpatch.pl (from Linux source tree). Will fix (and run through checkpatch.pl) in next version. >> + break; >> +#endif >> /* Application layer fields */ >> case 43: /* Vendor specific info - Not yet supported >> */ >> /* >> @@ -538,6 +548,11 @@ static int BootpExtended (u8 * e) >> *e++ = 32; >> e += 32; >> #endif >> +#if defined(CONFIG_BOOTP_NTPSERVER) >> + *e++ = 42; > > Too many spaces... Ditto. >> + *e++ = 4; >> + e += 4; >> +#endif > > WBR, Sergei > v3 coming shortly ___ 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
Signed-off-by: Luuk Paulussen
Acked-by: Chris Packham
Cc: Prafulla Wadaskar
---
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
+#include
+#include
+#include
+#include
+
+#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 + 1) << 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) - 1;
+ /* 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] sntp: avoid use of uninitialized variable
From: Luuk Paulussen
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
Acked-by: Chris Packham
Cc: Ben Warren
---
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;
}
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCHv3] bootp: add ntpserver option to bootp request
From: Luuk Paulussen
Signed-off-by: Luuk Paulussen
Acked-by: Chris Packham
Cc: Ben Warren
---
Changes since v1:
- fixed compile error in BootpVendorProcess when CONFIG_CMD_SNTP is not
defined
Changes since v2:
- run though checkpatch.pl. Address comments from Sergei.
net/bootp.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/net/bootp.c b/net/bootp.c
index 4db63cb..45eaab1 100644
--- a/net/bootp.c
+++ b/net/bootp.c
@@ -228,6 +228,11 @@ static void BootpVendorFieldProcess (u8 * ext)
NetOurNISDomain[size] = 0;
}
break;
+#if defined(CONFIG_CMD_SNTP) && defined(CONFIG_BOOTP_NTPSERVER)
+ case 42:/* NTP server IP */
+ NetCopyIP(&NetNtpServerIP, (IPaddr_t *) (ext + 2));
+ break;
+#endif
/* Application layer fields */
case 43:/* Vendor specific info - Not yet supported
*/
/*
@@ -278,6 +283,11 @@ static void BootpVendorProcess (u8 * ext, int size)
if (NetBootFileSize)
debug("NetBootFileSize: %d\n", NetBootFileSize);
+
+#if defined(CONFIG_CMD_SNTP) && defined(CONFIG_BOOTP_NTPSERVER)
+ if (NetNtpServerIP)
+ debug("NetNtpServerIP : %pI4\n", &NetNtpServerIP);
+#endif
}
/*
* Handle a BOOTP received packet.
@@ -538,6 +548,11 @@ static int BootpExtended (u8 * e)
*e++ = 32;
e += 32;
#endif
+#if defined(CONFIG_BOOTP_NTPSERVER)
+ *e++ = 42;
+ *e++ = 4;
+ e += 4;
+#endif
*e++ = 255; /* End of the list */
--
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 3/3] MX53: Add initial support for MX53ARD board
Hi, Fabio, 2011/5/17 Fabio Estevam : > Signed-off-by: Fabio Estevam > --- > Changes since v1: > - Use io accessors to access weim and iomuxc > - Initialize the 2 esdhc controllers > - Configure the 2 banks of DDR memory > - Fix typo on machine_id > - Remove CONFIG_SYS_BOOTMAPSZ from config file > > MAINTAINERS | 1 + > board/freescale/mx53ard/Makefile | 48 + > board/freescale/mx53ard/imximage.cfg | 96 +++ > board/freescale/mx53ard/mx53ard.c | 314 > ++ > boards.cfg | 1 + > include/configs/mx53ard.h | 193 + > 6 files changed, 653 insertions(+), 0 deletions(-) > create mode 100644 board/freescale/mx53ard/Makefile > create mode 100644 board/freescale/mx53ard/imximage.cfg > create mode 100644 board/freescale/mx53ard/mx53ard.c > create mode 100644 include/configs/mx53ard.h > We have two version of ARD board, one is DDR3 board, Had better specify which ARD board this patch support? Jason Liu > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] MX5: Add iomux structure
Hi, Fabio,
2011/5/17 Fabio Estevam :
> Signed-off-by: Fabio Estevam
> ---
> Changes since v1:
> - iomuxc was accessed directly in v1, so create a iomux struct
> so that we can use io accessors
>
> arch/arm/include/asm/arch-mx5/imx-regs.h | 11 +++
> 1 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-mx5/imx-regs.h
> b/arch/arm/include/asm/arch-mx5/imx-regs.h
> index d80e0c0..eb690ec 100644
> --- a/arch/arm/include/asm/arch-mx5/imx-regs.h
> +++ b/arch/arm/include/asm/arch-mx5/imx-regs.h
> @@ -273,6 +273,17 @@ struct weim {
> u32 ear;
> };
>
> +struct iomuxc {
> + u32 gpr0;
> + u32 gpr1;
> + u32 gpr2;
> + u32 omux0;
> + u32 omux1;
> + u32 omux2;
> + u32 omux3;
> + u32 omux4;
> +};
I think iomux register does not limited to the above registers and you
defined some unused register
such as IOMUXC_OBSERVE_MUX_0, if you only use gpr, you can just define
iomuxc_gpr etc.
And what's more, mx51 and mx53 has different layout, on i.mx51, the layout is:
IOMUXC_GPR0,
IOMUXC_GPR1,
IOMUXC_OBSERVE_MUX_0,
IOMUXC_OBSERVE_MUX_1,
IOMUXC_OBSERVE_MUX_2,
IOMUXC_OBSERVE_MUX_3,
so, you can't simply put it to the common head file for all the i.mx5 soc.
> +
> /* GPIO Registers */
> struct gpio_regs {
> u32 gpio_dr;
> --
> 1.6.0.4
>
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] MX5: Make the weim structure complete
Hi, Fabio,
2011/5/17 Fabio Estevam :
> 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.
> Signed-off-by: Fabio Estevam
> ---
> 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 {
>
Jason Liu
> --
> 1.6.0.4
>
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] MX31: Make get_reset_cause() static
Hi, Stefano,
2011/5/16 Stefano Babic :
> Signed-off-by: Fabio Estevam
> Signed-off-by: Stefano Babic
> ---
>
> Changes since V1:
> - as get_cpu_rev is exported, only get_reset_cause
> is set to static.
>
> arch/arm/cpu/arm1136/mx31/generic.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/cpu/arm1136/mx31/generic.c
> b/arch/arm/cpu/arm1136/mx31/generic.c
> index fccd2cd..fb01013 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 =
> --
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.
char *get_reset_cause(void)
{
/* read RCSR register from CCM module */
struct clock_control_regs *ccm =
(struct clock_control_regs *)CCM_BASE;
u32 cause = readl(&ccm->rcsr) & 0x07;
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";
}
}
Jason Liu
> 1.7.1
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 02/10] armv7: add miscellaneous utility macros
Dear Simon Glass, In message 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? > 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. > 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. 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 Forty two. ___ 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
Hi, Stefano,
2011/5/16 Stefano Babic :
> 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: m>0 and n>0. 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 M
[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 To: Wolfgang Denk Hi Wolfgang, On Monday 16 May 2011 01:29 AM, Wolfgang Denk wrote: > Dear Aneesh V, > > In message<1305472900-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 message<4dd1189d.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 V >>> ... + /* 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 V 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
