Re: [U-Boot] [PATCH] powerpc/85xx: Fix SRIO LAW setup on corenet_ds boards
On Aug 18, 2010, at 9:21 AM, Wolfgang Denk wrote: > Dear Kumar Gala, > > In message <1282139990-17758-1-git-send-email-ga...@kernel.crashing.org> you > wrote: >> From: Lian Minghuan >> >> In funciton board_early_init_r(), serdes does not initialize yet. >> variable "serdes_prtcl_map" in function is_serdes_configured() does >> not initialize. sRIO will always be disable. >> >> In the original code, there is a undefined variable gur if SRIO is not >> defined. > > Please fix the typos when applying. Thanks. > > Best regards, > > Wolfgang Denk applied and fixed commit message. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] fdt: call fdt_parent_offset fewer times while translating addresses
From: Scott Wood
fdt_parent_offset() is an expensive operation, so we'd like to reduce
unnecessary calls to it.
Further, the practice of iterating up to the root if address/size cells
aren't found was apparently done for Linux for compatibility with certain
buggy Open Firmware implementations, and U-Boot inherited the code. The
compliant behavior is to treat a missing #address-cells as 2, and a missing
#size-cells as 1 -- never looking anywhere but the immediate parent of the
node of interest.
Signed-off-by: Scott Wood
Signed-off-by: Kumar Gala
---
It also reduces the size of the u-boot image by 216 bytes.
common/fdt_support.c | 58 ++---
1 files changed, 21 insertions(+), 37 deletions(-)
diff --git a/common/fdt_support.c b/common/fdt_support.c
index 6be..aef4fe2 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -874,35 +874,6 @@ static inline u64 of_read_number(const __be32 *cell, int
size)
return r;
}
-static int of_n_cells(const void *blob, int nodeoffset, const char *name)
-{
- int np;
- const int *ip;
-
- do {
- np = fdt_parent_offset(blob, nodeoffset);
-
- if (np >= 0)
- nodeoffset = np;
- ip = (int *)fdt_getprop(blob, nodeoffset, name, NULL);
- if (ip)
- return be32_to_cpup(ip);
- } while (np >= 0);
-
- /* No #-cells property for the root node */
- return 1;
-}
-
-int of_n_addr_cells(const void *blob, int nodeoffset)
-{
- return of_n_cells(blob, nodeoffset, "#address-cells");
-}
-
-int of_n_size_cells(const void *blob, int nodeoffset)
-{
- return of_n_cells(blob, nodeoffset, "#size-cells");
-}
-
#define PRu64 "%llx"
/* Max address size we deal with */
@@ -928,7 +899,7 @@ static void of_dump_addr(const char *s, const u32 *addr,
int na) { }
struct of_bus {
const char *name;
const char *addresses;
- void(*count_cells)(void *blob, int offset,
+ void(*count_cells)(void *blob, int parentoffset,
int *addrc, int *sizec);
u64 (*map)(u32 *addr, const u32 *range,
int na, int ns, int pna);
@@ -936,13 +907,26 @@ struct of_bus {
};
/* Default translator (generic bus) */
-static void of_bus_default_count_cells(void *blob, int offset,
+static void of_bus_default_count_cells(void *blob, int parentoffset,
int *addrc, int *sizec)
{
- if (addrc)
- *addrc = of_n_addr_cells(blob, offset);
- if (sizec)
- *sizec = of_n_size_cells(blob, offset);
+ const u32 *prop;
+
+ if (addrc) {
+ prop = fdt_getprop(blob, parentoffset, "#address-cells", NULL);
+ if (prop)
+ *addrc = be32_to_cpup(prop);
+ else
+ *addrc = 2;
+ }
+
+ if (sizec) {
+ prop = fdt_getprop(blob, parentoffset, "#size-cells", NULL);
+ if (prop)
+ *sizec = be32_to_cpup(prop);
+ else
+ *sizec = 1;
+ }
}
static u64 of_bus_default_map(u32 *addr, const u32 *range,
@@ -1068,7 +1052,7 @@ u64 __of_translate_address(void *blob, int node_offset,
const u32 *in_addr,
bus = &of_busses[0];
/* Cound address cells & copy address locally */
- bus->count_cells(blob, node_offset, &na, &ns);
+ bus->count_cells(blob, parent, &na, &ns);
if (!OF_CHECK_COUNTS(na, ns)) {
printf("%s: Bad cell count for %s\n", __FUNCTION__,
fdt_get_name(blob, node_offset, NULL));
@@ -1095,7 +1079,7 @@ u64 __of_translate_address(void *blob, int node_offset,
const u32 *in_addr,
/* Get new parent bus and counts */
pbus = &of_busses[0];
- pbus->count_cells(blob, node_offset, &pna, &pns);
+ pbus->count_cells(blob, parent, &pna, &pns);
if (!OF_CHECK_COUNTS(pna, pns)) {
printf("%s: Bad cell count for %s\n", __FUNCTION__,
fdt_get_name(blob, node_offset, NULL));
--
1.6.0.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/83xx: Fix build issue with ve8313 board due to lbus changes
On Aug 19, 2010, at 1:50 AM, Kumar Gala wrote: > We get two build errors: > > fsl_elbc_nand.c: In function 'fsl_elbc_run_command': > fsl_elbc_nand.c:231: error: 'fsl_lbc_t' has no member named 'lsor' > make[1]: *** [/work/wd/tmp-ppc/drivers/mtd/nand/fsl_elbc_nand.o] Error 1 > > and > > ve8313.c: In function 'initdram': > ve8313.c:104: error: expected '=', ',', ';', 'asm' or '__attribute__' > before '*' token > ve8313.c:104: error: 'lbc' undeclared (first use in this function) > ve8313.c:104: error: (Each undeclared identifier is reported only once > ve8313.c:104: error: for each function it appears in.) > ve8313.c:104: error: 'immap_t' has no member named 'lbus' > make[1]: *** [ve8313.o] Error 1 > make: *** [board/ve8313/libve8313.a] Error 2 > > Due to changes to unifiy local bus struct definitions. > > Reported-by: Wolfgang Denk > Signed-off-by: Kumar Gala > --- > board/ve8313/ve8313.c|2 +- > drivers/mtd/nand/fsl_elbc_nand.c |4 +++- > include/configs/ve8313.h |1 + > 3 files changed, 5 insertions(+), 2 deletions(-) applied - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] QorIQ NAND-Boot configs not building
On Aug 18, 2010, at 5:15 PM, Wolfgang Denk wrote: > Dear Andy & Kumar, > > all QorIQ NAND-Boot configurations are apeareantly failing to build. > > I get > > ld: NAND bootstrap too big > > error messages for these board configurations: P1011RDB_NAND, > P1020RDB_NAND, P2010RDB_NAND, and P2020RDB_NAND > > Please fix. This will take a bit longer since it seems to be compiler version dependent. Not seeing it with gcc 4.3.2. What gcc are you using? - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-mpc85xx.git
The following changes since commit bd2313078114c4b44c4a5ce149af43bcb7fc8854: Wolfgang Denk (1): Merge branch 'master' of ssh://gemini/home/wd/git/u-boot/master are available in the git repository at: git://git.denx.de/u-boot-mpc85xx master Kim Phillips (1): powerpc/8xxx: share PIC defines among 85xx and 86xx Kumar Gala (2): powerpc/85xx: Rename Security Engine Job Queue to Job Ring to match docs powerpc/83xx: Fix build issue with ve8313 board due to lbus changes Lian Minghuan (1): powerpc/85xx: Fix SRIO LAW setup on corenet_ds boards york (1): powerpc/8xxx: Fix quad-rank DIMMs support on corenet_ds board. arch/powerpc/cpu/mpc85xx/cpu.c |2 +- arch/powerpc/cpu/mpc85xx/cpu_init.c |2 +- arch/powerpc/cpu/mpc85xx/interrupts.c |2 +- arch/powerpc/cpu/mpc85xx/mp.c |6 ++-- arch/powerpc/cpu/mpc85xx/p4080_ids.c|8 ++-- arch/powerpc/cpu/mpc85xx/traps.c|2 +- arch/powerpc/cpu/mpc8xxx/cpu.c |8 +++-- arch/powerpc/include/asm/fsl_liodn.h|8 ++-- arch/powerpc/include/asm/immap_85xx.h | 10 ++ arch/powerpc/include/asm/immap_86xx.h |9 -- board/freescale/corenet_ds/corenet_ds.c | 47 -- board/freescale/corenet_ds/ddr.c| 18 +++- board/ve8313/ve8313.c |2 +- drivers/mtd/nand/fsl_elbc_nand.c|4 ++- include/configs/corenet_ds.h|2 +- include/configs/ve8313.h|1 + 16 files changed, 78 insertions(+), 53 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] eSPI and Intel E1000 support for P1/P2 RDB
On Aug 8, 2010, at 2:57 PM, Wolfgang Denk wrote: > Dear Kumar Gala, > > In message <57cdb146-383a-4629-b7e4-c2729200a...@kernel.crashing.org> you > wrote: >> >> On Jun 23, 2010, at 8:56 AM, Poonam Aggrwal wrote: >> >>> This patch enables the eSPI configuration to use >>> the Spansion Flash on P1 and P2 RDB Platforms >>> >>> This also enables the Intel Pro/1000 PT Gb Ethernet >>> PCI-E Network Adapter configuration support >>> >>> Signed-off-by: Poonam Aggrwal >>> --- >>> include/configs/P1_P2_RDB.h | 15 +++ >>> 1 files changed, 15 insertions(+), 0 deletions(-) >> >> applied to 85xx > > I think I haven't seen this in a pull request yet? > > Best regards, > > Wolfgang Denk I think there was some issue with SPI change so I dropped this patch and replaced with: commit ddac6f08db3d539d05fad5400ed3dc815b1a196b Author: Poonam Aggrwal Date: Thu Jul 1 14:24:36 2010 +0530 85xx/p1_p2_rdb: PCIe E1000 card support added. which is already in your tree. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCHv2] net: Fix faulty definition of uec_initialize()
The correct definition is in drivers/qe/uec.h so just remove this one. Signed-off-by: Joakim Tjernlund --- include/netdev.h |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/include/netdev.h b/include/netdev.h index 882642a..65833e2 100644 --- a/include/netdev.h +++ b/include/netdev.h @@ -83,7 +83,6 @@ int skge_initialize(bd_t *bis); int smc911x_initialize(u8 dev_num, int base_addr); int smc9_initialize(u8 dev_num, int base_addr); int tsi108_eth_initialize(bd_t *bis); -int uec_initialize(int index); int uec_standard_init(bd_t *bis); int uli526x_initialize(bd_t *bis); int sh_eth_initialize(bd_t *bis); -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] QorIQ NAND-Boot configs not building
Dear Kumar Gala, In message you wrote: > > This will take a bit longer since it seems to be compiler version > dependent. Not seeing it with gcc 4.3.2. What gcc are you using? gcc 4.2.2 as comes with ELDK 4.2 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 The only time the world beats a path to your door is when you are in the bathroom. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/2] TI: DaVinci DA850 EVM: support passing maximum allowed cpu clock rate information to kernel
Sekhar Nori wrote:
> The TI DA850/OMAP-L138/AM18x EVM can be populated with devices
> having different maximum allowed CPU clock rating.
>
> The maximum clock the chip can support can only be determined from
> the label on the package (not software readable).
>
> Introduce a method to pass the maximum allowed clock rate information
> to kernel using ATAG_REVISION. The kernel uses this information to
> determine the maximum cpu clock rate reachable using cpufreq.
>
> Note that U-Boot itself does not set the CPU clock rate. The CPU
> clock is setup by a primary bootloader ("UBL"). The rate setup by
> UBL could be different from the maximum clock rate supported by the
> device.
>
> Signed-off-by: Sekhar Nori
> ---
> Changes in v3:
> a) renamed maxspeed to maxcpuclk
> b) add information regarding the new environment variable in README.davinci
> c) use if-else instead of switch to check for value range rather than specific
>values of maxcpuclk
> d) change comment to document values returned in bit[0-3] by get_board_rev()
> in
>binary
>
> board/davinci/da8xxevm/da850evm.c | 33 +
> doc/README.davinci| 13 +
> include/configs/da850evm.h|1 +
> 3 files changed, 47 insertions(+), 0 deletions(-)
Hi,
sorry if I come only late in the discussion, I have a general question.
As I see, the UBL does not take care at all of the possibility to have
different frequencies, and sets the PLL with a fix value (300 Mhz, as I
read in sources). From my point of view, it makes sense to use the
maximum allowed cpu clock if we then set the CPU to increase the
performances.
If you set the value in a u-boot environment, the value could be easy
overwritten and a wrong value could be displayed. So I have doubt on
using an environment to get a so hardware-related value..
Do you plan to use the maximum cpu clock to set the PLL ? Or is it only
for info purposes ?
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mpc5xxx_fec: add call to reset_phy() after PHY initialization
Some boards need their board-specific PHY quirks to be called to PHY to work normally. As mpc5xxx_fec driver uses on demand PHY initialization and can even reinit PHY during normal operation we can't count on reset_phy() call from arch//lib/board.c (it is most likely called _before_ we init the PHY from the driver) so we need to add call to reset_phy() directly in the driver. Cc: Ben Warren Signed-off-by: Ilya Yanok --- drivers/net/mpc5xxx_fec.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/drivers/net/mpc5xxx_fec.c b/drivers/net/mpc5xxx_fec.c index c88e596..bc8c922 100644 --- a/drivers/net/mpc5xxx_fec.c +++ b/drivers/net/mpc5xxx_fec.c @@ -250,6 +250,13 @@ static int mpc5xxx_fec_init(struct eth_device *dev, bd_t * bis) mpc5xxx_fec_init_phy(dev, bis); /* +* Call board-specific PHY fixups (if any) +*/ +#ifdef CONFIG_RESET_PHY_R + reset_phy(); +#endif + + /* * Initialize RxBD/TxBD rings */ mpc5xxx_fec_rbd_init(fec); -- 1.6.2.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/2] TI: DaVinci DA850 EVM: support passing maximum allowed cpu clock rate information to kernel
Hi Stefano,
On Thu, Aug 19, 2010 at 13:51:46, Stefano Babic wrote:
> Sekhar Nori wrote:
> > The TI DA850/OMAP-L138/AM18x EVM can be populated with devices
> > having different maximum allowed CPU clock rating.
> >
> > The maximum clock the chip can support can only be determined from
> > the label on the package (not software readable).
> >
> > Introduce a method to pass the maximum allowed clock rate information
> > to kernel using ATAG_REVISION. The kernel uses this information to
> > determine the maximum cpu clock rate reachable using cpufreq.
> >
> > Note that U-Boot itself does not set the CPU clock rate. The CPU
> > clock is setup by a primary bootloader ("UBL"). The rate setup by
> > UBL could be different from the maximum clock rate supported by the
> > device.
> >
> > Signed-off-by: Sekhar Nori
> > ---
> > Changes in v3:
> > a) renamed maxspeed to maxcpuclk
> > b) add information regarding the new environment variable in README.davinci
> > c) use if-else instead of switch to check for value range rather than
> > specific
> >values of maxcpuclk
> > d) change comment to document values returned in bit[0-3] by
> > get_board_rev() in
> >binary
> >
> > board/davinci/da8xxevm/da850evm.c | 33 +
> > doc/README.davinci| 13 +
> > include/configs/da850evm.h|1 +
> > 3 files changed, 47 insertions(+), 0 deletions(-)
>
> Hi,
>
> sorry if I come only late in the discussion, I have a general question.
> As I see, the UBL does not take care at all of the possibility to have
> different frequencies, and sets the PLL with a fix value (300 Mhz, as I
> read in sources). From my point of view, it makes sense to use the
> maximum allowed cpu clock if we then set the CPU to increase the
> performances.
Yes, cpufreq in kernel can do this based on cpu load.
> If you set the value in a u-boot environment, the value could be easy
> overwritten and a wrong value could be displayed. So I have doubt on
> using an environment to get a so hardware-related value..
Overwritten by whom and displayed where?
> Do you plan to use the maximum cpu clock to set the PLL ? Or is it only
> for info purposes ?
The kernel will use the value to understand the maximum frequency it can
reach using cpufreq. So yes, kernel uses this to set the PLL.
Thanks,
Sekhar
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Disaligned buffer in print_buffer
As linebuf is accessed with 32-bit pointers, its address
must be 32 bit aligned to avoid misaligned access.
Signed-off-by: Stefano Babic
---
lib/display_options.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/display_options.c b/lib/display_options.c
index 20319e6..30374f9 100644
--- a/lib/display_options.c
+++ b/lib/display_options.c
@@ -101,7 +101,7 @@ void print_size(unsigned long long size, const char *s)
#define DEFAULT_LINE_LENGTH_BYTES (16)
int print_buffer (ulong addr, void* data, uint width, uint count, uint linelen)
{
- uint8_t linebuf[MAX_LINE_LENGTH_BYTES + 1];
+ uint8_t linebuf[MAX_LINE_LENGTH_BYTES + 1]
__attribute__((__aligned__(4)));
uint32_t *uip = (void*)linebuf;
uint16_t *usp = (void*)linebuf;
uint8_t *ucp = (void*)linebuf;
--
1.6.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] coldfire m68k/mcf547x_8x : Fix relocation errors in start.S
When the environment sectors in the flash are big, one get those errors : mcf547x_8x/start.S:173: relocation truncated to fit: R_68K_PC16 against symbol `cpu_init_f' defined in .text section in libmcf547x_8x.a(cpu_init.o) mcf547x_8x/start.S:174: relocation truncated to fit: R_68K_PC16 against symbol `board_init_f' defined in .text section in libm68k.a(board.o) Fix that. Signed-off-by: Philippe De Muyter --- arch/m68k/cpu/mcf547x_8x/start.S |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/m68k/cpu/mcf547x_8x/start.S b/arch/m68k/cpu/mcf547x_8x/start.S index 8411862..80905ed 100644 --- a/arch/m68k/cpu/mcf547x_8x/start.S +++ b/arch/m68k/cpu/mcf547x_8x/start.S @@ -164,8 +164,8 @@ _start: move.l #__got_start, %a5/* put relocation table address to a5 */ - bsr cpu_init_f /* run low-level CPU init code (from flash) */ - bsr board_init_f/* run low-level board init code (from flash) */ + jbsr cpu_init_f /* run low-level CPU init code (from flash) */ + jbsr board_init_f /* run low-level board init code (from flash) */ /* board_init_f() does not return */ -- 1.6.3.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/4] Add support for PRTLVT2 boards
The following patches add support for PRTLVT2 based boards (i.MX515 SoC). [PATCH 1/4] MX51: iomux: Added support for mxc_iomux_set_input() [PATCH 2/4] MX51: Added missing pin definition [PATCH 3/4] mc13982 driver: corrected/added some definitions according to latest user-manual [PATCH 4/4] Added initial support for PRTLVT2-based boards. Signed-off-by: David Jander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] MX51: iomux: Added support for mxc_iomux_set_input()
Signed-off-by: David Jander
---
arch/arm/cpu/armv7/mx51/iomux.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/arm/cpu/armv7/mx51/iomux.c b/arch/arm/cpu/armv7/mx51/iomux.c
index 62b2954..fb48f1c 100644
--- a/arch/arm/cpu/armv7/mx51/iomux.c
+++ b/arch/arm/cpu/armv7/mx51/iomux.c
@@ -34,7 +34,7 @@ enum iomux_reg_addr {
IOMUXSW_MUX_CTL = IOMUXC_BASE_ADDR,
IOMUXSW_MUX_END = IOMUXC_BASE_ADDR + MUX_I_END,
IOMUXSW_PAD_CTL = IOMUXC_BASE_ADDR + PAD_I_START,
- IOMUXSW_INPUT_CTL = IOMUXC_BASE_ADDR,
+ IOMUXSW_INPUT_CTL = IOMUXC_BASE_ADDR + INPUT_CTL_START,
};
#define MUX_PIN_NUM_MAX (((MUX_I_END - MUX_I_START) >> 2) + 1)
@@ -164,3 +164,9 @@ unsigned int mxc_iomux_get_pad(iomux_pin_name_t pin)
u32 pad_reg = get_pad_reg(pin);
return readl(pad_reg);
}
+
+void mxc_iomux_set_input(iomux_input_select_t input, u32 config)
+{
+ u32 pad_reg = IOMUXSW_INPUT_CTL+(input*4);
+ writel(config, pad_reg);
+}
--
1.6.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] MX51: Added missing pin definition
Signed-off-by: David Jander
---
arch/arm/include/asm/arch-mx51/mx51_pins.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx51/mx51_pins.h
b/arch/arm/include/asm/arch-mx51/mx51_pins.h
index ca26f41..c443f13 100644
--- a/arch/arm/include/asm/arch-mx51/mx51_pins.h
+++ b/arch/arm/include/asm/arch-mx51/mx51_pins.h
@@ -320,6 +320,7 @@ enum iomux_pins {
MX51_PIN_DISP1_DAT22 = _MXC_BUILD_NON_GPIO_PIN(0x324, 0x724),
MX51_PIN_DISP1_DAT23 = _MXC_BUILD_NON_GPIO_PIN(0x328, 0x728),
MX51_PIN_DI1_PIN3 = _MXC_BUILD_NON_GPIO_PIN(0x32C, 0x72C),
+ MX51_PIN_DI1_DISP_CLK = _MXC_BUILD_NON_GPIO_PIN(0, 0x730), /* No MUX
register!! */
MX51_PIN_DI1_PIN2 = _MXC_BUILD_NON_GPIO_PIN(0x330, 0x734),
MX51_PIN_DI_GP1 = _MXC_BUILD_NON_GPIO_PIN(0x334, 0x73C),
MX51_PIN_DI_GP2 = _MXC_BUILD_NON_GPIO_PIN(0x338, 0x740),
--
1.6.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] mc13982 driver: corrected/added some definitions according to latest user-manual
Signed-off-by: David Jander
---
include/fsl_pmic.h |2 +-
include/mc13892.h | 41 +
2 files changed, 34 insertions(+), 9 deletions(-)
diff --git a/include/fsl_pmic.h b/include/fsl_pmic.h
index e3abde6..2f2aa7d 100644
--- a/include/fsl_pmic.h
+++ b/include/fsl_pmic.h
@@ -112,7 +112,7 @@ enum {
#define GPO4STBY (1 << 13)
#define PWGT1SPIEN (1 << 15)
#define PWGT2SPIEN (1 << 16)
-#define PWUP (1 << 21)
+#define GPO4ADIN (1 << 21)
/* Power Control 0 */
#define COINCHEN (1 << 23)
diff --git a/include/mc13892.h b/include/mc13892.h
index b291757..4eea6af 100644
--- a/include/mc13892.h
+++ b/include/mc13892.h
@@ -29,29 +29,51 @@
/* REG_CHARGE */
-#define VCHRG0 0
+#define VCHRG0 (1 << 0)
#define VCHRG1 (1 << 1)
#define VCHRG2 (1 << 2)
#define ICHRG0 (1 << 3)
#define ICHRG1 (1 << 4)
#define ICHRG2 (1 << 5)
#define ICHRG3 (1 << 6)
-#define ICHRGTR0 (1 << 7)
-#define ICHRGTR1 (1 << 8)
-#define ICHRGTR2 (1 << 9)
+#define TREN (1 << 7)
+#define ACKLPB (1 << 8)
+#define THCHKB (1 << 9)
#define FETOVRD(1 << 10)
#define FETCTRL(1 << 11)
#define RVRSMODE (1 << 13)
-#define OVCTRL0(1 << 15)
-#define OVCTRL1(1 << 16)
-#define UCHEN (1 << 17)
+#define PLIM0 (1 << 15)
+#define PLIM1 (1 << 16)
+#define PLIMDIS(1 << 17)
#define CHRGLEDEN (1 << 18)
-#define CHRGRAWPDEN(1 << 19)
+#define CHGTMRRST (1 << 19)
#define CHGRESTART (1 << 20)
#define CHGAUTOB (1 << 21)
#define CYCLB (1 << 22)
#define CHGAUTOVIB (1 << 23)
+
+/* Power Control 2 (reg 15) */
+#define RESTARTEN (1 << 0)
+#define PWRON1RSTEN (1 << 1)
+#define PWRON2RSTEN (1 << 2)
+#define PWRON3RSTEN (1 << 3)
+#define PWRON1DBNC0 (1 << 4)
+#define PWRON1DBNC1 (1 << 5)
+#define PWRON2DBNC0 (1 << 6)
+#define PWRON2DBNC1 (1 << 7)
+#define PWRON3DBNC0 (1 << 8)
+#define PWRON3DBNC1 (1 << 9)
+#define STANDBYINV(1 << 10)
+#define STANDBYSECINV (1 << 11)
+#define WDIRESET (1 << 12)
+#define SPIDRV0 (1 << 13)
+#define SPIDRV1 (1 << 14)
+#define CLK32KDRV0(1 << 17)
+#define CLK32KDRV1(1 << 18)
+#define STBYDLY0 (1 << 22)
+#define STBYDLY1 (1 << 23)
+
/* REG_SETTING_0/1 */
#define VO_1_20V 0
#define VO_1_30V 1
@@ -84,6 +106,9 @@
#define SWMODE_PFM_PFM 15
#define SWMODE_MASK0x0F
+/* Switchers 4 (reg 28) */
+#define SWILIMB(1 << 22)
+
#define SWMODE1_SHIFT 0
#define SWMODE2_SHIFT 10
#define SWMODE3_SHIFT 0
--
1.6.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] Added initial support for PRTLVT2-based boards.
Signed-off-by: David Jander --- board/Protonic/prtlvt2/Makefile | 48 board/Protonic/prtlvt2/config.mk| 25 ++ board/Protonic/prtlvt2/imximage.cfg | 171 board/Protonic/prtlvt2/prtlvt2.c| 513 +++ board/Protonic/prtlvt2/prtlvt2.h| 50 boards.cfg |1 + include/configs/prtlvt2.h | 203 ++ 7 files changed, 1011 insertions(+), 0 deletions(-) create mode 100644 board/Protonic/prtlvt2/Makefile create mode 100644 board/Protonic/prtlvt2/config.mk create mode 100644 board/Protonic/prtlvt2/imximage.cfg create mode 100644 board/Protonic/prtlvt2/prtlvt2.c create mode 100644 board/Protonic/prtlvt2/prtlvt2.h create mode 100644 include/configs/prtlvt2.h diff --git a/board/Protonic/prtlvt2/Makefile b/board/Protonic/prtlvt2/Makefile new file mode 100644 index 000..e1f1157 --- /dev/null +++ b/board/Protonic/prtlvt2/Makefile @@ -0,0 +1,48 @@ +# +# Copyright (C) 2007, Guennadi Liakhovetski +# +# (C) Copyright 2009 Freescale Semiconductor, Inc. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS := prtlvt2.o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak .depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/Protonic/prtlvt2/config.mk b/board/Protonic/prtlvt2/config.mk new file mode 100644 index 000..af70ec2 --- /dev/null +++ b/board/Protonic/prtlvt2/config.mk @@ -0,0 +1,25 @@ +# +# Copyright 2009 Freescale Semiconductor, Inc. All Rights Reserved. +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +LDSCRIPT = $(CPUDIR)/$(SOC)/u-boot.lds +TEXT_BASE = 0x9780 +IMX_CONFIG = $(SRCTREE)/board/$(BOARDDIR)/imximage.cfg diff --git a/board/Protonic/prtlvt2/imximage.cfg b/board/Protonic/prtlvt2/imximage.cfg new file mode 100644 index 000..a89168e --- /dev/null +++ b/board/Protonic/prtlvt2/imximage.cfg @@ -0,0 +1,171 @@ +# +# (C Copyright 2009 +# Stefano Babic DENX Software Engineering sba...@denx.de. +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not write to the Free Software +# Foundation Inc. 51 Franklin Street Fifth Floor Boston, +# MA 02110-1301 USA +# +# Refer docs/README.imxmage for more details about how-to configure +# and create imximage boot image +# +# The syntax is taken as close as possible with the kwbimage + +# Boot Device : one of +# spi, sd (the board has no nand neither onenand) + +# BOOT_FROMspi +BOOT_
Re: [U-Boot] [PATCH v2] [TESTING] da8xx: fixup ARM relocation support
Hi Sudhakar,
Thank you for reviewing this patch.
On Thu, Aug 19, 2010 at 2:25 AM, Sudhakar Rajashekhara
wrote:
> Ben Gardiner nanometrics.ca> writes:
>
> [...] snip
>
>> +
>> +void dram_init_banksize (void)
>> +{
>> + gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
>> + gd->bd->bi_dram[0].size = gd->ram_size;
>> +}
>> +#endif
>>
>
> dram_init() gets called from arch/arm/lib/board.c and initializes gd->ram_size
> but who is calling dram_init_banksize to initialize gd->bd->bi_dram[0].start
> and gd->bd->bi_dram[0].size?
As of commit a716b323f10d4f2bce6b4ae01f6d1544e5781ed8 on the
arm-reloc-and-cache-support branch of
git://git.denx.de/u-boot-testing.git , dram_init_banksize() is called
from board_init_f which is executed just before relocation.
Best Regards,
Ben Gardiner
---
Nanometrics Inc.
+1 (613) 592-6776 x239
http://www.nanometrics.ca
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] Added initial support for PRTLVT2-based boards.
Dear David Jander,
In message
<00b6eb8822a36b67a5e6154fd256e51e605fe47a.1282213859.git.da...@protonic.nl> you
wrote:
>
> board/Protonic/prtlvt2/Makefile | 48
> board/Protonic/prtlvt2/config.mk| 25 ++
> board/Protonic/prtlvt2/imximage.cfg | 171
> board/Protonic/prtlvt2/prtlvt2.c| 513
> +++
> board/Protonic/prtlvt2/prtlvt2.h| 50
> boards.cfg |1 +
> include/configs/prtlvt2.h | 203 ++
> 7 files changed, 1011 insertions(+), 0 deletions(-)
> create mode 100644 board/Protonic/prtlvt2/Makefile
> create mode 100644 board/Protonic/prtlvt2/config.mk
> create mode 100644 board/Protonic/prtlvt2/imximage.cfg
> create mode 100644 board/Protonic/prtlvt2/prtlvt2.c
> create mode 100644 board/Protonic/prtlvt2/prtlvt2.h
> create mode 100644 include/configs/prtlvt2.h
Entry to MAINTAINERS missing.
...
> + /* SCL_2V8, SDA_2V8 on KEY_COL4 and KEY_COL5 */
> + {MX51_PIN_KEY_COL4,IOMUX_CONFIG_ALT3, PIO_OD,
> MUX_IN_I2C2_IPP_SCL_IN_SELECT_INPUT, INPUT_CTL_PATH1},
> + {MX51_PIN_KEY_COL5,IOMUX_CONFIG_ALT3, PIO_OD,
> MUX_IN_I2C2_IPP_SCL_IN_SELECT_INPUT, INPUT_CTL_PATH1},
Lines too long, please fix globally.
...
> + /* Write needed to update Charger 0 */
> + /* Charge voltage=4.2V, Current=full-on, Plim=800mW, charger sw,
> battfet off */
Incorrect multiline comment format, please fix globally.
> + pmic_reg_write(REG_CHARGE, VCHRG0 | VCHRG1 /*| VCHRG2 */ |
> + ICHRG0 | ICHRG1 | ICHRG2 | ICHRG3 | FETOVRD |
> + PLIM0 /* | PLIM1 */ |
> + CHRGLEDEN | CHGAUTOB | CYCLB);
> +
> + /* Configure Power Control, enable PWRON switches */
> + pmic_reg_write(REG_POWER_CTL2, RESTARTEN |
> + PWRON1RSTEN | PWRON2RSTEN | PWRON3RSTEN |
> + PWRON1DBNC0 | PWRON2DBNC0 | PWRON3DBNC0 |
> + WDIRESET | STBYDLY0);
> +
> + /* power up the system first */
> + // FIXME: Is this bit still there in rev 2?
> + // This bit was called PWUP??
No C++ comments, please!
> + pmic_reg_write(REG_POWER_MISC, GPO4ADIN);
It would really be great if someone cold clean up this mess in
"include/fsl_pmic.h"
Using an "enum" for register definitions is just horrible.
I am well aware that you did not introduce this code, but reading this
feels is if my nails are rolling up.
> + /* Set core voltage to 1.1V */
> + val = pmic_reg_read(REG_SW_0);
> + val = (val & (~0x80001F)) | 0x14;
> + pmic_reg_write(REG_SW_0, val);
> +
> + /* Setup VCC (SW2) to 1.225 */
> + val = pmic_reg_read(REG_SW_1);
> + val = (val & (~0x80001F)) | 0x19;
> + pmic_reg_write(REG_SW_1, val);
> +
> + /* Setup 1V2_DIG1 (SW3) to 1.2 */
> + val = pmic_reg_read(REG_SW_2);
> + val = (val & (~0x80001F)) | 0x18;
> + pmic_reg_write(REG_SW_2, val);
> + udelay(50);
Don't you feel the need to intr=oduce some readable symbolic
constants for all these magic numbers here?
> + /* Raise the core frequency to 800MHz */
> + /* printf("Core at 400 MHz!\n"); */
> + /* writel(0x1, &mxc_ccm->cacrr); */
Please remove dead code.
> +#if 0 /* FIXME: This shouldn't be changed for PRTLVT2 */
> + /* Set VDIG to 1.25V, VGEN3 to 1.8V, VCAM to 2.6V */
> + val = pmic_reg_read(REG_SETTING_0);
> + val &= ~(VCAM_MASK | VGEN3_MASK | VDIG_MASK);
> + val |= VDIG_1_25 | VGEN3_1_8 | VCAM_2_6;
> + pmic_reg_write(REG_SETTING_0, val);
> +#endif
Please remove dead code.
> + /* Turn on backlight */
> + val = readl(GPIO1_BASE_ADDR + 0x0);
> + val |= 0x0004; /* Make GPIO1_2 high (BLEN) */
> + writel(val, GPIO1_BASE_ADDR + 0x0);
> +
> + val = readl(GPIO1_BASE_ADDR + 0x4);
> + val |= 0x0004; /* configure GPIO line as output */
> + writel(val, GPIO1_BASE_ADDR + 0x4);
We don't accept register base plus offset notation any more. Please
use a C struct to describe the register layout. Please fix globally.
...
> +#define CONFIG_EXTRA_ENV_SETTINGS
> \
> + "netdev=eth0\0" \
> + "uboot_addr=0xa000\0" \
> + "uboot=u-boot.bin\0"\
> + "loadaddr=0x9080\0" \
> + "bootargs_base=setenv bootargs console=tty "\
> + "console=ttymxc0,${baudrate}\0"\
> + "bootargs_nfs=setenv bootargs ${bootargs} root=/dev/nfs "\
> + "ip=${ipaddr}
> nfsroot=${nfsserverip}:${nfsroot},v3,tcp\0"\
> + "bootcmd_net=run bootargs_base bootargs_nfs; " \
> + "tftpboot ${loadaddr} ${kernel}; bootm\0" \
> +"bootcmd_SD=run bootcmd_SD1 bootcmd_SD2\0" \
Indentation by TAB only, please. [Check & fix globally, please.]
> + "ethaddr=00:00:00:00:00:00\0" \
> +
[U-Boot] NAND 16 bit buswidth issue
I am running U-boot 2009.08 on a sequoia based custom board. The board
has a Micron 29F2G16AAD nand chip. This chip is a large page device
with a 16 bit buswidth. I have an issue in nand_base.c in the
nand_get_flash_type function where the check for buswidth fails, causing
the print out -
printk(KERN_WARNING "NAND bus width %d instead %d bit\n",
(chip->options & NAND_BUSWIDTH_16) ? 16 : 8,
busw ? 16 : 8);
The busw is read from the nand chip and is correct, but the
chip->options is incorrect. I don't see where this gets set to the
options shown in nand_ids.c. I see that here:
/* Lookup the flash id */
for (i = 0; nand_flash_ids[i].name != NULL; i++) {
if (dev_id == nand_flash_ids[i].id) {
type = &nand_flash_ids[i];
break;
}
}
type gets the correct values from nand_ids, should the value of
type->options be assigned to chip->options? Or am I missing something
and need to set chip->options somewhere in my board specific files?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Disaligned buffer in print_buffer
On Thursday, August 19, 2010 07:01:58 Stefano Babic wrote: > - uint8_t linebuf[MAX_LINE_LENGTH_BYTES + 1]; > + uint8_t linebuf[MAX_LINE_LENGTH_BYTES + 1] > __attribute__((__aligned__(4))); i'd rather we go with Albert Aribaud's change (posted 14 Aug 2010) -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 4/4] Added initial support for PRTLVT2-based boards.
Dear Wolfgang,
On Thursday 19 August 2010 03:03:54 pm Wolfgang Denk wrote:
>[...]
> > create mode 100644 board/Protonic/prtlvt2/Makefile
> > create mode 100644 board/Protonic/prtlvt2/config.mk
> > create mode 100644 board/Protonic/prtlvt2/imximage.cfg
> > create mode 100644 board/Protonic/prtlvt2/prtlvt2.c
> > create mode 100644 board/Protonic/prtlvt2/prtlvt2.h
> > create mode 100644 include/configs/prtlvt2.h
>
> Entry to MAINTAINERS missing.
Oops. Thanks for pointing out. Will add maintainer info.
> > + /* SCL_2V8, SDA_2V8 on KEY_COL4 and KEY_COL5 */
> > + {MX51_PIN_KEY_COL4,IOMUX_CONFIG_ALT3, PIO_OD,
> > MUX_IN_I2C2_IPP_SCL_IN_SELECT_INPUT, INPUT_CTL_PATH1},
> > + {MX51_PIN_KEY_COL5,IOMUX_CONFIG_ALT3, PIO_OD,
> > MUX_IN_I2C2_IPP_SCL_IN_SELECT_INPUT, INPUT_CTL_PATH1},
>
> Lines too long, please fix globally.
Ok. Will fix that.
> > + /* Write needed to update Charger 0 */
> > + /* Charge voltage=4.2V, Current=full-on, Plim=800mW, charger sw,
> > battfet off */
>
> Incorrect multiline comment format, please fix globally.
Ok.
>[...]
> > + pmic_reg_write(REG_POWER_MISC, GPO4ADIN);
>
> It would really be great if someone cold clean up this mess in
> "include/fsl_pmic.h"
Yes, but fixing it will probably break a lot of other code. Am I supposed to
do that and fix everything that I can find breaking and hope for the rest
(which I can't test myself)?
> Using an "enum" for register definitions is just horrible.
I agree.
> I am well aware that you did not introduce this code, but reading this
> feels is if my nails are rolling up.
I agree. Should I propose a fix first (could be a lot of work)?
> > + /* Set core voltage to 1.1V */
> > + val = pmic_reg_read(REG_SW_0);
> > + val = (val & (~0x80001F)) | 0x14;
> > + pmic_reg_write(REG_SW_0, val);
> > +
> > + /* Setup VCC (SW2) to 1.225 */
> > + val = pmic_reg_read(REG_SW_1);
> > + val = (val & (~0x80001F)) | 0x19;
> > + pmic_reg_write(REG_SW_1, val);
> > +
> > + /* Setup 1V2_DIG1 (SW3) to 1.2 */
> > + val = pmic_reg_read(REG_SW_2);
> > + val = (val & (~0x80001F)) | 0x18;
> > + pmic_reg_write(REG_SW_2, val);
> > + udelay(50);
>
> Don't you feel the need to intr=oduce some readable symbolic
> constants for all these magic numbers here?
Yes I do. It was copied almost literally from the MX51EVK code, and somehow I
think this should go elsewhere anyway
I'll see what I can come up with.
> > + /* Raise the core frequency to 800MHz */
> > + /* printf("Core at 400 MHz!\n"); */
> > + /* writel(0x1, &mxc_ccm->cacrr); */
>
> Please remove dead code.
Ok.
> > +#if 0 /* FIXME: This shouldn't be changed for PRTLVT2 */
> > + /* Set VDIG to 1.25V, VGEN3 to 1.8V, VCAM to 2.6V */
> > + val = pmic_reg_read(REG_SETTING_0);
> > + val &= ~(VCAM_MASK | VGEN3_MASK | VDIG_MASK);
> > + val |= VDIG_1_25 | VGEN3_1_8 | VCAM_2_6;
> > + pmic_reg_write(REG_SETTING_0, val);
> > +#endif
>
> Please remove dead code.
Ok.
> > + /* Turn on backlight */
> > + val = readl(GPIO1_BASE_ADDR + 0x0);
> > + val |= 0x0004; /* Make GPIO1_2 high (BLEN) */
> > + writel(val, GPIO1_BASE_ADDR + 0x0);
> > +
> > + val = readl(GPIO1_BASE_ADDR + 0x4);
> > + val |= 0x0004; /* configure GPIO line as output */
> > + writel(val, GPIO1_BASE_ADDR + 0x4);
>
> We don't accept register base plus offset notation any more. Please
> use a C struct to describe the register layout. Please fix globally.
Again, this is copy/pasted from MX51EVK code somewhere. Will try to improve
this.
> ...
>
> > +#defineCONFIG_EXTRA_ENV_SETTINGS
> > \
> > + "netdev=eth0\0" \
> > + "uboot_addr=0xa000\0" \
> > + "uboot=u-boot.bin\0"\
> > + "loadaddr=0x9080\0" \
> > + "bootargs_base=setenv bootargs console=tty "\
> > + "console=ttymxc0,${baudrate}\0"\
> > + "bootargs_nfs=setenv bootargs ${bootargs} root=/dev/nfs "\
> > + "ip=${ipaddr}
> > nfsroot=${nfsserverip}:${nfsroot},v3,tcp\0"\
> > + "bootcmd_net=run bootargs_base bootargs_nfs; " \
> > + "tftpboot ${loadaddr} ${kernel}; bootm\0" \
> > +"bootcmd_SD=run bootcmd_SD1 bootcmd_SD2\0" \
>
> Indentation by TAB only, please. [Check & fix globally, please.]
Ok.
> > + "ethaddr=00:00:00:00:00:00\0" \
> > + "ipaddr=192.168.1.244\0" \
> > + "serverip=192.168.1.132\0" \
> > + "nfsserverip=192.168.1.160\0" \
>
> NAK!!
>
> We do not allow network parameters in the default environment (and
> especially not broken/incorrect MAC addresses.
Ooops. This wasn't meant to be here :-(
Anyway, I am currently working on implementing access to SPI-NOR-flash, and
this was there only for convinience while developing on one board. It was
meant to be removed, though.
Re: [U-Boot] [PATCH] Disaligned buffer in print_buffer
Mike Frysinger wrote: > On Thursday, August 19, 2010 07:01:58 Stefano Babic wrote: >> -uint8_t linebuf[MAX_LINE_LENGTH_BYTES + 1]; >> +uint8_t linebuf[MAX_LINE_LENGTH_BYTES + 1] >> __attribute__((__aligned__(4))); > > i'd rather we go with Albert Aribaud's change (posted 14 Aug 2010) > -mike Ok, I have missed someone else went in the same trouble ! Wolfgang, could you apply Albert's patch to the mainline ? As I see in the discussion, the patch proposed is accepted because _attribute__((__aligned__())) is everywhere used in u-boot. Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/83xx: Fix build issue with ve8313 board due to lbus changes
On Thu, 19 Aug 2010 01:50:40 -0500 Kumar Gala wrote: > diff --git a/drivers/mtd/nand/fsl_elbc_nand.c > b/drivers/mtd/nand/fsl_elbc_nand.c > index acdb431..ca61daf 100644 > --- a/drivers/mtd/nand/fsl_elbc_nand.c > +++ b/drivers/mtd/nand/fsl_elbc_nand.c > @@ -1,6 +1,6 @@ > /* Freescale Enhanced Local Bus Controller FCM NAND driver > * > - * Copyright (c) 2006-2008 Freescale Semiconductor > + * Copyright (c) 2006-2010 Freescale Semiconductor > * > * Authors: Nick Spence , > * Scott Wood > @@ -227,8 +227,10 @@ static int fsl_elbc_run_command(struct mtd_info *mtd) >in_be32(&lbc->fbar), in_be32(&lbc->fpar), >in_be32(&lbc->fbcr), priv->bank); > > +#ifdef CONFIG_FSL_ELBC > /* execute special operation */ > out_be32(&lbc->lsor, priv->bank); > +#endif NACK, if you don't have an ELBC you have no business compiling this file at all. This changes a loud failure to a quiet failure if someone forgets to define this symbol. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] samsung s3c2440 support
What is the status of support for the samsung s3c2440 in mainline u-boot? I have seen patches in the the mailing list archive from 2009 but they don't appear to have been applied yet. -- Craig Nauman Diagraph an ITW Company cnauman at diagraph dot com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] MAKEALL: cut down on duplication of targets
Merge the other significant source of board name duplication with the new
boards.cfg file. I cleaned up most targets, but the ARM and MIPS trees
are such a mess than I didn't bother. If those maintainers care, they can
take are of it.
While we're at it, we can be a bit more clever in the LIST_xxx handling
and avoid duplicating the list names too.
Signed-off-by: Mike Frysinger
---
v2
- keep $(...) style consistent
MAKEALL | 360 ++-
1 files changed, 56 insertions(+), 304 deletions(-)
diff --git a/MAKEALL b/MAKEALL
index b34ae33..81931ec 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -41,39 +41,39 @@ ERR_LIST=""
TOTAL_CNT=0
RC=0
+# Helper funcs for parsing boards.cfg
+boards_by_field()
+{
+ awk \
+ -v field="$1" \
+ -v select="$2" \
+ '($1 !~ /^#/ && $field == select) { print $1 }' \
+ boards.cfg
+}
+boards_by_arch() { boards_by_field 2 "$@" ; }
+boards_by_cpu() { boards_by_field 3 "$@" ; }
+
#
## MPC5xx Systems
#
-LIST_5xx=" \
- cmi_mpc5xx \
-"
+LIST_5xx="$(boards_by_cpu mpc5xx)"
#
## MPC5xxx Systems
#
-LIST_5xxx="\
- BC3450 \
- cm5200 \
- cpci5200\
+LIST_5xxx="$(boards_by_cpu mpc5xxx)
digsy_mtc \
EVAL5200\
fo300 \
galaxy5200 \
icecube_5200\
- inka4x0 \
- ipek01 \
lite5200b \
mcc200 \
- mecp5200\
- motionpro \
- munices \
MVBC_P \
MVSMR \
- o2dnt \
pcm030 \
- pf5200 \
PM520 \
TB5200 \
Total5200 \
@@ -81,62 +81,39 @@ LIST_5xxx=" \
TQM5200 \
TQM5200_B \
TQM5200S\
- v38b\
"
#
## MPC512x Systems
#
-LIST_512x="\
- aria\
- mecp5123\
+LIST_512x="$(boards_by_cpu mpc512x)
mpc5121ads \
- pdm360ng\
"
#
## MPC8xx Systems
#
-LIST_8xx=" \
+
+LIST_8xx="$(boards_by_cpu mpc8xx)
Adder87x\
AdderII \
ADS860 \
- AMX860 \
- c2mon \
- CCM \
- cogent_mpc8xx \
- ELPT860 \
- EP88x \
- ESTEEM192E \
- ETX094 \
FADS823 \
FADS850SAR \
FADS860T\
- FLAGADM \
FPS850L \
GEN860T \
GEN860T_SC \
- GENIETV \
- hermes \
- IAD210 \
ICU862_100MHz \
- IP860 \
IVML24 \
IVML24_128 \
IVML24_256 \
IVMS8 \
IVMS8_128 \
IVMS8_256 \
- KUP4K \
- KUP4X \
- LANTEC \
- lwmon \
- kmsupx4 \
MBX \
MBX860T \
- mgsuvd \
- MHPC\
MPC86xADS \
MPC885ADS \
NETPHONE\
@@ -145,33 +122,16 @@ LIST_8xx="\
NETTA_ISDN \
NETVIA \
NETVIA_V2 \
- NX823 \
- pcu_e \
- QS823 \
- QS850 \
- QS860T \
- quantum \
- R360MPI \
- RBC823 \
- rmu \
- RPXClassic \
- RPXlite \
RPXlite_DW \
- RRvision\
- SM850 \
- spc1920 \
SPD823TS\
- svm_sc8xx \
SXNI855T\
TK885D \
- TOP860 \
TQM823L \
TQM823L_LCD \
TQM850L \
TQM855L \
TQM860L \
TQM885D \
- uc100 \
v37 \
"
@@ -179,195 +139,98 @@ LIST_8xx=" \
## PPC4xx Systems
#
-LIST_4xx=" \
- acadia \
+LIST_4xx="
Re: [U-Boot] [PATCH v2] MAKEALL: cut down on duplication of targets
On Thu, Aug 19, 2010 at 1:05 PM, Mike Frysinger wrote: > Merge the other significant source of board name duplication with the new > boards.cfg file. I cleaned up most targets, but the ARM and MIPS trees > are such a mess than I didn't bother. If those maintainers care, they can > take are of it. > > While we're at it, we can be a bit more clever in the LIST_xxx handling > and avoid duplicating the list names too. > > Signed-off-by: Mike Frysinger > --- > v2 > - keep $(...) style consistent Reviewed-by: Ben Gardiner Best Regards, Ben Gardiner --- Nanometrics Inc. +1 (613) 592-6776 x239 http://www.nanometrics.ca ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] FW: which protocol do I use to send S-record files when using the loads command ?
Ok, here is a summary of what I have found out so, with the help of Wolfgang. Many thanks. 1) Wolfgang refers to the manual for system setup: http://www.denx.de/wiki/view/DULG/SystemSetup He recommends Linux programs cu and Kermit. 2) When using the "loads" command to upload an S-record file, only use the upload text feature of your terminal emulator. Do not use any of the protocols (like Kermit, YMODEM, ...). In the Windows program Teraterm, this corresponds to menu: File | Send file ... In Hyperterminal, this would be Transfer | Send text File ... 3) Also, U-boot does NOT use Hardware protocol or XON/OFF. So protocol is set to None. 4) I can not get this to work on our system (our U-boot is configured for 115200 baud). The following explanation is based on my observation. I might be wrong and please correct me if I am: U-boot can not keep up with the incoming text stream while parsing the S-records, i.e. I saw that it processed the first S0-record correctly, but when parsing the next record, it breaks off because the following record contains junk. As far as I can see, this seems to be because the Terminal program keeps sending data when U-boot is busy parsing a received S-record. Even after the S-record parser breaks off, the terminal program keeps sending the file content, which U-boot interprets a unknown commands. The junk record is basically what is left in the buffer by the time U-boot gets around to parsing the next record. 5) I was able to make this work by slowing down the file upload. In some terminal programs (like TeraTerm, menu Setup | Serial port ...) you can specify a delay after every character and a delay after every line. The above theory suggest (and was also suggested by Wolfgang) to put in a delay after every line to allow U-boot to process. However that did not work for me, even with putting in delays of 500 to 600 ms after each line. I might make it work with putting in higher values but that would be ridiculous. I was able to make it work with putting in delays after each character. Unfortunately, Teraterm and many other terminal programs do not allow delays of less than 1 msec. It works for me with a 1 msec delay after each character but at a grueling slow pace. A file of 3 Mbytes takes hours. 6) maybe I can get this to work by making the RX buffer much bigger, but haven't tried it yet. 7) Our board is based on the PowerPC-based ADS5121running at 400MHz. U-boot is configured at 115200 baud 8) People that use Kermit under Linux seem to have no problem, but I do not know in what sense their systems differ from mine. 9) Please do not suggest I switch to Linux. it is not an option. Personally I would like to, but we can not enforce this upon our clients. 10) The system I work on is a bareboard embedded system using U-boot to start up. That is why we are trying to use S-record files for uploading new programs, and not the more efficient FTP used in Linux. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] which protocol do I use to send S-record files when using the loads command ?
Ok, here is a summary of what I have found out so, with the help of Wolfgang. Many thanks. 1) Wolfgang refers to the manual for system setup: http://www.denx.de/wiki/view/DULG/SystemSetup He recommends Linux programs cu and Kermit. 2) When using the "loads" command to upload an S-record file, only use the upload text feature of your terminal emulator. Do not use any of the protocols (like Kermit, YMODEM, ...). In the Windows program Teraterm, this corresponds to menu: File | Send file ... In Hyperterminal, this would be Transfer | Send text File ... 3) Also, U-boot does NOT use Hardware protocol or XON/OFF. So protocol is set to None. 4) I can not get this to work on our system (our U-boot is configured for 115200 baud). The following explanation is based on my observation. I might be wrong and please correct me if I am: U-boot can not keep up with the incoming text stream while parsing the S-records, i.e. I saw that it processed the first S0-record correctly, but when parsing the next record, it breaks off because the following record contains junk. As far as I can see, this seems to be because the Terminal program keeps sending data when U-boot is busy parsing a received S-record. Even after the S-record parser breaks off, the terminal program keeps sending the file content, which U-boot interprets a unknown commands. The junk record is basically what is left in the buffer by the time U-boot gets around to parsing the next record. 5) I was able to make this work by slowing down the file upload. In some terminal programs (like TeraTerm, menu Setup | Serial port ...) you can specify a delay after every character and a delay after every line. The above theory suggest (and was also suggested by Wolfgang) to put in a delay after every line to allow U-boot to process. However that did not work for me, even with putting in delays of 500 to 600 ms after each line. I might make it work with putting in higher values but that would be ridiculous. I was able to make it work with putting in delays after each character. Unfortunately, Teraterm and many other terminal programs do not allow delays of less than 1 msec. It works for me with a 1 msec delay after each character but at a grueling slow pace. A file of 3 Mbytes takes hours. 6) maybe I can get this to work by making the RX buffer much bigger, but haven't tried it yet. 7) Our board is based on the PowerPC-based ADS5121running at 400MHz. U-boot is configured at 115200 baud 8) People that use Kermit under Linux seem to have no problem, but I do not know in what sense their systems differ from mine. 9) Please do not suggest I switch to Linux. it is not an option. Personally I would like to, but we can not enforce this upon our clients. 10) The system I work on is a bareboard embedded system using U-boot to start up. That is why we are trying to use S-record files for uploading new programs, and not the more efficient FTP used in Linux. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx51evk: Provide a proper reset for the Ethernet PHY
Provide a proper reset for the Ethernet PHY (LAN8700) on the MX51EVK. Signed-off-by: Fabio Estevam --- board/freescale/mx51evk/mx51evk.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/board/freescale/mx51evk/mx51evk.c b/board/freescale/mx51evk/mx51evk.c index 75d642b..70cce55 100644 --- a/board/freescale/mx51evk/mx51evk.c +++ b/board/freescale/mx51evk/mx51evk.c @@ -261,6 +261,10 @@ static void power_init(void) /* Reset the ethernet controller over GPIO */ writel(0x1, IOMUXC_BASE_ADDR + 0x0AC); + udelay(200); + reg = readl(GPIO2_BASE_ADDR + 0x0); + reg |= 0x4000; /* Set reset line to high*/ + writel(reg, GPIO2_BASE_ADDR + 0x0); /* Enable VGEN3, VCAM, VAUDIO, VVIDEO, VSD regulators */ val = VGEN3EN | VGEN3CONFIG | VCAMEN | VCAMCONFIG | -- 1.6.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Persönliche Informationen für Sie
Lieber Freund, Ich bin Barrister Talaki Gilbert, einem Rechtsanwalt und ich würde gerne mit Ihnen teilen, ein sehr wichtiges Geschäft Satz, daß der gegenseitige Nutzen für beide von uns werden. Ein verstorbener Klient von mir, dass die Aktien den gleichen Nachnamen wie Sie, der hier nach, wird als mein verstorbener Client bezeichnet werden, auf den 1. Oktober 2006 starb, er und seine Frau und seine einzige Tochter war in einen Autounfall verwickelt, während Reise in ein benachbartes Land auf Urlaub. Um das Beste aus meinem Wissen, vor seinem Tod hatte er eine Investition Anzahlung in Höhe von insgesamt mehr als US9.4M (9,4 Millionen US-Dollar) mit der Großbank hier und jetzt haben sie mich gebeten, einen nächsten Angehörigen, wenn oder gibt es das Weingut wird dann wieder an die Regierung und so verloren gehen würde. Mein Vorschlag ist, dass man für diese Rolle vorgestellt werden können, so dass Unterlagen können bearbeitet werden und die Zahlung zu Ihren Gunsten aus. Bitte beachten Sie meine persönliche E-Mail hinzuzufügen Antwort: gilberttal...@hotmail.fr Mit freundlichen Grüßen, Barrister Gilbert Talaki Principal Attorney___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/83xx: Fix build issue with ve8313 board due to lbus changes
On Aug 19, 2010, at 11:49 AM, Scott Wood wrote: > On Thu, 19 Aug 2010 01:50:40 -0500 > Kumar Gala wrote: > >> diff --git a/drivers/mtd/nand/fsl_elbc_nand.c >> b/drivers/mtd/nand/fsl_elbc_nand.c >> index acdb431..ca61daf 100644 >> --- a/drivers/mtd/nand/fsl_elbc_nand.c >> +++ b/drivers/mtd/nand/fsl_elbc_nand.c >> @@ -1,6 +1,6 @@ >> /* Freescale Enhanced Local Bus Controller FCM NAND driver >> * >> - * Copyright (c) 2006-2008 Freescale Semiconductor >> + * Copyright (c) 2006-2010 Freescale Semiconductor >> * >> * Authors: Nick Spence , >> * Scott Wood >> @@ -227,8 +227,10 @@ static int fsl_elbc_run_command(struct mtd_info *mtd) >> in_be32(&lbc->fbar), in_be32(&lbc->fpar), >> in_be32(&lbc->fbcr), priv->bank); >> >> +#ifdef CONFIG_FSL_ELBC >> /* execute special operation */ >> out_be32(&lbc->lsor, priv->bank); >> +#endif > > NACK, if you don't have an ELBC you have no business compiling this > file at all. This changes a loud failure to a quiet failure if someone > forgets to define this symbol. Ah, didn't even think about that from the file name, duh! Will drop the change. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] powerpc/83xx: Fix build issue with ve8313 board due to lbus changes
We get two build errors:
fsl_elbc_nand.c: In function 'fsl_elbc_run_command':
fsl_elbc_nand.c:231: error: 'fsl_lbc_t' has no member named 'lsor'
make[1]: *** [/work/wd/tmp-ppc/drivers/mtd/nand/fsl_elbc_nand.o] Error 1
and
ve8313.c: In function 'initdram':
ve8313.c:104: error: expected '=', ',', ';', 'asm' or '__attribute__'
before '*' token
ve8313.c:104: error: 'lbc' undeclared (first use in this function)
ve8313.c:104: error: (Each undeclared identifier is reported only once
ve8313.c:104: error: for each function it appears in.)
ve8313.c:104: error: 'immap_t' has no member named 'lbus'
make[1]: *** [ve8313.o] Error 1
make: *** [board/ve8313/libve8313.a] Error 2
Due to changes to unifiy local bus struct definitions.
Reported-by: Wolfgang Denk
Signed-off-by: Kumar Gala
---
* Removed change to fsl_elbc_nand.c as Scott points out we shouldn't build
this if we aren't already CONFIG_FSL_ELBC.
board/ve8313/ve8313.c|2 +-
include/configs/ve8313.h |1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/board/ve8313/ve8313.c b/board/ve8313/ve8313.c
index 8ba1b19..2272ff0 100644
--- a/board/ve8313/ve8313.c
+++ b/board/ve8313/ve8313.c
@@ -101,7 +101,7 @@ static long fixed_sdram(void)
phys_size_t initdram(int board_type)
{
volatile immap_t *im = (volatile immap_t *)CONFIG_SYS_IMMR;
- volatile fsl_lbus_t *lbc = &im->lbus;
+ volatile fsl_lbc_t *lbc = &im->im_lbc;
u32 msize;
if ((im->sysconf.immrbar & IMMRBAR_BASE_ADDR) != (u32)im)
diff --git a/include/configs/ve8313.h b/include/configs/ve8313.h
index 1589913..56d24f9 100644
--- a/include/configs/ve8313.h
+++ b/include/configs/ve8313.h
@@ -39,6 +39,7 @@
#define CONFIG_VE8313 1
#define CONFIG_PCI 1
+#define CONFIG_FSL_ELBC1
#define CONFIG_BOARD_EARLY_INIT_F 1
--
1.6.0.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] mpx85xx/fdt: Add cpu-release-addr for all cores
We currently do not add a cpu-release-addr for core 0, this is needed
when we want to reset core 0 and later restart it from Linux
Signed-off-by: Matthew McClintock
---
v2: Mark boot cpu status as "okay"
arch/powerpc/cpu/mpc85xx/fdt.c | 15 ---
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/fdt.c b/arch/powerpc/cpu/mpc85xx/fdt.c
index 8e7b827..4540364 100644
--- a/arch/powerpc/cpu/mpc85xx/fdt.c
+++ b/arch/powerpc/cpu/mpc85xx/fdt.c
@@ -54,18 +54,19 @@ void ft_fixup_cpu(void *blob, u64 memory_limit)
u32 *reg = (u32 *)fdt_getprop(blob, off, "reg", 0);
if (reg) {
+ u64 val = *reg * SIZE_BOOT_ENTRY + spin_tbl_addr;
+ val = cpu_to_fdt32(val);
if (*reg == id) {
- fdt_setprop_string(blob, off, "status", "okay");
+ fdt_setprop_string(blob, off, "status",
+ "okay");
} else {
- u64 val = *reg * SIZE_BOOT_ENTRY +
spin_tbl_addr;
- val = cpu_to_fdt32(val);
fdt_setprop_string(blob, off, "status",
"disabled");
- fdt_setprop_string(blob, off, "enable-method",
- "spin-table");
- fdt_setprop(blob, off, "cpu-release-addr",
- &val, sizeof(val));
}
+ fdt_setprop_string(blob, off, "enable-method",
+ "spin-table");
+ fdt_setprop(blob, off, "cpu-release-addr",
+ &val, sizeof(val));
} else {
printf ("cpu NULL\n");
}
--
1.6.6.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND 16 bit buswidth issue
On Thu, 19 Aug 2010 09:07:48 -0400
Pete Murray wrote:
> I am running U-boot 2009.08 on a sequoia based custom board. The board
> has a Micron 29F2G16AAD nand chip. This chip is a large page device
> with a 16 bit buswidth. I have an issue in nand_base.c in the
> nand_get_flash_type function where the check for buswidth fails, causing
> the print out -
>
> printk(KERN_WARNING "NAND bus width %d instead %d bit\n",
>(chip->options & NAND_BUSWIDTH_16) ? 16 : 8,
>busw ? 16 : 8);
>
> The busw is read from the nand chip and is correct, but the
> chip->options is incorrect. I don't see where this gets set to the
> options shown in nand_ids.c. I see that here:
>
> /* Lookup the flash id */
> for (i = 0; nand_flash_ids[i].name != NULL; i++) {
> if (dev_id == nand_flash_ids[i].id) {
> type = &nand_flash_ids[i];
> break;
> }
> }
>
>
> type gets the correct values from nand_ids, should the value of
> type->options be assigned to chip->options? Or am I missing something
> and need to set chip->options somewhere in my board specific files?
The controller driver is supposed to set chip->options.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] FW: which protocol do I use to send S-record files when using the loads command ?
On 2010/08/19 7:28 PM, Jef Mangelschots wrote: > Ok, here is a summary of what I have found out so, with the help of > Wolfgang. Many thanks. > > 4) I can not get this to work on our system (our U-boot is configured > for 115200 baud). The following explanation is based on my > observation. I might be wrong and please correct me if I am: > U-boot can not keep up with the incoming text stream while parsing the > S-records, i.e. I saw that it processed the first S0-record correctly, > but when parsing the next record, it breaks off because the following > record contains junk. As far as I can see, this seems to be because > the Terminal program keeps sending data when U-boot is busy parsing a > received S-record. Even after the S-record parser breaks off, the > terminal program keeps sending the file content, which U-boot > interprets a unknown commands. The junk record is basically what is > left in the buffer by the time U-boot gets around to parsing the next > record. Have you tried configuring your serial port to operate at a lower speed? setenv baudrate 57600 should tell u-boot to adjust the serial port settings, do the same in your terminal software, and you should be able to continue. Press Enter a couple of times to get your prompt back. While it will be slower than 115200, it will likely be better than introducing artificial delays after each character. Rogan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] FW: which protocol do I use to send S-record files when using the loads command ?
Dear Jef Mangelschots, In message you wrote: > > 4) I can not get this to work on our system (our U-boot is configured > for 115200 baud). The following explanation is based on my > observation. I might be wrong and please correct me if I am: > U-boot can not keep up with the incoming text stream while parsing the > S-records, i.e. I saw that it processed the first S0-record correctly, > but when parsing the next record, it breaks off because the following It is not exactly _parsing_ the record, but storing the decoded data to it's final destination, which usually includes flash programming cycles. > record contains junk. As far as I can see, this seems to be because > the Terminal program keeps sending data when U-boot is busy parsing a > received S-record. Even after the S-record parser breaks off, the Right. We recommend "cu" and setting the CONFIG_LOADS_ECHO option in your board config file, because "cu" appears to implemnt a simple kind of handshake in the form that after sending a line to the target it waits until it receives a line (the echo) back. Without that, you need to insert inter-line delays. > in delays after each character. Unfortunately, Teraterm and many other > terminal programs do not allow delays of less than 1 msec. It works > for me with a 1 msec delay after each character but at a grueling slow > pace. A file of 3 Mbytes takes hours. Apply better tools. Use for example "expect", which allows fine-graded inter-charatcer and inter-line timings ( see the "send-slow" command). "expect" is also available for Windows, I understand. > 6) maybe I can get this to work by making the RX buffer much bigger, > but haven't tried it yet. This will not help. U-Boot uses polling drivers. When it is programming the flash, it is simply nt listening on the serial port - no matter how big the buffers are. > 8) People that use Kermit under Linux seem to have no problem, but I > do not know in what sense their systems differ from mine. Kermit binary protocol is not only much more eficient than S-Records, but also much more robust nd reliable. > 10) The system I work on is a bareboard embedded system using U-boot > to start up. That is why we are trying to use S-record files for > uploading new programs, and not the more efficient FTP used in Linux. So you do have a network interface on your board? Heck, why don;t you use TFTP then??? 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 Peace was the way. -- Kirk, "The City on the Edge of Forever", stardate unknown ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND 16 bit buswidth issue
The controller driver being used is ndfc.c, it doesn't set the
options though. From what I can tell, nand.c calls nand_scan without
actually setting the nand options. I have been setting chip->options to
include NAND_BUSWIDTH_16, but want to move all my changes back to board
specific code to eventually submit for review.
/* Lookup the flash id */
for (i = 0; nand_flash_ids[i].name != NULL; i++) {
if (dev_id == nand_flash_ids[i].id) {
type = &nand_flash_ids[i];
break;
}
}
if (!type)
return ERR_PTR(-ENODEV);
if (!mtd->name)
mtd->name = type->name;
chip->chipsize = type->chipsize << 20;
Since type is set to the options read from nand_flash_ids in the
nand_get_flash_type function, would it be appropriate to just set
chip->options to type->options as is done with the chipsize? If not,
what would be the most acceptable way to do this?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND 16 bit buswidth issue
On Thu, 19 Aug 2010 16:22:40 -0400
Pete Murray wrote:
>
> The controller driver being used is ndfc.c, it doesn't set the
> options though. From what I can tell, nand.c calls nand_scan without
> actually setting the nand options. I have been setting chip->options to
> include NAND_BUSWIDTH_16, but want to move all my changes back to board
> specific code to eventually submit for review.
>
>
>
> /* Lookup the flash id */
> for (i = 0; nand_flash_ids[i].name != NULL; i++) {
> if (dev_id == nand_flash_ids[i].id) {
> type = &nand_flash_ids[i];
> break;
> }
> }
>
> if (!type)
> return ERR_PTR(-ENODEV);
>
> if (!mtd->name)
> mtd->name = type->name;
>
> chip->chipsize = type->chipsize << 20;
>
>
> Since type is set to the options read from nand_flash_ids in the
> nand_get_flash_type function, would it be appropriate to just set
> chip->options to type->options as is done with the chipsize? If not,
> what would be the most acceptable way to do this?
The controller driver isn't sufficiently board-specific, so you want to
change the generic code instead? :-)
The problem with autodetection is that you need to issue accesses to
the chip in order to read the ID data. What word size are you going
to use to make *those* accesses? Maybe doing 8-bit accesses happens to
work well enough for ID on your 16-bit chip and controller combination,
but that's not something we can assume generically.
Find a way to have your board config file tell the controller driver
what bus width to specify.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] FW: which protocol do I use to send S-record files when using the loads command ?
> It is not exactly _parsing_ the record, but storing the decoded data > to it's final destination, which usually includes flash programming > cycles. Whenever some code takes a ASCII string (in my case an S-record), extracts fields from it, converts these to numeric values, then I call that parsing. >> 8) People that use Kermit under Linux seem to have no problem, but I >> do not know in what sense their systems differ from mine. > Kermit binary protocol is not only much more eficient than S-Records, > but also much more robust nd reliable. Yes, there is the Kermit program and the Kermit protocol implemented by many terminal programs. Kermit protocol works great for us for transferring binary files (using both Teraterm and Hyperterminal). It is my understanding that we cannot use Kermit PROTOCOL to transfer S-record files with loads command. I though you indicated that in your previous email and it simply doesn't work when I try. The question was not about how to transfer binary files using Kermit protocol (works for us) but transferring S-record files. I am aware that you have suggested in many places AGAINST the use of S-record, but there is a genuine use for it. When using U-boot in a non-Linux bareboard embedded system, you need a way to give your users the capability to upload now software. An embedded software image is not a 'file' like in Linux but a memory image where data needs to reside at fixed addresses. In an multi-megabyte address space, the 'executable image' can consist of chunks of data spread over a wide range. 2 options here: (1) create a binary image of the entire Flash area, (2) a file that specifies which byte go in which address, i.e. an S-record file. Option (1) results in a big file with very little. Unless you break it up in smaller pieces and ask your user to burn image 1 at offset x and image 2 at offset y, ... > >> 10) The system I work on is a bareboard embedded system using U-boot >> to start up. That is why we are trying to use S-record files for >> uploading new programs, and not the more efficient FTP used in Linux. > So you do have a network interface on your board? Heck, why don;t you > use TFTP then??? I didn't say that. I was trying to say that our bareboard system doesn't support Ethernet and does not have TCP/IP stack (like Linux). If our system was a Linux system, we wouldn't be having this conversation. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] FW: which protocol do I use to send S-record files when using the loads command ?
Dear Jef Mangelschots, In message you wrote: > > It is not exactly _parsing_ the record, but storing the decoded data > > to it's final destination, which usually includes flash programming > > cycles. > > Whenever some code takes a ASCII string (in my case an S-record), > extracts fields from it, converts these to numeric values, then I call > that parsing. Me too, but that's not what is taking the time. It is the flash programming cycles. > Kermit protocol works great for us for transferring binary files > (using both Teraterm and Hyperterminal). > It is my understanding that we cannot use Kermit PROTOCOL to transfer > S-record files with loads command. > I though you indicated that in your previous email and it simply > doesn't work when I try. Sorry if I was not clear enough. I always meant to refer to using kermit binary protocol in combinationwith the loadb command. > I am aware that you have suggested in many places AGAINST the use of > S-record, but there is a genuine use for it. > When using U-boot in a non-Linux bareboard embedded system, you need a > way to give your users the capability > to upload now software. An embedded software image is not a 'file' > like in Linux but a memory image where data needs to > reside at fixed addresses. In an multi-megabyte address space, the > 'executable image' can consist of chunks of > data spread over a wide range. 2 options here: (1) create a binary > image of the entire Flash area, (2) a file that specifies which byte > go in which address, i.e. an S-record file. > Option (1) results in a big file with very little. Unless you break it > up in smaller pieces and ask your user to burn image 1 at offset x and > image 2 at offset y, ... You could probably wrap the parts in a FIT image, transfer it in binary mode, and use a script to extract the parts and move them into place. 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 A day without sunshine is like night. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] FW: which protocol do I use to send S-record files when using the loads command ?
Dear Jef Mangelschots, In message you wrote: ... > I am aware that you have suggested in many places AGAINST the use of > S-record, but there is a genuine use for it. BTW - there are UUCP versions for Windows out there, too. You might want to install one and try using "cu" ... 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 ... not meant for the weak-at-heart: /^(?=.*one)(?=.*two)/ If you can follow that, you can use it. - Randal L. Schwartz in ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] MAKEALL: cut down on duplication of targets
On 08/20/2010 01:05 AM, Mike Frysinger wrote: > Merge the other significant source of board name duplication with the new > boards.cfg file. I cleaned up most targets, but the ARM and MIPS trees > are such a mess than I didn't bother. If those maintainers care, they can > take are of it. > > While we're at it, we can be a bit more clever in the LIST_xxx handling > and avoid duplicating the list names too. > > Signed-off-by: Mike Frysinger > --- > v2 > - keep $(...) style consistent Build nios2 targets and tested on boards. Tested-by: Thomas Chou ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-mpc85xx.git (fwd)
[ Updated ve8313 patch and adding Matt's fix to cpu release dts nodes ] The following changes since commit bd2313078114c4b44c4a5ce149af43bcb7fc8854: Wolfgang Denk (1): Merge branch 'master' of ssh://gemini/home/wd/git/u-boot/master are available in the git repository at: git://git.denx.de/u-boot-mpc85xx master Kim Phillips (1): powerpc/8xxx: share PIC defines among 85xx and 86xx Kumar Gala (2): powerpc/85xx: Rename Security Engine Job Queue to Job Ring to match docs powerpc/83xx: Fix build issue with ve8313 board due to lbus changes Lian Minghuan (1): powerpc/85xx: Fix SRIO LAW setup on corenet_ds boards Matthew McClintock (1): mpx85xx/fdt: Add cpu-release-addr for all cores york (1): powerpc/8xxx: Fix quad-rank DIMMs support on corenet_ds board. arch/powerpc/cpu/mpc85xx/cpu.c |2 +- arch/powerpc/cpu/mpc85xx/cpu_init.c |2 +- arch/powerpc/cpu/mpc85xx/fdt.c | 15 + arch/powerpc/cpu/mpc85xx/interrupts.c |2 +- arch/powerpc/cpu/mpc85xx/mp.c |6 ++-- arch/powerpc/cpu/mpc85xx/p4080_ids.c|8 ++-- arch/powerpc/cpu/mpc85xx/traps.c|2 +- arch/powerpc/cpu/mpc8xxx/cpu.c |8 +++-- arch/powerpc/include/asm/fsl_liodn.h|8 ++-- arch/powerpc/include/asm/immap_85xx.h | 10 ++ arch/powerpc/include/asm/immap_86xx.h |9 -- board/freescale/corenet_ds/corenet_ds.c | 47 -- board/freescale/corenet_ds/ddr.c| 18 +++- board/ve8313/ve8313.c |2 +- include/configs/corenet_ds.h|2 +- include/configs/ve8313.h|1 + 16 files changed, 83 insertions(+), 59 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] nios2: fix out of reach case for do_reset
Thomas,
Applied to: git://git.denx.de/u-boot-nios.git next
Thanks,
--Scott
Thomas Chou wrote:
> There is a limitation (or bug?) of nios2 toolchain. The nios2 gcc
> didn't generate correct code when the reset vector is passed as a
> constant. It just generated a direct "call", which was wrong when
> the reset vector was not located in the same 256MB span as u-boot.
>
> The "Nios II Processor Reference Handbook" said,
> "call can transfer execution anywhere within the 256 MByte range
> determined by PC31..28. The Nios II GNU linker does not automatically
> handle cases in which the address is out of this range."
>
> So we have to use registered "callr" instruction to do the job.
>
> Signed-off-by: Thomas Chou
> ---
> v2, add a macro for the inlince asm nios2_callr.
>
> arch/nios2/cpu/cpu.c| 11 +--
> arch/nios2/include/asm/system.h |5 +
> 2 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/arch/nios2/cpu/cpu.c b/arch/nios2/cpu/cpu.c
> index 6379534..d9c6544 100644
> --- a/arch/nios2/cpu/cpu.c
> +++ b/arch/nios2/cpu/cpu.c
> @@ -40,11 +40,10 @@ int checkcpu (void)
> return (0);
> }
>
> -
> -int do_reset (void)
> +int do_reset(void)
> {
> - void (*rst)(void) = (void(*)(void))CONFIG_SYS_RESET_ADDR;
> - disable_interrupts ();
> - rst();
> - return(0);
> + disable_interrupts();
> + /* indirect call to go beyond 256MB limitation of toolchain */
> + nios2_callr(CONFIG_SYS_RESET_ADDR);
> + return 0;
> }
> diff --git a/arch/nios2/include/asm/system.h b/arch/nios2/include/asm/system.h
> index bb03ca5..086d92b 100644
> --- a/arch/nios2/include/asm/system.h
> +++ b/arch/nios2/include/asm/system.h
> @@ -56,4 +56,9 @@
> ((flags & NIOS2_STATUS_PIE_MSK) == 0x0);\
> })
>
> +/* indirect call to go beyond 256MB limitation of toolchain */
> +#define nios2_callr(addr) __asm__ __volatile__ ( \
> + "callr %0" \
> + : : "r" (addr))
> +
> #endif /* __ASM_NIOS2_SYSTEM_H */
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] mpx85xx/fdt: Add cpu-release-addr for all cores
On Aug 19, 2010, at 1:57 PM, Matthew McClintock wrote: > We currently do not add a cpu-release-addr for core 0, this is needed > when we want to reset core 0 and later restart it from Linux > > Signed-off-by: Matthew McClintock > --- > v2: Mark boot cpu status as "okay" > > arch/powerpc/cpu/mpc85xx/fdt.c | 15 --- > 1 files changed, 8 insertions(+), 7 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2 v2] ARMV7: S5P: make s5p-common for sharing the code between s5pc1xx and s5pc2xx
This patch adds basic support for s5pc210.
s5p-common will be used by all of s5p SoCs.
Signed-off-by: Minkyu Kang
Signed-off-by: Kyungmin Park
---
v2: no change
Makefile |7 +
arch/arm/cpu/armv7/s5p-common/Makefile | 46 +++
arch/arm/cpu/armv7/s5p-common/cpu_info.c | 57 +
arch/arm/cpu/armv7/s5p-common/timer.c| 192 ++
arch/arm/cpu/armv7/s5pc1xx/Makefile |2 -
arch/arm/cpu/armv7/s5pc1xx/cpu_info.c| 57 -
arch/arm/cpu/armv7/s5pc1xx/timer.c | 192 --
7 files changed, 302 insertions(+), 251 deletions(-)
create mode 100644 arch/arm/cpu/armv7/s5p-common/Makefile
create mode 100644 arch/arm/cpu/armv7/s5p-common/cpu_info.c
create mode 100644 arch/arm/cpu/armv7/s5p-common/timer.c
delete mode 100644 arch/arm/cpu/armv7/s5pc1xx/cpu_info.c
delete mode 100644 arch/arm/cpu/armv7/s5pc1xx/timer.c
diff --git a/Makefile b/Makefile
index 9cea069..47f4e7d 100644
--- a/Makefile
+++ b/Makefile
@@ -253,6 +253,13 @@ ifeq ($(SOC),omap4)
LIBS += $(CPUDIR)/omap-common/libomap-common.a
endif
+ifeq ($(SOC),s5pc1xx)
+LIBS += $(CPUDIR)/s5p-common/libs5p-common.a
+endif
+ifeq ($(SOC),s5pc2xx)
+LIBS += $(CPUDIR)/s5p-common/libs5p-common.a
+endif
+
LIBS := $(addprefix $(obj),$(LIBS))
.PHONY : $(LIBS) $(TIMESTAMP_FILE) $(VERSION_FILE)
diff --git a/arch/arm/cpu/armv7/s5p-common/Makefile
b/arch/arm/cpu/armv7/s5p-common/Makefile
new file mode 100644
index 000..37371f6
--- /dev/null
+++ b/arch/arm/cpu/armv7/s5p-common/Makefile
@@ -0,0 +1,46 @@
+#
+# Copyright (C) 2009 Samsung Electronics
+# Minkyu Kang
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)libs5p-common.a
+
+COBJS-y+= cpu_info.o
+COBJS-y+= timer.o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS-y) $(SOBJS))
+
+all:$(obj).depend $(LIB)
+
+$(LIB):$(OBJS)
+ $(AR) $(ARFLAGS) $@ $(OBJS)
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/arch/arm/cpu/armv7/s5p-common/cpu_info.c
b/arch/arm/cpu/armv7/s5p-common/cpu_info.c
new file mode 100644
index 000..454175c
--- /dev/null
+++ b/arch/arm/cpu/armv7/s5p-common/cpu_info.c
@@ -0,0 +1,57 @@
+/*
+ * Copyright (C) 2009 Samsung Electronics
+ * Minkyu Kang
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+#include
+#include
+#include
+
+/* Default is s5pc100 */
+unsigned int s5pc1xx_cpu_id = 0xC100;
+
+#ifdef CONFIG_ARCH_CPU_INIT
+int arch_cpu_init(void)
+{
+ s5pc1xx_cpu_id = readl(samsung_get_base_pro_id());
+ s5pc1xx_cpu_id = 0xC000 | ((s5pc1xx_cpu_id & 0x00FFF000) >> 12);
+
+ s5pc1xx_clock_init();
+
+ return 0;
+}
+#endif
+
+u32 get_device_type(void)
+{
+ return s5pc1xx_cpu_id;
+}
+
+#ifdef CONFIG_DISPLAY_CPUINFO
+int print_cpuinfo(void)
+{
+ char buf[32];
+
+ printf("CPU:\ts5...@%smhz\n",
+ s5pc1xx_cpu_id, strmhz(buf, get_arm_clk()));
+
+ return 0;
+}
+#endif
diff --git a/arch/arm/cpu/armv7/s5p-common/timer.c
b/arch/arm/cpu/armv7/s5p-common/timer.c
new file mode 100644
index 000..6487c0f
--- /dev/null
+++ b/arch/arm/cpu/armv7/s5p-common/timer.c
@@ -0,0 +1,192 @@
+/*
+ * Copyri
[U-Boot] [PATCH 2/2 v2] ARMV7: S5P: rename from s5pc1xx to s5p
Because of these are common files around s5p Socs, rename from s5pc1xx to s5p.
And getting cpu_id is SoC specific, so move to SoC's header file.
Signed-off-by: Minkyu Kang
Signed-off-by: Kyungmin Park
---
v2: moves read funcion also to s5p_set_cpu_id().
arch/arm/cpu/armv7/s5p-common/cpu_info.c | 11 +--
arch/arm/cpu/armv7/s5p-common/timer.c| 16
arch/arm/cpu/armv7/s5pc1xx/clock.c |2 +-
arch/arm/include/asm/arch-s5pc1xx/clk.h |2 +-
arch/arm/include/asm/arch-s5pc1xx/cpu.h | 11 +--
arch/arm/include/asm/arch-s5pc1xx/pwm.h |8
6 files changed, 28 insertions(+), 22 deletions(-)
diff --git a/arch/arm/cpu/armv7/s5p-common/cpu_info.c
b/arch/arm/cpu/armv7/s5p-common/cpu_info.c
index 454175c..2f6c708 100644
--- a/arch/arm/cpu/armv7/s5p-common/cpu_info.c
+++ b/arch/arm/cpu/armv7/s5p-common/cpu_info.c
@@ -25,15 +25,14 @@
#include
/* Default is s5pc100 */
-unsigned int s5pc1xx_cpu_id = 0xC100;
+unsigned int s5p_cpu_id = 0xC100;
#ifdef CONFIG_ARCH_CPU_INIT
int arch_cpu_init(void)
{
- s5pc1xx_cpu_id = readl(samsung_get_base_pro_id());
- s5pc1xx_cpu_id = 0xC000 | ((s5pc1xx_cpu_id & 0x00FFF000) >> 12);
+ s5p_set_cpu_id();
- s5pc1xx_clock_init();
+ s5p_clock_init();
return 0;
}
@@ -41,7 +40,7 @@ int arch_cpu_init(void)
u32 get_device_type(void)
{
- return s5pc1xx_cpu_id;
+ return s5p_cpu_id;
}
#ifdef CONFIG_DISPLAY_CPUINFO
@@ -50,7 +49,7 @@ int print_cpuinfo(void)
char buf[32];
printf("CPU:\ts5...@%smhz\n",
- s5pc1xx_cpu_id, strmhz(buf, get_arm_clk()));
+ s5p_cpu_id, strmhz(buf, get_arm_clk()));
return 0;
}
diff --git a/arch/arm/cpu/armv7/s5p-common/timer.c
b/arch/arm/cpu/armv7/s5p-common/timer.c
index 6487c0f..1f1c7ff 100644
--- a/arch/arm/cpu/armv7/s5p-common/timer.c
+++ b/arch/arm/cpu/armv7/s5p-common/timer.c
@@ -44,14 +44,14 @@ static unsigned long long timestamp;/* Monotonic
incrementing timer */
static unsigned long lastdec; /* Last decremneter snapshot */
/* macro to read the 16 bit timer */
-static inline struct s5pc1xx_timer *s5pc1xx_get_base_timer(void)
+static inline struct s5p_timer *s5p_get_base_timer(void)
{
- return (struct s5pc1xx_timer *)samsung_get_base_timer();
+ return (struct s5p_timer *)samsung_get_base_timer();
}
int timer_init(void)
{
- struct s5pc1xx_timer *const timer = s5pc1xx_get_base_timer();
+ struct s5p_timer *const timer = s5p_get_base_timer();
u32 val;
/*
@@ -80,13 +80,13 @@ int timer_init(void)
lastdec = count_value;
val = (readl(&timer->tcon) & ~(0x07 << TCON_TIMER4_SHIFT)) |
- S5PC1XX_TCON4_AUTO_RELOAD;
+ TCON4_AUTO_RELOAD;
/* auto reload & manual update */
- writel(val | S5PC1XX_TCON4_UPDATE, &timer->tcon);
+ writel(val | TCON4_UPDATE, &timer->tcon);
/* start PWM timer 4 */
- writel(val | S5PC1XX_TCON4_START, &timer->tcon);
+ writel(val | TCON4_START, &timer->tcon);
timestamp = 0;
@@ -151,7 +151,7 @@ void __udelay(unsigned long usec)
void reset_timer_masked(void)
{
- struct s5pc1xx_timer *const timer = s5pc1xx_get_base_timer();
+ struct s5p_timer *const timer = s5p_get_base_timer();
/* reset time */
lastdec = readl(&timer->tcnto4);
@@ -160,7 +160,7 @@ void reset_timer_masked(void)
unsigned long get_timer_masked(void)
{
- struct s5pc1xx_timer *const timer = s5pc1xx_get_base_timer();
+ struct s5p_timer *const timer = s5p_get_base_timer();
unsigned long now = readl(&timer->tcnto4);
if (lastdec >= now)
diff --git a/arch/arm/cpu/armv7/s5pc1xx/clock.c
b/arch/arm/cpu/armv7/s5pc1xx/clock.c
index 67af84a..c9b5485 100644
--- a/arch/arm/cpu/armv7/s5pc1xx/clock.c
+++ b/arch/arm/cpu/armv7/s5pc1xx/clock.c
@@ -297,7 +297,7 @@ static unsigned long s5pc100_get_pclk(void)
return get_pclkd1();
}
-void s5pc1xx_clock_init(void)
+void s5p_clock_init(void)
{
if (cpu_is_s5pc110()) {
get_pll_clk = s5pc110_get_pll_clk;
diff --git a/arch/arm/include/asm/arch-s5pc1xx/clk.h
b/arch/arm/include/asm/arch-s5pc1xx/clk.h
index 3e59abe..c25e17a 100644
--- a/arch/arm/include/asm/arch-s5pc1xx/clk.h
+++ b/arch/arm/include/asm/arch-s5pc1xx/clk.h
@@ -29,7 +29,7 @@
#define HPLL 3
#define VPLL 4
-void s5pc1xx_clock_init(void);
+void s5p_clock_init(void);
extern unsigned long (*get_pll_clk)(int pllreg);
extern unsigned long (*get_arm_clk)(void);
diff --git a/arch/arm/include/asm/arch-s5pc1xx/cpu.h
b/arch/arm/include/asm/arch-s5pc1xx/cpu.h
index bcb8f5c..0e80ba3 100644
--- a/arch/arm/include/asm/arch-s5pc1xx/cpu.h
+++ b/arch/arm/include/asm/arch-s5pc1xx/cpu.h
@@ -57,13 +57,20 @@
#define S5PC110_VIC3_BASE 0xF230
#ifndef __ASSEMBLY__
+#include
/* CPU detection macros */
-extern unsigned int s5pc1xx_cpu_id;
+e
Re: [U-Boot] [PATCH] Align linebuf to avoid misaligned aliases of it
Le 19/08/2010 07:58, Mike Frysinger a écrit : > On Wednesday, August 18, 2010 16:36:39 Albert ARIBAUD wrote: >> Le 18/08/2010 19:54, Mike Frysinger a écrit : >>> On Wed, Aug 18, 2010 at 1:46 PM, Albert ARIBAUD wrote: Le 18/08/2010 18:46, Mike Frysinger a écrit : > you need to include linux/compiler.h first ... but i would have > thought this be a header already included globally. maybe that's a > new topic to start. I don't understand why I should introduce a dependency on linux. What is the benefit? >>> >>> u-boot already includes the header in the source tree, not to mention >>> the fact that this file is already including linux/ctype.h >> >> But absolutely no .h or .c file uses __aligned whereas >> __attribute__((__aligned__())) is used in several places, right? > > that would seem to be the case currently > -mike In that case, I'll stick with the currently used syntax for this patch. If someone feels the need to switch over to __aligned, I think issuing a separate global patch which changes all occurrences makes more sense than using both forms in the source code. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
