yes, it is pipelined, my interest about this implementation is about the 
"debug module", i'd like to see how it is implemented, also the host 
debugger part seems interesting (although … i have read that it has been 
developed in Visual Basic, brrr)

yeah, EJTAG approach is very bloated, i simply do not like it.

about the gdb-stub approach, well i thing i think the ugly of this is 
that filling break instruction to force a breakpoints, also you can't 
trust the firmware (the gdb-stub side) when your soft core is not 
validated, yet.

about the article

> ...
> This enabled us to connect to a hardware ZPU core
> with the GNU debugger like we would attach to the emulator.
> ...

i am afraid this is not correct!

> The same has been implemented for the ADI Blackfin family
> for a long time.

i have bought a blackfin BF537 development board with its 
cheap(1)-usb-jtag-B1000, this jtag is composed by a tiny board in where 
a second BF53x chip sits, that's cool, i have a jtag which is composed 
by the same DSP it aims to debug for :D

the magic of this is that the DSP on the cheap-jtag-cable is running a 
sort of software emulation of the expensive-jtags (they may cost up to 
$4000 USD), so the point is: the dsp in the cheap-usb-jtag is a sort of 
"debug processor" used to debug the real target!

(1) it costs about 200 euro (VAT applied), that is really expensive for 
me, while AnalogDevices says it is the cheapest they have for blackfin, 
the so called "relativity" =D

> In fact, I use emulation to validate the soft core. This is a multi
> stage approach, really.

have you validated the ZPU ? Great =D

I got a similar validation problem with a RISC-MIPS-like cpu and … i am 
looking for the best way to fix the jam. With a friend of mine we have 
recently found 2 bugs in the RTL level of the hazard detect unit, and … 
we suspect other bugs around. Simulating things is very ugly, boring, 
and … terribly slow.

could i ask you more details about (in private, if you prefer, in case 
my email is carlojpisani at gmail dot com)

> There's nothing wrong with using a "break" instruction for soft breaks.
> This is GDB standard technique.

Which is the difference between Harvard Architecture and von Neumann 
Architecture?

The most obvious characteristic of the Harvard Architecture is that it 
has physically separated signals and storage for code and data memory, 
so it is possible to access program memory and data memory 
simultaneously (that is extremely good for pipelining because it can do 
pre-fetch). Typically, code space is read-only and data memory is 
read-write. Therefore, it is impossible for program contents to be 
modified by the program itself.

The von Neumann Architecture is named after the mathematician and early 
computer scientist John von Neumann and Neumann machines have shared 
signals and memory for code and data. Thus, the program can be easily 
modified by itself since it is stored in read-write memory.

What does it means for SoC ? That if you want to use break instruction … 
you need
1) your soft core needs to be developed in the von Neumann Architecture 
way
2) if your soft core is Harvard Architecture … then you need a dual-port 
ram to brings the data-space (which is accessible by all the load/store 
instruction) in order to write the 4 byte break-instruction in the 
instruction-space

Also the gdb-host side needs to hardly synchronized to the debug code, 
in order to remove the break instruction from iram replacing the 
original byte s-code.

p.s.
about Harvard Architecture .. can you imagine how ugly it goes if you 
have iram sitting into flash (like AVR8, aka Atmel Arduino1 core) ? As 
flash are organized in "banks" (chunks of bytes, or word, of you prefer) 
to insert/remove break instruction you have

- to erase the whole flash bank
- to reprogram the whole flash bank

> Nope, I was talking about a MIPS core
> (rewritten from scratch using MyHDL).

which one ? is this MIPS-core public || available ?


> Afraid it's pipelined though

don't worry about this, i have already written my toy-multi-cycle (1) in 
order to toy/study with my uart debug module


(1) actually it has a reduced MIPS1 ISA
- lw, sw, lb, sw
- beq, bne
- j, jall
- add, sub, or, and
- lui, li
- addi, subi, ori, andi

i don't think i will add other instructions
it may be i will add just {break, syscall, something about cop0}

it's an easy toy and must be easy for its definition of "toy"



> Well, I guess I've just got this advice: If it's broken and from someone
> else, don't bother fixing it. Rewrite the whole shlorm :-)

in same case it is a MUST (especially if the original author has 
confused ideas in his/her mind), but … there is an other must that must 
be considered first: why to reinvent the wheel ? also … for example MAIS 
is a great work, and if it has bugs in the RTL level … you'd better fix 
them than think about  rewriting the whole from scratches, don't you 
think it is better ?


> Speaking about Harvard and vNeumann: You're correct, but we're still on
> an FPGA, right? My MIPS implementation is kinda modified Harvard, like
> the Blackfin. Either dual port RAM is used

i applied the same patch (dual port ram to iram, in order to map it to 
dram space, "i" stands for instruction-ram, "d" stands for data-ram) to 
the Mais scheme with success, this makes gdb-stub able to work. Just an 
idea, a proof of the concept, because i think that to use gdb-stub 
(which is firmware) you have to trust the RTL level, and … this is not 
compatible with soft cores that have bugs in the RTL level: the gdb-stub 
is requiring interrupts, so … i am afraid it will look like a bloody 
fight nightmare if the RTL is bugged, and this is also a contradiction 
to the purpose, which is to find out a way to fix the RTL from its bugs!


> You're completely free to implement WP units for HW breakpoints, but I
> would start with the simple things first

that is a good idea!

> The in-circuit-emulation approach is way more elegant
> and even simpler to implement

ok, good advice, i will follow it, thank you =)

> It's described in various papers

i am new to these things, up today i have always "used" jtag and bdm 
(motorola m68332 / freescale coldfire) as "user", i have never 
implemented such a stuff.

> The MAIS architecture is not really laid out for ICE, although I had a
> functional ICE workaround for it.

it may be a good example, can i see it for educational purpose ?

is there around any good and simple jtag or bdm module, with a bit of 
documentation and HTL sources ?

what about putting a tiny debug-processor inside the SoC (just near the 
main Softcore) ?

Assuming you have enough resources to put two soft core inside your fpga 
(a smaller debug-processor-Softcore, very essential and tiny, and .. a 
potential elephant big Softcore plus its devices, rams, etc etc, … i 
think a spartan3e-500 may not be enough but a 1600 could be), we are 
speaking about something that can
- blocks the Main Softcore's clock, at a particular PC, or .. just every 
its fetches to do step by step instead of breakpoint debugging
- access (reading/writing) the Main Softcore's registers (also to PC, 
EPC, cause, cop0 and whatever …)
- access (reading/writing) the Main Softcore's local bus (so r/w its 
iram/dram)

the idea is to put gdb-stub inside the tiny Debug Processor (which is 
validated, so you can trust it), and let it to (uart-serially-)-talk 
gdb-protocol with the host in order to control the target !

in this ways you put much more intelligence in the debug module, which 
could simplify things like … attaching the host in order to control 
things

with a gdb-debug-processor the host could simply send commands (high 
level commands, also in pretty ASCII form) and gets replies instead of 
hardly handling all the signals of a jtag tap machines (which also 
requires … a special file that describe the target from the point of 
view of the TAP machine)

what do you think ?

> A JTAG/BSCAN-FSM is just the perfect debug processor...

i do not think about that because
1) you have to deal with BSDL files, which can be very complex/difficult 
to have/write/use
2) you have to deal with a low level protocol (such the jtag is) that is 
slow and which requires a lot of cares about the SoC main clock
3) the host side is … difficult, too, and you have to deal with USB-jtag 
adaptor and their driver/handler etc etc


a debug processor which talks ascii protocol over the uart is simply 
"easy", portable, good to be understood, fast, and … easy to be 
adapted/interfaced with gdb

Legacy My wrote:
>> A JTAG/BSCAN-FSM is just the perfect debug processor...
>
> i do not think about that because
> 1) you have to deal with BSDL files, which can be very complex/difficult
> to have/write/use

Nope, this has nothing to do with BSDL. Look at the paper I've sent you.
Either you use the built-in JTAG primitive or implement your own FSM.

> 2) you have to deal with a low level protocol (such the jtag is) that is
> slow and which requires a lot of cares about the SoC main clock

Nah, that's easy. If you do not need to "live" poll the PC or specific 
counters, you don't even need cross clock domain syncing. The JTAG state 
machine allows for enough handshaking. On the MIPS, a program loads 
within fractions of a second onto the target using emulation (memory 
write commands).

> 3) the host side is … difficult, too, and you have to deal with USB-jtag
> adaptor and their driver/handler etc etc
>

Ok, that's stuff you have to do once. There's a bunch of tools around 
(OpenOCD, various gdbproxy implementations for FTDI adapters, etc.)

>
> a debug processor which talks ascii protocol over the uart is simply
> "easy", portable, good to be understood, fast, and … easy to be
> adapted/interfaced with gdb

Well, if you think so, then go ahead and write one. There's just one 
dogma in the debugger's world: You don't wanna go and debug your 
debugger.

IMHO, gdbstubs over UART are completely useless on an FPGA. You'll have 
to deal with proper timeouts, etc. All serial gdb stubs I've seen so far 
were broken by design and very unstable (this due to some serious gdb 
design flaws, however they can be worked around by ethernet).
Put the intelligence in your host side, not the FPGA!

Cheers

- Strubi

is it possible to see a working example ? i mean source code, script, 
and something i can put, on my toy-fpga ?

Strubi wrote:
> follow some simple emulation techniques as demonstrated.

where has it been demonstrated by examples ? i can only see this (1) 
skimpy article.


(1) http://tech.section5.ch/news/?p=251

Strubi wrote:
> I've sent you all you need to have to implement your own debugger basing
> on the approach from the ZPU debug branch.

you have sent me a poor skimpy paper without any example or code, your 
skimpy pdf is useless at all, it is much more a brochure to sell a 
product than a technical paper, there are no details, no documentation, 
nothing at all.

> So, please don't keep asking the same question over and over again.

first of all i am free to ask whatever i want and how many times i want 
(also you are not the only one, others can contribute, giving answers), 
second i am asking things because they are not clear at all

> You need to dig into the details, others won't do it for you.

well, to be honest i am also thinking you have nothing working and you 
are telling bullshit just in order to open doors with business.

in short: bye-bye

> Ok, here's a few last comments:

i hope it is the last time i have to read you!

You have trashed a lot of my time

> - Showing off

nothing useful


> - Debug tools are simply not free. My advices are.

Unfortunately, you are missing you are dealing about OpenSource things 
and you are posting in a forum where people is interested about such a 
things

you seem to use this forum to claim about your private business, perhaps 
this is useful for you, but how can be useful to others ?

> - Learn

learn respect!

> Immature people like you are mainly the reason why I stopped handing out
> valuable source code in the first place.

Yeah, just the last one comment: i am really sure you have nothing of 
what you claimed "ready and working" as i hope you are just trolling to 
business doors, about "reason" you look like the ones-fellows that grab 
other's people work in order to close things into their dirty business, 
that means you take other's people effort for free! It is not correct.

Btw, for such a reason, hope never see you again in my threads!

it seems to me there is a good OpenSource and Documentation around 
Lattice LM32, which also provide a debug module plus its host side.

Pretty to know that, writing this note in the hope it could help people 
like me (student with a limited know/how, learning needed, still in 
progress)

In case of the LM32, Lattice use the hard coded JTAG primitive of the
FPGA. Perhaps this can be rebuild by VHDL/Verilog to make it usable
for other FPGAs.

In this case an OpenSource CPU with a complete Ecosystem would be
available?!

Regards,
Michael

Hello ???,

I understand under "Ecosystem" a full functional system with Compiler,
Debugger and so on. Yes "Ecosystem" could be to colored and bloomy.
I mean a working toolchain. In case of LM32 it is available for the
Lattice platform. Nios for Altera and Microblaze for Xilinx. Even
there exist free RTOS and network stacks which can working on FPGAs.

E.g. there exists working toolchains for ARM, even with debugger.
In 2006 I started YAGARTO because there was no free working windows
native solution available. Where even the debugger was working under
Eclipse.

I think it is the same problem with the free OpenSource softcore
solution now. There exist no smooth working solution. Of course you
can use the CPU from the FPGA manufacture. Even you will find some
on OpenCores, but does there exist a complete toolchain where
the functionality can be compared against an hardcore CPU?

Even it could be possible that all the MIPS and other softcores are
only a playground in the academic research. But why does not exist
a free FPGA/JTAG debug solution whereas more people has started with
an own CPU?

I think if there exist a free smooth working toolchain and a free
CPU core. It will be easier to start porting the application to
this solution.

Regards,
Michael

> I think it is the same problem with the free OpenSource softcore
> solution now. There exist no smooth working solution. Of course you
> can use the CPU from the FPGA manufacture. Even you will find some
> on OpenCores, but does there exist a complete toolchain where
> the functionality can be compared against an hardcore CPU?

well, for Soft Core MIPS1 compliant it is possible (and i already did) 
to realize a full working toolchain composed by

1) GNU binutils, assembler, linker, objcopy objdump (these are useful to 
manipulate the final binary in order to upload it to the target or to 
embedded it into VHDL)

2) GNU C compiler, aka gcc, it is tricky for MIPS1 but it works

what is still missing ? all the debug side!

gdb-mips can be cross-compiled for host in order to remote-connect to a 
gdb-stub running inside the soft core, but this part is … simply wrong 
by its definition!

you can not trust a firmware like gdb-stub until you are pretty sure 
your soft core is pretty and full validated (which is false during the 
development stages)! Also gdb-stub work has stalled for a few years (i 
can show it with my ATLAS board, it has gdb-stub in its firmware, it is 
NOT compatible with modern gdb's protocol) and one of the problems is 
that gdb serial protocol has evolved, but documentation didn't … what is 
around the web is crippled gdb-stub known that not all functions worked 
and will work.

extremely care is needed about this


> Even it could be possible that all the MIPS and other softcores are
> only a playground in the academic research.

yes, all i have seen about MIPS is

1) mono cycle -> academic material, not really usable for real fpgas, 
not compliant with any MIPS1 class (they use to have an extremely 
reduced ISA, to reduced that it is impossible to retarget gcc/lcc or 
whatever C compiler), practically used within HDL simulators to teach 
computer science

2) multi cycle (not pipelined), it is the advance version of 1), used in 
advanced university courses, still not usable in practical things

3) the pipelined approach is pure theory in universities, because it is 
too difficult and it requires to much effort to be handled in 
laboratories. All is existing is … hobbits project for the most (with 
exceptions, like the LM32, which was developed by a Company), btw, some 
are good, same are not, and they are used not to be trusted as 
"validated", that means you are not sure they are really working without 
bad behaviors! Also … practically they use to miss the debug side (no 
ICE/TAP). ZPU and LM32 are exceptions, they comes with a pretty TAP 
inside, but they are not MIPS.

3) virtual systems, e.g. SPIM, EDUMIPS64, softwares that run on 
workstation and try to teach you about assembly programming the MIPS, 
the must of these soft wares are still not exactly MIPS1-compliant, e.g. 
SPIM has no delayed slot and it is missing a few opcodes, so you'd 
better program it in assembly, as suggested by the SPIM ambient.


> But why does not exist a free FPGA/JTAG debug solution
> whereas more people has started with an own CPU?

probably because guys are using jtag/BDM/etc with real ASIC, so the 
effort has been taken this way instead of thinking/writing/debugging 
around Soft Core. I can't provide a better explanation, but i am really 
thinking the debug things are not easy, they go very complex, so … i am 
afraid an other reason of this … may be that this things are not a piece 
of cake for the rest of us, and only Guru-addicted-guys can =(


> I think if there exist a free smooth working toolchain and a free
> CPU core

usually they exist, but be in mind that "toolchain" is not guarantee to 
have a debugger, usually with "toolchain" you mean {"binutils" + "c 
compiler"}, and you are missing the "libC" environment that is not 
necessary with the "bare board" aka "metal bare" aka "os-less" profile: 
i mean you can write by yourself your own libC and BSP. It's not 
difficult, it's really a piece of cake.


> it will be easier to start porting the application to this solution

an other problem is related to the fpga resources, for example the bram 
amount you have and could handle in your pfga.

the MIPS architecture is eating about 4-6 times the space of a CISC 
machine. Try to compile for 6809 for example! There is a pretty SoC made 
around 6809, it has a fully validated 6809 soft core, also there is

- gcc-6809 port, and it is working brilliant!
- binutils, the linker is tricky, it is not GNU compliant, it does not 
support common linker scripts, it does not produces an elf, it has a 
sort of binary output only, but it works!
- there is no gdb-6809, but there is great Windows program, aka 
noICE-6809 (you could get it for free), that is pretty able to use your 
elf's debugger-symbols (if you compile with -g flag on) in order to make 
you able to fully debug you C/assembly application.

but conceding instruction size, as i said MIPS is 4-6 time bigger than 
CISC 8 bit machines, that means you need larger bram in your FPGA, that 
means … we'd better implement an external SDRAM controller in order to 
have large ram to be used for .session {data, text}

this also means to have a fast upload link or an external SPI flash to 
bootstrap

in short: you can buy a real Atheros tiny router for 10 euro from china 
(i bought mine at 15 euro as the total, already shipped and VAT 
applied), it comes with an ASIC MIPS32-r2 core and it is already ready 
to work, it has soldered 64Mbyte of ram, a pretty DRAM controller, usb, 
ethernet, spi, uart, COP0 with timers, and also a JTAG port, the whole 
for 10 euro, so i think these things are killer applications about 
fpga-SoC … so people take effort to them instead of having troubles and 
consuming time developing all of these features in HDL (also, a good 
point is: WHY? does it makes sense ? Sometime it has no sense, i mean 
you'd better put an FPGA near to an ASIC CPU or SoC, instead of toying 
with HDL to have the whole embedded)


p.s.
also these chinese toys run linux, that is an other killer application 
for the most of guys, unfortunately =(

p.s.
guys, i am always talking about compiling/recompiling things on linux 
host, i do not want to deal with CyGwin, in short because i have found 
it more difficult and frustrating all the times i tried to compile 
things from GNU.

i trust virtual machines instead, for example putting a development 
linux mini root inside a VirtualBox Virtual machine, this way it will go 
easy for everyone

- download the virtual machine (hopefully it could be around 500Mbyte) 
with the development mini root inside (gcc, bintuilts, and so on, pretty 
ready out of the box)

- download the virtualizer, e.g. CoNix (1), or VirtualBox, or such a 
things

- run it from you host OS, about CoNix … well Windows Xp is the only 
choice , while VirtualBox runs on Windows, MacOSX, linux

- have fun


on linux you could prefer to mount the mini root, and in case it is 
possible to use a kernel service in order to have things 
loopback-mounted, something like mounting an image file (the virtual 
file system image, practically a file, used by the virtual machine) to a 
path instead of mounting a real device.



(1) CoNix is a virtualizing technology used by Analog Devices to put a 
linux kernel into a cooperative environment for Windows, that means you 
can have a virtual machine that shares files with your host NTFS, it 
also shares the lan, and makes you able to compile things inside a 
virtual filesystem (EXT3) full provided with all the LINUX environment 
(they are required by git, for example, NTFS has no native support for 
this, so CyGwin has to use ugly tricky workarounds) . Trust me, it is 
extremely cool if you want to mix Windows and Linux for your hobby 
purposes!

In my case i need Windows XP instead of linux, as native host OS, 
because i have a lot of Applications that are Windows-binary-only and 
they do no run inside Wine (especially if they need to access the 
hardware). So i am using this solution that is excellent! You also need 
a ssh-v2 terminal, plus a X11 environment: MobaXterm is the perfect 
solution for this, it pretty works under Xp, and it is free ! It is 
perfect to provide you a console to access the virtual machine 
throughout a Windows application.

- - - - - - - - - - - - - - -
Propeller 1 is now OpenSource
- - - - - - - - - - - - - - -


see this news, it provides a download zip package with inside Verilog 
sources of the Propeller v1, plus a pdf with instructions to put this 
SoftCore on Altera boards (e.g. De0 nano)

http://www.parallax.com/microcontrollers/propeller-1-open-source

personally i do not like "propeller", i am writing this news in the hope 
it can help guys that are looking for a complete SoftCore eco-system, 
because in case you are wandering … Yes, it also comes with its 
toolchain and debug module!

I have tried the Mais CPU for some month.
And it is not the right CPU for me at the current level.

> And it is not the right CPU for me at the current level.

exactly what is your purpose ? Have you ever considered an ASIC CPU 
instead of a pure FPGA SoC design ? In case have you have considered an 
ASIC CPU connected to a FPGA like the "mojo" boards, which also provides 
a native jtag, so you are fine with OpenOCD ? Which are your target 
applications, and exactly WHY you want a SoC ?

> I have the impression that

i have the impression that guys are attracted by the following things

"Connect GDB server to already running ARM micro program on-the-fly, 
When I was using Rowley CrossStudio, there was Attach button which 
connected debugger to already running program on the micro. Of course I 
know that Debug info in the project and binary on micro has to be in the 
sync. Now I use Eclipse, GCC and St-link GDB server, but question apply 
to other GDB servers like CoIDE GDB and OpenOCD. Is there same/similar 
functionality of attaching GDB/Debugger to already running code on micro 
with these tools? If I knew the exact term of this I would google it"

it seems an other point in favor of my thesis: it seems people want 
things already working just out of the box, and they are expecting a 
fpga-SoC to have these features already running, elseway they go for 
ARM-chips =(

it also seems no one remember the old-ages where there ware no ICE and 
jtag, for example m68k has nothing, and people used assembly monitor 
traps to debug throughout the serial port.

> The JTAG tool like OPENOCD receive gdb commands and make from this JTAG
> signals. This can be also frustration, when the timing is not correct or
> the JTAG server is for you CPU not full supported.

this is the reason of the idea of debug processor.



p.s.
Atmel is going to use a new proprietary debug-chip, it will go cheap and 
only compatible with AVR-studio, they want to use it for their new ARM 
boards and Arduino is planning to do the same with "Arduino/Zero".

>
> You have trashed a lot of my time

Wrong. You've used too much of my time. Definitely.


> you seem to use this forum to claim about your private business, perhaps
> this is useful for you, but how can be useful to others ?
>

I haven't read so much bullshit in a while...

>
>> Immature people like you are mainly the reason why I stopped handing out
>> valuable source code in the first place.
>
> Yeah, just the last one comment: i am really sure you have nothing of
> what you claimed "ready and working" as i hope you are just trolling to
> business doors, about "reason" you look like the ones-fellows that grab
> other's people work in order to close things into their dirty business,
> that means you take other's people effort for free! It is not correct.

FYI:
I've sent you plenty of info, including links to working code. If you 
had some decent amount of teeth, you would have gotten started with the 
docs and would have found out that it is far from being a 'brochure'. 
What do you do? You keep complaining and annoying me with private 
messages.
Sorry, boy, but this is just far from the least bit of netiquette, and 
you should simply accept that I don't opensource all of my work to 
nagging students. Also, your false allegations are inacceptable and you 
should be ashamed.
First, I don't do business with students, plus it definitely isn't 
dirty. Your tantrum babble would be rather close to defamation, if it 
wasn't so ridiculous.

>
> Btw, for such a reason, hope never see you again in my threads!

Well, I'm sorry you have to read this again, but you're behaving very 
immature. This is my last advice: Quit the pestering/trolling and start 
writing some code yourself.

Regards,

- Strubi

i do not want to deal with a troll like you

> Wrong. You've used too much of my time. Definitely.

yes, it is wrong: i haven't contacted you, YOU have contacted me, 
annoying then with something that looks like you want to sell to your 
customers

by emails (and also here) i have asked you 2 times about your code that 
is also not compiling and useless by its design (i was also told about 
this by other guys here in private).

Facts: four emails sent for the total, an useless brochure got.

You have claimed around the net about your "revolutionary debug method 
that should save us", so assuming what you have written could really be 
useful, i have asked for more informations and details, but, as the fact 
you believe you are a genius and other guys are simply "no-gooder", or, 
more probably, that they MUST be your customers in order to have 
informations, you have answered "go to the hell", that is really aligned 
with the OpenSource philosophy and it is also very polite and useful, 
man.

Let me say that people like you are THE reason why OpenSource is going 
wasted, especially if we consider that what happened looks like an 
evidence of your real intentions to open doors to your business, in 
order to sell things or to be a asked for consultant's jobs: you have 
nothing really working and you can't prove the opposite, while it could 
be easily proved that it is politically incorrect, especially when you 
try to use other people's work to close their effort into your business.

btw, i have things to develop, so you could really get my "bye bye" for 
free.

> (2)
> http://www.le.ac.uk/eg/embedded/PH.htm

two words about this topic: i have opened it asking about(2), but, as 
the fact "MIPS1 PH project v2's sources" are not available and as the 
fact i have been developing the debug-processor in a completely 
different way, about me, i assume this topic is concluded and in case i 
will open a new thread.

regards

Duke Scarring wrote:
> Martin S. wrote:
>> I haven't read so much bullshit in a while...
> Me too

yes, let me explain others what happened, then you can go to the 
blacklist, too.

you have contacted me in private asking annoying things and hints about 
the development of my SoC, also you wanted hints about book and 
development material, and i kindly answered you also offering a free 
evaluation copy of the book i have bought (and payed) from Amazon! I 
have provide this book and support in the hope it could be helpful for 
you!

note, YOU have contacted me, then i asked about your comment about the 
MAIS, you answered not-resonable things like "it sux" without providing 
any valid reason, so i asked WHY you have find difficult and exactly 
WHAT you have found difficult -> that is useful for us in order to 
develop what could make you more comfortable

and at this point of the conversation, what was you answer, child ?

i asked these things 2 times, then i understood that you have found 
difficulties because the SoC comes without boot loader and no debugger, 
so you find difficulties because you have to re-synthetize everything 
and every time you change the firmware (that is a VHDL file).

that's UAU, very amazing from a guy who is claiming to be able to write 
an operating system port in his web site !

so the next question was: why haven't you code the boot loader by 
yourself instead proving us such a rants ? You answered "every body is 
able to write a boot loader", everybody is able, but you did't !

Talking with guys like you is a totally time trashed, i have written a 
lot of things here, and i am thinking it was time trashed, i do now want 
to trash my free time this way, i'd like useful conversation, i have 
been writing tools, i have been doing debugging, i have been using my 
free time also to help others.

btw, my disappoint is really over, since now, i have found a way to hide 
any notifications about this thread, i will never follow it, and the 
next time i will read such a shit i will remove my account from this 
forum!

Hello,

it was not Duke, I think you mean me?

>you have contacted me in private asking annoying things and hints about
>the development of my SoC, also you wanted hints about book and
>development material, and i kindly answered you also offering a free
>evaluation copy of the book i have bought (and payed) from Amazon! I
>have provide this book and support in the hope it could be helpful for
>you!
This is correct, I have deleted the files directly on the server and
bought the book from Amazon.

>note, YOU have contacted me, then i asked about your comment about the
>MAIS, you answered not-resonable things like "it sux" without providing
>a reason, so i asked WHY you have find difficult and exactly WHAT you
>have found difficult -> that is useful for us in order to develop what
>could make you more comfortable
This is correct, I have told you that I am not comfortable with the Mais
CPU compared to the LM32. I told you to test the "soc-lm32" project to
see the difference what I mean. With the soc-lm32 it is easier to get
the CPU up and running.

>i asked these things 2 times, then i understood that you have found
>difficulties because the SoC comes without boot loader and no debugger,
>so you find difficulties because you have to re-synthetize everything
>and every time you change the firmware (that is a VHDL file).

>that's UAU, very amazing from a guy who is claiming to be able to write
>an operating system port in his web site !

You have not understand my motivation. I have told before like YAGARTO.
It was created to simplify the use of an OpenSource ARM toolchain.

And this is my motivation here too. I want to create an OpenSource
MIPS packet which can be used easily. Therefore I am searching a
good point to start.

Best regards,
Michael

this project is completed. If someone is interested, feel free to 
contact me