Script to generate dts.fixup file for Zephyr RTOS #13
Conversation
While Zephyr RTOS defines their DTS-based code generation interface for drivers, they currently require a dts.fixup file to redefine the generated macros to the symbols consumed by the drivers themselves. This script generates that dts.fixup file based on the board's DTS. The current roadmap for Zephyr puts the new DTS code generation as a milestone for Zephyr 1.14, so until that support is released, the Freedom SDK will need to generate these fixup files for creating a port of Zephyr to a new board. Signed-off-by: Nathaniel Graff <nathaniel.graff@sifive.com>
freedom-zephyrdtsfixup-generator.c++
Outdated
| static void write_config_file(const fdt &dtb, fstream &os) | ||
| { | ||
| os << "/* Copyright (c) 2018 SiFive Inc." << endl; | ||
| os << " * SPDX-License-Identifier: Apache-2.0 */" << endl; |
There was a problem hiding this comment.
The Linux guys told be that SPDX headers must be structured as //-style comments, but I don't know if that applies to Zephyr as well. I also like adding a "autogenerated by X" header to anything that comes out of a tool and is then checked in, just so people know it's not a human source file.
There was a problem hiding this comment.
Zephyr has the SPDX headers within the /.../ style comments all over the source tree, so this should be fine for them.
I'll add the autogenerated header.
| auto emit_fixup = [&](string out_prefix, string in_prefix, int dev_num, target_addr base, string suffix) { | ||
| os << "#define "; | ||
| os << out_prefix << "_" << dev_num << "_" << suffix << "\t"; | ||
| os << in_prefix << "_" << std::hex << base << std::dec << "_" << suffix << endl; |
There was a problem hiding this comment.
This is an aside, but is there any way to emit an integer as hex to a stream and then reset it to it's original state? I always use this idiom, but it assumes the stream was in std::dec mode. I feel like @brucehoult might know...
There was a problem hiding this comment.
No standard way using manipulators inline in a series of << no.
There are a bunch of suggestions here, but still none that are very pretty: https://stackoverflow.com/questions/2273330/restore-the-state-of-stdcout-after-manipulating-it
|
iostreams are horrible.
Have you looked at {fmt}?
https://github.com/fmtlib/fmt/blob/master/README.rst
It’s worth reading the README, especially the section comparing {fmt} to
iostreams.
I would prefer to use C++14 more like LLVM does. LLVM doesn’t use STL
internally. It has its own libs. It’s nice to have templates and lambdas,
etc, (Core Language Features) but to have library interfaces that are a bit
more modern like Rust or Go. It’s possible. iostreams are very C++98.
|
|
I do like the look of {fmt}, on first glance it looks really similar to Python's formatting syntax. |
Signed-off-by: Nathaniel Graff <nathaniel.graff@sifive.com>
While Zephyr RTOS defines their DTS-based code generation interface for
drivers, they currently require a dts.fixup file to redefine the
generated macros to the symbols consumed by the drivers themselves. This
script generates that dts.fixup file based on the board's DTS.
The current roadmap for Zephyr puts the new DTS code generation as a
milestone for Zephyr 1.14, so until that support is released, the
Freedom SDK will need to generate these fixup files for creating a port
of Zephyr to a new board.