MaxT

Found the actual codes executed in /usr/lib/armbian-config/jobs.sh, when you run
sudo armbian-config Basically, it updates /etc/hostname, /etc/hosts
Here is my wrapped function:
change_hostname() { # modified from /usr/lib/armbian-config/jobs.sh # should be OK for debian as well(?) local hostname_current=$(cat /etc/hostname) if [[ -z $1 ]]; then echo "Current hostname: $hostname_current" else local hostname_new=$1 sudo sed -i "s/$hostname_current/$hostname_new/g" /etc/hosts sudo sed -i "s/$hostname_current/$hostname_new/g" /etc/hostname # Temporarily change the hostname for the current session sudo hostname "$hostname_new" sudo systemctl restart systemd-logind.service echo "Logout to make effective the new hostname: $hostname_new" fi }  

https://github.com/garywill/linux-router

@Nick A I understand you.
Working with the source code and making patches within the framework of the build system is a sad business.
 
Let's try to sort it out.
I'm writing this for everyone. Don't read it if it's familiar to you.
First, basic knowledge about git:
A git is a chain of related git objects.
The git object is the compressed difference between the current state and the previous one.
The Git object has a name in the form of a 40-digit hexadecimal numeric word.
Each object is tightly linked to the previous (parent) and subsequent (child) objects.
Concepts such as HEAD, tag, branch are references to a specific git object.
The working tree is the git state extracted to the working directory.
 
In previous posts, we talked about u-boot. Let's check what we have in the build system.
My build system is located in the VM in the folder: /home/leo/armbian
 
leo@armbuild:~/armbian/cache/sources/u-boot-worktree/u-boot/v2024.01$ git branch + master * u-boot-edge-bananapim3 leo@armbuild:~/armbian/cache/sources/u-boot-worktree/u-boot/v2024.01$ git log --pretty=oneline -3 866ca972d6c3cabeaf6dbac431e8e08bb30b3c8e (HEAD -> u-boot-edge-bananapim3, tag: v2024.01) Prepare v2024.01 82750ce44226e5f2b3bbcd79cf7b3ba3dfd3de4d arm: dts: iot2050: Fix by syncing from Linux dbb124cf6888da9581834a3c17b02f958a8afacf configs: j7200: Remove HBMC_AM654 config  
Enter your data from the github here.
It is important.
git config --global user.email "you@example.com" git config --global user.name "Your Name"  
Let's add all the changed files to the monitored state and make a commit:
leo@armbuild:~/armbian/cache/sources/u-boot-worktree/u-boot/v2024.01$ sudo git add --all leo@armbuild:~/armbian/cache/sources/u-boot-worktree/u-boot/v2024.01$ sudo git commit -m "The Armbian changes" [u-boot-edge-bananapim3 dcf395c104] The Armbian changes 52 files changed, 682 insertions(+), 16 deletions(-) create mode 100644 arch/arm/dts/sun50i-a64-recore.dts create mode 100644 arch/arm/dts/sun50i-h313-x96q-lpddr3.dts create mode 100644 configs/recore_defconfig create mode 100644 configs/x96q_lpddr3_defconfig  
Now we will see:
leo@armbuild:~/armbian/cache/sources/u-boot-worktree/u-boot/v2024.01$ git log --pretty=oneline -3 dcf395c1044533320913373b3b8da980ac49ac73 (HEAD -> u-boot-edge-bananapim3) The Armbian changes 866ca972d6c3cabeaf6dbac431e8e08bb30b3c8e (tag: v2024.01) Prepare v2024.01 82750ce44226e5f2b3bbcd79cf7b3ba3dfd3de4d arm: dts: iot2050: Fix by syncing from Linux The HEAD and branch links point to the new git object.
But the v2024.01 tag continues to point to 866ca972d6c3cabeaf6dbac431e8e08bb30b3c8e
 
Let's add the debugging code and make a commit:
leo@armbuild:~/armbian/cache/sources/u-boot-worktree/u-boot/v2024.01$ sudo nano drivers/mmc/sunxi_mmc.c leo@armbuild:~/armbian/cache/sources/u-boot-worktree/u-boot/v2024.01$ sudo git add drivers/mmc/sunxi_mmc.c leo@armbuild:~/armbian/cache/sources/u-boot-worktree/u-boot/v2024.01$ sudo git commit -m "define DEBUG macros for sunxi mmc"  
Look at the last commit. This is what will be extracted using the command "git format-patch -1":
leo@armbuild:~/armbian/cache/sources/u-boot-worktree/u-boot/v2024.01$ git log -p -1 commit c5a54a85e206c32c4a17aa573c8f409899c2a77a (HEAD -> u-boot-edge-bananapim3) Author: The-going <48602507+The-going@users.noreply.github.com> Date: Wed Sep 25 09:09:47 2024 +0000 define DEBUG macros for sunxi mmc diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c index 8b684929e0..c32c9bda28 100644 --- a/drivers/mmc/sunxi_mmc.c +++ b/drivers/mmc/sunxi_mmc.c @@ -33,6 +33,8 @@ #include "sunxi_mmc.h" +#define DEBUG + #ifndef CCM_MMC_CTRL_MODE_SEL_NEW #define CCM_MMC_CTRL_MODE_SEL_NEW 0 #endif  
We will extract these changes to the target directory:
leo@armbuild:~/armbian/cache/sources/u-boot-worktree/u-boot/v2024.01$ git format-patch -1 -o /home/leo/armbian/patch/u-boot/u-boot-sunxi/ /home/leo/armbian/patch/u-boot/u-boot-sunxi/0001-define-DEBUG-macros-for-sunxi-mmc.patch leo@armbuild:~/armbian/cache/sources/u-boot-worktree/u-boot/v2024.01$ mv /home/leo/armbian/patch/u-boot/u-boot-sunxi/0001-define-DEBUG-macros-for-sunxi-mmc.patch /home/leo/armbian/patch/u-boot/u-boot-sunxi/define-DEBUG-macros-for-sunxi-mmc.patch leo@armbuild:~/armbian/cache/sources/u-boot-worktree/u-boot/v2024.01$ cat /home/leo/armbian/patch/u-boot/u-boot-sunxi/define-DEBUG-macros-for-sunxi-mmc.patch From c5a54a85e206c32c4a17aa573c8f409899c2a77a Mon Sep 17 00:00:00 2001 From: The-going <48602507+The-going@users.noreply.github.com> Date: Wed, 25 Sep 2024 09:09:47 +0000 Subject: [PATCH] define DEBUG macros for sunxi mmc --- drivers/mmc/sunxi_mmc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c index 8b684929e0..c32c9bda28 100644 --- a/drivers/mmc/sunxi_mmc.c +++ b/drivers/mmc/sunxi_mmc.c @@ -33,6 +33,8 @@ #include "sunxi_mmc.h" +#define DEBUG + #ifndef CCM_MMC_CTRL_MODE_SEL_NEW #define CCM_MMC_CTRL_MODE_SEL_NEW 0 #endif -- 2.34.1 I have removed the prefix number of the patch file name so that the patch is applied last.
 
If I do git format-patch -1 v2024.01 I will get the changes that are stored in the git object referenced by this v2024.01 tag.
 
Do I need to write here how to correctly add multiple changes to the kernel?
 

Why not search forum first? There was smth similar few days ago

Someone always should be liable that you are not happy with smth, and must do smth here and/or there to make you happy, right?

Just a few thoughts (I'm also not young):

Suggest you direct claims to Linux devs and enjoy having reply there (just find an appropriate mail list at lore.kernel.org, probably in the MAINTAINERS file in Linux sources). If the board isn't supported in mainline, that's another reason to complain and ask why the hell they are there. Will appreciate if you share reply here when you get one.

I guess armbian people are here because they enjoy playing with SBC and to the extent acceptable for them help others, but obviously (for me at least) without any sort of guarantees or promises

As to the community, suggest you think of yourself as the only member of the Community currently having interest in this particular board, facing this particular issue and having enough time. Probably an answer why you have not got any reply will be clear. So you also might what to blame other owners of the board who are not on this site and dropping all their current affairs just to do what you need.

You also might want to find the person fixing the bug in question 9 years (?) ago and raise complaints on why that asshole have not fixed the bug for all boards to him and change him your time invested so far, otherwise that time is your time, no one got any value (now you know more than before ) out of that investment except yourself, so that's your R&D.

At to usefulness, seems there are quite many people finding this project useful, probably not all their expectations are met, but still, and I guess they are happy that there are knowledgeable people that might have will/time to help. Even if not, no one has any right to try insulting the team.

Some people become wiser as they get older, some not, where are you with this?

Hi,
I'd also like to see armbian running on my M1S.
It arrived today and honestly I ordered it in the hope to see it being supported one day.
Afaik none of the devs currently own an M1S yet, what makes development somewhat more difficult. So I would be happy to contribute by providing my M1S for tests.
So if anyone without an own M1S can provide an Armbian image with modified device tree and so on I will try to perform the desired tests.
 
Cheers and thank you!

This is a tricky shit that hides behind openness, but in fact tightly controls the main part-the loader. I.e., at any time, it can block or completely control any unwanted person's actions.
 
 
It's funny, you described a whole theory about freedom, and as a result it all came down to advertising and pushing aml shit. 
For your information, aml imposes its BSP shit on everyone, which is stuffed with Trojans and bookmarks to gain full control over those who use their shit. They lie to all users about their hardware and actively cooperate with those you are trying to protect yourself from.
 
In general, everything is as usual, if you remove the beautiful words about freedom, it all came down to the fact that "someone" would spend their time and money and provide the rest with free use of aml shit.
 

In /home/hts there are two hidden folders:
/home/hts/.hts and /home/hts/.xmltv

stop tvheadend, tar profile which is in /home/hts like here http:// https://askubuntu.com/questions/834717/recursive-tar-compression
on another system stop tvheadend, untar profile, start tvheadend.

I guess that you will have to manually check that dvb cards are properly mapped

I think the boot process is the same or very similar among rk322x and rk3318/rk3328. I had the time to study the rk322x boot and make some intresting experiments.
The standard firmware boot that uses proprietary rockchip binaries and sources usually do these steps:
the SoC ROM code reads the ddrbin at sector 0x40 and executes it to initialize DDR memory the SoC ROM then reads the code that follows the ddrbin and finds the miniloader (you can find various versions of miniloaders from the kwiboo repository I linked before) the miniloader takes control and checks for GPT partitions called "uboot" and "trustos", if partitions are found sets PTR_UBOOT and PTR_TRUSTOS pointers to the partitions sectors, otherwise sets the pointers to default values respectively of 0x2000 and 0x4000 the miniloader looks for the "LOADER" (that's exactly a string with uppercase characters) signature at PTR_UBOOT sector, if the signature is found loads u-boot in memory, otherwise increases the PTR_UBOOT pointer by 0x800 sectors and retries the miniloader looks for "TRUST" signature at PTR_TRUSTOS to do the same job the miniloader boots the trust os (that's a build of the ATF), which installs itself, and then boots u-boot u-boot finally loads the device tree and boots the kernel when you use prepare the u-boot and trust images with  loaderimage --pack command, is actually decorating uboot/trust image with a header (the LOADER/TRUST signatures, maybe other things like checksums and the memory location where the image should be loaded into).
Likewise you can extract u-boot and trust images from flash memory looking at those locations and obtain the originals using loaderimage --unpack command. @knaerzche extracted a working trustos from a rk3228 box image this way and now LibreELEC uses that blob as trustos for all rk322x images. I'm also using a trustos extracted this way to boot the multitool, and it works pretty well.
 
The other boot process that uses mainline u-boot and Opensource OPTEE (in place of ATF) is as follows:
The SoC ROM code reads the u-boot TPL at sector 0x40, this initializes DDR memory the SoC ROM code reads the u-boot SPL that immediately follows the TPL u-boot SPL executes the OPTEE trustos u-boot SPL executes the main u-boot u-boot loads device tree and boots the kernel For some extents, you can mix the two boot processes, for example in Armbian I use the second boot process, but at the step 1 I use the proprietary ddrbin because u-boot TPL does not support DDR2 memories.
 
My guess is that the rk3318/rk3328 boot process is very much the same
 

Michael was asking me in a PM where the MAC address is persisted during "first boot" ...
@TonyMac32 are you aware of the persisted address file location ?