TonyMac32

Purpose: Discuss displays that at least someone has tested and/or use, particularly touchscreens/strange resolutions/sizes/alternative technologies (DSI, parallel TFT, SPI, etc) Goal: Have some kind of "This at least worked with this version at that time" resource. Over and over people post things like "I have a Waveshare <XX.YY.ZZ> and Armbian can't do what the vendor kernel that uses a crap kernel full of security holes and crusty drivers can". So, point them here and say: "By the power of Google, I beseech thee, search!" And I have some random stuff lying around.

Ha thanks @chwe, I think... I am familiar with ham hock. My uncles actually eat the feet pickled. I never acquired a taste for that... For an unintentionally American meal (I did not know Chwe would actually start this thread): I smoked a lean flat cut roast today (beef). Last night I did a dry rub of pepper/salt/cumin/oregano/garlic/onion, then rolled the roast and tied it with string (cotton of course, don't poison yourselves) I put that in a bag with Worcestershire sauce overnight. This morning (6:00) I fired my charcoal grill with a decent amount of oak lump and raw oak for smoking, got the temperature stable to 95 C (~7:30, one must be patient) and put the roast in there in a glass baking dish large enough for it and it's resulting juices. Smoked it for 8 hours. Brilliant! Served with mashed Potatoes. Substitute for whatever you prefer, but something potato and maybe some beans. The "Drippings" as they're called were used to top the potatos. (If they are too concentrated, they can be diluted with water and used to make gravy) Slow-roasting meats and barbecue are a Southern US thing, the Northerners just copy it. They apparently got tired of their pot roasts and boiled vegetables... This particular endeavor had no recipe other than the rub I used, and it came out with a steak-like consistency and a ton of good flavor. Very tender, but still needed the knife, so the structure of the meat wasn't destroyed. Yes. I also like to accept "challenges" from my wife when she says "there is nothing in this house to eat". I then make something using whatever is laying around. This time of year, with my garden, there is a lot involving tomatoes, peppers and cucumbers. I don't take pictures of the plate, though, so no fancy images like tkaiser

Yes it does, and it's enabled.

This is a bit of a circular discussion, SoC's for SBC's are almost always "old news", so they've been around a few years before Linux is going to work on them properly. In order for people to support them they have to be expected to have some longevity, but again, you're looking at 3-ish years after SOP sometimes before good support. Then the SoC has more or less service life left, and that's entirely up to the vendor. As far as Chinese company goes, there are few alternatives. I would recommend simply sticking to as standard of libraries and api's as possible to maintain portability.

I can't help, since I've never installed Android on a single board computer (usually I'm deletiglng it), and this is a Linux project, after all, and this is an unsupported board.

I made a crappy power adapter for my SATA SSD, works quit nicely. Of course, powering it via the GPIO on the Duo is... Not ideal, let's say. Still, a fun experiment.

Awesome

Agreed. I'm just wondering how good the routing on these various boards really is. In any case I've set the rk3328 to 8mA, if anything presents itself on the rk3399 I'd recommend the same.

https://dl.khadas.com/Hardware/VIM1/Datasheet/S905X_Datasheet V0.3 20170314publicversion-Wesion.pdf and https://drive.google.com/file/d/0B1Rq7NcD_39QYnltdGtWWEFvS0U/view?usp=sharing Page 26, you can see that UART B and C live on I2C_A (The RPI's "ID" pins) and "PCM_DOUT/DIN" (Pins 19 and 21 on Le Potato) https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi#L764 Shows the definition of the UART's in question in the GXL dtsi, https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-libretech-cc.dts#L266 shows where the A0 UART is enabled, it should be very similar for UART B and C https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi#L425 There are the pins that need referenced in the same manner as the AO one does. If you're up for some "fun with device tree", or are quite creative that should do the job. I haven't tried it personally, but you have access to the pins and they have those alternate functions. As to power management, I haven't used the 4.18 kernel to any real effect yet, so I can't speak to it's consumption, but I would guess some more "fun with device tree" in both u-boot and linux could disable all the stuff you're not using. Also make sure you're using "conservative" or similar for your CPU governor. If you can't get as low as you want, there are "SoM-style" H3 or H2+ boards that could also fit your needs like the NanoPi Neo/Core/Duo, or even the Libre Computer Tritium H2/3, if you want to keep the flexibility of maintaining the ports. If you search the forums you'll find a ton of "minimize consumption on H3" information.

Also VIM "1". I agree with you that a power delivery compliant USB-C is the only proper way to approach this, if one truly wishes to use USB-C. Can both of you keep notes on whether you get SD card corruption or failure to boot (with no obvious reason)? @botfap confirmed my hypothesis (or at the very least has strong evidence leading to the same conclusion) that the 4mA default SD drive levels is not enough. ASUS (or Rockchip, or whoever did the dev on the "miniarm" hardware) seem to have had the same idea, Tinker uses 8mA as well. @botfap has stated 12 mA was really the only "safe" setting, I'm waiting to get more feedback. TL;DR: Rockchip SoC's appear to have a default setting on SD GPIO's that are generic to all their GPIO's and are no good for 50 MHz + operation across varying SD cards (even decent quality ones), let me know if anything weird is going on. [edit] come to think of it, that would mess with SPI as well at higher speeds (I guess that should be obvious)

I see too many people worrying about the words they are saying, and not worrying enough about the words they're being told not to say... </political> That was actually entered into the bug tracker? ffs... So, how about that Article 11? Or article 13? I think that counts as tech related, in a bad way. On a lighter note, I work with a Transylvanian who sounds exactly like Gru. Makes me smile every time. He has a much easier life than the 1.55 m tall Scottish fellow we kept trying to get to say the Lucky Charms slogan.. "They're magically delicious!" we got cussed at a lot, which was just as funny. (I'm half Scot and half German, I am triggered by this cereal box, and Budweiser. ) This cereal is made of whole Monsanto grain! Extra GMO! And corn syrup marshmallows. I'm depressing myself, back to sipping whisky and eating Spätzle <--- if that isn't comfort food, I don't know what is. @chwe we should start a "local foods" thread. Mostly because I'm hungry and want to learn some recipes.

So I'm guessing there is no documentation on the SoC either? Perhaps those Mediatek guys who were given the... task of supporting Bpi could be helpful?

Quite honestly my favorite feature when I was introduced to this project when hacking music players out of NanoPi Neo's...

Also forgot: https://github.com/rockchip-linux/kernel/pull/122 That's for the phase tuning on mmc's, partially separate and minor, but another twig on the heap.

Right, I've set it to 8, I'm considering 12 because of the results of some oversimplification modelling I did in the tutorial section showing it not completely taking care of the issue. For the screen, yeah, we could do that. If Ayufan rebases the u-boot it won't be an issue. Sent from my Pixel using Tapatalk

I believe the initialization got some how messed up in Rockchip kernel past June. On Tinker Board the answer was initialize display in U-boot. Ayafun u-boot doesn't have any of the drivers for that yet, so I have only found unplugging/replugging the HDMI, sometimes multiple times, to work. Thanks all for the updates so far, this looks like an issue on multiple fronts. I also opened a pull request to Rockchip (I'll drop Ayufan a note) about the ciu-drv clock name typo that might impact tuning phase on the eMMC. And a deprecated frequency parameter that really shouldn't do anything but gives dmesg spam.

Well, should be valid enough. This is a case where I don't think too many of the original are "in the wild" anyway. The chip near the Ethernet port that has the crab on it will say RTL8211E or F (IIRC, mine is an old one).

We would need the hardware to do that, and the time. That said it looks like a board with promise, I think it would be a nice addition.

Is it simply not pingable, or is it just plain not booting? Can you give me the age of the Rock64 and the part number of the Ethernet chip? Power domains, time to reset/bring up the SD card might not be waiting long enough either (I think it simply waits default 10 ms, might need a little longer) Can everyone involved please give me the exact SD cards being used, or even pictures of them?

Since we haven't done it, sadly, no.

No worries, my rock64 is happy with all of my cards and various images, so I have a hard time verifying... And yes, I confused the boards, but the patches are to the dtsi, so should affect both builds equally. I noticed late last night the added clocks for rk3328 dw-mmc controller had one that I believe to be a typo (ciu-drv instead of ciu-drive), which is corrected in the Renegade dts. It involves phase correction/adjustment, I didn't think much of it since Rock64 doesn't have UHS capabilities to my knowledge and I thought the phase adjustments wouldn't be fooled with. I'll see if my board is complaining about it, fix it, and post it. (Should push to Ayufan)

Interesting. @JMCC may I impose on you to test the current build?

I'll have to snag one of those cards.

This is a far too commonplace issue these days, unfortunately people want to take action on how they *feel* about something rather than by any objective facts. Being an asshole does not mean you don't do good science. The position of feeling over fact is antithetical to science, but here we are.

Quick follow-up, my board / SD card combinations don't exhibit issues, but having access to @JMCC's misfortune in having a Renegade with constant file system corruption/failures, I took advantage. A series of testing on his part using an 8mA drive setting on the RK3328 (so far) solved his issue, and in any case significantly improved the situation, I've pushed a patch for that to the build system so we can get a wider sample. Again, as I said, the increase doesn't "force" anything to take power it can't handle, it simply makes it available if needed. A lot more work in that area is needed, such as re-enabling UHS modes on boards with hardware support for the voltage level switching