starting embedded linux debugging

That's too bad, you have my condolences. You can probably cut the schedule in half by switching to a Linux host.

Same as in non-embedded environments:

If it that doesn't work, I create a circular buffer and log timestamped "events" into it, then I put in code to dump the circular buffer when something interesting has happened.

I don't know what dbg is. I suppose you could use gdb for application code, but I rarely find it useful unless I'm trying to send a bug report to somebody based on a core dump when their program crashes. There is some scheme to use a debugger on kernel code, but I've never known anybody to use it.

DDD and Insight are both good GUIs for gdb.

My main comment: debuggers are vastly overrated. You can often accomplish in 20 minutes of study that which would take 20 hours of stepping and breakpointing.

Next time, if you have to post the same message to several newsgroups, please cross-post instead of multi-posting.

I replied in comp.arch.embedded. Please look there.

Half a year ago I also started my first embedded linux project. I asked some suppliers of hardware and software of our company if it's advisable to use Cygwin . The most said: "You will not be able to compile the kernel, because Cygwin can't handle that long path names." or "Most of our customers have problems with that tftp server under windows, it doesn't work". So i didn't try it as a development environment. One problem you will have under Windows is, that if someone sends you a tarzipped archive with source code and you decompress it under windows, it will overwrite some files, because the file system is not case sensitive. It's a small problem, but if more small problems ... bla bla you know.

The company I work for doesn't allow you to install a Linux system and connect it to the network. So i decided to buy a couble of VMWare licenses and every devolper installed VMWare on his computer. Everybody had Debian under VMWare running. Then I had to install some packages on my machine and had some programs and testcode here and there, and every devolper had his own isolated system with different packages and tools installed. Very bad solution, and it was also soooo slow to compile under VMWare. Then I set up the same system on a separate computer. All developers are now connected over an additional network card and switches to this computer. Using remote shell or telnet (Cygwin), sometimes over VNC. Making backups from all home directories is easy, all are using the same environment for compiling. If you recognize that some package ist missing, update one computer and all developers have it. I think that's the best way to make the development environment for Unix in a M$ corporate network.

If you are looking for a grphical frontend for gdb, try ddd.

Enjoy your first Linux project,

Simon

They're not talking a lot of sense then. I have the kernel compiling perfectly easily under Cygwin.

TFTPD32 on Windows works perfectly :

If you have to work a lot on both UNIX-like systems as well as Windows, Cygwin is possibly a useful compromise. VMWare would definitely be preferable, however.

That isn't my experience; VMWare is almost as quick as the host machine.

In fact, I use VMware every day, but the opposite way around, to use some Windows CAD programs on a Linux machine. It's just as fast as the host, because it's running most stuff native on the host's processor exactly as if the host was running the embedded OS. The only performance hit you *might* see is with screen drawing, because it's emulating a video card on top of your native OS's graphics system. Nevertheless, the graphics performace of the CAD stuff I use is pretty much the same as it is under native Windows - although it's not 3d which I'm sure would suffer. Other IO might suffer a bit too, although that's generally not much of a problem.

Do you have the guest tools installed on your VMs? They make an appreciable difference to graphics performance. I've not used many linux VMs (because it's my host so I don't generally need to) but I do use a Fedora Core 1 VM (on a FC4 host) to do some backward compatible stuff. In that instance, though, I don't use X, and I edit on the host, and only compile on the guest using a virtual network connection to the host's filesystem. You could do the same with a Windows guest - I also do that for some windows based DSP compilations with the Analog Devices DSP compiler whose name I temporarily forget.

I wonder if the company you work for realises that a VMware hosted OS is effecively a Linux machine, and if you've bridged it to the network it's effectively connected to the network. If they're stupid enough to have that policy, but still want you to develop a linux project, then they're undoubtedly too stupid to realise that. Why on earth do they have such a stupid policy? If they really insist on it, can't you install some Linux machines, and run a completely separate network with a single ethernet switch connecting them? Or get a job with a company that's dragging itself into the last couple of decades of the

I'd like to run Linux by default, but unfortunately in the embedded world a lot of tools are fixed on Windows - things like CPLD programmers, some JTAG devices etc which fiddle with the parallel port and have proprietary Windows controlling apps.

They do, but another trick I like to do is use Cygwin/X and throw an XDMCP session from the VM onto the Windows machine (when the VM is a Linux OS). That way the display rendering is done "natively" by Windows.

I assume you're talking to the previous poster. Some larger places have daft and all-imposing IT departments that are restrictive about whom they allow on the network. They can quite easily block the MAC addresses that the VMware bridged networking interface uses (although you should still be able to use it's NAT capability).

Quite true. Stuff that needs the parallel port can probably be run from VMware, but stuff that needs to access things on the PCI bus won't work. I know that parallel port dongles work fine from VMware, for example, because it allows direct access to the hardware - well, it might not be direct I guess but the end result is the same. I guess it has to track contention with the host's accesses somewhere.

Yes, I was referring to the previous poster, got confused with the quoting levels :) I know about IT departments, often the company's worst enemy. But don't start me, I could rant ...

One problem you will run into if you try to compile a kernel under cygwin is that the Windows file system is not case-sensitive, and unfortunately there are places in the linux source tree where two files appear in the same directory that differ only by case. You will have to find these and modify the names and places they are referenced (#include, Makefile, etc.) before you will be able to compile the kernel.

Gregg