TonyMac32

Haha yes, that is the other option. Sent from my Pixel using Tapatalk

Yes, that one. Basically it is a simple check that just looks to see if compatible = "spidev". It's a technicality that someone decided was worth a lot of noise, the device tree is for hardware description, spidev is a driver, so you "shouldn't say the driver is compatible with itself". So it is desirable for the board/distro maintainers to define a "hardware" at least in name (I was arbitrarily choosing "armbian,soft_spi"), then applying the driver to that. The concern for me is that compatible = "spidev" loads properly, but after adding a compatible string and using it, it doesn't load. The only functional difference between the working Tinker board implementation of spidev and my try on Amlogic is the fact that I have a bit-banged software SPI device, not a hardware one. Sent from my Pixel using Tapatalk

It is a warning with a stack trace, it was intentionally put into the spidev driver to make people create compatible strings. It doesn't actually do anything, but it looks/acts like a real bug in the dmesg output, I'm assuming it's only a matter of time before we get questions about why the kernel is complaining on boot. Sent from my Pixel using Tapatalk

I'm currently working on the meson64 family (C2, K2, Le Potato) as a family, and am trying to more or less make their GPIO behaviors similar and matching (as best I can) to the RPi they are form factor clones of. An issue I'm having right now has to do with the spidev driver, these boards don't have hardware spi where the Pi/Tinker does does, so I'm defining spi-gpio devices in the device tree. That part is fine. Where it gets interesting is setting up a spidev node under it. - Calling out a compatible = "spidev" works, enumerates, etc, but throws the typical ugly error during boot that it is wrong to do it that way. - Adding a compatible string to the driver (as seen in Tinker and recommended in the documentation) results in no device enumeration. Has anyone come across this? I'm not going to put much more time into it and just deal with the error if there's not some obvious reason for it not working. [edit] Yes, I have made sure the compatible string added to the driver and the one in the dts match. )

Please refer to the "posting recommendations", we don't know which of 10 or so kernels you're talking about, what board, anything. Now, if there is a TX timeout on an HCI uart based device, my shot in the dark is either a) the module isn't getting reset b) you're suddenly missing CTR/RTS pins with a Device tree update.

More or less installing the Mali userspace blob and properly linking it is the only thing I can recommend, aside from deciphering and implementing the video decoder driver how-to the way @JMCC has on RK3288.

This only affects seeing the u-boot output before the kernel takes over, it's of very little impact. On kernel 4.4 there is a question as to whether it will work properly, but it needs investigated while we fix the kernel Sent from my Pixel using Tapatalk

The entire DW-HDMI setup in U-boot appears questionable on RK3288. We had a patch from ASUS designed to "fix some issues" with HDMI, that included a lot of data channel "tweaks". I disabled that patch and the problem got worse (I went from not seeing this issue to having an issue on 1 monitor. So what I've done is disabled the entire video subsystem on U-boot, the kernel brings up the interface just fine. Sent from my Pixel using Tapatalk

@Batmah moved to TV boxes. Actually looks somewhat interesting with the batteries, you can get far better capacities than pictured, too, I have 18650's at 2800 mAh. More or less you need to find out what's inside, then figure out if a device tree exists for it.

For 64-bit you are probably correct. On the other side, the Tinker board web browses quite well with it's 2GB of RAM. Sent from my Pixel using Tapatalk

SDR104 is enabled for the SDMMC interface, and if you look at the iozone testing I did above I was getting well over 50 MB/s, exceeding the SDR50, maximum. Another note: I have disabled video in U-boot on this architecture for now, there have been changes to the HDMI drivers within the Rockchip family that the old patches may not be properly addressing, specifically the RK3288 has been split from the rest of the Rockchip code. Sent from my Pixel using Tapatalk

OK, for the unafraid, I have removed some HDMI hackery that was part of some patches on older U-boots than what we use. Install the file below if you have kernel 4.14 (so "next") and are seeing this issue, let me know if that alone fixes it, or if you see any other issues. http://electricgraveyard.com/armbian/tinker/uboot/linux-u-boot-next-tinkerboard_5.67_armhf.deb [EDIT] Updated, I found the issue now appeared on one of my "previously good" monitors. I disabled video in u-boot entirely, seems ok now. That does leave some questions for the 4.4 kernel as I think it now needs u-boot to set this up...

@Evgeny would you be able to put the code blocks into the Spoiler containers so they don't hog an entire page? As to the question, I assume the Opi zero plus has a "dumb" regulator setup with no voltage switching? (OK, found it, it will do 1.1 and 1.3V). Basically you have no voltage to support those higher operating points, the processor will theoretically fall on it's face if you tried. As for the temp and random hex showing up, I do not know.

Haha. I got frustrated and put down the RockPro64 for a little bit, the miniloader and RAM blobs seem to work *most* of the time, but then U-boot just plain kills it instantly and it sits there in stasis. Spent my day getting used to my Chinese CNC engraver for PCB's. Not bad, but I won't be doing anything too exciting with it. ;-)

Interesting, I don't keep track of them and their support. Perhaps they haven't been following the mainline developments... This is one of the few boards actually capable of 4K video, and the recent pacthset submitted should enable HDMI 2.0 support shortly, and the memory on the board is fast enough to actually play 4k, and with the hardware decoders working....

Our images so far are vanilla kernel images with patchsets put out by BayLibre, who is doing the mainlining work for the Amlogic SoC's. That said, video decoding will be accelerated soon, as it is being integrated into the upstream kernel.

@igor no problem, I just wanted to point out that the current Meson64 has all the BayLibre patches for mainline support of the VIM at least, and a lot of VIM2. I only held off adding it because of Balbes's separate work, it seemed redundant. If, however, we are to reunite the build systems, I don't see any reason to keep from just adding those to Meson64, at least for the upcoming 4.19LTS once it's ready Sent from my Pixel using Tapatalk

@balbes150 If you think it's appropriate, boards like the Vim (and I would guess Vim2/edge) which don't need as much "special care" from the user to load linux on like the standard TV boxes (Vim(2) has configurations in both U-boot and linux kernel if I remember correctly), those could be moved to the Meson64 part of the script, and we add the Mali/etc as per the usual Armbian method. I would like to get the Mali driver patched into the kernel source rather than building it separately, but haven't had the time to sit down and go through the configuration to make that happen, so I don't include it in the images yet.

I'm not going to be the one to say this isn't interesting hardware, I know the beaglboard community is pretty healthy and there are a lot of cool projects in that arena. I just see the current issues with supporting this without bringing a new dev into the picture: - New SoC for Armbian requires a lot of work compared to new board on a supported SoC - "one-off" boards require more love per board because work only benefits a single device (in this case I assume the Black, Black Wireless, Green, and Green Wireless could all share with only device tree differences) - We don't have the hardware on hand, and not being a company/profit machine we don't just go snag any and every board, so unless boards are provided to us, or we had specific personal interest in it we wouldn't even look at it. - Most devs aren't going to be interested in a single core Cortex A8 board, it falls outside the use case of the team (I'm an outlier and am working on migrating from microcontrollers to Linux hardware where it makes sense, but things like the ESP32 and Teensy make it a hard decision most of the time) The last bit is that there are a significant amount of userspace libraries that no doubt utilize some tweaks to the environment. This would be (in my opinion) the hardwest part, because a BeagleBoard image had best support BeagleBoard peripherals, libraries, etc. If we could get the BeagleBoard fans interested enough in Amrbian to quite frankly do the bulk of the work for themselves on the board support, I do think Armbian would be a good choice. If you've wandered around the forums a bit you'll see we've been actively sorting and ending support for anything "exotic" (MiQi) or EOL'd by the manufacturer (Random Allwinner boards with "quirks". The only boards escaping that are ones with active software support upstream (Amlogic S905 is, as far as I know, a dead processor, but is almost perfectly software compatible with the S905X and in the same family as the new S805X, and is still getting a lot of upstream support, so we continue to support Odroid C2 and NanoPi K2, as it's barely any more work than supporting the Le Potato alone). The BeagleBoard Black is nice and has a community, if we could get that community to come here and help out, I think it would be a good addition, I do like the truly open-source hardware design and the existing user base. I just know none of us have the time and resources to add it ourselves. Now, as a last note, I got into this because I wanted support for a board (Tinker Board), and this was a good way to get into Linux building for embedded targets, there's a ton to learn here. I went form that board to bringing up "Le Potato" and the NanoPi K2. If I were you I'd fork the build system, do some reading, and give it a try

[edit] Oh wait... @Igor did you test Odroid C2? It didn't really change.. K2/Potato are the affected boards. I have to go for the night, but do you just wipe out the extra packaging file?

@Neil Armstrong Odroid C2 booting u-boot 2018.11, kernel 4.19, integrated with Meson64: http://ix.io/1pp7 Link is diagnostic info. [edit] the older patch for fclk_div3 issue resolved the -5 clock issue again. For everyone else, The packaging script on 4.14 still needs adjusted to boot 4.14, but u-boot isn't the problem there, I will push the u-boot update.

The Amlogic flash tools will be relevant when discussing La Frite as well, should we support it (I think the S805X is to the S905X what the H2+ is to the H3). I'll need to review their function (I actually plugged the eMMC in during boot of the SD to get it in a position where I could work with it the first time, not a fun task) Sent from my Pixel using Tapatalk

Is there something in particular you want form the the debug/dri folder? I have a "0" folder with some contents EDID's attached, Acer is the HDMI-DVI connected monitor, Samsung is a 27" 4K screen, 7" is, well, an RTD2660H-based 7" hdmi LCD 7InchEDID.txt AcerEDID.txt samsungEDID.txt

I have an i96 on my desk, thick cover of dust. :-/

Ah, I did "the wrong thing" very early on and dd'd garbage over the boot sector to kill Android. Then you can boot SD. There is also an Amlogic download tool I've never used...