TonyMac32

I have tried it, there are boot problems here that I haven't yet gotten into (the list grows) I have seen implementations of boot menus with u-boot, but have not done so myself. Google may yield some examples, it appears there is a "bootmenu" command.that can be scripted.

To update my thoughts/observations: Pros: Exactly, to some extent this is the base model of Allwinner boards. Short of a failure to build it correctly it is simply going to work. (I drive a car without power windows or locks, so I'm partial to simple things) Low development support footprint for something people will buy. Using all SoC peripherals, no random changing of wireless chips or ethernet PHY's to cause wrinkles/confusion. Also low development/support footprint. Faithful replication of RPi form factor (for those who are interested in that, which is a few people) Upstream mainline activity is basically done, the device trees/etc are already available, no exotic hardware All 3 boards share the entire device tree other than the processor compatible/include. Pin compatible, so the same board definition goes for all three. Low development/support footprint again. Cons: Typical "powered via micro USB, beware your system voltage" warning applies. Not sure how many devs have it/would be interested. Somewhat mitigated by the "simplicity pro" No voltage scaling, although I'd have to see what the power costs truly are, and test stability. The biggest confusion I see is actually in the naming and marking scheme. Users, after putting their heatsinks on, may forget which one they have and download the wrong image for their "ALL-H3-CC" (written on every board). There are no distinguishing marks other than the giant "Hx" on the SoC itself, which you cover up. I would like to think the average user could figure it out, but... I propose this board series be placed in WIP. Typical statement about gpio powering/"no single board computer really meets the USB host spec for power delivery" etc. Once I remember my details I can make an entry for it on the page. I will need to change the H3/2+ config away from the current device tree and substitute in the correct one now that it exists. Do we want separate configs for the H2+ and H3? Or would it make any difference other than the user being confuses at seeing "H3" in their welcome screen?

SoC's have built-in support for changing frequency, generally. So the "Magic" is a driver controlling a clock generator/multiplier. However, most of the time, with reduced frequency you can reduce operating voltage a little bit to save on power and reduce heat. In this case that isn't going to be an option, on the Allwinner-based boards that support it it's a bit of a hack in the first place, using a transistor on a gpio to change the target voltage of the system regulator by adding/removing a resistor from the regulator's "voltage setting". This board does not support that. On a board like the Tinker, Renegade, Rock64, there is a matched/recommended regulator chip PMIC that takes commands and adjusts the voltages accordingly in a much more controlled fashion.

http://ix.io/1be2 Error: thermal thermal_zone0: failed to read out thermal zone (-110) [ 6.600383] sun4i-codec 1c22c00.codec: ASoC: /soc/codec-analog@01f015c0 not registered [ 6.600397] sun4i-codec 1c22c00.codec: Failed to register our card [ 6.618111] sun4i-codec 1c22c00.codec: Codec <-> 1c22c00.codec mapping ok Not bad. I believe there is a known issue involving the CPU Frequency. Also remember this board does not have the "V" part of the DVFS, so it will be a little bit less flexible power wise.

@lanefu try a different keyboard if you have one, I just logged in and got to desktop on the build I just made. Color me surprised.

I'm reading as things pop up, and keeping my eye on the Lima code, I saw yuq push a couple patches to the kernel recently, so that's exciting

I've gotten tied up trying to gracefully switch to mainline u-boot on Le Potato, haven't had time to double back on this (hence CSC).

Well that's new, I had nothing on screen...

Available on Amazon and from most SBC companies, most are 3.3 volt logic, some (Odroid XU4) are 1.8 volt. It is a USB to serial uart adapter.

Well, yes and no. On the Le Potato, the 3 pins beside the HDMI are a serial port, where the bootloader and kernel send boot messages and a console to log into the device directly. If you don't know what it is, then you probably don't have an "FTDI friend" or other adapter to interface to it. That's ok, just thought I would ask. Hard to debug much farther I'm afraid... :-/

Is it even attempting to boot? Any chance of a serial terminal?

Did I ever? I simply pointed out that a blanket statement such as "Kernel 4.14 is bad for Amlogic S905 devices" was incorrect. I then pointed to a possible cause of the problem, memory corruption. What is the kernel being used on these images? 4.9? The meson8b-dwmac driver is an extension of the stmmaceth driver, with adjustments specific to differences in the IP block implementation in the Meson and Meson64 SoC's (S905). This could be a tx-delay issue on the C2. The K2 is WIP. I update it as I have time, interest, and resources.

Learning is continuous improvement. ;-) I only have 1 significant one, and it involves mainline u-boot for Le potato. I have to reconcile mainline with the old boot script so old installs don't break, then update boot script to Armbian specs for any new images.

I saw @zador.blood.stained was doing some housekeeping, so I wanted to open the discussion again about what to do about it in the future. We've obviously demonstrated what you "don't want to do". My last comments on this were as follows: We should have temporary per-kernel branches when undertaking a bigger change. This allows wider testing for those who like to build experimental things Makes the creator of the branch responsible for keeping it up to date gets flattened out and merged into "master" or a "next" waiting for a revision bump PR's should be used on anything anyone is not 100% certain of to get ack's from the team (who hopefully knows?) Annnnd.... discuss!

It comes from a few things, vendor relations is one of them, but not the only one. There is often an issue with vendor software and documentation being incomplete/incorrect/non-existent, sometimes hardware bugs, etc. It may be improving, I haven't checked recently.

Bumping this due to some random issues seen with PulseAudio and perhaps ALSA allegedly due to the PA scriptto properly name the onboard USB names. @chwe, if you would so kindly take the last few posts from the Tinker Board Bluetooth thread involving audio and stuff them in here?

See:

As I said, it is a U-boot problem, not a kernel problem that is the issue with the K2, so the comparison is incorrect and has nothing to do with the blanket of "S905 devices". The only issues I know of with C2 on mainline *kernel* involve the eMMC clock speeds needing throttled, but we have that accounted for.

Absolutely and fundamentally incorrect. Legacy u-boot does not properly configure the memory space for the patched kernel. That may not be the issue with C2, however that is the issue with K2

Yeah, I had a feeling that might be part of it, however that kills the onboard headphone amplifier defs to get rid of it. I'll have to figure out a compromise, I'm not completely sure why that is causing any issues, it's sticking a couple lines into the config to name the USB audio endpoints, you can look at the file itself in the build system...

What I mean to say is, I'd prefer to have a widely supported SBC and add 4G rather than gamble on something at that price. Were it $20, sure thing, I'd buy one for an experiment. But at $45, well...

So, the Odroid-C2 is still a very relevant piece of hardware, I'm not sure if you're going to get a (significant) performance boost by moving to another board today. For USB3 you have a very small group of SBC's including the ODROID XU4/HC1/HC2, and the Rock64 that have decent support. (I'm not 100% on the newest Allwinner stuff, it's a weak spot in my portfolio) Odroid XU4 family (like HC1): 32-bit 8-core HMP (4 fast and 4 slow cores) 2 GB RAM (LPDDR3) USB3 (HC1 trades USB3 external with a USB->SATA adapter) Gigabit Ethernet eMMC available Rock64: Same basic speed as C2, design-wise (64-bit quad-core a53) up to 4 GB RAM USB3 Gigabit Ethernet Available eMMC Pi Form Factor (like the C2) Some boards on the horizon should be quite a bit more powerful, but they're still either in very early release or as yet unavailable. For what it's worth I run my Plex server on an XU4, it can transcode a stream at a time in software when necessary. With @JMCC's work on multimedia things, I am going to give Emby a try, as I can use a custom ffmpeg with it, unlike Plex where it's "stuck" at whatever they have compiled (Indeed IIRC there was some debate about their compliance with FOSS licensing early on).

The kernel tree. at the end this will beast be done with overlays, as the 2 different possible cameras conflict with each other for resources, but if we get one working then we can handle that later.

You could move the reported speed, yes, but the CPU never ran at that speed. It said it was going that fast, it responded to commands telling it to go that fast, but it never, ever, ever went that fast. Hence the use of the term "cheating", which means dishonestly misleading people in order to gain business through deception of the quality or capability of a product. So, advertise or insinuate 2.0 GHz operation, make the hardware say "Why yes, I am doing that", but then have the hardware not actually do what it's saying it does. Like a car with a top speed of 30 kph claiming it's doing 100, the speedometer says "I am going 100 kph", but you're being passed by a moped...

Well, the channel is showing up in the sink devices for PA, but I'm not getting anything out via my monitor... I'll do some more checking