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>
<minerva> Guys, after several months woth my PBP "dead" laying on my desk bc of the emmc not showing up I decided to reflash the sd with a very old armbian, and yep, everything shows up, even the emmc
<DC-IRC>
<minerva> I understand that armbian is about mainline uboot... but since mainline uboot is a mayhem currently on the PBP, wouldn't be wise to just use a 2 years old uboot with the PBP?
<DC-IRC>
<minerva> Armbian on the PBP is mostly impossible bc of this modern uboot
<DC-IRC>
<minerva> I tried to burn this old uboot on the spi to use a newer armbian with the old uboot, but from armbian config it doesn't work and since uboot doesn't release an easy way for burning uboot on the spi, I am stuck. Does anybody knows how to install an ancient yet reliable (like my image armbian uboot) into the spi? I need it to just work to be honest, don't care about new features (t <clipped message>
<DC-IRC>
<minerva> hose are mostly needed on the kernel, not uboot)
<DC-IRC>
<minerva> @nicod_sbc like you said at the forum, burning modern armbian to emmc throws me to initframs and busybox
<DC-IRC>
<minerva> And from the sd I can't even mount the emmc
<DC-IRC>
<minerva> Anyway, if someone has a way to burn a reliable uboot to the spi, hit me with a PM please.
<DC-IRC>
<minerva> Uboot is super annoying and towboot is also super broken for the PBP. No emmc on my side.
<DC-IRC>
<minerva> Pine64 seems to have abandon his platform since also manjaro sucks on this department. It's the official OS...
<DC-IRC>
<amazingfate> If you can't mount emmc, it's a kernel issue, not uboot.
<DC-IRC>
<tenkawa42> @minerva TowBoot works fine here except for needing to power cycle after reboot..
<DC-IRC>
<tenkawa42> I'm using pinebookpro/u-boot-rk3399_2023.01 on mine
<DC-IRC>
<tenkawa42> works fine here
<DC-IRC>
<Tonymac32> hmmmmmmmm what does our device tree look like for this thing?
<DC-IRC>
<tenkawa42> That I can't say.. this is mine and c0rnelius build
<DC-IRC>
<Tonymac32> right, so I'm guessing the DTS has had a partial overwrite or a bad patch experience in the rockchip64 mess we're still trying to clean up
<DC-IRC>
<tenkawa42> Its definitely been cleaned up
<DC-IRC>
<tenkawa42> The sound doesn't even hardly pop anymore... that was unexpected
<DC-IRC>
<Tonymac32> how old is "very old"
<DC-IRC>
<Tonymac32> ah you provided screenshot
<DC-IRC>
<Tonymac32> nm, I'm not always very observant
<DC-IRC>
<minerva> @amazingfate I am 99% sure it's bc of uboot.
<DC-IRC>
<minerva> In fact. This happened like this
<DC-IRC>
<Tonymac32> yeah if u-boot isn't bringing up the emmc then it wn't boot obviously
<DC-IRC>
<Tonymac32> but there's also some handoff with the kernel and the device tree, so that's not impossible either
<DC-IRC>
<minerva> Several months ago I had a very ancient build on the emmc, booted a modern armbian from sd trying to do a cleab update, burned the system sd to the emmc.. and then the emmc didn't show up anymore
<DC-IRC>
<minerva> Until I got this old armbian system, now it shows and behave correctly
<DC-IRC>
<minerva> But it's focal, so, too ancient for my needs sadly
<DC-IRC>
<amazingfate> If you can get into initramfs busybox, you have already loaded the kernel on emmc from uboot.
<DC-IRC>
<minerva> I understand this is mostly pine64 fault on not taking care on uboot, not yours.
<DC-IRC>
<tenkawa42> Keep in mind also if you had this sitting for a long while those emmcs were not the "highest" quality and it may have just gone bad so the socketed chip in there could just be bad
<DC-IRC>
<Tonymac32> "This patch is required to boot some Rock Pi 4 and NanoPC T4 units
<DC-IRC>
<Tonymac32> with kernel 5.3+ and is on par with how it is done in Rockchip's BSP.
<DC-IRC>
<Tonymac32> "
<DC-IRC>
<minerva> Nono, the emmc works fine, done some testing already
<DC-IRC>
<minerva> And it's the same behavior than nicod explained on the forum
<DC-IRC>
<minerva> Yes, you got me wrong, @amazingfate that's bc that happens if I try to boot the emmc. But botting from sd then the emmc doesnt show up
<DC-IRC>
<minerva> The emmc does "boot" to linux then busybox. But booting from sd the emmc doesnt mount at all.
<DC-IRC>
<Tonymac32> can you share a dmesg of booting from SD
<DC-IRC>
<minerva> I am referring about modern armbian. The oldie just works 😆
<DC-IRC>
<minerva> Yes, it says that the emmc is busy, something like that.
<DC-IRC>
<Tonymac32> via armbianmonitor -u so we get the link. I'd like to see the error message
<DC-IRC>
<minerva> I need to rewrite the modern armbian to be more exact
<DC-IRC>
<minerva> Thanks tony
<DC-IRC>
<minerva> Will burn modern armbian then show up the problem
<DC-IRC>
<minerva> The dmesg
<DC-IRC>
<minerva> Sorry the armbianmonitor
<DC-IRC>
<Tonymac32> Thanks. armbianmonitor uploads a bunch of info including the dmesg, nice tool
<DC-IRC>
<minerva> Burning
<DC-IRC>
<Tonymac32> @amazingfate back to rk35xx, I also see an rk3568-odroid.conf, it only has edge and looks like it's doing nothing special, looks like @igorpec added it for the Odroid M1
<DC-IRC>
<Tonymac32> I guess we should check if that can get tossed into rockchip64 as well
<DC-IRC>
<nicod_sbc> Yeah, it's an old issue. I thought it was now fixed with the previous release. Seems it's back???
<DC-IRC>
<Tonymac32> any other emmc boards for rk3399 been having issues?
<DC-IRC>
<nicod_sbc> Right, eMMC type did matter I believe. Some versions have this, mine too. I think pine eMMC fine but Odroid eMMC not... Can't remember the exact things, it's all a haze...
<DC-IRC>
<nicod_sbc> @nicod_sbc Can you share the topic that's been discussed in?
<DC-IRC>
<Tonymac32> probably a speed problem then
<DC-IRC>
<Tonymac32> only set to hs200 though....
<DC-IRC>
<Tonymac32> their board routing can't be *that* bad
<DC-IRC>
<Tonymac32> *knocks on wood*
<DC-IRC>
<minerva> Okay, the emmc shows up this time for some reason!! Will burn it just in case (it tends to mount and then to not do it, so I will not miss this chance)
<DC-IRC>
<Tonymac32> [ 2.889635] mmc_host mmc0: Bus speed (slot 0) = 148500000Hz (slot req 150000000Hz, actual 148500000HZ div = 0)
<DC-IRC>
<Tonymac32> [ 2.892050] mmc_host mmc1: Bus speed (slot 0) = 148500000Hz (slot req 150000000Hz, actual 148500000HZ div = 0)
<DC-IRC>
<Tonymac32> [ 2.893408] dwmmc_rockchip fe320000.mmc: All phases bad!
<DC-IRC>
<Tonymac32> TADA
<DC-IRC>
<minerva> What I dont understand is the next thing. While booting from the emmc (that throws me to busybox) the emmc was mounted properly (if anything). How is that the rest of the system isn't? Thst makes no sense to me. It cant find root partition on the emmc but yes to mount it?
<DC-IRC>
<Tonymac32> ok
<DC-IRC>
<Tonymac32> so why
<DC-IRC>
<Tonymac32> kernel is breaking it, u-boot isn't
<DC-IRC>
<minerva> Ohh, good
<DC-IRC>
<minerva> That's better
<DC-IRC>
<minerva> We can fix it on armbian then
<DC-IRC>
<Tonymac32> ideally. the clock mismatch is special
<DC-IRC>
<Tonymac32> and the phase problem. *head hurts*
<DC-IRC>
<minerva> Okay, if you have anything to try out, let say an image, warn me. Make it minimal, so I use armbian-config to burn the emmc and then see what happens to corroborate that it really solves the issue
<DC-IRC>
<minerva> Text me privately! Thanks sir
<DC-IRC>
<nicod_sbc> You can try installing a previous kernel on your sd image, reboot and install to eMC and see what happens.Use armbian-config THEN other
<DC-IRC>
<nicod_sbc> You can try installing a previous kernel on your sd image, reboot and install to eMMC and see what happens.Use armbian-config THEN other
<DC-IRC>
<tenkawa42> btw.... kernel 6.1 is "very" problematic without tuning
<DC-IRC>
<tenkawa42> (on the PBP anyway)
<DC-IRC>
<tenkawa42> (on the PBP anyway) .. and most other devices I've tested it on so far
<DC-IRC>
<tenkawa42> If you don't configure it's settings around the device you are going to be installing it for I've found it gets ... "interesting".. and not in a good way
<DC-IRC>
<tenkawa42> 6.3 actually seems to be better than 6.1 ironicly.. just not as much supported yet I don't think
<DC-IRC>
<meneerkim> Does anyone know how I can set accepted pixel formats on the Radxa Rock 5B HDMI-in? I only want to support BGR but somtimes the format differs
<DC-IRC>
<amazingfate> It's BGR when source resoluton is under 4K30. It will be NV12 at 4K60.
<DC-IRC>
<meneerkim> Is that always the case?
<DC-IRC>
<amazingfate> It depends on the source. I also get nv24 from rock5a.
<DC-IRC>
<Tonymac32> Right. For "Current" images we stick with LTS kernels, for better or worse. Next LTS will certainly be an improvement
<DC-IRC>
<tenkawa42> Yeah I have noticed major differences in 6.3 vs 6.1 already... 6.1 was a mess
<DC-IRC>
<tenkawa42> I know there was a kernel revision a few (maybe more than a few) years back that was like that... everyone wants to forget it ever even existed.
<DC-IRC>
<minerva> I will give 6.3 a chance then
<DC-IRC>
<minerva> Well, I tried one image with 6.3 that didn't boot, but will retry with a diff one
<DC-IRC>
<minerva> If you have a cli one that's proven to work from your side warn me
<DC-IRC>
<minerva> I would like my pbp up and running from the emmc. The sd card reader is caped.. no UHS speeds
<DC-IRC>
<minerva> Like on the vast majority of sbcs
<DC-IRC>
<tenkawa42> I put TowBoot on my SPI and just put a boot partition on a microsd... I don't want to have any "internal" storage make me have to open up the chassis again
<DC-IRC>
<tenkawa42> now if something goes wrong on my NVMe or internal emmc I always have a safety
<DC-IRC>
<rpardini> No, it was me. We used to have a 4.x legacy for the ODROID-M1, then I added edge "pure mainline".
<DC-IRC>
<rpardini> I also have tried to make it "go" on rockchip64 but... it didn't.
<DC-IRC>
<rpardini> I'd rather it be merged to rk35xx (it seems with little effort we can bringup the rkr4 5.10 on it) and then the rk35xx edge will just work on it.
<DC-IRC>
<minerva> Pure mainline, I didn't know that actually existed in our ecosystem 😆
<DC-IRC>
<minerva> Just joking
<DC-IRC>
<rpardini> Well at least that 1 board is absolutely perfect on mainline. I think the only thing we add is overlays.
<DC-IRC>
<Tonymac32> Yeah 3568 is basically "good to go"
<DC-IRC>
<rpardini> I couldn't find what, in rockchip64, is breaking it -- dunno if patches or .config
<DC-IRC>
<rpardini> It simply does not boot, if I recall correctly.
<DC-IRC>
<Tonymac32> Interesting
<DC-IRC>
<c0rnelius77> If someone could explain to me how to prevent the rkbin master from doing it's stuff during u-boots compilation I could attempt to add mainline u-boot and linux to the M1 and the NanoPi R5 series.
<DC-IRC>
<minerva> Tested K6.4, sadly, it also does not resolve my issue. The emmc isn't there 🥹
<DC-IRC>
<tenkawa42> @minerva Ok I just recreated the issue so I am going to start debugging it here
<DC-IRC>
<tenkawa42> Since I have mine running on nvme root I can debug it in stages fairly quickly
<DC-IRC>
<tenkawa42> I also have a machine that I can build new kernels to test in 4 minutes
<DC-IRC>
<tenkawa42> I have made a few changes and rebuilding now.. we'll see what happens
<DC-IRC>
<tenkawa42> I think its a dts issue though looking at the output hwinfo had when I first started debugging.. I think they moved things around in the kernel at some point
<DC-IRC>
<tenkawa42> Going to need to move them back...
<DC-IRC>
<tenkawa42> (probably)
<DC-IRC>
<tenkawa42> @minerva ok.. first test didn't show any new devices.. going to focus a bit more on the u-boot
<DC-IRC>
<tenkawa42> I got some activity out of it finally..
<DC-IRC>
<tenkawa42> now to start debugging
<DC-IRC>
<tenkawa42> definitely appears to be dts related
<DC-IRC>
<tenkawa42> (with first couple of tests)
<DC-IRC>
<tenkawa42> I can get the controller itself to try to talk to the card but it times out currently