Trouble setting up GITHub projects in XDE

[LyleHaze]

All interesting..
My math was wrong, now corrected.
xobjdump asks for 0x00001f00, which
also calculates to 400 MHz..

I am now wondering two things..

How can I add a check/load of this value
to the JTAG suite?

What _other_ things are normally handled
in the boot process that I should worry about?

All quite interesting, once I get a clearer view
of the issues. Thank you.

EDIT: Follow Up.
Went back to the fast serial code.
Changed desired_baud to 460800 (115200 * 4)
Working correctly, I'm getting correct readback of all typed characters.

:)

Obviously I'd like to get things "up to speed", but at least we have now:
Confirmed that my system clock settings are not correct.
Confirmed what the correct settings are.

That's a pretty good morning. :)

[segher]

My math was wrong, now corrected.

Mine too :-) (Wrong, that is; not corrected).

How can I add a check/load of this value to the JTAG suite?

There is debug_write_sswitch() for that. But if you wait a little bit I'll update
runxe to set the PLL to whatever is in your XE file :-)

What _other_ things are normally handled
in the boot process that I should worry about?

You need to set up the network of xlinks; that is handled completely
in the XE file. This and the PLL is all the regs in the sswitch.

There is nothing in the pswitch that needs setting up.

There is nothing in the processor status regs that needs setting up,
except the RAM and vector base, and the boot ROM deals with that.
(All the resources are handled by your program).

So, nothing :-)

Working correctly, I'm getting correct readback of all typed characters.

Cheers :-)

[LyleHaze]

OK, on with the project..
As I mentioned before, as a workaround I have set the baud rate to 4X, and I can continue developing.

Now I'm getting tangled up in some other places, but since this thread has already gone "way off" from the original topic, I'll start a new thread for the next questions.

I suppose I should summarize the results here in case someone else finds this thread in a future search:

I started the thread because I could not get any serial code from github working.
I am working on a "foreign" system, that is not fully supported by the XMOS toolchain.
I learned that by editing the project "*.xn" file, and adding my oscillator frequency, the toolchain will calculate the correct clock prescaler settings for my system.
And finally, thanks to the kindness of an XCore friend, my jtag tools will soon support loading that information when code is loaded into the XMOS chip.

Thanks all for your advice, help, and patience as I get "up to speed" here. :)

Now off to start a new thread about dividing workflow into separate threads.

[segher]

Just a quick note to let you know I've updated my JTAG tools to
write the PLL settings in runxe: here. Please let me know if that
works for you (test with sregs, and your cores should run 4x faster
now, you'll notice that I bet ;-) )

[LyleHaze]

Thank You!!
I'll report back again with stories of great success!

[LyleHaze]

Segher,
Either I broke the makefile, or I need to port xs1-elf-as before I can build the new tools.
Since I am running on a PPC processor, I did not look through the XDE directories.

My compiler environment is GCC, but mostly very basic. Most options for MkMk and config scripts are not supported. So I usually have to manually edit makefiles before they will run. Did I break something?

Thanks,
Lyle

[segher]

Either I broke the makefile, or I need to port xs1-elf-as before I can build the new tools.
Since I am running on a PPC processor, I did not look through the XDE directories.

You can get it from my xs1-binutils repo, which should work everywhere
that binutils does. I use it on some quite different PowerPC machines,
for example. It is not completely production-ready yet.

But you do not need xs1-elf-as: it is only used to build the program-sreg-tramps.ci
file, via .s -> .o -> .bin -> .ci (as, ld, and bin2c), and I checked in the .ci file
as well. Maybe the time stamps were messed up.

To fix it, just do the equivalent of "touch program-sregs-tramp.ci", to set the
timestamp to the current time, i.e. newer than any other file, so it will not be
remade. Or just disable the bin2c step by commenting it out.

I've now set things up such that the Makefile only ever tries to regenerate those
files when you pass it M=1 (so don't :-) )

My compiler environment is GCC, but mostly very basic. Most options for MkMk and config scripts are not supported. So I usually have to manually edit makefiles before they will run.

You really, really, really want to have GNU make. I certainly assume it is
available everywhere, life is too short to use broken tools. It is available
for your platform too, it seems?

[LyleHaze]

Thanks, that gets me back in motion. ;)

We have GNU make, gcc, and a few of the most required tools.
What we don't have (and I'm really unfamiliar with these, for obvious reasons)
are the tools used to generate makefiles based on a set of rules, often used for apps
that are written for multiple platforms. As far as I know, as soon as I see a "config"
file or a makefile generator like Mkmk, I know I'll have to manually write a makefile
and figure it out "by hand".
And as I'm sure you have figured out by now, I still have a lot to learn about writing
better makefiles. :)
Some Amiga developers set up a linux station with a cross-compiler, so they will
get access to the missing tools.
Personally, I prefer to do all my coding from the Amiga whenever possible. My work
with these XMOS chips requires me to run XDE on a WinXP netbook for now.

Which brings up a few new questions: Did the new makefile also require perl?
That would be another deal-breaker. I'm fairly sure we don't have that yet.
Python, Yes. but not yet Perl.

I like the new modular format for adapters. That part is easy to port. What's taking
some time is working around all the buffering again. I'll figure it out, but I'm already
considering going back to the "clean" source and trying to use a compiler switch
to omit the buffers, so I won't have to Hack-n-Slash your code too much.

I'll have a look again and see if I can find a clean way to do so. If I'm successful,
I'll pass the edits back in case you might want to merge them permanently.

I saw something in the new code that made me do a double-take. Please check your
inbox to see if it might be a problem.

Also, You have mentioned before that you usually don't use XDE when developing for
XMOS chips. I'd love to learn more about what you use and how you use it. Since
we will never be able to support x86 code or an Eclipse IDE, I'm always curious
about what options we might have for these XMOS chips embedded in our computers.

Again, I thank you for your support and assistance. I look forward to getting the clock
clock rates up to standard.

Lyle

[segher]

What we don't have (and I'm really unfamiliar with these, for obvious reasons)
are the tools used to generate makefiles based on a set of rules, often used for apps
that are written for multiple platforms. As far as I know, as soon as I see a "config"
file or a makefile generator like Mkmk, I know I'll have to manually write a makefile
and figure it out "by hand".

I use plain Makefiles; the "config" file I have is just an include file for it.
It's not autoconf or anything :-)

Which brings up a few new questions: Did the new makefile also require perl?
That would be another deal-breaker. I'm fairly sure we don't have that yet.
Python, Yes. but not yet Perl.

I only use it for bin2c; you could replace it with a little python code if
you want (or awk, or C, or sh+dd, or anything really; it is totally trivial
stuff). And, you do not need bin2c, it is disabled unless you set M=1.

I like the new modular format for adapters. That part is easy to port. What's taking
some time is working around all the buffering again.

The generic part (jtag.c) does not buffer anything now?

If I'm successful, I'll pass the edits back in case you might want to merge
them permanently.

Yes please, I'll happily merge new adapter code. Changes to the rest, I'll think
about :-)

You want to have all tools in one executable, right? I'll probably go that way
as well, will take a while though.

Also, You have mentioned before that you usually don't use XDE when developing for
XMOS chips. I'd love to learn more about what you use and how you use it.

I have no machine that can run the XDE. I just use xcc etc. directly; I cannot
stand IDEs anyway. This is over ssh.

For running the code, I use my JTAG tools (or sometimes I flash to a boot
ROM, or boot over USB). Same tools for all debug.

For assembling and disassembling, I used to use the Forth assembler and
disassembler (also in dis-xs1.git, I really need to rearrange that stuff), but
nowadays I mostly use my binutils port (which works fine for most (simple)
things already). My GCC port can run most simple programs (C, not XC!);
it also can crash very well, it's really good at that. So for production stuff
I still use xcc, remotely.

[LyleHaze]

I grabbed a fresh download, but did not see your changes to the makefile.
One of these days I need to take a serious look at learning more about
makefiles.

The good news: I have created a nemo_adapter for your tools, and I am
back up and running 100%.
Actually, since we are blowing past the old benchmarks, I could say that we
are up and running 400%. :)

I have sent back the new module and a diff list of the other edits I made,
just in case you need a good laugh today.

Segher, thank you for your support. Now off to re-time the projects to the new
system clock!

LyleHaze