dgilmore changed the topic of #fedora-riscv to: Fedora on RISC-V https://fedoraproject.org/wiki/Architectures/RISC-V || Logs: https://libera.irclog.whitequark.org/fedora-riscv || Alt Arch discussions are welcome in #fedora-alt-arches
bkeys has quit [*.net *.split]
warren has quit [*.net *.split]
sharkcz has quit [*.net *.split]
warren has joined #fedora-riscv
sharkcz has joined #fedora-riscv
bkeys has joined #fedora-riscv
tekkamanninja has joined #fedora-riscv
King_InuYasha has quit [Read error: Connection reset by peer]
King_InuYasha has joined #fedora-riscv
jcajka has joined #fedora-riscv
bkeys has quit [Remote host closed the connection]
bkeys has joined #fedora-riscv
bkeys has quit [Quit: bkeys]
bkeys has joined #fedora-riscv
Denis has joined #fedora-riscv
<Denis> hello all
<davidlt[m]> hi
<Denis> I have tried the latest WIP build of Fedora for Nezha D1, and it seems to be hard-coded to assume 2GB of RAM
<davidlt[m]> I don't think Fu Wei is online right now. He produced those disk images IIRC.
<Denis> which does not block me entirely from running the image on the board (it is possible using a much older kernel), but if anybody is interested to take a bug report, I can provide diagnostics
<davidlt[m]> You should fine that on StarFive GitHub repos.
<Denis> davidlt[m]: it looks like a different manufacturer, Nezha D1 is made by Allwinner
<davidlt[m]> Ops, sorry :)
<davidlt[m]> My brain went on the autopilot :D
<Denis> the wiki page that documents this is https://fedoraproject.org/wiki/Architectures/RISC-V/Allwinner
<davidlt[m]> I was reading about StarFive board and somehow everything became StarFive boards :)
<davidlt[m]> Those are also produced by Fu Wei.
<davidlt[m]> I am not sure where to file a bug report for it.
<Denis> davidlt[m]: it looks like the best next attempt would be during Beijing business hours then
bkeys has quit [Remote host closed the connection]
bkeys has joined #fedora-riscv
<tekkamanninja> yes, I am online
<tekkamanninja> this is fuwei speaking
<tekkamanninja> sorry for the my nickname
<tekkamanninja> Denis: sorry for the "hard-coded", this is in dtb
<Denis> oh, nice to meet you
<tekkamanninja> you can load different dtb for your board(1GB or 512MB)
<Denis> tekkamanninja: I tried that, it works as expected only if I boot the old kernel (5.4.61) with its own "aw" DT files via extlinux
<tekkamanninja> https://github.com/starfive-tech/Fedora_on_StarFive is out of date , I don't have time to maintain it , please just using our Image :
<Denis> for clarity, I use D1-1GB to run this: https://ci.tcpdump.org/#/workers/16
<tekkamanninja> yes, the new kernel doesn't support wifi and hdmi
<tekkamanninja> even RTC
<Denis> tekkamanninja: that's fine, this is one of several Buildbot workers, so they run headless anyway. only the networking is required
<tekkamanninja> yes, this is the latest one with ethernet enabled
<Denis> so the problem is, if I try to boot a newer kernel, it either does not boot or thinks it has 2GB of RAM
<tekkamanninja> with this image, wifi works on 5.4.61
<Denis> I can explain what I tried if you have time
<tekkamanninja> you just need to modify grub.conf in boot partition
<Denis> in theory, yes
<tekkamanninja> devicetree /dtb-5.16.0-rc3/allwinner/sun20i-d1-nezha-2g.dtb to devicetree /dtb-5.16.0-rc3/allwinner/sun20i-d1-nezha-1g.dtb
<tekkamanninja> have you tried ?
<Denis> yes, it boots and after booting it "sees" 2GB
<tekkamanninja> sorry , the one you have is dtb-5.16.0-rc2
<Denis> sed --in-place 's#\(devicetree .*\)/sun20i-d1-nezha.dtb#\1/sun20i-d1-nezha-1g.dtb#' /boot/grub.cfg
<tekkamanninja> OMG, it seems got info from u-boot, I only tried 2GB
<Denis> either the "1GB" DT file does not specify 1GB, or the kernel ignores that
<tekkamanninja> I need to check this with 512B
<Denis> on the u-boot note, u-boot claims 2GB upfront as well
<tekkamanninja> I need to check this with 512MB, I have one ,
<Denis> this is u-boot output: "DRAM: 2 GiB"
<tekkamanninja> could you try to build a new uboot by following https://fedoraproject.org/wiki/Architectures/RISC-V/Allwinner
<tekkamanninja> or I can build one for you, please let me know your email , I can send it to you
<Denis> whichever suits you, let me know
<Denis> one problem with the old 5.4.61 is the load average never goes below 1.0 and the system feels very slow
<Denis> the new 5.14.16 does not have this problem, but the RAM size issue blocks me from using it
<Denis> other than that, HDMI, WiFi, Bluetooth and other peripherals are irrelevant for the purpose, so long as the board boots from an SD card or even from USB, brings up Ethernet and runs as a server
<tekkamanninja> don't expect WiFi, Bluetooth can work, the driver is incompatible with upstream kernel , and no one have time to update it
<tekkamanninja> HDMI may work if I have some time
<Denis> yes, that's perfectly acceptable
<davidlt[m]> Yeah, Allwinner will be problematic for a long time
<tekkamanninja> for 1GB board
<tekkamanninja> davidlt[m]: yes, still
<tekkamanninja> just do a dd : dd if=u-boot-1GB.toc1 of=/dev/sdX bs=512 seek=32800
<tekkamanninja> into your SD, that should work, I have tried that
<tekkamanninja> Denis: :-) ^^
<tekkamanninja> I may need to add more config for different ddr size
bkeys has quit [Remote host closed the connection]
bkeys has joined #fedora-riscv
bkeys has quit [Client Quit]
bkeys has joined #fedora-riscv
<Denis> alright, the new bootloader should be in the right place in the middle of unallocated disk space, and there is a backup of the previous contents, so I am ready to reboot
<tekkamanninja> I have tried it on my board , that works
<Denis> this time u-boot says "DRAM: 1 GiB"
<tekkamanninja> and you just need to wait kernel boot up
<tekkamanninja> [ 0.000000] Memory: 948320K/1046528K available (11523K kernel code, 6566K rwdata, 6144K rodata, 2544K init, 604K bss, 98208K reserved, 0K cma-reserved)
<tekkamanninja> on my board
<Denis> it is paused now. what is the right thing to do to boot 5.14.16: give it sun20i-d1-nezha.dtb as it was originally or sun20i-d1-nezha-1g.dtb?
<Denis> grub.cfg still has sun20i-d1-nezha-1g.dtb, I guess
<tekkamanninja> you can ignore this, since ddr size comes from uboot
<Denis> okay, trying with whatever is there
<tekkamanninja> o, 5.14.16 can not boot by grub
<tekkamanninja> because it is lack of efi stub support
<Denis> 5.16.0-rc2 it says
<tekkamanninja> yes, grub only boot mainline kernel(with patches) for now
<Denis> 5.14.16 is the newest from the disk image I had before today's upgrade (September version)
<davidlt[m]> 5.14.X has EFI STUB support in the kernel
<Denis> anyway, it is booting and in a minute should be up
<davidlt[m]> EFI is available within the kernel for a long time now
<tekkamanninja> sorry , typo , I mean 5.4.61
<davidlt[m]> Yeah, that should be too old.
<tekkamanninja> 5.14.16 can boot with grub
<Denis> 1GB RAM it is
<tekkamanninja> but I didn't put 5.14.16 into image , so ... that maybe your own knernel I guess
<Denis> hmm, something isn't right, because the kernel says it is 5.4.61
<Denis> let me watch the boot closely
<tekkamanninja> stop uboot, by v
<tekkamanninja> then , "run boot_grub"
<Denis> yes, that's exactly what I did, let me check the scrollback
<tekkamanninja> you can see grub menu
<Denis> as it turns out, GRUB started, displayed the menu, started to load the kernel, then it was a hardware reset
<Denis> which then defaulted to extlinux and the old 5.4.61 kernel
<tekkamanninja> ha , my friend have checked the image , "run boot_grub" should work , I guess, can you try it again ?
<tekkamanninja> I have rebased the kernel to 5.16.0-rc3 , works well for now , you can build it by nezha_fedora_defconfig
<Denis> as it turns out, grub.cfg has "devicetree /aw_nezha_d1_1G.dtb" from one of my previous attempts
<tekkamanninja> ah , you are using wrong dtb
<Denis> let me set it to the original filename and try again
<tekkamanninja> please try devicetree /dtb-5.16.0-rc2/allwinner/sun20i-d1-nezha-1g.dtb
<Denis> okay
<Denis> I am using "/dtb-5.16.0-rc2/allwinner/sun20i-d1-nezha-1g.dtb" to match the filesystem layout
<tekkamanninja> yes
<Denis> I meant "/dtbs/5.16.0-rc2+/allwinner/sun20i-d1-nezha-1g.dtb"
<tekkamanninja> yes
<tekkamanninja> sorry , that is my test PATH,
<tekkamanninja> you are right
<tekkamanninja> . /dtbs/5.16.0-rc2+/allwinner/sun20i-d1-nezha-1g.dtb is right
<Denis> looks like this time it managed to start booting instead of resetting
<Denis> I am capturing a log of that as well, in case you need it
<Denis> in fact, it should not be difficult to provide you with serial console access, if it helps
<tekkamanninja> have you got into login:
<Denis> yes. I was delayed by the fact it now has a different MAC address and a different DHCP lease
<Denis> it is kernel 5.16.0-rc2+ and it sees 1GB of RAM, which is success
<Denis> also load average is below 1.0, which is useful
<tekkamanninja> :-)
<Denis> tekkamanninja: thank you for the help, is there any other testing to do before you are confident about the bugfix?
<Denis> I can try booting with sun20i-d1-nezha.dtb if it helps
<Denis> it does not say the amount of RAM in the filename, is it because it is supposed to auto-detect, or because 2GB is the default?
<tekkamanninja> no, I think I should update uboot/linux repo in my github, Great thanks for letting me kwon there is a bug in my wiki and image :-)
<tekkamanninja> sun20i-d1-nezha.dtb is the one without ddr size info
<Denis> is it supposed to just work?
<tekkamanninja> so this info is decided by uboot in build time
<tekkamanninja> so for booting kernel , sun20i-d1-nezha.dtb should work
<Denis> let me test whilst everything is hot
<tekkamanninja> I did not notice that , thanks to you to let me know :-)
<tekkamanninja> sure , thanks :-)
<tekkamanninja> sun20i-d1-nezha.dtb == sun20i-d1-nezha-1g.dtb == sun20i-d1-nezha-2g.dtb == sun20i-d1-nezha-512m.dtb
<tekkamanninja> those should be the same
<tekkamanninja> I only tested 2G , my bad :-(
<Denis> devicetree sun20i-d1-nezha.dtb boots OK and the amount of RAM is 1GB
<tekkamanninja> Denis: I need to sleep for RISC-V open hour in 8 hours, sorry, ttyl :-) Great thanks for your testing :-)
<tekkamanninja> 3am for me now
<Denis> contents is different in all four .dtb files, as far as sha1sum sees it
<Denis> size is the same for -1g, -2g and -512m
<tekkamanninja> yes, you can see the code in my uboot repo
<Denis> tekkamanninja: thank you very much, when would be a good time to talk later?
<tekkamanninja> ping me on linkedin : https://www.linkedin.com/in/wei-fu-tekkamanninja/
<tekkamanninja> or slack
<Denis> alright, talk to you later
<tekkamanninja> Wei Fu on slack
<Esmil> tekkamanninja: speaking of u-boot. i was preparing an sd-card for the starlight board yesterday, and i noticed that having an EFI partition with an efi-executable at the standard location /EFI/BOOT/BOOTRISCV64.EFI doesn't seem to work.
<Esmil> the Fedora image has grub at /EFI/fedora/grubriscv64.efi, but it would be great if the standard path worked too
<tekkamanninja> Esmil: Great to see you here
<tekkamanninja> which image you are using ?
<tekkamanninja> for starlight board, we are alway using grub to boot kernel
<Esmil> Right, but not everyone is using the fedora image. So it would be nice if u-boot would just default to load the efi-executable at the standard location
<Esmil> i just created the efi and root partitions myself and bootstrapped my own root filesystem
<tekkamanninja> ah, I got your point, this depends on Image boot(partition)/boot/uEnv.txt
<tekkamanninja> if the image is for debian/gentoo/arch ..... , they should modify uEnv.txt in their own image
<Esmil> hmm.. bit this file is not in the latest fedora image, so there must be some default built into u-boot
<Esmil> i just think this built-in default should be the distro-neutral efi-defined standard path
<tekkamanninja> yes, in a config file
<tekkamanninja> they can change it by setevn and saveenv in to flash
<Esmil> right it's definitely possible to change. again i just think the default should be what efi-defined path
<tekkamanninja> partition info for uEnv.txt is set in uboot, but I will fix it ASAP, I will scearch the file instead of hard-coding the partition
<Esmil> cool, thanks
<tekkamanninja> yes, you are right , I should fix it in uboot header file
<Esmil> yes, i think that's the best place *thumbs up*
<tekkamanninja> include/configs/starfive-jh7100.h
<tekkamanninja> #define STARLIGHT_FEDORA_BOOTENV \
<tekkamanninja> "bootdir=/boot\0" \
<tekkamanninja> "bootenv=uEnv.txt\0" \
<tekkamanninja> "mmcdev=0\0" \
<tekkamanninja> "mmcpart=3\0"
<tekkamanninja> there is the place I should fix
<tekkamanninja> I will fix ASAP , will let you kown
<tekkamanninja> Esmil: ：-）
<tekkamanninja> Esmil: :-)
<Esmil> Thanks
<davidlt[m]> I wonder how it works, because I don't see anything Fedora specific.
<tekkamanninja> davidlt[m]: it import uEnv.txt frist ,
<tekkamanninja> bootcmd is in uEnv.txt
<davidlt[m]> I mean most boards don't support uEnv.txt
<tekkamanninja> so you can do whatever you want in uEnv.txt
<tekkamanninja> sysboot?
<tekkamanninja> some board can not load file from storage ???
<davidlt[m]> no, Unleashed, Unmatched, etc. don't have uEnv.txt support
<tekkamanninja> uEnv.txt just a file or a env storage
<tekkamanninja> davidlt[m]: we may can update the uboot to make it supported
<davidlt[m]> Yes, but there is no generic "uEnv.txt" support in U-Boot
<davidlt[m]> Those are board specific and not all the boards support it (most don't)
<tekkamanninja> Unmatched uboot even support ssd in M.2
<davidlt[m]> Yes, but that's a different thing.
<davidlt[m]> But I wonder in general how it works
<davidlt[m]> I don't see anything distro specific in U-Boot and there aren't any Fedora specific patches.
<tekkamanninja> we can import env from SD or other storage , because uboot(firmware) is board specific , right ?
<Esmil> tekkamanninja: oh, i see now what you mean. that file hardcodes that u-boot looks at mmcblk0p3 for the uEnv.txt
<tekkamanninja> Esmil: yes
<davidlt[m]> Typically uEnv.txt is the same as extlinux.conf, which tends to be mmc 0:0
<tekkamanninja> Esmil: that is wrong , I should scearch uEnv.txt file in SD file instead of hard-coding
<Esmil> I guess that's fine, but it it's not found then it would be great if it would fall by to just trying the standard /EFI/BOOT/BOOTRISCV64.EFI
<Esmil> tekkamanninja: yes, that would be good too
<Esmil> *fall back to
<tekkamanninja> davidlt[m]: yes
<davidlt[m]> Distroboot command will do: "efi/boot/"BOOTEFI_NAME"
<davidlt[m]> #define BOOTEFI_NAME "bootriscv64.efi"
<tekkamanninja> where is the "uEnv.txt" is board specific , I guess
<Esmil> davidlt[m]: yeah, so I guess I'm just asking for jh7100 u-boot to be more distroboot-like ;)
<tekkamanninja> Esmil: yes,
<davidlt[m]> I wonder how BOOTX64.EFI and gets to grubx64.efi
<tekkamanninja> davidlt[m]: ah, yes, you are right, let me fix it and let you and Esmil know this ASAP
<davidlt[m]> I wonder if bootriscv64.efi is kinda a shim that later loads grub efi or something
<tekkamanninja> I should use Distroboot
<Esmil> tekkamanninja: that be great if you can make that work, yes
<tekkamanninja> I knew there is a command "Distroboot"
<tekkamanninja> Esmil: yes, I will use that instead of my ugly hack :-)
<tekkamanninja> davidlt[m]: thanks for your info , that is helpfull
<davidlt[m]> ah, on x86_64 /boot/efi/EFI/BOOT/BOOTX64.EFI is a shim
<tekkamanninja> davidlt[m]: Esmil: see you guys in riscv open hours soon, I need to go to bad now
<tekkamanninja> glad to see you are all here :-)
<Esmil> tekkamanninja: oh yeah. if you're in china it must be past midnight. sleep well ;)
<tekkamanninja> 3:40am
<davidlt[m]> go get some sleep :)
jcajka has quit [Quit: Leaving]
<tekkamanninja> davidlt[m]: going to sleep now, Great thanks for your works(rocks) BTW
bkeys has quit [Remote host closed the connection]
bkeys has joined #fedora-riscv
tekkamanninja has quit [Ping timeout: 256 seconds]
tekkamanninja has joined #fedora-riscv
drewfustini has quit []
drewfustini has joined #fedora-riscv
ahs3 has quit [Remote host closed the connection]
nb has quit [Read error: Connection reset by peer]
nb has joined #fedora-riscv