Open MichaIng opened 1 year ago
lgray
commented
1 year ago Hi, just updated the bootloader and got dietpi running on my VF2, thanks a lot for this! One first major issue is that I only see half the amount of RAM that's available on my board (8 GB model). If I use the starfivetech debian image the full amount shows up, but both armbian and dietpi show half that! Any pointers would be greatly appreciated!
MichaIng
commented
1 year ago Thanks for the info, I read about this on https://forum.rvspace.org. @StephanStS your's is definitely a 4 GiB model, right?
I did already rebase the kernel onto latest upstream 5.15.y, which only required trivial conflict resolving. Will try a build later today. Then will have a look at known fixes for HDMI, e.g. here: https://github.com/hexdump0815/linux-starfive-visionfive2-kernel/tree/main/misc.vf2/patches
MichaIng
commented
1 year ago Have you updated the SPI bootloader? Some open issues state that it has been fixed since a while:
apt install mtd-utils
curl -fLO 'https://github.com/starfive-tech/VisionFive2/releases/download/VF2_v2.10.4/u-boot-spl.bin.normal.out'
curl -fLO 'https://github.com/starfive-tech/VisionFive2/releases/download/VF2_v2.10.4/visionfive2_fw_payload.img'
flashcp -v u-boot-spl.bin.normal.out /dev/mtd0
flashcp -v visionfive2_fw_payload.img /dev/mtd1
rm u-boot-spl.bin.normal.out visionfive2_fw_payload.imgYes I updated the bootloader and fw-payload before installing dietpi. What's the best way I can check the versions of uboot / fw-payload just to make sure?
MichaIng
commented
1 year ago Ah okay, indeed not fixed when not using the 4 partitions layout and uEnv.txt to run different boot commands: https://github.com/starfive-tech/VisionFive2/issues/20#issuecomment-1426529552
I'll check where the U-Boot environment is located, so we can adjust it to apply the needed visionfive2_mem_set and also enable eMMC boot (which AFAIK currently does not work).
congocongo
commented
1 year ago @MichaIng Ethernet does not work on hardware rev 1.2a, but it works fine on 5.15.0-starfive kernel
MichaIng
commented
1 year ago Many thanks for testing and reporting. Did you test both Ethernet ports? It works fine on revision 1.3 here, but not sure whether on both Ethernet ports. @StephanStS could you test switching the port, after
sed -i 's/eth0/eth1/' /etc/network/interfacesAnd to compare:
The end is bringing up the second port formally, however, without cable attached and actual data transfer tested yet.
congocongo
commented
1 year ago A second eth is YT8512B, not YT8531 on rev 1.2a
congocongo
commented
1 year ago compare it with vendor's build:
MichaIng
commented
1 year ago And did you test using eth1 on your image?
Yours and our logs match nearly 100%, the only difference is that somehow in your case eth0 is identified as 100Mbps adapter and in our case as well as in your case with vendor kernel as 1Gbps adapter (which is of course correct). I have somehow the impression that there is an issue with dealing our link attributes with the router. Also the link goes down after some minutes, while is is up at first. Just to rule that out, does it help to detach and reattach the cable, then:
ifdown eth0
ifup eth0
sleep 5
ping 192.168.88.1And another test: Does it help to add stmmaceth=chain_mode:1 to the end of the kernel command-line (append line) in /boot/extlinux/extlinux.conf and reboot to apply the change? I didn't fully understand the purpose of this option and on our test system it didn't make any difference (I also ran benchmarks), so I removed it compared to StarFive's Debian images.
congocongo
commented
1 year ago I just copied fresh device tree from vendor's image and now it works. Only first eth is avaliable, looks like there is no driver for YT8512B in kernel. rev 1.2a was supplied with YT8531(1Gb)/YT8512B(100Mb) PHY on board.
MichaIng
commented
1 year ago Is this the same with the StarFive image?
Support for this chip was added here: https://github.com/MichaIng/linux/commit/e036d0777cbbc975615105f37b6d6b82257ed62d Then, without removing the support declaration at the top of the file, "inverted" here (whatever this means, since code was only moved around, not really removed, from what I see): https://github.com/MichaIng/linux/commit/3c9ef2d35c69c6f388701bd4b019817d83f3cd99
These commits are from StarFive kernel repository, so should be the same there.
Also the device tree should be identical, at least the raw dts is 🤔.
congocongo
commented
1 year ago It works on Starfive. And I copied dtb from this release https://forum.rvspace.org/t/visionfive-2-debian-image-202302-released/2132 from folder 202302
MichaIng
commented
1 year ago I've no idea then. The device tree source and the Ethernet driver source are 100% identical and it works well on V1.3. If on your V1.2 neither of both Ethernet adapters work with the device tree from our build, something in mainline Linux 5.15.y must have changed, outside of those drivers and device tree, but affecting them on build time. And this must affect V1.2 only, V1.3 not, even for the Ethernet adapter which uses the same chip. Very strange.
Just to be sure: You copied the jh7110-visionfive-v2.dtb (and only this!) from the latest StarFive Debian image and installed it on our image to /usr/lib/linux-image-visionfive2/starfive/jh7110-visionfive-v2.dtb? Did you run a diff on them to see whether there is an actual difference? Not sure whether builds are reproducible and may contain compiler/environment related differences though.
And also please assure you can reliably trigger the issue by swapping the device trees back and forth and that it is not a coincidence while the issue is unrelated to the device tree, as searching through possibly affecting upstream 5.15.y commits is time consuming as I have no idea where to start 🤔.
MichaIng
commented
1 year ago Update can be applied via:
cd /tmp
curl -O 'https://dietpi.com/downloads/binaries/linux-image-visionfive2.deb'
dpkg -i linux-image-visionfive2.deb
rm linux-image-visionfive2.deb/dev/pty* legacy pseudo terminal devices/dev/hvc* hypervisor virtual console devicesdietpi-preboot or cpufrequtils change it in userland)DietPi (only relevant until the init system changes it in userland)fw_printenv now generally can find it at /dev/mtd2Check out the source code here: https://github.com/MichaIng/linux I'll keep rebasing all changes onto latest upstream Linux 5.15.y release as well merging commits from the StarFive repo.
congocongo
commented
1 year ago Will try this kernel. Maybe better to wait when they send patches to upstream? They are actively do it now:
https://lore.kernel.org/lkml/?q=JH71x0
btw I decompiled dtb files:
congocongo
commented
1 year ago I tried 5.15.102 from your deb package. Still wrong ethphy settings in dtb file. btw if I'll copy starfive's dtb file it will broke pcie driver, your dtb settings for pcie is correct (on 5.15.102).
MichaIng
commented
1 year ago Okay, so all these phandle properties are internal addresses generated at build time, counted up for every added node. Since our device tree has two additional nodes (probably related to https://github.com/MichaIng/linux/commit/85034f1), the addresses are up to 2 larger. You can also see the addresses with <...> on other properties changed the same way as the related phandle property it aims to point to.
Interesting is this part:
@@ -1620,10 +1601,10 @@
ethernet-phy@0 {
rxc_dly_en = <0x01>;
tx_delay_sel_fe = <0x05>;
- tx_delay_sel = <0x0a>;
- tx_inverted_10 = <0x01>;
- tx_inverted_100 = <0x01>;
- tx_inverted_1000 = <0x01>;
+ tx_delay_sel = <0x09>;
+ tx_inverted_10 = <0x00>;
+ tx_inverted_100 = <0x00>;
+ tx_inverted_1000 = <0x00>;
};
};
@@ -1660,10 +1641,10 @@
ethernet-phy@1 {
tx_delay_sel_fe = <0x05>;
- tx_delay_sel = <0x00>;
+ tx_delay_sel = <0x09>;
rxc_dly_en = <0x00>;
- tx_inverted_10 = <0x01>;
- tx_inverted_100 = <0x01>;
+ tx_inverted_10 = <0x00>;
+ tx_inverted_100 = <0x00>;
tx_inverted_1000 = <0x00>;
};
};Our device tree matches StarFive sources: https://github.com/starfive-tech/linux/blob/JH7110_VisionFive2_devel/arch/riscv/boot/dts/starfive/jh7110-visionfive-v2.dtsi#L593-L619 These have been changed here: https://github.com/starfive-tech/linux/commit/b516027b3e and here: https://github.com/starfive-tech/linux/commit/4ea57bb614 last November.
I am pretty disturbed by the fact that obviously the StarFive device tree (likely the whole kernel) does not match their kernel sources, respectively is older than the sources from last November. I also found the commit for the additional two nodes now, from last month: https://github.com/starfive-tech/linux/commit/2757ebeaf3
The one commit even states that it is for JH7110B+YT8531PHY while YT8512B obviously requires the old values. So they broke it intentionally. Since their Debian image works on the new revision as well, not sure about the benefit of the new values, and especially not sure why they e.g. did not add a new device tree for A12 (as they exist for A10 and A11), or set those values somehow in the drivers/variable if possible, instead of fixed in the device tree.
Probably the A12 revision was so rare that it wasn't seen important to keep supporting it 🤔.
The issue may be reported here: https://github.com/starfive-tech/linux/issues But lately StarFive is not reacting to issues or pull requests on their repo.
MichaIng
commented
1 year ago Since I found this valuable information, here the upstream plan and status page: https://rvspace.org/en/project/JH7110_Upstream_Plan
All upstream mails/patches are linked, transparent to follow, including suggested changes by reviewers etc. Very interesting and looks great how upstreaming all relevant parts is driven.
congocongo
commented
1 year ago @MichaIng Sorry for the delay in your response. I saw this plan. As I told before, better to wait a pair months when they will finish the most significant parts.
MichaIng
commented
1 year ago Wait with what? We have a board and we want to add/polish RISC-V support for DietPi, detect and reports related bugs in Debian etc, so we cannot/do not want to wait for upstream support to have fully finished 😉. For end users who just want a stable system, RISC-V SBCs in general are completely unsuitable, of course, but we are developers 😃.
As of the Ethernet issue: I fear, unless someone reports and pushes the topic, this won't be resolved, since it broke only for an old rarely shipped revision. Any official docs you find are about V1.3. As said, the change looks intentional, not like a mistake, and it is not a bug in the code where Linux maintainers would care about.
The only thing we could do is to create a dedicated device tree, respectively an overlay, which reverts exactly the above parts. We could even enable it automatically at first boot, if the revision can be detected from within the system?
congocongo
commented
1 year ago Well, you don’t need a dedicated device tree here. They do modifications using the u-boot scripts before the kernel.
I guess the root of the problem with Ethernet and correct memory size detection is a hardcoded partitioning schema in the u-boot's scripts. They use 0 and 1 partition for OpenSBI/u-boot images, second partition for EFI/boot and third for root. Something may be wrong with u-boot scripts with one partition.
Disk /dev/mmcblk0: 57.95 GiB, 62226694144 bytes, 121536512 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A8D55636-C016-4B30-864A-FE61B85F33D9
Device Start End Sectors Size Type
/dev/mmcblk0p1 4096 8191 4096 2M HiFive BBL
/dev/mmcblk0p2 8192 16383 8192 4M HiFive FSBL
/dev/mmcblk0p3 16384 221183 204800 100M EFI System
/dev/mmcblk0p4 221184 121534463 121313280 57.8G Linux filesystemAh good to see that. And yes, bootcmd_distro does not run in our case. Looks like its time to do some PRs on their U-Boot script. This hardcoded intended partitioning is very unnecessary. The U-Boot default drive scans work pretty well, as can be seen with the fallback that is done on our image. So it would be perfectly possible to just scan through all drives and partitions for uEnv.txt and extlinux and do those dynamic device tree adjustments in every case. Additionally functional default RAM addresses for a compressed kernel make sense, so this does not need to be set in uEnv.txt, making it obsolete (while it's nice to have the option for environment adjustments), respectively it allows us to use a compressed kernel image.
I fixed a bug which caused a wrong U-Boot environment address: https://github.com/MichaIng/linux/commit/dbd2367 With this we can write an own environment, replacing StarFive's default. I've not yet tested it, but if this works, we can do that on first boot as well to have things fixed. This also allows eMMC usage (as long as the driver in U-Boot is working) which is currently not working either because of the hardcoded device IDs in the env.
MichaIng
commented
1 year ago Actually, while this U-Boot script commands run with common partitioning, there is also the following which should do the same before even running bootcmd: https://github.com/starfive-tech/u-boot/blob/JH7110_VisionFive2_devel/configs/starfive_visionfive2_defconfig#L31-L32
CONFIG_USE_PREBOOT=y CONFIG_PREBOOT="run chipa_set_uboot;run mmcbootenv"
In the environment we see related preboot variable:
preboot=run chipa_set_uboot;run mmcbootenvchipa_set_uboot=fdt addr ${uboot_fdt_addr};run chipa_set;chipa_set=if test ${chip_vision} = A; then run chipa_gmac_set;fi;chipa_gmac_set=fdt set /soc/ethernet@16030000/ethernet-phy@0 tx_inverted_10 <0x0>;fdt set /soc/ethernet@16030000/ethernet-phy@0 tx_inverted_100 <0x0>;fdt set /soc/ethernet@16030000/ethernet-phy@0 tx_inverted_1000 <0x0>;fdt set /soc/ethernet@16030000/ethernet-phy@0 tx_delay_sel <0x9>;fdt set /soc/ethernet@16040000/ethernet-phy@1 tx_inverted_10 <0x0>;fdt set /soc/ethernet@16040000/ethernet-phy@1 tx_inverted_100 <0x0>;fdt set /soc/ethernet@16040000/ethernet-phy@1 tx_inverted_1000 <0x0>;fdt set /soc/ethernet@16040000/ethernet-phy@1 tx_delay_sel <0x9>However, obviously it does not work in your case, not sure why... Ah wait, this cannot work before the device tree is even loaded, respectively this applies it for U-Boot internal device tree, but not for the one which finally boots. This is the reason they have the device tree loading parts in the env.
Actually
set_fdt_distro=if test ${chip_vision} = A; then if test ${memory_size} = 200000000; then run chipa_gmac_set;run visionfive2_mem_set;fatwrite mmc ${fatbootpart} ${fdt_addr_r} /dtbs/${fdtfile} ${filesize};else run chipa_gmac_set;run visionfive2_mem_set;fatwrite mmc ${fatbootpart} ${fdt_addr_r} /dtbs/${fdtfile} ${filesize};fi;else run visionfive2_mem_set;fatwrite mmc ${fatbootpart} ${fdt_addr_r} /dtbs/${fdtfile} ${filesize};fi;this rewrites the device tree binary on every boot, which I do not like at all. But reasonably this is the only way to have this parts dynamic as extlinux and common U-Boot scripts (re-)load the device tree and would hence overwrite any previous change. As long as there is no way to add commands to extlinux itself to adjust the device tree after it was loaded, or adjusting these values in userland, I'm going with the overlay route, which seems much cleaner to me than requiring write access and rewriting something essential like the device tree file on every boot. This allows vast cleanup and much simpler and complete (looping through all drives and partitions, regardless which filesystem, checking for efi>extlinux>boot.scr and booting with the first match.
MichaIng
commented
1 year ago @congocongo Could you show the serial number of your VF2, respectively the first block?
cat /proc/device-tree/serial-numberMine starts with VF7110B1, which likely means VisionFive JH7110 B1 revision, which matches the chip_vision of the U-Boot env. If it starts with VF7110A in your case, I think we found the needed identifier.
congocongo
commented
1 year ago yes.
VF7110A1-2250-D008E000-00000540
MichaIng
commented
1 year ago Great!
Could you test this:
apt install device-tree-compiler
cat << '_EOF_' > dietpi-visionfive2-A12.dts
/dts-v1/;
/plugin/;
/ {
compatible = "starfive,visionfive-v2", "starfive,jh7110";
fragment@0 {
target = <ðernet0>;
__overlay__ {
tx_delay_sel = <0x9>;
tx_inverted_10 = <0x0>;
tx_inverted_100 = <0x0>;
tx_inverted_1000 = <0x0>;
};
};
fragment@1 {
target = <ðernet1>;
__overlay__ {
tx_delay_sel = <0x9>;
tx_inverted_10 = <0x0>;
tx_inverted_100 = <0x0>;
tx_inverted_1000 = <0x0>;
};
};
};
_EOF_
dtc -I dts -O dtb -o /boot/dietpi-visionfive2-A12.dtbo dietpi-visionfive2-A12.dts
G_CONFIG_INJECT 'fdtoverlays[[:blank:]]' 'fdtoverlays /boot/dietpi-visionfive2-A12.dtbo' /boot/extlinux/extlinux.conf 'fdt[[:blank:]]'This might not be sufficient, as the U-Boot environment lacks the fdtoverlay_addr_r variable, but let's at least give it a shot. I'll otherwise add fw_setenv + config anyway to allow (and do) adding/setting some variables, also to add support for booting from eMMC, M.2 and USB.
congocongo
commented
1 year ago does not work
[FAILED] File does not exist or cannot be written to by current user
Please verify the existence of the file $3
fdt[[:blank:]]
Retry with proper permissions or apply the setting manually:
fdtoverlays /boot/dietpi-visionfive2-A12.dtboWhoops, I forgot the filename in the last command 😄:
G_CONFIG_INJECT 'fdtoverlays[[:blank:]]' 'fdtoverlays /boot/dietpi-visionfive2-A12.dtbo' /boot/extlinux/extlinux.conf 'fdt[[:blank:]]'@lgray Can you show your serial number as well?
cat /proc/device-tree/serial-numberProbably the 3rd block is about the RAM size.
@congocongo Does yours actually have 8 GiB RAM (while only 4 GiB are usable currently)?
congocongo
commented
1 year ago @congocongo Does yours actually have 8 GiB RAM (while only 4 GiB are usable currently)?
yes 8Gb with 4Gb visible
MichaIng
commented
1 year ago Great, confirmed here as well: http://forum.rvspace.org/t/dietpi-os-for-visionfive-2/2356/13?u=michaing
So to enable 8 GiB, the following device tree overlay can be tested:
apt install device-tree-compiler
cat << '_EOF_' > /boot/dietpi-visionfive2-8GB.dts
/dts-v1/;
/plugin/;
/ {
compatible = "starfive,visionfive-v2", "starfive,jh7110";
fragment@0 {
target-path = "/memory@40000000";
__overlay__ {
reg = <0x0 0x40000000 0x2 0x0>;
};
};
};
_EOF_
dtc -I dts -O dtb -o /boot/dietpi-visionfive2-8GB.dtbo /boot/dietpi-visionfive2-8GB.dts
G_CONFIG_INJECT 'fdtoverlays[[:blank:]]' 'fdtoverlays /boot/dietpi-visionfive2-8GB.dtbo' /boot/extlinux/extlinux.conf 'fdt[[:blank:]]'Same as with the Ethernet fix, probably this only works after adding an fdtoverlay memory addresses to the U-Boot environment, but lets test without this first.
And I need to find out how to add multiple device trees. Not sure whether they can be just added one after another to the same fdtoverlays line, or whether multiple such lines are supported.
MichaIng
commented
1 year ago Btw, default addresses for device tree overlays as well as compressed kernel are coming with StarFive's next bootloader release:
As we already have a dietpi-config option to update the bootloader, we can offer this on first boot with the info that this enables support for 8 GiB and Ethernet on A1.2 revision.
I'll do some tests this weeks for own U-Boot env overrides, since e.g. eMMC and M.2 boot still do not work:
chip_vision, which depend on the actual hardware model, are always provided by U-Boot, even if not defined in the override env address space. Otherwise we would break the ability for U-Boot itself to fix Ethernet and RAM size for its own device tree (the one loaded by U-Boot, not the one loaded for the OS).
aragubas
commented
1 year ago Hi, I was having issues booting the official debian image from StarFive itself, this is the only debian image that boots on my StarFive VisionFive 2 xD here are the issues that I noticed:
the model I have is the 8GB model with the dual ethernet ports
MichaIng
commented
1 year ago Many thanks for your feedback!
Included wifi adapter cannot connect to 5GHz SSID's (but does connect to 2.5GHz SSID's)
That is known, that adapter, even that it is declared as Wi-Fi 6 adapter, does not support 5 GHz: https://forum.rvspace.org/t/ecr6600u-firmware/2368
Included wifi adapter doesn't scan available wifi networks
Ah that is bad. So both commands do not work?
iw dev wlan0 scan
iwlist wlan0 scanWhat happens? Do they hang, report an error or just nothing?
XFCE Desktop doesn't boot, X11 crashes with error (cannot find starfive-dri)
Is it this error? https://forum.rvspace.org/t/failed-to-open-starfive-usr-lib-dri-starfive-dri-so/2325
However, in our case it generally worked to start a desktop. How did you try it? startx or one of the dietpi-autostart options, or starting LightDM with its service?
@StephanStS I know you're busy the next days, so just for backlog when you find time to retest a desktop with latest kernel (already installed). And if the strange colour change happens, the xrandr colour format change from here could be tested.
APT takes a looong time when "Reading packages lists..."
In dietpi-config > Advanced Options > APT you can (re-)enable the APT cache and disable APT list compression. Also cache, lists and the dir for downloaded DEB packages (before they are installed) can be moved to RAM. On DietPi, other than Debian, the APT cache is disabled by default and lists are left xz-compressed, which radically reduces disk writes on every apt update call, but also quite significantly slows it down.
the model I have is the 8GB model with the dual ethernet ports
But only 4 GiB are currently shown, e.g. in htop, right? Can be currently manually solved: http://forum.rvspace.org/t/dietpi-os-for-visionfive-2/2356/15?u=michaing
But with next StarFive bootloader release, we'll implement this fix (as well as A1.2 variant Ethernet) to be applied automatically: https://github.com/starfive-tech/u-boot/pull/44
aragubas
commented
1 year ago Ah that is bad. So both commands do not work?
I was using the wifi settings in the dietpie-config 👀
Is it this error? https://forum.rvspace.org/t/failed-to-open-starfive-usr-lib-dri-starfive-dri-so/2325
Yes! this exact same error!
However, in our case it generally worked to start a desktop. How did you try it? startx or one of the dietpi-autostart options, or starting LightDM with its service?
I tried using startx xP haven't tried the autostart options
In dietpi-config > Advanced Options > APT you can (re-)enable the APT cache and disable APT list compression. Also cache, lists and the dir for downloaded DEB packages (before they are installed) can be moved to RAM. On DietPi, other than Debian, the APT cache is disabled by default and lists are left xz-compressed, which radically reduces disk writes on every apt update call, but also quite significantly slows it down.
Oky! I'll try that
But only 4 GiB are currently shown, e.g. in htop, right? Can be currently manually solved: http://forum.rvspace.org/t/dietpi-os-for-visionfive-2/2356/15?u=michaing
for me it shows the full 8GB's
I glued a heatsink on the processor because it was overheating xP so I'll have to wait until tomorrow for the thermal glue to dry x3 I'll provide more feedback tomorrow!
MichaIng
commented
1 year ago I was using the wifi settings in the dietpie-config 👀
It calls iwlist wlan0 scan. Would be interesting whether iw dev wlan0 scan works. And still whether both work from console, to assure it is not something else not working in our tools.
I tried using startx xP haven't tried the autostart options
LightDM could be also tested like this (without reboot):
apt install lightdm # probably already installed
systemctl start lighdmfor me it shows the full 8GB's
Hah, interesting. @congocongo is this the case for you now as well? Probably with latest kernel?
cd /tmp
curl -O https://dietpi.com/downloads/binaries/linux-image-visionfive2.deb
dpkg -i linux-image-visionfive2.deb
rm linux-image-visionfive2.deb
Ah sorry I was wrong, it is only reconizing 4GB, but my model is the 8GB one xP
aragubas
commented
1 year ago 
also iw dev wlan0 scan does show the wifi connections
MichaIng
commented
1 year ago Okay, then indeed the device tree overlay needs to be applied or we need to hope for a better upstream solution. Rewriting the on-disk dtb file in U-Boot, like StarFive is currently doing it (given partitioning, FAT filesystem and dtb path are identical) will definitely not making it into upstream U-Boot default env, so either upstream Linux needs to solve this differently or via multiple device trees.
also
iw dev wlan0 scandoes show the wifi connections
So far so good. iwlist wlan0 scan shows nothing, or does it hang? I actually wanted to migrate from deprecated iwlist to iw, but with a WiFi dongle I used here, iw did hang forever while iwlist did work well. Recently I actually found both working well, but this made me hesitate switching just now, given that there are cases where WiFi is strictly required to setup the system (via SSH, headless). However, if it starts to be the other way round in cases, I may apply the switch with next DietPi version.
aragubas
commented
1 year ago So far so good.
iwlist wlan0 scanshows nothing, or does it hang?
it says that the interface doesn't support scanning xP
MichaIng
commented
1 year ago Does it return an error code, so that we could do something like that:
iwlist wlan0 scan || iw dev wlan0 scaniwlist wlan0 scan || iw dev wlan0 scan
with that command it first returns that error but then it lists the wifi interfaces owo
MichaIng
commented
1 year ago Okay, so we can go that way.
MichaIng
commented
1 year ago Latest U-Boot breaks boot of our image currently: https://github.com/starfive-tech/u-boot/issues/51
Tomorrow, I will provide instructions about how to fix it.
MichaIng
commented
1 year ago Image btw boots still fine as long as no NVMe drive is attached. I will update our firmware package the next days to provide a complete U-Boot environment override with a clean boot target/order selection and device tree overlays for 8 GiB RAM and model A1.2 support. I already tested this and it generally works fine.
Golang Go currently cannot be installed since the Debian Sid riscv64 build fails: https://buildd.debian.org/status/fetch.php?pkg=golang-1.20&arch=riscv64&ver=1.20.5-1&stamp=1686533537&raw=0
darkgeek
commented
1 year ago I see a new version of uboot is out, say v3.4.5, is it possible to solve the 8G issue by flashing this version?😃
MichaIng
commented
1 year ago The previous U-Boot version did already support it. Sorry for the delay, I did not find the time to finish the thing yet. However, here is how to do it:
maleadt
commented
11 months ago Is the latest DietPi testing image compatible with bootloader v3.6.1? IIUC the 1-partition layout doesn't seem supported:
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc1 is current device
Try booting from MMC1 ...
** Invalid partition 3 **
Couldn't find partition mmc 1:3
Can't set block device
Some software titles may not be supported on RISC-V in general, or because no RISC-V binaries or packages are provided yet. Most of these cases have been identified already and related software titles have been disabled for the RISC-V architecture for now.
Other software titles may only be unsupported on the particular VisionFive 2 SBC, or the kernel build we use. This is known for Docker, likely other container engines, the NFS server and the SMB client, but there may be more. We aim to generate own kernel builds, with added features the next week(s). Any help to create an rebase a fork on latest upstream Linux 5.15 is highly appreciated.
Again other software titles may not be supported with latest PHP, Python and other runtime environments and libraries, provided by Debian Sid. The RISC-V architecture is not yet officially supported by Debian, but only with the dedicated Debian ports repository and Debian Sid/unstable suite. Currently, this mostly equals Bookworm, which is the reason DietPi identifies as this. A list of software titles tested on Bookworm can be found here: https://github.com/MichaIng/DietPi/wiki/Debian-Bookworm-testing
As an introduction, read our blog post: https://dietpi.com/blog/?p=2629