Adding support for OMAP4430 SDP board based on the TI OMAP4430 SOC.
TI OMAP4430 is an SOC based on ARM Cortex-A9 cpu.
OMAP4430 SDP is a reference board based on OMAP4430.
This patch adds minimum support for booting the board.
OMAP4430 SDP does not support XIP. U-boot is loaded to SDRAM with the h
Renaming the cpu arm_cortexa8 to armv7 so that we can share code between
cortexa8
and cortexa9.
Both A8 and A9 belong to the armv7 architecture.
The differences between cortexa8 and cortexa9 do not impact u-boot
initialization.
We can have common code for both the CPUs.
Signed-off-by: Aneesh V
The following series implements support for TI OMAP4430 SDP based TI OMAP4430.
TI OMAP4430 is a Cortex-A9 based SOC from TI. OMAP4430 is a refrence board
based on OMAP4430.
The first patch in this series renames the cpu arm_cortexa8 to armv7 so that
the existing cortexa8 code can be shared with c
Dear Wolfgang,
Since Scott is very busy, I'd be willing to take over the maintenance of
nios2 in u-boot.
I've been doing nios development for ten years. We work closely with
Altera. I maintain nios2-linux, nios2-dev mailing list, the nios2 git
repos and nios wiki, which is sponsored by Altera.
Dear Wolfgang Denk,
On 25 May 2010 05:50, Wolfgang Denk wrote:
> Dear Minkyu Kang,
>
> In message you
> wrote:
>>
>> >> I will post two boards "aquila" and "goni". (s5pc110 soc)
>> >> These board are very similar and can detect the board by gpio. (at
>> >> runtime)
>> >> So, I want to support
Dear Minkyu Kang,
In message you
wrote:
>
> >> I will post two boards "aquila" and "goni". (s5pc110 soc)
> >> These board are very similar and can detect the board by gpio. (at runtime)
> >> So, I want to support these two boards at same board file.
> >> Thus, I will use same binary at two boar
Dear Delio Brignoli,
In message <15866eae-624b-4850-b10f-78ab99e3a...@audioscience.com> you wrote:
>
> On 21/05/2010, at 15:13, Wolfgang Denk wrote:
> >> + *rxp = buf_reg_val & 0xFF;
> >> + rxp++;
> >> + }
> >
> > Please ch
On Mon, May 24, 2010 at 3:09 PM, Kumar Gala wrote:
> We have several boards that use the same ICS307 CLK chip to drive the
> System clock and DDR clock. Move the code into a common location so we
> share it.
>
> Convert the P2020DS board as the first to use the new common ICS307
> code.
>
> Signe
The device tree (fdt) must always exist in within the bootmap (usually the
first 16MB of RAM). If it doesn't, then boot_relocate_fdt() will allocate an
LMB region in the bootmap and copy the fdt into that region. It will also
increase the size of the fdt.
If the fdt is already in the bootmap, th
We have several boards that use the same ICS307 CLK chip to drive the
System clock and DDR clock. Move the code into a common location so we
share it.
Convert the P2020DS board as the first to use the new common ICS307
code.
Signed-off-by: Kumar Gala
---
* unsigned char -> u8
* remove 1 +
boa
On Mon, May 24, 2010 at 1:57 PM, Kumar Gala wrote:
> What in the world does 'const' get me in C.
Actually, scrap that. A const function tells the compiler that, for a
given set of parameters, the returned value is always the same, so the
compiler will eliminate redundant calls to the function.
On May 24, 2010, at 9:52 AM, Timur Tabi wrote:
> On Sat, May 22, 2010 at 5:36 PM, Kumar Gala wrote:
>
>> +static unsigned long
>> +ics307_clk_freq(unsigned char cw0, unsigned char cw1, unsigned char cw2)
>
> You forgot to change these to u8
Oops, thought that was fixed.
> Also, you can decla
The various boards that have PIXIS FPGAs have slightly different
register definitions, however there is some common functionality (like
reset, ICS307 clk control, etc) that can be shared.
The struct definition exists for MPC8536DS, MPC8544DS, MPC8572DS,
MPC8610HPCD, and MPC8641HPCN boards.
Also f
On May 24, 2010, at 1:19 PM, Timur Tabi wrote:
> On Mon, May 24, 2010 at 1:12 PM, Kumar Gala wrote:
>
+} pixis_t __attribute__ ((aligned(1)));
>>>
>>> What's the aligned(1) for?
>>
>> Asked Timur, I copied it from the ngpixis.h header
>
> Hmmm... I think I might have meant __packed__ i
On Mon, May 24, 2010 at 1:12 PM, Kumar Gala wrote:
>>> +} pixis_t __attribute__ ((aligned(1)));
>>
>> What's the aligned(1) for?
>
> Asked Timur, I copied it from the ngpixis.h header
Hmmm... I think I might have meant __packed__ instead of aligned(1).
--
Timur Tabi
Linux kernel developer at
On May 24, 2010, at 11:23 AM, Scott Wood wrote:
> On Sat, May 22, 2010 at 05:33:31PM -0500, Kumar Gala wrote:
>> +/* PIXIS register set. */
>> +#if defined(CONFIG_MPC8536DS)
>> +typedef struct pixis {
>> +u8 id;
>> +u8 ver;
>> +u8 pver;
>> +u8 csr;
>> +u8 rst;
>> +u8 rst2;
Apply for 3% oan and send name. address, amount, duration, tel No
This message was sent using IMP, the Internet Messaging Program.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://li
On Sat, May 22, 2010 at 05:33:31PM -0500, Kumar Gala wrote:
> +/* PIXIS register set. */
> +#if defined(CONFIG_MPC8536DS)
> +typedef struct pixis {
> + u8 id;
> + u8 ver;
> + u8 pver;
> + u8 csr;
> + u8 rst;
> + u8 rst2;
> + u8 aux1;
> + u8 spd;
> + u8 aux2;
> +
Apply for 3% oan and send name. address, amount, duration, tel No
This message was sent using IMP, the Internet Messaging Program.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://li
On Sat, May 22, 2010 at 5:36 PM, Kumar Gala wrote:
> +static unsigned long
> +ics307_clk_freq(unsigned char cw0, unsigned char cw1, unsigned char cw2)
You forgot to change these to u8
Also, you can declare this function as "const". You could just use
the version of this function that I posted,
Move serdes init until after we are in ram so we can keep track of a
global static protocal map for the particular serdes config we are in.
This makes is_serdes_configured() much simplier and not constantly
reading registers to determine if a given device is enabled based on the
protocol.
Signed-o
Add a sort of batch mode to fw_setenv, allowing to set
multiple variables in one shot, without updating the flash after
each set as now. It is added the possibility to pass
a config file with a list of pairs to be set,
separated by a TAB character.
Signed-off-by: Stefano Babic
---
tools/env/fw_
Hi Graeme,
> One quick question - Since I am currently the only x86 developer, how do
> you want to handle the SOB + Ack'd for x86 patches? I feel that to date be
> applying my patches you have implied your own Ack'd By. Should I wait for
> you (or somebody else) to Ack them before I apply them to
Peter Tyser wrote:
> Hi Stefano,
>
Hi Peter,
> It'd be nice to document the new functionality you're adding. Any
> interest in adding a runtime usage message? It seems like that'd be
> pretty useful. At a minimum it would be nice to update the description
> in fw_env_main.c to reflect the cha
24 matches
Mail list logo
