Re: [Xenomai] ARMv8 (ARM64) port of Xenomai

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

On Mon, Mar 23, 2015 at 03:00:15PM +0100, Jan Kiszka wrote:
> On 2015-03-23 10:53, Gilles Chanteperdrix wrote:
> > On Mon, Mar 23, 2015 at 10:03:06AM +0100, Jan Kiszka wrote:
> >> On 2015-03-23 07:01, Hongfei Cheng wrote:
> >>> Thank you for the terrific info and timely advice. I'll proceed as you
> >>> suggested and report back progress regularly.
> >>
> >> Another tip: it can we useful to do early bring-up on QEMU basis. It is
> >> already in a pretty decent state regarding aarch64, Linaro is hacking on
> >> it, and vendors like Xilinx do their virtual prototyping on that basis
> >> as well (in the latter case for the upcoming MPSoC). Probably - I didn't
> >> try it out myself yet, only planning to do these days - the gdb
> >> interface also works fine, thus will give you source level debugging.
> > 
> > I would not recommend that, as it adds the debug tools and emulator
> > bugs, and removes some real silicon bugs, as well as adding the
> > temptation to rely too much on the debug tools and not see the
> > forest for the tree. If you really really want to use gdb, I would
> > rather recommend JTAG (but it still has some of the issues of QEMU).
> 
> Sure, there are always specific aspects that require real hw - e.g. when
> in doubt about an emulated behavior or when you need to validate
> timings.

Or when you want to use a register that is not implemented in the
emulator.

> But for an initial architecture port, specifically to a pretty
> much unified one like AARCH64, emulation remains handier.
> 
> > 
> > Besides, developing on real hardware is much less painful on embedded
> > hardware than on x86 hardware because: 
> > 
> > - embedded hardware usually has a serial console, which makes things
> > real easy (when everything fails, you can output characters to the
> > serial console in a brute force polling manner) 
> 
> So do all my PC targets. But already the output of a physical console
> slows things down so much that an emulated UART (without speed
> limitation) pays off.

Recent embedded hardware use DMA for serial output, so the serial
output has little to no impact on the code execution unless you have
as much output as the UART bit rate. Unless of course you are using
the brute force polling, but this is something you usually do when
the system is in so bad a shape that the speed does not matter.

> 
> > 
> > - embedded hardware usually does not take forever to initialize its
> > firmware (no BIOS with stupid timeoeuts waiting for not unplugged
> > peripherals). Typically, u-boot is slower to execute in qemu than on
> > real hardware (if you want to execute u-boot in qemu).
> 
> There is generally no need for a boot loader (unless that is your
> development target), you just boot the kernel directly.

Then you are relying on yet another code which is different from
what will run on real hardware. Even more risks of bugs, even more
differences between real environment and emulated environment,
etc...

> 
> There is a trend in industry towards virtual targets. That's because you
> can do much more (and much earlier) with emulation than with real hw,
> and handling is much easier (no wiring, no physical reset, free
> replication of setups etc.).

Being a trend does not mean this is a good idea. I still believe a
lot of people using JTAG or gdb tend to see symptoms rather than
real issue and misinterpret them.

-- 
					    Gilles.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150323/9e85b4f1/attachment.sig>