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
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
-
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
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
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
> 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
> > @@ -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_
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 +
> 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 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
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
> > 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
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
!!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
> 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
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
> 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?
>
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
> 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,
> > +
> 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
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
> +
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
>...
>
>
> > +/* 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 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
> 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
___
> 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/
> >> __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.
> >>
> >
> > 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
> > 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
> 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
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
> > 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
> > 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
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
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
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
> 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
> 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
> 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
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
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
41 matches
Mail list logo
