Re: [linux-sunxi] Probing A10s GPIOs with fel-gpio/pio

[Angus Gratton]

On Mon, Apr 08, 2013 at 08:43:57PM -0700, Angus Gratton wrote:
> I'm trying to probe some test pads on my A10S MK802+ stick.

Worked out most of this. The two marked test points on my MK802+ stick
are PB11 & PB14. According to the datasheet they mux to half of SPI2
or half the JTAG port, but not a UART... Design error? Or is the rest
of JTAG available somewhere else?

Photos: http://www.projectgus.com/files/a10s/

The two pads on two opposite corners of the A10s package appear to be
fiducials or something similar. Measured as floating. Pulling them up
& down didn't show anything in fel-gpio.

I don't see anything else in the photos that looks like a possible
serial port. Anyone have any ideas?

With regards to my other questions:

> However, I'm having trouble getting sensible output. Lots of values seem to
> be changing at random (not just drv_level/data, some mux_sel values are
> changing too.) Here's a sample from running fel-gpio and then pressing
> Enter a few times to have it diff the PIO status without changing anything
> myself: http://pastebin.com/raw.php?i=i5TaErCT

The pio tool was broken and I was looking at garbage uninitialised
data each time. Pull request with fix sent[1].

fel-gpio works fine on A10s, same as A10.


> What are
> the drive levels? Is data used for input only, or is it for both directions?

I was mostly confused here due to trying to interpret random data. It seems:

- Data bit is bidirectional.

- Drive levels don't seem to do anything in GPIO mode that I could
measure easily. The only thing I can guess is they're related to setting an
output current drive limit.


> * I'm assuming it's not possible to get at I/O memory directly via FEL,
> hence the need for the fel-pio.c binary? If I run './fel hex 0x1c20800
> 0x228' then I see some varied but unchanging data, but I assume that's not
> actually seeing into the GPIO memory space?

Yes, you can read I/O data this way. Seems you can't write to the GPIO
space that way, though.

Regards,


Angus

[Henrik Nordström]

On Tuesday, April 9, 2013 5:43:57 AM UTC+2, Angus Gratton wrote:

However, I'm having trouble getting sensible output. Lots of values seem to be changing at random (not just drv_level/data, some mux_sel values are changing too.) Here's a sample from running fel-gpio and then pressing Enter a few times to have it diff the PIO status without changing anything myself: http://pastebin.com/raw.php?i=i5TaErCT

Should work...
 

* Does anyone have any insight? Is this just garbage data or am I really looking at floating/random states on some pins?

You should only see changes in data, no other fields.

* What exactly do the GPIO fields mul_sel, pull, drv_level & data mean? mul_sel & pull I think I understand (mul_sel sets a pin to either simple GPIO or one of the muxed functions, pull is to enable/disable soft pullups on inputs, yes?) However I don't really understand the last two. What are the drive levels? Is data used for input only, or is it for both directions?

pull is pull up/down configuration.

drv_level is uncertain. Not well specified. Not sure it it's different voltage levels or differend current limits or different slope speeds.
 

* I'm assuming it's not possible to get at I/O memory directly via FEL, hence the need for the fel-pio.c binary? If I run './fel hex 0x1c20800 0x228' then I see some varied but unchanging data, but I assume that's not actually seeing into the GPIO memory space?

Direct FEL I/O only provides byte access but the I/O space is only accessible in 32-bit word access. So if using FEL directly only the lower byte of each 32-bit wprd is accessible.

Regards
Henrik

[Angus Gratton]

On Tue, Apr 30, 2013 at 01:00:01PM -0700, Henrik Nordstr�m wrote:
> On Tuesday, April 9, 2013 5:43:57 AM UTC+2, Angus Gratton wrote:
> >
> >
> > However, I'm having trouble getting sensible output. Lots of values seem
> > to be changing at random (not just drv_level/data, some mux_sel values are
> > changing too.) Here's a sample from running fel-gpio and then pressing
> > Enter a few times to have it diff the PIO status without changing anything
> > myself: http://pastebin.com/raw.php?i=i5TaErCT
> >
>
> Should work...

Hi Henrik,

Thanks for replying and relaying the other information about FEL mode
and the GPIOs.

I don't know if you saw the other post I sent on April 12, but the
'pio' tool had a bug that meant I was just looking at uninitialised
memory not actual data from my board.

I sent a pull request with a fix, it's open here:
https://github.com/linux-sunxi/sunxi-tools/pull/13

- Angus

[Henrik Nordström]

ons 2013-05-01 klockan 17:23 +1000 skrev Angus Gratton:

> I don't know if you saw the other post I sent on April 12, but the
> 'pio' tool had a bug that meant I was just looking at uninitialised
> memory not actual data from my board.

Ouch.

> I sent a pull request with a fix, it's open here:
> https://github.com/linux-sunxi/sunxi-tools/pull/13

Ah, sorry about that. Got broken by the pio.c mmap change.

Thanks for the fix! It has been merged.

Regards
Henrik