Until OSD335X runs U-boot on a custom board (memo) https://qiita.com/nonNoise/items/ef6702fd666421bd5688
Now that I can see how U-Boot works, let's talk about it.
Patch U-Boot
wget -c https://rcn-ee.com/repos/git/u-boot-patches/v2018.01/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch wget -c https://rcn-ee.com/repos/git/u-boot-patches/v2018.01/0002-U-Boot-BeagleBone-Cape-Manager.patch wget -c https://raw.githubusercontent.com/RobertCNelson/Bootloader-Builder/master/patches/v2018.03-rc1/0002-NFM-Production-eeprom-assume-device-is-BeagleBone-Bl.patch
patch -p1 < 0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch patch -p1 < 0002-U-Boot-BeagleBone-Cape-Manager.patch patch -p1 < 0002-NFM-Production-eeprom-assume-device-is-BeagleBone-Bl.patch
I searched for U-Boot patches. I want to customize U-Boot for the original board. First, I looked at what Pach was doing in the first place. I was looking for the source, thinking that it was some compiled content, but I can't find it. I patched it before compiling ... maybe ...
The patch file was usually a file with git diff information. I see, there was a patch command, so if you think there is a mechanism, is it such a mechanism? In that case, I wonder if I can make my own patch by grasping the patch difference, rewriting the source of U-Boot itself, and making the difference a patch. I see, I didn't know.
If you look at the diff information of git, it is convenient to know at a glance which file you played with
◎ 0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch
◎ 0002-U-Boot-BeagleBone-Cape-Manager.patch
◎ 0002-NFM-Production-eeprom-assume-device-is-BeagleBone-Bl.patch
Looking at the Diff, I found that the same files were processed by different patches, so I thought that if they were out of order, they would collide.
For the time being, one by one
◎ 0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch
It's the first patch to apply. am335x_pocketbeagle_defconfig has been modified the most. This is a U-Boot / configs block that sets which features to y / n.
◎ 0002-U-Boot-BeagleBone-Cape-Manager.patch
The next patch to apply. board / ti / am335x / board.c has changed the most. I feel like I'm patching the board here. In particular, the BeagleBone-Cape, a slightly newer board in the BeagleBone. https://github.com/u-boot/u-boot/tree/master/board/ti/am335x
◎ 0002-NFM-Production-eeprom-assume-device-is-BeagleBone-Bl.patch
The last patch I applied. board / ti / common / board_detect.c has changed the most. Since it is common, I feel that I am modifying the interface (external extension function) specific to the board. https://github.com/u-boot/u-boot/tree/master/board/ti/common
do not know. After all, look at the basic U-boot source, then grasp the difference between the three types of patches, and apply the correction patch you want to do. Since it is a Diff, the corrected (deleted) part is displayed as a minus, so if you apply 3 types of patches for the time being and then play with the source and leave the Diff, I think that a highly reproducible U-Boot patch will be completed. ..
Feeling, I want to recreate the patch with the latest U-boot version, but that is probably a technique with difference understanding and source understanding.
Recommended Posts