Otherwise, you can exploit the new kernel patch allowing ledtrig-gpio (as discussed on https://forum.doozan.com/read.php?2,136831) and compile a dts as follow: sata1-red-led { //label = "wdmcmg2:red:hdd1"; color = <LED_COLOR_ID_RED>; function = LED_FUNCTION_DISK_ACTIVITY; function-enumerator = <1>; gpios = <&gpio1 11 GPIO_ACTIVE_HIGH>;by CyberPK - Debian
In my WD MyCloud Mirror Gen2 I've found an area near the cpu that appear to contain some jumpers ready to setup pull-up or pull-down resistors in the area of the MPP pins. So I've modified the uboot to read the Sar value sed -i '640 i mvOsPrintf("satrVal: 0x%x\\n", satrVal);' board/mv_ebu/a38x/armada_38x_family/ctrlEnv/mvCtrlEnvLib.c and after some tries Iby CyberPK - Debian
I've found and read the "88F6810, 88F6820, and 88F6828 ARMADA® 380, 385, and 388 High-Performance Single/Dual CPU System on Chip Hardware Specifications", and I think you're true about the hardware configuration. Compared the uboot from devices with the same cpu but different clock, and couldn't find any indication that it's setup via software. Probably, the onlyby CyberPK - Debian
It could be useful to gather any data from the i2c bus (it's an eeprom?). Also any hires image of the board to search for an eeprom. I'll dismount mine in the next days. If anyone can activate in the dts the i2c bus and gather any useful data maybe helpful in understanding if the cpu speed and memory could me modified by software.by CyberPK - Debian
Poking around I found a valid i2c device (i2c0) that I've managed to read, but cannot understand if contains any useful data. It appear to have 2 valid addresses: 0x13 and 0x64, and only 0x13 returns 256 byte of data that I cannot translate into anything useful. Any feedback? *** EDIT *** Removed the read memory, because was not useful to the topic.by CyberPK - Debian
I haven't still found the solution to change the clock in uboot. Anyone known a board clocked at 1600mhz instead of the 1333 of the WD MyCloud Mirror Gen2? I've already verified that my board has ddr3 1600 (800Mhz), so I should be safe. In the meantime I've adapted a patch from openwrt to enable cpu frequency scaling on kernel 6.7.7 Source: https://forum.openwrt.org/t/cpu-frequby CyberPK - Debian
After countless attempts, I found the commit impacting the performances: 28ee8b0912ca2ff68c2c03ff97bf1c22634c7942 Ironically it's reported a 2x speed increase, but it's not true for me. Apply both the attached patches tested and adapted to work on kernel 6.7.7; cesa_reenable as patch, 28338b... as patch reverse (-R). Consider also compiling using CONFIG_VFP=y CONFIG_NEON=y CONFIby CyberPK - Debian
Can you please share the latest patch (any difference for nand/uart?), and the exact name of the GPL package to download? I would like to test a patch to allow the change of the CPU frequency. *** edit *** Managed to compile the uboot by my own, and found that the build process produces both the nand and uart binary. To anyone interested, you can find attached the useful patch and a scriptby CyberPK - Debian
bodhi Wrote: ------------------------------------------------------- > I've re-uploaded linux-5.3.5-mvebu-tld-1 tarball. > See > > Old > kernel and rootfs releases. Thank you very much! Using kernel 5.4.270, I can measure the expected performance. cryptsetup benchmark --cipher aes-cbc # Tests are approximate using memory only (no storage IO). # Algorithm |by CyberPK - Debian
I'm trying to change the CPU clock on a MVEBU based WD MyCloud Mirror Gen2. I've studied the u-boot sources from WD (https://support-en.wd.com/app/products/product-detailweb/p/137 WDMyCloud_Mirror_GPL_v2.31.204_20191206.tar.gz), a customized version of uboot 2013.01-14t3 (github mirror https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/tree/u-boot-2013.01-14t3) On my deviby CyberPK - Debian
Hi bodhi, for WD MyCloud Mirror Gen2 the gpio 16 and 26 (mpp48 and mpp58) sense the disk presence. So it is useful on this machines to mimic the default behavior: blue led, solid on = disk presence, solid off = disk absence, blink disk activity. I'm struggling to make this behavior work, but I probably need to edit your patch because I'm still not able to connect both the behavioby CyberPK - Debian
Today I've brutally tried the very aggressive attached patch on kernel 6.7.6 to fully disable CRYPTO_ALG_ALLOCATES_MEMORY flag but still getting 40mb/s on aes-xts (instead of about 73mb/s) and 53 mb/s on aes-cbc instead of about 80mb/s. There should be something else impacting the performance. Any idea?by CyberPK - Debian
I've just noticed a rewrite of ledtrig-gpio driver: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/leds/trigger/ledtrig-gpio.c?id=4a11dbf04f31c71eb458c062129e95b7aa308464 If I'm not wrong, this patch should enable the trigger source, eliminating the need to set the leds in rc.localby CyberPK - Debian
someguys561235 Wrote: ------------------------------------------------------- > edit: https://wiki.kobol.io/helios4/cesa/ reverts > the patch in case anyone has a use case where the > memory corruption risk isnt a problem. I was not aware of the patch proposed on the page that you linked. The patch I've proposed on the first post is more aggressive because impact also hashby CyberPK - Debian
Yes, I've read the warnings. I think it should be investigated because until now there were no report of data corruption/deadlocks on encrypted drives using Marvel CESA engine, so I think that the problem is more theorical then real. Also, if the problem is not fixed, should be made clear to all that the hardware acceleration is not used anymore by dm-crypt, and the encrypted reading/writinby CyberPK - Debian
I've noticed a performance drop using LUKS in recent kernel (>=5.9) with marvell_cesa acceleration. After some investigation I found that marvell_cesa is not used anymore by dm_crypt because of potential deadlocks. Even if "cryptsetup benchmark" shows the HW accelerated speed, the performance writing and reading on a disk are poor, aligned to software only encryption. For moby CyberPK - Debian
bodhi Wrote: ------------------------------------------------------- > mcmg2, > > > I changed /etc/fw_env.config > > > > > > /dev/mtd0 0x100000 0x80000 0x20000 4 > > > > Very good! so the location is actually at 0x100000 > on this box. Please, note that this address is valid only for the patched uboot. As explained in my post, the sby CyberPK - Debian
You are missing the kernel patch from bodhi to handle the additional ide-disk1 & ide-disk2 Read my post, there you will find also the relevant patches to manage the poweroff and rebootby CyberPK - Debian
encrypt drive 1 encrypt drive 2 open both drive create brtfs partition in raid mode on the opened device. Or, if you can't initialize both drive at once, create brtfs on one drive, then convert to raid. Cant you share your initrd?by CyberPK - Debian
Quotevzhilov Ah, Ok. I got it. It should be in quotes. 257 default-state = "keep"; Yes, sorry. My mistake. I've copied an old version containing only this stupid errorby CyberPK - Debian
Hello, looking at this post https://forum.doozan.com/read.php?2,26394,26510 the performance of my armada385 are really poor. My kernel has marvell_cesa builtin but cannot obtain such performances. Also I've noticed that my processor has a lot of cpu used to handle the irq used to communicate with cesa. Why? Any clue? Thank youby CyberPK - Debian
Quotevzhilov Does it mean that Kernel is still too big? Or I need to make uRamdisk smaller? Or the only solution is to patch the U-Boot? Yes, it is the only solution. In short, the stock uboot is missing the saveenv command. Also, if it was available would store the settings over the kernel. read my post for details: https://forum.doozan.com/read.php?2,28939,98649#msg-98649 please note thby CyberPK - Debian
Look to my post: https://forum.doozan.com/read.php?2,28939,98649#msg-98649 Also this for latest DTS: https://forum.doozan.com/read.php?2,28939,99099#msg-99099 In days I'll release a more refined version. About using BTRFS: It should be BTRFS over LUKS directly, managing both volumes and raid instead of EXT4 over LUKS over RAID. Also take a moment to understand what is better betweenby CyberPK - Debian
Thank you, I'm interested too in your results. I point you that our devices have an hw crypto engine (CESA) that can be used to improve disk encryption, as pointed at https://wiki.kobol.io/helios4/cesa/ QuoteIn order to offload disk encryption on the CESA unit, you will need to specify to cryptsetup the following cipher: aes-cbc-essiv:sha256. Therefore the command to create your encrypby CyberPK - Debian
> I am glad it works for you! But I think it is the > wrong approach to change the GPIO trigger. This is > only related to disk GPIO trigger. I've added a missing function to the DTS setup. It was really strange to have GPIO available but not settable in DTS! In fact timer, one-shot, and pattern are all configurable trough led-pattern parameter. This patch can be useful also forby CyberPK - Debian
I've created the attached patch to enable the gpio trigger set by DTS So: 1) done with the attached patch and "1 -" DTSs. Tested working; 2) done with the attached "2 -" DTSs and rc.local. Tested Working; 3) any idea? I've extracted the original DTB and translated to DTS but no clue. Analyzed the kernel source, but cannot find any clue. Analyzed the root searby CyberPK - Debian
No red blinking. Please note, gpio48 and gpio58 are IN, not OUT as the other gpio leds. GPIO48 and GPIO58 status changes accordingly to the disk presence/poweron Also, I did a bit of research and found this: https://www.at91.com/viewtopic.php?t=25697 So, it appear there is no way to set gpio trigger parameters directly in the dts as I want. Here what I can do: 1) I can try a kernel paby CyberPK - Debian
I don't need any script. In rc local I can enable the trigger with echo 48 > /sys/class/leds/wdmcmg2\:blue\:hdd1/gpio and the led start to sense the hdd insert How this parameter can be set in the DTS (in addition to the led own gpio)?by CyberPK - Debian
1000001101000 Wrote: ------------------------------------------------------- > here's a device tree using a drive detect gpio as > a button as I described earlier: > > https://github.com/1000001101000/Debian_on_Buffalo/blob/master/Buster/device_trees/armada-370-linkstation-ls421d.dts Thank you, to me it does not trigger the leds, but simply return the hard disk presencby CyberPK - Debian