The makefiles are regenerated each run, so trying to hack it won't
get us very far. Also, the XMP files are fairly different between
7.1 and 10.1, so you'd have to manually check for functional
equivalence.
Andrew Siemion wrote:
Billy,
I think the makefiles Glenn is referring to is
system_incl.make and system.make in the XPS_iBOB_base dir.
Glenn,
I noticed some differences in your compile line directives from 10.1 and
mine from 7.1. Have you tried diff'ing your system.xmp, system.make,
system_incl.make w/ a set from a working 7.1 lwip inc'ed compile to see if
there are any glaring irregularities?
- Andrew
On 9/3/08 12:25 AM, "William Mallard" <[email protected]> wrote:
Hi Glenn,
Where's the Makefile in question? I can give it a shot.
Billy
G Jones wrote:
Hi Andrew,
Thanks for the suggestions. The include files are definitely in the
included paths. I tried copying them into the Software directory,
and that helped a little, but it still can't find the files included
in a subdirectory (thus Software/lwip). Does anyone know how to
untangle the makefile to get it to print the working directory or
something useful like that?
Thanks,
Glenn
On Tue, Sep 2, 2008 at 6:35 PM, <[email protected]> wrote:
Hi Glenn,
It looks like all the -I lines use relative paths, so maybe the
cwd when gcc is being executed is not what's expected? Also, I
would #1. Make sure the include files exist in one of the included
paths and #2. Try explicitly specifying their location in the
source files to see if it is indeed a path problem (of course this
is not a long term solution). If #2. works, you could probably
just copy the missing header files to XPS_iBOB_base/Software,
where they shouldn't be overwritten during subsequent gateware or
software compiles.
- Andrew
I found the source of the permissions problem, it turns out that
EDK is installed with read only permissions on the 'sw'
directory, and this was being propagated in the local copy. I
changed the permissions to read write for now, but am curious if
there's a better way.
However, I have run across another problem.
When I get to the gcc stage, the following command is executed:
Bitstream generation is complete.
powerpc-eabi-gcc -O2
/cygdrive/d/casper_work/ten/snaptestlwip/XPS_iBOB_base/Software/main.c
/cygdrive/d/casper_work/ten/snaptestlwip/XPS_iBOB_base/Software/tinysh.c
/cygdrive/d/casper_work/ten/snaptestlwip/XPS_iBOB_base/drivers/core_util.c
/cygdrive/d/casper_work/ten/snaptestlwip/XPS_iBOB_base/drivers/xps_xsg/clk.c
/cygdrive/d/casper_work/ten/snaptestlwip/XPS_iBOB_base/drivers/xps_xsg/devic
es.c
/cygdrive/d/casper_work/ten/snaptestlwip/XPS_iBOB_base/drivers/xps_xsg/memor
y.c
/cygdrive/d/casper_work/ten/snaptestlwip/XPS_iBOB_base/drivers/xps_adc/adc.c
/cygdrive/d/casper_work/ten/snaptestlwip/XPS_iBOB_base/drivers/xps_lwip/fifo
.c
/cygdrive/d/casper_work/ten/snaptestlwip/XPS_iBOB_base/drivers/xps_lwip/lwip
init.c
/cygdrive/d/casper_work/ten/snaptestlwip/XPS_iBOB_base/drivers/xps_lwip/lwip
util.c
/cygdrive/d/casper_work/ten/snaptestlwip/XPS_iBOB_base/drivers/xps_sw_reg/re
g.c
/cygdrive/d/casper_work/ten/snaptestlwip/XPS_iBOB_base/drivers/xps_bram/bram
.c
/cygdrive/d/casper_work/ten/snaptestlwip/XPS_iBOB_base/drivers/core_info.c
-o Software/executable.elf \
-Wl,-T
-Wl,/cygdrive/d/casper_work/ten/snaptestlwip/XPS_iBOB_base/Software/LinkerSc
ript.lwip
-I./ppc405_1/include/ -ISoftware/ -Idrivers/ -Idrivers/xps_xsg/
-Idrivers/xps_adc/ -Idrivers/xps_lwip/ -Idrivers/xps_sw_reg/
-Idrivers/xps_bram/ -L./ppc405_1/lib/ \
-DLWIP_ENABLE
From this, it looks like the correct directories are included with -I to
find all of the include files. However, I end up with many many errors
like:
/cygdrive/d/casper_work/ten/snaptestlwip/XPS_iBOB_base/Software/main.c:12:25>>>
:
error: xparameters.h: No such file or directory
/cygdrive/d/casper_work/ten/snaptestlwip/XPS_iBOB_base/Software/main.c:13:25>>>
:
error: xuartlite_l.h: No such file or directory
which indicates that the include files are not being found.
Does anyone know why this might be the case, or how I might fix this? I
see
the same behavior regardless if I run through bee_xps or just xps from
the
command line.
Thanks,
Glenn
On Tue, Aug 19, 2008 at 1:48 PM, G Jones <[email protected]>
wrote:
I checked the permissions, and they seem fine, I can manually copy the
file. Perhaps it has to do with cygwin/xygwin somehow?
On Tue, Aug 19, 2008 at 1:03 PM, John Ford <[email protected]> wrote:
Running generate for OS'es, Drivers and Libraries ...
Running generate for lwIP library ...
Generating xemacliteif_g.c ...
Generating lwipopts.h file ...
ERROR:MDT - lwip () - error copying
"./src/contrib/ports/v2pro/netif/xemacliteif_polled.c" to
"./src/contrib/ports/v2pro/netif/xemacliteif.c": permission
denied
while executing
"file copy -force
"./src/contrib/ports/v2pro/netif/xemacliteif_polled.c"
"./src/contrib/ports/v2pro/netif/xemacliteif.c""
(procedure "::sw_lwip_v2_00_a::generate" line 120)
invoked from within
"::sw_lwip_v2_00_a::generate 60581752"
ERROR:MDT - Error while running "generate" for processor ppc405_1...
make: *** [ppc405_1/lib/libxil.a] Error 2
ERROR:MDT - Error while running "make -f system.make init_bram"
Sorry if this is a stupid comment.
Isn't this purely a file permissions error? Like there's no permission
for the build to overwrite an older version or write in the directory?
John
On Mon, Aug 18, 2008 at 4:48 PM, Henry Chen
<[email protected]>wrote:
Hi Glenn,
It looks like a lot of cores were deprecated in the intervening
tool
revisions.
If you want, it looks like you can manually bring in pcores from
EDK7.1
by
going
to <EDK dir>\hw\XilinxProcessorIPLib\pcores and copy it into the
local
pcores
directory.
Or if are so inclined, you can experiment with the 2.00.a version
of
the
core to
bring us up to speed =)
Thanks,
Henry
G Jones wrote:
Hello,
I'm trying to start using the 10.1 tool flow. Compiling a simple
design
with the iBOB LWIP block yields this error:
ERROR:MDT - IPNAME:opb_ethernetlite HW_VER:1.01.a - Can not find
valid
MPD
I opened XPS and indeed it seems like the only version available
is
2.00.a
Is there any way to get 10.1 to see the old version of the core?
Thanks,
Glenn
