Re: [U-Boot] ARM relocation, question to Heiko
Hello Albert, Albert ARIBAUD wrote: Le 02/10/2010 22:39, Reinhard Meyer a écrit : And as an idea, if position independent code is used, only pointers in initialized data need adjustment. Cannot the linker emit a table of addresses that need fixing? IIU Bill C, yes the linker can emit the information and the startup code could use this information instead of relying on hand-provided info; the linker file probably needs to be modified in order to provide such info. I intend to look into this, but feel free to do too. I thought therefore is the GOT. But if there is another way, to get rid of this hand fixing, it would be a good thing. bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM relocation, question to Heiko
Hello Wolfgang, Wolfgang Denk wrote: Dear Reinhard Meyer, In message 4ca79896.2010...@emk-elektronik.de you wrote: I agree here. _If_ relocation, it should work without hand-adding fixup stuff to all functions using initialized data with pointers. Even Wolfgang forgot to fixup his 2nd level command table in cmd_nvedit.c ;) I didn't forget it - at least not in the sensse that I think this is something that needs to be done. This works fine on PPC with relocation, and we should make it work the same on other arches. If we find a way for this on ARM, Ack! And, for space concerns in flash, relocation should always be an option on a board by board basis... NAK. And as an idea, if position independent code is used, only pointers in initialized data need adjustment. Cannot the linker emit a table of addresses that need fixing? It does. That's the GOT. So I thought too, and I made a fixup in relocate_code() for the GOT entries. But this don;t work with for example the commandtables. bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM relocation, question to Heiko
Hello Albert, Albert ARIBAUD wrote: Le 03/10/2010 20:03, Wolfgang Denk a écrit : Dear Reinhard Meyer, In message4ca6e8e5.2090...@emk-elektronik.de you wrote: And yes, this means the content arrays of pointers such as init_sequence is not relocated. Been there, done that, can give you one of the tee-shirts I got :) It should work. Eventually we need to find out which sort of tweaking of compiler and/or linker options is needed on ARM. While looking for enhancements to Heiko's arm relocation patches, I have gone through all relocation related compiler and linker options, and then some. -fPIC / -fPIE will not generate GOT fixups for data containing pointers, and I have found no additional option that will. Yep, that was also my problem ... OTOH, -pie will generate this kind of fixup (and all others needed) in the form of .rel.dyn relocations, as Bill describes. Ah! Have to look in this, maybe thats the way we have to go ... bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] denx/master is not building for OMAP3 platforms except Beagle
Hello Hiremath, Hiremath, Vaibhav wrote: Hi All, I think the current denx/matser is broken and is not building up for OMAP3 platforms except Beagle board. but they should compile if you define CONFIG_SYS_ARM_WITHOUT_RELOC or compile with: CONFIG_SYS_ARM_WITHOUT_RELOC=1 ./MAKEALL board But be aware, this option wil be removed ... bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM relocation, question to Heiko
Hi Wolfgang, snip Well, please keep in mind that all this code is working find on PowerPC, which has been using relocation right from the beginning. It is my understanding that we don't suffer from this issue any more on PPC - Peter Tyser posted relocation fixup patches for PPC about a year ago or so. I have to admit that I cannot remeber the final result of this discussion (there were tool chain dependencies?), but IIRC this has been solved for PPC. We should do the same for AMR now. Peter, could you please fill in the details of that old story? I haven't been following the ARM relocation thread very closely, but a summary of the PPC relocation is: - Prior to commit 858290178f222d998b6425d85cf06822467918f3 PPC supported basic relocation, but didn't relocate static pointers, eg pointers in a structure, such as the strings in the cmd_pca953x[] table. So we had to use the hokey struct-field += gd-reloc_off fixups that we still have for some arches. - Adding -mrelocatable to the gcc's flags would add additional relocation info into the .fixup section that allowed us to properly fixup static pointers and get rid of the += gd-reloc_off fixups. The additional fixup code was relatively small, in the 1-2% ballpark I think. - Unfortunately -mrelocatable is PPC specific. I remember dabbling with other, more general relocation flags like -fPIC, pie, etc, but went with -mrelocatable mainly because it was a smaller, easier change. We could share the already-used relocation fixup code in many PPC arch's start.S, so it wasn't too hard to get working unlike the other relocation schemes. - Graeme Russ was working on relocation for x86 near the same time. He started this thread which may provide useful info: http://www.mail-archive.com/u-boot@lists.denx.de/msg23347.html He discusses the impact of other compile flags, most of which were generic so could apply to this ARM discussion hopefully. However, I think we will loose the possibility to add link once, burn and run anywhere feature I impl. once(but it was at the time deemed to intrusive) if we skip -fPIC and go for the linker -pie relocation. I would suggest to leave ppc as is for the time being and see how -pie works out on the other archs. Jocke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] AT91 clock and timer cleanups (was: ARM relocation, probably trivial mistake - back to original problem)
I wrote: Dear Wolfgang Denk, In message 4ca5d26d.2090...@emk-elektronik.de you wrote: If this is really for all AT91 SoCs, then please feel free to introduce a common define (CONFIG_SYS_AT91 ?) and use that. Eventually you can clean up some other such #if's on the way. That would have to be set either in each board.h file or in each at91*.h file. Isn't there a central place? Probably there is a header file common to all AT91 SoCs when then can use a single such construct to #define the new variable so you don;t have to touch all the many board config files. The only files I can see included in each instance are those of the kind hardware.h, memory_map.h and similiar. The define does not really belong in any of those. I tried arch-at91/hardware.h. Apparently it gets included after global_data.h. Same would be true for all files included inside hardware.h. Without reordering the includes (which I don't want to do) the remaining place would be each board's config file. Since all AT91 boards are broken anyway right now; adding it could be left to the respective maintainers :) If no better place is found, we can even add this to common.h (we do similar things there already for CONFIG_MPC866_FAMILY, CONFIG_MPC86x, CONFIG_MPC8272_FAMILY, CONFIG_TQM8xxM, CONFIG_TQM8xxL, etc. Into this chain? #if defined(CONFIG_MPC852)|| defined(CONFIG_MPC852T) || \ defined(CONFIG_MPC859)|| defined(CONFIG_MPC859T) || \ defined(CONFIG_MPC859DSL) || \ defined(CONFIG_MPC866)|| defined(CONFIG_MPC866T) || \ defined(CONFIG_MPC866P) # define CONFIG_MPC866_FAMILY 1 #elif defined(CONFIG_MPC870) \ Ugly, but possible :) Just hoping that everytime a new AT91 comes out, it will not be forgotten to be added there ;) I have added required variables to global_data.h, it looks like this now: ... #ifdef CONFIG_FSL_ESDHC unsigned long sdhc_clk; #endif #if defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9XE) /* static data needed by at91's clock.c */ unsigned long cpu_clk_rate_hz; unsigned long main_clk_rate_hz; unsigned long mck_rate_hz; unsigned long plla_rate_hz; unsigned long pllb_rate_hz; unsigned long at91_pllb_usb_init; /* static data needed by at91's timer.c */ unsigned long timer_rate_hz; unsigned long tbl; unsigned long tbu; unsigned long long timer_reset_value; #endif #if !defined(CONFIG_SYS_ARM_WITHOUT_RELOC) unsigned long relocaddr; /* Start address of U-Boot in RAM */ ... At the same time I cleaned up timer.c to really operate using 64 bit values like on powerpc (hence tbu, tbl) The Qs that remain now are: 1. currently I see about 8 CONFIG_AT91SAMxxx defines required (not only 2 like above). The method is still undecided how to handle this. Add CONFIG_AT91SAM9_FAMILY to common.h? Or put all 8 defined() into global_data.h (would give 4 lines there)? 2. How many patches would this change need, and who would collect them? It affects at worst 3 areas: common.h, arm/global_data.h, at91/clock.c+timer.c --- Or is it ok to put that into one patch and add it later to my atmel tree? Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM relocation, question to Heiko
Le 04/10/2010 09:36, Joakim Tjernlund a écrit : However, I think we will loose the possibility to add link once, burn and run anywhere feature I impl. once(but it was at the time deemed to intrusive) if we skip -fPIC and go for the linker -pie relocation. On ARM at least, I don't think so. From what I see, the -pie ld option without the -fPIC/-fPIE compiler option alone builds a .rel.syn table that contains all necessary fixes to mve the code anywhere. hmm, maybe my memory fails me but doesn't these relocs change the code to relocate accesses? While in flash you can't do that. Perhaps this is fixable too with the LINK_OFF method I impl. but memory fails me as it was quite some time ago. Jocke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 2/2] MTD/SPI: add support for Ramtron FRAMs
Dear Mike Frysinger, All:)
On Tuesday, September 14, 2010 10:50:09 Reinhard Meyer wrote:
JEDEC types
non JEDEC types
this changelog is useless ... either make it say something, or just leave it
empty
+static int ramtron_common(struct spi_flash *flash,
+u32 offset, size_t len, void *buf, u8 command)
+{
+
+if (sn-params-addr_len == 3 sn-params-merge_cmd == 0) {
+cmd[0] = command;
+cmd[1] = offset 16;
+cmd[2] = offset 8;
+cmd[3] = offset;
+cmd_len = 4;
+}
+else if (sn-params-addr_len == 2 sn-params-merge_cmd == 0) {
+cmd[0] = command;
+cmd[1] = offset 8;
+cmd[2] = offset;
+cmd_len = 3;
+}
+else {
i thought i had mentioned this before, but those else statements need cuddling
+/* claim the bus */
+ret = spi_claim_bus(flash-spi);
+if (ret) {
+debug(SF: Unable to claim SPI bus\n);
+return ret;
+}
i'm thinking we should push the bus claim from the read/write funcs into the
common spi flash layer ... not that this is specific to your flash. we can
do
this after yours gets merged.
+sn = malloc(sizeof(struct ramtron_spi_fram));
sizeof(*sn)
otherwise, this looks good
-mike
I am unsure whether currently I should put further effort into this, because
this
won't work on architectures with incomplete relocation. The pointers in the
probe table would need relocation fixups otherwise.
Reinhard
attachment: reinhard_meyer.vcf___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] AT91 clock and timer cleanups (was: ARM relocation, probably trivial mistake - back to original problem)
Dear Reinhard Meyer, In message 4ca985dc.4000...@emk-elektronik.de you wrote: The Qs that remain now are: 1. currently I see about 8 CONFIG_AT91SAMxxx defines required (not only 2 like above). The method is still undecided how to handle this. Add CONFIG_AT91SAM9_FAMILY to common.h? Or put all 8 defined() into global_data.h (would give 4 lines there)? You wille ventually need this in other locations as well, so please add a single 4-line-#if to some appropriate header file; if there is no better file for AT91 I will accept this for common.h 2. How many patches would this change need, and who would collect them? It affects at worst 3 areas: common.h, arm/global_data.h, at91/clock.c+timer.c --- Or is it ok to put that into one patch and add it later to my atmel tree? I see two patches: Patch 1 will change the #if and introduce CONFIG_AT91SAM9_FAMILY instead. Patch 2 will fix at91/clock.c+timer.c 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 They say a little knowledge is a dangerous thing, but it is not one half so bad as a lot of ignorance. - Terry Pratchett, _Equal Rites_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM relocation, question to Heiko
Le 04/10/2010 08:08, Heiko Schocher a écrit : Hello Albert, Albert ARIBAUD wrote: Le 03/10/2010 20:03, Wolfgang Denk a écrit : Dear Reinhard Meyer, In message4ca6e8e5.2090...@emk-elektronik.de you wrote: And yes, this means the content arrays of pointers such as init_sequence is not relocated. Been there, done that, can give you one of the tee-shirts I got :) It should work. Eventually we need to find out which sort of tweaking of compiler and/or linker options is needed on ARM. While looking for enhancements to Heiko's arm relocation patches, I have gone through all relocation related compiler and linker options, and then some. -fPIC / -fPIE will not generate GOT fixups for data containing pointers, and I have found no additional option that will. Yep, that was also my problem ... OTOH, -pie will generate this kind of fixup (and all others needed) in the form of .rel.dyn relocations, as Bill describes. Ah! Have to look in this, maybe thats the way we have to go ... Right now I can build (not run, mind you) u-boot for edminiv2 without -fPIC/-fPIE, with -pie and a modified u-boot.lds and start.S. Almost all of the .rel.dyn fixup entries are type 23, that is, relative to the base address, which is good. However, here are about ten at the end which are type 2 -- symbol-relative -- and I am studying them in order to see if they are needed. If type 23 relocations are all that is needed, then a first ARM ELF relocation implementation should 'simply' trade GOT vs .rel.dyn relocation in start.S (I am almost there) and remove fixups in board_init_r. Start.S would apply type 23 fixups only and ignore the rest. Later on we could add a build stage to rewrite the .rel.dyn section as suggested, by filtering out non-type-23 relocs and keeping only the address part of type-23 ones, reducing the .rel.dyn table roughly by half. The good news is, I can spare a couple more hours today on this. I'll let you all know how this fares! bye, Heiko Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] OneNAND: Use generic_onenand_read_page in IPL
Dear Marek Vasut, In message 201010040224.35419.marek.va...@gmail.com you wrote: The data section isn't writable, right ? The data section is (officially) writable only after relocation. This rule has the situation in mind that U-Boot starts runnng from some form of ROM (like NOR flash). If loaded to RAM by some other preloader then the data segmentis axctually writable, but you still have to keep in mind that you have only a minimal stack and no valid BSS. 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 While money can't buy happiness, it certainly lets you choose your own form of misery. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 2/2] MTD/SPI: add support for Ramtron FRAMs
Dear Reinhard Meyer, In message 4ca974b5.8030...@emk-elektronik.de you wrote: I am unsure whether currently I should put further effort into this, because this won't work on architectures with incomplete relocation. The pointers in the probe table would need relocation fixups otherwise. The relocation problems will be fixed one way or another. We must find a solution for this problem, so please go on... 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 all the Chinese simultaneously jumped into the Pacific off a 10 foot platform erected 10 feet off their coast, it would cause a tidal wave that would destroy everything in this country west of Nebraska. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM relocation, question to Heiko
Dear Peter Tyser, In message 1286167382.22760.19.ca...@ptyser-laptop you wrote: Peter, could you please fill in the details of that old story? I haven't been following the ARM relocation thread very closely, but a summary of the PPC relocation is: - Prior to commit 858290178f222d998b6425d85cf06822467918f3 PPC supported basic relocation, but didn't relocate static pointers, eg pointers in a structure, such as the strings in the cmd_pca953x[] table. So we had to use the hokey struct-field += gd-reloc_off fixups that we still have for some arches. - Adding -mrelocatable to the gcc's flags would add additional relocation info into the .fixup section that allowed us to properly fixup static pointers and get rid of the += gd-reloc_off fixups. The additional fixup code was relatively small, in the 1-2% ballpark I think. - Unfortunately -mrelocatable is PPC specific. I remember dabbling with other, more general relocation flags like -fPIC, pie, etc, but went with -mrelocatable mainly because it was a smaller, easier change. We could share the already-used relocation fixup code in many PPC arch's start.S, so it wasn't too hard to get working unlike the other relocation schemes. - Graeme Russ was working on relocation for x86 near the same time. He started this thread which may provide useful info: http://www.mail-archive.com/u-boot@lists.denx.de/msg23347.html He discusses the impact of other compile flags, most of which were generic so could apply to this ARM discussion hopefully. Thanks alot for the summary. 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: How do you spell onomatopoeia? A: The way it sounds. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] packed attribute problem
On 10/4/2010 4:14 PM, Wolfgang Denk wrote: Dear Vipin Kumar, In message 4ca9acaa.2020...@st.com you wrote: This writel results in writing byte by byte on the address pointed to by status_reg. This problem is visible with both gcc version 4.4.1 as well as 4.5.0 I bet this is on some ARM system? Yes, it is on an ARM system (CortexA9). But I still feel that since I am creating a new u32 * status_reg, the code should not use any intelligence and use the pointer only to produce an str instruction in the form str r0, [r1] But it retains the packed property of the structure even with a new u32 ponter typecasted to u32 * u32 * status_reg = (u32 *)xyz-x; A writel to status_reg results in byte by byte writing I agree with you. I always considered such behaviour of the ARM C compiler a bug, and still do. However, people with better knowledge of the ARm architecture than me might be able to explain why the responsible PTB consider this to be a good and necessary feature of th compiler. Hm... Why do these structs have any __attribute__ ((packed)) at all? Even I could not understand that very well Eventually alignment of these structs cannot be guaranteed? In my opinion it can be guaranteed. btw, I am talking about ehci_hcor structure in include/usb/host/ehci.h The only reason I am confused is that a lot many platforms would have faced a similar problem (or is it only me). Please confirm if I should remove the packed attribute and send a patch This also raises one doubt. Since u-boot code now contains structures to access device registers, using packed attribute with these structures can be lethal Regards Vipin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] packed attribute problem
Dear Vipin Kumar,
In message 4ca9a095.9000...@st.com you wrote:
I encountered a problem something like
struct xyz {
int x;
int y;
int z[CONST];
} __attribute__ ((packed));
struct xyz *abc;
u32 * status_reg = (u32 *)abc-z[0];
writel(status, status_reg);
This writel results in writing byte by byte on the address pointed to by
status_reg.
This problem is visible with both gcc version 4.4.1 as well as 4.5.0
I bet this is on some ARM system?
Incidently, the same code works well with 4.2.4
...which surprises me. I thought this has always been an ARM
feature.
The problem is visible in the usb host driver which uses the packed
structures for
accessing device registers.
Hm... Why do these structs have any __attribute__ ((packed)) at all?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
If I had to live my life again, I'd make the same mistakes, only
sooner. -- Tallulah Bankhead
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] AT91 clock and timer cleanups
Dear Reinhard Meyer, In message 4ca995d7.5010...@emk-elektronik.de you wrote: Maybe there is a misunderstanding here. I see three patches 1. introduce CONFIG_AT91SAM9_FAMILY to common.h 2. add an #ifdef CONFIG_AT91SAM9_FAMILY to global_data.h with the required variables 3. change clock and timer. 2+3 combined in one patch? OK No. 1 + 2 belong together; they deal with the same topic and should be applied as a single commit. Ok, so introducing (at this point still) unreferenced variables here is OK? It will not be unreferenced. It will be needed to replace the #if defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9XE) in global_data.h and a ton of similar ocurrences like these: arch/arm/cpu/arm926ejs/at91/clock.c:#if defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9M10G45) arch/arm/cpu/arm926ejs/at91/clock.c:#elif defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9M10G45) arch/arm/cpu/arm926ejs/at91/lowlevel_init.S:#elif defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9261) \ arch/arm/include/asm/arch-at91/at91_matrix.h:#if defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9G20) arch/arm/include/asm/arch-at91/at91_matrix.h:#if defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9G20) arch/arm/include/asm/arch-at91/at91_matrix.h:#elif defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9G20) arch/arm/include/asm/arch-at91/at91_matrix.h:#if defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9263) || \ arch/arm/include/asm/arch-at91/at91_matrix.h:#if defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9263) arch/arm/include/asm/arch-at91/at91_matrix.h:#elif defined(CONFIG_AT91SAM9261) || defined(CONFIG_AT91SAM9260) arch/arm/include/asm/arch-at91/at91_matrix.h:#elif defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9261) || \ arch/arm/include/asm/arch-at91/at91_matrix.h:#if defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9263) arch/arm/include/asm/arch-at91/at91_matrix.h:#if defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9263) || \ arch/arm/include/asm/arch-at91/at91_matrix.h:#if defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91SAM9G45) arch/arm/include/asm/arch-at91/at91_pio.h:#if defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9261) || \ arch/arm/include/asm/arch-at91/at91_pio.h: defined(CONFIG_AT91SAM9G10) || defined(CONFIG_AT91SAM9G20) arch/arm/include/asm/arch-at91/at91_pio.h:#elif defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91SAM9G45) || \ arch/arm/include/asm/arch-at91/at91sam9_matrix.h:#if defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9G20) arch/arm/include/asm/arch-at91/at91sam9_matrix.h:#elif defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9M10G45) arch/arm/include/asm/arch-at91/hardware.h:#elif defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9G20) arch/arm/include/asm/arch-at91/hardware.h:#elif defined(CONFIG_AT91SAM9261) || defined(CONFIG_AT91SAM9G10) arch/arm/include/asm/arch-at91/hardware.h:#elif defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9M10G45) drivers/i2c/soft_i2c.c: defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9261) || \ drivers/net/macb.c:defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91SAM9G20) || \ drivers/net/macb.c: defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9M10G45) drivers/net/macb.c:defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91SAM9G20) || \ drivers/net/macb.c: defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9M10G45) drivers/usb/host/ohci-at91.c:defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91SAM9G20) || \ drivers/usb/host/ohci-at91.c:#elif defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9M10G45) drivers/usb/host/ohci-at91.c:defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91SAM9G20) drivers/usb/host/ohci-at91.c:#elif defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9M10G45) include/i2c.h: defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9261) || \ 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 He'd heard her use that sweet, innocent tone of voice before. It meant that, pretty soon, there was going to be trouble. - Terry Pratchett, _Truckers_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] AT91 clock and timer cleanups
Dear Wolfgang Denk, The Qs that remain now are: 1. currently I see about 8 CONFIG_AT91SAMxxx defines required (not only 2 like above). The method is still undecided how to handle this. Add CONFIG_AT91SAM9_FAMILY to common.h? Or put all 8 defined() into global_data.h (would give 4 lines there)? You wille ventually need this in other locations as well, so please add a single 4-line-#if to some appropriate header file; if there is no better file for AT91 I will accept this for common.h There is no at91 common header file that gets included BEFORE global_data.h, unfortunately. 2. How many patches would this change need, and who would collect them? It affects at worst 3 areas: common.h, arm/global_data.h, at91/clock.c+timer.c --- Or is it ok to put that into one patch and add it later to my atmel tree? I see two patches: Patch 1 will change the #if and introduce CONFIG_AT91SAM9_FAMILY instead. Patch 2 will fix at91/clock.c+timer.c Maybe there is a misunderstanding here. I see three patches 1. introduce CONFIG_AT91SAM9_FAMILY to common.h 2. add an #ifdef CONFIG_AT91SAM9_FAMILY to global_data.h with the required variables 3. change clock and timer. 2+3 combined in one patch? OK And I bet, this must be a patch series ;) Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] packed attribute problem
Dear Reinhard Meyer,
In message 4ca9be94.6000...@emk-elektronik.de you wrote:
Do you imply that the code is really different when the pointer gets
its value by assigning it NOT to a packed entity? Hard to believe.
This is a special feature of GCC on ARM.
- cat foo.c
#define writel(v,a) (*(volatile unsigned int *)(a) = (v))
struct p {
int n;
} __attribute__ ((packed));
struct q {
int n;
};
void foo()
{
struct p *pp = (struct p *)0x1000;
pp-n = 5;
}
void bar()
{
struct q *qq = (struct q *)0x1000;
qq-n = 5;
}
- arm-linux-gcc -O -S foo.c
- cat foo.s
.file foo.c
.text
.align 2
.global foo
.type foo, %function
foo:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
@ lr needed for prologue
mov r3, #4096
mov r2, #0
orr r1, r2, #5
strbr1, [r3, #0]
strbr2, [r3, #1]
strbr2, [r3, #2]
strbr2, [r3, #3]
bx lr
.size foo, .-foo
.align 2
.global bar
.type bar, %function
bar:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
@ lr needed for prologue
mov r2, #5
mov r3, #4096
str r2, [r3, #0]
bx lr
.size bar, .-bar
.ident GCC: (GNU) 4.2.2
Note that this is with GCC 4.2.2. Even GCC 4.0.0 behaves the same, so
this is *not* an issue with very recent tool chains.
2. the culprit on ARM is that unaligned accesses do not raise any signal
but silently IGNORE the unused adress lines which leads to very
undesirable effects that are hard to find.
Well, the compiler turning a single 32 bit access silently into 4 x 8
bit accesses can also lead to very undesirable effects that are hard
to find, especially when accessing hardware that performs
auto-incrementing or any kind of (IRQ or similar) ACK for each
access.
*((int *)0x1) = 5 is the same as *((int *)0x10003) = 5 !
Both write 5 to the word at adress 0x1 !
So, MAYBE, in newer toolchains it was decided to circumvent that problem
by always assuming unaligned pointers unless clearly instructed otherwise.
No, AFAICT this behaviour has not changed in the last few months / years.
Nope. It does not have to do with packed. It would have to do with the fact
that I/O registers cannot be safely written byte-wise.
Yes, it has to do with pcked. See above.
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 a person (a) is poorly, (b) receives treatment intended to make
him better, and (c) gets better, then no power of reasoning known to
medical science can convince him that it may not have been the
treatment that restored his health.
- Sir Peter Medawar, The Art of the Soluble
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc4xx: Change tsr/tcr macros to upper case
Remove uneccessary functions to access the TCR/TSR registers as well.
Signed-off-by: Stefan Roese s...@denx.de
---
arch/powerpc/cpu/ppc4xx/cpu_init.c |8
arch/powerpc/cpu/ppc4xx/interrupts.c |7 ---
arch/powerpc/cpu/ppc4xx/traps.c | 11 +--
3 files changed, 5 insertions(+), 21 deletions(-)
diff --git a/arch/powerpc/cpu/ppc4xx/cpu_init.c
b/arch/powerpc/cpu/ppc4xx/cpu_init.c
index d54b30e..fe97d53 100644
--- a/arch/powerpc/cpu/ppc4xx/cpu_init.c
+++ b/arch/powerpc/cpu/ppc4xx/cpu_init.c
@@ -341,7 +341,7 @@ cpu_init_f (void)
#endif
#if defined(CONFIG_WATCHDOG)
- val = mfspr(tcr);
+ val = mfspr(SPRN_TCR);
#if defined(CONFIG_440EP) || defined(CONFIG_440GR)
val |= 0xb800; /* generate system reset after 1.34 seconds */
#elif defined(CONFIG_440EPX)
@@ -353,11 +353,11 @@ cpu_init_f (void)
val = ~0x3000; /* clear WRC bits */
val |= CONFIG_SYS_4xx_RESET_TYPE 28; /* set board specific WRC type
*/
#endif
- mtspr(tcr, val);
+ mtspr(SPRN_TCR, val);
- val = mfspr(tsr);
+ val = mfspr(SPRN_TSR);
val |= 0x8000; /* enable watchdog timer */
- mtspr(tsr, val);
+ mtspr(SPRN_TSR, val);
reset_4xx_watchdog();
#endif /* CONFIG_WATCHDOG */
diff --git a/arch/powerpc/cpu/ppc4xx/interrupts.c
b/arch/powerpc/cpu/ppc4xx/interrupts.c
index c2d4973..d0bca92 100644
--- a/arch/powerpc/cpu/ppc4xx/interrupts.c
+++ b/arch/powerpc/cpu/ppc4xx/interrupts.c
@@ -67,13 +67,6 @@ static __inline__ void set_pit(unsigned long val)
asm volatile(mtpit %0 : : r (val));
}
-
-static __inline__ void set_tcr(unsigned long val)
-{
- asm volatile(mttcr %0 : : r (val));
-}
-
-
static __inline__ void set_evpr(unsigned long val)
{
asm volatile(mtevpr %0 : : r (val));
diff --git a/arch/powerpc/cpu/ppc4xx/traps.c b/arch/powerpc/cpu/ppc4xx/traps.c
index b5562ad..9baa7a1 100644
--- a/arch/powerpc/cpu/ppc4xx/traps.c
+++ b/arch/powerpc/cpu/ppc4xx/traps.c
@@ -46,15 +46,6 @@ extern unsigned long search_exception_table(unsigned long);
*/
#define END_OF_MEM (gd-bd-bi_memstart + gd-bd-bi_memsize)
-static __inline__ void set_tsr(unsigned long val)
-{
-#if defined(CONFIG_440)
- asm volatile(mtspr 0x150, %0 : : r (val));
-#else
- asm volatile(mttsr %0 : : r (val));
-#endif
-}
-
static __inline__ unsigned long get_esr(void)
{
unsigned long val;
@@ -364,7 +355,7 @@ DecrementerPITException(struct pt_regs *regs)
/*
* Reset PIT interrupt
*/
- set_tsr(0x0800);
+ mtspr(SPRN_TSR, 0x0800);
/*
* Call timer_interrupt routine in interrupts.c
--
1.7.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] denx/master is not building for OMAP3 platforms except Beagle
Hello Rogan, Rogan Dawes wrote: On 2010/10/04 8:00 AM, Heiko Schocher wrote: Hello Hiremath, Hiremath, Vaibhav wrote: Hi All, I think the current denx/matser is broken and is not building up for OMAP3 platforms except Beagle board. but they should compile if you define CONFIG_SYS_ARM_WITHOUT_RELOC or compile with: CONFIG_SYS_ARM_WITHOUT_RELOC=1 ./MAKEALL board But be aware, this option wil be removed ... bye, Heiko For what it is worth, would it be possible to have a more verbose error message that actually provides a reference to what needs to be done, rather than simply failing with an obscure message about DRAM configuration? I ended up bisecting the tree to find the commit, and suitable references for what needs to be done to get a board working again, after searching git log -p for SDRAM got me nowhere. Surely having e.g. #if (not fixed config) #error See http://blah/blah/blah for information about how to fix your board #endif would be more beneficial than an obscure compiler failure that doesn't even reference useful keywords? but that would result in editing *all* config files, which are not coverted. bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] AT91 clock and timer cleanups
Dear Wolfgang Denk, I see the misunderstanding here: It will be needed to replace the #if defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9XE) in global_data.h and a ton of similar ocurrences like these: That does not exist yet (its only in my local tree so far!) arch/arm/cpu/arm926ejs/at91/clock.c:#if defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9M10G45) arch/arm/cpu/arm926ejs/at91/clock.c:#elif defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9M10G45) arch/arm/cpu/arm926ejs/at91/lowlevel_init.S:#elif defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9261) \ arch/arm/include/asm/arch-at91/at91_matrix.h:#if defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9G20) arch/arm/include/asm/arch-at91/at91_matrix.h:#if defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9G20) arch/arm/include/asm/arch-at91/at91_matrix.h:#elif defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9G20) arch/arm/include/asm/arch-at91/at91_matrix.h:#if defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9263) || \ arch/arm/include/asm/arch-at91/at91_matrix.h:#if defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9263) arch/arm/include/asm/arch-at91/at91_matrix.h:#elif defined(CONFIG_AT91SAM9261) || defined(CONFIG_AT91SAM9260) arch/arm/include/asm/arch-at91/at91_matrix.h:#elif defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9261) || \ arch/arm/include/asm/arch-at91/at91_matrix.h:#if defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9263) arch/arm/include/asm/arch-at91/at91_matrix.h:#if defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9263) || \ arch/arm/include/asm/arch-at91/at91_matrix.h:#if defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91SAM9G45) arch/arm/include/asm/arch-at91/at91_pio.h:#if defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9261) || \ arch/arm/include/asm/arch-at91/at91_pio.h: defined(CONFIG_AT91SAM9G10) || defined(CONFIG_AT91SAM9G20) arch/arm/include/asm/arch-at91/at91_pio.h:#elif defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91SAM9G45) || \ arch/arm/include/asm/arch-at91/at91sam9_matrix.h:#if defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9G20) arch/arm/include/asm/arch-at91/at91sam9_matrix.h:#elif defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9M10G45) arch/arm/include/asm/arch-at91/hardware.h:#elif defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9G20) arch/arm/include/asm/arch-at91/hardware.h:#elif defined(CONFIG_AT91SAM9261) || defined(CONFIG_AT91SAM9G10) arch/arm/include/asm/arch-at91/hardware.h:#elif defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9M10G45) drivers/i2c/soft_i2c.c: defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9261) || \ drivers/net/macb.c:defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91SAM9G20) || \ drivers/net/macb.c: defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9M10G45) drivers/net/macb.c:defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91SAM9G20) || \ drivers/net/macb.c: defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9M10G45) drivers/usb/host/ohci-at91.c:defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91SAM9G20) || \ drivers/usb/host/ohci-at91.c:#elif defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9M10G45) drivers/usb/host/ohci-at91.c:defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91SAM9G20) drivers/usb/host/ohci-at91.c:#elif defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9M10G45) include/i2c.h: defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9261) || \ Careful here, the ones here are distinguishing between different family members! See the abundance of #elif's there! Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/19] x86: zboot update
On 04/10/10 20:54, Sergei Shtylyov wrote:
Hello.
On 04-10-2010 7:37, Graeme Russ wrote:
The header of recent Linux Kernels includes the size of the image, and
therefore is not needed to be passed to zboot. Still process the third
parameter (size of image) in the event that an older kernel is being
loaded
Signed-off-by: Graeme Russgraeme.r...@gmail.com
[...]
diff --git a/arch/i386/lib/zimage.c b/arch/i386/lib/zimage.c
index 89fe015..f279b43 100644
--- a/arch/i386/lib/zimage.c
+++ b/arch/i386/lib/zimage.c
[...]
@@ -256,10 +257,17 @@ int do_zboot (cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[])
/* Setup board for maximum PC/AT Compatibility */
setup_pcat_compatibility();
-/* argv[1] holds the address of the bzImage */
-bzImage_addr = (void *)simple_strtoul(argv[1], NULL, 16);
+if (argc= 2) {
+/* argv[1] holds the address of the bzImage */
+bzImage_addr = (void *)simple_strtoul(argv[1], NULL, 16);
+} else {
+s = getenv(fileaddr);
+if (s)
+bzImage_addr = (void *)simple_strtoul(s, NULL, 16);
+}
Why not:
+if (argc = 2)
+/* argv[1] holds the address of the bzImage */
+s = argv[1];
+else
+s = getenv(fileaddr);
+
+if (s)
+bzImage_addr = (void *)simple_strtoul(s, NULL, 16);
WBR, Sergei
Nice, thanks - will do
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM relocation, question to Heiko
On 04/10/10 19:28, Albert ARIBAUD wrote: Le 04/10/2010 09:27, Reinhard Meyer a écrit : Dear Albert ARIBAUD, Right now I can build (not run, mind you) u-boot for edminiv2 without -fPIC/-fPIE, with -pie and a modified u-boot.lds and start.S. Almost all Any reason to do it in assembler? Have a look at arch/i386/lib/board.c board_init_f() (especially if you apply my latest patch series) of the .rel.dyn fixup entries are type 23, that is, relative to the base address, which is good. However, here are about ten at the end which are type 2 -- symbol-relative -- and I am studying them in order to see if they are needed. Hmm, for x86 they are all type 8 (R_386_RELATIVE) which are a simple Base + Addend (B + A) entries Type 23 is R_ARM_RELATIVE which are also B + A (although they can also by S + A whatever that means) If type 23 relocations are all that is needed, then a first ARM ELF relocation implementation should 'simply' trade GOT vs .rel.dyn relocation in start.S (I am almost there) and remove fixups in Removing fixups - sweet, oh so sweet ;) board_init_r. Start.S would apply type 23 fixups only and ignore the rest. Later on we could add a build stage to rewrite the .rel.dyn section as suggested, by filtering out non-type-23 relocs and keeping only the address part of type-23 ones, reducing the .rel.dyn table roughly by half. Also non type-8 for x86 - If all arches reduce down to a single relocation type in .rel.dyn then we can ignore the type and simply strip all the 'type' fields. [snip] A rather wild, but quite arch independant additional build stage for relocation would be to link u-boot for two different TEXT_BASE values e.g. TEXT_BASE (as desired) and TEXT_BASE+0x00010010. A special diff tool should find the 32 bit places where relocation is required and add a table to the end of u-boot.bin... (Just a rough idea) I don't think we need to - everything should be handled by .rel.dyn. I wrote a diff tool to do as you suggest, but I have no need for it now Looks like we could be onto a winner :) Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] packed attribute problem
Dear Vipin Kumar, In message 4ca9b316.3050...@st.com you wrote: Hm... Why do these structs have any __attribute__ ((packed)) at all? Even I could not understand that very well Eventually alignment of these structs cannot be guaranteed? In my opinion it can be guaranteed. btw, I am talking about ehci_hcor structure in include/usb/host/ehci.h The only reason I am confused is that a lot many platforms would have faced a similar problem (or is it only me). Please confirm if I should remove the packed attribute and send a patch This is mostly a decision Remy has to make (on cc:) This also raises one doubt. Since u-boot code now contains structures to access device registers, using packed attribute with these structures can be lethal On ARM, indeed. Such structures must not use any packed attributes. 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 About the use of language: it is impossible to sharpen a pencil with a blunt ax. It is equally vain to try to do it with ten blunt axes instead. -- Edsger Dijkstra ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] USB: Make non-bulk delay longer in OHCI
Dne Po 4. října 2010 06:43:45 Wolfgang Denk napsal(a): Dear Marek Vasut, In message 201010040136.27940.marek.va...@gmail.com you wrote: Dne Po 20. zá#í 2010 03:57:25 Marek Vasut napsal(a): This fixes TIMEOUT with my Kingston 32GB USB3.0 flashdrive, which I experienced on my PXA270 (USB 1.1) Vpac270 board. CC Remy How do you expoect this to work? You did NOT add him to the Cc: list. Also please note that wd...@denx.de is a non-existing address. Best regards, Wolfgang Denk I added him to CC in mail ... what else do you expect? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM relocation, question to Heiko
Le 04/10/2010 10:57, Heiko Schocher a écrit : ./MAKEALL edminiv2 results: text databssdechexfilename 141376 4388 16640 162404 27a64./u-boot (for GOT reloc) 150160 3819 16640 170619 29a7b./u-boot (for ELF reloc) u-boot.bin size in bytes: 145764 (for GOT reloc) 153976 (for ELF reloc) Huh... The .rel.dyn table is 18472 bytes, and should eventually shrink by half, losing about 9 KB. That would bring the u-boot.bin size down to 145 KB, roughly the same size as GOT reloc -- plus we'd save a few code ... puuh ;-) :) Think also that if I'm not mistaken, the GOT has to move to RAM while the .rel.dyn and .dynsym tables will not be necessary once relocated (unless you want u-boot to be able to move around in RAM), so RAM footprint would be smaller. You might get away with less relocs using -msdata -G . Not sure how that works on arm. Jocke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] packed attribute problem
Dear Wolfgang Denk and Reinhard Meyer,
The compiler (4.4.1) generates the expected 32bit store instruction when using:
struct p {
int n;
} __attribute__ ((packed, aligned(4)));
In case of hardware registers, I have yet to see a case where this is not true.
Regards,
Francesco
On Mon, Oct 4, 2010 at 2:43 PM, Reinhard Meyer u-b...@emk-elektronik.de wrote:
Dear Wolfgang Denk,
Dear Reinhard Meyer,
In message 4ca9be94.6000...@emk-elektronik.de you wrote:
Do you imply that the code is really different when the pointer gets
its value by assigning it NOT to a packed entity? Hard to believe.
This is a special feature of GCC on ARM.
- cat foo.c
#define writel(v,a) (*(volatile unsigned int *)(a) = (v))
struct p {
int n;
} __attribute__ ((packed));
struct q {
int n;
};
void foo()
{
struct p *pp = (struct p *)0x1000;
pp-n = 5;
}
void bar()
{
struct q *qq = (struct q *)0x1000;
qq-n = 5;
}
- arm-linux-gcc -O -S foo.c
- cat foo.s
.file foo.c
.text
.align 2
.global foo
.type foo, %function
foo:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
@ lr needed for prologue
mov r3, #4096
mov r2, #0
orr r1, r2, #5
strb r1, [r3, #0]
strb r2, [r3, #1]
strb r2, [r3, #2]
strb r2, [r3, #3]
bx lr
.size foo, .-foo
.align 2
.global bar
.type bar, %function
In a non-packed struct an int will never be unaligned
(unless you use an unaligned pointer to the whole struct)
In a packed struct an int might be unaligned, so it
_might_ make sense for the compiler to handle that
differently on ARM. Assume you overlay (bad idea anyway)
a packed structure over some communication data stream
thats is byte oriented. On most architectures that would
work (besides obvious endianess issues) but on ARM it would
(without raising an exception) malfunction.
[remember the display_buffer issue]
bar:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
@ lr needed for prologue
mov r2, #5
mov r3, #4096
str r2, [r3, #0]
bx lr
.size bar, .-bar
.ident GCC: (GNU) 4.2.2
Note that this is with GCC 4.2.2. Even GCC 4.0.0 behaves the same, so
this is *not* an issue with very recent tool chains.
OK, for directly adressing elements inside a packed struct;
but the original post said:
struct xyz {
int x;
int y;
int z[CONST];
} __attribute__ ((packed));
struct xyz *abc;
u32 * status_reg = (u32 *)abc-z[0];
writel(status, status_reg);
So the status_reg pointer is in a completely unrelated (to the packed
struct)
u32 * and still the access is done like it was packed. If the
compiler silently drags that attribute along into the u32 *
THAT is really sick!
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] DDR SPD table
Do you have the general materials about DDR programming in u-boot? Thanks! Shuyou ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] denx/master is not building for OMAP3 platforms except Beagle
Hi Heiko, [...] Surely having e.g. #if (not fixed config) #error See http://blah/blah/blah for information about how to fix your board #endif would be more beneficial than an obscure compiler failure that doesn't even reference useful keywords? but that would result in editing *all* config files, which are not coverted. Are you sure? Isn't there some central place in arm land where board.h is included? Such an ifdef there would catch all configs or what am I missing? Cheers Detlev -- Whenever you find yourself on the side of the majority it is time to pause and reflect. -- Mark Twain -- 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] denx/master is not building for OMAP3 platforms except Beagle
Dear Detlev Zundel, In message m2hbh2ruux@ohwell.denx.de you wrote: but that would result in editing *all* config files, which are not coverted. Are you sure? Isn't there some central place in arm land where board.h is included? Such an ifdef there would catch all configs or what am I missing? Any central place would catch _all_ files, but we need to make a difference between those that have already been converted, and those that have not yet. This _is_ indeed a board specific thing. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A little suffering is good for the soul. -- Kirk, The Corbomite Maneuver, stardate 1514.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] board_init_r: Removed unused cmdtp variable
Hello Richard, Richard Retanubun wrote: Follow up to commit 620f1f6a64095ed558e68d37f1965d015cd49b02 removed compiler warning for (now) unused cmd_tbl_t* cmdtp --- Hi Heiko, Not sure if you caught this one already, just a simple unused variable cleanup Thanks, but already fixed in arch/arm/lib/board.c bye, Heiko Hi Heiko, Does this mean I should cc the respective maintainers for avr32, m68k, and mips arch (the ones I found in my patch) to have them applied it? Yes. or was that a typo and you mean the patch is already applied on the ARM branch of the git repo? I meant with already fixed in arch/arm/lib/board.c, that in arch/arm/lib/board.c there is no such unused variable in code, so no need for fixing it there. bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] denx/master is not building for OMAP3 platforms except Beagle
Hello Detlev, Detlev Zundel wrote: Hi Heiko, [...] Surely having e.g. #if (not fixed config) #error See http://blah/blah/blah for information about how to fix your board #endif would be more beneficial than an obscure compiler failure that doesn't even reference useful keywords? but that would result in editing *all* config files, which are not coverted. Are you sure? Isn't there some central place in arm land where board.h is included? Such an ifdef there would catch all configs or what am I missing? How would you detect there, if the config file (board.h) is converted for relocation and working or not? This help should only be printed if CONFIG_SYS_ARM_WITHOUT_RELOC is not defined and compiling fails ... bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 1/2] APM821xx: Add CPU support
On Tuesday 28 September 2010 23:15:14 tma...@apm.com wrote: 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. Applied to u-boot-ppc4xx/master. Thanks. 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] ARM relocation, question to Heiko
Le 04/10/2010 10:52, Joakim Tjernlund a écrit : Albert ARIBAUDalbert.arib...@free.fr wrote on 2010/10/04 10:33:05: Le 04/10/2010 10:28, Joakim Tjernlund a écrit : Le 04/10/2010 09:36, Joakim Tjernlund a écrit : However, I think we will loose the possibility to add link once, burn and run anywhere feature I impl. once(but it was at the time deemed to intrusive) if we skip -fPIC and go for the linker -pie relocation. On ARM at least, I don't think so. From what I see, the -pie ld option without the -fPIC/-fPIE compiler option alone builds a .rel.syn table that contains all necessary fixes to mve the code anywhere. hmm, maybe my memory fails me but doesn't these relocs change the code to relocate accesses? While in flash you can't do that. Perhaps this is fixable too with the LINK_OFF method I impl. but memory fails me as it was quite some time ago. Jocke Actually the principle is to link with TEXT_BASE equal to the NOR FLASH location of the image [1] so that relocation is not needed there. Only when you move the code to RAM do you need relocation. Yes, that is there today. I am talking about linking to any TEXT_BASE(say 0) but burn and run into another address. I impl. this quite some time ago for PPC(search for LINK_OFF) I am ultimately looking for same here on ARM. Note however that linking for base address 0 is not mandatory for achieving true position independence. What is required is that the code which runs from power-up until relocation be able to run anywhere, i.e., this code should not require any relocation fixup. That can be achieved on ARM by using only relative branches and accessing data only relative to pc (e.g. literals) or truly absolute (e.g. HW registers etc). Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM relocation, question to Heiko
Dear Joakim Tjernlund, In message ofe6153b0a.80735dd8-onc12577b2.002963a5-c12577b2.0029d...@transmode.se you wrote: However, I think we will loose the possibility to add link once, burn and run anywhere feature I impl. once(but it was at the time deemed to intrusive) if we skip -fPIC and go for the linker -pie relocation. I would suggest to leave ppc as is for the time being and see how -pie works out on the other archs. I see two tasks here: Prio 1: fix the current problems on ARM Prio 2: make architectures as similar as possible. My dream would be to have all that work in the same way (even if eventually differen mechanisms need ti be deployed) on ARM, x86 and PPC (and MIPS? and others?). 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 question is too silly to ask. Of course, some questions are too silly to to answer... - L. Wall R. L. Schwartz, _Programming Perl_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] board_init_r: Removed unused cmdtp variable
Follow up to commit 620f1f6a64095ed558e68d37f1965d015cd49b02 removed compiler warning for (now) unused cmd_tbl_t* cmdtp --- Hi Heiko, Not sure if you caught this one already, just a simple unused variable cleanup Thanks, but already fixed in arch/arm/lib/board.c bye, Heiko Hi Heiko, Does this mean I should cc the respective maintainers for avr32, m68k, and mips arch (the ones I found in my patch) to have them applied it? or was that a typo and you mean the patch is already applied on the ARM branch of the git repo? Thanks, - Richard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM relocation, question to Heiko
Le 04/10/2010 10:28, Joakim Tjernlund a écrit : Le 04/10/2010 09:36, Joakim Tjernlund a écrit : However, I think we will loose the possibility to add link once, burn and run anywhere feature I impl. once(but it was at the time deemed to intrusive) if we skip -fPIC and go for the linker -pie relocation. On ARM at least, I don't think so. From what I see, the -pie ld option without the -fPIC/-fPIE compiler option alone builds a .rel.syn table that contains all necessary fixes to mve the code anywhere. hmm, maybe my memory fails me but doesn't these relocs change the code to relocate accesses? While in flash you can't do that. Perhaps this is fixable too with the LINK_OFF method I impl. but memory fails me as it was quite some time ago. Jocke Actually the principle is to link with TEXT_BASE equal to the NOR FLASH location of the image [1] so that relocation is not needed there. Only when you move the code to RAM do you need relocation. [1] which voids my idea of setting TEXT_BASE to 0, btw, but that does not matter much anyway. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM relocation, question to Heiko
Albert ARIBAUD albert.arib...@free.fr wrote on 2010/10/04 10:33:05: Le 04/10/2010 10:28, Joakim Tjernlund a écrit : Le 04/10/2010 09:36, Joakim Tjernlund a écrit : However, I think we will loose the possibility to add link once, burn and run anywhere feature I impl. once(but it was at the time deemed to intrusive) if we skip -fPIC and go for the linker -pie relocation. On ARM at least, I don't think so. From what I see, the -pie ld option without the -fPIC/-fPIE compiler option alone builds a .rel.syn table that contains all necessary fixes to mve the code anywhere. hmm, maybe my memory fails me but doesn't these relocs change the code to relocate accesses? While in flash you can't do that. Perhaps this is fixable too with the LINK_OFF method I impl. but memory fails me as it was quite some time ago. Jocke Actually the principle is to link with TEXT_BASE equal to the NOR FLASH location of the image [1] so that relocation is not needed there. Only when you move the code to RAM do you need relocation. Yes, that is there today. I am talking about linking to any TEXT_BASE(say 0) but burn and run into another address. I impl. this quite some time ago for PPC(search for LINK_OFF) Jocke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc4xx/fdt/flash: Fix bug in fdt_fixup_nor_flash_node()
On Wednesday 29 September 2010 17:22:32 Stefan Roese wrote: This patch fixes a bug in fdt_fixup_nor_flash_node() when the reg property has multiple reg tuples, like: reg = 0 0x 0x0400 0 0x0400 0x0400; In this case this function did not update the reg property correctly. Applied to u-boot-ppc4xx/master. Thanks. 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] ppc4xx: Small whitespace cleanup in canyonlands.c
On Wednesday 29 September 2010 17:22:45 Stefan Roese wrote: Signed-off-by: Stefan Roese s...@denx.de Applied to u-boot-ppc4xx/master. Thanks. 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] ppc4xx: Big lwmon5 board support rework/update
On Wednesday 29 September 2010 17:20:10 Stefan Roese wrote: From: Sascha Laue sascha.l...@liebherr.com This patch brings the lwmon5 board support up-to-date. Here a summary of the changes: lwmon5 board port related: - GPIO's changed to control the LSB transmitter - Reset USB PHY's upon power-up - Enable CAN upon power-up - USB init error workaround (errata CHIP_6) - EBC: Enable burstmode and modify the timings for the GDC memory - EBC: Speed up NOR flash timings lwmon5 board POST related: - Add FPGA memory test - Add GDC memory test - DSP POST reworked - SYSMON POST: Fix handling of negative temperatures - Add output for sysmon1 POST - HW-watchdog min. time test reworked Additionally some coding-style changes were done. Applied to u-boot-ppc4xx/master. Thanks. 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] ppc4xx: Add defines for COM3 COM4 (UART2 UART3) on 440EPx/GRx
On Wednesday 29 September 2010 17:21:08 Stefan Roese wrote: Signed-off-by: Stefan Roese s...@denx.de Applied to u-boot-ppc4xx/master. Thanks. 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] ARM relocation, question to Heiko
Le 04/10/2010 11:58, Graeme Russ a écrit : On 04/10/10 19:28, Albert ARIBAUD wrote: Le 04/10/2010 09:27, Reinhard Meyer a écrit : Dear Albert ARIBAUD, Right now I can build (not run, mind you) u-boot for edminiv2 without -fPIC/-fPIE, with -pie and a modified u-boot.lds and start.S. Almost all Any reason to do it in assembler? Have a look at arch/i386/lib/board.c board_init_f() (especially if you apply my latest patch series) The main reasons are that start.S is historically responsible for setting up the C environment, and that only in assembly language can you ensure that no nasty relocation fixup is going to be required by the code that is precisely supposed to do the fixing up. Now it may be possible to do the fixups in C on ARM; that'll be a second step IMO. of the .rel.dyn fixup entries are type 23, that is, relative to the base address, which is good. However, here are about ten at the end which are type 2 -- symbol-relative -- and I am studying them in order to see if they are needed. Hmm, for x86 they are all type 8 (R_386_RELATIVE) which are a simple Base + Addend (B + A) entries Type 23 is R_ARM_RELATIVE which are also B + A (although they can also by S + A whatever that means) 23 is program base relative -- basically, subtract link-time image base address, add run-time image base address and you're set. If type 23 relocations are all that is needed, then a first ARM ELF relocation implementation should 'simply' trade GOT vs .rel.dyn relocation in start.S (I am almost there) and remove fixups in Removing fixups - sweet, oh so sweet ;) Apparently sweetness is not far away, see below. :) board_init_r. Start.S would apply type 23 fixups only and ignore the rest. Later on we could add a build stage to rewrite the .rel.dyn section as suggested, by filtering out non-type-23 relocs and keeping only the address part of type-23 ones, reducing the .rel.dyn table roughly by half. Also non type-8 for x86 - If all arches reduce down to a single relocation type in .rel.dyn then we can ignore the type and simply strip all the 'type' fields. Can't reduce to a single relocation type as produced by the linker, because references to linker-file-generated symbols seem to always be symbol-relative, not program-relative, even under -pie. This may be something to ask on the binutils mailing list, though. [snip] A rather wild, but quite arch independant additional build stage for relocation would be to link u-boot for two different TEXT_BASE values e.g. TEXT_BASE (as desired) and TEXT_BASE+0x00010010. A special diff tool should find the 32 bit places where relocation is required and add a table to the end of u-boot.bin... (Just a rough idea) I don't think we need to - everything should be handled by .rel.dyn. I wrote a diff tool to do as you suggest, but I have no need for it now Looks like we could be onto a winner :) Regards, Graeme At this point I have an ARM926, ELF-relocating, u-boot reaching prompt. Environment is correctly read and can be modified (did not try saving though). Flash operations work (flinfo, erase, cp.b). Ethernet does not work, however -- ping or tftp just wait without me being able to ^C it. I'll look into that as soon as some domestic chores are done. :) Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] AT91 clock and timer cleanups
Dear Reinhard Meyer, In message 4ca99373.7020...@emk-elektronik.de you wrote: Patch 1 will change the #if and introduce CONFIG_AT91SAM9_FAMILY instead. Patch 2 will fix at91/clock.c+timer.c Maybe there is a misunderstanding here. I see three patches 1. introduce CONFIG_AT91SAM9_FAMILY to common.h 2. add an #ifdef CONFIG_AT91SAM9_FAMILY to global_data.h with the required variables 3. change clock and timer. 2+3 combined in one patch? OK No. 1 + 2 belong together; they deal with the same topic and should be applied as a single commit. 3 is a completely different story and goes in a separate patch. And I bet, this must be a patch series ;) Not necessarily. The 1+2 combo is independent from 3 (but needed as a prerequisite, so posting this in a series is fine as well). 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 Lots of people drink from the wrong bottle sometimes. -- Edith Keeler, The City on the Edge of Forever, stardate unknown ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/19] x86: Move ECC initialisation outside RAM initialisation
On 04/10/10 20:59, Sergei Shtylyov wrote: Hello. On 04-10-2010 7:37, Graeme Russ wrote: To allow for 'load anywhere' images, the %ebp return pointer 'hack' must be removed, so we cannot have two 'calls' to get_mem_size Signed-off-by: Graeme Russgraeme.r...@gmail.com [...] diff --git a/arch/i386/cpu/start.S b/arch/i386/cpu/start.S index cb47ce7..9e6e0bf 100644 --- a/arch/i386/cpu/start.S +++ b/arch/i386/cpu/start.S @@ -93,6 +93,17 @@ mem_init_ret: jmpget_mem_size get_mem_size_ret: +#if CONFIG_SYS_SDRAM_ECC_ENABLE +/* Skip ECC initialization if not starting from cold-reset */ +movl%ebx, %ecx +andl$GD_FLG_COLD_BOOT, %ecx +jzecc_init_ret But the label you added is called 'init_ecc_ret'. Are you sure the name is correct here? Yes, if the board has not been cold-booted (i.e. a new U-Boot image has been loaded into RAM and executed) we must skip ECC initialization (it destroys the contents of memory) +mov$init_ecc_ret, %ebp +jmpinit_ecc + +init_ecc_ret: +#endif + /* Check we have enough memory for stack */ movl$CONFIG_SYS_STACK_SIZE, %ecx cmpl%ecx, %eax WBR, Sergei Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM relocation, question to Heiko
Le 04/10/2010 09:27, Reinhard Meyer a écrit : Dear Albert ARIBAUD, Right now I can build (not run, mind you) u-boot for edminiv2 without -fPIC/-fPIE, with -pie and a modified u-boot.lds and start.S. Almost all of the .rel.dyn fixup entries are type 23, that is, relative to the base address, which is good. However, here are about ten at the end which are type 2 -- symbol-relative -- and I am studying them in order to see if they are needed. If type 23 relocations are all that is needed, then a first ARM ELF relocation implementation should 'simply' trade GOT vs .rel.dyn relocation in start.S (I am almost there) and remove fixups in board_init_r. Start.S would apply type 23 fixups only and ignore the rest. Later on we could add a build stage to rewrite the .rel.dyn section as suggested, by filtering out non-type-23 relocs and keeping only the address part of type-23 ones, reducing the .rel.dyn table roughly by half. The good news is, I can spare a couple more hours today on this. I'll let you all know how this fares! Thats good news! How much did the image size increase with this table? ./MAKEALL edminiv2 results: text data bss dec hex filename 141376 4388 16640 162404 27a64 ./u-boot (for GOT reloc) 150160 3819 16640 170619 29a7b ./u-boot (for ELF reloc) u-boot.bin size in bytes: 145764 (for GOT reloc) 153976 (for ELF reloc) The .rel.dyn table is 18472 bytes, and should eventually shrink by half, losing about 9 KB. That would bring the u-boot.bin size down to 145 KB, roughly the same size as GOT reloc -- plus we'd save a few code bytes since reloc fixup functions in board_init_r would not be needed any more. And I am willing to test your efforts on AT91 here, maybe you can send me the changes to .lds and start.S beforehand so I can see what type of relocation info gets produced here. I'll post an RFC patch within one or two hours. A rather wild, but quite arch independant additional build stage for relocation would be to link u-boot for two different TEXT_BASE values e.g. TEXT_BASE (as desired) and TEXT_BASE+0x00010010. A special diff tool should find the 32 bit places where relocation is required and add a table to the end of u-boot.bin... (Just a rough idea) That would be the simplest option even though it's obviously not optimal. Feel free to start this if you want, and let's meet at the bridge. :) Best Regards, Reinhard Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] denx/master is not building for OMAP3 platforms except Beagle
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Monday, October 04, 2010 12:08 AM To: Hiremath, Vaibhav Cc: Albert ARIBAUD; u-boot@lists.denx.de Subject: Re: [U-Boot] denx/master is not building for OMAP3 platforms except Beagle Dear Hiremath, Vaibhav, In message 19f8576c6e063c45be387c64729e739404aa21c...@dbde02.ent.ti.com you wrote: Note that adding the definition may not be sufficient to get relocation working. [Hiremath, Vaibhav] But atleast it will make code to compile cleanly. I feel, at any cost we should not add such patches which will break compilation, the code should build always. If the code compiles without problems, but then fails to run, the situation would be only worse. [Hiremath, Vaibhav] I agree that the situation in both the case is going to be only worst, but I feel we should not merge the patches which breaks other platforms. Anyway I will test this for AM3517, OMAP3EVM and submit the patch shortly. Thanks, Vaibhav It is MUCH BETTER to roar a clear and unmistakable error message into the face of the user so everybody gets aware that some work needs to be done to fix these boards rather than to hush up the problems, in which case nobody would do anything, and a much bigger turmoil would start when the feature removel time comes and all these broken boards get removed from the tree, [Hiremath, Vaibhav] I 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 Was heißt Windows auf Indianisch? - Weißer Mann, der auf Sanduhr wartet! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ppc44x - watchdog timers reboots during the image loading
Hi ame, On Friday 01 October 2010 17:36:39 ame wrote: Ok, confirmed the new one has it in there. sorry about that. The logic is the same as the one that is in the old code though. Well, ok, kind of. cpu.c is correct, cpu_init.c that actually sets up the watchdog timer is not though. It still has the lower case register names. #if defined(CONFIG_WATCHDOG) val = mfspr(tcr); ... mtspr(tcr, val); val = mfspr(tsr); val |= 0x8000; /* enable watchdog timer */ mtspr(tsr, val); ... #endif /* CONFIG_WATCHDOG */ Ah, correct. I missed those. I'll fix it soon. Thanks for pointing out. I've added some prints and turned on debug and find that it makes it all the way to the jump to the kernel. So it must be an issue with the setup or config of the kernel. Does the device tree require any changes to work with the watchdog? Thanks for your help. Depends on the watchdog device driver. The Book-E driver doesn't seem to need anything here, AFAIK. I suggest you enable the debug early-printk feature and/or look the __log_buf to see how far Linux really comes. This is not U- Boot realted any more though. So further questions/mails should be moved to linuxppc-dev. 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 10/19] x86: Move ECC initialisation outside RAM initialisation
Dear Graeme Russ, In message 4ca9a70b.6030...@gmail.com you wrote: +#if CONFIG_SYS_SDRAM_ECC_ENABLE +/* Skip ECC initialization if not starting from cold-reset */ +movl%ebx, %ecx +andl$GD_FLG_COLD_BOOT, %ecx +jzecc_init_ret But the label you added is called 'init_ecc_ret'. Are you sure the name is correct here? Yes, if the board has not been cold-booted (i.e. a new U-Boot image has been loaded into RAM and executed) we must skip ECC initialization (it destroys the contents of memory) +mov$init_ecc_ret, %ebp +jmpinit_ecc + +init_ecc_ret: Sergei did not question the code itself, but the possible confusion between ecc_init_ret versus init_ecc_ret, which both were added with the same commit, so it seems likely both should actually be the _same_ name? 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 Crash programs fail because they are based on the theory that, with nine women pregnant, you can get a baby a month. - Wernher von Braun ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM relocation, question to Heiko
Le 04/10/2010 08:40, Albert ARIBAUD a écrit : Right now I can build (not run, mind you) u-boot for edminiv2 without -fPIC/-fPIE, with -pie and a modified u-boot.lds and start.S. Almost all of the .rel.dyn fixup entries are type 23, that is, relative to the base address, which is good. However, here are about ten at the end which are type 2 -- symbol-relative -- and I am studying them in order to see if they are needed. Those type 2 relocations correspond to symbols which are defined in the linker file (e.g. __got_start and __got_end) and thus are absolute, not relative. If type 23 relocations are all that is needed, then a first ARM ELF relocation implementation should 'simply' trade GOT vs .rel.dyn relocation in start.S (I am almost there) and remove fixups in board_init_r. Start.S would apply type 23 fixups only and ignore the rest. Later on we could add a build stage to rewrite the .rel.dyn section as suggested, by filtering out non-type-23 relocs and keeping only the address part of type-23 ones, reducing the .rel.dyn table roughly by half. Al right, so type 2 are needed too, and of course they need a different processing than type 23, but the good news is, one should easily make the linker provide relative values for type 2 fixups by telling it to base the executable at offset 0. The interest of doing so is that all fixups in .rel.dyn could be processed homogeneously by adding the actual base address of the code to each fixup location. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Would somebody block this please?
Hi Sergey, It is already 5th or more same spam email in a row. Does anybody care? Yes I do, thanks for the reminder. Cheers Detlev -- Less talking -- more hacking -- Olin Shivers -- 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] ARM relocation, question to Heiko
Le 04/10/2010 09:36, Joakim Tjernlund a écrit : However, I think we will loose the possibility to add link once, burn and run anywhere feature I impl. once(but it was at the time deemed to intrusive) if we skip -fPIC and go for the linker -pie relocation. On ARM at least, I don't think so. From what I see, the -pie ld option without the -fPIC/-fPIE compiler option alone builds a .rel.syn table that contains all necessary fixes to mve the code anywhere. However: I would suggest to leave ppc as is for the time being and see how -pie works out on the other archs. I second that. More precisely, I'd suggest to wait for ELF relocation to succeed on arm296ejs before considering any other ARM, then any other arch. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM relocation, question to Heiko
Hello Albert, Albert ARIBAUD wrote: Le 04/10/2010 09:27, Reinhard Meyer a écrit : Dear Albert ARIBAUD, Right now I can build (not run, mind you) u-boot for edminiv2 without -fPIC/-fPIE, with -pie and a modified u-boot.lds and start.S. Almost all of the .rel.dyn fixup entries are type 23, that is, relative to the base address, which is good. However, here are about ten at the end which are type 2 -- symbol-relative -- and I am studying them in order to see if they are needed. If type 23 relocations are all that is needed, then a first ARM ELF relocation implementation should 'simply' trade GOT vs .rel.dyn relocation in start.S (I am almost there) and remove fixups in board_init_r. Start.S would apply type 23 fixups only and ignore the rest. Later on we could add a build stage to rewrite the .rel.dyn section as suggested, by filtering out non-type-23 relocs and keeping only the address part of type-23 ones, reducing the .rel.dyn table roughly by half. The good news is, I can spare a couple more hours today on this. I'll let you all know how this fares! Thats good news! How much did the image size increase with this table? ./MAKEALL edminiv2 results: text databssdechexfilename 141376 4388 16640 162404 27a64./u-boot (for GOT reloc) 150160 3819 16640 170619 29a7b./u-boot (for ELF reloc) u-boot.bin size in bytes: 145764 (for GOT reloc) 153976 (for ELF reloc) Huh... The .rel.dyn table is 18472 bytes, and should eventually shrink by half, losing about 9 KB. That would bring the u-boot.bin size down to 145 KB, roughly the same size as GOT reloc -- plus we'd save a few code ... puuh ;-) bytes since reloc fixup functions in board_init_r would not be needed any more. Sounds good. And we can easy test this, by defining CONFIG_RELOC_FIXUP_WORKS for all arm boards ... And I am willing to test your efforts on AT91 here, maybe you can send me the changes to .lds and start.S beforehand so I can see what type of relocation info gets produced here. I'll post an RFC patch within one or two hours. Thanks! I am wating for it, and try your patches too. bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] CONFIG_SYS_ARM_WITHOUT_RELOC: document feature removal
In message 1285752572-2107-1-git-send-email...@denx.de you wrote: Signed-off-by: Wolfgang Denk w...@denx.de --- doc/feature-removal-schedule.txt | 29 - 1 files changed, 28 insertions(+), 1 deletions(-) Applied (with fixes as discussed here). Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If the code and the comments disagree, then both are probably wrong.- Norm Schryer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM relocation, question to Heiko
Le 04/10/2010 10:57, Heiko Schocher a écrit : ./MAKEALL edminiv2 results: text databssdechexfilename 141376 4388 16640 162404 27a64./u-boot (for GOT reloc) 150160 3819 16640 170619 29a7b./u-boot (for ELF reloc) u-boot.bin size in bytes: 145764 (for GOT reloc) 153976 (for ELF reloc) Huh... The .rel.dyn table is 18472 bytes, and should eventually shrink by half, losing about 9 KB. That would bring the u-boot.bin size down to 145 KB, roughly the same size as GOT reloc -- plus we'd save a few code ... puuh ;-) :) Think also that if I'm not mistaken, the GOT has to move to RAM while the .rel.dyn and .dynsym tables will not be necessary once relocated (unless you want u-boot to be able to move around in RAM), so RAM footprint would be smaller. bytes since reloc fixup functions in board_init_r would not be needed any more. Sounds good. And we can easy test this, by defining CONFIG_RELOC_FIXUP_WORKS for all arm boards ... I'll check that. And I am willing to test your efforts on AT91 here, maybe you can send me the changes to .lds and start.S beforehand so I can see what type of relocation info gets produced here. I'll post an RFC patch within one or two hours. Thanks! I am wating for it, and try your patches too. Testing on the board right now. bye, Heiko Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-ppc4xx/master
The following changes since commit dd09985499ac95484974eb0f832fe47b33369952: hmi1001, mucmc52, uc100, uc101: move boards to vendor directory (2010-10-04 10:58:38 +0200) are available in the git repository at: git://www.denx.de/git/u-boot-ppc4xx.git master Rupjyoti Sarmah (1): ppc44x: config GPIOs for USB on canyonlands board Sascha Laue (1): ppc4xx: Big lwmon5 board support rework/update Stefan Roese (5): ppc4xx: Add defines for COM3 COM4 (UART2 UART3) on 440EPx/GRx ppc4xx/fdt/flash: Fix bug in fdt_fixup_nor_flash_node() ppc4xx: Small whitespace cleanup in canyonlands.c ppc4xx: Use common ns16550 functions in 4xx UART POST driver ppc4xx: Remove some testing hacks from ppc4xx.h Tirumala Marri (2): APM821xx: Add CPU support APM821xx: Add bluestone board support MAINTAINERS |4 + 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 | 72 +++ arch/powerpc/include/asm/ppc440epx_grx.h |2 + 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| 21 +-- 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 | 60 ++ board/amcc/canyonlands/canyonlands.c | 43 +++-- board/lwmon5/kbd.c | 45 + board/lwmon5/lwmon5.c| 249 +++- boards.cfg |1 + common/fdt_support.c | 17 +- include/configs/bluestone.h | 178 + include/configs/hcu4.h |2 +- include/configs/hcu5.h |2 +- include/configs/kilauea.h|3 +- include/configs/lwmon5.h | 284 include/configs/makalu.h |3 +- include/configs/mcu25.h |2 +- include/configs/zeus.h |2 +- post/board/lwmon5/dsp.c | 21 ++- post/board/lwmon5/dspic.c| 56 -- post/board/lwmon5/fpga.c | 308 +- post/board/lwmon5/gdc.c | 308 -- post/board/lwmon5/sysmon.c | 160 ++-- post/board/lwmon5/watchdog.c | 19 ++- post/cpu/ppc4xx/uart.c | 302 ++--- 37 files changed, 1804 insertions(+), 708 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 V2] LZO: Add a LZO compression feature
Changes from V1 to V2:
- Add a configuration option for the LZO compression
- Add a comment line specifying the origin of the source code
In some case, LZO compression function is needed in U-Boot.
This patch supports LZO compression feature which is originated from Linux
kernel.
Thanks.
-Donggeun Kim
Signed-off-by: Donggeun Kim dg77@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
lib/lzo/Makefile |1 +
lib/lzo/lzo1x_compress.c | 221 ++
2 files changed, 222 insertions(+), 0 deletions(-)
create mode 100644 lib/lzo/lzo1x_compress.c
diff --git a/lib/lzo/Makefile b/lib/lzo/Makefile
index 5dd1bf5..ca2253a 100644
--- a/lib/lzo/Makefile
+++ b/lib/lzo/Makefile
@@ -28,6 +28,7 @@ LIB = $(obj)liblzo.a
SOBJS =
COBJS-$(CONFIG_LZO) += lzo1x_decompress.o
+COBJS-$(CONFIG_LZO_COMPRESSION) += lzo1x_compress.o
COBJS = $(COBJS-y)
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
diff --git a/lib/lzo/lzo1x_compress.c b/lib/lzo/lzo1x_compress.c
new file mode 100644
index 000..1743727
--- /dev/null
+++ b/lib/lzo/lzo1x_compress.c
@@ -0,0 +1,221 @@
+/*
+ * LZO1X Compressor from MiniLZO
+ *
+ * Copyright (C) 1996-2005 Markus F.X.J. Oberhumer mar...@oberhumer.com
+ *
+ * The full LZO package can be found at:
+ * http://www.oberhumer.com/opensource/lzo/
+ *
+ * Changed for kernel use by:
+ * Nitin Gupta nitingupta...@gmail.com
+ * Richard Purdie rpur...@openedhand.com
+ *
+ * Note : This code is taken from linux kernel.
+ */
+#include common.h
+#include linux/lzo.h
+#include asm/unaligned.h
+#include lzodefs.h
+
+static size_t
+_lzo1x_1_do_compress(const unsigned char *in, size_t in_len,
+ unsigned char *out, size_t *out_len, void *wrkmem)
+{
+ const unsigned char * const in_end = in + in_len;
+ const unsigned char * const ip_end = in + in_len - M2_MAX_LEN - 5;
+ const unsigned char ** const dict = wrkmem;
+ const unsigned char *ip = in, *ii = ip;
+ const unsigned char *end, *m, *m_pos;
+ size_t m_off, m_len, dindex;
+ unsigned char *op = out;
+
+ ip += 4;
+
+ for (;;) {
+ dindex = ((size_t)(0x21 * DX3(ip, 5, 5, 6)) 5) D_MASK;
+ m_pos = dict[dindex];
+
+ if (m_pos in)
+ goto literal;
+
+ if (ip == m_pos || ((size_t)(ip - m_pos) M4_MAX_OFFSET))
+ goto literal;
+
+ m_off = ip - m_pos;
+ if (m_off = M2_MAX_OFFSET || m_pos[3] == ip[3])
+ goto try_match;
+
+ dindex = (dindex (D_MASK 0x7ff)) ^ (D_HIGH | 0x1f);
+ m_pos = dict[dindex];
+
+ if (m_pos in)
+ goto literal;
+
+ if (ip == m_pos || ((size_t)(ip - m_pos) M4_MAX_OFFSET))
+ goto literal;
+
+ m_off = ip - m_pos;
+ if (m_off = M2_MAX_OFFSET || m_pos[3] == ip[3])
+ goto try_match;
+
+ goto literal;
+
+try_match:
+ if (get_unaligned((const unsigned short *)m_pos)
+ == get_unaligned((const unsigned short *)ip)) {
+ if (likely(m_pos[2] == ip[2]))
+ goto match;
+ }
+
+literal:
+ dict[dindex] = ip;
+ ++ip;
+ if (unlikely(ip = ip_end))
+ break;
+ continue;
+
+match:
+ dict[dindex] = ip;
+ if (ip != ii) {
+ size_t t = ip - ii;
+
+ if (t = 3) {
+ op[-2] |= t;
+ } else if (t = 18) {
+ *op++ = (t - 3);
+ } else {
+ size_t tt = t - 18;
+
+ *op++ = 0;
+ while (tt 255) {
+ tt -= 255;
+ *op++ = 0;
+ }
+ *op++ = tt;
+ }
+ do {
+ *op++ = *ii++;
+ } while (--t 0);
+ }
+
+ ip += 3;
+ if (m_pos[3] != *ip++ || m_pos[4] != *ip++
+ || m_pos[5] != *ip++ || m_pos[6] != *ip++
+ || m_pos[7] != *ip++ || m_pos[8] != *ip++) {
+ --ip;
+ m_len = ip - ii;
+
+ if (m_off = M2_MAX_OFFSET) {
+ m_off -= 1;
+ *op++ = (((m_len - 1) 5)
+ | ((m_off 7) 2));
+ *op++ = (m_off 3);
+ } else if (m_off = M3_MAX_OFFSET) {
+
Re: [U-Boot] AT91 clock and timer cleanups
Dear Wolfgang Denk, Patch 1 will change the #if and introduce CONFIG_AT91SAM9_FAMILY instead. Patch 2 will fix at91/clock.c+timer.c Maybe there is a misunderstanding here. I see three patches 1. introduce CONFIG_AT91SAM9_FAMILY to common.h 2. add an #ifdef CONFIG_AT91SAM9_FAMILY to global_data.h with the required variables 3. change clock and timer. 2+3 combined in one patch? OK No. 1 + 2 belong together; they deal with the same topic and should be applied as a single commit. Ok, so introducing (at this point still) unreferenced variables here is OK? 3 is a completely different story and goes in a separate patch. And I bet, this must be a patch series ;) Not necessarily. The 1+2 combo is independent from 3 (but needed as a prerequisite, so posting this in a series is fine as well). Ok, I rather post it independant, if thats OK, patch series are still more trouble ;) Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM relocation, question to Heiko
Dear Albert ARIBAUD, Right now I can build (not run, mind you) u-boot for edminiv2 without -fPIC/-fPIE, with -pie and a modified u-boot.lds and start.S. Almost all of the .rel.dyn fixup entries are type 23, that is, relative to the base address, which is good. However, here are about ten at the end which are type 2 -- symbol-relative -- and I am studying them in order to see if they are needed. If type 23 relocations are all that is needed, then a first ARM ELF relocation implementation should 'simply' trade GOT vs .rel.dyn relocation in start.S (I am almost there) and remove fixups in board_init_r. Start.S would apply type 23 fixups only and ignore the rest. Later on we could add a build stage to rewrite the .rel.dyn section as suggested, by filtering out non-type-23 relocs and keeping only the address part of type-23 ones, reducing the .rel.dyn table roughly by half. The good news is, I can spare a couple more hours today on this. I'll let you all know how this fares! Thats good news! How much did the image size increase with this table? And I am willing to test your efforts on AT91 here, maybe you can send me the changes to .lds and start.S beforehand so I can see what type of relocation info gets produced here. A rather wild, but quite arch independant additional build stage for relocation would be to link u-boot for two different TEXT_BASE values e.g. TEXT_BASE (as desired) and TEXT_BASE+0x00010010. A special diff tool should find the 32 bit places where relocation is required and add a table to the end of u-boot.bin... (Just a rough idea) Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] packed attribute problem
Dear Vipin Kumar, A writel to status_reg results in byte by byte writing How do you know that? Disassembly? Bus snooping? Disassembly I agree with you. I always considered such behaviour of the ARM C compiler a bug, and still do. However, people with better knowledge of the ARm architecture than me might be able to explain why the responsible PTB consider this to be a good and necessary feature of th compiler. Maybe because writel(v,a) is ultimately defined as (*(volatile unsigned int *)(a) = (v)) and the compiler has to assume the worst, i.e. that (a) is not word aligned? Maybe there is a new compiler switch to turn that pessimisation off? I agree with you on this. But if I create a new u32 pointer and point to an element with in the packed structure, then what should be the behavior ? Do you imply that the code is really different when the pointer gets its value by assigning it NOT to a packed entity? Hard to believe. My assumptions: 1. it has to do NOTHING with packed attributes, once the pointer is in a new variable, that packed information should be lost. Just try int *ptr = (int *) 0x1; a) *ptr = 5; b) writel (5, ptr); do a) and b) produce different code? 2. the culprit on ARM is that unaligned accesses do not raise any signal but silently IGNORE the unused adress lines which leads to very undesirable effects that are hard to find. *((int *)0x1) = 5 is the same as *((int *)0x10003) = 5 ! Both write 5 to the word at adress 0x1 ! So, MAYBE, in newer toolchains it was decided to circumvent that problem by always assuming unaligned pointers unless clearly instructed otherwise. On the other hand, if what you say were true, all code for AT91 that uses writel() to access 32 bit only peripheral registers would not work with those newer toolchains (still 4.2.4 here). Yes, if the at91 code is using packed attribute for device structures Nope. It does not have to do with packed. It would have to do with the fact that I/O registers cannot be safely written byte-wise. Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM relocation, question to Heiko
On 2010/10/04 4:17 PM, Albert ARIBAUD wrote: At this point I have an ARM926, ELF-relocating, u-boot reaching prompt. Environment is correctly read and can be modified (did not try saving though). Flash operations work (flinfo, erase, cp.b). Ethernet does not work, however -- ping or tftp just wait without me being able to ^C it. I'll look into that as soon as some domestic chores are done. :) Excellent work! Congratulations! Rogan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] packed attribute problem
Dear Reinhard Meyer, In message 4ca9cc04.5020...@emk-elektronik.de you wrote: In a non-packed struct an int will never be unaligned (unless you use an unaligned pointer to the whole struct) Which may happen for example when overlaying such a struct on top of some I/O buffer. In a packed struct an int might be unaligned, so it _might_ make sense for the compiler to handle that differently on ARM. Assume you overlay (bad idea anyway) In a packed struct, where the struct itself is located with sufficient alignment, and where all previous elements in the struct are sufficiently aligned (like in the example I gave), it is NOT possible that such unaligment happens. a packed structure over some communication data stream thats is byte oriented. On most architectures that would work (besides obvious endianess issues) but on ARM it would (without raising an exception) malfunction. Keep in mind that the compiler knows the start address of the struct, and the alignment of the elements. It could easily determine that no unaligned accesses can result. With the same logic you would have to enforce byte accesses for the not-packed structs as well, as theese might be accessed through a not sufficiently aligned pointer. So the status_reg pointer is in a completely unrelated (to the packed struct) u32 * and still the access is done like it was packed. If the compiler silently drags that attribute along into the u32 * THAT is really sick! We do agree on this statement. GCC on ARM is a strange beast. 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 whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts. - Bertrand Russell ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SD card on the GuruPlug
Hi, Prafulla Wadaskar prafu...@marvell.com writes: On guruplug+ if the uSD cards are inserted on both the slots (internal and external) The USB storage does not gets detected. Yes, I figured out. I’m preparing a patch that adds support for multi-LUN USB mass storage devices. Thanks, Ludo’. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] denx/master is not building for OMAP3 platforms except Beagle
On 2010/10/04 8:00 AM, Heiko Schocher wrote: Hello Hiremath, Hiremath, Vaibhav wrote: Hi All, I think the current denx/matser is broken and is not building up for OMAP3 platforms except Beagle board. but they should compile if you define CONFIG_SYS_ARM_WITHOUT_RELOC or compile with: CONFIG_SYS_ARM_WITHOUT_RELOC=1 ./MAKEALL board But be aware, this option wil be removed ... bye, Heiko For what it is worth, would it be possible to have a more verbose error message that actually provides a reference to what needs to be done, rather than simply failing with an obscure message about DRAM configuration? I ended up bisecting the tree to find the commit, and suitable references for what needs to be done to get a board working again, after searching git log -p for SDRAM got me nowhere. Surely having e.g. #if (not fixed config) #error See http://blah/blah/blah for information about how to fix your board #endif would be more beneficial than an obscure compiler failure that doesn't even reference useful keywords? Regards, Rogan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] hmi1001, mucmc52, uc100, uc101: move boards to vendor directory
Dear Wolfgang Denk,
In message 1282133657-28368-1-git-send-email...@denx.de you wrote:
Signed-off-by: Wolfgang Denk w...@denx.de
Cc: Heiko Schocher h...@denx.de
Cc: Stefan Roese s...@denx.de
Cc: Roderik Wildenburg roderik.wildenb...@manroland.com
---
board/{ = manroland}/hmi1001/Makefile |0
board/{ = manroland}/hmi1001/config.mk |0
board/{ = manroland}/hmi1001/hmi1001.c |0
board/{ = manroland}/mucmc52/Makefile |0
board/{ = manroland}/mucmc52/config.mk |0
board/{ = manroland}/mucmc52/mucmc52.c |0
board/{ = manroland}/uc100/Makefile |0
board/{ = manroland}/uc100/config.mk|0
board/{ = manroland}/uc100/pcmcia.c |0
board/{ = manroland}/uc100/u-boot.lds |0
board/{ = manroland}/uc100/u-boot.lds.debug |0
board/{ = manroland}/uc100/uc100.c |0
board/{ = manroland}/uc101/Makefile |0
board/{ = manroland}/uc101/config.mk|0
board/{ = manroland}/uc101/uc101.c |0
boards.cfg |8
16 files changed, 4 insertions(+), 4 deletions(-)
rename board/{ = manroland}/hmi1001/Makefile (100%)
rename board/{ = manroland}/hmi1001/config.mk (100%)
rename board/{ = manroland}/hmi1001/hmi1001.c (100%)
rename board/{ = manroland}/mucmc52/Makefile (100%)
rename board/{ = manroland}/mucmc52/config.mk (100%)
rename board/{ = manroland}/mucmc52/mucmc52.c (100%)
rename board/{ = manroland}/uc100/Makefile (100%)
rename board/{ = manroland}/uc100/config.mk (100%)
rename board/{ = manroland}/uc100/pcmcia.c (100%)
rename board/{ = manroland}/uc100/u-boot.lds (100%)
rename board/{ = manroland}/uc100/u-boot.lds.debug (100%)
rename board/{ = manroland}/uc100/uc100.c (100%)
rename board/{ = manroland}/uc101/Makefile (100%)
rename board/{ = manroland}/uc101/config.mk (100%)
rename board/{ = manroland}/uc101/uc101.c (100%)
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
As the system comes up, the component builders will from time to time
appear, bearing hot new versions of their pieces -- faster, smaller,
more complete, or putatively less buggy. The replacement of a working
component by a new version requires the same systematic testing pro-
cedure that adding a new component does, although it should require
less time, for more complete and efficient test cases will usually be
available. - Frederick Brooks Jr., The Mythical Man Month
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] MIPS relocation?
Dear Shinya Kuribayashi, with all the discussion about relocation on ARM going on, Heiko and me wondered if we had similar problems on MIPS. Unfortunately don't we have to any MIPS board that could be used for testing. Could you please tru and check if the current top-of-tree version of U-Boot still works on MIPS systems? Please check especially if the new environment commands work, i. e. please try out: printenvversus env print saveenv versus env save Thanks in advance! 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 When all is said and done, more is said than done. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] packed attribute problem
On 10/4/2010 3:47 PM, Wolfgang Denk wrote:
Dear Vipin Kumar,
Dear Wolfgang
In message 4ca9a095.9000...@st.com you wrote:
I encountered a problem something like
struct xyz {
int x;
int y;
int z[CONST];
} __attribute__ ((packed));
struct xyz *abc;
u32 * status_reg = (u32 *)abc-z[0];
writel(status, status_reg);
This writel results in writing byte by byte on the address pointed to by
status_reg.
This problem is visible with both gcc version 4.4.1 as well as 4.5.0
I bet this is on some ARM system?
Yes, it is on an ARM system (CortexA9). But I still feel that since I am
creating
a new u32 * status_reg, the code should not use any intelligence and use the
pointer
only to produce an str instruction in the form
str r0, [r1]
But it retains the packed property of the structure even with a new u32 ponter
typecasted to u32 *
u32 * status_reg = (u32 *)xyz-x;
A writel to status_reg results in byte by byte writing
Incidently, the same code works well with 4.2.4
...which surprises me. I thought this has always been an ARM
feature.
The problem is visible in the usb host driver which uses the packed
structures for
accessing device registers.
Hm... Why do these structs have any __attribute__ ((packed)) at all?
Even I could not understand that very well
Regards
Vipin
Best regards,
Wolfgang Denk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] packed attribute problem
Dear Balau,
In message aanlktik6fcn-n+4ig0vv67t7rvsatb16=27qya8d6...@mail.gmail.com you
wrote:
The compiler (4.4.1) generates the expected 32bit store instruction when
using:
struct p {
int n;
} __attribute__ ((packed, aligned(4)));
Confirmed. Thanks for pointing this out.
In case of hardware registers, I have yet to see a case where this is not
true.
Indeed, sounds as if this was a solution in case the packed should
really be needed - which I seriously doubt.
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
Objects in mirror are closer than they appear.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 2/2] APM821xx: Add bluestone board support
On Tuesday 28 September 2010 23:15:21 tma...@apm.com wrote: 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. Applied to u-boot-ppc4xx/master. Thanks. 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] ppc4xx: Remove some testing hacks from ppc4xx.h
On Wednesday 29 September 2010 17:23:17 Stefan Roese wrote: I accidentally left these hacks in the code while doing the big header cleanup. Let's remove it now. Applied to u-boot-ppc4xx/master. Thanks. 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 v1] ppc44x: config GPIOs for USB on canyonlands board
On Friday 01 October 2010 11:01:28 Rupjyoti Sarmah wrote: The GPIO 16 and 19 reconfiguration should be done once USB is initialized. So moved the reconfiguration to the USB init function. Applied to u-boot-ppc4xx/master. Thanks. 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] ppc4xx: Use common ns16550 functions in 4xx UART POST driver
On Wednesday 29 September 2010 17:23:03 Stefan Roese wrote: This patch changes the PPC4xx POST UART driver to use the common NS16550 functions for receiving and sending. Additionally the local function for SoC divisor setup are removed. Instead the functions from arch/powerpc/cpu/ppc4xx/4xx_uart.c are used. This removes code duplication. Also the common CONFIG_SYS_NS16550_COMx defines are now used to describe the POST UART's. And a compile breakage is fixed, introduced by a git merge of the ppc4xx/next branch into master. Now ppc4xx.h is moved to asm/ppc4xx.h. Fixed as well with this patch. Applied to u-boot-ppc4xx/master. Thanks. 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] packed attribute problem
Dear Vipin Kumar, In message 4ca9acaa.2020...@st.com you wrote: This writel results in writing byte by byte on the address pointed to by status_reg. This problem is visible with both gcc version 4.4.1 as well as 4.5.0 I bet this is on some ARM system? Yes, it is on an ARM system (CortexA9). But I still feel that since I am creating a new u32 * status_reg, the code should not use any intelligence and use the pointer only to produce an str instruction in the form str r0, [r1] But it retains the packed property of the structure even with a new u32 ponter typecasted to u32 * u32 * status_reg = (u32 *)xyz-x; A writel to status_reg results in byte by byte writing I agree with you. I always considered such behaviour of the ARM C compiler a bug, and still do. However, people with better knowledge of the ARm architecture than me might be able to explain why the responsible PTB consider this to be a good and necessary feature of th compiler. Hm... Why do these structs have any __attribute__ ((packed)) at all? Even I could not understand that very well Eventually alignment of these structs cannot be guaranteed? 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 PLEASE NOTE: Some Quantum Physics Theories Suggest That When the Con- sumer Is Not Directly Observing This Product, It May Cease to Exist or Will Exist Only in a Vague and Undetermined State. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] packed attribute problem
On 10/4/2010 4:26 PM, Reinhard Meyer wrote: Dear Wolfgang Denk, Vipin Kumar, In message 4ca9acaa.2020...@st.com you wrote: This writel results in writing byte by byte on the address pointed to by status_reg. This problem is visible with both gcc version 4.4.1 as well as 4.5.0 I bet this is on some ARM system? Yes, it is on an ARM system (CortexA9). But I still feel that since I am creating a new u32 * status_reg, the code should not use any intelligence and use the pointer only to produce an str instruction in the form str r0, [r1] But it retains the packed property of the structure even with a new u32 ponter typecasted to u32 * u32 * status_reg = (u32 *)xyz-x; A writel to status_reg results in byte by byte writing How do you know that? Disassembly? Bus snooping? Disassembly I agree with you. I always considered such behaviour of the ARM C compiler a bug, and still do. However, people with better knowledge of the ARm architecture than me might be able to explain why the responsible PTB consider this to be a good and necessary feature of th compiler. Maybe because writel(v,a) is ultimately defined as (*(volatile unsigned int *)(a) = (v)) and the compiler has to assume the worst, i.e. that (a) is not word aligned? Maybe there is a new compiler switch to turn that pessimisation off? I agree with you on this. But if I create a new u32 pointer and point to an element with in the packed structure, then what should be the behavior ? On the other hand, if what you say were true, all code for AT91 that uses writel() to access 32 bit only peripheral registers would not work with those newer toolchains (still 4.2.4 here). Yes, if the at91 code is using packed attribute for device structures Regards Vipin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MIPS relocation?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Wolfgang Denk since my board (Ben NanoNote) is mips. so I test the those commands in my board. printenv, saveenv: works fine. env print, evn save: make U-Boot hang. (then I must reset the board) - -- my board patch never touch the common/ folder. if I have time I will try to debug. On 10/04/2010 09:03 PM, Wolfgang Denk wrote: Dear Shinya Kuribayashi, with all the discussion about relocation on ARM going on, Heiko and me wondered if we had similar problems on MIPS. Unfortunately don't we have to any MIPS board that could be used for testing. Could you please tru and check if the current top-of-tree version of U-Boot still works on MIPS systems? Please check especially if the new environment commands work, i. e. please try out: printenvversus env print saveenv versus env save Thanks in advance! Best regards, Wolfgang Denk - -- Best Regards Xiangfu Liu http://www.openmobilefree.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyp6DEACgkQRRAEFRxkgLTylQCgkZjmI5Tn3q70/3Lr+NkArWsC HIkAoInQvU3P/PU1N2CWJML9RKfFE9+h =0LVF -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MIPS relocation?
Hello Xiangfu,
Xiangfu Liu wrote:
Hi Wolfgang Denk
since my board (Ben NanoNote) is mips.
so I test the those commands in my board.
printenv, saveenv: works fine.
env print, evn save: make U-Boot hang. (then I must reset the board)
as I thought ... can you try following patch:
From 276bcedbd581b11665a5424b274ae30d07245e1f Mon Sep 17 00:00:00 2001
From: Heiko Schocher h...@denx.de
Date: Mon, 4 Oct 2010 10:28:58 +0200
Subject: [PATCH] env: fix cmd_env_sub fct pointers if CONFIG_RELOC_FIXUP_WORKS
is not defined
commit ea882baf9c17cd142c99e3ff640d3ab01daa5cec introduces
a command_sub_table for the env command. On arm, avr32, m68k,
mips and sparc architectures, relocation needs manual fixups,
so add this for this sub command table too.
Tested on the qong board.
Signed-off-by: Heiko Schocher h...@denx.de
---
common/cmd_nvedit.c |6 ++
common/env_common.c |5 +
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index c3d63b8..16f5fb0 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -837,6 +837,12 @@ static cmd_tbl_t cmd_env_sub[] = {
U_BOOT_CMD_MKENT(set, CONFIG_SYS_MAXARGS, 0, do_env_set, , ),
};
+#if !defined(CONFIG_RELOC_FIXUP_WORKS)
+void env_reloc(void) {
+ fixup_cmdtable(cmd_env_sub, ARRAY_SIZE(cmd_env_sub));
+}
+#endif
+
static int do_env (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
cmd_tbl_t *cp;
diff --git a/common/env_common.c b/common/env_common.c
index a415ef8..88f068c 100644
--- a/common/env_common.c
+++ b/common/env_common.c
@@ -227,6 +227,11 @@ int env_import(const char *buf, int check)
void env_relocate (void)
{
+#if !defined(CONFIG_RELOC_FIXUP_WORKS)
+ extern void env_reloc(void);
+
+ env_reloc();
+#endif
if (gd-env_valid == 0) {
#if defined(CONFIG_ENV_IS_NOWHERE) /* Environment not changable */
set_default_env(NULL);
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] packed attribute problem
Dear Wolfgang Denk, Vipin Kumar, In message 4ca9acaa.2020...@st.com you wrote: This writel results in writing byte by byte on the address pointed to by status_reg. This problem is visible with both gcc version 4.4.1 as well as 4.5.0 I bet this is on some ARM system? Yes, it is on an ARM system (CortexA9). But I still feel that since I am creating a new u32 * status_reg, the code should not use any intelligence and use the pointer only to produce an str instruction in the form str r0, [r1] But it retains the packed property of the structure even with a new u32 ponter typecasted to u32 * u32 * status_reg = (u32 *)xyz-x; A writel to status_reg results in byte by byte writing How do you know that? Disassembly? Bus snooping? I agree with you. I always considered such behaviour of the ARM C compiler a bug, and still do. However, people with better knowledge of the ARm architecture than me might be able to explain why the responsible PTB consider this to be a good and necessary feature of th compiler. Maybe because writel(v,a) is ultimately defined as (*(volatile unsigned int *)(a) = (v)) and the compiler has to assume the worst, i.e. that (a) is not word aligned? Maybe there is a new compiler switch to turn that pessimisation off? On the other hand, if what you say were true, all code for AT91 that uses writel() to access 32 bit only peripheral registers would not work with those newer toolchains (still 4.2.4 here). Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/19] x86: zboot update
Hello.
On 04-10-2010 7:37, Graeme Russ wrote:
The header of recent Linux Kernels includes the size of the image, and
therefore is not needed to be passed to zboot. Still process the third
parameter (size of image) in the event that an older kernel is being loaded
Signed-off-by: Graeme Russgraeme.r...@gmail.com
[...]
diff --git a/arch/i386/lib/zimage.c b/arch/i386/lib/zimage.c
index 89fe015..f279b43 100644
--- a/arch/i386/lib/zimage.c
+++ b/arch/i386/lib/zimage.c
[...]
@@ -256,10 +257,17 @@ int do_zboot (cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
/* Setup board for maximum PC/AT Compatibility */
setup_pcat_compatibility();
- /* argv[1] holds the address of the bzImage */
- bzImage_addr = (void *)simple_strtoul(argv[1], NULL, 16);
+ if (argc= 2) {
+ /* argv[1] holds the address of the bzImage */
+ bzImage_addr = (void *)simple_strtoul(argv[1], NULL, 16);
+ } else {
+ s = getenv(fileaddr);
+ if (s)
+ bzImage_addr = (void *)simple_strtoul(s, NULL, 16);
+ }
Why not:
+ if (argc = 2)
+ /* argv[1] holds the address of the bzImage */
+ s = argv[1];
+ else
+ s = getenv(fileaddr);
+
+ if (s)
+ bzImage_addr = (void *)simple_strtoul(s, NULL, 16);
WBR, Sergei
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] packed attribute problem
Hi All,
I encountered a problem something like
struct xyz {
int x;
int y;
int z[CONST];
} __attribute__ ((packed));
struct xyz *abc;
u32 * status_reg = (u32 *)abc-z[0];
writel(status, status_reg);
This writel results in writing byte by byte on the address pointed to by
status_reg.
This problem is visible with both gcc version 4.4.1 as well as 4.5.0
Incidently, the same code works well with 4.2.4
The problem is visible in the usb host driver which uses the packed structures
for
accessing device registers.
Regards
Vipin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/19] x86: Move ECC initialisation outside RAM initialisation
Hello. On 04-10-2010 7:37, Graeme Russ wrote: To allow for 'load anywhere' images, the %ebp return pointer 'hack' must be removed, so we cannot have two 'calls' to get_mem_size Signed-off-by: Graeme Russgraeme.r...@gmail.com [...] diff --git a/arch/i386/cpu/start.S b/arch/i386/cpu/start.S index cb47ce7..9e6e0bf 100644 --- a/arch/i386/cpu/start.S +++ b/arch/i386/cpu/start.S @@ -93,6 +93,17 @@ mem_init_ret: jmp get_mem_size get_mem_size_ret: +#if CONFIG_SYS_SDRAM_ECC_ENABLE + /* Skip ECC initialization if not starting from cold-reset */ + movl%ebx, %ecx + andl$GD_FLG_COLD_BOOT, %ecx + jz ecc_init_ret But the label you added is called 'init_ecc_ret'. Are you sure the name is correct here? + mov $init_ecc_ret, %ebp + jmp init_ecc + +init_ecc_ret: +#endif + /* Check we have enough memory for stack */ movl$CONFIG_SYS_STACK_SIZE, %ecx cmpl%ecx, %eax WBR, Sergei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] AT91 clock and timer cleanups
Dear Wolfgang Denk, I see the misunderstanding here: It will be needed to replace the #if defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9XE) in global_data.h and a ton of similar ocurrences like these: That does not exist yet (its only in my local tree so far!) arch/arm/cpu/arm926ejs/at91/clock.c:#if defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9M10G45) arch/arm/cpu/arm926ejs/at91/clock.c:#elif defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9M10G45) Careful here, the ones here are distinguishing between different family members! See the abundance of #elif's there! The actual example code: #if defined(CONFIG_AT91RM9200) /* mdiv */ gd-mck_rate_hz = freq / (1 + ((mckr AT91_PMC_MCKR_MDIV_MASK) 8)); #elif defined(CONFIG_AT91SAM9G20) /* mdiv ; (x 7) = ((x 8) * 2) */ gd-mck_rate_hz = (mckr AT91_PMC_MCKR_MDIV_MASK) ? freq / ((mckr AT91_PMC_MCKR_MDIV_MASK) 7) : freq; if (mckr AT91_PMC_MCKR_MDIV_MASK) freq /= 2; /* processor clock division */ #elif defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9M10G45) gd-mck_rate_hz = (mckr AT91_PMC_MCKR_MDIV_MASK) == (AT91_PMC_MCKR_MDIV_2 | AT91_PMC_MCKR_MDIV_4) ? freq / 3 : freq / (1 ((mckr AT91_PMC_MCKR_MDIV_MASK) 8)); #else gd-mck_rate_hz = freq / (1 ((mckr AT91_PMC_MCKR_MDIV_MASK) 8)); #endif Note: I did not write that code, and I am sure it could be made to look less obfuscated. But that's not my problem right now. I looked at common.h which is already overcrowded by arch and even board specifics. I don't want to add anything there. In my tree I have solved the issue as follows: 1. The board's config file defines CONFIG_AT91FAMILY like this: /* SoC */ #define CONFIG_ARM926EJS1 /* ARM926EJS Core */ #define CONFIG_AT91FAMILY 1 /* it's a member of AT91 */ #define CONFIG_AT91SAM9260 1 /* Atmel AT91SAM9260 based SoC */ #define CONFIG_AT91SAM9XE 1 /* more specific: AT91SAM9XE */ 2. both at91 clock.c and timer.c contain the statements: #if !defined(CONFIG_AT91FAMILY) # error You need to define CONFIG_AT91FAMILY in your board config! #endif This will catch all boards that are affected. Since all ARM/AT91 boards are broken right now anyway and need fixing their config file that should work fine. 3. arm/global_data.h has now: ... #endif #ifdef CONFIG_AT91FAMILY /* static data needed by at91's clock.c */ unsigned long cpu_clk_rate_hz; unsigned long main_clk_rate_hz; unsigned long mck_rate_hz; unsigned long plla_rate_hz; unsigned long pllb_rate_hz; unsigned long at91_pllb_usb_init; /* static data needed by at91's timer.c */ unsigned long timer_rate_hz; unsigned long tbl; unsigned long tbu; unsigned long long timer_reset_value; #endif #if !defined(CONFIG_SYS_ARM_WITHOUT_RELOC) ... I can now post this as a patch. Best Regards Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MIPS relocation?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Heiko
by applied this patch. both works fine.
On 10/04/2010 10:49 PM, Heiko Schocher wrote:
Hello Xiangfu,
Xiangfu Liu wrote:
Hi Wolfgang Denk
since my board (Ben NanoNote) is mips.
so I test the those commands in my board.
printenv, saveenv: works fine.
env print, evn save: make U-Boot hang. (then I must reset the board)
as I thought ... can you try following patch:
From 276bcedbd581b11665a5424b274ae30d07245e1f Mon Sep 17 00:00:00 2001
From: Heiko Schocher h...@denx.de
Date: Mon, 4 Oct 2010 10:28:58 +0200
Subject: [PATCH] env: fix cmd_env_sub fct pointers if
CONFIG_RELOC_FIXUP_WORKS is not defined
commit ea882baf9c17cd142c99e3ff640d3ab01daa5cec introduces
a command_sub_table for the env command. On arm, avr32, m68k,
mips and sparc architectures, relocation needs manual fixups,
so add this for this sub command table too.
Tested on the qong board.
Signed-off-by: Heiko Schocher h...@denx.de
---
common/cmd_nvedit.c |6 ++
common/env_common.c |5 +
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index c3d63b8..16f5fb0 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -837,6 +837,12 @@ static cmd_tbl_t cmd_env_sub[] = {
U_BOOT_CMD_MKENT(set, CONFIG_SYS_MAXARGS, 0, do_env_set, , ),
};
+#if !defined(CONFIG_RELOC_FIXUP_WORKS)
+void env_reloc(void) {
+ fixup_cmdtable(cmd_env_sub, ARRAY_SIZE(cmd_env_sub));
+}
+#endif
+
static int do_env (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
cmd_tbl_t *cp;
diff --git a/common/env_common.c b/common/env_common.c
index a415ef8..88f068c 100644
--- a/common/env_common.c
+++ b/common/env_common.c
@@ -227,6 +227,11 @@ int env_import(const char *buf, int check)
void env_relocate (void)
{
+#if !defined(CONFIG_RELOC_FIXUP_WORKS)
+ extern void env_reloc(void);
+
+ env_reloc();
+#endif
if (gd-env_valid == 0) {
#if defined(CONFIG_ENV_IS_NOWHERE) /* Environment not changable */
set_default_env(NULL);
- --
Best Regards
Xiangfu Liu
http://www.openmobilefree.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkyp7I4ACgkQRRAEFRxkgLR/RACgmpYBqc74PeMT3DkngPy9zuD6
bAMAoISoyBKy4A1B3aTmLdg0hFsLRYMS
=hr/V
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM relocation, question to Heiko
Le 04/10/2010 16:25, Rogan Dawes a écrit : On 2010/10/04 4:17 PM, Albert ARIBAUD wrote: At this point I have an ARM926, ELF-relocating, u-boot reaching prompt. Environment is correctly read and can be modified (did not try saving though). Flash operations work (flinfo, erase, cp.b). Ethernet does not work, however -- ping or tftp just wait without me being able to ^C it. I'll look into that as soon as some domestic chores are done. :) Excellent work! Congratulations! Thanks, but I'd suggest to wait for congrats until ethernet works -- tough I've got a clue, I think; it may have to do with the core activating its caches and the driver doing DMA. :) Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM relocation, question to Heiko
On 10/4/2010 3:13 AM, Wolfgang Denk wrote: Dear Albert ARIBAUD, In message4ca999ee.5030...@free.fr you wrote: Note however that linking for base address 0 is not mandatory for achieving true position independence. What is required is that the code which runs from power-up until relocation be able to run anywhere, i.e., this code should not require any relocation fixup. That can be achieved on ARM by using only relative branches and accessing data only relative to pc (e.g. literals) or truly absolute (e.g. HW registers etc). That means you need to build all of U-Boot that way, because significant parts of the code already run before relocation (including all clocks and timers setup, console setup, printf and all routines these pull in). Yes, I think Wolfgang is correct. This is not going to be easy to do in general. To run anywhere, the code must be true Position Independent code. If you intend to use any C code in the initialization, this will result in needing -fPIC for at least that code. I am not sure you can mix -fPIC and non -fPIC code in the same link, but I expect not. I am a bit surprised that it is possible to get even the initialization code to be Position Independent, but it appears that on at least some PPC it is possible/has been done. On a related topic, I did find some information on the -mrelocatable history. Take a look at http://www.mail-archive.com/g...@gcc.gnu.org/msg02528.html. If you read both thread entries, it explains -mrelocatable as more or less the post-processor that re-formats the ELF relocation information into a smaller format and puts it in the text as another segment. What Albert is doing now, and Graeme did before, is the first option, creating a loader that understands ELF. This has the advantage that it will work on all architectures. However, once this understanding is in place, it would be easy to write a small post-processing program that would reduce the size of the relocation entries, much like -mrelocatable does. This may or may not be necessary, but it is certainly possible. Best Regards, Bill Campbell Best regards, Wolfgang Denk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM (was: MIPS) relocation?
Dear Heiko Schocher, printenv, saveenv: works fine. env print, evn save: make U-Boot hang. (then I must reset the board) as I thought ... can you try following patch: Not surprisingly, it makes env subcommands work on ARM/AT91, too:) Thanks, Reinhard PS: I still get the *** Warning - bad CRC, using default environment when relocation is on :( - of course that is a different issue from command handling... Since the env is read before relocation, I must investigate further there. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM relocation, question to Heiko
Le 04/10/2010 17:28, J. William Campbell a écrit : On 10/4/2010 3:13 AM, Wolfgang Denk wrote: Dear Albert ARIBAUD, In message4ca999ee.5030...@free.fr you wrote: Note however that linking for base address 0 is not mandatory for achieving true position independence. What is required is that the code which runs from power-up until relocation be able to run anywhere, i.e., this code should not require any relocation fixup. That can be achieved on ARM by using only relative branches and accessing data only relative to pc (e.g. literals) or truly absolute (e.g. HW registers etc). That means you need to build all of U-Boot that way, because significant parts of the code already run before relocation (including all clocks and timers setup, console setup, printf and all routines these pull in). Yes, I think Wolfgang is correct. This is not going to be easy to do in general. To run anywhere, the code must be true Position Independent code. If you intend to use any C code in the initialization, this will result in needing -fPIC for at least that code. I am not sure you can mix -fPIC and non -fPIC code in the same link, but I expect not. I am a bit surprised that it is possible to get even the initialization code to be Position Independent, but it appears that on at least some PPC it is possible/has been done. I'm not entirely sure about -fPIC, but it is possible indeed that true position independence might need it. For the moment, I'll settle for ELF relocatable. :) On a related topic, I did find some information on the -mrelocatable history. Take a look at http://www.mail-archive.com/g...@gcc.gnu.org/msg02528.html. If you read both thread entries, it explains -mrelocatable as more or less the post-processor that re-formats the ELF relocation information into a smaller format and puts it in the text as another segment. What Albert is doing now, and Graeme did before, is the first option, creating a loader that understands ELF. This has the advantage that it will work on all architectures. However, once this understanding is in place, it would be easy to write a small post-processing program that would reduce the size of the relocation entries, much like -mrelocatable does. This may or may not be necessary, but it is certainly possible. Best Regards, Bill Campbell Thanks Bill. I'll look into it once I get the current issues resolved; however it seems GOT-related, and -pie is not GOT-based -- and unlike GOT, -pie handles pointers in data, for instance, removing the need for manual fixups. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] DDR SPD table
On Monday, October 04, 2010 09:02:26 sywang wrote: Do you have the general materials about DDR programming in u-boot? do not hijack threads. start your own. -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] Add new NAND flash
On Sat, 2 Oct 2010 14:50:23 +0200 Matthias Weißer weiss...@arcor.de wrote: Hi Scott Am 01.10.2010 21:52, schrieb Scott Wood: On Fri, 1 Oct 2010 16:31:40 +0200 MT29F16G08CBABA The NAND is connected (8 bit wide) to an iMX25 which is booting from NOR. So the NAND is only a mass storage device. I am able to read the ID of the chip. 2Ch 48h 04h 46h 85h According to http://patchwork.ozlabs.org/patch/60042/, this chip is supposed to have ID: 2C 48 00 26 89 Take a closer look at the table in the link. There is a MT29F16G08ABABA with ID: 2C 48 00 26 89 and a MT29F16G08CBABA with ID: 2C 48 04 46 85. The second one is the one I have here. Ah, misread the part name. I have also a datasheet of the chip here from where I copy pasted the above ID. The ID gets read correctly from the chip by u-boot NAND subsystem. Does the datasheet say anything about what it intends that bit to mean? Is there a new ID format we need to support? Do you have a datasheet that says what it's supposed to be? The bytes may be getting corrupted. If you hack up the code to override the ID bytes with good ones, do you see any problems doing real I/O? I tried that. If I run a nand bad command then it never returns and keeps performing some actions on the NAND device as I can see with an oscilloscope. Could you instrument the code to see what software thinks it's doing? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM relocation, question to Heiko
On Monday 04 October 2010 17:24:09 Albert ARIBAUD wrote: Excellent work! Congratulations! Thanks, but I'd suggest to wait for congrats until ethernet works -- tough I've got a clue, I think; it may have to do with the core activating its caches and the driver doing DMA. :) Yes. Very likely a aching problem and not an relocation issue. With D-cache enabled some IO drivers might have some problems. This will also be a problem with for example USB support. 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/2] USB: Make non-bulk delay longer in OHCI
Dear Marek Vasut, In message 201010041602.04183.marek.va...@gmail.com you wrote: How do you expoect this to work? You did NOT add him to the Cc: list. ... I added him to CC in mail ... what else do you expect? The message I received through the list did not contain any such Cc: | Subject: Re: [U-Boot] [PATCH 1/2] USB: Make non-bulk delay longer in OHCI | From: Marek Vasut marek.va...@gmail.com | Date: Mon, 4 Oct 2010 01:36:27 +0200 | To: u-boot@lists.denx.de | Cc: wd...@denx.de But I ran into a similar issue myself today. Dunno what happens... 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 Microsoft Multitasking: several applications can crash at the same time. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] ARM relocation, board_init() now called AFTER relocation
Hello, before the relocation patches, and if relocation is disabled (CONFIG_SYS_ARM_WITHOUT_RELOC) board_init() is called _very_ early, before relocation. With relocation enabled, board_init() is called after relocation and when BSS is available. --- Board maintainers should look at their board_init() and check that they do not do early init stuff there. Most AT91 boards, as I can see do high level inits (requiring bss), which is NOW ok to do (with relocation) and actually was WRONG before that. (Or you might say, board_init() was until now called in the wrong place) Reinhard PS: realizing that solved my ENV READ CRC issue ;) - the GPIO pins were initialized in board_init() which is too late now. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] AT91 clock and timer cleanups
Dear Reinhard Meyer, In message 4ca9eb88.5000...@emk-elektronik.de you wrote: 1. The board's config file defines CONFIG_AT91FAMILY like this: /* SoC */ #define CONFIG_ARM926EJS 1 /* ARM926EJS Core */ #define CONFIG_AT91FAMILY 1 /* it's a member of AT91 */ #define CONFIG_AT91SAM92601 /* Atmel AT91SAM9260 based SoC */ #define CONFIG_AT91SAM9XE 1 /* more specific: AT91SAM9XE */ Out of principle: please omit the 1 in all such cases unless you really want to pass or test for such a numeric value anywhere. As far as I can tell all relevant code uses only #ifdef or defined(...), so not to confuse people better omit the irrelevant value. 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 Hiring experienced unix people is like a built-in filter against idiots. Hiring experienced NT people provides no such guarantee. -- Miguel Cruz in wgl96.349$cc.122...@typhoon2.ba-dsg.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MIPS relocation?
Dear Xiangfu Liu, In message 4ca9ec8e.9080...@openmobilefree.net you wrote: by applied this patch. both works fine. Thanks a lot for testing. This confirms that we have a more global issue here, i. e. not only ARM is affected, but also MIPS. Any MIPS tool chain experts out there to try and follow-up for MIPS what Albert is doing for ARM right now? 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 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM relocation, question to Heiko
On Monday, October 4, 2010, Wolfgang Denk w...@denx.de wrote: Dear Albert ARIBAUD, In message 4ca999ee.5030...@free.fr you wrote: Note however that linking for base address 0 is not mandatory for achieving true position independence. What is required is that the code which runs from power-up until relocation be able to run anywhere, i.e., this code should not require any relocation fixup. That can be achieved on ARM by using only relative branches and accessing data only relative to pc (e.g. literals) or truly absolute (e.g. HW registers etc). That means you need to build all of U-Boot that way, because significant parts of the code already run before relocation (including all clocks and timers setup, console setup, printf and all routines these pull in). Have a look at x86 - Relocation is performed at the first possible moment This made full relocation for x86 was relatively trivial :) Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM relocation, question to Heiko
Dear J. William Campbell, In message 4ca9f294.8080...@comcast.net you wrote: Yes, I think Wolfgang is correct. This is not going to be easy to do in general. To run anywhere, the code must be true Position Independent code. If you intend to use any C code in the initialization, this will result in needing -fPIC for at least that code. I am not sure you can mix -fPIC and non -fPIC code in the same link, but I expect not. I am a bit surprised that it is possible to get even the initialization code to be Position Independent, but it appears that on at least some PPC it is possible/has been done. Not really. On PowerPC, only the first 20 or 30 lines of assembler code in start.S are position independent; then we compute the link (resp. execution) address and branch to it. From then, we run from the very address range we were linked for (starting at TEXT_BASE). Albert is doing now, and Graeme did before, is the first option, creating a loader that understands ELF. This has the advantage that it will work on all architectures. However, once this understanding is in place, it would be easy to write a small post-processing program that would reduce the size of the relocation entries, much like -mrelocatable does. This may or may not be necessary, but it is certainly possible. Eventually we might even add -mrelocatable support for the other architectures to the tool chain. 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 Its always easier short term to pee in the pond than install a toilet - it's just not a good long term plan. - Alan Cox in 20100101145701.6432e...@lxorguk.ukuu.org.uk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM relocation, question to Heiko
Dear Graeme Russ, In message aanlktiknkfjuq6dmw3ey=0qiekim716e=1+3np3jg...@mail.gmail.com you wrote: That means you need to build all of U-Boot that way, because significant parts of the code already run before relocation (including all clocks and timers setup, console setup, printf and all routines these pull in). Have a look at x86 - Relocation is performed at the first possible moment This made full relocation for x86 was relatively trivial :) Well, U-Boot is not only a fancy boot loader, but also a hardware bringup tool. It was designed to make it as easy for the software guy to bring up code on new hardware. That means, that one of the very first things we always try to do is get a (usually serial) console port working, so we can use printf() to get some helpful information out. This happens especially before doing anythign that is known to be complicated and error prone, like especially the initialization of both the memory controller and the RAM system on the board. I am aware that there are systems out there which perform the RAM initialization either in hardware or for example table-driven by some built-in ROM boot loader code. Here RAM initalization is obviously not such an issue, but nevertheless there is a LOT of code running before we relocate the code to RAM. 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 glory of creation is in its infinite diversity. And in the way our differences combine to create meaning and beauty. -- Dr. Miranda Jones and Spock, Is There in Truth No Beauty?, stardate 5630.8 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] AT91 clock and timer cleanups
Dear Wolfgang Denk, In message4ca9eb88.5000...@emk-elektronik.de you wrote: 1. The board's config file defines CONFIG_AT91FAMILY like this: /* SoC */ #define CONFIG_ARM926EJS 1 /* ARM926EJS Core */ #define CONFIG_AT91FAMILY 1 /* it's a member of AT91 */ #define CONFIG_AT91SAM9260 1 /* Atmel AT91SAM9260 based SoC */ #define CONFIG_AT91SAM9XE1 /* more specific: AT91SAM9XE */ Out of principle: please omit the 1 in all such cases unless you really want to pass or test for such a numeric value anywhere. As far as I can tell all relevant code uses only #ifdef or defined(...), so not to confuse people better omit the irrelevant value. I agree here, and will change that whenever I encounter it in files I touch (most is copied from the atmel EK config file). I also see the tab vs. space issue once its quoted. I think a space after the #define is better. The general question, however was, if that approach is OK with you. Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request u-boot-blackfin.git
The following changes since commit 2e6e1772c0e34871769be4aef79748fe3e47d953: Merge branch 'next' of /home/wd/git/u-boot/next (2010-09-28 23:30:47 +0200) are available in the git repository at: git://www.denx.de/git/u-boot-blackfin.git master Mike Frysinger (34): Blackfin: add support for BF538/BF539 processors Blackfin: add support for BF51x parts Blackfin: bfin_spi: add optional DMA support Blackfin: bfin_sdh: clean up send_cmd Blackfin: unify gpio cfi implementations Blackfin: punt headers for non-existent BF541 Blackfin: bfin_mac: convert from old style MMR macros Blackfin: bf537-stamp: post: update old MMR style macros Blackfin: bf527-ezkit: video: convert from old style MMR macros Blackfin: bf548-ezkit: video: convert from old style MMR macros Blackfin: cm-bf548: video: convert from old style MMR macros Blackfin: bf527-ad7160-eval: convert from old style MMR macros Blackfin: punt old *p style volatile MMR defines Blackfin: bf537: unify arch header duplication Blackfin: bf52x: unify arch header duplication Blackfin: unify core MMRs Blackfin: bf533: merge headers Blackfin: bf561: merge headers Blackfin: move CONFIG_BFIN_CPU to board config.mk Blackfin: cmd_gpio: document/extend input sub-option Blackfin: adi config: add an all spi flashes option to unify board lists Blackfin: adi config: add a hook for boards to append the env Blackfin: bf527-sdp: new board port Blackfin: cmd_gpio: return gpio value to caller Blackfin: adi config: allow boards to tweak a little more Blackfin: adi config: enable nand lock/unlock support Blackfin: bf526-ezbrd: enable BootROM-OOB layout when booting from NAND Blackfin: cmd_gpio: accept upper case pin names Blackfin: propagate target cpu defines when building embedded env Blackfin: fix MMC init output alignment Blackfin: bf548-ezkit: bump SPI flash size up Blackfin: bf527-ad7160-eval: fix GPIO CS define Blackfin: bf537-pnav: increase monitor len Blackfin: otp: fix build after constification of args[] Peter Meerwald (2): Blackfin: support a 3rd gpio cfi pin Blackfin: bct-brettl2: new board port Wojtek Skulski (1): Blackfin: blackvme: new board port MAINTAINERS| 10 +- arch/blackfin/config.mk|7 +- arch/blackfin/cpu/cmd_gpio.c | 34 +- arch/blackfin/include/asm/blackfin_cdef.h | 19 +- arch/blackfin/include/asm/blackfin_def.h | 33 +- arch/blackfin/include/asm/config.h |5 - arch/blackfin/include/asm/dma.h| 75 + arch/blackfin/include/asm/mach-bf518/BF512_cdef.h | 1000 ++ arch/blackfin/include/asm/mach-bf518/BF512_def.h | 523 + arch/blackfin/include/asm/mach-bf518/BF514_cdef.h | 68 + arch/blackfin/include/asm/mach-bf518/BF514_def.h | 40 + arch/blackfin/include/asm/mach-bf518/BF516_cdef.h | 170 ++ arch/blackfin/include/asm/mach-bf518/BF516_def.h | 91 + arch/blackfin/include/asm/mach-bf518/BF518_cdef.h | 58 + arch/blackfin/include/asm/mach-bf518/BF518_def.h | 35 + arch/blackfin/include/asm/mach-bf518/anomaly.h | 158 ++ arch/blackfin/include/asm/mach-bf518/def_local.h |5 + arch/blackfin/include/asm/mach-bf518/gpio.h| 58 + arch/blackfin/include/asm/mach-bf518/portmux.h | 201 ++ arch/blackfin/include/asm/mach-bf518/ports.h | 59 + .../asm/mach-bf527/ADSP-EDN-BF52x-extended_cdef.h | 511 - .../asm/mach-bf527/ADSP-EDN-BF52x-extended_def.h |6 - arch/blackfin/include/asm/mach-bf527/BF522_cdef.h | 311 --- arch/blackfin/include/asm/mach-bf527/BF522_def.h | 101 - arch/blackfin/include/asm/mach-bf527/BF523_cdef.h | 342 + arch/blackfin/include/asm/mach-bf527/BF523_def.h | 124 +-- arch/blackfin/include/asm/mach-bf527/BF524_cdef.h | 480 - arch/blackfin/include/asm/mach-bf527/BF524_def.h | 101 - arch/blackfin/include/asm/mach-bf527/BF525_cdef.h | 849 + arch/blackfin/include/asm/mach-bf527/BF525_def.h | 293 +--- arch/blackfin/include/asm/mach-bf527/BF526_cdef.h | 559 -- arch/blackfin/include/asm/mach-bf527/BF526_def.h | 101 - arch/blackfin/include/asm/mach-bf527/BF527_cdef.h | 1086 +--- arch/blackfin/include/asm/mach-bf527/BF527_def.h | 372 + arch/blackfin/include/asm/mach-bf533/BF531_cdef.h | 862 - arch/blackfin/include/asm/mach-bf533/BF531_def.h | 428 - arch/blackfin/include/asm/mach-bf533/BF532_cdef.h | 15 +- arch/blackfin/include/asm/mach-bf533/BF532_def.h |6 +- arch/blackfin/include/asm/mach-bf533/BF533_cdef.h | 15 +- arch/blackfin/include/asm/mach-bf533/BF533_def.h |4 +- .../asm/mach-bf537/ADSP-EDN-BF534-extended_cdef.h | 1130 +--- .../asm/mach-bf537/ADSP-EDN-BF534-extended_def.h
Re: [U-Boot] AT91 clock and timer cleanups
Dear Reinhard Meyer, In message 4caa0bb1.7010...@emk-elektronik.de you wrote: I agree here, and will change that whenever I encounter it in files I touch (most is copied from the atmel EK config file). Thanks. The general question, however was, if that approach is OK with you. Well, I still prefer to have this added to a single, central location instead to a large number of board config files. However, if you have to touch all these board config files anyway (and accept the need to re-test on all affected boards) then I don't insist on any specific implementation. Please don't forget to document the new CONFOG_ variable (in the README). 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 Too much of anything, even love, isn't necessarily a good thing. -- Kirk, The Trouble with Tribbles, stardate 4525.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/2 v2] nand: allow delayed initialization
On Sat, 2 Oct 2010 15:47:20 -0400 Mike Frysinger vap...@gentoo.org wrote: +#ifdef CONFIG_SYS_NAND_DELAYED_INIT Seems like this should be CONFIG_ rather than CONFIG_SYS_. I'm wondering if we should just make this the default behavior. We already deferred the bad block scanning, perhaps this could replace that. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
