u-boot.git/disk, branch v2012.07-rc2 Unnamed repository; edit this file 'description' to name the repository. Block: Remove MG DISK support 2012-06-21T18:53:09+00:00 Marek Vasut marex@denx.de 2012-03-04T15:11:32+00:00 b37d41aa24aedd84f718d019e5b7a27a06aa73fc This driver is unused and obsolete. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Wolfgang Denk <wd@denx.de> Cc: unsik Kim <donari75@gmail.com> 
This driver is unused and obsolete.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: unsik Kim <donari75@gmail.com>
part_dos: align disk buffers on cache line to enable DMA and cache 2012-04-30T14:54:50+00:00 Eric Nelson eric.nelson@boundarydevices.com 2012-03-03T12:02:20+00:00 dec049d92427a4bf8bf4083f4ebaedbc5dc83e7b Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com> Acked-by: Mike Frysinger <vapier@gentoo.org> 
Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
Acked-by: Mike Frysinger <vapier@gentoo.org>
disk/part.c: Fix device enumeration through API 2012-03-27T09:46:33+00:00 Tim Kientzle kientzle@freebsd.org 2012-03-27T09:43:25+00:00 7e71dc68846647f387a74d50924da1218e197089 The patch below fixes device enumeration through the U-Boot API. Device enumeration crashes when the system in question doesn't have any RAM mapped to address zero (I discovered this on a BeagleBone board), since the enumeration calls get_dev with a NULL ifname sometimes which then gets passed down to strncmp(). This fix simply ensures that get_dev returns NULL when invoked with a NULL ifname. Signed-off-by: Tim Kientzle <kientzle@freebsd.org> Signed-off-by: Anatolij Gustschin <agust@denx.de> 
The patch below fixes device enumeration through the U-Boot API.

Device enumeration crashes when the system in question doesn't
have any RAM mapped to address zero (I discovered this on a
BeagleBone board), since the enumeration calls get_dev with a
NULL ifname sometimes which then gets passed down to strncmp().

This fix simply ensures that get_dev returns NULL when invoked
with a NULL ifname.

Signed-off-by: Tim Kientzle <kientzle@freebsd.org>
Signed-off-by: Anatolij Gustschin <agust@denx.de>
part_efi: Fix compile errors 2011-12-06T22:59:30+00:00 Sanjeev Premi premi@ti.com 2011-11-16T15:20:47+00:00 29b7042addcad3512c9e597bf4c805df7b9d2757 Fix errors noticed after enabling CONFIG_EFI_PARTITION for the OMAP3 EVM board: part_efi.c: In function 'print_part_efi': part_efi.c:133:5: warning: passing argument 3 of 'is_gpt_valid' from incompatible pointer type part_efi.c:95:12: note: expected 'struct gpt_header *' but arg ument is of type 'struct gpt_header **' part_efi.c: In function 'get_partition_info_efi': part_efi.c:173:4: warning: passing argument 3 of 'is_gpt_valid ' from incompatible pointer type part_efi.c:95:12: note: expected 'struct gpt_header *' but arg ument is of type 'struct gpt_header **' part_efi.c: In function 'alloc_read_gpt_entries': part_efi.c:384:18: error: 'CONFIG_SYS_CACHELINE_SIZE' undeclare d (first use in this function) Signed-off-by: Sanjeev Premi <premi@ti.com> Cc: Tom Rini <tom.rini@gmail.com> Cc: Anton staaf <robotboy@chromium.org> Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com> 
Fix errors noticed after enabling CONFIG_EFI_PARTITION
for the OMAP3 EVM board:

part_efi.c: In function 'print_part_efi':
part_efi.c:133:5: warning: passing argument 3 of 'is_gpt_valid'
 from incompatible pointer type
part_efi.c:95:12: note: expected 'struct gpt_header *' but arg
ument is of type 'struct gpt_header **'
part_efi.c: In function 'get_partition_info_efi':
part_efi.c:173:4: warning: passing argument 3 of 'is_gpt_valid
' from incompatible pointer type
part_efi.c:95:12: note: expected 'struct gpt_header *' but arg
ument is of type 'struct gpt_header **'
part_efi.c: In function 'alloc_read_gpt_entries':
part_efi.c:384:18: error: 'CONFIG_SYS_CACHELINE_SIZE' undeclare
d (first use in this function)

Signed-off-by: Sanjeev Premi <premi@ti.com>
Cc: Tom Rini <tom.rini@gmail.com>
Cc: Anton staaf <robotboy@chromium.org>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
disk: part_efi: fix regression due to incorrect buffer usage 2011-12-05T21:23:21+00:00 Stephen Warren swarren@nvidia.com 2011-10-28T09:21:46+00:00 4715a81136049167160230efd28eb9d48eeded1f Commit deb5ca80275e8cfa74d5680b41204e08a095eca5 "disk: part_efi: fix **pgpt_pte == NULL" modified the code to pass "&gpt_head" to is_gpt_valid() rather than the previous "gpt_head". However, gpt_head is a pointer to the buffer, not the actual buffer, since it was allocated using ALLOC_CACHE_ALIGN_BUFFER. This caused is_gpt_valid() to read the disk block onto the stack rather than into the buffer, causing the code to fail. This change reverts that portion of the commit mentioned above. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Doug Anderson <dianders@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org> Tested-by: Anton Staaf <robotboy@chromium.org> 
Commit deb5ca80275e8cfa74d5680b41204e08a095eca5 "disk: part_efi: fix
**pgpt_pte == NULL" modified the code to pass "&gpt_head" to
is_gpt_valid() rather than the previous "gpt_head". However, gpt_head
is a pointer to the buffer, not the actual buffer, since it was allocated
using ALLOC_CACHE_ALIGN_BUFFER. This caused is_gpt_valid() to read the
disk block onto the stack rather than into the buffer, causing the
code to fail.

This change reverts that portion of the commit mentioned above.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Doug Anderson <dianders@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Acked-by: Mike Frysinger <vapier@gentoo.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
disk: part_efi: fix **pgpt_pte == NULL 2011-10-27T21:53:59+00:00 Doug Anderson dianders@chromium.org 2011-10-19T09:47:31+00:00 deb5ca80275e8cfa74d5680b41204e08a095eca5 Code was setting **pgpt_pte == NULL, which meant that the pointer to the gpt_pte would be stored at RAM address 00000000. This 'worked' on T20 (SDRAM starts @ 0x00000000), but hung gpt/EFI access on T30 (SDRAM starts @ 0x80000000). Signed-off-by: Tom Warren <twarren@nvidia.com> Signed-off-by: Doug Anderson <dianders@chromium.org> 
Code was setting **pgpt_pte == NULL, which meant that the pointer
to the gpt_pte would be stored at RAM address 00000000. This 'worked'
on T20 (SDRAM starts @ 0x00000000), but hung gpt/EFI access on T30
(SDRAM starts @ 0x80000000).

Signed-off-by: Tom Warren <twarren@nvidia.com>
Signed-off-by: Doug Anderson <dianders@chromium.org>
cosmetic: Replace __FUNCTION__ with __func__ in part_efi.c 2011-10-27T21:53:59+00:00 Doug Anderson dianders@chromium.org 2011-10-19T08:04:46+00:00 df70b1c2e2e5ba5254f2070b1dd690896ee3c2a2 This makes checkpatch happy. Signed-off-by: Doug Anderson <dianders@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org> 
This makes checkpatch happy.

Signed-off-by: Doug Anderson <dianders@chromium.org>
Acked-by: Mike Frysinger <vapier@gentoo.org>
part_efi: dcache: allocate cacheline aligned buffers 2011-10-25T07:26:34+00:00 Anton staaf robotboy@chromium.org 2011-10-12T13:56:04+00:00 f75dd584cdfe29dfdcfd424bb237b9238cfb8fe4 Currently part_efi.c allocates buffers for the gpt_header, the legacy_mbr, and the pte (partition table entry) that may be incorrectly aligned for DMA operations. This patch uses ALLOC_CACHE_ALIGN_BUFFER for the stack allocated buffers and memalign to replace the malloc of the pte. Signed-off-by: Anton Staaf <robotboy@chromium.org> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: Mike Frysinger <vapier@gentoo.org> Cc: Albert ARIBAUD <albert.u.boot@aribaud.net> Acked-by: Mike Frysinger <vapier@gentoo.org> 
Currently part_efi.c allocates buffers for the gpt_header, the
legacy_mbr, and the pte (partition table entry) that may be
incorrectly aligned for DMA operations.

This patch uses ALLOC_CACHE_ALIGN_BUFFER for the stack allocated
buffers and memalign to replace the malloc of the pte.

Signed-off-by: Anton Staaf <robotboy@chromium.org>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
Acked-by: Mike Frysinger <vapier@gentoo.org>
part: show efi partition name when print out partition info 2011-10-06T18:42:47+00:00 Lei Wen leiwen@marvell.com 2011-09-07T18:11:19+00:00 6eecc0307927fee1ff70151980b3a8c02ffeb947 Previous output: Marvell>> mmc part Partition Map for MMC device 1 -- Partition Type: EFI Part Start LBA End LBA gpt1 0x8C00 0xCBFF gpt2 0xCC00 0x57BFF gpt3 0x57C00 0xA2BFF gpt4 0xA2C00 0xECBFDE With the patch, the output becomes: Marvell>> mmc part Partition Map for MMC device 1 -- Partition Type: EFI Part Name Start LBA End LBA 1 ramdisk 0x00008C00 0x0000CBFF 2 system 0x0000CC00 0x00057BFF 3 userdata 0x00057C00 0x000A2BFF 4 remaining 0x000A2C00 0x00ECBFDE Signed-off-by: Lei Wen <leiwen@marvell.com> 
Previous output:
Marvell>>  mmc part

Partition Map for MMC device 1  --   Partition Type: EFI

Part  Start LBA  End LBA
gpt1  0x8C00    0xCBFF
gpt2  0xCC00    0x57BFF
gpt3  0x57C00    0xA2BFF
gpt4  0xA2C00    0xECBFDE

With the patch, the output becomes:
Marvell>> mmc part

Partition Map for MMC device 1  --   Partition Type: EFI

Part    Name                    Start LBA       End LBA
  1     ramdisk                 0x00008C00      0x0000CBFF
  2     system                  0x0000CC00      0x00057BFF
  3     userdata                0x00057C00      0x000A2BFF
  4     remaining               0x000A2C00      0x00ECBFDE

Signed-off-by: Lei Wen <leiwen@marvell.com>
part_dos: fix crash with big sector size 2011-07-27T21:41:33+00:00 Sergei Shtylyov sshtylyov@ru.mvista.com 2011-06-03T09:37:43+00:00 54193c5d8133f4f35267f412e5c1bbcbc6ac041c Apple iPod nanos have sector sizes of 2 or 4 KiB, which crashes U-Boot when it tries to read the MBR into 512-byte buffer situated on stack. Instead use the variable length arrays to be safe with any large sector size. Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> 
Apple iPod nanos have sector sizes of 2 or 4 KiB, which crashes U-Boot when it
tries to read the MBR into 512-byte buffer situated on stack. Instead use the
variable length arrays to be safe with any large sector size.

Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>