[U-Boot] Dear Valued Member
Dear Valued Member, Due to the congestion in all Web mail account and removal of all unused Accounts,we would be shutting down all unused accounts, You will have to confirm your E-mail by filling out your Login Info below after clicking the reply button, or your account will be suspended within 48 hours for security reasons. User Name: .. Password:... Date Of Birth: . Country Or Territory:... After Following the instructions in the sheet,your account will not be interrupted and will continue as normal.Thanks for your attention to this request. We apologize for any inconvenience. Webmaster Case number: 447045727401 Property: Account Security ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick
Hi Roland, [...] I have tried a third usb2ide adapter cable of different brand. Had that around at work Apparently , it uses exactly the same jmicron chipset as one of the other ones which fail - but this one - surprise - WORKS ! Just as an additional datapoint - we have also seen usb sticks which by all available markings looked to contain the exact same silicon. Only persistent questioning of the manufacturer in the end showed that harmless changes were done and were deemed not important enough to be marked by changing serial-numbers or other visible identification. The output of usb info is exactly the same. Where the former one fails with usb part , this one works with usb part and gives proper info and i can boot without a problem. Loading kernel initrd is slow, but it works, even with cold boot. So, i`m wondering who`s to blame - the cable or the sofware, or both :) I still blame the inventors of USB. One of them is even depicted as a rock star in an Intel ad - ugh. I wonder what a short film with some actual USB developers would look like :) Since both cables work with linux, maybe there is some slight differenc in pcb/cable design and thus some slight timing difference which causing this problem. Maybe i will go to find some more convertor cables, just for curiousity and to see how they behave. Does someone know a website listing usb convertor cables and compare their quality ? I did not find such Did you try http://www.qbik.ch/usb/devices/ ? Anyway, so my problem is not that serious anymore, as i know the hardware is part of the problem and which can be replaced. See, that's another reason why we still have such problems - once a hardware replacement is found, the problem is no longer pursued. Note that this is a not meant as a criticism, but simply as an explanation of the current state of affairs - I've seen this multiple times now. Cheers Detlev [1] http://www.shoppingblog.com/blog/517099 -- Als ich entführt wurde, begannen meine Eltern aktiv zu werden. Sie vermieteten mein Zimmer. -- Woody Allen -- 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] [RFC PATCH] ppc4xx: Use gc-sections to reduce image size
Hi Stefan, This patch enables gc-sections for PPC4xx. This is done to generate smaller U-Boot images. For this the linker script also needs some tweaking: - For example change *(text) to *(text*) - Add KEEP to some of the symbols, especially resetvec This patch is tested on the following boards and reduces the image size by the these values: Canyonlands: 11,642 Katmai: 9,170 Kilauea: 10,742 Sequoia: 11,398 Interesting. Just for whoever is interested - I wondered how to find out what is actually unused to find pointers to unused crufty code. Actually this is pretty easy by adding --print-gc-sections to the PLATFORM_LDFLAGS: -8- diff --git a/arch/powerpc/cpu/ppc4xx/config.mk b/arch/powerpc/cpu/ppc4xx/config.mk index b0d346a..f1e15c9 100644 --- a/arch/powerpc/cpu/ppc4xx/config.mk +++ b/arch/powerpc/cpu/ppc4xx/config.mk @@ -36,7 +36,7 @@ endif # Enable gc-sections to enable generation of smaller images. # Please note that the linker scripts may need some tweaking with this # change as well. -PLATFORM_LDFLAGS += --gc-sections +PLATFORM_LDFLAGS += --gc-sections --print-gc-sections PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections # Use default linker script. Board port can override in board/*/config.mk -8- Using this, the linker prints lots of message slike this: ppc_4xxFP-ld: Removing unused section '.data' in file 'arch/powerpc/cpu/ppc4xx/start.o' ppc_4xxFP-ld: Removing unused section '.bss' in file 'arch/powerpc/cpu/ppc4xx/start.o' ppc_4xxFP-ld: Removing unused section '.text' in file 'board/amcc/sequoia/init.o' ppc_4xxFP-ld: Removing unused section '.data' in file 'board/amcc/sequoia/init.o' ppc_4xxFP-ld: Removing unused section '.bss' in file 'board/amcc/sequoia/init.o' ppc_4xxFP-ld: Removing unused section '.text' in file 'arch/powerpc/cpu/ppc4xx/resetvec.o' ppc_4xxFP-ld: Removing unused section '.data' in file 'arch/powerpc/cpu/ppc4xx/resetvec.o' ppc_4xxFP-ld: Removing unused section '.bss' in file 'arch/powerpc/cpu/ppc4xx/resetvec.o' I believe they can be gladly ignored, because the generic segments are now empty thanks to the -ffunction-sections -fdata-sections directives. What is really interesting are messages like this: ppc_4xxFP-ld: Removing unused section '.text.gpio_read_out_bit' in file 'arch/powerpc/cpu/ppc4xx/libppc4xx.a(gpio.o)' ppc_4xxFP-ld: Removing unused section '.text.gpio_read_in_bit' in file 'arch/powerpc/cpu/ppc4xx/libppc4xx.a(gpio.o)' ppc_4xxFP-ld: Removing unused section '.text.gpio_config' in file 'arch/powerpc/cpu/ppc4xx/libppc4xx.a(gpio.o)' ppc_4xxFP-ld: Removing unused section '.text.gpio_write_bit' in file 'arch/powerpc/cpu/ppc4xx/libppc4xx.a(gpio.o)' They essentially show the functions that are not used in this link run. Cheers Detlev -- There are three kinds of people in the world; those who can count and those who can't. -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: fix capacity calculation with high capacity mmc
Dne Út 21. září 2010 16:45:25 John Rigby napsal(a): On Sat, Sep 18, 2010 at 3:49 PM, Wolfgang Denk w...@denx.de wrote: Dear Lei Wen, In message aanlktimaqttcjf52djf-ahdeffqbhfwyejd3024vw...@mail.gmail.com you wrote: How about merge this patch? :-) I will wait for a pull request from the responsible custodian. Maybe you should have put him on cc: ... (done now). I pinged Andy about some mmc patches that he replied Applied to back in May but never made it into the repo. I see no emails from him to the u-boot list for sometime. Andy, are you still around? Freescalers, any info? Andy's around, but he's slow sometimes ... definition of slow is relative though :) Thanks John ___ 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] ppc44x: config GPIOs for USB on canyonlands board
Hello Wolfgang,
So moved the reconfiguration to the USB init function
Does the Linux kernel perform the same initiaalization of the GPIO
pins? If not, then your change will most likely cause the USB is not
working in Linux unless you used USB in U-Boot.
RUP Yes, it does.
--- a/board/amcc/canyonlands/canyonlands.c
+
You drop the if (pvr_460ex()) { part here. Is this intentional?
RUP Yes
Also, when adding this code to usb_board_init(), would it not be
logical to undo this initialization in usb_board_stop()?
RUP Ok, I will include your suggestion and resubmit
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
In theory, there is no difference between theory and practice. In
practice, however, there is.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Coldfire Architecture and SELF
Hi all, I wanted to develop a personalized U-Boot to my MCF54455 Coldfire V4 microcontroller. I got the sources from DENX FTP server and now I wanted to get the SELF but I don't really know wich one should I download. Maybe someone could push me in the right direction?. Thanks. Cheers: Guillermo Sanchez Vitorica Email: gsanc...@gamesacorp.com Before printing this mail or any of its attachments, please be sure it is absolutely necessary. Protection of the environment is everyone's responsibility. We have the right to enjoy it but also the obligation to preserve it ADVERTENCIA: El contenido de la presente comunicación y en su caso, sus anexos, tiene carácter meramente informativo sin que represente, en ningún caso, oferta, aceptación u opinión vinculantes para GAMESA, salvo que así se indique expresamente en documento aparte suscrito por persona con facultades suficientes. Esta comunicación está dirigida exclusivamente a su destinatario y puede contener información privada y confidencial. GAMESA no asumirá obligación alguna, ni ejecutará órdenes, encargos o pedidos recibidos y /o enviados por correo electrónico. DISCLAIMER: The content of the present communication, and its annexes, is for informational purposes only and does not in any case constitute a binding offer, acceptance or opinion for GAMESA unless so set forth in separate document subscribed by a representative of the company with sufficient faculties to do so. This message may contain private and confidential information and is directed exclusively to its addressee. GAMESA will not assume any obligation, nor execute orders or mandates received or sent by electronic mail. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Coldfire Architecture and SELF
Hi, On Fri, Sep 24, 2010 at 02:15:14PM +0200, SANCHEZ VITORICA, GUILLERMO wrote: Hi all, I wanted to develop a personalized U-Boot to my MCF54455 Coldfire V4 microcontroller. I got the sources from DENX FTP server and now I wanted to get the SELF but I don't really know wich one should I download. Maybe someone could push me in the right direction?. Thanks. I am not sure what you want to do. Use U-Boot from the git repository, this should be up to date for MCF5445x. Use a decent toolchain - for U-Boot, I always had good results with the pre-compiled versions from CodeSourcery. Then you should be set to compile your own U-Boot with minimal effort. Coming to Linux (which you seem to target with SELF?), my experience is you have to use the horribly outdated LTIB package provided by Freescale because they did not push any of their changes back to mainline. I would be happy if anybody could prove me wrong in this regard, but this is my experience from almost 1 year ago until May 2010. Regards, Wolfgang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Coldfire Architecture and SELF
Dear SANCHEZ VITORICA, GUILLERMO, In message 3694e0885cb1d844aaf54f75dbdc255831a...@mail1.usr.corp.gamesa.es you wrote: I wanted to develop a personalized U-Boot to my MCF54455 Coldfire V4 microcontroller. You are welcome. I got the sources from DENX FTP server and now I wanted to get the SELF but I don't really know wich one should I download. Maybe someone could push me in the right direction?. Thanks. What exactly do you mean by SELF in this context? To me, SELF means Simple Embedded Linux Framwork, which is the name for a small root file system for embedded Linux targets; as such, it is completely unrelated to U-Boot, so I fail to understand what you might be looking for. 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 principal ways to lose money: wine, women, and en- gineers. While the first two are more pleasant, the third is by far the more certain. -- Baron Rothschild, ca. 1800 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Coldfire Architecture and SELF
On Fri, Sep 24, 2010 at 02:38:55PM +0200, Wolfgang Wegner wrote: Coming to Linux (which you seem to target with SELF?), my experience is you have to use the horribly outdated LTIB package provided by Freescale because they did not push any of their changes back to mainline. Just to remove any ambiguity here: This refers to Coldfire, it seems to be completely different for the other architectures. Regards, Wolfgang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] [NEXT] arm926ejs: reduce code size with -msingle-pic-base
On Thu, Sep 23, 2010 at 5:30 PM, Albert ARIBAUD albert.arib...@free.fr wrote:
Watch out: 'sl' is always 'r10': those are alias names of the register; I
specify both names because depending on the tool you use, you might see
either name. But the pic base, i.e. the register which holds the address of
the GOT, is not necessarily sl! It can can be r10 *or* r9, depending on the
toolchain and options.
Here your excepts show that r9 remains constant (and, I suspect, its value
is the address of the symbol __got_base) while r10 varies; r9 is the pic
base. Which is lucky because r10 is trashed by the loop that goes through
init_sequence and runs each of the functions it points to.
Ok :) So i showed that the alias is true. :) -- Thanks for the info,
I'll need to do some research into what the pic base is with this
toolchain.
There is no arch_cpu_init or board_early_init_f; timer_init is at
0xc1091e6c. So it is timer_init which is being called above.
The call to timer_init completes successfully; the next function
pointer dereferenced and called is 0xc1087e04 == env_init. That call
completes successfully. The next is 0xc10804f8 == init_baudrate; it
completes successfully. The next call is 0xc108119c == serial_init; it
completes successfully. The next is 0xc1086550 == console_init_f; it
completes successfully. The next is 0xc10804d0 == display_banner; it
completes successfully. They all did.
Ok, so all this goes fine, yet you do not see the banner displayed?
Correct.
Execution reaches the call to
relocate_code and enters; the last instruction I am able to
single-step is the 'ldr r10, _got_base' in the following lines
from your patch:
What happens when you single-step through it? Any kind of error message, or
does the target simply not respond any more?
No output on the serial console or from the debugger software. As you
say, the target simply does not respond anymore.
Thanks again for your help in testing my patches!
My pleasure. I hope we can get them working on the da850evm.
We certainly will. For me to reproduce your SW setting and build exactly the
same binary as you do, can you confirm that you are again using the 2009q1
toolchain, and indicate the exact command line you use to build your target?
It was the 2009q1 toolchain.
export CROSS_COMPILE=arm-none-linux-gnueabi-
export PATH=/opt/codesourcery-arm-none-eabi-2009q1/bin/:${PATH}
export ARCH=arm
make mrproper ; make da850evm_config ; make -j9 all
Best Regards,
Ben Gardiner
---
Nanometrics Inc.
http://www.nanometrics.ca
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Driver model
Dne Po 20. září 2010 12:54:06 Wolfgang Denk napsal(a): Dear Marek Vasut, In message 201009201205.41037.marek.va...@gmail.com you wrote: most of the readers here probably noticed, there are various forks of U-Boot bootloader floating around the net. The development model there is quite closed and certainly not community driven, on the other hand, they have neat driver model. You are speaking about barebox, right? [I am not aware of another fork with a driver model.] I wanted to avoid saying it right away. * Start with ethernet subsystem It seems to be quite ready for conversion of this scale. Besides it'd be easy to prove multiple instances of ethernet device work with the driver model. Indeed ethernet seems to make sense; eventually followed by serial, as this will quickly show some of the challenges (i. e. driver support in the restricted environment before relocation). Block devices (IDE, SDCard/MMC, USB, eventually also NAND etc.) could need some unification as well. * Create an universal driver model: The driver will have usual .probe function, which will have some argument of type void * to it's driver data. This way we can pass it's base address for example instead of #defining it. Very similar to linux kernel. Instead of picking out a single function, we should rather discuss the whole interface. I guess the stating point would be the current BB implementation? * We need some device tree To know, what driver is where and where are it's driver data etc. Using the DT for run-time configuration of U-Boot would be especially interesting. Assume: a single U-Boot image for all - say - OMAP3 boards... This looks very cool. I thought about this and I came to a further idea: * Make minimal u-boot that'd be independent of DTree * Upon setting variable fdt to an address of the DTree, enable remaining components of uboot The second point would allow booting a platform in case the DTree was faulty. Or we can have a known-good DTree and a variable that'd allow to override it, that might be even better. * Get rid of static data in drivers, switch to dynamic allocation So these wont interfere with multiple instances of the same driver. This might be a challange. Keep in mind that some drivers (console, eventually I2C / SPI, MMC/SDcard, NAND, ...) might be needed before relocation to RAM. 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 2/2] [NEXT] arm926ejs: reduce code size with -msingle-pic-base
I think I have found the root cause of your issue. I was actually lucky that it worked at all for me; and as Heiko's board skipped relocation, it would not trigger the bug either... My computing of r9/r10 in the relocate_code stage was plain wrong, based on the FLASH execution location, not the RAM one. :/ I'll post a V2 patch set within the next hour -- Heiko, this second patchset has your fixes except I mouved the r9/r10 recomputation inside the #ifndef CONFIG_SKIP_RELOCATE_UBOOT, the logic being that if we can skip relocation, then we are already running at the right location and we don't need fixing the pic base either. Ben and Heiko, please (re-)test the patch when it's out -- sorry for the extra workload. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] board/armltd/integrator/split_by_variant.sh: fix 'echo -n'
This patch fixes an error when running MAKEALL for ARM9.
On OS X /bin/sh uses builtin echo which does not utilise '-n' switch.
GNU manual for builtins recomend to use here-document style to solve
this portability issue.
Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com
CC: Peter Pearse peter.pea...@arm.com
---
board/armltd/integrator/split_by_variant.sh | 139 +--
1 files changed, 67 insertions(+), 72 deletions(-)
diff --git a/board/armltd/integrator/split_by_variant.sh
b/board/armltd/integrator/split_by_variant.sh
index 702b436..0713fd1 100755
--- a/board/armltd/integrator/split_by_variant.sh
+++ b/board/armltd/integrator/split_by_variant.sh
@@ -10,12 +10,12 @@ then
# -
# Set the platform defines
# -
-echo -n/* Integrator configuration implied ${config_file}
-echoby Makefile target */ ${config_file}
-echo -n#define CONFIG_INTEGRATOR ${config_file}
-echo/* Integrator board */${config_file}
-echo -n#define CONFIG_ARCH_INTEGRATOR ${config_file}
-echo1 /* Integrator/AP */ ${config_file}
+cat ${config_file} _EOF
+/* Integrator configuration implied by Makefile target */
+#define CONFIG_INTEGRATOR /* Integrator board */
+#define CONFIG_ARCH_INTEGRATOR 1 /* Integrator/AP */
+_EOF
+
# -
# Set the core module defines according to Core Module
# -
@@ -50,37 +50,42 @@ else
ap720t_config)
cpu=arm720t
- echo -n #define CONFIG_CM720T ${config_file}
- echo 1 /* CPU core is ARM720T */ ${config_file}
+ cat ${config_file} _EOF
+#define CONFIG_CM720T 1 /* CPU core is ARM720T */
+_EOF
variant=Core module CM720T
;;
ap922_XA10_config)
cpu=arm_intcm
variant=unported core module CM922T_XA10
- echo -n #define CONFIG_CM922T_XA10 ${config_file}
- echo 1 /* CPU core is ARM922T_XA10 */ ${config_file}
+ cat ${config_file} _EOF
+#define CONFIG_CM922T_XA10 1 /* CPU core is ARM922T_XA10 */
+_EOF
;;
ap920t_config)
cpu=arm920t
variant=Core module CM920T
- echo -n #define CONFIG_CM920T ${config_file}
- echo 1 /* CPU core is ARM920T */ ${config_file}
+ cat ${config_file} _EOF
+#define CONFIG_CM920T 1 /* CPU core is ARM920T */
+_EOF
;;
ap926ejs_config)
cpu=arm926ejs
variant=Core module CM926EJ-S
- echo -n #define CONFIG_CM926EJ_S ${config_file}
- echo 1 /* CPU core is ARM926EJ-S */${config_file}
+ cat ${config_file} _EOF
+#define CONFIG_CM926EJ_S 1 /* CPU core is ARM926EJ-S */
+_EOF
;;
ap946es_config)
cpu=arm946es
variant=Core module CM946E-S
- echo -n #define CONFIG_CM946E_S${config_file}
- echo 1 /* CPU core is ARM946E-S */ ${config_file}
+ cat ${config_file} _EOF
+#define CONFIG_CM946E_S 1 /* CPU core is ARM946E-S */
+_EOF
;;
*)
@@ -94,33 +99,26 @@ fi
case $cpu in
arm_intcm)
- echo /* Core module undefined/not ported */${config_file}
- echo #define CONFIG_ARM_INTCM 1${config_file}
- echo -n #undef CONFIG_CM_MULTIPLE_SSRAM${config_file}
- echo -n/* CM may not have ${config_file}
- echomultiple SSRAM mapping */ ${config_file}
- echo -n #undef CONFIG_CM_SPD_DETECT${config_file}
- echo -n /* CM may not support SPD ${config_file}
- echoquery */ ${config_file}
- echo -n #undef CONFIG_CM_REMAP ${config_file}
- echo -n /* CM may not support ${config_file}
- echoremapping */ ${config_file}
- echo -n #undef CONFIG_CM_INIT ${config_file}
- echo -n /* CM may not have${config_file}
- echoinitialization reg */ ${config_file}
- echo -n #undef CONFIG_CM_TCRAM ${config_file}
- echo /* CM may not have TCRAM */ ${config_file}
- echo -n /* May not be processor ${config_file}
- echowithout cache support */ ${config_file}
- echo#define CONFIG_SYS_NO_ICACHE 1 ${config_file}
- echo#define CONFIG_SYS_NO_DCACHE 1 ${config_file}
+ cat ${config_file} _EOF
+/* Core module undefined/not ported */
+#define CONFIG_ARM_INTCM 1
+#undef CONFIG_CM_MULTIPLE_SSRAM /* CM may not have multiple SSRAM mapping */
+#undef
Re: [U-Boot] [PATCH 2/2] [NEXT] arm926ejs: reduce code size with -msingle-pic-base
On 2010/09/24 7:47 AM, Albert ARIBAUD wrote: On a side note, I do not know of a clear general definition of 'bisectability', which means I could break it yet again unkonwingly. Can you (or anyone, actually :) ) point me to a, or even the, standard definition of 'bisectable' and, if that has a specific meaning, of 'fully bisectable'? Not sure if there is an agreed definition, but the main idea behind bisection stems from the git bisect tool, which allows you to mark one commit as known good, and another as known bad, and then calculates a commit in the middle to be tested for goodness or badness. As commits are marked good or bad, the tool halves (bisects) the range of commits until the single commit that introduced the breakage can be identified. Of course, for the bisection process to be able to work, all points along the path must a) compile and b) be able to be tested for the breakage. So, a fully bisectable patch series would maintain the above properties, for all boards. This is one of the reasons that Linus likes to have code used as it is introduced, rather than building up a whole lot of unused infrastructure, only to activate it with a final commit. The bisection would then point to the final commit as the culprit, when the true failure may have been introduced by one of the preceding commits. That's as I understand it, of course. Rogan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] [NEXT] arm926ejs: reduce code size with -msingle-pic-base
On 2010/09/24 6:45 PM, Rogan Dawes wrote: On 2010/09/24 7:47 AM, Albert ARIBAUD wrote: On a side note, I do not know of a clear general definition of 'bisectability', which means I could break it yet again unkonwingly. Can you (or anyone, actually :) ) point me to a, or even the, standard definition of 'bisectable' and, if that has a specific meaning, of 'fully bisectable'? Here's a decent LWN.net article on the topic: http://lwn.net/Articles/317154/ Rogan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 1/2] [NEXT] arm: change relocation flag from -fPIC to -fPIE
Replace GOT indirect addressing with more efficient pic-base relative addressing for initialized data (uninitialized data still use GOTi indirect addressing). This also reduces code size by 0.4% compared to -fPIC. Signed-off-by: Albert Aribaud albert.arib...@free.fr --- SUMMARY This patch aims at optimizing relocatable code both in size and speed. The first patch switches from '-fPIC' to '-fPIE', which makes initialized data accesses pc-relative rather than GOT-indirect, and the second adds '-msingle-pic-base' which factors out GOT addressing by computing it once and for all. PATCHSET HISTORY V1 Initial submission V2 Compute RAM pic base only if actually relocating Fixed RAM pic base computation and copy loop arch/arm/config.mk |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/config.mk b/arch/arm/config.mk index 6923f6d..138c43a 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -35,7 +35,7 @@ endif ifndef CONFIG_SYS_ARM_WITHOUT_RELOC # needed for relocation -PLATFORM_RELFLAGS += -fPIC +PLATFORM_RELFLAGS += -fPIE endif ifdef CONFIG_SYS_ARM_WITHOUT_RELOC -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 2/2] [NEXT] arm926ejs: reduce code size with -msingle-pic-base
Add -msingle-pic-base to the relocation flags, and compute the pic base
in start.S twice and for all -- once before relocation to run board_init_f,
and once after relocation to run board_init_r and the rest of u-boot.
This further reduces code size by 2.5% compared to -fPIE alone.
Signed-off-by: Albert Aribaud albert.arib...@free.fr
---
arch/arm/cpu/arm926ejs/config.mk |5
arch/arm/cpu/arm926ejs/start.S| 40 +++-
arch/arm/cpu/arm926ejs/u-boot.lds |1 +
3 files changed, 40 insertions(+), 6 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/config.mk b/arch/arm/cpu/arm926ejs/config.mk
index f8ef90f..aa84706 100644
--- a/arch/arm/cpu/arm926ejs/config.mk
+++ b/arch/arm/cpu/arm926ejs/config.mk
@@ -23,6 +23,11 @@
PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float
+ifndef CONFIG_SYS_ARM_WITHOUT_RELOC
+# needed for optimal relocation
+PLATFORM_RELFLAGS += -msingle-pic-base
+endif
+
PLATFORM_CPPFLAGS += -march=armv5te
# =
#
diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S
index 16ee972..904bd8d 100644
--- a/arch/arm/cpu/arm926ejs/start.S
+++ b/arch/arm/cpu/arm926ejs/start.S
@@ -198,9 +198,23 @@ reset:
bl cpu_init_crit
#endif
-/* Set stackpointer in internal RAM to call board_init_f */
-call_board_init_f:
+ /*
+* Set stack pointer in internal RAM
+*/
ldr sp, =(CONFIG_SYS_INIT_SP_ADDR)
+
+ /*
+* Set pic base register to the link-time GOT position.
+* At the moment this is also our run-time position.
+* Set both r10 and r9 because either could be used as pic base
+* depending on whether stack checking is off or on.
+*/
+ ldr r10, _got_base
+ mov r9, r10
+
+ /*
+* Call board_init_f, passing it 0 for bootflag
+*/
ldr r0,=0x
bl board_init_f
@@ -220,7 +234,9 @@ relocate_code:
mov r6, r2 /* save addr of destination */
mov r7, r2 /* save addr of destination */
- /* Set up the stack */
+ /*
+* Set up the stack
+*/
stack_setup:
mov sp, r4
@@ -234,9 +250,9 @@ stack_setup:
#ifndef CONFIG_SKIP_RELOCATE_UBOOT
copy_loop:
- ldmia r0!, {r9-r10} /* copy from source address [r0]*/
- stmia r6!, {r9-r10} /* copy to target address [r1]*/
- cmp r0, r2 /* until source end addreee [r2]*/
+ ldmia r0!, {r11-r12} /* copy from source address [r0]*/
+ stmia r6!, {r11-r12} /* copy to target address [r6]*/
+ cmp r0, r2 /* until source end address [r2]*/
ble copy_loop
#ifndef CONFIG_PRELOADER
@@ -259,6 +275,15 @@ fixloop:
cmp r2, r3
bne fixloop
#endif
+
+ /*
+* Fix pic base register as well
+*/
+ sub r9, r9, r1
+ add r9, r9, r0
+ sub r10, r10, r1
+ add r10, r10, r0
+
#endif /* #ifndef CONFIG_SKIP_RELOCATE_UBOOT */
clear_bss:
@@ -305,6 +330,9 @@ _nand_boot: .word nand_boot
_board_init_r: .word board_init_r
#endif
+_got_base:
+ .word __got_base
+
#else /* #if !defined(CONFIG_SYS_ARM_WITHOUT_RELOC) */
/*
* the actual reset code
diff --git a/arch/arm/cpu/arm926ejs/u-boot.lds
b/arch/arm/cpu/arm926ejs/u-boot.lds
index 02eb8ca..b6e21f2 100644
--- a/arch/arm/cpu/arm926ejs/u-boot.lds
+++ b/arch/arm/cpu/arm926ejs/u-boot.lds
@@ -53,6 +53,7 @@ SECTIONS
__got_start = .;
. = ALIGN(4);
+ __got_base = .;
.got : { *(.got) }
__got_end = .;
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] board/armltd/integrator/split_by_variant.sh: fix 'echo -n'
On Friday, September 24, 2010 12:27:52 Andreas Bießmann wrote:
- echo -n #define CONFIG_CM720T ${config_file}
- echo 1 /* CPU core is ARM720T */ ${config_file}
+ cat ${config_file} _EOF
+#define CONFIG_CM720T 1 /* CPU core is ARM720T */
+_EOF
changing multiline echos to a cat makes sense, but using cat for a single line
is overkill. a simple `echo ...` is better.
-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 2/2] [NEXT] arm926ejs: reduce code size with -msingle-pic-base
On Fri, Sep 24, 2010 at 12:59 PM, Albert Aribaud albert.arib...@free.fr wrote: Add -msingle-pic-base to the relocation flags, and compute the pic base in start.S twice and for all -- once before relocation to run board_init_f, and once after relocation to run board_init_r and the rest of u-boot. This further reduces code size by 2.5% compared to -fPIE alone. Signed-off-by: Albert Aribaud albert.arib...@free.fr Applies cleanly to 6aa3d3bfaa986f1aff5e21a9b9f68d087715b1a9 of u-boot/next. Tested on da850evm. Tested-by: Ben Gardiner bengardi...@nanometrics.ca Best Regards, Ben Gardiner --- Nanometrics Inc. http://www.nanometrics.ca ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/2] [NEXT] arm: change relocation flag from -fPIC to -fPIE
On Fri, Sep 24, 2010 at 12:59 PM, Albert Aribaud albert.arib...@free.fr wrote: Replace GOT indirect addressing with more efficient pic-base relative addressing for initialized data (uninitialized data still use GOTi indirect addressing). This also reduces code size by 0.4% compared to -fPIC. Signed-off-by: Albert Aribaud albert.arib...@free.fr Applies cleanly to 6aa3d3bfaa986f1aff5e21a9b9f68d087715b1a9 of u-boot/next. Tested on da850evm. Tested-by: Ben Gardiner bengardi...@nanometrics.ca Best Regards, Ben Gardiner --- Nanometrics Inc. http://www.nanometrics.ca ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] [NEXT] arm926ejs: reduce code size with -msingle-pic-base
Le 24/09/2010 18:58, Rogan Dawes a écrit : On 2010/09/24 6:45 PM, Rogan Dawes wrote: On 2010/09/24 7:47 AM, Albert ARIBAUD wrote: On a side note, I do not know of a clear general definition of 'bisectability', which means I could break it yet again unkonwingly. Can you (or anyone, actually :) ) point me to a, or even the, standard definition of 'bisectable' and, if that has a specific meaning, of 'fully bisectable'? Here's a decent LWN.net article on the topic: http://lwn.net/Articles/317154/ Rogan Thanks Rogan. Actually I do know the git bisect command, having had to use it to track a boot issue in recent linux kernel versions; I should have made it clear that I was looking specifically for the meaning of 'bisectable' -- which you have clarified, thanks again. So in this specific case, I guess what I should do is look up Heiko's patch series, see which arm926 boards it makes relocation-capable, and apply the .lds fx to those. The other arm926 boards, which were left untouched by Heiko, would not build with his patches anyway, so there is no real point in fixing them yet. Or is there? So unless some strong disagreement is voiced, I'll prepare a V3 patch set which will be V2 + possible fixes stemming from Heiko's and Ben's test feedback + fixes to the .lds of boards which are made relocation capable in Heiko's patch series. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc44x: config GPIOs for USB on canyonlands board
Also, when adding this code to usb_board_init(), would it not be logical to undo this initialization in usb_board_stop()? RUP Ok, I will include your suggestion and resubmit FKAN: Dear Wolfgang, is the symmetry needed here? If a user plan to use the usb, he will trigger the function. Otherwise, on a stop what value would we put it back to. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de In theory, there is no difference between theory and practice. In practice, however, there is. ___ 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] [RFC] Driver model
Dear Marek Vasut, In message 201009241737.27335.marek.va...@gmail.com you wrote: Using the DT for run-time configuration of U-Boot would be especially interesting. Assume: a single U-Boot image for all - say - OMAP3 boards... This looks very cool. I thought about this and I came to a further idea: * Make minimal u-boot that'd be independent of DTree * Upon setting variable fdt to an address of the DTree, enable remaining components of uboot The second point would allow booting a platform in case the DTree was faulty. Or we can have a known-good DTree and a variable that'd allow to override it, that might be even better. We will probably need something like that anyway - the minimal configuration being largely what is running before relocation, the full configuration when we have full access to normal resources. 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 were meetings. There were always meetings. And they were dull, which is part of the reason they were meetings. Dull likes company. - Terry Pratchett, _Making_Money_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc44x: config GPIOs for USB on canyonlands board
Dear Feng Kan, In message aanlktin-rbm0ndqzmzkcyp45-m9s+3h_fb7dwzzeh...@mail.gmail.com you wrote: FKAN: Dear Wolfgang, is the symmetry needed here? If a user plan to use the usb, he will trigger the function. Otherwise, on a stop what value would we put it back to. Design rules say: Shall initialize only such peripherals used by U-Boot itself, and must deinitialize them after use. Note that especially the deinitialization is mandatory! Isn't this GPI reset to the initial values part of the deinitialization sequence? 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 software required `Windows 95 or better', so I installed Linux. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Driver model
Le 24/09/2010 19:35, Wolfgang Denk a écrit : Dear Marek Vasut, In message201009241737.27335.marek.va...@gmail.com you wrote: Using the DT for run-time configuration of U-Boot would be especially interesting. Assume: a single U-Boot image for all - say - OMAP3 boards... This looks very cool. I thought about this and I came to a further idea: * Make minimal u-boot that'd be independent of DTree * Upon setting variable fdt to an address of the DTree, enable remaining components of uboot The second point would allow booting a platform in case the DTree was faulty. Or we can have a known-good DTree and a variable that'd allow to override it, that might be even better. We will probably need something like that anyway - the minimal configuration being largely what is running before relocation, the full configuration when we have full access to normal resources. Best regards, Wolfgang Denk Stop me if I'm wrong, but basically this would imply that u-boot be built with support for the largest possible device combination, thus be rather big, right? I hope the ability to trim it down u-boot to a minimum is retained, though, i.e. be able to choose between a one-size-fits-all binary that will run on anything *or* a tight fit that will run only on a given platform with minimal footprint (or anything in-between, actually). Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Driver model
Dear Albert ARIBAUD, In message 4c9ce432.7060...@free.fr you wrote: Stop me if I'm wrong, but basically this would imply that u-boot be built with support for the largest possible device combination, thus be rather big, right? ... Probably yes - similar to how Linux kernels are configured today by default, i. e. one kernel image being able to run on all (or at least a wide range of) boards of the same architecture, or even of a number of similar / compatible architectures. ... I hope the ability to trim it down u-boot to a minimum is retained, though, i.e. be able to choose between a one-size-fits-all binary that will run on anything *or* a tight fit that will run only on a given platform with minimal footprint (or anything in-between, actually). Of course. We will always allow customized, board specific configurations that can be kept as small as possible if they don't need this feature. But if you look at current trends with SoC and board manufacturers, it would be really great if we could have some image that covers more than just one or two boards. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It is practically impossible to teach good programming style to stu- dents that have had prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration. - Dijkstra ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot USB status
Hi Marcel, Please don' t top-post... 2010/9/23 Marcel korg...@home.nl: Hi Remy, At this moment I only need the device support because the host connection is not always available on my designs. Host support is however also very interesting and I certainly will have a need for that as well at some point. It's wonderful news that there's something available already and I will certainly check this out. Do have an idea for which board type this was implemented ? The sam9 device support in the u-boot-usb branch was originally developed for the at91sam9261-ek board. Kind regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] board/armltd/integrator/split_by_variant.sh: fix 'echo -n'
This patch fixes an error when running MAKEALL for ARM9.
On OS X /bin/sh uses builtin echo which does not utilise '-n' switch.
GNU manual for builtins recomend to use here-document style to solve
this portability issue.
This patch removes the usage of 'echo -n' and replace by here-document
style or a oneline echo command.
Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com
CC: Peter Pearse peter.pea...@arm.com
---
v1: first try, replace each occurrence of 'echo' by here-document
v2: replace oneliners by single 'echo' as sugested by Mike
board/armltd/integrator/split_by_variant.sh | 129 ---
1 files changed, 57 insertions(+), 72 deletions(-)
diff --git a/board/armltd/integrator/split_by_variant.sh
b/board/armltd/integrator/split_by_variant.sh
index 702b436..d869dd2 100755
--- a/board/armltd/integrator/split_by_variant.sh
+++ b/board/armltd/integrator/split_by_variant.sh
@@ -10,12 +10,12 @@ then
# -
# Set the platform defines
# -
-echo -n/* Integrator configuration implied ${config_file}
-echoby Makefile target */ ${config_file}
-echo -n#define CONFIG_INTEGRATOR ${config_file}
-echo/* Integrator board */${config_file}
-echo -n#define CONFIG_ARCH_INTEGRATOR ${config_file}
-echo1 /* Integrator/AP */ ${config_file}
+cat ${config_file} _EOF
+/* Integrator configuration implied by Makefile target */
+#define CONFIG_INTEGRATOR /* Integrator board */
+#define CONFIG_ARCH_INTEGRATOR 1 /* Integrator/AP */
+_EOF
+
# -
# Set the core module defines according to Core Module
# -
@@ -50,37 +50,37 @@ else
ap720t_config)
cpu=arm720t
- echo -n #define CONFIG_CM720T ${config_file}
- echo 1 /* CPU core is ARM720T */ ${config_file}
+ echo #define CONFIG_CM720T 1 /* CPU core is ARM720T */ \
+${config_file}
variant=Core module CM720T
;;
ap922_XA10_config)
cpu=arm_intcm
variant=unported core module CM922T_XA10
- echo -n #define CONFIG_CM922T_XA10 ${config_file}
- echo 1 /* CPU core is ARM922T_XA10 */ ${config_file}
+ echo #define CONFIG_CM922T_XA10 1 /* CPU core is ARM922T_XA10 */ \
+${config_file}
;;
ap920t_config)
cpu=arm920t
variant=Core module CM920T
- echo -n #define CONFIG_CM920T ${config_file}
- echo 1 /* CPU core is ARM920T */ ${config_file}
+ echo #define CONFIG_CM920T 1 /* CPU core is ARM920T */ \
+${config_file}
;;
ap926ejs_config)
cpu=arm926ejs
variant=Core module CM926EJ-S
- echo -n #define CONFIG_CM926EJ_S ${config_file}
- echo 1 /* CPU core is ARM926EJ-S */${config_file}
+ echo #define CONFIG_CM926EJ_S 1 /* CPU core is ARM926EJ-S */ \
+${config_file}
;;
ap946es_config)
cpu=arm946es
variant=Core module CM946E-S
- echo -n #define CONFIG_CM946E_S${config_file}
- echo 1 /* CPU core is ARM946E-S */ ${config_file}
+ echo #define CONFIG_CM946E_S 1 /* CPU core is ARM946E-S */ \
+${config_file}
;;
*)
@@ -94,33 +94,26 @@ fi
case $cpu in
arm_intcm)
- echo /* Core module undefined/not ported */${config_file}
- echo #define CONFIG_ARM_INTCM 1${config_file}
- echo -n #undef CONFIG_CM_MULTIPLE_SSRAM${config_file}
- echo -n/* CM may not have ${config_file}
- echomultiple SSRAM mapping */ ${config_file}
- echo -n #undef CONFIG_CM_SPD_DETECT${config_file}
- echo -n /* CM may not support SPD ${config_file}
- echoquery */ ${config_file}
- echo -n #undef CONFIG_CM_REMAP ${config_file}
- echo -n /* CM may not support ${config_file}
- echoremapping */ ${config_file}
- echo -n #undef CONFIG_CM_INIT ${config_file}
- echo -n /* CM may not have${config_file}
- echoinitialization reg */ ${config_file}
- echo -n #undef CONFIG_CM_TCRAM ${config_file}
- echo /* CM may not have TCRAM */ ${config_file}
- echo -n /* May not be processor ${config_file}
- echowithout cache support */ ${config_file}
- echo#define CONFIG_SYS_NO_ICACHE 1 ${config_file}
-
Re: [U-Boot] [RFC] Driver model
Le 24/09/2010 20:59, Wolfgang Denk a écrit : Of course. We will always allow customized, board specific configurations that can be kept as small as possible if they don't need this feature. Good. But if you look at current trends with SoC and board manufacturers, it would be really great if we could have some image that covers more than just one or two boards. This is understandable too; I just wanted to make sure there was a choice. Thanks for the clarification! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arch/arm/include/asm/sizes.h: cleanups
Merge several sizes.h in asm/arch subdirectories into a single asm/sizes.h file. Fixup usage of asm/arch/sizes.h in some files to use the merged file. Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com --- These changes where submitted in 2008 but never applied. See http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/44229 It is not necessary to have several copies of files with nearly the same content. arch/arm/include/asm/arch-arm925t/sizes.h | 50 arch/arm/include/asm/arch-arm926ejs/sizes.h | 51 arch/arm/include/asm/arch-omap/sizes.h| 52 - arch/arm/include/asm/arch-omap24xx/omap2420.h |2 +- arch/arm/include/asm/arch-omap24xx/sizes.h| 49 --- arch/arm/include/asm/sizes.h |5 +- include/configs/h2_p2_dbg_board.h |2 +- include/configs/omap1510.h|2 +- include/configs/omap730.h |2 +- 9 files changed, 6 insertions(+), 209 deletions(-) delete mode 100644 arch/arm/include/asm/arch-arm925t/sizes.h delete mode 100644 arch/arm/include/asm/arch-arm926ejs/sizes.h delete mode 100644 arch/arm/include/asm/arch-omap/sizes.h delete mode 100644 arch/arm/include/asm/arch-omap24xx/sizes.h diff --git a/arch/arm/include/asm/arch-arm925t/sizes.h b/arch/arm/include/asm/arch-arm925t/sizes.h deleted file mode 100644 index 7319bd9..000 --- a/arch/arm/include/asm/arch-arm925t/sizes.h +++ /dev/null @@ -1,50 +0,0 @@ -/* - * 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 - */ -/* DO NOT EDIT!! - this file automatically generated - *from .s file by awk -f s2h.awk - */ -/* Size defintions - * Copyright (C) ARM Limited 1998. All rights reserved. - */ - -#ifndef __sizes_h -#define __sizes_h 1 - -/* handy sizes */ -#define SZ_1K 0x0400 -#define SZ_4K 0x1000 -#define SZ_8K 0x2000 -#define SZ_16K 0x4000 -#define SZ_64K 0x0001 -#define SZ_128K0x0002 -#define SZ_256K0x0004 -#define SZ_512K0x0008 - -#define SZ_1M 0x0010 -#define SZ_2M 0x0020 -#define SZ_4M 0x0040 -#define SZ_8M 0x0080 -#define SZ_16M 0x0100 -#define SZ_32M 0x0200 -#define SZ_64M 0x0400 -#define SZ_128M0x0800 -#define SZ_256M0x1000 -#define SZ_512M0x2000 - -#define SZ_1G 0x4000 -#define SZ_2G 0x8000 - -#endif /* __sizes_h */ diff --git a/arch/arm/include/asm/arch-arm926ejs/sizes.h b/arch/arm/include/asm/arch-arm926ejs/sizes.h deleted file mode 100644 index ef0b99b..000 --- a/arch/arm/include/asm/arch-arm926ejs/sizes.h +++ /dev/null @@ -1,51 +0,0 @@ -/* - * 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, MA0 2111-1307 - * USA - */ -/* DO NOT EDIT!! - this file automatically generated - *from .s file by awk -f s2h.awk - */ -/* Size defintions - * Copyright (C) ARM Limited 1998. All rights reserved. - */ - -#ifndef __sizes_h -#define __sizes_h 1 - -/* handy sizes */ -#define SZ_1K 0x0400 -#define SZ_4K
Re: [U-Boot] [PATCH] ppc44x: config GPIOs for USB on canyonlands board
On Fri, Sep 24, 2010 at 10:43 AM, Wolfgang Denk w...@denx.de wrote: Dear Feng Kan, In message aanlktin-rbm0ndqzmzkcyp45-m9s+3h_fb7dwzzeh...@mail.gmail.com you wrote: FKAN: Dear Wolfgang, is the symmetry needed here? If a user plan to use the usb, he will trigger the function. Otherwise, on a stop what value would we put it back to. Design rules say: Shall initialize only such peripherals used by U-Boot itself, and must deinitialize them after use. Note that especially the deinitialization is mandatory! FKAN: I agree, thanks. However, this conflict with one of your other rule Don't make U-Boot slow. If another software entity wish to use the GPIO after, the code would deinit to gpio state and the other init would init gpio to the same state. Essentially doubling the code doing the same thing. Isn't this GPI reset to the initial values part of the deinitialization sequence? FKAN: In this case, gpio is double muxed in functionality. Do we need to remember state if the gpio is tri-muxed? 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 software required `Windows 95 or better', so I installed Linux. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 0/2] Add support for new SoC APM821XX
From: Tirumala Marri tma...@apm.com APM821XX is Applied Micro Circuits Corporations naming convention for new line of SoCs. V3: * Missing TLB entry for CONFIG_SYS_BOOT_BASE_ADDR. * Move CONFIG_SYS_EBC_PB0AP etc to EBC area in the config file. * remove unused CONFIG_RTL8211CL_PHY. * Replace hard coded valued for CONFIG_SYS_EBC_CFG with macro definitions. * Change APM82XXX to APM821XX * Modify the way cpu id is printed. * Correct inadvertent change. * Sort define list. * Remove comment for get_sys_info(). * Define a symbolic constat CONFIG_SYS_OCM_SIZE. * Create apm821xx.h instead of using ppc440.h * board.cfg add the entry in sorted. * use puts() if there is no formating needed. * Correct multiline comment. V4: * Rebasing with Stefan Roese tree Tirumala Marri (2): APM821xx: Add CPU support APM821xx: Add bluestone board support MAINTAINERS |4 + MAKEALL |1 + arch/powerpc/cpu/ppc4xx/cpu.c | 19 arch/powerpc/cpu/ppc4xx/cpu_init.c |5 +- arch/powerpc/cpu/ppc4xx/speed.c | 75 +- arch/powerpc/cpu/ppc4xx/start.S | 11 ++- arch/powerpc/include/asm/apm821xx.h | 69 arch/powerpc/include/asm/ppc4xx-ebc.h |3 +- arch/powerpc/include/asm/ppc4xx-isram.h | 14 ++- arch/powerpc/include/asm/ppc4xx-sdram.h | 12 +- arch/powerpc/include/asm/ppc4xx-uic.h |5 +- arch/powerpc/include/asm/ppc4xx.h |4 + arch/powerpc/include/asm/processor.h|1 + board/amcc/bluestone/Makefile | 52 + board/amcc/bluestone/bluestone.c| 111 +++ board/amcc/bluestone/config.mk | 40 +++ board/amcc/bluestone/init.S | 59 ++ boards.cfg |1 + include/configs/bluestone.h | 176 +++ 19 files changed, 643 insertions(+), 19 deletions(-) create mode 100644 arch/powerpc/include/asm/apm821xx.h create mode 100644 board/amcc/bluestone/Makefile create mode 100644 board/amcc/bluestone/bluestone.c create mode 100644 board/amcc/bluestone/config.mk create mode 100644 board/amcc/bluestone/init.S create mode 100644 include/configs/bluestone.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 1/2] APM821xx: Add CPU support
From: Tirumala Marri tma...@apm.com
APM821XX is a new line of SoCs which are derivatives of
PPC44X family of processors. This patch adds support of CPU, cache,
tlb, 32k ocm, bootstraps, PLB and AHB bus.
Signed-off-by: Tirumala R Marri tma...@apm.com
---
V3:
* Change APM82XXX to APM821XX
* Modify the way cpu id is printed.
* Correct inadvertent change.
* Sort define list.
* Remove comment for get_sys_info().
* Define a symbolic constat ISRAM1_OCM_SIZE.
* Create apm821xx.h instead of using ppc440.h
* Correct multiline comment.
V4:
* Rebase with Stefan Roese tree
---
arch/powerpc/cpu/ppc4xx/cpu.c | 19
arch/powerpc/cpu/ppc4xx/cpu_init.c |5 +-
arch/powerpc/cpu/ppc4xx/speed.c | 75 ++-
arch/powerpc/cpu/ppc4xx/start.S | 11 +++--
arch/powerpc/include/asm/apm821xx.h | 69
arch/powerpc/include/asm/ppc4xx-ebc.h |3 +-
arch/powerpc/include/asm/ppc4xx-isram.h | 14 +-
arch/powerpc/include/asm/ppc4xx-sdram.h | 12 +++---
arch/powerpc/include/asm/ppc4xx-uic.h |5 +-
arch/powerpc/include/asm/ppc4xx.h |4 ++
arch/powerpc/include/asm/processor.h|1 +
11 files changed, 199 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/cpu/ppc4xx/cpu.c b/arch/powerpc/cpu/ppc4xx/cpu.c
index 6009b0c..f3bdf18 100644
--- a/arch/powerpc/cpu/ppc4xx/cpu.c
+++ b/arch/powerpc/cpu/ppc4xx/cpu.c
@@ -250,6 +250,20 @@ static char *bootstrap_str[] = {
};
static char bootstrap_char[] = { 'A', 'B', 'C', 'D', 'E', 'G', 'F', 'H' };
#endif
+#if defined(CONFIG_APM821XX)
+#define SDR0_PINSTP_SHIFT 29
+static char *bootstrap_str[] = {
+ RESERVED,
+ RESERVED,
+ RESERVED,
+ NAND (8 bits),
+ NOR (8 bits),
+ NOR (8 bits) w/PLL Bypassed,
+ I2C (Addr 0x54),
+ I2C (Addr 0x52),
+};
+static char bootstrap_char[] = { 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H' };
+#endif
#if defined(SDR0_PINSTP_SHIFT)
static int bootstrap_option(void)
@@ -590,6 +604,11 @@ int checkcpu (void)
strcpy(addstr, No Security support);
break;
+ case PVR_APM821XX_RA:
+ puts(APM821XX Rev. A);
+ strcpy(addstr, Security support);
+ break;
+
case PVR_VIRTEX5:
puts(440x5 VIRTEX5);
break;
diff --git a/arch/powerpc/cpu/ppc4xx/cpu_init.c
b/arch/powerpc/cpu/ppc4xx/cpu_init.c
index d54b30e..125241b 100644
--- a/arch/powerpc/cpu/ppc4xx/cpu_init.c
+++ b/arch/powerpc/cpu/ppc4xx/cpu_init.c
@@ -237,7 +237,8 @@ cpu_init_f (void)
reconfigure_pll(CONFIG_SYS_PLL_RECONFIG);
-#if (defined(CONFIG_405EP) || defined (CONFIG_405EX))
!defined(CONFIG_SYS_4xx_GPIO_TABLE)
+#if !defined(CONFIG_APM821XX) (defined(CONFIG_405EP) ||\
+ defined (CONFIG_405EX)) !defined(CONFIG_SYS_4xx_GPIO_TABLE)
/*
* GPIO0 setup (select GPIO or alternate function)
*/
@@ -393,7 +394,7 @@ cpu_init_f (void)
#if defined(CONFIG_405EX) || \
defined(CONFIG_440SP) || defined(CONFIG_440SPE) || \
defined(CONFIG_460EX) || defined(CONFIG_460GT) || \
-defined(CONFIG_460SX)
+defined(CONFIG_460SX) || defined(CONFIG_APM821XX)
/*
* Set PLB4 arbiter (Segment 0 and 1) to 4 deep pipeline read
*/
diff --git a/arch/powerpc/cpu/ppc4xx/speed.c b/arch/powerpc/cpu/ppc4xx/speed.c
index abd4e91..09d6671 100644
--- a/arch/powerpc/cpu/ppc4xx/speed.c
+++ b/arch/powerpc/cpu/ppc4xx/speed.c
@@ -189,7 +189,7 @@ ulong get_PCI_freq (void)
#elif defined(CONFIG_440)
#if defined(CONFIG_460EX) || defined(CONFIG_460GT) || \
-defined(CONFIG_460SX)
+defined(CONFIG_460SX) || defined(CONFIG_APM821XX)
static u8 pll_fwdv_multi_bits[] = {
/* values for: 1 - 16 */
0x00, 0x01, 0x0f, 0x04, 0x09, 0x0a, 0x0d, 0x0e, 0x03, 0x0c,
@@ -250,6 +250,78 @@ u32 get_cpr0_fbdv(unsigned long cpr_reg_fbdv)
return 0;
}
+#if defined(CONFIG_APM821XX)
+
+void get_sys_info(sys_info_t *sysInfo)
+{
+ unsigned long plld;
+ unsigned long temp;
+ unsigned long mul;
+ unsigned long cpudv;
+ unsigned long plb2dv;
+ unsigned long ddr2dv;
+
+ /* Calculate Forward divisor A and Feeback divisor */
+ mfcpr(CPR0_PLLD, plld);
+
+ temp = CPR0_PLLD_FWDVA(plld);
+ sysInfo-pllFwdDivA = get_cpr0_fwdv(temp);
+
+ temp = CPR0_PLLD_FDV(plld);
+ sysInfo-pllFbkDiv = get_cpr0_fbdv(temp);
+
+ /* Calculate OPB clock divisor */
+ mfcpr(CPR0_OPBD, temp);
+ temp = CPR0_OPBD_OPBDV(temp);
+ sysInfo-pllOpbDiv = temp ? temp : 4;
+
+ /* Calculate Peripheral clock divisor */
+ mfcpr(CPR0_PERD, temp);
+ temp = CPR0_PERD_PERDV(temp);
+ sysInfo-pllExtBusDiv = temp ? temp : 4;
+
+ /* Calculate CPU clock divisor */
+ mfcpr(CPR0_CPUD, temp);
+ temp = CPR0_CPUD_CPUDV(temp);
+ cpudv = temp ? temp : 8;
+
+ /*
[U-Boot] [PATCH v4 2/2] APM821xx: Add bluestone board support
From: Tirumala Marri tma...@apm.com
Add support code for bluestone board wth APM821XX processor based.
This patch includes early board init, misc init, configure EBC,
initializes UIC, MAKEALL, board.cfg and MAINTAINERS file.
Signed-off-by: Tirumala R Marri tma...@apm.com
---
V3:
* Missing TLB entry for CONFIG_SYS_BOOT_BASE_ADDR.
* Move CONFIG_SYS_EBC_PB0AP etc to EBC area in the config file.
* remove unused CONFIG_RTL8211CL_PHY.
* Replace hard coded valued for CONFIG_SYS_EBC_CFG with
macro definitions.
* Change APM82XXX to APM821XX
* board.cfg add the entry in sorted.
* use puts() if there is no formating needed.
V4:
* Rebasing with Stefan Roese tree
---
MAINTAINERS |4 +
MAKEALL |1 +
board/amcc/bluestone/Makefile| 52 +++
board/amcc/bluestone/bluestone.c | 111
board/amcc/bluestone/config.mk | 40 +
board/amcc/bluestone/init.S | 59 +
boards.cfg |1 +
include/configs/bluestone.h | 176 ++
8 files changed, 444 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 0c6ce2b..e20055f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -500,6 +500,10 @@ Detlev Zundel d...@denx.de
inka4x0 MPC5200
+Tirumala Marri tma...@apm.com
+
+ bluestone APM821XX
+
-
Unknown / orphaned boards:
diff --git a/MAKEALL b/MAKEALL
index 1b506d6..a2aa7d8 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -143,6 +143,7 @@ LIST_4xx=$(boards_by_cpu ppc4xx)
acadia_nand \
arches \
bamboo_nand \
+ bluestone \
canyonlands \
canyonlands_nand \
CPCI405 \
diff --git a/board/amcc/bluestone/Makefile b/board/amcc/bluestone/Makefile
new file mode 100644
index 000..41751c8
--- /dev/null
+++ b/board/amcc/bluestone/Makefile
@@ -0,0 +1,52 @@
+#
+# Copyright (c) 2010, Applied Micro Circuits Corporation
+# Author: Tirumala R Marri tma...@apm.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 $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).a
+
+COBJS-y:= $(BOARD).o
+SOBJS := init.o
+
+COBJS := $(COBJS-y)
+SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+SOBJS := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(OBJS) $(SOBJS)
+ $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS)
+
+clean:
+ rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+ rm -f $(LIB) core *.bak $(obj).depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/amcc/bluestone/bluestone.c b/board/amcc/bluestone/bluestone.c
new file mode 100644
index 000..fe8929c
--- /dev/null
+++ b/board/amcc/bluestone/bluestone.c
@@ -0,0 +1,111 @@
+/*
+ * Bluestone board support
+ *
+ * Copyright (c) 2010, Applied Micro Circuits Corporation
+ * Author: Tirumala R Marri tma...@apm.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+#include asm/apm821xx.h
+#include libfdt.h
+#include fdt_support.h
+#include i2c.h
+#include asm/processor.h
+#include asm/io.h
+#include asm/mmu.h
+#include asm/ppc4xx-gpio.h
+
+int board_early_init_f(void)
+{
+ /*
+* Setup the interrupt controller
Re: [U-Boot] [PATCH V3] mvsata_ide: adjust port init sequence
Le 16/09/2010 13:13, Prafulla Wadaskar a écrit :
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de] On Behalf Of Albert Aribaud
Sent: Wednesday, September 08, 2010 11:01 PM
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH V3] mvsata_ide: adjust port init sequence
mvsata_ide_initialize_port(): adjust init sequence (SStatus
should be checked only after all writes to SControl) and
return success/failure to ide_preinit().
Also, as some tests showed init durations in the hundreds
of us, raise the time-out to 01 ms to be on the safe side.
Signed-off-by: Albert Aribaudalbert.arib...@free.fr
---
PATCH HISTORY
V1 Initial patch.
V2 Fixed wrong placement of comment.
Fixed wrong description (was 01 ms, should have been 10).
Added Signed-off-by.
V3 Replaced return status values with symbolic names.
Made error status values negative.
Renamed 'tout' to 'timeleft' for clarity.
Replaced ternary '?:' operator with '!' and if.
Patch was run through checkscript.pl with 0 errors and warnings.
drivers/block/mvsata_ide.c | 42
+-
1 files changed, 33 insertions(+), 9 deletions(-)
diff --git a/drivers/block/mvsata_ide.c b/drivers/block/mvsata_ide.c
index 077b278..3d6993a 100644
--- a/drivers/block/mvsata_ide.c
+++ b/drivers/block/mvsata_ide.c
@@ -91,29 +91,48 @@ struct mvsata_port_registers {
#define MVSATA_SSTATUS_DET_DEVCOMM 0x0003
/*
+ * Status codes to return to client callers. Currently,
callers ignore
+ * exact value and only care for zero or nonzero, so no need
to make this
+ * public, it is only #define'd for clarity.
+ * If/when standard negative codes are implemented in
U-boot, then these
+ * #defines should be moved to, or replaced by ones from,
the common list
+ * of status codes.
+ */
+
+#define MVSATA_STATUS_OK0
+#define MVSATA_STATUS_TIMEOUT -1
+
+/*
* Initialize one MVSATAHC port: set SControl's IPM to
always active
* and DET to reset, then wait for SStatus's DET to become
device and
* comm ok (or time out after 50 us if no device), then set
SControl's
* DET back to no action.
*/
-static void mvsata_ide_initialize_port(struct
mvsata_port_registers *port)
+static int mvsata_ide_initialize_port(struct
mvsata_port_registers *port)
{
u32 control;
u32 status;
-u32 tout = 50; /* wait at most 50 us for SATA reset to
complete */
+u32 timeleft = 1; /* wait at most 10 ms for SATA
reset to complete */
+/* Set control IPM to 3 (no low power) and DET to 1
(initialize) */
control = readl(port-scontrol);
control = (control ~MVSATA_SCONTROL_MASK) | MVSATA_PORT_INIT;
writel(control,port-scontrol);
-while (--tout) {
+/* Toggle control DET back to 0 (normal operation) */
+control = (control ~MVSATA_SCONTROL_MASK) | MVSATA_PORT_USE;
+writel(control,port-scontrol);
+/* wait for status DET to become 3 (device and
communication OK) */
+while (--timeleft) {
status = readl(port-sstatus)
MVSATA_SSTATUS_DET_MASK;
if (status == MVSATA_SSTATUS_DET_DEVCOMM)
break;
udelay(1);
}
-control = (control ~MVSATA_SCONTROL_MASK) | MVSATA_PORT_USE;
-writel(control,port-scontrol);
+/* return success or time-out error depending on time left */
+if (!timeleft)
+return MVSATA_STATUS_TIMEOUT;
+return MVSATA_STATUS_OK;
}
/*
@@ -123,18 +142,23 @@ static void
mvsata_ide_initialize_port(struct mvsata_port_registers *port)
int ide_preinit(void)
{
+int status;
/* Enable ATA port 0 (could be SATA port 0 or 1) if declared */
#if defined(CONFIG_SYS_ATA_IDE0_OFFSET)
-mvsata_ide_initialize_port(
+status = mvsata_ide_initialize_port(
(struct mvsata_port_registers *)
(CONFIG_SYS_ATA_BASE_ADDR +
CONFIG_SYS_ATA_IDE0_OFFSET));
+if (status)
+return status;
#endif
/* Enable ATA port 1 (could be SATA port 0 or 1) if declared */
#if defined(CONFIG_SYS_ATA_IDE1_OFFSET)
-mvsata_ide_initialize_port(
+status = mvsata_ide_initialize_port(
(struct mvsata_port_registers *)
(CONFIG_SYS_ATA_BASE_ADDR +
CONFIG_SYS_ATA_IDE1_OFFSET));
+if (status)
+return status;
#endif
-/* return 0 as we always succeed */
-return 0;
+/* return success if all ports initializations succeeded */
+return MVSATA_STATUS_OK;
}
Applied to u-boot-marvell.git master branch
Regards..
Prafulla . .
Prafulla,
Is it possible to ask for a pull of the marvell tree in order to get
this bugfix pulled in v2010.09?
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
