FPGA Central

simple JTAG Chain: Atmel-SAM7 ARM --> XC3S1500 --> XC9572XL

attempt to configure FPGA with Impact, done not high configuration status
register = 0000
attempt to program PLD seems to stall forever clicking abort and waiting
makes impact again responsive with failure to program

changing the BSDL file makes the chain order to get messed, attempt to re
order the device by mouse drag and drop causes impact to self terminate.

are there any issues with non Xilinx device in JTAG chain with impact 8.1?

any help really welcome, I do not have time to open a webcase as I must have
the board up and running til early next week.

(the new bugs are entered in bugtrackter http://bugs.xilant.com )

--
Antti Lukats

"Antti Lukats" <[email protected]> wrote in message
news:[email protected]...
> simple JTAG Chain: Atmel-SAM7 ARM --> XC3S1500 --> XC9572XL
>
> attempt to configure FPGA with Impact, done not high configuration status
> register = 0000
> attempt to program PLD seems to stall forever clicking abort and waiting
> makes impact again responsive with failure to program
>
> changing the BSDL file makes the chain order to get messed, attempt to re
> order the device by mouse drag and drop causes impact to self terminate.
>
> are there any issues with non Xilinx device in JTAG chain with impact 8.1?
>
> any help really welcome, I do not have time to open a webcase as I must
> have the board up and running til early next week.
>
> (the new bugs are entered in bugtrackter http://bugs.xilant.com )
>
> --
> Antti Lukats


I don't know why I had problems but we worked around them. The Spartan-3 on
my board was the first in the JTAG chain followed by 4 other non-Xilinx
devices. On the new rev of board we connected the FPGA so it could be
isolated from the other devices for Chipscope-like debug (Synplify's
Identify product) by swapping a couple resistors. Without the isolation
from the chain, when I tried to get the debugger to communicate the board
would reset. There may have been troubles with 1) another chip resetting
the system when toggled through the jtag sequence with or without TRST
applied properly to that device or 2) unexpected voltages on the soft reset
signal sourced by the FPGA causing a system reset. Bottom line: I couldn't
get the JTAG port up & running for debug on the first generation of board.
Thankfully the Identify tool allows a "custom" port that's a JTAG emulator
that I ported out to 4 test points.

"John_H" <[email protected]> schrieb im Newsbeitrag
news:[email protected]...
> "Antti Lukats" <[email protected]> wrote in message
> news:[email protected]...
>> simple JTAG Chain: Atmel-SAM7 ARM --> XC3S1500 --> XC9572XL
>>
>> attempt to configure FPGA with Impact, done not high configuration status
>> register = 0000
>> attempt to program PLD seems to stall forever clicking abort and waiting
>> makes impact again responsive with failure to program
>>
>> changing the BSDL file makes the chain order to get messed, attempt to re
>> order the device by mouse drag and drop causes impact to self terminate.
>>
>> are there any issues with non Xilinx device in JTAG chain with impact
>> 8.1?
>>
>> any help really welcome, I do not have time to open a webcase as I must
>> have the board up and running til early next week.
>>
>> (the new bugs are entered in bugtrackter http://bugs.xilant.com )
>>
>> --
>> Antti Lukats
>
>
> I don't know why I had problems but we worked around them. The Spartan-3
> on my board was the first in the JTAG chain followed by 4 other non-Xilinx
> devices. On the new rev of board we connected the FPGA so it could be
> isolated from the other devices for Chipscope-like debug (Synplify's
> Identify product) by swapping a couple resistors. Without the isolation
> from the chain, when I tried to get the debugger to communicate the board
> would reset. There may have been troubles with 1) another chip resetting
> the system when toggled through the jtag sequence with or without TRST
> applied properly to that device or 2) unexpected voltages on the soft
> reset signal sourced by the FPGA causing a system reset. Bottom line: I
> couldn't get the JTAG port up & running for debug on the first generation
> of board. Thankfully the Identify tool allows a "custom" port that's a
> JTAG emulator that I ported out to 4 test points.
>
thanks John,

well I have a workaround also, the chip that makes impact to freeze is
Atmel ARM7SAM, with 2 different JTAG inside (selectable by ext pin at
powerup)
one of them has 4 bit IR lenght (ARM Embedded ICE) the other (boundary scan)
3 bit IR
length. So if the ARMice is chain all is OK. if the ARM boundary scan then
impact freezes.

So my guess is that Impact can not handle JTAG devices with IR register
lenght less than 4
but I may be wrong of course.

Anyway the workaround for us was to remove the pullup on JTAGSEL of the ARM
SAM
and those make the ARM IR register 4 bit long, then impact can work without
problems


--
Antti Lukats
http://www.xilant.com

"Antti Lukats" <[email protected]> wrote in message
news:[email protected]...
<snip>
> thanks John,
>
> well I have a workaround also, the chip that makes impact to freeze is
> Atmel ARM7SAM, with 2 different JTAG inside (selectable by ext pin at
> powerup)
> one of them has 4 bit IR lenght (ARM Embedded ICE) the other (boundary
> scan) 3 bit IR
> length. So if the ARMice is chain all is OK. if the ARM boundary scan then
> impact freezes.
>
> So my guess is that Impact can not handle JTAG devices with IR register
> lenght less than 4
> but I may be wrong of course.
>
> Anyway the workaround for us was to remove the pullup on JTAGSEL of the
> ARM SAM
> and those make the ARM IR register 4 bit long, then impact can work
> without problems
>
>
> --
> Antti Lukats
> http://www.xilant.com

It almost sounds like the BDSL file expected the ARM IR jtag chain rather
than the boundary scan chain. That *is* where the length is specified,
isn't it?

I'm glad you've got a workaround.

"John_H" <[email protected]> schrieb im Newsbeitrag
news:%[email protected]...
> "Antti Lukats" <[email protected]> wrote in message
> news:[email protected]...
> <snip>
>> thanks John,
>>
>> well I have a workaround also, the chip that makes impact to freeze is
>> Atmel ARM7SAM, with 2 different JTAG inside (selectable by ext pin at
>> powerup)
>> one of them has 4 bit IR lenght (ARM Embedded ICE) the other (boundary
>> scan) 3 bit IR
>> length. So if the ARMice is chain all is OK. if the ARM boundary scan
>> then impact freezes.
>>
>> So my guess is that Impact can not handle JTAG devices with IR register
>> lenght less than 4
>> but I may be wrong of course.
>>
>> Anyway the workaround for us was to remove the pullup on JTAGSEL of the
>> ARM SAM
>> and those make the ARM IR register 4 bit long, then impact can work
>> without problems
>>
>>
>> --
>> Antti Lukats
>> http://www.xilant.com
>
> It almost sounds like the BDSL file expected the ARM IR jtag chain rather
> than the boundary scan chain. That *is* where the length is specified,
> isn't it?
>
> I'm glad you've got a workaround.
>
I am using proper BSDL files in both cases to support the proper IR lenght
impact still freezes, but with the workaround its no longer a showstopper.

the thing is an small FPGA board that is going to displayed at embedded
in Nurnberg so I am a little bit under pressure as the PCBs did delay.

but a few minutes the board did boot uClinux from SD card OK

I just love how easy it is to port uClinux to new platform, just
change the UCF file and there you go


--
Antti Lukats
http://www.xilant.com

I am unfamiliar with the Atmel part in question but am quite certain
that iMPACT is OK with instruction register lengths down to 2 bits
(which is the minimum allowed by the standard). My cursory examination
of the Atmel data sheets indicates that the part has 2 pins that control
the test modes - a TST (which seems to enable some manufacturing
modes so it must always be low) and the JTAGSEL (which seems to be
temperamental in that a reset is required between toggles). I'm
wondering if the FPGA pins are connected to either of these pins and
perhaps interfering with the boundary-scan chain during configuration?
I'm suspicious of some interaction of that sort, if not between the FPGA
and those pins, perhaps some other ones - or perhaps an interaction
between the processor pins and PROG or the FPGA mode pins during
configuration.

Idle thoughts...

Glad you have a work-around.

Antti Lukats wrote:
> "John_H" <[email protected]> schrieb im Newsbeitrag
> news:[email protected]...
>> "Antti Lukats" <[email protected]> wrote in message
>> news:[email protected]...
>>> simple JTAG Chain: Atmel-SAM7 ARM --> XC3S1500 --> XC9572XL
>>>
>>> attempt to configure FPGA with Impact, done not high configuration status
>>> register = 0000
>>> attempt to program PLD seems to stall forever clicking abort and waiting
>>> makes impact again responsive with failure to program
>>>
>>> changing the BSDL file makes the chain order to get messed, attempt to re
>>> order the device by mouse drag and drop causes impact to self terminate.
>>>
>>> are there any issues with non Xilinx device in JTAG chain with impact
>>> 8.1?
>>>
>>> any help really welcome, I do not have time to open a webcase as I must
>>> have the board up and running til early next week.
>>>
>>> (the new bugs are entered in bugtrackter http://bugs.xilant.com )
>>>
>>> --
>>> Antti Lukats
>>
>> I don't know why I had problems but we worked around them. The Spartan-3
>> on my board was the first in the JTAG chain followed by 4 other non-Xilinx
>> devices. On the new rev of board we connected the FPGA so it could be
>> isolated from the other devices for Chipscope-like debug (Synplify's
>> Identify product) by swapping a couple resistors. Without the isolation
>> from the chain, when I tried to get the debugger to communicate the board
>> would reset. There may have been troubles with 1) another chip resetting
>> the system when toggled through the jtag sequence with or without TRST
>> applied properly to that device or 2) unexpected voltages on the soft
>> reset signal sourced by the FPGA causing a system reset. Bottom line: I
>> couldn't get the JTAG port up & running for debug on the first generation
>> of board. Thankfully the Identify tool allows a "custom" port that's a
>> JTAG emulator that I ported out to 4 test points.
>>
> thanks John,
>
> well I have a workaround also, the chip that makes impact to freeze is
> Atmel ARM7SAM, with 2 different JTAG inside (selectable by ext pin at
> powerup)
> one of them has 4 bit IR lenght (ARM Embedded ICE) the other (boundary scan)
> 3 bit IR
> length. So if the ARMice is chain all is OK. if the ARM boundary scan then
> impact freezes.
>
> So my guess is that Impact can not handle JTAG devices with IR register
> lenght less than 4
> but I may be wrong of course.
>
> Anyway the workaround for us was to remove the pullup on JTAGSEL of the ARM
> SAM
> and those make the ARM IR register 4 bit long, then impact can work without
> problems
>
>

"Neil Glenn Jacobson" <[email protected]> schrieb im
Newsbeitrag news:[email protected]...
>I am unfamiliar with the Atmel part in question but am quite certain that
>iMPACT is OK with instruction register lengths down to 2 bits (which is the
>minimum allowed by the standard). My cursory examination of the Atmel data
>sheets indicates that the part has 2 pins that control the test modes - a
>TST (which seems to enable some manufacturing modes so it must always be
>low) and the JTAGSEL (which seems to be temperamental in that a reset is
>required between toggles). I'm wondering if the FPGA pins are connected to
>either of these pins and perhaps interfering with the boundary-scan chain
>during configuration? I'm suspicious of some interaction of that sort, if
>not between the FPGA and those pins, perhaps some other ones - or perhaps
>an interaction between the processor pins and PROG or the FPGA mode pins
>during configuration.
>
> Idle thoughts...
>
> Glad you have a work-around.
>
yes I have a workaround that is ok so far, but for production test I need
correct solution too.

JTAGSEL is connected to PLD, everything was fine until I changed the JTAGSEL
value by reprogramming the PLD, afer that impact just frozed while trying to
reporgram the PLD.

so no matter the the reason for the fail, there is some sort of bug with
impact as any kind of
wrong behaviour of the JTAG chain during programming should not cause impact
to freeze.

my guess about the 3 IR bits not supported was based on fact that as soon
as reverted
the ARM into ICE mode with longer IR register everything started to work
again. the
ARM has been unprogrammed all the time, only change to revert the chain
useable
was disconnecting JTAGSEL - as JTAGSEL is only latched on power up the
connection
to PLD can not change the scan chain config once powered.

well FPGA PROG_B is also connected to the PLD, but it should not matter as
the
signal that made the difference was JTAGSEL on ARM, no matter the FPGA
connections it should not prevent the PLD from being programmed - as long
as ARM IR chain doesnt chain its length during runtime. I will investigate
it
a little more when the board is otherwise fully tested.

Antti

Antti Lukats wrote:
> "Neil Glenn Jacobson" <[email protected]> schrieb im
> Newsbeitrag news:[email protected]...
>> I am unfamiliar with the Atmel part in question but am quite certain that
>> iMPACT is OK with instruction register lengths down to 2 bits (which is the
>> minimum allowed by the standard). My cursory examination of the Atmel data
>> sheets indicates that the part has 2 pins that control the test modes - a
>> TST (which seems to enable some manufacturing modes so it must always be
>> low) and the JTAGSEL (which seems to be temperamental in that a reset is
>> required between toggles). I'm wondering if the FPGA pins are connected to
>> either of these pins and perhaps interfering with the boundary-scan chain
>> during configuration? I'm suspicious of some interaction of that sort, if
>> not between the FPGA and those pins, perhaps some other ones - or perhaps
>> an interaction between the processor pins and PROG or the FPGA mode pins
>> during configuration.
>>
>> Idle thoughts...
>>
>> Glad you have a work-around.
>>
> yes I have a workaround that is ok so far, but for production test I need
> correct solution too.
>
> JTAGSEL is connected to PLD, everything was fine until I changed the JTAGSEL
> value by reprogramming the PLD, afer that impact just frozed while trying to
> reporgram the PLD.
>
> so no matter the the reason for the fail, there is some sort of bug with
> impact as any kind of
> wrong behaviour of the JTAG chain during programming should not cause impact
> to freeze.
>
> my guess about the 3 IR bits not supported was based on fact that as soon
> as reverted
> the ARM into ICE mode with longer IR register everything started to work
> again. the
> ARM has been unprogrammed all the time, only change to revert the chain
> useable
> was disconnecting JTAGSEL - as JTAGSEL is only latched on power up the
> connection
> to PLD can not change the scan chain config once powered.
>
> well FPGA PROG_B is also connected to the PLD, but it should not matter as
> the
> signal that made the difference was JTAGSEL on ARM, no matter the FPGA
> connections it should not prevent the PLD from being programmed - as long
> as ARM IR chain doesnt chain its length during runtime. I will investigate
> it
> a little more when the board is otherwise fully tested.
>
> Antti
>

Hmm. Which PLD is involved here? I'm suspicious that iMPACT is not
actually frozen but just taking a really long time to fail. If it is a
9500/XL/XV then these devices use polling to indicate when programming
(or erasure) is complete. The device responds with a status to iMPACT
to indicate success or failure. Some failure statuses mean keep trying
- just wait longer. The wait time increase can quickly increase to
minutes in certain failure situations. I am speculating that the PLD
mucks with JTAGSEL doing something horrible to the boundary-scan chain,
making the output look like the status that says "keep trying - just
wait longer" and then you end up with this apparent "freeze". Bad
behavior. Should fail more elegantly if that's what happening. That's
my theory, anyway.

>
>
>
>
>
>
>
>

Antti Lukats wrote:
> my guess about the 3 IR bits not supported was based on fact that as soon
> as reverted
> the ARM into ICE mode with longer IR register everything started to work
> again.

... perhaps the Atmel device itself has Bypass problems in the other mode ?

-jg

The PLD pins float during programming. Depending on the CPLD, it is
typically pulled high, weakly, while the device is being programmed.
You might want to install a strong pull-up on the JTAGSEL to hold it
high during configuration and see if that helps things. If JTAGSEL
floats low, you will be hosed - it appears.

Again, not knowing which Atmel device you are using you may also find
this instructive:

http://www.atmel.com/dyn/products/fa...asp?faq_id=780


Neil Glenn Jacobson wrote:
> Antti Lukats wrote:
>> "Neil Glenn Jacobson" <[email protected]>
>> schrieb im Newsbeitrag news:[email protected]...
>>> I am unfamiliar with the Atmel part in question but am quite certain
>>> that iMPACT is OK with instruction register lengths down to 2 bits
>>> (which is the minimum allowed by the standard). My cursory
>>> examination of the Atmel data sheets indicates that the part has 2
>>> pins that control the test modes - a TST (which seems to enable some
>>> manufacturing modes so it must always be low) and the JTAGSEL (which
>>> seems to be temperamental in that a reset is required between
>>> toggles). I'm wondering if the FPGA pins are connected to either of
>>> these pins and perhaps interfering with the boundary-scan chain
>>> during configuration? I'm suspicious of some interaction of that
>>> sort, if not between the FPGA and those pins, perhaps some other ones
>>> - or perhaps an interaction between the processor pins and PROG or
>>> the FPGA mode pins during configuration.
>>>
>>> Idle thoughts...
>>>
>>> Glad you have a work-around.
>>>
>> yes I have a workaround that is ok so far, but for production test I need
>> correct solution too.
>>
>> JTAGSEL is connected to PLD, everything was fine until I changed the
>> JTAGSEL
>> value by reprogramming the PLD, afer that impact just frozed while
>> trying to reporgram the PLD.
>>
>> so no matter the the reason for the fail, there is some sort of bug
>> with impact as any kind of
>> wrong behaviour of the JTAG chain during programming should not cause
>> impact to freeze.
>>
>> my guess about the 3 IR bits not supported was based on fact that as
>> soon as reverted
>> the ARM into ICE mode with longer IR register everything started to
>> work again. the
>> ARM has been unprogrammed all the time, only change to revert the
>> chain useable
>> was disconnecting JTAGSEL - as JTAGSEL is only latched on power up the
>> connection
>> to PLD can not change the scan chain config once powered.
>>
>> well FPGA PROG_B is also connected to the PLD, but it should not
>> matter as the
>> signal that made the difference was JTAGSEL on ARM, no matter the FPGA
>> connections it should not prevent the PLD from being programmed - as long
>> as ARM IR chain doesnt chain its length during runtime. I will
>> investigate it
>> a little more when the board is otherwise fully tested.
>>
>> Antti
>>
>
> Hmm. Which PLD is involved here? I'm suspicious that iMPACT is not
> actually frozen but just taking a really long time to fail. If it is a
> 9500/XL/XV then these devices use polling to indicate when programming
> (or erasure) is complete. The device responds with a status to iMPACT
> to indicate success or failure. Some failure statuses mean keep trying
> - just wait longer. The wait time increase can quickly increase to
> minutes in certain failure situations. I am speculating that the PLD
> mucks with JTAGSEL doing something horrible to the boundary-scan chain,
> making the output look like the status that says "keep trying - just
> wait longer" and then you end up with this apparent "freeze". Bad
> behavior. Should fail more elegantly if that's what happening. That's
> my theory, anyway.
>
>>
>>
>>
>>
>>
>>
>>
>>

"Neil Glenn Jacobson" <[email protected]> schrieb im
Newsbeitrag news:[email protected]...
> The PLD pins float during programming. Depending on the CPLD, it is
> typically pulled high, weakly, while the device is being programmed. You
> might want to install a strong pull-up on the JTAGSEL to hold it high
> during configuration and see if that helps things. If JTAGSEL floats low,
> you will be hosed - it appears.
>
> Again, not knowing which Atmel device you are using you may also find this
> instructive:
>
> http://www.atmel.com/dyn/products/fa...asp?faq_id=780
>

Hi Neil,

hmmm - the JTAGSEL is only captured at powerup later level changes (PLD pins
floating)
should not cause any change or trouble.

also I would have expected JTAG problems in the case where ARM-ICE JTAG is
in chain
but it is the other way around, when ICE is in chain all works, when ARM
boundary scan is
in chain then the chain is scanneable, but impact fails really strange.

I would be happy to leave the JTAGSEL=0 and ARM in ICE mode, but the
manufacturer
of the board wants to access boundary scan on all devices that support it,
this includes the ARM

and yes the PLD is XC9572XL, but complete freeze (or what seems as complete
freeze) could
still be prevented, ie the 'abort' button should be responsive also during
the wait periods

Antti

"Jim Granville" <[email protected]> schrieb im Newsbeitrag
news:[email protected]...
> Antti Lukats wrote:
>> my guess about the 3 IR bits not supported was based on fact that as
>> soon as reverted
>> the ARM into ICE mode with longer IR register everything started to work
>> again.
>
> .. perhaps the Atmel device itself has Bypass problems in the other mode ?
>
> -jg
>
the mode that has problems is the boundary scan mode not ICE mode
so I do not want to belive that the bypass instruction in boundary scan
mode is not implemented properly. Atmel is sure know to have weird
silicon bugs, but this time I am relatilvly sure there is no issue with
bypass instruction.

--
Antti Lukats
http://www.xilant.com

Antti Lukats wrote:

> I just love how easy it is to port uClinux to new platform, just
> change the UCF file and there you go

You know Antti, in a very strange way you can take some credit for that
fact. Your statement in a comp.arch.fpga posting 18 months ago

http://groups.google.com.au/group/co...12c984240d22e8

"NIOS uCLinux is WAY easier to get started then MicroBlaze uCLinux
thanks to the full integration of the config and integration into
Eclipse workbench, as EDK6.3 is also Eclipse based it would be possible
todo the same for MicroBlaze uClinux config and build. "

p***ed me off so much I went and created the auto-config mechanisms that
now make mb-uclinux by far the easiest (and probably most popular)
soft-CPU Linux solution around.

So, thanks - I think

John

"John Williams" <[email protected]> schrieb im Newsbeitrag
news:[email protected]...
> Antti Lukats wrote:
>
>> I just love how easy it is to port uClinux to new platform, just
>> change the UCF file and there you go
>
> You know Antti, in a very strange way you can take some credit for that
> fact. Your statement in a comp.arch.fpga posting 18 months ago
>
> http://groups.google.com.au/group/co...12c984240d22e8
>
> "NIOS uCLinux is WAY easier to get started then MicroBlaze uCLinux
> thanks to the full integration of the config and integration into
> Eclipse workbench, as EDK6.3 is also Eclipse based it would be possible
> todo the same for MicroBlaze uClinux config and build. "
>
> p***ed me off so much I went and created the auto-config mechanisms that
> now make mb-uclinux by far the easiest (and probably most popular)
> soft-CPU Linux solution around.
>
> So, thanks - I think
>
> John

Oh John,

sorry when I got you pissed off.

you know I am happen to so poor guy that I can not afford to have second
workstation only for MicroBlaze development and as you know the MicroBlaze
uClinux build until today can not be done on the Windows machine.

So what I stated 18months ago stands so far that it is (or was at least)
possible to configure and and build uClinux on single Windows PC a nice to
have thing for poor souls like me not having separate linux PC box around.

OTOH - I did only check the uClinux config from SOPC builder, it worked, but
I have never ever seen it working as I do not happend to have NIOS uClinux
ready hardware ready and hasnt cared enough to obtain such hardware so far
either.

And I have build uClinux systems way before the auto-config, and it has been
always been easy for me (after the first try).

I have spent a lot of time in desperate attempts to get coLinux environment
setup with preconfigured microblaze uClinux toolchain after some pain it
works but the way todo file transfer to windows host PC is real complicated,
so only ysterday (or today if in US timezone) I did install Bochs source
code and compiled Bocs x86 emulator on Windows for one simple reason:

to have windows based virtual linux with pre installed images containing
MicroBlaze toolchain and uClinux deve tools - so other poor guys (those with
no Linux!) can also work on single PC and still develop for uClinux
Microblaze

and again just today I got finally working a MicroBlaze uClinux FPGA tested
driver for SD Cards so I was able to mount in MicroBlaze uClinux a SD card
formatted with FAT16 and after mount I did see files on the card.

its FAST bit.banged software driver that works with SD (later I may add MMC
card support too) cards in NON-SPI mode. It can work with any software
controllabe PIO port, currently with GPIO CMD-DAT-CLK-card sense onto port,
all other is software.

a small bootloader exists that loads the full uClinux image from SD card
using the same bitbang mode, load time approc 7seconds. This could be even
better as I have not done assembly level optimization to the code yet.

I am replying in such details as I was just about to contact you to ask what
is the procedure to submit the driver to be included in the uClinux
distribution (it is GPL licensed)

John, dont judge me so hard, for those who primare work on linux its really
hard to understand how much trouble it is setting up and maintaining 2 work
stations for the linux cross compile. I just want to type

make menuconfig
make dep
make

from my primary workstation (winPC)

as long as that is not possible, well it means additioal burden - at work I
did today the following procedure 18 times

1 edit mmc.c
2 TFTP PUT mmc.c
3 stand up from my chair going to linux PC here working standing
4 copy from tftpboot to \drivers\block
5 make
6 back to my workplace, sitting down
7 TFTP GET image bin

8 copy image.bin to SD card, insert to FPGA board, reset 10 seconds linux
prompt is ready

I have a mouse-keyboard-switch, but linux doesnt work with it I really
have killed pretty much of my time because of no easy solution exist for
those whose primary system is windows - and that has to be so as FPGA tools
are generically better supported on WinXP then linux so switching to linux
completly is not an option for me.

anyway I am hoping to have the BOCHS emulator setup to provide a solution
that doesnt require the purchase of second PC for microblaze uclinux
development

cheers
Antti

What about SSH ?

Mostly when I work on the kernel, my test platforms are no just right
beside me but connected to a "server" where it download (tftp & nfs)
from and it's serial port is also connected to that machine. I can even
hard-reset the platform from that machine.

All I have to do is ssh to that machine with 2 terminals, and on one,
lauche a terminal emultator to see the RS232 console output and on the
other I can do the "common" tasks. Well, since my main pc is also Linux
I don't do the compile on the server but nothing prevents me from ...
And all that without sitting up


Sylvain

Antti Lukats <[email protected]> wrote:
....
> you know I am happen to so poor guy that I can not afford to have second
> workstation only for MicroBlaze development and as you know the MicroBlaze
> uClinux build until today can not be done on the Windows machine.

Doesn't CoLinux work?

--
Uwe Bonnes [email protected]

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

"Uwe Bonnes" <[email protected]> schrieb im Newsbeitrag
news:[email protected]...
> Antti Lukats <[email protected]> wrote:
> ...
>> you know I am happen to so poor guy that I can not afford to have second
>> workstation only for MicroBlaze development and as you know the
>> MicroBlaze
>> uClinux build until today can not be done on the Windows machine.
>
> Doesn't CoLinux work?
>
it does.

nothing wrong running mincroblaze toolchain on it, the problem was copying
the resulting file out from colinux
the virtual network adapters and bridginh things did not want to work
properly

Antti

"Sylvain Munaut <[email protected]>" <[email protected]> schrieb im
Newsbeitrag news:[email protected] oups.com...
> What about SSH ?
>
> Mostly when I work on the kernel, my test platforms are no just right
> beside me but connected to a "server" where it download (tftp & nfs)
> from and it's serial port is also connected to that machine. I can even
> hard-reset the platform from that machine.
>
> All I have to do is ssh to that machine with 2 terminals, and on one,
> lauche a terminal emultator to see the RS232 console output and on the
> other I can do the "common" tasks. Well, since my main pc is also Linux
> I don't do the compile on the server but nothing prevents me from ...
> And all that without sitting up
>
>
> Sylvain
>
I was possible yesterday lazy in non creative way, sure remote access
would also work if linux accessible computer is on accessible, what is
unfortunatly is not the case at home.
I just need to setup some scripts that launch make and shuffle files.

Antti

Hi Antti,

On the Linux vs windows workstation issue, we are almost evenly split
here in our group. I do everything (ISE, EDK, uClinux, ...) on a Linux
box, running CentOS3 (perfectly compatible with Xilinx tools). I do
have an old Windows laptop for running MS Office and web/email but
that's about it.

Others in the group are running CoLinux, some on laptops, and they run
all of the tools in that environment. CentOS 3 installs just fine in
CoLinux, so the entire Xilinx tool flow can occur in a virtual Linux PC.

One of our brainy guys hacked colinux to tunnel the parallel port, so we
run impact inside CoLinux with vanilla Xilinx drivers - it couldn't be
much easier.

The decision to not support Windows (Cygwin) for MicroBlaze uClinux
development is a difficult one, but justified I believe by experience in
the misery of Cygwin. Cygwin is just enough like Linux to make you
think "it should work", but just different enough to make life
miserable.

Some of these restrictions come from underlying Windows crud, like case
insensitive filesystems, poor handling of file permissions, that sort of
thing. Linux sees a difference between 'makefile' and 'Makefile' -
windows can't. While nobody would recommend overloading filenames in
this way, there's not a lot that can be done about it retrospectively
without (IMO) inordinate effort.

It's also dreadfully slow - compile times can be on the order of 2-3
times longer.

Anyway, perhaps we should package up our CoLinux environment a bit
better and distribute it, it might make life a bit easier for people in
your position (and those stuck in MS Windows corporate environments).

Regards,

John

Antti Lukats wrote:

> "John Williams" <[email protected]> schrieb im Newsbeitrag
> news:[email protected]...
>
>>Antti Lukats wrote:
>>
>>
>>>I just love how easy it is to port uClinux to new platform, just
>>>change the UCF file and there you go
>>
>>You know Antti, in a very strange way you can take some credit for that
>>fact. Your statement in a comp.arch.fpga posting 18 months ago
>>
>>http://groups.google.com.au/group/co...12c984240d22e8
>>
>>"NIOS uCLinux is WAY easier to get started then MicroBlaze uCLinux
>>thanks to the full integration of the config and integration into
>>Eclipse workbench, as EDK6.3 is also Eclipse based it would be possible
>>todo the same for MicroBlaze uClinux config and build. "
>>
>>p***ed me off so much I went and created the auto-config mechanisms that
>>now make mb-uclinux by far the easiest (and probably most popular)
>>soft-CPU Linux solution around.
>>
>>So, thanks - I think
>>
>>John
>
>
> Oh John,
>
> sorry when I got you pissed off.
>
> you know I am happen to so poor guy that I can not afford to have second
> workstation only for MicroBlaze development and as you know the MicroBlaze
> uClinux build until today can not be done on the Windows machine.
>
> So what I stated 18months ago stands so far that it is (or was at least)
> possible to configure and and build uClinux on single Windows PC a nice to
> have thing for poor souls like me not having separate linux PC box around.
>
> OTOH - I did only check the uClinux config from SOPC builder, it worked, but
> I have never ever seen it working as I do not happend to have NIOS uClinux
> ready hardware ready and hasnt cared enough to obtain such hardware so far
> either.
>
> And I have build uClinux systems way before the auto-config, and it has been
> always been easy for me (after the first try).
>
> I have spent a lot of time in desperate attempts to get coLinux environment
> setup with preconfigured microblaze uClinux toolchain after some pain it
> works but the way todo file transfer to windows host PC is real complicated,
> so only ysterday (or today if in US timezone) I did install Bochs source
> code and compiled Bocs x86 emulator on Windows for one simple reason:
>
> to have windows based virtual linux with pre installed images containing
> MicroBlaze toolchain and uClinux deve tools - so other poor guys (those with
> no Linux!) can also work on single PC and still develop for uClinux
> Microblaze
>
> and again just today I got finally working a MicroBlaze uClinux FPGA tested
> driver for SD Cards so I was able to mount in MicroBlaze uClinux a SD card
> formatted with FAT16 and after mount I did see files on the card.
>
> its FAST bit.banged software driver that works with SD (later I may add MMC
> card support too) cards in NON-SPI mode. It can work with any software
> controllabe PIO port, currently with GPIO CMD-DAT-CLK-card sense onto port,
> all other is software.
>
> a small bootloader exists that loads the full uClinux image from SD card
> using the same bitbang mode, load time approc 7seconds. This could be even
> better as I have not done assembly level optimization to the code yet.
>
> I am replying in such details as I was just about to contact you to ask what
> is the procedure to submit the driver to be included in the uClinux
> distribution (it is GPL licensed)
>
> John, dont judge me so hard, for those who primare work on linux its really
> hard to understand how much trouble it is setting up and maintaining 2 work
> stations for the linux cross compile. I just want to type
>
> make menuconfig
> make dep
> make
>
> from my primary workstation (winPC)
>
> as long as that is not possible, well it means additioal burden - at work I
> did today the following procedure 18 times
>
> 1 edit mmc.c
> 2 TFTP PUT mmc.c
> 3 stand up from my chair going to linux PC here working standing
> 4 copy from tftpboot to \drivers\block
> 5 make
> 6 back to my workplace, sitting down
> 7 TFTP GET image bin
>
> 8 copy image.bin to SD card, insert to FPGA board, reset 10 seconds linux
> prompt is ready
>
> I have a mouse-keyboard-switch, but linux doesnt work with it I really
> have killed pretty much of my time because of no easy solution exist for
> those whose primary system is windows - and that has to be so as FPGA tools
> are generically better supported on WinXP then linux so switching to linux
> completly is not an option for me.
>
> anyway I am hoping to have the BOCHS emulator setup to provide a solution
> that doesnt require the purchase of second PC for microblaze uclinux
> development
>
> cheers
> Antti
>
>

John Williams wrote:

[ ... ]

> Some of these restrictions come from underlying Windows crud, like case
> insensitive filesystems, poor handling of file permissions, that sort of
> thing. Linux sees a difference between 'makefile' and 'Makefile' -
> windows can't.

I don't want to create a long off-topic thread about it, but Windows is
entirely capable of distinguishing case in file names. See the
documentation for CreateFile, specifically FILE_FLAG_POSIX_SEMANTICS,
(e.g. at
http://msdn.microsoft.com/library/de...createfile.asp)
for more details.

Given the basic nature of Cygwin, I'd have expected its implementation
of creat and/or open to include this, and just about everything else
should run on top of that, but perhaps not -- I haven't looked at its
source code recently to check.

> While nobody would recommend overloading filenames in
> this way, there's not a lot that can be done about it retrospectively
> without (IMO) inordinate effort.

I'm not sure what constitutes inordinate, but I'd expect the effort to
be relatively minor. There shouldn't be many places that need changing
(quite possibly only one), and most of the software running on cygwin
expects case-sensitive file names anyway, so it doesn't seem like this
change would be likely to break much of it.

--
Later,
Jerry.

John Williams wrote:
> Hi Antti,
>
> On the Linux vs windows workstation issue, we are almost evenly split
> here in our group. I do everything (ISE, EDK, uClinux, ...) on a Linux
> box, running CentOS3 (perfectly compatible with Xilinx tools). I do
> have an old Windows laptop for running MS Office and web/email but
> that's about it.
>
> Others in the group are running CoLinux, some on laptops, and they run
> all of the tools in that environment. CentOS 3 installs just fine in
> CoLinux, so the entire Xilinx tool flow can occur in a virtual Linux PC.
>
> One of our brainy guys hacked colinux to tunnel the parallel port, so we
> run impact inside CoLinux with vanilla Xilinx drivers - it couldn't be
> much easier.
>
> The decision to not support Windows (Cygwin) for MicroBlaze uClinux
> development is a difficult one, but justified I believe by experience in
> the misery of Cygwin. Cygwin is just enough like Linux to make you
> think "it should work", but just different enough to make life
> miserable.
>
> Some of these restrictions come from underlying Windows crud, like case
> insensitive filesystems, poor handling of file permissions, that sort of
> thing. Linux sees a difference between 'makefile' and 'Makefile' -
> windows can't. While nobody would recommend overloading filenames in
> this way, there's not a lot that can be done about it retrospectively
> without (IMO) inordinate effort.
>
> It's also dreadfully slow - compile times can be on the order of 2-3
> times longer.
>
> Anyway, perhaps we should package up our CoLinux environment a bit
> better and distribute it, it might make life a bit easier for people in
> your position (and those stuck in MS Windows corporate environments).
>
> Regards,
>
> John
>


Hi John,

It would be *very* nice to have pass-through parallel port access from
CoLinux. Personally, I'd be looking at it for debugging a ColdFire
running ucLinux rather than any Xilinx work, but I suspect it would be
of interest to a range of embedded developers. I know the CoLinux
developers have been looking at the possibilities of tunnelling serial
ports, parallel ports, and USB, but have had problems with locking
issues. If your "brainy guy" has working code, perhaps it could be
donated to the official CoLinux project?

mvh.,

David

Jerry Coffin wrote:
> John Williams wrote:
>
> [ ... ]
>
>> Some of these restrictions come from underlying Windows crud, like case
>> insensitive filesystems, poor handling of file permissions, that sort of
>> thing. Linux sees a difference between 'makefile' and 'Makefile' -
>> windows can't.
>
> I don't want to create a long off-topic thread about it, but Windows is
> entirely capable of distinguishing case in file names. See the
> documentation for CreateFile, specifically FILE_FLAG_POSIX_SEMANTICS,
> (e.g. at
> http://msdn.microsoft.com/library/de...createfile.asp)
> for more details.
>
> Given the basic nature of Cygwin, I'd have expected its implementation
> of creat and/or open to include this, and just about everything else
> should run on top of that, but perhaps not -- I haven't looked at its
> source code recently to check.
>

Windows is *not* entirely capable of dealing with posix semantics
properly. It can handle them to some extent, on some file systems
(NTFS) on some forks of windows. It can't handle symbolic links, hard
links are limited (even on NTFS), and having two files like "makefile"
and "Makefile" in the same directory confuses windows. Cygwin goes to a
lot of effort to hide that sort of issue. This is the main reason
(AFAIK) for compilations to be slower under Cygwin than coLinux, as it
takes much longer to find and open files, which is a big overhead when
compiling.


>> While nobody would recommend overloading filenames in
>> this way, there's not a lot that can be done about it retrospectively
>> without (IMO) inordinate effort.
>
> I'm not sure what constitutes inordinate, but I'd expect the effort to
> be relatively minor. There shouldn't be many places that need changing
> (quite possibly only one), and most of the software running on cygwin
> expects case-sensitive file names anyway, so it doesn't seem like this
> change would be likely to break much of it.
>

Hi David,

David Brown wrote:

> It would be *very* nice to have pass-through parallel port access from
> CoLinux. Personally, I'd be looking at it for debugging a ColdFire
> running ucLinux rather than any Xilinx work, but I suspect it would be
> of interest to a range of embedded developers. I know the CoLinux
> developers have been looking at the possibilities of tunnelling serial
> ports, parallel ports, and USB, but have had problems with locking
> issues. If your "brainy guy" has working code, perhaps it could be
> donated to the official CoLinux project?

Should be OK - I'll see what I can do.

John