* [U-Boot] uboot to read kernel and rootfs from a bootfs.
@ 2018-11-20 19:26 C Michael Sundius
2018-11-21 8:35 ` Wolfgang Denk
0 siblings, 1 reply; 3+ messages in thread
From: C Michael Sundius @ 2018-11-20 19:26 UTC (permalink / raw)
To: u-boot
we are supporting several platforms and have a well established format and
set of tools for upgrading our images and rolling back to prior images upon
upgrade failure.
that said we'd like to use the same layout for our boot file system and not
mtd partitions for
kernel, rootfs etc.
to boot we read the kernel and a squashfs rootfs and boot them. we'd like
to have u-boot do the same. on intel of course our bootfs is a fat file
system, on our arm platform we have a spi-(nor)-flash
which holds the persistent memory so we'll have to put the boot fs there.
like this:
device nor0 <is25lp512-flash.0>, # parts = 6
#: name size offset mask_flags
0: SPL 0x00020000 0x00000000 0
1: u-boot 0x00080000 0x00020000 0
2: fdt 0x00020000 0x000a0000 0
3: u-boot-env1 0x00020000 0x000c0000 0
4: u-boot-env2 0x00020000 0x000e0000 0
5: bootfs 0x03f00000 0x00100000 0
we were thinking that jffs2 would be best for the bootfs since we gain the
wear leveling. There are really only a few files in the bootfs and not much
r/w activity except on upgrades of images and boot, so I don't think we'll
have a problem mount time or gc,
I looked briefly at ubifs but it seems that uses abotu 10% more space and
we are really looking to be close on space so I am avoiding this.
of course we could stick w/ fat, but of course that does not give us the
wear leveling.
My questions:
1) does u-boot support the use of jffs2 on spi-nor-flash? seems like I get
the error:
get_fl_mem: unknown device type, using raw offset!
when I try to read the fsinfo or fsls. if I just remove that error allowing
get_fl_mem() to return the offset, then I get all 0 and I don't think its
reading the correct data.
should I have CONFIG_CMD_FLASH turned on? was thinking that that was for
"nor" flash that is direct mapped. rather than spi
2) Is jffs2 still supported or should I be using ubi? or maybe just use the
fatfs... if I am largely filling up the flash with my bootfs, then does it
really mater if I'm wear leveling? will I run into fragmentation problems
w/ fat?
^ permalink raw reply [flat|nested] 3+ messages in thread
* [U-Boot] uboot to read kernel and rootfs from a bootfs.
2018-11-20 19:26 [U-Boot] uboot to read kernel and rootfs from a bootfs C Michael Sundius
@ 2018-11-21 8:35 ` Wolfgang Denk
[not found] ` <CAGVhguGjKWY+qaHmfCRSZfSRSsGG8Gep2BV6-gKx6zDCoU0obg@mail.gmail.com>
0 siblings, 1 reply; 3+ messages in thread
From: Wolfgang Denk @ 2018-11-21 8:35 UTC (permalink / raw)
To: u-boot
Dear Michael,
In message <CAGVhguFAT+hAgOK1D-eQ5-C=mS09H-ZHaqhbR1yrDbeYfnT9Vw@mail.gmail.com> you wrote:
>
> we were thinking that jffs2 would be best for the bootfs since we gain the
> wear leveling. There are really only a few files in the bootfs and not much
> r/w activity except on upgrades of images and boot, so I don't think we'll
> have a problem mount time or gc,
JFFS2 is a dead horse. Use UBI/UBIFS instead.
> I looked briefly at ubifs but it seems that uses abotu 10% more space and
> we are really looking to be close on space so I am avoiding this.
Use UBIFS.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It is surely a great calamity for a human being to have no ob-
sessions. - Robert Bly
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2018-11-21 15:38 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-11-20 19:26 [U-Boot] uboot to read kernel and rootfs from a bootfs C Michael Sundius
2018-11-21 8:35 ` Wolfgang Denk
[not found] ` <CAGVhguGjKWY+qaHmfCRSZfSRSsGG8Gep2BV6-gKx6zDCoU0obg@mail.gmail.com>
2018-11-21 15:38 ` Wolfgang Denk
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox