<FergusL>
macromorgan I'll just go ahead and ping you here, apologies to bother you. i've read along your messages on the odroid forum. I saw you also worked on the rg351m compatibility, I've got one, do you know what's the status on 351m with the spi flash? there is no dedicated switch. I've opened it up, soldered serial and popped the cpu cover to find the
<FergusL>
flash IC, trying to short cs to 3v3 but it just seems to forbid booting
<FergusL>
and everytime I do that, it just seem to fail and then I have to unplug battery and serial adapter and back on for it to boot again
<FergusL>
the anbernic rg351m is a clone of odroid go advance, except they removed this switch that allows to short the SPI NOR and force using the sdcard uboot
<FergusL>
and yes the go advance is supported by u-boot! there's a defconfig which I used. And the rg351m is even in mainline linux including dtb (thanks to the user I pinged above!)
<marex>
are you sure they didnt change something more ?
<marex>
did you compile uboot yourself or did you get prebuilt blob somewhere ?
<FergusL>
I compiled it myself, following along the rockchip.rst in doc/boards and the thread above
<marex>
try older version, some 2021.10 or so
<marex>
it could be something has bitrotted in the meantime
<FergusL>
you're right, there's the possibility some other things were changed! but since the exact device I have is in mainline kernel and its dtb is very close to that of odroid go advance, and the efforts were seemingly from the same person, I figured as a relative beginner I might have missed something :)
<FergusL>
oh okay, very helpful! i'll try that tomorrow, thanks a lot
<FergusL>
I should add that even without using mainline u-boot I could boot a kernel, also built myself + dtb, both from mainline. So that was using the default u-boot in the spi nor
<marex>
the other option is that shorting the SPI NOR doesnt really make it fail to boot and fall back to SD card
<marex>
note that I am not familiar with rockchip platforms
<FergusL>
indeed, as the actual routing might be different on the clone, it might not work
<marex>
possibly
<marex>
but if kernel is capable of printing to UART, the UART routing ought to be the same
<FergusL>
thanks for your interest in my attempts, appreciated!
<FergusL>
One thing that I find intriguing is there are several custom images for this device, they all use rockchip sources as base for both kernel and u-boot, very old, but because of this spi nor situation, it's likely to have 0 effect to flash uboot during their build process as it might just be bypassed and ignored
<marex>
FergusL: you can try the prebuilts and see whether you have more success with those
<marex>
FergusL: if they boot, you have at least some sort of a starting point
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
prabhakarlad has joined #u-boot
xroumegue has quit [Ping timeout: 250 seconds]
xroumegue has joined #u-boot
tnovotny has joined #u-boot
emanuellee has joined #u-boot
emanuellee has left #u-boot [#u-boot]
mmu_man has quit [Ping timeout: 260 seconds]
d-s-e has joined #u-boot
d-s-e has quit [Client Quit]
<macromorgan>
FergusL: Honestly I'm not sure. Driving the CS pin high should bypass the SPI chip. Do you know for sure the SPI pads are going to the SFC and not some other function?
<macromorgan>
You could try driving the clk pin to ground maybe also?
<FergusL>
do you remember having to do anything like that if you did test mainline uboot on this device?
torez has joined #u-boot
<FergusL>
macromorgan I could yeah, although I didn't as CS is active low, which the datasheet confirmed, sooo that would mean force it always selected, which isn't desired
<FergusL>
although I reckon the chip looks for falling/rising edges, and not state
<FergusL>
also, I built v2021.10 as per marex suggestion, and then tried both the spl and miniloader instructions from your post, and flashed that to a blank sd card except for a FAT partition at the right offset and I get nothing on the serial, just a few garbage character. Speed is still 115200 right?
mmu_man has joined #u-boot
LordKalma has quit [Quit: Server has probably crashed]
LordKalma has joined #u-boot
LordKalma has quit [Client Quit]
LordKalma has joined #u-boot
davlefou has quit [Ping timeout: 248 seconds]
<FergusL>
okay I just got my selfcompiled 2021.10 u-boot to work on the rg351m but I had to hold CS to Vcc (with a more stable connection than what I did last night), here's the log https://dpaste.com/ECLJWJ9HD at the end the version command confirms it
<FergusL>
I'm not sure I want to put a permanent hack and solder stuff 5mm away from the CPU chip haha
<FergusL>
earlier today I could confirm that the other images I tested (various flavours of libreelec, ubuntu etc.) were indeed working with their own uboot, I was just fooled by the uboot version (2017.09) which is very old but the build dates change, confirming it was picked up by the device
<FergusL>
so it might just be in the u-boot defconfig
ikarso has quit [Quit: Connection closed for inactivity]
<FergusL>
yeah :D
<FergusL>
https://dpaste.com/5988GZZ3E I've tried this, alas to no avail, should that be enough to disable SPI? it doesn't really make sense to try to disable spi from u-boot as it doesn't seem to start at all. I get the same 10 garbage characters and then nothing
vagrantc has joined #u-boot
naoki has quit [Quit: naoki]
<macromorgan>
The SFC is in the bootpath of the BROM before the SDMMC... if there's a valid TPL/SPL stage on the SPI chip it will never get to the SDMMC
<macromorgan>
you'll need to nuke the SPI chip if you want to bypass it permanently
<macromorgan>
(erase it, basically)
<macromorgan>
is the devicetree identical between the Odroid Go Advance and the RG351? I don't have a 351 so I can't test it, but I can rig up a mainline U-Boot for you and test it on my Odroid real fast.
<FergusL>
marex that will be helpful to compare DT in the distros that manage to boot using the u-boot sdcard
<marex>
FergusL: if you can boot those two u-boots, you can dump two DTs and run diff -Naruwdb on the result to see what changed
<marex>
maybe run them through dtc -I dts -O dts -s to sort the nodes at least
<FergusL>
macromorgan thanks! if I understand correctly, I want the opposite. The SPI flash is indeed getting in the way with mainline uboot unless I short CS, which is tedious to do on rg351m
<macromorgan>
erase the flash and you'll be good
<macromorgan>
mainline U-Boot should support doing that (if you include the sf commands and build with the Rockchip SFC and XTX SPI flash chip drivers)
<marex>
macromorgan: as far as I understand the conversation, FergusL cannot boot mainline uboot just yet, but I might be wrong
<macromorgan>
I'm not sure where the status of the mainline Linux support for the XTX flash chip went... I tried to mainline it but it collided with another manufacturer code, an alternate solution was proposed, and I kind of lost track
<FergusL>
I am treating both DTs as equal but they are clearly not -- which is probably why the other images I have manage to start their uboot *without shorting CS* and I cannot *unless I do the short*
<marex>
macromorgan: maybe you can bring FergusL up to speed and they can upstream the remaining stuff :)
<FergusL>
(is your other fish the RG353v? I think you're the author of the 6.3rc4 commits for adding touchscreen, which is awesome btw
<macromorgan>
yes, for the moment I'm working extensively on the RGxx3 series (the rk3566 based stuff for Anbernic)
<macromorgan>
I am more or less done with the linux stuff, excepting some bug fixes. For U-Boot there was a lot to upstream and that's in progress. The biggest bits are the DSI host and DSI-DPHY bits which are more or less copied and pasted from Linux into U-Boot (with slight modifications)
<macromorgan>
those bits are necessary to auto-detect which panel is used. Once those are accepted into mainline U-Boot I should be able to submit the rest of the parts
<FergusL>
that's really cool, thank you so much for the time and effort put into this! I'm actually just playing around with the rg351 until I can catch a second hand 353 around 100€
<FergusL>
curious if you have a specific personal usecase? besides gaming my own thing is audio stuff, I really think all these devices especially with touch screen, with a simple (touch) interface could do really exciting stuff
<FergusL>
I treat it as an SBC with buttons and screen for a few tens of euros more
<FergusL>
marex I think you're correct! to be perfectly honest though, I'm getting distracted, I'll do the DT comparison tomorrow but then if I can boot into a decent rootfs with mainline kernel, I'll move on and use the old rockchip u-boot. I'd happily post about the current status and summary of our research here on the mailing list or elsewhere though!
<macromorgan>
my usecase? Playing Android games (Stardew Valley, Grand Theft Auto SA, Evoland, Roblox for my kids). To get there I want to use AOSP and not what the devices came with. To get to AOSP I want a mainline kernel with a mainline bootloader.
<macromorgan>
for U-Boot I only copied the high level rk3566-anbernic-rgxx3.dtsi from upstream linux, then I use a generic rgxx3.dts to cover all devices. By querying ADC0 I can figure out which device I'm on.
<macromorgan>
Then if I check for an eMMC I can tell if I have a 353V or a 353VS. Then I also have to query the panel to see if it's the first revision or 2nd revision panel and update the devicetree in place if it's a v2 (code is done, but not submitted for review yet).
<macromorgan>
then the variable of ${fdtfile} is set which the boot.scr can reference; as long as all the devicetrees are in the correct location the bootloader will select the correct one and pass it to Linux.
<macromorgan>
so that way one image can be used for all devices
<Tartarus>
Well, here's something that feels like progress. I've got rpi_3_32b building with clang-16 and seemingly booting and running pytest, too
<Tartarus>
(and, passing)
<Tartarus>
once this run is done I'll pop over to console and confirm that yes, really, it's doing that
<Tartarus>
Well nice, it really is
<Tartarus>
First to figure out how plumb this properly in to my scripts (gotta fire off docker for the build, but not for the test, but, I do that for sandbox, so hopefully not super hard), then start fixing warnings again
<Tartarus>
xypron, apalos, for EFI, this warning should be ignored, right?
<Tartarus>
include/efi_api.h:1173:13: warning: field guid within 'struct efi_hii_keyboard_layout' is less aligned than 'efi_guid_t' and is usually due to 'struct efi_hii_keyboard_layout' being packed, which can lead to unaligned accesses [-Wunaligned-access]
<Tartarus>
efi_guid_t guid;
<Tartarus>
That's a feature.
<Tartarus>
I've done a pragma push/pop for now which I think is right, along with a comment, I'll cc you both when I post it all
Kwiboo has quit [Quit: .]
Kwiboo has joined #u-boot
monstr has quit [Remote host closed the connection]
<apalos>
Tartarus: yea UA is enabled when EFI is running
<apalos>
but I dont get the wanring tbh
<apalos>
when you add packed on a struct, the compiler is free to place that thing into *any* boundary
<apalos>
So it should emit code that's safe regardless no ?
vagrantc has joined #u-boot
<apalos>
ah that's probably because efi_guid_t is defined as 'aligned(8)'
mmu_man has quit [Ping timeout: 264 seconds]
<Tartarus>
Yeah, I am assuming clang is correct here
mmu_man has joined #u-boot
camus has quit [Remote host closed the connection]
camus has joined #u-boot
mmu_man has quit [Ping timeout: 260 seconds]
camus has quit [Remote host closed the connection]
prabhakarlad has joined #u-boot
camus has joined #u-boot
GNUtoo has quit [Ping timeout: 255 seconds]
prabhakarlad has quit [Quit: Client closed]
GNUtoo has joined #u-boot
redbrain has quit [Read error: Connection reset by peer]
mmu_man has joined #u-boot
redbrain has joined #u-boot
mmu_man has quit [Ping timeout: 268 seconds]
<sjg1_>
marex: Yes it is a Typlo and should be 'Tuple'
prabhakarlad has joined #u-boot
<FergusL>
marex hm.. so the diff of mine vs amberelec (one of the compatible "distros", based on libreelec, with a recent build) ends up longer than the dts themselves haha
<marex>
sjg1_: will you send a pytch fixing the typlo ?
guillaume_g has quit [Quit: Konversation terminated!]
<FergusL>
I thing diff got a little confused, the sorting helped I think it's not easy to get an idea. what stands out is that the amberelec one has a driver called "rksfc" (rockchip serial flash chip) while mainline is just "sfc", but I don't think it means anything interesting
<marex>
oh hum, phandles, yeah ... that is one thing which does suck
<marex>
but basically what you care about are UART and that is about it
mmu_man has joined #u-boot
<macromorgan>
SFC is the hardware that controls the flash chip (that SPI chip you're trying to boot off of)
<macromorgan>
Serial Flash Controller
<macromorgan>
it's basically an SPI bus that's optimized/dedicated to solely driving flash instead of doing other SPI things
<marex>
macromorgan: wouldnt the board print at least something in SPL ?
<marex>
macromorgan: at least some sign of life, even before anything else kicks in ?
<marex>
you should at least get the uboot banner if the SPL started
<macromorgan>
yes, you should
<macromorgan>
unless the TPL has the right header (so the BROM starts booting it) but is so broken it can't even output to serial. Rare, but possible.
<marex>
since FergusL has some prebuilt blob which does start, it could be compared to the newly built mainline uboot, right ?
<marex>
somehow
<marex>
hexdump maybe ?
<macromorgan>
did he flash anything to the SPI chip?
<macromorgan>
or is it still running the BSP bootloader?
<marex>
afaict it is still boot from SD card or whatever
<macromorgan>
IF it still has the BSP TPL and SPL stage, it would be running at 1.5M UART speed
<marex>
remember, I do not know anything about how the rockchip SoCs boot
<macromorgan>
right... basically it goes (if I remember correctly) eMMC, SPI, SDMMC, USB, then goes into a special maskrom mode
<macromorgan>
if it is finding a valid TPL/SPL stage on the SPI it will never try to boot from SDMMC
<macromorgan>
and if it's the BSP TPL/SPL it will be running at 1500000 baud
<macromorgan>
so if you're expecting 115200 you'll never see anything
<macromorgan>
BSP everything runs at 1500000 baud, and mainline everything (for the PX30/RK3326) runs at 115200 baud
<macromorgan>
if you drive the CS pin to 3.3v however it should bypass the SPI flash... if that's not working you can try grounding the clk pin.
<macromorgan>
or you can erase the SPI flash too
<marex>
FergusL: ^
<marex>
macromorgan: I assume you will see something on the UART, it would just be garbage if you have baudrate mismatch
marc2 has quit [Read error: Connection reset by peer]
<macromorgan>
lastly, if I recall correctly the BSP would also be "weird" in that the SPL stage would try to always boot from the SDMMC first. Of course it would be wonky because Rockchip does weird things with the devicetree that mainline doesn't do.
<macromorgan>
so if you do nothing BSP SPL will try to boot from mainline U-Boot on the SDMMC and not work properly/not work at all
<FergusL>
sorry for the slight misconceptions and wrong info before! and thanks for explaining
<FergusL>
so, I haven't flashed anything to the SPI chip and would rather not, so afaik yes I am still running BSP bootloader, if that indeed means the one that's put on the SPI chip by the manufacturer
<FergusL>
the SPI flash bypass by driving CS to 3.3 is indeed working and I get inside the u-boot shell (at 115200), so that's self compiled u-boot. But driving CS to 3.3 is tedious, i'd like to avoid that if possible
<FergusL>
all that is with an sdcard in. And I know it's possible without shorting CS to 3.3 because if I flash a non-mainline uboot to my sd card, start and interrupt u-boot over serial during boot and print the version, it's clearly the one from the sdcard and not the BSP bootloader (iirc odroid call it recovery)
<FergusL>
it's still unclear to me though if I'm doing the process correctly, https://forum.odroid.com/viewtopic.php?p=321094#p321094 I've followed along your message here, so I got rkbin, crated idbloader.img with the right miniloader.img from their repo, then the trust step, and then followed the steps for mainline u-boot (make odroid-go2_defconfig,
<FergusL>
make), and then flashing the 3 files at the given offsets: idbloader, u-boot-dtb, trust, I stop here and just insert the sdcard and try to boot. I will try at 1.5M but that'll be tomorrow!
<FergusL>
but just at that point, with CS to 3.3 it just works, at 115200, without CS to 3.3 I get 15-20 garbage characters and then nothing (then have to unplug/plug back battery to get it to boot again)
<marex>
those 15-20 characters might be the 1500000 Bdps which macromorgan mentioned ?
<FergusL>
big thanks to both of you for the help and understanding that I'm not too familiar with all that and I'm learning a lot along the way!
<marex>
if you upstreamed support for this board, it would be even better ;)
<macromorgan>
don't mess with idbloader and stuff, just leave 16MB empty at the beginning of your SD card. Then, you can flash the u-boot-rockchip.bin file by doing `dd if=u-boot-rockchip.bin of=/dev/mmcblk0 bs=512 seek=64 conv=notrunc`
<macromorgan>
make sure you have a valid Arm Trusted Firmware file and set it's absolute location as "BL31", then build U-Boot.