Previously, SPD configuration of RAM was non functional on
this board. Now that the root cause is known (an i2c address
conflict), there is a simple end-user workaround - remove the
old slower local bus 128MB module and then SPD detection on the
main DDR2 memory module works fine.
We make the ena
Existing boards by default have an issue where the LBC SDRAM
SPD EEPROM and the DDR2 SDRAM SPD EEPROM both land at 0x51.
After the hardware modification listed in the README is made,
then the DDR2 SPD EEPROM appears at 0x53. So this implements
a board specific get_spd() by taking advantage of the
Nothing to see here, just a relocation of the fixed ddr init
sequence to live in the actual ddr.c file itself.
Signed-off-by: Paul Gortmaker
---
board/sbc8548/ddr.c | 48 +
board/sbc8548/sbc8548.c | 44 --
The code here was copied from the mpc8548cds support, and it
wasn't using the CONFIG_SYS_LBC_LCRR define, and was just
unconditionally setting the LCRR_EADC bit. Snooping with a
hardware debugger also showed we had LCRR_DBYP set, since we were
setting it based on a read of an uninitialized lcrr re
This board has an 8MB soldered on flash, and a 64MB SODIMM
flash module. Normally the board boots from the 8MB flash,
but the hardware can be configured for booting from the 64MB
flash as well by swapping CS0 and CS6. This can be handy
for recovery purposes, or for supporting u-boot and VxBoot
at
These were cloned from the mpc8548cds platform which has
a different memory layout (1/2 the size). Set the values
by comparing to the register file for the board used during
JTAG init sequence:
LSDMR1 0x2863B727 /* PCHALL */
LSDMR2 0x0863B727 /* NORMAL
This updates the sbc8548 board support with several improvements
for the end users.
-ability to use SPD DDR config for easy RAM upgrades
-ability to use alternate SODIMM flash for backup u-boot image
-localbus config settings fixed so 128MB LBC SDRAM works reliably
The discovery of a har
This reverts commit ccf1ad535ae1c0dc2d466235c668adbdfe3a55b7.
The commit "SBC8548: fix address mask to allow 64M flash"
essentially made this change:
* OR6:
- *Addr Mask = 64M = OR6[0:16] = 1100 0
+ *Addr Mask = 64M = OR6[0:16] = 1000 0
But this makes no s
The current situation has the 64MB user flash at an awkward
alignment; shifted back from 0xfc00_ by 8M, to leave an 8MB hole
for the soldered on boot flash @ EOM. But to switch to optionally
supporting booting off the 64MB flash, the 64MB will then be mapped
at the sane address of 0xfc00_.
Hi Graeme,
On Fri, Dec 30, 2011 at 7:49 AM, Graeme Russ wrote:
> Hi Simon,
>
> Sorry for the delay in reviewing this - I've been doing a lot of work on
> the x86 side of things. I now have a working solution to the
> board_init_f_r() / global data clobbering problem which involves having the
> gd
Dear Graeme Russ,
In message <4efddd7d.50...@gmail.com> you wrote:
>
> I honestly think we should get the x86 init sequence patches finalised
> first for several reasons:
>
> - Because x86 is so small, it provides a good test-bed - ELF relocation
>was first finalised on x86 (it came and went
Hi Simon,
Sorry for the delay in reviewing this - I've been doing a lot of work on
the x86 side of things. I now have a working solution to the
board_init_f_r() / global data clobbering problem which involves having the
gd 'variable' as a register like all other arch's. The solution is
non-trivial
The commit message of a28afca (Add uboot "fdt_high" enviroment variable)
states that fdt_high behaves similarly to the existing initrd_high.
But fdt_high actually has an outstanding difference from initrd_high.
The former specifies the start address, while the later specifies the
end address.
As f
Dear Andreas,
In message
you wrote:
>
> sha1sum sum is yes enough to verify that no files have been modified on the
> file system on the already installed Linux device.
It is also good enough to ensure that the files on any distribution
media have not been corrupted or modified in some way. Of
sha1sum sum is yes enough to verify that no files have been modified on the
file system on the already installed Linux device.
But my case here is if one need to update the software on the device out
somewhere in the world we have now made a usb stick and uboot looks for
special files first on the
This patch is added to support SPL feature on AM335X
platform. In this patch, MMC1 is configured as boot
device for SPL and support for other devices will be
added in the next patch series.
Signed-off-by: Chandan Nath
Signed-off-by: Tom Rini
---
Changes since v1:
- Rebased to master branch
- R
This patch is added to update incorrect ddr, pll and timer
register offset along with some additional cleanup like
removing unused code. Also, generic CONFIG_AM33XX symbol
is added for AM33XX platform.
Signed-off-by: Chandan Nath
Signed-off-by: Tom Rini
---
Changes since v1:
- Changed CONFIG_AM
This patch series is submitted to add support for MMC/SD along
with SPL support. Also, fixed incorrect register offset of
ddr and timer registers.
The patches have been compile tested and run on AM335X EVM.
The patches depends on previous patch series which was submitted
for supporting AM33xx pla
This patch add supports for mmc/sd driver on AM335X platform.
PLL and pinmux configurations for mmc/sd are configured in this
patch.
Signed-off-by: Chandan Nath
Signed-off-by: Tom Rini
---
Changes since v1:
- Removed unwanted code from omap_hsmmc.c file
- Rebased to master branch
arch/arm/cp
19 matches
Mail list logo
