From: Soeren Moch <smoch@web.de>
To: u-boot@lists.denx.de
Subject: [PATCH 07/11] env: Enable SPI flash env for rockchip
Date: Fri, 27 Dec 2019 11:30:05 +0100 [thread overview]
Message-ID: <ee58a8ea-89b1-4b9c-53e3-74c112e66fb4@web.de> (raw)
In-Reply-To: <CAMty3ZDQptk4NJkLfdGiygQMTdLNhSWOxNu57OOf-DpUhFndtA@mail.gmail.com>
Hi!
On 27.12.19 07:50, Jagan Teki wrote:
> Hi Kever,
>
> On Mon, Dec 23, 2019 at 8:04 AM Kever Yang <kever.yang@rock-chips.com> wrote:
>>
>> Jagan,
>>
>>
>> On 2019/12/21 下午3:54, Jagan Teki wrote:
>>> Most of the SPI flash devices in rockchip are 16MiB size.
>>>
>>> So, keeping U-Boot proper offset start from 128MiB with 1MiB
>>> size and then start env of 8KiB would be a compatible location
>>> between all variants of flash sizes.
>>>
>>> This patch add env start from 0x14000 with a size of 8KiB.
>>
>> What's the space map in SPI flash suppose to be? Including
>> tpl/spl/u-boot.itb
>>
>> I would prefer to use 128KiB-8KiB as the env start address, we'd better
>> to avoid the
>>
>> risk of overlap between the env space and the firmware space.
>
> Here is the 16MiB flash layout, I have used. I can see the loader1
> (tpl/spl) can be possible to load at 0x0 or 0x32K so I have given the
> space for it. and 8K env after loader2(u-boot). let me know your
> thoughts?
Why we cannot use the same layout as what is defined for SD/eMMC:
http://opensource.rock-chips.com/wiki_Partitions
>
> 0x0 - 0x8000, 32K => reserved/loader1
> 0x8000 - 0x40000, 224K => loader1
> 0x40000 - 0x140000, 1M => loader2
> 0x140000 - 0x142000, 8K => env
> 0x142000 - 0x842000, 7M => kernel
> 0x842000 - 0x853800, 100K => dtb
> 0x853800 - => root
These small loader1/loader2 partitions may byte us later when newer
u-boot versions only will fit for SD and not for SPI anymore.
The reserved space for kernel is already too small for normal kernel
builds today, not to mention a root filesystem.
Are there any use cases where somebody needs to place boot and root
partitions on SPI flash?
Regards,
Soeren
next prev parent reply other threads:[~2019-12-27 10:30 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-21 7:54 [PATCH 00/11] rk3399: SPI boot support (fixes, updates) Jagan Teki
2019-12-21 7:54 ` [PATCH 01/11] spi: rk: Limit transfers to (64K - 1) bytes Jagan Teki
2019-12-23 2:30 ` Kever Yang
2019-12-27 5:55 ` Jagan Teki
2019-12-21 7:54 ` [PATCH 02/11] distro_bootcmd: Add SF support Jagan Teki
2019-12-30 3:07 ` Kever Yang
2020-01-20 17:22 ` Tom Rini
2020-01-20 17:40 ` Alexander Graf
2020-01-23 16:55 ` Jagan Teki
2020-01-23 17:03 ` Tom Rini
2020-01-23 17:11 ` Jagan Teki
2020-01-23 17:15 ` Tom Rini
2020-01-23 17:29 ` Jagan Teki
2020-01-23 17:59 ` Tom Rini
2019-12-21 7:54 ` [PATCH 03/11] rockchip: Include SF on distrocmd devices Jagan Teki
2020-01-07 8:44 ` Kever Yang
2019-12-21 7:54 ` [PATCH 04/11] rk3399: Add boot flash script offet, size Jagan Teki
2019-12-30 3:06 ` Kever Yang
2019-12-21 7:54 ` [PATCH 05/11] rk3399: Check MMC env while defining it Jagan Teki
2019-12-30 3:06 ` Kever Yang
2019-12-21 7:54 ` [PATCH 06/11] env: kconfig: Restrict rockchip env for MMC Jagan Teki
2019-12-30 3:05 ` Kever Yang
2019-12-21 7:54 ` [PATCH 07/11] env: Enable SPI flash env for rockchip Jagan Teki
2019-12-23 2:34 ` Kever Yang
2019-12-27 6:50 ` Jagan Teki
2019-12-27 10:02 ` Kever Yang
2019-12-27 10:10 ` Jagan Teki
2019-12-27 10:30 ` Soeren Moch [this message]
2019-12-27 12:04 ` Jagan Teki
2019-12-27 13:19 ` Soeren Moch
2019-12-28 12:08 ` Jagan Teki
2019-12-30 9:04 ` Soeren Moch
2019-12-30 2:59 ` Kever Yang
2019-12-21 7:54 ` [PATCH 08/11] rockchip: dts: Sync ROC-RK3399-PC changes from Linux Jagan Teki
2019-12-30 3:00 ` Kever Yang
2019-12-21 7:54 ` [PATCH 09/11] roc-pc-rk3399: Enable SPI Flash Jagan Teki
2019-12-30 3:00 ` Kever Yang
2019-12-21 7:54 ` [PATCH 10/11] rockpro-rk3399: " Jagan Teki
2019-12-30 3:00 ` Kever Yang
2019-12-30 11:51 ` Emmanuel Vadot
2020-01-08 12:59 ` Jagan Teki
2019-12-21 7:54 ` [PATCH 11/11] roc-rk3399-pc: Add SPI boot support Jagan Teki
2019-12-30 3:05 ` Kever Yang
2019-12-30 7:52 ` Jagan Teki
2020-01-07 8:53 ` Kever Yang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ee58a8ea-89b1-4b9c-53e3-74c112e66fb4@web.de \
--to=smoch@web.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox