Re: [U-Boot] [PATCH 1/1] MX5: clock: Add clock config interface
Hi, Stefano, 2011/4/13 Jason Liu jason@linaro.org: Add clock config interface support, so that we can configure CPU or DDR clock in the later init Signed-off-by: Jason Liu jason@linaro.org --- arch/arm/cpu/armv7/mx5/clock.c | 551 +- arch/arm/include/asm/arch-mx5/clock.h | 4 + arch/arm/include/asm/arch-mx5/crm_regs.h | 6 + arch/arm/include/asm/arch-mx5/imx-regs.h | 1 + 4 files changed, 559 insertions(+), 3 deletions(-) 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? Jason ___ 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 0/4] Accurate boot time measurement
On Mon, May 16, 2011 at 3:56 PM, Wolfgang Denk w...@denx.de wrote:
Dear Graeme Russ,
In message banlktinsypvnpg06uolze65t-fcqdn_...@mail.gmail.com you wrote:
I've thought of a 'better' approach:
- Do no modify the parameters of show_boot_progress()
- Create a new struct:
struct boot_progress_msg {
int boot_progress_id;
const char *message;
{
Where do you store this data _before_ relocation, when we have no
access to RAM yet?
This data is Read-Only so pre/post relocation is not an issue. The boot
stage records however are a problem
Regards,
Graeme
___
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 3:55 PM, Wolfgang Denk w...@denx.de wrote: Dear Graeme Russ, In message BANLkTim7=-rza_l-dy0b-+adqv4ngol...@mail.gmail.com you wrote: But at 9600 baud it is over 1ms - 9600 is still considered the lowest common denominator for serial comms for diagnostic output for a lot of devices such as industrial PLCs etc. I think in the last 5 years I have seen but 2 devices using 9600 bps. All others appear to be using 115200 bps these days. And even at 9600 we're still close to millisecond reolution... And in the field, you may be interested more in transient timing anomalies which may result from network issues if the device is obtaining an IP address or loading an image file. In such scenarios, you will need to log the boot timing of every boot, not just when a serial terminal is connected 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 And finally, the lack of a serial port is a biggie - There are devices out there that do not have serial ports If they have a console interface, then the output can be time-stamped. See above Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/1] mx5: board: code clean up for checkboard code
On 05/16/2011 07:48 AM, Jason Liu wrote: Hi,Stefano, Any comments, if not, please pull it, thanks. No, I have not. I will pull it. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/1] mx5: board: code clean up for checkboard code
On 04/22/2011 02:55 PM, Jason Liu wrote: The boot cause code has been factor out to soc common code,we need drop the part from the board support code This patch also remove the redundant cpu version print 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
Re: [U-Boot] [PATCH 0/4] Accurate boot time measurement
On Mon, May 16, 2011 at 3:48 PM, Wolfgang Denk w...@denx.de wrote: Dear Simon Glass, In message BANLkTi=0ijj7dnlsjovo-3eqjmw+rso...@mail.gmail.com 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. 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. - 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. Fine if your running Linux - What if the only tool tyou have is Hyperterminal? 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. 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? If it can be compiled by U-Boot and passed to the OS then the OS can do the ou 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? Maybe it can be retrieved over a network connection 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? 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 resort to network sniffing but if the problem is intermittent, this is very hit and miss. If you have several devices on a network and you can see the breakdown of the bootstage on each individual device, traking down the problem is much easier - Is it a associated with a common network function (DHCP/TFTP)? A common network segment, a particular file being TFTP'd? - 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? - It does not cause execution overhead on the running system - it affects neither the execution speed not the memory footprint of the target under test. 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 transmit direction in U-Boot. what is happening. The overhead of bootstage is a function call, a readl(), a a few memory accesses and an optional strcpy. It is much cheaper than outputting a serial character. 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 approach, i. e. which problems can be addressed with your code where the output timing method cannot be used, or where it is less efficient? With a little bit of cheating I can think of 10: 1. It doesn't need a serial watcher to be connected, which is not available in the field, and is something that anyway would only be attached when the engineer is not using the console for actually typing commands. OK, not needing a console port during boot is indeed an advantage. It comes at the cost of needing log space, which is not
Re: [U-Boot] [PATCH 1/1] MX5: clock: Add clock config interface
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. Anyway, I will send today my comments on this patch. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MMC S5P: Fix typo
Dear Dirk Behme, On 16 May 2011 00:39, Dirk Behme dirk.be...@googlemail.com wrote: From: Dirk Behme dirk.be...@googlemail.com 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 dirk.be...@googlemail.com CC: John Rigby john.ri...@linaro.org CC: Andy Fleming aflem...@freescale.com --- 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 sba...@denx.de: 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 sgui...@lacie.com
---
Changes for v2:
- add entries to MAINTAINERS file
- move boards from root Makefile to boards.cfg
- move MACH_TYPE definition into netspace_v2.h
- remove CONFIG_SYS_HZ redefinition
- turn PHY initialization message into debug()
Changes for v3: none
Changes for v4:
- enhance commit message: add SoC information
Changes for v5: none
Changes for v6:
- enable device tree support
- clean some #define in netspace_v2.h
- enhance commit message: provide description URL and mention SoC
family
- rebase against u-boot-{arm,marvell}/master branches
Changes for v7:
- rebase against u-boot-marvell/master branch
Changes for v8:
- update commit title (add netspace_v2 parents information).
- move GPIO button definition into header file.
- update CONFIG_IDENT_STRING with boards alias.
- handle wrong board definition.
- by default, use DHCP to get IP address.
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 ratb...@faraday-tech.com Signed-off-by: Po-Yu Chuang ratb...@faraday-tech.com --- 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 asm/arch/a320.h /*--- + * 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 nick.thomp...@ge.com 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 jh80.ch...@samsung.com
signed-off-by: Minkyu Kang mk7.k...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
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;
+
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: m0 and n0. Let g=gcd(m,n). */
+static int gcd(int m, int n)
+{
+ int t;
+ while (m 0) {
+ if (n m) {
+ t = m;
+ m = n;
+ n = t;
+ } /* swap */
+ m -= n;
+ }
+ return n;
+}
This function has nothing to do with MX5 code. This is a general
function, and should be add to lib/. I think you have to remove it from
here and put it in a separate patch.
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. You can at least move the memset inside this function, if
it is used by all callers.
+ for
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 fabio.este...@freescale.com --- 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 ane...@ti.com
Add the basic spl framework and linker script common for OMAP3/4
platforms.
Signed-off-by: Aneesh V ane...@ti.com
---
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, www.ti.com
+ *
+ * Aneesh V ane...@ti.com
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+#include common.h
+#include asm/u-boot.h
+#include asm/arch/sys_proto.h
+#include timestamp_autogenerated.h
+
+/* 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, ga...@denx.de
+ *
+ * (C) Copyright 2010
+ * Texas Instruments, www.ti.com
+ * Aneesh V ane...@ti.com
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+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 fabio.este...@freescale.com
Signed-off-by: Stefano Babic sba...@denx.de
---
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 fabio.este...@freescale.com #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 hongbo.zh...@windriver.com 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 bocui...@gmail.com 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 bocui...@gmail.com 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 message1305472900-4004-2-git-send-email-ane...@ti.com you wrote:
From: John Rigbyjohn.ri...@linaro.org
Signed-off-by: John Rigbyjohn.ri...@linaro.org
---
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 sba...@denx.de: 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 fabio.este...@freescale.com #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 jason@linaro.org 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 mk7.k...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
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 asm/io.h
/* 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 s...@denx.de Cc: Scott Wood scottw...@freescale.com --- 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 banlktim55mvfj-fdekea3gsbvqnnaic...@mail.gmail.com 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 BANLkTi=u4gj+ci8hpfv95m8nynyedhg...@mail.gmail.com 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 ratb...@faraday-tech.com Signed-off-by: Po-Yu Chuang ratb...@faraday-tech.com --- 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 asm/arch/a320.h /*--- + * 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 luuk.paulus...@alliedtelesis.co.nz Signed-off-by: Luuk Paulussenluuk.paulus...@alliedtelesis.co.nz Acked-by: Chris Packhamchris.pack...@alliedtelesis.co.nz Cc: Ben Warrenbiggerbadder...@gmail.com [...] 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 message1305472900-4004-3-git-send-email-ane...@ti.com you wrote:
Signed-off-by: Aneesh Vane...@ti.com
---
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 message1305472900-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 Vane...@ti.com ... +/* Store the boot device in omap4_boot_device */ +ldr r2, [r0, #BOOT_DEVICE_OFFSET] @ r1- value of boot device +and r2, #BOOT_DEVICE_MASK +ldr r3, =omap4_boot_device +str r2, [r3]@ omap4_boot_device- r1 Why don't you use stadard global data here? SPL has access to .data right from the beginning. Besides this is too early. global data is not initialized yet. 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 message1305472900-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 Vane...@ti.com --- 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 grinb...@compulab.co.il
---
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 message1305472900-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 Vane...@ti.com --- 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/vendor/board/ . Let spl/board/vendor/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 message1305472900-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 Vane...@ti.com
...
+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 w...@denx.de 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 message1305472900-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 Vane...@ti.com --- 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 e...@cmu.edu 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 message1305202276-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 Vane...@ti.com ... + /* Store the boot device in omap4_boot_device */ + ldr r2, [r0, #BOOT_DEVICE_OFFSET] @ r1- value of boot device + and r2, #BOOT_DEVICE_MASK + ldr r3, =omap4_boot_device + str r2, [r3]@ omap4_boot_device- r1 Why don't you use stadard global data here? SPL has access to .data right from the beginning. Besides this is too early. global data is not initialized yet. Please keep in mind that this is a special situation then. The code will not work as intended for example when running form NOR flash. 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/vendor/board/ . Let spl/board/vendor/board/Makefile decide what it wants to build. There are common, board independent parts both in spl/nand and spl/onenand. 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 BANLkTin6o4OEp7aBfCsxpt=z5oztoxv...@mail.gmail.com 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 w...@denx.de wrote:
Dear Simon Glass,
In message BANLkTi=0ijj7dnlsjovo-3eqjmw+rso...@mail.gmail.com 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 transmit direction in U-Boot.
It does save time.
what is
Re: [U-Boot] [PATCH 0/4] Accurate boot time measurement
On Mon, 16 May 2011 13:40:20 +0200
Wolfgang Denk w...@denx.de wrote:
Dear Graeme Russ,
In message BANLkTi=u4gj+ci8hpfv95m8nynyedhg...@mail.gmail.com 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 BANLkTi=wdddekljobfroncqzxjn9ugn...@mail.gmail.com 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 ane...@ti.com wrote:
diff --git a/Makefile b/Makefile
index 384a59e..d3f4bef 100644
--- a/Makefile
+++ b/Makefile
@@ -289,6 +289,22 @@ LDPPFLAGS += \
$(shell $(LD) --version | \
sed -ne 's/GNU ld version
\([0-9][0-9]*\)\.\([0-9][0-9]*\).*/-DLD_MAJOR=\1 -DLD_MINOR=\2/p')
+ifeq ($(CONFIG_NAND_U_BOOT),y)
+NAND_SPL = nand_spl
+U_BOOT_NAND = $(obj)u-boot-nand.bin
+endif
+
+ifeq ($(CONFIG_SPL),y)
+.PHONEY : SPL
+ALL += SPL
+endif
+
+ifeq ($(CONFIG_ONENAND_U_BOOT),y)
+ONENAND_IPL = onenand_ipl
+U_BOOT_ONENAND = $(obj)u-boot-onenand.bin
+ONENAND_BIN ?= $(obj)onenand_ipl/onenand-ipl-2k.bin
+endif
+
__OBJS := $(subst $(obj),,$(OBJS))
__LIBS := $(subst $(obj),,$(LIBS)) $(subst $(obj),,$(LIBBOARD))
@@ -402,8 +418,13 @@ $(obj)u-boot.lds: $(LDSCRIPT)
$(CPP) $(CPPFLAGS) $(LDPPFLAGS) -ansi -D__ASSEMBLY__ -P - $^
$@
nand_spl:$(TIMESTAMP_FILE) $(VERSION_FILE) depend
+
+$(NAND_SPL): $(TIMESTAMP_FILE) $(VERSION_FILE) depend
You are reverting part of e935a374dbe5c745fdde05b2b07ced0bbe70887f. Merge
accident?
@@ -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 ane...@ti.com 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/vendor/board/ . Let spl/board/vendor/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 ane...@ti.com 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 ane...@ti.com 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 s...@denx.de Cc: Scott Wood scottw...@freescale.com --- 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 a...@nucleodyne.us 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 Ceresoliluca.ceres...@comelit.it
Cc: Wolfgang Denkw...@denx.de
---
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 message4dbff3af.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 w...@denx.de 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, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Life would be so much
[U-Boot] [PATCH 1/1] Fix hang when entering udelay after GPTIMER2 overflows (about 22 minutes on AM37x)
Signed-off-by: Rick Bronson r...@efn.org
---
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 fabio.este...@freescale.com
---
Changes since v1:
- Make the weim struct complete
arch/arm/include/asm/arch-mx5/imx-regs.h | 46 ++
1 files changed, 40 insertions(+), 6 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx5/imx-regs.h
b/arch/arm/include/asm/arch-mx5/imx-regs.h
index a1849f8..d80e0c0 100644
--- a/arch/arm/include/asm/arch-mx5/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx5/imx-regs.h
@@ -41,6 +41,7 @@
#define CSD1_BASE_ADDR 0xB000
#define NFC_BASE_ADDR_AXI 0xF7FF
#define IRAM_BASE_ADDR 0xF800
+#define CS1_BASE_ADDR 0xF400
#else
#error CPU_TYPE not defined
#endif
@@ -231,12 +232,45 @@ struct clkctl {
/* WEIM registers */
struct weim {
- u32 csgcr1;
- u32 csgcr2;
- u32 csrcr1;
- u32 csrcr2;
- u32 cswcr1;
- u32 cswcr2;
+ u32 cs0gcr1;
+ 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 fabio.este...@freescale.com
---
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 fabio.este...@freescale.com --- 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 kristoffer.eric...@gmail.com Fabio Estevam fabio.este...@freescale.com mx31pdk i.MX31 + mx53ard i.MX53 mx53smd i.MX53 Peter Figuli pep...@etc.sk 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 l...@denx.de +# +# (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
Re: [U-Boot] [PATCH 0/4] Accurate boot time measurement
On Mon, May 16, 2011 at 9:40 PM, Wolfgang Denk w...@denx.de wrote:
Dear Graeme Russ,
In message BANLkTi=u4gj+ci8hpfv95m8nynyedhg...@mail.gmail.com 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
insert you local currency here 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 w...@denx.de wrote: Dear Po-Yu Chuang, In message 1305531660-1595-1-git-send-email-ratbert.chu...@gmail.com you wrote: From: Po-Yu Chuang ratb...@faraday-tech.com Signed-off-by: Po-Yu Chuang ratb...@faraday-tech.com --- 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 asm/arch/a320.h /*--- + * 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 ratb...@faraday-tech.com
Signed-off-by: Po-Yu Chuang ratb...@faraday-tech.com
---
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 asm/arch/a320.h
-/*---
+/*
* 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 config_cmd_default.h
@@ -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 ratb...@faraday-tech.com Signed-off-by: Po-Yu Chuang ratb...@faraday-tech.com --- 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 asm/arch/a320.h /* + * 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 w...@denx.de wrote: Dear Simon Glass, In message BANLkTi=zl-whpe9mxdgbzzxoeaz10pb...@mail.gmail.com 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 sshtyl...@mvista.com wrote: Hello. On 16-05-2011 6:24, Chris Packham wrote: From: Luuk Paulussen luuk.paulus...@alliedtelesis.co.nz Signed-off-by: Luuk Paulussenluuk.paulus...@alliedtelesis.co.nz Acked-by: Chris Packhamchris.pack...@alliedtelesis.co.nz Cc: Ben Warrenbiggerbadder...@gmail.com [...] 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 luuk.paulus...@alliedtelesis.co.nz
Signed-off-by: Luuk Paulussen luuk.paulus...@alliedtelesis.co.nz
Acked-by: Chris Packham chris.pack...@alliedtelesis.co.nz
Cc: Prafulla Wadaskar prafu...@marvell.com
---
Changes since v1:
- run through checkpatch.pl and fix style issues (spaces before bracket and
lines 80 chars)
arch/arm/include/asm/arch-kirkwood/kirkwood.h |2 +
drivers/rtc/Makefile |1 +
drivers/rtc/kirkwood.c| 79 +
3 files changed, 82 insertions(+), 0 deletions(-)
create mode 100644 drivers/rtc/kirkwood.c
diff --git a/arch/arm/include/asm/arch-kirkwood/kirkwood.h
b/arch/arm/include/asm/arch-kirkwood/kirkwood.h
index 0104418..15922eb 100644
--- a/arch/arm/include/asm/arch-kirkwood/kirkwood.h
+++ b/arch/arm/include/asm/arch-kirkwood/kirkwood.h
@@ -50,6 +50,8 @@
#define KW_MPP_BASE(KW_REGISTER(0x1))
#define KW_GPIO0_BASE (KW_REGISTER(0x10100))
#define KW_GPIO1_BASE (KW_REGISTER(0x10140))
+#define KW_RTC_TIME(KW_REGISTER(0x10300))
+#define KW_RTC_DATE(KW_REGISTER(0x10304))
#define KW_NANDF_BASE (KW_REGISTER(0x10418))
#define KW_SPI_BASE(KW_REGISTER(0x10600))
#define KW_CPU_WIN_BASE(KW_REGISTER(0x2))
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index e4be4a4..ec064d9 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -43,6 +43,7 @@ COBJS-$(CONFIG_RTC_DS174x) += ds174x.o
COBJS-$(CONFIG_RTC_DS3231) += ds3231.o
COBJS-$(CONFIG_RTC_FTRTC010) += ftrtc010.o
COBJS-$(CONFIG_RTC_ISL1208) += isl1208.o
+COBJS-$(CONFIG_RTC_KIRKWOOD) += kirkwood.o
COBJS-$(CONFIG_RTC_M41T11) += m41t11.o
COBJS-$(CONFIG_RTC_M41T60) += m41t60.o
COBJS-$(CONFIG_RTC_M41T62) += m41t62.o
diff --git a/drivers/rtc/kirkwood.c b/drivers/rtc/kirkwood.c
new file mode 100644
index 000..b08fd91
--- /dev/null
+++ b/drivers/rtc/kirkwood.c
@@ -0,0 +1,79 @@
+/*
+ * Driver for the RTC in Marvell SoCs.
+ *
+ * Based on Linux Kernel driver.
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include common.h
+#include command.h
+#include rtc.h
+#include bcd.h
+#include asm/arch/kirkwood.h
+
+#if defined(CONFIG_CMD_DATE)
+
+#define RTC_TIME_REG_OFFS 0
+#define RTC_SECONDS_OFFS 0
+#define RTC_MINUTES_OFFS 8
+#define RTC_HOURS_OFFS 16
+#define RTC_WDAY_OFFS 24
+#define RTC_HOURS_12H_MODE (1 22) /* 12 hours mode */
+
+#define RTC_DATE_REG_OFFS 4
+#define RTC_MDAY_OFFS 0
+#define RTC_MONTH_OFFS 8
+#define RTC_YEAR_OFFS 16
+#define KIRKWOOD_YEAR_BASE 2000
+
+int rtc_set(struct rtc_time *tmp)
+{
+ ulong rtc_reg;
+
+ GregorianDay(tmp);
+
+ rtc_reg = (bin2bcd(tmp-tm_sec) RTC_SECONDS_OFFS) |
+ (bin2bcd(tmp-tm_min) RTC_MINUTES_OFFS) |
+ (bin2bcd(tmp-tm_hour) RTC_HOURS_OFFS) |
+ (bin2bcd(tmp-tm_wday) RTC_WDAY_OFFS);
+ writel(rtc_reg, KW_RTC_TIME);
+
+ rtc_reg = (bin2bcd(tmp-tm_mday) RTC_MDAY_OFFS) |
+ (bin2bcd(tmp-tm_mon + 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 luuk.paulus...@alliedtelesis.co.nz
When we use the ntpserverip environment variable argv[1] may not be set.
Printing the error message using the NetNtpServerIP variable ensures the
correct output in both cases.
Signed-off-by: Luuk Paulussen luuk.paulus...@alliedtelesis.co.nz
Acked-by: Chris Packham chris.pack...@alliedtelesis.co.nz
Cc: Ben Warren biggerbadder...@gmail.com
---
Changes since v1:
- run through checkpatch.pl, fix line 80 chars
common/cmd_net.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/common/cmd_net.c b/common/cmd_net.c
index 8c6f5c8..fae3c7f 100644
--- a/common/cmd_net.c
+++ b/common/cmd_net.c
@@ -324,7 +324,8 @@ int do_sntp (cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
else NetTimeOffset = simple_strtol (toff, NULL, 10);
if (NetLoop(SNTP) 0) {
- printf(SNTP failed: host %s not responding\n, argv[1]);
+ printf(SNTP failed: host %pI4 not responding\n,
+ NetNtpServerIP);
return 1;
}
--
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 luuk.paulus...@alliedtelesis.co.nz Signed-off-by: Luuk Paulussen luuk.paulus...@alliedtelesis.co.nz Acked-by: Chris Packham chris.pack...@alliedtelesis.co.nz Cc: Ben Warren biggerbadder...@gmail.com --- 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 fabio.este...@freescale.com: Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- 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 fabio.este...@freescale.com:
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
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 fabio.este...@freescale.com:
Make the weim register set complete for MX51/MX53.
While at it also add the weim chip select 1 address definition.
From the code, you just add the cs for mx53 not for mx51, so,
Had better specify you add the cs1 address definition for mx53,
otherwise, it will make confusion.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Changes since v1:
- Make the weim struct complete
arch/arm/include/asm/arch-mx5/imx-regs.h | 46
++
1 files changed, 40 insertions(+), 6 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx5/imx-regs.h
b/arch/arm/include/asm/arch-mx5/imx-regs.h
index a1849f8..d80e0c0 100644
--- a/arch/arm/include/asm/arch-mx5/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx5/imx-regs.h
@@ -41,6 +41,7 @@
#define CSD1_BASE_ADDR 0xB000
#define NFC_BASE_ADDR_AXI 0xF7FF
#define IRAM_BASE_ADDR 0xF800
+#define CS1_BASE_ADDR 0xF400
#else
#error CPU_TYPE not defined
#endif
@@ -231,12 +232,45 @@ struct clkctl {
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 sba...@denx.de:
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
Signed-off-by: Stefano Babic sba...@denx.de
---
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 banlktine7bfsyousgxwg0rg3ownbpn_...@mail.gmail.com you wrote: There are a few very primitive macros in setbits and clrbits. I would very much like to see at least: Maybe we can agree to use these existing macros then instead of inventing new ones with the same functionality. - 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
