First, in adding the link to the sunxi wiki page documenting GPIO access on Allwinner chips[1] to the rhombus-tech.net "Testing" wiki page[2], I again triggered the "An error occurred while writing CGI reply" page delivered at URL: http://rhombus-tech.net/cgi-bin/rhombus/ikiwiki.cgi
I clicked the "Save" button after editting the ikiwiki code and just waited for it to return.
Second, the linux-sunxi wiki page refers to the interaction with the GPIO driver differently depending on whether using linux-mainline or sunxi-3.4 kernel. If memory serves it seems you mentioned we plan to ship the cards with sunxi-3.4 until we get several drivers into linux-mainline, is that so?
Sincerely, Richard
References:
[1] https://linux-sunxi.org/GPIO [2] http://rhombus-tech.net/allwinner_a10/testing/
Hi richard on phone brief. Yes 3.4, different, uses module config, works fine. Talk to phil about ikiwiki itsvon his server
On Friday, May 11, 2018, Richard Wilbur richard.wilbur@gmail.com wrote:
First, in adding the link to the sunxi wiki page documenting GPIO access on Allwinner chips[1] to the rhombus-tech.net "Testing" wiki page[2], I again triggered the "An error occurred while writing CGI reply" page delivered at URL: http://rhombus-tech.net/cgi-bin/rhombus/ikiwiki.cgi
I clicked the "Save" button after editting the ikiwiki code and just waited for it to return.
Second, the linux-sunxi wiki page refers to the interaction with the GPIO driver differently depending on whether using linux-mainline or sunxi-3.4 kernel. If memory serves it seems you mentioned we plan to ship the cards with sunxi-3.4 until we get several drivers into linux-mainline, is that so?
Sincerely, Richard
References:
[1] https://linux-sunxi.org/GPIO [2] http://rhombus-tech.net/allwinner_a10/testing/ _______________________________________________ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
On Sat, May 12, 2018 at 5:27 AM, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
Hi richard on phone brief. Yes 3.4, different, uses module config, works fine.
Thanks for the response. What I'm wondering is what the boot image/partition has for 'script.bin' because under kernel 3.4 that defines the set of GPIO pins that will be enabled at boot and their initial state. (Looks like it determines the initial state of all the pin multiplexors.) Probably more easily interpreted in the FEX form (human-readable text), albeit larger.
Talk to phil about ikiwiki itsvon his server
Thanks for the referral. Took it up with him separately.
Look up sunxi-tools fex2bin bin2fex and wiki sunxi fex.
On Monday, May 14, 2018, Richard Wilbur richard.wilbur@gmail.com wrote:
On Sat, May 12, 2018 at 5:27 AM, Luke Kenneth Casson Leighton < lkcl@lkcl.net> wrote:
Hi richard on phone brief. Yes 3.4, different, uses module config, works fine.
Thanks for the response. What I'm wondering is what the boot image/partition has for 'script.bin' because under kernel 3.4 that defines the set of GPIO pins that will be enabled at boot and their initial state. (Looks like it determines the initial state of all the pin multiplexors.) Probably more easily interpreted in the FEX form (human-readable text), albeit larger.
Talk to phil about ikiwiki itsvon his server
Thanks for the referral. Took it up with him separately. _______________________________________________ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
On May 14, 2018, at 12:24, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
Look up sunxi-tools fex2bin bin2fex and wiki sunxi fex.
I did look up and read some about those topics--and I will read more!
What I'm wondering is what does the script.bin configure presently at boot? Then I can figure out whether we need to change it in order to be able to test the GPIO pins. With sunxi 3.4 kernel it looks like whatever we have configured in script.bin is what we have to work with on that load of the gpio-sunxi kernel module so I'm interested in making sure the GPIO pins we want to test are configured into the /sys/class/gpio namespace, and at what names they appear.
I read in the sunxi GPIO wiki page[1] that script.bin can specify the mapping between the GPIO number NNN and PORT:BIT that determines the sysfs name /sys/class/gpio/gpioNNN_PORTBIT brought about by sudo echo NNN >/sys/class/gpio/export # A request to export control over gpio mapping NNN (as defined in script.bin) from kernel space to user space.
So, to track down the pins we want, we need to know the mapping that is currently in script.bin (or specify it ourselves).
There is a scheme outlined in the sunxi GPIO wiki page[1] for associating the numbers NNN with PORT:BIT that is followed on the A20/PIO page[2] and seems useful as it is consistent and reversible. So if we haven't already created a version of script.bin (for the sunxi-gpio module) that maps the A20's Programmable Input/Output pins for the DS113 card, I'd recommend we follow that scheme.
NNN := (PORT - 'A') * 32 + BIT
PORT:BIT NNN sysfs PI11 267 gpio267_pi11 PI10 266 gpio266_pi10 PI13 269 gpio269_pi13 PI12 268 gpio268_pi12 PI3 259 gpio259_pi3 PB4 36 gpio36_pb4 PH0 224 gpio224_ph0 PB3 35 gpio35_pb3
References:
[1] https://linux-sunxi.org/GPIO [2] https://linux-sunxi.org/A20/PIO
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Tue, May 15, 2018 at 9:14 PM, Richard Wilbur richard.wilbur@gmail.com wrote:
On May 14, 2018, at 12:24, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
Look up sunxi-tools fex2bin bin2fex and wiki sunxi fex.
I did look up and read some about those topics--and I will read more!
What I'm wondering is what does the script.bin configure presently at boot?
whatever you ask it to. it's the exact analogous equivalent of device-tree.
Then I can figure out whether we need to change it in order to be able to test the GPIO pins. With sunxi 3.4 kernel it looks like whatever we have configured in script.bin is what we have to work with on that load of the gpio-sunxi kernel module so I'm interested in making sure the GPIO pins we want to test are configured into the /sys/class/gpio namespace, and at what names they appear.
I read in the sunxi GPIO wiki page[1] that script.bin can specify the mapping between the GPIO number NNN and PORT:BIT that determines the sysfs name /sys/class/gpio/gpioNNN_PORTBIT brought about by sudo echo NNN >/sys/class/gpio/export # A request to export control over gpio mapping NNN (as defined in script.bin) from kernel space to user space.
yep.
So, to track down the pins we want, we need to know the mapping that is currently in script.bin (or specify it ourselves).
yyep. that means looking at the schematic DS113 PDF (oh, you have the A20 pin names already don't you?), so just... drop those into the fex gpio section, and as long as CONFIG_SUNXI_GPIO is enabled on kernel compiles they'll get dropped into /sys/class/gpio as expected.
There is a scheme outlined in the sunxi GPIO wiki page[1] for associating the numbers NNN with PORT:BIT that is followed on the A20/PIO page[2] and seems useful as it is consistent and reversible. So if we haven't already created a version of script.bin (for the sunxi-gpio module) that maps the A20's Programmable Input/Output pins for the DS113 card, I'd recommend we follow that scheme.
NNN := (PORT - 'A') * 32 + BIT
PORT:BIT NNN sysfs PI11 267 gpio267_pi11 PI10 266 gpio266_pi10 PI13 269 gpio269_pi13 PI12 268 gpio268_pi12 PI3 259 gpio259_pi3 PB4 36 gpio36_pb4 PH0 224 gpio224_ph0 PB3 35 gpio35_pb3
ok - hum i need to send you that card, don't i. you'll be able to try this out.
l.
On Tue, May 15, 2018 at 2:30 PM, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
ok - hum i need to send you that card, don't i. you'll be able to try this out.
Sure, the card would be lovely. Then I could work on some other stuff, too. Like DDC over I2C over GPIO for VESA monitor detection on the VGA port.
Even before you have a chance to send the card I'd be able to make some progress given a place I could download a copy of the current script.bin you are using (I'd be willing to try and download the sunxi-tools bin2fex and fex2bin and run them on this x86_64 machine) or script.fex (which is reportedly human-readable text).
Is there a
On May 16, 2018, at 11:39, Richard Wilbur richard.wilbur@gmail.com wrote:
Is there a
place I can download the install image (boot image) you are presently using on the DS113 A20 cards?
(Accidentally hit send before I finished the sentence. A less than satisfying user experience on this phone, but at least I can interact in my present physical context.)
Richard
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Wed, May 16, 2018 at 6:46 PM, Richard Wilbur richard.wilbur@gmail.com wrote:
On May 16, 2018, at 11:39, Richard Wilbur richard.wilbur@gmail.com wrote:
Is there a
place I can download the install image (boot image) you are presently using on the DS113 A20 cards?
grab or make quite literally any debian image and you have the rootfs. you should be able to make one with qemu, what i do is create a *RAW* file (not a qcow) then mount that, and then of course you can either dd it directly to a microsd card after shutting qemu down or you can get access to it via loopback (losetup).
the VFAT partition which includes u-boot i have a version here: http://hands.com/~lkcl/partition1.tgz
it's quite old, but should still be functional.
i'm on the move at the moment so i don't have the stack of microsd cards with me that contain all the (various) OSes.
how to set up a microsd card:
http://rhombus-tech.net/allwinner_a10/a10_mmc_boot/
l.
Luke, thanks for the links and the instructions. I'll study them further when I get home this evening (bigger screen and keyboard!).
Richard
arm-netbook@lists.phcomp.co.uk
-
Luke Kenneth Casson Leighton -
Richard Wilbur