Bootable image for imx8qxp

[Matthias Weißer]

Hi

I currently try to create a bootable image of u-boot for the imx8qxp eval
board. If I follow the instruction in I see the following output on the
serial debug port:

U-Boot SPL 2020.10 (Oct 15 2020 - 15:54:37 +0200)
Normal Boot
Trying to boot from MMC2_2
Load image from MMC/SD 0x53800

And then nothing. So, it seems that SPL is running but the main u-boot
can't be started. Can anyone out there give me a hint on how to get
the board to the u-boot prompt?

BTW:
I also tried the NXP provided u-boot (seems to be a modified 2020.04)
with the same result. I also tried different combinations of SECO and
SCFW versions. Always with the same result in hanging u-boot after SPL

Regards,
Matthias

Re: QSPI mode on imx6ull evk

[Matthias Weißer]

Am Mi., 22. Juli 2020 um 14:39 Uhr schrieb Peng Fan :
>
> > Subject: QSPI mode on imx6ull evk
> >
> > Hi
> >
> > I currently try to get the QSPI flash on the imx6ull evk working in quad 
> > mode.
> > This attempt fails as when spi_child_post_bind is called there seems to be 
> > no
> > spi child in the udevice (spi@21e) which then leads to
> > spi_slave_ofdata_to_platdata not called and the according definitions in the
> > device tree (like spi-rx-bus-width) are not parsed. I am using plain 
> > v2020.07
> > without any modifications on the MCIMX6ULL-EVK.
>
> Any device tree changes to make it work?

I have no idea what to change in the DT to make it work. I found some hints to
create an alias in the DT but everything i tried didn't help.

The qspi node in arch/arm/dts/imx6ul-14x14-evk.dtsi contains an entry for the
flash but it doesn't show up as child in spi_child_post_bind. Maybe its just
the wrong compatible string but I am clueless.


Regards

Matthias

QSPI mode on imx6ull evk

[Matthias Weißer]

Hi

I currently try to get the QSPI flash on the imx6ull evk working in quad mode.
This attempt fails as when spi_child_post_bind is called there seems to be no
spi child in the udevice (spi@21e) which then leads to
spi_slave_ofdata_to_platdata not called and the according definitions in the
device tree (like spi-rx-bus-width) are not parsed. I am using plain v2020.07
without any modifications on the MCIMX6ULL-EVK.

mx6ull_14x14_evk_defconfig was the config I used.

I tried to CC some of the people involved in the development of the affected
parts of u-boot. Please correct me if I am wrong. Any help would be appreciated.


Regards

Matthias

Re: [U-Boot] [PATCH] image: fix getenv_bootm_size() function

[Matthias Weißer]

Hi Hannes

I had the same problem. http://patchwork.ozlabs.org/patch/579391/ fixed it.

Regards,
Matthias


2016-02-08 15:01 GMT+01:00 Hannes Schmelzer :
>
>
> On 18.12.2015 06:17, Masahiro Yamada wrote:
>>
>> Currently, this function returns wrong size if "bootm_low" is defined,
>> but "bootm_size" is not.
>>
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>>   common/image.c | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/common/image.c b/common/image.c
>> index d63d9e0..f4a1dc8 100644
>> --- a/common/image.c
>> +++ b/common/image.c
>> @@ -472,9 +472,9 @@ phys_size_t getenv_bootm_size(void)
>>   #if defined(CONFIG_ARM) && defined(CONFIG_NR_DRAM_BANKS)
>> -   return gd->bd->bi_dram[0].size - tmp;
>> +   return gd->bd->bi_dram[0].size - (tmp - gd->bd->bi_dram[0].start);
>>   #else
>> -   return gd->bd->bi_memsize - tmp;
>> +   return gd->bd->bi_memsize - (tmp - gd->bd->bi_memstart);
>>   #endif
>>   }
>
> Hi Masahiro,
>
> your commit has been merged on 19.1. this year.
> Today i ran a test on my tseries board with most current u-boot/master.
>
> I ran into trouble booting my linux kernel:
>
> ---
> Kernel image @ 0x8020 [ 0x00 - 0x222720 ]
> ## Loading init Ramdisk from Legacy Image at 80a0 ...
>Image Name:
>Image Type:   ARM Linux RAMDisk Image (uncompressed)
>Data Size:12452646 Bytes = 11.9 MiB
>Load Address: 
>Entry Point:  
> ## Flattened Device Tree blob at 8010
>Booting using the fdt blob at 0x8010
> ERROR: Failed to allocate 0xbe0326 bytes below 0x1000.
> ramdisk - allocation error
> FDT creation failed! hanging...### ERROR ### Please RESET the board ###
> ---
>
> I debugged  bit am came to the conclusio, that the line
>
> +   return gd->bd->bi_dram[0].size - (tmp - gd->bd->bi_dram[0].start);
>
> brings me into trouble.
>
> On my board DRAM is configured as follows:
> U-Boot (BuR V2.0)# bdinfo
> arch_number = 0x
> boot_params = 0x8100
> DRAM bank   = 0x
> *-> start= 0x8000**
> **-> size = 0x1000**
> *
> so size minus start would give a negative number.
> I tried local revert of this commit and everything works as before.
>
> more correct would be
>
> +   return gd->bd->bi_dram[0].start - (tmp - gd->bd->bi_dram[0].size);
>
>
> whats your thinking about?
>
> best regards,
> Hannes
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] image: fix getenv_bootm_size() function again

[Matthias Weißer]

Hi Masahiro

2016-02-05 8:12 GMT+01:00 Masahiro Yamada :
> Commit 9c11135ce053 ("image: fix getenv_bootm_size() function") fixed
> the case where "bootm_low" is defined, but "bootm_size" is not.
> Instead, it broke the case where neither "bootm_low" nor "bootm_size"
> is defined.  Fix this function again.
>
> Fixes: 9c11135ce053 ("image: fix getenv_bootm_size() function")
> Signed-off-by: Masahiro Yamada 

This fixes the problem for me. Thanks a lot.

Tested-by: Matthias Weisser 

2016-02-05 8:12 GMT+01:00 Masahiro Yamada :
> Commit 9c11135ce053 ("image: fix getenv_bootm_size() function") fixed
> the case where "bootm_low" is defined, but "bootm_size" is not.
> Instead, it broke the case where neither "bootm_low" nor "bootm_size"
> is defined.  Fix this function again.
>
> Fixes: 9c11135ce053 ("image: fix getenv_bootm_size() function")
> Signed-off-by: Masahiro Yamada 
> ---
>
>  common/image.c | 21 +
>  1 file changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/common/image.c b/common/image.c
> index f4a1dc8..82ace38 100644
> --- a/common/image.c
> +++ b/common/image.c
> @@ -458,24 +458,29 @@ ulong getenv_bootm_low(void)
>
>  phys_size_t getenv_bootm_size(void)
>  {
> -   phys_size_t tmp;
> +   phys_size_t tmp, size;
> +   phys_addr_t start;
> char *s = getenv("bootm_size");
> if (s) {
> tmp = (phys_size_t)simple_strtoull(s, NULL, 16);
> return tmp;
> }
> +
> +#if defined(CONFIG_ARM) && defined(CONFIG_NR_DRAM_BANKS)
> +   start = gd->bd->bi_dram[0].start;
> +   size = gd->bd->bi_dram[0].size;
> +#else
> +   start = gd->bd->bi_memstart;
> +   size = gd->bd->bi_memsize;
> +#endif
> +
> s = getenv("bootm_low");
> if (s)
> tmp = (phys_size_t)simple_strtoull(s, NULL, 16);
> else
> -   tmp = 0;
> -
> +   tmp = start;
>
> -#if defined(CONFIG_ARM) && defined(CONFIG_NR_DRAM_BANKS)
> -   return gd->bd->bi_dram[0].size - (tmp - gd->bd->bi_dram[0].start);
> -#else
> -   return gd->bd->bi_memsize - (tmp - gd->bd->bi_memstart);
> -#endif
> +   return size - (tmp - start);
>  }
>
>  phys_size_t getenv_bootm_mapsize(void)
> --
> 1.9.1
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] 9c11135 breaks bootz

[Matthias Weißer]

Hi

9c11135 image: fix getenv_bootm_size() function breaks the bootz
command for me on a custom hardware (very similar to mx6sxsabresd but
with only 256MB RAM). I don't have bootm_size or bootm_low defined.

After reading zImage and dtb from serial flash I run

=> bootz 0x8080 - 0x8300
Kernel image @ 0x8080 [ 0x00 - 0x1e5f48 ]
## Flattened Device Tree blob at 8300
   Booting using the fdt blob at 0x8300
ERROR: Failed to allocate 0xb28a bytes below 0x1000.
device tree - allocation error
FDT creation failed! hanging...### ERROR ### Please RESET the board ###

I am totally unsure what the commit intents but subtracting the ram
start address from its size doesn't make much sense to me.

+   return gd->bd->bi_dram[0].size - (tmp - gd->bd->bi_dram[0].start);

Maybe someone can shed some light on this issue for me.

Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] arm: imx: Kernel not booting when environment is in QSPI

[Matthias Weißer]

Hi Stefan

Actually the interrupt flags are cleared in the driver found in the
linux tree from freescale before the interrupts are enabled

/* enable the interrupt */
writel(0x, q-iobase + QUADSPI_FR);
writel(QUADSPI_RSER_TFIE, q-iobase + QUADSPI_RSER);

Clearing of the flags is missing in the mainline driver. After adding
the clear mainline kernel boots with an unmodified u-boot. So, I think
I currently use a patched kernel until the change arrives in mainline.

Thanks to all
Matthias


2015-06-10 8:55 GMT+02:00 Stefan Roese s...@denx.de:
 Hi Matthias,

 On 10.06.2015 08:19, Matthias Weißer wrote:

 With some wild guessing I found out that it must be an interrupt
 issue. If I clear FR (offset 0x160) in the QSPI module using u-boot
 command Linux boots successfully. So it seams that u-boot should clear
 the interrupt flag of the QSPI module after it was used.


 Or the Linux driver should take care of clearing this before enabling the
 interrupts instead. In general Linux should make no assumption of the
 previously used/configured devices.

 Thanks,
 Stefan

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] arm: imx: Kernel not booting when environment is in QSPI

[Matthias Weißer]

Hi Peng

With some wild guessing I found out that it must be an interrupt
issue. If I clear FR (offset 0x160) in the QSPI module using u-boot
command Linux boots successfully. So it seams that u-boot should clear
the interrupt flag of the QSPI module after it was used.

Commands used to clear the flags:

= md 0x021e4160 1
021e4160: 08010001   
= mw 0x021e4160 0x08010001

I then added clearing FR in qspi_xfer

diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c
index 868df5f..cb67f98 100644
--- a/drivers/spi/fsl_qspi.c
+++ b/drivers/spi/fsl_qspi.c
@@ -765,6 +765,9 @@ int qspi_xfer(struct fsl_qspi_priv *priv, unsigned
int bitlen,
qspi_ahb_invalid(priv);
 #endif

+   qspi_write32(priv-flags, priv-regs-fr,
+   qspi_read32(priv-flags, priv-regs-fr));
+
return 0;
 }

This works for me.

Regards
Matthias

2015-06-10 3:45 GMT+02:00 Peng Fan b51...@freescale.com:
 Hi Matthias,

 I can not reproduce your issue. All is fine in my side.

 which version/branch are you using for uboot and linux? mainline or fsl 
 vendor?

 Regards,
 Peng.

 On Tue, Jun 09, 2015 at 10:24:38AM -0500, Nitin Garg wrote:
On 06/09/2015 10:02 AM, Fabio Estevam wrote:
 Adding some FSL folks in case they have some suggestions.

 Regards,

 Fabio Estevam

 On Tue, Jun 9, 2015 at 11:41 AM, Matthias Weißer m.weisse...@gmail.com 
 wrote:
 Hi

 I work with an imx6sx sdb. I observed that placing u-boot in QSPI
 flash and also having the environment in QSPI the linux kernel doesn't
 boot. The backtrace from the kernel contains 'fsl_qspi_probe'. If only
 u-boot resides in QSPI and the environment is on mmc then the kernel
 boots successfully.

 Some more investigation showed that even when u-boot and the
 environment is on mmc a simple
 = sf probe 1:0
 causing the kernel not to boot.

 So I suspect a problem with u-boot not leaving the QSPI hardware in a
 sane state for the kernel driver to take over control. If no serial
 flash operations are executed in u-boot I can access the flash in
 linux via mtd.

 Kernel and u-boot are both current git HEAD with minor changes. Anyone
 with an idea?

 Regards
 Matthias

 Kernel output:
 Starting kernel ...

 [0.00] Booting Linux on physical CPU 0x0
 [0.00] Linux version 4.1.0-rc7-00047-g5879ae5-dirty
 (mweisser@ldev) (gcc version 4.9.2 (crosstool-NG 1.20.0) ) #2 Tue Jun
 9 09:40:49 CEST 2015
 [0.00] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), 
 cr=10c53c7d
 [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
 instruction cache
 [0.00] Machine model: Freescale i.MX6 SoloX SDB RevB Board
 [0.00] cma: Reserved 16 MiB at 0xbf00
 [0.00] Memory policy: Data cache writeback
 [0.00] CPU: All CPU(s) started in SVC mode.
 [0.00] Built 1 zonelists in Zone order, mobility grouping on.
 Total pages: 260096
 [0.00] Kernel command line: console=ttymxc0,115200 ip=dhcp
 root=/dev/nfs nfsroot=192.168.1.60:/data/users/mweisser/tgt-fs/linux-fs
 consoleblank=0
 [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
 [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 
 bytes)
 [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 
 bytes)
 [0.00] Memory: 1006056K/1048576K available (6035K kernel code,
 321K rwdata, 1960K rodata, 232K init, 8310K bss, 26136K reserved,
 16384K cma-reserved, 0K highmem)
 [0.00] Virtual kernel memory layout:
 [0.00] vector  : 0x - 0x1000   (   4 kB)
 [0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
 [0.00] vmalloc : 0xc080 - 0xff00   (1000 MB)
 [0.00] lowmem  : 0x8000 - 0xc000   (1024 MB)
 [0.00] pkmap   : 0x7fe0 - 0x8000   (   2 MB)
 [0.00] modules : 0x7f00 - 0x7fe0   (  14 MB)
 [0.00]   .text : 0x80008000 - 0x807d7044   (7997 kB)
 [0.00]   .init : 0x807d8000 - 0x80812000   ( 232 kB)
 [0.00]   .data : 0x80812000 - 0x808624e0   ( 322 kB)
 [0.00].bss : 0x808624e0 - 0x8107ff88   (8311 kB)
 [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
 [0.00] Running RCU self tests
 [0.00] NR_IRQS:16 nr_irqs:16 16
 [0.00] L2C-310 erratum 769419 enabled
 [0.00] L2C-310 enabling early BRESP for Cortex-A9
 [0.00] L2C-310 full line of zeros enabled for Cortex-A9
 [0.00] L2C-310 ID prefetch enabled, offset 1 lines
 [0.00] L2C-310 dynamic clock gating enabled, standby mode enabled
 [0.00] L2C-310 cache controller enabled, 16 ways, 256 kB
 [0.00] L2C-310: CACHE_ID 0x41c8, AUX_CTRL 0x76430001
 [0.00] Switching to timer-based delay loop, resolution 333ns
 [0.07] sched_clock: 32 bits at 3000kHz, resolution 333ns,
 wraps every 715827882841ns
 [0.35] clocksource mxc_timer1: mask: 0x

[U-Boot] arm: imx: Kernel not booting when environment is in QSPI

[Matthias Weißer]

Hi

I work with an imx6sx sdb. I observed that placing u-boot in QSPI
flash and also having the environment in QSPI the linux kernel doesn't
boot. The backtrace from the kernel contains 'fsl_qspi_probe'. If only
u-boot resides in QSPI and the environment is on mmc then the kernel
boots successfully.

Some more investigation showed that even when u-boot and the
environment is on mmc a simple
= sf probe 1:0
causing the kernel not to boot.

So I suspect a problem with u-boot not leaving the QSPI hardware in a
sane state for the kernel driver to take over control. If no serial
flash operations are executed in u-boot I can access the flash in
linux via mtd.

Kernel and u-boot are both current git HEAD with minor changes. Anyone
with an idea?

Regards
Matthias

Kernel output:
Starting kernel ...

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.1.0-rc7-00047-g5879ae5-dirty
(mweisser@ldev) (gcc version 4.9.2 (crosstool-NG 1.20.0) ) #2 Tue Jun
9 09:40:49 CEST 2015
[0.00] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[0.00] Machine model: Freescale i.MX6 SoloX SDB RevB Board
[0.00] cma: Reserved 16 MiB at 0xbf00
[0.00] Memory policy: Data cache writeback
[0.00] CPU: All CPU(s) started in SVC mode.
[0.00] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 260096
[0.00] Kernel command line: console=ttymxc0,115200 ip=dhcp
root=/dev/nfs nfsroot=192.168.1.60:/data/users/mweisser/tgt-fs/linux-fs
consoleblank=0
[0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[0.00] Memory: 1006056K/1048576K available (6035K kernel code,
321K rwdata, 1960K rodata, 232K init, 8310K bss, 26136K reserved,
16384K cma-reserved, 0K highmem)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
[0.00] vmalloc : 0xc080 - 0xff00   (1000 MB)
[0.00] lowmem  : 0x8000 - 0xc000   (1024 MB)
[0.00] pkmap   : 0x7fe0 - 0x8000   (   2 MB)
[0.00] modules : 0x7f00 - 0x7fe0   (  14 MB)
[0.00]   .text : 0x80008000 - 0x807d7044   (7997 kB)
[0.00]   .init : 0x807d8000 - 0x80812000   ( 232 kB)
[0.00]   .data : 0x80812000 - 0x808624e0   ( 322 kB)
[0.00].bss : 0x808624e0 - 0x8107ff88   (8311 kB)
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[0.00] Running RCU self tests
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] L2C-310 erratum 769419 enabled
[0.00] L2C-310 enabling early BRESP for Cortex-A9
[0.00] L2C-310 full line of zeros enabled for Cortex-A9
[0.00] L2C-310 ID prefetch enabled, offset 1 lines
[0.00] L2C-310 dynamic clock gating enabled, standby mode enabled
[0.00] L2C-310 cache controller enabled, 16 ways, 256 kB
[0.00] L2C-310: CACHE_ID 0x41c8, AUX_CTRL 0x76430001
[0.00] Switching to timer-based delay loop, resolution 333ns
[0.07] sched_clock: 32 bits at 3000kHz, resolution 333ns,
wraps every 715827882841ns
[0.35] clocksource mxc_timer1: mask: 0x max_cycles:
0x, max_idle_ns: 637086815595 ns
[0.000888] Console: colour dummy device 80x30
[0.000918] Lock dependency validator: Copyright (c) 2006 Red Hat,
Inc., Ingo Molnar
[0.000927] ... MAX_LOCKDEP_SUBCLASSES:  8
[0.000934] ... MAX_LOCK_DEPTH:  48
[0.000941] ... MAX_LOCKDEP_KEYS:8191
[0.000948] ... CLASSHASH_SIZE:  4096
[0.000955] ... MAX_LOCKDEP_ENTRIES: 32768
[0.000961] ... MAX_LOCKDEP_CHAINS:  65536
[0.000968] ... CHAINHASH_SIZE:  32768
[0.000975]  memory used by lock dependency info: 5167 kB
[0.000983]  per task-struct memory footprint: 1152 bytes
[0.001006] Calibrating delay loop (skipped), value calculated
using timer frequency.. 6.00 BogoMIPS (lpj=3)
[0.001023] pid_max: default: 32768 minimum: 301
[0.001180] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[0.001196] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[0.002704] CPU: Testing write buffer coherency: ok
[0.003382] Setting up static identity map for 0x80008200 - 0x80008258
[0.006410] devtmpfs: initialized
[0.028795] VFP support v0.3: implementor 41 architecture 3 part 30
variant 9 rev 4
[0.029434] clocksource jiffies: mask: 0x max_cycles:
0x, max_idle_ns: 1911260446275 ns
[0.031015] pinctrl core: initialized pinctrl subsystem
[0.034119] NET: Registered protocol family 16
[0.037054] DMA: 

Re: [U-Boot] arm: imx: Kernel not booting when environment is in QSPI

[Matthias Weißer]

Hi Peng

I use mainline (current HEAD, u-boot 2015.07-rc2, linux 4.1.0-rc7) on
both sides.

Regards
Matthias

2015-06-10 3:45 GMT+02:00 Peng Fan b51...@freescale.com:
 Hi Matthias,

 I can not reproduce your issue. All is fine in my side.

 which version/branch are you using for uboot and linux? mainline or fsl 
 vendor?

 Regards,
 Peng.

 On Tue, Jun 09, 2015 at 10:24:38AM -0500, Nitin Garg wrote:
On 06/09/2015 10:02 AM, Fabio Estevam wrote:
 Adding some FSL folks in case they have some suggestions.

 Regards,

 Fabio Estevam

 On Tue, Jun 9, 2015 at 11:41 AM, Matthias Weißer m.weisse...@gmail.com 
 wrote:
 Hi

 I work with an imx6sx sdb. I observed that placing u-boot in QSPI
 flash and also having the environment in QSPI the linux kernel doesn't
 boot. The backtrace from the kernel contains 'fsl_qspi_probe'. If only
 u-boot resides in QSPI and the environment is on mmc then the kernel
 boots successfully.

 Some more investigation showed that even when u-boot and the
 environment is on mmc a simple
 = sf probe 1:0
 causing the kernel not to boot.

 So I suspect a problem with u-boot not leaving the QSPI hardware in a
 sane state for the kernel driver to take over control. If no serial
 flash operations are executed in u-boot I can access the flash in
 linux via mtd.

 Kernel and u-boot are both current git HEAD with minor changes. Anyone
 with an idea?

 Regards
 Matthias

 Kernel output:
 Starting kernel ...

 [0.00] Booting Linux on physical CPU 0x0
 [0.00] Linux version 4.1.0-rc7-00047-g5879ae5-dirty
 (mweisser@ldev) (gcc version 4.9.2 (crosstool-NG 1.20.0) ) #2 Tue Jun
 9 09:40:49 CEST 2015
 [0.00] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), 
 cr=10c53c7d
 [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
 instruction cache
 [0.00] Machine model: Freescale i.MX6 SoloX SDB RevB Board
 [0.00] cma: Reserved 16 MiB at 0xbf00
 [0.00] Memory policy: Data cache writeback
 [0.00] CPU: All CPU(s) started in SVC mode.
 [0.00] Built 1 zonelists in Zone order, mobility grouping on.
 Total pages: 260096
 [0.00] Kernel command line: console=ttymxc0,115200 ip=dhcp
 root=/dev/nfs nfsroot=192.168.1.60:/data/users/mweisser/tgt-fs/linux-fs
 consoleblank=0
 [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
 [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 
 bytes)
 [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 
 bytes)
 [0.00] Memory: 1006056K/1048576K available (6035K kernel code,
 321K rwdata, 1960K rodata, 232K init, 8310K bss, 26136K reserved,
 16384K cma-reserved, 0K highmem)
 [0.00] Virtual kernel memory layout:
 [0.00] vector  : 0x - 0x1000   (   4 kB)
 [0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
 [0.00] vmalloc : 0xc080 - 0xff00   (1000 MB)
 [0.00] lowmem  : 0x8000 - 0xc000   (1024 MB)
 [0.00] pkmap   : 0x7fe0 - 0x8000   (   2 MB)
 [0.00] modules : 0x7f00 - 0x7fe0   (  14 MB)
 [0.00]   .text : 0x80008000 - 0x807d7044   (7997 kB)
 [0.00]   .init : 0x807d8000 - 0x80812000   ( 232 kB)
 [0.00]   .data : 0x80812000 - 0x808624e0   ( 322 kB)
 [0.00].bss : 0x808624e0 - 0x8107ff88   (8311 kB)
 [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
 [0.00] Running RCU self tests
 [0.00] NR_IRQS:16 nr_irqs:16 16
 [0.00] L2C-310 erratum 769419 enabled
 [0.00] L2C-310 enabling early BRESP for Cortex-A9
 [0.00] L2C-310 full line of zeros enabled for Cortex-A9
 [0.00] L2C-310 ID prefetch enabled, offset 1 lines
 [0.00] L2C-310 dynamic clock gating enabled, standby mode enabled
 [0.00] L2C-310 cache controller enabled, 16 ways, 256 kB
 [0.00] L2C-310: CACHE_ID 0x41c8, AUX_CTRL 0x76430001
 [0.00] Switching to timer-based delay loop, resolution 333ns
 [0.07] sched_clock: 32 bits at 3000kHz, resolution 333ns,
 wraps every 715827882841ns
 [0.35] clocksource mxc_timer1: mask: 0x max_cycles:
 0x, max_idle_ns: 637086815595 ns
 [0.000888] Console: colour dummy device 80x30
 [0.000918] Lock dependency validator: Copyright (c) 2006 Red Hat,
 Inc., Ingo Molnar
 [0.000927] ... MAX_LOCKDEP_SUBCLASSES:  8
 [0.000934] ... MAX_LOCK_DEPTH:  48
 [0.000941] ... MAX_LOCKDEP_KEYS:8191
 [0.000948] ... CLASSHASH_SIZE:  4096
 [0.000955] ... MAX_LOCKDEP_ENTRIES: 32768
 [0.000961] ... MAX_LOCKDEP_CHAINS:  65536
 [0.000968] ... CHAINHASH_SIZE:  32768
 [0.000975]  memory used by lock dependency info: 5167 kB
 [0.000983]  per task-struct memory footprint: 1152 bytes
 [0.001006] Calibrating delay loop (skipped), value calculated
 using timer frequency.. 6.00 BogoMIPS (lpj=3

Re: [U-Boot] Strange CFI flash problem

[Matthias Weißer]

Hi Wolfgang

Am 11.04.2014 12:43, schrieb Wolfgang Denk:

Dear Matthias,

In message 5347bbbc.9000...@arcor.de you wrote:


we are currently trying to get an out-of-tree board based on 2013.01
back in sync with current master and observing a strange behavior which
we think is located in the CFI flash system. If we load an image via
tftp, copy it to flash and then try to run the image via bootm we see an
error while decomressing:

...

Uncompressing Kernel Image ... LZO: uncompress or overwrite error -5


Are you sure your malloc arena is big enough for LZO?  Try if
increasing it helps...


We increaded it from 4MB to 8MB and the behavior is still the same.

We also observed a different behavior when tftping the image to RAM and 
then directly executing it without copying it to flash. It seems that 
the flash device (EN29GL256H) is then in some a mode (maybe auto-select) 
which prevents it from normal read operations which doesn't allow the 
flash driver of the OS come up. We never saw this with our old u-boot. 
If there are no ideas left we will have to bisect the problem.


Regards
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Strange CFI flash problem

[Matthias Weißer]

Am 14.04.2014 08:09, schrieb Matthias Weißer:

Hi Wolfgang

Am 11.04.2014 12:43, schrieb Wolfgang Denk:

Dear Matthias,

In message 5347bbbc.9000...@arcor.de you wrote:


we are currently trying to get an out-of-tree board based on 2013.01
back in sync with current master and observing a strange behavior which
we think is located in the CFI flash system. If we load an image via
tftp, copy it to flash and then try to run the image via bootm we see an
error while decomressing:

...

Uncompressing Kernel Image ... LZO: uncompress or overwrite error -5


Are you sure your malloc arena is big enough for LZO?  Try if
increasing it helps...


We increaded it from 4MB to 8MB and the behavior is still the same.

We also observed a different behavior when tftping the image to RAM and
then directly executing it without copying it to flash. It seems that
the flash device (EN29GL256H) is then in some a mode (maybe auto-select)
which prevents it from normal read operations which doesn't allow the
flash driver of the OS come up. We never saw this with our old u-boot.
If there are no ideas left we will have to bisect the problem.


Bisecting was successfull. The commit introducing the problem is

commit ff9d2efdbf1b3b5263f81e843c6724b8bead7f1f
Author: Kees Cook keesc...@chromium.org
Date:   Fri Aug 16 07:59:15 2013 -0700

lzo: correctly bounds-check output buffer

This checks the size of the output buffer and fails if it was going to
overflow the buffer during lzo decompression.

Signed-off-by: Kees Cook keesc...@chromium.org
Acked-by: Simon Glass s...@chromium.org

This commit introduced the usage of the dst_len output parameter as 
additional input parameter containing the maximum output buffer size. 
This parameter isn't initialized in cmd_bootm.c:


 454 #ifdef CONFIG_LZO
 455 case IH_COMP_LZO: {
 456 size_t size;
 457
 458 printf(   Uncompressing %s ... , type_name);
 459
 460 ret = lzop_decompress(image_buf, image_len, load_buf, size);

Setting size to some big value (SZE_MAX is not avialable) fixed the 
behavior but I am unsure if this is the correct solution. I think its 
hard to get the max output buffer size at this point in cmd_bootm.c.


Regards
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Strange CFI flash problem

[Matthias Weißer]

Am 14.04.2014 17:38, schrieb Kees Cook:

On Mon, Apr 14, 2014 at 1:51 AM, Matthias Weißer weiss...@arcor.de wrote:

Am 14.04.2014 08:09, schrieb Matthias Weißer:


Hi Wolfgang

Am 11.04.2014 12:43, schrieb Wolfgang Denk:


Dear Matthias,

In message 5347bbbc.9000...@arcor.de you wrote:



we are currently trying to get an out-of-tree board based on 2013.01
back in sync with current master and observing a strange behavior which
we think is located in the CFI flash system. If we load an image via
tftp, copy it to flash and then try to run the image via bootm we see an
error while decomressing:


...


Uncompressing Kernel Image ... LZO: uncompress or overwrite error -5



Are you sure your malloc arena is big enough for LZO?  Try if
increasing it helps...



We increaded it from 4MB to 8MB and the behavior is still the same.

We also observed a different behavior when tftping the image to RAM and
then directly executing it without copying it to flash. It seems that
the flash device (EN29GL256H) is then in some a mode (maybe auto-select)
which prevents it from normal read operations which doesn't allow the
flash driver of the OS come up. We never saw this with our old u-boot.
If there are no ideas left we will have to bisect the problem.



Bisecting was successfull. The commit introducing the problem is

commit ff9d2efdbf1b3b5263f81e843c6724b8bead7f1f
Author: Kees Cook keesc...@chromium.org
Date:   Fri Aug 16 07:59:15 2013 -0700

lzo: correctly bounds-check output buffer

This checks the size of the output buffer and fails if it was going to
overflow the buffer during lzo decompression.

Signed-off-by: Kees Cook keesc...@chromium.org
Acked-by: Simon Glass s...@chromium.org

This commit introduced the usage of the dst_len output parameter as
additional input parameter containing the maximum output buffer size. This
parameter isn't initialized in cmd_bootm.c:

 454 #ifdef CONFIG_LZO
 455 case IH_COMP_LZO: {
 456 size_t size;
 457
 458 printf(   Uncompressing %s ... , type_name);
 459
 460 ret = lzop_decompress(image_buf, image_len, load_buf, size);

Setting size to some big value (SZE_MAX is not avialable) fixed the behavior
but I am unsure if this is the correct solution. I think its hard to get the
max output buffer size at this point in cmd_bootm.c.


Does this work?


Yes. Didn't saw that configuration option. Thanks.


---
From: Kees Cook keesc...@chromium.org
Subject: [PATCH] bootm: set max output for LZO

The LZO decompressor wasn't initializing the maximum output size.

Reported-by: Matthias Weißer weiss...@arcor.de
Signed-off-by: Kees Cook keesc...@chromium.org
---
  common/cmd_bootm.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 9751edc..c243a5b 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -453,7 +453,7 @@ static int bootm_load_os(bootm_headers_t *images,
unsigned long *load_end,
  #endif /* CONFIG_LZMA */
  #ifdef CONFIG_LZO
 case IH_COMP_LZO: {
-   size_t size;
+   size_t size = unc_len;

 printf(   Uncompressing %s ... , type_name);



Tested-by: Matthias Weißer weiss...@arcor.de

Regards
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Strange CFI flash problem

[Matthias Weißer]

Hi

we are currently trying to get an out-of-tree board based on 2013.01 
back in sync with current master and observing a strange behavior which 
we think is located in the CFI flash system. If we load an image via 
tftp, copy it to flash and then try to run the image via bootm we see an 
error while decomressing:


zmx25 tftpboot 0x8100 zmx25-gfx.lzo.img;
Using FEC device
TFTP from server 192.168.1.60; our IP address is 192.168.1.107
Filename 'zmx25-gfx.lzo.img'.
Load address: 0x8100
Loading: 
# 
  #

#
2.8 MiB/s
done
Bytes transferred = 2508249 (2645d9 hex)
zmx25 erase 0xA008 +${filesize};
 done
Erased 20 sectors
zmx25 cp.b 0x8100 0xA008 ${filesize};
Copy to Flash... done
zmx25 bootm  0xA008;
## Booting kernel from Legacy Image at a008 ...
   Image Name:   zmx25-gfx ifs
   Image Type:   ARM QNX Kernel Image (lzo compressed)
   Data Size:2508185 Bytes = 2.4 MiB
   Load Address: 8000
   Entry Point:  8000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... LZO: uncompress or overwrite error -5 
- must RESET board to recover

resetting ...

After the board is up and running again everything is fine when directly 
booting the image:


zmx25 bootm 0xa008
## Booting kernel from Legacy Image at a008 ...
   Image Name:   zmx25-gfx ifs
   Image Type:   ARM QNX Kernel Image (lzo compressed)
   Data Size:2508185 Bytes = 2.4 MiB
   Load Address: 8000
   Entry Point:  8000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
## Starting application at 0x80001cc0 ...

Doing an iminfo after the copy from RAM to flash (following the TFTP 
step) also fixes the problem. Or hides it. We tried with and without 
caches which didn't show any difference.


zmx25 flinfo

Bank # 1: CFI conformant flash (16 x 16)  Size: 32 MB in 256 Sectors
  AMD Standard command set, Manufacturer ID: 0x1C, Device ID: 0x227E2201
  Erase timeout: 8192 ms, write timeout: 1 ms
  Buffer write timeout: 1 ms, buffer size: 64 bytes

zmx25 bdinfo
arch_number = 0x0C29
boot_params = 0x8100
DRAM bank   = 0x
- start= 0x8000
- size = 0x03C0
eth0name= FEC
ethaddr = 66:15:00:87:02:00
current eth = FEC
ip_addr = 192.168.1.107
baudrate= 115200 bps
TLB addr= 0x83BF
relocaddr   = 0x83B6F000
reloc off   = 0xE3B6F000
irq_sp  = 0x83756F38
sp start= 0x83756F28
FB base = 0x

Any ideas?

Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] zmx25: Select CONFIG_OF_LIBFDT

[Matthias Weißer]

Hello Fabio

Am 04.07.2013 22:30, schrieb Fabio Estevam:

From: Fabio Estevam fabio.este...@freescale.com

Allow the boot of a device tree kernel.

Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
  include/configs/zmx25.h | 1 +
  1 file changed, 1 insertion(+)

diff --git a/include/configs/zmx25.h b/include/configs/zmx25.h
index e9216d9..871009d 100644
--- a/include/configs/zmx25.h
+++ b/include/configs/zmx25.h
@@ -90,6 +90,7 @@
  #include config_cmd_default.h
  #define CONFIG_CMD_NET
  #define CONFIG_CMD_CACHE
+#define CONFIG_OF_LIBFDT

  /*
   * Additional command



As I currently have no support for Linux on this board (but working on 
it) I would prefer if we can not apply this patch. My current 
development version (with a couple of other things enabled) doesn't fit 
into the reserved 256k. I need some more time to come up with a board 
update patch for this system.



Regards
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] imx: Kernel not booting with fdt

[Matthias Weißer]

Am 03.07.2013 03:16, schrieb Fabio Estevam:

On Tue, Jul 2, 2013 at 12:26 PM, Matthias Weißer weiss...@arcor.de wrote:

Hi

I try to boot a current 3.11 kernel on a custom iMX25 board using DT. u-boot
starts the kernel but it stops working just after the first eralyprintk
lines are out. The u-boot/kernel output:

bootm 0x8100 - 0x8080
## Booting kernel from Legacy Image at 8100 ...
   Image Name:   Linux-3.10.0
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:3834336 Bytes = 3.7 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 8080
   Booting using the fdt blob at 0x8080
   Loading Kernel Image ... OK
OK
   Loading Device Tree to 8374f000, end 837545d4 ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
[0.00] Booting Linux on physical CPU 0x0
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.10.0 (mweisser@ubuntu) (gcc version 4.7.3
(Ubuntu/Linaro 4.7.3-1ubuntu1) ) #4 Tue Jul 2 1
7:13:13 CEST 2013
[0.00] CPU: ARM926EJ-S [41069264] revision 4 (ARMv5TEJ), cr=00053177
[0.00] CPU: VIVT data cache, VIVT instruction cache
[0.00] Machine: Generic DT based system, model: Graf-Syteco zmx25


Not sure why you get a Generic DT based system here.


Isn't that supossed to be the right output for a DT kernel?


Can you post your dts file?


Sure. It is based on imx25-pdk.dts minus nand plus uart2 which is used 
as debug uart on the system in question.


/dts-v1/;
#include imx25.dtsi

/ {
model = Graf-Syteco zmx25;
compatible = fsl,zmx25, fsl,zmx25;

memory {
reg = 0x8000 0x400;
};
};

uart1 {
status = okay;
};

uart2 {
status = okay;
};

fec {
phy-mode = rmii;
status = okay;
};



Have you selected CONFIG_MACH_IMX25_DT=y on your kernel config file?


$ cat .config | grep CONFIG_MACH_IMX25_DT
CONFIG_MACH_IMX25_DT=y

Confirmed.


Also, make sure you have #define CONFIG_OF_LIBFDT on your U-boot
board config file.


$ cat include/configs/zmx25.h | grep CONFIG_OF_LIBFDT
#define CONFIG_OF_LIBFDT

Confirmed.

As the kernel is not crashing but hanging in an endless loop I will try 
if I can get some additional information via the JTAG debugger.


Regards
Matthias

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] imx: Kernel not booting with fdt

[Matthias Weißer]

Am 03.07.2013 13:25, schrieb Fabio Estevam:

The Generic DT based system is not usual.



Sure. It is based on imx25-pdk.dts minus nand plus uart2 which is used as
debug uart on the system in question.

/dts-v1/;
#include imx25.dtsi

/ {
model = Graf-Syteco zmx25;
compatible = fsl,zmx25, fsl,zmx25;


Ah, this should be:

compatible = graf,imx25-zmx25, fsl,imx25; (There is no valid match
against fsl,zmx25)

Then your dts file should be called 'imx25-zmx25.dts'

Hope this helps.


Yes. Thanks a lot. But why is that? Can you give me an explanation for 
that or point me to the correct documentation?


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] imx: Kernel not booting with fdt

[Matthias Weißer]

Am 03.07.2013 16:33, schrieb Fabio Estevam:

On Wed, Jul 3, 2013 at 11:20 AM, Matthias Weißer weiss...@arcor.de wrote:


Yes. Thanks a lot. But why is that? Can you give me an explanation for that
or point me to the correct documentation?


Does it boot now?


Yes, it does. And the output changed to

[0.00] Machine: Freescale i.MX25 (Device Tree Support), model: 
Graf-Syteco zmx25




I think you got Generic DT based system because your original entry
fsl,zmx25 is not valid.


Now I see. I changed imx25 to zmx25 for both the board and the 
processor which is clearly wrong. Thanks a lot.


Regards
Matthias


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] imx: Kernel not booting with fdt

[Matthias Weißer]

Hi

I try to boot a current 3.11 kernel on a custom iMX25 board using DT. 
u-boot starts the kernel but it stops working just after the first 
eralyprintk lines are out. The u-boot/kernel output:


bootm 0x8100 - 0x8080
## Booting kernel from Legacy Image at 8100 ...
   Image Name:   Linux-3.10.0
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:3834336 Bytes = 3.7 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 8080
   Booting using the fdt blob at 0x8080
   Loading Kernel Image ... OK
OK
   Loading Device Tree to 8374f000, end 837545d4 ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
[0.00] Booting Linux on physical CPU 0x0
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.10.0 (mweisser@ubuntu) (gcc version 4.7.3 
(Ubuntu/Linaro 4.7.3-1ubuntu1) ) #4 Tue Jul 2 1

7:13:13 CEST 2013
[0.00] CPU: ARM926EJ-S [41069264] revision 4 (ARMv5TEJ), cr=00053177
[0.00] CPU: VIVT data cache, VIVT instruction cache
[0.00] Machine: Generic DT based system, model: Graf-Syteco zmx25
[0.00] bootconsole [earlycon0] enabled
[0.00] Memory policy: ECC disabled, Data cache writeback

As this is my first contact with DT I expect a trivial error on my side. 
Anyone with any hint?


Regards
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Uncompress error with LZO

[Matthias Weißer]

18.10.2012 19:21, schrieb Tom Rini:

On Thu, Oct 18, 2012 at 02:24:20PM +0200, Matthias Wei?er wrote:

Hi

I get some misterious errors from time to time when decompressing an
LZO compressed image. The output is as follows

zmx25 bootm 0x8200
## Booting kernel from Legacy Image at 8200 ...
   Image Name:   zmx25-gfx ifs
   Image Type:   ARM QNX Kernel Image (lzo compressed)
   Data Size:8181868 Bytes = 7.8 MiB
   Load Address: 8000
   Entry Point:  8000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... LZO: uncompress or overwrite error
-5 - must RESET board to recover
resetting ...

RAM is from 0x8000 to 0x83ff. The image was transfered using
TFTP and has an uncompressed size of about 20MB. If I change
something in the image so that the compressed data is different it
works. If an image is broken it is always broken so the behavior
is reproducable. I compress the image under windows using:


So you're saying that changing the source image results in good, or bad,
behavior correct?  Can you try taking a bad source image and using lzop
on Linux instead?


Right. Small changes in the source image (which is not a linux kernel) 
can lead to a corrupted image. lzop under linux can decompress the image 
successfully. I also checked if it is possible to compress the image and 
make an u-boot image out of the compressed data under linux. This also 
worked without problems but when decompressing that image the error is 
the same.


lzo1x_decompress_safe from the current linux kernel is the same as that 
one used in u-boot.


Any ideas?

Regards
Matthias

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Uncompress error with LZO

[Matthias Weißer]

Hi

I get some misterious errors from time to time when decompressing an LZO 
compressed image. The output is as follows


zmx25 bootm 0x8200
## Booting kernel from Legacy Image at 8200 ...
   Image Name:   zmx25-gfx ifs
   Image Type:   ARM QNX Kernel Image (lzo compressed)
   Data Size:8181868 Bytes = 7.8 MiB
   Load Address: 8000
   Entry Point:  8000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... LZO: uncompress or overwrite error -5 
- must RESET board to recover

resetting ...

RAM is from 0x8000 to 0x83ff. The image was transfered using 
TFTP and has an uncompressed size of about 20MB. If I change something 
in the image so that the compressed data is different it works. If an 
image is broken it is always broken so the behavior is reproducable. I 
compress the image under windows using:


 lzop.exe -f -9 zmx25-gfx-codesys.ifs
 lzop.exe -V
  Lempel-Ziv-Oberhumer Packer
   Copyright (C) 1996 - 2010
lzop v1.03 Markus Franz Xaver Johannes Oberhumer  Nov 
1st 2010


lzop version: v1.03, Nov 1st 2010
lzop build date: Nov  1 2010 12:45:58

The image is then created with

 mkimage.exe  -A ARM -O QNX -T kernel -C lzo  -n zmx25-gfx-codesys 
ifs -a 0x8000 -e 0x8000 -d zmx25-gfx-codesys.ifs.lzo 
zmx25-gfx-codesys.lzo.img


Is someone out there who have observed similar behavior? Am I doing 
something wrong?


Regards
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] I2C on iMX25

[Matthias Weißer]

Hi Stefano

I am currently in the process of updating my zmx25 board support for a new
hardware revision where I need I2C access. I2C on imx25 currently fails
to build:

mxc_i2c.c: In function 'i2c_imx_get_clk':
mxc_i2c.c:101:31: error: 'MXC_IPG_PERCLK' undeclared (first use in this 
function)


I can easily fix this by replacing MXC_IPG_PERCLK with MXC_I2C_CLK. But
MXC_I2C_CLK is only defined for imx25. So, this change will break all other
imx chips. I can now add MXC_IPG_PERCLK to arch-mx25/clock.h and adopt
generic.c accordingly but I don't think that this is the right way to go
as the i2c clock can be different from perclk. Doing this
#define MXC_IPG_PERCLK MXC_I2C_CLK
in my config file is even more ugly.

Do you have any advice for me how to solve that?

Regards
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] I2C on iMX25

[Matthias Weißer]

Hi Stefano

Am 24.09.2012 11:45, schrieb Stefano Babic:

On 24/09/2012 11:32, Matthias Weißer wrote:

Hi Stefano



Hi Matthias,


I am currently in the process of updating my zmx25 board support for a new
hardware revision where I need I2C access. I2C on imx25 currently fails
to build:

mxc_i2c.c: In function 'i2c_imx_get_clk':
mxc_i2c.c:101:31: error: 'MXC_IPG_PERCLK' undeclared (first use in this
function)


Ok, I see.



I can easily fix this by replacing MXC_IPG_PERCLK with MXC_I2C_CLK. But
MXC_I2C_CLK is only defined for imx25. So, this change will break all other
imx chips.


But this seems the right solution. The mxc_get_clk() gets as parameter
an enum representing a peripheral or a special clock name, valid for a
SOC. The driver should use the peripheral name.


ACK


and updating the mxc_i2c driver to follow the same rule.


I can create such a patch but I am not able to runtime test it on any 
other system then imx25. Will do so.


Regards
Matthias

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] I2C on iMX25

[Matthias Weißer]

Am 24.09.2012 13:05, schrieb Benoît Thébaudeau:

Hi Stefano, Matthias,

On Monday, September 24, 2012 11:45:33 AM, Stefano Babic wrote:

On 24/09/2012 11:32, Matthias Weißer wrote:
 Hi Stefano


Hi Matthias,

 I am currently in the process of updating my zmx25 board support
 for a new
 hardware revision where I need I2C access. I2C on imx25 currently
 fails
 to build:

 mxc_i2c.c: In function 'i2c_imx_get_clk':
 mxc_i2c.c:101:31: error: 'MXC_IPG_PERCLK' undeclared (first use in
 this
 function)

Ok, I see.


I had the same issue a while ago. I have a fix for that. I will try to post it
tonight.


 I can easily fix this by replacing MXC_IPG_PERCLK with MXC_I2C_CLK.
 But
 MXC_I2C_CLK is only defined for imx25. So, this change will break
 all other
 imx chips.

But this seems the right solution. The mxc_get_clk() gets as
parameter
an enum representing a peripheral or a special clock name, valid for
a
SOC. The driver should use the peripheral name.


Yes and no. The best would be to add a clock abstraction function
imx_get_i2cclk(), like what exists for UART. This is what I did.


What is the advantage of such a function over i2c_imx_get_clk(MXC_I2C_CLK)?


Really I think the right way is to add MXC_I2C_CLK to the other SOCs,
adding the case in their specific mxc_get_clock() implementation, for
example for mx6 something like this:

diff --git a/arch/arm/cpu/armv7/mx5/clock.c
b/arch/arm/cpu/armv7/mx5/clock.c
index c67c3cf..8fa737a 100644
--- a/arch/arm/cpu/armv7/mx5/clock.c
+++ b/arch/arm/cpu/armv7/mx5/clock.c
@@ -482,6 +482,7 @@ unsigned int mxc_get_clock(enum mxc_clock clk)
case MXC_IPG_CLK:
return get_ipg_clk();
case MXC_IPG_PERCLK:
+   case MXC_I2C_CLK:
return get_ipg_per_clk();
case MXC_UART_CLK:
return get_uart_clk();


and updating the mxc_i2c driver to follow the same rule.


That can be a good solution. What do you think about my imx_get_i2cclk()?

Also, note that there are some broken clocks for i.MX25. I²C is one of them. It
should be:
case MXC_I2C_CLK:
return imx_get_perclk(I2C_PER_CLK);


Why that? My understanding is that imx_get_perclk picks the right clock 
as long as the 16 first entries of enum mxc_clock ar in the rigth order.


Regards
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] uboot and ZFS

[Matthias Weißer]

Am 07.05.2012 09:13, schrieb Jorgen Lundman:

 If you correctly skip the HW init, you can try booting u-boot from u-boot ...
 (now, WD will hate me for bringing this up :-) ). It's possible, but 
unsupported
 operation. You might need to do some research on this matter :-)



I was thinking more along the lines of;  Since I am testing a filesystem
driver, to have a small test binary I can run and just feed a patch to (be
it block device, or raw file) to test it can traverse, and read the contents.


You could use sandbox arch for this purpose and use an image of a zfs 
filesystem. You can then use your native toolchain to compile and debug 
u-boot.


Reagards
Matthias

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Sandbox question

[Matthias Weißer]

Am 23.04.2012 20:30, schrieb Wolfgang Denk:

Dear Matthias,

In message4f959612.7040...@arcor.de  you wrote:


Because you will have the same address for physical memory in all
instances of sandbox u-boot. This could simplify test scripts a bit.
Imagine testing tftp downloads to memory where DRAM bank-  start is
different for every program run. This was a PITA for me while testing
the tap ethernet simulation for sandbox. And that is why I came up with
the patch.


Agreed - though I would expect the mapping at least to be consistent
through all runs of the same binary image.


This would be the case as long as the u-boot image is run without ASLR 
which can be achieved by running it using setarch



Or is there something like $(ramstart) in u-boot?


Not yet - but it would be trivial to add.


And would fix the issue without any problems introduced by hinted mmap 
or an address translation layer. But ramstart would be different on 
every run of the binary if ASLR is active.


--
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] testing u-boot on virtual environment

[Matthias Weißer]

Am 24.12.2011 11:00, schrieb Albert ARIBAUD:
 I don't understand why we'd need a third way to map. It's still an issue 
 of physical vs virtual mapping, only in the sandbox case the 
 phys-vs-virt mapping should be done through the mmap()/munmap() OS 
 services (which at the moment it does not). Or am I missing something else?
 
 OTOH, while reading the sandbox board config header, I see this:
 
   /* Memory things - we don't really want a memory test */
 
 Seems to me like it comforts my comment that having 'effective' (in the 
 sense of 'having an actual effect') memory access commands does not make 
 much sense for sandbox -- it's an application in Linux and as such could 
 barely use physical memory unless it is reserved for it, which on a pure 
 development host is improbable: either the reserved memory is mundane 
 RAM and it would best be allocated to the sandbox app as BSS or data, or 
 it is actually mapped to some HW module and you had better make sure the 
 underlying Linux kernel never ever uses this module.

Don't forget that we have commands like tftpboot or fatload which both
get an address where to load the data. At least tftpboot is working with
my tap patch and USB should also be possible. So we may need to touch
more then just the memory commands to get the current situation fixed.

 But since the goal of sandbox is only to test U-Boot commands, not 
 perform actual bootloader tasks, it can test md/mw etc. with some big 
 array of RAM correctly 'mapped' to the working area defined through 
 CONFIG_SYS_MEMTEST_START and CONFIG_SYS_MEMTEST_END.
 
 I think mmap() allows the callerto suggest a value for the returned 
 pointer, but it is only a suggestion, so you can never be sure what 
 actual address the test RAM area will have in sandbox. But you can 
 always set a pair env vars with the actual values and write the md/mw 
 etc. tests so that they uses these values.

This was the way my original patch worked. It passed an address to mmap
which was unlikely to not match the returned address as far as I know
the typical linux process address space layout. The actual address was
then readable with the bdinfo command. Another possible solution would
be to assert when the address passed to mmap is not the same as the
returned address.

I think we should still think of sandbox as a tool which eases debugging
and shouldn't let it influence real systems by adding code to these
systems which is not needed.

Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] testing u-boot on virtual environment

[Matthias Weißer]

Hi Érico

Am 23.12.2011 14:19, schrieb Érico Porto:
 Thanks!
 
 Tried to do some memory display commands but got instant segmentation
 fault, and tried to run it as root - but then some bad things
 happened, so now I know no one should run it as root.
 
 I wanted to tryout a memory test algorithm I developed, but it seem
 u-boot runs with no ram access. If I could findout the ram address
 where it is located, I think then the 8MB it says it has wouldn't give
 me segmentation fault...

You could try to change the address passed to the mmap in
os.c: 92  void *os_malloc(size_t length) from NULL to something known.
0x2000 worked well for me when I added the RAM simulation. The
approach of a fixed RAM address was nacked for mainline but for tests I
still use this approach.

Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] AES128 in U-Boot

[Matthias Weißer]

Am 15.12.2011 08:30, schrieb Simon Glass:

Hi,

I am wanting to add an AES encryption library to U-Boot. I suppose it
should be written in C, with small compiled code/data size (rather
than high performance), GPL and fairly easy to read.

Does anyone have any suggestions?


Take a look at libtomcrypt -
http://libtom.org/?page=featureswhatfile=crypt

Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm926ejs: remove noop flush_dcache_all function

[Matthias Weißer]

Am 12.12.2011 00:09, schrieb Ilya Yanok:
 Commit 2f3427c added noop cache functions implementation for arm926ejs
 to fix compilation of drivers depending on these functions (DaVinci
 EMAC in particular).

 Unfortunately, the bug was introduced: noop implementation calls
 dcache_disable which calls flush_dcache_all which in turn calls
 dcache_disable thus creating an infinite loop.

 This patch removes noop implementation for flush_dcache_all, we already
 have default one in arch/arm/lib/cache.c and it should be used instead.

 Signed-off-by: Ilya Yanokya...@emcraft.com
 ---

 Hi Matthias,

 thanks for cathing this. Surely my initial patch was totally wrong.
 Could you please test this one?

This patches solves at least my problem. Thanks.

Tested-by: Matthias Weisser weiss...@arcor.de

Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Cache function change breaks zmx25

[Matthias Weißer]

Hi

commit 2f3427ccb915c6f6774f0bcebb67c648dc25dcfd
Author: Ilya Yanok ya...@emcraft.com
Date:   Mon Nov 28 06:37:32 2011 +

arm926ejs: add noop implementation for dcache ops

breaks zmx25 booting with the following command:

tftpboot 0x8200 foo.img; dcache on; bootm 0x8200

It is stuck then in an endless loop after dcache is disabled before 
jumping to the OS.



WARNING: cache operations are not implemented!
WARNING: disabling D-Cache now, you can re-enable itlater with 'dcache 
on' command



Switching on dcache after the tftp worked without problems until this 
patch. I think this should be fixed before the release as it may have 
effects on other boards doing similar things.


Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] undefined reference to `abort'

[Matthias Weißer]

Am 05.12.2011 18:28, schrieb Mike Frysinger:
 On Monday 05 December 2011 11:43:09 Shadid, Bill wrote:
 /opt/embedded/tools/usr/bin/../lib/gcc/powerpc-linux/4.2.2/m8540/libgcc.a(d
 ivsf3.o): In function `__divsf3':
 /opt/eldk/build/ppc-2008-04-01/work/usr/src/denx/BUILD/crosstool-0.43/buil
 d/gcc-4.2.2-glibc-20070515T2025-eldk/powerpc-linux/gcc-4.2.2/gcc/config/sof
 t-fp/divsf3.c:44: undefined reference to `abort'
 
 looks like you should be using a diff cross-compiler.  or ppc should grow 
 private libgcc support.
 -mike

Or just don't use any floating point operations in a bootloader. There
seems to be some usages of floats around in u-boot but most (all?) of
them are compile time calculations.

Just curious: Bill, what is the use case for float at runtime?

Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sandbox: Add timer simulation

[Matthias Weißer]

Am 28.11.2011 23:57, schrieb Mike Frysinger:
 On Monday 28 November 2011 16:40:29 Matthias Weisser wrote:
 Making sleep command work
 
 i like the idea, but using clock_xxx funcs makes me sad (generally requires a 
 newerish glibc and -lrt).  my only alternative proposal is to use usec's 
 with gettimeofday ... maybe that's good enough ?  although we'll probably 
 need 
 to add nsec support eventually anyways for the newer timer code ...

I would like to stay with clock_gettime(CLOCK_MONOTONIC, ...) as the
value isn't subjected to change when wall time is changed. Still there
are chances to get wrong (non monotonic) values when NTP adjusts
frequencies. Maybe some ifdef magic can be used to even use
CLOCK_MONOTONIC_RAW if it is available and fall back to gettimeofday in
case of older systems. The only thing would be then -lrt on the linker
command line which has to be sorted out somehow.

 feel like wiring up timer_get_us() too ?

Will do in a v2.

Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Reduce build times

[Matthias Weißer]

Am 02.11.2011 07:54, schrieb Wolfgang Denk:
 U-Boot Makefiles contain a number of tests for compiler features etc.
 which so far are executed again and again.  On some architectures
 (especially ARM) this results in a large number of calls to gcc.

 This patch makes sure to run such tests only once, thus largely
 reducing the number of execve system calls.

 Example: number of execve system calls for building the P2020DS
 (Power Architecture) and qong (ARM) boards, measured as:
   -  strace -f -e trace=execve -o /tmp/foo ./MAKEALLboard
   -  grep execve /tmp/foo | wc -l

   Before: After:  Reduction:
 ==
 P2020DS 20555 15205   -26%
 qong  31692   14490   -54%

 As a result, built times are significantly reduced, typically by
 30...50%.

 Signed-off-by: Wolfgang Denkw...@denx.de
 Cc: Andy Flemingaflem...@gmail.com
 Cc: Kumar Galaga...@kernel.crashing.org
 Cc: Albert Aribaudalbert.arib...@free.fr
 cc: Graeme Russgraeme.r...@gmail.com
 cc: Mike Frysingervap...@gentoo.org
 ---

Nice. Some additional numbers:

zmx25: make
---
real1m47.546s 0m57.213s -53%
user1m39.698s 0m54.831s
sys 0m24.798s 0m9.509s


zmx25: make -j2
---
real0m56.791s 0m32.187s -57%
user1m38.478s 0m55.571s
sys 0m24.522s 0m9.513s

Tested-by: Matthias Weisser weiss...@arcor.de

Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Makefile : fix generation of cpu related asm-offsets.h

[Matthias Weißer]

Dear Stefano

Am 17.08.2011 12:12, schrieb Stefano Babic:
 commit 0edf8b5b2fa0d210ebc4d6da0fd1aceeb7e44e47 breaks
 building on a different directory with the O= parameter.
 The patch wil fix this issue, generating always asm-offsets.h before
 the other targets.

 Signed-off-by: Stefano Babicsba...@denx.de
 ---

 Note: the patch fixes the issue, however I generate an empty asm-offsets.c
 for boards that do not have one. Is there a better way to reach the goal ?

Wouldn't it be possible to just create an empty asm-offsets.h if there 
is no asm-offsets.c?

And maybe it is handy to add the auto-generated files (asm-offsets.s/h) 
to the list of removed files of the clean or distclean target.

Regards
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Pull request: u-boot-arm/master -- updated

[Matthias Weißer]

Dear Albert

Am 04.08.2011 19:04, schrieb Albert ARIBAUD:
 Hi Wolfgang,

 Here is my pull request for u-boot-arm/master, from which I did remove
 the wrongly applied commits that you indicated and in which all patches
 submitted before the merge window closure are taken into account.

 Developers, please direct complaints to me for any ARM-directed patches
 submitted before the window closure, and which is not accounted for at
 this point.

I still missing http://patchwork.ozlabs.org/patch/96842/

Thanks
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: lib: memcpy: Do not copy to same address

[Matthias Weißer]

Dear Albert

Am 23.05.2011 11:49, schrieb Albert ARIBAUD:
 Le 23/05/2011 11:30, Alexander Holler a écrit :
 Am 23.05.2011 11:06, schrieb Matthias Weisser:
 In some cases (e.g. bootm with a elf payload which is already at the right
 position) there is a in place copy of data to the same address. Catching 
 this
 saves some ms while booting.

 Signed-off-by: Matthias Weisserweiss...@arcor.de
 ---
 arch/arm/lib/memcpy.S |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/lib/memcpy.S b/arch/arm/lib/memcpy.S
 index 3b5aeec..f655256 100644
 --- a/arch/arm/lib/memcpy.S
 +++ b/arch/arm/lib/memcpy.S
 @@ -60,6 +60,9 @@
 .globl memcpy
 memcpy:

 +   cmp r0, r1
 +   moveq   pc, lr
 +
 enter   r4, lr

 subsr2, r2, #4

 The standard clearly say to both memory regions should not overlap when
 memcpy() is used, so I would say this is the wrong place to fix that.

 I think the intent here is not to enforce the standard but to handle an
 actual, and degenerate, copy request in the most efficient manner, and
 in that respect, the patch does its job.

Can this patch go in or do I need to change anything? I really would 
like to see it in mainline.

Regards,
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] i.MX51: FEC: Cache coherency problem?

[Matthias Weißer]

Dear Aneesh

Am 18.07.2011 18:16, schrieb Aneesh V:
 commit c2dd0d45540397704de9b13287417d21049d34c6
 armv7: integrate cache maintenance support

 In this patch I added a call to dcache_enable() at the beginning of
 board_init_r() for ARM(i.e. as soon as relocation is over). As a result
 D-cache will be enabled for all ARM platforms now unless
 CONFIG_SYS_DCACHE_OFF is set.

Is this really a good idea? This will break a couple of boards using 
non-cache-aware drivers. And there are a couple of them in u-boot. I 
think d-cache should be opt-in rather then opt-out as long as there are 
any drivers which didn't handle cached memory regions correct. i-cache 
is much less problematic and can be enabled by default.

If d-cache will be enabled by default on ARM I think I have to send a 
patch for one of my boards :-)

Regards
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] i.MX51: FEC: Cache coherency problem?

[Matthias Weißer]

Am 19.07.2011 13:19, schrieb Wolfgang Denk:
 Dear =?ISO-8859-1?Q?Matthias_Wei=DFer?=,

 In message4e256588.4010...@arcor.de  you wrote:

 Is this really a good idea? This will break a couple of boards using
 non-cache-aware drivers. And there are a couple of them in u-boot. I
 think d-cache should be opt-in rather then opt-out as long as there are
 any drivers which didn't handle cached memory regions correct. i-cache
 is much less problematic and can be enabled by default.

 If we do this, then everybody will just be lazy, and nothing will ever
 change.

You are right. But time is a limited resource. And fixing cache related 
issues is a bit more complex then, for example, the simple changes 
needed when relocation was introduced in ARM.

 If d-cache will be enabled by default on ARM I think I have to send a
 patch for one of my boards :-)

 Why don't you just help identifying and fixing the problems in the
 misbehaving drivers?!?

 That would be a _much_ more helpful approach.

Well, that is what I meant. I have to fix the driver then. But this will 
interfere with the fact that time is a lim You know ;-)

If both of my boards are in mainline I will take a look at them and try 
to fix problematic drivers (mainly USB OHCI should be the problem)

Regards
Matthias

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/5] imx: Add support for zmx25 board

[Matthias Weißer]

Hi Stefano

Am 30.06.2011 17:36, schrieb Stefano Babic:
 On 06/30/2011 11:57 AM, Matthias Weisser wrote:
 zmx25 is a board based on imx25 SoC, 64 Megs of LPDDR, 32 Megs of NOR flash, 
 an
 optional NAND flash.

 Hi Matthias,

 diff --git a/board/syteco/zmx25/lowlevel_init.S 
 b/board/syteco/zmx25/lowlevel_init.S
 new file mode 100644
 index 000..4f3b756

 +#includeasm/macro.h
 +#includeasm/arch/imx-regs.h
 +#includeasm/arch/asm-offsets.h
 +
 +.macro init_aips
 +write32 IMX_AIPS1_BASE + AIPS_MPR_0_7, 0x
 +write32 IMX_AIPS1_BASE + AIPS_MPR_8_15, 0x
 +write32 IMX_AIPS2_BASE + AIPS_MPR_0_7, 0x
 +write32 IMX_AIPS2_BASE + AIPS_MPR_8_15, 0x
 +.endm
 +
 +.macro init_max
 +write32 IMX_MAX_BASE + MAX_MPR0, 0x43210
 +write32 IMX_MAX_BASE + MAX_MPR1, 0x43210
 +write32 IMX_MAX_BASE + MAX_MPR2, 0x43210
 +write32 IMX_MAX_BASE + MAX_MPR3, 0x43210
 +write32 IMX_MAX_BASE + MAX_MPR4, 0x43210
 +
 +write32 IMX_MAX_BASE + MAX_SGPCR0, 0x10
 +write32 IMX_MAX_BASE + MAX_SGPCR1, 0x10
 +write32 IMX_MAX_BASE + MAX_SGPCR2, 0x10
 +write32 IMX_MAX_BASE + MAX_SGPCR3, 0x10
 +write32 IMX_MAX_BASE + MAX_SGPCR4, 0x10
 +
 +write32 IMX_MAX_BASE + MAX_MGPCR0, 0x0
 +write32 IMX_MAX_BASE + MAX_MGPCR1, 0x0
 +write32 IMX_MAX_BASE + MAX_MGPCR2, 0x0
 +write32 IMX_MAX_BASE + MAX_MGPCR3, 0x0
 +write32 IMX_MAX_BASE + MAX_MGPCR4, 0x0
 +.endm

 All these macro are in common with karo/tx25 and you added useful names
 instead of raw hexadecimal values. This code is not strictly related to
 the board, but it is part of the processor initialisation.

 I am thinking about if we can factorize this stuff. What about to have a
 file in asm/arch/ that can be included by all i.MX25 boards ?

I can do that. Would you suggest a name of this new file? Is there any 
convention of file extensions for asm files that can be included and 
define macros? Both .h and .S seems no the right extension to me.

 +/*
 + * Set up LAN-RESET and FEC_RX_ERR
 + *
 + * LAN-RESET:  gpio3[16] is ALT 5 mode of pin U20
 + * FEC_RX_ERR: FEC_RX_ERR is ALT 2 mode of pin R2
 + */
 +muxctl = (struct iomuxc_mux_ctl *)IMX_IOPADMUX_BASE;
 +padctl = (struct iomuxc_pad_ctl *)IMX_IOPADCTL_BASE;
 +
 +writel(gpio_mux_mode5,muxctl-pad_upll_bypclk);
 +writel(gpio_mux_mode2,muxctl-pad_uart2_cts);
 +
 +/* assert PHY reset (low) */
 +val = readl(gpio3-dr)  ~(1  16);
 +writel(val,gpio3-dr);
 +val = readl(gpio3-dir) | (1  16);
 +writel(val,gpio3-dir);

 For i.MX there are accessors to access gpios (mxc_gpio_*). They are not
 yet extended to the i.MX25, but I see the internal structure is the same
 as for other i.MX processors. As far as I can see, it should be enough
 to change the i.MX25 imx-reg-h using the same defines gor GPIO base
 addresses already used by other microprocessors.

Yes, this can be done. But it will break at least tx25 board. I can fix 
tx25 and build test it. But as I have no hardware I can't runtime test 
it. What would be right way to do this?

 +void dram_init_banksize(void)
 +{
 +gd-bd-bi_dram[0].start = PHYS_SDRAM;
 +gd-bd-bi_dram[0].size = gd-ram_size;
 +}

 You copy the same function that is defined as weak in
 arch/arm/lib/board.c. You could rely on that function and drop this one.

OK

 +#define CONFIG_CMDLINE_TAG  1   /* enable passing of ATAGs  */

 You do not need to set this to 1, it is enough to define it. The same
 for most of the defines in this file.

OK

Thanks for you review. As soon as I have answers to my questions above I 
will come up with a v2 of the series.

Regards,
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/5] imx: Add get_tbclk() function for imx25

[Matthias Weißer]

Hi Stefano

Am 30.06.2011 17:38, schrieb Stefano Babic:
 On 06/30/2011 11:57 AM, Matthias Weisser wrote:
 Need this function for autoboot keyd


 Hi Matthias,

 +/*
 + * This function is derived from PowerPC code (timebase clock frequency).
 + * On ARM it returns the number of timer ticks per second.
 + */
 +ulong get_tbclk(void)
 +{
 +ulong tbclk;
 +
 +tbclk = CONFIG_MX25_CLK32;
 +return tbclk;
 +}

 Which is the advantage to add this function instead using directly
 CONFIG_MX25_CLK32 in the caller ? It is not me so clear..

The caller is in common code (see common/main.c line 76 - 97). I think 
if I add CONFIG_MX25_CLK32 there whis will break a couple of boards 
which I don't want to. ;-)

Also, we will have all this stuff cleaned up when the timer redesign 
comes in.

Regards,
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2] memcpy/memmove: Do not copy to same address

[Matthias Weißer]

Dear Wolfgang

Am 14.06.2011 08:18, schrieb Matthias Weißer:
 Am 23.05.2011 11:03, schrieb Matthias Weisser:
 In some cases (e.g. bootm with a elf payload which is already at the right
 position) there is a in place copy of data to the same address. Catching this
 saves some ms while booting.

 What about this patch? As the initial submission of the patch was inside
 the merge window (see http://patchwork.ozlabs.org/patch/90725/) I would
 like to see the current version of this patch (see
 http://patchwork.ozlabs.org/patch/96841/) in the upcoming release.

May I kindly ask you if http://patchwork.ozlabs.org/patch/96841/ can go 
in as the merge window is now open again?

Thanks
Matthias


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/5] imx: Use correct imx25 reset.c

[Matthias Weißer]

Hello Wolfgang

Am 30.06.2011 12:49, schrieb Wolfgang Denk:
 +$(OBJS) : $(TOPDIR)/include/asm/arch/asm-offsets.h
 +
   #

   # defines $(obj).depend target
 @@ -44,3 +44,14 @@ include $(SRCTREE)/rules.mk
   sinclude $(obj).depend

   #
 +
 +$(TOPDIR)/include/asm/arch/asm-offsets.h:   
 $(TOPDIR)/include/autoconf.mk.dep \
 +./asm-offsets.s
 +@echo Generating $@
 +$(TOPDIR)/tools/scripts/make-asm-offsets ./asm-offsets.s $@
 +
 +asm-offsets.s:  $(TOPDIR)/include/autoconf.mk.dep \
 +./asm-offsets.c
 +$(CC) -DDO_DEPS_ONLY \
 +$(CFLAGS) $(CFLAGS_$(BCURDIR)/$(@F)) $(CFLAGS_$(BCURDIR)) \
 +-o $@ ./asm-offsets.c -c -S
 --

 Also, the asm-offset change is unrelated to the other change mentioned
 in your commit message.  These needs to be split into two separate
 commits.

You are right. That came in by accident. It should have been added in 
4/5 of the series. Will fix this in a v2.

Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/5] imx: Use correct imx25 reset.c

[Matthias Weißer]

Hello Wolfgang

Am 30.06.2011 12:46, schrieb Wolfgang Denk:
 +
 +$(TOPDIR)/include/asm/arch/asm-offsets.h:   
 $(TOPDIR)/include/autoconf.mk.dep \
 +./asm-offsets.s
 +@echo Generating $@
 +$(TOPDIR)/tools/scripts/make-asm-offsets ./asm-offsets.s $@
 +
 +asm-offsets.s:  $(TOPDIR)/include/autoconf.mk.dep \
 +./asm-offsets.c
 +$(CC) -DDO_DEPS_ONLY \
 +$(CFLAGS) $(CFLAGS_$(BCURDIR)/$(@F)) $(CFLAGS_$(BCURDIR)) \
 +-o $@ ./asm-offsets.c -c -S
 --

 NAK.

 See previous comments to Setano's postings.  It makes no sense to copy
 identical lines into a large number of Makefiles.

OK. I will address this point in a v2 of the series.

Matthias

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/5] imx: Add support for zmx25 board

[Matthias Weißer]

Am 30.06.2011 12:44, schrieb Wolfgang Denk:
 Dear Matthias Weisser,

 In message1309427865-17531-6-git-send-email-weiss...@arcor.de  you wrote:
 zmx25 is a board based on imx25 SoC, 64 Megs of LPDDR, 32 Megs of NOR flash, 
 an
 optional NAND flash.

 Signed-off-by: Matthias Weisserweiss...@arcor.de
 ---
   MAINTAINERS|1 +
   board/syteco/zmx25/Makefile|   51 +
   board/syteco/zmx25/lowlevel_init.S |  136 +++
   board/syteco/zmx25/zmx25.c |  209 
 
   boards.cfg |1 +
   include/configs/zmx25.h|  182 +++
   6 files changed, 580 insertions(+), 0 deletions(-)
   create mode 100644 board/syteco/zmx25/Makefile
   create mode 100644 board/syteco/zmx25/lowlevel_init.S
   create mode 100644 board/syteco/zmx25/zmx25.c
   create mode 100644 include/configs/zmx25.h

 checkpatch says:

 please, no space before tabs

I see. The checkpatch.pl I was using (0.28) didn't catch this. That one 
from latest kernel (0.31) does. So this will be fixed in v2.

 ...
 diff --git a/board/syteco/zmx25/zmx25.c b/board/syteco/zmx25/zmx25.c
 new file mode 100644
 index 000..c27ad20
 --- /dev/null
 +++ b/board/syteco/zmx25/zmx25.c
 @@ -0,0 +1,209 @@
 +/*
 + * (c) 2011 Graf-Syteco, Matthias Weisser
 + *weiss...@arcor.de

 Are you absolutely sure that this code was wriiten by you from
 scratch, without re-using any existing code?

Well, actually not. But as the changes where that big (there are only 
two handful of identical lines without comments and common function 
names) that I thought that it will be the right way to do it so. That 
may be wrong. I (re)add the copyright from tx25.c in v2.

 +void tx25_fec_init(void)
 ...
 +#define tx25_fec_init()

 etc.

 This looks suspiciously as if the code was copied from the TX25 board,
 and then adapted.  If so then what gives you the right to claim
 exclusive ownership of this code and remove/omit oall existing
 copyright entries???

See above. Will (re)add. It was not my intention to offend someone.

 ...
 +#define CONFIG_CMDLINE_TAG  1   /* enable passing of ATAGs  */
 +#define CONFIG_SETUP_MEMORY_TAGS 1
 +#define CONFIG_INITRD_TAG   1
 +#define BOARD_LATE_INIT 1

 Please omit values from #defines that enable features only.

 +#define CONFIG_BOOTP_BOOTFILESIZE   1
 +#define CONFIG_BOOTP_BOOTPATH   1
 +#define CONFIG_BOOTP_GATEWAY1
 +#define CONFIG_BOOTP_HOSTNAME   1

 Ditto. Please fix globally.

OK

 +#includeconfig_cmd_default.h
 +#define CONFIG_CMD_NET
 +#define CONFIG_CMD_CACHE
 +#undef CONFIG_CMD_FPGA
 +#undef CONFIG_CMD_IMLS
 +#undef CONFIG_CMD_LOADS
 +#undef CONFIG_CMD_SOURCE
 +#undef CONFIG_CMD_NFS
 +#undef CONFIG_CMD_XIMG

 Is there any specific reason for sisabling these commands?
 You don't appear to be very short on resources, so this makes no sense
 to me.

Well, mainly copy+paste from our other board jadecpu. I will remove 
these undefs in v2 as it only saves about 10k of image size, some of 
them may be useful and, as you have noticed, we are not short on flash.

Thanks for your review.

Matthias

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Removal of generated asm-offsets.s/h

[Matthias Weißer]

Hi

If a soc automatically generates asm-offsets.s/h in its makefile it 
isn't removed by a make clean or make distclean. See mx35 as an example. 
Even adding a clean: target to the SoCs makefile doesn't help. What 
would be the right way to remove these files with make clean?


Regards
Matthias Weißer
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Removal of generated asm-offsets.s/h

[Matthias Weißer]

Am 29.06.2011 16:20, schrieb Wolfgang Denk:
 Dear =?ISO-8859-15?Q?Matthias_Wei=DFer?=,

 In message4e0b3331.9030...@arcor.de  you wrote:

 If a soc automatically generates asm-offsets.s/h in its makefile it
 isn't removed by a make clean or make distclean. See mx35 as an example.
 Even adding a clean: target to the SoCs makefile doesn't help. What
 would be the right way to remove these files with make clean?

 Add it to the list of files to remove in the top level Makefile?

Well, thats is not that easy. The generated asm-offsets.h file ends up 
in arch/arm/include/asm/arch-mx35/ after a make mx35pdk_config make 
make distclean run. It is generated to include/asm/arch/ in the SoCs 
makefile so I don't understand why it ends up in 
arch/arm/include/asm/arch-mx35/

I don't think it makes sense to add a entry for each SoC using auto 
generated asm-offset files to the top level makefile. Same goes for the 
.s file as we shouldn't remove all .s files in the tree.

Matthias



___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2] memcpy/memmove: Do not copy to same address

[Matthias Weißer]

Hello Wolfgang

Am 23.05.2011 11:03, schrieb Matthias Weisser:
 In some cases (e.g. bootm with a elf payload which is already at the right
 position) there is a in place copy of data to the same address. Catching this
 saves some ms while booting.

What about this patch? As the initial submission of the patch was inside 
the merge window (see http://patchwork.ozlabs.org/patch/90725/) I would 
like to see the current version of this patch (see 
http://patchwork.ozlabs.org/patch/96841/) in the upcoming release.

Sorry for the broken reference in patchwork. I try my best next time.

If the community decides to NACK the patch I would be happy if you could 
accept http://patchwork.ozlabs.org/patch/79325/

Thanks
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: lib: memcpy: Do not copy to same address

[Matthias Weißer]

Am 23.05.2011 11:30, schrieb Alexander Holler:
 Am 23.05.2011 11:06, schrieb Matthias Weisser:
 In some cases (e.g. bootm with a elf payload which is already at the right
 position) there is a in place copy of data to the same address. Catching this
 saves some ms while booting.

 Signed-off-by: Matthias Weisserweiss...@arcor.de
 ---
arch/arm/lib/memcpy.S |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/lib/memcpy.S b/arch/arm/lib/memcpy.S
 index 3b5aeec..f655256 100644
 --- a/arch/arm/lib/memcpy.S
 +++ b/arch/arm/lib/memcpy.S
 @@ -60,6 +60,9 @@
.globl memcpy
memcpy:

 +cmp r0, r1
 +moveq   pc, lr
 +
  enter   r4, lr

  subsr2, r2, #4

 The standard clearly say to both memory regions should not overlap when
 memcpy() is used, so I would say this is the wrong place to fix that.

Well, real world applications do this. And these two instructions 
shouldn't hurt a lot.

I first send a patch fixing only my problem in cmd_elf.c but Wolfgang 
suggested to do this globally. Please see 
http://www.mail-archive.com/u-boot@lists.denx.de/msg50612.html as reference.

Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] USB on iMX25

[Matthias Weißer]

Am 19.05.2011 07:29, schrieb Sathish:
 Matthias Weißerweissermat  arcor.de  writes:
 Hi

 I am currently porting u-boot to a new board based on Freescales iMX25
 processor. I would like to add USB support. As I can see there is no
 support in current head for USB on iMX. Can someone give me some hints
 what I have to do to enable USB host support on iMX25.

 Matthias


 Hi Matthias,
 I'm also trying the same, did you got solution for your problem, if so kindly
 share with me.

Hi Sathish

I got it working and plan to submit a patchset for our iMX25 based board 
when the next merge window opens. I can send you the patch (which will 
probably break other iMX based boards) privatly if you are interested.

Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Update and Cut down mach types

[Matthias Weißer]

Hello Sandeep, Wolfgang

Am 19.04.2011 14:42, schrieb Paulraj, Sandeep:
 Wolfgang, Albert,

 Russell King sent some updates to the linux kernel for mach-types.

 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=6f82f4db80189281a8ac42f2e72396accb719b57

  He also removed a lot of entries which never made it to mainline.

 I have a patch and it is the branch below

 http://git.denx.de/?p=u-boot/u-boot-ti.git;a=shortlog;h=refs/heads/update-mach-types

 Please review and if it is acceptable to everyone then we should
 apply this patch to remain in sync with the mainline kernel.

This will break a least jadecpu. We don't use Linux on this board. When 
porting I was requested to reserve an MACH_ID just in case the board 
will ever be used with Linux. This has not been the case for this board. 
But I would like to have this board in the u-boot tree. What will be the 
solution for ARM but non-Linux u-boot ports then? What should be passed 
to gd-bd-bi_arch_number?

Regards,
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Do not copy to same address

[Matthias Weißer]

Am 12.04.2011 09:06, schrieb Albert ARIBAUD:
 Hi Matthias,

 Le 12/04/2011 08:58, Matthias Weisser a écrit :
 In some cases (e.g. bootm with a elf payload) there is a in place copy of
 data to the same address. Catching this saves some ms while booting.

 Signed-off-by: Matthias Weisserweiss...@arcor.de
 ---
lib/string.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)

 I believe that is a V2 patch, right? Please tag it as V2 in the subject
 line, and add patch history below the commit message delimiter ('---' ).

No, it is a replacement for http://patchwork.ozlabs.org/patch/79447/ 
which picks up a suggestion from Wolfgang.

Regards,
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Do not copy to same address

[Matthias Weißer]

Am 12.04.2011 09:05, schrieb Mike Frysinger:
 this summary is kind of weak.  please prefix it with something like string:
 or memcpy/memmove:.  keep in mind that the summary needs to quickly pick out
 what the changeset is doing from every other changeset in the tree based only
 on that.  or at least give a pretty good idea.

OK. I will wait for additional comments and post a V2 then.

 side note, i wonder why we even bother with bcopy at all.  i dont see any
 users of it in the tree ...

I see the same. But removal of bcopy should be a separate patch.

Regards,
Matthias

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Do not copy to same address

[Matthias Weißer]

Am 12.04.2011 09:27, schrieb Albert ARIBAUD:
 Hi Matthias,

 Le 12/04/2011 09:13, Matthias Weißer a écrit :
 Am 12.04.2011 09:06, schrieb Albert ARIBAUD:
 Hi Matthias,

 Le 12/04/2011 08:58, Matthias Weisser a écrit :
 In some cases (e.g. bootm with a elf payload) there is a in place
 copy of
 data to the same address. Catching this saves some ms while booting.

 Signed-off-by: Matthias Weisserweiss...@arcor.de
 ---
 lib/string.c | 9 +
 1 files changed, 9 insertions(+), 0 deletions(-)

 I believe that is a V2 patch, right? Please tag it as V2 in the subject
 line, and add patch history below the commit message delimiter ('---' ).

 No, it is a replacement for http://patchwork.ozlabs.org/patch/79447/
 which picks up a suggestion from Wolfgang.

 So it is a V3, not V2, but still you must tag it so that readers who see
 the previous patch can relate it to the 'replacement' -- yes, even if
 the files touched by V2 are different.

Well, as the patch is only slightly related to my original one I thought 
it is better to start a new patch as I had to change the subject also. 
The only relation between them would be the reference in the mail 
header. Maybe Wolfgang can bring some light into this situation.

What would be the right way to post this patch? And what would be the 
right way to post a patch doing exactly the same to the ARM optimized 
version of memcpy?

Sorry for all that administrative questions.

Regards,
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Image copy to ram

[Matthias Weißer]

Hi

I looked into the documentation but I can't find a command which copies 
an image from one address to another. This would be extremly useful for 
me as reading from (uncached) flash is way slower then reading from 
cached SDRAM. Currently booting is done by a simple bootm. This requires 
that the image is read from flash twice (once for checksum and once for 
decompression) If the image is copied to DRAM first it has to be read 
from flash only once. Checksum calculation and decompression is done in 
SDRAM which saves me about 500ms on my system. A further optimization 
would be to do the checksum calculation while copying the image to SDRAM 
which would save some more ms.

So, if there is no such command I am willing to implemt 'imcpy'.


Regards,
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Some notes and status on porting U-Boot to the Cavium 64-bit Octeon MIPS Processor

[Matthias Weißer]

Hi Aaron

Am 07.02.2011 23:02, schrieb Aaron Williams:
 5. Fix for Micron NAND flash MT29F32G08CBABA which erroneously reports a 16-
 bit bus when it has an 8-bit BUS.

Can you send that patch separately? I have a iMX25 board here with the 
2GiB version of that chip which also reports a 16 bit bus width. I 
didn't had time to look into this and if you have a fix for this...

Thanks,
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2] arm: Use optimized memcpy and memset from linux

[Matthias Weißer]

Am 26.01.2011 13:07, schrieb Albert ARIBAUD:
 ---

 IIRC, the '---' line separates patch commit message (above) from
 freeform comments and history (below). Here, at least the version
 history should move below the '---' line.

Wolfgang asked me that I add the numbers to the commit message. For the 
changelog I will investigate the git commands on how to do that best 
without manually editing the patch file before git send-email them.

 +- CONFIG_USE_ARCH_MEMCPY
 + CONFIG_USE_ARCH_MEMSET
 + If these options are used a optimized version of memcpy/memset will
 + be used if available. These functions may be faster under some
 + conditions but may increase the binary size.
 +

 The name of the options is not self-explaining to me. If the difference
 is generic vs arch-optimal, then maybe CONFIG_USE_ARCH_OPTIMAL_MEMxxx
 would be a better name?

Wolfgang didn't object on these names. If we use the OPTIMAL form it is 
still not clear what optimal mean. There may be a size optimized version 
and a speed optimized version. So we would need 
CONFIG_USE_ARCH_SPEED_OPTIMAL_MEMxxx which I personally dislike a lot as 
it is quite long. I also think that if there is an architecture specific 
function that it should be clear that this is optimal in some way.

Thanks for review

Regards
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: Use optimized memcpy and memset from linux

[Matthias Weißer]

Am 24.01.2011 21:07, schrieb Wolfgang Denk:
 OK - so which results do you see in reallife use, say when loading and
 booting an OS? How much boot time can be saved?

All tests are done with jadecpu

| HEAD(1)| HEAD(1)| HEAD(2)| HEAD(2)|
|| +patch || +patch |
---+++++
Reset to prompt|  438ms |  330ms |  228ms |  120ms |
|||||
TFTP a 3MB img | 4782ms | 3428ms | 3245ms | 2820ms |
|||||
FATLOAD USB a 3MB img* | 8515ms | 8510ms | -- | -- |
|||||
BOOTM LZO img in RAM   | 3473ms | 3168ms |  592ms |  592ms |
  where CRC is  |  615ms |  615ms |   54ms |   54ms |
  uncompress| 2460ms | 2462ms |  450ms |  451ms |
  final boot_elf|  376ms |   68ms |   65ms |   65ms |
|||||
BOOTM LZO img in FLASH | 3207ms | 2902ms | 1050ms | 1050ms |
  where CRC is  |  600ms |  600ms |  135ms |  135ms |
  uncompress| 2209ms | 2211ms |  828ms |  828ms |
  final boot_elf|  376ms |   68ms |   65ms |   65ms |

(1) No dcache
(2) dcache enabled in board_init
*Does not work when dcache is on

I think we can see that there seems to be no negativ impact of theses 
patches when only execution speed is taken into consideration. The gain 
is noticable when caching is not used or not activated. For pure RAM to 
RAM copy when caching is activated the patch didn't change anything.

Here are some additional numbers for copying a 1.4MB image from NOR to RAM:

HEAD  : 134ms
HEAD + patch  : 72ms
HEAD + dcache : 120ms
HEAD + dcache + patch : 70ms

So, for copy actions from flash to RAM there is also an improvement. As 
boot times are a bit critical or us every improvement  10ms is 
interesting for us.

 I guess the speed improvemnt you see for a few large copy operations
 is just one side - probably there will be slower excution (due to the
 effort to set up the operations) for the (many more frequent) small
 operations.  In addition, there is an increase of the memory footprint
 of nearly 1 kB.
 
 I think additional measuremnts need to be done - for example, we
 should check how the execution times change for typical operations
 like TFTP download, reading from NAND flash and MMC/SDcard, booting a
 Linux kernel etc.

As the test above show there is no negative performance impact with the 
test cases I have done. As we don't use Linux here I can't test this. 
Maybe someone other can jump in here.

 Also, it should be possible to enable this feature consditionally, so
 users can decide wether speed or size is more important in their
 configurations.

Would it be an option to use the CONFIG entries CONFIG_USE_ARCH_MEMCPY 
and CONFIG_USE_ARCH_MEMSET to enable that feature? If that is OK I can 
send a new version of the patch. The only problem I see with this 
approach is that there are architectures which already have their own 
implementations which are then not affected by these config options.


Regards
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: Use optimized memcpy and memset from linux

[Matthias Weißer]

Am 24.01.2011 17:13, schrieb Wolfgang Denk:
 Dear Matthias Weisser,
 
 In message 1295884607-9044-1-git-send-email-weiss...@arcor.de you wrote:
 Using optimized versions of memset and memcpy from linux brings a quite
 noticeable speed (x2 or better) improvement for these two functions.

 Size impact:

 C version:
textdata bss dec hex filename
  202862   18912  266456  488230   77326 u-boot

 ASM version:
textdata bss dec hex filename
  203798   18912  266288  488998   77626 u-boot
 
 How exactly did you measure the speed improvement?

I inserted a printf before and after calls to these functions with sizes
of 1MB or more each. I then measured the times between these printfs
using grabserial (http://elinux.org/Grabserial). In both cases caches
where enabled.

To be precise: As memset test case I used the memset(.., 0, ..) of the
malloc pool (which was 4MB in my case) and a memcpy from flash to RAM
which I inserted in cmd_bootm.c of about 2.2MB (see RFC patch
http://patchwork.ozlabs.org/patch/79480/ for exact location of the memcpy).

Do you think a factor of 2 is not possible against the C version? Maybe
I have done something wrong while measuring theses times. From my point
of view it should be possible to get such improvements as the code takes
cache alignment into account and also uses the PLD instruction.

I can do some additional measurements tomorrow on two systems (jadecpu
with a 32Bit@166MHz DDR2 memory and a imx25 based on with 16Bit@133MHz
LPDDR) and come up with some exact numbers. Maybe you can give some more
hints what and how the improvements of this patch can be measured.

Matthias Weißer
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] [NEXT]arm: Enable dcache in jadecpu

[Matthias Weißer]

Am 03.12.2010 09:47, schrieb Matthias Weisser:
 Enabling d cache leads to greatly improved image decompression times.

Please do not apply this patch as it causes some commands to fail when 
dcache is enabled. I will investigate the problem a send a working patch.

Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] arm: Activating dcache breaks 'usb start' and 'tftpboot' on jadecpu

[Matthias Weißer]

Hi

I just activated the dcache on our jadecpu board but it seems to me that 
this breaks some commands.

jade dcache
Data (writethrough) Cache is OFF
jade usb start
(Re)start USB...
USB:   scanning bus for devices... 2 USB Device(s) found
scanning bus for storage devices... 1 Storage Device(s) found
jade dcache on
Data (writethrough) Cache is ON
jade usb start
(Re)start USB...
USB:   scanning bus for devices... ERROR: CTL:TIMEOUT
2 USB Device(s) found
scanning bus for storage devices... 0 Storage Device(s) found
jade dcache off
Data (writethrough) Cache is OFF
jade usb start
(Re)start USB...
USB:   scanning bus for devices... 2 USB Device(s) found
scanning bus for storage devices... 1 Storage Device(s) found
jade

Same goes for tftpboot on this machine and also on a imx25 based system 
which is currently not in mainline. As there is a timeout involved I had 
the timer implementation under suspicion where some static variables may 
be used before relocation but moving them to gd_t didn't help.

Has anyone an explanation for this behavior? Is anyone out there having 
dcache running on an ARM926 and working usb/tftpboot?

Many thanks,
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] arm: Activating dcache breaks 'usb start' and 'tftpboot' on jadecpu

[Matthias Weißer]

Hello Wolfgang

Am 03.12.2010 15:47, schrieb Wolfgang Denk:
 Has anyone an explanation for this behavior? Is anyone out there having
 dcache running on an ARM926 and working usb/tftpboot?

 Many drivers have not been written to work with enabled caches.

What is the reason that special handling is needed when dcache is 
enabled? If a driver doesn't use any DMA there should be no need as the 
dcache is only enabled for the RAM and not for any memory mapped IO if I 
understand the code in arch/arm/lib/cache-cp15.c right.

 As far as USB is concerned, you might be lucky that your system usies
 a EHCI controller, so setting CONFIG_EHCI_DCACHE should help.

No, only OHCI.

 As for the network driver, you will probably have to figure out
 yourself how to fix that.

As the memory mapped network controller (SMSC9221) is not cached it 
shouldn't be a problem or do I miss something here?

 Patches welcome.

If someone can give me a little push into the right direction I will try 
but currently I have no idea what to do besides activating the cache 
right before the default bootm booting.

Thanks a lot
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] arm: Activating dcache breaks 'usb start' and 'tftpboot' on jadecpu

[Matthias Weißer]

Hello Wolfgang

Am 03.12.2010 16:33, schrieb Wolfgang Denk:
 Dear =?ISO-8859-1?Q?Matthias_Wei=DFer?=,
 
 In message 4cf90819.7040...@arcor.de you wrote:

 Has anyone an explanation for this behavior? Is anyone out there having
 dcache running on an ARM926 and working usb/tftpboot?

 Many drivers have not been written to work with enabled caches.

 What is the reason that special handling is needed when dcache is 
 enabled? If a driver doesn't use any DMA there should be no need as the 
 dcache is only enabled for the RAM and not for any memory mapped IO if I 
 understand the code in arch/arm/lib/cache-cp15.c right.
 
 On ARM, device write accesses are typically just store instructions
 (in C: assignments to a volatile pointer). With caches on, these
 accesses will be - guess what? cached, i. e. they are NOT written to

 the device, at least not immediately.  And if you repeatedly read a
 register (like when polling for some status bit to change) these
 accesses will be cached, too.

I understand this behavior. But it is only true if the memory area in
question is marked as cacheable.

 As the memory mapped network controller (SMSC9221) is not cached it 
 shouldn't be a problem or do I miss something here?
 
 You said you had enabled the data cache, so why do you think these
 accesses are not cached?

Please see arch/arm/lib/cache-cp15.c
The code there creates 4096 page table entries (1MB each) for the whole
4GB address space and initializes each entry in a way that it is not
cacheable (mmu_setup():71). It then changes the page table entries which
are pointing to a RAM area to make these, and only these, cacheable
(dram_bank_mmu_setup():57).

If the whole address space would be cached I would expect that even
writing to NOR flash fails as the write accesses wouldn't reach the
flash chip. But that works perfect on both of my systems.

Thanks
Matthias Weißer
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] arm: Activating dcache breaks 'usb start' and 'tftpboot' on jadecpu

[Matthias Weißer]

Am 03.12.2010 17:34, schrieb Albert ARIBAUD:
 In addition to making sure that register reads/write are not bitten by 
 caching, note that some controllers have DMA capabilities which require 
 proper cache handling for DMA memory buffers -- typically flushing them 
 from cache before a DMA to the device, and invalidating their cache 
 entries after a DMA from the device.

This is true. DMA and caching can be a lot of fun for a driver developer
:-) But I can guarantee that the network driver doesn't use any DMA
transfer as the hardware doesn't support it.

Thanks
Matthias Weißer
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2] imx25: Fix reset

[Matthias Weißer]

Am 26.10.2010 11:27, schrieb Reinhard Meyer:
 Dear Matthias Weisser,
 This patch fixes the reset command on imx25

 Signed-off-by: Matthias Weisserweiss...@arcor.de
 +writew(0x,regs-wcr);
 +writew(0x,regs-wsr);
 +writew(0x,regs-wsr);

 It might be nicer to use 16 Bit constants (with 4 hex digits)
 here..?

Sure. Would be nicer. I wait a bit for further comments and will create 
a V3 then.

Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] ARM: Warning with current master

[Matthias Weißer]

Am 20.10.2010 22:38, schrieb Albert ARIBAUD:
 This is an ld, not gcc, issue. What does arm-unknown-eabi-ld -V produce?

$ arm-unknown-eabi-ld -V
GNU ld (GNU Binutils) 2.19.1
   Supported emulations:
armelf

Thanks for your time
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] ARM: Warning with current master

[Matthias Weißer]

Hi

after pulling the latest changes I get the following warning during 
linking of arm boards (I tested jadecpu and tx25).

arm-unknown-eabi-ld: warning: creating a DT_TEXTREL in object.

Must have something to do with the latest ELF based relocation changes 
but I am not an expert in these tool chain related issues to dig a bit 
deeper into this issue.

I didn't test if the image runs on the target.

gcc version is 4.3.4

Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] ARM: Warning with current master

[Matthias Weißer]

Am 20.10.2010 09:44, schrieb Albert ARIBAUD:
 Le 20/10/2010 09:22, Matthias Weißer a écrit :
 Hi

 after pulling the latest changes I get the following warning during
 linking of arm boards (I tested jadecpu and tx25).

 arm-unknown-eabi-ld: warning: creating a DT_TEXTREL in object.

 Hmm... Which toolchain do you use?

I build it myself using crosstools-ng

$ arm-unknown-eabi-gcc -v
Using built-in specs.
Target: arm-unknown-eabi
Configured with: ~/ctdev/targets/src/gcc-4.3.4/configure 
--build=i686-build_pc-linux-gnu --host=i686-build_pc-linux-gnu 
--target=arm-unknown-eabi --prefix=~/x-tools/arm-unknown-eabi 
--with-local-prefix=~/x-tools/arm-unknown-eabi/arm-unknown-eabi//sys-root 
--disable-multilib 
--disable-libmudflap 
--with-sysroot=~/x-tools/arm-unknown-eabi/arm-unknown-eabi//sys-root 
--with-newlib --enable-threads=no --disable-shared 
--with-pkgversion=crosstool-NG-1.8.0 --disable-__cxa_atexit 
--with-gmp=~/ctdev/targets/arm-unknown-eabi/build/static 
--with-mpfr=~/ctdev/targets/arm-unknown-eabi/build/static 
--enable-target-optspace --disable-nls --enable-symvers=gnu 
--enable-languages=c,c++
Thread model: single
gcc version 4.3.4 (crosstool-NG-1.8.0)

Hope this helps.

Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] [NEXT]arm: Make jadecpu use relocation

[Matthias Weißer]

Hello Wolfgang

Am 05.10.2010 20:41, schrieb Wolfgang Denk:
 Dear Matthias Weisser,
 -gd-bd-bi_dram[0].start = PHYS_SDRAM;
 -gd-bd-bi_dram[0].size = PHYS_SDRAM_SIZE;
 +/* dram_init must store complete ramsize in gd-ram_size */
 +gd-ram_size = get_ram_size((volatile void *)PHYS_SDRAM,
 +PHYS_SDRAM_SIZE);

 Unfortunately this breaks building for this board:

 jadecpu.c: In function 'dram_init':
 jadecpu.c:158: error: 'gd_t' has no member named 'ram_size'
 jadecpu.c: In function 'dram_init_banksize':
 jadecpu.c:167: error: 'gd_t' has no member named 'ram_size'

 Can you please provide a fix? Thanks.

I am not sure how to fix this. gd_t contains a member ram_size if 
CONFIG_SYS_ARM_WITHOUT_RELOC is not defined. This is the case for our 
jadecpu board.

Also the patch is in current master branch and builds cleanly here.

Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Add new NAND flash

[Matthias Weißer]

Hi Scott

Am 01.10.2010 21:52, schrieb Scott Wood:
 On Fri, 1 Oct 2010 16:31:40 +0200
 MT29F16G08CBABA
 The NAND is connected (8 bit wide) to an iMX25 which is booting from 
 NOR. So the NAND is only a mass storage device. I am able to read the ID 
 of the chip.

 2Ch 48h 04h 46h 85h

 
 According to http://patchwork.ozlabs.org/patch/60042/, this chip
 is supposed to have ID: 2C 48 00 26 89

Take a closer look at the table in the link. There is a MT29F16G08ABABA
with ID: 2C 48 00 26 89 and a MT29F16G08CBABA with ID: 2C 48 04 46
85. The second one is the one I have here. I have also a datasheet of
the chip here from where I copy  pasted the above ID. The ID gets read
correctly from the chip by u-boot NAND subsystem.

 Do you have a datasheet that says what it's supposed to be?
 
 The bytes may be getting corrupted.  If you hack up the code to
 override the ID bytes with good ones, do you see any problems doing
 real I/O?

I tried that. If I run a nand bad command then it never returns and
keeps performing some actions on the NAND device as I can see with an
oscilloscope.

-- 
Matthias Weißer

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] USB on iMX25

[Matthias Weißer]

Hi

I am currently porting u-boot to a new board based on Freescales iMX25 
processor. I would like to add USB support. As I can see there is no 
support in current head for USB on iMX. Can someone give me some hints 
what I have to do to enable USB host support on iMX25.

Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFD] store env size in env area (+ cookie + len)

[Matthias Weißer]

Am 12.08.2010 08:43, schrieb Frans Meulenbroeks:
  I've seen a few times that people get a u-boot with their board and
  want to use fw_setenv under linux to tweak with environment variables.
  This requires them to come up with an fw-env.config (if not provided).
  One of the things that I've seen, that some people have trouble with
  it is obtaining the proper size of the environment area to be stuffed
  in that file.

  Con: not compatible with current env layout so (without precautions) a
  new u-boot cannot  use the old env and vice versa.

I didn't dig into the code but I don't think it is good idea to change 
the environment format. There may be (or at least there is for my board) 
code that scans the environment which is not derived from u-boot code. A 
new header entry would break this code.

Why not store the size of the environment sector as env variable? The 
size should be only needed for storing the environment and not for 
loading (as it is terminated by a '\0'). So we could load the 
environment, check for env_size and if its not there take the value 
from fw_env.config

Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V5 1/3] arm: Add support for MB86R0x SoCs

[Matthias Weißer]

Hello Wolfgang

Am 07.08.2010 23:35, schrieb Wolfgang Denk:
 Dear Matthias Weisser,

 In message1280734550-18403-2-git-send-email-weiss...@arcor.de  you wrote:
 +void __udelay(unsigned long usec)
 +{
 +unsigned long long tmp;
 +ulong tmo;
 +
 +tmo = usec_to_tick(usec);
 +tmp = get_ticks() + tmo;/* get current timestamp */
 +
 +while (get_ticks()  tmp)   /* loop till event */
 + /*NOP*/;

 This is broken when the timer wraps around. Compare the limit against
 the difference, to make use of unsigned arithmetics.

Isn't this a theoretical problem? The timer increments with approx. 
160kHz. get_ticks() returns a 64 bit value which wraps all ~ 3*10^6 
years. I don't expect my hardware to work that long without a reboot.

Can you point me to an example where the timer stuff is done right? I 
see it done differently on nearly all ARM SOCs.

Thanks for the review
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC][PATCH 00/19] arm: add full relocation / cache support

[Matthias Weißer]

Hello Heiko

Am 05.08.2010 08:19, schrieb Heiko Schocher:
 The board runs through my low level init (so DDR RAM is up) and later on
 crashes in the first call to memset. I could not further debug this as I

 Where is this memset()? The first after low level init is in:
 arch/arm/lib/board.c board_init_f(), do you mean this?

Yes. That was the point it crashed.

 If so, then something must be wrong with your memory setup.

It was at more then one point :-)

 Hmmm... from where did your board boot? I tried it on the tx25
 board, which boots from nand. Do you boot from a NOR flash?

Yes. My board boots from NOR.

 If so you *must* change TEXT_BASE in config.mk (see:
 doc/README.arm-relocation line 45) in your board directory
 to where u-boot starts in flash!

I think I missed that point.

 Ah, yep, this seems to me the reason why it don;t work for you:

 found in the patchseries you pointed to
 http://lists.denx.de/pipermail/u-boot/2010-August/074688.html

 board/syteco/jadecpu/config.mk
 [...]
 +TEXT_BASE = 0x4600

 change this to

 (as in include/configs/jadecpu.h is defined the following:

 +/*
 + * FLASH and environment organization
 + */
 +#define CONFIG_SYS_FLASH_BASE0x1000
 +#define CONFIG_SYS_MAX_FLASH_BANKS   1
 +#define CONFIG_SYS_MAX_FLASH_SECT256
 +#define CONFIG_SYS_MONITOR_BASE  CONFIG_SYS_FLASH_BASE
 )

 +TEXT_BASE = 0x1000

 and try it again.

I did that but the board still failed to boot and crashed at the first 
call to memset. So I had a nice debug session single stepping through 
the code with a lss file in parallel.

The reason it crashed so early was my setup of CONFIG_SYS_INIT_SP_ADDR 
which I set to the *beginning* of some 32k internal SRAM. And as the 
stack grows downwards it crashed right at the first push instruction.

So, I now have a running system with your patches and greatly improved 
uncompressing times of my boot images. We are now able to use compressed 
images which was not possible due to boot time restrictions in older 
versions. So it would be great if this stuff could go mainline.

Thanks,
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC][PATCH 00/19] arm: add full relocation / cache support

[Matthias Weißer]

Hello Heiko

 images which was not possible due to boot time restrictions in older
 versions. So it would be great if this stuff could go mainline.

 I hope so ;-) So, could you send a patch for this board, based on my
 RFC patches? I pick them up at first, and it will then go in mainline
 when it is time for this step ...

As my board is not mainlined (still waiting for any review on V5) this 
doesn't make sense from my point of view.

 (And it would be nice if you could send some testsresults, how faster
 let your boot time ;-)

Here are some numbers:

Test:  old (icache)  new (i+d cache)
image size  191k 204k x 1.06
copy 32MB NOR - RAM7.0s 6.5s x 1.07
iminfo of 1.2MiB image  0.5s 0.1s x 5.0
bootm of 1.2MiB gz image5.4s 0.5s x 10.8
bootm of 0.8MiB lzma image 17.1s 1.5s x 11.4
bootm of 1.6MiB lzo image   3.2s 0.2s x 16.0

The three images have all the same payload. Just tested the three 
different compression methods.

Boot time limit into application code is 5s so u-boot image compression 
was not an option. But now it is.

Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC][PATCH 00/19] arm: add full relocation / cache support

[Matthias Weißer]

Hello Heiko

Am 29.07.2010 12:44, schrieb Heiko Schocher:
 This patch series add full relocation and cache support for arm
 based boards. I did this for arm1136, arm_cortexa8 and arm926ejs
 based boards. As this change is not compatible to old code,
 before this can go to mainline *all* plattforms and boards
 have to be converted! As I don;t have access to all plattforms/
 boards I need help here! Also I couldn;t test all boards,
 so please test and report, send bugfixes!

I just tested your patch set on my version of u-boot for MB86R01 from 
Fujitsu (arm926ejs based SoC). This is currently not available in 
mainline u-boot but current patches are available here

http://lists.denx.de/pipermail/u-boot/2010-August/074688.html

The point is that the board doesn't boot after applying your patches and 
doing the changes to my board which are given at the end of this mail.

The board runs through my low level init (so DDR RAM is up) and later on 
crashes in the first call to memset. I could not further debug this as I 
have to admit that I am not an expert with GDB + BDI2000 debugging. 
Maybe you can give me some hints what I am missing.


Thanks

Matthias


Changes made to the board code after applying your patches:

diff --git a/include/configs/jadecpu.h b/include/configs/jadecpu.h
index bfc60a6..24aa23d 100644
--- a/include/configs/jadecpu.h
+++ b/include/configs/jadecpu.h
@@ -149,6 +149,10 @@
  #define PHYS_SDRAM 0x4000  /* Start address of 
DDRRAM */
  #define PHYS_SDRAM_SIZE0x0800  /* 128 megs */

+/* additions for new relocation code, must added to all boards */
+#define CONFIG_SYS_SDRAM_BASE  PHYS_SDRAM
+#define CONFIG_SYS_INIT_SP_ADDR0x0100
+
  /*
   * FLASH and environment organization
   */

diff --git a/board/syteco/jadecpu/jadecpu.c b/board/syteco/jadecpu/jadecpu.c
index 04d2f9d..bf96bcd 100644
--- a/board/syteco/jadecpu/jadecpu.c
+++ b/board/syteco/jadecpu/jadecpu.c
@@ -154,12 +154,18 @@ int misc_init_r(void)
   */
  int dram_init(void)
  {
-   gd-bd-bi_dram[0].start = PHYS_SDRAM;
-   gd-bd-bi_dram[0].size = PHYS_SDRAM_SIZE;
-
+   /* dram_init must store complete ramsize in gd-ram_size */
+   gd-ram_size = get_ram_size((volatile void *)PHYS_SDRAM,
+   PHYS_SDRAM_SIZE);
 return 0;
  }

+void dram_init_banksize (void)
+{
+   gd-bd-bi_dram[0].start = PHYS_SDRAM;
+   gd-bd-bi_dram[0].size = gd-ram_size;
+}
+
  int board_eth_init(bd_t *bis)
  {
 int rc = 0;



___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Support for MB86R01 cpu

[Matthias Weißer]

Hello Thirumalai

Am 18.05.2010 07:37, schrieb Thirumalai:
 Hi Matthias,
  We are using MB86R01 processor in our design. We just want to know
 what emulator/debugger can be used for initial board bring-up activity and
 also whether the latest u-boot(2010.03) is supporting this processor ?

I recently posted a patch series adding support for MB86R01 to u-boot. I 
did not receive any comments on V2 so I thinks its more or less fine and 
I hope it will be merged within the upcoming merge window.

See http://lists.denx.de/pipermail/u-boot/2010-May/071097.html for the 
initial mail of the patch series.

I am using a BDI2000 (http://www.abatron.ch/products/bdi-family.html) 
for initial flash programming. A Segger JLink 
(http://www.segger.com/cms/jlink.html) works also.

Hope this helped.

Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] arm: Add support for jadecpu board based on MB86R01 SoC

[Matthias Weißer]

Hallo Wolfgang

Am 22.04.2010 14:51, schrieb Wolfgang Denk:
   extern struct serial_device serial0_device;
   extern struct serial_device serial1_device;
   #if defined(CONFIG_SYS_NS16550_SERIAL)
 diff --git a/tools/Makefile b/tools/Makefile
 index 749d994..b2e73b2 100644
 --- a/tools/Makefile
 +++ b/tools/Makefile
 @@ -118,6 +118,9 @@ endif
   ifeq ($(VENDOR),ronetix)
   LOGO_BMP= logos/ronetix.bmp
   endif
 +ifeq ($(VENDOR),syteco)
 +LOGO_BMP= logos/syteco.bmp
 +endif

 Please keep list sorted.

S is behind R in alphabet as you know for sure. So, can you explain 
which list should be kept sorted?

Regards,
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] video: add support for display controller in MB86R0x SoCs

[Matthias Weißer]

Am 22.04.2010 14:41, schrieb Wolfgang Denk:
 Dear Matthias Weisser,

 In message1271932257-14618-3-git-send-email-weiss...@arcor.de  you wrote:
 This patch adds support for the display controller in
 the MB86R0x SoCs.

 Signed-off-by: Matthias Weisserweiss...@arcor.de
 ...
 +pGD-memSize = VIDEO_MEM_SIZE;
 +pGD-frameAdrs = PHYS_SDRAM + PHYS_SDRAM_SIZE - VIDEO_MEM_SIZE;

 Please pay attention to the global memory map requirements. PRAM might
 go first.

Can you please explain this a bit more in detail? I checked the source 
and README for CONFIG_PRAM and it seems to be reserving some space at 
the end of RAM. But I have only found reference to it in ppc and m68k code.

What would be the correct way to reserve some 2MB-4MB at the end of 
system RAM as a framebuffer for the integrated graphics device?

Thanks in advance

Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] video: add support for display controller in MB86R0x SoCs

[Matthias Weißer]

Am 28.04.2010 08:44, schrieb Wolfgang Denk:
 Dear Matthias,


 in message4bd7d5dd.6080...@arcor.de  you wrote:

 +  pGD-memSize = VIDEO_MEM_SIZE;
 +  pGD-frameAdrs = PHYS_SDRAM + PHYS_SDRAM_SIZE - VIDEO_MEM_SIZE;

 Please pay attention to the global memory map requirements. PRAM might
 go first.

 Can you please explain this a bit more in detail? I checked the source
 and README for CONFIG_PRAM and it seems to be reserving some space at
 the end of RAM. But I have only found reference to it in ppc and m68k code.

 Right. But there is a chance that the ARM implementation might be
 reworked soon, and then it will follow the documented approach as
 well, so better start correctly from the beginning so you don;t run
 into conflicts soon.

I totally agree with you, but...

 What would be the correct way to reserve some 2MB-4MB at the end of
 system RAM as a framebuffer for the integrated graphics device?

 See the PPC implementation for reference.

I had a look into the PPC code and its clear to me how it is done there. 
But I currently do not see how this can be done on ARM without a couple 
of changes to arch/arm/lib/board.c

Another question regarding the video driver:
I have seen some video drivers in driver/video/... and some are in 
arch/.../cpu/...

What would be the right place for mine? As it is integrated into the SoC 
I tend to put it in arch/arm/cpu/arm/arm926ejs/mb86r0x and not into 
drivers/video. On the other hand there is a imx31 related video driver 
in drivers/video.

Thanks for you patience
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] bootdelay can be an environemt variable

[Matthias Weißer]

Am 27.04.2010 10:19, schrieb Wolfgang Denk:
 Dear Matthias Weisser,

 In message1272348834-30161-1-git-send-email-weiss...@arcor.de  you wrote:
 This patch allows the bootdelay variable contain the name of
 another variable holding the actual bootdelay value.

 Why make the bootdelay variable in any way special, compared to all
 other variables? Such inconsistent handling makes no sense to me and
 will only confuse users (not to mentiuon that you don't even attempt
 to document the change).

 NAK.

 If you need any such evaluation, then perform it for example as part
 of a PREBOOT command. This allows you to do the same thing, in a clean
 way.

It was an attempt to get the bootdelay in an environment variable which 
can be overridden by board specific code.

With this I tried to follow your suggestion in 
http://lists.denx.de/pipermail/u-boot/2010-April/070431.html where you 
NAKed the direct override of bootdelay in board_late_init. So, currently 
my setup is:

bootdelay=gs_bootdelay

and in board.c I set gs_bootdelay according to some GPIO states. Another 
user of the board could simply change bootdelay to an integer and get 
rid of the boards behavior.

I don't see a way to achieve this with a PREBOOT command.

Is there a way that you accept the patch if I add a sentence or two to 
the README?

Regards,
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] arm: Add support for MB86R0x SoCs

[Matthias Weißer]

Am 22.04.2010 14:34, schrieb Wolfgang Denk:
  Dear Matthias Weisser,
 
  In message1271932257-14618-2-git-send-email-weiss...@arcor.de  you 
wrote:
  This patch adds support for MB86R0x SoCs from Fujitsu
 
  Signed-off-by: Matthias Weisserweiss...@arcor.de
  ...
  --- /dev/null
  +++ b/arch/arm/cpu/arm926ejs/mb86r0x/reset.c
  ...
  +void reset_cpu(ulong ignored)
  +{
  +writel(0x0002, MB86R0x_CRG_PHYS_BASE + CRG_CRSR);
 
  Please define some symbolic name for the magic constant 0x0002
 
  Also, we do not accept code based on a base + offset notation.
  Please use C structures instead. [Please fix globally.]

I will fix this

  +#define TIMER_LOAD_VAL0x
  +#define TIMER_BASEMB86R0x_TIMER_PHYS_BASE
  +
  +#define TIMER_REG_LOAD(TIMER_BASE + 0)
  +#define TIMER_REG_VALUE(TIMER_BASE + 4)
  +#define TIMER_REG_CONTROL(TIMER_BASE + 8)
 
  Create a proper C struct, please!

and this

  +/*
  + * Offset definitions for DRAM controller
  + */
  +#define DDR2C_DRIC0x00
  +#define DDR2C_DRIC10x02
  +#define DDR2C_DRIC20x04
  +#define DDR2C_DRCA0x06
  +#define DDR2C_DRCM0x08
  +#define DDR2C_DRCST10x0a
  +#define DDR2C_DRCST20x0c
  +#define DDR2C_DRCR0x0e
  +#define DDR2C_DRCF0x20
  +#define DDR2C_DRASR0x30
  +#define DDR2C_DRIMS0x50
  +#define DDR2C_DROS0x60
  +#define DDR2C_DRIBSLI0x62
  +#define DDR2C_DRIBSODT10x64
  +#define DDR2C_DRIBSOCD0x66
  +#define DDR2C_DRIBSOCD20x68
  +#define DDR2C_DROABA0x70
  +#define DDR2C_DROBV0x80
  +#define DDR2C_DROBS0x84
  +#define DDR2C_DROBSR10x86
  +#define DDR2C_DROBSR20x88
  +#define DDR2C_DROBSR30x8a
  +#define DDR2C_DROBSR40x8c
  +#define DDR2C_DRIMR10x90
  +#define DDR2C_DRIMR20x92
  +#define DDR2C_DRIMR30x94
  +#define DDR2C_DRIMR40x96
  +#define DDR2C_DROISR10x98
  +#define DDR2C_DROISR20x9a
 
  C struct, please.
 
  +/*
  + * Offset definitions Chip Control Module
  + */
  +#define CCNT_CCID0x00
  +#define CCNT_CSRST0x1c
  +#define CCNT_CIST0x20
  +#define CCNT_CISTM0x24
  +#define CCNT_CMUX_MD0x30
  +#define CCNT_CDCRC0xec
 
  Ditto.
 
  +/*
  + * Offset definitions clock reset generator
  + */
  +#define CRG_CRPR0x00
  +#define CRG_CRWR0x08
  +#define CRG_CRSR0x0c
  +#define CRG_CRDA0x10
  +#define CRG_CRDB0x14
  +#define CRG_CRHA0x18
  +#define CRG_CRPA0x1c
  +#define CRG_CRPB0x20
  +#define CRG_CRHB0x24
  +#define CRG_CRAM0x28
 
  Ditto.

Well, the above three modules are used in assembler code only 
(lowlevel_init.S) and I didn't found a way to use C structs here. What 
would be the right approach in this case? Defining all these registers
as absolute addresses?

I have a also a couple of magic values in the mentioned .S file. Do I 
have to move them also to some symbolic constants?

Thanks for the quick review.

Regards,
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] video: add support for display controller in MB86R0x SoCs

[Matthias Weißer]

Am 22.04.2010 14:41, schrieb Wolfgang Denk:
 Dear Matthias Weisser,

 In message1271932257-14618-3-git-send-email-weiss...@arcor.de  you wrote:
 This patch adds support for the display controller in
 the MB86R0x SoCs.

 Signed-off-by: Matthias Weisserweiss...@arcor.de
 ...
 +pGD-memSize = VIDEO_MEM_SIZE;
 +pGD-frameAdrs = PHYS_SDRAM + PHYS_SDRAM_SIZE - VIDEO_MEM_SIZE;

 Please pay attention to the global memory map requirements. PRAM might
 go first.


 +writel(dcm1, dspBase[i] + GC_DCM1);
 +writel(dcm2, dspBase[i] + GC_DCM2);
 +writel(dcm3, dspBase[i] + GC_DCM3);
 +
 +writew(htp, dspBase[i] + GC_HTP);
 +writew(hdp, dspBase[i] + GC_HDP);
 +writew(hdb, dspBase[i] + GC_HDB);
 +writew(hsp, dspBase[i] + GC_HSP);
 +writeb(hsw, dspBase[i] + GC_HSW);
 +
 +writeb(vsw, dspBase[i] + GC_VSW);
 +writew(vtr, dspBase[i] + GC_VTR);
 +writew(vsp, dspBase[i] + GC_VSP);
 +writew(vdp, dspBase[i] + GC_VDP);
 +
 +writel(l2m, dspBase[i] + GC_L2M);
 +writel(l2em, dspBase[i] + GC_L2EM);
 +writel(l2oa0, dspBase[i] + GC_L2OA0);
 +writel(l2da0, dspBase[i] + GC_L2DA0);
 +writel(l2oa1, dspBase[i] + GC_L2OA1);
 +writel(l2da1, dspBase[i] + GC_L2DA1);
 +writew(l2dx, dspBase[i] + GC_L2DX);
 +writew(l2dy, dspBase[i] + GC_L2DY);
 +writew(l2wx, dspBase[i] + GC_L2WX);
 +writew(l2wy, dspBase[i] + GC_L2WY);
 +writew(l2ww, dspBase[i] + GC_L2WW);
 +writew(l2wh, dspBase[i] + GC_L2WH);
 +
 +writel(dcm1 | (1  18) | (1  31), dspBase[i] + GC_DCM1);

 Please use a C struct instead.

This driver is mainly copied from mb862xx (sharing the header as offsets 
are the same) and that was the approach used there. I will add the 
structures and use them.

 +/*
 + * Set a RGB color in the LUT
 + */
 +void video_set_lut(unsigned int index, unsigned char r,
 +unsigned char g, unsigned char b)
 +{
 +
 +}

 Code seems to be missing?

The driver doesn't support palletized color format at the moment but 
removing this function leads to a linker error.

Maybe we should add a config option to disable palletized color format 
or add a weak function somewhere. Maybe Anatolij can comment on this 
issue also.

Regards,
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] arm: Add support for jadecpu board based on MB86R01 SoC

[Matthias Weißer]

Am 22.04.2010 14:51, schrieb Wolfgang Denk:
 +if ((in_word  0xC0) == 0xC0) {
 +setenv(stdin, serial);
 +setenv(stdout, serial);
 +setenv(stderr, serial);
 +setenv(bootdelay, 10);
 +} else if ((in_word  0xC0) != 0) {
 +setenv(stdout, vga);
 +setenv(bootcmd, mw.l 0x4000 0 1024; usb start;
 +fatls usb 0; fatload usb 0 0x4000 mcq5resq.bin;
 +bootelf 0x4000; bootelf 0x1008);
 +setenv(bootdelay, 5);

 I consider such mandatory settings of behaviour-critical variables as
 bootcmd and bootdelay bad style.  I recommend to use oither
 variables instead, and to use these as defaults, so the user still has
 a choice to define his own bootcmd which does not get overwritten at
 each boot.

OK. I think this will be the approach you mentioned:

setenv bootcmd '${gs_bootcmd}'
setenv gs_bootcmd bootelf 0x...

Is the redirection of the console OK as it is done in the above code?

Regards,
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [STATUS] Patch status update

[Matthias Weißer]

59  07/08 Matthias Weisser   [U-Boot] [PATCH RESEND 1/3] arm: Added 
 support for MB86R01 'Jade' SoC
  http://article.gmane.org/gmane.comp.boot-loaders.u-boot/63112

Can be dropped. I will come up with a new version of this patch set.

  6384  01/12 Matthias Weisser   [U-Boot] [PATCH] video: Fix console display 
 when splashscreen is used
  http://article.gmane.org/gmane.comp.boot-loaders.u-boot/73529

I don't received feedback on this an would like to see it mainlined.



___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Antw: Re: [PATCH] Add support for jadecpu board

[Matthias Weißer]

Hello Wolfgang

Am 18.01.2010 08:57, schrieb Wolfgang Denk:
  My board doesn't match any of the above categories so I thought
  introducing a new category for generic ARM926EJS devices would be
  a good idea.
 
  Why do you think your board does not fit into the Atmel ARM926EJ-S
  Systems group?

Because the MB86R01 'Jade' is not manufactured by Atmel. And therefore I 
thought that Atmel ARM926EJ-S Systems does not match.

Regards,
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Removing Atmel from ARM926EJ-S Systems

[Matthias Weißer]

Am 18.01.2010 11:08, schrieb Albin Tonnerre:
 On Mon, 18 Jan 2010 10:58 +0100, Matthias Weisser wrote :
 Signed-off-by: Matthias Weisserweiss...@arcor.de
 ---
   Makefile |2 +-
   1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/Makefile b/Makefile
 index ed6156f..ffe07ef 100644
 --- a/Makefile
 +++ b/Makefile
 @@ -2698,7 +2698,7 @@ mp2usb_config  :   unconfig
  @$(MKCONFIG) $(@:_config=) arm arm920t mp2usb NULL at91rm9200

   #
 -## Atmel ARM926EJ-S Systems
 +## ARM926EJ-S Systems
   #

   afeb9260_config:   unconfig

 I'm not sure I get the rationale for this change - all the boards listed 
 there are
 actually built around ARM926-based Atmel SoCs.

Please see http://lists.denx.de/pipermail/u-boot/2010-January/066596.html

I will come up with a patch set adding support for a non Atmel based SoC 
and Wolfgang suggested to remove the Atmel from the section.

Regards,
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Add support for jadecpu board

[Matthias Weißer]

Am 18.01.2010 09:52, schrieb Wolfgang Denk:
 As I don't use Linux on this board I don't have such an id. How to deal
 with such a situation? Should I get a machine id anyway? And if so can
 you give me a hint on how I can get such an id?

 Yes, you are required to register a machine ID. See
 http://www.arm.linux.org.uk/developer/machines/?action=new

I have registered a machine id now. Should I include the id into my 
reworked patch set or will that be synced with the linux kernel by one 
of the u-boot maintainers? I think the latter option has to be done but 
then my patch will not build until the sync takes place.

Regards,
Matthias

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Adding new vendor logo

[Matthias Weißer]

Am 16.01.2010 17:43, schrieb Tom:
 Matthias Weisser wrote:
 Signed-off-by: Matthias Weissermatthias.weis...@graf-syteco.de
 ---
   tools/Makefile |3 +++
   tools/logos/syteco.bmp |  Bin 0 -  12278 bytes
   2 files changed, 3 insertions(+), 0 deletions(-)
   create mode 100644 tools/logos/syteco.bmp

 diff --git a/tools/Makefile b/tools/Makefile
 index 5b8c3c3..702bb83 100644
 --- a/tools/Makefile
 +++ b/tools/Makefile
 @@ -105,6 +105,9 @@ endif
   ifeq ($(VENDOR),ronetix)
   LOGO_BMP= logos/ronetix.bmp
   endif
 +ifeq ($(VENDOR),syteco)
 +LOGO_BMP= logos/syteco.bmp
 +endif

 The grey S in the middle looks a bit lighter that
 what is on the website
 http://www.graf-syteco.de/html/deutsch/bediengerate.html

Thats OK. We use that bitmap since ever as logo in our devices and I 
think I am going to use it in u-boot also.

Regards,
Matthias

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Add support for MB86R01 from Fujitsu

[Matthias Weißer]

Am 16.01.2010 16:39, schrieb Tom:
 Matthias Weisser wrote:
 @@ -41,7 +41,8 @@ struct serial_device *__default_serial_console (void)
   #elif defined(CONFIG_405GP) || defined(CONFIG_405CR) || 
 defined(CONFIG_440) \
  || defined(CONFIG_405EP) || defined(CONFIG_405EZ) || 
 defined(CONFIG_405EX) \
  || defined(CONFIG_MPC5xxx) || defined(CONFIG_MPC83xx) \
 -   || defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx)
 +   || defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx) \
 +   || defined(CONFIG_JADE)
   #if defined(CONFIG_CONS_INDEX)  defined(CONFIG_SYS_NS16550_SERIAL)
   #if (CONFIG_CONS_INDEX==1)
  returneserial1_device;

 Including serial here is premature.
 I do not see where you set up there serial devices.
 Please save this for a later serial-only patch.

Well, the SoC has UARTs which are fully compatible with the ns16550 
driver (drivers/serial/serial.c) and therefore I simply set it up like 
this. What would be the right way to do it? I don't see a reason to add 
a serial_mb860x.c driver which is virtually identical to the current 
stuff in serial.c

 Otherwise this patch looks fine.

Thanks for checking.

Regards,
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Add support for Jade display controller

[Matthias Weißer]

Am 16.01.2010 17:30, schrieb Tom:
 Instead of adding CONFIG_VIDEO_JADEGDC, define VIDEO_FB_16BPP_WORD_SWAP
 in your board config file or a more appropriate file.

Done.

 +/*
 + * Graphic Device
 + */
 +GraphicDevice jadegdc;

 It does not look like this global is accessed output of this function
 It should be declared static.

Done.

 +
 +void *video_hw_init(void)
 +{
 +GraphicDevice *pGD =jadegdc;
 +struct ctfb_res_modes var_mode[2];
 +unsigned long *vid;
 +unsigned long div;
 +unsigned long dspBase[2];
 +char *penv;
 +int bpp;
 +int i, j;
 +
 +memset(pGD, 0, sizeof(GraphicDevice));
 +
 +dspBase[0] = JADE_GDC_DISP0_PHYS_BASE;
 +dspBase[1] = JADE_GDC_DISP1_PHYS_BASE;
 +
 +pGD-gdfIndex = GDF_15BIT_555RGB;
 +pGD-gdfBytesPP = 2;
 +
 +pGD-memSize = VIDEO_MEM_SIZE;
 +pGD-frameAdrs = PHYS_SDRAM + PHYS_SDRAM_SIZE - VIDEO_MEM_SIZE;
 +vid = (unsigned long *)pGD-frameAdrs;
 +
 +for (i = 0; i  2; i++) {
 +char varName[32];
 +u32 dcm1, dcm2, dcm3;
 +u16 htp, hdp, hdb, hsp, vtr, vsp, vdp;
 +u8 hsw, vsw;
 +u32 l2m, l2em, l2oa0, l2da0, l2oa1, l2da1;
 +u16 l2dx, l2dy, l2wx, l2wy, l2ww, l2wh;
 +
 +sprintf(varName, gs_dsp_%d_param, i);
 +
 +penv = getenv(varName);
 +if (penv == NULL) {
 +penv = getenv(videomode);
 +if ((i == 1) || (penv == NULL))
 +continue;

 This check for (i == 1) should be moved before the getenv

Done.


 +/*
 + * Set a RGB color in the LUT
 + */
 +void video_set_lut(unsigned int index, unsigned char r,
 +unsigned char g, unsigned char b)
 +{

 If leaving this a noop is intentional, add a comment.

Done.

Thanks for checking.

Regards,
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Add support for jadecpu board

[Matthias Weißer]

Hi Tom

thanks for your feedback.

Am 16.01.2010 20:18, schrieb Tom:
 +/*
 + * Miscellaneous platform dependent initialisations
 + */
 +int board_init(void)
 +{

 board_init should fill out entries in
 structglobal_data.
 See other board like lopgicpd/zoom1 as an example.
 Make sure to include the machine id.

As I don't use Linux on this board I don't have such an id. How to deal 
with such a situation? Should I get a machine id anyway? And if so can 
you give me a hint on how I can get such an id?

 +/*
 + * (4) IRESET/IUSRRST release
 +/*

 This looks like a programming error
 /* -  */  ?

You are right. Thanks for catching this.

 +#define CONFIG_JADE

 The board and cpu defines go first
 move the device configs to later

Can you please explain what you mean with this comment?

 +#define CONFIG_JADE_IOCLK   (41164767)

 This is a strange number. please add a comment.

Well, it is the clock frequency of the IO blocks of the SoC. Its 
14,31818 MHz * 46 / 16. I added a comment.

I have fixed the other stuff you pointed out.

Regards,
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] CAN console

[Matthias Weißer]

Hi

I have a device here which has only a CAN interface to the
outside world. I am currently thinking about implementing
a serial driver using the CAN controller.

Is there any chance to get this accepted in the public u-boot
tree?

A special program on the PC side would be needed to translate
the CAN messages back to a serial stream and vice versa and
make it available to a terminal program. But thats another story.

Regards,
Matthias Weißer

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] CAN console

[Matthias Weißer]

Mike Frysinger schrieb:
 On Monday 26 October 2009 04:20:02 Matthias Weißer wrote:
 I have a device here which has only a CAN interface to the
 outside world. I am currently thinking about implementing
 a serial driver using the CAN controller.

 Is there any chance to get this accepted in the public u-boot
 tree?
 
 someone just posted a port of the Linux CAN framework.  if your driver used 
 that to implement a serial layer, i dont see why it wouldnt be accepted.
 -mike

Well, that means that I have to implement a full functional CAN driver
and then additionally add a serial driver using the (completely new) CAN
framework. My idea was that I just add a serial_ccan.c to drivers/serial.

Matthias Weißer
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] CAN console

[Matthias Weißer]

Mike Frysinger schrieb:
 you would rather write a driver that is specific to one CAN hardware ?  

In general? No, I wouldn't. I would use a given CAN driver framework 
where I put my CAN driver in.

In this specific case: I think I would, as there is currently no CAN 
framework available in u-boot.

Is there any chance that the stuff posted by miaofng will be available 
in u-boot-next?

 writing it to a common framework would allow every one with a CAN driver to 
 use it ...

Yes. I totally agree here. And if there is a chance that there will be a 
CAN framework in u-boot in not to far future I will write my stuff 
against that.

I think I am not deep enough in u-boot that I will be able to write such 
a framework by myself.

Ragards,
Matthias Weißer

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Relocating u-boot console

[Matthias Weißer]

Hello

Is it possible to relocate the u-boot console depending on the state of 
some GPIO pins (e.g. in board_init or board_late_init)? Currently I have 
the following serial configuration for my board:

#define CONFIG_SERIAL_MULTI
#define CONFIG_SYS_NS16550
#define CONFIG_SYS_NS16550_SERIAL
#define CONFIG_SYS_NS16550_REG_SIZE (-4)
#define CONFIG_SYS_NS16550_CLK  CONFIG_JADE_IOCLK
#define CONFIG_SYS_NS16550_COM1 0xfffe1000
#define CONFIG_SYS_NS16550_COM2 0xfff5
#define CONFIG_SYS_NS16550_COM3 0xfff51000
#define CONFIG_SYS_NS16550_COM4 0xfff43000
#define CONFIG_CONS_INDEX   4

This results in a console on COM4. Now I would like to have the console
on COM1 under some circumstances for maintanance reasons.

Regards,
Matthias Weißer
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Relocating u-boot console

[Matthias Weißer]

Mike Frysinger schrieb:
 On Wednesday 14 October 2009 09:47:27 Matthias Weißer wrote:
 This results in a console on COM4. Now I would like to have the console
 on COM1 under some circumstances for maintanance reasons.
 
 if your devices fit into the stdio framework, simply change the 
 std{err,in,out} env vars in your board code

Ah. OK. That guided me into the right direction. To redirect the console 
to another serial port I had to set std{err,in,out} to eserialn.

Thanks,
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot