x86: Add implementations of setjmp() and longjmp()

This is required for x86 and is also correct for ARM (since it is empty).

Signed-off-by Simon Glass <[email protected]>

Reviewed-by Bin Meng <[email protected]>

Quoted 5 lines · Simon Glass

This is required for x86 and is also correct for ARM (since it is empty).

Signed-off-by Simon Glass <[email protected]>

Reviewed-by Bin Meng <[email protected]>

(Replying here in lack for a cover letter)

Could you please rebase your patches on top of

https://github.com/agraf/u-boot.git efi-next

so that all the patches that I already queued are not repeated in the patch set and we don't get any conflicts?

Hi Alex,

Quoted 12 lines · Alexander Graf

Quoted 5 lines · Simon Glass

This is required for x86 and is also correct for ARM (since it is empty).

Signed-off-by Simon Glass <[email protected]>

Reviewed-by Bin Meng <[email protected]>

(Replying here in lack for a cover letter)

Could you please rebase your patches on top of

Quoted 4 lines

https://github.com/agraf/u-boot.git efi-next

so that all the patches that I already queued are not repeated in the patch set and we don't get any conflicts?

I can do that - but is this targeting -next? I was expecting these patches to land in master.

Quoted 20 lines · Simon Glass

Hi Alex,

Quoted 16 lines · Alexander Graf

Quoted 5 lines · Simon Glass

This is required for x86 and is also correct for ARM (since it is empty).

Signed-off-by Simon Glass <[email protected]>

Reviewed-by Bin Meng <[email protected]>

(Replying here in lack for a cover letter)

Could you please rebase your patches on top of

https://github.com/agraf/u-boot.git efi-next

so that all the patches that I already queued are not repeated in the patch set and we don't get any conflicts?

Quoted 2 lines

I can do that - but is this targeting -next? I was expecting these patches to land in master.

Sorry, they are on their way to master. It's just old habit wrt my naming scheme:

-next: current development branch, basically staging for master

-release-number: future patches that I already applied proactively for
the next release, or backports :)

As it stands, I've only taken the base patches, not all of them. Would you expect all of the x86 efi enablement to land in 2016.11?

At present we use a CONFIG option in efi.h to determine whether we are building the EFI stub or not. This means that the same header cannot be used for EFI_LOADER support. The CONFIG option will be enabled for the whole build, even when not building the stub.

Use a different define instead, set up just for the files that make up the stub.

Signed-off-by Simon Glass <[email protected]>

---

Changes in v3: None
Changes in v2:
- Add new patch to tidy up selection of building the EFI stub

 include/efi.h    | 7 +++++--
 lib/efi/Makefile | 4 ++--
 2 files changed, 7 insertions(+), 4 deletions(-)

It is useful to have a basic sanity check for EFI loader support. Add a 'bootefi hello' command which loads HelloWord.efi and runs it under U-Boot.

Signed-off-by Simon Glass <[email protected]>

---

Changes in v3:
- Include a link to the program instead of adding it to the tree

Changes in v2: None

 arch/x86/lib/Makefile | 1 +
 1 file changed, 1 insertion(+)

It is useful to have a basic sanity check for EFI loader support. Add a 'bootefi hello' command which loads HelloWord.efi and runs it under U-Boot.

Signed-off-by Simon Glass <[email protected]>

---

Changes in v3:
- Include a link to the program instead of adding it to the tree

Quoted 5 lines · Simon Glass

It is useful to have a basic sanity check for EFI loader support. Add a 'bootefi hello' command which loads HelloWord.efi and runs it under U-Boot.

Quoted 5 lines

Signed-off-by Simon Glass <[email protected]>

---

Changes in v3:
- Include a link to the program instead of adding it to the tree

So, uh, where is the link?

I'm really not convinced this command buys us anything yet. I do agree that we want automated testing - but can't we get that using QEMU and a downloadable image file that we pass in as disk and have the distro boot do its magic?

Hi Alex,

Quoted 6 lines · Alexander Graf

Quoted 5 lines · Simon Glass

It is useful to have a basic sanity check for EFI loader support. Add a 'bootefi hello' command which loads HelloWord.efi and runs it under U-Boot.

Quoted 8 lines

Quoted 5 lines

Signed-off-by Simon Glass <[email protected]>

---

Changes in v3:
- Include a link to the program instead of adding it to the tree

So, uh, where is the link?

I put it in the README (see the arm patch).

Quoted 1 line

Quoted 4 lines

I'm really not convinced this command buys us anything yet. I do agree that we want automated testing - but can't we get that using QEMU and a downloadable image file that we pass in as disk and have the distro boot do its magic?

That seems very heavyweight as a sanity check, although I agree it is useful.

Here I am just making sure that EFI programs can start, print output and exit. It is a test that we can easily run without a lot of overhead, much less than a full distro boot.

Quoted 26 lines · Simon Glass

Hi Alex,

Quoted 6 lines · Alexander Graf

Quoted 5 lines · Simon Glass

It is useful to have a basic sanity check for EFI loader support. Add a 'bootefi hello' command which loads HelloWord.efi and runs it under U-Boot.

Quoted 8 lines

Quoted 5 lines

Signed-off-by Simon Glass <[email protected]>

---

Changes in v3:
- Include a link to the program instead of adding it to the tree

So, uh, where is the link?

I put it in the README (see the arm patch).

Quoted 5 lines

I'm really not convinced this command buys us anything yet. I do agree that we want automated testing - but can't we get that using QEMU and a downloadable image file that we pass in as disk and have the distro boot do its magic?

Quoted 1 line

That seems very heavyweight as a sanity check, although I agree it is useful.

It's not really much more heavy weight. The "image file" could simply contain your hello world binary. But with this we don't just verify whether "bootefi" works, but also whether the default boot path works ok.

Quoted 4 lines

Here I am just making sure that EFI programs can start, print output and exit. It is a test that we can easily run without a lot of overhead, much less than a full distro boot.

Again, I don't think it's much more overhead and I do believe it gives us much cleaner separation between responsibilities of code (tests go where tests are).

Hi Alex,

Quoted 29 lines · Alexander Graf

Quoted 26 lines · Simon Glass

Hi Alex,

Quoted 6 lines · Alexander Graf

Quoted 5 lines · Simon Glass

It is useful to have a basic sanity check for EFI loader support. Add a 'bootefi hello' command which loads HelloWord.efi and runs it under U-Boot.

Quoted 8 lines

Quoted 5 lines

Signed-off-by Simon Glass <[email protected]>

---

Changes in v3:
- Include a link to the program instead of adding it to the tree

So, uh, where is the link?

I put it in the README (see the arm patch).

Quoted 5 lines

I'm really not convinced this command buys us anything yet. I do agree that we want automated testing - but can't we get that using QEMU and a downloadable image file that we pass in as disk and have the distro boot do its magic?

Quoted 5 lines

Quoted 1 line

That seems very heavyweight as a sanity check, although I agree it is useful.

It's not really much more heavy weight. The "image file" could simply contain your hello world binary. But with this we don't just verify whether "bootefi" works, but also whether the default boot path works ok.

I don't think I understand what you mean by 'image file'. Is it something other than the .efi file? Do you mean a disk image?

Quoted 6 lines

Quoted 5 lines

Here I am just making sure that EFI programs can start, print output and exit. It is a test that we can easily run without a lot of overhead, much less than a full distro boot.

Quoted 3 lines

Again, I don't think it's much more overhead and I do believe it gives us much cleaner separation between responsibilities of code (tests go where tests are).

You are talking about a functional test, something that tests things end to end. I prefer to at least start with a smaller test. Granted it takes a little more work but it means there are fewer things to hunt through when something goes wrong.

Quoted 47 lines · Simon Glass

Hi Alex,

Quoted 43 lines · Alexander Graf

Quoted 37 lines · Simon Glass

Hi Alex,

Quoted 12 lines · Alexander Graf

Quoted 10 lines · Simon Glass

It is useful to have a basic sanity check for EFI loader support. Add a
'bootefi hello' command which loads HelloWord.efi and runs it under U-Boot.

Signed-off-by Simon Glass <[email protected]>

---

Quoted 6 lines

Quoted 2 lines

Changes in v3:
- Include a link to the program instead of adding it to the tree

So, uh, where is the link?

I put it in the README (see the arm patch).

Quoted 7 lines

I'm really not convinced this command buys us anything yet. I do agree that
we want automated testing - but can't we get that using QEMU and a downloadable image file that we pass in as disk and have the distro boot do
its magic?

That seems very heavyweight as a sanity check, although I agree it is useful.

Quoted 7 lines

Quoted 3 lines

It's not really much more heavy weight. The "image file" could simply contain your hello world binary. But with this we don't just verify whether "bootefi" works, but also whether the default boot path works ok.

I don't think I understand what you mean by 'image file'. Is it something other than the .efi file? Do you mean a disk image?

Yes. For reasonable test coverage, we should also verify that the distro defaults wrote a sane boot script that automatically searches for a default EFI binary in /efi/boot/bootx86.efi on the first partition of all devices and runs it.

So if we just provide an SD card image or hard disk image to QEMU which contains a hello world .efi binary as that default boot file, we don't only test whether the "bootefi" command works, but also whether the distro boot script works.

Quoted 13 lines

Quoted 11 lines

Quoted 6 lines

Here I am just making sure that EFI programs can start, print output and exit. It is a test that we can easily run without a lot of overhead, much less than a full distro boot.

Again, I don't think it's much more overhead and I do believe it gives us much cleaner separation between responsibilities of code (tests go where tests are).

Quoted 4 lines

You are talking about a functional test, something that tests things end to end. I prefer to at least start with a smaller test. Granted it takes a little more work but it means there are fewer things to hunt through when something goes wrong.

Yes, I personally find unit tests terribly annoying and unproductive and functional tests very helpful :). And in this case, the effort to write it is about the same for both, just that the functional test actually tells you that things work or don't work at the end of the day.

With a code base like U-Boot, a simple functional test like the above plus git bisect should get you to an offending patch very quickly.

Am 11.11.2016 um 17:17 schrieb Simon Glass <[email protected]>:

Hi Alex,

Quoted 65 lines · Alexander Graf

Quoted 50 lines · Simon Glass

Hi Alex,

Quoted 44 lines · Alexander Graf

Quoted 41 lines · Simon Glass

Hi Alex,

Quoted 13 lines · Alexander Graf

Quoted 12 lines · Simon Glass

It is useful to have a basic sanity check for EFI loader support. Add a
'bootefi hello' command which loads HelloWord.efi and runs it under U-Boot.

Signed-off-by Simon Glass <[email protected]>

---

Quoted 6 lines

Quoted 2 lines

Changes in v3:
- Include a link to the program instead of adding it to the tree

So, uh, where is the link?

I put it in the README (see the arm patch).

Quoted 7 lines

I'm really not convinced this command buys us anything yet. I do agree that
we want automated testing - but can't we get that using QEMU and a downloadable image file that we pass in as disk and have the distro boot do
its magic?

That seems very heavyweight as a sanity check, although I agree it is useful.

Quoted 7 lines

Quoted 3 lines

It's not really much more heavy weight. The "image file" could simply contain your hello world binary. But with this we don't just verify whether "bootefi" works, but also whether the default boot path works ok.

I don't think I understand what you mean by 'image file'. Is it something other than the .efi file? Do you mean a disk image?

Yes. For reasonable test coverage, we should also verify that the distro defaults wrote a sane boot script that automatically searches for a default EFI binary in /efi/boot/bootx86.efi on the first partition of all devices and runs it.

Quoted 4 lines

So if we just provide an SD card image or hard disk image to QEMU which contains a hello world .efi binary as that default boot file, we don't only test whether the "bootefi" command works, but also whether the distro boot script works.

That's right.

Quoted 19 lines

Quoted 13 lines

Quoted 11 lines

Quoted 6 lines

Here I am just making sure that EFI programs can start, print output and exit. It is a test that we can easily run without a lot of overhead, much less than a full distro boot.

Again, I don't think it's much more overhead and I do believe it gives us much cleaner separation between responsibilities of code (tests go where tests are).

Quoted 4 lines

You are talking about a functional test, something that tests things end to end. I prefer to at least start with a smaller test. Granted it takes a little more work but it means there are fewer things to hunt through when something goes wrong.

Quoted 7 lines

Yes, I personally find unit tests terribly annoying and unproductive and functional tests very helpful :). And in this case, the effort to write it is about the same for both, just that the functional test actually tells you that things work or don't work at the end of the day.

With a code base like U-Boot, a simple functional test like the above plus git bisect should get you to an offending patch very quickly.

This is not a unit test - in fact the EFI stuff has no unit tests. I suppose if we are trying to find a name this is a small functional test since it exercises the general functionality.

I am much keener on small tests than large ones for finding simple bugs. Of course you can generally bisect to find a bug, but the more layers of software you need to look for the harder this is.

We could definitely use a pytest which checks an EFI boot into an image, but I don't think this obviates the need for a smaller targeted test like this one.

Quoted 113 lines

Am 11.11.2016 um 17:17 schrieb Simon Glass <[email protected]>:

Hi Alex,

Quoted 65 lines · Alexander Graf

Quoted 50 lines · Simon Glass

Hi Alex,

Quoted 44 lines · Alexander Graf

Quoted 41 lines · Simon Glass

Hi Alex,

Quoted 13 lines · Alexander Graf

Quoted 12 lines · Simon Glass

It is useful to have a basic sanity check for EFI loader support. Add a
'bootefi hello' command which loads HelloWord.efi and runs it under U-Boot.

Signed-off-by Simon Glass <[email protected]>

---

Quoted 6 lines

Quoted 2 lines

Changes in v3:
- Include a link to the program instead of adding it to the tree

So, uh, where is the link?

I put it in the README (see the arm patch).

Quoted 7 lines

I'm really not convinced this command buys us anything yet. I do agree that
we want automated testing - but can't we get that using QEMU and a downloadable image file that we pass in as disk and have the distro boot do
its magic?

That seems very heavyweight as a sanity check, although I agree it is useful.

Quoted 7 lines

Quoted 3 lines

It's not really much more heavy weight. The "image file" could simply contain your hello world binary. But with this we don't just verify whether "bootefi" works, but also whether the default boot path works ok.

I don't think I understand what you mean by 'image file'. Is it something other than the .efi file? Do you mean a disk image?

Yes. For reasonable test coverage, we should also verify that the distro defaults wrote a sane boot script that automatically searches for a default EFI binary in /efi/boot/bootx86.efi on the first partition of all devices and runs it.

Quoted 4 lines

So if we just provide an SD card image or hard disk image to QEMU which contains a hello world .efi binary as that default boot file, we don't only test whether the "bootefi" command works, but also whether the distro boot script works.

That's right.

Quoted 19 lines

Quoted 13 lines

Quoted 11 lines

Quoted 6 lines

Here I am just making sure that EFI programs can start, print output and exit. It is a test that we can easily run without a lot of overhead, much less than a full distro boot.

Again, I don't think it's much more overhead and I do believe it gives us much cleaner separation between responsibilities of code (tests go where tests are).

Quoted 4 lines

You are talking about a functional test, something that tests things end to end. I prefer to at least start with a smaller test. Granted it takes a little more work but it means there are fewer things to hunt through when something goes wrong.

Quoted 7 lines

Yes, I personally find unit tests terribly annoying and unproductive and functional tests very helpful :). And in this case, the effort to write it is about the same for both, just that the functional test actually tells you that things work or don't work at the end of the day.

With a code base like U-Boot, a simple functional test like the above plus git bisect should get you to an offending patch very quickly.

This is not a unit test - in fact the EFI stuff has no unit tests. I suppose if we are trying to find a name this is a small functional test since it exercises the general functionality.

I am much keener on small tests than large ones for finding simple bugs. Of course you can generally bisect to find a bug, but the more layers of software you need to look for the harder this is.

Quoted 3 lines

We could definitely use a pytest which checks an EFI boot into an image, but I don't think this obviates the need for a smaller targeted test like this one.

I think arguing over this is moot :). More tests is usually a good thing, so whoever gets to write them gets to push them ;). As long as the licenses are sound at least.

Hi Alex,

Quoted 113 lines · Alexander Graf

Quoted 113 lines

Am 11.11.2016 um 17:17 schrieb Simon Glass <[email protected]>:

Hi Alex,

Quoted 65 lines · Alexander Graf

Quoted 50 lines · Simon Glass

Hi Alex,

Quoted 44 lines · Alexander Graf

Quoted 41 lines · Simon Glass

Hi Alex,

Quoted 13 lines · Alexander Graf

Quoted 12 lines · Simon Glass

It is useful to have a basic sanity check for EFI loader support. Add a
'bootefi hello' command which loads HelloWord.efi and runs it under U-Boot.

Signed-off-by Simon Glass <[email protected]>

---

Quoted 6 lines

Quoted 2 lines

Changes in v3:
- Include a link to the program instead of adding it to the tree

So, uh, where is the link?

I put it in the README (see the arm patch).

Quoted 7 lines

I'm really not convinced this command buys us anything yet. I do agree that
we want automated testing - but can't we get that using QEMU and a downloadable image file that we pass in as disk and have the distro boot do
its magic?

That seems very heavyweight as a sanity check, although I agree it is useful.

Quoted 7 lines

Quoted 3 lines

It's not really much more heavy weight. The "image file" could simply contain your hello world binary. But with this we don't just verify whether "bootefi" works, but also whether the default boot path works ok.

I don't think I understand what you mean by 'image file'. Is it something other than the .efi file? Do you mean a disk image?

Yes. For reasonable test coverage, we should also verify that the distro defaults wrote a sane boot script that automatically searches for a default EFI binary in /efi/boot/bootx86.efi on the first partition of all devices and runs it.

Quoted 4 lines

So if we just provide an SD card image or hard disk image to QEMU which contains a hello world .efi binary as that default boot file, we don't only test whether the "bootefi" command works, but also whether the distro boot script works.

That's right.

Quoted 19 lines

Quoted 13 lines

Quoted 11 lines

Quoted 6 lines

Here I am just making sure that EFI programs can start, print output and exit. It is a test that we can easily run without a lot of overhead, much less than a full distro boot.

Again, I don't think it's much more overhead and I do believe it gives us much cleaner separation between responsibilities of code (tests go where tests are).

Quoted 4 lines

You are talking about a functional test, something that tests things end to end. I prefer to at least start with a smaller test. Granted it takes a little more work but it means there are fewer things to hunt through when something goes wrong.

Quoted 7 lines

Yes, I personally find unit tests terribly annoying and unproductive and functional tests very helpful :). And in this case, the effort to write it is about the same for both, just that the functional test actually tells you that things work or don't work at the end of the day.

With a code base like U-Boot, a simple functional test like the above plus git bisect should get you to an offending patch very quickly.

This is not a unit test - in fact the EFI stuff has no unit tests. I suppose if we are trying to find a name this is a small functional test since it exercises the general functionality.

I am much keener on small tests than large ones for finding simple bugs. Of course you can generally bisect to find a bug, but the more layers of software you need to look for the harder this is.

Quoted 5 lines

Quoted 3 lines

We could definitely use a pytest which checks an EFI boot into an image, but I don't think this obviates the need for a smaller targeted test like this one.

I think arguing over this is moot :). More tests is usually a good thing, so whoever gets to write them gets to push them ;). As long as the licenses are sound at least.

OK good, well please can you review this at some point?

Also, are you
planning to write the 'larger' test? How do you test this all in suse?

Quoted 154 lines · Simon Glass

Hi Alex,

Quoted 148 lines · Alexander Graf

Quoted 136 lines

Am 11.11.2016 um 17:17 schrieb Simon Glass <[email protected]>:

Hi Alex,

Quoted 79 lines · Alexander Graf

Quoted 65 lines · Simon Glass

Hi Alex,

Quoted 52 lines · Alexander Graf

Quoted 45 lines · Simon Glass

Hi Alex,

Quoted 15 lines · Alexander Graf

Quoted 14 lines · Simon Glass

It is useful to have a basic sanity check for EFI loader support. Add
a
'bootefi hello' command which loads HelloWord.efi and runs it under
U-Boot.

Signed-off-by Simon Glass <[email protected]>

---

Quoted 7 lines

Quoted 2 lines

Changes in v3:
- Include a link to the program instead of adding it to the tree

So, uh, where is the link?

I put it in the README (see the arm patch).

Quoted 8 lines

I'm really not convinced this command buys us anything yet. I do agree
that
we want automated testing - but can't we get that using QEMU and a downloadable image file that we pass in as disk and have the distro boot do
its magic?

Quoted 3 lines

That seems very heavyweight as a sanity check, although I agree it is
useful.

Quoted 4 lines

It's not really much more heavy weight. The "image file" could simply contain your hello world binary. But with this we don't just verify whether "bootefi" works, but also whether the default boot path works ok.

Quoted 2 lines

I don't think I understand what you mean by 'image file'. Is it something other than the .efi file? Do you mean a disk image?

Yes. For reasonable test coverage, we should also verify that the distro
defaults wrote a sane boot script that automatically searches for a default
EFI binary in /efi/boot/bootx86.efi on the first partition of all devices
and runs it.

Quoted 6 lines

So if we just provide an SD card image or hard disk image to QEMU which contains a hello world .efi binary as that default boot file, we don't only
test whether the "bootefi" command works, but also whether the distro boot
script works.

That's right.

Quoted 31 lines

Quoted 16 lines

Quoted 9 lines

Quoted 6 lines

Here I am just making sure that EFI programs can start, print output and exit. It is a test that we can easily run without a lot of overhead, much less than a full distro boot.

Quoted 4 lines

Again, I don't think it's much more overhead and I do believe it gives
us much cleaner separation between responsibilities of code (tests go where tests are).

Quoted 4 lines

You are talking about a functional test, something that tests things end to end. I prefer to at least start with a smaller test. Granted it takes a little more work but it means there are fewer things to hunt through when something goes wrong.

Yes, I personally find unit tests terribly annoying and unproductive and
functional tests very helpful :). And in this case, the effort to write it
is about the same for both, just that the functional test actually tells you
that things work or don't work at the end of the day.

Quoted 3 lines

With a code base like U-Boot, a simple functional test like the above plus
git bisect should get you to an offending patch very quickly.

This is not a unit test - in fact the EFI stuff has no unit tests. I suppose if we are trying to find a name this is a small functional test since it exercises the general functionality.

Quoted 7 lines

I am much keener on small tests than large ones for finding simple bugs. Of course you can generally bisect to find a bug, but the more layers of software you need to look for the harder this is.

We could definitely use a pytest which checks an EFI boot into an image, but I don't think this obviates the need for a smaller targeted test like this one.

I think arguing over this is moot :). More tests is usually a good thing, so whoever gets to write them gets to push them ;). As long as the licenses are sound at least.

Quoted 1 line

OK good, well please can you review this at some point?

Review what exactly?

Quoted 3 lines

Also, are you
planning to write the 'larger' test? How do you test this all in suse?

Planning yes, but I'm very good at not writing tests :).

Currently I'm testing this all in suse by running systems which rely on the code to work.

Hi Alex,

Quoted 157 lines · Alexander Graf

Quoted 154 lines · Simon Glass

Hi Alex,

Quoted 148 lines · Alexander Graf

Quoted 136 lines

Am 11.11.2016 um 17:17 schrieb Simon Glass <[email protected]>:

Hi Alex,

Quoted 79 lines · Alexander Graf

Quoted 65 lines · Simon Glass

Hi Alex,

Quoted 52 lines · Alexander Graf

Quoted 45 lines · Simon Glass

Hi Alex,

Quoted 15 lines · Alexander Graf

Quoted 14 lines · Simon Glass

It is useful to have a basic sanity check for EFI loader support. Add
a
'bootefi hello' command which loads HelloWord.efi and runs it under
U-Boot.

Signed-off-by Simon Glass <[email protected]>

---

Quoted 7 lines

Quoted 2 lines

Changes in v3:
- Include a link to the program instead of adding it to the tree

So, uh, where is the link?

I put it in the README (see the arm patch).

Quoted 8 lines

I'm really not convinced this command buys us anything yet. I do agree
that
we want automated testing - but can't we get that using QEMU and a downloadable image file that we pass in as disk and have the distro boot do
its magic?

Quoted 3 lines

That seems very heavyweight as a sanity check, although I agree it is
useful.

Quoted 4 lines

It's not really much more heavy weight. The "image file" could simply contain your hello world binary. But with this we don't just verify whether "bootefi" works, but also whether the default boot path works ok.

Quoted 2 lines

I don't think I understand what you mean by 'image file'. Is it something other than the .efi file? Do you mean a disk image?

Yes. For reasonable test coverage, we should also verify that the distro
defaults wrote a sane boot script that automatically searches for a default
EFI binary in /efi/boot/bootx86.efi on the first partition of all devices
and runs it.

Quoted 6 lines

So if we just provide an SD card image or hard disk image to QEMU which contains a hello world .efi binary as that default boot file, we don't only
test whether the "bootefi" command works, but also whether the distro boot
script works.

That's right.

Quoted 31 lines

Quoted 16 lines

Quoted 9 lines

Quoted 6 lines

Here I am just making sure that EFI programs can start, print output and exit. It is a test that we can easily run without a lot of overhead, much less than a full distro boot.

Quoted 4 lines

Again, I don't think it's much more overhead and I do believe it gives
us much cleaner separation between responsibilities of code (tests go where tests are).

Quoted 4 lines

You are talking about a functional test, something that tests things end to end. I prefer to at least start with a smaller test. Granted it takes a little more work but it means there are fewer things to hunt through when something goes wrong.

Yes, I personally find unit tests terribly annoying and unproductive and
functional tests very helpful :). And in this case, the effort to write it
is about the same for both, just that the functional test actually tells you
that things work or don't work at the end of the day.

Quoted 3 lines

With a code base like U-Boot, a simple functional test like the above plus
git bisect should get you to an offending patch very quickly.

This is not a unit test - in fact the EFI stuff has no unit tests. I suppose if we are trying to find a name this is a small functional test since it exercises the general functionality.

Quoted 7 lines

I am much keener on small tests than large ones for finding simple bugs. Of course you can generally bisect to find a bug, but the more layers of software you need to look for the harder this is.

We could definitely use a pytest which checks an EFI boot into an image, but I don't think this obviates the need for a smaller targeted test like this one.

I think arguing over this is moot :). More tests is usually a good thing, so whoever gets to write them gets to push them ;). As long as the licenses are sound at least.

Quoted 4 lines

Quoted 1 line

OK good, well please can you review this at some point?

Review what exactly?

I mean the patches. There should be ~14 in your queue.

Quoted 195 lines · Simon Glass

Hi Alex,

Quoted 191 lines · Alexander Graf

Quoted 184 lines · Simon Glass

Hi Alex,

Quoted 170 lines · Alexander Graf

Quoted 160 lines

Am 11.11.2016 um 17:17 schrieb Simon Glass <[email protected]>:

Hi Alex,

Quoted 91 lines · Alexander Graf

Quoted 76 lines · Simon Glass

Hi Alex,

Quoted 60 lines · Alexander Graf

Quoted 52 lines · Simon Glass

Hi Alex,

Quoted 17 lines

Quoted 14 lines · Alexander Graf

On 10/18/2016 04:29 AM, Simon Glass wrote:

It is useful to have a basic sanity check for EFI loader support.
Add
a
'bootefi hello' command which loads HelloWord.efi and runs it under
U-Boot.

Signed-off-by Simon Glass <[email protected]>

---

Quoted 8 lines

Quoted 2 lines

Changes in v3:
- Include a link to the program instead of adding it to the tree

So, uh, where is the link?

I put it in the README (see the arm patch).

Quoted 10 lines

I'm really not convinced this command buys us anything yet. I do agree
that
we want automated testing - but can't we get that using QEMU and a
downloadable image file that we pass in as disk and have the distro
boot do
its magic?

Quoted 3 lines

That seems very heavyweight as a sanity check, although I agree it is
useful.

Quoted 6 lines

It's not really much more heavy weight. The "image file" could simply
contain your hello world binary. But with this we don't just verify whether "bootefi" works, but also whether the default boot path works
ok.

Quoted 2 lines

I don't think I understand what you mean by 'image file'. Is it something other than the .efi file? Do you mean a disk image?

Yes. For reasonable test coverage, we should also verify that the distro
defaults wrote a sane boot script that automatically searches for a default
EFI binary in /efi/boot/bootx86.efi on the first partition of all devices
and runs it.

Quoted 8 lines

So if we just provide an SD card image or hard disk image to QEMU which
contains a hello world .efi binary as that default boot file, we don't
only
test whether the "bootefi" command works, but also whether the distro boot
script works.

That's right.

Quoted 38 lines

Quoted 20 lines

Quoted 11 lines

Quoted 7 lines

Here I am just making sure that EFI programs can start, print output
and exit. It is a test that we can easily run without a lot of overhead, much less than a full distro boot.

Quoted 5 lines

Again, I don't think it's much more overhead and I do believe it gives
us much cleaner separation between responsibilities of code (tests go
where tests are).

Quoted 5 lines

You are talking about a functional test, something that tests things end to end. I prefer to at least start with a smaller test. Granted it
takes a little more work but it means there are fewer things to hunt through when something goes wrong.

Yes, I personally find unit tests terribly annoying and unproductive and
functional tests very helpful :). And in this case, the effort to write
it
is about the same for both, just that the functional test actually tells you
that things work or don't work at the end of the day.

Quoted 3 lines

With a code base like U-Boot, a simple functional test like the above plus
git bisect should get you to an offending patch very quickly.

This is not a unit test - in fact the EFI stuff has no unit tests. I suppose if we are trying to find a name this is a small functional test since it exercises the general functionality.

Quoted 7 lines

I am much keener on small tests than large ones for finding simple bugs. Of course you can generally bisect to find a bug, but the more layers of software you need to look for the harder this is.

We could definitely use a pytest which checks an EFI boot into an image, but I don't think this obviates the need for a smaller targeted test like this one.

Quoted 5 lines

I think arguing over this is moot :). More tests is usually a good thing,
so whoever gets to write them gets to push them ;). As long as the licenses
are sound at least.

OK good, well please can you review this at some point?

Quoted 4 lines

Quoted 1 line

Review what exactly?

I mean the patches. There should be ~14 in your queue.

Interesting. I see them on patchwork, but neither in my U-Boot folder, my inbox nor my spam folder. I wonder what happened there.

Bring in these functions from Linux v4.4. They will be needed for EFI loader support.

Signed-off-by Simon Glass <[email protected]>

---

Changes in v3:
- Add a parameter to longjmp()
- Drop unused header files

Changes in v2:
- Drop irrelevant comment
- Add a comment about .size
- Drop unnecessary .text directive
- Make longjmp() always cause setjmp() to return 1

 arch/x86/cpu/Makefile         |  2 +-
 arch/x86/cpu/setjmp.S         | 61 +++++++++++++++++++++++++++++++++++++++++++
 arch/x86/include/asm/setjmp.h | 24 +++++++++++++++++
 3 files changed, 86 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/cpu/setjmp.S
 create mode 100644 arch/x86/include/asm/setjmp.h

Quoted 16 lines · Simon Glass

Bring in these functions from Linux v4.4. They will be needed for EFI loader support.

Signed-off-by Simon Glass <[email protected]>

---

Changes in v3:
- Add a parameter to longjmp()
- Drop unused header files

Changes in v2:
- Drop irrelevant comment
- Add a comment about .size
- Drop unnecessary .text directive
- Make longjmp() always cause setjmp() to return 1

Quoted 7 lines

 arch/x86/cpu/Makefile         |  2 +-
 arch/x86/cpu/setjmp.S         | 61 +++++++++++++++++++++++++++++++++++++++++++
 arch/x86/include/asm/setjmp.h | 24 +++++++++++++++++
 3 files changed, 86 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/cpu/setjmp.S
 create mode 100644 arch/x86/include/asm/setjmp.h

Reviewed-by Bin Meng <[email protected]>