-
Notifications
You must be signed in to change notification settings - Fork 89
qdl: add support for dry run execution #98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
e3da70f
to
2929f09
Compare
9ecd150
to
d921829
Compare
@andersson Thank you for your review. I have addressed all your recently posted comments. Please let me know if there's anything else I need to do. |
@konradybcio @lumag could you please take a look |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Commit message for the first patch doesn't answer on the main question: why are you decoupling it. Please update it to describe the reason for the changes.
- Ideally all 'Why' questions should get some comment in the file.
struct qdl_device_sim | ||
{ | ||
struct qdl_device base; | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think qdl_device_foo should be internal to foo.h
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tbh I don't want to introduce a new header file just for one struct definition. If there are more things to move to a separate header in the future, that will definitely make sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then just sim.c, if that's the only place where it is used.
Decouple the flashing logic from the underlying type of communication. This is needed for introducing simulation mode, where no real flashing is performed, but firehose packets are used for other tasks, like VIP table generation. Signed-off-by: Igor Opaniuk <[email protected]>
This mode assists in validating the `rawprogram_.xml` and `patch_.xml` files, as well as the Firehose commands that are expected to be sent to the Firehose programmer. Dry run implementation is also expected to be extended for the Digests Table generation required for Firehose Validated Image Programming (VIP). Example of usage: $ qdl --dry-run --serial=0AA94EFD --debug prog_firehose_ddr.elf rawprogram*.xml patch*.xml qdl version v2.1-24-g30ac3a8-dirty This is a dry-run execution of QDL. No actual flashing has been performed waiting for programmer... FIREHOSE WRITE: <?xml version="1.0"?> <data><configure MemoryName="ufs" MaxPayloadSizeToTargetInBytes="1048576" verbose="0" ZLPAwareHost="1" SkipStorageInit="0"/></data> FIREHOSE WRITE: <?xml version="1.0"?> <data><configure MemoryName="ufs" MaxPayloadSizeToTargetInBytes="0" verbose="0" ZLPAwareHost="1" SkipStorageInit="0"/></data> accepted max payload size: 0 FIREHOSE WRITE: <?xml version="1.0"?> <data><program SECTOR_SIZE_IN_BYTES="4096" num_partition_sectors="131072" physical_partition_number="0" start_sector="6" filename="efi.bin"/></data> Signed-off-by: Igor Opaniuk <[email protected]>
d921829
to
f07a2d3
Compare
@lumag all comments addressed (to some extent), please let me know if you have additional comments/objections. Thanks! |
This mode assists in validating the
rawprogram_.xml
andpatch_.xml
files, as well as the Firehose commands that are expected to be sent to the Firehose programmer.Dry run implementation is also expected to be extended for the Digests Table generation required for Firehose Validated Image Programming (VIP).
Example of usage: