Differences

This shows you the differences between two versions of the page.

--- batocera.linux_buildroot_modifications [2022/08/26 03:00] – [Patching a package] added tip about -A flag for git add atari
+++ batocera.linux_buildroot_modifications [2022/09/28 07:14] (current) – specifics atari
@@ Line 2: / Line 2: @@
 You may know me from former titles such as "Batocera Linux Buildroot Modifications" and "How to work on Batocera (and not recompile everything)".
+<WRAP center round info>
+RPi3, the "per platform" example used here, was formerly known internally as ''rpi3'' in Batocera **v35** and lower. This is now ''bcm2837'' in **v36** and higher.
+</WRAP>
 <WRAP center round tip>
@@ Line 25: / Line 29: @@
   - download the package in the dl directory according to information from ''package/package-name/package-name.mk'' or ''package/batocera/package-name/package-name.mk''
   - extract the package in ''output/build/package-name-version''
-  - patch the package from ''*.patch'' files (files next to the ''.mk'' file or ''board/batocera/patches/'' or ''board/batocera/rpi/patches/'')
+  - patch the package from ''*.patch'' files (files next to the ''.mk'' file or ''board/batocera/patches/'' or ''board/batocera/bcm2837/patches/'')
   - configure the package according to the ''.mk'' file
   - build the package according to the ''.mk'' file
-  - install in the ''output/rpi3/host/'' staging directory, in case of libraries
+  - install in the ''output/bcm2837/host/'' staging directory, in case of libraries
-  - install in the ''output/rpi3/target/'' directory
+  - install in the ''output/bcm2837/target/'' directory
-For each step, Buildroot creates an empty flag file. For example: ''%%.stamp_downloaded%%'' in ''output/rpi3/build/package-name-version''.
+For each step, Buildroot creates an empty flag file. For example: ''%%.stamp_downloaded%%'' in ''output/bcm2837/build/package-name-version''.
 In case a step failed, just run ''make'' or ''make package-name'' again to restart/continue the build where you left.
-To completely rebuild a package:
+To completely rebuild a package (for example an RPi 3 package):
-  rm -rf output/rpi3/build/package-name-version
+  rm -rf output/bcm2837/build/package-name-version
   make package-name
 For example, to build EmulationStation again from the latest ''master'' git version:
-  rm -rf output/rpi3/build/batocera-emulationstation-master
+  rm -rf output/bcm2837/build/batocera-emulationstation-master
   make batocera-emulationstation
@@ Line 174: / Line 178: @@
 Let's say you want to work on the package "retroarch" to make it evolve via a patch.
-First, compile a complete version of Batocera for the architecture you will test. In this example, we will do so for ''rpi3''.
+First, compile a complete version of Batocera for the architecture you will test. In this example, we will do so for RPi3.
 <code bash>
 cd batocera.linux
-make rpi3-build
+make bcm2837-build
 </code>
@@ Line 184: / Line 188: @@
 <code bash>
-mv output/rpi3/target output/rpi3/target_
+mv output/bcm2837/target output/bcm2837/target_
 </code>
@@ Line 190: / Line 194: @@
 <code bash>
-cd output/rpi3/build/retroarch-version
+cd output/bcm2837/build/retroarch-version
 </code>
@@ Line 221: / Line 225: @@
 <code bash>
 cd ../../..
-rm -rf ouput/rpi3/build/batocera/retroarch-version
+rm -rf ouput/bcm2837/build/batocera/retroarch-version
 </code>
@@ Line 233: / Line 237: @@
 ===== Testing a package without compiling the entirety of Batocera =====
-It's possible to compile //just// the package you've modified and then transfer it over to your live Batocera installation using ''rsync''. First, compile the individual package [[#package_compilation|as explained above]] with ''make rpi3-pkg PKG=<package name>'' and then run:
+It's possible to compile //just// the package you've modified and then transfer it over to your live Batocera installation using ''rsync''. First, compile the individual package [[#package_compilation|as explained above]] with ''make bcm2837-pkg PKG=<package name>'' and then run:
 <code bash>
-rsync -av output/rpi3/target/ root@batocera.local:/
+rsync -av output/bcm2837/target/ root@batocera.local:/
 </code>
 This will sync up the contents of the target directory on your build machine with the Batocera machine. Feel free to immediately test your changes. If the changes are bad and you need to restore, simply reboot and the changes will not persist. To have them persist instead, run [[modify_the_system_while_it_s_running|batocera-save-overlay]] from the machine itself.