On Sat, Jan 20, 2018 at 5:26 AM, Richard Wilbur richard.wilbur@gmail.com wrote:

Having taken a closer look I did find an equivalence mapping:

yeah this is a pain in the ass. the person who did the work 5 years ago, after i EXPLICITLY sent them a schematic that had the correct mapping, COMPLETELY fucking well ignored it and changed it from a 1, 2, 3 .... 68 mapping to a 1, 35, 2, 36 ... mapping.

fucking idiots.

anyway it's meant that i've had to ignore the pin numbers in the schematic and go by pin positions. about 2 years ago i worked out a trick which wouldn't screw with the PCB layout: adding a SECOND connector, in position on top of the existing one, manually connecting the tracks and then deleting the old one with the wrong pinouts.

the reason it has to be done that way is because if you *remove* the [older, wrong] connector PADS rips up the fucking tracks, right the way back to the damn processor pins. so i left it for 3 years until i had worked out / learned a technique to avoid that happening.

*sigh*....

--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Tue, Jan 23, 2018 at 7:40 AM, Richard Wilbur richard.wilbur@gmail.com wrote:

On Sat, Jan 20, 2018 at 12:01 AM, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:

...

anyway it's meant that i've had to ignore the pin numbers in the schematic and go by pin positions. [...] so i left it for 3 years until i had worked out / learned a technique to avoid that happening.

I'm sorry to hear it has been such a thorn in the side!

ehn i got used to it.

I went and read the EOMA68 specification since, as you mentioned, it is normative.

cool.

I then tried to update the testing wiki page and it didn't seem to want to save my changes.

that's happened occasionally in the past. i've done a manual rebuild.

I saved them off locally here so I can try to figure out the problem and then reapply the changes.

git log compared to "Recent Changes" showed that there were 4 revisions that hadn't been applied.

did you get at any point a failure of the "page updated" thing or at any point interrupt the cgi script whilst it was rebuilding the page? ikiwiki works by generating static HTML using cgi-bin perl scripts that pull markdown (etc.) out of the git repository. it can be... a little fragile.

l.

--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Tue, Jan 23, 2018 at 10:40 AM, Richard Wilbur richard.wilbur@gmail.com wrote:

I got an error message that said there had been a failure of the CGI script--I don't remember the exact wording. If I did interrupt something I'm not sure how I accomplished that as I was trying to be patient and wait till it was done before initiating anything new.

if it happens again please take a screenshot, it's important as it means there's a bug in ikiwiki that is essential to report and get fixed.

l.

On Tue, Jan 23, 2018 at 11:23 AM, Richard Wilbur richard.wilbur@gmail.com wrote:

By the way, do you happen to know in what language ikiwiki is written?

perl. *gibber, shake*. luckily it was written by an absolute genius who actually cares and is like... really responsible. otherwise ikiwiki would be a dog's dinner.

l.

On Fri, Jan 26, 2018 at 12:43 PM, Richard Wilbur richard.wilbur@gmail.com wrote: [...]

I added some more details and selected "Save" and after awhile my browser came back with a page that says only: "An error occurred while writing CGI reply"

I don't know whether this is a cause of the error but I had forgotten to type anything in the comment section. If that causes problems, sounds like it would be a fine candidate for input data validation.

--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Wed, Feb 28, 2018 at 9:09 PM, Richard Wilbur richard.wilbur@gmail.com wrote:

After realizing that you mentioned all 8 GPIO lines were on the 20-pin expansion header J5 in the microdesktop case, I consulted the microdesktop schematic for clues.

I suspect the UART and EOMA I2C pins should be left to those functions.

yehyeh. UART implicitly tested "if console works it's probably good" and I2C with a bus scan, i2c-utils, if 0x51 EEPROM shows up, it's good.

I have added tables to the "Testing"[*] page under the "GPIO" section with my nominations for which pins to test and their mapping back to A20 register bits.

awesome. it'll have to be done manually for now,

Luke, does this match your understanding of the GPIO pins to test?

yep - GPIO_19,20,21 missing.

Reference: [*] http://rhombus-tech.net/allwinner_a10/testing

hey that looks great!

--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Thu, Mar 1, 2018 at 8:33 PM, Richard Wilbur richard.wilbur@gmail.com wrote:

On Wed, Feb 28, 2018 at 2:41 PM, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:

...

On Wed, Feb 28, 2018 at 9:09 PM, Richard Wilbur richard.wilbur@gmail.com wrote:

...

After realizing that you mentioned all 8 GPIO lines were on the 20-pin expansion header J5 in the microdesktop case, I consulted the microdesktop schematic for clues.

I suspect the UART and EOMA I2C pins should be left to those functions.

yehyeh. UART implicitly tested "if console works it's probably good" and I2C with a bus scan, i2c-utils, if 0x51 EEPROM shows up, it's good.

...

I have added tables to the "Testing"[*] page under the "GPIO" section with my nominations for which pins to test and their mapping back to A20 register bits.

awesome. it'll have to be done manually for now,

Are you suggesting that the testing "will have to be done manually"?

the mapping created manually. sorry, i was thinking in terms of device-tree fragments... which don't exist yet.

What is the time frame of "for now"?

when testing is required.

I'm trying to figure out which pins of the expansion header we want to test, which pins of the processor those correspond to, and thus which registers and bits of those registers we need to manipulate. That determines how I need to interact with the GPIO driver.

yehyeh. and determining that interaction "has to be done manually". if the devicetree fragment existed it would be a much simpler matter.

...

...

Luke, does this match your understanding of the GPIO pins to test?

yep - GPIO_19,20,21 missing.

In the following table (created while I was trying to figure out which GPIO were connected in the EOMA standard) you will see that EOMA nets GPIO(18)/EINT3, GPIO(19), GPIO(20), and GPIO(21) are not connected on the microdesktop schematic v1.7 from J14. Thus they are at J14 but not available anywhere else in the microdesktop v1.7.

yep, forgot that. why the heck did i leave them out?? duur...

1342 Fri 23 Feb 2018: EOMA A20 DS113 microdesktop Net Name ball register CON15 pin J14 pin PWM B19 PI3 43 22 GPIO(10) EINT0 A6 PH0 63 32 GPIO(11) EINT1 B6 PH1 17 9 GPIO(16) EINT2 B2 PH14 44 56 PWFBOUT GPIO(17) EINT3 C2 PH18 39 20 NC GPIO(18) GPIO(19) A1 PH15 40 54 NC GPIO(20) C1 PH17 41 21 NC GPIO(21) B1 PH16 42 55 NC

We could obviously create a v1.8 schematic for the microdesktop and connect these EOMA nets to a header, if desired.

yes. damn. i think it's probably that i didn't update the micro-desktop schematic when i changed the EOMA68 spec from 24-pin to 18-pin RGB/TTL.

l.

It looks to me like the fastest way to test the GPIO lines connected on the micro-desktop board to VESA_SCL and VESA_SDA would simply be to connect a VGA monitor to the micro-desktop and make sure it is properly detected and a test image looks right on it. This would leave 6 GPIO lines to test. So we get better test coverage for the EOMA interface and shorter GPIO test at the same time!

On Thu, Mar 1, 2018 at 2:54 PM, Christopher Havel laserhawk64@gmail.com wrote:

Oh LOL.

VGA is analog, and has six wires for color (red signal, red ground, ditto each for blue and green). It's not /exactly/ serial (serial as I understand it is inherently digital, which VGA is *ahem* very much not) but the paradigm sort of fits. RGBTTL is parallel. You have one wire per bit of color. So that's 18 wires. Plus your sync lines... which may or may not match VGA signal standards, I'm not sure.

If you actually manage to figure out how to get that hooked up correclty, let me know ;)

(Hint, it's doable, but you need additional components. There's a cheap way, and there's an easy way, and they are two *very* different ways...)

Looking at the micro-desktop schematic it seems Luke has this issue well in hand. Christopher have you seen the micro-desktop schematic? The VGA conversion is on page 3.

Luke, have you tested the D/A circuit on the micro-desktop board? Only thing I would worry about is the hold time on the data lines. If the A20 sets up the data quickly (relative to the pixel time) and holds it until the next setup, we should be in good shape.

Much easier suggestion: get a small LCD. *ANY* small LCD. Like a five or seven inch display at the largest. Raw panel, no driver board. Get the datasheet and a compatible connector. (If you source from eBay this is very easy; those are almost all commodity displays with available datasheets.) If it's a SMALL DISPLAY it *will* be RGBTTL, 90%+ of the time (I've seen one exception to this ever and it was in an off-brand portable DVD player). Wire it up. Wire it to the card connector. Add power. If you get a screen that works, you've done it right.

I think this is why Luke put the display signals on the EOMA68 standard in the RGBTTL format--to simplify the job of connecting to LCD's. (I'm thinking of the laptop, tablet, gaming console, phone, etc.)

btw i'm tempted to suggest treating the SPI pins as straight GPIO. if they can do 0 and 1 (input and output) then they're not short-circuited and/or disconnected and that's... good enough.

l.

On Mar 1, 2018, at 20:40, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:

On Thu, Mar 1, 2018 at 10:42 PM, Richard Wilbur richard.wilbur@gmail.com wrote:

...

Luke, have you tested the D/A circuit on the micro-desktop board?

yep it works great up to 1024x768. i haven't yet been able to get it to sync at anything greater than that, because you have to manually convert the signals into A20 timings... and of course if you can't read the EDID data you don't know *exactly* what the settings are in the first place for any given monitor.

1024x768, being a common VESA standard, has worked consistently on every monitor i've tried.

So if we could read the EDID the driver would figure out the A20 timings? Does the A20 already have a graphics driver capable of that? (In which case the bit-banging VESA DDC driver becomes very important.) How much of this infrastructure already exists? I'm bringing my tools, where do we start building?

I have a collection of VGA monitors with different aspect ratios and sizes (3 CRT and 3 LCD). I'd be happy to test resolutions above and below 1024x768.

...

Only thing I would worry about is the hold time on the data lines. If the A20 sets up the data quickly (relative to the pixel time) and holds it until the next setup, we should be in good shape.

sigh yeah i thought about that... using buffer ICs with a "hold", and linking up the clock line to it.... never got round to it. i'd prefer to just skip the entire circuit and use a TFP410 (or maybe it's a TFP401a), or a Chrontel RGB/TTL to VGA converter IC. CH7036 i think it is.

Are you thinking of octal D flip-flops? I'll have to look up those datasheets. What do those chips offer over the flip-flops? How do the prices compare?

[…]

yyup. exactly. remember, you can't do more than one interface on any given set of pins, so i had to pick one (RGB/TTL or LVDS or MIPI or eDP), that then means you have to have a conversion IC in-place on the Card if a particular SoC doesn't *have* that interface... and many of the lower-cost SoCs don't because they're not part of the MIPI or DisplayPort cartel(s)....

Yes, that's the awful thing about so many industry standards: you can't get the text without signing documents and paying a handsome price, you can't use them without paying royalties to the patent owners.

... and even if you had LVDS, the cost on the other side (Housing side) of having an LVDS-to-RGB/TTL converter is so high relative to the cost of the LCD itself that companies would rebel and not bother with the standard at all.

so, bizarrely, RGB/TTL, by being both "free" and also unencumbered by patents *and* by being lowest-common-denominator, wins out on all fronts. except for the fact that you need a 125mhz clock-rate for 1920x1080@60fps, which is a bit... high. but hey.

Will the A20 clock the RGBTTL interface that high?

If we did decide to roll a v1.8 micro-desktop board, it would afford us the opportunity to bring two of the presently unconnected GPIO18-21 lines to the expansion header in place of VESA_SCL and VESA_SDA (which are after all available on pins 15 and 12 of the VGA connector). If VESA_SCL and VESA_SDA are more useful on the expansion header then, by all means, forget this suggestion.

The other option to accommodate all our GPIO goodness would be to replace J5 (2x10 header) with a 2x11 or 2x12 header allowing us to bring all the GPIO pins to the expansion header (the only difference being whether we would prefer to retain VESA_SCL and VESA_SDA in the header).

On Thu, Mar 1, 2018 at 3:05 PM, Christopher Havel laserhawk64@gmail.com wrote:

...BTW, those SCL and SDA lines on a VGA connector are for a nifty signal coming from your monitor. It's called EDID and it's basically how every modern OS magically knows what to do with the monitor it wants to display on, regardless of the specs or origin of said monitor.

If you've ever had a cheap VGA cable where all the pins are present on the connectors but those two lines are disconnected internally, you have experience with what happens when you eff with those wires. Best to leave them alone!

Christopher, you are quite correct about the usefullness of untarnished VESA EDID. Turns out I've worked with it before and respect its utility with respect to VGA/DVI/HDMI monitors.

We are simply talking about how to test the DS-113 EOMA68-A20 processor cards when they come to the end of the assembly line. In that regard, our discussion is mainly about how to create a test jig/fixture that has the most complete coverage of the signals available on the EOMA68 interface and some of the possible use scenarios. We also have an interest in time efficiency as a matter of economy.

On Thu, Mar 1, 2018 at 4:12 PM, Christopher Havel laserhawk64@gmail.com wrote:

I /designed/ that circuitry in the micro-desktop. I still have the paper copy somewhere...

Very nice!

You can also do it with a dedicated DAC chip, which is the easy-but-expensive way I hinted at.

But we aren't testing /that/ part -- the micro-desktop -- are we? If we're testing the /card/, the card does not output anything remotely like VGA, and, therefore, some kind of conversion is necessary in order to attach it to a VGA cable as was being proposed in the email I replied to about that.

We aren't planning to test the micro-desktop. The planning is for tests of the card mounted in a micro-desktop case to use as a test fixture. We are planning to use your good work on the micro-desktop case to our advantage and connect the VGA cable to the micro-desktop VGA connector in order to see that the EOMA68 RGBTTL (with EDID) works as advertised!

All you really need for this is a laptop PCMCIA or CardBus card cage, an IDE cable or two, a couple 4051s and toggle switches on a slice of perfboard, a 9v battery with connector and switch, and a cheap USB logic analyzer attached to a laptop. You use the 4051s, switched manually, and powered by the 9v battery, to act as input expanders for the logic analyzer. Each 4015 turns one channel into eight and requires three "on-on" switches -- with one "on" wired to +9v, one to ground, and the common to the chip. You use the IDE cable for the wires ;) If you hook it up so that you have one 4051 mux per logic analyzer channel, that'll give you 128 (!) channels to switch with -- most USB logic analyzers, even the super cheap ones, are 16-channel...

Heck, if you wanted to make the circuit "complicated" -- I could draw up something that automatically iterated through the channels for you at the press of a single button, switching at variable speed with a pot, a 555, a resistor and cap, and a couple 4017s and 4051s. You'd only need /one/ channel for that -- so you could even use an o-scope there. Heck, I could do it with that circuit and my old, old Tektronix 422...

I'm honestly surprised that this sort of idea hasn't been mentioned yet.

That is a cool way to set up a very wide logic analyzer. We were planning to use a little specialized hardware and less elbow grease to make our test fixture: * USB devices connected to the micro-desktop case USB ports, * SD peripheral connected to the micro SD slot, * VGA monitor connected to the VGA connector, * serial terminal connected to the UART pins in expansion header

On Thu, Mar 1, 2018 at 5:10 PM, Christopher Havel laserhawk64@gmail.com wrote:

Posting from my phone while making dinner, so forgive that it's a top-post plz.

Testing via the micro desktop works as long as you've got a known good micro desktop and your ports haven't won through. I think the 4051 idea might be a little better - I've worn out USB ports before, just from using them - ask me sometime about my mother's old VAIO laptop and how it ultimately died... the only thing in my test rig to wear out is the card cage...

But, I'm not in charge, so I'll defer.

You make very good points about connector fatigue. I was planning to leave everything connected and only install/remove the EOMA68 card from the micro-desktop case. That works as long as we don't need to test hot-plugging anything. To my knowledge we figured the hot-plug capability would likely be conferred by the applicable standard and thus were designing a basic functionality test.

(Incidentally I have a dead VAIO laptop in which the power jack center pin broke. I really need to get that ordered and replaced.;>)

On Mar 1, 2018, at 17:23, Christopher Havel laserhawk64@gmail.com wrote:

Be careful... it was the replacing of the two ports on that old VGN-S360 that killed it... VAIOs are well known in repair circles for dying of heatstroke from even the slightest rework (and I was duly warned)... if it's a modular jack (on a cable, so no soldering), you'll be fine. If you need an iron... buy a board, not a port. Trust me.

I'll have to open the case and take a look to see what the particulars of the situation are. Thank you for sounding the voice of experience. I consider myself forewarned.

--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Thu, Mar 1, 2018 at 10:02 PM, Richard Wilbur richard.wilbur@gmail.com wrote:

If we did decide to roll a v1.8 micro-desktop board, it would afford us the opportunity to bring two of the presently unconnected GPIO18-21 lines to the expansion header in place of VESA_SCL and VESA_SDA (which are after all available on pins 15 and 12 of the VGA connector). If VESA_SCL and VESA_SDA are more useful on the expansion header then, by all means, forget this suggestion.

the reason i brought those out is just in case someone decided they wanted to use them as plain GPIO.

The other option to accommodate all our GPIO goodness would be to replace J5 (2x10 header) with a 2x11 or 2x12 header

yep.

allowing us to bring all the GPIO pins to the expansion header (the only difference being whether we would prefer to retain VESA_SCL and VESA_SDA in the header).

yes.

l.

--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Thu, Mar 1, 2018 at 9:46 PM, Richard Wilbur richard.wilbur@gmail.com wrote:

It looks to me like the fastest way to test the GPIO lines connected on the micro-desktop board to VESA_SCL and VESA_SDA would simply be to connect a VGA monitor to the micro-desktop and make sure it is properly detected and a test image looks right on it.

yep, pretty much... with one slight fly in the ointment: the SCL and SDA lines are straight GPIO and will need a bit-banging I2C linux kernel driver. once that's configured, doing i2cdetect _should_ be enough to test the circuit, although scanning the data and running read-edid on it would be awesome and amazing: it would mean being able to *really* do proper VESA detection.

l.

Hello,

On Fri, Mar 02, 2018 at 03:26:32PM -0700, Richard Wilbur wrote:

On Mar 1, 2018, at 20:30, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:

Sent from my iPhone

...

On Thu, Mar 1, 2018 at 9:46 PM, Richard Wilbur richard.wilbur@gmail.com wrote:

...

It looks to me like the fastest way to test the GPIO lines connected on the micro-desktop board to VESA_SCL and VESA_SDA would simply be to connect a VGA monitor to the micro-desktop and make sure it is properly detected and a test image looks right on it.

yep, pretty much... with one slight fly in the ointment: the SCL and SDA lines are straight GPIO and will need a bit-banging I2C linux kernel driver. once that's configured, doing i2cdetect _should_ be enough to test the circuit, although scanning the data and running read-edid on it would be awesome and amazing: it would mean being able to *really* do proper VESA detection.

Is someone already working on that? Sounds like we need the device tree for the micro-desktop to be populated. If we did it for micro-desktop v1.7 it would be something to build off for micro-desktop v1.8 and also a good place to begin for the laptop.

I'm not actively working on any of this, but I'm interested in the devicetree side of things.

From what I'm hearing, once the device tree is ready we could work on "automagically" configuring the VESA DDC driver to bit-bang the correct GPIO pins. Does the bit-banging VESA DDC driver exist already? (I wrote a bit-banging I2C driver in VxWorks at a previous position so the topic is not foreign.)

Mainline Linux has a driver[1] for I2C-over-GPIO. It's been there since 2.6.22, albeit initially without devicetree support, which came in 3.4.

There's also a generic devicetree binding[2] for I2C-over-GPIO in Linux's Documentation/devicetree/bindings directory.

If none of this is underway I'll continue mapping things out so we can create the device tree for the micro-desktop. If I remember correctly we also should create a device tree for the DS-113 v2.7.4 and v2.7.5?

What is DS-113?

I'd be happy to work on that if you think that is the highest priority right now. It sounds like it will help both testing and deployment.

Thanks, Jonathan Neuschäfer

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/driv... [2]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Docu...

On Sat, Mar 03, 2018 at 01:37:15AM +0000, Luke Kenneth Casson Leighton wrote:

On Fri, Mar 2, 2018 at 10:43 PM, Jonathan Neuschäfer j.neuschaefer@gmx.net wrote:

...

Hello,

...

I'm not actively working on any of this, but I'm interested in the devicetree side of things.

excellent, can you look up the status of A20 and the devicetree fragments?

There has been some work on HDMI on the A10/A20 in October (merged in 4.15): https://www.spinics.net/lists/devicetree/msg198941.html Reportedly, HDMI works now. I'm not sure what else was/is missing.

About DT fragments: I'm not sure what you mean exactly. Mainline support devicetree overlays which should do (half of) the job for EOMA68, though. The tricky part would be figuring out how the same overlay can be used on base devicetrees for different SoCs, as the exposed busses will have different names. This may be solved by a future iteration of this patchset: https://www.spinics.net/lists/kernel/msg2710913.html

The other side of the DT job is the dynamic loading of a devicetree overlay based on the EEPROM of the connected housing. Mainline Linux doesn't have something like capemgr[1], AFAIK; But I think this could also be handled in userspace. And then there's the question of how the kernel/userspace is supposed to know on which i2c bus it finds the EOMA68 EEPROM.

Jonathan

[1]: https://elinux.org/Capemgr

On Sat, Mar 03, 2018 at 03:46:33AM +0000, Luke Kenneth Casson Leighton wrote:

On Sat, Mar 3, 2018 at 2:44 AM, Jonathan Neuschäfer j.neuschaefer@gmx.net wrote:

...

...

About DT fragments: I'm not sure what you mean exactly. Mainline support devicetree overlays which should do (half of) the job for EOMA68, though.

ah, yes, that's the official name. overlays.

question: do you know if they've added the patches to *REMOVE* overlays yet? Cards could potentially be dynamically removed... or at least put into sleep / suspend only to wake up with a totally different Housing.

The whole DT overlay discussion rang a bell somewhere in my brain and now I had time to look it up. I read about a DT overlay hack here: https://joeyh.name/blog/entry/easy-peasy-devicetree-squeezy/ Please read the README for details. Can the above hack be of some use to the EOMA project until "patches to fully support overlays, including loading them on the fly into a running system" are mainlined? I can not answer the question myself because I am not into DT overlays.

It seems we are not the only one with DT overlay problems: https://elinux.org/BeagleBone_and_the_3.8_Kernel#Cape_Manager_and_Device_Tre...

kind regards Pablo

On Sat, Mar 03, 2018 at 03:46:33AM +0000, Luke Kenneth Casson Leighton wrote:

On Sat, Mar 3, 2018 at 2:44 AM, Jonathan Neuschäfer j.neuschaefer@gmx.net wrote:

...

...

excellent, can you look up the status of A20 and the devicetree fragments?

There has been some work on HDMI on the A10/A20 in October (merged in 4.15): https://www.spinics.net/lists/devicetree/msg198941.html Reportedly, HDMI works now. I'm not sure what else was/is missing.

the *full* hardware set is needed. except for NAND, which has been removed from 2.7.5.

I understand.

But I'm not deeply familiar with the A20 and don't have one around for testing, so I don't now how close we are to that goal.

...

About DT fragments: I'm not sure what you mean exactly. Mainline support devicetree overlays which should do (half of) the job for EOMA68, though.

Turns out I was wrong about this. Mainline supports the bare core functionality to apply/unapply DT overlays, but it doesn't expose this functionality to userspace.

ah, yes, that's the official name. overlays.

question: do you know if they've added the patches to *REMOVE* overlays yet? Cards could potentially be dynamically removed... or at least put into sleep / suspend only to wake up with a totally different Housing.

...

The tricky part would be figuring out how the same overlay can be used on base devicetrees for different SoCs, as the exposed busses will have different names.

... i'm not sure what you're referring to, here. do you have an example?

Let's say you have an expansion board that connects to a pair of UART pins and has a bluetooth module on it (simplifying here, because EOMA68 is more complex than necessary for this example).

On A20 you might want to use the UART controller at 0x1c28800 (just an example), which has the label uart2. But on RK3399 you might want to use the UART at 0xff180000, labeled uart0. Now the overlay for A20 would look something like this:

/plugin/; / { ...

fragment@0 { target = <&uart2>; __overlay__ { bluetooth { compatible = "brcm,bcm43438-bt"; max-speed = <921600>; }; }; }; };

But for RK3399, you'd have to change that to target = <&uart0>.

...

This may be solved by a future iteration of this patchset: https://www.spinics.net/lists/kernel/msg2710913.html

there's nothing mentioned about what standard he's referring to. is there a link, or can you do a quick summary?

This snippet? "It would be good to have a way to expose #<list>-cells types of providers through a connector in a standard way." (That's the only occurence of "standard" on that page)

This work is about coming up with a convention (a "standard" in the general sense) to express the remapping of, at first, GPIOs in DT to give them consistent names from the point of view of an expansion interface.

Or did you mean something else by "what standard he's referring to"?

...

The other side of the DT job is the dynamic loading of a devicetree overlay based on the EEPROM of the connected housing.

yes that's correct.

...

Mainline Linux doesn't have something like capemgr[1], AFAIK; But I think this could also be handled in userspace.

it has to be handled in u-boot (at least partially).

Why in u-boot? u-boot won't be around to do something when the card is hot-plugged, right?

...

And then there's the question of how the kernel/userspace is supposed to know on which i2c bus it finds the EOMA68 EEPROM.

good point. the bus utilised will be in the Card's devicetree file: it will have to be named as such.

(Somewhat answering my own question:) I guess there could be something like a DT node that collects all the pieces that go into the EOMA68 interface:

eoma68: connector { compatible = "eoma,eoma68-connector"; gpios = <&gpio0 0 &gpio2 14 ... >; i2c = <&i2c3>; spi = <&spi4>; ... };

And then the overlays could be written to always attach to &eoma68.

Thanks, Jonathan

--- Because it might be of interest to some who aren't familiar with devicetree source syntax, let's go over that example line by line:

eoma68: connector {

A new node is defined. Nodes start with a name and an opening curly bracket. The node is named "connector". Its path would be /.../connector, depending on the names of the outer nodes.

A label "eoma68" points at this node, so the node can be referenced in other places without using the full path.

compatible = "eoma,eoma68-connector";

This is a property of the connector node. It only has a name and a value. Every property and node is terminated with a semicolon.

The "compatible" property tells the OS that the device described by this node is an EOMA68 connector, and allows the right drivers to be selected. The syntax of a "compatible" string is vendor,device.

i2c = <&i2c3>;

This property's value is a "phandle" (property handle). It points at the node with the label "i2c3".

gpios = <&gpio0 0 &gpio2 14 ... >;

In this property, we see pairs of data: A phandle pointing at a GPIO controller, and a plain number, representing the GPIO pin within that GPIO controller.

spi = <&spi4>; ...

More properties.

};

This is the end of the node.

The meaning of all these properties is specified in a devicetree "binding". An example of a DT binding is that of the Allwinner A10's SPI controller, which is also used in the A20: https://www.kernel.org/doc/Documentation/devicetree/bindings/spi/spi-sun4i.t...

There's also a devicetree specification, available at: https://www.devicetree.org/specifications/

On Mar 2, 2018, at 15:43, Jonathan Neuschäfer j.neuschaefer@gmx.net wrote:

...

On Fri, Mar 02, 2018 at 03:26:32PM -0700, Richard Wilbur wrote:

[…]

I'm not actively working on any of this, but I'm interested in the devicetree side of things.

To what does your interest in devicetree extend? Are you interested in helping create the devicetree mappings for EOMA68 hardware, or following developments, etc. How would you like to be involved? Thank you for imparting your knowledge below.

...

From what I'm hearing, once the device tree is ready we could work on "automagically" configuring the VESA DDC driver to bit-bang the correct GPIO pins. Does the bit-banging VESA DDC driver exist already? (I wrote a bit-banging I2C driver in VxWorks at a previous position so the topic is not foreign.)

Mainline Linux has a driver[1] for I2C-over-GPIO. It's been there since 2.6.22, albeit initially without devicetree support, which came in 3.4.

There's also a generic devicetree binding[2] for I2C-over-GPIO in Linux's Documentation/devicetree/bindings directory.

That's wonderful news! So with the devicetree for the micro-desktop we should be able to setup the I2C driver. Next question: has anyone created a VESA DDC driver that will get the EDID from any connected monitor given when given access to an I2C device (as exposed by our bit-banging I2C driver).

VESA DDC is a standard that specifies a protocol on top of I2C for obtaining monitor information (supported resolutions and timings, color gamma, etc.).

...

If none of this is underway I'll continue mapping things out so we can create the device tree for the micro-desktop. If I remember correctly we also should create a device tree for the DS-113 v2.7.4 and v2.7.5?

What is DS-113?

EOMA68-A20 the CPU card.

On Sat, Mar 03, 2018 at 12:11:02AM -0700, Richard Wilbur wrote:

On Mar 2, 2018, at 15:43, Jonathan Neuschäfer j.neuschaefer@gmx.net wrote:

...

...

On Fri, Mar 02, 2018 at 03:26:32PM -0700, Richard Wilbur wrote:

[…]

...

I'm not actively working on any of this, but I'm interested in the devicetree side of things.

To what does your interest in devicetree extend? Are you interested in helping create the devicetree mappings for EOMA68 hardware, or following developments, etc. How would you like to be involved? Thank you for imparting your knowledge below.

Following the development and discussions like this, and offering some input every now and then.

I might also write some small kernel patches.

...

...

From what I'm hearing, once the device tree is ready we could work on "automagically" configuring the VESA DDC driver to bit-bang the correct GPIO pins. Does the bit-banging VESA DDC driver exist already? (I wrote a bit-banging I2C driver in VxWorks at a previous position so the topic is not foreign.)

Mainline Linux has a driver[1] for I2C-over-GPIO. It's been there since 2.6.22, albeit initially without devicetree support, which came in 3.4.

There's also a generic devicetree binding[2] for I2C-over-GPIO in Linux's Documentation/devicetree/bindings directory.

That's wonderful news! So with the devicetree for the micro-desktop we should be able to setup the I2C driver. Next question: has anyone created a VESA DDC driver that will get the EDID from any connected monitor given when given access to an I2C device (as exposed by our bit-banging I2C driver).

VESA DDC is a standard that specifies a protocol on top of I2C for obtaining monitor information (supported resolutions and timings, color gamma, etc.).

...

...

If none of this is underway I'll continue mapping things out so we can create the device tree for the micro-desktop. If I remember correctly we also should create a device tree for the DS-113 v2.7.4 and v2.7.5?

The devicetree for the CPU card should be relatively straight-forward, at least the parts that don't involve the EOMA68 connector.

And for the connector and what's beyond, I see two solutions:

Short-term solution: Write an A20-specific DT snippet, either as an overlay that's loaded by u-boot (this will preclude hot-plug of the card into a different housing).

Long-term solution: Work with the mainline kernel folks to create something that lets us represent SoC-independent connectors properly, and also implement DTo loading based on the config EEPROM.

...

What is DS-113?

EOMA68-A20 the CPU card.

Aaah! Thanks.

Jonathan

On Sat, Mar 3, 2018 at 12:11 AM, Richard Wilbur richard.wilbur@gmail.com wrote:

Has anyone created a VESA DDC driver that will get the EDID from any connected monitor given when given access to an I2C device (as exposed by our bit-banging I2C driver).

VESA DDC is a standard that specifies a protocol on top of I2C for obtaining monitor information (supported resolutions and timings, color gamma, etc.).

Looks like ddcutil[*] provides (reasonably up-to-date) VESA DDC functionality.

Reference:

[*] http://www.ddcutil.com/

Hi Luke,

I have some memory of a request for help in transferring the EOMA standard from the elinux.org site to markdown format (as a step towards publishing it on eoma68.com) but can’t find the exact reference in the mailing list archives. If I’ve remembered that correctly, and it’s something you are looking for help with, I’d be happy to volunteer.

I have some experience with static-site generators (that, as you’d know, use markdown documents as source files), and could assemble something along those lines if you’d like. Here’s a quick mockup of a site for the EOMA standard using the MkDocs engine: https://my.pcloud.com/publink/show?code=kZP6WH7ZvLbZLKwpHaokSVkeG02gqd7dt5wQ... https://my.pcloud.com/publink/show?code=kZP6WH7ZvLbZLKwpHaokSVkeG02gqd7dt5wQxEdk

The present mockup design is based on the assumption that the specifications for all current and future EOMA standards would be housed on the same website (EOMA-26, EOMA-CF, EOMA-68, etc.); this would, I presume, consequently require the use of a more generic domain name (e.g., EOMAstandard.info/.org) instead of EOMA-68.com but obviously I’ll leave the decision about which way to go with you. I can easily change the site design to just cover EOMA-68 should that be your preference.

You’ll notice that I’ve added in some suggested extra pages including: ‘Contribute', ‘About', 'News', and ‘FAQs'. For the ‘Contribute' page, I had in mind suggesting that people could offer technical, marketing, or financial support to the project.

If you’d just prefer the pages in markdown (not assembled as a MkDocs site) I can also just do that, in which case I could just create a collection of individual pages in a flat file structure and leave any internal page links I find as they are.

Cheers, Bluey — P.S. I have noticed that sometimes various versions of the standard (e.g., EOMA-68) are written with a hyphen and sometimes without. I personally feel that the best format would be to include some nominated character to clearly indicate that there are multiple variations of the standard. You could then use a different character to indicate variation according to type of SOC.

For instance, the format might be: EOMA or EOMA-, EOMA-NN, and EOMA-NN:XYZ. Examples would then be...

EOMA or EOMA- EOMA-26, EOMA-68, EOMA-200, etc. EOMA-68:A20, EOMA-68:RISC-V, EOMA-68:RK3399, etc.

OR, swap the colon and hyphens around...

EOMA or EOMA: EOMA:26, EOMA:68, EOMA:200, etc. EOMA:68-A20, EOMA:68-RISC-V, EOMA:68-RK3399, etc.

OR, use the pipe or other symbol for SOC...

EOMA or EOMA: EOMA:26, EOMA:68, EOMA:200, etc. EOMA:68|A20, EOMA:68|RISC-V, EOMA:68|RK3399, etc.

EOMA or EOMA: EOMA:26, EOMA:68, EOMA:200, etc. EOMA:68~A20, EOMA:68~RISC-V, EOMA:68~RK3399, etc.

oh - no it was a discussion where i assessed and preferred - at the time - that the standard remain (for now) independent and hosted on an independent third party site.

No worries.

whilst i really like the idea of having a special dedicated domain for it, the other problem is, the elinux.org site now has quite a high page-rank for the keyword search "EOMA68". what do you do with the page there? remove it? that would reduce page-rank and cause quite a lot of confusion, suddenly the standard doesn't exist any more?? what's going on??

so the solution i came up with was to simply iframe it.

When/if you decide to move the standard, my suggestion would be to put some text on the existing elinux EOMA pages to say that the standard has moved to a dedicated site. Over time the page ranks would shift over to the new site. There would also be a number of other SEO activities we could do to boost the page ranking once the new site is up.

...

You’ll notice that I’ve added in some suggested extra pages including: ‘Contribute', ‘About', 'News', and ‘FAQs'. For the ‘Contribute' page, I had in mind suggesting that people could offer technical, marketing, or financial support to the project.

i think, these would be great to have on something like eoma68.com where the standard is iframe'd in.

Cool.

the key thing to understand about the standard is that i, as the "Guardian Of The Standard", am NOT PERMITTED to manufacture or in any way compete with people who may wish to be implementors of the standard. i can barely get away with the current campaign by claiming to be a "contracted assistant and advisor on EOMA68 to a sponsor, a commercial company named ThinkPenguin". me personally actually making a PROFIT out of being such an assistant and advisor to ThinkPenguin is an absolute NO.

Sure, I understand. However, I think we can keep it clean/ethical and differentiate between the various projects/teams/individuals easily enough. I would suggest the following financial and donations setup:

- an ‘Individual' liberapay account for you, Luke, as a libre developer (this is already in place at https://liberapay.com/lkcl/ https://liberapay.com/lkcl/);

- a ‘Team' liberapay account for EOMA standard* development, web hosting, and administration (including a percentage of money as wages for those working on the standard); and

- in addition to any money earned through Crowd Supply, an ‘Organisation’ or ‘Team’ liberapay account for Earth-friendly Computers that is managed by its sponsor, ThinkPenguin, with money directed to the project as the sponsor sees fit or that it explicitly specifies upfront. This might involve using the money to pay, for example, for equipment, raw materials, employee wages, marketing, or contracted assistants and advisors).

* Note, for this 2nd item, that it seems reasonable to me that developing a standard takes legitimate resources that include website hosting, equipment, and time. To me, that’s not profit. Although ISO, IEC, etc. are commercial entities, some of the money they make goes to paying for those standards to be developed plus any and all employee and administrative costs.

Essentially, I think of the EOMA standards project—in all but name—as a non-profit organisation that has operating costs.

...

P.S. I have noticed that sometimes various versions of the standard (e.g., EOMA-68) are written with a hyphen and sometimes without.

this was discussed 2 years ago. the glossary section explains it. the hyphen is *NOT* correct. if you find any location which says "EOMA-NN" please let me know and i will correct it.

Okay, no worries.

To start with, I think most of the pages on elinux.org need reviewing, for example: https://elinux.org/Embedded_Open_Modular_Architecture https://elinux.org/Embedded_Open_Modular_Architecture (search for 'EOMA-‘ and you should find 7 matches)

Plus all of the pages for the individual standards (EOMA-68, EOMA-200, etc.)

The Crowd Supply site looks good. I found just two references to EOMA-68 (one on the front page referenced from an external review) plus one in the title of an update from 2016.

Your liberapay page is fine: https://liberapay.com/lkcl/ https://liberapay.com/lkcl/

There are various references on the Rhombus-Tech site if you put ‘EOMA-‘ in the search box.

I’m not across any other sites you might have for the project, sorry.

Cheers, Bluey