date:20141217

Re: [U-Boot] [PATCH v3 0/9] sf: Update flash params for supported read commands and sector size

2014-12-17 Thread Jagan Teki

On 15 December 2014 at 19:21, Bin Meng bmeng...@gmail.com wrote:
 Hi Jagan,

 On Thu, Dec 11, 2014 at 3:40 PM, Bin Meng bmeng...@gmail.com wrote:
 Hi Jagan,

 On Thu, Dec 11, 2014 at 3:26 PM, Jagan Teki jagannadh.t...@gmail.com wrote:
 Hi Bin,

 On 11 December 2014 at 08:34, Bin Meng bmeng...@gmail.com wrote:
 Hi Jagan,

 On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki jagannadh.t...@gmail.com 
 wrote:
 Hi Bin,

 On 10 December 2014 at 18:21, Bin Meng bmeng...@gmail.com wrote:
 This series update SPI flash supported read commands per datasheet
 in the flash params table, and change flash sector size to 4KiB as
 long as flash supports sector erase (20h) command, to ensure
 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when
 given SECT_4K.

 Changes in v3:
 - Rebase with Jagan's patch series @ 
 http://patchwork.ozlabs.org/patch/419154/


 Bin Meng (9):
   sf: Update SST flash params
   sf: Update Atmel flash params
   sf: Update EON flash params
   sf: Update GigaDevice flash params
   sf: Update Macronix flash params
   sf: Update Spansion flash params
   sf: Update Micron flash params
   sf: Update Winbond flash params
   sf: Give proper spacing between flash table params

 Thanks for the updates - have you verified these changes?

 I verified some, but not all of these flash parts. The update is based
 on flash datasheet, so if something is broken, eg before this series
 the flash advertises only READ_NORM and after my series it is changed
 to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very
 likely that the SPI controller driver has some bugs when supporting
 QUAD_IO_FAST.

 Since these updates were tested before, I will skip these for this PR.
 Will test all the rest (except these) and send the PR soon.

 Let me know your inputs?

 I am fine, as long as this PR will not contains other commits which
 modify the same sf_params.c to introduce more flash support. We can
 test these updates and if everything looks fine, apply these first and
 ask other commits to rebase on this series to introduce more flash
 support.


 Do you have any additional comments about this patch series besides
 the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send
 the v4.

I'm thinking about the other flashes too,  since these params were taken from
previous working and Linux mtd.

thanks!
-- 
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 0/9] sf: Update flash params for supported read commands and sector size

2014-12-17 Thread Bin Meng

Hi Jagan,

On Wed, Dec 17, 2014 at 3:59 PM, Jagan Teki jagannadh.t...@gmail.com wrote:
 On 15 December 2014 at 19:21, Bin Meng bmeng...@gmail.com wrote:
 Hi Jagan,

 On Thu, Dec 11, 2014 at 3:40 PM, Bin Meng bmeng...@gmail.com wrote:
 Hi Jagan,

 On Thu, Dec 11, 2014 at 3:26 PM, Jagan Teki jagannadh.t...@gmail.com 
 wrote:
 Hi Bin,

 On 11 December 2014 at 08:34, Bin Meng bmeng...@gmail.com wrote:
 Hi Jagan,

 On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki jagannadh.t...@gmail.com 
 wrote:
 Hi Bin,

 On 10 December 2014 at 18:21, Bin Meng bmeng...@gmail.com wrote:
 This series update SPI flash supported read commands per datasheet
 in the flash params table, and change flash sector size to 4KiB as
 long as flash supports sector erase (20h) command, to ensure
 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when
 given SECT_4K.

 Changes in v3:
 - Rebase with Jagan's patch series @ 
 http://patchwork.ozlabs.org/patch/419154/


 Bin Meng (9):
   sf: Update SST flash params
   sf: Update Atmel flash params
   sf: Update EON flash params
   sf: Update GigaDevice flash params
   sf: Update Macronix flash params
   sf: Update Spansion flash params
   sf: Update Micron flash params
   sf: Update Winbond flash params
   sf: Give proper spacing between flash table params

 Thanks for the updates - have you verified these changes?

 I verified some, but not all of these flash parts. The update is based
 on flash datasheet, so if something is broken, eg before this series
 the flash advertises only READ_NORM and after my series it is changed
 to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very
 likely that the SPI controller driver has some bugs when supporting
 QUAD_IO_FAST.

 Since these updates were tested before, I will skip these for this PR.
 Will test all the rest (except these) and send the PR soon.

 Let me know your inputs?

 I am fine, as long as this PR will not contains other commits which
 modify the same sf_params.c to introduce more flash support. We can
 test these updates and if everything looks fine, apply these first and
 ask other commits to rebase on this series to introduce more flash
 support.


 Do you have any additional comments about this patch series besides
 the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send
 the v4.

 I'm thinking about the other flashes too,  since these params were taken from
 previous working and Linux mtd.


You mean 'thinking about' or 'testing'? I should say previously they
might not be 100% working as per datasheet some flash params currently
are apparently wrong.

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 03/15] x86: Convert microcode format to device-tree-only

2014-12-17 Thread Bin Meng

Hi,

On Wed, Dec 17, 2014 at 3:50 PM, Bin Meng bmeng...@gmail.com wrote:
 From: Simon Glass s...@chromium.org

 To avoid having two microcode formats, adjust the build system to support
 obtaining the microcode from the device tree, even in the case where it
 must be made available before the device tree can be accessed.

 Signed-off-by: Simon Glass s...@chromium.org

 ---

 Changes in v4:
 - Squash the microcode.dtsi to patch#1 in the v4 series

 Changes in v3: None
 Changes in v2: None

  Makefile |  4 +++-
  arch/x86/cpu/queensbay/tnc_car.S | 11 ---
  arch/x86/dts/crownbay.dts|  7 +++
  3 files changed, 14 insertions(+), 8 deletions(-)

 diff --git a/Makefile b/Makefile
 index fd24cde..d4e60e8 100644
 --- a/Makefile
 +++ b/Makefile
 @@ -947,7 +947,9 @@ ifneq ($(CONFIG_X86_RESET_VECTOR),)
  rom: u-boot.rom FORCE

  IFDTOOL=$(objtree)/tools/ifdtool
 -IFDTOOL_FLAGS  = -w $(CONFIG_SYS_TEXT_BASE):$(objtree)/u-boot-dtb.bin
 +IFDTOOL_FLAGS  = -f 0:$(objtree)/u-boot.dtb
 +IFDTOOL_FLAGS += -m 0x$(shell $(NM) u-boot |grep _dt_ucode_base_size |cut 
 -d' ' -f1)
 +IFDTOOL_FLAGS += -U $(CONFIG_SYS_TEXT_BASE):$(objtree)/u-boot.bin
  IFDTOOL_FLAGS += -w $(CONFIG_SYS_X86_START16):$(objtree)/u-boot-x86-16bit.bin

  ifneq ($(CONFIG_HAVE_INTEL_ME),)
 diff --git a/arch/x86/cpu/queensbay/tnc_car.S 
 b/arch/x86/cpu/queensbay/tnc_car.S
 index 6834a64..2e9139e 100644
 --- a/arch/x86/cpu/queensbay/tnc_car.S
 +++ b/arch/x86/cpu/queensbay/tnc_car.S
 @@ -116,12 +116,9 @@ temp_ram_init_romstack:
 .long   temp_ram_init_ret
 .long   temp_ram_init_params
  temp_ram_init_params:
 -   .long   ucode_start /* microcode base */
 -   .long   ucode_size  /* microcode size */
 +_dt_ucode_base_size:
 +   /* These next two fields are filled in by ifdtool */
 +   .long   0   /* microcode base */
 +   .long   0   /* microcode size */
 .long   CONFIG_SYS_MONITOR_BASE /* code region base */
 .long   CONFIG_SYS_MONITOR_LEN  /* code region size */
 -
 -   .balign 4
 -ucode_start:
 -   .include arch/x86/cpu/queensbay/M0220661105.inc
 -ucode_size = ( . - ucode_start)
 diff --git a/arch/x86/dts/crownbay.dts b/arch/x86/dts/crownbay.dts
 index 399dafb..3f43f3c 100644
 --- a/arch/x86/dts/crownbay.dts
 +++ b/arch/x86/dts/crownbay.dts
 @@ -50,4 +50,11 @@
 memory-map = 0xffe0 0x0020;
 };
 };
 +
 +   microcode {
 +   update@0 {
 +#include microcode/m0220661105_cv.dtsi
 +   };
 +   };
 +
  };
 --

Reviewed-by: Bin Meng bmeng...@gmail.com
Tested-by: Bin Meng bmeng...@gmail.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 6/6] x86: Convert microcode format to device-tree-only

2014-12-17 Thread Bin Meng

Hi Simon,

On Wed, Dec 17, 2014 at 10:49 AM, Simon Glass s...@chromium.org wrote:
 Hi Bin,

 On 16 December 2014 at 03:01, Bin Meng bmeng...@gmail.com wrote:
 On Tue, Dec 16, 2014 at 1:02 PM, Simon Glass s...@chromium.org wrote:
 To avoid having two microcode formats, adjust the build system to support
 obtaining the microcode from the device tree, even in the case where it
 must be made available before the device tree can be accessed.

 Also move the microcode for queensbay (unfortunately the wrong version).

 Signed-off-by: Simon Glass s...@chromium.org
 ---

 Changes in v2:
 - Update microcode file to version 5_cv
 - Drop patches that have already been applied

  Makefile   |4 +-
  arch/x86/cpu/queensbay/M0220661105.inc | 1288 
 
  arch/x86/cpu/queensbay/tnc_car.S   |   11 +-
  arch/x86/dts/crownbay.dts  |7 +
  arch/x86/dts/microcode/m0220661105_cv.dtsi |  366 
  5 files changed, 380 insertions(+), 1296 deletions(-)
  delete mode 100644 arch/x86/cpu/queensbay/M0220661105.inc
  create mode 100644 arch/x86/dts/microcode/m0220661105_cv.dtsi

 [snip]
 --

 Reviewed-by: Bin Meng bmeng...@gmail.com

 Tested on Intel Crown Bay

 Tested-by: Bin Meng bmeng...@gmail.com

 This patch is for you, I cannot apply it as it depends on one of your
 patches. If I apply your patch then it breaks the build.

 So it would be best if you squashed this patch into one of yours. I'll
 push everything to x86/master (except the microcode patch which needs
 another rev) ready for you to rebase your patches.

 Regards,
 Simon

This patch is integrated into my series @
http://patchwork.ozlabs.org/patch/422192/. Thanks!

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 25/25] x86: Add a README.x86 for U-Boot on x86 support

2014-12-17 Thread Bin Meng

Hi Pavel,

On Tue, Dec 16, 2014 at 6:34 AM, Pavel Machek pa...@denx.de wrote:
 Hi!

 +Status
 +--
 +U-Boot supports running as a coreboot [1] payload on x86. So far only link
 +(Chromebook pixel) has been tested, but it should work with minimal
 adjustments

 Link is codeword for Chromebook Pixel? I'd write Chromebook Pixel
 (Link) if so.

 +on other x86 boards since coreboot deals with most of the low-level details.
 +
 +U-Boot also supports booting directly from x86 reset vector without 
 coreboot,
 +aka raw support or bare support. Currently Google Chromebook link and Intel

 Should this me Chromebook Pixel?


 +Building rom version U-Boot (hereafter referred to as u-boot.rom) is a 
 little

 ROM version of ?

 +bit tricky, as generally it requires several binary blobs which are not 
 shipped
 +in the U-Boot source tree. Due to this reason, the u-boot.rom build is not
 +turned on by default in the U-Boot source tree. Firstly, you need turn it on
 +by uncommenting the following line in the main U-Boot Makefile:
 +
 +# ALL-$(CONFIG_X86_RESET_VECTOR) += u-boot.rom
 +
 +Google Chromebook link specific instructions:

 link - Pixel?

 +Firstly, you need the following binary blobs:

 Firstly-First

 +You can get these binary blobs by:
 +
 +$ git clone http://review.coreboot.org/p/blobs.git
 +$ cd blobs
 +
 +Find the following files:
 +
 +* ./mainboard/google/link/descriptor.bin
 +* ./mainboard/google/link/me.bin
 +* ./northbridge/intel/sandybridge/systemagent-ivybridge.bin
 +
 +The 3rd one should be renamed to mrc.bin.

 Should there be instruction where to put those files? Perhaps a script
 doing this and getting ROM would be nice?

 +As for the video ROM, you can get it here [2].
 +
 +Now you can build U-Boot and obtain u-boot.rom:

 +$ make chromebook_link_defconfig
 +$ make all
 +
 +Intel Crown Bay specific instructions:
 +
 +U-Boot support of Intel Crown Bay board [3] relies on a binary blob called
 +Firmware Support Package [4] to perform all the necessary initialization 
 steps
 +as documented in the BIOS Writer Guide including initialization of
 the CPU,

 Guide, 


 +Downalod the Intel FSP for Atom E6xx series and Platform Controller

 - Download.


Most issues fixed in the v4 patch @
http://patchwork.ozlabs.org/patch/422203/, except the Chromebook Pixel
(link) issue which will need Simon to comment.

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 15/25] x86: Add a simple command to show FSP HOB information

2014-12-17 Thread Bin Meng

Hi Pavel,

On Tue, Dec 16, 2014 at 6:34 AM, Pavel Machek pa...@denx.de wrote:
 Hi!


 +static char *hob_type[] = {
 + reserved,
 + Hand-off,
 + Memory Allocation,
 + Resource Descriptor,
 + GUID Extension,
 + Firmware Volumn,

 volume? ?

 +int do_hob(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 +{
 + EFI_PEI_HOB_POINTERS hob;
 + UINT16 type;
 + char *desc;
 + int i = 0;
 +
 + hob.Raw = (UINT8 *)gd-arch.hob_list;

 + printf(HOB list address: 0x%08x\n\n, (unsigned int)hob.Raw);
 +
 + printf( No. | Address  | Type | Length in Bytes \n);
 + printf(-|--|--|-\n);
 + while (!END_OF_HOB_LIST(hob)) {
 + printf( %-3d | %08x |, i, (unsigned int)hob.Raw);
 + type = hob.Header-HobType;

 Can we get rid of camelCase easily?

 + if (type == EFI_HOB_TYPE_UNUSED)
 + desc = *Unused*;
 + else if (type == EFI_HOB_TYPE_END_OF_HOB_LIST)
 + desc = **END OF HOB**;
 + else if (type = HOB_TYPE_MIN  type = HOB_TYPE_MAX)
 + desc = hob_type[type];
 + else
 + desc = !!!Invalid Type!!!;

 I'd put there less stars and !s...

 +U_BOOT_CMD(
 + hob,1,  1,  do_hob,
 + print FSP Hand-Off Block information,

 You might what to spell out FSP... it is help text after all.


All issues are fixed in the v4 patch @ http://patchwork.ozlabs.org/patch/422204/

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2] powerpc/t1024: add serdes protocol 0x40 and 0x5f

2014-12-17 Thread Shengzhou Liu

Add serdes protocol 0x40 and 0x5f.

Signed-off-by: Shengzhou Liu shengzhou@freescale.com
---
v2: fix a typo.

 arch/powerpc/cpu/mpc85xx/t1024_serdes.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/powerpc/cpu/mpc85xx/t1024_serdes.c 
b/arch/powerpc/cpu/mpc85xx/t1024_serdes.c
index 7dc8385..2ba314a 100644
--- a/arch/powerpc/cpu/mpc85xx/t1024_serdes.c
+++ b/arch/powerpc/cpu/mpc85xx/t1024_serdes.c
@@ -11,6 +11,7 @@
 
 
 static u8 serdes_cfg_tbl[][4] = {
+   [0x40] = {PCIE1, PCIE1, PCIE1, PCIE1},
[0xD5] = {QSGMII_FM1_A, PCIE3, PCIE2, PCIE1},
[0xD6] = {QSGMII_FM1_A, PCIE3, PCIE2, SATA1},
[0x95] = {XFI_FM1_MAC1, PCIE3, PCIE2, PCIE1},
@@ -20,6 +21,7 @@ static u8 serdes_cfg_tbl[][4] = {
[0x56] = {PCIE1, PCIE3, PCIE2, SATA1},
[0x5A] = {PCIE1, PCIE3, SGMII_FM1_DTSEC2, SATA1},
[0x5B] = {PCIE1, PCIE3, SGMII_FM1_DTSEC2, SGMII_FM1_DTSEC1},
+   [0x5F] = {PCIE1, PCIE3, SGMII_2500_FM1_DTSEC2, SGMII_2500_FM1_DTSEC1},
[0x6A] = {PCIE1, SGMII_FM1_DTSEC3, SGMII_FM1_DTSEC2, SATA1},
[0x6B] = {PCIE1, SGMII_FM1_DTSEC3, SGMII_FM1_DTSEC2, SGMII_FM1_DTSEC1},
[0x6F] = {PCIE1, SGMII_FM1_DTSEC3, SGMII_2500_FM1_DTSEC2,
-- 
1.8.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] t1024qds: add missing T1024QDS_defconfig

2014-12-17 Thread Shengzhou Liu

Add missing T1024QDS_defconfig for NOR boot on T1024QDS.

Signed-off-by: Shengzhou Liu shengzhou@freescale.com
---
 configs/T1024QDS_defconfig | 4 
 1 file changed, 4 insertions(+)
 create mode 100644 configs/T1024QDS_defconfig

diff --git a/configs/T1024QDS_defconfig b/configs/T1024QDS_defconfig
new file mode 100644
index 000..94a76ba
--- /dev/null
+++ b/configs/T1024QDS_defconfig
@@ -0,0 +1,4 @@
+CONFIG_SYS_EXTRA_OPTIONS=PPC_T1024
+CONFIG_PPC=y
+CONFIG_MPC85xx=y
+CONFIG_TARGET_T102XQDS=y
-- 
1.8.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 0/9] sf: Update flash params for supported read commands and sector size

2014-12-17 Thread Jagan Teki

On 17 December 2014 at 13:32, Bin Meng bmeng...@gmail.com wrote:
 Hi Jagan,

 On Wed, Dec 17, 2014 at 3:59 PM, Jagan Teki jagannadh.t...@gmail.com wrote:
 On 15 December 2014 at 19:21, Bin Meng bmeng...@gmail.com wrote:
 Hi Jagan,

 On Thu, Dec 11, 2014 at 3:40 PM, Bin Meng bmeng...@gmail.com wrote:
 Hi Jagan,

 On Thu, Dec 11, 2014 at 3:26 PM, Jagan Teki jagannadh.t...@gmail.com 
 wrote:
 Hi Bin,

 On 11 December 2014 at 08:34, Bin Meng bmeng...@gmail.com wrote:
 Hi Jagan,

 On Thu, Dec 11, 2014 at 2:41 AM, Jagan Teki jagannadh.t...@gmail.com 
 wrote:
 Hi Bin,

 On 10 December 2014 at 18:21, Bin Meng bmeng...@gmail.com wrote:
 This series update SPI flash supported read commands per datasheet
 in the flash params table, and change flash sector size to 4KiB as
 long as flash supports sector erase (20h) command, to ensure
 'sf erase offset +len' work on 4KiB boundary instead of 64KiB when
 given SECT_4K.

 Changes in v3:
 - Rebase with Jagan's patch series @ 
 http://patchwork.ozlabs.org/patch/419154/


 Bin Meng (9):
   sf: Update SST flash params
   sf: Update Atmel flash params
   sf: Update EON flash params
   sf: Update GigaDevice flash params
   sf: Update Macronix flash params
   sf: Update Spansion flash params
   sf: Update Micron flash params
   sf: Update Winbond flash params
   sf: Give proper spacing between flash table params

 Thanks for the updates - have you verified these changes?

 I verified some, but not all of these flash parts. The update is based
 on flash datasheet, so if something is broken, eg before this series
 the flash advertises only READ_NORM and after my series it is changed
 to READ_FULL, and let's say QUAD_IO_FAST is not working, it is very
 likely that the SPI controller driver has some bugs when supporting
 QUAD_IO_FAST.

 Since these updates were tested before, I will skip these for this PR.
 Will test all the rest (except these) and send the PR soon.

 Let me know your inputs?

 I am fine, as long as this PR will not contains other commits which
 modify the same sf_params.c to introduce more flash support. We can
 test these updates and if everything looks fine, apply these first and
 ask other commits to rebase on this series to introduce more flash
 support.


 Do you have any additional comments about this patch series besides
 the S25FL128S_64K and S25FL256S_64K sector size? If not, I can send
 the v4.

 I'm thinking about the other flashes too,  since these params were taken from
 previous working and Linux mtd.


 You mean 'thinking about' or 'testing'? I should say previously they
 might not be 100% working as per datasheet some flash params currently
 are apparently wrong.

Yes - about testing.

thanks!
-- 
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] fat: scripts for prepare and test read fat files

2014-12-17 Thread Przemyslaw Marczak


Hello Simon,

On 12/16/2014 09:41 PM, Simon Glass wrote:

Hi Przemyslaw,

On 12 December 2014 at 08:54, Przemyslaw Marczak p.marc...@samsung.com wrote:


Hello,


On 12/12/2014 04:52 PM, Przemyslaw Marczak wrote:


-
mktest_files: script for generating random size long name files
-
Usage:
./1_mktest_files.sh count

count - number of files to be generated

The output directory is: ./test_files

-
copy_files: copy the test_files/* into test partition mount point
-
Usage:
./2_copy_files.sh mount_point

---
fat_test.sh: test fat read by write commands to the device console
--
This script send commands to U-Boot console.
First specify few script variables, e.g:
- TTY=/dev/ttyS0
- MMCDEV=0
- PARTITION=2
- LOAD_ADDR=0x4000

usage:
1. Target:
 run: ums 0 mmc 0
2. Run script 1 and 2 to make and copy the test files
 onto the test partition by UMS
3. This script:
 - set test device $PARTITION and other variables in the script,
   which is required for sending proper commands
 - set $TTY in the script
 run: ./3_fat_test.sh
4. Compare the crc results on the target and device consoles
 (sorry for the mess on the console)

Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
---
   1_mktest_files.sh | 82 
+++
   2_copy_files.sh   | 20 ++
   3_fat_test.sh | 38 ++
   3 files changed, 140 insertions(+)
   create mode 100755 1_mktest_files.sh
   create mode 100755 2_copy_files.sh
   create mode 100755 3_fat_test.sh



This is just for some quick test.
I will add something more pretty to the sandbox.


Perhaps this should be written in Python? We now have quite a few
tests and it's getting to the point where we might want to have a way
to run them all, check results, etc. That would be easier if we could
import them through some standard interface. For now, perhaps we
should avoid shell scripts except for really trivial things.

You can bring in the patman libraries (we could break these out into
another dir but it doesn't seem important):

import os
import sys

# Bring in the patman libraries
our_path = os.path.dirname(os.path.realpath(__file__))
sys.path.append(os.path.join(our_path, 'tools/patman'))

import command

The, for example:
print command.Output('ls', '-l')

Regards,
Simon



The patch fixes the issue with the hidden files, so for looking the 
issue on some other cases I made some simple script. I understand that 
this is not good for a U-Boot tests, and I agree that better is to write 
something automated in the Python for the sandbox.

I think that the fix should be merged.
I can write the test for the sandbox in a free time, but it will take a 
moment, because now I would like to focus on the pmic framework.

The pmic was on hold for too long.

Best regards,
--
Przemyslaw Marczak
Samsung RD Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] fs: fat: read: fix fat16 ls/read issue

2014-12-17 Thread Przemyslaw Marczak

Hello,

On 12/16/2014 11:26 PM, Simon Glass wrote:

Hi Przemyslaw,

On 12 December 2014 at 08:30, Przemyslaw Marczak p.marc...@samsung.com wrote:

Hello,

On 12/12/2014 01:32 AM, Simon Glass wrote:

Hi Przemyslaw,

On 11 December 2014 at 05:01, Przemyslaw Marczak p.marc...@samsung.com
wrote:

The present fat implementation ignores FAT16 long name
directory entries which aren't placed in a single sector.

This was becouse of the buffer was always filled by the
two sectors, and the loop was made also for two sectors.

If some file long name entries are stored in two sectors,
the we have two cases:

Case 1:
Both of sectors are in the buffer - all required data
for long file name is in the buffer.
- Read OK!

Case 2:
The current directory entry is placed at the end of the
second buffered sector. And the next entries are placed
in a sector which is not buffered yet. Then two next
sectors are buffered and the mentioned entry is ignored.
- Read fail!

This commit fixes this issue by:
- read two sectors after loop on each single is done
- keep the last used sector as a first in the buffer
before the read of two next

The commit doesn't affects the fat32 imlementation,
which works good as previous.

This is very interesting\! Is this the same failure that I saw on this
thread?

http://u-boot.10912.n7.nabble.com/PATCH-U-Boot-ARM-rpi-b-detect-board-revision-td196720.html

(search for fatload)

I tried this out. It worked OK for me except that it can't find the
device tree file bcm2835-rpi-b-rev2.dtb.

Oddly I can fatload it from /bcm2835-rpi-b-rev2.dtb but when I try
from /syslinux/..//bcm2835-rpi-b-rev2.dtb it fails and cannot find the
file. Reducing the filename length to 8 chars works. I wonder what
year of my life FAT will stop plaguing me?

Also can you write a test for this in test/fs/fs-test.sh?

Regards,
Simon

[snip]

Probably this is an another case which is caused by the sector buffer bug.
Does this patch fixed your issue?

I have some simple test for manual use with the ums tool.
It just copy the test files to the tested fat16 partition mounted using the
UMS, next it computes CRC32 of those files on the host and next using U-Boot
fatload/crc32 commands - it tests the read feature. But it's not full
automated - I didn't work on getting the log from U-Boot console.

So I could check if the file checksums are proper and if all files were
found on the partiion, by the U-Boot read command. It's not useful for the
test/fs/fs-test.sh because this is not designed for the sandbox.
My test writes some commands directly to U-Boot console, like this: echo
some cmd /dev/ttyS0.

Unfortunately the sandbox config seems to be broken.

The bug was not so obvious, any read/write on fat partition can change fat
directory entries or add the new ones and then all data can be read right.

I will send the scripts for such simple test.

I'm not sure if it fixes my problem but it seems likely. I will see if
I can make time to test it.

If you want to write input data to U-Boot sandbox we can do that
fairly easily. You can import cros_subprocess and use the function
there to generate output from your test and inspect the input from
U-Boot's command line. Let me know if you'd like an example.

Regards,
Simon

It sounds good. I can do that, as I wrote in my previous message, now
I'm focused on the pmic, and this will be a side task for a break time.
I will look into the present tests and I think, that I will find an
example there.

Best regards,
--
Przemyslaw Marczak
Samsung RD Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot