ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development - Did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait for an answer! - This channel is logged at https://oftc.irclog.whitequark.org/linux-sunxi
<LordKalma> this example shows different dts files for uboot and the kernel in the tree example
<LordKalma> but in this case it would be the same, right?
jernej has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
vagrantc has joined #linux-sunxi
<apritzel> yes, as the devicetree file is conceptually a hardware description, so should not be different between the software using it
<LordKalma> yeah, I find that example of a source tree for a BR2 external quite weird
<apritzel> we try to sync them from the kernel (where they get the best review) into U-Boot
<LordKalma> anyway, thanks again, I have to get some sleep :)
<LordKalma> thanks again for all the help, we'll talk more in the future, I'm sure :)
rajkosto has joined #linux-sunxi
jernej has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
moteen has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
moteen has quit [Ping timeout: 480 seconds]
cnxsoft has joined #linux-sunxi
rajkosto has quit [Read error: Connection reset by peer]
cnxsoft has quit [Remote host closed the connection]
cnxsoft has joined #linux-sunxi
chewitt has quit [Quit: Zzz..]
<jernej> LordKalma: another way to speed up kernel bisecting is to leave your image on SD card as-is and only update U-Boot script to load kernel over network (tftp in my case)
<jernej> naturally, U-Boot needs to support network, but that's usually the case most of the time
<jernej> you also have to disable kernel modules support and all drivers must be built-in, but that's acceptable for bisecting
moteen has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
bauen1_ has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
moteen has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
szemzoa has quit [Remote host closed the connection]
aggi has quit [Quit: connection closed.]
moteen has joined #linux-sunxi
montjoie_ has joined #linux-sunxi
apritzel has joined #linux-sunxi
montjoie has quit [Ping timeout: 480 seconds]
moteen has quit [Ping timeout: 480 seconds]
<LordKalma> With some nice copy-pasting from the official repos and other sources (thank you ST) I'm starting to get a basic image as I wanted: https://github.com/ruilvo/AetherX6100/blob/master/br2_external/configs/X6100_defconfig
<LordKalma> managed to build it once before I added the uboot stuff, didn't take _thaaat_ long
<LordKalma> It's building now. I'm not sure that using "BR2_TARGET_UBOOT_BOARD_DEFCONFIG="A33-OLinuXino"" will result in something that boots
<LordKalma> let's see
<LordKalma> what' do you think?
<LordKalma> Do you reckon I'd be able to understand the original defconfig used for building the "stock" firmware's u-boot from the built code?
<LordKalma> probably not
bauen1 has joined #linux-sunxi
aggi has joined #linux-sunxi
<LordKalma> DTC arch/arm/dts/sun8i-r16-x6100.dtb
<LordKalma> arch/arm/dts/sun8i-r16-x6100.dtb: ERROR (phandle_references): /soc@1c00000/mmc@1c10000: Reference to non-existent node or label "mmc1_pg_pins"
<LordKalma> any ideas why it complains?
<LordKalma> failed during the u-boot build
<LordKalma> interesting
<apritzel> LordKalma: what U-Boot version is this?
<apritzel> jernej: not sure he has Ethernet on that radio ...
<apritzel> LordKalma: if that is the DT I posted, you can't use this on U-Boot or older kernels as is
<apritzel> and especially not on older U-Boot versions (older as in: more than two months old)
<apritzel> that's what I dislike about buildroot: it encourages piling up hacks on top of tweaks
<LordKalma> apritzel, I realized the default version buildroot picked didn't have that
<LordKalma> 2022.01, not exactly old
<LordKalma> but yeah
gnarface has quit [Ping timeout: 480 seconds]
<LordKalma> changed to 2022.07.rc5 (latest available thing) and it works
szemzoa has joined #linux-sunxi
gnarface has joined #linux-sunxi
aggi has quit [Quit: connection closed.]
aggi has joined #linux-sunxi
<LordKalma> apritzel, okay, I'm getting onto something :D (I think)
<LordKalma> again thanks for the continued help, you all collectively have been amazing to me
<LordKalma> I do have a "next" question :p
machinehum1 has joined #linux-sunxi
<LordKalma> I copy pasted values from some other A33 defconfig from u-boot's repo
<LordKalma> that's all (probably?) wrong
<LordKalma> any suggestions on how I would be able to understand/discover the right configuration?
machinehum has quit [Ping timeout: 480 seconds]
aggi has quit [Quit: connection closed.]
aggi has joined #linux-sunxi
<apritzel> LordKalma: well, there is not too much in here (that is what I was after the whole time: upstreaming U-Boot support would be rather simple ...)
<apritzel> so I think I commented on some values earlier, like the DRAM frequency, you should copy what the existing port sets there currently
<apritzel> IIRC the frequency was shockingly low?
moteen has joined #linux-sunxi
<apritzel> LordKalma: how does does that config get you? That's probably enough for booting from SD, I guess?
<apritzel> you should add CONFIG_MMC_SUNXI_SLOT_EXTRA=2 to enable the eMMC (booting), and CONFIG_USB_EHCI_HCD=y and CONFIG_USB_OHCI_HCD=y to enable USB, should you need that in U-Boot
<LordKalma> and haven't tested if it works yet
<LordKalma> apritzel, for context, nobody has built u-boot for it yet, so nobody has a _defconfig
<LordKalma> "existing" ports extract u-boot with dd from the stock firmware and re-paste it into the sdcard
<LordKalma> I want to do away with that
<apritzel> yeah, but if you look at the other defconfigs, there are pretty simple, it's mainly some common A33 boilerplate, plus some features (USB, Ethernet, ...) you need
<apritzel> LordKalma: so all you need for building mainline U-Boot (on an already supported SoC!) is that DT and some version of defconfig that works
<apritzel> if you send that to the U-Boot mailing list, people can have a look and advice you on what's missing
<apritzel> getting display support in U-Boot would require more work, but is probably not really needed?
<apritzel> does the existing U-Boot enable the display?
moteen has quit [Remote host closed the connection]
<LordKalma> not sure, I don't where u-boot starts and ends
<LordKalma> *don't know, sorry
<LordKalma> I'll have to confirm turning it on connected to the serial port
<LordKalma> but I don't have it next to me
<LordKalma> the stock image does have a nice splash screen, dunno at what stage that is
szemzoa has quit [Remote host closed the connection]
<apritzel> *typically* a splash screen is done from U-Boot, but I don't know if that's the case here
szemzoa has joined #linux-sunxi
szemzoa has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
szemzoa has joined #linux-sunxi
szemzoa has quit [Remote host closed the connection]
szemzoa has joined #linux-sunxi
<LordKalma> how did you find out the ram speed btw?
moteen has quit [Remote host closed the connection]
aggi has quit [Quit: connection closed.]
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
szemzoa has quit []
<apritzel> I looked at their SPL disassembly
aggi has joined #linux-sunxi
moteen has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
<LordKalma> okay, so CONFIG_DRAM_CLK=384
<LordKalma> what about CONFIG_DRAM_ZQ
<LordKalma> what is it?
<LordKalma> (also, how did you disassembled the SPL? I'm interested :D)
apritzel_ has joined #linux-sunxi
<LordKalma> apritzel_, saw you reconnecting, I don't know if you saw, but I'm wondering how you disassembled the SPL, I would like to take a look as well
apritzel_ has quit [Ping timeout: 480 seconds]
<LordKalma> oh nope hahaha
moteen has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
<LordKalma> this is what I managed so far into the booting process
moteen has joined #linux-sunxi
cnxsoft has quit []
moteen has quit [Remote host closed the connection]
vagrantc has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
<apritzel> LordKalma: arm-linux-gnueabihf-objdump -D -b binary -m arm <binary SPL file>
<apritzel> then adding -Mforce-thumb for dump as Thumb2
<apritzel> I did the same again on something I actually compiled, to get a rough idea where to look at
<apritzel> the code to setup the DDR1 PLL had some characteristic pattern, and the addresses were similar, IIRC
<apritzel> so I traced that down in the self-compiled SPL first, using symbols, then re-traced my steps with the pure binary objdump
moteen has joined #linux-sunxi
<LordKalma> <binary SPL file> being that uboot_sdcard.bin we extracted?
apritzel_ has joined #linux-sunxi
<apritzel> yes
moteen has quit [Remote host closed the connection]
<apritzel> it would have been much easier to wait for you to dump the PLL clock register, though ;-)
<apritzel> for DRAM_ZQ: since all A33 boards use the same value, just go with that ...
apritzel_ has quit [Ping timeout: 480 seconds]
moteen has joined #linux-sunxi
aggi has quit [Ping timeout: 480 seconds]
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
moteen has quit [Remote host closed the connection]
hlauer has joined #linux-sunxi
moteen has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has quit []
evgeny_boger has quit [Remote host closed the connection]
evgeny_boger has joined #linux-sunxi
apritzel_ has joined #linux-sunxi
<LordKalma> well, I bet it would be much easier if I had any idea of what I'm doing :D
<LordKalma> apritzel_, there are some differences between the DTS you sent me and one directly decompiled...
<LordKalma> you don't have a usb1_vbus definition
<LordKalma> just usb1_vbus-supply = <&reg_vcc5v0>; on &usbphy
apritzel_ has left #linux-sunxi [#linux-sunxi]
apritzel has joined #linux-sunxi
<LordKalma> ah it's because it doesn't have a phandle?
<apritzel> LordKalma: because that is a nice distraction in the original DTB ;-)
<apritzel> yes
<apritzel> it's not referenced by anything, instead the usb1_vbus-supply refers to phandle 0x18, which is the static 5V supply
<apritzel> I remember I had two or three nodes like those left at the end, and then removed them
<LordKalma> you had a small mistake, just a copy paste bug, also
<LordKalma> decompiled says: regulator-min-microvolt = <0x23dbb0>; regulator-max-microvolt = <0x286f90>;
<LordKalma> while yours said "regulator-min-microvolt = <2350000>;regulator-max-microvolt = <2350000>;"
<LordKalma> a colleague picked that from the boot log: "1.239230] vdd-dll: Bringing 2500000uV into 2350000-2350000uV"
<LordKalma> and guess what?: https://i.gyazo.com/4c6f9a266f2c218f27cc4e315f1ca82a.png we have kernel booting
<LordKalma> the display is off, which I guess it to be expected, since nothing is configured
<LordKalma> but yeah, we have kernel boot from serial
<apritzel> does that matter? those unreferenced always-on regulators with ranges are fishy, I think
<apritzel> if they are used, they should be referenced
<apritzel> if they have no direct user in the DT, one would expect at least a fixed voltage
<LordKalma> that vdd-dll one is used
<apritzel> would be interesting to see what happens when the regulator-always-on is removed
<LordKalma> well, apparently no, it's not, actually, but oh well
<LordKalma> it made the board boot
<LordKalma> now, it doesn't find the soundcard, or turns on the display, or the lights on the buttons, or anything
<LordKalma> but that's another step, I guess
<apritzel> well, not really surprised, I don't see anything about LEDs or such in the DT
<apritzel> I guess they play with GPIOs directly, from userland? Or have something hardcoded, in their kernel?
<LordKalma> that's a good question
<LordKalma> for example, the guy that did the Armbian build created a "bypass" system so you can boot to the radio without removing the SD card
<LordKalma> he turns on the lights manually with that boot script
<apritzel> so it's PE15? I guess that should warrant an LED node in the DT then
<apritzel> are the buttons always lit, with the original kernel?
<LordKalma> they lit up somewhere during the boot process
<LordKalma> and some of them represent state
<LordKalma> it's more than just backlight
<LordKalma> I'm building the LCD panel driver as an external module, and it went to `/lib/modules/5.15.50/extra/panel-sitronix-st7701s.ko` and modprobe says nothing is loaded. That's also interesting
<apritzel> LordKalma: did you run depmod after copying the module?
<LordKalma> should be part of the buildroot's process
<apritzel> did you try to manually modprobe it? anything in dmesg?
<apritzel> for the key LEDs, I'd suggest to have a gpio-led node, with: function = LED_FUNCTION_KBD_BACKLIGHT; default-state = "on"; gpios = <&pio 4 15 GPIO_ACTIVE_HIGH>;
<apritzel> that should turn it on automatically, but still allows to turn it off
<LordKalma> I had to make linux-rebuild (buildroot thing) to get the DTB renewed, and I think it didn't rebuild the kernel module, maybe something to do with that
<LordKalma> I'll check tomorrow, I'm tired for today
<LordKalma> I'll do a clean build and see
hlauer has quit [Ping timeout: 480 seconds]
sunshavi has quit [Ping timeout: 480 seconds]
sunshavi has joined #linux-sunxi