From: Heiko Schocher <hs@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] Porting UBI fixes (specially fastmap's) to U-Boot
Date: Thu, 8 Oct 2015 16:54:29 +0200 [thread overview]
Message-ID: <561683A5.6060000@denx.de> (raw)
In-Reply-To: <56166992.2020004@nod.at>
Hello Richard,
Am 08.10.2015 um 15:03 schrieb Richard Weinberger:
> Hi!
>
> Am 08.10.2015 um 14:51 schrieb Heiko Schocher:
>> Hello Ezequiel, Richard,
>>
>> Am 02.10.2015 um 18:27 schrieb Ezequiel Garcia:
>>> Hello Heiko,
>>>
>>> According to Richard Weinberger, UBI fastmap is broken in U-Boot.
>>> There are plenty
>>> of fixes in Linux that we should pull in U-Boot to fix it.
>>>
>>> Maybe you are already aware of this and you have some work-in-progress
>>> patches to share?
>>> Otherwise, I might be able to spend some time working on this in the next weeks.
>>
>> I just tried to do this port ... but stumbled over some issues, I just try to
>> looking at ... but running out of time for doing more ...
>>
>> - ubifastmap needs now scatterlist ... we have no support for this
>> currently in U-Boot.
>
> Huh?
>
> We have support for that in UBI. But the only user is UBI block.
Ah... maybe I can drop it, great!
Fixed, dropped.
>> - I get some bogus compilerwarnings:
>>
>> CC drivers/mtd/ubi/fastmap-wl.o
>> drivers/mtd/ubi/fastmap-wl.c:69:3: warning: implicit declaration of function 'wl_tree_add' [-Wimplicit-function-declaration]
>>
>> wl_tree_add is declared static here:
>> http://lxr.free-electrons.com/source/drivers/mtd/ubi/wl.c#L152
>>
>> but called from fastmap-wl.c
>> http://lxr.free-electrons.com/source/drivers/mtd/ubi/fastmap-wl.c#L64
>
> wl.c has a "#include "fastmap-wl.c".
Ah, right ... got it, fixed.
>> same for:
>> find_mean_wl_entry
>> self_check_in_wl_tree
>> wl_get_wle
>> find_wl_entry
>> prot_queue_add
>> schedule_ubi_work
>> schedule_erase
>>
>> drivers/mtd/ubi/fastmap-wl.c: In function 'ubi_is_erase_work':
>> drivers/mtd/ubi/fastmap-wl.c:340:1: warning: control reaches end of non-void function [-Wreturn-type]
>>
>> :-(
>
> ???
>
> /**
> * ubi_is_erase_work - checks whether a work is erase work.
> * @wrk: The work object to be checked
> */
> int ubi_is_erase_work(struct ubi_work *wrk)
> {
> return wrk->func == erase_worker;
> }
>
>
>> Does this warnings not occur when compiling linux with fastmap support?
>
> Nope. But I'm not using fancy new compilers/flags.
Hmm.. have to look into it...
>
>> I used as base for porting ubi/ubifs from linux:
>>
>> commit 64291f7db5bd8150a74ad2036f1037e6a0428df2
>> Author: Linus Torvalds <torvalds@linux-foundation.org>
>> Date: Sun Aug 30 11:34:09 2015 -0700
>>
>> Linux 4.2
>
> Just checked v4.2
>
>>
>> @Richard: a first change for U-Boot wish:
>>
>> You used here and there sometimes "free" as an variable name ... for example:
>> in "drivers/mtd/ubi/fastmap.c"
>>
>> static int scan_pool(struct ubi_device *ubi, struct ubi_attach_info *ai,
>> int *pebs, int pool_size, unsigned long long *max_sqnum,
>> struct list_head *free)
>>
>> compiling this under U-Boot drops:
>>
>> CC drivers/mtd/ubi/fastmap.o
>> drivers/mtd/ubi/fastmap.c: In function 'scan_pool':
>> drivers/mtd/ubi/fastmap.c:475:3: error: called object 'free' is not a function
>
> Which gcc warning-flag triggers that?
Good question! I am not sure, if it is a flag ... why "called object" ...
>> (line number differs from mainline, because I added some U-Boot specific
>> line above)
>>
>> Could we rename this var to something else ... like for example "pfree" ?
>> I can prepare a patch for linux, if this would be Ok for you.
>
> Unless I'm mistaken this is fine in C.
Yes, it looks fine, do not understand this ...
> So, what exactly is the problem here?
Compiling stops, as it is an "error" ... renaming this var, and error
go away ...
Currently I have a (with warnings) compiled U-Boot with ubi/ubifs
with linux 4.2 base ... now testing (or tomorrow)
Thanks for your help!
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
next prev parent reply other threads:[~2015-10-08 14:54 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-02 16:27 [U-Boot] Porting UBI fixes (specially fastmap's) to U-Boot Ezequiel Garcia
2015-10-02 18:46 ` Richard Weinberger
2015-10-03 4:27 ` Heiko Schocher
2015-10-03 9:03 ` Richard Weinberger
2015-10-08 12:51 ` Heiko Schocher
2015-10-08 13:03 ` Richard Weinberger
2015-10-08 14:54 ` Heiko Schocher [this message]
2015-10-08 14:58 ` Hans de Goede
2015-10-08 16:04 ` Richard Weinberger
2015-10-09 3:34 ` Heiko Schocher
2015-10-08 15:54 ` Ezequiel Garcia
2015-10-09 4:01 ` Heiko Schocher
2015-10-09 12:30 ` Heiko Schocher
2015-10-16 7:56 ` Heiko Schocher
2015-10-16 11:58 ` Ezequiel Garcia
2015-10-17 18:07 ` Ezequiel Garcia
2015-10-17 18:28 ` Richard Weinberger
2015-10-19 5:17 ` Heiko Schocher
2015-10-19 13:47 ` Ezequiel Garcia
2015-10-19 14:53 ` Heiko Schocher
2015-10-19 20:22 ` Richard Weinberger
2015-10-19 21:40 ` Ezequiel Garcia
2015-10-19 21:48 ` Richard Weinberger
2015-10-20 4:00 ` Heiko Schocher
2015-10-20 7:16 ` Richard Weinberger
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=561683A5.6060000@denx.de \
--to=hs@denx.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 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.