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
, 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 su
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 Wi
t; On 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.
> >
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 tasked
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 add
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
> > location
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 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 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
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 p
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 o
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,
> > >
>
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 addit
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 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
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 n
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 Garapat
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 eMMC
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,
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 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 b
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,
> >
> >
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
lines of code 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
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
wrote:
Hi all,
In our bootloader based off of 2013.07 we make extensive use of the flat
device tree. In profiling our bootloader in our simulator I
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
fixed when a 64GB FAT32 filesystem was
accessed due to truncation.
Signed-off-by: Aaron Williams
---
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
--- a/include/fat.h
+++ b/include/fat.h
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 sta
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
Hi Anatolij,
On 05/12/2012 08:41 AM, Anatolij Gustschin wrote:
> Hello,
>
> On Wed, 02 May 2012 19:17:41 -0700
> Aaron Williams wrote:
>
>> This patch fixes several issues where sector offsets can overflow due to
>> being limited to 16-bits. There are many cases whi
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
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
> ok, we assume we are on a PBR only */
Hi Wolfgang,
I know it's rather late to comment on this, but this patch breaks FAT write
support.
-Aaron
--
Aaron Williams
(408) 943-7198
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
for that piece
of GPL code).
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
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
tloader, used when booting from
MMC/SD.
- octbootbus - Prints all 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:
H
Hi Daniel,
My comments are inline.
On 07/09/2012 02:11 PM, Daniel Schwierzeck wrote:
Hi Aaron,
2012/7/6 Aaron Williams :
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 amount of code
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 William
dentptr)->name, 16);
- checksum = mkcksum(s_name);
+ checksum = mkcksum((*dentptr)->name, (*dentptr)->ext);
do {
memset(slotptr, 0x00, sizeof(dir_slot));
--
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
long-term 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-
Hi all,
I was wondering if anyone has done any work on supporting USB 3.0 xHCI in U-
Boot?
-Aaron
--
Aaron Williams
(408) 943-7198
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
I'm working on adding EHCI support for our chips to U-Boot and I'm a bit
confused. In our case I have to replace the ehci_read/writel macros since all
of our EHCI registers are located starting at 0x800016F000400 (notice it's
a 64-bit address).
Anyway, to get back to my comment, it seems th
/2010.
-Aaron Williams
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
I just got EHCI support working with our chip and I was wondering what sort of
performance I could expect using ext2? Right now it seems extremely slow
coming off of a fast solid-state drive. I'm getting around 100KB/second. It's
running at full-speed (480Mbps). Is this normal?
We are basicall
On 1/14/2011 1:19 AM, Wolfgang Denk wrote:
> Dear Aaron Williams,
>
> please always keep the ML on cc:
>
> In message<4d2fa7f0.7020...@caviumnetworks.com> you wrote:
>> It is based off of 2010.09 but I have applied all of the latest USB
>> updates from GIT with
s filesystem will be automatically checked every 35 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
-Aaron
On Friday, January 14, 2011 01:19:04 am Wolfgang Denk wrote:
> Dear Aaron Williams,
>
> please always keep the ML on cc:
>
> In message <4d2fa7f0
I traced down the poor performance I was seeing with USB to only the
ext2 filesystem. With FAT32 I am getting 10MB/sec for file transfers,
but with ext2 I am only getting 100KB/sec.
I formatted the drive with:
mkfs.ext3 -j -L iomega -O dir_index,has_journal,large_file -t ext3 -v
/dev/sdc1
mke2f
The min and max macros break if x is 32-bit and y is 64-bit. y will always get
truncated to 32-bit and it will fail.
-Aaron
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
In some of my work with the Cavium Octeon 64-bit processor I ran into a
problem with the min and max macros provided in common.h. The problem occurs
if x is 32-bit and y is 64-bit. In this case, y will always be truncated to
32-bits. This patch fixes this problem.
-Aaron
diff --git a/include/
I ran into a problem with the Spansion S29GL064N flash chip in that it returns
a manufacturer ID of 0 and it also requires the AMD geometry fixup.
Additionally, I modified a few print statements to use KiB/MiB instead of
kB/MB.
-Aaron Williams
diff --git a/drivers/mtd/cfi_flash.c b/drivers
Any comments on this? This bug caused me a lot of problems since we make use
of 64-bit values quite a bit.
-Aaron
On Tuesday, January 25, 2011 02:30:55 pm Aaron Williams wrote:
> In some of my work with the Cavium Octeon 64-bit processor I ran into a
> problem with the min and max
Hi all,
It looks like the mtd partitioning code fails if the flash size exceeds a u32.
I am working with an 8GB flash chip on our board and was wondering if anyone
else has any experience with MTD with a chip this large?
-Aaron
___
U-Boot mailing list
I'll probably have something later today. I got it working with an earlier
version of u-boot though it hasn't been thoroughly tested.
-Aaron
On Thursday, January 27, 2011 05:06:09 pm Scott Wood wrote:
> On Thu, 27 Jan 2011 16:24:31 -0800
>
> Aaron Williams wrote:
>
n Exp $
* Copyright 2002 SYSGO Real-Time Solutions GmbH
*
+ * (C) Copyright 2011
+ * Aaron Williams, Cavium Networks, Inc.
+ *
+ * Added support for partitions and flash greater than or equal to 4GiB.
+ *
* See file CREDITS for list of people who contributed to this
* project.
*
@@ -174,7 +
Any comments on this? This bug caused me a lot of troube.
-Aaron
On Tuesday, January 25, 2011 02:30:55 pm Aaron Williams wrote:
> In some of my work with the Cavium Octeon 64-bit processor I ran into a
> problem with the min and max macros provided in common.h. The problem
> occurs i
This patch seems to be working fine in my setup. Any comments?
-Aaron
On Thursday, January 27, 2011 05:43:10 pm Aaron Williams wrote:
> I have included my preliminary patch which seems to be working.
> It has not been extensively tested yet. All of the changes were basically
> making
Trying again submitting the patch.
Adds support for NAND flash chips that are 4GiB and larger.
Signed-off-by: Aaron Williams
diff --git a/common/cmd_mtdparts.c b/common/cmd_mtdparts.c
index 5481c88..26d24b0 100644
--- a/common/cmd_mtdparts.c
+++ b/common/cmd_mtdparts.c
@@ -21,6 +21,11
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
I'm still fighting with my mail tool, hopefully this will work.
This patch adds support for NAND flash 4GiB and larger. The changes in
the data structure match those found in the Linux kernel. Most of the
changes involve changing u32s to u64s.
-Aaron
Signed-off-by: Aaron Williams
c
the kernel version.
Signed-off-by: Aaron Williams
include/common.h |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/common.h b/include/common.h
index d8c912d..cf5c076 100644
--- a/include/common.h
+++ b/include/common.h
@@ -180,11 +180,13 @@ typedef void
Are there any PCIE networking cards that are supported? So far I've
tried an Intel card and a Realtek RTL8168 card, but neither is
supported. It looks like the E1000 driver only supports PCI and PCIX
based cards (Linux uses the e1000e card for PCIe cards).
-Aaron
__
On Tue, 1 Feb 2011 13:15:01 -0600
>
> Kumar Gala wrote:
> > We utilize e1000 PCIe cards all the time
>
> Aren't there some versions that work, and some that don't?
>
> -Scott
>
> > - k
> >
> > On Feb 1, 2011, at 1:10 PM, Aaron Williams wro
I too am interested in this. I am running EHCI and have had problems with a
number of USB storage devices, one of which (the SanDisk Cruzer) causes a
crash due to it reporting the maximum LUN as 1. I'm also seeing some
interesting performance issues with ext2 being extremely slow compared to FA
000_read_eeprom
e1000_is_onboard_nvm_eeprom
On Tuesday, February 01, 2011 08:18:27 pm Kumar Gala wrote:
> You may want to look at the following patch that adds support for 0x10d3:
>
> http://patchwork.ozlabs.org/patch/79788/
>
> - k
>
> On Feb 1, 2011, at 3:32 PM,
no hub problems, but have only tried two types. I do recall a
> LUN patch floating around. I was going to try with an uSD card to see if
> it is needed there.
>
> Regards,
> Simon
>
> On Tue, Feb 1, 2011 at 4:03 PM, Aaron Williams <
>
> aaron.willi...@caviumnetworks.c
Disregard my previous email. I'm running into some issues trying to get PCIe
working in u-boot.
-Aaron
On Wednesday, February 02, 2011 03:51:14 pm Aaron Williams wrote:
> Thanks,
>
> I took the patch but it looks like it's unable to read the eeprom. It's
> possible
urce web site without registration :(
I have also been trying to keep up with the GIT patches to u-boot and I don't
think it will be all that difficult to move to the latest version since it
sounds like most of the changes have affected PowerPC and ARM.
-Aaron Williams
__
I just tried it for our Octeon boards and saw a noticeable reduction in size.
Our bootloader shrank from 1107840 to 941600 bytes. Size isn't too big of an
issue for us, though it's nice to see it shrink to under 1MB again.
-Aaron
On Friday, April 15, 2011 08:50:57 AM Shinya Kuribayashi wrote:
Will do. I've been quite busy lately bringing up a 32-core chip and
getting ready for a release but I should have some time now.
I've got some other patches I also need to submit.
-Aaron
On 04/30/2011 12:12 PM, Wolfgang Denk wrote:
> Dear Aaron Williams,
>
> In message
&g
On Tuesday, May 03, 2011 05:31:37 AM Shinya Kuribayashi wrote:
> We need to make sure that all MIPS-based systems don't necessarily use
> CP0 counter/compare registers as time keeping resources. And some MIPS
> variant processors might come with different hardware specs with genuine
> MIPS32 CP0 r
registers require 64-bit addressing so we use assembly
wrappers to do the actual read/writes to those addresses.
-Aaron Williams
On 06/21/2011 07:07 PM, hacklu wrote:
> I have a 64bit cnMips borad.In the mail list archives,it says "uboot is
> 32bit,even in the 64bit cpu."
> bu
Hi all,
I'm working with a Silicon Image U-Boot driver that supports the SIL3124, 3132
and related PCI/PCIe controllers.
So far I have it working with the 3132 except when I try and make use of LBA48
features. I'm not sure what is going on there and was wondering if anyone else
is interested i
Your driver is certainly a lot cleaner than mine... mine started up as a
really hacked up SATA driver made for U-Boot 1.1.1.
I did find a number of problems, however.
I have several suggestions.
1. On many MIPS platforms (not including ours) you need to flush the cache
before write operations
have and a couple of drives. It
looks like it does not support LBA48 mode among other things.
-Aaron Williams
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
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 (51
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
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
On Monday, February 07, 2011 02:26:15 pm Wolfgang Denk wrote:
> Dear Aaron Williams,
>
> In message <201102071402.37099.aaron.willi...@caviumnetworks.com> you wrote:
> > One of our challenges is the fact that the Octeon is a 64-bit multi-core
> > MIPS processor that re
Image 3132 PCIe boards.
-Aaron Williams
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
On Tuesday, February 08, 2011 07:38:44 am Andrew Dyer wrote:
> On Mon, Feb 7, 2011 at 16:58, Scott Wood wrote:
> > On Mon, Jan 31, 2011 at 06:56:48PM -0800, Aaron Williams wrote:
> >> Trying again submitting the patch.
> >>
> >>
On Tuesday, February 08, 2011 03:11:54 pm Aaron Williams wrote:
> On Tuesday, February 08, 2011 07:38:44 am Andrew Dyer wrote:
> > On Mon, Feb 7, 2011 at 16:58, Scott Wood wrote:
> > > On Mon, Jan 31, 2011 at 06:56:48PM -0800, Aaron Williams wrote:
> > >> Try
On Tuesday, February 08, 2011 12:53:27 am Wolfgang Denk wrote:
> Dear Aaron Williams,
>
> In message <201102071524.17440.aaron.willi...@caviumnetworks.com> you wrote:
> > > these. I understand that you are using a 64 bit port of U-Boot?
> >
> > No. We a
On Tuesday, February 08, 2011 11:39:58 pm Wolfgang Denk wrote:
> Dear Aaron Williams,
>
> In message <201102081927.36497.aaron.willi...@caviumnetworks.com> you
> wrote:
>
> ...
>
> > > > memory size to CONFIG_MAX_MEM_MAPPED. This won't work for us.
On Tuesday, February 08, 2011 10:08:12 pm Albert ARIBAUD wrote:
> Hi Aaron,
>
> Le 08/02/2011 22:58, Aaron Williams a écrit :
> > Hi,
> >
> > I'm trying to compile AHCI support but I'm running into a lot of
> > problems. It looks like AHCI is based
I got it working, thanks to the patch. I had to make a few minor patches for
our platform to map pointers to 64-bit physical addresses and a wrapper to
access the PCI BAR address space and it works well.
-Aaron
On Wednesday, February 02, 2011 10:05:52 pm Aaron Williams wrote:
> Disregard
On Thursday, February 10, 2011 07:08:01 am Andrew Dyer wrote:
> On Thu, Feb 10, 2011 at 00:28, Aaron Williams
>
> wrote:
> >> I would suggest to make sure any caching/prefetching stuff is off,
> >> hardware is doing one flash bus access per CPU read/write.
> >>
On Thursday, February 10, 2011 07:24:54 pm Aaron Williams wrote:
> On Thursday, February 10, 2011 07:08:01 am Andrew Dyer wrote:
> > On Thu, Feb 10, 2011 at 00:28, Aaron Williams
> >
> > wrote:
> > >> I would suggest to make sure any caching/prefetching stuff is
On Thursday, February 10, 2011 07:27:12 pm Aaron Williams wrote:
> On Thursday, February 10, 2011 07:24:54 pm Aaron Williams wrote:
> > On Thursday, February 10, 2011 07:08:01 am Andrew Dyer wrote:
> > > On Thu, Feb 10, 2011 at 00:28, Aaron Williams
> > >
> > >
Williams
On Thursday, February 10, 2011 08:05:37 pm Aaron Williams wrote:
> On Thursday, February 10, 2011 07:27:12 pm Aaron Williams wrote:
> > On Thursday, February 10, 2011 07:24:54 pm Aaron Williams wrote:
> > > On Thursday, February 10, 2011 07:08:01 am Andrew Dyer wrote:
>
Hi,
One thing that I have had to do in our Octeon port of U-Boot is to seperate
out the MIPS processors under /arch/mips/cpu much like has been done for ARM
and PowerPC.
I have no way of testing the other MIPS platforms, but I've seperated things
out as follows:
arch/mips/cpu/au1x00
arch/mips
On Friday, February 11, 2011 10:25:46 pm Albert ARIBAUD wrote:
> Le 12/02/2011 01:15, Aaron Williams a écrit :
> > I think I found the problem. The cfi code does not work properly in x8
> > mode.
> >
> > In x8 mode, according to the datasheet, the addresses should be
On Friday, February 11, 2011 11:01:40 pm Albert ARIBAUD wrote:
> Le 12/02/2011 07:42, Aaron Williams a écrit :
> > I've placed the results of the scan below.
> >
> > The problem is that in 8-bit mode the code that scans the CFI does not
> > follow the specificatio
On Friday, February 11, 2011 11:01:40 pm Albert ARIBAUD wrote:
> Le 12/02/2011 07:42, Aaron Williams a écrit :
> > I've placed the results of the scan below.
> >
> > The problem is that in 8-bit mode the code that scans the CFI does not
> > follow the specificatio
On Friday, February 11, 2011 11:51:24 pm Albert ARIBAUD wrote:
> Le 12/02/2011 08:14, Aaron Williams a écrit :
> > On Friday, February 11, 2011 11:01:40 pm Albert ARIBAUD wrote:
> >> Le 12/02/2011 07:42, Aaron Williams a écrit :
> >>> I've placed the results
On Saturday, February 12, 2011 12:49:24 am Albert ARIBAUD wrote:
> Le 12/02/2011 08:57, Aaron Williams a écrit :
> >> The CFI query is normal for a x16 device: byte address 0xAA is word
> >> address 0x55, which is what is expected from a x16 device in x8 mode as
> >&g
One thing that is getting confusing to me is that there seems to be many
different methods for doing I/O.
There's in_xxx/out_xxx, __raw_readx/__raw_writex and readx/writex. What
exactly is the difference between all of these? It looks like the in/out was
added recently and is not present in t
On Saturday, February 12, 2011 02:08:00 am Albert ARIBAUD wrote:
> Le 12/02/2011 09:54, Aaron Williams a écrit :
> > Octeon ebb6300(ram)# mw.b 0x1f40 0xf0
> > Octeon ebb6300(ram)# mw.b 0x1f40 0xf0
> > Octeon ebb6300(ram)# mw.b 0x1f4000AA 0x98
> > Octeon ebb63
1 - 100 of 178 matches
Mail list logo
