Wolfgang Denk | 1 Jul 01:59 2005
Picon
Picon

Re: cfi_flash is now working with 64 bit port width

In message <42C469BD.4010109 <at> orkun.us> you wrote:
>
> I think in this case instead of bloating the cfi_flash.c we could allow 
> user to define preprocessor macros in this board file for flash access 
> so if those macros are defined, cfi_flash.c would use them and exclude 
> its own built-in ones.

Oh no, please don't do this!

> That way, any board with custom data bus (reversed lanes for example) or 
> address bus (messed up address line) arrangements or specialized 
> handling (need floating point) as in this case would override them 
> easily and we would not end up blocks of #if/#elif/#else/#endif etc. in 

No. The whole idea of the CFI flash driver is to have  standard  code
for  all  boards.  If  your  design  does  not fit the standard, then
provide your own non-standard driver. Don't add complexity to the CFI
driver - it has just a single advantage (being "standard"), so please
don't drop this.

> the cfi_flash.c. The board would also enable FP unit in its board file 
> or within these functions if necessary as well.

"enabling FP" has nothing to do with this. The FPU is never  disabled
or  so.  It's  just  that  the  compiler is told to never emit any FP
instructions :-)

> I can submit a patch to do this while I am working on my other long 
> pending patch this weekend. I promise I will get it done this time.

(Continue reading)

llandre | 1 Jul 08:17 2005
Picon

Re: Re: [PATCH] Spartan3 family support

Hello,

>Thanks for the file!

you're welcome.

>What the problem with the loadb command ?

IIRC loadb did not parse the header correctly.

>and what is
>the difference between the loadb and load ?

loadb gets a .bit file while load gets a .bin file.
.bin file is the pure bitstream while .bit = <header> + .bin.
The header provides information about bitstream name, creation date etc.

llandre

DAVE Electronics System House - R&D Department
web:   http://www.dave-tech.it
email: r&d2 <at> dave-tech.it

>----- Original Message -----
>From: "llandre" <r&d2 <at> dave-tech.it>
>To: "Nicolas Colombain" <nicolas.colombain <at> laposte.net>
>Cc: <u-boot-users <at> lists.sourceforge.net>
>Sent: Thursday, June 30, 2005 9:49 AM
>Subject: Re: [U-Boot-Users] Re: [PATCH] Spartan3 family support
>
(Continue reading)

Murray.Jensen | 1 Jul 09:19 2005
Picon
Picon

[PATCH] update to "tools/bddb"

This patch contains an update to the php code in "tools/bddb". I doubt
anyone is actually using this code, but its a good reference, and besides
if it isn't going to be kept up-to-date, it should be removed. Cheers!
								Murray...
CHANGELOG entry:

* Patch by Murray Jensen, July 1, 2005:
  - update for Hymod Board Database PHP code in "tools" directory

Copyright:

This patch is free software; you can redistribute it and/or modify it under
the terms of the GNU General Public License as published by the Free Software
Foundation; either version 2 of the License, or (at your option) any later
version.
--

-- 
Murray Jensen, CSIRO Manufacturing & Infra. Tech.      Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia.         Fax: +61 3 9662 7853
Internet: Murray.Jensen <at> csiro.au

To the extent permitted by law, CSIRO does not represent, warrant and/or
guarantee that the integrity of this communication has been maintained or
that the communication is free of errors, virus, interception or interference.

The information contained in this e-mail may be confidential or privileged.
Any unauthorised use or disclosure is prohibited. If you have received this
e-mail in error, please delete it immediately and notify Murray Jensen on
+61 3 9662 7763. Thank you.

(Continue reading)

eagle keeper | 1 Jul 13:44 2005
Picon

uboot on pq2fadsvr

Hi all,
and sorry for my question. I have not very clear what to do to compile
uboot for pq2fadsvr with mpc8275 processor. I mean: it is an
evaluation board supported by uboot isn't it?
And if so, why doesn't exist a configuration file?
Is it enought to lighlty modify the 8260ads configuration file? And
wich entries?

Thank in advance

Lele

-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
Jerry Van Baren | 1 Jul 14:20 2005

Re: uboot on pq2fadsvr

eagle keeper wrote:
> Hi all,
> and sorry for my question. I have not very clear what to do to compile
> uboot for pq2fadsvr with mpc8275 processor. I mean: it is an
> evaluation board supported by uboot isn't it?
> And if so, why doesn't exist a configuration file?
> Is it enought to lighlty modify the 8260ads configuration file? And
> wich entries?
> 
> Thank in advance
> 
> Lele

In the top level directory, do the following:
$ grep PQ2FADS Makefile
PQ2FADS_config          \
PQ2FADS_lowboot_config          \
PQ2FADS-VR_config       \
PQ2FADS-VR_lowboot_config       \
PQ2FADS-ZU_config       \
PQ2FADS-ZU_lowboot_config       \
PQ2FADS-ZU_66MHz_config \
PQ2FADS-ZU_66MHz_lowboot_config \

I would expect PQ2FADS-VR_config or PQ2FADS-VR_lowboot_config would work 
(if you don't have the "lowboot" version, you may want to update your 
u-boot copy from the head of CVS).

The lowboot is configured to boot with the Boot Memory Space HWCW[BMS] 
set to 1 (i.e. booting at 0x00000000) and is the recommended 
(Continue reading)

Andreas Block | 1 Jul 10:01 2005

Re: RE: RE: Does u-boot relocate absolute symbols?

Rune: I'm sorry for the inconvenience, but I sent this mail to you instead  
of the U-Boot mailinglist.

And WD already slapped me for sending this example...

30.06.2005 18:54:40, "Rune Torgersen" <runet <at> innovsys.com> wrote:

> Wow.... This surprises me...
> I have alwayts thought that *test and test[] would be the same thing.
>
> Only solutionI can see is to change the definition in common.c to be
> *test, this will still get the address of test[] defined elsewhere.
> (See attached files)

Thanks, for your effort. Actually your suggestion is the way it's  
currently working
here, but as I described in my first post, I'm looking for a way, which  
leaves the
common code untouched. In my first post on 24.06.05 I've another solution,  
which is
working for Linux, but does not in U-Boot.

Regards,
Andreas

>> Sure, I've tried this. This is the point, where my problemarose.  
>> Attached you find twosmall files, you can easily compile under linux  
>> (gcc -oarrtest -I ./ ./common.c./array.c). The file "common.c"  
>> represents the code I can't(don't want to) touch."array.c" represents  
>> my project dependent code. If you runarrtest it will show to you,
(Continue reading)

Andreas Block | 1 Jul 09:57 2005

Re: Does u-boot relocate absolute symbols?

Jerry: I'm sorry for the inconvenience, but sent this mail to you instead  
of the U-Boot mailinglist.

I'm not quite sure, what happened on your side.
Here's the result on my side (together with the source as it ought look):

--- BEGIN OF CONSOLE OUTPUT
andreas <at> pc-linux-dev:~/arrtest> cat common.h
int showwrong(void);

andreas <at> pc-linux-dev:~/arrtest> cat common.c
#include <stdio.h>

extern const unsigned char test[];

int showwrong(void)
{
         printf("test[]: 0x%08X\n", (int)test);
         return 0;
}

andreas <at> pc-linux-dev:~/arrtest> cat array.c
#include "common.h"

const unsigned char *test = (unsigned char*)0x40000;

int main(void)
{
         printf("*test: 0x%08X\n", (int)test);
         showwrong();
(Continue reading)

Jerry Van Baren | 1 Jul 16:35 2005

Re: Does u-boot relocate absolute symbols?

I ran the code you (Andreas) sent, with the one correction for the 
printf().  The code you sent did not set the test array pointer to 
0x40000.  When I use the code you _ment_ rather than what you _sent_ 
(see below - sorry for top-quoting), I get the same effect you get:

vanbaren <at> sherwood:~/x> ./arrtest
*test: 0x08048558
test[]: 0x08048558

vanbaren <at> sherwood:~/x> ./arrtest-ptr
*test: 0x00040000
test[]: 0x08048558

I think I now understand the root of your problem.  You want to place an 
initialized array at a specific location.  C has a way of initializing 
arrays:
   const unsigned char test[] = { value... };
and a way of making a pointer to an array:
   const unsigned char *test = (unsigned char*)0x40000;
but it doesn't have a way to do _both_ at the same time.  You are trying 
to avoid the need for two initializations in one declaration limitation 
by doing it _differently_ in _two_ different places.  This is confusing 
the compiler and/or the linker.

I would guess this is a compiler/linker interaction that could be 
labeled unfortunate lack of communications or a bug, depending on your 
frustration level for the day.

I would contend that the "proper" solution is to declare the array 
consistantly and with data initialization in common.h:
(Continue reading)

Andreas Block | 1 Jul 17:06 2005

Re: Does u-boot relocate absolute symbols?

Hi Jerry,

thanks for your time.

On Fri, 01 Jul 2005 16:35:49 +0200, Jerry Van Baren  
<gerald.vanbaren <at> smiths-aerospace.com> wrote:

> I ran the code you (Andreas) sent, with the one correction for the
> printf().  The code you sent did not set the test array pointer to
> 0x40000.

I did look at the code, I had sent originally (with the typo you proposed)  
and in line 3 of array.c *test is initialized to 0x40000. I was writing  
big time nonsens that morning, but I wasn't that bad.

>  When I use the code you _ment_ rather than what you _sent_
> (see below - sorry for top-quoting), I get the same effect you get:
>
> vanbaren <at> sherwood:~/x> ./arrtest
> *test: 0x08048558
> test[]: 0x08048558
>
> vanbaren <at> sherwood:~/x> ./arrtest-ptr
> *test: 0x00040000
> test[]: 0x08048558
>
> I think I now understand the root of your problem.  You want to place an
> initialized array at a specific location.  C has a way of initializing
> arrays:
>    const unsigned char test[] = { value... };
(Continue reading)

Yusuf Ibrahim Ozkok | 1 Jul 18:09 2005
Picon

Re: cfi_flash is now working with 64 bit port width

Tolunay Orkun wrote:
>This is probably not acceptable for cfi_flash.c. cfi_flash.c is used by
> multiple CPU architectures so PowerPC assembly cannot be used. You have
> to find a solution based on "C" only.
I think the best is to keep cfi_flash.c as is, and to copy it into 
/board/flash.c and made the changes for custom needs in that file, for the 
sake of  keeping simplicity of generic drivers. But some descriptive 
warnings and comments may be added at the beggining of cfi_flash for 
possible non standart designs.

Tolunay Orkun wrote:
> How did you use "double" and it did not work? Please give example of the
> work you tried...
    First I had simply tried to cast data to double just before had been 
writing to the bus.

   in cfi_flash.c on line850 (in flash_write_cmd())
        -        *addr.llp = cword.ll;
        +        *addr.llp = (double) cword.ll;

But it caused a very strange think.  While compiling it passed all the make 
steps (compiled, linked ...) but at the lines to generate srec and bin 
formatted files

(ppc_82xx-objcopy --gap-fill=0xff -O srec u-boot u-boot.srec,
ppc_82xx-objcopy --gap-fill=0xff -O binary u-boot u-boot.bin)

the host machine(the redhat WS 3.0 machine where I made the compilation) is 
locked. than I exclude these lines from the makefile planning to do the work 
from command prompth.
(Continue reading)


Gmane