<feed xmlns='http://www.w3.org/2005/Atom'>
<title>lbmk.git/script/trees, branch 20241206rev6</title>
<subtitle>libreboot build system (LibreBoot MaKe)
</subtitle>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/'/>
<entry>
<title>Revert "trees: Allow using a custom clean command"</title>
<updated>2024-12-02T21:22:36+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-12-02T21:22:36+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=efebfa992b6f64d610115502d47468bc039b3a59'/>
<id>efebfa992b6f64d610115502d47468bc039b3a59</id>
<content type='text'>
This reverts commit 5b4c9158e5a79f8d7e776c8c4ece69dda5aa8690.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit 5b4c9158e5a79f8d7e776c8c4ece69dda5aa8690.
</pre>
</div>
</content>
</entry>
<entry>
<title>trees: Allow using a custom clean command</title>
<updated>2024-12-02T20:41:05+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-12-02T20:37:26+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=5b4c9158e5a79f8d7e776c8c4ece69dda5aa8690'/>
<id>5b4c9158e5a79f8d7e776c8c4ece69dda5aa8690</id>
<content type='text'>
On coreboot for example, as Mate has told me, if you're
making Kconfig changes and re-compiling, sometimes the
actual image that you build might still have the old one
in it, due to how coreboot's build system works.

To mitigate this, you can just always run distclean before
doing the build, but lbmk was doing just clean.

In practise, we did not find any issues, but this change should
be harmless, and might prevent such issues in the future. It's
even possible that we might have already encountered this before
and not realised, and we were just lucky that no noticeable issues
were caused.

It's *also* possible that the reverse is true: an issue that
was previously covered up, then that issue will now be exposed.
However, if that turns out to be true, then that is good because
we are exposing said bugs and then we will know to fix them!

Anyway, the variable in target.cfg is:

cleancmd="whatever_you_want"

e.g.

cleancmd="distclean"

You may also specify this in global mkhelper.cfg files, per
project; I've already done this for SeaBIOS, coreboot
and U-Boot, since all of these use Kconfig files.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
On coreboot for example, as Mate has told me, if you're
making Kconfig changes and re-compiling, sometimes the
actual image that you build might still have the old one
in it, due to how coreboot's build system works.

To mitigate this, you can just always run distclean before
doing the build, but lbmk was doing just clean.

In practise, we did not find any issues, but this change should
be harmless, and might prevent such issues in the future. It's
even possible that we might have already encountered this before
and not realised, and we were just lucky that no noticeable issues
were caused.

It's *also* possible that the reverse is true: an issue that
was previously covered up, then that issue will now be exposed.
However, if that turns out to be true, then that is good because
we are exposing said bugs and then we will know to fix them!

Anyway, the variable in target.cfg is:

cleancmd="whatever_you_want"

e.g.

cleancmd="distclean"

You may also specify this in global mkhelper.cfg files, per
project; I've already done this for SeaBIOS, coreboot
and U-Boot, since all of these use Kconfig files.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>trees: reset PATH per-target</title>
<updated>2024-11-29T00:39:35+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-11-29T00:36:40+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=7f6e47d27c673e29250cbdac03e326b9ba044b05'/>
<id>7f6e47d27c673e29250cbdac03e326b9ba044b05</id>
<content type='text'>
Otherwise, if PATH was set before, it will be re-used
again in the next pass. We previously unset CROSS_COMPILE
to avoid using the wrong cross-compiler when switching to
another target within a multi-tree project such as U-Boot.

Well, PATH was also being set, to use coreboot xgcc first.
This is fine, but the next target may not use the same one.

This patch solves a similar problem to the following patch
which was mentioned above:

commit 637c0a1521a03e3f65de85dcc5ffd478b37a5360
Author: Leah Rowe &lt;leah@libreboot.org&gt;
Date:   Tue Nov 19 02:52:28 2024 +0000

    trees: unset CROSS_COMPILE per target

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Otherwise, if PATH was set before, it will be re-used
again in the next pass. We previously unset CROSS_COMPILE
to avoid using the wrong cross-compiler when switching to
another target within a multi-tree project such as U-Boot.

Well, PATH was also being set, to use coreboot xgcc first.
This is fine, but the next target may not use the same one.

This patch solves a similar problem to the following patch
which was mentioned above:

commit 637c0a1521a03e3f65de85dcc5ffd478b37a5360
Author: Leah Rowe &lt;leah@libreboot.org&gt;
Date:   Tue Nov 19 02:52:28 2024 +0000

    trees: unset CROSS_COMPILE per target

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>trees: unset CROSS_COMPILE per target</title>
<updated>2024-11-19T02:52:28+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-11-19T02:52:28+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=637c0a1521a03e3f65de85dcc5ffd478b37a5360'/>
<id>637c0a1521a03e3f65de85dcc5ffd478b37a5360</id>
<content type='text'>
When building a coreboot image, if they enable the
x86 U-Boot payloads, sometimes what happens is you
have CROSS_COMPILE set, for i386-elf, but then it's
still set to that when later building 64-bit U-Boot,
which needs x86_64-elf.

We currently rely on hostcc to build U-Boot.

To mitigate this, unset CROSS_COMPILE in the main
loop of the trees script, for building project targets.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When building a coreboot image, if they enable the
x86 U-Boot payloads, sometimes what happens is you
have CROSS_COMPILE set, for i386-elf, but then it's
still set to that when later building 64-bit U-Boot,
which needs x86_64-elf.

We currently rely on hostcc to build U-Boot.

To mitigate this, unset CROSS_COMPILE in the main
loop of the trees script, for building project targets.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Experimental U-Boot payload (32-bit dtb, U-Boot)</title>
<updated>2024-11-03T09:22:52+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-11-03T02:41:41+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=c0017c73578a91c4a40bf033f641ce293cd3df2e'/>
<id>c0017c73578a91c4a40bf033f641ce293cd3df2e</id>
<content type='text'>
NOTE: Support added for xarch target x86_64-elf,
but U-Boot failed to build with this error:

OBJCOPY lib/efi_loader/helloworld.efi
x86_64-elf-objcopy: lib/efi_loader/helloworld_efi.so: invalid bfd target
make[2]: *** [scripts/Makefile.lib:476: lib/efi_loader/helloworld.efi] Error 1

Since I'm building U-Boot for x86_64 *on* an x86-64
host, and since that is currently the recommended type
of machine to use for lbmk development, and since the
other x86 payloads currently don't cross compile anyway,
this is an acceptable compromise for now. This is because
at present, I'm not making U-Boot the primary payload on x86,
instead preferring to chain it from GRUB and SeaBIOS.

The target.cfg file for x86 u-boot shows xarch/xtree commented.
Uncomment these to compile on crossgcc instead of hostcc.

I mention 64-bit because I initially did this first, but decided
to do 32-bit first. I'll work on the 64-bit one next (SPL).

It's only enabled in QEMU for now.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
NOTE: Support added for xarch target x86_64-elf,
but U-Boot failed to build with this error:

OBJCOPY lib/efi_loader/helloworld.efi
x86_64-elf-objcopy: lib/efi_loader/helloworld_efi.so: invalid bfd target
make[2]: *** [scripts/Makefile.lib:476: lib/efi_loader/helloworld.efi] Error 1

Since I'm building U-Boot for x86_64 *on* an x86-64
host, and since that is currently the recommended type
of machine to use for lbmk development, and since the
other x86 payloads currently don't cross compile anyway,
this is an acceptable compromise for now. This is because
at present, I'm not making U-Boot the primary payload on x86,
instead preferring to chain it from GRUB and SeaBIOS.

The target.cfg file for x86 u-boot shows xarch/xtree commented.
Uncomment these to compile on crossgcc instead of hostcc.

I mention 64-bit because I initially did this first, but decided
to do 32-bit first. I'll work on the 64-bit one next (SPL).

It's only enabled in QEMU for now.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>3050micro: Re-enable SeaGRUB</title>
<updated>2024-10-27T19:32:36+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-10-27T19:29:26+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=9bdec645a30ff81abb3f6d3db6c974bf6ab6321f'/>
<id>9bdec645a30ff81abb3f6d3db6c974bf6ab6321f</id>
<content type='text'>
Remove what is now unnecessary bloat, for ensuring that
GRUB is the primary payload; SeaGRUB is the only preference,
as per lbmk design.

The SeaBIOS hanging issue was fixed, so SeaGRUB is OK now.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Remove what is now unnecessary bloat, for ensuring that
GRUB is the primary payload; SeaGRUB is the only preference,
as per lbmk design.

The SeaBIOS hanging issue was fixed, so SeaGRUB is OK now.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>dell3050micro: make GRUB the primary payload</title>
<updated>2024-10-06T08:22:21+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-10-06T08:21:08+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=c99dced5b1022fd2053fa8e47785ce83f4e05f90'/>
<id>c99dced5b1022fd2053fa8e47785ce83f4e05f90</id>
<content type='text'>
SeaBIOS is known to hang on this board. It is being investigated.

Add two variable options for target.cfg files:

* seabiosname
* grubname

This string defines where it would be located in CBFS.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
SeaBIOS is known to hang on this board. It is being investigated.

Add two variable options for target.cfg files:

* seabiosname
* grubname

This string defines where it would be located in CBFS.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Add Sony PlayStation support to Libreboot</title>
<updated>2024-09-25T23:35:18+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-09-25T22:59:52+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=ff9c250a3ec05c9afa3faf84e2e5d793f68361b4'/>
<id>ff9c250a3ec05c9afa3faf84e2e5d793f68361b4</id>
<content type='text'>
I also added a "cleanargs" argument, similar to the makeargs
argument, to work around a build error.

This builds the PCSX-Redux PS1 BIOS. They reverse engineered
the Sony PS1 BIOS and wrote a free one under MIT license.

Run this:

./mk -b pcsx-redux

The file will appear: bin/playstation/openbios.bin

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
I also added a "cleanargs" argument, similar to the makeargs
argument, to work around a build error.

This builds the PCSX-Redux PS1 BIOS. They reverse engineered
the Sony PS1 BIOS and wrote a free one under MIT license.

Run this:

./mk -b pcsx-redux

The file will appear: bin/playstation/openbios.bin

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>lib.sh: new function mk() to handle trees in bulk</title>
<updated>2024-07-28T12:35:31+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-07-28T12:30:25+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=59894ed555ecccf0346a7942e208171a21412d9b'/>
<id>59894ed555ecccf0346a7942e208171a21412d9b</id>
<content type='text'>
single-tree projects cannot be handled in bulk, e.g.
./mk -f project1 project2 project3

that is still the case, from the shell, but internally
it is now possible:
mk -f project1 project2 project3

mk() is a function that simply handles the given flag,
and all projects specified.

it does not handle cases without argument, for example
you cannot do:
mk -f

arguments must be provided. it can be used internally,
to simplify cases where multiple single-tree projects
must be handled, but *also* allows multi-tree projects
to be specified, without being able to actually handle
trees within that multi-tree project; so for example,
you can only specify coreboot, and then it would run
on every coreboot tree.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
single-tree projects cannot be handled in bulk, e.g.
./mk -f project1 project2 project3

that is still the case, from the shell, but internally
it is now possible:
mk -f project1 project2 project3

mk() is a function that simply handles the given flag,
and all projects specified.

it does not handle cases without argument, for example
you cannot do:
mk -f

arguments must be provided. it can be used internally,
to simplify cases where multiple single-tree projects
must be handled, but *also* allows multi-tree projects
to be specified, without being able to actually handle
trees within that multi-tree project; so for example,
you can only specify coreboot, and then it would run
on every coreboot tree.

Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>general code cleanup in the build system</title>
<updated>2024-07-26T14:49:49+00:00</updated>
<author>
<name>Leah Rowe</name>
<email>leah@libreboot.org</email>
</author>
<published>2024-07-26T14:24:00+00:00</published>
<link rel='alternate' type='text/html' href='https://browse.libreboot.org/lbmk.git/commit/?id=7fa6052de036f81b54a93bf2f707f563205f176b'/>
<id>7fa6052de036f81b54a93bf2f707f563205f176b</id>
<content type='text'>
Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Signed-off-by: Leah Rowe &lt;leah@libreboot.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
