Hello,
I built a toolchain for PowerPC 440EP nad configured it for cpu 440fp
with hard-float.
Building u-boot with this toolchain failed, because there is
PLATFORM_CPPFLAGS += -DCONFIG_4xx -ffixed-r2 -mstring -msoft-float
in cpu/ppc4xx/config.mk.
What is the best way to solve this?
Possible s
> the best way will be to remove the -lgcc so you can build
> u-boot how you wish without depending of the toolchains
> support of hard-float or soft-float
You mean building u-boot withou lgcc? Can you give me a clue how to do
that?
Cheers
Dirk
___
U
> This is no reason for any problems. As mentioned above, ELDK
> in the ppc_4xxFP configuration (and some others)
> support hardware FP as
> well, but works fine with U-Boot. After all, U-Boot is
> self-contained.
Sorry for bugging you again, Wolfgang.
The messages I get a
> A 4xx FP toolchain is a perfectly good idea - that's why we
> support such a configuration in ppc_4xxFP with the ELDK. But
> it doesn't need any changes to U-Boot.
I tried building u-boot with the 4xxFP toolchain from ELDK and -
surprise, surprise - it worked.
So there is definetly somet
Hello Wolfgang,
Thanks for the review. I'm busys cleaning up the code, but at one point
I need some help:
> >
> +/
> > +*
> > + * initdram -- doesn't use serial presence detect.
> > + *
> > + * Assumes:256 MB, ECC, no
Hi Stefan,
> It's really not a big deal, but since I addressed these
> issues in my last mail again, I noticed them in this version as well.
>
>
>
> > +#defineCONFIG_SYS_SDRAM0_TR0 0x410a4012
> > +#defineCONFIG_SYS_SDRAM0_WDDCTR0x4000
Oops. Sorry. I thought I ha
Hi Stefan
> Subject: Re: [U-Boot] [PATCH v7] ppc4xx: Add GDsys PowerPC
> 440 ETX board support.
>
> Hi Dirk,
>
> On Wednesday 17 December 2008, Dirk Eibach wrote:
> > Board support for the Guntermann & Drunck PowerPC 440 ETX module.
> > Based on the AMCC Yosemite board support by Stefan Roese
This patch adds support for the National LM63 temperature
sensor with integrated fan control. It's used on the GDSys
Neo board (405EP) which will be submitted later.
Signed-off-by: Dirk Eibach <[EMAIL PROTECTED]>
Acked-by: Stefan Roese <[EMAIL PROTECTED]>
---
drivers/hwmon/Makefile |1 +
driv
> > @@ -403,11 +422,38 @@
> > /*
> > * Environment
> > */
> > -#define CONFIG_ENV_IS_IN_FLASH
> > -#define CONFIG_ENV_OVERWRITE
> > -#define CONFIG_ENV_ADDR
> (CONFIG_SYS_MONITOR_BASE - CONFIG_ENV_SECT_SIZE)
> > -#define CONFIG_ENV_SIZE0x2000
> > -#define CONFIG_ENV_
> Can you give me some instructions on how to test this? I'm
> working on adding NAND boot support to the P1022, so I need
> to make sure I don't conflict with your patch.
Hi Timur,
What is the current status of this stuff?
Cheers
Dirk
___
U-B
Some of your recent cfi flash driver enhancements have made flash
protect/unprotect work on our NOR based platforms (S29GL512). Good news
so far, but as a consequence fw_setenv is woking no more:
MTD erase error on /dev/mtd5: Input/output error
Error: can't write fw_env to flash
Also flash_unlock
Hi Stefan,
> > Some of your recent cfi flash driver enhancements have made flash
> > protect/unprotect work on our NOR based platforms (S29GL512). Good
> > news so far, but as a consequence fw_setenv is woking no more:
> > MTD erase error on /dev/mtd5: Input/output error
> > Error: can't write
Hi Georg,
maybe removing CONFIG_SYS_FLASH_PROTECTION from your configuration does already
what you want to achieve.
BTW Linux support should be available here:
http://patchwork.ozlabs.org/patch/213602/
Cheers
Dirk
> -Original Message-
> From: u-boot-boun...@lists.denx.de
> [mailto:u-b
The following commit modified include/asm-ppc/config.h so that
config_canyonlands has CONFIG_FSL_DMA active (because of
CONFIG_DDR_ECC), which is probably not intended. I'm not sure how to fix
this properly, maybe some Freescale guru could comment.
Cheers
Dirk
commit e94e460c6e8741f42dab6d8dd4b5
> Otherwise "git bisect" is your fried...
"git bisect" rocks!
So I finally found the nasty bugger:
commit d873133f2ba9bd613d5f6552c31cc70fb13f15d3
Author: Stefan Roese
Date: Mon May 11 13:46:14 2009 +0200
ppc4xx: Add Sequoia RAM-booting target
Hmm, not sure yet what causes the problem he
> > Hmm, not sure yet what causes the problem here, but this changes in
> > cpu/ppc4xx/start.S look fishy...
I found that the old code does not clear TLB entry #0.
So this helps in my case:
diff --git a/cpu/ppc4xx/start.S b/cpu/ppc4xx/start.S
index ac96fc2..7be73a7 100644
--- a/cpu/ppc4xx/sta
> > diff --git a/board/gdsys/compactcenter/compactcenter.c
> > b/board/gdsys/compactcenter/compactcenter.c new file mode
> 100644 index
> > 000..9f1e49d
> > --- /dev/null
> > +++ b/board/gdsys/compactcenter/compactcenter.c
>
>
>
> > +#if defined(CONFIG_OF_LIBFDT) &&
> defined(CONFIG_OF
> >> __ft_board_setup() sets the property "ranges", with an entry for
> >> every member of EBC_NUM_BANKS.
> >> Then the so called "fixup" happens and the property
> "ranges" is set
> >> again, this time with only one entry (for the nor flash).
> All other
> >> entries are lost.
> >>
> >
> Dirk, if you like I can add you s-o-b to the next patch
> version, since you contributed to this code as well. Just let me know.
Sure, you can list me as s-o-b.
Cheers
Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/
> Just checking: You only want to change the printed name upon
> bootup from "compactcenter" to "intip"? Not the U-Boot target name?
That's it. Since this might be sold as an OEM product, we need a more
generic name to be displayed.
Cheers
Dirk
___
> Dear Dirk Eibach,
Dear Wolfgang,
> ...
> > #define BASE_WIDTH 32
> > @@ -38,12 +44,18 @@
> > enum {
> > REG_CONTROL = 0x0010,
> > REG_MPC3W_CONTROL = 0x001a,
> > + REG_EXT_INTERRUPT = 0x001c,
> > + REG_EXT_INTERRUPT_ENABLE = 0x001e,
> > + REG_IIC_WRITE_MAILBOX = 0x0030,
> > +
Thanks, I can confirm this fixes the issue for me (405EX Rev. D with
security).
Still checkpatch finds some whitespace issues:
.dotest/patch:13: space before tab in indent.
defined(CONFIG_405EX_CHIP21_PVR_REV_D) && \
.dotest/patch:27: trailing whitespace.
*
warning: 2 lines add
> v2:
> Correct checkpatch errors/warnings re: whitespace, comment style, etc.
> Move PVR logic out of board config file.
> Simplify ifdef structure.
> Signed-off-by: Steve Falco
Works for me, thanks!
Tested on custom board using #define
CONFIG_SYS_4xx_CHIP_21_405EX_SECURITY.
Acked-by: Dirk E
Dear Wolfgang,
> In message <1319101940-780-1-git-send-email-eib...@gdsys.de>
> you wrote:
> > Signed-off-by: Dirk Eibach
> > ---
> > drivers/gpio/Makefile |1 +
> > drivers/gpio/pca9698.c | 143
>
> > include/pca9698.h | 34 +
> > The bootstrap.c file is the same as for Canyonlands. Maybe it makes
> > sense to share it between all 460EX boards, by moving it to some
> > common location. Stefan, what do you think ?
>
> I'm not so sure here. Even if those settings might work on
> most 460EX/GT boards, some custom boar
> > I narrowed it down to board_early_init_r() where
> remove_tlb() is done.
>
> Before or after the remove_tlb()?
It is in remove_tlb().
> > When I do a 'res halt' 'res run' sequence with the BDI the
> board comes
> > up fine.
> >
> > Any ideas?
>
> No, sorry. I haven't done much work on C
Hi Tom,
> ...
> There's checkpatch warning I'm guessing since I can spot some
> spacing issues.
> ...
Hmm, interesting, it's checkpatch clean. Maybe this tool can still get
even more annoying :)
Will fix issues asap.
Cheers
Dirk
-
While debugging an I2C problem I found in soft_i2c_read() and
soft_i2c_write():
if(write_byte(addr >> shift)) {
PRINTD("i2c_read, address not ed\n");
return(1);
}
and
if(write_byte(addr >> shift)) {
PRINTD("i2c_write, address not ed\n");
return(1);
}
This means t
Today I received an erratum fro apm that seems to claim that ddr2
autocalibration is not working properly on our 460EX boards. Is anyone
already working on this?
Would ddr_scan_option be the way to fix this? Or should
4xx_ibm_ddr2_autocalib.c generally be fixed for 460EX?
Cheers
Dirk
DDR_2: Int
> Hi Dirk,
Hi Stefan,
> On Friday 11 February 2011 08:59:47 Eibach, Dirk wrote:
> > Today I received an erratum fro apm that seems to claim that ddr2
> > autocalibration is not working properly on our 460EX
> boards. Is anyone
> > already working on this?
>
!!NOSIG
Hi Stefan,
> **
> > ** @@ -322,6 +326,9 @@ init_fnc_t *init_sequence[] = { #ifdef
> > CONFIG_POST
> > post_init_f,
> > #endif
> > +#ifdef CONFIG_FPGA_INIT
> > + init_func_fpga,
> > +#endif
>
> Do you really need
Dear Wolfgang,
> > I need a hook before relocation but with i2c running. I did
> not find
> > anything generic for this purpose.
>
> Why exactly does has this to run before relocation?
Our FPGA guys keep bugging me to get their stuff in a defined state ASAP
after poweron. So "before relocatio
> > Our FPGA guys keep bugging me to get their stuff in a defined state
> > ASAP after poweron. So "before relocation" seemed to me the
> best thing
> > I could offer to them.
>
> Well, tell them that ASAP means "right after relocation", then.
Hmm, maybe they won't even notice...
> > To ge
Commit "780f13a... hwmon: do not init sensors on startup" moved
initialization of the dtt driver to cmd_dtt.
I just realized that this means trouble for me, because the lm63 driver
used on our boards is responsible for setting up the fans. Relying on
cmd_dtt being called by preboot seems fragile t
Hi Stefan.
> While looking again, I noticed that you are not using the
> "standard" GPIO API borrowed from Linux. Please take a look
> at drivers/gpio/mxc_gpio.c or drivers/gpio/mvgpio.c as an example.
>
> Sorry for not mentioning this earlier. Could you please
> update this patch and your I
> Next time please update the patch version in the subject and
> add the changes below the "---" line. Other than this:
Oops, wrong serialization of save / git-send-email. I did a resend.
Cheers
Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
htt
> Hi Dirk,
Hi Stefan,
> ...
>
>
> > +/* Gbit PHYs */
> > +#define CONFIG_BITBANGMII /* bit-bang MII PHY
> management*/
> > +
> > +#define CONFIG_SYS_MDIO_PIN (0x8000 >> 13) /* our
> MDIO is GPIO0
> */
> > +#define CONFIG_SYS_MDC_PIN (0x8000 >> 7) /* our
> MD
>...
>
>
> > +/* Gbit PHYs */
> > +#define CONFIG_BITBANGMII /* bit-bang MII PHY
> management*/
> > +
> > +#define CONFIG_SYS_MDIO_PIN (0x8000 >> 13) /* our
> MDIO is GPIO0
> */
> > +#define CONFIG_SYS_MDC_PIN (0x8000 >> 7) /* our
> MDC is GPIO7
> */
> >
Hi Stefan,
> Why not use the already available GPIO functions instead
> (gpio_write_bit() etc)? This will make it easier to move this
> to the common (Linux) GPIO API at some time later.
>
Hmm, nice, didn't notice those yet.
But somehow functionality is missing for toggling between output an
Dear Wolfgang,
> Signed-off-by: Dirk Eibach
> > ---
> > MAINTAINERS |1 +
> > MAKEALL |1 +
> > board/gdsys/iocon/Makefile | 51 +++
> > board/gdsys/iocon/config.mk | 24
> > board/gdsys/iocon/iocon.c | 302
> +
> It seems thius board is very similar to the "io" board;
> especially board/gdsys/iocon/{io,iocon}.c and
> include/configs/{ip,iocon}.h share many, many identical lines.
>From the u-boot point of view they are similar indeed, while anything
but cpu and fpga interface has nothing in common (th
41 matches
Mail list logo
