On Tue, 21 May 2024, Jiaxun Yang wrote:
> It's nearly impossible to run MIPS OS in virtual (or paged)
> segment. All MIPS OS and bootloaders are running in KSEG/XKPHYS
> segment, which directly mapping lower bits of virtual address
> into physical address. So I suppose set_virtual_address_map
>
On Fri, 17 May 2024, Jiaxun Yang wrote:
> Replace it with his kenrel.org email, which has been used in
^^
Typo here.
Maciej
On Thu, 13 Jul 2023, Icenowy Zheng wrote:
> > FWIW, given the price and amount of DRAM used I think it makes no
> > sense
> > to build computers equipped with a DRAM subsystem without ECC
> > nowadays.
>
> Well the HiFive Unmatched board looks like it has a DRAM chip for ECC,
> but whether
On Wed, 28 Jun 2023, Icenowy Zheng wrote:
> When building the package `rustc` for AOSC OS on HiFive Unmatched,
> random SIGSEGV prevents the package from getting correctly built.
> Downclocking the CPU PLL clock seems to allow rustc to be built,
> although taking much more time.
>
> Downclock
On Sun, 8 Jan 2023, Heinrich Schuchardt wrote:
> > diff --git a/include/configs/sifive-unmatched.h
> > b/include/configs/sifive-unmatched.h
> > index 85fab92719..9261932af9 100644
> > --- a/include/configs/sifive-unmatched.h
> > +++ b/include/configs/sifive-unmatched.h
> > @@ -19,6 +19,7 @@
> >
On Tue, 30 Aug 2022, Pali Rohár wrote:
> > Agreed. But I also understand the reasoning from Maciej, at least in
> > parts. Thinking a bit more about this, my preference would be to still
> > include this workaround per default in U-Boot proper though. To not
> > make things too complicated here.
On Tue, 30 Aug 2022, Stefan Roese wrote:
> > I think I wrote it. One issue is that it is increasing size of SPL image
> > and we really should not include into SPL things which are not required
> > for all target platforms. Lot of boards have size constrained memory
> > requirements and
On Tue, 30 Aug 2022, Pali Rohár wrote:
> > > Moreover this workaround is enabled for all existing hardware and also all
> > > future PCIe hardware, which opens a hole that other PCIe vendors may
> > > introduce same HW issue as on systems where this workaround is required
> > > and
> > > nobody
On Sat, 27 Aug 2022, Pali Rohár wrote:
> Moreover this workaround is enabled for all existing hardware and also all
> future PCIe hardware, which opens a hole that other PCIe vendors may
> introduce same HW issue as on systems where this workaround is required and
> nobody would notice it because
On Thu, 5 May 2022, Maciej W. Rozycki wrote:
> > I see that Linux patch was not not merged yet and there are already
> > comments that this issue is probably board or arch specific and maybe
> > should be in arch/riscv linux dir:
> > https://lore.kernel.org/linux-pci/
On Sun, 1 May 2022, Pali Rohár wrote:
> > By now I have become somewhat tired arguing and explaining matters over
> > and over again as things have been moving as slow as molasses in this
> > area, but one point I want to raise here is while it is indeed the ASM2824
> > device that seems
On Thu, 7 Apr 2022, Stefan Roese wrote:
> > Hello! What do you think about this change? I think it is good
> > compromise between enable this workaround for all builds on all boards
> > and enable it only based on device id. Or would it be better to restrict
> > this workaround just for ASM2824
On Sat, 15 Jan 2022, Tom Rini wrote:
> > Keep the 2.5GT/s speed restriction then, conservatively, if functional
> > once applied.
> >
> > Signed-off-by: Maciej W. Rozycki
> > Reviewed-by: Stefan Roese
>
> Applied to u-boot/master, thanks!
Great,
On Wed, 12 Jan 2022, Tom Rini wrote:
> > I believe this version has addressed all concerns raised in the review
> > thus far. With the nature of a problem better understood now I'm sending
> > a corresponding update for Linux as well.
>
> What as the feedback to your Linux change? Is this
On Sat, 20 Nov 2021, Maciej W. Rozycki wrote:
> Attempt to handle cases with a downstream port of a PCIe switch where
> link training never completes and the link continues switching between
> speeds indefinitely with the data link layer never reaching the active
> state.
Ping
cky property of the Target Link Speed setting will keep the
2.5GT/s speed restriction across a reset.
Keep the 2.5GT/s speed restriction then, conservatively, if functional
once applied.
Signed-off-by: Maciej W. Rozycki
---
Hi,
I believe this version has addressed all concerns rai
On Thu, 18 Nov 2021, Maciej W. Rozycki wrote:
> "Use the Data Link Layer Link Active status flag as the primary indicator
> of successful link speed negotiation, but given that the flag is optional
> by hardware to implement (the ASM2824 does have it though) [...]"
NB I di
Hi Stefan,
> > > I would like to hear what Bjorn Helgaas thinks about this issue at all
> > > and how to handle it, without potentially break something else. And
> > > based on the fact that in U-Boot's PCI core code there is no such global
> > > quirk implemented, I really do not know if U-Boot
Hi Pali,
> > If that has indicated failure, reduce the target speed, request a link
> > retrain and check again if the link has stabilised. Repeat until either
> > successful or the link speeds supported by the downstream port have been
> > exhausted.
>
> I would like to hear what Bjorn
Hi Stefan,
> > Make use of this observation then and attempt to detect the inability to
> > negotiate the link speed automatically, and then handle it by hand. Use
> > the Data Link Layer Link Active status flag as the primary indicator of
> > successful link speed negotiation, but given that
eds supported by the downstream port have been
exhausted.
Signed-off-by: Maciej W. Rozycki
---
Hi,
Thank you, Pali, for your valuable feedback. Here's v2 of the change
with your suggestions taken into account. I believe I have addressed all
your concerns and I haven't heard from anyone else,
Hi Pali,
> > Well, this code checks for non-zero lnkcap2 first and ignores it if it's
> > zero, so I believe it does the right thing. Have I missed anything?
>
> I'm reading spec again and I'm not sure now. It has following section:
>
> For software to determine the supported Link speeds
Hi Pali,
> > + dm_pci_read_config32(dev, pcie_off + PCI_EXP_LNKCAP, _lnkcap);
> > + dm_pci_read_config32(dev, pcie_off + PCI_EXP_LNKCAP2, _lnkcap2);
> > + for (speed = (exp_lnkcap & PCI_EXP_LNKCAP_SLS) - 1;
> > +speed >= PCI_EXP_LNKCAP_SLS_2_5GB;
> > +speed--) {
> > +
ave been
exhausted.
Signed-off-by: Maciej W. Rozycki
---
Hi,
I came across this issue when building the system based on my recently
acquired SiFive HiFive Unmatched board. One of the project objectives was
to have a pair of legacy PCI options wired and in the course of the design
I came
On Thu, 13 Dec 2018, Daniel Schwierzeck wrote:
> > I'm not so sure, if overwriting 0x8000 (default value of EBase on
> > this SoC) with the exception handler is allowed. Is this address "zero"
> > handled somewhat specific in MIPS Linux? AFAICT, the complete DDR
> > area on my platform
25 matches
Mail list logo
