TonyMac32

@Neil Armstrong I get gpiochip0: GPIOs 0-9, parent: platform/c8100000.aobus:pinctrl@14, aobus-banks: gpio-2 ( |librecomputer:blue ) out lo gpio-3 ( |? ) out lo gpiochip1: GPIOs 10-110, parent: platform/c8834000.periphs:pinctrl@4b0, periphs-banks: gpio-29 ( |HDMI_5V ) out lo gpio-45 ( |reset ) out lo gpio-58 ( |cd ) in lo gpio-83 ( |librecomputer:system) out hi from/sys/kernel/debug/gpio Thanks again, for the quick reply.

Right. I just couldn't find the entries, truthfully I wasn't certain where to look. Thanks Neil for giving direction so quickly. I'll take a look after bit, at the moment installing curtains for the wife... ;-) Sent from my Pixel using Tapatalk

Yes, the device tree has a comma delimited table in it with the names, but that means they should exist in the kernel somewhere, I haven't spent enough time trying to find them. Maybe I should just ask @Neil Armstrong to fill in for my lack of knowledge whenever he has a free moment. (Obviously he is quite busy doing the real work, so don't expect anything/anything soon)

Good question, I have quite lost track of that work in the last few weeks. That is, of course for mainline, but will be relevant to this project.

That is the goal. I have 2 things on my list of "has to work" and 1 on the "should work" before we roll out a new image: Audio is a must and the Mali permissions. The Bluetooth situation is complicated by the Rockchip rfkill stuff, for some reason the simple service that works on other boards with rtl8723bs does not work at all on this one. If it doesn't work properly with a few adjustments I will leave it as it is.

Good, I haven't had time to try it yet, on the list for today. Then figuring out how far I can integrate it. I'm going over the documentation to see, I know there are extra packages installed for sun*i mali, I'd ideally want to do that. @zador.blood.stained and @Igor are the wizards that maintain the build system itself, I only work within it on board support, and haven't had much experience with the more advanced parts. I will at least get the permissions sorted today so the level 0 instruction is unnecessary.

This is something I haven't quite figured out either. The potato device tree assigned a user-friendly name to each pin, however for the life of me I can't find it in the device listing.

Yeah, oddly it looks like 3V0, which I believe falls within the required range. That said, scratching brain to remember if VDD is constant at 3.3 Volts and only the signalling voltage changes (SD_CLK, SD_CMD, Data_0..3). In that case it would be switched at the SoC.

I can only assume it will be more than the Tinker [Classic?]. The eMMC alone would probably push them to ~$80 (I think I saw that number on another site as well), so yes, I would be concerned about price competitiveness against the RK3399 boards due out this year. Something the Tinker has going for it though is the rk3288 having by far the best mainline support available, so $80 for it working more or less properly vs the same amount for an RK3399 board that is as of yet an unknown... Also, the 3399 only has 2 fast cores, 64-bit or not. The Tinker has 4. For brute-force processing, that might be a hard decision to make. For development, their kernel is really just the Rockchip kernel with some tweaks, which are of course available per release. My main contention is that by doing the between release work in a private repo, they shut out the interaction of the community, who is trying to help. (The Tinkerboarding forum folks have put in some PR's as well, and some requests.) It's also among the reasons I decided to patch the Rockchip kernel for the default rather than the ASUS one, because I can keep pace with the rockchip updates and account for them if errors happen, the ASUS one has no visibility until release, then who knows how many small issues might come up that have to be dealt with? Keeping the MiQi working that way would be a nightmare. But, back to the S: It is a Tinker board with some bugfixes and an eMMC on the board. The Tinker works admirably well, is not too bad to support (once the hardware bugs were handled in software, the only real support problems are the RPi-style ones where the RPi flaws became the Tinker flaws.) If the cost seems justified I'd say it's as good a pick as any if you have need of that form factor and that much processing power. Now of course, I would rather have seen a SPI flash get put onboard, but those pins are on the GPIO header, so it would have been a tear-up and ruined compatibility.

@JMCC thank you, the hotplug was on my to-do list (can't remember if image building included it yet if not, will check when back in the US with my equipment/boards). The mainline already has the script, the old kernel didn't need it somehow. I will work these into the release, hopefully I get started on that tonight.

I work with French people every day, I recognize the dialect. For powering, there is a thread devoted to that: For the "Why no barrel jack":. It is simple. The Tinker fits the RPi form factor perfectly. You can pull out the pi and stick in the tinker with no thought a lot of the time (mechanically of course, software is different). For the camera: I have no camera, so I do not know. I know I do not have all of the device drivers loading right now, and I haven't put in 100% of the device tree parts, so an image today would not work out of the box.

I can see where you're coming from and agree on some topics, but I think this needs to be carefully viewed in terms of "fit for market". The Raspberry Pi sets a very low bar for hardware, being a voltage and heat catastrophe with no High speed SD access, etc. (Don't want to wake the Pi Legion, so I'll leave it there) So in the context of that, the only real failure is the software support being less than what you would hope. And that, honestly, is somewhat unfair (again, through RPi goggles) given how long the Pi has been out and how long it took to get where it is. If I had 1 open criticism on the software side, I believe they should perform their kernel development publicly, and not per release. I think they would be able to benefit from that far more than their current model, for instance I have submitted some fixes/etc, but have no idea if they are implemented and also do not know if I will be credited at all (secondary concern, but not irrelevant for people who would like to contribute significant things) As far as speed goes, it is still one of my fastest boards. The 64 bit models have different strengths, so comparison is not always practical. I will review the S eventually and give feedback, so stay tuned.

Card 0:2 is the desired alsa device. It will not change anything in aplay to map it to pulse audio, but it should appear in the menu of available sinks on the desktop.

The USB codec is available following the above instructions on all kernels. It would appear, at least for mainline, the HDMI out and I2S are not working. They should be fine for 4.4 kernels.

Well, my personal opinion is this is most likely a "more complete" Tinker board with some of the originally intended functionality completed. For instance all the pins on the 2x2 header next to the microUSB now have a purpose, eMMC, etc. For thermal, I installed a much broader heat sink that still manages to fit under the hats. It is not perfect, but is much better about throttling. For power, you can power it via the GPIO. For testing purposes I still use the microUSB, but for running it as a user it is strictly GPIO. The system rarely has issues with undervoltage, but the USB devices will suffer when the 5.0 volts becomes 4.75 or lower. If possible get a 5.25 volt supply, to give more safety factor against voltage drop.

@Igor feedback so far has been quite positive, let's wait until next week, I am in Mexico on business and so I don't have access to my pc/tinker. I would like to take another shot at sound and Bluetooth before we release new images. @zador.blood.stained's Bluetooth scripts/service for the 8723bs should work, but don't, so I am a little in the dark on what the rockchip wireless subsystem might be doing.

I have to agree le potato has proven itself to be simple and reliable. I've put the same heatsink on it as I put on the Tinker, it runs much cooler. The Tinker and it are more or less even on general use, each having strengths and weaknesses. I may need to get a Tritium H5, I passed on the funding run and shouldn't have, and I don't have any H5 boards. Sent from my Pixel using Tapatalk

Always an adventure with low-cost hardware.

As with any SoC that shows up in multiple products, we are of course looking at it. Official support takes time with the resources at hand, and I know that I for one don't even have a device yet. We tend to focus on boards that are less than $100, as most people are in that market, so the Firefly didn't get a lot of attention. Now that it looks like nearly all the major players are going to make these boards, it will be given more attention.

And that is why it isn't so easy to just jump distros. ;-)

No. I don't have a pi camera. [Edit]. Typical additional statement that donations are welcome, but I can't guarantee I can make it work.

Let me know, it has a newer driver, also the mainline images are still another driver revision. (Older, but has been given a lot of attention)

@Igor, I believe so, I have not experienced this issue in normal use, and only see strange behavior while repeatedly cramming new settings into the DT via Ayufan's tkaiser-inspired script, which could be a multitude of other things. Sent from my Pixel using Tapatalk

For GbE, I have been playing with the delays, but no, so far no setting appears to be more stable than any other, so I'm not certain it is delay-related, and performance degrades quickly as you deviate from the pre-set delays. Sent from my Pixel using Tapatalk

If no one has any real complaints, I plan to merge the new kernel/config tomorrow. I've created a pull request in the meantime for discussion.