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 has quit [Remote host closed the connection]
DC-IRC has joined #armbian-rockchip
<DC-IRC>
<infinity_q> I'll try that when I can tether my phone to it for internet
<DC-IRC>
<infinity_q> and wait an eternity for it to cloe
<DC-IRC>
<infinity_q> clone
<DC-IRC>
<amazingfate> What kind of Ethernet, gamc or pcie?
<DC-IRC>
<infinity_q> opi5+ I'm not sure what it is
<DC-IRC>
<infinity_q> I haven't looked at the io schematic
<DC-IRC>
<amdbartek> Hey, I don't know if this is the place to ask but I am experiencing a weird issue with my Rock Pi 4 SE running Armbian. Only 2GB of RAM is accessible on my 4GB board.
<DC-IRC>
<amdbartek> Here's what I tried so far:
<DC-IRC>
<amdbartek> - Re-installing (tried both Ubuntu Jammy and Debian Bookworm builds)
<DC-IRC>
<amdbartek> - Updating "board firmware" using `armbian-config`
<DC-IRC>
<amdbartek> - Flipping the little white switch on the board
<DC-IRC>
<amdbartek> - Updating the system (`sudo apt update; sudo apt upgrade`)
<DC-IRC>
<amdbartek> - Tried switching to the Linux 5.x kernel (did nothing good except break WiFi)
<DC-IRC>
<amdbartek> Literally only 2GB shows in `/proc/meminfo`. It was working fine before.
<DC-IRC>
<lanefu> On a board that doesn't support 8gb
<DC-IRC>
<tenkawa42> I wonder if the u-boot isn't passing the full ram address through
<DC-IRC>
<lanefu> @amdbartek what image does it work correctly
<DC-IRC>
<amdbartek> This really has stumped me for a while, really not sure what to do. arm boards are not my area of expertise whatsoever.
<DC-IRC>
<amdbartek> and for the image that worked, I'm not sure but it was one with a 5.x kernel where wifi worked
<DC-IRC>
<amdbartek> when using `armbian-config` and switching to kernel 5.x it still has the issue on these current images though
<DC-IRC>
<amdbartek> when using `armbian-config` and switching to kernel 5.x it still has the issue on these current images though (with an added bonus of breaking WiFi)
<DC-IRC>
<amdbartek> Armbian image, not Radxa should have clarified. I'm talking about Armbian alone
<DC-IRC>
<lanefu> Really need to know what image did work
<DC-IRC>
<amdbartek> I should point out, it was 2.4 ~ GB before. Now 2.9 GB shows.
<DC-IRC>
<tenkawa42> I'm surprised I haven't falled over yet (and its only 10 pm here)... I am "not" a night person
<DC-IRC>
<tenkawa42> I am usually awake at 5 - 5:30 am lol
<DC-IRC>
<tenkawa42> I'm surprised I haven't fallen over yet (and its only 10 pm here)... I am "not" a night person
<DC-IRC>
<amdbartek> I am essentially nocturnal haha. my sleep schedule is now random cause I'm waiting for my next college course to start lol
<DC-IRC>
<tenkawa42> heheh yeah too long ago to remember lol
<DC-IRC>
<amdbartek> Heh, and I actually didn't even notice this RAM issue until I started to compile PrismLauncher. It worked on an older build of Armbian but this time it kept freezing. Checked memory and there it was - like 2~ gigs
<DC-IRC>
<tenkawa42> @mackahan hey... have you come across any good tools to analyze dts source and "compare" two source files very well ?
<DC-IRC>
<tenkawa42> (besides diff.. I need something more schema based)
<DC-IRC>
<Tonymac32> I feel like there must be a tool for this, but I more or less diff them
<DC-IRC>
<Tonymac32> there are checks to work against the yaml schemas' but I don't know dts to dts
<lanefu>
uploading now
<DC-IRC>
<tenkawa42> these 2 jh7110 boxes I know must have just something small different... just need to figure out what
<DC-IRC>
<amdbartek> alrighty, will flash as soon as I can download it
<DC-IRC>
<amdbartek> Also minor nitpick, but Vulkan doesn't seem to work on Armbian and apparently RK3399-T supports it. Doesn't really matter but would be nice to have.
<DC-IRC>
<amdbartek> Is it because it's using Mesa Panfrost driver?
<DC-IRC>
<lanefu> all that stuff is a moving target, an -edge kernel will probalby have neweer panfrost, and then the gpu nerds builds their own mesa
<DC-IRC>
<lanefu> and that makes me sound like i know what i'm talking about. i def don't
<DC-IRC>
<amdbartek> oh and that image flashed. gonna boot it rn
<DC-IRC>
<amdbartek> finally inserted the SD card via the small opening in the case - booting
<DC-IRC>
<Tonymac32> well, none in the boot anyway, wifi/bt/etc it can't be helped
<DC-IRC>
<Tonymac32> 🤔
<DC-IRC>
<amdbartek> yeah, but blobless boot is still interesting
<DC-IRC>
<Tonymac32> I did it on a few boards, hilariously it was the Radxa ones that didn't like it
<DC-IRC>
<Tonymac32> the low RAM variants
<DC-IRC>
<amdbartek> L4T ported Coreboot to the Nintendo Switch (Tegra X1), I'm pretty sure
<DC-IRC>
<lanefu> man i was reading about that chip the other night
<DC-IRC>
<lanefu> and like the first generation of it had a bank of 4 extra A53 cores.. and it was like you cuold use the primary cores or the 2ndary but not both
<DC-IRC>
<lanefu> so they were just sitting there inactive
<DC-IRC>
<Tonymac32> I don't see it in the board schematic
<DC-IRC>
<Tonymac32> but those are always a little dodgy
<DC-IRC>
<Tonymac32> it shouldn't matter unless it has trash on it
<DC-IRC>
<lanefu> trying blobless for grins
<DC-IRC>
<lanefu> with just the standard armbain junk
<DC-IRC>
<Tonymac32> wait a minute
<DC-IRC>
<Tonymac32> # - tpl-spl-blob: uses mainline u-boot TPL and SPL with proprietary rockchip ATF blob
<DC-IRC>
<Tonymac32> so it shouldn't be using the ddrbin
<DC-IRC>
<Tonymac32> :/
<DC-IRC>
<Tonymac32> # - spl-blobs: proprietary rockchip ddrin and ATF, but uses mainline u-boot SPL in place of rockchip miniloader
<DC-IRC>
<Tonymac32> so maybe try spl-blobs
<DC-IRC>
<lanefu> k, it puked on spl blobs when i provided the updated ddrbin but lemme finish this blobless attempt
<DC-IRC>
<Tonymac32> we need to put these board confs into folders by vendor 😄
<DC-IRC>
<Tonymac32> it's getting ridiculous
<DC-IRC>
<Tonymac32> and we need to move all this debris out of family files into the board confs, the attempt at unifying things just made it worse
<DC-IRC>
<Tonymac32> so if a Rock4 or a Pine64 doesn't play nice it gets left behind on its own until someone decides to love it and it doesn't hurt anything else
<DC-IRC>
<lanefu> yeah punchline is half the board confs (rockpi-4b.csc included) already overridr teh DDRbin
<DC-IRC>
<lanefu> but yes to your point
<DC-IRC>
<Tonymac32> exactly
<DC-IRC>
<lanefu> also putting conditioners in the common include file lol
<DC-IRC>
<Tonymac32> and calling the file "common is hilarious when it's 10 billion switch/case and if-thens
<DC-IRC>
<lanefu> yes
<DC-IRC>
<lanefu> lol
<DC-IRC>
<lanefu> slowest part of this process is compresing withh xz
<DC-IRC>
<Tonymac32> they have "rk3" common, that's it
<DC-IRC>
<rpardini> with the awesome 3566/3568 u-boot work by @kwiboo
<DC-IRC>
<rpardini> even got stable MAC address now 👍
<DC-IRC>
<kwiboo> @rpardini you should not really need preboot command to enum/scan usb/pci/nvme with u-boot standard boot, pci/nvme/usb should initialize automatically when it gets too a device that require it it in boot_targets
<DC-IRC>
<kwiboo> possible preboot command could be needed if your boot script depend on it, else there may be a bug in u-boot that we should fix
<DC-IRC>
<kwiboo> or maybe you just want it for debug information when user report issues ? 🙂
<DC-IRC>
<rpardini> Yeah I added for debug info, indeed. I'm still catching up to the recent-ish changes to distro boot.
<DC-IRC>
<rpardini> I also tried to enable UMS, but failed, it complains about DWC3.... `ums 0 nvme 1` would be absolutely awesome.
<DC-IRC>
<rpardini> Either way great work!!!
<DC-IRC>
<lanefu> UMS all the things!
<DC-IRC>
<kwiboo> For usb gadget you need `CONFIG_DM_USB_GADGET=y` and `CONFIG_DM_USB_GADGET=y`, nothing I have tested but without both options enabled it will not work and try to write to rk3399 dwc3 reg addr
<DC-IRC>
<kwiboo> `CONFIG_DM_USB_GADGET=y` and ` CONFIG_USB_GADGET=y`
<DC-IRC>
<kwiboo> also the `rk3568-2023.10-gmac` branch is no longer a gmac topic branch, my main `rk3568-2023.10` branch also contain all gmac patches, the `gmac` branch will go away once I have posted gmac+io-domain v2 patches later this week/weekend
<DC-IRC>
<rpardini> Thanks for the tips. I _think_ I did both `DM_USB_GADGET` and `USB_GADGET`, but not sure, will try again.
<DC-IRC>
<rpardini> I've pointed to a specific SHA1 (still in the gmac branch though, GitHub will eventually gc it if you delete the ref) , I will revisit from your `rk3568-2023.10` branch soon.