Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
On Fri, 04 Sep 2009 22:05:45 +0200 Wolfgang Denk w...@denx.de wrote: nand_bbt: Can't scan flash and build the RAM-based BBT Net: egiga0 88E1116 Initialized on egiga0 Hit any key to stop autoboot: 0 Marvell The 4.1 version just hangs on the NAND printout. I've tested both with USE_PRIVATE_LIBGCC=yes and USE_PRIVATE_LIBGCC unset, and get the same results. Did you make any progress an analyzing the cause of the issue? Well, I sent a patch [PATCH, RFC] Make arm926ejs use -march=armv5t to avoid problems with EABI, which corrects this for me, although I'd like some input on if it really makes any sense. The main difference I see between the two binaries is the use of ldrd/strd instructions, which comes with the e-version of armv5t. Obviously, that shouldn't by itself produce broken binaries, so something is still fishy here. // Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 4/4]: arm: Define test_and_set_bit and test_and_clear bit for ARM
Hi Justin!
On Fri, 4 Sep 2009 17:27:59 -0400
Justin Waters justin.wat...@timesys.com wrote:
I found a slight problem with this section of the patch:
On Mon, 2009-08-24 at 03:10 -0400, Simon Kagstrom wrote:
diff --git a/include/asm-arm/bitops.h b/include/asm-arm/bitops.h
index 854e225..3c7b00c 100644
--- a/include/asm-arm/bitops.h
+++ b/include/asm-arm/bitops.h
@@ -17,6 +17,8 @@
#ifdef __KERNEL__
+#include asm/proc/system.h
+
It causes a compiler error on the arm926ejs platform:
In file included from cpu.c:34:
/home/justin/git/u-boot/include/asm/system.h: At top level:
/home/justin/git/u-boot/include/asm/system.h:71: error: expected
identifier or '(' before 'asm'
I did some digging, and it looks like set_cr() is implemented by both
asm-arm/system.h and asm-arm/proc-armv/system.h. One implements the
function as a macro, while the other uses a standard C function, hence
the weird error message. The conflict occurs in cpu/arm926ejs/cpu.c.
You are right, but I believe this was fixed an earlier patch, [PATCH]
Remove duplicate set_cr [1], which is in the ARM tree. I guess that
one hasn't shown up in Wolfgangs repository yet, so this series must be
applied to the ARM tree for now.
Thanks for testing!
// Simon
[1]
http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commit;h=f3d4f8870e69e0fd177397778d97d0751bbd020a
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC: split ARM repo and distribute workload
-Original Message- From: Jean-Christophe PLAGNIOL-VILLARD [mailto:plagn...@jcrosoft.com] Sent: Saturday, September 05, 2009 4:48 AM To: Wolfgang Denk Cc: u-boot@lists.denx.de; Tom Rix; Magnus Lilja; Prafulla Wadaskar; Dirk Behme; Minkyu Kang; Kyungmin Park; Harald Welte Subject: Re: RFC: split ARM repo and distribute workload On 23:57 Fri 04 Sep , Wolfgang Denk wrote: Hello everybody, ARM has always been one of the architectures that generated a big number of different processors and SoCs, but recently the activitiy in this area is literally exploding. This is partially due to the fact that ARM is currently used in many designs, so many new ARM based processors and SoCs and even more new ARM boards show up, but another and at least as important change is that some silicon and board vendors have started to actively pushing their products into the U-Boot (and Linux) mainline source trees (and *welcome* they all are!). It has become evident that this growing complexity has become way too massive to be shouldered by a single custodian, even a very active one like Jean-Christophe. I think we have no other choice but to add more manpower to this task, i. e. split the ARM respository and distribute the workload across a few more custodians. Unline with the Power architecture, where the split can be easily defined by processor lines, with ARM it seems more logical to me to differentiate by silicon vendors. After much thinking I therefor suggest to implement the following change for the ARM architecture: I think this will be better master ARM repository : Jean-Christophe Plagniol-Villard Freescale (i.MX) Magnus Lilja? Or are there any volunteers at Freescale? Marvell Prafulla Wadaskar This makes more sense for u-boot-mrvl.git (proposed) to go entire Marvell specific patches through it Regards.. Prafulla . . Samsung (s3c, s5pc): Are there any volunteers at Samsung? Texas Instruments (OMAP): Tom Rix Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MTD compile error
Hi Kumar, On Saturday 05 September 2009 20:28:11 Kumar Gala wrote: LOG/TQM8548_BE.ERR:common/libcommon.a(cmd_mtdparts.o): In function `part_validate_eraseblock': LOG/TQM8548_BE.ERR:/local/home/galak/git/u-boot-85xx/common/ cmd_mtdparts.c:316: undefined reference to `get_mtd_device_nm' LOG/TQM8548_BE.ERR:common/libcommon.a(cmd_mtdparts.o): In function `mtd_device_validate': LOG/TQM8548_BE.ERR:/local/home/galak/git/u-boot-85xx/common/ cmd_mtdparts.c:706: undefined reference to `get_mtd_device_nm' LOG/TQM8548_BE.ERR:make: *** [u-boot] Error 1 Please check if CONFIG_MTD_DEVICE is defined. Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] at91: Update MEESC board support
On Mon, 07 Sep 2009 09:26:17 +0200 Daniel Gorsulowski daniel.gorsulow...@esd.eu wrote: nack this will be done when u-boot will need to use the macb# Just imagine: U-boot boots a Linux kernel from NAND flash. It does NOT need the ethernet interface, so it does NOT initialize ethernet, so the ethernet address will NOT be written to the EMAC module! As a result, Linux will assign a random address, that is not acceptable! Unfortunately, you'll have to communicate this in some other way to Linux. I also had this problem and submitted a patch for it. In the replies there were some suggestions on how to handle this: http://lists.denx.de/pipermail/u-boot/2009-July/055725.html Unfortunately, there is no standard way of doing this on ARM. Some people want to introduce PowerPC-style device trees on ARM as well, where this is handled in a generic way, but that hasn't been done yet and requires changes on both the Linux-side and U-boot. So I believe this kind of patches will not be accepted, unfortunately. If you depend on the behavior, you can obviously keep the patch in your own tree. // Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM mach-types.h sync request
Wolfgang Denk schrieb: Dear Daniel Gorsulowski, In message 4aa0f7b2.2010...@esd.eu you wrote: Hi, according to http://lists.denx.de/pipermail/u-boot/2008-September/040553.html I request an update. It is needed for MACH_TYPE_ETHERCAN2 (based on MEESC board, patch will come soon.) The last kernel source was synced on 2009-06-20, and is also outdated. So please sync against http://www.arm.linux.org.uk/developer/machines/ Done. Hope this helps. Best regards, Wolfgang Denk Thank you! Best regards, Daniel Gorsulowski ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] at91: Update MEESC board support
Hello Wolfgang, Jean-Christophe,
Wolfgang Denk wrote:
Dear Daniel,
In message 20090904211358.gr30...@game.jcrosoft.org Jean-Christophe wrote:
+#ifdef CONFIG_REVISION_TAG
+u32 get_board_rev(void)
+{
+ return hw_rev | 0x100;
+}
+#endif
+
+int misc_init_r(void)
+{
+#ifdef CONFIG_MACB
+ u32 hwaddr_btm;
+ u16 hwaddr_top;
+ u8 mac[6];
+
+ /* Set ethernet address */
+ if (!eth_getenv_enetaddr(ethaddr, mac)) {
+ puts(Missing environment variable 'ethaddr'\n);
+} else {
+ hwaddr_btm = mac[0] | mac[1] 8 | mac[2] 16 | mac[3] 24;
+ hwaddr_top = mac[4] | mac[5] 8;
+ writel(hwaddr_btm, (void *)(AT91SAM9263_BASE_EMAC + MACB_SA1B));
+ writel(hwaddr_top, (void *)(AT91SAM9263_BASE_EMAC + MACB_SA1T));
nack this will be done when u-boot will need to use the macb#
Just imagine: U-boot boots a Linux kernel from NAND flash. It does NOT need the
ethernet interface, so it does NOT initialize ethernet, so the ethernet address
will NOT be written to the EMAC module!
As a result, Linux will assign a random address, that is not acceptable!
Jean-Christophe means: The Etherent interface must not be always
initialized, but only when it is needed and used within U-Boot itself,
i. e. if U-boot is performing anetwork command. See also item 2 at
http://www.denx.de/wiki/U-Boot/DesignPrinciples and
http://www.denx.de/wiki/view/DULG/EthernetDoesNotWorkInLinux
Best regards,
Wolfgang Denk
I know about it.
But this patch does NOT initialize the Ethernet Interface. It JUST write
the ethernet address to the EMAC module!
So please ACK this patch.
Regards,
Daniel Gorsulowski
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Microblaze repo update - patches
Hi Wolfgang, I added all Microblaze changes to my repo. Ben: Can you finally check LL-Temac driver? I haven't got any your reaction. I know you have just a lot of work. Wolfgang: There are two patches for you. First remove xilinx_emac.c driver and second cleanup license in xilinx_emaclite.c file. There are some microblaze related changes too. If is Ben ok with pulling ll-temac driver directly, Wolfgang please pull to your tree. If not, I'll remove that last LL_Temac patch. Thanks, Michal The following changes since commit 9f23ca42b3ba19b24e66fade572f2b86d929b6e8: Wolfgang Denk (1): ARM: Update mach-types are available in the git repository at: git://www.denx.de/git/u-boot-microblaze.git master Michal Simek (7): microblaze: Add sbss, scommon and COMMON symbols for clearing microblaze: Short size of global data and fix malloc size net: Remove old Xilinx Emac driver microblaze: Remove AtmarkTechno Suzaku board microblaze: Enable hush parser net: emaclite: Cleanup license to be GPL compatible net: [V3] Add LL TEMAC driver to u-boot and move Emaclite to NET_MULTI MAINTAINERS|4 - MAKEALL|1 - Makefile |5 - board/AtmarkTechno/suzaku/Makefile | 44 -- board/AtmarkTechno/suzaku/config.mk| 29 - board/AtmarkTechno/suzaku/flash.c | 46 -- board/AtmarkTechno/suzaku/suzaku.c | 32 -- board/AtmarkTechno/suzaku/u-boot.lds | 68 --- .../xilinx/microblaze-generic/microblaze-generic.c | 16 + board/xilinx/microblaze-generic/u-boot.lds |3 + drivers/net/Makefile |2 +- drivers/net/xilinx_emac.c | 464 drivers/net/xilinx_emaclite.c | 123 +++-- drivers/net/xilinx_ll_temac.c | 561 include/configs/microblaze-generic.h | 19 +- include/configs/suzaku.h | 110 include/netdev.h |2 + lib_microblaze/board.c | 21 +- 18 files changed, 674 insertions(+), 876 deletions(-) delete mode 100644 board/AtmarkTechno/suzaku/Makefile delete mode 100644 board/AtmarkTechno/suzaku/config.mk delete mode 100644 board/AtmarkTechno/suzaku/flash.c delete mode 100644 board/AtmarkTechno/suzaku/suzaku.c delete mode 100644 board/AtmarkTechno/suzaku/u-boot.lds delete mode 100644 drivers/net/xilinx_emac.c create mode 100644 drivers/net/xilinx_ll_temac.c delete mode 100644 include/configs/suzaku.h -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] How to burn new U-Boot over network
Hi, I'm working on the DM365evm, and i was wondering if there is a way to burn new U-Boot version over network, instead of Code Composer and a JTAG? Thanks, Alex -- View this message in context: http://www.nabble.com/-U-Boot--How-to-burn-new-U-Boot-over-network-tp25327003p25327003.html Sent from the Uboot - Users mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/10] mkconfig: parse top level makefile target to multiple config targets
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Saturday, September 05, 2009 3:43 AM To: Hu Mingkai-B21284 Cc: Kumar Gala; Wood Scott-B07421; U-Boot-Users ML; Mike Frysinger Subject: Re: [PATCH 01/10] mkconfig: parse top level makefile target to multiple config targets Dear Hu Mingkai-B21284, sorry for the late reply [I have to admit that I kind of loist track where we are with this discussion - too many diverging statements found]. In message 73839b4a0818e747864426270ac332c3043f5...@zmy16exm20.fsl.frees cale.net you wrote: How do you think of this method? Or can we handle the different options as follows? MPC8536DS_NAND_config: unconfig @echo $(obj)include/config.h; @echo #define CONFIG_$(subst MPC8536DS_,,$(subst config,U_BOOT,$@)) \ $(obj)include/config.h @$(MKCONFIG) -a MPC8536DS ppc mpc85xx mpc8536ds freescale @echo CONFIG_$(subst MPC8536DS_,,$(subst config,U_BOOT,$@)) = y \ $(obj)include/config.mk If there's an orthogonal option, such as 36BIT, we have to handle it seperately: MPC8536DS_NAND_config \ MPC8536DS_NAND_36BIT_config: unconfig @echo $(obj)include/config.h; @if [ $(findstring _36BIT_,$@ ] ; then \ echo #define CONFIG_PHYS_64BIT $(obj)include/config.h ; \ fi @echo #define CONFIG_$(subst MPC8536DS_,,$(subst config,U_BOOT,$@)) \ $(obj)include/config.h @$(MKCONFIG) -a MPC8536DS ppc mpc85xx mpc8536ds freescale @echo CONFIG_$(subst MPC8536DS_,,$(subst config,U_BOOT,$@)) = y \ $(obj)include/config.mk I don't like either of these. It should be enough to pass the make target name to the mkconfig script resp. the board config file, i. e. in this case either CONFIG_MPC8536DS_NAND or CONFIG_MPC8536DS_NAND_36BIT. The rest of the scripting/decision making can then be done in the board config file. Thanks for your replay, but I'm not totally catch on you. the board config file in your words refer to board/*/config.mk, right? If yes, in the config.mk file we parse the board config name to tell the file include/configs/MPC8536DS.h what config we have, such as, 36BIT, boot from NAND, etc, but how can I implement this? I try to use echo in config.mk to put the macro definition to the file include/config.h, but it complains the following errors: *** commands commence before first target. Stop. If you want to avoid conflicts, feel free to chose a distict prefix, say CONFIG_MK_* or CONFIG_MAKE_* or so. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de To get something done, a committee should consist of no more than three men, two of them absent. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
-Original Message- From: Simon Kagstrom [mailto:simon.kagst...@netinsight.net] Sent: Monday, September 07, 2009 11:54 AM To: Wolfgang Denk Cc: u-boot@lists.denx.de; Prafulla Wadaskar; Jean-Christophe PLAGNIOL-VILLARD Subject: Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support On Fri, 04 Sep 2009 22:05:45 +0200 Wolfgang Denk w...@denx.de wrote: nand_bbt: Can't scan flash and build the RAM-based BBT Net: egiga0 88E1116 Initialized on egiga0 Hit any key to stop autoboot: 0 Marvell The 4.1 version just hangs on the NAND printout. I've tested both with USE_PRIVATE_LIBGCC=yes and USE_PRIVATE_LIBGCC unset, and get the same results. Did you make any progress an analyzing the cause of the issue? Well, I sent a patch [PATCH, RFC] Make arm926ejs use -march=armv5t to avoid problems with EABI, which corrects this for me, although I'd like some input on if it really makes any sense. I have tested this with Sheevaplug, this patch even works well for me too. The Kirkwood specification says that the core is armv5te compliant But this change is global, applicable for all arm926ejs based SoC which isn't relevant too. Do anybody have similar test results with other processors? Since this is very specific NAND How about looking into NAND code? Regards.. Prafulla . . The main difference I see between the two binaries is the use of ldrd/strd instructions, which comes with the e-version of armv5t. Obviously, that shouldn't by itself produce broken binaries, so something is still fishy here. // Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
On Mon, 7 Sep 2009 01:59:13 -0700 Prafulla Wadaskar prafu...@marvell.com wrote: Well, I sent a patch [PATCH, RFC] Make arm926ejs use -march=armv5t to avoid problems with EABI, which corrects this for me, although I'd like some input on if it really makes any sense. I have tested this with Sheevaplug, this patch even works well for me too. The Kirkwood specification says that the core is armv5te compliant But this change is global, applicable for all arm926ejs based SoC which isn't relevant too. Do anybody have similar test results with other processors? Since this is very specific NAND How about looking into NAND code? I did look at it, and indeed some of the ldrd/strd's are in the NAND code. I can't really see anything obviously wrong with the generated code. However, it's not NAND-specific. Depending on GCC version, I get issues with vsprintf or complete lockups as well. // Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/10] mkconfig: parse top level makefile target to multiple config targets
Dear Hu Mingkai-B21284, In message 73839b4a0818e747864426270ac332c30447e...@zmy16exm20.fsl.freescale.net you wrote: It should be enough to pass the make target name to the mkconfig script resp. the board config file, i. e. in this case either CONFIG_MPC8536DS_NAND or CONFIG_MPC8536DS_NAND_36BIT. The rest of the scripting/decision making can then be done in the board config file. Thanks for your replay, but I'm not totally catch on you. the board config file in your words refer to board/*/config.mk, right? No, with board config file I mean include/configs/*.h 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 Q: Why do PCs have a reset button on the front? A: Because they are expected to run Microsoft operating systems. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC: split ARM repo and distribute workload
Dear Magnus, In message 59b21cf20909070206t189fe96bpac3cce2770b6b...@mail.gmail.com you wrote: Freescale (i.MX) Magnus Lilja? Or are there any volunteers at Freescale? I don't have the time to handle this in a good way. It would be good if someone at Freescale could step in. I see. Thank you very much anyway. So until someone volunteers here, we leave this part untouched yet. 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 miracle: an extremely outstanding or unusual event, thing, or accomplishment.- Webster's Dictionary ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How to burn new U-Boot over network
alex889 wrote: Hi, I'm working on the DM365evm, and i was wondering if there is a way to burn new U-Boot version over network, instead of Code Composer and a JTAG? Thanks, Alex Hi Alex, of course it's possible! But it depends on the location of your U-Boot. I.e. your U-Boot is located in dataflash or NAND flash: tftp $(loadaddress) $(img) protect off $(start) $(end) erase $(start) $(end) cp.b $(loadaddress) $(start) $(filesize) $(loadaddress) - the temporary RAM address for downloading new U-Boot $(img) - the path to your new U-Boot image (i.e. /tftpboot/update/u-boot.img) $(start) - the flash address, where U-Boot is located $(end) - $(start) + maximum size of U-Boot (erasesize) $(filesize)- set automatically after tftp transfer Regards Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/10] mkconfig: parse top level makefile target to multiple config targets
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Monday, September 07, 2009 6:18 PM To: Hu Mingkai-B21284 Cc: Kumar Gala; Wood Scott-B07421; U-Boot-Users ML; Mike Frysinger Subject: Re: [PATCH 01/10] mkconfig: parse top level makefile target to multiple config targets Dear Hu Mingkai-B21284, In message 73839b4a0818e747864426270ac332c30447e...@zmy16exm20.fsl.frees cale.net you wrote: It should be enough to pass the make target name to the mkconfig script resp. the board config file, i. e. in this case either CONFIG_MPC8536DS_NAND or CONFIG_MPC8536DS_NAND_36BIT. The rest of the scripting/decision making can then be done in the board config file. Thanks for your replay, but I'm not totally catch on you. the board config file in your words refer to board/*/config.mk, right? No, with board config file I mean include/configs/*.h How can I parse the board name in a header file? If config booting from NAND, we also need to override the TEXT_BASE in the board/*/config.mk file, how could we do that? Thanks, Mingkai ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/10] mkconfig: parse top level makefile target to multiple config targets
Dear Hu Mingkai-B21284, In message 73839b4a0818e747864426270ac332c30447e...@zmy16exm20.fsl.freescale.net you wrote: It should be enough to pass the make target name to the mkconfig script resp. the board config file, i. e. in this case either CONFIG_MPC8536DS_NAND or CONFIG_MPC8536DS_NAND_36BIT. The rest of the scripting/decision making can then be done in the board config file. Thanks for your replay, but I'm not totally catch on you. the board config file in your words refer to board/*/config.mk, right? No, with board config file I mean include/configs/*.h How can I parse the board name in a header file? I'm not sure I understand the question (or rather the problem you are seeing). You already know the board name, because the board config file is clearly related ot one (or eventually more) boards. The rest can be done with some trivial #ifdef'fery. If config booting from NAND, we also need to override the TEXT_BASE in the board/*/config.mk file, how could we do that? You can for example set CONFIG_SYS_MONITOR_BASE (or some other CONFIG_ variable - but CONFIG_SYS_MONITOR_BASE is used anyway) as needed in your include/configs/*.h, which then gets exported through include/autoconf.mk, so you can use some TEXT_BASE = $(CONFIG_SYS_MONITOR_BASE) in your config.mk Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If you're not part of the solution, then you're part of the precipi- tate. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC: split ARM repo and distribute workload
Dear Kyungmin Park, In message 9c9fda240909061806j5ecc26c3ie53215e8aa017...@mail.gmail.com you wrote: Samsung (s3c, s5pc):Are there any volunteers at Samsung? I recommended the Minky Kang. He's working for several years for u-boot from pxa, omap3, s3c6410 and s5pc1xx series. Thanks. But with our internal security policy it's hard to use ssh on u-boot git. so we want to use u-boot-arm as base. Well, I think we can leave out the technical details here; we will find solutions to these. 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 don't mind criticism. You know me. I've never been one to take offence at criticism. No one could say I'm the sort to take offence at criticism -- Not twice, anyway. Not without blowing bubbles. - Terry Pratchett, _Witches Abroad_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc4xx: Fix compilation warning in 4xx miiphy.c
This patch fixes the following compilation warning: miiphy.c: In function 'emac4xx_miiphy_read': miiphy.c:353: warning: dereferencing type-punned pointer will break strict-aliasing rules Signed-off-by: Stefan Roese s...@denx.de --- cpu/ppc4xx/miiphy.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/cpu/ppc4xx/miiphy.c b/cpu/ppc4xx/miiphy.c index 6a92bf8..fa3bfc8 100644 --- a/cpu/ppc4xx/miiphy.c +++ b/cpu/ppc4xx/miiphy.c @@ -350,7 +350,7 @@ int emac4xx_miiphy_read (char *devname, unsigned char addr, unsigned char reg, return -1; sta_reg = in_be32((void *)EMAC_STACR + emac_reg); - *value = *(u16 *)(sta_reg); + *value = sta_reg 16; return 0; } -- 1.6.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] autoscr command failure saveenv dataflash
Hi, the reason for this problem is the definition of #define DATAFLASH_BUSY 0x00 #define DATAFLASH_OK0x01 in the file /include/dataflash.h. All functions return DATAFLASH_OK and in the file /common/cmd_nvedit.c function do_saveenv() return (saveenv() ? 1 : 0); than cause an error. I have modified it to return (saveenv() == 1 ? 0 : 1); and this works for my, but i'am not sure if this is the best way of fixing the problem. Regards Rainer Berns BEKA Elektronik Rainer Berns Rudolf Kauls GbR Siemensstrasse 29 50374 Erftstadt Tel.: +49 2235/4606-0 Fax.: +49 2235/4606-29 Email: be...@beka-elektronik.de -Original Message- From: Detlev Zundel [mailto:d...@denx.de] Sent: Friday, July 03, 2009 11:57 AM To: be...@beka-elektronik.de Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] autoscr command Hi Rainer, i use the autoscr command to store further information in a NAND at the first start. After this it modify the bootcmd and save the enviroment and the last command should restart the device. Where is your environment located? What parser do you use, i.e. regular or hush? The script works fine but saveenv seams to abort the script file. I have used different memory location, i have checked the memory contents and i have placed saveenv at the beginning, middle and at the end of the script. It allways abort after saveenv. I use Uboot 2008.10. I presume there is a bad return code somewhere. If you have the hush-parser enebled, try this for a start: = if saveenv ; then echo ok ; else echo failed ; fi Saving Environment to Flash... Un-Protected 2 sectors Un-Protected 2 sectors Erasing Flash... .. done Erased 2 sectors Writing to Flash... done Protected 2 sectors Protected 2 sectors ok = Cheers Detlev -- I shall be telling this with a sigh / Somewhere ages and ages hence: / Two roads diverged in a wood, and I-- / I took the one less traveled by, / And that has made all the difference. -- Robert Frost -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How to burn new U-Boot over network
Thanks for your answer. I tried this before i posted the question, and it didn't work. Do you know the exact address of the U-Boot on the NAND? Is there an additional header before the U-Boot? Alex Daniel Gorsulowski wrote: alex889 wrote: Hi, I'm working on the DM365evm, and i was wondering if there is a way to burn new U-Boot version over network, instead of Code Composer and a JTAG? Thanks, Alex Hi Alex, of course it's possible! But it depends on the location of your U-Boot. I.e. your U-Boot is located in dataflash or NAND flash: tftp $(loadaddress) $(img) protect off $(start) $(end) erase $(start) $(end) cp.b $(loadaddress) $(start) $(filesize) $(loadaddress) - the temporary RAM address for downloading new U-Boot $(img) - the path to your new U-Boot image (i.e. /tftpboot/update/u-boot.img) $(start) - the flash address, where U-Boot is located $(end) - $(start) + maximum size of U-Boot (erasesize) $(filesize)- set automatically after tftp transfer Regards Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- View this message in context: http://www.nabble.com/-U-Boot--How-to-burn-new-U-Boot-over-network-tp25327003p25329639.html Sent from the Uboot - Users mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/10] mkconfig: parse top level makefile target to multiple config targets
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Monday, September 07, 2009 6:59 PM To: Hu Mingkai-B21284 Cc: Kumar Gala; Wood Scott-B07421; U-Boot-Users ML; Mike Frysinger Subject: Re: [PATCH 01/10] mkconfig: parse top level makefile target to multiple config targets Dear Hu Mingkai-B21284, In message 73839b4a0818e747864426270ac332c30447e...@zmy16exm20.fsl.frees cale.net you wrote: It should be enough to pass the make target name to the mkconfig script resp. the board config file, i. e. in this case either CONFIG_MPC8536DS_NAND or CONFIG_MPC8536DS_NAND_36BIT. The rest of the scripting/decision making can then be done in the board config file. Thanks for your replay, but I'm not totally catch on you. the board config file in your words refer to board/*/config.mk, right? No, with board config file I mean include/configs/*.h How can I parse the board name in a header file? I'm not sure I understand the question (or rather the problem you are seeing). You already know the board name, because the board config file is clearly related ot one (or eventually more) boards. The rest can be done with some trivial #ifdef'fery. Oh... I complicated the matters, you means as the follows, right? In the Makefile: MPC8536DS_NAND_config \ MPC8536DS_NAND_36BIT_config \ MPC8536DS_36BIT_config \ MPC8536DS_config: unconfig @echo #define CONFIG_$(@:_config=) 1 $(obj)include/config.h @$(MKCONFIG) -a MPC8536DS ppc mpc85xx mpc8536ds freescale then in the include/configs/*.h: #ifdef MPC8536DS_NAND blablabla #endif #ifdef MPC8536DS_NAND_36BIT blablabla #endif #ifdef MPC8536DS_36BIT blablabla #endif If config booting from NAND, we also need to override the TEXT_BASE in the board/*/config.mk file, how could we do that? You can for example set CONFIG_SYS_MONITOR_BASE (or some other CONFIG_ variable - but CONFIG_SYS_MONITOR_BASE is used anyway) as needed in your include/configs/*.h, which then gets exported through include/autoconf.mk, so you can use some TEXT_BASE = $(CONFIG_SYS_MONITOR_BASE) in your config.mk Thanks. I'll intergate your comments, align the patchset to the latest U-Boot and resend the patches, please comments then. Many thanks, Mingkai ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/10] mkconfig: parse top level makefile target to multiple config targets
Dear Hu Mingkai-B21284, In message 73839b4a0818e747864426270ac332c30447e...@zmy16exm20.fsl.freescale.net you wrote: ... [Full quote deleted] ... You already know the board name, because the board config=20 file is clearly related ot one (or eventually more) boards.=20 The rest can be done with some trivial #ifdef'fery. Could you please stop full-quoting? Please see http://www.netmeister.org/news/learn2quote.html Oh... I complicated the matters, you means as the follows, right? In the Makefile: MPC8536DS_NAND_config \ MPC8536DS_NAND_36BIT_config \ MPC8536DS_36BIT_config \ MPC8536DS_config: unconfig @echo #define CONFIG_$(@:_config=) 1 $(obj)include/config.h @$(MKCONFIG) -a MPC8536DS ppc mpc85xx mpc8536ds freescale Yes, except that the echo line should not be needed either, as mkconfig would to that automatically for you. then in the include/configs/*.h: #ifdef MPC8536DS_NAND blablabla #endif #ifdef MPC8536DS_NAND_36BIT blablabla #endif #ifdef MPC8536DS_36BIT blablabla #endif That would be CONFIG_MPC8536DS_NAND etc., but except of that that's whaty I mean. [Eventually it might make sense to ise a common prefix for Maefile generated symbols, like CONFIG_MK_ or so.] I'll intergate your comments, align the patchset to the latest U-Boot and resend the patches, please comments then. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de What about WRITING it first and rationalizing it afterwords? :-) - Larry Wall in 8...@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] RFC: split ARM repo and distribute workload
Hello everybody, I wrote on | Hello everybody, | | ARM has always been one of the architectures that generated a big | number of different processors and SoCs, but recently the activitiy in | this area is literally exploding. This is partially due to the fact | that ARM is currently used in many designs, so many new ARM based | processors and SoCs and even more new ARM boards show up, but another | and at least as important change is that some silicon and board | vendors have started to actively pushing their products into the | U-Boot (and Linux) mainline source trees (and *welcome* they all | are!). | | It has become evident that this growing complexity has become way too | massive to be shouldered by a single custodian, even a very active one | like Jean-Christophe. | | I think we have no other choice but to add more manpower to this task, | i. e. split the ARM respository and distribute the workload across a | few more custodians. | | Unline with the Power architecture, where the split can be easily | defined by processor lines, with ARM it seems more logical to me to | differentiate by silicon vendors. Thanks for all the discussion so far. I really appreciate your help. As we are in the middle of a merge window, I don't want to waste much time. Therefore changes become effective immediately. This is the result we have so far: master ARM repository:Tom Rix Tom has accepted his new responsibility. Thanks a lot for that. Tom succeeds Jean-Christophe Plagniol-Villard who did this work so far. Big thanks goes to Jean-Christophe for all his work so far. I hope this change helps to reduce your work load enough so you can focus n the many tasks you are running in parallel. Many of us are looking forward to seeing your results. Atmel (AT91): Jean-Christophe Plagniol-Villard no changes here. Freescale (i.MX) So far we didn't find a volunteer yet. Until we find one, we will not split out a separate repository either. Marvell (PXA + IXP): Jean-Christophe Plagniol-Villard no changes here. Marvell (all other): Prafulla Wadaskar Prafulla has accepted his new responsibility. Thanks a lot for that. Samsung (s3c, s5pc): Minkyu Kang We don't have Minkyu Kang's word yet, but Kyungmin Park recommended him, and I'm optimistic to receiving his OK. Texas Instruments (OMAP,DaVinci): Sandeep Paulraj Sandeep has accepted responsibility for TI's DaVinci SOCs; at the moment it is not clear yet how we will handle OMAP - Sandeep suggested to split OMAP and DaVinci into separate repositories, but I would like to avoid this, at least until all the other changes have sunk in and stabilized. I hope that others (Dirk, Tom) can help out a bit here and support Sandeep where needed. I will thus create the following new git repositories: u-boot-marvell u-boot-samsung u-boot-ti Tom, Prafulla, Minkyu and Sandeep: can you please send me your SSH public keys so I can enable your access to these repositories? Minkyu - Kyungmin mentioned that you have problems to push files to an external git repository through SSH. Is there any other method we can set up to make access for you easier? Anything that can be done onour side (like providing a special configuration, say with non-standsard port numbers or so) is easy for us. Alternatively, if you could set up a local repository on your side and enable me to access it through ssh or rsync, I can easily use this and mirror it to the publicly accessable server. In short - if there is anything we can do to make work easier for you, please don't hesitate to tell me. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de WARNING: This Product Attracts Every Other Piece of Matter in the Universe, Including the Products of Other Manufacturers, with a Force Proportional to the Product of the Masses and Inversely Proportional to the Distance Between Them. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] PPC440GX: DDR ECC init time.
Hi Stefan, I didn't flush the cache (seemed a bit pointless since they're not in use at that point anyway, right?). I'll give it a whirl. I'll also look into the other ECC initialization. Good. I actually thought ECC initialization was only done in sdram.c (after a quick search for CONFIG_SDRAM_ECC). That probably also answers your next question. My SDRAM initialization is the same one as is used for the ALPR board and that uses the common code, as far as I know. Right. After looking at it, the ECC init is done in this common file. But the cache handling is missing here. I suggest you try to port this stuff from the DDR2 init file I mentioned in my last mail. Well, I've been trying to work this into my U-Boot. I haven't succeeded so far. Basically, the cache stuff in 4xx_spd_ddr2.c consists of setting up a TLB without the CACHE_INHIBITED bit and then using some cache instructions to fill up memory. That's what I've been trying to do, but my call to change_tlb() hangs because of the invalidate_dcache() call (bad trap exceptions). What could be going on here? I'll try and set up the DDR TLB dynamically instead of statically (in init.S) and see if I can get that working. By the way, I've also stumbled upon some other VERY strange behavior. If I leave the ecc_init() in its original state and just add in a puts( ) call at the beginning of the function, ECC generation is finished VERY quickly. What influence could adding the puts() call possibly have on the speed of generating ECC values in DDR? Kind regards, Wouter Eckhardt. Disclaimer: The information contained in this email, including any attachments is confidential and is for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender immediately by replying to this message and destroy all copies of this message and any attachments. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC: split ARM repo and distribute workload
Dear Wolfgang, 2009/9/7 Wolfgang Denk w...@denx.de Hello everybody, I wrote on | Hello everybody, | | ARM has always been one of the architectures that generated a big | number of different processors and SoCs, but recently the activitiy in | this area is literally exploding. This is partially due to the fact | that ARM is currently used in many designs, so many new ARM based | processors and SoCs and even more new ARM boards show up, but another | and at least as important change is that some silicon and board | vendors have started to actively pushing their products into the | U-Boot (and Linux) mainline source trees (and *welcome* they all | are!). | | It has become evident that this growing complexity has become way too | massive to be shouldered by a single custodian, even a very active one | like Jean-Christophe. | | I think we have no other choice but to add more manpower to this task, | i. e. split the ARM respository and distribute the workload across a | few more custodians. | | Unline with the Power architecture, where the split can be easily | defined by processor lines, with ARM it seems more logical to me to | differentiate by silicon vendors. Thanks for all the discussion so far. I really appreciate your help. As we are in the middle of a merge window, I don't want to waste much time. Therefore changes become effective immediately. This is the result we have so far: master ARM repository:Tom Rix Tom has accepted his new responsibility. Thanks a lot for that. Tom succeeds Jean-Christophe Plagniol-Villard who did this work so far. Big thanks goes to Jean-Christophe for all his work so far. I hope this change helps to reduce your work load enough so you can focus n the many tasks you are running in parallel. Many of us are looking forward to seeing your results. Atmel (AT91): Jean-Christophe Plagniol-Villard no changes here. Freescale (i.MX) So far we didn't find a volunteer yet. Until we find one, we will not split out a separate repository either. Marvell (PXA + IXP): Jean-Christophe Plagniol-Villard no changes here. Marvell (all other): Prafulla Wadaskar Prafulla has accepted his new responsibility. Thanks a lot for that. Samsung (s3c, s5pc): Minkyu Kang We don't have Minkyu Kang's word yet, but Kyungmin Park recommended him, and I'm optimistic to receiving his OK. sorry to late response. I need all of your help :) Thank you for give me the opportunity. Texas Instruments (OMAP,DaVinci): Sandeep Paulraj Sandeep has accepted responsibility for TI's DaVinci SOCs; at the moment it is not clear yet how we will handle OMAP - Sandeep suggested to split OMAP and DaVinci into separate repositories, but I would like to avoid this, at least until all the other changes have sunk in and stabilized. I hope that others (Dirk, Tom) can help out a bit here and support Sandeep where needed. I will thus create the following new git repositories: u-boot-marvell u-boot-samsung u-boot-ti Tom, Prafulla, Minkyu and Sandeep: can you please send me your SSH public keys so I can enable your access to these repositories? Minkyu - Kyungmin mentioned that you have problems to push files to an external git repository through SSH. Is there any other method we can set up to make access for you easier? Anything that can be done onour side (like providing a special configuration, say with non-standsard port numbers or so) is easy for us. Alternatively, if you could set up a local repository on your side and enable me to access it through ssh or rsync, I can easily use this and mirror it to the publicly accessable server. In short - if there is anything we can do to make work easier for you, please don't hesitate to tell me. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de WARNING: This Product Attracts Every Other Piece of Matter in the Universe, Including the Products of Other Manufacturers, with a Force Proportional to the Product of the Masses and Inversely Proportional to the Distance Between Them. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot 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-ARM] CONFIG_SYS_HZ fix for ARM902T S3C24X0 Boards
On Sat, 05 Sep 2009 16:33:13 +0100
kevin.morf...@fearnside-systems.co.uk kevin.morf...@fearnside-systems.co.uk
wrote:
This sets CONFIG_SYS_HZ to 1000 for all boards that use the s3c2400 and
s3c2410 cpu's which fixes various problems such as the timeouts in tftp being
too short.
Tested on an Embest SBC2440-II Board with local u-boot patches as I don't
have any s3c2400 or s3c2410 boards but need this patch applying before I can
submit patches for the SBC2440-II Board. Also, ran MAKEALL for all ARM9
targets
and no new warnings or errors were found.
It was originally submitted on 21/06/2009 but didn't get into the 2009.08
release, and Jean-Pierre made one comment on the original patch (see
http://lists.denx.de/pipermail/u-boot/2009-July/055470.html). I've made two
changes to the original patch:
- it's been re-based to the current release
- I've re-named get_timer_raw() to get_ticks() in response to Jean-Pierre's
comment
This affects the sbc2410, smdk2400, smdk2410 and trab boards. I've copied it
directly to the maintainers of all except the sbc2410 which doesn't have an
entry in MAINTAINERS.
Signed-off-by: Kevin Morfitt kmorf...@aselaptop-1.localdomain
---
cpu/arm920t/s3c24x0/timer.c | 36
include/configs/sbc2410x.h |4 +---
include/configs/smdk2400.h |4 +---
include/configs/smdk2410.h |4 +---
include/configs/trab.h | 12 +---
5 files changed, 24 insertions(+), 36 deletions(-)
diff --git a/cpu/arm920t/s3c24x0/timer.c b/cpu/arm920t/s3c24x0/timer.c
index c8c7cdb..db472bf 100644
--- a/cpu/arm920t/s3c24x0/timer.c
+++ b/cpu/arm920t/s3c24x0/timer.c
@@ -39,6 +39,7 @@
#endif
int timer_load_val = 0;
+static ulong timer_clk;
/* macro to read the 16 bit timer */
static inline ulong READ_TIMER(void)
@@ -66,6 +67,7 @@ int timer_init (void)
* @33.25MHz and 15625 @ 50 MHz
*/
timer_load_val = get_PCLK()/(2 * 16 * 100);
+ timer_clk = get_PCLK() / (2 * 16);
}
/* load value for 10 ms timeout */
lastdec = timers-TCNTB4 = timer_load_val;
@@ -100,13 +102,13 @@ void set_timer (ulong t)
void udelay (unsigned long usec)
{
ulong tmo;
- ulong start = get_timer(0);
+ ulong start = get_ticks();
tmo = usec / 1000;
tmo *= (timer_load_val * 100);
tmo /= 1000;
- while ((ulong)(get_timer_masked () - start) tmo)
+ while ((ulong) (get_ticks() - start) tmo)
/*NOP*/;
}
@@ -119,18 +121,9 @@ void reset_timer_masked (void)
ulong get_timer_masked (void)
{
- ulong now = READ_TIMER();
-
- if (lastdec = now) {
- /* normal mode */
- timestamp += lastdec - now;
- } else {
- /* we have an overflow ... */
- timestamp += lastdec + timer_load_val - now;
- }
- lastdec = now;
+ ulong tmr = get_ticks();
- return timestamp;
+ return tmr / (timer_clk / CONFIG_SYS_HZ);
}
void udelay_masked (unsigned long usec)
@@ -148,10 +141,10 @@ void udelay_masked (unsigned long usec)
tmo /= (1000*1000);
}
- endtime = get_timer_masked () + tmo;
+ endtime = get_ticks() + tmo;
do {
- ulong now = get_timer_masked ();
+ ulong now = get_ticks();
diff = endtime - now;
} while (diff = 0);
}
@@ -162,7 +155,18 @@ void udelay_masked (unsigned long usec)
*/
unsigned long long get_ticks(void)
{
- return get_timer(0);
+ ulong now = READ_TIMER();
+
+ if (lastdec = now) {
+ /* normal mode */
+ timestamp += lastdec - now;
+ } else {
+ /* we have an overflow ... */
+ timestamp += lastdec + timer_load_val - now;
+ }
+ lastdec = now;
+
+ return timestamp;
}
/*
diff --git a/include/configs/sbc2410x.h b/include/configs/sbc2410x.h
index f2ea926..e6886cf 100644
--- a/include/configs/sbc2410x.h
+++ b/include/configs/sbc2410x.h
@@ -139,9 +139,7 @@
#define CONFIG_SYS_LOAD_ADDR0x3300 /* default load
address */
-/* the PWM TImer 4 uses a counter of 15625 for 10 ms, so we need */
-/* it to wrap 100 times (total 1562500) to get 1 sec. */
-#define CONFIG_SYS_HZ 1562500
+#define CONFIG_SYS_HZ 1000
/* valid baudrates */
#define CONFIG_SYS_BAUDRATE_TABLE{ 9600, 19200, 38400, 57600, 115200 }
diff --git a/include/configs/smdk2400.h b/include/configs/smdk2400.h
index c234177..a1beb65 100644
--- a/include/configs/smdk2400.h
+++ b/include/configs/smdk2400.h
@@ -141,9 +141,7 @@
#define CONFIG_SYS_LOAD_ADDR0x0cf0 /* default load
address */
-/* the PWM TImer 4 uses a counter of 15625 for 10 ms, so we need */
-/* it to wrap 100 times (total 1562500) to get 1 sec. */
-#define CONFIG_SYS_HZ
Re: [U-Boot] [PATCH][v2] ep8248: add support for device tree and secondary Ethernet interface.
Hi Peter Peter Tyser ptyser at xes-inc.com writes: Hi Marcel, This patch also appears to be line wrapped. Sorry, obviously gmane can't be used for patch submission. Unfortunately I am not in a very Linux friendly environment right now, meaning M$ proxies and such. Trying to find a cleaner submission path will take me some time. Stay tuned. Cheers Marcel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][v1] mpc8260: move FDT memory node fixup into common CPU code.
Hi Heiko Heiko Schocher hs at denx.de writes: ... I couldn;t apply your patch, because your patch is line wrapped. Can you fix your mailer? Sorry, obviously gmane can't be used for patch submission. Unfortunately I am not in a very Linux friendly environment right now, meaning M$ proxies and such. Trying to find a cleaner submission path will take me some time. Stay tuned. Cheers Marcel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] ppc4xx: Allow overwriting pci target registers for all 4xx boards
This patch adds the CONFIG_PCI_4xx_PTM_OVERWRITE option and replaces
the ugly 'if defined(BOARD1) || ... || defined(BOARDn)' construct
in 4xx pci code.
When CONFIG_PCI_4xx_PTM_OVERWRITE is defined the default ptm register
setup can be overwritten through environment variables ptm1la, ptm1ms,
ptm2la and ptm2ms to do application specific pci target BAR configuration.
Signed-off-by: Matthias Fuchs matthias.fu...@esd.eu
---
cpu/ppc4xx/4xx_pci.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/cpu/ppc4xx/4xx_pci.c b/cpu/ppc4xx/4xx_pci.c
index 5d7d59c..184cef5 100644
--- a/cpu/ppc4xx/4xx_pci.c
+++ b/cpu/ppc4xx/4xx_pci.c
@@ -138,7 +138,7 @@ void pci_405gp_init(struct pci_controller *hose)
unsigned short temp_short;
unsigned long ptmpcila[2] = {CONFIG_SYS_PCI_PTM1PCI,
CONFIG_SYS_PCI_PTM2PCI};
-#if defined(CONFIG_CPCI405) || defined(CONFIG_PMC405)
+#if defined(CONFIG_PCI_4xx_PTM_OVERWRITE)
char *ptmla_str, *ptmms_str;
#endif
unsigned long ptmla[2]= {CONFIG_SYS_PCI_PTM1LA,
CONFIG_SYS_PCI_PTM2LA};
@@ -160,7 +160,7 @@ void pci_405gp_init(struct pci_controller *hose)
#endif
#endif
-#if defined(CONFIG_CPCI405) || defined(CONFIG_PMC405)
+#if defined(CONFIG_PCI_4xx_PTM_OVERWRITE)
ptmla_str = getenv(ptm1la);
ptmms_str = getenv(ptm1ms);
if(NULL != ptmla_str NULL != ptmms_str ) {
--
1.6.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] ppc4xx: Add CONFIG_PCI_4xx_PTM_OVERWRITE to some esd 4xx boards
Signed-off-by: Matthias Fuchs matthias.fu...@esd.eu --- include/configs/CPCI405.h |2 ++ include/configs/CPCI4052.h |2 ++ include/configs/CPCI405AB.h |2 ++ include/configs/CPCI405DT.h |2 ++ include/configs/PMC405.h|2 ++ include/configs/PMC405DE.h |2 ++ 6 files changed, 12 insertions(+), 0 deletions(-) diff --git a/include/configs/CPCI405.h b/include/configs/CPCI405.h index f032a8d..fca6de0 100644 --- a/include/configs/CPCI405.h +++ b/include/configs/CPCI405.h @@ -171,6 +171,8 @@ #define CONFIG_SYS_PCI_PTM2MS 0xffc1 /* 4MB, enable */ #define CONFIG_SYS_PCI_PTM2PCI 0x0400 /* Host: use this pci address */ +#define CONFIG_PCI_4xx_PTM_OVERWRITE 1 /* overwrite PTMx settings by env */ + /*--- * IDE/ATA stuff *--- diff --git a/include/configs/CPCI4052.h b/include/configs/CPCI4052.h index daa3c19..fd04566 100644 --- a/include/configs/CPCI4052.h +++ b/include/configs/CPCI4052.h @@ -192,6 +192,8 @@ #define CONFIG_SYS_PCI_PTM2MS 0xffc1 /* 4MB, enable */ #define CONFIG_SYS_PCI_PTM2PCI 0x0400 /* Host: use this pci address */ +#define CONFIG_PCI_4xx_PTM_OVERWRITE 1 /* overwrite PTMx settings by env */ + /*--- * IDE/ATA stuff *--- diff --git a/include/configs/CPCI405AB.h b/include/configs/CPCI405AB.h index 41795a7..d718ed4 100644 --- a/include/configs/CPCI405AB.h +++ b/include/configs/CPCI405AB.h @@ -189,6 +189,8 @@ #define CONFIG_SYS_PCI_PTM2MS 0xffc1 /* 4MB, enable */ #define CONFIG_SYS_PCI_PTM2PCI 0x0400 /* Host: use this pci address */ +#define CONFIG_PCI_4xx_PTM_OVERWRITE 1 /* overwrite PTMx settings by env */ + /*--- * IDE/ATA stuff *--- diff --git a/include/configs/CPCI405DT.h b/include/configs/CPCI405DT.h index 2333208..09df470 100644 --- a/include/configs/CPCI405DT.h +++ b/include/configs/CPCI405DT.h @@ -193,6 +193,8 @@ #define CONFIG_SYS_PCI_PTM2MS 0xffc1 /* 4MB, enable */ #define CONFIG_SYS_PCI_PTM2PCI 0x0400 /* Host: use this pci address */ +#define CONFIG_PCI_4xx_PTM_OVERWRITE 1 /* overwrite PTMx settings by env */ + /*--- * IDE/ATA stuff *--- diff --git a/include/configs/PMC405.h b/include/configs/PMC405.h index a9e7134..87ea7b6 100644 --- a/include/configs/PMC405.h +++ b/include/configs/PMC405.h @@ -181,6 +181,8 @@ #define CONFIG_SYS_PCI_PTM2MS 0xff01 /* 16MB, enable */ #define CONFIG_SYS_PCI_PTM2PCI 0x /* Host: use this pci address */ +#define CONFIG_PCI_4xx_PTM_OVERWRITE 1 /* overwrite PTMx settings by env */ + /* * Start addresses for the final memory configuration * (Set up by the startup code) diff --git a/include/configs/PMC405DE.h b/include/configs/PMC405DE.h index 5232745..7198632 100644 --- a/include/configs/PMC405DE.h +++ b/include/configs/PMC405DE.h @@ -164,6 +164,8 @@ #define CONFIG_SYS_PCI_PTM2MS 0xff01 /* 16MB, enable=1 */ #define CONFIG_SYS_PCI_PTM2PCI 0x0400 /* Host: use this pci address */ +#define CONFIG_PCI_4xx_PTM_OVERWRITE 1 /* overwrite PTMx settings by env */ + /* * For booting Linux, the board info and command line data * have to be in the first 8 MB of memory, since this is -- 1.6.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM Pull Request
Tom wrote: Dirk Behme wrote: Peter Tyser wrote: On Sun, 2009-09-06 at 19:59 +0200, Dirk Behme wrote: Jean-Christophe PLAGNIOL-VILLARD wrote: On 09:12 Sun 06 Sep , Dirk Behme wrote: Jean-Christophe PLAGNIOL-VILLARD wrote: On 07:37 Sat 05 Sep , Dirk Behme wrote: Dear Jean-Christophe, Jean-Christophe PLAGNIOL-VILLARD wrote: Hi, Please pull The following changes since commit 3aa8b68d80dbcb6829af60485c1e388b39af793d: Wolfgang Denk (1): Merge branch 'next' of ../next are available in the git repository at: git://git.denx.de/u-boot-arm.git master Albin Tonnerre (3): at91sam9260/afeb9260: Fix SPI initialization Add support for the Calao SBC35-A9G20 board Support for the Calao TNY-A9260/TNY-A9G20 boards Frederik Kriewitz (1): Add support for the DevKit8000 board I'd like to have the omap3_devkit8000.h version of that patch, instead. this one is fine no need not the omap3_devkit8000 version Jean-Christophe: In http://lists.denx.de/pipermail/u-boot/2009-August/059087.html we agreed on omap3_devkit8000. in v4 the author prefer it devkit8000 so I respect it You missed v5 and v6, no? My vote is for keeping the board config file named devkit8000.h - that's U-Boot's current, standard naming convention and it matches up with the board name under board/. And I vote (as agreed like mentioned above) for omap3_devkit8000.h as this is the current, standard OMAP3 config file naming convention which matches with all other OMAP3 configs. Best regards Dirk I know i may be muddying this up but.. The devkit8000 looks a lot like the beagle. Have you already thought of just rolling devkit8000 into beagle? My opinion on naming is to keep omap3_ prefix consistent. People used to building with their favorite omap3_* config should continue. For now, new omap3 boards to use the omap3_ prefix. I agree here, so we are at least 2 ;) If you really want to change U-Boot's user build interface for OMAP3, please remember how many documentation you will break with this. And additionally, please remember how many user you will confuse with this. At least for BeagleBoard there are already some thousand boards out there. Best regards Dirk If we want to break the config names, we should do it after a release. A good time for that will be when the omap4 versions come in and we have to figure out how to put them in. Tom ___ 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] arm_cortexa8: support cache flush to other soc
Dear Minkyu Kang,
Minkyu Kang wrote:
Dear Dirk,
2009/9/5 Dirk Behme dirk.be...@googlemail.com
Minkyu Kang wrote:
Dear, Dirk
2009/9/4 Dirk Behme dirk.be...@googlemail.com
Kyungmin Park wrote:
On Fri, Sep 4, 2009 at 7:45 PM, Dirk Behmedirk.be...@googlemail.com
wrote:
Kyungmin Park wrote:
...
+ if (get_device_type() != 0xC100) {
Hmm, what is this 0xC100 ?
Now we got two cpu, s5pc100 and s5pc110. In case of s5pc100 we don't
need to turn off l2 cache. but s5pc110 needs it.
So first check the device type, actually cpu type. then determine turn
off l2 cache or not.
0xC100 is the device type of s5pc100 then? So it should be
if (get_device_type() != S5PC100_DEVICE)
? I hear some people crying please use macro ;)
Agreed. DONT_NEED_CACHE_FLUSH?
But I don't like this selection here. When we get additional similar
SoCs,
we will end with something like
if (get_device_type() != 0xC100) ||
(get_device_type() != FOO) ||
(get_device_type() != BAR)) ||
... {
modifying each time cpu/arm_cortexa8/cpu.c.
I would like more that we are able to compile the functionality based
on
the
config file we use for compilation. E.g. provide emtpy
l2_cache_disable();
function for SoCs that don't need it, but have functionality behind it
where
needed.
With above patch, this would then become something like
cpu/arm_cortexa8/s5pcxxx/dcache.S
- Implements invalidate_dcache() (or implement a Cortex A8 generic one
in
cpu/arm_cortexa8/cache.S)
cpu/arm_cortexa8/s5pcxxx/cache_110.S
- Implements l2_cache_enable()/disable()
cpu/arm_cortexa8/s5pcxxx/cache_100.S
- Implements *empty* l2_cache_enable()/disable()
In cpu/arm_cortexa8/s5pcxxx/Makefile you then could have
SOBJS-y += dcache.o
SOBJS-$(CONFIG_S5PC100) += cache_100.o
SOBJS-$(CONFIG_S5PC110) += cache_110.o
What do you think about this?
Basically agreed, of course we can think weak attribute but now we
have to support both cpu simultaneously.
with this reason. we check the device_type at here.
What's about having this check in SoC specific code instead of Cortex
A8 generic code, then?
E.g apply patch
http://lists.denx.de/pipermail/u-boot/2009-August/058492.html
and then create
cpu/arm_cortexa8/s5pcxxx/cache.S
with
invalidate_dcache() {
if (get_device_type() == S5PC100_DEVICE)
return();
...
l2_cache_enable() {
if (get_device_type() == S5PC100_DEVICE)
return();
...
etc.
That is, have the SoC dependent part in SoC specific directory/file.
Best regards
Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
I know about the discussion of this issue between you and Jean-Christophe.
but it is gone without resolving.
So, I want to make issue again.
anyway,,
Actually, we don't need the function of get_device_type()
I think that function is omap specific function.. isn't it?
but.. because of current code already use that function, I had to use that
function
If you have plan to move the cache routines into SoC,
I think you can remove the argument for device_type. (check device type in
omap3's cache routines)
And I want to remove CONFIG_L2_OFF also.
We can know this through device type or soc type.
How about make new function?
e.g l2_off() or need_cache_flush() etc,
Please rework for removing dependency of omap3 soc first.
Just to clarify: It's my understanding that this is already done by
http://lists.denx.de/pipermail/u-boot/2009-August/058492.html
Do you agree? That is, when this patch is applied, then Samsung can go on.
Correct?
If not correct, what is missing in above patch?
Best regards
Dirk
I have two request.
1. I want to replace CONFIG_L2_OFF define to other function
for example..
if (need_cache_flush()) { /* or !l2_off() */
/* turn off L2 cache */
l2_cache_disable();
/* invalidate L2 cache also */
v7_flush_dcache_all(get_device_type());
i = 0;
/* mem barrier to sync up things */
asm(mcr p15, 0, %0, c7, c10, 4: :r(i));
l2_cache_enable();
}
2. I don't want to use get_device_type() function
(just call like this: v7_flush_decahe_all() )
How you think?
I wonder if these two requests are
- nice to have topics? Or
- required changes?
And if these are required changes, if
- these can go on top of
http://lists.denx.de/pipermail/u-boot/2009-August/058492.html
so that we can apply above patch, you are able to go on to bring
Samsung into mainline? And in parallel we discuss/change above topics? Or
- we have to rewrite
http://lists.denx.de/pipermail/u-boot/2009-August/058492.html
what will stall Samsungs mainline integration further?
Best regards
Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM Pull Request
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message 20090905013643.gk30...@game.jcrosoft.org you wrote:
Hi,
Please pull
The following changes since commit 3aa8b68d80dbcb6829af60485c1e388b39af793d:
Wolfgang Denk (1):
Merge branch 'next' of ../next
are available in the git repository at:
git://git.denx.de/u-boot-arm.git master
Albin Tonnerre (3):
at91sam9260/afeb9260: Fix SPI initialization
Add support for the Calao SBC35-A9G20 board
Support for the Calao TNY-A9260/TNY-A9G20 boards
Frederik Kriewitz (1):
Add support for the DevKit8000 board
Ilko Iliev (1):
DM9000 init for pm9261
Ilya Yanok (1):
imx27lite: add support for imx27lite board from LogicPD
Jean-Christophe PLAGNIOL-VILLARD (3):
omap: move TI's boards to board/ti/
arm: move Logicpd's boards to board/logicpd/
omap3: move the other boards to board/
Prafulla Wadaskar (1):
arm: Kirkwood: add SYSRSTn Duration Counter Support
Simon Kagstrom (1):
Remove duplicate set_cr
MAINTAINERS| 11 +
MAKEALL|5 +
Makefile | 47 +++-
board/afeb9260/afeb9260.c |2 +-
board/atmel/at91sam9260ek/at91sam9260ek.c |2 +-
.../{imx31_litekit = calao/sbc35_a9g20}/Makefile | 16 +-
board/calao/sbc35_a9g20/config.mk |1 +
board/calao/sbc35_a9g20/sbc35_a9g20.c | 197 +
board/calao/sbc35_a9g20/spi.c | 57
board/{imx31_litekit = calao/tny_a9260}/Makefile | 16 +-
board/calao/tny_a9260/config.mk|1 +
.../zoom2/debug_board.c = calao/tny_a9260/spi.c} | 53 ++--
board/calao/tny_a9260/tny_a9260.c | 110 +++
board/{omap5912osk = logicpd/imx27lite}/Makefile |6 +-
board/logicpd/imx27lite/config.mk |1 +
board/logicpd/imx27lite/imx27lite.c| 73 +
board/logicpd/imx27lite/lowlevel_init.S| 170 +++
board/{ = logicpd}/imx31_litekit/Makefile |0
board/{ = logicpd}/imx31_litekit/config.mk|0
board/{ = logicpd}/imx31_litekit/imx31_litekit.c |0
board/{ = logicpd}/imx31_litekit/lowlevel_init.S |0
board/{omap3 = logicpd}/zoom1/Makefile|0
board/{omap3 = logicpd}/zoom1/config.mk |0
board/{omap3 = logicpd}/zoom1/zoom1.c |0
board/{omap3 = logicpd}/zoom1/zoom1.h |0
board/{omap3 = logicpd}/zoom2/Makefile|0
board/{omap3 = logicpd}/zoom2/config.mk |0
board/{omap3 = logicpd}/zoom2/debug_board.c |0
board/{omap3 = logicpd}/zoom2/led.c |0
board/{omap3 = logicpd}/zoom2/zoom2.c |0
board/{omap3 = logicpd}/zoom2/zoom2.h |0
board/{omap3 = logicpd}/zoom2/zoom2_serial.c |0
board/{omap3 = logicpd}/zoom2/zoom2_serial.h |0
board/{omap3 = }/overo/Makefile |0
board/{omap3 = }/overo/config.mk |0
board/{omap3 = }/overo/overo.c|0
board/{omap3 = }/overo/overo.h|0
board/{omap3 = }/pandora/Makefile |0
board/{omap3 = }/pandora/config.mk|0
board/{omap3 = }/pandora/pandora.c|0
board/{omap3 = }/pandora/pandora.h|0
board/ronetix/pm9261/pm9261.c |7 +
board/{omap3 = ti}/beagle/Makefile|0
board/{omap3 = ti}/beagle/beagle.c|0
board/{omap3 = ti}/beagle/beagle.h|0
board/{omap3 = ti}/beagle/config.mk |0
board/{omap3 = ti}/evm/Makefile |0
board/{omap3 = ti}/evm/config.mk |0
board/{omap3 = ti}/evm/evm.c |0
board/{omap3 = ti}/evm/evm.h |0
board/{ = ti}/omap1510inn/Makefile|0
board/{ = ti}/omap1510inn/config.mk |0
board/{ = ti}/omap1510inn/lowlevel_init.S |0
board/{ = ti}/omap1510inn/omap1510innovator.c |0
board/{ = ti}/omap1610inn/Makefile|0
board/{ = ti}/omap1610inn/config.mk |0
board/{ = ti}/omap1610inn/flash.c |0
board/{ = ti}/omap1610inn/lowlevel_init.S |0
board/{ = ti}/omap1610inn/omap1610innovator.c |0
board/{ = ti}/omap2420h4/Makefile |0
board/{ = ti}/omap2420h4/config.mk|0
board/{ = ti}/omap2420h4/lowlevel_init.S |0
board/{ = ti}/omap2420h4/mem.c|0
board/{ = ti}/omap2420h4/omap2420h4.c |0
board/{ = ti}/omap2420h4/sys_info.c |0
board/{
Re: [U-Boot] ARM Pull Request
Dear Heiko Schocher, In message 4aa37e48.5070...@denx.de you wrote: Hello Wolfgang, The following changes since commit 9f23ca42b3ba19b24e66fade572f2b86d929b6e8: Wolfgang Denk (1): ARM: Update mach-types are available in the git repository at: git://git.denx.de/u-boot-i2c.git master Eric Millbrandt (1): Reset i2c slave devices during init on mpc5xxx cpus Timur Tabi (1): fsl_i2c: increase I2C timeout values and make them configurable README |7 ++ cpu/mpc5xxx/i2c.c| 49 ++ drivers/i2c/fsl_i2c.c| 24 +--- include/configs/galaxy5200.h |1 + 4 files changed, 77 insertions(+), 4 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There you go man, Keep as cool as you can. It riles them to believe that you perceive the web they weave. Keep on being free! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Microblaze repo update - patches
Dear Michal Simek, In message 4aa4c096.7060...@monstr.eu you wrote: Hi Wolfgang, I added all Microblaze changes to my repo. Ben: Can you finally check LL-Temac driver? I haven't got any your reaction. I know you have just a lot of work. Wolfgang: There are two patches for you. First remove xilinx_emac.c driver and second cleanup license in xilinx_emaclite.c file. There are some microblaze related changes too. If is Ben ok with pulling ll-temac driver directly, Wolfgang please pull to your tree. If not, I'll remove that last LL_Temac patch. I guess it would be easiest if Ben sends an ACK, and I will pull then. Ben? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de No one is fit to be trusted with power. ... No one. ... Any man who has lived at all knows the follies and wickedness he's capabel of ... And if he does know it, he knows also that neither he nor any man ought to be allowed to decide a single human fate. - C. P. Snow, The Light and the Dark ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH-ARM] CONFIG_SYS_HZ fix for ARM902T S3C24X0 Boards
Dear kevin.morf...@fearnside-systems.co.uk, In message 4aa284b9.8030...@fearnside-systems.co.uk you wrote: This sets CONFIG_SYS_HZ to 1000 for all boards that use the s3c2400 and s3c2410 cpu's which fixes various problems such as the timeouts in tftp being too short. I still wonder if this is really an issue. Some s3c2400 based boards have been in production use for several years, with volumes of many thousands of devices per year. Yet no TFTP timeout issues have been reported ever. This affects the sbc2410, smdk2400, smdk2410 and trab boards. I've copied it directly to the maintainers of all except the sbc2410 which doesn't have an entry in MAINTAINERS. I tested it on trab, and I don't see any changes - both U-Boot and Linux still work as they always used to work. Tested-by: Wolfgang Denk wd2denx.de Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. - George Bernard Shaw ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Remove atmel_df_pow2 binary with make clean
Commit 65f6f07b added support for the atmel_df_pow2 standalone program but missed to add a rule to remove it to the clean make target. Signed-off-by: Wolfgang Denk w...@denx.de --- Makefile |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/Makefile b/Makefile index 0449a5b..54610c6 100644 --- a/Makefile +++ b/Makefile @@ -3717,6 +3717,7 @@ grsim_leon2_config : unconfig clean: @rm -f $(obj)examples/standalone/82559_eeprom \ + $(obj)examples/standalone/atmel_df_pow2\ $(obj)examples/standalone/eepro100_eeprom \ $(obj)examples/standalone/hello_world \ $(obj)examples/standalone/interrupt\ -- 1.6.0.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH-ARM] CONFIG_SYS_HZ fix for ARM902T S3C24X0 Boards
On 07/09/2009 22:47, Wolfgang Denk wrote: Dear kevin.morf...@fearnside-systems.co.uk, In message 4aa284b9.8030...@fearnside-systems.co.uk you wrote: This sets CONFIG_SYS_HZ to 1000 for all boards that use the s3c2400 and s3c2410 cpu's which fixes various problems such as the timeouts in tftp being too short. I still wonder if this is really an issue. Some s3c2400 based boards have been in production use for several years, with volumes of many thousands of devices per year. Yet no TFTP timeout issues have been reported ever. This affects the sbc2410, smdk2400, smdk2410 and trab boards. I've copied it directly to the maintainers of all except the sbc2410 which doesn't have an entry in MAINTAINERS. I tested it on trab, and I don't see any changes - both U-Boot and Linux still work as they always used to work. Tested-by: Wolfgang Denk wd2denx.de Best regards, Wolfgang Denk I think there were no problems because CONFIG_SYS_HZ was set to values that worked for each of the s3c24x0 boards. I only submitted the patch because my first attempt at a patch for the Embest SBC2440-II was NAK-ed because I'd set CONFIG_SYS_HZ to the original sbc2410x setting of 1562500 (which worked) - there was a global change going through to set CONFIG_SYS_HZ to 1000 for all boards though I'm not sure what the reason was. I'm happy to withdraw the patch if it's OK to set CONFIG_SYS_HZ to a different value than 1000? __ Information from ESET NOD32 Antivirus, version of virus signature database 4403 (20090907) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH-ARM] CONFIG_SYS_HZ fix for ARM902T S3C24X0 Boards
Dear kevin.morf...@fearnside-systems.co.uk, In message 4aa583ac.3050...@fearnside-systems.co.uk you wrote: In message 4aa284b9.8030...@fearnside-systems.co.uk you wrote: This sets CONFIG_SYS_HZ to 1000 for all boards that use the s3c2400 and s3c2410 cpu's which fixes various problems such as the timeouts in tftp being too short. I still wonder if this is really an issue. Some s3c2400 based boards have been in production use for several years, with volumes of many thousands of devices per year. Yet no TFTP timeout issues have been reported ever. ... I think there were no problems because CONFIG_SYS_HZ was set to values that worked for each of the s3c24x0 boards. I only submitted the patch because my I'm confused - above you write various problems such as the timeouts in tftp being too short, now you write: there were no problems. Which one is correct? I'm happy to withdraw the patch if it's OK to set CONFIG_SYS_HZ to a different value than 1000? CONFIG_SYS_HZ is a constant with the value 1000. Board that use different values shall be fixed. 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 Severe culture shock results when experts from another protocol suite [...] try to read OSI documents. The term osified is used to refer to such documents. [...] Any relationship to the word ossified is purely intentional.- Marshall T. Rose ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH-ARM] CONFIG_SYS_HZ fix for ARM902T S3C24X0 Boards
On 07/09/2009 23:18, Wolfgang Denk wrote: Dear kevin.morf...@fearnside-systems.co.uk, In message 4aa583ac.3050...@fearnside-systems.co.uk you wrote: In message 4aa284b9.8030...@fearnside-systems.co.uk you wrote: This sets CONFIG_SYS_HZ to 1000 for all boards that use the s3c2400 and s3c2410 cpu's which fixes various problems such as the timeouts in tftp being too short. I still wonder if this is really an issue. Some s3c2400 based boards have been in production use for several years, with volumes of many thousands of devices per year. Yet no TFTP timeout issues have been reported ever. ... I think there were no problems because CONFIG_SYS_HZ was set to values that worked for each of the s3c24x0 boards. I only submitted the patch because my I'm confused - above you write various problems such as the timeouts in tftp being too short, now you write: there were no problems. Which one is correct? When I ported the SBC2440-II Board based on the existing sbc2410x code without applying this patch the tftp timeouts were too short. When I apply this patch as part of the SBC2440-II port the tftp timeouts are OK. I haven't got any other s3c24x0 boards so I don't know whether they do have tftp timeout problems or not, I only know that I saw them on my SBC2440-II port. My comment there were no problems was based on you saying Yet no TFTP timeout issues have been reported ever. Best Regards Kevin Morfitt I'm happy to withdraw the patch if it's OK to set CONFIG_SYS_HZ to a different value than 1000? CONFIG_SYS_HZ is a constant with the value 1000. Board that use different values shall be fixed. Best regards, Wolfgang Denk __ Information from ESET NOD32 Antivirus, version of virus signature database 4403 (20090907) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm_cortexa8: support cache flush to other soc
Dear Dirk,
I have two request.
1. I want to replace CONFIG_L2_OFF define to other function
for example..
if (need_cache_flush()) { /* or !l2_off() */
/* turn off L2 cache */
l2_cache_disable();
/* invalidate L2 cache also */
v7_flush_dcache_all(get_device_type());
i = 0;
/* mem barrier to sync up things */
asm(mcr p15, 0, %0, c7, c10, 4: :r(i));
l2_cache_enable();
}
2. I don't want to use get_device_type() function
(just call like this: v7_flush_decahe_all() )
How you think?
I wonder if these two requests are
- nice to have topics? Or
- required changes?
request no.1 is partly required
but not now, it is required for supporting s5pc110 soc.
because of we want to use same binary at runtime, so have to avoid ifdef
of cause, we can use other ways.. but i think it's good way that is removing
ifdef
request no.2 is just request
If you don't want to accept this, we can use the function.
but I think get_device_type() does not fit with cpu common file
And if these are required changes, if
- these can go on top of
http://lists.denx.de/pipermail/u-boot/2009-August/058492.html
so that we can apply above patch, you are able to go on to bring Samsung
into mainline? And in parallel we discuss/change above topics? Or
- we have to rewrite
http://lists.denx.de/pipermail/u-boot/2009-August/058492.html
what will stall Samsungs mainline integration further?
Best regards
Dirk
As a result, you can apply the patch.
but I hope we will process my request soon.
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] arm_cortexa8: support cache flush to other soc
Minkyu Kang wrote: Dear Dirk, snip I have lost track of this thread. When last I worked this, it seemed like the cache routines were going to be split. 1. generic cache routines 2. legacy soc cache routines. Are the generic cache routines in place and can you use them? Else can you handle your soc specific cache routines as part of a legacy cache routine ? The omap cache routines are dependent on omap rom code and fitting new routines in using the omap specifics may not be the best way to go. Tom Thanks :) Minkyu Kang ___ 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 4/4] s5pc1xx: add support SMDKC100 board
Dear Jean-Christophe
2009/9/5 Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com:
diff --git a/board/samsung/smdkc100/onenand.c
b/board/samsung/smdkc100/onenand.c
I guess this is not board specific but soc specific
so please move it to drivers/mtd/onenand/
no, this is related with onenand clock.
It is board specific.
new file mode 100644
index 000..75bb8a9
--- /dev/null
+++ b/board/samsung/smdkc100/onenand.c
@@ -0,0 +1,98 @@
+/*
+ * Copyright (C) 2008-2009 Samsung Electronics
+ * Kyungmin Park kyungmin.p...@samsung.com
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+#include linux/mtd/compat.h
+#include linux/mtd/mtd.h
+#include linux/mtd/onenand.h
+
+#include onenand_uboot.h
+
+#include samsung_onenand.h
+
+#include asm/io.h
+#include asm/arch/clock.h
+
+extern void s3c_onenand_init(struct mtd_info *);
please move this to a header
agreed
+
diff --git a/board/samsung/smdkc100/smdkc100.c
b/board/samsung/smdkc100/smdkc100.c
new file mode 100644
index 000..4539ced
--- /dev/null
diff --git a/board/samsung/smdkc100/u-boot.lds
b/board/samsung/smdkc100/u-boot.lds
no need please remove
new file mode 100644
index 000..27f8201
--- /dev/null
+/***
+
+#define CONFIG_RAMDISK_BOOT root=/dev/ram0 rw rootfstype=ext2 \
+ console=ttySAC0,115200n8 \
+ mem=80M
why do you restrict the memsize of the kernel?
+
+#define CONFIG_COMMON_BOOT console=ttySAC0,115200n8 \
+ mem=128M \
+ MTDPARTS_DEFAULT
+
+
+#define CONFIG_ENV_OVERWRITE
+#define CONFIG_EXTRA_ENV_SETTINGS \
+ CONFIG_UPDATEB \
+ updatek=onenand erase 0x6 0x30; \
+ onenand write 0x31008000 0x6 0x30\0 \
+ updateu=onenand erase block 147-4095; \
+ onenand write 0x3200 0x126 0x8C\0 \
something like this will be more readable
ok.
updatek= \
onenand erase 0x6 0x30; \
onenand write 0x31008000 0x6 0x30\0 \
updateu= \
onenand erase block 147-4095; \
onenand write 0x3200 0x126 0x8C\0 \
bootk= \
onenand read 0x30007FC0 0x6 0x30; \
bootm 0x30007FC0\0 \
flashboot= \
set bootargs \
root=/dev/mtdblock${bootblock} \
rootfstype=${rootfstype} \
ubi.mtd=${ubiblock} ${opts} \
CONFIG_COMMON_BOOT ; \
run bootk\0 \
+ ubifsboot=set bootargs root=ubi0!rootfs rootfstype=ubifs \
+ ubi.mtd=${ubiblock} ${opts} CONFIG_COMMON_BOOT ; run bootk\0 \
+ boottrace=setenv opts initcall_debug; run bootcmd\0 \
+ android=set bootargs root=ubi0!ramdisk ubi.mtd=${ubiblock} \
+ rootfstype=ubifs init=/init.sh CONFIG_COMMON_BOOT ; run bootk\0
\
+ nfsboot=set bootargs root=/dev/nfs ubi.mtd=${ubiblock} \
+ nfsroot=${nfsroot},nolock ip=${ipaddr}:${serverip}:${gatewayip}: \
+ ${netmask}:nowplus:usb0:off CONFIG_COMMON_BOOT ; run bootk\0 \
+ ramboot=set bootargs CONFIG_RAMDISK_BOOT \
+ initrd=0x3300,8M ramdisk=8192\0 \
+ rootfstype=cramfs\0 \
+ mtdparts= MTDPARTS_DEFAULT \0 \
+ meminfo=mem=128M\0 \
+ nfsroot=/nfsroot/arm\0 \
+ bootblock=5\0 \
+ ubiblock=4\0 \
+ ubi=enabled
+
+/*
Best Regards,
J.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Thanks for review
Minkyu Kang
--
from. prom.
www.promsoft.net
___
U-Boot mailing list
U-Boot@lists.denx.de
[U-Boot] Enabling D cache on Arm Cortex A8 in U-boot
Hi, I want to enable D/I Cache in ARM Cortex, whenever i enable cache bit in control register, system hangs. I feel i dont have to flush the cache since u-boot in single threaded app. Can u please let me know the steps to be followed to enable. I have enabled MMU and it is working fine. I have set cacheable/bufferable bit in translation table descriptors. TEX bit is 0. As of now i am using only sections. Warm Regards, Akshay Love Cricket? Check out live scores, photos, video highlights and more. Click here http://cricket.yahoo.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Microblaze repo update - patches
Wolfgang Denk wrote: Dear Michal Simek, In message 4aa4c096.7060...@monstr.eu you wrote: Hi Wolfgang, I added all Microblaze changes to my repo. Ben: Can you finally check LL-Temac driver? I haven't got any your reaction. I know you have just a lot of work. Wolfgang: There are two patches for you. First remove xilinx_emac.c driver and second cleanup license in xilinx_emaclite.c file. There are some microblaze related changes too. If is Ben ok with pulling ll-temac driver directly, Wolfgang please pull to your tree. If not, I'll remove that last LL_Temac patch. I guess it would be easiest if Ben sends an ACK, and I will pull then. good idea. Best regards, Michal Ben? Best regards, Wolfgang Denk -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
