Re: [U-Boot-Users] compilation problems
On Fri, 2008-08-01 at 16:25 +0200, Gino Mariucci wrote: > > THis is not the fault of Fedora 9 - we run this, too, on some systems, > > and it works fine here. To me it seems a sif you missed to install a > > few critical packages on your system. > > I agree with you, even though is not easy to find what is missing. > > >> ... > >> HOSTCC scripts/mod/sumversion.o > >> scripts/mod/sumversion.c: In function "get_src_version": > >> scripts/mod/sumversion.c:384: error: "PATH_MAX" undeclared (first use > >> in this function) > > > > This probably means that the "kernel-headers" package is missing. Try: > > "yum -y install kernel-headers" (running as root). > > I have checked what you say but, the answer is: > "package kernel-headers-2.6.25.11-97.fc9.i386 is already installed on > this system" On my debian based system the kernel header package is for developing kernel modules not for the userspace stuff. It's in another package. dpkg -S /usr/include/linux/limits.h linux-libc-dev: /usr/include/linux/limits.h But redhat may be different. > Could the problem be related to some path not correctly declared? > > Many Thanks > > Gino - 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=100&url=/ ___ 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=100&url=/ ___ 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=100&url=/ ___ 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, 2008-07-25 at 20:35 +0200, Haavard Skinnemoen wrote:
> On Fri, 25 Jul 2008 19:28:48 +0200
> 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 ;-)
>
> 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.
> [EMAIL PROTECTED]:~/work/u-boot/master$ avr32-linux-readelf -d u-boot
>
> Dynamic section at offset 0x1b8f0 contains 12 entries:
> TagType Name/Value
> 0x0004 (HASH) 0x182ac
> 0x0005 (STRTAB) 0x18260
> 0x0006 (SYMTAB) 0x18150
> 0x000a (STRSZ) 74 (bytes)
> 0x000b (SYMENT) 16 (bytes)
> 0x0003 (PLTGOT) 0x1ae70
> 0x7001 (Processor Specific: 7001) 0xe6c
> 0x0015 (DEBUG) 0x0
> 0x0007 (RELA) 0x1833c
> 0x0008 (RELASZ) 6996 (bytes)
> 0x0009 (RELAENT)12 (bytes)
> 0x (NULL) 0x0
>
> The dynamic relocation section became surprisingly large. I wonder if
> we actually manage to manually relocate all those buggers...I checked a
> couple of them and in both cases it looked like something that needed
> to be relocated, but I couldn't find any code that actually did it.
yes it's scary that it's working as well as it does. This is however
solved by reactivating Grant Likely's patch.
> One example from common/cmd_itest.c:
>
> op_tbl_t op_table [] = {
> { "-lt", LT },
> { "<" , LT },
> { "-gt", GT },
> { ">" , GT },
> { "-eq", EQ },
> { "==" , EQ },
> { "-ne", NE },
> { "!=" , NE },
> { "<>" , NE },
> { "-ge", GE },
> { ">=" , GE },
> { "-le", LE },
> { "<=" , LE },
> };
>
> 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.
> The symbol tables can probably be made smaller with some careful
> ldscript tweaking.
>
> 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=100&url=/
___
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, 2008-07-25 at 13:02 -0400, Jerry Van Baren wrote: > kenneth johansson wrote: > > On Fri, 2008-07-25 at 17:23 +0200, Haavard Skinnemoen wrote: > > [snip] > > >> There will obviously be a fair amount of arch-specific code required to > >> make the actual relocation work though. > > > > So the gain of using dynamic relocation is that we have fever relocation > > types to implement and objcopy is not going to strip away the relocation > > section as it do for non dynamic relocs. > > > > still the code to actually do the relocation is architecture dependent > > and non existing. At least for powerpc we have a much easier option of > > having gcc generate a fixup table. > > EVERYTHING *already* exists, we just aren't using it right. That is > what the elf loader does in a "normal" system. Grant did it on the > PowerPC architecture - look at the archives, he didn't write new code > for this, it's already in there. 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. 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. 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 ;-) - 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=100&url=/ ___ 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, 2008-07-25 at 17:23 +0200, Haavard Skinnemoen wrote: > On Fri, 25 Jul 2008 16:33:56 +0200 > kenneth johansson <[EMAIL PROTECTED]> wrote: > > now it works as follows. One final static link with all the .a files and > > a specified start address for TEXT. result is a elf file with al symbols > > resolved adn it can be relinked to another address if one wants but we > > use objcopy to make a binary. > > Have you ever _tried_ to relink the final u-boot ELF file to another > address? How do you do that? I have before but I just did a quick test to make sure I'm not spreading miss information. ld -Ttext 0x0200 -Map u-boot_2.map -o u-boot_2 u-boot at least creates a map file that looks ok for a u-boot compiled both with -fpic and without. Did not actually run the result. > > here is a patch to generate dynamic relocations in the elf file. What is > > the next step? objcopy -j .rela.dyn -O binary u-boot dyn_reloc_table ?? > > Might actually work, though we might need more linker options as well. > At least -Bsymbolic comes to mind. And I'm not sure if -Bstatic goes > well along with -shared... > > In any case, there's no next step. The dynamic relocations are included > in a loadable segment, so they will end up in the .bin file after the > last objcopy step. hmm just checked what objcopy does and it do not work well with a object file created with shared. the resulting binary do not have .text first so it's not really workable at least not with that simple patch. cant find any option to make objcopy print out what section it actually writes out in the out file. > There will obviously be a fair amount of arch-specific code required to > make the actual relocation work though. So the gain of using dynamic relocation is that we have fever relocation types to implement and objcopy is not going to strip away the relocation section as it do for non dynamic relocs. still the code to actually do the relocation is architecture dependent and non existing. At least for powerpc we have a much easier option of having gcc generate a fixup table. - 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=100&url=/ ___ 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, 2008-07-25 at 14:19 +0200, Haavard Skinnemoen wrote: > On Fri, 25 Jul 2008 13:55:58 +0200 > kenneth johansson <[EMAIL PROTECTED]> wrote: > > > > An ELF shared library has the dynamic relocations we need. So if we > > > build u-boot as an .so file, it should work in theory on most > > > architectures. > > > > well the elf binary of u-boot obviously has everything we need > > regardless of what options it was compiled with. If we had a full linker > > at runtime we could just do a relink to whatever address we wanted. > > No we couldn't if we don't have any relocation information. Just as you > can't relink just any ELF binary to run at a different location after > it's been through a final link, no matter how "full" the linker is. Take time and READ what people write. I wrote compiler option and you go on about some final link that removes the relocation information. My point was that it is irrelevant if you use pic shared whatever if you are going to use the elf relocation information anyway granted you have less work to do if the object was compiled as PIC. > So whether or not the u-boot ELF file has everything we need depends a > _lot_ on what options were used when building it. Not really only what info you stripped way in the last linker stage. But this is going way off topic nobody is really arguing to include a linker in u-boot so it does not matter what options is available if we did. > > It sounds a bit easier to just loop over a list of pointers and change > > the values than to implement a complete linker but maybe that is just > > me. > > The question remains how should that list of pointers be generated? One > possible answer is to let the linker do it (as dynamic relocations). Since I have not done a linker I probably miss some information on what makes the dynamic relocations so special ?? And could you outline how the last step in generating the binary image would work. now it works as follows. One final static link with all the .a files and a specified start address for TEXT. result is a elf file with al symbols resolved adn it can be relinked to another address if one wants but we use objcopy to make a binary. here is a patch to generate dynamic relocations in the elf file. What is the next step? objcopy -j .rela.dyn -O binary u-boot dyn_reloc_table ?? --- config.mk +++ config.mk @@ -215,7 +215,8 @@ AFLAGS := $(AFLAGS_DEBUG) -D__ASSEMBLY__ $(CPPFLAGS) -LDFLAGS += -Bstatic -T $(LDSCRIPT) $(PLATFORM_LDFLAGS) +#LDFLAGS += -Bstatic -T $(LDSCRIPT) $(PLATFORM_LDFLAGS) +LDFLAGS += -Bstatic -shared -T $(LDSCRIPT) $(PLATFORM_LDFLAGS) ifneq ($(TEXT_BASE),) LDFLAGS += -Ttext $(TEXT_BASE) endif - 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=100&url=/ ___ 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, 2008-07-25 at 11:10 +0200, Haavard Skinnemoen wrote: > On Fri, 25 Jul 2008 06:28:16 +0200 > Wolfgang Denk <[EMAIL PROTECTED]> wrote: > > > In message <[EMAIL PROTECTED]> you wrote: > > > We could build u-boot as a shared library I guess, but that feels a bit > > > weird... > > > > Shared? Shared by what? > > An ELF shared library has the dynamic relocations we need. So if we > build u-boot as an .so file, it should work in theory on most > architectures. > > Haavard > well the elf binary of u-boot obviously has everything we need regardless of what options it was compiled with. If we had a full linker at runtime we could just do a relink to whatever address we wanted. It sounds a bit easier to just loop over a list of pointers and change the values than to implement a complete linker but maybe that is just me. - 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=100&url=/ ___ 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 Thu, 2008-07-24 at 11:26 -0700, vb wrote: > On Thu, Jul 24, 2008 at 11:09 AM, Kenneth Johansson > <[EMAIL PROTECTED]> wrote: > > > > > > > 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. > > > > > > From what I saw in my limited experiment, there is no code (as in CPU > instructions) generated by gcc, just a data section containing > offsets. > > Maybe the linker is supposed to add some code to the startup file to > handle that section in case it is invoked with -mrelocatable (on't > know if it would recognize this an option) or detects .fixup section > in the .o files being linked. It is a mute point for embedded > development anyways. I think the code exist in libgcc __eabi_convert() but code already exist in u-boot at least in several start.S files. > I *think* the only thing missing is a simple function to scan the > .fixup table and fix the pointers after relocation. The code should be there find . -name "*.S" | xargs grep FIXUP_TABLE - 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=100&url=/ ___ 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 Thu, 2008-07-24 at 10:37 -0700, vb wrote: > On Thu, Jul 24, 2008 at 9:57 AM, Haavard Skinnemoen > <[EMAIL PROTECTED]> wrote: > > Kenneth Johansson <[EMAIL PROTECTED]> wrote: > >> you have to > >> read the gcc code to understand what the -mrelocatable option really do. > > > > Plus it's only defined for PowerPC. What do we do on the 11 other > > architectures? > > > > We could build u-boot as a shared library I guess, but that feels a bit > > weird... > > > > I ran a quick experiment with -mrelocate, compiled a module with it > and then objdump -D its contents, it seems to do exactly what I wanted > - stores addresses of pointers to adjust into the fixit section. > > I guess the least intrusive alternative would be to compile the ported > code with this option, and then add a check to the u-boot function > dealing with GOT adjustments to see if the fixit section is nonempty. > If so - relocate .fixit in addition to GOT. > > 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. - 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=100&url=/ ___ 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 Thu, 2008-07-24 at 18:57 +0200, Haavard Skinnemoen wrote: > Kenneth Johansson <[EMAIL PROTECTED]> wrote: > > you have to > > read the gcc code to understand what the -mrelocatable option really do. > > Plus it's only defined for PowerPC. What do we do on the 11 other > architectures? Well other architectures works in different ways and thus has other flags. > We could build u-boot as a shared library I guess, but that feels a bit > weird... What do you mean by that ? u-boot is already compiled with the -fPIC option. - 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=100&url=/ ___ 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 Thu, 2008-07-24 at 15:01 +0200, Wolfgang Denk wrote: > In message <[EMAIL PROTECTED]> you wrote: > > Quite frankly, GOT is also clumsy and even ugly IMHO - it requires a > > lot of special treatment, explicit data definitions and linker > > scripts, and does not work for arbitrary data as we saw above. > > It is standard, documented by the ABI, and works fine if done > correctly. We just don't do it correctly yet. > > Best regards, > > Wolfgang Denk > Well the type of runtime relocation that we do in u-boot is not really specified in any documentation. What is in the abi is assuming a dynamic linker and a proper elf file. Gcc can be nice and create a fixup table for us if we ask for it but that is not something that exist in any abi document I ever read. That also explains why when this reloaction code was initially done we ended up with the extra fixup code that tries to catch a few pointer that the GOT table is not containing, nobody know the fixup table even existed and it sure as hell is not mentioned in the documentation you have to read the gcc code to understand what the -mrelocatable option really do. - 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=100&url=/ ___ 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 Wed, 2008-07-23 at 23:45 -0700, vb wrote:
> Wolfgang, thank you for your reply, let me try to explain myself a bit
> clearer:
>
> On Wed, Jul 23, 2008 at 8:18 PM, Wolfgang Denk <[EMAIL PROTECTED]> wrote:
> > In message <[EMAIL PROTECTED]> you wrote:
> >
> >> some companies). If these added modules were not written in position
> >> independent manner (namely, using structures with multiple stage
> >> indirect pointers interleaved with data), the effort to make these
> >> modules work in u-boot is very exhausting.
> >
> > I don't understand what you mean. Either you link statically with the
> > U-Boot image, or you use standalone programs. In both situations no
> > such problem as described by you exists.
> >
>
> we talk here about modules statically linked into the u-boot image.
> Allow me to illustrate the problem I am trying to solve. Consider
> adding this code to a u-boot source file on a ppc460gt platform:
>
> vvv
> 87a88,105
> >
> > int do_ptrt (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]);
> >
> > int (*pf)(struct cmd_tbl_s *, int, int, char *[]) = do_ptrt;
> >
> > int do_ptrt (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
> > {
> > printf ("pointer is %p\n", pf);
> > printf ("function is %p\n", do_ptrt);
> > return 0;
> > }
> >
> > U_BOOT_CMD(
> > ptrt, CFG_MAXARGS, 1, do_ptrt,
> > "ptrt\n",
> > ""
> > );
> >
> ^^^
>
> And this is what happens when this command is invoked:
>
> vvv
> => ptrt
> pointer is fffb2754
> function is 0ffb7754
>
>
> So, the value of 'pf' is equal to the address of do_ptrt() *before*
> relocation. The fact that there is a GOT and a sophisticated linker
> script did not prevent this from happening.
This is due to a u-boot on powerpc not doing the right things when it is
relocating itself. The code to do the right things exist but is
currently disabled.
What is missing right now is that to properly fix function pointers
stored in data section we have to compile with -mrelocatable flag to get
gcc to create a fixup table so we later at runtime can just go over that
table and correct all function pointers.
This is currently not done as there was some problems with it that
people thought was due to toolchain issue. I'm not so sure it is, the
code to generate this fixup has been in gcc since mid 90's and has not
seen many changes and the linker should not have to know about it as
it's just a normal relocataion for it. My take is that some targets did
something special with trying to fixup some pointers themselves and fail
when it's done correctly.
this is the only issue I'm aware of regarding relocation and if you
enable this for your board all your problems goes away.
-
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=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Acknowledging the use of U-boot in an embedded project
On Mon, 2008-07-21 at 08:13 -0400, Steven Bass wrote: > I've just become involved in a project which is using U-boot as the > bootloader. This is a smallish embedded system. I'm trying to find the > right way to handle the use of U-boot. What sort of acknowledgements, > source code availability, etc. are expected here. The license is GPL a very widely used license that your company probably already know how to handle. short version is that if somebody ask for the source to u-boot you better give it to them but this is not the right list to discuss GPL or any other license. http://www.fsf.org/licensing/ > > U-boot isn't ever visible to the user; the system boots up and > launches the application. There is a small LCD screen; and really > nowhere to display much. Minor changes have been made to the U-boot > source; to customize it for the hardware and the software download of > new firmware. > > Thanks, > > Steve > > Steven Bass > Intertech Engineering Associates, Inc. > (781) 801-1130 > > - > 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=100&url=/ > ___ U-Boot-Users mailing list > U-Boot-Users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/u-boot-users signature.asc Description: This is a digitally signed message part - 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=100&url=/___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] Move mpc5121 iopoin feature from board specific to common files.
And in the process eliminate some duplicate register defines.
Signed-off-by: Kenneth Johansson <[EMAIL PROTECTED]>
---
board/ads5121/Makefile |2 +-
board/ads5121/ads5121.c | 58 ++-
board/ads5121/iopin.c | 115 -
board/ads5121/iopin.h | 222 -
cpu/mpc512x/Makefile|2 +-
cpu/mpc512x/iopin.c | 49 +
include/mpc512x.h | 251 --
7 files changed, 323 insertions(+), 376 deletions(-)
delete mode 100644 board/ads5121/iopin.c
delete mode 100644 board/ads5121/iopin.h
create mode 100644 cpu/mpc512x/iopin.c
diff --git a/board/ads5121/Makefile b/board/ads5121/Makefile
index 5b95682..470848f 100644
--- a/board/ads5121/Makefile
+++ b/board/ads5121/Makefile
@@ -27,7 +27,7 @@ $(shell mkdir -p $(OBJTREE)/board/freescale/common)
LIB= $(obj)lib$(BOARD).a
-COBJS-y:= $(BOARD).o iopin.o
+COBJS-y:= $(BOARD).o
COBJS-${CONFIG_FSL_DIU_FB} += ads5121_diu.o
COBJS-${CONFIG_FSL_DIU_FB} += ../freescale/common/fsl_diu_fb.o
COBJS-${CONFIG_FSL_DIU_FB} += ../freescale/common/fsl_logo_bmp.o
diff --git a/board/ads5121/ads5121.c b/board/ads5121/ads5121.c
index 8452054..ba3d7d2 100644
--- a/board/ads5121/ads5121.c
+++ b/board/ads5121/ads5121.c
@@ -23,14 +23,12 @@
#include
#include
-#include "iopin.h"
#include
#include
#include
#ifdef CONFIG_MISC_INIT_R
#include
#endif
-#include "iopin.h" /* for iopin_initialize() prototype */
/* Clocks in use */
#define SCCR1_CLOCKS_EN(CLOCK_SCCR1_CFG_EN |
\
@@ -124,7 +122,7 @@ long int fixed_sdram (void)
u32 i;
/* Initialize IO Control */
- im->io_ctrl.regs[MEM_IDX] = IOCTRL_MUX_DDR;
+ im->io_ctrl.regs[IOCTL_MEM/4] = IOCTRL_MUX_DDR;
/* Initialize DDR Local Window */
im->sysconf.ddrlaw.bar = CFG_DDR_BASE & 0xF000;
@@ -237,6 +235,56 @@ int misc_init_r(void)
return 0;
}
+static iopin_t ioregs_init[] = {
+ /* FUNC1=FEC_RX_DV Sets Next 3 to FEC pads */
+ {
+ IOCTL_SPDIF_TXCLK, 3, 0,
+ IO_PIN_FMUX(1) | IO_PIN_HOLD(0) | IO_PIN_PUD(0) |
+ IO_PIN_PUE(0) | IO_PIN_ST(0) | IO_PIN_DS(3)
+ },
+ /* Set highest Slew on 9 PATA pins */
+ {
+ IOCTL_PATA_CE1, 9, 1,
+ IO_PIN_FMUX(0) | IO_PIN_HOLD(0) | IO_PIN_PUD(0) |
+ IO_PIN_PUE(0) | IO_PIN_ST(0) | IO_PIN_DS(3)
+ },
+ /* FUNC1=FEC_COL Sets Next 15 to FEC pads */
+ {
+ IOCTL_PSC0_0, 15, 0,
+ IO_PIN_FMUX(1) | IO_PIN_HOLD(0) | IO_PIN_PUD(0) |
+ IO_PIN_PUE(0) | IO_PIN_ST(0) | IO_PIN_DS(3)
+ },
+ /* FUNC1=SPDIF_TXCLK */
+ {
+ IOCTL_LPC_CS1, 1, 0,
+ IO_PIN_FMUX(1) | IO_PIN_HOLD(0) | IO_PIN_PUD(0) |
+ IO_PIN_PUE(0) | IO_PIN_ST(1) | IO_PIN_DS(3)
+ },
+ /* FUNC2=SPDIF_TX and sets Next pin to SPDIF_RX */
+ {
+ IOCTL_I2C1_SCL, 2, 0,
+ IO_PIN_FMUX(2) | IO_PIN_HOLD(0) | IO_PIN_PUD(0) |
+ IO_PIN_PUE(0) | IO_PIN_ST(1) | IO_PIN_DS(3)
+ },
+ /* FUNC2=DIU CLK */
+ {
+ IOCTL_PSC6_0, 1, 0,
+ IO_PIN_FMUX(2) | IO_PIN_HOLD(0) | IO_PIN_PUD(0) |
+ IO_PIN_PUE(0) | IO_PIN_ST(1) | IO_PIN_DS(3)
+ },
+ /* FUNC2=DIU_HSYNC */
+ {
+ IOCTL_PSC6_1, 1, 0,
+ IO_PIN_FMUX(2) | IO_PIN_HOLD(0) | IO_PIN_PUD(0) |
+ IO_PIN_PUE(0) | IO_PIN_ST(0) | IO_PIN_DS(3)
+ },
+ /* FUNC2=DIUVSYNC Sets Next 26 to DIU Pads */
+ {
+ IOCTL_PSC6_4, 26, 0,
+ IO_PIN_FMUX(2) | IO_PIN_HOLD(0) | IO_PIN_PUD(0) |
+ IO_PIN_PUE(0) | IO_PIN_ST(0) | IO_PIN_DS(3)
+ }
+};
int checkboard (void)
{
@@ -246,7 +294,9 @@ int checkboard (void)
printf ("Board: ADS5121 rev. 0x%04x (CPLD rev. 0x%02x)\n",
brd_rev, cpld_rev);
/* initialize function mux & slew rate IO inter alia on IO Pins */
- iopin_initialize();
+
+
+ iopin_initialize(ioregs_init, sizeof(ioregs_init) /
sizeof(ioregs_init[0]));
return 0;
}
diff --git a/board/ads5121/iopin.c b/board/ads5121/iopin.c
deleted file mode 100644
index a6792a0..000
--- a/board/ads5121/iopin.c
+++ /dev/null
@@ -1,115 +0,0 @@
-/*
- * (C) Copyright 2008
- * Martha J Marx, Silicon Turnkey Express, [EMAIL PROTECTED]
- * mpc512x I/O pin/pad initialization for the ADS5121 board
- * See file CREDITS for list of people who contributed to this
- * project.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is di
[U-Boot-Users] [PATCH] fix DIU for small screens
The DIU_DIV register is 8 bit not 5 bit. This prevented large DIV values
so it was not possible to set a slow pixel clock and thus prevented
display on small screens.
Signed-off-by: Kenneth Johansson <[EMAIL PROTECTED]>
--- a/board/ads5121/ads5121_diu.c
+++ b/board/ads5121/ads5121_diu.c
@@ -57,7 +57,7 @@ void diu_set_pixel_clock(unsigned int pixclock)
/* Modify PXCLK in GUTS CLKDVDR */
debug("DIU: Current value of CLKDVDR = 0x%08x\n", *clkdvdr);
temp = *clkdvdr & 0xFF00;
- *clkdvdr = temp | (pixval & 0x1F);
+ *clkdvdr = temp | (pixval & 0xFF);
debug("DIU: Modified value of CLKDVDR = 0x%08x\n", *clkdvdr);
}
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Fw: Does U-boot support ethernet chip LAN9210 from SMSC?
On Mon, 2008-06-30 at 19:21 +0900, 이승열 wrote:
> Hi Ben,
>
> The below is the part of smsc911x.c.
>
> In reg_read(), line 5 shows "(*(addr_16 + 1) << 16));", which add 1 to
> addr_16.
> In reg_write(), line 10 shows *(volatile u16*)(addr + 2) = (u16)(val >> 16);,
> which add 2 to addr.
>
> I don't understand this. Can you explain to me why address offset differs?
>
The type of addr and addr_16 is not the same. one is a pointer and one
is a number.
> 1. #elif CONFIG_DRIVER_SMC911X_16_BIT
> 2. static inline u32 reg_read(u32 addr)
> 3. {
> 4. volatile u16 *addr_16 = (u16 *)addr;
> 5. return ((*addr_16 & 0x) | (*(addr_16 + 1) << 16));
> 6. }
> 7. static inline void reg_write(u32 addr, u32 val)
> 8.{
> 9. *(volatile u16*)addr = (u16)val;
> 10. *(volatile u16*)(addr + 2) = (u16)(val >> 16);
> 11. }
> 12. #else
>
> Best Regards,
> Seung Youl.
>
> - Original Message -
> From: "이승열" <[EMAIL PROTECTED]>
> To: "Ben Warren" <[EMAIL PROTECTED]>
> Cc:
> Sent: Monday, June 30, 2008 3:02 PM
> Subject: Re: [U-Boot-Users] Does U-boot support ethernet chip LAN9210 from
> SMSC?
>
>
> > Hi Ben,
> >
> > I have found smc911x.c source code in which both 16 and 32 bit access are
> > supported.
> > I will test my board with this source code.
> >
> > Thank you.
> >
> > Best Regards,
> > Seung Youl.
> >
> >
> >
> > - Original Message -
> > From: "Ben Warren" <[EMAIL PROTECTED]>
> > To: "이승열" <[EMAIL PROTECTED]>
> > Cc:
> > Sent: Monday, June 30, 2008 2:43 PM
> > Subject: Re: [U-Boot-Users] Does U-boot support ethernet chip LAN9210 from
> > SMSC?
> >
> >
> >> On Sun, Jun 29, 2008 at 10:06 PM, 이승열 <[EMAIL PROTECTED]> wrote:
> >>> Hi Ben,
> >>>
> >>> Sorry for bothering you.
> >>>
> >>> I have downloaded the latest version of U-boot.
> >>> There is smc911x.c file. I have added this file to Makefile.
> >>> The compilation is successful.
> >> You don't have to add anything to the Makefile, just use the correct
> >> CONFIG options
> >>>
> >>> But, there are two problems.
> >>> 1. there is no LAN9210 entry in chip id list
> >> So add it. I haven't looked at the LAN9210 data sheet to even know if
> >> it will work with this chip. You're going to have to do some work.
> >>> 2. Only 32-bit is supported.
> >>>
> >> Not true. Both 16 and 32 bit access is supported. Check the source
> >> code (hint: look for CONFIG_DRIVER_SMC911X_16_BIT)
> >>> Is there any recent driver for LAN9210?
> >>
> >> I don't know of another or I would have told you about it.
> >>
> >> Good luck,
> >> Ben
> >>
> -
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> ___
> U-Boot-Users mailing list
> U-Boot-Users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
signature.asc
Description: This is a digitally signed message part
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Problems with root JFFS2 on NAND Flash
On Thu, 2008-06-26 at 14:16 -0400, Stuart Wood wrote: > On Thu, Jun 26, 2008 at 1:55 PM, Grant Erickson > > Are you certain that u-boot and linux are in agreement about the NAND layout > > and format? I had some initial problems in that area until I applied a patch > > to u-boot (prior to 1.3.3) that addressed the issue and brought the two into > > agreement. > > Can you expand on this? I've set the partition tables to be the same > between the two, > but I'm not sure what else needs to synchronized. MTD version? jffs2 stores the cleanmarker in the oob area. u-boot and linux needs to be configured so it is stored in the same place in the oob area. do an erase with cleanmarker from u-boot and read out what is stored in oob then do the same under linux and you will probably have the cleanmarker att different places. if you do not see the cleanmarker you have it in the same place as ecc and that is also wrong. fixing it is specific to the nand chip and nand controller that is used. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] mpc5121 cache coherency
On Wed, 2008-06-18 at 13:38 -0600, John Rigby wrote: > Unlike other SOCs with e300 cores the 5121 is not cache coherent. The > problem is an internal bridge that the processor can not snoop across. I do not have access to the manuals right now but I search all over an this was not something I found. Is this a design decision or an errata for the current version of the chip ? > On Wed, Jun 18, 2008 at 1:29 PM, Kenneth Johansson <[EMAIL PROTECTED]> wrote: > > I have tried to speed up u-boot by turning on I/D cache during boot. > > > > It sort of works and gives quite a boost but I'm having problems with > > the ethernet driver that no longer works. > > > > What I'm seeing is that the cpu do not notice the ethernet hardwares > > updates that is located in DRAM. Basically what is expected from a cache > > incoherent system. > > > > Now my question is should not the e300 core detect writes to the DRAM > > and reload the cached data ?? > > > > --- > > To get cache working I'm turning on the MMU and program some BAT > > registers to a 1-1 mapping where only DRAM has cache on and all other > > memory regions like the IMMR, flash ... has cache off. > > > > > > > > - > > Check out the new SourceForge.net Marketplace. > > It's the best place to buy or sell services for > > just about anything Open Source. > > http://sourceforge.net/services/buy/index.php > > ___ > > U-Boot-Users mailing list > > U-Boot-Users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/u-boot-users > > > - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] mpc5121 cache coherency
I have tried to speed up u-boot by turning on I/D cache during boot. It sort of works and gives quite a boost but I'm having problems with the ethernet driver that no longer works. What I'm seeing is that the cpu do not notice the ethernet hardwares updates that is located in DRAM. Basically what is expected from a cache incoherent system. Now my question is should not the e300 core detect writes to the DRAM and reload the cached data ?? --- To get cache working I'm turning on the MMU and program some BAT registers to a 1-1 mapping where only DRAM has cache on and all other memory regions like the IMMR, flash ... has cache off. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ 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 booting from NAND
On Sat, 2008-06-14 at 23:50 +0200, Wolfgang Denk wrote: > In message <[EMAIL PROTECTED]> you wrote: > > > > I ditched the entire reuse thing when I implemented nand boot for a > > 5121e platform. 2k was to little space to try to force in the generic > > files. just make a new start.S that do only the things it needs to. > > I seriously hope you based your code on the nand_spl/ frame work, so > it has a chance to get merged into mainline, and I also hope you will > post patches soon? > > Viele Grüße, > > Wolfgang Denk > It is based on the nand boot support that existed for some 4xx boards. The code is going to be made available in someway sometime but I do not think that anyone will ever try to merge it into the mainline. Maybe I will have some time between project to port the stuff over to the ads5121 board but it's not going to be in near time. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ 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 booting from NAND
On Fri, 2008-06-13 at 10:24 -0300, Alan Carvalho de Assis wrote: > Hi, > I am trying to port U-Boot to MX31PDK board, but I getting a problem > related to lowlevel initialization to boot from NAND flash memory. > > The problem is because cpu/arm1136/start.S waste so much space with > IRQ/FIQ handling and stack initialization then lowlevel_init function > is placed at 0x400 position. As the NAND controller from i.MX31 copy > just 2KB to NANDFC internal buffer and lowlevel_init has about 0x6b0 > bytes then the final position is after 0x800 (2KB) then the SDRAM > initialization routine and NAND block copy to SDRAM doesn't work. > > Comparing with RedBoot I verified it place the lowlevel routines at > 0x120 position then it fit in 2KB and all works fine. > > I need help to modify cpu/arm1136/start.S and place the lowlevel_init > at 0x120 position instead 0x400. I am not ARM assembly expert then any > help is welcome. > I ditched the entire reuse thing when I implemented nand boot for a 5121e platform. 2k was to little space to try to force in the generic files. just make a new start.S that do only the things it needs to. basically it only sets up the stack pointer to the internal SRAM. then the C code relocates the code from the nand controllers internal 2k into internal SRAM. sets up the memory controller , then reads out u-boot into dram and jumps to _start. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Question About how the CPU find the right string address in U-boot binary file ?
On Thu, 2008-06-05 at 20:17 +0800, wang baohua wrote: > Dear kenneth, > Thanks for your quick reply. The first reply is clear. > The second reply, I cannot calc this string address easily. > According to your reply "at that address will be a 32 bit address that > is the address of the string." > I search all the U-boot.bin, and CANNOT find any "00 02 B2 80" (that > is the string "Call backtrace:") using hex search. hmm where did this number came from? is it the offset from the start of the binary file ?? in that case it's obviously not going to be right the data in the got table is absolute values and depend on where the final link put the code. Lets do this the easy way. take the final u-boot elf file do not use the .bin file. then do "objdump -D u-boot" this will list the data in the .got2 sections as instructions disregard that and look only at the values. > Can you give me the detail calc process: > 1. offset value used in the load, this should be 0xFFEFFFE0 ?? no the offset was in clear text it was -32768 its a decimal number. > 2. subtract -32768. this should be - 0x32768 ? or -0x8000 ? or other > value. x= offset to load instruction and keep the sign x-(-32768) -> offset from start of .got2 section in this case we have -32768 --32768 ->0 thus the first entry. > 3. r30 is a pointer to the GOT table, it should be 0xfff34000 at > 0xfff0358c exec ?? it should point +32768 from the start of .got2 section > > > > On Thu, Jun 5, 2008 at 5:53 PM, Kenneth Johansson > <[EMAIL PROTECTED]> wrote: > > On Thu, 2008-06-05 at 09:50 +0800, wang baohua wrote: > > Dear Johansson, > > Thanks for your reply. Your reply is very clear, that's > just my > > question. In fact, I am study a > > MIPS binary file, but I cannot find any resource, so I turn > to PowerPC > > platform and try to get > > clear understand about the string loading process. > > > I'm not sure how similar MIPS is to ppc ABI. > > > I want to ask according to your reply: > > 1. fff0358c: 80 7e 80 00 lwz r3,-32768(r30) > >Is the -32768 stand for " entry 0 in the .got table" ? > Why such a > > translate in objdump? > > > It's not objectdump that do this it's the compiler that > generate the > code like this. r30 is a pointer to the GOT table but the > pointer is > located so that it's possible to use the full range of the 16 > bit signed > offset. that is if the GOT table only have one entry the r30 > value would > be pointing outside of the table but since it's accessed with > a singed > offset it will still work. > > > 2. I found the .got2 section in the U-boot.map, can you tell > me how to > > calc the right string address (traps.o) ? > >.reloc 0xfff34000 0x1578 > >*(.got) > > 0xfff34000_GOT2_TABLE_ > = . > > *(.got2) > > .got2 0xfff34000 0x24 cpu/mpc8260/start.o > > .got2 0xfff34024 0x4c > cpu/mpc8260/libmpc8260.a(traps.o) > > > ?? I thought this was obvious. to get the entry from the code > take the > offset value used in the load and subtract -32768 to get the > offset into > the .got2 section. at that address will be a 32 bit address > that is the > address of the string. > > > thanks! > > > - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Question About how the CPU find the right string address in U-boot binary file ?
On Thu, 2008-06-05 at 09:50 +0800, wang baohua wrote: > Dear Johansson, > Thanks for your reply. Your reply is very clear, that's just my > question. In fact, I am study a > MIPS binary file, but I cannot find any resource, so I turn to PowerPC > platform and try to get > clear understand about the string loading process. I'm not sure how similar MIPS is to ppc ABI. > I want to ask according to your reply: > 1. fff0358c: 80 7e 80 00 lwz r3,-32768(r30) >Is the -32768 stand for " entry 0 in the .got table" ? Why such a > translate in objdump? It's not objectdump that do this it's the compiler that generate the code like this. r30 is a pointer to the GOT table but the pointer is located so that it's possible to use the full range of the 16 bit signed offset. that is if the GOT table only have one entry the r30 value would be pointing outside of the table but since it's accessed with a singed offset it will still work. > 2. I found the .got2 section in the U-boot.map, can you tell me how to > calc the right string address (traps.o) ? >.reloc 0xfff34000 0x1578 >*(.got) > 0xfff34000_GOT2_TABLE_ = . > *(.got2) > .got2 0xfff34000 0x24 cpu/mpc8260/start.o > .got2 0xfff34024 0x4c cpu/mpc8260/libmpc8260.a(traps.o) ?? I thought this was obvious. to get the entry from the code take the offset value used in the load and subtract -32768 to get the offset into the .got2 section. at that address will be a 32 bit address that is the address of the string. > thanks! - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Question About how the CPU find the right string address in U-boot binary file ?
On Wed, 2008-06-04 at 12:04 +0800, wang baohua wrote:
> Dear all,
> I study the U-boot.bin file using the objdump command, I don't know
> how the CPU can find the right string address when puts() string.
> For example, In my binary file, the string "Call backtrace: " in func
> "print_backtrace()" address is :0x0002b280, the func address is
> 0xfff03564, How the CPU can find the 0x0002b280 when call puts
> ("Call backtrace: "); ? I find the SMC serial driver
> "serial_putc()" but cannot know how to find the char address in
> binary file.
it's not exactly clear what you ask but lets start from the beginning.
r3 is the register used by a function call that takes one argument.
so puts() will print the string that is in this register when it is
called.
for the caller to get the correct address into r3 is a bit more work.
u-boot is for powerpc compiled to be relocatable so the actual address
of the string will be put into one entry in the GOT table (.got2
section). The compiler will then generate code that reads out the
address from this table and put it into r3.
In the code below you can se that at address fff0358c r3 is set to what
is in entry 0 in the .got table. hint r30 points in the middle of the
table and quite possible outside any memory you have this is since the
register offset is singed value and we want to maximize the numbers of
entries.
> assemble code
> fff03564 : ---> length: C0, u-boot.bin address
> 0x3584,offset address: 0xFFEFFFE0
> fff03564: 94 21 ff d8 stwu r1,-40(r1)
> fff03568: 7c 08 02 a6 mflr r0
> fff0356c: 42 9f 00 05 bcl- 20,4*cr7+so,fff03570
> fff03570: bf 61 00 14 stmw r27,20(r1)
> fff03574: 7f c8 02 a6 mflr r30
> fff03578: 90 01 00 2c stw r0,44(r1)
> fff0357c: 80 1e ff f0 lwz r0,-16(r30)
> fff03580: 7c 7c 1b 78 mr r28,r3
> fff03584: 3b e0 00 00 li r31,0
> fff03588: 7f c0 f2 14 add r30,r0,r30
> fff0358c: 80 7e 80 00 lwz r3,-32768(r30)
> fff03590: 48 01 1b ad bl fff1513c
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
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] ColdFire: Fix UART baudrate formula
On Thu, 2008-05-29 at 15:26 -0500, Tsi-Chung.Liew wrote: > From: TsiChung Liew <[EMAIL PROTECTED]> > > The formula "counter = (u32) (gd->bus_clk / gd->baudrate) / 32" > can generate the wrong divisor due to integer division truncation. > Round the calculated divisor value by adding 1/2 the baudrate > before dividing by the baudrate. > > Signed-off-by: TsiChung Liew <[EMAIL PROTECTED]> > Acked-by: Gerald Van Baren <[EMAIL PROTECTED]> > --- > drivers/serial/mcfuart.c |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/serial/mcfuart.c b/drivers/serial/mcfuart.c > index 88f3eb1..75e85b7 100644 > --- a/drivers/serial/mcfuart.c > +++ b/drivers/serial/mcfuart.c > @@ -63,8 +63,8 @@ int serial_init(void) > uart->umr = UART_UMR_SB_STOP_BITS_1; > > /* Setting up BaudRate */ > - counter = (u32) (gd->bus_clk / (gd->baudrate)); > - counter >>= 5; > + counter = (u32) (gd->bus_clk / 32) + (gd->baudrate / 2)); And you compiled this ?? > + counter = counter / gd->baudrate; > > /* write to CTUR: divide counter upper byte */ > uart->ubg1 = (u8) ((counter & 0xff00) >> 8); - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ 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] Consolidates ADS5121 IO Pin configuration
On Thu, 2008-05-29 at 15:37 -0400, Martha Marx wrote: > Signed-off-by: Martha Marx <[EMAIL PROTECTED]> > --- > board/ads5121/Makefile|2 +- > board/ads5121/ads5121.c | 36 +--- > board/ads5121/iopin.c | 96 > board/ads5121/iopin.h | 220 > + > cpu/mpc512x/fec.c | 15 --- > include/configs/ads5121.h |1 + > 6 files changed, 321 insertions(+), 49 deletions(-) > create mode 100644 board/ads5121/iopin.c > create mode 100644 board/ads5121/iopin.h It's good that you remove iomux setting from the drivers like fec it should not be there. It's NOT good that you now put them in another "driver" iopin. The pins should be in board specific files. iopin should only contain helper functions not data that everybody that do a new board needs to go in and change/add. put the table in ads5121.c and I'm happy with it. well I'm not sure we need this fancy stuff only gets harder to read but I take that over having the config spread out over different files like it's now. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [Junk released by Allow List] Command history no longer working
On Thu, 2008-05-29 at 15:41 -0400, Hugo Villeneuve wrote: > [EMAIL PROTECTED] wrote: > > Hi, > > I have observed that after this commit, the command history is no > > longer working: > > > > --- > > commit 597f6c26a18b389903a64692bacbf9a1ca69355b > > Author: James Yang <[EMAIL PROTECTED]> > > Date: Mon May 5 10:22:53 2008 -0500 > > > > Fix readline_into_buffer() with CONFIG_CMDLINE_EDITING before > > relocating > > > > When CONFIG_CMDLINE_EDITING is enabled, readline_into_buffer() > > doesn't > > work before relocating to RAM because command history is written > > into > > a global array that is not writable before relocation. This patch > > defers to the no-editing and no-history code in > > readline_into_buffer() > > if it is called before relocation. > > --- > > > > Based on the comments, I dont understand why it ceases to work > > because, in my case, U-Boot runs entirely from RAM (it is copied from > > flash to RAM by a first stage bootloader). > > > > I have CONFIG_CMDLINE_EDITING defined. > > Well after reading through the code in common/main.c, I figured that > by setting GD_FLG_RELOC in my board init function: > > gd->flags |= GD_FLG_RELOC; > > command history would be working again, and it did. > > But is it the right thing to do? Yes. > I noticed that not a lot of platforms/boards set GD_FLG_RELOC so > command history will probably cease to work for these boards also? Most boards do the relocation and then it gets set by the common board_init_r() function. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] Remove shell variable UNDEF_SYM.
UNDEF_SYM is a shell variable in the main Makefile used to force the
linker to add all u-boot commands to the final image. It has no use here.
Signed-off-by: Kenneth Johansson <[EMAIL PROTECTED]>
---
nand_spl/board/amcc/acadia/Makefile |2 +-
nand_spl/board/amcc/bamboo/Makefile |2 +-
nand_spl/board/amcc/canyonlands/Makefile |2 +-
nand_spl/board/amcc/kilauea/Makefile |2 +-
nand_spl/board/amcc/sequoia/Makefile |2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/nand_spl/board/amcc/acadia/Makefile
b/nand_spl/board/amcc/acadia/Makefile
index 4272108..931f04b 100644
--- a/nand_spl/board/amcc/acadia/Makefile
+++ b/nand_spl/board/amcc/acadia/Makefile
@@ -51,7 +51,7 @@ $(nandobj)u-boot-spl.bin: $(nandobj)u-boot-spl
$(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
$(nandobj)u-boot-spl: $(OBJS)
- cd $(LNDIR) && $(LD) $(LDFLAGS) $$UNDEF_SYM $(__OBJS) \
+ cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) \
-Map $(nandobj)u-boot-spl.map \
-o $(nandobj)u-boot-spl
diff --git a/nand_spl/board/amcc/bamboo/Makefile
b/nand_spl/board/amcc/bamboo/Makefile
index aed7960..e1c1467 100644
--- a/nand_spl/board/amcc/bamboo/Makefile
+++ b/nand_spl/board/amcc/bamboo/Makefile
@@ -50,7 +50,7 @@ $(nandobj)u-boot-spl.bin: $(nandobj)u-boot-spl
$(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
$(nandobj)u-boot-spl: $(OBJS)
- cd $(LNDIR) && $(LD) $(LDFLAGS) $$UNDEF_SYM $(__OBJS) \
+ cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) \
-Map $(nandobj)u-boot-spl.map \
-o $(nandobj)u-boot-spl
diff --git a/nand_spl/board/amcc/canyonlands/Makefile
b/nand_spl/board/amcc/canyonlands/Makefile
index 47c7d02..fb86752 100644
--- a/nand_spl/board/amcc/canyonlands/Makefile
+++ b/nand_spl/board/amcc/canyonlands/Makefile
@@ -55,7 +55,7 @@ $(nandobj)u-boot-spl.bin: $(nandobj)u-boot-spl
$(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
$(nandobj)u-boot-spl: $(OBJS)
- cd $(LNDIR) && $(LD) $(LDFLAGS) $$UNDEF_SYM $(__OBJS) \
+ cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) \
-Map $(nandobj)u-boot-spl.map \
-o $(nandobj)u-boot-spl
diff --git a/nand_spl/board/amcc/kilauea/Makefile
b/nand_spl/board/amcc/kilauea/Makefile
index 84bd298..f47261f 100644
--- a/nand_spl/board/amcc/kilauea/Makefile
+++ b/nand_spl/board/amcc/kilauea/Makefile
@@ -50,7 +50,7 @@ $(nandobj)u-boot-spl.bin: $(nandobj)u-boot-spl
$(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
$(nandobj)u-boot-spl: $(OBJS)
- cd $(LNDIR) && $(LD) $(LDFLAGS) $$UNDEF_SYM $(__OBJS) \
+ cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) \
-Map $(nandobj)u-boot-spl.map \
-o $(nandobj)u-boot-spl
diff --git a/nand_spl/board/amcc/sequoia/Makefile
b/nand_spl/board/amcc/sequoia/Makefile
index 93150aa..fba0322 100644
--- a/nand_spl/board/amcc/sequoia/Makefile
+++ b/nand_spl/board/amcc/sequoia/Makefile
@@ -50,7 +50,7 @@ $(nandobj)u-boot-spl.bin: $(nandobj)u-boot-spl
$(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
$(nandobj)u-boot-spl: $(OBJS)
- cd $(LNDIR) && $(LD) $(LDFLAGS) $$UNDEF_SYM $(__OBJS) \
+ cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) \
-Map $(nandobj)u-boot-spl.map \
-o $(nandobj)u-boot-spl
--
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] boot pc with uboot
On Wed, 2008-05-28 at 14:33 +0430, Soodeh Bakhshandeh wrote: > Dear sir > I have a problem. I want to boot my pc with uboot. Which work I shold > do?what is my roadmap? > thanks I do not work with PC at all so I can not answer any of your question but I'm curious as to why you need u-boot if you have a standard PC. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] boot pc with uboot
On Wed, 2008-05-28 at 14:33 +0430, Soodeh Bakhshandeh wrote: > Dear sir > I have a problem. I want to boot my pc with uboot. Which work I shold > do?what is my roadmap? > thanks I do not work with PC at all so I can not answer any of your question but I'm curious as to why you need u-boot if you have a standard PC. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] u-boot v2
I'm just wondering what the status and plans are with the V2 branch. Is the plan that at some future date everyone just stops works on the main branch and switch over to V2 or is the features of V2 going to be ported over one by one. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ 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 v2] PPC405EX(r) ECC and SDRAM Initialization Clean-ups
On Mon, 2008-04-28 at 14:47 -0700, Grant Erickson wrote: > On 4/28/08 2:27 PM, Wolfgang Denk wrote: > > In message <[EMAIL PROTECTED]> you > > wrote: > >> The primary goal of these changes is to unify some of the low-level > >> SDRAM and ECC initialization code for the PPC4xx processors that use a > >> common DDR2 SDRAM controller. > >> > >> In particular, in the case of the 405EX[r], it must initialize SDRAM > >> before a primordial stack is available since OCM doesn't exist and the > >> data cache does not work for such a purpose. As a consequence, the ECC > >> (and SDRAM) initialization code must be stack-free. > > > > Stefan already asked this... I would also like to understand why the > > data cache cannot be used for initial RAM as we do on so many other > > systems? > > Agreed. The changes were based on the comments in the Kilauea and Makalu > board ports indicating that this had been attempted--twice--and didn't work. > > I am escalating with AMCC to find out if this is a processor errata, board > issue or just a programming issue that needs to be investigated further. The cache trick works fine on 405CR/405GP. Is the cache redesigned for 405EX. Why would they still call it a 405 if the core was redesigned? - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] What methods of software authentication does U-Boot support?
On Mon, 2008-04-21 at 01:32 +0200, Wolfgang Denk wrote: > In message <[EMAIL PROTECTED]> you wrote: > > > > > U-Boot will run only software that has been > > > authenticated to be from the system's producer. > > Seems it's time to start a discussion to switch to GPL v3... > > > > > Any comments or suggestions? > > > > > this patch taps into openssl: > > Be careful. Linking against openssl is not possible because the > openssl licence is not compatible with GPL; see for example > http://www.gnome.org/~markmc/openssl-and-the-gpl.html > > Best regards, > > Wolfgang Denk > For a u-boot friendly version of RSA look at http://xyssl.org/code/source/rsa/ I have not used it as the client put the secure(authenticated) image thing on hold but it was the best I could find in the limited time I put into it. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Fixup entries
On Thu, 2008-04-10 at 01:03 +0200, Joakim Tjernlund wrote: > > -Original Message- > > From: kenneth johansson [mailto:[EMAIL PROTECTED] > > I had this misconception that the GOT was all that was needed for > > relocation. > > Could not find any useful information on what rules apply to gcc and > > binutils for handling stuff in this fixup section. > > > > Anybody have any information on this? > > Nope, never found anything either. To see a working one in u-boot, look at > mpc83xx start.S and its linker scripts. > > Jocke > > Found some code from gcc that do the relocation in the same way we want in u-boot. http://gcc.gnu.org/viewcvs/trunk/gcc/config/rs6000/eabi.asm?revision=130805&view=markup I tried to call __eabi and link with libgcc plus ecrti.o, ecrtn.o but in the end I had one silly undefined symbol(.Lfini) that I could not get past the linker. But I think copying that code over into u-boot could not hurt. And considering the age of that code I can't imagine that anybody has a tool chain that can't handle using the -mrelocatable. It would be nice to remove the manual relocation done when it's not needed it is just confusing. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Linker scripts, SEARCH_DIR and host directories
On Thu, 2008-04-10 at 20:34 +0100, Richard Danter wrote: > Hi all, > > Using a new toolchain I am seeing the following warnings at the final > link stage of U-Boot: > > warning: library search path "/lib" is unsafe for cross-compilation > warning: library search path "/usr/lib" is unsafe for cross-compilation > warning: library search path "/usr/local/lib" is unsafe for cross-compilation > > Looking further I can see in the u-boot.lds scripts that SEARCH_DIR is > specifying each of these directories. I am unsure why a cross-compiled > bootloader would specify that the linker should look in the hosts > directories for libraries. > > Can anyone explain this? > > Thanks > Rich You should delete that from the linker script. There is several scripts that has this error it's not needed and wrong as you suspected. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Fixup entries
On Thu, 2008-04-10 at 01:03 +0200, Joakim Tjernlund wrote: > > -Original Message- > > From: kenneth johansson [mailto:[EMAIL PROTECTED] > > Sent: den 10 april 2008 01:00 > > To: Joakim Tjernlund > > Cc: u-boot-users@lists.sourceforge.net > > Subject: RE: [U-Boot-Users] Fixup entries > > > > On Wed, 2008-04-09 at 18:19 +0200, Joakim Tjernlund wrote: > > > > > > > -Original Message- > > > > From: Kenneth Johansson [mailto:[EMAIL PROTECTED] > > > > Wonder if there is something else in u-boot that use function pointers > > > > and work by accident due to the fact that the old address in flash is > > > > still valid. > > > > > > Oh yes, there are a few such pointers. And the conversion to using fixups > > > instead > > > is a bit lazy. Several manual relocations has only been nullified by > > > setting > > > gd->reloc_off=0 instead of #ifdef:ing out the relevant code. Feel > > > free to send patches :) > > > > > > Jocke > > > > > > > If by lazy you mean less error prone and obviously simpler :). clearly > > using -mrelocatable is the smarter thing to do. > > > > I had this misconception that the GOT was all that was needed for > > relocation. > > Could not find any useful information on what rules apply to gcc and > > binutils for handling stuff in this fixup section. > > > > Anybody have any information on this? > > Nope, never found anything either. To see a working one in u-boot, look at > mpc83xx start.S and its linker scripts. I have it working that is not the problem the problem is that I would like to know why it is :-) - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Fixup entries
On Wed, 2008-04-09 at 18:19 +0200, Joakim Tjernlund wrote: > > > -Original Message- > > From: Kenneth Johansson [mailto:[EMAIL PROTECTED] > > Wonder if there is something else in u-boot that use function pointers > > and work by accident due to the fact that the old address in flash is > > still valid. > > Oh yes, there are a few such pointers. And the conversion to using fixups > instead > is a bit lazy. Several manual relocations has only been nullified by setting > gd->reloc_off=0 instead of #ifdef:ing out the relevant code. Feel > free to send patches :) > > Jocke > If by lazy you mean less error prone and obviously simpler :). clearly using -mrelocatable is the smarter thing to do. I had this misconception that the GOT was all that was needed for relocation. Could not find any useful information on what rules apply to gcc and binutils for handling stuff in this fixup section. Anybody have any information on this? - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Fixup entries
On Wed, 2008-04-09 at 13:23 +0200, Joakim Tjernlund wrote: > On Wed, 2008-04-09 at 11:32 +0200, Kenneth Johansson wrote: > > What is the fixup section used for ? > > > > of the 274 cards that build on my MAKEALL not one has any entries into > > this section. > > These are needed for relocation of function pointers(and possible some > think more). There was an attempt by Grant Likely to enable this > functionalty, but some toolchains had problems with so the function > was disabled. If you undo commit > 1c3dd43338a077165e7e0309cb3994e65d2bdbf8 you will enable it again for > powerpc. > > Jocke aaahhaa so that is how it's working. I remember having problem understanding this when I did the command section and ended up doing a manual relocation of the command table. But compiling with -mrelocatable and going over the .fixup section instead I can now remove that extra code and it works fine. It's not easy to understand the ABI. I removed the -fPIC and only used -mrelocatable and that works too. Wonder if there is something else in u-boot that use function pointers and work by accident due to the fact that the old address in flash is still valid. --- `-mrelocatable' `-mno-relocatable' On embedded PowerPC systems generate code that allows (does not allow) the program to be relocated to a different address at runtime. If you use `-mrelocatable' on any module, all objects linked together must be compiled with `-mrelocatable' or `-mrelocatable-lib'. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] Fixup entries
What is the fixup section used for ? of the 274 cards that build on my MAKEALL not one has any entries into this section. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ 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 mpc5xx start.s questions
On Tue, 2008-04-08 at 14:49 +0800, 278893452 wrote: > dear sir or madam, > When I study the u-boot about mpc5xx, I confuse the definition > in cpu/mpc5xx/start.s as follows: Do you think this is wrong or are you asking something else. > /* > * Set up GOT: Global Offset Table > * > * Use r14 to access the GOT > */ > START_GOT > GOT_ENTRY(_GOT2_TABLE_) > GOT_ENTRY(_FIXUP_TABLE_) > GOT_ENTRY(_start) > GOT_ENTRY(_start_of_vectors) > GOT_ENTRY(_end_of_vectors) > GOT_ENTRY(transfer_to_handler) > GOT_ENTRY(__init_end) > GOT_ENTRY(_end) > GOT_ENTRY(__bss_start) > END_GOT > Will you please kind enough to explain what happens here to me? > Thank you! > > jjbear jjbear you have a very strange email address. The above is cpp macros. they set a few symbols. Here is an exercise run it through the preprocessor. If it still do not make sense post the preprocessed out put to the list. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] ads5121e DRAM init
Do the DRAM init according to micron MT47H64M8B6-37E documentation. Signed-off-by: Kenneth Johansson <[EMAIL PROTECTED]> diff --git a/board/ads5121/ads5121.c b/board/ads5121/ads5121.c index 8629b03..606cc6b 100644 --- a/board/ads5121/ads5121.c +++ b/board/ads5121/ads5121.c @@ -158,26 +158,18 @@ long int fixed_sdram (void) im->mddrc.ddr_command = CFG_MICRON_NOP; im->mddrc.ddr_command = CFG_MICRON_PCHG_ALL; - im->mddrc.ddr_command = CFG_MICRON_NOP; - im->mddrc.ddr_command = CFG_MICRON_RFSH; - im->mddrc.ddr_command = CFG_MICRON_NOP; - im->mddrc.ddr_command = CFG_MICRON_RFSH; - im->mddrc.ddr_command = CFG_MICRON_NOP; - im->mddrc.ddr_command = CFG_MICRON_INIT_DEV_OP; - im->mddrc.ddr_command = CFG_MICRON_NOP; - im->mddrc.ddr_command = CFG_MICRON_EM2; - im->mddrc.ddr_command = CFG_MICRON_NOP; - im->mddrc.ddr_command = CFG_MICRON_PCHG_ALL; - im->mddrc.ddr_command = CFG_MICRON_EM2; - im->mddrc.ddr_command = CFG_MICRON_EM3; - im->mddrc.ddr_command = CFG_MICRON_EN_DLL; - im->mddrc.ddr_command = CFG_MICRON_INIT_DEV_OP; + im->mddrc.ddr_command = CFG_MICRON_DDR2_LM_EM2; + im->mddrc.ddr_command = CFG_MICRON_DDR2_LM_EM3; + im->mddrc.ddr_command = CFG_MICRON_DDR2_LM_EM; + im->mddrc.ddr_command = CFG_MICRON_DDR2_LM_MR_DLL_RESET; + im->mddrc.ddr_command = CFG_MICRON_PCHG_ALL; im->mddrc.ddr_command = CFG_MICRON_RFSH; - im->mddrc.ddr_command = CFG_MICRON_INIT_DEV_OP; - im->mddrc.ddr_command = CFG_MICRON_OCD_DEFAULT; - im->mddrc.ddr_command = CFG_MICRON_PCHG_ALL; - im->mddrc.ddr_command = CFG_MICRON_NOP; + im->mddrc.ddr_command = CFG_MICRON_RFSH; + + im->mddrc.ddr_command = CFG_MICRON_DDR2_LM_MR; + im->mddrc.ddr_command = CFG_MICRON_DDR2_LM_EM_OCD; + im->mddrc.ddr_command = CFG_MICRON_DDR2_LM_EM_EXIT; /* Start MDDRC */ im->mddrc.ddr_time_config0 = CFG_MDDRC_TIME_CFG0_RUN; diff --git a/include/configs/ads5121.h b/include/configs/ads5121.h index c147424..83781c6 100644 --- a/include/configs/ads5121.h +++ b/include/configs/ads5121.h @@ -117,14 +117,22 @@ #define CFG_MDDRC_TIME_CFG10x54EC1168 #define CFG_MDDRC_TIME_CFG20x35210864 -#define CFG_MICRON_NOP 0x0138 -#define CFG_MICRON_PCHG_ALL0x01100400 -#define CFG_MICRON_EM2 0x0102 -#define CFG_MICRON_EM3 0x0103 -#define CFG_MICRON_EN_DLL 0x0101 -#define CFG_MICRON_RFSH0x0108 -#define CFG_MICRON_INIT_DEV_OP 0x01000432 -#define CFG_MICRON_OCD_DEFAULT 0x01010780 +/* DRAM commands */ +#define CFG_MICRON_NOP 0x0138 +#define CFG_MICRON_PCHG_ALL0x01100400 +#define CFG_MICRON_RFSH0x0108 + +/* DDR2 specific commands */ +#define CFG_MICRON_DDR2_LM_MR_DLL_RESET0x01000100 /* reset DLL */ +#define CFG_MICRON_DDR2_LM_MR 0x01000432 /* burst lenght 4 */ + /* CAS 3*/ + /* Write recovery 3 */ +#define CFG_MICRON_DDR2_LM_EM_OCD 0x01010780 /* OCD default */ + /* DQS# enable */ +#define CFG_MICRON_DDR2_LM_EM_EXIT 0x01010400 /* DQS# enable */ +#define CFG_MICRON_DDR2_LM_EM 0x0101 +#define CFG_MICRON_DDR2_LM_EM2 0x0102 +#define CFG_MICRON_DDR2_LM_EM3 0x0103 /* DDR Priority Manager Configuration */ #define CFG_MDDRCGRP_PM_CFG1 0x000777AA - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] dcache on ads5121e
On Thu, 2008-03-06 at 17:29 +0100, Wolfgang Denk wrote: > In message <[EMAIL PROTECTED]> you wrote: > > > > When I set CONFIG_CMD_CACHE and then use the command "dcache on" to turn > > on cache I lose the serial port. u-boot is now just spinning on the > > serial receive but it never gets any input. > > What makes you expect that will work? The functions (in start.S ) was implemented. Kind of pointless if cache can only be used with a mmu. > > Anybody run with caches on ?? > > Did you read the README? No I read the code. the unused one it turns out :( - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] dcache on ads5121e
Using HEAD 6bc113886d7d316df1a4e459bec8baf027518551 When I set CONFIG_CMD_CACHE and then use the command "dcache on" to turn on cache I lose the serial port. u-boot is now just spinning on the serial receive but it never gets any input. Anybody run with caches on ?? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ 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 for MPC5121e
A precompiled version and source for it exist on the linux bsp distributed on freescales site. The HEAD on u-boot git tree also works fine for this card. On Tue, 2008-02-19 at 22:18 -0800, Nethra wrote: > > hi, > Can i get u-boot source code configured for MPC5121e eval board..? > > thanks, > Nethra > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
