Skip to content

Add support for nrf52_dk bootloader #8097

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

Merged
merged 9 commits into from
Dec 4, 2018
Merged

Add support for nrf52_dk bootloader #8097

merged 9 commits into from
Dec 4, 2018

Conversation

JammuKekkonen
Copy link
Contributor

@JammuKekkonen JammuKekkonen commented Sep 12, 2018

Bootloader for nrf52_dk is a intel hex file, which contains write instructions to the start of rom and also into registry which is outside rom region. This causes the current logic of forming the build regions to fail as it only supports bootloader that is in one segments which is at the start of rom.

This pr fixes bootloader build region generation in case where application size is restricted (space reserved for something else after application) and also adds support for nrf52_dk bootloader, which contains write instructions to registry which is outside rom region.

Also fixed printing of error case.

Pull request type

[x] Fix
[ ] Refactor
[ ] Target update
[ ] Functionality change
[ ] Breaking change

…s with multiple segments, as required by NRF52 bootloader.
@JammuKekkonen
Copy link
Contributor Author

@yogpan01
Copy link
Contributor

Approved,
@ARMmbed/mbed-os-maintainers please review.

@cmonr
Copy link
Contributor

cmonr commented Sep 12, 2018

/morph build

if len(part.segments()) == 1:
part_size = (part.maxaddr() - part.minaddr()) + 1
else:
# make same assumption as in region builder; first segments must fit.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand what this comment is about. Could you explain it?

return newstart

def _generate_bootloader_build(self, rom_start, rom_size):
start = rom_start
rom_end = rom_start + rom_size
max_app_addr = -1
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please don't use -1 as a marker. Pythonic optional types are generally None or an instance of the type. Could you replace this -1 with None?

# assume first segment is at start
# second at the end or outside ROM
# rest outside regular ROM
if part.segments()[0][0] != 0x0:
Copy link
Contributor

@theotherjimmy theotherjimmy Sep 12, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not always true; ROM does not always start at 0x0. Please compare with rom_start.

part_size = part.segments()[0][1] - part.segments()[0][0]
part_size = Config._align_ceiling(rom_start + part_size, self.sectors) - rom_start
if part.segments()[1][0] < rom_end and self.target.restrict_size is None:
if self.target.app_offset:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

target.app_offset is not the only way that an application can be pushed further back: target.header_format and target.header_offset can also push an application further back. Either this check should check for all of them, or max_app_addr should be used unconditionally.

@@ -722,9 +738,17 @@ def _generate_bootloader_build(self, rom_start, rom_size):
start, region = self._make_header_region(
start, self.target.header_format)
yield region._replace(filename=self.target.header_format)

if max_app_addr != -1 and self.target.restrict_size is None and not self.target.app_offset:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why does target.app_offset inhibit the use of target.restrict_size here?

@cmonr
Copy link
Contributor

cmonr commented Sep 12, 2018

Stopped build since changes have been requested.

@cmonr
Copy link
Contributor

cmonr commented Sep 13, 2018

@theotherjimmy Mind doing a re-review?

part_size = (part.maxaddr() - part.minaddr()) + 1
else:
# make same assumption as in region builder; first segments must fit.
part_size = part.segments()[0][1] - part.segments()[0][0]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you need the +1 here?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How is this branch different from the other branch when part.segments() == 1? Could we just use this implementation unconditionally?

# rest outside regular ROM
if part.segments()[0][0] != rom_start:
raise ConfigException("bootloader segments not in order")
part_size = part.segments()[0][1] - part.segments()[0][0]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Size is off by 1 here as well.

@JammuKekkonen
Copy link
Contributor Author

PR updated according to feedback.

Tested with blinky.
K64F using existing bootloader
NRF52_DK with two different bootloaders; one that is located right after softdevice and one that is located at the end of flash (softdevice in beginning).

In both of the NRF52_DK tests, app header is located before app. @LiyouZhou.

@bulislaw
Copy link
Member

All the PRs need to be engineering ready (marked as "needs: CI") by the end of the day (Austin time). Otherwise it won't make 5.11 and will need to come in the next release (5.12 for features, 5.11.1 for fixes and new platforms).

@0xc0170
Copy link
Contributor

0xc0170 commented Nov 26, 2018

Moved to 5.11.1.

Hold a second still @0xc0170 , @simosillankorva will still check the configs.

This still needs work as I understood.

@cmonr
Copy link
Contributor

cmonr commented Nov 26, 2018

@0xc0170 That sounds correct. Conversation has been taken offline.

@cmonr
Copy link
Contributor

cmonr commented Nov 29, 2018

My bad. Email conversation is still ongoing.

@JanneKiiskila
Copy link
Contributor

Internal ref: MBOTRIAGE-1871

@0xc0170
Copy link
Contributor

0xc0170 commented Dec 4, 2018

Based on the internal conversation, it was decide that this patch will go in as it is and another patch for tools will come separately

@theotherjimmy @naveenkaje Please confirm

@naveenkaje
Copy link
Contributor

@0xc0170 Yes, that is correct. We plan to do a follow on patch to enable placing an application at an offset based on configuration parameters.

@cmonr
Copy link
Contributor

cmonr commented Dec 4, 2018

CI started

@mbed-ci
Copy link

mbed-ci commented Dec 4, 2018

Test run: SUCCESS

Summary: 4 of 4 test jobs passed
Build number : 12
Build artifacts
Build logs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.