lanefu changed the topic of #armbian-rockchip to: Armbian - Linux for ARM development boards | Rockchip SoC | www.armbian.com | This channel is relayed to the equivalent Discord channel | this channel is logged
<DC-IRC> <lanefu> look at all this promise of a bright mainline future for rk3588(s)
<DC-IRC> <lanefu> ```
<DC-IRC> <lanefu> ├── [ 62K] rk3588-edgeble-neu6a-io.dtb
<DC-IRC> <lanefu> ├── [ 74K] rk3588-evb1-v10.dtb
<DC-IRC> <lanefu> ├── [ 69K] rk3588-rock-5b.dtb
<DC-IRC> <lanefu> ├── [ 67K] rk3588s-indiedroid-nova.dtb
<DC-IRC> <lanefu> ├── [ 58K] rk3588s-khadas-edge2.dtb
<DC-IRC> <lanefu> └── [ 64K] rk3588s-rock-5a.dtb
<DC-IRC> <lanefu> ```
<DC-IRC> <Tonymac32> NO pciE YET THOUGH :d
<DC-IRC> <Tonymac32> No PCIe though so far
<DC-IRC> <lanefu> Rk3588s don't care
<DC-IRC> <lanefu> Sweet mods
<DC-IRC> <lanefu> Pcie2 is there just not 3
lanefu has joined #armbian-rockchip
<DC-IRC> <RichN> there are 2 kernel patches needed upstream for pci-e
<DC-IRC> <RichN> these need to be in in the 6.x kernel
<DC-IRC> <EfeCTN> I guess they will send new patches
<DC-IRC> <EfeCTN> Combophy should/will be added with sata patchset
<DC-IRC> <RichN> ok well these will be needed to get tings moving forward
<DC-IRC> <RichN> for 3588
<DC-IRC> <RichN> hope they go in soon
<DC-IRC> <RichN> but we wait
<DC-IRC> <RichN> stop audio files and type for hard of hearinf people
<DC-IRC> <RichN> we dont use audio files
<DC-IRC> <Werner> Audio messages have been globally disabled.
<DC-IRC> <Tenkawa> They "can" still be re-enabled/played though...
<DC-IRC> <Tenkawa> "I" find Accessibility features useful to have out there if needed.
<DC-IRC> <Tenkawa> Although this one being in a different language I'm not sure if it wasn't just spam.... possibly not
<DC-IRC> <Tenkawa> There has been a fair bit lately
<DC-IRC> <gambl0r> no he was just saying hello
<DC-IRC> <gambl0r> @Az-eddine ciao, tutto bene grazie 🙂
<DC-IRC> <Tenkawa> Ok good.. I'm not familiar with that language. Which one is it.. I can't quite tell...
<DC-IRC> <Tenkawa> I speak French and a bit of Japanese and Korean
<DC-IRC> <gambl0r> italian
<DC-IRC> <Tenkawa> (Haven't used then though in 20 years regularly since I was working with my coworkers offices there)
<DC-IRC> <Tenkawa> (Haven't used them though in 20 years regularly since I was working with my coworkers offices there)
<DC-IRC> <Tenkawa> oh cool..
<DC-IRC> <Tenkawa> Italy is one place I haven't been too although one of my aunt's lived there for 20 years or so
<DC-IRC> <Tenkawa> I'm headed back to France later this year
<DC-IRC> <Tonymac32> I speak English, German, and Appalachian. (Appalachian being my native language). 😆
<DC-IRC> <Tenkawa> I'll move this to offtopic because I do have a response to that
<DC-IRC> <Tenkawa> is that mainline or a forked/vendor kernel tree
<DC-IRC> <Tenkawa> is that mainline or a forked/vendor kernel tree?
<DC-IRC> <lanefu> collabora's treet
<DC-IRC> <Tenkawa> ahh
<DC-IRC> <lanefu> *tree
<DC-IRC> <lanefu> just plugged a usb drive in
<DC-IRC> <Tenkawa> are you booted on nvme?
<DC-IRC> <Tenkawa> or emmc?
<DC-IRC> <Tenkawa> or please don't tell me microsd.....
<DC-IRC> <lanefu> sdcard, i dont' bother with emmc
<DC-IRC> <lanefu> nvme is no-go right now.. the pcie3 stuff needs patches
<DC-IRC> <Tenkawa> Then that's a no go for me.... I like my nvme
<DC-IRC> <lanefu> yeah i get it
<DC-IRC> <lanefu> but this really means that the rk3588s boards
<DC-IRC> <lanefu> are probably in an interesting spot
<DC-IRC> <lanefu> _if_ the had mainline device trees
<DC-IRC> <lanefu> _if_ they had mainline device trees
<DC-IRC> <Tenkawa> Yeah.. I wish Khadas would hurry things up a bit
<DC-IRC> <Tenkawa> they have great engineering but lag on software
<DC-IRC> <Tenkawa> This Edge2 board could do some even more interesting things with that
<DC-IRC> <lanefu> device tree is there
<DC-IRC> <Tenkawa> Yeah... we'll see.....
<DC-IRC> <Tenkawa> RPI took "how many years?"
<DC-IRC> <Tenkawa> even after it started appearing
<DC-IRC> <Tenkawa> but yeah I'm cautiously optimistic
<DC-IRC> <lanefu> usb 3 disk performance ain't too amazing
<DC-IRC> <lanefu> ```
<DC-IRC> <lanefu> root@rock-5b:/mnt/tmp/tmp# dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync status=progress
<DC-IRC> <lanefu> 867237888 bytes (867 MB, 827 MiB) copied, 2 s, 434 MB/s1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.4748 s, 434 MB/s
<DC-IRC> <lanefu> 16384+0 records in
<DC-IRC> <lanefu> 16384+0 records out
<DC-IRC> <lanefu> 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 32.8765 s, 32.7 MB/s
<DC-IRC> <lanefu> ```
<DC-IRC> <lanefu> around that speed on 2 different drives i've tested
<DC-IRC> <lanefu> same throughput on usb 2.0 port lol
<DC-IRC> <lanefu> anyway i guess i could try bolting ona few patches that y'all linked earlier and see whats what
<DC-IRC> <Tenkawa> @lanefu test with bs=1M and 2M see if there is any change... I think your blocksize is way too small for usb
<DC-IRC> <lanefu> even testing reads to /dev/null... same... and with 1M
<DC-IRC> <Tenkawa> hmm strange
<DC-IRC> <lanefu> for comparison. on vendor kernel on indiedroid
<DC-IRC> <lanefu> ```
<DC-IRC> <lanefu> root@indiedroid-nova:/mnt/tmp# dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync; unlink test
<DC-IRC> <lanefu> 16384+0 records in
<DC-IRC> <lanefu> 16384+0 records out
<DC-IRC> <lanefu> 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 4.84832 s, 221 MB/s
<DC-IRC> <lanefu> ```
<DC-IRC> <RichN> link to the tree
<DC-IRC> <lanefu> ?
<DC-IRC> <RichN> to the kernelel tree you built with
<DC-IRC> <RichN> see if it will get or new board going some
<DC-IRC> <RichN> sorry working to finish off desktops and push by tomorrow
<DC-IRC> <RichN> so new bookworm imgs can be built
<DC-IRC> <lanefu> yeah hang tight on going to crazy with this link.. ricardo's got cherry-picks form my branch to tee up the collabora kernel stuff .. house keeping required still 😛 (this brnach got messy cuz i'm doing unlreated stuff as well)
<DC-IRC> <ossuaries> Hey everyone.
<DC-IRC> <ossuaries> Rock Pi 4b (RK3399) has a failing ram chip (first 2GB/4GB total) that I'm trying to blacklist. Passing memmap=2G$0M (or memmap=2G\\\$0M) to /boot/boot.cmd (then compiling with sudo mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr) causes dmesg on boot to spit out "Unknown kernel command line parameters "memmap=2G$0M" will be passed to user space." Should I be pas <clipped message>
<DC-IRC> <ossuaries> sing this parameter to /boot/armbianEnv.txt instead? Are any of my commands wrong? OS: Armbian (23.02.2). Kernel: 5.15.93-rockchip64.
<DC-IRC> <ossuaries> If anyone could help that'd be incredible.
<DC-IRC> <ossuaries> Hey everyone.
<DC-IRC> <ossuaries> Rock Pi 4b (RK3399) has a failing ram chip (first 2GB/4GB total) that I'm trying to blacklist. Passing memmap=2G$0M (or memmap=2G\\\$0M) to /boot/boot.cmd (then compiling with sudo mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr) causes dmesg on boot to spit out "Unknown kernel command line parameters "memmap=2G$0M" will be passed to user space." Should I be pas <clipped message>
<DC-IRC> <ossuaries> sing this parameter to /boot/armbianEnv.txt instead? Are any of my commands wrong? OS: Armbian (23.02.2). Kernel: 5.15.93-rockchip64.
<DC-IRC> <ossuaries> If anyone could help that'd be incredible. If this is the wrong place to post this, let me know.
<DC-IRC> <lanefu> share your whole modified boot.scr in https://pastes.armbian.com
<DC-IRC> <ossuaries> Cryptrooted and booting off NVME, if that changes anything. Only line that's been altered is setenv bootargs.
<DC-IRC> <lanefu> at a glance it looks okay what you're doing.. but that error message is probably being truthful.. which is kernel doesnt thing htat's a valid argument
<DC-IRC> <lanefu> glancing at kernel 6.4 docs.. not sure `memmap=` even applies ot ARM.... https://docs.kernel.org/admin-guide/kernel-parameters.html?highlight=memmap
<DC-IRC> <ossuaries> Oh dear. Thanks for the help. Is there an equivalent command for arm?
<DC-IRC> <lanefu> dunno you're playing in territory beyond my 🧠
<DC-IRC> <Tenkawa> Its not really blacklisting
<DC-IRC> <Tenkawa> its used for DAX
<DC-IRC> <Tenkawa> Its actually the opposite
<DC-IRC> <Tenkawa> it is used for persistemt memory pseudo allocatiom
<DC-IRC> <Tenkawa> it is used for persistemt memory pseudo allocation
<DC-IRC> <Tenkawa> it is used for persistent memory pseudo allocation
<DC-IRC> <Tenkawa> You can use a segment of memory in the os layer..
<DC-IRC> <Tenkawa> The Linux pmem driver allows application developers to begin developing persistent memory enabled applications using memory mapped files residing on Direct Access Filesystems (DAX) such as EXT4 and XFS. A memmap kernel option was added that supports reserving one or more ranges of unassigned memory for use with emulated persistent memory.
<DC-IRC> <Tenkawa> Not sure that would have quite the effect you are looking for however check out this document and see what you think:
<DC-IRC> <ossuaries> Huh. Interesting. Thank you for the help!
<DC-IRC> <Tenkawa> np
<DC-IRC> <Tenkawa> I'm finding conflicting information that memmap "in theory" can be used... but you have to find and adjust addresses (on x86 at leest).. I still haven't found anything in any other architecture
<DC-IRC> <Tenkawa> It seems to be a very "unstable" workaround