u-boot.git/include/ide.h, branch v2013.07 Unnamed repository; edit this file 'description' to name the repository. Fix ext2/ext4 filesystem accesses beyond 2TiB 2013-07-15T21:06:13+00:00 Frederic Leroy fredo@starox.org 2013-06-26T16:11:25+00:00 04735e9c5578dd4f3584be5454b9779e8e5c2af9 With CONFIG_SYS_64BIT_LBA, lbaint_t gets defined as a 64-bit type, which is required to represent block numbers for storage devices that exceed 2TiB (the block size usually is 512B), e.g. recent hard drives We now use lbaint_t for partition offset to reflect the lbaint_t change, and access partitions beyond or crossing the 2.1TiB limit. This required changes to signature of ext4fs_devread(), and type of all variables relatives to block sector. ext2/ext4 fs uses logical block represented by a 32 bit value. Logical block is a multiple of device block sector. To avoid overflow problem when calling ext4fs_devread(), we need to cast the sector parameter. Signed-off-by: Frédéric Leroy <fredo@starox.org> 
With CONFIG_SYS_64BIT_LBA, lbaint_t gets defined as a 64-bit type,
which is required to represent block numbers for storage devices that
exceed 2TiB (the block size usually is 512B), e.g. recent hard drives

We now use lbaint_t for partition offset to reflect the lbaint_t change,
and access partitions beyond or crossing the 2.1TiB limit.
This required changes to signature of ext4fs_devread(), and type of all
variables relatives to block sector.

ext2/ext4 fs uses logical block represented by a 32 bit value. Logical
block is a multiple of device block sector. To avoid overflow problem
when calling ext4fs_devread(), we need to cast the sector parameter.

Signed-off-by: Frédéric Leroy <fredo@starox.org>
Fix block device accesses beyond 2TiB 2013-06-26T14:26:06+00:00 Sascha Silbe t-uboot@infra-silbe.de 2013-06-14T11:07:25+00:00 ff8fef566601ba27767e885386cb2074c4f09886 With CONFIG_SYS_64BIT_LBA, lbaint_t gets defined as a 64-bit type, which is required to represent block numbers for storage devices that exceed 2TiB (the block size usually is 512B), e.g. recent hard drives. For some obscure reason, the current U-Boot code uses lbaint_t for the number of blocks to read (a rather optimistic estimation of how RAM sizes will evolve), but not for the starting address. Trying to access blocks beyond the 2TiB boundary will simply wrap around and read a block within the 0..2TiB range. We now use lbaint_t for block start addresses, too. This required changes to all block drivers as the signature of block_read(), block_write() and block_erase() in block_dev_desc_t changed. Signed-off-by: Sascha Silbe <t-uboot@infra-silbe.de> 
With CONFIG_SYS_64BIT_LBA, lbaint_t gets defined as a 64-bit type,
which is required to represent block numbers for storage devices that
exceed 2TiB (the block size usually is 512B), e.g. recent hard drives.

For some obscure reason, the current U-Boot code uses lbaint_t for the
number of blocks to read (a rather optimistic estimation of how RAM
sizes will evolve), but not for the starting address. Trying to access
blocks beyond the 2TiB boundary will simply wrap around and read a
block within the 0..2TiB range.

We now use lbaint_t for block start addresses, too. This required
changes to all block drivers as the signature of block_read(),
block_write() and block_erase() in block_dev_desc_t changed.

Signed-off-by: Sascha Silbe <t-uboot@infra-silbe.de>
Adjust board_r.c for ppc 2013-03-15T20:14:00+00:00 Simon Glass sjg@chromium.org 2013-03-14T07:20:12+00:00 c2240d4dbef98f0bc5f5e99324d1eef8d6e9acdf This adds ppc features to the generic post-relocation board init. Signed-off-by: Simon Glass <sjg@chromium.org> 
This adds ppc features to the generic post-relocation board init.

Signed-off-by: Simon Glass <sjg@chromium.org>
ide: Add printf format string for CONFIG_SYS_64BIT_LBA option 2012-10-22T15:29:55+00:00 Gabe Black gabeblack@chromium.org 2012-10-12T14:26:06+00:00 24a3fdd64d449c1acd4ccc3636f8bf02e903b6f8 The size of an LBA type changes depending on this option. We need to use a different printf() string in each case, so create a define for this. Signed-off-by: Gabe Black <gabeblack@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org> 
The size of an LBA type changes depending on this option. We need to
use a different printf() string in each case, so create a define for
this.

Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
change all versions of input_data() and output_data() to global weak aliases 2012-10-17T14:59:08+00:00 Pavel Herrmann morpheus.ibis@gmail.com 2012-10-09T07:04:39+00:00 f5b82c0f9c34ded68e346a0fe7ad13c3ff63f573 This changes input_data() and friends from static function to global symbols under weak alias, to enable board specific overrides (and therefore get rid of board-specific code in cmd_ide.c) Also declare ide_bus_offset in the header file, so other files can use ATA_CURR_BASE as well. Signed-off-by: Pavel Herrmann <morpheus.ibis@gmail.com> 
This changes input_data() and friends from static function to global symbols
under weak alias, to enable board specific overrides (and therefore get rid of
board-specific code in cmd_ide.c)
Also declare ide_bus_offset in the header file, so other files can use
ATA_CURR_BASE as well.

Signed-off-by: Pavel Herrmann <morpheus.ibis@gmail.com>
split mpc8xx hooks from cmd_ide.c 2012-10-17T14:59:08+00:00 Pavel Herrmann morpheus.ibis@gmail.com 2012-10-09T07:01:56+00:00 8d1165e11a7aad00a2bbb05f20bacf021f6d1c12 move most of mpc8xx hooks from cmd_ide.c into ide_preinit() and newly created ide_init_postreset() (invoked after calling ide_reset after ide_preinit), some cleanup to make checkpatch happy, enable IDE init hooks in configs of affected boards. confusingly, these hooks are used by more than just mpc8xx-based boards, and therefore are placed in arch/ppc/lib/ note: checkpatch still emits warnings about using volatile Signed-off-by: Pavel Herrmann <morpheus.ibis@gmail.com> 
move most of mpc8xx hooks from cmd_ide.c into ide_preinit() and newly created
ide_init_postreset() (invoked after calling ide_reset after ide_preinit),
some cleanup to make checkpatch happy, enable IDE init hooks in configs of
affected boards.
confusingly, these hooks are used by more than just mpc8xx-based boards, and
therefore are placed in arch/ppc/lib/

note: checkpatch still emits warnings about using volatile

Signed-off-by: Pavel Herrmann <morpheus.ibis@gmail.com>
ide.h: Make ide_(read|write) match block_dev_desc_t block_(read|write) 2012-10-15T18:54:03+00:00 Tom Rini trini@ti.com 2012-09-29T14:36:43+00:00 4ac8f8e022dad149f47a369e60e536b356f14493 block_dev_desc_t says that block_(read|write) take lbaint_t for blkcnt not ulong Signed-off-by: Tom Rini <trini@ti.com> 
block_dev_desc_t says that block_(read|write) take lbaint_t for blkcnt
not ulong

Signed-off-by: Tom Rini <trini@ti.com>
ide: Correct IDE_BUS(dev) macro 2012-10-08T18:12:08+00:00 Luka Perkov uboot@lukaperkov.net 2012-05-14T09:29:10+00:00 8a10180d62bb50a1f19441494bf9a5cea29ccfda The IDE_BUS(dev) macro was previously doing dev >> 1. This however is a mis-match of the usage in common/cmd_ide.c and would cause boards with multiple ports / devices to not correctly detect all devices. For more details please see: http://lists.denx.de/pipermail/u-boot/2012-April/122525.html [Tom Rini: Reword commit message only] Tested-by: Luka Perkov <uboot@lukaperkov.net> Signed-off-by: Simon Baatz <gmbnomis@gmail.com> Signed-off-by: Tom Rini <trini@ti.com> 
The IDE_BUS(dev) macro was previously doing dev >> 1.  This however is a
mis-match of the usage in common/cmd_ide.c and would cause boards with
multiple ports / devices to not correctly detect all devices.  For more
details please see:
http://lists.denx.de/pipermail/u-boot/2012-April/122525.html

[Tom Rini: Reword commit message only]

Tested-by: Luka Perkov <uboot@lukaperkov.net>
Signed-off-by: Simon Baatz <gmbnomis@gmail.com>
Signed-off-by: Tom Rini <trini@ti.com>
IDE: fix compiler warnings 2011-04-30T21:29:55+00:00 Wolfgang Denk wd@denx.de 2011-04-30T21:29:55+00:00 96d04c3150ae9284500aef48803d7d132968f2b2 The changes introduced by commit 0abddf8 ``cmd_ide: enhance new feature "CONFIG_IDE_AHB"'' caused compiler warnings like cmd_ide.c: In function 'ide_init': cmd_ide.c:716: warning: assignment from incompatible pointer type Constify the respective function arguments to fix this. Signed-off-by: Wolfgang Denk <wd@denx.de> 
The changes introduced by commit 0abddf8 ``cmd_ide: enhance new
feature "CONFIG_IDE_AHB"'' caused compiler warnings like

cmd_ide.c: In function 'ide_init':
cmd_ide.c:716: warning: assignment from incompatible pointer type

Constify the respective function arguments to fix this.

Signed-off-by: Wolfgang Denk <wd@denx.de>
cmd_ide: enhance new feature "CONFIG_IDE_AHB" 2011-04-30T19:04:25+00:00 Macpaul Lin macpaul@andestech.com 2011-04-11T20:45:32+00:00 0abddf82d54c704cf066524235b6414333e8d087 Although most IDE controller is designed to be connected to PCI bridge, there are still some IDE controller support AHB interface for SoC design. The driver implementation of these IDE-AHB controllers differ from other IDE-PCI controller, some additional registers and commands access is required during CMD/DATA I/O. Hence a configuration "CONFIG_IDE_AHB" in cmd_ide.c is required to be defined to support these kinds of SoC controllers. Such as Faraday's FTIDE020 series and Global Unichip's UINF-0301. Signed-off-by: Macpaul Lin <macpaul@andestech.com> 
Although most IDE controller is designed to be connected to PCI bridge,
there are still some IDE controller support AHB interface for SoC design.

The driver implementation of these IDE-AHB controllers differ from other
IDE-PCI controller, some additional registers and commands access is required
during CMD/DATA I/O. Hence a configuration "CONFIG_IDE_AHB" in cmd_ide.c is
required to be defined to support these kinds of SoC controllers. Such as
Faraday's FTIDE020 series and Global Unichip's UINF-0301.

Signed-off-by: Macpaul Lin <macpaul@andestech.com>