TonyMac32

I just did a quick test on Le Potato, increasing CMA to 512 MB was very easy following the above instructions with the /boot/dtb/amlogic/meson-gxl-s905x-libretech-cc.dtb device tree. The property yo uwant to change is right at the top of the file as a handle under "reserved-memory" Any value that is 0x400000 aligned should be valid, so you can experiment.

Thankfully the kernel does not need recompiled for this, only the device tree. See the post below, I b elieve this is still accurate as far as device tree decompile/recompile method, can be done on the device (use the correct device tree for your board )

Hello uniformBuffer, The CMA memory is set by a device tree entry, so that would be the only way to change it to my knowledge. The drivers are extremely unoptimized presently for the vdec/venc, and the recommended setting is over 800 MB. This is an obvious problem for a general-purpose distribution, it renders the La Frite 512 MB boards unbootable, and leaves no real room for any working tasks on the 1 GB ones. It may be possible to implement this as an overlay, but in the meantime modifying the device tree is the only route: https://github.com/armbian/build/blob/cc7ab6a6b1d91977bd9e154245307e85f7f76519/patch/kernel/meson64-current/0302-arm64-dts-meson-set-dma-pool-to-896MB.patch This patch gives you the handle and value to get the required 896 MB CMA pool.

Remember the bcm2835 is the RPi SoC, you'll find no drivers for that mess in an Armbian distro for another SoC. You need to see if I2C is enabled via overlay for your board, and if you have an overlay for the specific RTC, in this case looking at your documentation rtc-ds1307. If you don't want the kernel to be using it, you should be able to probe for it on I2C0 and use some reference materials on the web to operate it:

Hi sulfuroid, I would look at a USB keyboard, unless you want to start writing device drivers. There are some projects out there for hooking the buttons to a micro and reporting as an HID that might make it easier. I have never tried it though.

For some info: http://opensource.rock-chips.com/wiki_Main_Page The boot process explained: http://opensource.rock-chips.com/wiki_Boot_option Sent from my Pixel using Tapatalk

Which image are you using? Sent from my Pixel using Tapatalk

Good luck with the deployment! Sent from my Pixel using Tapatalk

Rockchip recommends it for Linux as well. It isn't relevant to the processor thank goodness, and we certainly don't use it. Sent from my Pixel using Tapatalk

You could try the tinkerboard image and swap the EVB device tree. Model: Evb-RK3288 DRAM: 2 GiB Relocation Offset is: 7de4d000 Using default environment Sent from my Pixel using Tapatalk

Can confirm display port working in USB-C, don't try hotplugging too many times it will give up eventually until reboot. really cool though

I've been (trying) to move the Tinker and MiQi u-boots to 2020.07, however if I use any of the following: A MiQi, A Tinker S an image for a Tinker S an image for a Tinker on a Tinker S I get stuck in the initramfs busybox with it telling me the filesystem is toast. The only 2020.07 combo I've gotten to boot is the Tinker with the non-eMMC supporting u-boot. As for clues, I haven't found any, the u-boot source code is of course very well organized for debugging purposes :lol:. If anyone has an idea about what could be going on with this let me know, I'm shelving the effort to think about other stuff.

I have no problem with SPI flash when it doesnt require me to take extra steps to get basic functionality. I'm just not sure why you can't just load the u-boot preloader directly into flash and forget about tapdancing around all the chromebook knock off u-boot stuff. If yanking it works though (it should, really), that's probably what I'll do, I have the tools to do it and keep the SPI in case I need it.

As was stated only a couple posts above this one, the display was never working with mainline kernels. As the driver has been upstream for a while and gotten some attention I may try it again, however the RPi designed hardware is of course not fully compliant with any standard display module, and could cause some difficulties. Sent from my Pixel using Tapatalk

Mine is an "EPIK" branded model, Veyron Jerry. I got it for almost nothing. I'd be willing to take a look at if there's a way to wipe the entire coreboot mess off the SPI and start over.

I can. Sent from my Pixel using Tapatalk

Moved to TV boxes.

I have one actually (veyron), but it seemed like a pain in the ... to flash it so it got forgotten.

The GPIO pins are very low current, 3-5 mA if I remember correctly. I don't think you'll damage the SoC, but it certainly won't drive a fan if my memory is correct. Sent from my Pixel using Tapatalk

@ning Yeah, I was keeping up with the mailing list, reverted it here: https://github.com/armbian/build/commit/9372fcdedfb6af9709ba1a046e983523997aeada Now it all works, we had a Vim1 issue because it wasn't using the modified card name so PA wasn't immediately enabling it (I chose to use "gx-sound-card") I have not touched vim2 and up, I don't have test boards.

Thank you @jrober19, that's what I would expect from an eMMC in this case.

let's go with iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 We used to do this to benchmark SD cards, however I think we should probably do it to benchmark Kernel/SBC/etc. It will only tell us if something is very wrong or significantly improved, small differences are meaningless because too many variables

on 5.6 yes, I patched 5.6 ;-) However my quick test on 5.7 this was not the case. I will check again of course [Edit] Found the issue, all of the board dts patches got wiped with the bump to 5.7 somehow. putting them back. [edit2] Can anyone run iozone on their meson64 boards and tell me the outcome? I'm working on sound, but my SD performance seems really bad.

I tried reverting a patch in 5.7 that chewitt blamed for some problems but it didn't restore sound. @balbes150 our current Amlogic patch situation is, well, interesting. I need to go through one by one and figure out what each one is for. I neglected my duties for too long.

https://github.com/rockchip-linux/kernel/blob/develop-4.4/arch/arm/boot/dts/rk3288cg-opp.dtsi is the vendor opps for the rk3288-C (Tinker/chromebook version) If it isn't a "C", then it wouldn't have 600 MHz Mali or faster than 1.6 GHz CPU according to Rockchip (I don't know about the "W") @Myy Wow, that patch is garbage, I didn't even notice that. It's worse than you are summarizing: "NPLL is necessary for 500 MHz, ancient krusty kernel suxors and doesn't have this OPP, so in case someone hypothetically someday maybe in theory thinks about possibly re-purposing the NPLL like the ancient kernel did, make mainline suck too for everyone." Yikes. I don't see any reason to not reintroduce that OPP for Armbian use, as far as I know this purely hypothetical situation has not taken place.