Solved How to patch some parts of the source code using a RK356X-diff file...

If you don't understand math, you can learn it from a textbook, or you can learn it from a video, or you can learn it form a lecture - all valid ways. But at the end of the day you understand math.

That's a nice point. When I was young I tried in 1000 ways to understand mathematics. Only one time I got a nice votation,a 7 because I was tested on mathematics applied to computer science. I created a small algorithm in basic and I was rewarded. The rest of the tests were painful, I didn't get more than 4. But in Literature and English I always got high votations. (in French or Deutch only very low votations : never understood why)

Same thing happened in the psychology course with the statistic. I didn't understand anything. On the end I've got 6--. I don't think that much can be done. At least for me there was no way to become decent at mathematics or statistic. Later in my life I chose humanities and there I understood what my path was. There I've got only high votations.
 
I thought you have a single big diff file? That's what you say in your first post.

yes,I have it. But I have splitted the patches inside the big file into small files / patches. Because the paths inside the big file are different,so I've found that I can patch every file by placing the single patches inside the directories where the files to patch are.
 
yes,I have it. But I have splitted the patches inside the big file into small files / patches. Because the paths inside the big file are different,so I've found that I can patch every file by placing the single patches inside the directories where the files to patch are.
You seem to insist on wasting your own time instead of reading the description in man page, you absolutely didn't have to do that, patch understands the format you had in that diff and can apply to different paths without issues.
 
You seem to insist on wasting your own time instead of reading the description in man page, you absolutely didn't have to do that, patch understands the format you had in that diff and can apply to different paths without issues.

Unfortunately not. I have placed the diff file in various locations and it never worked.
 
Unfortunately not. I have placed the diff file in various locations and it never worked.
It's not about about the diff file location, it's about your current directory where you run patch command, you could even use -d option (I'm always forgetting about it!).

ADD: and the paths in your diff correspond to /usr/src hierarchy, you just have to strip the subversion noise with -p2.
 
Won't all the patches be applied to arm/arm? What does
Code:
 /usr/src  #  < patch
show?

Now it worked. Not sure why before it didn't. I should investigate.

Code:
/mnt/zroot2/zroot2/OS/BSD/FreeBSD/arm64/img/Radxa-3W/Stuff/covacat/usr/src # patch -C -p2 < RK356X-diff

Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- trunk/stable-14/sys/arm/arm/generic_timer.c    2025-03-19 20:49:43.139887000 +0100
|+++ branches/stable-14-deepcore/sys/arm/arm/generic_timer.c    2025-03-19 20:22:23.334267000 +0100
--------------------------
Patching file sys/arm/arm/generic_timer.c using Plan A...
Hunk #1 succeeded at 185.
Hunk #2 succeeded at 207.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|
|--- trunk/stable-14/sys/arm/arm/pmu.c    2025-03-19 20:49:43.176176000 +0100
|+++ branches/stable-14-deepcore/sys/arm/arm/pmu.c    2025-03-19 20:22:23.363676000 +0100
--------------------------
Patching file sys/arm/arm/pmu.c using Plan A...
Hunk #1 succeeded at 67.
Hunk #2 succeeded at 83.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|
|--- trunk/stable-14/sys/arm64/arm64/machdep.c    2025-03-19 20:49:44.977546000 +0100
|+++ branches/stable-14-deepcore/sys/arm64/arm64/machdep.c    2025-03-19 20:22:25.074352000 +0100
--------------------------
Patching file sys/arm64/arm64/machdep.c using Plan A...
Hunk #1 succeeded at 719.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|
|--- trunk/stable-14/sys/arm64/arm64/undefined.c    2025-03-19 20:49:45.003419000 +0100
|+++ branches/stable-14-deepcore/sys/arm64/arm64/undefined.c    2025-03-19 20:22:25.097413000 +0100
--------------------------
Patching file sys/arm64/arm64/undefined.c using Plan A...
Hunk #1 succeeded at 119.
Hunk #2 succeeded at 170.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|
|--- trunk/stable-14/sys/arm64/conf/RADXA3W    1970-01-01 01:00:00.000000000 +0100
|+++ branches/stable-14-deepcore/sys/arm64/conf/RADXA3W    2025-06-10 19:46:29.526693000 +0200
--------------------------
(Creating file sys/arm64/conf/RADXA3W...)
Patching file sys/arm64/conf/RADXA3W using Plan A...
Empty context always matches.
Hunk #1 succeeded at 1.

Very thanks to everyone.
 
Is there a development group for the FreeBSD man pages. Can we do some sandboxing type of research dev on the man pages. By this I mean rebuild base system man pages with a ML/DL framework. We can call it FreeGPT or BSDGPT. LLM name and software architecture to be determined by community consensus
 
Here is a better man page of man then the one FreeBSD provide, its the result of the command man man in respectively both Debian and freebsd. The one that debian provide is more beginner oriented and will give you a good understanding of how to read a man page.
 
Do you want my honest opinion ?
For me this was the way I first understood how to read them. so I thought it could also help you if it did help me back then. Because you said you don't understand them. Another thing useful to know is how to use the pager to move around while reading them: man less
 
For me this was the way I first understood how to read them. so I thought it could also help you if it did help me back then. Because you said you don't understand them. Another thing useful to know is how to use the pager to move around while reading them: man less

I think some considerations are useful here.

0) thanks for the help,anyway.

1) I thought it could also help you if it did help me back then.

That's not automatic,since we have a different cultural / technical background ,a different mind,and so on...

2) Because you said you don't understand them. Another thing useful to know is how to use the pager to move around while reading them: man less

What I don't understand is not just a formal matter, but also a substantial one. It means that I'm not able to connect the sense, the meaning of the symbols with the symbols themselves. This is because there are no practical examples that show me what happens when a command is formed in a certain way.

Another difficult is to be able to connect the right parameters to create a working command that makes exactly what I want.

There isn't any brief theoretical introduction relating to the general context of the topic being discussed.

In short, if you put yourself in my head you would only see some kind of Chinese ideograms, without understanding what they mean.

Finally, man man doubles the initial difficulty, because it creates an additional level of complexity, since it tries to explain what I didn't understand at the beginning without simplifying the language. How can I better understand what is written if it uses the same way of presenting the information ? If I don't understand the first level,more levels of the same kind you add,less I will understand. Just because you condensate again more symbols,reducing the pratical examples and the theory that should explain what those symbols do. So,in a less space you put more "strange" symbols without interconnecting them at all.

That's not true for those users who can understand the first level of the man pages. They will understand also man man.

To understand what I see,you can't think with your mind,but you should or at least try,to think with my mind,starting to understand what I'm trying to tell you here...
 
This is because there are no practical examples that show me what happens when a command is formed in a certain way.
You have to read them to understand them. Every option or parameter of a specific command is described within it's man pages.
Finally, man man doubles the initial difficulty, because it creates an additional level of complexity, since it tries to explain what I didn't understand at the beginning without simplifying the language.
The manpage of man that I gave you explain everything you need to know to understand the man pages. I don't think you can't understand them, I think your just don't want to read them, it's natural, but you have to go counter nature here. They are not so complex, but you have to get used to it. At first your brain wont like it, but if you really have a motivation you'll go over that and you'll discipline yourself and even if you don't get it at first glance you'll insist and keep coming back at it, until you reach understanding, try to focus on the first thing you don't understand isolate it and focus on it, it could be the meaning of a technical word that you'll have to search. Also the manpages are not like a book on one topic. the manpage contain sections, or chapter related to one specific general technical subject. You have to be aware of what sections of the manpages you need to search.

here is another resources for you : https://medium.com/better-programming/man-pages-the-complete-guide-800ad93425fe
 
You have to read them to understand them. Every option or parameter of a specific command is described within it's man pages.

The manpage of man that I gave you explain everything you need to know to understand the man pages. I don't think you can't understand them, I think your just don't want to read them, it's natural, but you have to go counter nature here. They are not so complex, but you have to get used to it. At first your brain wont like it, but if you really have a motivation you'll go over that and you'll discipline yourself and even if you don't get it at first glance you'll insist and keep coming back at it, until you reach understanding, try to focus on the first thing you don't understand isolate it and focus on it, it could be the meaning of a technical word that you'll have to search. Also the manpages are not like a book on one topic. the manpage contain sections, or chapter related to one specific general technical subject. You have to be aware of what sections of the manpages you need to search.

here is another resources for you : https://medium.com/better-programming/man-pages-the-complete-guide-800ad93425fe

1) If I don't understand man,it does not mean that I will not read anything. We are on the internet. There are useful and less complicated sources of informations in abundance. And some good places where I can ask what I dont understand. This is the reason why these places do exist.

2) it seems that man pages are the only way I have to learn. It seems that you want to impose them.

3) why should I insist by studying the man pages if I don't understand them ? I'm not masochist. I can find useful informations,better presented,at least for me,elsewhere.

4) The game is not worth the candle. They are presented in such an abstruse way for me that I should start from scratch, studying many other books first. Since this is a hobby for me, it means that I do it for pleasure and not for suffering and not in a professional manner. Despite this,I learn day by day and by doing even without studying the man pages.

5) There are always some subjects that many students will never get decent grades in. They have to work twice as hard to get average to low grades. That's how the human mind works. It prefers to absorb certain types of information in certain ways and not others, formally and / or conceptually.

If you are here, I bet many of you are poor at understanding humanities, for example. So ? You decide to study them anyway ? I don't think so, if you are here messing around with computers and with FreeBSD. So why do you tell me to persist in something I can't do if you also have things that you don't do because you don't like them and you're not good at them ?

It's like food. There are an infinite kind of foods, many of which we like and others we don't. Luckily we can decide to choose the ones we like without depriving our body of precious substances.
 
When I was a college student, I heared from one that had an account for Unix computer told me that what they're educated first on getting the account is `man man` to study how to read man pages. 😁 I had none at the era.

Some of the knowledges on Internet are great, but some are not, as the info by personell are not audited the precisions. And assumed environment (OS, version, what's additionally installed and what's deleted, and differences on hardwares) are, in many cases, not matches and even if the info is 100% precise for the author, the difference make us somehow modify things to apply on hand.

If there's man pages, they basically (not missingly upgraded) match the corresponding installed ones, thus, more precise.

But man pages are written by human beings (at least for now). And human beings make mistakes. So unfortunately not all manpages are 100% precise. And busy volunteer developers often misses to incorporate enough examples to understand. But cannot blame them as they are volunteers.

The best to consult is the "source codes". But much harder to understand for anyone that are NOT talented and experienced developers like me.

And this is why I often excuse "Not read the codes, but...".

And "humanity" is a quite difficult term. Even each one of twins differs on their humanities. Some would want quick and easy way, but some others would want to tackle reading and understanding source codes with great pleasures.
 
For hints who reads here in the future:

Not all patches/diffs are in the same format.
Some would be in the form of shell scripts that applies to by itself.
Some would have ">" at the first column for added lines, " " for unmodified lines and "<" for to be deleted lines.
And recently, as far as I know, most often used is so-called "Unfied Diff".

Even on Unified Diffs, there are some variants. These are because of how the diffs are created. For example, if I backup /usr/src/sys/sys/param.h to /usr/src/sys/sys/param.h.orig and execute diff -u sys/sys/param.h.orig sys/sys/param.h at /usr/src, it would show something like below. (Example on stable/14 at commit fad4064226b2aa3de6a6c83adb7e0e0108e69bd3)

Diff:
--- sys/sys/param.h.orig
+++ sys/sys/param.h
@@ -75,7 +75,7 @@
  * cannot include sys/param.h and should only be updated here.
  */
 #undef __FreeBSD_version
-#define __FreeBSD_version 1403502
+#define __FreeBSD_version 1403503
 
 /*
  * __FreeBSD_kernel__ indicates that this system uses the kernel of FreeBSD,

For this, cd /usr/src ; patch -i /path/to/patch/file or cd /usr/src ; patch -p0 -i /path/to/patch/file would apply it.

And another example is the diff to upgrade x11/nvidia-driver and related ports to 570.153.02 to 570.169 (already landed on main branch of ports tree).

In this case, I've edited my local ports tree directly and let git to generate diff and including diffs for multiple files in single diff file.
This was applicable via git, but cd /usr/ports ; patch -p1 -i /path/to/patch/file also worked (already impossible on latest main branch of ports tree, as it is already landed).

On manually merging multiple diffs for convenience, make sure not mixing up unmatched format of diffs which require different option to apply.
 
Back
Top