u-boot.git/drivers/mtd, branch v2018.07-rc2 Unnamed repository; edit this file 'description' to name the repository. spi: sandbox: Fix memory leak in sandbox_sf_bind_emul() 2018-06-19T11:31:44+00:00 Simon Glass sjg@chromium.org 2018-06-12T06:05:01+00:00 fb95283931011aef78d885f2799ad9d7367f4e48 Move the strdup() call so that it is only done when we know we will bind the device. Reported-by: Coverity (CID: 131216) Signed-off-by: Simon Glass <sjg@chromium.org> 
Move the strdup() call so that it is only done when we know we will bind
the device.

Reported-by: Coverity (CID: 131216)

Signed-off-by: Simon Glass <sjg@chromium.org>
lib: Add hexdump 2018-06-13T11:49:12+00:00 Alexey Brodkin Alexey.Brodkin@synopsys.com 2018-06-05T14:17:57+00:00 f8c987f8f127f867d96ca74bcd1fcb11d8265b67 Often during debugging session it's very interesting to see what data we were dealing with. For example what we write or read to/from memory or peripherals. This change introduces functions that allow to dump binary data with one simple function invocation like: ------------------->8---------------- print_hex_dump_bytes("", DUMP_PREFIX_OFFSET, buf, len); ------------------->8---------------- which gives us the following: ------------------->8---------------- 00000000: f2 b7 c9 88 62 61 75 64 72 61 74 65 3d 31 31 35 ....baudrate=115 00000010: 32 30 30 00 62 6f 6f 74 61 72 67 73 3d 63 6f 6e 200.bootargs=con 00000020: 73 6f 6c 65 3d 74 74 79 53 33 2c 31 31 35 32 30 sole=ttyS3,11520 00000030: 30 6e 38 00 62 6f 6f 74 64 65 6c 61 79 3d 33 00 0n8.bootdelay=3. 00000040: 62 6f 6f 74 66 69 6c 65 3d 75 49 6d 61 67 65 00 bootfile=uImage. 00000050: 66 64 74 63 6f 6e 74 72 6f 6c 61 64 64 72 3d 39 fdtcontroladdr=9 00000060: 66 66 62 31 62 61 30 00 6c 6f 61 64 61 64 64 72 ffb1ba0.loadaddr 00000070: 3d 30 78 38 32 30 30 30 30 30 30 00 73 74 64 65 =0x82000000.stde 00000080: 72 72 3d 73 65 72 69 61 6c 30 40 65 30 30 32 32 rr=serial0@e0022 00000090: 30 30 30 00 73 74 64 69 6e 3d 73 65 72 69 61 6c 000.stdin=serial 000000a0: 30 40 65 30 30 32 32 30 30 30 00 73 74 64 6f 75 0@e0022000.stdou 000000b0: 74 3d 73 65 72 69 61 6c 30 40 65 30 30 32 32 30 t=serial0@e00220 000000c0: 30 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00.............. ... ------------------->8---------------- Source of hexdump.c was copied from Linux kernel v4.7-rc2. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Anatolij Gustschin <agust@denx.de> Cc: Mario Six <mario.six@gdsys.cc> Cc: Simon Glass <sjg@chromium.org> Cc: Tom Rini <trini@konsulko.com> Cc: Stefan Roese <sr@denx.de> 
Often during debugging session it's very interesting to see
what data we were dealing with. For example what we write or read
to/from memory or peripherals.

This change introduces functions that allow to dump binary
data with one simple function invocation like:
------------------->8----------------
print_hex_dump_bytes("", DUMP_PREFIX_OFFSET, buf, len);
------------------->8----------------

which gives us the following:
------------------->8----------------
00000000: f2 b7 c9 88 62 61 75 64 72 61 74 65 3d 31 31 35  ....baudrate=115
00000010: 32 30 30 00 62 6f 6f 74 61 72 67 73 3d 63 6f 6e  200.bootargs=con
00000020: 73 6f 6c 65 3d 74 74 79 53 33 2c 31 31 35 32 30  sole=ttyS3,11520
00000030: 30 6e 38 00 62 6f 6f 74 64 65 6c 61 79 3d 33 00  0n8.bootdelay=3.
00000040: 62 6f 6f 74 66 69 6c 65 3d 75 49 6d 61 67 65 00  bootfile=uImage.
00000050: 66 64 74 63 6f 6e 74 72 6f 6c 61 64 64 72 3d 39  fdtcontroladdr=9
00000060: 66 66 62 31 62 61 30 00 6c 6f 61 64 61 64 64 72  ffb1ba0.loadaddr
00000070: 3d 30 78 38 32 30 30 30 30 30 30 00 73 74 64 65  =0x82000000.stde
00000080: 72 72 3d 73 65 72 69 61 6c 30 40 65 30 30 32 32  rr=serial0@e0022
00000090: 30 30 30 00 73 74 64 69 6e 3d 73 65 72 69 61 6c  000.stdin=serial
000000a0: 30 40 65 30 30 32 32 30 30 30 00 73 74 64 6f 75  0@e0022000.stdou
000000b0: 74 3d 73 65 72 69 61 6c 30 40 65 30 30 32 32 30  t=serial0@e00220
000000c0: 30 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00  00..............
...
------------------->8----------------

Source of hexdump.c was copied from Linux kernel v4.7-rc2.

Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Anatolij Gustschin <agust@denx.de>
Cc: Mario Six <mario.six@gdsys.cc>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Stefan Roese <sr@denx.de>
Merge branch 'master' of git://git.denx.de/u-boot-ubi 2018-06-08T14:08:20+00:00 Tom Rini trini@konsulko.com 2018-06-08T14:08:20+00:00 813d1fb56dc0af9567feb86cd71c49f14662044b 






mtd: ubi: Add missing newlines in ubi_init()
2018-06-06T08:25:13+00:00

Stefan Roese
sr@denx.de

2018-05-29T13:28:54+00:00

78306cba118e718a3b429695ac48846b9d9afeff

I just stumbled over some cluttered UBI messages. It seems some newline
chars are missing in the current U-Boot UBI source. Lets fix this
in U-Boot as well (Linux has those fixes already).

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Heiko Schocher <hs@denx.de>





I just stumbled over some cluttered UBI messages. It seems some newline
chars are missing in the current U-Boot UBI source. Lets fix this
in U-Boot as well (Linux has those fixes already).

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Heiko Schocher <hs@denx.de>







sf: Add support for gd25q32b gigadevice flash
2018-06-04T18:10:04+00:00

Carlo Caione
carlo@endlessm.com

2018-06-02T13:06:17+00:00

b1f2b72e39465f2d4582bb4d8c426489ee94e2d9

This flash IC is used in some chromebook models
manufactured by Bitland.

Signed-off-by: Carlo Caione <carlo@endlessm.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>





This flash IC is used in some chromebook models
manufactured by Bitland.

Signed-off-by: Carlo Caione <carlo@endlessm.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>







sf: Set current flash bank to 0 in clean_bar()
2018-06-04T18:01:37+00:00

Marek Vasut
marex@denx.de

2018-05-24T19:58:40+00:00

8ff4130debcc09594b550209c44abf6c7e3ee595

The clean_bar() function resets the SPI NOR BAR register to 0, but
does not set the flash->curr_bar to 0 , therefore those two can get
out of sync, which could ultimatelly result in corrupted flash content.

The simplest test case is this:

  => mw 0x10000000 0x1234abcd 0x4000
  => sf probe
  => sf erase 0x1000000 0x10000
  => sf write 0x10000000 0x1000000 0x10000

  => sf probe ; sf read 0x12000000 0 0x10000 ; md 0x12000000

That is, erase a sector above the 16 MiB boundary and write it with
random pre-configured data. What will actually happen without this
patch is the sector will be erased, but the data will be written to
BAR 0 offset 0x0 in the flash.

This is because the erase command will call write_bar()+clean_bar(),
which will leave flash->bank_curr = 1 while the hardware BAR registers
will be set to 0 through clean_bar(). The subsequent write will also
trigger write_bar()+clean_bar(), but write_bar checks if the target
bank == flash->bank_curr and if so, does NOT reconfigure the BAR in
the SPI NOR. Since flash->bank_curr is still 1 and out of sync with
the HW, the condition matches, BAR programming is skipped and write
ends up at address 0x0, thus corrupting flash content.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>





The clean_bar() function resets the SPI NOR BAR register to 0, but
does not set the flash->curr_bar to 0 , therefore those two can get
out of sync, which could ultimatelly result in corrupted flash content.

The simplest test case is this:

  => mw 0x10000000 0x1234abcd 0x4000
  => sf probe
  => sf erase 0x1000000 0x10000
  => sf write 0x10000000 0x1000000 0x10000

  => sf probe ; sf read 0x12000000 0 0x10000 ; md 0x12000000

That is, erase a sector above the 16 MiB boundary and write it with
random pre-configured data. What will actually happen without this
patch is the sector will be erased, but the data will be written to
BAR 0 offset 0x0 in the flash.

This is because the erase command will call write_bar()+clean_bar(),
which will leave flash->bank_curr = 1 while the hardware BAR registers
will be set to 0 through clean_bar(). The subsequent write will also
trigger write_bar()+clean_bar(), but write_bar checks if the target
bank == flash->bank_curr and if so, does NOT reconfigure the BAR in
the SPI NOR. Since flash->bank_curr is still 1 and out of sync with
the HW, the condition matches, BAR programming is skipped and write
ends up at address 0x0, thus corrupting flash content.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>







Merge branch 'master' of git://git.denx.de/u-boot-spi
2018-05-30T18:51:37+00:00

Tom Rini
trini@konsulko.com

2018-05-30T18:51:37+00:00

8ada17dde84954e36d8bc6ff62a6956686eb0ec4

- Fix a conflict in drivers/spi/atcspi200_spi.c related to the riscv
  tree fixing a warning.

Signed-off-by: Tom Rini <trini@konsulko.com>





- Fix a conflict in drivers/spi/atcspi200_spi.c related to the riscv
  tree fixing a warning.

Signed-off-by: Tom Rini <trini@konsulko.com>







Merge git://git.denx.de/u-boot-riscv
2018-05-30T12:43:04+00:00

Tom Rini
trini@konsulko.com

2018-05-30T12:43:04+00:00

964d4f7211ec85b890e852d0226adba0b4f8c1c9












mtd: ftsmc020: Drop unsed code
2018-05-29T06:45:04+00:00

Rick Chen
rick@andestech.com

2018-05-29T03:10:56+00:00

9171ab8836511ab1e65e120b7288acd6d5baac70

ftsmc020_init is not used anymore.
So it can be removed.

Signed-off-by: Rick Chen <rick@andestech.com>
Signed-off-by: Rick Chen <rickchen36@gmail.com>
Cc: Greentime Hu <green.hu@gmail.com>





ftsmc020_init is not used anymore.
So it can be removed.

Signed-off-by: Rick Chen <rick@andestech.com>
Signed-off-by: Rick Chen <rickchen36@gmail.com>
Cc: Greentime Hu <green.hu@gmail.com>







sf: Add Macronix MX25U25635F ID
2018-05-29T04:35:52+00:00

Marek Vasut
marex@denx.de

2018-05-17T12:49:03+00:00

a2569f12f0efaad2b1e0754a19f373275562f91e

Add ID for the Macronix MX25U25635F flash.

Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Jagan Teki <jagan@openedev.com>





Add ID for the Macronix MX25U25635F flash.

Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Jagan Teki <jagan@openedev.com>