Any comments on this patch?
If not, could it please be applied/merged? It fixes a definite
bug on the HWW-1U-1A board.
Cheers,
Kyle Moffett
--
Curious about my work on the Debian powerpcspe port?
I'm keeping a blog here: http://pureperl.blogspot.com/
On Dec 15, 2011, at 21:15, Kyle Moffett wro
--
Curious about my work on the Debian powerpcspe port?
I'm keeping a blog here: http://pureperl.blogspot.com/
>>> This allows systems to pause autoboot with USB keyboard. Tested on
>>> tegra2 seaboard.
>>>
>>> Signed-off-by: Allen Martin
>>
>> Can't you just add "usb reset" to preboot env?
>
On Dec 20, 2011, at 13:20, Mike Frysinger wrote:
> On Tuesday 20 December 2011 12:41:14 Kyle Moffett wrote:
>> +/*
>> + * The U-Boot EHCI driver cannot handle more than 4096*5 bytes in a
>> + * transfer without running itself out of qt_buffers.
>> + */
>> +ss->max_xfer_blk = (40
On Dec 20, 2011, at 13:20, Mike Frysinger wrote:
> On Tuesday 20 December 2011 12:41:12 Kyle Moffett wrote:
>> --- a/fs/fat/fat.c
>> +++ b/fs/fat/fat.c
>>
>> +static disk_partition_t cur_part_info = {
>> +.start = 0,
>> +.size = 0,
>> +.blksz = 512,
>> +.name = "",
>> +.type =
On Dec 20, 2011, at 12:36, Anatolij Gustschin wrote:
> Fix:
> e1000.c: In function 'e1000_read_mac_addr':
> e1000.c:1149:2: warning: dereferencing type-punned pointer
> will break strict-aliasing rules [-Wstrict-aliasing]
>
> e1000.c:1149:2: warning: dereferencing type-punned pointer
> will break
On Dec 20, 2011, at 07:29, Anatolij Gustschin wrote:
> Fix:
> e1000_spi.c: In function 'spi_free_slave':
> e1000_spi.c:115: warning: unused variable 'hw'
> e1000_spi.c: In function 'do_e1000_spi':
> e1000_spi.c:472: warning: 'checksum' may be used uninitialized in this
> function
> e1000_spi.c:472
On Dec 20, 2011, at 10:49, Anatolij Gustschin wrote:
> Fix:
> e1000.c: In function 'e1000_read_mac_addr':
> e1000.c:1149:2: warning: dereferencing type-punned pointer will break
> strict-aliasing rules [-Wstrict-aliasing]
> e1000.c:1149:2: warning: dereferencing type-punned pointer will break
> s
On Dec 19, 2011, at 15:21, Kyle Moffett wrote:
> The U-Boot FAT driver appears to manually check for the existence of
> an MS-DOS partition table, even when CONFIG_DOS_PARTITION is present
> and working.
>
> As a result, it is not possible to use the FAT driver on an ISO9660
> El-Torito boot volum
The U-Boot FAT driver appears to manually check for the existence of
an MS-DOS partition table, even when CONFIG_DOS_PARTITION is present
and working.
As a result, it is not possible to use the FAT driver on an ISO9660
El-Torito boot volume, because it does not have a DOS MBR and does
not pass the
On Dec 17, 2011, at 15:16, Wolfgang Denk wrote:
> Dear Kyle Moffett,
> In message <1324001821-15337-1-git-send-email-kyle.d.moff...@boeing.com> you
> wrote:
>> When using an offboard ethernet chip such as e1000, it is highly likely
>> that the driver has already read a valid MAC address from the o
On Dec 16, 2011, at 14:30, Mike Frysinger wrote:
> On Friday 16 December 2011 13:49:15 Moffett, Kyle D wrote:
>> On Dec 16, 2011, at 00:05, Mike Frysinger wrote:
>>> On Thursday 15 December 2011 22:32:41 Kyle Moffett wrote:
>>>> This new #define is set in c
On Dec 16, 2011, at 00:05, Mike Frysinger wrote:
> On Thursday 15 December 2011 22:32:41 Kyle Moffett wrote:
>> This new #define is set in config_cmd_defaults.h (which is automatically
>> included on every board by "mkconfig"), but this allows boards to elect
>> to omit the "reset" command if neces
On Dec 16, 2011, at 11:07, Mike Frysinger wrote:
> On Thursday 15 December 2011 21:13:55 Kyle Moffett wrote:
>> The version from the kernel is not directly usable as it has code for
>> supporting CONFIG_LOCALVERSION from Kconfig, but the version that was
>> imported is very similar to the one in Li
Ping?
Is this patch acceptable for merging?
Cheers,
Kyle Moffett
On Oct 18, 2011, at 17:16, Moffett, Kyle D wrote:
> Standard Debian powerpc and powerpcspe systems only include hard-float
> libgcc in their native compilers, which causes scary build warnings when
> building U-Boot.
>
Hi,
I was just rebasing and tweaking my board-support patch to send out
again and I noticed that the latest U-Boot master branch does not
build when the config option "CONFIG_CMD_SPI" is enabled:
In file included from exports.c:41
[...]/include/_exports.h: In function 'jumptable_init':
[...]
On Nov 04, 2011, at 12:47, Wolfgang Denk wrote:
> you have been modifyong the E1000 driver lately so I hope you are in
> the best position to help and fix a number of build warnings.
>
> For example when building for the MVBC_P board, I get this:
>
> e1000.c: In function 'e1000_read_mac_addr':
>
On Oct 29, 2011, at 15:33, Wolfgang Denk wrote:
> Commit 114d7fc0 "e1000: Rewrite EEPROM checksum error to give more
> information" failed to initialize the checksum variable which should
> result in random results. Fix that.
>
> Commit 2326a94d caused a ton of "unused variable 'x'" warnings.
> Fi
On Oct 28, 2011, at 01:49, Wolfgang Denk wrote:
> Commit 114d7fc0 "e1000: Rewrite EEPROM checksum error to give more
> information" failed to initialize the checksum variable which should
> result in random results. Fix that.
> [I wonder if that code has _ever_ been tested!!]
>
> I wonder if you
On Oct 20, 2011, at 15:53, Mike Frysinger wrote:
> On Thursday 20 October 2011 15:05:50 Kyle Moffett wrote:
>> --- a/common/cmd_boot.c
>> +++ b/common/cmd_boot.c
>> @@ -71,8 +71,10 @@ U_BOOT_CMD(
>>
>> #endif
>>
>> +#ifdef CONFIG_CMD_RESET
>> U_BOOT_CMD(
>> reset, 1, 0,do_reset,
>>
On Oct 20, 2011, at 15:31, Wolfgang Denk wrote:
> Dear Kyle Moffett,
> In message <1319134031-28503-1-git-send-email-kyle.d.moff...@boeing.com> you
> wrote:
>> All of these errors are various kinds of fatal memory overwrite
>> conditions and so should be handled by panic(). This fixes a bug in
>>
On Oct 20, 2011, at 10:02, Wolfgang Denk wrote:
> Dear "Moffett, Kyle D",
> In message <8b4ac84d-1f22-4326-b75a-fb3cc39a5...@boeing.com> you wrote:
>>
>> Would you accept a patch which makes it possible for a board to not
>> implement a "reset"
On Oct 19, 2011, at 20:15, Mike Frysinger wrote:
> On Wednesday 19 October 2011 18:52:10 Moffett, Kyle D wrote:
>> So U-Boot MUST NOT reset without negotiating, even if the current CPU has
>> crashed, as that will cause the other (possibly perfectly operational) CPU
>> to al
On Oct 19, 2011, at 17:55, Mike Frysinger wrote:
> On Wednesday 19 October 2011 17:05:12 Moffett, Kyle D wrote:
>> On Oct 19, 2011, at 16:35, Wolfgang Denk wrote:
>>> Moffett, Kyle D wrote:
>>>> Since "reset" is basically just like any other U-B
On Oct 19, 2011, at 16:35, Wolfgang Denk wrote:
> Dear "Moffett, Kyle D",
>
> In message <7c2673d7-cc5c-490c-9809-06c9a2071...@boeing.com> you wrote:
>>
>> Since "reset" is basically just like any other U-Boot shell command,
>
> No, it
On Oct 18, 2011, at 23:20, Mike Frysinger wrote:
> On Tuesday 18 October 2011 19:41:23 Kyle Moffett wrote:
>> +int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
>> +{
>> unsigned long val, msr;
>>
>> +/* Allow boards to override the reset */
>> +int err = __board
On Oct 19, 2011, at 09:51, Kumar Gala wrote:
> On Oct 18, 2011, at 10:19 PM, Mike Frysinger wrote:
>> On Tuesday 18 October 2011 19:41:22 Kyle Moffett wrote:
>>> --- a/README
>>> +++ b/README
>>>
>>> - 85xx CPU Options:
>>> + CONFIG_MPC85XX_GENERIC_GPIO
>>> +
>>> + Provide a ge
On Jul 29, 2011, at 17:46, York Sun wrote:
> On Fri, 2011-07-29 at 16:26 -0500, Moffett, Kyle D wrote:
>> On Jul 29, 2011, at 14:46, York Sun wrote:
>>> On Fri, 2011-07-29 at 11:35 -0700, York Sun wrote:
>>>> On Fri, 2011-07-29 at 12:20 -0500, Moffett, Kyle D wrote:
&
On Jul 29, 2011, at 14:46, York Sun wrote:
> On Fri, 2011-07-29 at 11:35 -0700, York Sun wrote:
>> On Fri, 2011-07-29 at 12:20 -0500, Moffett, Kyle D wrote:
>>> On Jul 28, 2011, at 17:41, York Sun wrote:
>>>> I found a problem with the round up. Please try
>>&g
On Jul 28, 2011, at 17:41, York Sun wrote:
> On Mon, 2011-03-14 at 16:35 -0500, Moffett, Kyle D wrote:
>> On Mar 14, 2011, at 16:22, York Sun wrote:
>>> On Wed, 2011-02-23 at 11:35 -0500, Kyle Moffett wrote:
>>>> + * Now divide by 5^12 and track the 32-bit remainde
On Apr 13, 2011, at 16:57, Wolfgang Denk wrote:
> In message <1298479238-22114-1-git-send-email-kyle.d.moff...@boeing.com> you
> wrote:
>> Standard Debian powerpc and powerpcspe systems only include hard-float
>> libgcc in their native compilers, which causes scary build warnings when
>> building
On Apr 13, 2011, at 01:23, Wolfgang Denk wrote:
> In message <0ef7e520-ff4a-435f-af2a-0d47c0951...@boeing.com> you wrote:
>> In particular, those other eeprom drivers simply have a single hardcoded
>> I/O base address that they assume is properly mapped, IE:
>>> struct eth_device dev;
>>> dev.iob
On Apr 12, 2011, at 16:24, Wolfgang Denk wrote:
> In message <1297467482-14864-5-git-send-email-kyle.d.moff...@boeing.com> you
> wrote:
>> For our new board ports, we are programming the EEPROMs attached to our
>> Intel 82571EB controllers from software (using U-Boot and Linux).
>>
>> This code p
On Apr 12, 2011, at 16:17, Wolfgang Denk wrote:
> In message <1297467482-14864-3-git-send-email-kyle.d.moff...@boeing.com> you
> wrote:
>> By allocating the e1000 device structures much earlier, we can easily
>> generate better error messages and siginficantly clean things up.
>>
>> The only user
On Mar 21, 2011, at 18:24, Wolfgang Denk wrote:
> In message you wrote:
>>
>> I apparently cannot rely on the U-Boot *CODE* to understand what the
>> U-Boot *CODING* style is.
>
> You don't have to rely on the code. It's clearly documented.
>
> The README says:
>
> Coding Standards:
>
On Mar 21, 2011, at 17:34, Wolfgang Denk wrote:
> In message you wrote:
>>
>> Just looking at the last ~200 commits (actually 187, because it ignores
>> merges):
>>
>> $ git format-patch -o recent-patches -200 origin/master
>> $ ./checkpatch.pl --no-tree --strict recent-patches/* >checkpatch.log
On Mar 21, 2011, at 16:30, Wolfgang Denk wrote:
> In message <5b9d9c87-c278-4af3-b20c-26ecff6c0...@boeing.com> you wrote:
>>
>>> WARNING: line over 80 characters
>>> #463: FILE: board/exmeritus/hww1u1a/hww1u1a.c:136:
>>> +int do_hww1u1a_test_cpu_a(cmd_tbl_t *cmdtp, int flag, int argc, char *
>>> c
Wolfgang,
Thanks for your detailed reviews!
Once I get these last few style issues resolved, what more do I need to do to
get this merged? I don't really want to spam the list with more nearly
identical copies of these patches unless I'm sure that all the necessary review
items have been take
On Mar 14, 2011, at 16:22, York Sun wrote:
> On Wed, 2011-02-23 at 11:35 -0500, Kyle Moffett wrote:
>> + * Now divide by 5^12 and track the 32-bit remainder, then divide
>> + * by 2*(2^12) using shifts (and updating the remainder).
>> + */
>> +clks_rem = do_div(clks, UL_5pow12);
>>
On Mar 14, 2011, at 16:38, Wolfgang Denk wrote:
> In message <613c8f89-3ce5-4c28-a48e-d5c3e8143...@boeing.com> you wrote:
>>
>> If just *one* of the 2 CPUs triggers the reset then only *some* of
>> the attached hardware will be properly reset due to a hardware
>> errata, and as a result the board
On Mar 14, 2011, at 14:19, York Sun wrote:
> On Wed, 2011-02-23 at 11:35 -0500, Kyle Moffett wrote:
>> The current FreeScale MPC-8xxx DDR SPD interpreter is using full 64-bit
>> integer divide operations to convert between nanoseconds and DDR clock
>> cycles given arbitrary DDR clock frequencies.
>
On Mar 14, 2011, at 15:41, York Sun wrote:
> Kyle,
>
> On Mon, 2011-03-14 at 14:04 -0500, Moffett, Kyle D wrote:
>> On 64-bit this change is basically a no-op, because do_div() is implemented
>> as a literal 64-bit divide operation and the instruction scheduling works
&
On Mar 14, 2011, at 14:59, Wolfgang Denk wrote:
> In message you wrote:
>> My own board needs both processor modules to synchronize resets to allow
>> them to come back up at all, which means that a "reset" may block for an
>> arbitrary amount of time waiting for the other module to cleanly shut d
Hi!
On Mar 13, 2011, at 15:24, Wolfgang Denk wrote:
> In message <1299519462-25320-2-git-send-email-kyle.d.moff...@boeing.com> you
> wrote:
>> In preparation for making system restart use a generic set of hooks for
>> boards and architectures, we define some wrappers and weak stubs.
>>
>> The ne
Hi!
On Mar 08, 2011, at 19:13, Scott McNutt wrote:
> Hi Kyle,
>
> Kyle Moffett wrote:
>> The Nios-II port appears to use no generic hardware capability for
>> performing a CPU reset. Since all of the supported boards use the exact
>> same code to perform a jump-to-flash it goes into __arch_resta
Hi!
On Mar 07, 2011, at 16:55, Graeme Russ wrote:
> On Tue, Mar 8, 2011 at 4:37 AM, Kyle Moffett
> wrote:
>> All of the users of the legacy do_reset() function have been converted
>> to __arch_restart() or __board_restart() as appropriate, so the
>> compatibility calls to do_reset() may be remov
On Mar 07, 2011, at 17:26, Graeme Russ wrote:
> On Tue, Mar 8, 2011 at 9:06 AM, Moffett, Kyle D
> wrote:
>> On Mar 07, 2011, at 16:54, Graeme Russ wrote:
>>> This part does not make much sense - If the CPU is in 'a bad state' then
>>> it will probably be l
Hi!
On Mar 07, 2011, at 16:54, Graeme Russ wrote:
> On Tue, Mar 8, 2011 at 4:37 AM, Kyle Moffett
> wrote:
>> The i386 port has its own reset_cpu() dispatch for its various supported
>> CPU families, so the existing do_reset() function is simply altered to
>> use the new prototype for __arch_rest
On Mar 07, 2011, at 16:40, Mike Frysinger wrote:
> On Monday, March 07, 2011 12:37:22 Kyle Moffett wrote:
>> +__attribute__((__noreturn__))
>> +void emergency_restart(void)
>> +{
>> +__board_emergency_restart();
>> +__arch_emergency_restart();
>> +
>> +/* Fallback to the old do_reset()
On Feb 24, 2011, at 13:41, Wolfgang Denk wrote:
> In message you wrote:
>>
>> Perhaps the default should instead be something like this?
>>
>> __attribute__((__weak__)) int arch_reset(void)
>> {
>> while(1);
>> }
>
> No. Please don;t implement something that does not do what it is
> sup
On Feb 23, 2011, at 14:35, Mike Frysinger wrote:
> On Wednesday, February 23, 2011 14:28:44 Kyle Moffett wrote:
>> +__attribute__((__weak__)) int arch_reset(void)
>> +{
>> +return 0;
>> +}
>
> is there any cpu which wouldnt provide arch_reset() ? i dont think it was
> possible in the past to
On Feb 21, 2011, at 16:14, Wolfgang Denk wrote:
> In message <1298311199-18775-4-git-send-email-kyle.d.moff...@boeing.com> you
> wrote:
>> To ease the implementation of other MPC85xx board ports, several common
>> GPIO helpers are added to .
>
> In which way is this specific to 85xx? Why not mak
On Feb 21, 2011, at 16:03, Wolfgang Denk wrote:
> In message <1298311199-18775-3-git-send-email-kyle.d.moff...@boeing.com> you
> wrote:
>> Use #define constants to enhance readability of DDR2/3 SPD parsing code.
>> Also add the DDR2 type for an SO-RDIMM module to the switch statement.
>>
>> Signe
On Feb 21, 2011, at 15:59, Wolfgang Denk wrote:
> In message <1298311199-18775-2-git-send-email-kyle.d.moff...@boeing.com> you
> wrote:
>> Some board models (such as the submitted P2020-based HWW-1U-1A hardware)
>> need specialized code to run when a reset is requested to ensure proper
>> synchron
On Feb 21, 2011, at 16:56, Wolfgang Denk wrote:
> In message you wrote:
>>
+static inline int gpio_direction_input(unsigned gpio)
+{
+ mpc85xx_gpio_set_in(1U << gpio);
+ return 0;
+}
>>>
>>> Why is this function not void when it cannot return any usefult return
>>> cod
On Feb 21, 2011, at 16:47, Wolfgang Denk wrote:
> In message <1298311199-18775-8-git-send-email-kyle.d.moff...@boeing.com> you
> wrote:
>> The eXMeritus HWW-1U-1A unit is a DO-160-certified 13lb 1U chassis
>> with 3 independent TEMPEST zones. Two independent P2020 computers may
>> be found inside
On Feb 21, 2011, at 16:23, Wolfgang Denk wrote:
> In message <1298311199-18775-6-git-send-email-kyle.d.moff...@boeing.com> you
> wrote:
>> Standard Debian powerpc and powerpcspe systems only include hard-float
>> libgcc in their native compilers, which causes scary build warnings when
>> building
Whoops!
Please ignore this grouping of patches (1-3 of 5), I accidentally specified the
wrong commit range and sent 3 emails before I realized.
I've since resent the correct patch queue.
My apologies!
Cheers,
Kyle Moffett
On Sep 13, 2010, at 11:51, Kyle Moffett wrote:
> To ease the implementa
On Sep 07, 2010, at 18:09, Peter Tyser wrote:
>>> The GPIO functions above aren't hww1u1a specific. What about adding
>>> generic 85xx GPIO functions so others can use them too?
>>
>> I can do that. Do you have any particular place you recommend I put them?
>
> The 2 places that jump to mind ar
Peter,
I've got one more followup question as I work through these updates:
On Sep 03, 2010, at 00:00, Peter Tyser wrote:
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -2499,6 +2499,10 @@ P2020DS_36BIT_config \
>> P2020DS_config: unconfig
>> @$(MKCONFIG) -t $(@:_config=) P2020DS ppc
On Sep 07, 2010, at 17:40, Peter Tyser wrote:
> Hi Kyle,
>> The latest u-boot.git still seems to have the P2020DS lines that I
>> referenced in "Makefile", and it has no references at all to "P2020DS" in
>> the "boards.cfg" file.
>
> It looks like the top-level Makefile is still required for boa
60 matches
Mail list logo
