[v2] package/pdbg: new package

PowerPC FSI Debugger, for low level debugging of a Power8 CPU over FSI.

Signed-off-by: Joel Stanley <joel@jms.id.au>
---
v2:
 - Fix whitespace in pdbg.mk
 - Add URL to help text

 package/pdbg/Config.in |  8 ++++++++
 package/pdbg/pdbg.mk   | 13 +++++++++++++
 2 files changed, 21 insertions(+)
 create mode 100644 package/pdbg/Config.in
 create mode 100644 package/pdbg/pdbg.mk

Hello,

On Mon, 25 Jul 2016 16:23:12 +0930, Joel Stanley wrote:

> diff --git a/package/pdbg/Config.in b/package/pdbg/Config.in
> new file mode 100644
> index 000000000000..cf37eb8aca41
> --- /dev/null
> +++ b/package/pdbg/Config.in
> @@ -0,0 +1,8 @@
> +config BR2_PACKAGE_PDBG
> +	bool "pdbg"
> +	depends on BR2_arm

Anything that makes it ARM-specific?

> +	help
> +	  PowerPC FSI Debugger, for low level debugging of a PowerPC CPU
> +	  over FSI.

It would have been good to explain somewhere than pdbg runs on the BMC,
which is generally an ARM-powered system monitoring/controlling a
number of PowerPC CPUs. Otherwise, it feels odd to have a
PowerPC-related package available only on the ARM architecture.


> +PDBG_VERSION = 90a7370a11e727f1482dea6ff2bd6aec20c64805
> +PDBG_SITE = $(call github,open-power,pdbg,$(PDBG_VERSION))
> +PDBG_LICENSE = Apache 2.0
> +PDBG_LICENSE_FILES = COPYING
> +PDBG_AUTORECONF = YES

Side note (unrelated to Buildroot packaging): had a look at the code,
and this mapping of /dev/mem to then bing-bang some protocol on GPIOs
from userspace is really, really nasty :-/

Thomas

Hi Thomas,

On Tue, Jul 26, 2016 at 7:39 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Mon, 25 Jul 2016 16:23:12 +0930, Joel Stanley wrote:
>
>> diff --git a/package/pdbg/Config.in b/package/pdbg/Config.in
>> new file mode 100644
>> index 000000000000..cf37eb8aca41
>> --- /dev/null
>> +++ b/package/pdbg/Config.in
>> @@ -0,0 +1,8 @@
>> +config BR2_PACKAGE_PDBG
>> +     bool "pdbg"
>> +     depends on BR2_arm
>
> Anything that makes it ARM-specific?

Upstream has only ever tested the code on ARM. It does build for x86
(and power, and anything else I guess), but as you point out below it
is only useful when run from a processor that is attached to a p8
host.

What's the general rule in this circumstance?

>
>> +     help
>> +       PowerPC FSI Debugger, for low level debugging of a PowerPC CPU
>> +       over FSI.
>
> It would have been good to explain somewhere than pdbg runs on the BMC,
> which is generally an ARM-powered system monitoring/controlling a
> number of PowerPC CPUs. Otherwise, it feels odd to have a
> PowerPC-related package available only on the ARM architecture.

Sure, I will add some more text.

>
>> +PDBG_VERSION = 90a7370a11e727f1482dea6ff2bd6aec20c64805
>> +PDBG_SITE = $(call github,open-power,pdbg,$(PDBG_VERSION))
>> +PDBG_LICENSE = Apache 2.0
>> +PDBG_LICENSE_FILES = COPYING
>> +PDBG_AUTORECONF = YES
>
> Side note (unrelated to Buildroot packaging): had a look at the code,
> and this mapping of /dev/mem to then bing-bang some protocol on GPIOs
> from userspace is really, really nasty :-/

Yep! You and I are the same page here. To date the tool has been used
on a BIOS vendor's BMC firmware, running a very old kernel that lacks
the proper linux APIs for access to hardware. It's not ideal.

I've been slowly upstreaming a from-scratch kernel port. Once we have
that in place pdbg can add support for doing GPIO through the kernel.

In the future near future we will add FSI support in the kernel, and
from there perhaps use the Coldfire processor inside the Aspeed SoC to
offload the bitbanging. Lots of work to do, but we're getting there.

Cheers,

Joel

Hello,

On Tue, 26 Jul 2016 11:43:53 +0930, Joel Stanley wrote:

> > Anything that makes it ARM-specific?  
> 
> Upstream has only ever tested the code on ARM. It does build for x86
> (and power, and anything else I guess), but as you point out below it
> is only useful when run from a processor that is attached to a p8
> host.
> 
> What's the general rule in this circumstance?

I believe in such cases we tend to make the package available on all
architectures anyway. There is no inherent limitation in having it
build and run on other architectures.

The only cases where we add architecture dependencies are:

 - The package contains architecture-specific code.

 - The package contains pre-built binaries for a given architecture
   (e.g. OpenGL blobs).

 - The package is really relevant only for an architecture, like some
   GPU or VPU related stuff, where the GPU/VPU only exists for this
   architecture. We could say that pdbg falls into this category though.

> >> +PDBG_VERSION = 90a7370a11e727f1482dea6ff2bd6aec20c64805
> >> +PDBG_SITE = $(call github,open-power,pdbg,$(PDBG_VERSION))
> >> +PDBG_LICENSE = Apache 2.0
> >> +PDBG_LICENSE_FILES = COPYING
> >> +PDBG_AUTORECONF = YES  
> >
> > Side note (unrelated to Buildroot packaging): had a look at the code,
> > and this mapping of /dev/mem to then bing-bang some protocol on GPIOs
> > from userspace is really, really nasty :-/  
> 
> Yep! You and I are the same page here. To date the tool has been used
> on a BIOS vendor's BMC firmware, running a very old kernel that lacks
> the proper linux APIs for access to hardware. It's not ideal.
> 
> I've been slowly upstreaming a from-scratch kernel port. Once we have
> that in place pdbg can add support for doing GPIO through the kernel.
> 
> In the future near future we will add FSI support in the kernel, and
> from there perhaps use the Coldfire processor inside the Aspeed SoC to
> offload the bitbanging. Lots of work to do, but we're getting there.

OK, sounds good.

Thomas