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

Use OpenOCD for Launchxl build and sanitize #1102

Merged
merged 9 commits into from Jul 10, 2018

Conversation

Projects
None yet
4 participants
@alevy
Copy link
Member

alevy commented Jul 9, 2018

Pull Request Overview

This pull request makes a number of changes to the launchxl board's build system:

  • Replaces TI's proprietary tool (that's a nightmare to setup) with OpenOCD (which is slightly less of a nightmare) to flash the kernel over USB by default.

  • Moves the process ROM offset to that expected by tockloader by default. There is still plenty of room for the kernel, and doing this makes programming apps using tockloader much simpler.

  • Removes the CCFG registers from the kernel binary, and instead uses a separate binary for encoding and flashing the CCFG registers as a separate step. This one's important. Overwriting the CCFG registers is both dangerous (it can brick the board) and very very instance specific (i.e. this is where you'd put the MAC address). Having it as a separate step allows the user to just do it once when they buy the board from TI and spend most of their time not touching it. It also gives a more controlled environment when changing the registers later (e.g. for deployment, or to fiddle with power settings).

  • Adds an optional flash-jlink and flash-ccfg-jlink make targets for programming with JLinkExe and an external debugger as well.

I also updated the launchxl README to reflect flashing with OpenOCD and JLinkExe and how to specifically set up the jumpers for each.

One nit to note is that OpenOCD doesn't properly support hardware reset for the on-board debug chip yet, so we're using soft-reset instead---this only resets the Cortex-M core, and could leave the rest of the hardware in an unexpected state. Always best to manually tap the reset button next to the USB port after flashing the kernel.

Testing Strategy

Fairly exhaustive testing on both the CC2652 launchxl and CC1312 launchxl, including bricking two of my four boards when I was blindly using the previous kernel binary.

TODO or Help Wanted

(Specifically for @ppannuto) I changed Makefile.common to be more permissive about which binaries it's willing to convert to other formats. I think the changes are pretty straight forward and safe, but input would be useful none-the-less.

This PR also removes the Makefile.common targets for converting to .hex files since llvm-objcopy only supports converting to binary. It however doesn't cleanup references to those targets from various custom scripts and Makefile targets in a couple boards.

To come in future a PRs:

  • Flashing using JLinkExe using an external debugger (JLinkExe doesn't support the on-board debugger, and probably never will) Done

  • Documenting the CCFG registers set in ccfg.rs. This is not gonna be fun, and doing something sane seems more useful short term then waiting to build up the motivation to try and understand that section of the data-sheet properly.

Documentation Updated

  • Updated the relevant files in /docs, or no updates are required.

Formatting

  • Ran make formatall.
@alevy

This comment has been minimized.

Copy link
Member

alevy commented Jul 9, 2018

@@ -164,3 +165,6 @@ clean::

.PHONY: debug
debug: target/$(TARGET)/debug/$(PLATFORM).elf

.PHONY: release
debug: target/$(TARGET)/release/$(PLATFORM).elf

This comment has been minimized.

@bradjc

bradjc Jul 9, 2018

Contributor

Presumably this should be release:

Also, why do we have these targets in two places (also line 108)? That seems odd.

This comment has been minimized.

@alevy

alevy Jul 9, 2018

Member

You're right. fixing.

$(Q)$(OBJCOPY) -O=binary $^ $@

target/$(TARGET)/debug/$(PLATFORM).bin: target/$(TARGET)/debug/$(PLATFORM).elf
target/$(TARGET)/debug/%.bin: target/$(TARGET)/debug/%.elf

This comment has been minimized.

@ppannuto

ppannuto Jul 9, 2018

Member

If we're going to go for pattern rules, why not just go all the way and replace both of these with
%.bin: %.elf

This comment has been minimized.

@alevy

alevy Jul 9, 2018

Member

Right, you're the makefile expert :) I'm entirely sure what might possibly break if I change them that drastically, but if you think it's ok, I'm game.

target/$(TARGET)/debug/$(PLATFORM).lst: target/$(TARGET)/debug/$(PLATFORM).elf
$(Q)$(OBJDUMP) $(OBJDUMP_FLAGS) $< > target/$(TARGET)/debug/$(PLATFORM).lst
target/$(TARGET)/debug/%.lst: target/$(TARGET)/debug/%.elf
$(Q)$(OBJDUMP) $(OBJDUMP_FLAGS) $< > $@

This comment has been minimized.

@ppannuto

ppannuto Jul 9, 2018

Member

Same here for .lst -> .elf


.PHONY: target/$(TARGET)/release/$(PLATFORM)
target/$(TARGET)/release/$(PLATFORM):
$(Q)RUSTFLAGS="$(RUSTFLAGS_FOR_CARGO_LINKING)" $(CARGO) build --target=$(TARGET) $(VERBOSE) --release
$(Q)$(SIZE) $@

target/$(TARGET)/debug/$(PLATFORM).elf: target/$(TARGET)/debug/$(PLATFORM)
$(Q)cp target/$(TARGET)/debug/$(PLATFORM) target/$(TARGET)/debug/$(PLATFORM).elf
$(Q)cp $< $@

This comment has been minimized.

@ppannuto

ppannuto Jul 9, 2018

Member

And for %.elf -> %

@bradjc

This comment has been minimized.

Copy link
Contributor

bradjc commented Jul 9, 2018

Is there value to having the ccfg.rs file in the chip crate still?

@alevy

This comment has been minimized.

Copy link
Member

alevy commented Jul 9, 2018

Is there value to having the ccfg.rs file in the chip crate still?

I think it will be valuable to have a ccfg.rs file that actually has register definitions (as opposed to just an array of constants), but not an instantiation.

@alevy alevy force-pushed the alevy:remove_ccfg branch 2 times, most recently from 0d18abd to b2da0f0 Jul 9, 2018

@refugeesus

This comment has been minimized.

Copy link
Contributor

refugeesus commented Jul 10, 2018

I think implementing a minimal ccfg with its register definitions is probably smart since the ccfg file is supposed to make it easier for users to make broad changes to radio settings, clock, and power controls. I am not 100% certain what a setting in ccfg pertaining to vd_ctl does when I try to change something about vd_ctl independently (perhaps blocking registers?).

@bradjc

This comment has been minimized.

Copy link
Contributor

bradjc commented Jul 10, 2018

Should this PR then delete the ccfg.rs file that currently exists?

@refugeesus

This comment has been minimized.

Copy link
Contributor

refugeesus commented Jul 10, 2018

No, you must have some ccfg settings or the board will brick. The array of constants forces it to work but the settings should be implemented later. Maybe not in this PR necessarily though.

@bradjc

This comment has been minimized.

Copy link
Contributor

bradjc commented Jul 10, 2018

Why is 23ac2dd attached to this PR?

And I guess what I am asking is how is https://github.com/tock/tock/blob/master/chips/cc26xx/src/ccfg.rs being used after this change? It seems like the CCFG struct is defined with the board now.

@alevy

This comment has been minimized.

Copy link
Member

alevy commented Jul 10, 2018

@bradjc it's not exactly being used by the board. The board has an additional binary target (see cargo.toml) that constains just the ccfg struct and is programmed separately only when you first use the board (make flash-ccfg)

@alevy

This comment has been minimized.

Copy link
Member

alevy commented Jul 10, 2018

After an in depth conversation with @bradjc we discovered that good condition was because I hadn't deleted ccfg.rs from the chip crate, even though I removed it from lib.rs and said I removed it.

Will fix

@refugeesus

This comment has been minimized.

Copy link
Contributor

refugeesus commented Jul 10, 2018

Regarding the firmware update to xds110 on the on-board debugger: One thing I noticed flashing different boards was that due to a reset bug in xds110 as when a board that has been flashed with a tock kernel rather than TI distribution, it will not be able to reset itself after being switched into DFU mode per TI's firmware update instructions [here]
(http://processors.wiki.ti.com/index.php/XDS110#Updating_the_XDS110_Firmware). (aon does not hard reset the board properly I think which is unrelated to this PR) However you can still update the firmware in this situation by building one of the base RTOS distributions from TI in CCS and flash the board which will prompt CCS to run the firmware update itself which works.

Edit: clarity and wrote openocd instead of xds110 by accident

alevy added some commits Jul 6, 2018

Use OpenOCD to flash Launchxl board
The existing makefile was using UniFlash, which is some TI-specific
tool. I couldn't quite get it to work, and OpenOCD (in git-tip) now has
support for the Launchxl's on-board debug chip (the xds110).

This commit adds an openocd script to flash the kernel hex, and changes
the Makefile to use it.
Move Launchxl process offset to default
The Launchxl was using a non-standard offset for program flash
(0x47000). There's nothing wrong with that, but it requires an extra
argument to tockloader, and isn't necessary (the kernel is nowhere near
big enough). This changes it to 0x30000, as expected by tockloader by
default.

@alevy alevy force-pushed the alevy:remove_ccfg branch from b2da0f0 to 949bba7 Jul 10, 2018

@alevy

This comment has been minimized.

Copy link
Member

alevy commented Jul 10, 2018

@bradjc fixed ccfg.rs issue

@bradjc
Copy link
Contributor

bradjc left a comment

one more thing

#![no_std]
#![no_main]
#![feature(used, panic_implementation)]
#![feature(used, panic_implementation)]

This comment has been minimized.

@bradjc

bradjc Jul 10, 2018

Contributor

Delete

This comment has been minimized.

@alevy

alevy Jul 10, 2018

Member

done

alevy added some commits Jul 6, 2018

Make launchxl ccfg a separate binary
We don't want to flash CCFG data for the launchxl as part of the kernel.
It's dangerous, it makes the flah binary huge, and it makes it harder to
make board-specific changes.

Instead, pulls the ccfg into a separately compiled binary for the
launchxl board with it's own Makefile target to flash it to the ccfg
section. Other boards should do other board-specific things for CCFG
(including potentially leaving it untouched).

@alevy alevy force-pushed the alevy:remove_ccfg branch from 949bba7 to 3f2b9bc Jul 10, 2018

@bradjc

bradjc approved these changes Jul 10, 2018

Copy link
Contributor

bradjc left a comment

I'd rather the makefile changes were their own pr, but eh.

@alevy alevy merged commit 8f30164 into tock:master Jul 10, 2018

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
deploy/netlify Deploy preview ready!
Details

@alevy alevy deleted the alevy:remove_ccfg branch Jul 10, 2018

@ppannuto

This comment has been minimized.

Copy link
Member

ppannuto commented Jul 11, 2018

Re makefile: Yeah, sorry, once I started cleaning that up I kept going, and didn't want to create a somewhat needless conflict (at first), which is a hole that dug deeper as I did more.

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