TonyMac32

I agree, however we weren't clear which wire was even cut last time we discussed, so I can't be sure what feature is truly causing the issue without confirmation. I unfortunately don't have a monitor that causes this, I'll run through them again and see if I can find one I guess. Sent from my Pixel using Tapatalk

Of course, but it seems better than might be feared if it hasn't appeared yet. Well, we might find out sooner rather than later then.

OK, I'm sure I'll find my head on a pike for the question, but, it looks like the hardware is at least acceptably made, correct? No crazy errata to worry about? And mainline support is likewise fairly mature for arn ARM SoC, correct? And since this is a hardware bringup thread, I guess the question could be, is it worth to bring this up? I see 3 people who can work and support if they are so inclined, and even the Mediatek guy. It's a big question, because Igor does not need anything else to worry about, I'm getting my wind back with Amlogic and Rockchip after a long summer and can't learn another new SoC with all of it's fun oddities, etc. I honestly don't think we need a new board of different architecture, but a lot of the work has already been done it seems. If you want a laugh: https://www.newegg.com/Product/Product.aspx?Item=9SIAFK56SJ5438 BPi might want to check with those guys and see why they are trying to give them a bad name for being 10x more expensive than anyone else...

Unsure, I never anticipate having "good" performance on any board with a "chiptenna". The drivers are also the predictable mess you get from a vendor unwilling to really support open source meaningfully, blobs and really crappy source code cause constant headaches.

Thank you for the info, it is definitely u-boot where the problem lies. As for the comment, more or less while mainlining Amlogic SoC's they've come across hardware dependancies that were completely undocumented and caused very strange bugs after what should have been pretty simple code improvements. Sent from my Pixel using Tapatalk

Read further, it's some kind of boot testing. It jumps to 400 then 800 with the 800 MHz binary, I've gone back to the 933MHz binary as used in the Ayufan repo. I compared the scripts, they appear the same, but with so much going on variable wise it's hard to say. Part of why I want to reattempt mainline. I've done diffs on all the various files looking for a "smoking gun", I have a few directions, but the defconfig is the biggest one.

No problem. My thought here is, if there were something fundamentally wrong with the RAM no one could boot these boards anywhere. And up until you load u-boot only the RAM and SoC are "alive", so all of these boards should behave nearly identically up until you load the u-boot image, so the problem is most likely there. We have some issues with the post-process I'll commit later, with them resolved you get to the point of loading the bl31 every time (limited number of tries)

I'm about 75% sure it's the defconfig for the board in u-boot, it has environment and such coming off of the SPI flash, and has a bunch of Android boot stuff enabled that the nanopi's does not. Tried playing with it in the rockchip folder but it started having compile issues. Otherwise U-boot should at least try to load, the system does not care what board it is living on as long as the RAM is working until it loads the actual uboot image. RK ---> RAM + miniloader --> u-boot/trust. We have the miniloader running, up until it goes to grab the u-boot image, then it falls on its face. I'll try it with mainline u-boot tomorrow, and use a more generic defconfig that is pointing in the right directions

I've started poking at this, I missed the conversation, to fill in more for the U-boot plumber @chwe: Output of what the build system currently creates: DDR Version 1.13 20180801 In So that is quite obviously missing the entire loader portion of the equation, simply the RAM part is alive (maybe freezing, unknown exactly) My observation: The idbspl.img and idbloader.bin are mutually exclusive, the Rockchip documentation is a little sloppy on that. So this is trying to handle two separate and incompatible boot paths simultaneously ("Path4" is not too well defined, but is relatively blob-free I think, but my tries with it didn't fo anything at all... ) My tries so far got me to: ...and it hangs. So I think the missing "0x200000" on the loaderimage may be partially to blame. [edit] well, load address changed, but still a hang at BL31 statement. I think @chwe is on to the answer. <--- Nope.

Hmmm, I'm catching up on what was more or less an extended absence, I'll have to add this to the list. It will be a kernel driver issue if it's anything.

Yeah, every single Amlogic device we support has it's own boot blob, it gets messy quick.

Working on the rockchip64 family dev images, since 4.19 is an LTS and the RK3328 support is somewhat workable. With a reminder of something I failed to read by @JMCC, I got this today: ____ _ | _ \ ___ _ __ ___ __ _ __ _ __| | ___ | |_) / _ \ '_ \ / _ \/ _` |/ _` |/ _` |/ _ \ | _ < __/ | | | __/ (_| | (_| | (_| | __/ |_| \_\___|_| |_|\___|\__, |\__,_|\__,_|\___| |___/ Welcome to ARMBIAN 5.65 user-built Debian GNU/Linux 9 (stretch) 4.19.0-rockchip6 4 System load: 0.99 0.55 0.22 Up time: 2 min Memory usage: 3 % of 2000MB IP: CPU temp: 40°C Usage of /: 2% of 117G [ General system configuration (beta): armbian-config ] New to Armbian? Check the documentation first: https://docs.armbian.com Thank you for choosing Armbian! Support: www.armbian.com Building a Rock64 test image as I write this, then checking out the RK3399 boards in my possession. HDMI works after a plug cycle, may need to utilize some of @botfap's script-fu on boot to wake up the interface. Known Issues: Renegade bottom USB2 port is non-functional HDMI needs a friendly reminder to talk to the display Rock64 Same HDMI hickup Top USB2 port is non-functional Boot up your build machines (or launch you virtual ones, whatever) and get hacking!

This says you are stuck in u-boot. There are some patches there that may be troublesome, would need checked. Good information We added some patches from Asus to enable some of the nicer things like CEC/etc, unfortunately someone with a similar problem apparently simply decided to start cutting wires instead of finishing the software debug. Have you tried another monitor that may have different/more limited capabilities? UART adapter on the debug UART (it is either UART 2 or 3, it changed at one point and then again after the vendor kernel issues) That will show whatever output is being produced by U-boot/the kernel (assuming it gets to the kernel but dies parsing the DT) What is typically wrong with such things: open source drivers created without 100% cooperation of the vendor who produced the thing. Changes in the codebase have entirely unintended consequences (See BayLibre's comments about the Amlogic clock system and their undocumented system supervisor core)

Hmmm, I have a 7" hdmi, the only board I own that will work with it is the Tinkerboard... If the RPi touchscreen patches have been disabled (I'm still catching up) then the Tinker won't have the mode lines for the oddball resolution, so it doesn't know what to do with the display. If they aren't, well, Rockchip has been in a constant cycle of breaking their kernel's backward compatibility, so I can only assume one of the other patches is causing issue. Can you start the tinkerboard with the 7" HDMI, then change monitors and then post the output of armbianmonitor -u ?

The layout did change, they are now laid out by the physical attachment point. I'll have to look to see what the C2 is, or you can in the board definition in U-boot if you don't want to wait a day or so.

I have a VIM, but no VIM2. My issue here was/is Balbes' excellent work making mine redundant/unnecessary, and Khadas has a wide range of OS options already.

I've noticed on the C2 and K2 as well, will debug. [edit] It would appear the "Linux hates HDMI--->DVI" situation is back. My typical testing monitor with DVI does not work at all and my proper hdmi one works perfectly.

You can multitask with more or less anything that can handle a stack and save context: http://www.z80.info/multtask.htm At one point I had written a Java z80 emulator from scratch and built a tiny fixed-task multitasking demo to run on it. Lost to history, and useless since it was written in that garbage excuse for a language. I transitioned from that to x86 assembly for a few years (where I learned what a flaming pile of garbage USB is on the inside), then found myself here after a brief flirtation with ARM assembly on the venerable ARM7TDMI. Adafruit also has a variety of ARM-based Arduino boards, I have a Metro M4 Express on my desk right now with 2 load cells attached to it. QSPI is broken in Arduino IDE so I either have to rectify the driver myself or see if I can bit-bang an SD card fast enough to gather the data I need. If I was more comfortable with the IIO stack on linux and could be certain I'd get a sample every 100 microseconds I'd be using an SBC, probably a duo if the end user was ok with a small slow LCD over SPI.

The Ayufan kernel is simply a fork of Rockchip with fixes applied. One of those release tags should be really close to what we need. There is also a fork maintained by one of the multimedia distributions that has a ton of fixes in it, I'll have to remember whose it is. Sent from my Pixel using Tapatalk

True, we tried, but somehow it was a weird botch job. I think if we start off of an Ayufan tag we can succeed, unfortunately my slow summer of coding resulted in my not pushing this one as hard as I should have. The Rockchip guys are also completely uninterested in merging any fixes from outside sources from what I can tell. Sent from my Pixel using Tapatalk

Well, an Allwinner V3s might be a more related baby step, you can avoid routing RAM, for instance.

@Tido the esp32 fits a lot of the use cases, it's true, but the quad-core ARM is going to be able to do a lot more processing and has way more memory.

I guess for a dual inline I personally don't care about wireless. If I need wireless I can grab a NEO air, so the point was the wireless is only so much of an improvement, I very much like the form factor and use it for random gadgets, I'm only pointing out that for someone looking to upgrade, be aware the wireless is the upgrade, nothing else in real terms, so if you want to save a little money you can stick with the original.

For the build it yourself crowd, I've aligned our 4.18 patchset with @Neil Armstrong 's collection, which include the video decoder drivers. I haven't installed the Mali drivers yet, so screen redraw is still painful, but otherwise...