forked from Xilinx/bootgen
-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathhelp.h
More file actions
executable file
·1940 lines (1868 loc) · 142 KB
/
help.h
File metadata and controls
executable file
·1940 lines (1868 loc) · 142 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
/******************************************************************************
* Copyright 2015-2019 Xilinx, Inc.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
******************************************************************************/
#pragma once
#ifndef _HELP_H_
#define _HELP_H_
/*
-------------------------------------------------------------------------------
*********************************************** H E A D E R F I L E S ***
-------------------------------------------------------------------------------
*/
#include <string>
/******************************************************************************
arch
******************************************************************************/
#define ARCHHELP "\
-------------+----------------------------------------------------------------+\n\
OPTION | arch |\n\
-------------+----------------------------------------------------------------+\n\
DESCRIPTION | Xilinx family architecture for which the bootimage needs to |\n\
| be created |\n\
-------------+----------------------------------------------------------------+\n\
SYNOPSIS | -arch [arguments] |\n\
-------------+----------------------------------------------------------------+\n\
ARGUMENTS | *zynq : Image is targeted for ZYNQ architecture |\n\
| zynqmp : Image is targeted for ZYNQ MP SoC architecture |\n\
| fpga : Image is targeted for other FPGA architectures |\n\
-------------+----------------------------------------------------------------+\n\
USAGE | [bootgen -arch zynq -image test.bif -o boot.bin] |\n\
-------------+----------------------------------------------------------------+\n\
EXPLANATION | boot.bin generated is a Zynq boot image |\n\
-------------+----------------------------------------------------------------+\n"
/******************************************************************************
image
******************************************************************************/
#define IMAGEHELP "\
-------------+----------------------------------------------------------------+\n\
OPTION | image |\n\
-------------+----------------------------------------------------------------+\n\
DESCRIPTION | Input BIF file name |\n\
| BIF file specifies each component of the boot image in order of|\n\
| boot and allows optional attributes to be specified to each |\n\
| image component. Each image component is usually mapped to a |\n\
| partition, but in some cases an image component can be mapped |\n\
| to more than one partition if the image component is not |\n\
| contiguous in memory |\n\
-------------+----------------------------------------------------------------+\n\
SYNOPSIS | -image <bif filename> |\n\
-------------+----------------------------------------------------------------+\n\
USAGE | [bootgen -arch zynq -image test.bif -o boot.bin] |\n\
-------------+----------------------------------------------------------------+\n\
EXPLANATION | test.bif is the input BIF file |\n\
| Sample BIF file is shown below |\n\
| the_ROM_image: |\n\
| { |\n\
| [init] init_data.int |\n\
| [bootloader] Fsbl.elf |\n\
| Partition1.bit |\n\
| Partition2.elf |\n\
| } |\n\
-------------+----------------------------------------------------------------+\n"
/******************************************************************************
split
******************************************************************************/
#define SPLITHELP "\
-------------+----------------------------------------------------------------+\n\
OPTION | split |\n\
-------------+----------------------------------------------------------------+\n\
DESCRIPTION | This option outputs each data partition with headers as a new |\n\
| file in MCS or BIN format. |\n\
-------------+----------------------------------------------------------------+\n\
SYNOPSIS | -split [arguments] |\n\
-------------+----------------------------------------------------------------+\n\
ARGUMENTS | bin : Output files generated in bin format |\n\
| mcs : Output files generated in mcs format |\n\
-------------+----------------------------------------------------------------+\n\
USAGE | [bootgen -arch zynq -image test.bif -split bin] |\n\
-------------+----------------------------------------------------------------+\n\
EXPLANATION | Consider the sample bif |\n\
| the_ROM_image: |\n\
| { |\n\
| [bootloader] Fsbl.elf |\n\
| Partition1.bit |\n\
| Partition2.elf |\n\
| } |\n\
| Output files generated are: |\n\
| 1. Bootheader + Image Headers + Partition Headers + Fsbl.elf |\n\
| 2. Partition1.bit |\n\
| 3. Partition2.elf |\n\
-------------+----------------------------------------------------------------+\n"
/******************************************************************************
fill
******************************************************************************/
#define FILLHELP "\
-------------+----------------------------------------------------------------+\n\
OPTION | fill |\n\
-------------+----------------------------------------------------------------+\n\
DESCRIPTION | This option specifies the byte to use for filling extra memory |\n\
-------------+----------------------------------------------------------------+\n\
SYNOPSIS | -fill <hex byte> |\n\
-------------+----------------------------------------------------------------+\n\
USAGE | [bootgen -arch zynq -image test.bif -fill 0xAB -o boot.bin] |\n\
-------------+----------------------------------------------------------------+\n\
EXPLANATION | Byte 0xAB is padded in the header tables instead of 0xFF when |\n\
| fill is specified. |\n\
-------------+----------------------------------------------------------------+\n"
/******************************************************************************
o
******************************************************************************/
#define OHELP "\
-------------+----------------------------------------------------------------+\n\
OPTION | o |\n\
-------------+----------------------------------------------------------------+\n\
DESCRIPTION | This option specifies the name of the output image file with |\n\
| bin or mcs extension. |\n\
-------------+----------------------------------------------------------------+\n\
SYNOPSIS | -o <filename> |\n\
-------------+----------------------------------------------------------------+\n\
USAGE | [bootgen -arch zynq -image test.bif -o boot.mcs] |\n\
-------------+----------------------------------------------------------------+\n\
EXPLANATION | The output image is generated with name boot.mcs |\n\
| The format of the output image is decided based on the file |\n\
| extension of the file given with '-o' option |\n\
-------------+----------------------------------------------------------------+\n"
/******************************************************************************
p
******************************************************************************/
#define PHELP "\
-------------+----------------------------------------------------------------+\n\
OPTION | p |\n\
-------------+----------------------------------------------------------------+\n\
DESCRIPTION | This option specifies the partname of the Xilinx chip. |\n\
| This is needed for generating a encryption key. It is copied |\n\
| verbatim to the *.nky file in the 'Device' line. |\n\
| This is applicable only with encryption is enabled. |\n\
-------------+----------------------------------------------------------------+\n\
SYNOPSIS | -p <part name> |\n\
-------------+----------------------------------------------------------------+\n\
USAGE | [bootgen -image test.bif -o boot.bin -p xc7z020clg484 |\n\
| -encrypt efuse] |\n\
-------------+----------------------------------------------------------------+\n\
EXPLANATION | If the key file is not present in the path specified in BIF |\n\
| file, then a new encryption key is generated in the same path |\n\
| and xc7z020clg484 is copied along side the 'Device' field in |\n\
| the nky file. The generated image is an encrypted image. |\n\
-------------+----------------------------------------------------------------+\n"
/******************************************************************************
w
******************************************************************************/
#define WHELP "\
-------------+----------------------------------------------------------------+\n\
OPTION | w |\n\
-------------+----------------------------------------------------------------+\n\
DESCRIPTION | This option specifies whether to overwrite an existing file or |\n\
| not. |\n\
-------------+----------------------------------------------------------------+\n\
SYNOPSIS | -w [arguments] |\n\
-------------+----------------------------------------------------------------+\n\
ARGUMENTS | on : Overwrite the existing file |\n\
| *off : Don't overwrite the existing file |\n\
-------------+----------------------------------------------------------------+\n\
USAGE | [bootgen -image test.bif -w on -o boot.bin] or |\n\
| [bootgen -image test.bif -w -o boot.bin] |\n\
-------------+----------------------------------------------------------------+\n\
EXPLANATION | If the file boot.bin already exists in the path, then it is |\n\
| overwritten. |\n\
| Options '-w on' & '-w' are treated as same |\n\
| If the '-w' option is not specified, the file will not be |\n\
| overwritten by default |\n\
-------------+----------------------------------------------------------------+\n"
/******************************************************************************
efuseppkbits
******************************************************************************/
#define EFUSEPPKBITSHELP "\
-------------+----------------------------------------------------------------+\n\
OPTION | efuseppkbits |\n\
-------------+----------------------------------------------------------------+\n\
DESCRIPTION | This option specifies the name of the efuse file to be written |\n\
| to contain the PPK hash. This option generates a direct hash |\n\
| without any padding. |\n\
| Zynq : Hashing done by SHA2 |\n\
| ZynqMP : Hashing done by SHA3 |\n\
-------------+----------------------------------------------------------------+\n\
SYNOPSIS | -efuseppkbits <filename> |\n\
-------------+----------------------------------------------------------------+\n\
USAGE | [bootgen -image test.bif -o boot.bin |\n\
| -efuseppkbits efusefile.txt] |\n\
-------------+----------------------------------------------------------------+\n\
EXPLANATION | efusefile.txt file gets generated, which contains the hash of |\n\
| the PPK key. |\n\
-------------+----------------------------------------------------------------+\n"
/******************************************************************************
zynqmpes1
******************************************************************************/
#define ZYNQMPES1HELP "\
-------------+----------------------------------------------------------------+\n\
OPTION | zynqmpes1 |\n\
-------------+----------------------------------------------------------------+\n\
DESCRIPTION | This option specifies that the image generated will be used |\n\
| on ES1(1.0). |\n\
| This option makes a difference only when generating |\n\
| authenticated image, else ignored. |\n\
-------------+----------------------------------------------------------------+\n\
SYNOPSIS | -zynqmpes1 |\n\
-------------+----------------------------------------------------------------+\n\
USAGE | [bootgen -image test.bif -o boot.bin -zynqmpes1 ] |\n\
-------------+----------------------------------------------------------------+\n\
EXPLANATION | The authentication padding scheme will be as per ES1(1.0). |\n\
| The default padding scheme is for (2.0)ES2 and above. |\n\
-------------+----------------------------------------------------------------+\n"
/******************************************************************************
generate_hashes
******************************************************************************/
#define GENERATEHASHESHELP "\
-------------+----------------------------------------------------------------+\n\
OPTION | generate_hashes |\n\
-------------+----------------------------------------------------------------+\n\
DESCRIPTION | This option generates file containing PKCS#1v1.5 padded hash |\n\
|----------------------------------------------------------------|\n\
| Zynq Format: |\n\
| SHA-2 (256 bytes) |\n\
| +-----------+-----------+------+------+------+------+ |\n\
| | SHA2 Hash | T-Padding | 0x00 | 0xFF | 0x01 | 0x00 | |\n\
| +-----------+-----------+------+------+------+------+ |\n\
| Bytes:| 32* | 19 | 1 | 202 | 1 | 1 | |\n\
| +-----------+-----------+------+------+------+------+ |\n\
| * 32 byte hash is reversed. |\n\
|----------------------------------------------------------------|\n\
| ZynqMP Format: |\n\
| SHA-3 (384 bytes) |\n\
| +------+------+------+------+-----------+-----------+ |\n\
| | 0x00 | 0x01 | 0xFF | 0x00 | T-Padding | SHA3 Hash | |\n\
| +------+------+------+------+-----------+-----------+ |\n\
| Bytes:| 1 | 1 | 314 | 1 | 19 | 48 | |\n\
| +------+------+------+------+-----------+-----------+ |\n\
-------------+----------------------------------------------------------------+\n\
SYNOPSIS | -generate_hashes |\n\
-------------+----------------------------------------------------------------+\n\
USAGE | [bootgen -image test.bif -generate_hashes] |\n\
-------------+----------------------------------------------------------------+\n\
EXPLANATION | To generate a SPK hash |\n\
| Sample BIF - test.bif |\n\
| all: |\n\
| { |\n\
| [spkfile]secondary.pub |\n\
| } |\n\
-------------+----------------------------------------------------------------+\n"
/******************************************************************************
padimageheader
******************************************************************************/
#define PADHDRHELP "\
-------------+----------------------------------------------------------------+\n\
OPTION | padimageheader |\n\
-------------+----------------------------------------------------------------+\n\
DESCRIPTION | This option pads the Image Header Table and Partition Header |\n\
| Table to maximum partitions allowed, to force alignment of |\n\
| following partitions. This feature is enabled by default. |\n\
| Specifying a 0, disables this feature |\n\
| Zynq : Maximum Partitions - 14 |\n\
| ZynqMP : Maximum Partitions - 32 partitions |\n\
-------------+----------------------------------------------------------------+\n\
SYNOPSIS | -padimageheader=[arguments] |\n\
-------------+----------------------------------------------------------------+\n\
ARGUMENTS | *1 : Pad the header tables to max partitions |\n\
| 0 : Do not pad the header tables |\n\
-------------+----------------------------------------------------------------+\n\
USAGE | [bootgen -image test.bif -w on -o boot.bin -padimageheader=0] |\n\
-------------+----------------------------------------------------------------+\n\
EXPLANATION | boot.bin has the image header tables and partition header |\n\
| tables in actual and no extra tables are padded. If nothing is |\n\
| specified or -padimageheader=1, then total image header tables |\n\
| and partition header tables are padded to max partitions. |\n\
-------------+----------------------------------------------------------------+\n"
/******************************************************************************
spksignature
******************************************************************************/
#define SPKSIGNHELP "\
-------------+----------------------------------------------------------------+\n\
OPTION | spksignature |\n\
-------------+----------------------------------------------------------------+\n\
DESCRIPTION | This option is used to generate the SPK signature file. This |\n\
| option must be used only when [spkfile] & [pskfile] are |\n\
| specified in BIF |\n\
-------------+----------------------------------------------------------------+\n\
SYNOPSIS | -spksignature <filename> |\n\
-------------+----------------------------------------------------------------+\n\
USAGE | [bootgen -image test.bif -w on -o boot.bin |\n\
| -spksignature spksignfile.txt] |\n\
-------------+----------------------------------------------------------------+\n\
EXPLANATION | The SPK signature file (spksignfile.txt) is generated. |\n\
-------------+----------------------------------------------------------------+\n"
/******************************************************************************
debug
******************************************************************************/
#define DEBUGHELP "\
-------------+----------------------------------------------------------------+\n\
OPTION | debug |\n\
-------------+----------------------------------------------------------------+\n\
DESCRIPTION | This option is deprecated. |\n\
| Please refer -log option |\n\
-------------+----------------------------------------------------------------+\n"
/******************************************************************************
encrypt
******************************************************************************/
#define ENCRYPTHELP "\
-------------+----------------------------------------------------------------+\n\
OPTION | encrypt |\n\
-------------+----------------------------------------------------------------+\n\
DESCRIPTION | This option specifies how to do encryption, where the keys are |\n\
| stored. |\n\
-------------+----------------------------------------------------------------+\n\
SYNOPSIS | -encrypt [key source args] <filename> |\n\
-------------+----------------------------------------------------------------+\n\
ARGUMENTS | Key source arguments: |\n\
| efuse : The AES key is stored in EFUSE |\n\
| bbram : The AES key is stored in BBRAM |\n\
|----------------------------------------------------------------|\n\
| filename : Key file name in .nky format. IV, AES and HMAC keys |\n\
| are specified in the file itself. |\n\
-------------+----------------------------------------------------------------+\n\
USAGE | [bootgen -image test.bif -o boot.bin -encrypt efuse] |\n\
-------------+----------------------------------------------------------------+\n\
EXPLANATION | The .nky key file is passed through BIF file attribute |\n\
| [aeskeyfile]. Only source is specified through command line. |\n\
-------------+----------------------------------------------------------------+\n"
/******************************************************************************
generate_keys
******************************************************************************/
#define GENKEYSHELP "\
-------------+----------------------------------------------------------------+\n\
OPTION | generate_keys |\n\
-------------+----------------------------------------------------------------+\n\
DESCRIPTION | This option generates keys. |\n\
| . Generates authentication keys in rsa/pem format. |\n\
| . Generate Obfuscated Key for encryption. |\n\
| BIF File should have the paths of all the keys. |\n\
-------------+----------------------------------------------------------------+\n\
SYNOPSIS | For authentication : |\n\
| -generate_keys [arguments] |\n\
| For encryption : |\n\
| -generate_keys obfuscatedkey |\n\
-------------+----------------------------------------------------------------+\n\
ARGUMENTS | Format of authentication keys |\n\
| rsa : RSA format keys |\n\
| pem : PEM format keys |\n\
-------------+----------------------------------------------------------------+\n\
USAGE | For authentication : |\n\
| [bootgen -image test.bif -generate_keys rsa] |\n\
| For encryption : |\n\
| [bootgen -image test.bif -generate_keys obfuscatedkey] |\n\
-------------+----------------------------------------------------------------+\n\
EXPLANATION | For authentication : |\n\
| Contents of BIF file: test.bif |\n\
| image: |\n\
| { |\n\
| [ppkfile] <path/ppkgenfile.txt> |\n\
| [pskfile] <path/pskgenfile.txt> |\n\
| [spkfile] <path/spkgenfile.txt> |\n\
| [sskfile] <path/sskgenfile.txt> |\n\
| } |\n\
| The key files are generated in the paths mentioned above |\n\
|----------------------------------------------------------------|\n\
| For encryption : |\n\
| image: |\n\
| { |\n\
| [aeskeyfile] aes.nky |\n\
| [bh_key_iv] bhkeyiv.txt |\n\
| [familykey] familykey.txt |\n\
| } |\n\
-------------+----------------------------------------------------------------+\n\
NOTES | PEM Key Format: |\n\
| -----BEGIN RSA PRIVATE KEY----- |\n\
| MIIEpAIBAAKCAQEAmlJyPcZVXltASHrtm/YnOMxskf0k2RZrIajqymqZptnG |\n\
| kyBMalXaqmGb1kqGCgGZVvQt3FSRO3yXa.... |\n\
| -----END RSA PRIVATE KEY----- |\n\
|----------------------------------------------------------------|\n\
| RSA Key Format: |\n\
| N = c6b9a521234567890abc4d4567e99f1234567891235987564.... |\n\
| E = 10001 |\n\
| D = 37c80c81234567890abcdef1234567890abcdef1234567790.... |\n\
-------------+----------------------------------------------------------------+\n"
/******************************************************************************
dual_qspi_mode
******************************************************************************/
#define DQSPIHELP "\
-------------+----------------------------------------------------------------+\n\
OPTION | dual_qspi_mode |\n\
-------------+----------------------------------------------------------------+\n\
DESCRIPTION | This option generates output files as per the configuration |\n\
| specified by the Dual QSPI mode |\n\
-------------+----------------------------------------------------------------+\n\
SYNOPSIS | -dual_qspi_mode [arguments] |\n\
-------------+----------------------------------------------------------------+\n\
ARGUMENTS | parallel : |\n\
| The QSPI configuration is Dual Parallel |\n\
| Generates 2 output files, the actual output is written to |\n\
| two different files in bit-by-bit fashion. |\n\
| stacked <size> : |\n\
| The QSPI configuration is Dual Stacked. |\n\
| Generates 2 output files, in sequential fashion. |\n\
| <size> - Size of flash in MB (16/32/64/128) |\n\
| Both the flashes can then be programmed independently. |\n\
-------------+----------------------------------------------------------------+\n\
USAGE | 1. [bootgen -image test.bif -o -boot.bin |\n\
| -dual_qspi_mode parallel] |\n\
|----------------------------------------------------------------|\n\
| 2. [bootgen -image test.bif -o -boot.bin |\n\
| -dual_qspi_mode stacked 64] |\n\
-------------+----------------------------------------------------------------+\n\
EXPLANATION | Suppose the output bootimage content is around 120MB |\n\
| Usage 1: Two files are generated boot_1.bin & boot_2.bin of |\n\
| 60MB each |\n\
| Usage 2: Two files are generated boot_1.bin & boot_2.bin of |\n\
| 64MB & 56MB |\n\
|----------------------------------------------------------------|\n\
| Suppose the output bootimage content is around 50MB |\n\
| Usage 1: Two files are generated boot_1.bin & boot_2.bin of |\n\
| 25MB each |\n\
| Usage 2: Only one file is generated boot_1.bin of 50MB |\n\
-------------+----------------------------------------------------------------+\n"
/******************************************************************************
log
******************************************************************************/
#define LOGHELP "\
-------------+----------------------------------------------------------------+\n\
OPTION | log |\n\
-------------+----------------------------------------------------------------+\n\
DESCRIPTION | This command generates log while generating the bootimage. |\n\
| There are various options for choosing the level of information|\n\
| The information is displayed on the console as well as log file|\n\
| named 'bootgen_log.txt' in the current working directory. |\n\
-------------+----------------------------------------------------------------+\n\
SYNOPSIS | -log [arguments] |\n\
-------------+----------------------------------------------------------------+\n\
ARGUMENTS | error : Only the error information is captured. |\n\
| warning : The warnings & error information is captured. |\n\
|*info : The general info and all the above info is captured. |\n\
| debug : The debugging info in case of errors is captured in |\n\
| in detail and all the above info is captured. |\n\
| trace : More detailed information is captured along with the |\n\
| above |\n\
-------------+----------------------------------------------------------------+\n\
USAGE | [bootgen -image test.bif -o -boot.bin -log trace] |\n\
-------------+----------------------------------------------------------------+\n\
EXPLANATION | The detailed info is described while creating the bootimage. |\n\
| The file 'bootgen_log.txt' is generated. |\n\
-------------+----------------------------------------------------------------+\n"
/******************************************************************************
bif_help
******************************************************************************/
#define BIFHELP "\
-------------+----------------------------------------------------------------+\n\
OPTION | bif_help |\n\
-------------+----------------------------------------------------------------+\n\
DESCRIPTION | This option is used to list all the supported BIF file |\n\
| attributes. |\n\
-------------+----------------------------------------------------------------+\n\
SYNOPSIS | -bif_help [arguments] |\n\
-------------+----------------------------------------------------------------+\n\
ARGUMENTS | Any of the bif keywords |\n\
-------------+----------------------------------------------------------------+\n\
USAGE | 1. [bootgen -bif_help] |\n\
| 2. [bootgen -bif_help aeskeyfile] |\n\
-------------+----------------------------------------------------------------+\n\
EXPLANATION | Usage 1: All the bif file attributes are listed |\n\
| Usage 2: Detailed explanation of the attribute aeskeyfile with |\n\
| example |\n\
-------------+----------------------------------------------------------------+\n"
/******************************************************************************
process_bitstream
******************************************************************************/
#define PROCESSBITHELP "\
-------------+----------------------------------------------------------------+\n\
OPTION | process_bitstream |\n\
-------------+----------------------------------------------------------------+\n\
DESCRIPTION | Processes only bitstream from the BIF, and output as an MCS or |\n\
| a BIN file. |\n\
| For example: If encryption is selected for bitstream in the BIF|\n\
| file, the output is an encrypted bitstream. |\n\
-------------+----------------------------------------------------------------+\n\
SYNOPSIS | -process_bitstream [arguments] |\n\
-------------+----------------------------------------------------------------+\n\
ARGUMENTS | bin : Output in bin format |\n\
| mcs : Output in mcs format |\n\
-------------+----------------------------------------------------------------+\n\
USAGE | [bootgen -arch zynq -image test.bif -process_bitstream bin] |\n\
-------------+----------------------------------------------------------------+\n\
EXPLANATION | Sample BIF - test.bif |\n\
| all: |\n\
| { |\n\
| system.bit |\n\
| } |\n\
| Output generated is bitstream in BIN format. |\n\
-------------+----------------------------------------------------------------+\n"
/******************************************************************************
encryption_dump
******************************************************************************/
#define ENCRDUMPHELP "\
-------------+----------------------------------------------------------------+\n\
OPTION | *** Only for ZynqMP Architecture *** |\n\
| encryption_dump |\n\
-------------+----------------------------------------------------------------+\n\
DESCRIPTION | Generates Encryption log file, aes_log.txt |\n\
-------------+----------------------------------------------------------------+\n\
SYNOPSIS | -encryption_dump |\n\
-------------+----------------------------------------------------------------+\n\
USAGE | [bootgen -arch zynqmp -image test.bif -encryption_dump] |\n\
-------------+----------------------------------------------------------------+\n\
EXPLANATION | Sample BIF - test.bif |\n\
| all: |\n\
| { |\n\
| [keysrc_encryption] bbram_red_key |\n\
| [bootloader, encryption=aes, aeskeyfile=test.nky] fsbl.elf |\n\
| [encryption=aes,aeskeyfile=test2.nky] hello.elf |\n\
| } |\n\
|----------------------------------------------------------------|\n\
| aes_log.txt generarted has the details of AES Key/IV pairs used|\n\
| for encrypting each block of data. It also logs the partition |\n\
| and the aes key file used to encrypt it. |\n\
-------------+----------------------------------------------------------------+\n"
/******************************************************************************
nonbooting
******************************************************************************/
#define NONBOOTINGHELP "\
-------------+----------------------------------------------------------------+\n\
OPTION | nonbooting |\n\
-------------+----------------------------------------------------------------+\n\
DESCRIPTION | Used for generating an intermediate boot image. |\n\
-------------+----------------------------------------------------------------+\n\
SYNOPSIS | -nonbooting |\n\
-------------+----------------------------------------------------------------+\n\
USAGE | [bootgen -arch zynq -image test.bif -o test.bin -nonbooting] |\n\
-------------+----------------------------------------------------------------+\n\
EXPLANATION | Sample BIF - test.bif |\n\
| all: |\n\
| { |\n\
| [ppkfile]primary.pub |\n\
| [spkfile]secondary.pub |\n\
| [spksignature]secondary.pub.sha256.sig |\n\
| [bootimage,authentication=rsa, |\n\
| presign=fsbl_0.elf.0.sha256.sig]fsbl_e.bin |\n\
| } |\n\
|----------------------------------------------------------------|\n\
| An intermediate image test.bin is generated as output even in |\n\
| the absence of secret key, which is actually needed to generate|\n\
| an authenticated image. |\n\
| This intermediate image cannot be booted. |\n\
-------------+----------------------------------------------------------------+\n"
/******************************************************************************
verify
******************************************************************************/
#define VERIFYHELP "\
-------------+----------------------------------------------------------------+\n\
OPTION | verify |\n\
-------------+----------------------------------------------------------------+\n\
DESCRIPTION | Used for verifying authentication of a boot image. |\n\
-------------+----------------------------------------------------------------+\n\
SYNOPSIS | -verify |\n\
-------------+----------------------------------------------------------------+\n\
USAGE | [bootgen -arch zynqmp -verify boot.bin] |\n\
-------------+----------------------------------------------------------------+\n\
EXPLANATION | All the authentication certificates in a boot image will be |\n\
| verified againist the available partitions. |\n\
| The verification process is done as below - |\n\
| 1. Verify Header Authentication Certificate |\n\
| verify SPK Signature |\n\
| verify Header Signature |\n\
| 2. Verify Bootloader Authentication Certificate |\n\
| verify Boot Header Signature |\n\
| verify SPK Signature |\n\
| verify Bootloader Signature |\n\
| 3. Verifiy Partition Authentication Certificate |\n\
| verify SPK Signature |\n\
| verify Partition Signature |\n\
| This is repeated for all partitions in the given boot image.|\n\
-------------+----------------------------------------------------------------+\n"
/******************************************************************************
init
******************************************************************************/
#define H_BIF_INIT_H "\
-------------+----------------------------------------------------------------+\n\
ATTRIBUTE | init |\n\
-------------+----------------------------------------------------------------+\n\
DESCRIPTION | Register initialization block at the end of the bootloader, |\n\
| built by parsing the .int file specification. Maximum of 256 |\n\
| address-value init pairs are allowed. The int files have |\n\
| a specific format. |\n\
-------------+----------------------------------------------------------------+\n\
USAGE | [init] <filename> |\n\
-------------+----------------------------------------------------------------+\n\
EXPLANATION | Sample BIF - test.bif |\n\
| all: |\n\
| { |\n\
| [init] test.int |\n\
| } |\n\
|----------------------------------------------------------------|\n\
| Sample .int file - test.int |\n\
| .set. 0xF8000120 = 0x1F000200; |\n\
| .set. 0xF8000720 = 0x00000202; |\n\
| .set. 0xF800014C = 0x00000521; |\n\
-------------+----------------------------------------------------------------+\n"
/******************************************************************************
aeskeyfile
******************************************************************************/
#define H_BIF_AES_H "\
-------------+----------------------------------------------------------------+\n\
ATTRIBUTE | aeskeyfile |\n\
-------------+----------------------------------------------------------------+\n\
DESCRIPTION | The path to the AES keyfile. The keyfile contains AES key used |\n\
| to encrypt the partitions. The contents of the key file needs |\n\
| to be written to efuse or bbram. |\n\
| If the key file is not present in the path specified, a new key|\n\
| is generated by bootgen, which is used for encryption. |\n\
-------------+----------------------------------------------------------------+\n\
USAGE | [aeskeyfile] <key filename> |\n\
| [aeskeyfile = <keyfile name>] <partition> |\n\
-------------+----------------------------------------------------------------+\n\
EXPLANATION | For Zynq only: |\n\
| Sample BIF - test.bif |\n\
| all: |\n\
| { |\n\
| [keysrc_encryption] bbram_red_key |\n\
| [aeskeyfile] test.nky |\n\
| [bootloader, encryption=aes] fsbl.elf |\n\
| [encryption=aes] hello.elf |\n\
| } |\n\
| The partitions fsbl.elf & hello.elf are encrypted using |\n\
| test.nky key file. |\n\
|----------------------------------------------------------------|\n\
| Sample key (.nky) file - test.nky |\n\
| Device xc7z020clg484; |\n\
| Key 0 8177B12032A7DEEE35D0F71A7FC399027BF....D608C58; |\n\
| Key StartCBC 952FD2DF1DA543C46CDDE4F811506228; |\n\
| Key HMAC 123177B12032A7DEEE35D0F71A7FC3990BF....127BD89; |\n\
-------------+----------------------------------------------------------------+\n\
| For ZynqMP only: |\n\
| * Each partition being encrypted needs its own aeskeyfile. |\n\
| * Key0, IV0 and Key Opt should be the same accross all nky |\n\
| files that will be used. |\n\
| * For cases where multiple partitions are generated for an elf |\n\
| file, each partition can be encrypted using keys from a unique |\n\
| key file. [Refer Example 2] |\n\
|----------------------------------------------------------------|\n\
| Example 1: |\n\
| The partition fsbl.elf is encrypted with keys in test.nky, |\n\
| hello.elf using keys in test1.nky & app.elf using keys in |\n\
| test2.nky. |\n\
| Sample BIF - test_multiple.bif |\n\
| all: |\n\
| { |\n\
| [keysrc_encryption] bbram_red_key |\n\
| [bootloader,encryption=aes,aeskeyfile=test.nky] fsbl.elf |\n\
| [encryption=aes,aeskeyfile=test1.nky] hello.elf |\n\
| [encryption=aes,aeskeyfile=test2.nky] app.elf |\n\
| } |\n\
|----------------------------------------------------------------|\n\
| Example 2: |\n\
| Consider bootgen creates 3 partitions for hello.elf |\n\
| - hello.elf.0, hello.elf.1 & hello.elf.2 |\n\
| |\n\
| Sample BIF - test_multiple.bif |\n\
| all: |\n\
| { |\n\
| [keysrc_encryption] bbram_red_key |\n\
| [bootloader,encryption=aes,aeskeyfile=test.nky] fsbl.elf |\n\
| [encryption=aes,aeskeyfile=test1.nky] hello.elf |\n\
| } |\n\
| |\n\
| The partition fsbl.elf is encrypted with keys in test.nky. |\n\
| All hello.elf partitions are encrypted using keys in test1.nky.|\n\
| |\n\
| User can have unique key files for each hello partition by |\n\
| having key files named test1.1.nky & test1.2.nky in the same |\n\
| path as test1.nky. |\n\
| hello.elf.0 uses test1.nky |\n\
| hello.elf.1 uses test1.1.nky |\n\
| hello.elf.2 uses test1.2.nky |\n\
| If any of the key files (test1.1.nky or test1.2.nky) is not |\n\
| present, bootgen generated the key file. |\n\
-------------+----------------------------------------------------------------+"
/******************************************************************************
ppkfile, pskfile, spkfile, sskfile
******************************************************************************/
#define H_BIF_PPK_H "\
-------------+----------------------------------------------------------------+\n\
ATTRIBUTE | ppkfile, pskfile, spkfile, sskfile |\n\
-------------+----------------------------------------------------------------+\n\
DESCRIPTION | These keys are used to authenticate partitions in the bootimage|\n\
| Xilinx SoCs use primary & secondary keys for authentication. |\n\
| The primary keys authenticate the secondary keys and the |\n\
| secondary keys authenticate the partitions. |\n\
| PPK - Primary Public Key |\n\
| PSK - Primary Secret Key |\n\
| SPK - Secondary Public Key |\n\
| SSK - Secondary Secret Key |\n\
-------------+----------------------------------------------------------------+\n\
USAGE | [ppkfile] <key filename> |\n\
| [pskfile] <key filename> |\n\
| [spkfile] <key filename> |\n\
| [sskfile] <key filename> |\n\
|----------------------------------------------------------------|\n\
| For ZynqMP only : |\n\
| - PPK/PSK cannot be specific to partition. |\n\
| - Each partition can have its own SPK/SSK.(Refer sample BIF 2)|\n\
| The SPKs can be differentiated using the spk_id. |\n\
| - SPK/SSK outside the partition scope is mandatory for |\n\
| authentication. These keys will be used to authenticate |\n\
| headers and any other partition that does not have a |\n\
| specific SPK/SSK. |\n\
-------------+----------------------------------------------------------------+\n\
EXPLANATION | Sample BIF 1 - test.bif |\n\
| all: |\n\
| { |\n\
| [pskfile] primarykey.pem |\n\
| [sskfile] secondarykey.pem |\n\
| [bootloader, authentication=rsa] fsbl.elf |\n\
| [authentication=rsa] hello.elf |\n\
| } |\n\
|----------------------------------------------------------------|\n\
| Sample BIF 2 - test.bif |\n\
| all: |\n\
| { |\n\
| [pskfile] primary.pem |\n\
| [sskfile] secondary0.pem |\n\
| |\n\
| /* FSBL (Partition-0) */ |\n\
| [ |\n\
| bootloader, |\n\
| destination_cpu = a53-0, |\n\
| authentication = rsa, |\n\
| sskfile = secondary1.pem |\n\
| ]fsbla53.elf |\n\
| |\n\
| /* Partition-1 */ |\n\
| [ |\n\
| destination_cpu = a53-0, |\n\
| authentication = rsa |\n\
| ] hello.elf |\n\
| } |\n\
|----------------------------------------------------------------|\n\
| Sample key files: |\n\
| 1. OpenSSL Key Format: (.pem/.pub) |\n\
| -----BEGIN RSA PRIVATE KEY----- |\n\
| MIIEpAIBAAKCAQEAxrmlJyPcZVXltASHrtm/YnOMxskf0k2RZrIajqy |\n\
| kyBMalXaqmGb1kqGCgGZVvQt3FSRO3yXa.... |\n\
| -----END RSA PRIVATE KEY----- |\n\
| |\n\
| -----BEGIN PUBLIC KEY----- |\n\
| MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxrmlJyPcZVm |\n\
| YnOMxskf0k2RZrIajq.... |\n\
| -----END RSA PRIVATE KEY----- |\n\
| |\n\
| 2. Xilinx RSA Format: |\n\
| N = c6b9a522354238902352302acfb3.......a21678123412 |\n\
| E = 10001 |\n\
| D = 37c80c8c6b9a522354238f4a6cdf.......c6b9a5223542 |\n\
-------------+----------------------------------------------------------------+\n"
/******************************************************************************
udf_bh
******************************************************************************/
#define H_BIF_UDFBH_H "\
-------------+----------------------------------------------------------------+\n\
ATTRIBUTE | udf_bh |\n\
-------------+----------------------------------------------------------------+\n\
DESCRIPTION | Imports a file of data to be copied to the User Defined Field |\n\
| of the Boot Header. The input user defined data is provided |\n\
| through a text file in the form of a hex string. |\n\
| Total no. of bytes in UDF in Xilinx SoCs: |\n\
| Zynq : 76 bytes |\n\
| ZynqMP : 40 bytes |\n\
-------------+----------------------------------------------------------------+\n\
USAGE | [udf_bh] <filename> |\n\
-------------+----------------------------------------------------------------+\n\
EXPLANATION | Sample BIF - test.bif |\n\
| all: |\n\
| { |\n\
| [udf_bh] test.txt |\n\
| [bootloader] fsbl.elf |\n\
| hello.elf |\n\
| } |\n\
|----------------------------------------------------------------|\n\
| Sample input file for udf_bh - test.txt |\n\
| 123456789abcdef85072696e636530300301440408706d616c6c6164000508 |\n\
| 266431530102030405060708090a0b0c0d0e0f101112131415161718191a1b |\n\
| 1c1d1 |\n\
-------------+----------------------------------------------------------------+\n"
/******************************************************************************
spksignature
******************************************************************************/
#define H_BIF_SPKSIGN_H "\
-------------+----------------------------------------------------------------+\n\
ATTRIBUTE | spksignature |\n\
-------------+----------------------------------------------------------------+\n\
DESCRIPTION | Imports SPK signature into authentication certificate. This can|\n\
| be used incase the user does't want to share the secret key PSK|\n\
| The user can create a signature and provide it to Bootgen. |\n\
-------------+----------------------------------------------------------------+\n\
USAGE | [spksignature] <signature-file> |\n\
-------------+----------------------------------------------------------------+\n\
EXPLANATION | Sample BIF - test.bif |\n\
| all: |\n\
| { |\n\
| [ppkfile] ppk.txt |\n\
| [spkfile] spk.txt |\n\
| [spksignature] spk.txt.sha256.sig |\n\
| [bootloader, authentication=rsa] fsbl.elf |\n\
| } |\n\
-------------+----------------------------------------------------------------+\n"
/******************************************************************************
headersignature
******************************************************************************/
#define H_BIF_HDRSIGN_H "\
-------------+----------------------------------------------------------------+\n\
ATTRIBUTE | headersignature |\n\
-------------+----------------------------------------------------------------+\n\
DESCRIPTION | Imports Header signature into authentication certificate. This |\n\
| can be used incase the user does't want to share the secret key|\n\
| The user can create a signature and provide it to Bootgen. |\n\
-------------+----------------------------------------------------------------+\n\
USAGE | [headersignature] <signature-file> |\n\
-------------+----------------------------------------------------------------+\n\
EXPLANATION | Sample BIF - test.bif |\n\
| all: |\n\
| { |\n\
| [ppkfile] ppk.txt |\n\
| [spkfile] spk.txt |\n\
| [headersignature] headers.sha256.sig |\n\
| [spksignature] spk.txt.sha256.sig |\n\
| [bootloader, authentication=rsa] fsbl.elf |\n\
| } |\n\
-------------+----------------------------------------------------------------+\n"
/******************************************************************************
bootimage
******************************************************************************/
#define H_BIF_BI_H "\
-------------+----------------------------------------------------------------+\n\
ATTRIBUTE | bootimage |\n\
-------------+----------------------------------------------------------------+\n\
DESCRIPTION | This specifies that the following file specification is a |\n\
| bootimage that was created by Bootgen, being reused as input. |\n\
-------------+----------------------------------------------------------------+\n\
USAGE | [bootimage] <image created by bootgen> |\n\
-------------+----------------------------------------------------------------+\n\
EXPLANATION | Sample BIF - test.bif |\n\
| all: |\n\
| { |\n\
| [bootimage] fsbl.bin |\n\
| [bootimage] system.bin |\n\
| } |\n\
|----------------------------------------------------------------|\n\
| In the above example, the fsbl.bin & system.bin are images |\n\
| generated using bootgen. |\n\
| |\n\
| Example fsbl.bin generation |\n\
| image: |\n\
| { |\n\
| [keysrc_encryption] bbram_red_key |\n\
| [pskfile] primary.pem |\n\
| [sskfile] secondary.pem |\n\
| [bootloader, authentication=rsa, encryption=aes, |\n\
| aeskeyfile=aes.nky] fsbl.elf |\n\
| } |\n\
| Command: bootgen -image fsbl.bif -o fsbl.bin -encrypt efuse |\n\
| |\n\
| Example system.bin generation |\n\
| image: |\n\
| { |\n\
| [pskfile] primary.pem |\n\
| [sskfile] secondary.pem |\n\
| [bootloader, authentication=rsa] system.bit |\n\
| } |\n\
| Command: bootgen -image system.bif -o system.bin |\n\
-------------+----------------------------------------------------------------+\n"
/******************************************************************************
bootloader
******************************************************************************/
#define H_BIF_BL_H "\
-------------+----------------------------------------------------------------+\n\
ATTRIBUTE | bootloader |\n\
-------------+----------------------------------------------------------------+\n\
DESCRIPTION | This specifies the partition is a bootloader (FSBL). This |\n\
| attribute is specified with along with other partition bif |\n\
| attributes. |\n\
-------------+----------------------------------------------------------------+\n\
USAGE | [bootloader] <partition> |\n\
-------------+----------------------------------------------------------------+\n\
EXPLANATION | Sample BIF - test.bif |\n\
| all: |\n\
| { |\n\
| [bootloader] fsbl.elf |\n\
| hello.elf |\n\
| } |\n\
-------------+----------------------------------------------------------------+\n"
/******************************************************************************
encryption
******************************************************************************/
#define H_BIF_ENCR_H "\
-------------+----------------------------------------------------------------+\n\
ATTRIBUTE | encryption |\n\
-------------+----------------------------------------------------------------+\n\
DESCRIPTION | This specifies the partition needs to be encrypted. |\n\
| Encryption Algorithms |\n\
| Zynq : AES-CBC |\n\
| ZynqMP : AES-GCM |\n\
-------------+----------------------------------------------------------------+\n\
USAGE | [encryption = <options>] <partition> |\n\
-------------+----------------------------------------------------------------+\n\
OPTIONS | *none : Partition not encrypted |\n\
| aes : Partition encrypted using AES algorithm |\n\
-------------+----------------------------------------------------------------+\n\
EXPLANATION | Sample BIF - test.bif |\n\
| all: |\n\
| { |\n\
| [aeskeyfile] test.nky |\n\
| [bootloader, encryption=aes] fsbl.elf |\n\
| [encryption=aes] hello.elf |\n\
| } |\n\
-------------+----------------------------------------------------------------+\n"
/******************************************************************************
pid
******************************************************************************/
#define H_BIF_PID_H "\
-------------+----------------------------------------------------------------+\n\
ATTRIBUTE | *** Only for ZynqMP Architecture *** |\n\
| pid |\n\
-------------+----------------------------------------------------------------+\n\
DESCRIPTION | This is used to specify an id to which the partition is |\n\
| associated with. |\n\
-------------+----------------------------------------------------------------+\n\
USAGE | [pid = <id>] <partition> |\n\
| <id> is an integer value, representing the partition number. |\n\
-------------+----------------------------------------------------------------+\n\
EXPLANATION | Sample BIF - test.bif |\n\
| all: |\n\
| { |\n\
| [keysrc_encryption] bbram_red_key |\n\
| [encryption=aes,aeskeyfile=test.nky,pid=1] hello.elf |\n\
| } |\n\
|----------------------------------------------------------------|\n\
| While creating an image bootgen by default assigns an id to |\n\
| every partition, which is in line with the order of partitions |\n\
| given in the bif. |\n\
| To assign a different id to any partition, pid can be used. |\n\
| During encryption, the IV is incremented by this value to avoid|\n\
| security vulneribilities. |\n\
-------------+----------------------------------------------------------------+\n"
/******************************************************************************
authentication
******************************************************************************/