Hi all,
You can ignore my previous email. It looks like it's being added as I type
this.
Best Regards,
-Aaron Williams
On Wednesday, September 22, 2021 6:22:00 PM PDT Aaron Williams wrote:
> Hi Bin, Stefan,
>
> Is the U-Boot USB support compatible with USB 3.1 or does this need to b
?
Best Regards,
-Aaron Williams
Tue, 2021-02-23 at 09:15 +0100, Stefan Roese wrote:
> >>> Hi Bin,
> >>> Hi Aaron,
> >>>
> >>> I've added Nicolas to Cc, as he also recently did some work on the
> >>> physical vs virtual addresses in the xHCI driver.
> >>>
Hi Bin,
I can do that later. Right now I'm under the gun to get my backport working
with a USB 3 hub. It is failing when trying to set the hub depth.
-Aaron
On Tuesday, February 23, 2021 12:07:57 AM PST Bin Meng wrote:
> Hi Aaron,
>
> On Tue, Feb 23, 2021 at 3:31 PM Aaron William
, the Octeon
XHCI controller does not use the scratchpad memory.
-Aaron
On Friday, February 19, 2021 5:57:47 AM PST Aaron Williams wrote:
> External Email
>
> --
> Hi all,
>
> While backporting the latest USB
Hi all,
While backporting the latest USB support in U-Boot to support USB 3 hubs I
decided to try the latest U-Boot for Octeon which should contain everything.
When I start USB, however, with a USB 3 thumb drive plugged into a USB 3 hub,
I am seeing a crash. I have enabled all of the debugging
Hi all,
I am looking at using FIT images to update the various blobs in our SPI NOR
and eMMC devices since various blobs must be placed at specific addresses.
Right now it looks like this update support is limited to CFI flash. Does
anyone have any thoughts on extending this to SPI NOR and
Hi Simon,
On Tuesday, November 19, 2019 7:00:23 PM PST Simon Glass wrote:
> External Email
>
> --
> Hi,
>
> On Tue, 29 Oct 2019 at 14:08, Suneel Garapati
wrote:
> > From: Suneel Garapati
> >
> > Signed-off-by: Suneel
Hi Wolfgang,
On Wednesday, November 6, 2019 7:06:17 AM PST Wolfgang Denk wrote:
> Dear Aaron,
>
> In message
you wrote:
> > > Definitely not. You could not implement any of this without heavily
> > > relyin on and deriving from internal interfaces of U-Boot which are
> > > not exported for
Hi Tom,
From: Tom Rini
Sent: Tuesday, November 5, 2019 6:16 AM
To: Wolfgang Denk
Cc: Aaron Williams; Daniel Schwierzeck; u-boot@lists.denx.de
Subject: Re: [EXT] Re: Cavium/Marvell Octeon Support
On Tue, Nov 05, 2019 at 09:33:35AM +0100, Wolfgang Denk wrote
From: Wolfgang Denk
Sent: Tuesday, November 5, 2019 3:36 AM
To: Aaron Williams
Cc: Tom Rini ; Daniel Schwierzeck
; u-boot@lists.denx.de
Subject: Re: [EXT] Re: Cavium/Marvell Octeon Support
Hi Wolfgang,
I apologize in advance for the lack of email
Hi Wolfgang,
On Tuesday, November 5, 2019 12:37:26 AM PST Wolfgang Denk wrote:
> Dear Aaron,
>
> In message <1838672.aZrPjDvGh8@flash> you wrote:
> > To be blunt, the current U-Boot EFI driver does not provide the required
> > functionality. It would need to be extended in order to work. In
Hi Wolfgang,
On Monday, November 4, 2019 9:22:16 AM PST Tom Rini wrote:
> On Thu, Oct 31, 2019 at 06:01:34PM +0000, Aaron Williams wrote:
> > Hi Wolfgang,
> >
> > On Thursday, October 31, 2019 3:40:27 AM PDT Wolfgang Denk wrote:
> > > Dear Aaron,
> > >
>
On Monday, November 4, 2019 8:23:08 AM PST Tom Rini wrote:
> On Mon, Nov 04, 2019 at 04:44:18PM +0100, Wolfgang Denk wrote:
> > Dear Aaron,
> >
> > In message <2710076.TiSPtmOvtb@flash> you wrote:
> > > > What exactly do you need this for? Why don't you just link your
> > > > code with the rest
Hi Wolfgang,
On Monday, November 4, 2019 7:44:18 AM PST Wolfgang Denk wrote:
> Dear Aaron,
>
> In message <2710076.TiSPtmOvtb@flash> you wrote:
> > > What exactly do you need this for? Why don't you just link your
> > > code with the rest of U-Boot?
> >
> > We need it to obtain and modify the
Hi Tim,
On Thursday, October 31, 2019 12:12:34 PM PST Tim Harvey wrote:
> On Wed, Oct 30, 2019 at 5:04 PM Aaron Williams
wrote:
> > Hi Tim,
> >
> > I think I can answer some of your questions.
> >
> > On Wednesday, October 30, 2019 10:06:41 AM PDT Tim H
On Thursday, October 31, 2019 6:26:51 AM PDT Tom Rini wrote:
> On Wed, Oct 30, 2019 at 11:36:19PM +0000, Aaron Williams wrote:
> > On Wednesday, October 30, 2019 3:05:25 PM PDT Tom Rini wrote:
> > &
Hi Wolfgang,
On Thursday, October 31, 2019 3:40:27 AM PDT Wolfgang Denk wrote:
> Dear Aaron,
>
> In message <1889679.7FQr5zsBR1@flash> you wrote:
> > Currently we are using 39MB under arch/mips. I think I can easily cut this
> > down to 15MB or smaller, especially by moving some code here to the
On Thursday, October 31, 2019 3:36:10 AM PDT Wolfgang Denk wrote:
> Dear Aaron,
>
> In message <1932577.QJWW3v3lL8@flash> you wrote:
> > We do this relocation as well, however the way we do it is by changing a
> > couple of TLB entries. This lets U-Boot begin execution from any memory
> >
Hi Tim,
I think I can answer some of your questions.
On Wednesday, October 30, 2019 10:06:41 AM PDT Tim Harvey wrote:
> External Email
>
> --
>
> On Tue, Oct 29, 2019 at 2:08 PM Suneel Garapati
wrote:
> > This series will
On Wednesday, October 30, 2019 3:05:25 PM PDT Tom Rini wrote:
> External Email
>
> --
>
> On Wed, Oct 23, 2019 at 03:50:00AM +, Aaron Williams wrote:
> > Hi all,
> >
> > I have been task
On Saturday, October 26, 2019 3:15:36 PM PDT Tom Rini wrote:
> External Email
>
> --
>
> On Fri, Oct 25, 2019 at 05:13:57PM +0200, Daniel Schwierzeck wrote:
> > Hi Aaron,
> >
> > Am 23.10.1
Hi Daniel,
On Friday, October 25, 2019 8:13:57 AM PDT Daniel Schwierzeck wrote:
> External Email
>
> --
> Hi Aaron,
>
> Am 23.10.19 um 05:50 schrieb Aaron Williams:
> > Hi all,
> >
> >
Hi all,
I have been tasked with porting our Octeon U-Boot to the latest U-Boot and
merging it upstream. This will involve a very significant amount of code that
generally will not be compatible with other MIPS processors due to our needs
and requirements. For example, the start.S will need to
Hi Simon,
From: Simon Glass
Sent: Friday, October 11, 2019 4:42 PM
To: Aaron Williams
Cc: Bin Meng ; u-boot@lists.denx.de
Subject: Re: [EXT] Re: [U-Boot] Issues with driver binding and probing
Hi Aaron,
On Wed, 25 Sep 2019 at 22:08, Aaron Williams wrote
Hi Simon,
On Friday, October 11, 2019 4:42:55 PM PDT Simon Glass wrote:
> Hi Aaron,
>
> On Wed, 25 Sep 2019 at 22:08, Aaron Williams wrote:
> > Hi Simon,
> >
> > On Wednesday, September 25, 2019 8:40:48 PM PDT Bin Meng
Hi Simon,
On Wednesday, September 25, 2019 8:40:48 PM PDT Bin Meng wrote:
> External Email
>
> --
> +Simon
>
> Hi Aaron,
>
> On Thu, Sep 26, 2019 at 11:10 AM Aaron Williams
wrote:
> > Hi all,
&g
Hi all,
I have an issue where I have a nexus driver and a sub serial driver on top of
it. The base nexus driver is getting bound and probed properly, however the
serial drivers (pci-console) below it are not.
My device tree looks something like this:
pci-console-nexus@0x0300 {
On Thursday, September 19, 2019 4:43:27 AM PDT Stefan Roese wrote:
Hi Stefan,
>
> --
> Hi Aaron,
>
> On 19.09.19 13:35, Aaron Williams wrote:
> > Hi,
> >
> > In my device tree I need to
On 19.09.19 13:35, Aaron Williams wrote:
> > Hi,
> >
> > In my device tree I need to translate some address via ranges but I'm
> > running into some issues. If I use ofnode_get_addr_size() it is not using
> > the #address-cells and #size-cells nor is it performing
Hi,
In my device tree I need to translate some address via ranges but I'm running
into some issues. If I use ofnode_get_addr_size() it is not using the
#address-cells and #size-cells nor is it performing the ranges translation. It
always assumes #address-cells and #size-cells is 2 and doesn't
64K where packets fit in the first half. I have attached this patch to force
the XHCI problem to manifest itself.
-Aaron
On Friday, July 12, 2019 8:51:41 PM PDT Aaron Williams wrote:
> No, it's our Marvell OcteonTX2 SoC. I put in what I thought was a fix, but
> I'm still w
:00 PM PDT Bin Meng wrote:
> External Email
>
> --
> Hi Aaron,
>
> On Sat, Sep 7, 2019 at 11:08 AM Aaron Williams
wrote:
> > Hi,
> >
> > I am seeing crashes in our XHCI implementation based o
4.10.1.1.1.
Personally I find this PAE bit a major pain in the arse that causes more
trouble than it's worth.
-Aaron
--
Aaron Williams
Senior Software Engineer
Marvell Semiconductor, Inc.
(408) 943-7198 (510) 789-8988 (cell)
signature.asc
Description: This is a digitally signed message part
-by: Aaron Williams
Reviewed-by: Bin Meng
---
drivers/nvme/nvme.c | 29 +++--
1 file changed, 19 insertions(+), 10 deletions(-)
diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
index d4965e2ef6..47f101e280 100644
--- a/drivers/nvme/nvme.c
+++ b/drivers/nvme/nvme.c
-by: Aaron Williams
Reviewed-by: Bin Meng
---
drivers/nvme/nvme.c | 29 +++--
1 file changed, 19 insertions(+), 10 deletions(-)
diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
index d4965e2ef6..47f101e280 100644
--- a/drivers/nvme/nvme.c
+++ b/drivers/nvme/nvme.c
Doh! I forgot to check that in. This should fix it. I'm still
trying to get used to git send-email.
-Aaron
Aaron Williams (1):
nvme: Fix PRP Offset Invalid
drivers/nvme/nvme.c | 29 +++--
1 file changed, 19 insertions(+), 10 deletions(-)
--
2.16.4
-by: Aaron Williams
Reviewed-by: Bin Meng
---
drivers/nvme/nvme.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
index d4965e2ef6..bc4cf40b40 100644
--- a/drivers/nvme/nvme.c
+++ b/drivers/nvme/nvme.c
-by: Aaron Williams
Reviewed-by: Bin Meng
---
drivers/nvme/nvme.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
index d4965e2ef6..bc4cf40b40 100644
--- a/drivers/nvme/nvme.c
+++ b/drivers/nvme/nvme.c
points to the next
page. This patch fixes this and duplicates the way this works in
the Linux kernel.
Personally I would like to move away from using PRP since I think
it may be possible to just use a simple scatter-gather entry instead.
If I do that it will be in a later patch.
Aaron Williams (1
I'm sorry about the messed up subject saying [PATCH]. For some reason git
send-email is mangling the subject line. I'm new to trying to use this method
to send out patches. This is version 2 of my patch.
-Aaron
On Thursday, August 22, 2019 2:12:32 AM PDT Aaron Williams wrote:
> When la
-by: Aaron Williams
---
drivers/nvme/nvme.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
index d4965e2ef6..bc4cf40b40 100644
--- a/drivers/nvme/nvme.c
+++ b/drivers/nvme/nvme.c
@@ -73,6 +73,9 @@ static
From: Aaron Williams
When large writes take place I saw a Samsung EVO 970+ return a status
value of 0x13, PRP Offset Invalid. I tracked this down to the
improper handling of PRP entries. The blocks the PRP entries are
placed in cannot cross a page boundary and thus should be allocated
on page
Hi Bin,
On Wednesday, August 21, 2019 8:23:50 AM PDT Bin Meng wrote:
> Hi Aaron,
>
> On Wed, Aug 21, 2019 at 7:26 PM Aaron Williams
wrote:
> > Hi Bin,
> >
> > I submitted another patch via git. Hopefully it went through. I'm new to
> > trying to get email
From: Aaron Williams
When large writes take place I saw a Samsung EVO 970+ return a status
value of 0x13, PRP Offset Invalid. I tracked this down to the
improper handling of PRP entries. The blocks the PRP entries are
placed in cannot cross a page boundary and thus should be allocated
on page
From: Aaron Williams
When large writes take place I saw a Samsung EVO 970+ return a status
value of 0x13, PRP Offset Invalid. I tracked this down to the
improper handling of PRP entries. The blocks the PRP entries are
placed in cannot cross a page boundary and thus should be allocated
on page
PDT Bin Meng wrote:
> External Email
>
> --
> Hi Aaron,
>
> On Wed, Aug 21, 2019 at 8:34 AM Aaron Williams
wrote:
> > When large writes take place I saw a Samsung
> > EVO 970+ return a status value o
Hopefully this addresses your concerns. Note that nprbs can't be used
directly for the size since one must be removed from each page to point
to the next page.
-Aaron
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
From: Aaron Williams
When large writes take place I saw a Samsung EVO 970+ return a status
value of 0x13, PRP Offset Invalid. I tracked this down to the
improper handling of PRP entries. The blocks the PRP entries are
placed in cannot cross a page boundary and thus should be allocated
on page
wrote:
> External Email
>
> --
>
> On Wed, Aug 21, 2019 at 10:29 AM Aaron Williams
wrote:
> > OK, for some reason my patch with this fix is not making it to this
> > mailing
> > list.
>
&g
OK, for some reason my patch with this fix is not making it to this mailing
list.
-Aaron
On Tuesday, August 20, 2019 5:23:29 PM PDT Aaron Williams wrote:
> Our QA team had problems writing large files (187MB) to the
> FAT filesystem on a Samsung EVO 970 NVME drive and I was
> able
-by: Aaron Williams
---
drivers/nvme/nvme.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
index 7008a54a6d..ae64459edf 100644
--- a/drivers/nvme/nvme.c
+++ b/drivers/nvme/nvme.c
@@ -75,6 +75,8 @@ static int nvme_setup_prps
-by: Aaron Williams
---
drivers/nvme/nvme.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
index 7008a54a6d..ae64459edf 100644
--- a/drivers/nvme/nvme.c
+++ b/drivers/nvme/nvme.c
@@ -75,6 +75,8 @@ static int nvme_setup_prps
driver to match what the Linux kernel PCI
driver does.
Aaron Williams (1):
nvme: Fix PRP Offset Invalid
drivers/nvme/nvme.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https
Let's try this yet again. I'm sorry if multiple emails are going
out, I'm having issues getting git send-email working with our
mail server.
Anyway, this fixes a problem where the U-Boot NVME driver fails
during large transfers due to the way the NVME driver allocates
the PRP data structure.
driver to match what the Linux kernel PCI
driver does.
Aaron Williams (1):
nvme: Fix PRP Offset Invalid
drivers/nvme/nvme.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https
-by: Aaron Williams
---
drivers/nvme/nvme.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
index 7008a54a6d..ae64459edf 100644
--- a/drivers/nvme/nvme.c
+++ b/drivers/nvme/nvme.c
@@ -75,6 +75,8 @@ static int nvme_setup_prps
: I8df66c87d6a6105da556d327d4cc5148e444d20e
Signed-off-by: Aaron Williams
---
drivers/nvme/nvme.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
index 7008a54a6d..c94a6d0654 100644
--- a/drivers/nvme/nvme.c
+++ b/drivers/nvme
in contact now with one of our hardware designers who can hopefully answer
what's going on.
-Aaron
From: Bin Meng
Sent: Wednesday, July 10, 2019 9:57 PM
To: Aaron Williams
Cc: u-boot@lists.denx.de
Subject: [EXT] Re: [U-Boot] [u-boot][xhci] Dealing with XHCI controllers with
spurious success
Hi All,
I'm running into a problem with the XHCI driver on our SOC where I am getting
spurious success TRBs after a short packet response. In this particular case,
the driver for a USB network controller has a receive buffer that crosses a 64K
boundary. This results in two TRBs being created
Hi all,
I am debugging a problem where sometimes our hardware (DW implementation)
responds with a short TX event (13) during a bulk transfer when two TRBs are
involved. In this case, a USB Ethernet driver is receiving data and the buffer
address and size causes it to cross a 64K boundary. Due
Hi all,
I'm working on a driver for our ARM64 SOCs but am having an issue where the
driver never gets probed. I added a bind function and the driver is getting
bound and I have the appropriate entry in the device tree for it, but the probe
function is never called.
This is a pseudo driver in
port for our boards up to
> date without having to bring all the Octeon SoC support forward as
> well. Is there any interest from Cavium to get Octeon upstreamed?
--
Aaron Williams
Senior Software Engineer
Cavium, Inc.
(408) 943-7198 (510) 789-8988 (cell)
Hi all,
I am trying to port our OcteonTX Linux NAND driver to U-Boot and am running
into an issue with ordering. We have a bch engine which consists of a pf and a
vf and uses SRIOV to activate the vf.
The problem is that the nand device is probed before the BCH engine is probed
and the NAND
On Tuesday, July 24, 2018 2:45:42 AM PDT Marek Vasut wrote:
> External Email
>
> On 07/24/2018 08:25 AM, Aaron Williams wrote:
> > On Monday, July 23, 2018 11:15:59 PM PDT Aaron Williams wrote:
> >> External Email
> >>
> >> Hi all,
> >>
> &g
On Monday, July 23, 2018 11:25:41 PM PDT Aaron Williams wrote:
> External Email
>
> On Monday, July 23, 2018 11:15:59 PM PDT Aaron Williams wrote:
>
> > External Email
> >
> >
> >
> > Hi all,
> >
> >
> >
> > It looks like after a
On Monday, July 23, 2018 11:15:59 PM PDT Aaron Williams wrote:
> External Email
>
> Hi all,
>
> It looks like after a certain amount of data has been written that all hell
> breaks loose with the ext4 filesystem.
>
> In my case, I have the following files on a 64G
has been backported to our older MIPS
bootloader.
My guess is that all hell is breaking loose when a file spans multiple block
groups.
-Aaron Williams
On Thursday, July 19, 2018 7:35:46 PM PDT Aaron Williams wrote:
>
> Hi all,
>
> I am sometimes seeing issues when using ext4writ
the descriptor is larger than the offset. When
debugging was enabled I'd always hit this assert.
Also, in ext4fs_write, the debug statement should say blocks and not bytes.
-Aaron
--
Aaron Williams
Senior Software Engineer
Cavium, Inc.
(408) 943-7198 (510) 789-8988 (cell
gt; > >> Hi all,
> > >>
> > >> The latest git version does not turn on USB power on BeagleBone Black:
> > >> "usb start" reports that the port is not accessible, but with external
> > >> power provided it detects the
On Tuesday, July 25, 2017 4:54:15 PM PDT Aaron Williams wrote:
> Hi all,
>
> I am trying to enable support for booting signed FIT images but I'm not sure
> how I go about setting up the public keys. The documentation under
> uImage.fit does not seem to cover how to go about sett
or fit_image_process_hash returns -ENOSPC then -1 is
returned which causes mkimage to fail. Instead shouldn't -ENOSPC be returned
so that mkimage can resize the image and allow it to proceed?
Cheers,
-Aaron
--
Aaron Williams
Senior Software Engineer
Cavium, Inc.
(408) 943-7198 (510) 789-8988 (cell
Hi Jagen,
On 11/01/2016 11:33 AM, Jagan Teki wrote:
On Tue, Nov 1, 2016 at 6:49 AM, Aaron Williams
<aaron.willi...@caviumnetworks.com> wrote:
Hi all,
I am working on several drivers for our Octeon-TX/Thunder chips which talk
to devices connected to the ECAM bus through another sub-bus
device tree? How should I go about setting it up so that
not only things like the base address get resolved but also the
of_offset field since all of the slot configuration comes from the
device tree.
In our case we have a single MMC device on the
not allow for this. There can be multiple PCI devices
as well in our NUMA configurations, with one PCI device per SoC.
-Aaron
--
Aaron Williams
Software Engineer
Cavium, Inc.
(408) 943-7198 (510) 789-8988 (cell)
___
U-Boot mailing list
U-Boot@lists.denx.de
don't run into
the situation we've been stuck with our Octeon MIPS processors. My
biggest problem is that a lot of code doesn't work.
I'm still trying to get up to speed with the armv8 U-Boot.
-Aaron
--
Aaron Williams
Software Engineer
Cavium, Inc.
(408) 943-7198 (510) 789-8988 (cell
Hi Marek,
On 12/17/2015 07:06 AM, Marek Vasut wrote:
On Thursday, December 17, 2015 at 10:12:08 AM, Aaron Williams wrote:
Hi all,
Hi Aaron,
I maintain U-Boot for the Cavium Octeon series of 64-bit MIPS processors
and have been experiencing problems with USB 3 hubs with XHCI.
If I plug
to the sheer amount of code involved.
-Aaron
--
Aaron Williams
Software Engineer
Cavium, Inc.
(408) 943-7198 (510) 789-8988 (cell)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
--
Aaron Williams
Software Engineer
Cavium, Inc.
(408) 943-7198 (510) 789-8988 (cell)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
to
drives no longer applies.
-Aaron
--
Aaron Williams
Software Engineer
Cavium, Inc.
(408) 943-7198 (510) 789-8988 (cell)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
More info
On 01/13/2014 08:28 PM, Aaron Williams wrote:
On 01/13/2014 06:20 PM, Aaron Williams wrote:
Hi all,
I am bringing up XHCI support for our SOC and have run into several
issues with U-Boot's XHCI code.
1. I need to use a wrapper I call xhci_readl/xhci_writel since all of
our I/O
involved for our MIPS SOCs.
-Aaron
--
Aaron Williams
Software Engineer
Cavium, Inc.
(408) 943-7198 (510) 789-8988 (cell)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
On 01/13/2014 06:20 PM, Aaron Williams wrote:
Hi all,
I am bringing up XHCI support for our SOC and have run into several
issues with U-Boot's XHCI code.
1. I need to use a wrapper I call xhci_readl/xhci_writel since all of
our I/O is to 64-bit addresses rather than readl/writel which work
Hi Simon,
Sorry for the long delay.
On 10/17/2013 03:27 PM, Simon Glass wrote:
Hi Aaron,
On Thu, Oct 17, 2013 at 12:24 AM, Aaron Williams
aaron.willi...@caviumnetworks.com wrote:
Hi all,
In our bootloader based off of 2013.07 we make extensive use of the flat
device tree. In profiling our
of the space taken since now the linker can place these
in BSS.
-Aaron
--
Aaron Williams
Software Engineer
Cavium, Inc.
(408) 943-7198 (510) 789-8988 (cell)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
into is that the M95XXX driver is hard coded to use CS1.
Perhaps the eeprom command could be enhanced to specify whether the
device should be spi or i2c rather than hard coded as well as support
multiple devices?
-Aaron
--
Aaron Williams
Software Engineer
Cavium, Inc.
(408) 943-7198 (510) 789-8988
Never mind about the multiple devices, it looks like that is supported.
My problem is still that only either I2C or SPI are supported and not both.
-Aaron
On 11/18/2013 08:18 PM, Aaron Williams wrote:
Hi all,
On one of our new boards we have both a SPI (M9256-W) and I2C
(24lc256) EEPROM. I
for
improvement especially in the skip name section.
Some of the checks in fdt_offset_ptr also look useless, such as if
((offset + len) offset) which will always be false, or
if (p + len p)
len is always positive.
-Aaron
--
Aaron Williams
Software Engineer
Cavium, Inc.
(408) 943-7198 (510) 789
Thanks, I'll be glad to finally see this patch applied.
-Aaron
On 04/02/2013 05:34 AM, Stefan Roese wrote:
On 27.03.2013 11:22, Jagannadha Sutradharudu Teki wrote:
Hi,
Any update on this.
I'll apply this patch shortly. Sorry for the delay.
Thanks,
Stefan
--
Aaron Williams
Software
*l_name)
/* Get short file name and checksum value */
strncpy(s_name, (*dentptr)-name, 16);
- checksum = mkcksum(s_name);
+ checksum = mkcksum((*dentptr)-name, (*dentptr)-ext);
do {
memset(slotptr, 0x00, sizeof(dir_slot));
--
Aaron Williams
Software
solution.
Ideally device tree support should be integrated more deeply into U-Boot
so each PHY device would have its node offset stored like in the Linux
driver.
-Aaron
--
Aaron Williams
Software Engineer
Cavium, Inc.
(408) 943-7198 (510) 789-8988 (cell
Hi Daniel,
My comments are inline.
On 07/09/2012 02:11 PM, Daniel Schwierzeck wrote:
Hi Aaron,
2012/7/6 Aaron Williams aaron.willi...@cavium.com:
Hi Andreas,
I would love to see OCTEON support in the mainline as well, though I am not
sure how I should go about this since it is a substantial
of the timing parameters on our boot bus or
allows the timing parameters to be changed for various devices
-Aaron
On 07/06/2012 01:19 AM, Andreas Bießmann wrote:
Dear Aaron Williams,
On 06.07.2012 01:52, Aaron Williams wrote:
Hi Zahid,
I am in charge of U-Boot for OCTEON MIPS. I have
).
I have not followed their open source efforts since then, but I saw a
lot of work on the linux-mips list by David Daney and I think Aaron
Williams is working for Cavium too and is on this list. Maybe one of
them can comment?
Please put some light on this. I would be glad if you guys,
give my some
guys,
give my some idea to where to start with or suggest some documents which
will help me understand and port on a new architecture
Regards
Zahid
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
--
Aaron
Hi all,
There seems to be an issue with the tftpboot command in that it changes
load_addr but does not update the loadaddr environment variable.
Shouldn't these two remain in sync?
-Aaron
--
Aaron Williams
Software Engineer
Cavium, Inc.
(408) 943-7198 (510) 789-8988 (cell
Hi Anatolij,
On 05/12/2012 08:41 AM, Anatolij Gustschin wrote:
Hello,
On Wed, 02 May 2012 19:17:41 -0700
Aaron Williams aaron.willi...@cavium.com wrote:
This patch fixes several issues where sector offsets can overflow due to
being limited to 16-bits. There are many cases which can cause
Has anyone implemented a command to use lzma and/or bzip to decompress
files in memory like unzip?
-Aaron
--
Aaron Williams
Software Engineer
Cavium, Inc.
(408) 943-7198 (510) 789-8988 (cell)
___
U-Boot mailing list
U-Boot@lists.denx.de
http
Any comments on this patch?
On 05/02/2012 07:17 PM, Aaron Williams wrote:
This patch fixes several issues where sector offsets can overflow due to
being limited to 16-bits. There are many cases which can cause an
overflow, including large FAT32 partitions and partitions that start
and fixed when a 64GB FAT32 filesystem was
accessed due to truncation.
Signed-off-by: Aaron Williams aaron.willi...@caviumnetworks.com
---
include/fat.h | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/fat.h b/include/fat.h
index 4c92442..7215628 100644
1 - 100 of 174 matches
Mail list logo
