Using a ROM burned in MAC address is the normal way devices that have
this ability will store their MAC. It's normal operation and a warning
message isn't appropriate. Make it a debug message, as it is in
non-DM_ETH code paths that do this.
Signed-off-by: Trent Piepho
---
net/eth-uc
oblem if value overflows.
For instance, if one were to add 0x as a code to mean the clock
output should be turned off.
Cc: Joe Hershberger
Cc: Janine Hagemann
Cc: Grygorii Strashko
Signed-off-by: Trent Piepho
---
drivers/net/phy/ti.c | 16 +---
1 file changed, 5 insertions(+
seems obvious one is meant to use
ofnode_read_s32_default() with signed values.
Cc: Simon Glass
Signed-off-by: Trent Piepho
---
drivers/core/ofnode.c | 2 +-
include/dm/ofnode.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/core/ofnode.c b/drivers/core/ofn
r
Cc: Janine Hagemann
Cc: Grygorii Strashko
Signed-off-by: Trent Piepho
---
drivers/net/phy/ti.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/phy/ti.c b/drivers/net/phy/ti.c
index 6db6edd0d0..33f5687e0e 100644
--- a/drivers/net/phy/ti.c
+++ b/drivers/net/phy
These are standard across gigabit phys. These mostly extend the
auto-negotiation information with gigabit fields.
Signed-off-by: Trent Piepho
---
cmd/mii.c | 34 +-
1 file changed, 29 insertions(+), 5 deletions(-)
diff --git a/cmd/mii.c b/cmd/mii.c
index
t use the field.
Change reg > max+1 into reg >= max, which doesn't fail if max+1 could
overflow, besides just making more sense.
Signed-off-by: Trent Piepho
---
cmd/mii.c | 154 --
1 file changed, 69 insertions(+), 85 dele
On Thu, 2019-05-09 at 08:20 +0200, Anatolij Gustschin wrote:
> On Wed, 8 May 2019 23:30:01 +
> Trent Piepho tpie...@impinj.com wrote:
> ...
> > diff --git a/board/wandboard/wandboard.c
> > b/board/wandboard/wandboard.c
> > index 69fbc8b690..9d7a94ff9d 10064
h
Cc: Priyanka Jain
Cc: Heiko Schocher
Signed-off-by: Trent Piepho
---
Changes from v1:
Added patch in series to fix wandboard build issue
Enable settings if SPL is enabled, as SPL will not use DM_I2C
drivers/i2c/Kconfig | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --
they do not control the bus
speed. Otherwise it is quite easy to mistakenly believe they are used
to set the bus speed.
Cc: Heiko Schocher
Cc: Anatolij Gustschin
Signed-off-by: Trent Piepho
---
board/wandboard/wandboard.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions
On Thu, 2019-05-02 at 07:23 +0200, Heiko Schocher wrote:
> Am 30.04.2019 um 18:04 schrieb Trent Piepho:
> > On Tue, 2019-04-30 at 06:34 +0200, Heiko Schocher wrote:
> > > Am 16.04.2019 um 00:02 schrieb Trent Piepho:
> > > > This is an old driver that supports bot
On Thu, 2019-05-02 at 08:11 +0200, Anatolij Gustschin wrote:
> Hi Heiko,
>
> On Thu, 2 May 2019 07:39:06 +0200
> Heiko Schocher h...@denx.de wrote:
> ...
> >
> > @Anatolij: Is this code needed anymore, as board is moved to DM ?
>
> ...
> > dm_i2c_probe should initialize the i2c bus completly, al
On Tue, 2019-04-30 at 09:20 +0200, Heiko Schocher wrote:
> > Am 12.04.2019 um 21:19 schrieb Trent Piepho:
> > > These options only apply when not using DM_I2C. When using device
> > > trees, the dt will enable and control the speeds of the I2C
> > > controller(s
ds in a row, as
it's a lot more invasive and obviously no one has every wanted them
since they've never worked. It didn't seem like the extra complexity
was justified to support something no one uses.
Cc: Nandor Han
Cc: Heiko Schocher
Cc: Stefano Babic
Cc: Fabio Estevam
Cc:
boards.
Cc: Nandor Han
Cc: Heiko Schocher
Cc: Stefano Babic
Cc: Fabio Estevam
Cc: Breno Matheus Lima
Signed-off-by: Trent Piepho
---
Changes from v1:
None, re-sending as base64 to avoid Microsoft email mangling.
drivers/i2c/mxc_i2c.c | 34 ++
1 file changed
On Tue, 2019-04-30 at 06:34 +0200, Heiko Schocher wrote:
> Hello Trent,
>
> Am 16.04.2019 um 00:02 schrieb Trent Piepho:
> > This is an old driver that supports both device mapped and non-mapped
> > mode, and covers a wide range of hardware. It's hard to change wi
boards.
Cc: Nandor Han
Cc: Heiko Schocher
Cc: Stefano Babic
Cc: Fabio Estevam
Cc: Breno Matheus Lima
Signed-off-by: Trent Piepho
---
drivers/i2c/mxc_i2c.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c
index
ds in a row, as
it's a lot more invasive and obviously no one has every wanted them
since they've never worked. It didn't seem like the extra complexity
was justified to support something no one uses.
Cc: Nandor Han
Cc: Heiko Schocher
Cc: Stefano Babic
Cc: Fabio Estevam
controllers and setting the speed
when really it's doing nothing.
Cc: Sriram Dash
Cc: Priyanka Jain
Cc: Heiko Schocher
Signed-off-by: Trent Piepho
---
drivers/i2c/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
The code that sets a regulator by looking up the voltage in a table had
an off by one error. vsel_mask is a bitmask, not the number of table
entries, so a vsel_mask value of 0x7 indicates there are 8, not 7,
entries in the table.
Cc: Peng Fan
Cc: Jaehoon Chung
Signed-off-by: Trent Piepho
as if it's some kind of generic MMC configuration option.
Cc: Marcel Ziswiler
Cc: Simon Glass
Cc: Jaehoon Chung
Cc: Tom Warren
Signed-off-by: Trent Piepho
---
drivers/mmc/Kconfig | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/mmc/Kconfi
It looks like a rebase mistake in the original commit that added it, as
it would behaved as expected if just moved up a bit in the file.
Cc: Peng Fan
Cc: Mario Six
Cc: Jaehoon Chung
Signed-off-by: Trent Piepho
---
drivers/mmc/Kconfig | 12 ++--
1 file changed, 6 insertions(+), 6 del
On Thu, 2019-03-28 at 03:42 +0100, Marek Vasut wrote:
> On 3/27/19 9:43 PM, Trent Piepho wrote:
> > I didn't see HS400 working on my IMX7d, even thought it appears it
> > should be supported.
> >
> > Alternatively, there is a property that can be added to the devic
the flushed region by subtracting the former from the
latter.
Cc: Tom Rini
Cc: Simon Glass
Cc: Bryan O'Donoghue
Signed-off-by: Trent Piepho
---
common/bootm.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/common/bootm.c b/common/bootm.c
index 8bf84ebcb7..8af8e
I didn't see HS400 working on my IMX7d, even thought it appears it
should be supported.
The problem appears to be when this bit of code in fsl_esdhc.c, which
dates to a patch "mmc: fsl_esdhc: support SDR104 and HS200":
static struct esdhc_soc_data usdhc_imx7d_data = {
.flags = ESDHC_FLA
On Wed, 2018-09-05 at 06:57 -0500, Adam Ford wrote:
> On Wed, Sep 5, 2018 at 3:46 AM Alex Kiernan wrote:
> >
> > On Tue, Sep 4, 2018 at 3:54 PM Andy Shevchenko
> > wrote:
> > >
> > > On Tue, Sep 4, 2018 at 5:50 PM Andy Shevchenko
> > > wrote:
> > > >
> > > > On Tue, Sep 4, 2018 at 5:00 PM Tom
On Mon, 2018-07-16 at 23:56 +, Henry Beberman wrote:
> >
> > >
> > > I need to revise the commit message for this patch. The script is not
> > > fixed
> >
> > to the first partition of the selected MMC, it scans the disk for partitions
> > marked bootable, then checks each one of those unti
On Tue, 2018-07-17 at 01:41 +, Henry Beberman wrote:
> > -Original Message-
> > From: Trent Piepho
> > Sent: Monday, July 16, 2018 11:22 AM
> > To: Henry Beberman ; u-
> > b...@lists.denx.de
> > Cc: fabio.este...@nxp.com; adrian.alo...@nxp.com
&g
On Mon, 2018-07-16 at 22:28 +, Henry Beberman wrote:
> Hi Trent,
>
> > -Original Message-
> > From: Trent Piepho
> > Sent: Monday, July 16, 2018 10:17 AM
> > To: Henry Beberman ; u-
> > b...@lists.denx.de
> > Cc: tr...@konsulko.com; fabi
On Sat, 2018-07-14 at 00:11 +, Henry Beberman wrote:
> From: Henry Beberman
>
> This patch adds a new bootable configuration for Windows 10 IoT Core on
> the i.MX7 Dual Sabre board.
>
> It enables SPL on the i.MX7 Sabre in order to support the FIT load of
> OP-TEE and U-Boot proper.
>
> di
On Sat, 2018-07-14 at 00:11 +, Henry Beberman wrote:
> From: Henry Beberman
>
> This patch is part of the i.MX Windows 10 IoT Core boot flow.
>
> It adds a modified linker script for SPL to keep all segments in
> on-chip ram. This is to harden the device against potential leaks of
> device s
On Sat, 2018-07-14 at 00:11 +, Henry Beberman wrote:
> From: Henry Beberman
>
> This patch enables i.MX platforms to easily add a boot script to their
> U-Boot Proper environment to automatically load and execute an EFI
> firmware from the first FAT partition of an MMC device.
Is there a rea
On Wed, 2018-07-11 at 08:56 -0500, Jason Rush wrote:
> On 7/11/2018 8:48 AM, Marek Vasut wrote:
> > On 07/11/2018 03:49 PM, Jason Rush wrote:
> > >
> > > My mistake. I did disable the dcache after scrubbing too. The
> > > code is almost identical to the Arria10 code where after
> > > scrubbing i
On Fri, 2018-06-22 at 11:09 +0200, Stefan Agner wrote:
> On 31.05.2018 20:13, Trent Piepho wrote:
> > This command should be supported for PSCI 1.0. Current code results in
> > this message from the kernel: "PSCIv65535.65535 detected in firmware."
> >
> > Th
On Mon, 2018-06-18 at 06:57 +0300, Baruch Siach wrote:
> Since commit f916757300 (imx: Create distinct pre-processed mkimage
> config files), *.cfgtmp files are no longer generated. There is no need
> to remove them on the 'clean' target anymore.
>
> Remove also the .gitignore glob.
I didn't thin
On Thu, 2018-06-14 at 10:53 +, u-boot-requ...@lists.denx.de wrote:
> Message: 52
> Date: Thu, 14 Jun 2018 11:48:48 +0200
> From: Janine Hagemann
> To: albert.u.b...@aribaud.net, s...@chromium.org,
> philipp.toms...@theobroma-systems.com, w.ego...@phytec.de,
> joe.hershber...@ni.com
This can be used for device register access from board code.
This allows access to capabilities in the RTC chip not abstracted in
U-Boot's RTC class. E.g., device NVRAM or a tamper detection circuit.
Cc: Klaus Goger
Cc: Philipp Tomsich
Cc: Simon Glass
Signed-off-by: Trent P
ak
anything, as the incorrect version and correct version are both >= 1.0,
but as soon as a check for > 1.0 goes in it will fail.
CC: Anson Huang
Cc: Fabio Estevam
Cc: Peng Fan
Cc: Stefano Babic
Signed-off-by: Trent Piepho
---
arch/arm/mach-imx/mx7/psci.S | 10 ++
1 file changed, 1
Ping. Been a while. 2018.05 is out.
On Thu, 2018-04-26 at 03:22 -0300, Fabio Estevam wrote:
> On Wed, Apr 25, 2018 at 2:06 PM, Trent Piepho
> wrote:
> > The PFUZE3000 uses registers addresses up to 0xff.
> >
> > The DM pfuze100 driver supports both pfuze100 and pfuze30
On Wed, 2018-05-09 at 01:13 +, Peng Fan wrote:
> > +0800, Anson Huang wrote:
> > > > > Add i.MX7 PSCI system reset support, linux kernel now can use "reboot"
> > > > > command to reset system.
> > > >
> > > >
> > > > > +__secure void imx_system_reset(void) {
> > > > > + writew(1 << 2, WDO
On Tue, 2018-05-08 at 05:29 +, Peng Fan wrote:
> > -Original Message-
> > From: Trent Piepho [mailto:tpie...@impinj.com]
> > Sent: 2018年5月8日 6:07
> > To: christian.gmei...@gmail.com; Peng Fan ; Anson
> > Huang ; u-boot@lists.denx.de;
> > albert.u.b..
On Thu, 2018-01-04 at 17:03 +0800, Anson Huang wrote:
> Add i.MX7 PSCI system reset support, linux
> kernel now can use "reboot" command to reset
> system.
> +__secure void imx_system_reset(void)
> +{
> + writew(1 << 2, WDOG1_BASE_ADDR);
> +}
This does not work properly on our board.
Due to
3000_" prefixed enumerations and the
pfuze100 enumeration value PFUZE100_NUM_OF_REGS.
Cc: Peng Fan
Cc: Jaehoon Chung
Cc: Stefano Babic
Cc: Fabio Estevam
Signed-off-by: Trent Piepho
---
drivers/power/pmic/pfuze100.c | 3 ++-
drivers/power/pmic/pmic_pfuze3000.c | 2 +-
inc
fixed the build bug referenced in b5b0e4e3 ("imximage:
Remove failure when no IVT offset is found").
Cc: Breno Lima
Cc: Thomas Petazzoni
Cc: Fabio Estevam
Signed-off-by: Trent Piepho
---
arch/arm/mach-imx/Makefile | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-
On Fri, 2018-03-09 at 08:25 -0300, Fabio Estevam wrote:
> From: Fabio Estevam
>
> Sometimes imximage throws the following error:
>
> CFGSboard/freescale/vf610twr/imximage.cfg.cfgtmp
> CFGSboard/freescale/vf610twr/imximage.cfg.cfgtmp
> MKIMAGE u-boot-dtb.imx
> Error: No BOOT_FROM ta
On Wed, 2016-01-27 at 21:13 +0800, Chin Liang See wrote:
> On Wed, 2016-01-27 at 00:01 +0000, Trent Piepho wrote:
> > On Fri, 2015-11-27 at 15:22 +0800, Chin Liang See wrote:
> > > Enable SDMMC calibration to determine the best setting for
> > > drvsel and smplsel. Calib
On Fri, 2015-11-27 at 15:22 +0800, Chin Liang See wrote:
> Enable SDMMC calibration to determine the best setting for
> drvsel and smplsel. Calibration will be triggered if the
> drvsel and smplsel node are not available in DTS.
We have a Cyclone V based board and on the latest revision the SD car
On Fri, May 3, 2013 at 5:08 PM, Marek Vasut wrote:
> > On 4/25/2013 6:13 PM, Marek Vasut wrote:
> > > I didn't really track the thread and I'm plenty busy, besides I had
> quite
> > > a clash with Trent in another thread, sorry about me being plenty
> > > unpleasant. Anyway, can you please sum wh
On Fri, Apr 19, 2013 at 6:03 PM, Paul B. Henson wrote:
> On 4/11/2013 4:25 PM, Trent Piepho wrote:
>>
>> Maybe it would make more sense for mxsboot to write two files? One
>> with the FCBs and one with everything else?
>
> Hmm, possibly; I guess that would be conce
On Sat, Apr 13, 2013 at 7:42 AM, Marek Vasut wrote:
> Dear Paul B. Henson,
>
>> Let me just preface this reply with the disclaimer that I'm fairly new
>> to embedded development, and it sounds like you know a lot more about
>> what you're talking about than I do ;).
>
> [...]
>
> I'm not reading t
On Thu, Apr 11, 2013 at 11:33 AM, Paul B. Henson wrote:
> On 4/11/2013 5:03 AM, Trent Piepho wrote:
>> What one should actually do to flash these blocks is write 2048 bytes
>> in raw mode.
>
>
> I guess that would only work if whatever reading the blocks also read them
>
>> I don't think the image u-boot mxsboot generates includes any OOB
>> data. For me, it made an image which is *exactly* 24 blocks of 128
>> kiB each. If the FCB blocks had OOB data then there would need to
>> be some multiple of 64 OBB bytes in the image (16 kiB I would think).
>> I think maybe
On Apr 5, 2013 9:28 PM, "Paul B. Henson" wrote:
>
> On 4/4/2013 3:09 AM, Trent Piepho wrote:
>
>> It's something to do with the way u-boot writes to nand. If I write
>> with nandwrite it doesn't happen, nandtest doesn't find any bad
>
>
On Mon, Mar 18, 2013 at 5:50 PM, Paul B. Henson wrote:
> I'm prototyping a project that's going to need to boot linux from NAND on a
> mx28evk board.
>
> I was able to successfully use the u-boot mxsboot utility to generate a nand
> image and burn it, then boot from it. I noticed one anomaly thoug
On Sun, 16 Aug 2009, Wolfgang Denk wrote:
> > ...
> > > I change this to:
> > >
> > > *(.text)
> > > . = ALIGN(16);
> > > *(.eh_frame)
> > > *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*)))
> >
> > Unfortunately it turns out that this breaks some older tool chains.
> > For example, using ELDK 3.1 (binu
On Wed, 18 Feb 2009, Wolfgang Denk wrote:
> He. Of course I can only ask to provide patch that, to the best of
> Trent's experience, is supposed to fix the problems. I am aware
> thatthere is a chance that it will not work on some boards, but then
> it's up to the board maintainers to co
On Sat, 31 Jan 2009, Wolfgang Denk wrote:
> In message you wrote:
> > > so, what's the status of this patch? I've seen this fail on 83xx.
> > > Most of these types of patches that fix the newer gcc's behaviour have
> > > been dropped, one of which even did sorting on name and alignment:
> > >
> >
On Wed, 21 Jan 2009, Kim Phillips wrote:
> On Wed, 7 Jan 2009 18:29:54 -0500
>> This addresses the problem described here:
>>
>> http://lists.denx.de/pipermail/u-boot/2008-December/045029.html
>>
>> This changes the link scripts of several of the mpcXXX CPUs to include
>> everything from '.rodata'.
LCRR_CLKDIV.
Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
Acked-by: Kumar Gala <[EMAIL PROTECTED]>
Acked-by: Jon Loeliger <[EMAIL PROTECTED]>
---
board/freescale/mpc8540ads/mpc8540ads.c |2 +-
board/freescale/mpc8541cds/mpc8541cds.c |2 +-
board/freescale/mpc8548cds/m
will print out the local bus frequency
from sysinfo, like the other frequencies, instead of calculating it on the
spot.
Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
Acked-by: Kumar Gala <[EMAIL PROTECTED]>
Acked-by: Jon Loeliger <[EMAIL PROTECTED]>
---
cpu/mpc85xx/c
PC86xx, I've used "fsl,elbc" which is used by some of the 86xx systems
and is also looked for by the Linux code. On MPC8641, I've also used
"fsl,mpc8641-localbus" as it is also commonly used in dts files, some of
which don't use "fsl,elbc" or any other acc
-by: Trent Piepho <[EMAIL PROTECTED]>
Acked-by: Kumar Gala <[EMAIL PROTECTED]>
Acked-by: Jon Loeliger <[EMAIL PROTECTED]>
---
cpu/mpc85xx/cpu.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/cpu/mpc85xx/cpu.c b/cpu/mpc85xx/cpu.c
index 59a9ac8..89800b
The local bus clock divider should be doubled for both 8610 and 8641.
Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
Acked-by: Kumar Gala <[EMAIL PROTECTED]>
Acked-by: Jon Loeliger <[EMAIL PROTECTED]>
---
cpu/mpc86xx/cpu.c |1 +
1 files changed, 1 insertions(+), 0 deletion
On Wed, 3 Dec 2008, Sean MacLennan wrote:
>> Yes, I would recommend to do it this way if possible. A small NOR for
>> U-Boot and environment and everything else in NAND. This makes things
>> much easier. But I understand that this is sometimes a problem with
>> space (2 FLASH chips) and costs.
>
>
Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
---
drivers/i2c/fsl_i2c.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/fsl_i2c.c b/drivers/i2c/fsl_i2c.c
index 281a88b..3b5c06b 100644
--- a/drivers/i2c/fsl_i2c.c
+++ b/drivers/i2c/fsl_i2c.c
@@
On Fri, 31 Oct 2008, Peter Tyser wrote:
> +$(TIMESTAMP_FILE):
> + @( printf '#define U_BOOT_DATE "%s"\n' '$(shell date +"%b %d
> %C%y")' \
> + ) > $@
> + @( printf '#define U_BOOT_TIME "%s"\n' '$(shell date +"%T")' \
> + ) >> $@
You could do this:
On Tue, 14 Oct 2008, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
>>
>>> This affects *all* boards and should therefore be implemented for
>>> *all* boards, not only for 85xx.
>>
>> The other board's linker scripts are somewhat different. Maybe someone who
>> maintains them
On Thu, 16 Oct 2008, Selvamuthukumar wrote:
> Most of the bss initialization loop increments 4 bytes
> at a time. And the loop end is checked for an 'equal'
> condition. Make the bss end address aligned by 4, so
> that the loop will end as expected.
It's not really the end of bss that matters, but
On Wed, 15 Oct 2008, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
>>
>> All the mpc85xx platforms hard code the size of the flash via the local bus
>
> No, they don't.
Name one that doesn't.
>> controller settings. For example, if you look in include/configs/MPC8572DS.h
>> yo
On Tue, 14 Oct 2008, Wolfgang Denk wrote:
> Dear Trent,
>
> in message <[EMAIL PROTECTED]> you wrote:
>>
>> This data doesn't exist in the board config file. The linker scripts already
>> in effect contain this data. I have a calculation that uses the flash bank
>> size. What's there now is the
On Tue, 14 Oct 2008, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
>>
>> This is where bss goes when u-boot is linked. It gets relocated to a
>> different address in ram.
>
> Where is defined which address it is, then?
It is determined at run time. Look in cpu/mpc85xx/start.S
On Tue, 14 Oct 2008, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
>>> U-Boot should *never* assume static flash bank sizes. The whole
>>> design is based on the idea to automatically determine the actual
>>> size of flash and RAM that is fit on a specific board,
On Tue, 14 Oct 2008, Wolfgang Denk wrote:
> Dear Trent Piepho,
>
> In message <[EMAIL PROTECTED]> you wrote:
>> A recent gcc added a new unaligned rodata section called '.rodata.str1.1'
>> and that needs to be added the the linker script.
>>
>> R
On Tue, 14 Oct 2008, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
>>
>> B) The U-Boot image is over 4MB in size. The image size for this is from
>> TEXT_BASE to the end of the reset vector. It's not the size of the U-Boot
>> code as there could be a huge gap between the end of
On Tue, 14 Oct 2008, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
>> The boot page and reset vector need to be at the absolute address
>> 0xf000 and 0xfffc, respectively, when the CPU boots.
> ...
>> To handle to both different U-Boot image sizes and flash locations, wha
On Tue, 14 Oct 2008, Wolfgang Denk wrote:
> Dear Trent Piepho,
>
> In message <[EMAIL PROTECTED]> you wrote:
>>
>> B) The U-Boot image is over 4MB in size. The image size for this is from
>> TEXT_BASE to the end of the reset vector. It's not the size of
On Tue, 14 Oct 2008, Wolfgang Denk wrote:
> Dear Trent,
>
> In message <[EMAIL PROTECTED]> you wrote:
>>
>> At this point all the mpc85xx linker scripts are exactly the same, except for
>> one line that defines the flash bank size, so they are combined into one
>> script in cpu/mpc85xx/u-boot.lds.
Since this part of the linker script is the same for all mpc85xx targets,
maybe it should be placed into an include file instead of duplicated?
Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
---
board/freescale/mpc8536ds/u-boot.lds | 11 +--
board/freescale/mpc8540
It wasn't used in one instance where the end of the rotext section is
aligned to 256 bytes.
Maybe this alignment isn't necessary? I have to wonder about the alignment
of the .data.init and .text.init sections too, since they don't appear to
even exist.
Signed-off-by: Trent
blems, they can create a custom
ld script that overrides the flash bank size and then just include
the common mpc85xx script. It would look something like this:
__flash_mask = 2M - 1;/* For a 2MB flash bank */
INCLUDE cpu/mpc85xx/u-boot.lds
Signed-off-by: Trent Piepho <[EMAIL P
elf will result in sub-optimal section ordering. The
section will be sorted by object file, which causes extra padding between
the unaligned rodata.str.1.1 of one object file and the aligned rotdata of
the next object file. This is easy to fix by using the SORT_BY_ALIGNMENT
command.
Signed-off-by:
This patch series does $SUBJ.
The first patch changes the way the existing linker scripts locate the boot
page, reset vector, and bss section. This method works for any size of u-boot
image (the previous one didn't work images that weren't 512K) and any location
flash is mapped to.
At this point
81 matches
Mail list logo
