In D6879#144346, @nwhitehorn wrote:

Thanks! Please go ahead and commit.

Thank you for the review.

Thank you for reviewing the code.

All reviewers comments have been applied.
Booting from ZFS have been removed for now.

Partition scheme screen from Thunder:

Oh.sorry True. This one is really old.

Just try this:

~/tmp/mkimg]$ dd if=/dev/zero of=efi.img.part bs=1024 count=$((1024*4))
4096+0 records in
4096+0 records out
4194304 bytes transferred in 0.055327 secs (75809436 bytes/sec)
~/tmp/mkimg]$ dd if=/dev/zero of=other.img.part bs=1024 count=$((1024*4))
4096+0 records in
4096+0 records out
4194304 bytes transferred in 0.050146 secs (83641674 bytes/sec)
~/tmp/mkimg]$ mkimg -s mbr efi:=efi.img.part freebsd:=other.img.part  -o final.img
~/tmp/mkimg]$ mkimg -s mbr -p efi:=efi.img.part -p freebsd:=other.img.part  -o final.img
mkimg: partition 1: Invalid argument
~/tmp/mkimg]$ mkimg -s MBR -p efi:=efi.img.part -p freebsd:=other.img.part  -o final.img
mkimg: partition 1: Invalid argument
~/tmp/mkimg]$ mkimg -s gtp -p efi:=efi.img.part -p freebsd:=other.img.part  -o final.img
mkimg: scheme: Invalid argument
~/tmp/mkimg]$ mkimg -s gpt -p efi:=efi.img.part -p freebsd:=other.img.part  -o final.img
~/tmp/mkimg]$ echo $?
0
~/tmp/mkimg]$

The script does not work at all because the syntax of mkimg is broken. This script generates no image when there is "-s mbr". You are not able to create memstick.img with this script. I have been able to create GPT type memstick and boot it of SATA and USB flash drive on ThunderX.

ed, gjb, wma can you please proceed with review? Do you have any more comments?

The oldest firmwre version, I have tested, is:
Firmware Version: 2016-02-12 12:59:55
BDK Version: thunder-release-v1.20-2-gd555028, Branch: remotes/origin/thunder-dev, Built: pią, 12 lut 2016, 11:58:38 UTC
("pią 12 lut" is "Fri Feb 12")

The problem was not with the EFI. The gpart, that has been called by, mkimg refused to create such combination of partitions.
When I have invoked "make memstick (...)" I got memstick.img.part prepared but mkimg fails producing memstick.img.
When I have tested the mkimg command line it seemd that the "-s mbr" does not want to work with "-p efi:=(...)".
producing error: "mkimg: partition 1: Invalid argument" . Changing the "-s mbr" to "-s gpt" fixed the problem and created image did boot.
I did not know abot the problem with UUID you have mentioned. I have faced problem creating the img itself - but this is good to know. I wil give you the firmware info on Monday since I have no remote access to board right now.

Explanation for x5 zeroing before jumping to "normal" for buffers of size <= 16 has been added.

Something more to fix?

Reviewers comments have been applied.

In D5726#123719, @kib wrote:

Initial NULL check is still there.

Do you have any more comments regarding the latest changes?
I would like to move forward with this and need to know if you are OK with the soultion or need some changes to it.

Provided comment as requested.

In D5741#123261, @kib wrote:

There seems to be some issues with spaces/tabs between instructions and operands.

All reviewers' comments have been applited.

All of reviewers' comments have been applied.

In D5741#122931, @kib wrote:

Wouldn't it be (much) cleaner to select one of two implementations (dc/stp) e.g. by function pointer ?

Review comments have been applied with following differences:

• will jump directly to normal for buffers with size <= 16 rather than 8 as suggested by wma
• function has not been split because optimized pagezero is in work; which is much more simplier than bzero

Implemented fixes suggested by kib.

In D5719#122136, @andrew wrote:

Because of this I don't see how this would be anything other than an optimisation.

We do not want this kind of optimizations? I do not see why it is worth to engage CPU cycles in action, that is certain to fail. That is sloppy from our side.

Not when it's an optimisation for an uncommon case at the cost of the common case.

In D5719#122136, @andrew wrote:

Because of this I don't see how this would be anything other than an optimisation.

I agree that the solution that you propose is more elegant. And takes less instructions.

In D5664#120939, @andrew wrote:

Can you also try with smaller bs values in dd to show how the performance changes for buffer sizes.

I have tested bs from 4096 to above 1024kB. the 3.6GB has been achievend with 512kB block size; increasing the block size above that does not seem to improve the performance.

ACK.

In D4324#98953, @ngie wrote:

Hi,

Just saw this review. We (Isilon) have a different change that implements this in userspace (IIRC). Is there a reason why this was implemented in the kernel instead?

Thanks,
-NGie

Following has been fixed according to requests:

• Panic when unknown file format (non-elf/gzelf) file has been provided.
• duplicated code has been removed
• problem with file left open in case of error with gzelf file loading