[U-Boot] Running u-boot without relocation to RAM?
Hi, I´m working on running U-Boot from a Leon3-System on an evaluation board from Actel. Some GPIO and Hello World programs are already running. Now I created the necessary files for my board/sytem and compiling of U-Boot goes well, but starting this application nothing is happening on the serial terminal. After checking my U-Boot and system configuration again, I think that my very small RAM area of only 16 kB might be the problem while U-Boot relocates itself to RAM at startup. So is it possible to completly disable the relocation process at startup and run U-Boot with having opcode in PROM and data in RAM? If yes, how could I achieve this? I already tried to remove the corresponding code in the start.S and searched the README for switches, but without success. Best regards, Tobias Kraitschy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM pull request v2
Dear Tom, In message 4ad3e52d.4050...@windriver.com you wrote: Sandeep has pointed out that the pull request should be one down. This is new request. The following changes since commit 2d4072c06b5549444e4140231bba3d47d9b0bc53: Sandeep Paulraj (1): ARM: DaVinci: Adding Support for DaVinci DM365 EVM are available in the git repository at: git://git.denx.de/u-boot-arm master Anton Vorontsov (11): Move uninitialized_var() macro from ubi_uboot.h to compiler.h mpc83xx/serdes: License cleanup: remove All Rights Reserved notice fsl: sys_eeprom: Fix 'may be used uninitialized' warning net: uec_phy: Implement TXID and RXID RGMII modes for Marvell PHYs net: uec: Fix uccf.h and uec.h headers to include headers they depend on mpc83xx: mpc8360emds: Don't use LBC SDRAM when DDR is available mpc83xx: mpc8360emds: Use RGMII-ID mode, add workarounds for rev. 2.1 CPUs mpc83xx: mpc8360emds: Add QE USB device tree fixups Move uninitialized_var() macro from ubi_uboot.h to compiler.h mpc83xx/serdes: License cleanup: remove All Rights Reserved notice fsl: sys_eeprom: Fix 'may be used uninitialized' warning Umm... all this stuff, as well as the other MPC85xx, ppc2xx etc. related commits below, is not supposed to show up in a ARM pull request. It is essential that I see _only_ ARM related commits in your pull request. If you want to sync your tree against u-boot/master you must either rebase your tree against master (not recommended for any published tree unless really needed), or send a pull request _before_ pulling. Next time - for now, it's obviously too late. I tried pulling your repo in a temp branch and rebase this, but this caused a lots of merge conflicts in non-ARM files. Can you please try to clean this up? Maybe we can split this in a list of ARM related commits that can be cherry-picked? Thanks in advance. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de : ... and it's got weird formatting - Notepad, Write, Works 3 can't : decipher it, and it's too big to go in DOS Edit. Help! Install an operating system. :-) -- Tom Christiansen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM pull request v2
Wolfgang Denk wrote: Dear Tom, In message 4ad3e52d.4050...@windriver.com you wrote: Sandeep has pointed out that the pull request should be one down. This is new request. The following changes since commit 2d4072c06b5549444e4140231bba3d47d9b0bc53: Sandeep Paulraj (1): ARM: DaVinci: Adding Support for DaVinci DM365 EVM are available in the git repository at: git://git.denx.de/u-boot-arm master Anton Vorontsov (11): Move uninitialized_var() macro from ubi_uboot.h to compiler.h mpc83xx/serdes: License cleanup: remove All Rights Reserved notice fsl: sys_eeprom: Fix 'may be used uninitialized' warning net: uec_phy: Implement TXID and RXID RGMII modes for Marvell PHYs net: uec: Fix uccf.h and uec.h headers to include headers they depend on mpc83xx: mpc8360emds: Don't use LBC SDRAM when DDR is available mpc83xx: mpc8360emds: Use RGMII-ID mode, add workarounds for rev. 2.1 CPUs mpc83xx: mpc8360emds: Add QE USB device tree fixups Move uninitialized_var() macro from ubi_uboot.h to compiler.h mpc83xx/serdes: License cleanup: remove All Rights Reserved notice fsl: sys_eeprom: Fix 'may be used uninitialized' warning Umm... all this stuff, as well as the other MPC85xx, ppc2xx etc. related commits below, is not supposed to show up in a ARM pull request. It is essential that I see _only_ ARM related commits in your pull request. If you want to sync your tree against u-boot/master you must either rebase your tree against master (not recommended for any published tree unless really needed), or send a pull request _before_ pulling. Next time - for now, it's obviously too late. I tried pulling your repo in a temp branch and rebase this, but this caused a lots of merge conflicts in non-ARM files. Can you please try to clean this up? Maybe we can split this in a list of ARM related commits that can be cherry-picked? Yes I see that that merge conflict. I will clean this up to a new branch by cherry-picking. This may take a day or two to do and to verify. I will have it done asap. Tom Thanks in advance. Best regards, Wolfgang Denk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add mpc5125ads board and processor to the mpc512x family
Dear Martha Stan,
In message 1254987657-10103-1-git-send-email-mm...@silicontkx.com you wrote:
Signed-off-by: Martha Stan mm...@silicontkx.com
---
MAINTAINERS |5 +
MAKEALL |1 +
Makefile|3 +
board/freescale/mpc5125ads/Makefile | 53
board/freescale/mpc5125ads/config.mk| 23 ++
board/freescale/mpc5125ads/cpld.h | 50
board/freescale/mpc5125ads/mpc5125ads.c | 415 ++
cpu/mpc512x/asm-offsets.h |6 +
cpu/mpc512x/cpu.c |3 +
cpu/mpc512x/fixed_sdram.c |6 +
cpu/mpc512x/iopin.c | 22 ++
cpu/mpc512x/serial.c| 17 +-
cpu/mpc512x/start.S | 15 +
drivers/net/mpc512x_fec.c | 51 +++-
include/asm-ppc/immap_512x.h| 285 +-
include/configs/mpc5125ads.h| 486
+++
16 files changed, 1418 insertions(+), 23 deletions(-)
create mode 100644 board/freescale/mpc5125ads/Makefile
create mode 100644 board/freescale/mpc5125ads/config.mk
create mode 100644 board/freescale/mpc5125ads/cpld.h
create mode 100644 board/freescale/mpc5125ads/mpc5125ads.c
create mode 100644 include/configs/mpc5125ads.h
First, I want to point out that I am well aware that a lot of the
trouble with this patch is caused by factors completely out of your
control (like Freescale coming up with such an ugly incompatibility
in the register interface between chips in the same CPU family), and
that you are not the culprit but the victim actually.
However, I think this current version of the patch is still not ripe
for inclusion into mainline - there are still way too many ugly
#ifdef's everywhere.
We need to find a way to work around these register interface issues
more intelligently.
Besides that, there are a few formal issues with your patch:
- there are whitespace errors:
Applying: Add mpc5125ads board and processor to the mpc512x
family
/home/wd/git/u-boot/work/.git/rebase-apply/patch:815: trailing
whitespace.
out_be32(fec-eth-r_cntrl, (FEC_MAX_FRAME_LEN 16)
| 0x124);
warning: 1 line applied after fixing whitespace errors.
- checkpatch.pl reports a number of issues, especially inconsistent
use of white space
+++ b/board/freescale/mpc5125ads/cpld.h
@@ -0,0 +1,50 @@
...
+/*
+ * MPC5125ADS CPLD Registers
+ */
+typedef struct mpc5125ads_cpld {
+ u16 board_id;
+ u8 cpld_rev[2];
+ u8 reset_cfg_word[4];
+ u8 nor_flash_ctl;
+ u8 nand_can_gpio_ctl;
+ u8 res1[3];
+ u8 int_mask;
+ u8 int_satus;
+ u8 misc_ctl;
+ u8 video_ctl;
+ u8 user_led;
+ u8 res2;
+ u8 cfg_switch;
+} mpc5125ads_cpld_t;
This is unrelated to this patch - but could we please have such a
struct for the mpc5121ads CPLD registers, too? Thanks in advance.
+#if defined(CONFIG_HARD_I2C) || defined(CONFIG_SOFT_I2C)
+ /*
+ * DIU init before the driver in linux takes over
+ * Enable the TFP410 Encoder (I2C address 0x38)
+ */
This seems logically wrong to me. Why does the DIU init code depend
on CONFIG_HARD_I2C or CONFIG_SOFT_I2C? Support for the DIU is an
unrelated feature, which should separately be enabled. And if it's
enabled, you must make sure to enable the prerequisites (like I2C
suport), too.
+ i2c_set_bus_num(1);
+ tmp_val = 0xBF;
+ if (i2c_write(0x38, 0x08, 1, tmp_val, sizeof(tmp_val)) != 0)
+ goto i2c_err;
+
+ /* Verify if enabled */
+ if (i2c_read(0x38, 0x08, 1, tmp_val, sizeof(tmp_val)) != 0)
+ goto i2c_err;
+ debug(DVI Encoder Read: 0x%02lx\n, tmp_val);
+ tmp_val = 0x10;
+ if (i2c_write(0x38, 0x0A, 1, tmp_val, sizeof(tmp_val)) != 0)
+ goto i2c_err;
+
+ /* Verify if enabled */
+ if (i2c_read(0x38, 0x0A, 1, tmp_val, sizeof(tmp_val)) != 0)
+ goto i2c_err;
+ debug(DVI Encoder Read: 0x%02lx\n, tmp_val);
+#endif
+#ifdef CONFIG_FSL_DIU_FB
+#if !(defined(CONFIG_VIDEO) || defined(CONFIG_CFB_CONSOLE))
+ mpc5121_diu_init();
+#endif
+#endif
Actually it seems we have copies of identical code in
board/freescale/mpc5121ads/mpc5121ads.c and in
board/freescale/mpc8610hpcd/mpc8610hpcd.c already. So instead of
adding a third copy of that code please factor this out into a
separate, common function that can be called by all such boards (this
needs to be done in a separate patch).
diff --git a/cpu/mpc512x/asm-offsets.h b/cpu/mpc512x/asm-offsets.h
index 4b14778..b79c656 100644
--- a/cpu/mpc512x/asm-offsets.h
+++ b/cpu/mpc512x/asm-offsets.h
@@ -11,5 +11,11 @@
#define CS_CTRL 0x00020
#define CS_CTRL_ME 0x0100 /* CS Master Enable bit */
+/* needed for pin muxing in
Re: [U-Boot] ARM pull request v2
Dear Tom, In message 4ad44bde.80...@bumblecow.com you wrote: I tried pulling your repo in a temp branch and rebase this, but this caused a lots of merge conflicts in non-ARM files. Can you please try to clean this up? Maybe we can split this in a list of ARM related commits that can be cherry-picked? Yes I see that that merge conflict. I will clean this up to a new branch by cherry-picking. This may take a day or two to do and to verify. I will have it done asap. Thanks a lot. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de One planet is all you get. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] OMAP3: proposal: dont piggy back on ROMCode interrupt vectors
Hi, Current interrupt vectors[1] are piggy backing on OMAP3 ROM Code vectors This has the disadvantage that external boot option of OMAP GP devices for booting off NOR devices would probably not function as the interrupt vectors are not setup. I had faced this during the port of u-boot-v2 and had done an implementation[2] for this. would we be interested in pulling this back in for u-boot-v1? I suppose all OMAP3 devices could benefit from it. Regards, Nishanth Menon Ref: [1] http://git.denx.de/?p=u-boot/u-boot-ti.git;a=blob;f=cpu/arm_cortexa8/start.S;h=14a9bd3b039143f92aed2133493aa9ee6a175738;hb=HEAD#l112 [2] http://git.denx.de/?p=u-boot/u-boot-v2.git;a=blob;f=arch/arm/mach-omap/omap3_core.S;h=dece199faefb3354189347d17cb0709d0ce2ad6c;hb=HEAD#l71 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Relocation size penalty calculation
On Sun, Oct 11, 2009 at 11:51 PM, Joakim Tjernlund
joakim.tjernl...@transmode.se wrote:
Graeme Russ graeme.r...@gmail.com wrote on 11/10/2009 12:47:19:
[Massive Snip :)]
So, all that is left are .dynsym and .dynamic ...
.dynsym
- Contains 70 entries (16 bytes each, 1120 bytes)
- 44 entries mimic those entries in .got which are not relocated
- 21 entries are the remaining symbols exported from the linker
script
- 4 entries are labels defined in inline asm and used in C
Try adding proper asm declarations. Look at what gcc
generates for a function/variable and mimic these.
Thanks - Now .dynsym contains only exports from the linker script
- 1 entry is a NULL entry
.dynamic
- 88 bytes
- Array of Elf32_Dyn
- typedef struct {
Elf32_Sword d_tag;
union {
Elf32_Word d_val;
Elf32_Addr d_ptr;
} d_un;
} Elf32_Dyn;
- 0x11 entries
[00] 0x0010, 0x DT_SYMBOLIC, (ignored)
[01] 0x0004, 0x38059994 DT_HASH, points to .hash
[02] 0x0005, 0x380595AB DT_STRTAB, points to .dynstr
[03] 0x0006, 0x3805BDCC DT_SYMTAB, points to .dynsym
[04] 0x000A, 0x03E6 DT_STRSZ, size of .dynstr
[05] 0x000B, 0x0010 DT_SYMENT, ???
[06] 0x0015, 0x DT_DEBUG, ???
[07] 0x0011, 0x3805A8F4 DT_REL, points to .rel.text
[08] 0x0012, 0x14D8 DT_RELSZ, ???
How big DT_REL is
[09] 0x0013, 0x0008 DT_RELENT, ???
hmm, cannot remeber :)
How big an entry in DT_REL is
[0a] 0x0016, 0x DT_TEXTREL, ???
Oops, you got text relocations. This is generally a bad thing.
TEXTREL is commonly caused by asm code that arent truly pic so it needs
to modify the .text segment to adjust for relocation.
You should get rid of this one. Look for DT_TEXTREL in .o files to find
the culprit.
Alas I cannot - The relocations are a result of loading a register with a
return address when calling show_boot_progress in the very early stages of
initialisation prior to the stack becoming available. The x86 does not
allow direct access to the IP so the only way to find the 'current
execution address' is to 'call' to the next instruction and pop the return
address off the stack
This is not a problem because this is very low-level init that is not
called once relocated into RAM - These relocations can be safely ignored
[0b] 0x6FFA, 0x0236 ???, Entries in .rel.dyn
[0c] 0x, 0x DT_NULL, End of Array
[0d] 0x, 0x DT_NULL, End of Array
[0e] 0x, 0x DT_NULL, End of Array
[0f] 0x, 0x DT_NULL, End of Array
[10] 0x, 0x DT_NULL, End of Array
I think some more investigation into the need for .dynsym and .dynamic is
still required...
.dynsym may still be required if only for accessing the __u_boot_cmd
structure. However, I may be able to hack that a little and not create a
__u_boot_cmd symbol in the linker script (create some other temporary
symbol) and populate __u_boot_cmd with a valid value after relocation. It
will look a little weird, but may mean not loading this section into RAM
Other than that, .dynsym is now only needed to locate the sections during
the relocation phase and can be kept in flash and not copied to RAM
I don't think .dynamic is needed due to the exporting of section addresses
from the linker script
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Relocation size penalty calculation
Graeme Russ graeme.r...@gmail.com wrote on 13/10/2009 13:21:05:
On Sun, Oct 11, 2009 at 11:51 PM, Joakim Tjernlund
joakim.tjernl...@transmode.se wrote:
Graeme Russ graeme.r...@gmail.com wrote on 11/10/2009 12:47:19:
[Massive Snip :)]
So, all that is left are .dynsym and .dynamic ...
.dynsym
- Contains 70 entries (16 bytes each, 1120 bytes)
- 44 entries mimic those entries in .got which are not relocated
- 21 entries are the remaining symbols exported from the linker
script
- 4 entries are labels defined in inline asm and used in C
Try adding proper asm declarations. Look at what gcc
generates for a function/variable and mimic these.
Thanks - Now .dynsym contains only exports from the linker script
:)
- 1 entry is a NULL entry
.dynamic
- 88 bytes
- Array of Elf32_Dyn
- typedef struct {
Elf32_Sword d_tag;
union {
Elf32_Word d_val;
Elf32_Addr d_ptr;
} d_un;
} Elf32_Dyn;
- 0x11 entries
[00] 0x0010, 0x DT_SYMBOLIC, (ignored)
[01] 0x0004, 0x38059994 DT_HASH, points to .hash
[02] 0x0005, 0x380595AB DT_STRTAB, points to .dynstr
[03] 0x0006, 0x3805BDCC DT_SYMTAB, points to .dynsym
[04] 0x000A, 0x03E6 DT_STRSZ, size of .dynstr
[05] 0x000B, 0x0010 DT_SYMENT, ???
[06] 0x0015, 0x DT_DEBUG, ???
[07] 0x0011, 0x3805A8F4 DT_REL, points to .rel.text
[08] 0x0012, 0x14D8 DT_RELSZ, ???
How big DT_REL is
[09] 0x0013, 0x0008 DT_RELENT, ???
hmm, cannot remeber :)
How big an entry in DT_REL is
Right, how could I forget :)
[0a] 0x0016, 0x DT_TEXTREL, ???
Oops, you got text relocations. This is generally a bad thing.
TEXTREL is commonly caused by asm code that arent truly pic so it needs
to modify the .text segment to adjust for relocation.
You should get rid of this one. Look for DT_TEXTREL in .o files to find
the culprit.
Alas I cannot - The relocations are a result of loading a register with a
return address when calling show_boot_progress in the very early stages of
initialisation prior to the stack becoming available. The x86 does not
allow direct access to the IP so the only way to find the 'current
execution address' is to 'call' to the next instruction and pop the return
address off the stack
hmm, same as ppc but that in it self should not cause a TEXREL, should it?
Ahh, the 'call' is absolute, not relative? I guess there is some way around it
but it is not important ATM I guess.
Evil idea, skip -fpic et. all and add the full reloc procedure
to relocate by rewriting directly in TEXT segment. Then you save space
but you need more relocation code. Something like dl_do_reloc from
uClibc. Wonder how much extra code that would be? Not too much I think.
This is not a problem because this is very low-level init that is not
called once relocated into RAM - These relocations can be safely ignored
[0b] 0x6FFA, 0x0236 ???, Entries in .rel.dyn
[0c] 0x, 0x DT_NULL, End of Array
[0d] 0x, 0x DT_NULL, End of Array
[0e] 0x, 0x DT_NULL, End of Array
[0f] 0x, 0x DT_NULL, End of Array
[10] 0x, 0x DT_NULL, End of Array
I think some more investigation into the need for .dynsym and .dynamic is
still required...
.dynsym may still be required if only for accessing the __u_boot_cmd
structure. However, I may be able to hack that a little and not create a
__u_boot_cmd symbol in the linker script (create some other temporary
symbol) and populate __u_boot_cmd with a valid value after relocation. It
will look a little weird, but may mean not loading this section into RAM
Why do you need to much around with u_boot_cmd at all? Now that relocation
works you should be able to drop all that code/linker stuff?
Other than that, .dynsym is now only needed to locate the sections during
the relocation phase and can be kept in flash and not copied to RAM
Still occupies space in the *bin image though.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Running u-boot without relocation to RAM?
Hi Tobias, Kraitschy, Tobias wrote: Hi, I´m working on running U-Boot from a Leon3-System on an evaluation board from Actel. Some GPIO and Hello World programs are already running. Now I created the necessary files for my board/sytem and compiling of U-Boot goes well, but starting this application nothing is happening on the serial terminal. After checking my U-Boot and system configuration again, I think that my very small RAM area of only 16 kB might be the problem while U-Boot relocates itself to RAM at startup. Yes. Major problem. So is it possible to completly disable the relocation process at startup and run U-Boot with having opcode in PROM and data in RAM? If yes, how could I achieve this? You would be the first to achieve this. One of the fundamental assumptions of u-boot is that it copies itself into RAM and runs out of RAM. There are many good reasons for this: RAM tends to be faster, it allows u-boot to reprogram flash without jumping extra hoops, u-boot is a boot *loader* to load a real OS (into RAM), real OSes require gobs of RAM, etc. While it isn't impossible, it appears to be a pretty daunting task. On the other hand, everything looks daunting when you start. Y'know, a trip of a thousand miles starts with the first step sort of stuff. I already tried to remove the corresponding code in the start.S and searched the README for switches, but without success. Nobody has had success yet, but maybe they just haven't tried hard enough. ;-) Best regards, Tobias Kraitschy Best regards, gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP3: proposal: dont piggy back on ROMCode interrupt vectors
Nishanth Menon wrote: Hi, Current interrupt vectors[1] are piggy backing on OMAP3 ROM Code vectors This has the disadvantage that external boot option of OMAP GP devices for booting off NOR devices would probably not function as the interrupt vectors are not setup. In general we want to limit dependencies of ROM code. And it should be moved to omap3 so other cortexa8 users don't have to code around it. Like we did for the cache flushing. I had faced this during the port of u-boot-v2 and had done an implementation[2] for this. would we be interested in pulling this back in for u-boot-v1? I suppose all OMAP3 devices could benefit from it. Poking around it does not look like any of the omap boards define CONFIG_USE_IRQ so it seems like you really will be creating the interrupt handlers. I think this is a good idea as long as the existing non-interrupts still works. I would be happy to test whatever you want to do. Should we set up a special ti-omap-irq topic branch ? Tom Regards, Nishanth Menon Ref: [1] http://git.denx.de/?p=u-boot/u-boot-ti.git;a=blob;f=cpu/arm_cortexa8/start.S;h=14a9bd3b039143f92aed2133493aa9ee6a175738;hb=HEAD#l112 [2] http://git.denx.de/?p=u-boot/u-boot-v2.git;a=blob;f=arch/arm/mach-omap/omap3_core.S;h=dece199faefb3354189347d17cb0709d0ce2ad6c;hb=HEAD#l71 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Linux seamless booting
On Mon, 2009-10-12 at 15:54 +0200, Fortini Matteo wrote: Yes, that's what we're currently using, but the problem is a little broader: I should answer to CAN messages in at most 100-200ms from powerup, and that can be done in u-boot. if you are in that interval you definitely need to go to a more exotic start sequence than usual. one solution would be to do as you suggest and do a special driver that is living outside of the kernel during startup. you still need to hack into the interrupt code to let your external driver handle the CAN. then you need to hack up the ordinary driver to take over from yours. I have not seen this solution on any project I worked on but should be doable. optimizing the boot time of linux so it starts up in 200ms is probably going to be quite hard. I did 2 seconds to /sbin/init started from ide driver without to much trouble. removing the IDE and going to a root on NOR would probably get closer to 1.5 but to get down to 200ms would probably mean removing most of u-boot and only keep the dram setup then you probably need to remove most of the drivers from the kernel and load them later as modules. I have never really tried to do a insane fast boot like this so I'm not sure what problems you will run up against. but maybe it's possible. but 200ms feels a bit to optimistic. However, handing CAN transmission control over to Linux is quite complicated nowadays, since it would involve passing structures in memory and hacking through device init. It'd be nice to have a framework with which u-boot could hand-over devices to Linux in a clean and defined way. not likely to happen as a generic solution. Much better to just remove the boat loader then and work on optimizing the linux startup code. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] ARM pull request v3
Wolfgang, I have cleaned up the commits to arm/master-sync. The cleanup is from doing a git rev-list --reverse master..arm/master Then working back from my notes to take only the commits were either misc arm or other arm pull requests. These were cherry picked on top of the current u-boot/master. I ran the MAKEALL regression and the results look like what I posted on Sunday. That said, it would be a good idea to wait a bit for others to review this list and pick up on anything that I missed. I will be offline for about 10hrs and will fix any problems then. Tom The following changes since commit 14abfe361b3ed23b02f564e2f5d663e158cd5799: Wolfgang Denk (1): Merge branch 'master' of /home/wd/git/u-boot/custodians are available in the git repository at: git://git.denx.de/u-boot-arm master-sync Daniel Gorsulowski (1): at91: Update MEESC board support Dirk Behme (1): OMAP3 MMC: Fix warning dereferencing type-punned pointer Olof Johansson (3): OMAP3: Clean up whitespace in mux configs SMC911X: Add chip auto detection TI: OMAP3: Overo Tobi ethernet support Prafulla Wadaskar (2): Kirkwood: rd6281a: Add kwbimage build support Kirkwood: mv88f6281gtw_ge: Add kwbimage build support Sandeep Paulraj (9): TI DaVinci: Remove references to SZ_xx TI DaVinci: DM6446: Fix Compilation error in NAND mode TI DaVinci: DM646x: Initial Support for DM646x SOC TI DaVinci: DM355: Config Cleanup and Update TI DaVinci DM365: Removing header file which does not exist TI: DaVinci DM365: Minor config cleanup TI: DaVinci DM646x: Update flag used to represent DM646x SOC's TI: DaVinci: GPIO header file and definitions TI: DaVinci DM365: Enabling network Support on DM365 EVM Simon Kagstrom (2): Support for the OpenRD base board arm: Correct build with CONFIG_SYS_HUSH_PARSER set Tom Rix (4): OMAP3 Move cache routine to cache.S Add support for Eukrea CPUAT91 SBC Add support for Eukrea CPU9260/CPU9G20 SBC TI OMAP3 Use arm init sequence to initialize i2c MAINTAINERS| 10 + MAKEALL|6 +- Makefile | 17 + board/Marvell/mv88f6281gtw_ge/config.mk|3 + board/Marvell/mv88f6281gtw_ge/kwbimage.cfg | 165 +++ board/Marvell/openrd_base/Makefile | 56 +++ board/Marvell/openrd_base/config.mk| 33 ++ board/Marvell/openrd_base/kwbimage.cfg | 168 +++ board/Marvell/openrd_base/openrd_base.c| 160 +++ board/Marvell/openrd_base/openrd_base.h| 46 ++ board/Marvell/rd6281a/config.mk|3 + board/Marvell/rd6281a/kwbimage.cfg | 167 +++ board/davinci/dm365evm/dm365evm.c | 44 ++- board/esd/meesc/meesc.c| 65 +++- board/eukrea/cpu9260/Makefile | 59 +++ board/eukrea/cpu9260/config.mk |1 + board/eukrea/cpu9260/cpu9260.c | 220 + board/eukrea/cpu9260/led.c | 153 +++ board/eukrea/cpuat91/Makefile | 50 +++ board/eukrea/cpuat91/config.mk |1 + board/eukrea/cpuat91/cpuat91.c | 81 board/logicpd/zoom1/zoom1.h| 164 board/logicpd/zoom2/zoom2.h| 188 board/overo/overo.c| 59 +++ board/overo/overo.h| 645 ++-- board/pandora/pandora.h| 662 ++-- board/ti/beagle/beagle.h | 640 ++-- board/ti/evm/evm.h | 662 ++-- board/timll/devkit8000/devkit8000.h| 628 +- cpu/arm920t/at91rm9200/Makefile|5 +- cpu/arm920t/at91rm9200/ks8721.c| 249 +++ cpu/arm926ejs/at91/lowlevel_init.S |3 +- cpu/arm926ejs/davinci/Makefile |1 + cpu/arm926ejs/davinci/dm646x.c | 41 ++ cpu/arm926ejs/kirkwood/cpu.c |1 + cpu/arm_cortexa8/cpu.c |2 +- cpu/arm_cortexa8/omap3/Makefile|2 +- cpu/arm_cortexa8/omap3/board.c |2 +- cpu/arm_cortexa8/omap3/cache.S | 191 cpu/arm_cortexa8/omap3/cache.c | 95 cpu/arm_cortexa8/start.S | 85 drivers/mmc/omap3_mmc.c| 48 +-- drivers/net/smc911x.c | 14 +- drivers/net/smc911x.h |7 +- include/asm-arm/arch-davinci/emac_defs.h |4 +- include/asm-arm/arch-davinci/gpio_defs.h | 53 +++ include/asm-arm/arch-davinci/hardware.h| 11 + include/asm-arm/arch-davinci/nand_defs.h |2 +-
Re: [U-Boot] ARM pull request v3
Tom Rix a écrit : Wolfgang, I have cleaned up the commits to arm/master-sync. The cleanup is from doing a git rev-list --reverse master..arm/master Then working back from my notes to take only the commits were either misc arm or other arm pull requests. These were cherry picked on top of the current u-boot/master. I ran the MAKEALL regression and the results look like what I posted on Sunday. That said, it would be a good idea to wait a bit for others to review this list and pick up on anything that I missed. I will be offline for about 10hrs and will fix any problems then. Tom The following changes since commit 14abfe361b3ed23b02f564e2f5d663e158cd5799: Wolfgang Denk (1): Merge branch 'master' of /home/wd/git/u-boot/custodians are available in the git repository at: git://git.denx.de/u-boot-arm master-sync Daniel Gorsulowski (1): at91: Update MEESC board support Dirk Behme (1): OMAP3 MMC: Fix warning dereferencing type-punned pointer Olof Johansson (3): OMAP3: Clean up whitespace in mux configs SMC911X: Add chip auto detection TI: OMAP3: Overo Tobi ethernet support Prafulla Wadaskar (2): Kirkwood: rd6281a: Add kwbimage build support Kirkwood: mv88f6281gtw_ge: Add kwbimage build support Sandeep Paulraj (9): TI DaVinci: Remove references to SZ_xx TI DaVinci: DM6446: Fix Compilation error in NAND mode TI DaVinci: DM646x: Initial Support for DM646x SOC TI DaVinci: DM355: Config Cleanup and Update TI DaVinci DM365: Removing header file which does not exist TI: DaVinci DM365: Minor config cleanup TI: DaVinci DM646x: Update flag used to represent DM646x SOC's TI: DaVinci: GPIO header file and definitions TI: DaVinci DM365: Enabling network Support on DM365 EVM Simon Kagstrom (2): Support for the OpenRD base board arm: Correct build with CONFIG_SYS_HUSH_PARSER set Tom Rix (4): OMAP3 Move cache routine to cache.S Add support for Eukrea CPUAT91 SBC Add support for Eukrea CPU9260/CPU9G20 SBC TI OMAP3 Use arm init sequence to initialize i2c Tom, Why this pull request does not include this[1] sub pull request from samsung repository? [1]: http://lists.denx.de/pipermail/u-boot/2009-October/062364.html Thanks ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP3: proposal: dont piggy back on ROMCode interrupt vectors
On Tue, Oct 13, 2009 at 7:27 AM, Tom Rix t...@bumblecow.com wrote: Nishanth Menon wrote: Hi, Current interrupt vectors[1] are piggy backing on OMAP3 ROM Code vectors This has the disadvantage that external boot option of OMAP GP devices for booting off NOR devices would probably not function as the interrupt vectors are not setup. In general we want to limit dependencies of ROM code. And it should be moved to omap3 so other cortexa8 users don't have to code around it. Like we did for the cache flushing. I had faced this during the port of u-boot-v2 and had done an implementation[2] for this. would we be interested in pulling this back in for u-boot-v1? I suppose all OMAP3 devices could benefit from it. Poking around it does not look like any of the omap boards define CONFIG_USE_IRQ so it seems like you really will be creating the interrupt handlers. I think this is a good idea as long as the existing non-interrupts still works. I would be happy to test whatever you want to do. Should we set up a special ti-omap-irq topic branch ? it is going to be just a silly little patch.. and given it is a cp15 feature, I think it might be cortex_a8 specific and not OMAP3 specific.. it would be good to have the irqs to be enabled for data abort reports etc.. but then, that is just my 2 cents.. Tom Regards, Nishanth Menon Ref: [1] http://git.denx.de/?p=u-boot/u-boot-ti.git;a=blob;f=cpu/arm_cortexa8/start.S;h=14a9bd3b039143f92aed2133493aa9ee6a175738;hb=HEAD#l112 [2] http://git.denx.de/?p=u-boot/u-boot-v2.git;a=blob;f=arch/arm/mach-omap/omap3_core.S;h=dece199faefb3354189347d17cb0709d0ce2ad6c;hb=HEAD#l71 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM pull request v3
Dear Tom Rix, In message 4ad478ae.10...@bumblecow.com you wrote: Wolfgang, I have cleaned up the commits to arm/master-sync. The cleanup is from doing a git rev-list --reverse master..arm/master Then working back from my notes to take only the commits were either misc arm or other arm pull requests. These were cherry picked on top of the current u-boot/master. I ran the MAKEALL regression and the results look like what I posted on Sunday. That said, it would be a good idea to wait a bit for others to review this list and pick up on anything that I missed. I will be offline for about 10hrs and will fix any problems then. Tom The following changes since commit 14abfe361b3ed23b02f564e2f5d663e158cd5799: Wolfgang Denk (1): Merge branch 'master' of /home/wd/git/u-boot/custodians are available in the git repository at: git://git.denx.de/u-boot-arm master-sync Daniel Gorsulowski (1): at91: Update MEESC board support Dirk Behme (1): OMAP3 MMC: Fix warning dereferencing type-punned pointer Olof Johansson (3): OMAP3: Clean up whitespace in mux configs SMC911X: Add chip auto detection TI: OMAP3: Overo Tobi ethernet support Prafulla Wadaskar (2): Kirkwood: rd6281a: Add kwbimage build support Kirkwood: mv88f6281gtw_ge: Add kwbimage build support Sandeep Paulraj (9): TI DaVinci: Remove references to SZ_xx TI DaVinci: DM6446: Fix Compilation error in NAND mode TI DaVinci: DM646x: Initial Support for DM646x SOC TI DaVinci: DM355: Config Cleanup and Update TI DaVinci DM365: Removing header file which does not exist TI: DaVinci DM365: Minor config cleanup TI: DaVinci DM646x: Update flag used to represent DM646x SOC's TI: DaVinci: GPIO header file and definitions TI: DaVinci DM365: Enabling network Support on DM365 EVM Simon Kagstrom (2): Support for the OpenRD base board arm: Correct build with CONFIG_SYS_HUSH_PARSER set Tom Rix (4): OMAP3 Move cache routine to cache.S Add support for Eukrea CPUAT91 SBC Add support for Eukrea CPU9260/CPU9G20 SBC TI OMAP3 Use arm init sequence to initialize i2c MAINTAINERS| 10 + MAKEALL|6 +- Makefile | 17 + board/Marvell/mv88f6281gtw_ge/config.mk|3 + board/Marvell/mv88f6281gtw_ge/kwbimage.cfg | 165 +++ board/Marvell/openrd_base/Makefile | 56 +++ board/Marvell/openrd_base/config.mk| 33 ++ board/Marvell/openrd_base/kwbimage.cfg | 168 +++ board/Marvell/openrd_base/openrd_base.c| 160 +++ board/Marvell/openrd_base/openrd_base.h| 46 ++ board/Marvell/rd6281a/config.mk|3 + board/Marvell/rd6281a/kwbimage.cfg | 167 +++ board/davinci/dm365evm/dm365evm.c | 44 ++- board/esd/meesc/meesc.c| 65 +++- board/eukrea/cpu9260/Makefile | 59 +++ board/eukrea/cpu9260/config.mk |1 + board/eukrea/cpu9260/cpu9260.c | 220 + board/eukrea/cpu9260/led.c | 153 +++ board/eukrea/cpuat91/Makefile | 50 +++ board/eukrea/cpuat91/config.mk |1 + board/eukrea/cpuat91/cpuat91.c | 81 board/logicpd/zoom1/zoom1.h| 164 board/logicpd/zoom2/zoom2.h| 188 board/overo/overo.c| 59 +++ board/overo/overo.h| 645 ++-- board/pandora/pandora.h| 662 ++-- board/ti/beagle/beagle.h | 640 ++-- board/ti/evm/evm.h | 662 ++-- board/timll/devkit8000/devkit8000.h| 628 +- cpu/arm920t/at91rm9200/Makefile|5 +- cpu/arm920t/at91rm9200/ks8721.c| 249 +++ cpu/arm926ejs/at91/lowlevel_init.S |3 +- cpu/arm926ejs/davinci/Makefile |1 + cpu/arm926ejs/davinci/dm646x.c | 41 ++ cpu/arm926ejs/kirkwood/cpu.c |1 + cpu/arm_cortexa8/cpu.c |2 +- cpu/arm_cortexa8/omap3/Makefile|2 +- cpu/arm_cortexa8/omap3/board.c |2 +- cpu/arm_cortexa8/omap3/cache.S | 191 cpu/arm_cortexa8/omap3/cache.c | 95 cpu/arm_cortexa8/start.S | 85 drivers/mmc/omap3_mmc.c| 48 +-- drivers/net/smc911x.c | 14 +- drivers/net/smc911x.h |7 +- include/asm-arm/arch-davinci/emac_defs.h |4 +-
Re: [U-Boot] ARM pull request v3
Dear Tom Rix, In message 4ad478ae.10...@bumblecow.com you wrote: Wolfgang, I have cleaned up the commits to arm/master-sync. The cleanup is from doing a git rev-list --reverse master..arm/master Then working back from my notes to take only the commits were either misc arm or other arm pull requests. These were cherry picked on top of the current u-boot/master. I ran the MAKEALL regression and the results look like what I posted on Sunday. That said, it would be a good idea to wait a bit for others to review this list and pick up on anything that I missed. I will be offline for about 10hrs and will fix any problems then. Tom The following changes since commit 14abfe361b3ed23b02f564e2f5d663e158cd5799: Wolfgang Denk (1): Merge branch 'master' of /home/wd/git/u-boot/custodians are available in the git repository at: git://git.denx.de/u-boot-arm master-sync Daniel Gorsulowski (1): at91: Update MEESC board support Dirk Behme (1): OMAP3 MMC: Fix warning dereferencing type-punned pointer Olof Johansson (3): OMAP3: Clean up whitespace in mux configs SMC911X: Add chip auto detection TI: OMAP3: Overo Tobi ethernet support Prafulla Wadaskar (2): Kirkwood: rd6281a: Add kwbimage build support Kirkwood: mv88f6281gtw_ge: Add kwbimage build support Sandeep Paulraj (9): TI DaVinci: Remove references to SZ_xx TI DaVinci: DM6446: Fix Compilation error in NAND mode TI DaVinci: DM646x: Initial Support for DM646x SOC TI DaVinci: DM355: Config Cleanup and Update TI DaVinci DM365: Removing header file which does not exist TI: DaVinci DM365: Minor config cleanup TI: DaVinci DM646x: Update flag used to represent DM646x SOC's TI: DaVinci: GPIO header file and definitions TI: DaVinci DM365: Enabling network Support on DM365 EVM Simon Kagstrom (2): Support for the OpenRD base board arm: Correct build with CONFIG_SYS_HUSH_PARSER set Tom Rix (4): OMAP3 Move cache routine to cache.S Add support for Eukrea CPUAT91 SBC Add support for Eukrea CPU9260/CPU9G20 SBC TI OMAP3 Use arm init sequence to initialize i2c MAINTAINERS| 10 + MAKEALL|6 +- Makefile | 17 + board/Marvell/mv88f6281gtw_ge/config.mk|3 + board/Marvell/mv88f6281gtw_ge/kwbimage.cfg | 165 +++ board/Marvell/openrd_base/Makefile | 56 +++ board/Marvell/openrd_base/config.mk| 33 ++ board/Marvell/openrd_base/kwbimage.cfg | 168 +++ board/Marvell/openrd_base/openrd_base.c| 160 +++ board/Marvell/openrd_base/openrd_base.h| 46 ++ board/Marvell/rd6281a/config.mk|3 + board/Marvell/rd6281a/kwbimage.cfg | 167 +++ board/davinci/dm365evm/dm365evm.c | 44 ++- board/esd/meesc/meesc.c| 65 +++- board/eukrea/cpu9260/Makefile | 59 +++ board/eukrea/cpu9260/config.mk |1 + board/eukrea/cpu9260/cpu9260.c | 220 + board/eukrea/cpu9260/led.c | 153 +++ board/eukrea/cpuat91/Makefile | 50 +++ board/eukrea/cpuat91/config.mk |1 + board/eukrea/cpuat91/cpuat91.c | 81 board/logicpd/zoom1/zoom1.h| 164 board/logicpd/zoom2/zoom2.h| 188 board/overo/overo.c| 59 +++ board/overo/overo.h| 645 ++-- board/pandora/pandora.h| 662 ++-- board/ti/beagle/beagle.h | 640 ++-- board/ti/evm/evm.h | 662 ++-- board/timll/devkit8000/devkit8000.h| 628 +- cpu/arm920t/at91rm9200/Makefile|5 +- cpu/arm920t/at91rm9200/ks8721.c| 249 +++ cpu/arm926ejs/at91/lowlevel_init.S |3 +- cpu/arm926ejs/davinci/Makefile |1 + cpu/arm926ejs/davinci/dm646x.c | 41 ++ cpu/arm926ejs/kirkwood/cpu.c |1 + cpu/arm_cortexa8/cpu.c |2 +- cpu/arm_cortexa8/omap3/Makefile|2 +- cpu/arm_cortexa8/omap3/board.c |2 +- cpu/arm_cortexa8/omap3/cache.S | 191 cpu/arm_cortexa8/omap3/cache.c | 95 cpu/arm_cortexa8/start.S | 85 drivers/mmc/omap3_mmc.c| 48 +-- drivers/net/smc911x.c | 14 +- drivers/net/smc911x.h
Re: [U-Boot] Running u-boot without relocation to RAM?
So is it possible to completly disable the relocation process at startup and run U-Boot with having opcode in PROM and data in RAM? If yes, how could I achieve this? I already tried to remove the corresponding code in the start.S and searched the README for switches, but without success. Did you try the CONFIG_SKIP_RELOCATE_UBOOT ? I am not sure if it serves your purpose here. It depends upon whether or not your start.S uses it at all. -Alfred ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM pull request v3
On Tue, 13 Oct 2009 16:51:14 +0200 Wolfgang Denk w...@denx.de wrote: I want to let you know that there will probably be some compilation warnings. These are patches for these. These have been sent to the list and ACK'ed by Tom and currently in my master. This will be part of my next pull request. Thanks for the heads-up. Indeed there are lots of warning. OK, so I will wait until Tom sends another pull request that includes these fixes. Tom: Perhaps you could pick up [PATCH v3] arm926ejs: 8-byte align stack to avoid LDRD/STRD problems for the ARM repo as well then? I know it could go via Prafullas tree, but it's not really Marvell-specific, just fixes an issue for Sheevaplug and OpenRD. I also don't see how it could do any harm to other ARM boards. // Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/3] ppc/p1_p2_RDB: DDR Relocation support for NAND/SD/eSPI Boot
On Oct 12, 2009, at 10:42 AM, Kim Phillips wrote:
On Mon, 12 Oct 2009 12:01:32 +0530
Dudhat Dipen-B09055 dipen.dud...@freescale.com wrote:
On Oct 9, 2009, at 12:42 PM, Dipen Dudhat wrote:
+void initsdram(void)
+{
+
+ volatile ccsr_ddr_t *ddr= (ccsr_ddr_t
*)CONFIG_SYS_MPC85xx_DDR_ADDR;
+ int d_init, dbw;
+ volatile ccsr_gpio_t *pgpio = (void *)
(CONFIG_SYS_MPC85xx_GPIO_ADDR);
+ unsigned int ddr_size;
+ sys_info_t sysinfo;
+ phys_size_t dram_size = 0;
+
+ set_next_law(0,LAW_SIZE_1G , LAW_TRGT_IF_DDR_1);
+
+ out_be32(ddr-cs0_bnds, CONFIG_SYS_DDR_CS0_BNDS);
+ out_be32(ddr-cs0_config, CONFIG_SYS_DDR_CS0_CONFIG);
+ out_be32(ddr-cs0_config_2, CONFIG_SYS_DDR_CS0_CONFIG_2);
+
+ out_be32(ddr-timing_cfg_3, CONFIG_SYS_DDR_TIMING_3_667);
+ out_be32(ddr-timing_cfg_0, CONFIG_SYS_DDR_TIMING_0_667);
+ out_be32(ddr-timing_cfg_1, CONFIG_SYS_DDR_TIMING_1_667);
+ out_be32(ddr-timing_cfg_2, CONFIG_SYS_DDR_TIMING_2_667);
+ out_be32(ddr-sdram_mode, CONFIG_SYS_DDR_MODE_1_667);
+ out_be32(ddr-sdram_mode_2, CONFIG_SYS_DDR_MODE_2_667);
+ out_be32(ddr-sdram_interval, CONFIG_SYS_DDR_INTERVAL_667);
+ out_be32(ddr-sdram_clk_cntl, CONFIG_SYS_DDR_CLK_CTRL_667);
+ out_be32(ddr-sdram_cfg, CONFIG_SYS_DDR_CONTROL);
+ out_be32(ddr-sdram_cfg_2, CONFIG_SYS_DDR_CONTROL_2);
did fsl_ddr_set_memctl_regs() not work?
This function will take more space as we have only 4K space here.
And this function contains 'printf' statements which is not valid.
So I think this is the simplest approach, as
fsl_ddr_set_memctl_regs()
is doing the same thing.
What do you suggest??
We can dummy out the printf. I'd prefer if we can try and use it.
It
unifies the register setting in one place which is key.
On Mon, 12 Oct 2009 12:01:32 +0530
Dudhat Dipen-B09055 dipen.dud...@freescale.com wrote:
I have tried using fsl_ddr_set_memctl_regs().
But this can't get fit into 4K NAND_SPL Loader.
by how much? Have you tried using raw i/o accessors (__raw_writel and
friends) instead of the usual out_be32, etc.?
with Kim on this, by how much.. or can you post the patch that does
that and I can take a look.
- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM pull request v3
Tom Rix wrote: ... Olof Johansson (3): ... SMC911X: Add chip auto detection This is broken [1] and doesn't work without http://git.denx.de/?p=u-boot/u-boot-ti.git;a=commit;h=e7911214d5aee1ba5eb160327d5ff305c9e6ee5a And while last re-organization of u-boot-ti http://git.denx.de/?p=u-boot/u-boot-ti.git;a=commit;h=83fb7d7bb237cc7adae37e0e3328c203fd1b9ad1 was lost, but now is there again. Maybe you like to cherry-pick both? Best regards Dirk [1] http://lists.denx.de/pipermail/u-boot/2009-October/062301.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] TI DaVinci: DM355 Leopard: Fix compilation warning
From: Sandeep Paulraj s-paul...@ti.com We get a compliation warning when we enable the NAND driver for DM355 leopard. The waring we get is that we have an implicit declaration of davinci_nand_init. It is fixed by including the asm/arch/nand_defs.h header file Signed-off-by: Sandeep Paulraj s-paul...@ti.com --- board/davinci/dm355leopard/dm355leopard.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/board/davinci/dm355leopard/dm355leopard.c b/board/davinci/dm355leopard/dm355leopard.c index 7350e8d..e89786e 100644 --- a/board/davinci/dm355leopard/dm355leopard.c +++ b/board/davinci/dm355leopard/dm355leopard.c @@ -21,6 +21,7 @@ #include asm/io.h #include asm/arch/hardware.h #include asm/arch/gpio_defs.h +#include asm/arch/nand_defs.h #include ../common/misc.h #include net.h #include netdev.h -- 1.6.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM pull request v3
Tom Rix wrote: ... Olof Johansson (3): ... SMC911X: Add chip auto detection This is broken [1] and doesn't work without http://git.denx.de/?p=u-boot/u-boot- ti.git;a=commit;h=e7911214d5aee1ba5eb160327d5ff305c9e6ee5a And while last re-organization of u-boot-ti http://git.denx.de/?p=u-boot/u-boot- ti.git;a=commit;h=83fb7d7bb237cc7adae37e0e3328c203fd1b9ad1 was lost, but now is there again. Maybe you like to cherry-pick both? I'll send out a pull request which will have these 2. I'll do that later today. Best regards Dirk [1] http://lists.denx.de/pipermail/u-boot/2009-October/062301.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Relocation size penalty calculation
Joakim Tjernlund wrote:
Graeme Russ graeme.r...@gmail.com wrote on 13/10/2009 13:21:05:
On Sun, Oct 11, 2009 at 11:51 PM, Joakim Tjernlund
joakim.tjernl...@transmode.se wrote:
Graeme Russ graeme.r...@gmail.com wrote on 11/10/2009 12:47:19:
[Massive Snip :)]
So, all that is left are .dynsym and .dynamic ...
.dynsym
- Contains 70 entries (16 bytes each, 1120 bytes)
- 44 entries mimic those entries in .got which are not relocated
- 21 entries are the remaining symbols exported from the linker
script
- 4 entries are labels defined in inline asm and used in C
Try adding proper asm declarations. Look at what gcc
generates for a function/variable and mimic these.
Thanks - Now .dynsym contains only exports from the linker script
:)
- 1 entry is a NULL entry
.dynamic
- 88 bytes
- Array of Elf32_Dyn
- typedef struct {
Elf32_Sword d_tag;
union {
Elf32_Word d_val;
Elf32_Addr d_ptr;
} d_un;
} Elf32_Dyn;
- 0x11 entries
[00] 0x0010, 0x DT_SYMBOLIC, (ignored)
[01] 0x0004, 0x38059994 DT_HASH, points to .hash
[02] 0x0005, 0x380595AB DT_STRTAB, points to .dynstr
[03] 0x0006, 0x3805BDCC DT_SYMTAB, points to .dynsym
[04] 0x000A, 0x03E6 DT_STRSZ, size of .dynstr
[05] 0x000B, 0x0010 DT_SYMENT, ???
[06] 0x0015, 0x DT_DEBUG, ???
[07] 0x0011, 0x3805A8F4 DT_REL, points to .rel.text
[08] 0x0012, 0x14D8 DT_RELSZ, ???
How big DT_REL is
[09] 0x0013, 0x0008 DT_RELENT, ???
hmm, cannot remeber :)
How big an entry in DT_REL is
Right, how could I forget :)
[0a] 0x0016, 0x DT_TEXTREL, ???
Oops, you got text relocations. This is generally a bad thing.
TEXTREL is commonly caused by asm code that arent truly pic so it needs
to modify the .text segment to adjust for relocation.
You should get rid of this one. Look for DT_TEXTREL in .o files to find
the culprit.
Alas I cannot - The relocations are a result of loading a register with a
return address when calling show_boot_progress in the very early stages of
initialisation prior to the stack becoming available. The x86 does not
allow direct access to the IP so the only way to find the 'current
execution address' is to 'call' to the next instruction and pop the return
address off the stack
hmm, same as ppc but that in it self should not cause a TEXREL, should it?
Ahh, the 'call' is absolute, not relative? I guess there is some way around it
but it is not important ATM I guess.
Evil idea, skip -fpic et. all and add the full reloc procedure
to relocate by rewriting directly in TEXT segment. Then you save space
but you need more relocation code. Something like dl_do_reloc from
uClibc. Wonder how much extra code that would be? Not too much I think.
I think this approach will turn out to be a big win. At present, the
problem with just using the relocs is that objcopy is stripping them out
when u-boot.bin is created, as I understand it. It seems this can be
solved by changing the command switches appropriately, like using
--strip-unneeded. In any case, there is some combination of switches
that will preserve the relocation data. The executable code will get
smaller, there will be no .got, and the relocation data will be larger
(than with -fpic). In total size, it probably will be slightly smaller,
but that is a guess. The most important benefit of this approach is that
it will work for all architectures, thereby solving the problem once and
forever! Even if the result is a bit larger, the RAM footprint will be
reduced by the smaller object code size (since the relocation data need
not be copied into ram).Having this approach as an option would be real
nice, since it would always just work.
Best Regards,
Bill Campbell
This is not a problem because this is very low-level init that is not
called once relocated into RAM - These relocations can be safely ignored
[0b] 0x6FFA, 0x0236 ???, Entries in .rel.dyn
[0c] 0x, 0x DT_NULL, End of Array
[0d] 0x, 0x DT_NULL, End of Array
[0e] 0x, 0x DT_NULL, End of Array
[0f] 0x, 0x DT_NULL, End of Array
[10] 0x, 0x DT_NULL, End of Array
I think some more investigation into the need for .dynsym and .dynamic is
still required...
.dynsym may still be required if only for accessing the __u_boot_cmd
structure. However, I may be able to hack that a little and not create a
__u_boot_cmd symbol in the linker script (create some other temporary
symbol) and populate __u_boot_cmd with a valid value after relocation. It
will look a little weird, but may mean
[U-Boot] [PATCH] TI DaVinci: Fix DM6467 EVM Compilation Warning
From: Sandeep Paulraj s-paul...@ti.com Due to new TI boards being added to U-Boot, the hardware.h is getting very messy. The warning being fixed is due to the EMIF addresses being redefined. The long term solution(after 2009.11) to this is to have SOC specific header files. Signed-off-by: Sandeep Paulraj s-paul...@ti.com --- include/asm-arm/arch-davinci/hardware.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/asm-arm/arch-davinci/hardware.h b/include/asm-arm/arch-davinci/hardware.h index ac32510..acf12ea 100644 --- a/include/asm-arm/arch-davinci/hardware.h +++ b/include/asm-arm/arch-davinci/hardware.h @@ -71,10 +71,12 @@ typedef volatile unsigned int * dv_reg_p; #define DAVINCI_SPI_BASE (0x01c66800) #define DAVINCI_GPIO_BASE (0x01c67000) #define DAVINCI_VPSS_REGS_BASE (0x01c7) +#if !defined(CONFIG_SOC_DM646X) #define DAVINCI_ASYNC_EMIF_DATA_CE0_BASE (0x0200) #define DAVINCI_ASYNC_EMIF_DATA_CE1_BASE (0x0400) #define DAVINCI_ASYNC_EMIF_DATA_CE2_BASE (0x0600) #define DAVINCI_ASYNC_EMIF_DATA_CE3_BASE (0x0800) +#endif #define DAVINCI_DDR_BASE (0x8000) #ifdef CONFIG_SOC_DM644X -- 1.6.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Relocation size penalty calculation
J. William Campbell jwilliamcampb...@comcast.net wrote on 13/10/2009
18:30:43:
Joakim Tjernlund wrote:
Graeme Russ graeme.r...@gmail.com wrote on 13/10/2009 13:21:05:
On Sun, Oct 11, 2009 at 11:51 PM, Joakim Tjernlund
joakim.tjernl...@transmode.se wrote:
Graeme Russ graeme.r...@gmail.com wrote on 11/10/2009 12:47:19:
[Massive Snip :)]
So, all that is left are .dynsym and .dynamic ...
.dynsym
- Contains 70 entries (16 bytes each, 1120 bytes)
- 44 entries mimic those entries in .got which are not relocated
- 21 entries are the remaining symbols exported from the linker
script
- 4 entries are labels defined in inline asm and used in C
Try adding proper asm declarations. Look at what gcc
generates for a function/variable and mimic these.
Thanks - Now .dynsym contains only exports from the linker script
:)
- 1 entry is a NULL entry
.dynamic
- 88 bytes
- Array of Elf32_Dyn
- typedef struct {
Elf32_Sword d_tag;
union {
Elf32_Word d_val;
Elf32_Addr d_ptr;
} d_un;
} Elf32_Dyn;
- 0x11 entries
[00] 0x0010, 0x DT_SYMBOLIC, (ignored)
[01] 0x0004, 0x38059994 DT_HASH, points to .hash
[02] 0x0005, 0x380595AB DT_STRTAB, points to .dynstr
[03] 0x0006, 0x3805BDCC DT_SYMTAB, points to .dynsym
[04] 0x000A, 0x03E6 DT_STRSZ, size of .dynstr
[05] 0x000B, 0x0010 DT_SYMENT, ???
[06] 0x0015, 0x DT_DEBUG, ???
[07] 0x0011, 0x3805A8F4 DT_REL, points to .rel.text
[08] 0x0012, 0x14D8 DT_RELSZ, ???
How big DT_REL is
[09] 0x0013, 0x0008 DT_RELENT, ???
hmm, cannot remeber :)
How big an entry in DT_REL is
Right, how could I forget :)
[0a] 0x0016, 0x DT_TEXTREL, ???
Oops, you got text relocations. This is generally a bad thing.
TEXTREL is commonly caused by asm code that arent truly pic so it needs
to modify the .text segment to adjust for relocation.
You should get rid of this one. Look for DT_TEXTREL in .o files to find
the culprit.
Alas I cannot - The relocations are a result of loading a register with a
return address when calling show_boot_progress in the very early stages of
initialisation prior to the stack becoming available. The x86 does not
allow direct access to the IP so the only way to find the 'current
execution address' is to 'call' to the next instruction and pop the return
address off the stack
hmm, same as ppc but that in it self should not cause a TEXREL, should it?
Ahh, the 'call' is absolute, not relative? I guess there is some way around
it
but it is not important ATM I guess.
Evil idea, skip -fpic et. all and add the full reloc procedure
to relocate by rewriting directly in TEXT segment. Then you save space
but you need more relocation code. Something like dl_do_reloc from
uClibc. Wonder how much extra code that would be? Not too much I think.
I think this approach will turn out to be a big win. At present, the
problem with just using the relocs is that objcopy is stripping them out
when u-boot.bin is created, as I understand it. It seems this can be
solved by changing the command switches appropriately, like using
--strip-unneeded. In any case, there is some combination of switches
that will preserve the relocation data. The executable code will get
smaller, there will be no .got, and the relocation data will be larger
(than with -fpic). In total size, it probably will be slightly smaller,
but that is a guess. The most important benefit of this approach is that
it will work for all architectures, thereby solving the problem once and
forever! Even if the result is a bit larger, the RAM footprint will be
reduced by the smaller object code size (since the relocation data need
not be copied into ram).Having this approach as an option would be real
nice, since it would always just work.
Yes, I had this in the back of my head. I do think some other arch than ppc
will have to try this out though :)
I am not 100% sure this will work with my end goal, true PIC so I can load
the same img anywhere in flash.
Jocke
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add mpc5125ads board and processor to the mpc512x family
Hi Wolfgang,
I had to chuckle when I read your opening paragraph – let me say that I have
never thought of myself as a victim – even at the hands of these FSL silicon
guys!!! But I did get a pretty raw deal – yes.
Now I am going to respond a little before I go and resubmit.
Very Best Regards,
Martha
diff --git a/cpu/mpc512x/asm-offsets.h b/cpu/mpc512x/asm-offsets.h
index 4b14778..b79c656 100644
--- a/cpu/mpc512x/asm-offsets.h
+++ b/cpu/mpc512x/asm-offsets.h
@@ -11,5 +11,11 @@
#define CS_CTRL 0x00020
#define CS_CTRL_ME 0x0100 /* CS Master Enable bit */
+/* needed for pin muxing in MPC5125 */
+#define IOCTRL_OFFSET0xA000
+#define IOCTRL_LPC_AX03 0x09
+#define IOCTRL_I2C1_SCL 0x4f
+#define IOCTRL_I2C1_SDA 0x50
We should avoid adding stuff to asm-offsets.h; instead, we should
finally auto-generate this file from the respective C structs as it's
done in Linux. Do you dare to tackle this?
I can't do this any time soon Wolfgang … I work part-time now (post wedding
issues to take care of).
diff --git a/cpu/mpc512x/fixed_sdram.c b/cpu/mpc512x/fixed_sdram.c
index 673d61e..09985e7 100644
--- a/cpu/mpc512x/fixed_sdram.c
+++ b/cpu/mpc512x/fixed_sdram.c
@@ -36,6 +36,7 @@ u32 default_mddrc_config[4] = {
};
u32 default_init_seq[] = {
+#ifndef CONFIG_SYS_DDR_OVRIDE_DEF /* makes it unnecessary to declare these
*/
CONFIG_SYS_DDRCMD_NOP,
CONFIG_SYS_DDRCMD_NOP,
CONFIG_SYS_DDRCMD_NOP,
@@ -67,6 +68,7 @@ u32 default_init_seq[] = {
CONFIG_SYS_DDRCMD_OCD_DEFAULT,
CONFIG_SYS_DDRCMD_PCHG_ALL,
CONFIG_SYS_DDRCMD_NOP
+#endif
};
NAK. Please don't add #ifdef's here. This is the default init
sequence, and if it does not fit your purposes, then please use a
private one.
Yes but the default has constants like CONFIG_SYS_MICRON_INIT_DEV_OP … must I
then declare this if I am using CONFIG_SYS_ELPIDA_INIT_DEV_OP ?
The default constants are a large mem array that just plain doesn't need to be
there if you must override it anyway. I don't understand the impetus to save
on printf strings, for example, and not wanting to save here ???
/* Initialize IO Control */
+#ifdef CONFIG_MPC5125
+ out_8(im-io_ctrl.io_control_mem, IOCTRL_MUX_DDR);
+#else
out_be32(im-io_ctrl.io_control_mem, IOCTRL_MUX_DDR);
+#endif
This is something which happens a lot in the remaining code - so often
that it is plain unacceptable. As mentioned above, I know that you are
just a victim here, but we need a less ugly implementation.
Actually – since I redid the entire iopin_initialize function to a separate one
for the mpc5125 this is the only place where an ugly #ifdef'ed iopin init
occurs now.
If I understand correctly, all MPC512x actually use 8 bit only here,
even though the register declarations on MPC5121/5123 are 32 bit
wide. Eventually we should do what Grant Likely already did in the
Linux kernel and change all thjis code to use 8 bit accesses only,
which means to add the needed padding to the respective data stricts
- similar to what was done to make the 16550 serial driver really
generic.
However, this is a pretty invasive operation, that will have to wait
for the next release in any case. And actually I would like to delay
this until at least an official Reference Manual for the MPC5125 has
been publicly released by Freescale.
As I said – since I redid the iopin_initialize (there are now 2 different
functions) I don't think this is necessary … it's not just a size difference …
there is also a bit configuration difference. I redid the #define for this
too. Also .. the elements within the struct are all different.
diff --git a/cpu/mpc512x/serial.c b/cpu/mpc512x/serial.c
index 4fc4693..89fa139 100644
--- a/cpu/mpc512x/serial.c
+++ b/cpu/mpc512x/serial.c
@@ -80,7 +80,7 @@ int serial_init(void)
volatile psc512x_t *psc = (psc512x_t *) im-psc[CONFIG_PSC_CONSOLE];
fifo_init (psc);
-
+#ifndef CONFIG_MPC5125
/* set MR register to point to MR1 */
out_8(psc-command, PSC_SEL_MODE_REG_1);
@@ -93,12 +93,25 @@ int serial_init(void)
/* switch to UART mode */
out_be32(psc-sicr, 0);
- /* mode register points to mr1 */
/* configure parity, bit length and so on in mode register 1*/
+ /* mode register points to mr1 */
out_8(psc-mode, PSC_MODE_8_BITS | PSC_MODE_PARNONE);
/* now, mode register points to mr2 */
out_8(psc-mode, PSC_MODE_1_STOPBIT);
+#else
+ /* disable Tx/Rx */
+ out_8(psc-command, PSC_TX_DISABLE | PSC_RX_DISABLE);
+
+ /* choose the prescaler the Tx/Rx clock generation */
+ out_8(psc-psc_clock_select, 0xdd);
+
+ /* switch to UART mode */
+ out_be32(psc-sicr, 0);
+ /* configure parity, bit length and so on in mode registers */
+ out_8(psc-mr1, PSC_MODE_8_BITS | PSC_MODE_PARNONE);
+ out_8(psc-mr2, PSC_MODE_1_STOPBIT);
Re: [U-Boot] [PATCH] TI DaVinci: DM355 Leopard: Fix compilation warning
From: Sandeep Paulraj s-paul...@ti.com We get a compliation warning when we enable the NAND driver for DM355 leopard. The waring we get is that we have an implicit declaration of davinci_nand_init. It is fixed by including the asm/arch/nand_defs.h header file Signed-off-by: Sandeep Paulraj s-paul...@ti.com --- board/davinci/dm355leopard/dm355leopard.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/board/davinci/dm355leopard/dm355leopard.c b/board/davinci/dm355leopard/dm355leopard.c index 7350e8d..e89786e 100644 --- a/board/davinci/dm355leopard/dm355leopard.c +++ b/board/davinci/dm355leopard/dm355leopard.c @@ -21,6 +21,7 @@ #include asm/io.h #include asm/arch/hardware.h #include asm/arch/gpio_defs.h +#include asm/arch/nand_defs.h #include ../common/misc.h #include net.h #include netdev.h -- 1.6.0.4 I'll take the liberty to push this to u-boot-ti master (2 hours after I submitted) in preparation for a pull request to Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Relocation size penalty calculation
On Tue, Oct 13, 2009 at 10:53 PM, Joakim Tjernlund
joakim.tjernl...@transmode.se wrote:
Graeme Russ graeme.r...@gmail.com wrote on 13/10/2009 13:21:05:
On Sun, Oct 11, 2009 at 11:51 PM, Joakim Tjernlund
joakim.tjernl...@transmode.se wrote:
Graeme Russ graeme.r...@gmail.com wrote on 11/10/2009 12:47:19:
[Massive Snip :)]
So, all that is left are .dynsym and .dynamic ...
.dynsym
- Contains 70 entries (16 bytes each, 1120 bytes)
- 44 entries mimic those entries in .got which are not relocated
- 21 entries are the remaining symbols exported from the linker
script
- 4 entries are labels defined in inline asm and used in C
Try adding proper asm declarations. Look at what gcc
generates for a function/variable and mimic these.
Thanks - Now .dynsym contains only exports from the linker script
:)
- 1 entry is a NULL entry
.dynamic
- 88 bytes
- Array of Elf32_Dyn
- typedef struct {
Elf32_Sword d_tag;
union {
Elf32_Word d_val;
Elf32_Addr d_ptr;
} d_un;
} Elf32_Dyn;
- 0x11 entries
[00] 0x0010, 0x DT_SYMBOLIC, (ignored)
[01] 0x0004, 0x38059994 DT_HASH, points to .hash
[02] 0x0005, 0x380595AB DT_STRTAB, points to .dynstr
[03] 0x0006, 0x3805BDCC DT_SYMTAB, points to .dynsym
[04] 0x000A, 0x03E6 DT_STRSZ, size of .dynstr
[05] 0x000B, 0x0010 DT_SYMENT, ???
[06] 0x0015, 0x DT_DEBUG, ???
[07] 0x0011, 0x3805A8F4 DT_REL, points to .rel.text
[08] 0x0012, 0x14D8 DT_RELSZ, ???
How big DT_REL is
[09] 0x0013, 0x0008 DT_RELENT, ???
hmm, cannot remeber :)
How big an entry in DT_REL is
Right, how could I forget :)
[0a] 0x0016, 0x DT_TEXTREL, ???
Oops, you got text relocations. This is generally a bad thing.
TEXTREL is commonly caused by asm code that arent truly pic so it needs
to modify the .text segment to adjust for relocation.
You should get rid of this one. Look for DT_TEXTREL in .o files to find
the culprit.
Alas I cannot - The relocations are a result of loading a register with a
return address when calling show_boot_progress in the very early stages of
initialisation prior to the stack becoming available. The x86 does not
allow direct access to the IP so the only way to find the 'current
execution address' is to 'call' to the next instruction and pop the return
address off the stack
hmm, same as ppc but that in it self should not cause a TEXREL, should it?
Ahh, the 'call' is absolute, not relative? I guess there is some way around it
but it is not important ATM I guess.
Evil idea, skip -fpic et. all and add the full reloc procedure
to relocate by rewriting directly in TEXT segment. Then you save space
but you need more relocation code. Something like dl_do_reloc from
uClibc. Wonder how much extra code that would be? Not too much I think.
With the following flags
PLATFORM_RELFLAGS += -fvisibility=hidden
PLATFORM_CPPFLAGS += -fno-dwarf2-cfi-asm
PLATFORM_LDFLAGS += -pic --emit-relocs -Bsymbolic -Bsymbolic-functions
I get no .got, but a lot of R_386_PC32 and R_386_32 relocations. I think
this might mean I need the symbol table in the binary in order to resolve
them
This is not a problem because this is very low-level init that is not
called once relocated into RAM - These relocations can be safely ignored
[0b] 0x6FFA, 0x0236 ???, Entries in .rel.dyn
[0c] 0x, 0x DT_NULL, End of Array
[0d] 0x, 0x DT_NULL, End of Array
[0e] 0x, 0x DT_NULL, End of Array
[0f] 0x, 0x DT_NULL, End of Array
[10] 0x, 0x DT_NULL, End of Array
I think some more investigation into the need for .dynsym and .dynamic is
still required...
.dynsym may still be required if only for accessing the __u_boot_cmd
structure. However, I may be able to hack that a little and not create a
__u_boot_cmd symbol in the linker script (create some other temporary
symbol) and populate __u_boot_cmd with a valid value after relocation. It
will look a little weird, but may mean not loading this section into RAM
Why do you need to much around with u_boot_cmd at all? Now that relocation
works you should be able to drop all that code/linker stuff?
Other than that, .dynsym is now only needed to locate the sections during
the relocation phase and can be kept in flash and not copied to RAM
Still occupies space in the *bin image though.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Relocation size penalty calculation
Graeme Russ graeme.r...@gmail.com wrote on 13/10/2009 22:06:56:
On Tue, Oct 13, 2009 at 10:53 PM, Joakim Tjernlund
joakim.tjernl...@transmode.se wrote:
Graeme Russ graeme.r...@gmail.com wrote on 13/10/2009 13:21:05:
On Sun, Oct 11, 2009 at 11:51 PM, Joakim Tjernlund
joakim.tjernl...@transmode.se wrote:
Graeme Russ graeme.r...@gmail.com wrote on 11/10/2009 12:47:19:
[Massive Snip :)]
So, all that is left are .dynsym and .dynamic ...
.dynsym
- Contains 70 entries (16 bytes each, 1120 bytes)
- 44 entries mimic those entries in .got which are not relocated
- 21 entries are the remaining symbols exported from the linker
script
- 4 entries are labels defined in inline asm and used in C
Try adding proper asm declarations. Look at what gcc
generates for a function/variable and mimic these.
Thanks - Now .dynsym contains only exports from the linker script
:)
- 1 entry is a NULL entry
.dynamic
- 88 bytes
- Array of Elf32_Dyn
- typedef struct {
Elf32_Sword d_tag;
union {
Elf32_Word d_val;
Elf32_Addr d_ptr;
} d_un;
} Elf32_Dyn;
- 0x11 entries
[00] 0x0010, 0x DT_SYMBOLIC, (ignored)
[01] 0x0004, 0x38059994 DT_HASH, points to .hash
[02] 0x0005, 0x380595AB DT_STRTAB, points to .dynstr
[03] 0x0006, 0x3805BDCC DT_SYMTAB, points to .dynsym
[04] 0x000A, 0x03E6 DT_STRSZ, size of .dynstr
[05] 0x000B, 0x0010 DT_SYMENT, ???
[06] 0x0015, 0x DT_DEBUG, ???
[07] 0x0011, 0x3805A8F4 DT_REL, points to .rel.text
[08] 0x0012, 0x14D8 DT_RELSZ, ???
How big DT_REL is
[09] 0x0013, 0x0008 DT_RELENT, ???
hmm, cannot remeber :)
How big an entry in DT_REL is
Right, how could I forget :)
[0a] 0x0016, 0x DT_TEXTREL, ???
Oops, you got text relocations. This is generally a bad thing.
TEXTREL is commonly caused by asm code that arent truly pic so it needs
to modify the .text segment to adjust for relocation.
You should get rid of this one. Look for DT_TEXTREL in .o files to find
the culprit.
Alas I cannot - The relocations are a result of loading a register with a
return address when calling show_boot_progress in the very early stages of
initialisation prior to the stack becoming available. The x86 does not
allow direct access to the IP so the only way to find the 'current
execution address' is to 'call' to the next instruction and pop the return
address off the stack
hmm, same as ppc but that in it self should not cause a TEXREL, should it?
Ahh, the 'call' is absolute, not relative? I guess there is some way around
it
but it is not important ATM I guess.
Evil idea, skip -fpic et. all and add the full reloc procedure
to relocate by rewriting directly in TEXT segment. Then you save space
but you need more relocation code. Something like dl_do_reloc from
uClibc. Wonder how much extra code that would be? Not too much I think.
With the following flags
PLATFORM_RELFLAGS += -fvisibility=hidden
PLATFORM_CPPFLAGS += -fno-dwarf2-cfi-asm
PLATFORM_LDFLAGS += -pic --emit-relocs -Bsymbolic -Bsymbolic-functions
I get no .got, but a lot of R_386_PC32 and R_386_32 relocations. I think
this might mean I need the symbol table in the binary in order to resolve
them
Possibly, but I think you only need to add an offset to all those
relocs.
Jokce
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC] [mpc8xxx_spi] enabling driver to support MPC8360e SPI in cpu-mode
Hi,
I am working on getting u-boot (circa 2009.08) to program an SPI flash (STMicro
M25P40)
that contains the equations for our board's fpga.
While looking at mpc8xxx_spi I realized it is coded for a non-QUICC-Engine
based SPI flavor of 8xxx.
I worked up this patch that compiles for mpc8360e. I'd like to share to get
some sanity check if this is
a good approach that have a hope of being mainlined. The idea is to use the
MPC8360e SPI controller
in cpu-mode, in which case SOME bits are different, but none are being used at
the moment.
Another approach I looked at is the /cpu/mpc8260/spi.c but I think this will
eventually be superseded by mpc_8xxx.spi, no?
Right now I'm stuck in the transfer timing out. With a slight head-scratching
at this comment:
/*
* Wait for SPI transmit to get out
* or time out (1 second = 1000 ms)
* The NE event must be read and cleared first
*/
Yet in the loop I don't see any udelay(1000) to get us to 1second (based on
SPI_TIMEOUT = 1000)
am I missing something here?
This is what I've done so far to compile with mpc8360
-
diff --git a/drivers/spi/mpc8xxx_spi.c b/drivers/spi/mpc8xxx_spi.c
index c4b36f0..ff4b44e 100644
--- a/drivers/spi/mpc8xxx_spi.c
+++ b/drivers/spi/mpc8xxx_spi.c
@@ -27,14 +27,27 @@
#include spi.h
#include asm/mpc8xxx_spi.h
+#if defined (CONFIG_MPC8360)
+#include asm/immap_qe.h
+#endif
+
+#if defined (CONFIG_MPC8360)
+#define SPI_EV_NE (0x80 6) /* Receiver Not Empty */
+#define SPI_EV_NF (0x80 7) /* Transmitter Not Full */
+#else
#define SPI_EV_NE (0x8000 22) /* Receiver Not Empty */
#define SPI_EV_NF (0x8000 23) /* Transmitter Not Full */
+#endif
#define SPI_MODE_LOOP (0x8000 1) /* Loopback mode */
#define SPI_MODE_REV (0x8000 5) /* Reverse mode - MSB first */
#define SPI_MODE_MS (0x8000 6) /* Always master */
#define SPI_MODE_EN (0x8000 7) /* Enable interface */
+#if defined (CONFIG_MPC8360)
+#define SPI_MODE_OP(0x8000 17) /* CPU mode */
+#endif
+
#define SPI_TIMEOUT 1000
struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
@@ -67,6 +80,22 @@ void spi_free_slave(struct spi_slave *slave)
void spi_init(void)
{
+#if defined (CONFIG_MPC8360)
+ volatile immap_t *im = (volatile immap_t *)CONFIG_SYS_IMMR;
+ volatile qe_map_t *qe = (volatile qe_map_t *)im-qe;
+ volatile spi_t *spi = (volatile spi_t *)qe-spi;
+
+ /*
+* SPI pins on the MPC83xx are not muxed, so all we do is initialize
+* some registers (mode must be CPU mode to use this driver)
+*/
+ spi-mode = SPI_MODE_REV | SPI_MODE_MS | SPI_MODE_EN | SPI_MODE_OP;
+ spi-mode = (spi-mode 0xfff0) | (1 16); /* Use QE_CLK / 16
+(12.5 MHz typ.) */
+ spi-event = 0xff; /* Clear all SPI events */
+ spi-mask = 0x00; /* Mask all SPI interrupts */
+ spi-com = 0; /* LST bit doesn't do anything, so disregard */
+#else
volatile spi8xxx_t *spi = ((immap_t *) (CONFIG_SYS_IMMR))-spi;
/*
@@ -79,6 +108,8 @@ void spi_init(void)
spi-event = 0x;/* Clear all SPI events */
spi-mask = 0x; /* Mask all SPI interrupts */
spi-com = 0; /* LST bit doesn't do anything, so disregard */
+#endif
+
}
int spi_claim_bus(struct spi_slave *slave)
@@ -94,19 +125,32 @@ void spi_release_bus(struct spi_slave *slave)
int spi_xfer(struct spi_slave *slave, unsigned int bitlen, const void *dout,
void *din, unsigned long flags)
{
+#if defined (CONFIG_MPC8360)
+ volatile immap_t *im = (volatile immap_t *)CONFIG_SYS_IMMR;
+ volatile qe_map_t *qe = (volatile qe_map_t *)im-qe;
+ volatile spi_t *spi = (volatile spi_t *)qe-spi;
+ unsigned short event;
+#else
volatile spi8xxx_t *spi = ((immap_t *) (CONFIG_SYS_IMMR))-spi;
- unsigned int tmpdout, tmpdin, event;
+ unsigned int event;
+#endif
+
+ unsigned int tmpdout, tmpdin;
int numBlks = bitlen / 32 + (bitlen % 32 ? 1 : 0);
int tm, isRead = 0;
unsigned char charSize = 32;
- debug(spi_xfer: slave %u:%u dout %08X din %08X bitlen %u\n,
+ printf(spi_xfer: slave %u:%u dout %08X din %08X bitlen %u\n,
slave-bus, slave-cs, *(uint *) dout, *(uint *) din, bitlen);
if (flags SPI_XFER_BEGIN)
spi_cs_activate(slave);
+#if defined (CONFIG_MPC8360)
+ spi-event = 0xff; /* Clear all SPI events */
+#else
spi-event = 0x;/* Clear all SPI events */
+#endif
/* handle data in 32-bit chunks */
while (numBlks--) {
@@ -139,7 +183,7 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen,
const void *dout,
}
spi-tx = tmpdout; /* Write the data
[U-Boot] [PATCH] TI DaVinci: Adding Copyright for DM365 EVM
From: Sandeep Paulraj s-paul...@ti.com Forgot to add Copyright while submitting the patch. This patch adds the copyright. Signed-off-by: Sandeep Paulraj s-paul...@ti.com --- board/davinci/dm365evm/dm365evm.c |1 + include/configs/davinci_dm365evm.h |1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/board/davinci/dm365evm/dm365evm.c b/board/davinci/dm365evm/dm365evm.c index 1e3a14f..290eb99 100644 --- a/board/davinci/dm365evm/dm365evm.c +++ b/board/davinci/dm365evm/dm365evm.c @@ -1,4 +1,5 @@ /* + * Copyright (C) 2009 Texas Instruments Incorporated * * 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 diff --git a/include/configs/davinci_dm365evm.h b/include/configs/davinci_dm365evm.h index f715da3..53a105b 100644 --- a/include/configs/davinci_dm365evm.h +++ b/include/configs/davinci_dm365evm.h @@ -1,4 +1,5 @@ /* + * Copyright (C) 2009 Texas Instruments Incorporated * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License as -- 1.6.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Relocation size penalty calculation
Joakim Tjernlund wrote:
Graeme Russ graeme.r...@gmail.com wrote on 13/10/2009 22:06:56:
On Tue, Oct 13, 2009 at 10:53 PM, Joakim Tjernlund
joakim.tjernl...@transmode.se wrote:
Graeme Russ graeme.r...@gmail.com wrote on 13/10/2009 13:21:05:
On Sun, Oct 11, 2009 at 11:51 PM, Joakim Tjernlund
joakim.tjernl...@transmode.se wrote:
Graeme Russ graeme.r...@gmail.com wrote on 11/10/2009 12:47:19:
[Massive Snip :)]
So, all that is left are .dynsym and .dynamic ...
.dynsym
- Contains 70 entries (16 bytes each, 1120 bytes)
- 44 entries mimic those entries in .got which are not relocated
- 21 entries are the remaining symbols exported from the linker
script
- 4 entries are labels defined in inline asm and used in C
Try adding proper asm declarations. Look at what gcc
generates for a function/variable and mimic these.
Thanks - Now .dynsym contains only exports from the linker script
:)
- 1 entry is a NULL entry
.dynamic
- 88 bytes
- Array of Elf32_Dyn
- typedef struct {
Elf32_Sword d_tag;
union {
Elf32_Word d_val;
Elf32_Addr d_ptr;
} d_un;
} Elf32_Dyn;
- 0x11 entries
[00] 0x0010, 0x DT_SYMBOLIC, (ignored)
[01] 0x0004, 0x38059994 DT_HASH, points to .hash
[02] 0x0005, 0x380595AB DT_STRTAB, points to .dynstr
[03] 0x0006, 0x3805BDCC DT_SYMTAB, points to .dynsym
[04] 0x000A, 0x03E6 DT_STRSZ, size of .dynstr
[05] 0x000B, 0x0010 DT_SYMENT, ???
[06] 0x0015, 0x DT_DEBUG, ???
[07] 0x0011, 0x3805A8F4 DT_REL, points to .rel.text
[08] 0x0012, 0x14D8 DT_RELSZ, ???
How big DT_REL is
[09] 0x0013, 0x0008 DT_RELENT, ???
hmm, cannot remeber :)
How big an entry in DT_REL is
Right, how could I forget :)
[0a] 0x0016, 0x DT_TEXTREL, ???
Oops, you got text relocations. This is generally a bad thing.
TEXTREL is commonly caused by asm code that arent truly pic so it needs
to modify the .text segment to adjust for relocation.
You should get rid of this one. Look for DT_TEXTREL in .o files to find
the culprit.
Alas I cannot - The relocations are a result of loading a register with a
return address when calling show_boot_progress in the very early stages of
initialisation prior to the stack becoming available. The x86 does not
allow direct access to the IP so the only way to find the 'current
execution address' is to 'call' to the next instruction and pop the return
address off the stack
hmm, same as ppc but that in it self should not cause a TEXREL, should it?
Ahh, the 'call' is absolute, not relative? I guess there is some way around
it
but it is not important ATM I guess.
Evil idea, skip -fpic et. all and add the full reloc procedure
to relocate by rewriting directly in TEXT segment. Then you save space
but you need more relocation code. Something like dl_do_reloc from
uClibc. Wonder how much extra code that would be? Not too much I think.
With the following flags
PLATFORM_RELFLAGS += -fvisibility=hidden
PLATFORM_CPPFLAGS += -fno-dwarf2-cfi-asm
PLATFORM_LDFLAGS += -pic --emit-relocs -Bsymbolic -Bsymbolic-functions
I get no .got, but a lot of R_386_PC32 and R_386_32 relocations. I think
this might mean I need the symbol table in the binary in order to resolve
them
Possibly, but I think you only need to add an offset to all those
relocs.
Almost right. The relocations specify a symbol value that needs to be
added to the data in memory to relocate the reference. The symbol values
involved should be the start of the text section for program references,
the start of the uninitialized data section for bss references, and the
start of the data section for initialized data and constants. So there
are about four symbols whose value you need to keep. Take a look at
http://refspecs.freestandards.org/elf/elf.pdf (which you have probably
already looked at) and it tells you what to do with R_386_PC32 ad
R_386_32 relocations. Hopefully the objcopy with the --strip-unneeded
will remove all the symbols you don't actually need, but I don't know
that for sure. Note also that you can change the section flags of a
section marked noload to load.
Best Regards,
Bill Campbell
Jokce
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Running concurrent applications
I'd like to know whether it is possible to run two or more concurrent executables from the u-boot command prompt. There is no operating systems running on the machine and I just need to run two applications concurrently. Thanks a lot. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Running concurrent applications
On Tuesday 13 October 2009 21:00:09 Salvatore Campagna wrote: I'd like to know whether it is possible to run two or more concurrent executables from the u-boot command prompt. There is no operating systems running on the machine and I just need to run two applications concurrently. as you said, there's no OS. boot one if you want this kind of thing -- u-boot is not an OS. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] TI DaVinci: Fix DM6467 EVM Compilation Warning
s-paul...@ti.com wrote: From: Sandeep Paulraj s-paul...@ti.com Due to new TI boards being added to U-Boot, the hardware.h is getting very messy. The warning being fixed is due to the EMIF addresses being redefined. The long term solution(after 2009.11) to this is to have SOC specific header files. Signed-off-by: Sandeep Paulraj s-paul...@ti.com --- include/asm-arm/arch-davinci/hardware.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/asm-arm/arch-davinci/hardware.h b/include/asm-arm/arch-davinci/hardware.h index ac32510..acf12ea 100644 --- a/include/asm-arm/arch-davinci/hardware.h +++ b/include/asm-arm/arch-davinci/hardware.h @@ -71,10 +71,12 @@ typedef volatile unsigned int * dv_reg_p; #define DAVINCI_SPI_BASE (0x01c66800) #define DAVINCI_GPIO_BASE(0x01c67000) #define DAVINCI_VPSS_REGS_BASE (0x01c7) +#if !defined(CONFIG_SOC_DM646X) #define DAVINCI_ASYNC_EMIF_DATA_CE0_BASE (0x0200) #define DAVINCI_ASYNC_EMIF_DATA_CE1_BASE (0x0400) #define DAVINCI_ASYNC_EMIF_DATA_CE2_BASE (0x0600) #define DAVINCI_ASYNC_EMIF_DATA_CE3_BASE (0x0800) +#endif #define DAVINCI_DDR_BASE (0x8000) #ifdef CONFIG_SOC_DM644X You have already pushed this so mostly this is for the future.. This can be cleaned up so the default #defines are set only if they are not already defined by the board. Or handled with the board files are you are planning. Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] TI DaVinci: Adding Copyright for DM365 EVM
s-paul...@ti.com wrote: From: Sandeep Paulraj s-paul...@ti.com Forgot to add Copyright while submitting the patch. This patch adds the copyright. Signed-off-by: Sandeep Paulraj s-paul...@ti.com --- board/davinci/dm365evm/dm365evm.c |1 + include/configs/davinci_dm365evm.h |1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/board/davinci/dm365evm/dm365evm.c b/board/davinci/dm365evm/dm365evm.c index 1e3a14f..290eb99 100644 --- a/board/davinci/dm365evm/dm365evm.c +++ b/board/davinci/dm365evm/dm365evm.c @@ -1,4 +1,5 @@ /* + * Copyright (C) 2009 Texas Instruments Incorporated * * 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 diff --git a/include/configs/davinci_dm365evm.h b/include/configs/davinci_dm365evm.h index f715da3..53a105b 100644 --- a/include/configs/davinci_dm365evm.h +++ b/include/configs/davinci_dm365evm.h @@ -1,4 +1,5 @@ /* + * Copyright (C) 2009 Texas Instruments Incorporated * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License as Ack-ed Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Blackfin: drop MAC display at boot
The default Blackfin boot would display the MAC address for the first NIC, but this relies on the environment. The current net multi stack no longer writes the default hardware settings to the environment, so most of the time the display shows all zeros. This can be pretty confusing and really doesn't add anything useful, so just drop it. Signed-off-by: Mike Frysinger vap...@gentoo.org --- lib_blackfin/board.c |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/lib_blackfin/board.c b/lib_blackfin/board.c index bf943ea..6cade7d 100644 --- a/lib_blackfin/board.c +++ b/lib_blackfin/board.c @@ -278,7 +278,6 @@ static void board_net_init_r(bd_t *bd) bb_miiphy_init(); #endif #ifdef CONFIG_CMD_NET - uchar enetaddr[6]; char *s; if ((s = getenv(bootfile)) != NULL) @@ -288,9 +287,6 @@ static void board_net_init_r(bd_t *bd) printf(Net: ); eth_initialize(gd-bd); - - eth_getenv_enetaddr(ethaddr, enetaddr); - printf(MAC: %pM\n, enetaddr); #endif } -- 1.6.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] TI DaVinci: Fix DM6467 EVM Compilation Warning
-Original Message- From: Tom Rix [mailto:t...@bumblecow.com] Sent: Tuesday, October 13, 2009 9:49 PM To: Paulraj, Sandeep Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] TI DaVinci: Fix DM6467 EVM Compilation Warning s-paul...@ti.com wrote: From: Sandeep Paulraj s-paul...@ti.com Due to new TI boards being added to U-Boot, the hardware.h is getting very messy. The warning being fixed is due to the EMIF addresses being redefined. The long term solution(after 2009.11) to this is to have SOC specific header files. Signed-off-by: Sandeep Paulraj s-paul...@ti.com --- include/asm-arm/arch-davinci/hardware.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/asm-arm/arch-davinci/hardware.h b/include/asm- arm/arch-davinci/hardware.h index ac32510..acf12ea 100644 --- a/include/asm-arm/arch-davinci/hardware.h +++ b/include/asm-arm/arch-davinci/hardware.h @@ -71,10 +71,12 @@ typedef volatile unsigned int * dv_reg_p; #define DAVINCI_SPI_BASE (0x01c66800) #define DAVINCI_GPIO_BASE (0x01c67000) #define DAVINCI_VPSS_REGS_BASE (0x01c7) +#if !defined(CONFIG_SOC_DM646X) #define DAVINCI_ASYNC_EMIF_DATA_CE0_BASE (0x0200) #define DAVINCI_ASYNC_EMIF_DATA_CE1_BASE (0x0400) #define DAVINCI_ASYNC_EMIF_DATA_CE2_BASE (0x0600) #define DAVINCI_ASYNC_EMIF_DATA_CE3_BASE (0x0800) +#endif #define DAVINCI_DDR_BASE (0x8000) #ifdef CONFIG_SOC_DM644X You have already pushed this so mostly this is for the future.. This can be cleaned up so the default #defines are set only if they are not already defined by the board. Or handled with the board files are you are planning. I will clean it up soon. But this will be considered a feature and thus cannot make it to 2009.11; hence this quick fix solution. In fact I might work on the clean up this weekend and even send for review but even if accepted, I will have to keep it in my next Tom Sandeep ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Running u-boot without relocation to RAM?
alfred steele wrote: So is it possible to completly disable the relocation process at startup and run U-Boot with having opcode in PROM and data in RAM? If yes, how could I achieve this? I already tried to remove the corresponding code in the start.S and searched the README for switches, but without success. Did you try the CONFIG_SKIP_RELOCATE_UBOOT ? I am not sure if it serves your purpose here. It depends upon whether or not your start.S uses it at all. -Alfred Tobias can try CONFIG_SKIP_RELOCATE_UBOOT, but it isn't likely to work as is. That flag is to configure u-boot to be loaded directly into RAM and run out of RAM (i.e. no relocation from flash to RAM). U-Boot was not designed to run from flash (aka. XIP - eXecute In Place) and nobody has done that as far as I know. That doesn't mean u-boot cannot run XIP, it means that it will take an unknown amount of effort to make it happen. gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] NET: SDP3430: trouble with shifting from LAN9C916 to SMC91XX driver
Hi Folks,
While attempting to address the warning for SDP3430 as pointed out by
dirk in [1], I did a patch corresponding to what was done for EVM(353x)
as in [2]. unfortunately, this wont work for me, I get:
U-Boot 2009.08-00515-gfea6a55-dirty (Oct 12 2009 - 14:03:23)
OMAP3530-GP ES3.0, CPU-OPP2 L3-165MHz
OMAP3 SDP3430 board + LPDDR/NOR
I2C: ready
DRAM: 128 MB
Flash: 128 MB
In:serial
Out: serial
Err: serial
smc911x: Invalid chip endian 0xdee0013d
Net: No ethernet found.
OMAP34XX SDP #
and no network, using LEGACY driver seems to be working just great for me.
Note: in my patch [2], I did try both CONFIG_SMC911X_32_BIT and
CONFIG_SMC911X_16_BIT with no luck either way. I even tried to hack the
driver by skipping the supported chip detection code, but the driver
still did not work for me.
scanning a little more in the git repo, I see all the ancient boards of
OMAP family - 5912,2420 etc.. still have LEGACY driver being used..
I am pretty sure I must be missing something here and appreciate any
guidance folks can give me on this..
--
Regards,
Nishanth Menon
Ref:
[1]
http://www.nabble.com/forum/Permalink.jtp?root=25837696post=25841367page=y
[2]
From fea6a55cb67b3fda1d93da74b2fe68fb25376e7e Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Mon, 12 Oct 2009 13:54:17 -0500
Subject: [BAD][PATCH] TI OMAP3: SDP3430: dont use legacy ethernet driver
Stop using the LEGACY driver and use NET_MULTI
this also removes the build warning for SDP3430
---
board/ti/sdp3430/sdp.c |8 +---
include/configs/omap3_sdp3430.h |7 ---
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/board/ti/sdp3430/sdp.c b/board/ti/sdp3430/sdp.c
index 40cf26f..85181c8 100644
--- a/board/ti/sdp3430/sdp.c
+++ b/board/ti/sdp3430/sdp.c
@@ -22,6 +22,7 @@
* MA 02111-1307 USA
*/
#include common.h
+#include netdev.h
#include twl4030.h
#include asm/io.h
#include asm/arch/mux.h
@@ -121,8 +122,8 @@ int board_init(void)
return 0;
}
-#define LAN_RESET_REGISTER (CONFIG_LAN91C96_BASE + 0x01c)
-#define ETH_CONTROL_REG(CONFIG_LAN91C96_BASE + 0x30b)
+#define LAN_RESET_REGISTER (CONFIG_SMC911X_BASE + 0x01c)
+#define ETH_CONTROL_REG(CONFIG_SMC911X_BASE + 0x30b)
/**
* @brief ether_init Take the Ethernet controller out of reset and wait
@@ -130,7 +131,7 @@ int board_init(void)
*/
static void ether_init(void)
{
-#ifdef CONFIG_DRIVER_LAN91C96
+#ifdef CONFIG_SMC911X
int cnt = 20;
writew(0x0, LAN_RESET_REGISTER);
@@ -155,6 +156,7 @@ static void ether_init(void)
writeb(readb(ETH_CONTROL_REG) ~0x1, ETH_CONTROL_REG);
udelay(1000);
+ smc911x_initialize(0, CONFIG_SMC911X_BASE);
reset_err_out:
return;
diff --git a/include/configs/omap3_sdp3430.h
b/include/configs/omap3_sdp3430.h
index 229dc5e..7b0a248 100644
--- a/include/configs/omap3_sdp3430.h
+++ b/include/configs/omap3_sdp3430.h
@@ -200,9 +200,10 @@
*/
#if defined(CONFIG_CMD_NET)
-#define CONFIG_DRIVER_LAN91C96
-#define CONFIG_LAN91C96_BASE DEBUG_BASE
-#define CONFIG_LAN91C96_EXT_PHY
+#define CONFIG_NET_MULTI
+#define CONFIG_SMC911X
+#define CONFIG_SMC911X_32_BIT
+#define CONFIG_SMC911X_BASEDEBUG_BASE
#define CONFIG_BOOTP_SEND_HOSTNAME
/*
--
1.6.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-samsung/master
Minkyu Kang wrote: Dear Tom, The following changes since commit 617da90c1dcf65428ddfb63fef897439950bc915: Tom Rix (1): Merge branch 't-next-marvell' into t-next-at91 are available in the git repository at: git://git.denx.de/u-boot-samsung master Minkyu Kang (5): s5pc1xx: support Samsung s5pc1xx SoC s5pc1xx: support onenand driver s5pc1xx: support serial driver s5pc1xx: add support SMDKC100 board Merge branch 'master' of git://git.denx.de/u-boot-arm This is a new board. I think this board was submitted after the merge window And it has a lot of compiler warnings. Can you clean these up ? I think these should wait to be merged. kevin.morf...@fearnside-systems.co.uk (5): CONFIG_SYS_HZ fix for ARM902T S3C24X0 Boards Clean-up of cpu_arm920t and cpu_arm920t_s3c24x0 code Clean-up of s3c24x0 header files Clean-up of s3c24x0 drivers excluding nand driver Clean-up of s3c24x0 nand driver These look like a code that was run through indent. cleaning up without any obvious new features. These would be ok to merge. Does this sound ok? I can just cherry pick the cleanups. Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
