All of lore.kernel.org
 help / color / mirror / Atom feed
* [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

* [U-Boot] uboot to read kernel and rootfs from a bootfs.
       [not found]   ` <CAGVhguGjKWY+qaHmfCRSZfSRSsGG8Gep2BV6-gKx6zDCoU0obg@mail.gmail.com>
@ 2018-11-21 15:38     ` Wolfgang Denk
  0 siblings, 0 replies; 3+ messages in thread
From: Wolfgang Denk @ 2018-11-21 15:38 UTC (permalink / raw)
  To: u-boot

Dear Michael,

In message <CAGVhguGjKWY+qaHmfCRSZfSRSsGG8Gep2BV6-gKx6zDCoU0obg@mail.gmail.com> you wrote:
>
> as I asked in my email... since I'm using spi-flash for the fs access, it
> seems I'll need to use the DM_SPI_FLASH support.

For new code, yes.

> I'm using the 2017.09 version of u-boot with openembedded/poky and the 4.4
> kernel
>
> would it be worth me using a newer version of u-boot? would that give me
> better support of my spi-flash?

You should always go with top-of-tree from the respective mainline
repositoruy for any new developments.

> my board is basically an am335x_evm with an is25lp512 nor spi-flash instead
> of emmc.

SPI NOR is used on a zillion of boards and should work pretty well.

> when I tried to turn on the dm flash support it didn't compile. just
> wondering if that is supported more thouroughly in
> newer versions of u-boot.....

sorry, I don't know.  Again, here the ML is a much better reource to
ask such things.

In any case you should not use JFFS2 any more; it is really, really
dead code.

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
Der Dativ ist dem Genitiv sein Tod.

^ 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.