- Shift in _csr_rd_buf should only been done when buf is set.
- When CSR size is not an exact multiple of the CSR data-width, the gap is in
the low addresses, not the high ones. So offset is introduced to take this into
account.
Dynamically adjusting the phase of a feedback will cause it to unlock.
The phase adjust ports are shared by all the outputs, so there is no
technical way to prevent this. Allow the user to indicate that they
will not adjust a clock when requesting an output by setting
uses_dpa=False, and only consider those that the user has promised not
to use.
Reimplement the configuration loop to allow all 4 outputs to be used by
the user, if one of them is suitable for use as VCO feedback.
The new strategy is to first iterate over requested outputs to see if
any of them can be used as a feedback source. If one can, it is
selected, and if no output is suitable, it attempts to instantiate one.
Once the feedback path is selected, the VCO frequency is known and it
attempts to calculate the remaining outputs' settings.
In addition, this implementation now respects datasheet limits in two
new ways:
- It respects the post-input-divider minimum frequency of 10MHz
- It respects the max output frequency of 400MHz for instantiated
feedback outputs
I am slightly unhappy with the seemingly-repetitive for loops. However
each one has slightly different sematics and I don't see a way to
combine them that doesn't hinder readability.
**Problems**
On macOS USB CDC ACM, which appears as `/dev/tty.usbmodem*`,
somehow `lxterm` keeps failing to send a payload.
**Solution**
Increase delay.
It's very unknown why to me, however, probably macOS USB CDC ACM
driver implementation issue.
**Testing**
Tested on MacBook Air (2020, M1) for OrangeCrab (rev.0.2) target
with Linux on LiteX SoC bitstream build from current commit and
load prebuild Linux On LiteX image.
Some targets have multiple alt settings for DFU for different zone
of the flash. Allowing to specify which one to flash and not
rebooting immediately allows to flash several of them at once.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
On designs which use Nexus parts without any external memory, it can be
difficult to fit an embedded ROM program larger than a few KiB. Radiant
cannot infer LRAM, and refuses to infer EBRAM under many circumstances
too, so large memories tend to just consume a huge number of LUTs.
This patch makes it possible to explicitly wire up an LRAM as a ROM,
populate its initial values with a program, and execute directly from
it. That lets us embed programs up to 64KiB.
In some SoCs where UART's PHY is managed externally (ex through a Bridge) we don't
necessarily want the UART TX to wait for the PHY to be ready (and then stall the
CPU) but just want to let the CPU print the UART and will just connect when useful
and handle backpressure when connected.
This is now possible by calling add_auto_tx_flush method, ex in the SoC:
self.uart.add_auto_tx_flush(sys_clk_freq)
Fix gcc warnings: use 'unsigned long' to represent memory addresses,
and remove 'static' from the definition of 'cdelay()', as it is called
from multiple C files.
FemtoRV is a minimalist RISC-V CPU with design process documented and
available at https://github.com/BrunoLevy/learn-fpga.
This CPU is a very nice way to discover/learn RISC-V and this LiteX support
can be useful to learn how to integrate a custom CPU with LiteX.
With this support, FemtoRV is now directly usable with LiteX Sim:
$litex_sim --cpu-type=femtorv
This should also enable its use on all boards (> 50) available in LiteX-Boards
repository (but hasn't been tested yet), ex:
$python3 -m litex_boards.targets.digilent_arty --cpu-type=femtorv --build
As discussed in #909, in some specific cases, it can be interesting to be able
to keep the CPU in reset while the rest of the SoC is still operating (ex the
peripherals/bridges).
With theses changes, the old behaviour is preserved to do a full SoC Reset (at
the exception that writing a 1 is now mandatory) and a separate field specific
to the CPU reset is added.
The SoC Reset is a pulse (otherwise the system would be stuck in Reset) while
the CPU Reset is based on the register value (so can be pulse or hold).
Before this patch, the loop would finish with lowest_div either set to the first failing value
or 0 even if it succeeded with 0. Fix it so that if all tests pass, it’ll end up being -1 before
the incrementation.
This patch also skips retesting the original value. If the retest failed, lowest_div would be incremented past the original value and could potentially wrap around.
* resolve issue #862 add description to soc.svd
The issue is that with no description provided it simply would
not put out a description tag, which breaks compatibility with
other programs.
Insert a somewhat useful default description including a timestamp
and the words "LiteX SoC".
* I2S fix: sample SYNC on the correct edge
The original Tx path implementation samples SYNC on the falling
edge, out of convenience with the fact that teh data must also
change on the falling edge.
This works OK, until you have a CODEC which has a ~40ns max
delay spec on the SYNC, and also has a slightly asymmetric
SYNC edge (the SYNC signal is also the WCLK or LRCLK depending on
which docs you read). The SYNC by spec is supposed to change
on the falling edge, and this extra delay is enough to cause
the SYNC to introduce occassional bit or frame shifts into
the audio.
This fix samples the SYNC on the rising edge, but still
changes the data on the falling edge, thus allowing for
implementations where SYNC has quite loose timings relative
to everything else (as is the case on the TLV320AIC3200)
I am working on testing out the patches from:
https://github.com/litex-hub/linux/pull/8
These linux patches take advantage of the sdcard interrupt to track when
transfers finish. However, it seems the interrupt is not being
connected to the CPU.
This patch does that by allowing us to directly register and
EventManager module with the irq handler.
With recent BIOS changes the default rom size on the mor1kx built just
passes over the 64k boundary and the build fails. Since the 128K
default is a soft limit and the ROM gets resized to the actual ROM
requirements this should be relatively safe.
Note, that if a RW rom is configured the full 128kb will be allocated.
Fixes: #893
When passed as str, the timing dict will be extracted from litex.soc.cores.video.video_timings.
When passed as tuple, custom dict will be directly passed to VTG.
The linker does not actually recognise -nodefaultlibs, that is a compiler
option.
Prior to binutils 2.36, ld treated -nodefaultlibs as a string of short
options and ignored them as unrecognised. Starting from binutils 2.36, it
reports an error instead:
riscv64-unknown-elf-ld: Error: unable to disambiguate: -nodefaultlibs (did you mean --nodefaultlibs ?)
See also: https://sourceware.org/bugzilla/show_bug.cgi?id=27050Fixes#825.
Adding wraps around capability will have to be discussed, if implemented this has to
be done very carefully since there are no relation between the total delay that can
be compensated through the I/O-DELAYs and the SDRAM clock period.
As implemented, it also produced confusing values in the logs:
m0:0 m1:0
Read leveling:
m0, b0: |00000000000000000000000000000000| delays: -
m0, b1: |00000000000011111111111111100000| delays: 19+-07
m0, b2: |00000000000000000000000000001111| delays: 14+-17
m0, b3: |00000000000000000000000000000000| delays: -
m0, b4: |00000000000000000000000000000000| delays: -
m0, b5: |00000000000000000000000000000000| delays: -
m0, b6: |00000000000000000000000000000000| delays: -
m0, b7: |00000000000000000000000000000000| delays: -
best: m0, b01 delays: 19+-07
m1, b0: |00000000000000000000000000000000| delays: -
m1, b1: |00000000000011111111111111000000| delays: 19+-07
m1, b2: |00000000000000000000000000001111| delays: 15+-17
m1, b3: |00000000000000000000000000000000| delays: -
m1, b4: |00000000000000000000000000000000| delays: -
m1, b5: |00000000000000000000000000000000| delays: -
m1, b6: |00000000000000000000000000000000| delays: -
m1, b7: |00000000000000000000000000000000| delays: -
best: m1, b01 delays: 19+-07
Switching SDRAM to hardware control.
--> 14+-17 and 15+-17 are confusing.
This is useful for long-running commands generally and in particular
for those without any data transfer, such as erase. It is a
level-sensitive interrupt because that makes it a little harder to
lose interrupts due to incorrect programming.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Bit 2 of the command register now tells the controller to wait while
the card is indicating that it is busy (by pulling the DAT0 line low).
The card can do this for commands 7 and 12 and app command 41 (and
also for commands 20, 28, 29, 38 and 43, but we don't use those here.)
This sets bit 2 for those commands.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
The issue is that with no description provided it simply would
not put out a description tag, which breaks compatibility with
other programs.
Insert a somewhat useful default description including a timestamp
and the words "LiteX SoC".
Not sure why nobody else saw this, but sometime in the last month's
patches sphinx started throwing an error when building docs for
the timer block. The problem is that the body and title are 'None'
and the doc code tries to invoke methods on None.
Changing the doc methodology to AutoDoc and explicitly creating the intro
section fixes this.
RAMXilinx was not infered correctly on Intel/Altera devices, we now have an Intel/Altera specific
implementation and could add other specific implementations in the future if required.
i2c@f0000800: '#address-cells' is a required property
From schema: Documentation/devicetree/bindings/i2c/litex,i2c.yaml
i2c@f0000800: '#size-cells' is a required property
From schema: Documentation/devicetree/bindings/i2c/litex,i2c.yaml
Fix this by adding the missing properties.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
gpio@f0003000: 'gpio-controller' is a required property
From schema: Documentation/devicetree/bindings/gpio/litex,gpio.yaml
gpio@f0003000: '#gpio-cells' is a required property
From schema: Documentation/devicetree/bindings/gpio/litex,gpio.yaml
Fix this by adding the missing properties.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
mmc@f0006800:reg:0: [4026558464, 256, 4026560512, 256, 4026562560, 256, 4026564608, 256] is too long
From schema: dt-schema/dtschema/schemas/simple-bus.yaml
mmc@f0006800:reg:0: [4026558464, 256, 4026560512, 256, 4026562560, 256, 4026564608, 256] is too long
From schema: dt-schema/dtschema/schemas/reg.yaml
Fix this by grouping the tuples in the "reg" property using angle
brackets.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
serial@f0001000: 'device_type' does not match any of the regexes: 'pinctrl-[0-9]+'
From schema: Documentation/devicetree/bindings/serial/litex,liteuart.yaml
Fix this by dropping the offending property.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
interrupt-controller@f0c00000: compatible:0: 'sifive,plic-1.0.0' is not one of ['sifive,fu540-c000-plic', 'canaan,k210-plic']
From schema: Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
interrupt-controller@f0c00000: compatible:1: 'sifive,plic-1.0.0' was expected
From schema: Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
interrupt-controller@f0c00000: '#address-cells' is a required property
From schema: Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
Fix this by correcting the order of the compatible values, and adding
the missing #address-cells property.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Assuming "#[address|size]-cells = <1>", both of the following are
equivalent:
reg = <start1 size1>, <start2 size2>, ..., <startN sizeN>;
reg = <start1 size1 start2 size2 ... startN sizeN>;
The second form appears more widely used and popular, including in
the output of json2dts.py, with the exception of the mac0 node, which
uses the first form. This patch makes output generated for mac0
consistent with that for other DT nodes.
Un-allocated CSRs were already automatically detected so when un-allocated we can just
simply allocate them automatically instead of raising an error. This also allows
simplifying user's code since self.csr.add/self.add_csr will no longer be required.
This commit adds support for enabling interupts in switches module.
Declaring switches as GPIOIn module with with_irq=True
will make dts generation add correct interrupt controller definition.
Also, if SWITCHES_NGPIO constant is defined it will be used to
specify correct number of gpios in dts.
example:
self.submodules.switches = GPIOIn(pads=switches_pads, with_irq=True)
self.add_csr("switches")
self.irq.add("switches", use_loc_if_exists=True)
self.add_constant("SWITCHES_NGPIO", len(switches_pads))
