On 21.10.20 23:54, Ed W wrote: Hi, > OK, I've just sent a new patch which conditionally configures GPIOs for boards with older firmware's > (older than 4.10.0). as mentioned in my reply to it: still breaks existing userlands as device names and keycodes change. userland would need to become dependent on bios version. Exactly one of those kind of instability we do NOT want. Remember: these boards are used for embedded applications - an area where we do not have any operator and need a very high level of stability (sending a technician costs 10x the price of the board). > This is followed up by the patch I really want to try and get in, which is to add support for APU5 > and APU6. Particularly APU5 is quite interesting to me and significantly different to previous > boards in that it has a lot more mpcie slots that can be used for LTE modules or wifi cards. Okay, why not just treating them differently ? Personally, I don't have an apu5, so can't tell much of them yet. But if they're so different, I can live with those having different names / keycode, assuming all this stuff is already supported by the lowest BIOS version they've ever been shipped with (remember: requirement of BIOS upgrade in the field is also not an option). Can you please check whether that's the case ? In that case we don't need any per bios-version special magic, just another entry in the DMI match table and separate board structs. For the mpcie reset lines we really should consider using the reset controller framework or add it to pci core (so pci_bus drivers also expose it to sysfs, in order to let userland trigger it). Tricky part is letting the board driver attach the reset functionality to the generic pci_bus driver. (grmpf, it wasn't ugly acpi, but dt instead, this would be pretty trivial via dt-overlay :o). > This > creates the realisation that the reset and sim-swap lines are always wired to the LTE slots, not to > the mpcie slots (although often they overlap in functionality), so naming is corrected here. Sorry, but i'm confused. What's the actual difference between mpcie and LTE slots ? What is an LTE slot anyways ? Are you talking about the USB lanes on the M2 slot ? Does anybody happen to have the FULL M2 spec available ? According to the pinouts i've found, the reset line is dedicated to PCIE, but perhaps we should treat it as "card reset" - IOW the whole card resets, no matter which channels (sata, pcie, usb, ...) it is actually using. If that's the case, maybe we should reconsider the whole bus topology, perhaps introduce an pseudo bus for representing the m2 connector, which has the corresponding pcie/sata/usb/... ports as childs. (I'm going to ask the corresponding bus maintainers for their oppinions) > That > said, I don't think the reset lines function on most iterations of boards, so possibly supporting > those lines with GPIOs is redundant anyway... My observation (on apu2/3/4) is that it seems to dependend on the cards, eg. one baseband I've testing did the reset (sometimes even needs on after poweron), another one just seemed to ignore it. Both were running via USB. No idea, whether that also depends on BIOS version ... > I don't know if it's useful, but I uploaded a couple of scripts for beeping and flashing the leds. > Here I just used globs to handle the different naming on the different boards (since I need to > handle the older Alix boards as well). Enrico, is this useful to you? > > https://github.com/nippynetworks/gpio-utils The swap_sim script illustrates a good point, that I resisted to think about: sim swapping needs extra, baseband specific logic, to make it actually work :( So, I'm still unsure whether this stuff should go into a separate portmux subsystem or an extended rfkill (where the basebands have to be put into) ... both options still a lot of work to do. > As an aside, these boards are super easy to flash as they support flashrom. Easy in the lab. But not in the field - if *anything* goes wrong, technician needs to fly out - several k$ plus days of downtime, until the technician reaches the place. Let me rephrase this again: embedded devices, litterally in the field. For kernel and userland, we already have good ways to handle redundancy (automatic rescue boot in bootloader, serial console, wdt, ...), but for the BIOS we don't have that. > The generic bios is quite slow to startup and I would like to prepare > a customised version with shorter timeouts. Happy to work with > you on something separately if this is interesting? Actually, I already planned an actual factory setup for these boxes, which includes the whole process, hw testing, bios deployment, OS/application deployment, etc, etc. Unfortunately, this is lots of work to do (has to be someting that arbitrary field technicians, who aren't sw engineers, can actually do on their own). Tried to get some sponsoring from pcengines, but they don't even seems to be interested in an arranging simple things like LED names. Damn, I'm really unhappy with these folks - we could have prevented much of this whole mess if they would talked to me (they know that I'm the apu-board kernel maintainer) :( Let's try summarize the current state of knowledge: * apu2..4: * BIOS support highly depends on BIOS version, we need to support older versions. * Field depends on on driver's naming, keycodes, ... * apu5/6: * no known field-users that depend on the driver's naming scheme yet, (actually not supported yet) - we possibly could tolerate change in naming * assuming that all boards in the field already have recent enough BIOS that support LEDs and keys * suggestion: only implement the missing parts (eg. dont instantiate LEDs/Keys for them) - need to make sure there's no conflict with acpi-instantiated gpios, or grab these instead * mpcie-reset: * no known field-users that depend on that - only has been used as debug tool and mapping to LEDs declared as temporary solution (planned to move it to reset controller subsystem or into pci subsystem) * therefore: userland API changes acceptable * open question: * do these lines actually belong to pcie or to the whole m2 card (which might not even use pcie, instead usb or sata) ? * shall we have a separate (pseudo)bus for m2, which controls these lines ? * do we need per-card special handlings (timing, ...) ? * simsw: * similar to mpcie-reset (still experimental, ...) ... * seems to be really bound to M2 ports Proposal: * introduce M2 (pseudo-)bus for modelling M2 ports + functionality * per-port reset lines (considered "card reset" instead of just pcie reset) * sim switch functionality * exposes switch/reset functionality via sysfs to userland * possibly publishes extra card information (if available) * linking to actual bus'es (currently active) on the card, which come from different subsystems (pci, usb, ...) I'm going to write a small proposal for this new m2-port subsystem, an post it @lkml. --mtx -- --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info@xxxxxxxxx -- +49-151-27565287
