In message <[EMAIL PROTECTED]> you wrote:
>
> In the past I had my own flag I called CONFIG_FORCE_FLASH SIZE.
> Suppose I will come with a way to cripple the CFI to work as it should
> in the latest version, would you like such a feature integrated in the
> u-boot for all?
To be honest - my immed
Hi all,
I'm just reading through the MPC8349EA-MDS-PB board
start-up code to understand it, eg. the initial SRAM
in data-cache trick.
In the BAT setups in include/configs/MPC8349EMDS.h,
some of the CFG_IBAT settings include the bit setting
BATL_MEMCOHERENCE, indicating that those BAT entries
are
Marc Leeman wrote:
>> I presume the problem is that the /aliases node doesn't exist in your
>> tree (original kernel .dts source, and thus the .dtb blob). One simple
>> solution would be to create the /aliases node if it doesn't exist, just
>> like we create the /chosen node if it doesn't exist
Hi Liberty,
> I believe I will prefare crippling the CFI over Crippling the flash
> eeprom as I believe it will be easier on our production team... But I
> will have to play with it some more...
If I understand your earlier posts, you are using a CFI
flash, and then 'hiding' half or more of that
> I presume the problem is that the /aliases node doesn't exist in your
> tree (original kernel .dts source, and thus the .dtb blob). One simple
> solution would be to create the /aliases node if it doesn't exist, just
> like we create the /chosen node if it doesn't exist.
Yep, that's how I go
Both of you (Wolfgang and Brent) Provided me with some new angle to think of...
I believe I will prefare crippling the CFI over Crippling the flash
eeprom as I believe it will be easier on our production team... But I
will have to play with it some more...
In the past I had my own flag I called C
Since fdt_node_offset_by_compatible() was converted to the new
fdt_next_node() iterator, a chunk of initialization code became
redundant, but was not removed by oversight. This patch cleans it up.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
---
libfdt/fdt_ro.c | 12 +---
1 files ch
Currently the CHECK_HEADER() macro is defined local to fdt_ro.c.
However, there are a handful of functions (fdt_move, rw_check_header,
fdt_open_into) from other files which could also use it (currently
they open-code something more-or-less identical). Therefore, this
patch moves CHECK_HEADER() to
For the record, publishing two more patches of libfdt from the dtc
master repository. I will apply them to the u-boot-fdt repository in
preparation for the next merge window.
Best regards,
gvb
-
This SF.net email is sponsor
Marian Balakowicz wrote:
> From: Bartlomiej Sieka <[EMAIL PROTECTED]>
>
> Signed-off-by: Bartlomiej Sieka <[EMAIL PROTECTED]>
> ---
>
> Makefile |3 +++
> include/libfdt_env.h |4
> libfdt/fdt.c |4
> libfdt/fdt_ro.c |4
> libfdt/fdt_rw
Brent Cook wrote:
> On Friday 29 February 2008 15:36:59 eran liberty wrote:
>
>> Any attempt to access these non existing address will lead to bus
>> fault exactly as if the flash was a 32Mb (which in many sense it is).
>> So, again, it is important for me to tell u-boot "go ahaed and use
>> CFI
Marc Leeman wrote:
> When booting an 8347 processor, the MAC addresses (ethaddr and eth1addr)
> don't seem to get passed anymore.
>
> I modified my config to include CONFIG_HAS_ETH0 and CONFIG_HAS_ETH1 and
> I am entering the code in fdt_fixup_ethernet (common/fdt_support.c) but
> get stuck at nod
Marian Balakowicz wrote:
> From: David Gibson <[EMAIL PROTECTED]>
>
> This patch adds an fdt_next_node() function which can be used to
> iterate through nodes of the tree while keeping track of depth. This
> function is used to simplify the iteration code in a lot of other
> functions, and is als
Hi again,
On Sat, Mar 01, 2008 at 05:09:44PM +0100, Wolfgang Wegner wrote:
[...]
> Everything went fine until reaching the final stage of linking, there
> I get:
> powerpc-linux-ld: u-boot: section `.bootpg' can't be allocated in segment 1
> powerpc-linux-ld: final link failed: Bad value
[...]
se
Hi all,
first of all, sorry for posting from the "wrong" account, but I do
follow the answers from the subscribed account.
I just got my "new" Ocotoea board and wanted to compile U-Boot for
it, so I grabbed binutils-2.18 and gcc-4.2.2 and started building...
Everything went fine until reaching t
This patch fix the checking of cluster size in fat32 filesystem.
The current implementation was broken.
Signed-off-by: michael <[EMAIL PROTECTED]>
---
fs/fat/fat.c |8
include/fat.h |3 ++-
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/fs/fat/fat.c b/fs/fat/f
In message <[EMAIL PROTECTED]> you wrote:
>
> By mistake today i entered "cp.b ox80 0x2c00 0x1a6c0" at the
> prompt
> Kindly look at this error >| "ox80" and not "0x80"
> as it shld be
>
> #> cp.b ox80 0x2c00 0x1a6c0
> Copy to Flash... done
>
> and now flash
Hi,
i am working a customized variant of arm versatile board. I have
spansion s29gl18n 16MB flash on board.
i am using Uboot-1.3.1 Version and CFI flash driver to work on flash
related commands
our board reset vector points to 0x2c00
By mistake today i entered "cp.b ox80 0x2c00 0x1
The 405EZ only supports 512 bytes of rx-/tx-fifo EMAC sizes. But
currently 4k/2k is configured. This patch fixes this issue.
Thanks to Thomas Kindler <[EMAIL PROTECTED]> for pointing this out.
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
---
cpu/ppc4xx/4xx_enet.c |5 +++--
include/ppc4xx_
> > Looks like something that was introduced between 2.6.24 and 2.6.25-rc3;
> > does this mean that u-boot-1.3.2 will not be able to boot 834x
> > processors (networking that is) with kernels before 2.6.25?
>
> No, it just means you need the newer device tree.
Of course, but since the device tree
On Friday 29 February 2008, Maupin, Chase wrote:
> > implementation. Is this
> > > problem in the 1.2.0 version of u-boot?
> >
> > No, I don't think so. This thread was related to problem with the
> > rewrite of the U-Boot NAND subsystem. The current implementation
> > should handle writing images
Hi Markus,
On Saturday 01 March 2008, Markus Klotzbücher wrote:
> >> Glancing over the patch I fail to see what hardware and configuration
> >> you are using for your development. Can you enlighten us on this?
> >
> > Ah, good point. This driver was developed for the Philips ISP156x.
> > The conf
Hi Marcel,
Marcel Moolenaar <[EMAIL PROTECTED]> writes:
> On Feb 29, 2008, at 9:24 AM, Detlev Zundel wrote:
>> Glancing over the patch I fail to see what hardware and configuration
>> you are using for your development. Can you enlighten us on this?
>
> Ah, good point. This driver was developed
Hi Marcel, Detlev,
I somehow missed this mail, thanks for following up!
Detlev Zundel <[EMAIL PROTECTED]> writes:
>> Juniper Networks wrote a driver for the EHCI UCB HC and I'd like to
>> contribute that back if there's interest. Besides a new piece of code,
>> this also changes some of the comm
24 matches
Mail list logo
