Re: [U-Boot-Users] Changing u-boot relocation scheme
On Fri, Jul 25, 2008 at 2:50 PM, Haavard Skinnemoen [EMAIL PROTECTED] wrote: Ok, I'll stop the chest-beating now. But please stop trying to tell people that adding a powerpc-specific option (which nobody seems to know how really works) to the command line will work on any other architectures than powerpc. You are completely right. For the purposes of this discussion, this is a powerpc-centric problem. The relocation code is written in assembly and is processor specific. Let the ARM folks make sure ARM relocation works (and I think it already does). Let the MIPS folks do the same. Each arch has it's own set of CFLAGS and LDFLAGS needed to produce a sane binary. They should be picked off and fixed one arch at a time. BTW, searching for assignments to reloc_off in the source will tell you which platforms are broken. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/1] Add support for ATMELAT91SAM9G20EKboard
[EMAIL PROTECTED] wrote: U-Boot already has too many preprocessor constants and the addition of another (perhaps) dubious one merits more debate. You omitted the context of this statement and hence most of its meaning. Haavard Skinnemoen wrote: I don't completely agree. U-Boot has too many #ifdefs, which isn't necessarily the same as too many #defines. And I don't think CONFIG_AT91 is dubious at all. Perhaps the CONFIG_* symbols should be defined as TRUE or FALSE rather than defined or not defined. I didn't say CONFIG_AT91 was dubious. I stated that defining CONFIG_SOMETHING where it isn't clear what SOMETHING should be is dubious. If one has to think too hard about what meaningful phrase SOMETHING should be, perhaps CONFIG_SOMETHING should not be defined at all. I'm complaining about defining new preprocessor definitions to be specific aggregations of other definitions just so a developer can type the conditions with fewer keystrokes without any improvement in code readability and maintainability. Sometimes an idiom should be left as an idiom rather than replaced by a preprocessor constant. I have nothing against defining CONFIG_AT91 if it is useful, unique and makes code that uses it easier to understand and maintain. But since we already have a CONFIG_AVR32 #define, we can clean up the mess in macb.c by simply reversing the logic. If CONFIG_AVR32 can be used in macb.c without ofuscation, why is CONFIG_AT91 needed here? However, simply reversing the logic may be too much ofuscation though; we want clear rather than clever code after all. An example of what I'd be opposed to is defining CONFIG_AT91SAM9260_OR_AT91SAM9263 where it is TRUE if either CONFIG_AT91SAM9260 or CONFIG_AT91SAM9263 are TRUE. Can you see where this might be used in the macb.c code? Sincerely, As I see it, CONFIG_AT91 would mean that you have a a certain class of peripherals which is developed for the AT91 range of processors (and is used by the AVR32 as well) The name is probably slightly misleading, but convenient. Not having this definition, will soon mean that you have statements like the following: #if defined(CONFIG_AT91RM9200) || \ defined(CONFIG_AT91SAM9260) || \ defined(CONFIG_AT91SAM9261) || \ defined(CONFIG_AT91SAM9263) || \ defined(CONFIG_AT91SAM9G10) || \ defined(CONFIG_AT91SAM9G15) || \ defined(CONFIG_AT91SAM9G20) || \ defined(CONFIG_AT91SAM9G41) || \ defined(CONFIG_AT91SAM9M10) || \ defined(CONFIG_AT91SAM9M11) || \ defined(CONFIG_AT91CAP9) || \ defined(CONFIG_AT572D940) This statement will have to be updated every time a new MCU is released. Having the statment #if defined(CONFIG_AT91) should definitely reduce the maintenance of drivers. Best Regards Ulf Samuelsson - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Changing u-boot relocation scheme
On Sat, 2008-07-26 at 07:36 +0200, Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: I know exactly what Grant did. But he is not using the elf relocation information as that is simply not included in the data that is the u-boot.bin file. So what? Is this a problem? Why would we need to use XXX if we can perform all we need to do by using YYY instead, especially if this is simpler to implement? The only reason would be to make all arch as similar as possible. The discussion would be totally retarded if we only though about powerpc since the problem is already solved and implemented. Also this discussion is more about doing it in a way that is not powerpc specific and documented, we already have as you mentioned code for the powerpc specific way but it's not using elf relocation information. Who says that we MUST use the ELF reloc info? The post I was replaying to indicated that the existing code already did this so I simply corrected that statement. Or why? If it turns out that is is not that complicated all architectures could do it in the same way. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Changing u-boot relocation scheme
On Sat, 2008-07-26 at 01:48 -0400, Grant Likely wrote: On Thu, Jul 24, 2008 at 2:09 PM, Kenneth Johansson [EMAIL PROTECTED] wrote: On Thu, 2008-07-24 at 10:37 -0700, vb wrote: But as you pointed out, this would work on ppc only (with a 'good' compiler), and still remains to be proven, I will get to it a bit later. I have run u-boot with everything compiled with -mrelocatable and normal relocation fixup code removed so I know it works fine. So consider it proven. But since it apparently is a problem in some situation the best is probably to make it a configuration option. Can you test against various versions of gcc? That is where I ran into trouble. Well If you have a specific version you know is not working I could test that. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] U-Boot-Users Digest, Vol 26, Issue 229
Dear All, I m new to U-Boot . Plz dont neglect me may be this a sily question but I want to know is U-Boot is using directly physical address or virtual address of a processor . plz reply this question . On 7/26/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Send U-Boot-Users mailing list submissions to u-boot-users@lists.sourceforge.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/u-boot-users or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than Re: Contents of U-Boot-Users digest... Today's Topics: 1. Re: Changing u-boot relocation scheme (Wolfgang Denk) 2. Re: Changing u-boot relocation scheme (Wolfgang Denk) 3. Re: Changing u-boot relocation scheme (Wolfgang Denk) 4. Re: Changing u-boot relocation scheme (Grant Likely) 5. Re: Changing u-boot relocation scheme (Grant Likely) 6. Re: Changing u-boot relocation scheme (vb) 7. Re: Changing u-boot relocation scheme (vb) 8. Re: Changing u-boot relocation scheme (Grant Likely) 9. Re: Changing u-boot relocation scheme (Grant Likely) -- Message: 1 Date: Sat, 26 Jul 2008 07:36:35 +0200 From: Wolfgang Denk [EMAIL PROTECTED] Subject: Re: [U-Boot-Users] Changing u-boot relocation scheme To: kenneth johansson [EMAIL PROTECTED] Cc: vb [EMAIL PROTECTED], u-boot-users@lists.sourceforge.net, Haavard Skinnemoen [EMAIL PROTECTED], Jerry Van Baren [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 In message [EMAIL PROTECTED] you wrote: I know exactly what Grant did. But he is not using the elf relocation information as that is simply not included in the data that is the u-boot.bin file. So what? Is this a problem? Why would we need to use XXX if we can perform all we need to do by using YYY instead, especially if this is simpler to implement? Also this discussion is more about doing it in a way that is not powerpc specific and documented, we already have as you mentioned code for the powerpc specific way but it's not using elf relocation information. Who says that we MUST use the ELF reloc info? Or why? I was afraid that what was needed was more or less a complete linker but it looks like if one generate the dynamic reloc table a much simpler linker(relocation function) is needed. Still probably a lot more complex than the GOT and fixup code that is just a loop over a table. We may need a case also ;-) Please re-read Grant's patch. There were NO changes to the existing simple code! Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] Murder is contrary to the laws of man and God. -- M-5 Computer, The Ultimate Computer, stardate 4731.3 -- Message: 2 Date: Sat, 26 Jul 2008 07:36:35 +0200 From: Wolfgang Denk [EMAIL PROTECTED] Subject: Re: [U-Boot-Users] Changing u-boot relocation scheme To: Haavard Skinnemoen [EMAIL PROTECTED] Cc: vb [EMAIL PROTECTED], u-boot-users@lists.sourceforge.net, Jerry Van Baren [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 In message [EMAIL PROTECTED] you wrote: Ok, I'll stop the chest-beating now. But please stop trying to tell people that adding a powerpc-specific option (which nobody seems to know how really works) to the command line will work on any other architectures than powerpc. OK - then please you explain exactly which other architectures have problems with relocation? 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: [EMAIL PROTECTED] I am more bored than you could ever possibly be. Go back to work. -- Message: 3 Date: Sat, 26 Jul 2008 07:36:35 +0200 From: Wolfgang Denk [EMAIL PROTECTED] Subject: Re: [U-Boot-Users] Changing u-boot relocation scheme To: Joakim Tjernlund [EMAIL PROTECTED] Cc: 'vb' [EMAIL PROTECTED], u-boot-users@lists.sourceforge.net, 'Haavard Skinnemoen' [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 In message [EMAIL PROTECTED]@transmode.se you wrote: I think the best bet is to make -mrelocatable work for PPC. Question is how does the other arches do it? Do they include fixup ptrs by default or do they
Re: [U-Boot-Users] [yes, i tried rtfming docs]u-boot on x86, how to?
Geraldo Netto a écrit : i tried the steps at http://www.denx.de/wiki/DULG/Manual but i was not able to make it work on x86 does anyone have any tip/doc(s) on how to make u-boot work on x86? i'd really appreciate that help :P Hello, You *might* get some help if you specify what exactly you tried, what succeeded, what did not succeed and what was the actual vs expected outcome of the unsuccessful step, including error messages. Amicalement, -- Albert. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/1] Add support for ATMELAT91SAM9G20EKboard
As I see it, CONFIG_AT91 would mean that you have a a certain class of peripherals which is developed for the AT91 range of processors (and is used by the AVR32 as well) The name is probably slightly misleading, but convenient. Not having this definition, will soon mean that you have statements like the following: #if defined(CONFIG_AT91RM9200) || \ defined(CONFIG_AT91SAM9260) || \ defined(CONFIG_AT91SAM9261) || \ defined(CONFIG_AT91SAM9263) || \ defined(CONFIG_AT91SAM9G10) || \ defined(CONFIG_AT91SAM9G15) || \ defined(CONFIG_AT91SAM9G20) || \ defined(CONFIG_AT91SAM9G41) || \ defined(CONFIG_AT91SAM9M10) || \ defined(CONFIG_AT91SAM9M11) || \ defined(CONFIG_AT91CAP9) || \ defined(CONFIG_AT572D940) This statement will have to be updated every time a new MCU is released. Having the statment #if defined(CONFIG_AT91) should definitely reduce the maintenance of drivers. I fully agree with Ulf, we need to have a better CONFIG, but I'm not sure that CONFIG_AT91 is the right one We have actually in the tree the following CPU CONFIG_AT91CAP9 CONFIG_AT91RM9200 CONFIG_AT91SAM9260 CONFIG_AT91SAM9261 CONFIG_AT91SAM9263 CONFIG_AT91SAM9RL and as mention Ulf are going to have more and more maybe we can use config related to the functionnality or the sub-class CPU ex : CONFIG_MACB_INCLK Best Regards, J. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Changing u-boot relocation scheme
On Sat, Jul 26, 2008 at 3:53 AM, kenneth johansson [EMAIL PROTECTED] wrote: On Sat, 2008-07-26 at 01:48 -0400, Grant Likely wrote: On Thu, Jul 24, 2008 at 2:09 PM, Kenneth Johansson [EMAIL PROTECTED] wrote: On Thu, 2008-07-24 at 10:37 -0700, vb wrote: But as you pointed out, this would work on ppc only (with a 'good' compiler), and still remains to be proven, I will get to it a bit later. I have run u-boot with everything compiled with -mrelocatable and normal relocation fixup code removed so I know it works fine. So consider it proven. But since it apparently is a problem in some situation the best is probably to make it a configuration option. Can you test against various versions of gcc? That is where I ran into trouble. Well If you have a specific version you know is not working I could test that. gcc 4.0 worked for me. Anything newer or older seemed to behave differently. Looking at the size of the .got and .fixup sections seems to be a good indication of if things are being placed correctly. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Changing u-boot relocation scheme
In message [EMAIL PROTECTED] you wrote: You are completely right. For the purposes of this discussion, this is a powerpc-centric problem. The relocation code is written in assembly and is processor specific. Let the ARM folks make sure ARM relocation works (and I think it already does). Let the MIPS folks do the same. Each arch has it's own set of CFLAGS and LDFLAGS needed to produce a sane binary. They should be picked off and fixed one arch at a time. Neither ARM nor MIPS do relocation. They link for a fixed address in RAM (which for example means that they cannot deal in a sane way with systems where the RAM size might change, not to mention issues with things like support for pRAM, pre-initialized framebuffers or shared log buffer which only work reasonably when you have relocation. 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: [EMAIL PROTECTED] This is now. Later is later. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Changing u-boot relocation scheme
In message [EMAIL PROTECTED] you wrote: Or why? If it turns out that is is not that complicated all architectures could do it in the same way. That would require that all architectures implementrelocation in the same way (or at all). Actually this is not the case. 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: [EMAIL PROTECTED] There you go man, Keep as cool as you can. It riles them to believe that you perceive the web they weave. Keep on being free! - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] U-Boot-Users Digest, Vol 26, Issue 229
In message [EMAIL PROTECTED] you wrote: I m new to U-Boot . Plz dont neglect me may be this a sily question but I Do not top post. Do not full quote. Do not hijack an unrelated subject. Use a descriptive subject. Do not post HTML. In other words: make sure to read http://catb.org/esr/faqs/smart-questions.html 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: [EMAIL PROTECTED] Where a calculator on the ENIAC is equipped with 18,000 vacuum tubes and weighs 30 tons, computers in the future may have only 1,000 vacuum tubes and weigh only 1/2 tons. - Popular Mechanics, March 1949 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] USB Uboot on OSK5912
On 16:46 Fri 25 Jul , Hunter, Jon wrote: Hello! I am working on getting USB-uboot working on OSK5912. from linux USB gadget device controller drivers (i.e. kernel/drivers/usb/gadget/) it looks like USB core for omap1510 and OSK5912 is same..But not sure, please confirm No idea. You will have to RTFM. RTFM indeed ;-) However, sadly TI does not always make this easy as some of the documentation for these devices is only available under NDA...boo! If you are having problem locating the fine manual for OMAP1510 purposes you can refer to the OMAP5910 device as this is pretty much the same device. Documentation for the OMAP5910 can be found here: Due to the fact thath the documentation is under NDA and you have access to it. Could you send a patch for it? Best Regards, J. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Changing u-boot relocation scheme
On 01:57 Sat 26 Jul , Grant Likely wrote: On Fri, Jul 25, 2008 at 1:28 PM, kenneth johansson [EMAIL PROTECTED] wrote: I was afraid that what was needed was more or less a complete linker but it looks like if one generate the dynamic reloc table a much simpler linker(relocation function) is needed. Still probably a lot more complex than the GOT and fixup code that is just a loop over a table. We may need a case also ;-) The GOT relocation works. It works really well. As long as gcc and ld put the correct GOT bits into the GOT table. It seems not all versions of gcc do it in the same way with the same flags. Why not set the code depending on the GCC version? Best Regards, J. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Changing u-boot relocation scheme
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-Christophe PLAGNIOL-VILLARD Sent: den 26 juli 2008 16:03 To: Grant Likely Cc: u-boot-users@lists.sourceforge.net; Wolfgang Denk; vb; Jerry Van Baren; Haavard Skinnemoen Subject: Re: [U-Boot-Users] Changing u-boot relocation scheme On 01:57 Sat 26 Jul , Grant Likely wrote: On Fri, Jul 25, 2008 at 1:28 PM, kenneth johansson [EMAIL PROTECTED] wrote: I was afraid that what was needed was more or less a complete linker but it looks like if one generate the dynamic reloc table a much simpler linker(relocation function) is needed. Still probably a lot more complex than the GOT and fixup code that is just a loop over a table. We may need a case also ;-) The GOT relocation works. It works really well. As long as gcc and ld put the correct GOT bits into the GOT table. It seems not all versions of gcc do it in the same way with the same flags. Why not set the code depending on the GCC version? For fun I had a look into eabi.asm code at http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/eabi.asm?rev=1.13content-type=text/x-cvsweb-markup and I noticed one difference: The __eabi_uconvert() function skips NULL ptrs. Perhaps this is the missing piece needed in start.S for PPC? __eabi_convert pasted below for convenience. Jocke FUNC_START(__eabi_convert) cmplw 1,3,4/* any pointers to convert? */ subf5,3,4/* calculate number of words to convert */ bclr4,4/* return if no pointers */ srawi 5,5,2 addi3,3,-4/* start-4 for use with lwzu */ mtctr 5 .Lcvt: lwzu6,4(3)/* pointer to convert */ cmpwi0,6,0 beq-.Lcvt2/* if pointer is null, don't convert */ add 6,6,12/* convert pointer */ stw 6,0(3) .Lcvt2: bdnz+ .Lcvt blr - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Changing u-boot relocation scheme
On Fri, 25 Jul 2008 22:51:09 +0200 kenneth johansson [EMAIL PROTECTED] wrote: Hmm...looks like linking with -pie (or --pic-executable) does something vaguely resembling the trick. But I don't know what vintage of ld you need for this to be available and actually work... Can't see any reason for using this flag over -fPIC for a program like u-boot. You need both. One is a compiler flag, the other is a linker flag. The linker will probably barf if you try to create a PIC executable from modules that were not compiled with -fPIC. On the other hand, using -fPIC but not -pie takes us about 95% of the way to a fully relocatable u-boot, and is what PowerPC, AVR32 and others are doing today. The remaining cases -- static and global initialized pointers -- are fixed up manually. If we link with -pie and add a bit of code to handle the dynamic relocations, we could get rid of the manual fixups. I don't know if the result would be larger or smaller than what we have today, but it would probably be a bit more robust. Does this really work without any relocation? Or is it being relocated and I'm just too blind to see it? No you are right there is probably many places like this. the code just use the old location and that works most of the time. Ah, of course. The strings are probably read directly from flash. Haavard - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Changing u-boot relocation scheme
On Sat, 26 Jul 2008 07:36:35 +0200 Wolfgang Denk [EMAIL PROTECTED] wrote: n message [EMAIL PROTECTED] you wrote: Ok, I'll stop the chest-beating now. But please stop trying to tell people that adding a powerpc-specific option (which nobody seems to know how really works) to the command line will work on any other architectures than powerpc. OK - then please you explain exactly which other architectures have problems with relocation? Well, AVR32 doesn't exactly have a _problem_ with relocation except that it relies on a handful of manual fixups for initialized pointers. From a quick scan, Blackfin, m68k, MIPS, PPC and SPARC also rely on this. While it does work, it is somewhat fragile and requires people writing new code to know about this particular quirk if they want to use statically initialized pointers. Also, as was shown elsewhere in this thread, quite a few strings are being accessed directly from flash even after relocating to RAM. This could at least in theory interfere with the flash driver due to cache effects. So I'm a bit concerned that if PowerPC introduces its own method of relocating these data pointers, the code used on other platforms would get less exposure and therefore be more susceptible to bugs. Ideally, all platforms should do relocation the same way, and that necessarily means using standard methods like ELF dynamic relocations. Haavard - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/1] Add support for ATMELAT91SAM9G20EK board
On Fri, 25 Jul 2008 17:44:52 -0500 [EMAIL PROTECTED] wrote: But since we already have a CONFIG_AVR32 #define, we can clean up the mess in macb.c by simply reversing the logic. If CONFIG_AVR32 can be used in macb.c without ofuscation, why is CONFIG_AT91 needed here? However, simply reversing the logic may be too much ofuscation though; we want clear rather than clever code after all. Reversing the logic wouldn't obfuscate anything. The code in question is a simple matter of AT91 needs to do it this way, AVR32 needs to do it another way. Whether we check for AT91 or AVR32 is completely arbitrary. An example of what I'd be opposed to is defining CONFIG_AT91SAM9260_OR_AT91SAM9263 where it is TRUE if either CONFIG_AT91SAM9260 or CONFIG_AT91SAM9263 are TRUE. I completely agreee with this. Can you see where this might be used in the macb.c code? Not really, no. The processors aren't _that_ different. It's a bit unfortunate that the USRIO register ended up with different behaviour on AT91 and AVR32, but fixing the silicon at this point would just make things worse, and IMO it's not a huge deal. From a CPP abuse point of view, the macb driver is IMO exceptionally clean compared to a lot of other code in u-boot. Haavard - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [yes, i tried rtfming docs]u-boot on x86, how to?
Hi Albert, Thank you very much for your support/help :) i actually didn't want be harsh with my words :( i'm pretty newbie, *really* and what i did is: sudo tar xjvf u-boot-1.3.3.tar.bz2 -C /usr/src then i tried: make distclean canyonlands_config all (as i read at http://www.denx.de/wiki/view/DULG/UBootConfiguration ) and i got: mbdev-deb:/usr/src/u-boot-1.3.3# make distclean canyonlands_config all Configuring for canyonlands board... System not configured - see README make: ** [all] Erro 1 also, as you all can easely see, i was not able to 'configure' the system i tried many other things in a 'adhoc' way and i still not able to handle this :( Kind Regards and Best Wishes, Geraldo São Paulo, Brasil, -3gmt site: http://exdev.sf.net/ msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 2008/7/26 Albert ARIBAUD [EMAIL PROTECTED]: Geraldo Netto a écrit : i tried the steps at http://www.denx.de/wiki/DULG/Manual but i was not able to make it work on x86 does anyone have any tip/doc(s) on how to make u-boot work on x86? i'd really appreciate that help :P Hello, You *might* get some help if you specify what exactly you tried, what succeeded, what did not succeed and what was the actual vs expected outcome of the unsuccessful step, including error messages. Amicalement, -- Albert. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [yes, i tried rtfming docs]u-boot on x86, how to?
Hi Geraldo, On Sat, Jul 26, 2008 at 11:31 AM, Geraldo Netto [EMAIL PROTECTED] wrote: Hi Albert, Thank you very much for your support/help :) i actually didn't want be harsh with my words :( i'm pretty newbie, *really* I haven't tried to build U-boot for x86 target, but am led to believe that it's not easy. If you're a newbie, it may not be for you. and what i did is: sudo tar xjvf u-boot-1.3.3.tar.bz2 -C /usr/src then i tried: make distclean canyonlands_config all (as i read at http://www.denx.de/wiki/view/DULG/UBootConfiguration ) Each target has a config file in include/configs. When you 'make' canyonlands_config, you're telling the build system to set things up for a target called 'canyonlands'. This target is a PowerPC target, not x86. You need to find one that's close to your hardware or make your own. and i got: mbdev-deb:/usr/src/u-boot-1.3.3# make distclean canyonlands_config all Configuring for canyonlands board... System not configured - see README make: ** [all] Erro 1 also, as you all can easely see, i was not able to 'configure' the system i tried many other things in a 'adhoc' way and i still not able to handle this :( You're seriously missing some big concepts and trying things without understanding them will only lead to pain. Ask yourself why you want U-boot on an x86 target. Grub or Lilo may be a better fit. regards, Ben - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [yes, i tried rtfming docs]u-boot on x86, how to?
In message [EMAIL PROTECTED] you wrote: sudo tar xjvf u-boot-1.3.3.tar.bz2 -C /usr/src then i tried: make distclean canyonlands_config all (as i read at http://www.denx.de/wiki/view/DULG/UBootConfiguration ) You mention u-boot on x86 in the subjct - are you aware that the Canyonlands board is not x86, but PPC? What you should do is: make distclean make canyonlands_config make all Do not try to perform all there steps in a single call to make - this cannot work. mbdev-deb:/usr/src/u-boot-1.3.3# make distclean canyonlands_config all Configuring for canyonlands board... System not configured - see README make: ** [all] Erro 1 This is caused by your incorrect call to make - see above. also, as you all can easely see, i was not able to 'configure' the system i tried many other things in a 'adhoc' way and i still not able to handle this :( Please read the manual - it describes step by step what to do. If you had follwed the examples, aboveerror could have been avoided. See http://www.denx.de/wiki/view/DULG/Manual?stickboard=canyonlands 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: [EMAIL PROTECTED] If there are self-made purgatories, then we all have to live in them. -- Spock, This Side of Paradise, stardate 3417.7 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Changing u-boot relocation scheme
Haavard Skinnemoen wrote: On Fri, 25 Jul 2008 22:51:09 +0200 kenneth johansson [EMAIL PROTECTED] wrote: Hmm...looks like linking with -pie (or --pic-executable) does something vaguely resembling the trick. But I don't know what vintage of ld you need for this to be available and actually work... Can't see any reason for using this flag over -fPIC for a program like u-boot. You need both. One is a compiler flag, the other is a linker flag. The linker will probably barf if you try to create a PIC executable from modules that were not compiled with -fPIC. No, it won't. You just get a module with a lot more relocations to do. I have verified that all four possible combinations of the compiler -fPIC and linker -pie work and make sense. FWIW, -fPIC code on IA32 is about 16% larger than non-PIC code, while on the Blackfin, -fPIC code is about 2% larger than non-PIC code. This is an average over several large C++ applications. On the other hand, using -fPIC but not -pie takes us about 95% of the way to a fully relocatable u-boot, and is what PowerPC, AVR32 and others are doing today. The remaining cases -- static and global initialized pointers -- are fixed up manually. If we link with -pie and add a bit of code to handle the dynamic relocations, we could get rid of the manual fixups. I don't know if the result would be larger or smaller than what we have today, but it would probably be a bit more robust. I agree with this suggestion. This is the only way to ensure a sane environment, because it emulates what the compiler expects to happen. Looping over all the relocation entries and doing the right thing is architecture specific, but the process is general. The GOT entries can also be processed this way. Effort spent on this approach will tend to be more generic than the current PPC specific approach. Does this really work without any relocation? Or is it being relocated and I'm just too blind to see it? No you are right there is probably many places like this. the code just use the old location and that works most of the time. Ah, of course. The strings are probably read directly from flash. Maybe not. I have been looking at assembly dumps of short examples on the IA32 built with -fPIC. It is clear that the method of addressing static variables and static constants is DIFFERENT from the method used for global variables. The relationship of the location of the text segment (executable code), the GOT data, and the static variables/constants must remain fixed. The location of the entire program can move, but it must move in one piece. If it does move as one piece, the lea (load effective address) instructions relative to the GOT pointer will be relocated to the new address correctly. These references are based totally on the offset from the point of reference. If the code is similar on your platform (which I bet it is), then the reference will not be to the flash but rather the new place where the data was moved.. Global variables, however are referenced indirectly via 32 bit address pointers in the GOT, and these addresses must be relocated by the loader. The loader also must relocate any initialized pointers, because the program itself does not. It would be interesting to know how this is accomplished, via what relocation codes, but it does happen. Best Regards, Bill Campbell Haavard - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Changing u-boot relocation scheme
On Sat, 26 Jul 2008 14:29:35 -0700 J. William Campbell [EMAIL PROTECTED] wrote: Haavard Skinnemoen wrote: On Fri, 25 Jul 2008 22:51:09 +0200 kenneth johansson [EMAIL PROTECTED] wrote: Can't see any reason for using this flag over -fPIC for a program like u-boot. You need both. One is a compiler flag, the other is a linker flag. The linker will probably barf if you try to create a PIC executable from modules that were not compiled with -fPIC. No, it won't. On some platforms it will. Text relocations are nasty, so some platforms (e.g. avr32) just refuse to deal with them. But that's not really relevant -- each architecture should decide whether to compile with -fPIC or not. You just get a module with a lot more relocations to do. I have verified that all four possible combinations of the compiler -fPIC and linker -pie work and make sense. FWIW, -fPIC code on IA32 is about 16% larger than non-PIC code, while on the Blackfin, -fPIC code is about 2% larger than non-PIC code. This is an average over several large C++ applications. Right...that's counting the whole loadable image or just the .text section? Not suprising that a modern architecture like Blackfin likes -fPIC a lot better than an old beast like i386 though. I agree with this suggestion. This is the only way to ensure a sane environment, because it emulates what the compiler expects to happen. Looping over all the relocation entries and doing the right thing is architecture specific, but the process is general. The GOT entries can also be processed this way. Effort spent on this approach will tend to be more generic than the current PPC specific approach. Right...I think the GOT entries already are processed this way, sort of. Ah, of course. The strings are probably read directly from flash. Maybe not. I have been looking at assembly dumps of short examples on the IA32 built with -fPIC. It is clear that the method of addressing static variables and static constants is DIFFERENT from the method used for global variables. The relationship of the location of the text segment (executable code), the GOT data, and the static variables/constants must remain fixed. The location of the entire program can move, but it must move in one piece. If it does move as one piece, the lea (load effective address) instructions relative to the GOT pointer will be relocated to the new address correctly. These references are based totally on the offset from the point of reference. If the code is similar on your platform (which I bet it is), then the reference will not be to the flash but rather the new place where the data was moved.. Yes, address calculations in the code should be correct, as the whole thing was compiled with -fPIC. Data references, however, are usually not. The code being discussed here is an array of pointers to strings. I'm pretty sure the pointers are still pointing to flash after relocation. Global variables, however are referenced indirectly via 32 bit address pointers in the GOT, and these addresses must be relocated by the loader. The global variables themselves are accessed through the GOT, yes. But the _value_ of a global variable is currently not relocated automatically. The loader also must relocate any initialized pointers, because the program itself does not. It would be interesting to know how this is accomplished, via what relocation codes, but it does happen. This is what's currently being done manually by adding a fixed offset to all the pointers we know need to be relocated. When linking with -pie, these initialized pointers will get a dynamic relocation entry each so that we can replace all these manual fixups by simply iterating over the relocations. To summarize: Address calculations in executable code do not need to change since we already compile with -fPIC. Initialized pointers, however, are currently handled in a very suboptimal way, and linking with -pie might be one piece of the solution to this. Haavard - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] USB Uboot on OSK5912
Due to the fact thath the documentation is under NDA and you have access to it. Could you send a patch for it? No problem. I will have a crack. Please note long-time user, first time patcher, so let me know if anything gets messed up but I have tried to follow the guidelines that you have. By the way, whilst playing around with this, I did noticed that there have been alot of updates made to drivers/serial/usbtty.c. It appears to have broken support for usbtty on OMAP devices. The board SX1 (a Siemens OMAP1510 board which I don't have) that originally added the usbtty support for OMAP is no longer compiling correctly with the latest version of u-boot. Back in the days of u-boot v1.1.x usbtty was working a treat for OMAP5912. Looks like more work to get usbtty back up and running on the OMAP5912 ;-( Cheers Jon - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] Add support for OMAP5912 and OMAP16xx to usbdcore_omap1510.c
Add support to drivers/usb/usbdcore_omap1510.c for OMAP5912 and OMAP16xx devices. Signed-off-by: Jon Hunter [EMAIL PROTECTED] --- drivers/usb/usbdcore_omap1510.c | 27 --- 1 files changed, 24 insertions(+), 3 deletions(-) diff --git a/drivers/usb/usbdcore_omap1510.c b/drivers/usb/usbdcore_omap1510.c index 84bb936..61c0d3b 100644 --- a/drivers/usb/usbdcore_omap1510.c +++ b/drivers/usb/usbdcore_omap1510.c @@ -28,7 +28,7 @@ #include common.h -#if defined(CONFIG_OMAP1510) defined(CONFIG_USB_DEVICE) +#if ((defined(CONFIG_OMAP1510) || defined(CONFIG_OMAP1610)) defined(CONFIG_USB_DEVICE)) #include asm/io.h #ifdef CONFIG_OMAP_SX1 @@ -1109,21 +1109,42 @@ int udc_init (void) */ outw ((1 4) | (1 5), CLOCK_CTRL); UDCREG (CLOCK_CTRL); + +#ifdef CONFIG_OMAP1510 + /* This code was originally implemented for OMAP1510 and +* therefore is only applicable for OMAP1510 boards. For +* OMAP5912 or OMAP16xx the register APLL_CTRL does not +* exist and DPLL_CTRL is already configured. +*/ + /* Set and check APLL */ outw (0x0008, APLL_CTRL); UDCREG (APLL_CTRL); /* Set and check DPLL */ outw (0x2210, DPLL_CTRL); UDCREG (DPLL_CTRL); - /* Set and check SOFT */ - outw ((1 4) | (1 3) | 1, SOFT_REQ); +#endif + /* Set and check SOFT +* The below line of code has been changed to perform a +* read-modify-write instead of a simple write for +* configuring the SOFT_REQ register. This allows the code +* to be compatible with OMAP5912 and OMAP16xx devices +*/ + outw ((1 4) | (1 3) | 1 | (inw(SOFT_REQ)), SOFT_REQ); /* Short delay to wait for DPLL */ udelay (1000); /* Print banner with device revision */ udc_rev = inw (UDC_REV) 0xff; +#ifdef CONFIG_OMAP1510 printf (USB: TI OMAP1510 USB function module rev %d.%d\n, udc_rev 4, udc_rev 0xf); +#endif + +#ifdef CONFIG_OMAP1610 + printf (USB: TI OMAP5912 USB function module rev %d.%d\n, + udc_rev 4, udc_rev 0xf); +#endif #ifdef CONFIG_OMAP_SX1 i2c_read (0x32, 0x04, 1, value, 1); -- 1.4.4.4 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Changing u-boot relocation scheme
Haavard Skinnemoen wrote: On Sat, 26 Jul 2008 14:29:35 -0700 J. William Campbell [EMAIL PROTECTED] wrote: Haavard Skinnemoen wrote: On Fri, 25 Jul 2008 22:51:09 +0200 kenneth johansson [EMAIL PROTECTED] wrote: Can't see any reason for using this flag over -fPIC for a program like u-boot. You need both. One is a compiler flag, the other is a linker flag. The linker will probably barf if you try to create a PIC executable from modules that were not compiled with -fPIC. No, it won't. On some platforms it will. Text relocations are nasty, so some platforms (e.g. avr32) just refuse to deal with them. But that's not really relevant -- each architecture should decide whether to compile with -fPIC or not. You just get a module with a lot more relocations to do. I have verified that all four possible combinations of the compiler -fPIC and linker -pie work and make sense. FWIW, -fPIC code on IA32 is about 16% larger than non-PIC code, while on the Blackfin, -fPIC code is about 2% larger than non-PIC code. This is an average over several large C++ applications. Right...that's counting the whole loadable image or just the .text section? Not suprising that a modern architecture like Blackfin likes -fPIC a lot better than an old beast like i386 though. That is the entire loadable image. The percentage will therefore be slightly higher as a function of just the .text section. It is pretty representative of the effect though. On the old beast, it is not so good! I agree with this suggestion. This is the only way to ensure a sane environment, because it emulates what the compiler expects to happen. Looping over all the relocation entries and doing the right thing is architecture specific, but the process is general. The GOT entries can also be processed this way. Effort spent on this approach will tend to be more generic than the current PPC specific approach. Right...I think the GOT entries already are processed this way, sort of Ah, of course. The strings are probably read directly from flash. Maybe not. I have been looking at assembly dumps of short examples on the IA32 built with -fPIC. It is clear that the method of addressing static variables and static constants is DIFFERENT from the method used for global variables. The relationship of the location of the text segment (executable code), the GOT data, and the static variables/constants must remain fixed. The location of the entire program can move, but it must move in one piece. If it does move as one piece, the lea (load effective address) instructions relative to the GOT pointer will be relocated to the new address correctly. These references are based totally on the offset from the point of reference. If the code is similar on your platform (which I bet it is), then the reference will not be to the flash but rather the new place where the data was moved.. Yes, address calculations in the code should be correct, as the whole thing was compiled with -fPIC. Data references, however, are usually not. The code being discussed here is an array of pointers to strings. I'm pretty sure the pointers are still pointing to flash after relocation. You are correct. The contents of initialized pointers are not relocated without using the relocation data provided by -pie on the ld script. Global variables, however are referenced indirectly via 32 bit address pointers in the GOT, and these addresses must be relocated by the loader. The global variables themselves are accessed through the GOT, yes. But the _value_ of a global variable is currently not relocated automatically. The loader also must relocate any initialized pointers, because the program itself does not. It would be interesting to know how this is accomplished, via what relocation codes, but it does happen. This is what's currently being done manually by adding a fixed offset to all the pointers we know need to be relocated. When linking with -pie, these initialized pointers will get a dynamic relocation entry each so that we can replace all these manual fixups by simply iterating over the relocations. To summarize: Address calculations in executable code do not need to change since we already compile with -fPIC. Initialized pointers, however, are currently handled in a very suboptimal way, and linking with -pie might be one piece of the solution to this. I agree completely. Now we just need to add processing the relocation data. Also, the relocation vectors differ in contents from platform to platform, so a bit of custom processing will be needed for each architecture. Bill Campbell Haavard - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based
[U-Boot-Users] [PATCH] omap1510: fix usbtty support
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD [EMAIL PROTECTED]
---
drivers/serial/usbtty.c | 10 +-
drivers/serial/usbtty.h |7 ++-
drivers/usb/usbdcore_omap1510.c | 16
include/usbdcore_omap1510.h |6 +++---
4 files changed, 26 insertions(+), 13 deletions(-)
diff --git a/drivers/serial/usbtty.c b/drivers/serial/usbtty.c
index 2bc5c3c..e6edb79 100644
--- a/drivers/serial/usbtty.c
+++ b/drivers/serial/usbtty.c
@@ -25,13 +25,13 @@
#ifdef CONFIG_USB_TTY
+#include config.h/* If defined, override Linux identifiers with
+* vendor specific ones */
#include circbuf.h
#include devices.h
#include usbtty.h
#include usb_cdc_acm.h
#include usbdescriptors.h
-#include config.h/* If defined, override Linux identifiers with
-* vendor specific ones */
#if 0
#define TTYDBG(fmt,args...)\
@@ -155,7 +155,7 @@ struct acm_config_desc {
/* Slave Interface */
struct usb_interface_descriptor data_class_interface;
struct usb_endpoint_descriptor
- data_endpoints[NUM_ENDPOINTS-1] __attribute__((packed));
+ data_endpoints[NUM_ENDPOINTS-1];
} __attribute__((packed));
static struct acm_config_desc acm_configuration_descriptors[NUM_CONFIGS] = {
@@ -285,9 +285,9 @@ struct gserial_config_desc {
struct usb_configuration_descriptor configuration_desc;
struct usb_interface_descriptor
- interface_desc[NUM_GSERIAL_INTERFACES] __attribute__((packed));
+ interface_desc[NUM_GSERIAL_INTERFACES];
struct usb_endpoint_descriptor
- data_endpoints[NUM_ENDPOINTS] __attribute__((packed));
+ data_endpoints[NUM_ENDPOINTS];
} __attribute__((packed));
diff --git a/drivers/serial/usbtty.h b/drivers/serial/usbtty.h
index 71c47bc..74098f7 100644
--- a/drivers/serial/usbtty.h
+++ b/drivers/serial/usbtty.h
@@ -36,12 +36,17 @@
/* If no VendorID/ProductID is defined in config.h, pretend to be Linux
* DO NOT Reuse this Vendor/Product setup with protocol incompatible devices */
+#ifndef CONFIG_USBD_VENDORID
#define CONFIG_USBD_VENDORID 0x0525/* Linux/NetChip */
+#endif
#define CONFIG_USBD_PRODUCTID_GSERIAL 0xa4a6 /* gserial */
#define CONFIG_USBD_PRODUCTID_CDCACM 0xa4a7 /* CDC ACM */
+#ifndef CONFIG_USBD_MANUFACTURER
#define CONFIG_USBD_MANUFACTURER Das U-Boot
+#endif
+#ifndef CONFIG_USBD_PRODUCT_NAME
#define CONFIG_USBD_PRODUCT_NAME U_BOOT_VERSION
-
+#endif
#define CONFIG_USBD_CONFIGURATION_STR TTY via USB
diff --git a/drivers/usb/usbdcore_omap1510.c b/drivers/usb/usbdcore_omap1510.c
index 84bb936..e51e066 100644
--- a/drivers/usb/usbdcore_omap1510.c
+++ b/drivers/usb/usbdcore_omap1510.c
@@ -452,7 +452,7 @@ static void omap1510_prepare_for_control_write_status
(struct urb *urb)
outw (UDC_EP_Dir, UDC_EP_NUM);
}
-/* udc_state_transition_up
+/* dc_state_transition_up
* udc_state_transition_down
*
* Helper functions to implement device state changes. The device states and
@@ -1064,10 +1064,14 @@ void omap1510_udc_noniso_irq (void)
*/
/* Called to start packet transmission. */
-void udc_endpoint_write (struct usb_endpoint_instance *endpoint)
+int udc_endpoint_write (struct usb_endpoint_instance *endpoint)
{
- unsigned short epnum =
- endpoint-endpoint_address USB_ENDPOINT_NUMBER_MASK;
+ unsigned short epnum;
+
+ if (!udc_device || !endpoint)
+ return -1;
+
+ epnum = endpoint-endpoint_address USB_ENDPOINT_NUMBER_MASK;
UDCDBGA (Starting transmit on ep %x, epnum);
@@ -1080,7 +1084,11 @@ void udc_endpoint_write (struct usb_endpoint_instance
*endpoint)
outw (UDC_Set_FIFO_En, UDC_CTRL);
/* deselect the endpoint FIFO */
outw (UDC_EP_Dir | epnum, UDC_EP_NUM);
+ } else {
+ return -1;
}
+
+ return 0;
}
/* Start to initialize h/w stuff */
diff --git a/include/usbdcore_omap1510.h b/include/usbdcore_omap1510.h
index 526fcd9..ecc94f7 100644
--- a/include/usbdcore_omap1510.h
+++ b/include/usbdcore_omap1510.h
@@ -168,8 +168,8 @@
#define UDC_IN_ENDPOINT1
#define UDC_IN_PACKET_SIZE 64
#define UDC_INT_ENDPOINT 5
-#define UDC_INT_PKTSIZE16
-#define UDC_BULK_PKTSIZE 16
+#define UDC_INT_PACKET_SIZE 16
+#define UDC_BULK_PACKET_SIZE 16
void udc_irq (void);
/* Flow control */
@@ -177,7 +177,7 @@ void udc_set_nak(int epid);
void udc_unset_nak (int epid);
/* Higher level functions for abstracting away from specific device */
-void udc_endpoint_write(struct usb_endpoint_instance *endpoint);
+int udc_endpoint_write(struct usb_endpoint_instance *endpoint);
int udc_init (void);
--
1.5.6.2
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based
Re: [U-Boot-Users] [yes, i tried rtfming docs]u-boot on x86, how to?
Hi :) regarding ppc boards,oh, i didn't know that actually i'm a 22yo newbie guy which is interested in u-boot because i do study information systems in Brazil and i'm doing a linux distro for thin clients(as a final course project-monograph+software) and i got interested in u-boot because it seems the *correct* bootloader for my project ie: it seems far smaller than other ones and at once offers many features :) and i also studied/setup grub/lilo/syslinux :) i need to compare bootloaders and write down the features of each one and show which bootloader is better for each case ie: which one has 'best' features for diskless boot; which one is better for local boot(size, 'dinamyc configuration(ie: pass parameter on the fly)',...,...; ... Kind Regards and Best Wishes, Geraldo São Paulo, Brasil, -3gmt site: http://exdev.sf.net/ msn: geraldo_boca_at_hotmail.com skype: geraldo-netto icq: 145-061-456 2008/7/26 Wolfgang Denk [EMAIL PROTECTED]: In message [EMAIL PROTECTED] you wrote: sudo tar xjvf u-boot-1.3.3.tar.bz2 -C /usr/src then i tried: make distclean canyonlands_config all (as i read at http://www.denx.de/wiki/view/DULG/UBootConfiguration ) You mention u-boot on x86 in the subjct - are you aware that the Canyonlands board is not x86, but PPC? What you should do is: make distclean make canyonlands_config make all Do not try to perform all there steps in a single call to make - this cannot work. mbdev-deb:/usr/src/u-boot-1.3.3# make distclean canyonlands_config all Configuring for canyonlands board... System not configured - see README make: ** [all] Erro 1 This is caused by your incorrect call to make - see above. also, as you all can easely see, i was not able to 'configure' the system i tried many other things in a 'adhoc' way and i still not able to handle this :( Please read the manual - it describes step by step what to do. If you had follwed the examples, aboveerror could have been avoided. See http://www.denx.de/wiki/view/DULG/Manual?stickboard=canyonlands 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: [EMAIL PROTECTED] If there are self-made purgatories, then we all have to live in them. -- Spock, This Side of Paradise, stardate 3417.7 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/1] Add support for ATMEL AT91SAM9G20EK board
Hi Hong Xu, On Thu, Jul 24, 2008 at 1:05 AM, Hong Xu [EMAIL PROTECTED] wrote: From 81230b02610c06fdc8a175e635851346488e3bdb Mon Sep 17 00:00:00 2001 From: Hong Xu [EMAIL PROTECTED] Date: Thu, 24 Jul 2008 14:25:05 +0800 Subject: [PATCH 1/1] Add support for ATMEL AT91SAM9G20EK board This patch adds support for ATMEL AT91SAM9G20EK board. User manual for AT91SAM9G20EK board, see http://www.atmel.com/dyn/resources/prod_documents/doc6413.pdf AT91 SAM9G20 datasheet, see http://www.atmel.com/dyn/resources/prod_documents/doc6384.pdf Signed-off-by: Hong Xu [EMAIL PROTECTED] --- snip diff --git a/net/eth.c b/net/eth.c index 38979aa..3f50e2b 100644 --- a/net/eth.c +++ b/net/eth.c @@ -287,7 +287,7 @@ int eth_initialize(bd_t *bis) mcdmafec_initialize(bis); #endif #if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || \ -defined(CONFIG_AT91SAM9263) +defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91SAM9G20) at91sam9_eth_initialize(bis); #endif Please don't touch net/eth.c. Instead, implement the following in board code: int board_eth_init(bd_t *bis); Please be sure to check that the weak version of board_eth_init() is overridden (the board_eth_init and __def_eth_init symbols should have different addresses in the object code). You can do something like: $ cat System.map | grep eth_init regards, Ben - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
