KREYREN

it was originally named armbian, because the framework was providing images for arm, but now we do riscv and even amd64 so i propose a rename.

I felt summoned sooo... BeagleV-Ahead support was submitted in https://github.com/armbian/build/pull/5712 along-side the LicheePi4A https://github.com/armbian/build/pull/5689 and OpenSBI https://github.com/armbian/build/pull/5714 If you have the other boards then you can send them to Base48 Hackerspace and leave a note that they are for me to turn into drones and stuff -OR- volunteer to test my contributions :p Donations also help to keep the tea brewing: https://github.com/Kreyren/Kreyren#donate

The framework provides way to share the output that makes it use the colors and stuff, so prefer to use that `curl --data-binary @output..` thing

Noted, i will take a look and get back to you please share full logs next time, armbian prints a command to do that once the build finishes to provide a link alike https://paste.next.armbian.com/oxamexecoj

and seems that i've been banned in armbian and stripped the role on the forum for writing this.. I am happy to put my name and role in armbian on the line to address this issue, if you prefer to represent yourself as the guy who doesn't care about his project, code and code quality then i won't stop you

Just to clarify i don't mean to be rude, but i also don't want to censor myself as i prefer to be honest.. this is submitted in a good faith with the hope to address what i see as a serious issue in the code base. And i am not the guy who just screams about issues and expect them to be solved i write this because i want to work on fixing them and expect you to adjust your management so that i can do that

I don't work on proprietary devices i do OSHW-only so that ain't my problem, the problem is that over 70% of development is trying to decypher what the code does and why, because it in super-majority lacks explanations and abstracting or is doing the implementation in a really weird and messed up way take a look at ./lib/functions//compilation/uboot.sh for example that's something that could be defined under 100 lines, but instead we do a 450+ line of code that is overcomplicated and took me hours to abstract and work with it ideally i want to agree on a standard so that it can be rewritten, but when i submit it in the objectively significantly more readable, reliable, safer and functional way, but you will just complain about it and refuse to discuss it. [functionality wise we are further than the other projects you even promote that in the readme](https://github.com/armbian/build#compared-with-industry-standards). I am not here to just argue and complain i want to work on fixing it and i want to discuss the changes and agree on a better standard so that it's not like with guix where i submit contributions that i invest lot of time and effort into only for other contributors to think that they know better and mess them up to the point where i have to migrate on nixos, bcs the OS became a liability. So you are aware of the funding difficulties, yet you decide that removing a small and short sentence from the bottom of my merge requests which is not included in the git log where people give me donations which enable me to sustainably work on armbian and giving it the care it needs is a great idea.. I keep feeling like you have lot of experience in proprietary development and keep trying to use that as a good idea for open-source where is terrible malpractice.. I don't need additional project leaders i have my developer team that i work with on stuff that is over my head if needs be and i proposed you to adding me to relevant code owners so that you don't have to review all the stuff and if i break something then i do my best to fix it asap if you don't trust me then we have people who can do reviews if you feel like reviewing merge requests where i do my best to be easy to review and understandable through making the code as readable as possible and documenting it is too expensive then provide the calculations i try to cover the cost of the reviewing or ask my supporters to help. Using your visualization the sooner you address the code quality issues the less of a work it will be to deal with so in this case grabing a megaphone and screaming to get priority is a really really good idea Namely: I provided a vscode configuration that enables to capture the issues on the developer-side prior to merge in https://github.com/armbian/build/pull/5691 sooner you merge it sooner it's able to capture major issues and bugs that the QA system might miss, refer to dr. reason's swiss cheese model for rationale: it doesn't feel like we have any, people do whatever they want in most of the script files without enforcement which is why we are in this situation and i do my best to adjust the code for it whenever i can, but it's really painful to take good code and turn it into a worse version just to appease you and make it mergable

Oh the `beagle.csc` is for the old version of BeagleV that had the jh7100 chip, afaik they got mad at starfive for trying to restrict what they can release as they are an OSHW developer (OLIMEX had the same issue, hug you starfive!) and went with TH1520 instead and are calling it BeagleV-Ahead.. So `beagle.csc` is different chip and the config is not compatible with the board

Oh didn't notice that someone already defined that ... 9 months ago even! > BOOT_FDT_FILE="starfive/jh7100-beaglev-starlight-a1.dtb" Is interesting I get that error too when i try to checkout on an armbian branch, you seem to be using using wrong repository :p Clone the repository in a new directory with: $ git clone -b canIPetDatDawg https://github.com/Kreyren/armbian-build-kreyren # Clone the repository Notice the https://github.com/Kreyren/armbian-build-kreyren ! As the changes are in my fork, instead of in official armbian repo

Bookworm won't work, debian says that it will never support riscv64 and their process of making trixie support it didn't even start yet so sid is the only sane option yep seems like you are running that on a wrong branch it doesn't look like the changes proposed

Also you do this on your own danger and stuff, if you break up your board and or system, house, planet it's not my fault!~ Monitor the temperature of the chip, my licheepi gets uncomfortably hot atm during fastbooting so have a blower fan ready Refer to https://github.com/armbian/build/pull/5689 for details, once in system you might need to invoke: echo 1 > /sys/class/pwm/pwmchip0/export echo 1000000 > /sys/class/pwm/pwmchip0/pwm1/period echo 1000000 > /sys/class/pwm/pwmchip0/pwm1/duty_cycle echo 1 > /sys/class/pwm/pwmchip0/pwm1/enable To get the fan to spin

@Seth N_Oke give it a try, i submitted stuff to https://github.com/Kreyren/armbian-build-kreyren/tree/canIPetDatDawg $ git clone -b canIPetDatDawg https://github.com/Kreyren/armbian-build-kreyren # Clone the repository $ cd armbian-build # change directory to it $ ./compile.sh build BOARD=beaglev-ahead BRANCH=edge BUILD_DESKTOP=no BUILD_MINIMAL=yes EXPERT=yes KERNEL_CONFIGURE=no RELEASE=sid # Make it do vroom vroom You are expecting a build to go like this https://paste.next.armbian.com/oxamexecoj and end up with: --> (1036) INFO: Done building [ Armbian_23.08.0-trunk_Sipeed-licheepi-4a_sid_legacy_5.10.113_minimal.img ] --> (1036) INFO: SHA256 calculating [ Armbian_23.08.0-trunk_Sipeed-licheepi-4a_sid_legacy_5.10.113_minimal.img ] --> (1047) INFO: Moving artefacts using rsync to final destination [ Armbian_23.08.0-trunk_Sipeed-licheepi-4a_sid_legacy_5.10.113_minimal ] --> (1047) COMMAND: rsync -av --no-owner --no-group --remove-source-files /armbian/.tmp/image-292da042-51dd-41a8-907e-bb00588f2ad1/Armbian_23.08.0-trunk_Sipeed-licheepi-4a_sid_legacy_5.10.113_minimal.img /armbian/.tmp/image-292da042-51dd-41a8-907e-bb00588f2ad1/Armbian_23.08.0-trunk_Sipeed-licheepi-4a_sid_legacy_5.10.113_minimal.img.sha /armbian/.tmp/image-292da042-51dd-41a8-907e-bb00588f2ad1/Armbian_23.08.0-trunk_Sipeed-licheepi-4a_sid_legacy_5.10.113_minimal.img.txt /armbian/output/images sending incremental file list Armbian_23.08.0-trunk_Sipeed-licheepi-4a_sid_legacy_5.10.113_minimal.img Armbian_23.08.0-trunk_Sipeed-licheepi-4a_sid_legacy_5.10.113_minimal.img.sha Armbian_23.08.0-trunk_Sipeed-licheepi-4a_sid_legacy_5.10.113_minimal.img.txt sent 1,531,314,901 bytes received 145 bytes 48,613,176.06 bytes/sec total size is 1,530,940,868 speedup is 1.00 --> (1078) COMMAND: rm -rfv --one-file-system /armbian/.tmp/image-292da042-51dd-41a8-907e-bb00588f2ad1 removed directory '/armbian/.tmp/image-292da042-51dd-41a8-907e-bb00588f2ad1' --> (1078) INFO: Unmounting recursively [ SDCARD rootfs finished - be patient ] --> (1082) TARGET-REACHED: Done building image [ sipeed-licheepi-4a ] Note the `Armbian_23.08.0-trunk_Sipeed-licheepi-4a_sid_legacy_5.10.113_minimal.img` (or what it prints on your end) $ mkdir kreysmessings # Make a new directory $ cp armbian-build/output/images/Armbian_23.08.0-trunk_Sipeed-licheepi-4a_sid_legacy_5.10.113_minimal.img kreysmessins # Copy that to a new directory # losetup -P -f Armbian_23.08.0-trunk_Sipeed-licheepi-4a_sid_legacy_5.10.113_minimal.img # Mount the armbian image # losetup -a # Outputs where it got mounted e.g. /dev/loop0 # sudo dd if=/dev/loop0p1 of=bootfs.ext4 status=progress # Get the boot filesystem # sudo dd if=/dev/loop0p2 of=rootfs.ext4 status=progress # Get the root filesystem Somewhere at the bottom of the build log you will have: --> (1035) INFO: Sourcing u-boot install functions [ /armbian/output/debs/linux-u-boot-sipeed-licheepi-4a-legacy_23.08.0-trunk_riscv64__2020.01-Sd82d-Pd2e2-Hfaa0-V5349-Bb0e7-R448a.deb ] $ cp armbian-build/output/debs/linux-u-boot-sipeed-licheepi-4a-legacy_23.08.0-trunk_riscv64__2020.01-Sd82d-Pd2e2-Hfaa0-V5349-Bb0e7-R448a.deb . # Copy the debian package of u-boot in directory $ ar x linux-u-boot-sipeed-licheepi-4a-legacy_23.08.0-trunk_riscv64__2020.01-Sd82d-Pd2e2-Hfaa0-V5349-Bb0e7-R448a.deb # Extract it $ tar xpf data.tar.something # Extract the data dir It will have something like `usr/lib/.../u-boot-with-spl.bin` keep that and remove everything else from what the deb archive spit out Get the device in fastboot mode on licheepi there is a BOOT button that you are supposed to press and then insert USB-C cable while the device is turned off, verify in `dmesg` and `fastboot devices` that the device is seen by the system # fastboot flash ram u-boot-with-spl.bin # Flash the bootloader in temporary filesystem # fastboot reboot # Reboot into it # fastboot flash uboot u-boot-with-spl.bin # Flash the uboot to the board Now you have two options: a) Use the sdcard to test the thing (recommended) # dd if=Armbian_23.08.0-trunk_Sipeed-licheepi-4a_sid_legacy_5.10.113_minimal.img of=/dev/sdX conv=sync status=progress # Put armbian on the sdcard Put the sdcard in the thing and you should get armbian b) On eMMC (pain, misery and suffering for testing) # fastboot flash boot bootfs.ext4 # Flash boot to the board # fastboot flash root rootfs.ext4 # Flash root to the board Now try to boot the thing and you should be greeted with armbian armbianing stuff if no then tell meh

@Seth N_ I am currently working on the TH1520 for SiPeed LicheePi 4A (https://github.com/armbian/build/pull/5689), if you are willing to test the changes then i can work on an official support optionally willing to discuss issues you might run into as the boards are likely to share solutions.

Referenced in https://github.com/armbian/build/pull/5689

Writing code for armbian is currently pain and suffering, because the code quality is horrible and it always makes me do changes alike https://github.com/Kreyren/armbian-build-kreyren/compare/6cd581c96c0b7b800b6549afe23112d4a662d2a0..811288169004dccacab964129ecaf8cfe891b22d that waste time just to get the contribution to work reliably, thus proposing to take an inspiration for how other projects such as nixos handle this issue and implement a RFC: https://github.com/NixOS/rfcs Which is a repository filled with directives that are to be followed during development to unite the coding style through brainstorm and logical rationale Additionally this RFC can then be taken as an industry standard for scripting in bash/shell