* Re: Representing Embedded Architectures at the Kernel Summit
From: Paul Mundt @ 2009-06-18 2:51 UTC (permalink / raw)
To: Kumar Gala
Cc: James Bottomley, ksummit-2009-discuss, linux-arch, linux-embedded
In-Reply-To: <BE4622E9-611A-4D56-BB54-3C7786939CF2@kernel.crashing.org>
On Wed, Jun 17, 2009 at 09:31:48AM -0500, Kumar Gala wrote:
> One topic that was partially touched on was dealing with various
> memories on embedded systems. We have several sram based allocators
> in the kernel for various different arch's:
>
> - Blackfin sram allocator arch/blackfin/mm/sram-alloc.c
> - Lite5200(b) sram allocator arch/powerpc/sysdev/bestcomm/sram.c
> - AVR32 sram allocator arch/avr32/mach-at32ap/at32ap700x.c and arch/
> avr32/mach-at32ap/include/mach/sram.h
> - Potential davinci sram allocator
>
> There maybe others.
>
SH does this through NUMA on SRAM blocks that are anywhere from 128kB to
64MB. Some of our SMP configurations have upwards of a dozen of these
blocks.
^ permalink raw reply
* CDC ACM composite gadget serial not working between Linux and Windows?
From: Daniel Ng @ 2009-06-18 2:09 UTC (permalink / raw)
To: linux-embedded
Hi,
I've found this comment in f_acm.c, 2.6.27:
* Note that even MS-Windows has some support for ACM. However, that
* support is somewhat broken because when you use ACM in a composite
* device, having multiple interfaces confuses the poor OS. It doesn't
* seem to understand CDC Union descriptors. The new "association"
* descriptors (roughly equivalent to CDC Unions) may sometimes help.
Does this mean I will not be able to successfully connect a Linux box
to a Windows PC via the Linux box's CDC ACM composite gadget serial
driver?
Also, there are direct references to the composite driver in f_acm.c,
which tells me the following:
-In Linux (2.6.27), a CDC ACM gadget serial driver MUST be a composite
driver as well.
Is this true? If so why is such tight coupling required?
Please suggest an alternate list if this message is inappropriate for this list.
Cheers,
Daniel
^ permalink raw reply
* Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
From: Chris Friesen @ 2009-06-17 18:32 UTC (permalink / raw)
To: Marco; +Cc: Linux FS Devel, Linux Embedded, linux-kernel, Daniel Walker
In-Reply-To: <4A33A7A2.1050608@gmail.com>
Marco wrote:
> This is a second attempt at mainlining Pramfs. The first attempt was
> back in early 2004 by MontaVista. Since then the kernel code has almost
> been completely rewritten. So my first item on the list was porting the
> code on a recent kernel version. After that I added the XIP support.
>
> Now some FAQs:
>
> What is the goal of this filesystem?
>
> Many embedded systems have a block of non-volatile RAM separate from
> normal system memory, i.e. of which the kernel maintains no memory page
> descriptors. For such systems it would be beneficial to mount a
> fast read/write filesystem over this "I/O memory", for storing
> frequently accessed data that must survive system reboots and power
> cycles. An example usage might be system logs under /var/log, or a user
> address book in a cell phone or PDA.
Nice to see something like this submitted to mainline. We use something
similar to provide persistent storage for crash recovery debug data for
boards which don't have local storage.
In many cases kdump can provide good information, but it's not
sufficient for "flight recorder" type data if the kernel gets rebooted
by a hardware mechanism (watchdog, for instance) that doesn't give a
pre-interrupt.
I'm a bit concerned about your PTE modifications on every write
though...we do things like log every exception and scheduler operation
to persistent memory, and I think the overhead of changing the
protection on every write would be a killer. Instead, we make extensive
use of checksums at various different levels so that the recovery app
can determine which data is valid.
Also, I'd like to ensure that direct memory access to the memory area
would be available. There are some things (like the sched/exception
logging mentioned above) where we want to make accesses as fast as possible.
Chris
^ permalink raw reply
* Re: [Ksummit-2009-discuss] Representing Embedded Architectures at the Kernel Summit
From: H. Peter Anvin @ 2009-06-17 17:14 UTC (permalink / raw)
To: Ralf Baechle
Cc: Mike Frysinger, Mike Rapoport, James Bottomley, linux-arch,
linux-embedded, ksummit-2009-discuss
In-Reply-To: <20090617150414.GA18525@linux-mips.org>
Ralf Baechle wrote:
>>
>> However, on most systems, even embedded, bringing up memory falls on
>> firmware (sometimes in the form of a boot loader) so Linux rarely sees it.
>
> There are embedded systems were the firmware does not provide a usuable
> memory map or where that is plain broken. Or Linux with some extra init
> code serves as the firmware. Often there is a single serial EEPROM for
> the entire system. If there is an atrocity that can save a penny it will
> be commited at least in the embedded world.
>
"Rarely" is certainly not "never". Quite on the contrary. Also, I
think you can remove "that can save a penny" from your last sentence...
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* Re: [PATCH 13/14] Pramfs: Write Protection
From: Mike Frysinger @ 2009-06-17 17:10 UTC (permalink / raw)
To: Marco
Cc: Linux FS Devel, linux, linux-m68k, uclinux-dist-devel,
Linux Embedded, Linux Kernel, Daniel Walker
In-Reply-To: <4A392098.9060205@gmail.com>
On Wed, Jun 17, 2009 at 12:58, Marco wrote:
> Jared Hulbert wrote:
>> > > +#if defined(CONFIG_ARM) || defined(CONFIG_M68K) || defined(CONFIG_H8300) || \
>> > > + ? ? ? defined(CONFIG_BLACKFIN)
>> > > + ? ? ? /*
>> > > + ? ? ? ?* FIXME: so far only these archs have flush_tlb_kernel_page(),
>> > > + ? ? ? ?* for the rest just use flush_tlb_kernel_range(). Not ideal
>> > > + ? ? ? ?* to use _range() because many archs just flush the whole TLB.
>> > > + ? ? ? ?*/
>> > > + ? ? ? if (end <= start + PAGE_SIZE)
>> > > + ? ? ? ? ? ? ? flush_tlb_kernel_page(start);
>> > > + ? ? ? else
>> > > +#endif
>> > > + ? ? ? ? ? ? ? flush_tlb_kernel_range(start, end);
>> > > +}
>> >
>> > Why not just fix flush_tlb_range()?
>> >
>> > If an arch has a flush_tlb_kernel_page() that works then it stands to
>> > reason that the flush_tlb_kernel_range() shouldn't work with minimal
>> > effort, no?
>>
>> flush_tlb_kernel_page() is a new one to me, it doesn't have any mention
>> in Documentation/cachetlb.txt anyways.
>>
>> Many of the flush_tlb_kernel_range() implementations do ranged checks
>> with tunables to determine whether it is more expensive to selectively
>> flush vs just blowing the entire TLB away.
>>
>> Likewise, there is no reason why those 4 architectures can not just shove
>> that if (end <= start + PAGE_SIZE) check in the beginning of their
>> flush_tlb_kernel_range() and fall back on flush_tlb_kernel_page() for
>> those cases. Hiding this in generic code is definitely not the way to go.
>
> Ok I'll change that function at arch level and I'll remove the ifdef, I'll call only flush_tlb_kernel_page(), but I'd like to know what is the opinion of the arch maintainers to do that.
considering Blackfin defines flush_tlb_kernel_page() to BUG(), i dont
think we care what happens. we dont have a MMU, so all tlb funcs ->
BUG(). presumably this code shouldnt have been compiled in the first
place for us.
-mike
^ permalink raw reply
* Re: [PATCH 13/14] Pramfs: Write Protection
From: Marco @ 2009-06-17 16:58 UTC (permalink / raw)
To: Linux FS Devel, linux, linux-m68k, uclinux-dist-devel
Cc: Linux Embedded, Linux Kernel, Daniel Walker
Jared Hulbert wrote:
> > > +/* init_mm.page_table_lock must be held before calling! */
> > > +static void pram_page_writeable(unsigned long addr, int rw)
> > > +{
> > > + ? ? ? pgd_t *pgdp;
> > > + ? ? ? pud_t *pudp;
> > > + ? ? ? pmd_t *pmdp;
> > > + ? ? ? pte_t *ptep;
> > > +
> > > + ? ? ? pgdp = pgd_offset_k(addr);
> > > + ? ? ? if (!pgd_none(*pgdp)) {
> > > + ? ? ? ? ? ? ? pudp = pud_offset(pgdp, addr);
> > > + ? ? ? ? ? ? ? if (!pud_none(*pudp)) {
> > > + ? ? ? ? ? ? ? ? ? ? ? pmdp = pmd_offset(pudp, addr);
> > > + ? ? ? ? ? ? ? ? ? ? ? if (!pmd_none(*pmdp)) {
> > > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? pte_t pte;
> > > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ptep = pte_offset_kernel(pmdp, addr);
> > > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? pte = *ptep;
> > > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? if (pte_present(pte)) {
> > > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? pte = rw ? pte_mkwrite(pte) :
> > > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? pte_wrprotect(pte);
> > > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? set_pte(ptep, pte);
> > > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? }
> > > + ? ? ? ? ? ? ? ? ? ? ? }
> > > + ? ? ? ? ? ? ? }
> > > + ? ? ? }
> > > +}
> >
> > Wow. Don't we want to do this pte walking in mm/ someplace?
> >
> > Do you really intend to protect just the PTE in question rather than
> > the entire physical page, regardless of which PTE is talking to it?
> > Maybe I'm missing something.
> >
> follow_pfn() ought to be fine for this, optionally follow_pte() could be
> exported and used.
Ok I can create a new exported function follow_pte().
> > > +#if defined(CONFIG_ARM) || defined(CONFIG_M68K) || defined(CONFIG_H8300) || \
> > > + ? ? ? defined(CONFIG_BLACKFIN)
> > > + ? ? ? /*
> > > + ? ? ? ?* FIXME: so far only these archs have flush_tlb_kernel_page(),
> > > + ? ? ? ?* for the rest just use flush_tlb_kernel_range(). Not ideal
> > > + ? ? ? ?* to use _range() because many archs just flush the whole TLB.
> > > + ? ? ? ?*/
> > > + ? ? ? if (end <= start + PAGE_SIZE)
> > > + ? ? ? ? ? ? ? flush_tlb_kernel_page(start);
> > > + ? ? ? else
> > > +#endif
> > > + ? ? ? ? ? ? ? flush_tlb_kernel_range(start, end);
> > > +}
> >
> > Why not just fix flush_tlb_range()?
> >
> > If an arch has a flush_tlb_kernel_page() that works then it stands to
> > reason that the flush_tlb_kernel_range() shouldn't work with minimal
> > effort, no?
>
> flush_tlb_kernel_page() is a new one to me, it doesn't have any mention
> in Documentation/cachetlb.txt anyways.
>
> Many of the flush_tlb_kernel_range() implementations do ranged checks
> with tunables to determine whether it is more expensive to selectively
> flush vs just blowing the entire TLB away.
>
> Likewise, there is no reason why those 4 architectures can not just shove
> that if (end <= start + PAGE_SIZE) check in the beginning of their
> flush_tlb_kernel_range() and fall back on flush_tlb_kernel_page() for
> those cases. Hiding this in generic code is definitely not the way to go.
Ok I'll change that function at arch level and I'll remove the ifdef, I'll call only flush_tlb_kernel_page(), but I'd like to know what is the opinion of the arch maintainers to do that.
(Who is the maintainer of H8300 arch?)
Marco
^ permalink raw reply
* Re: Re: [PATCH 14/14] Pramfs: XIP Operations
From: Marco @ 2009-06-17 16:57 UTC (permalink / raw)
To: Linux FS Devel; +Cc: Linux Embedded, Linux Kernel, Daniel Walker
Jared Hulbert wrote:
> > I know. It wasn't my intention to introduce it but as I said in my
> > first patch I've done a porting of this code from 2.6.10 and to
> > remove it I need time to analyze well the code to avoid deadlock and
> > so on. If someone would like to help me I'd really appreciate it.
> > However I see the use of BKL even in other recent "mainlined" fs as
> > ext4, so I preferred to move the porting effort on other areas.
> > However it's the first item on my todo list.
> Why do you need the lock in pram_find_and_alloc_blocks() to begin
> with? Why wouldn't a mutex work?
It's not impossible to use a mutex, but as I said it's inherited from
code written for 2.6.10. This function works as
pram_get_and_update_block works.
Marco
^ permalink raw reply
* Re: [Ksummit-2009-discuss] Representing Embedded Architectures at the Kernel Summit
From: Ralf Baechle @ 2009-06-17 15:04 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Mike Frysinger, Mike Rapoport, James Bottomley, linux-arch,
linux-embedded, ksummit-2009-discuss
In-Reply-To: <4A38705A.3060007@zytor.com>
On Tue, Jun 16, 2009 at 09:26:02PM -0700, H. Peter Anvin wrote:
> > I2C or similar busses can be a particularly annoying if they contain
> > essential configuration information such as memory size which is needed
> > long before anything else. So for far a common solution is that platforms
> > are carrying a private (aka redundant, ugly) early-i2c system that's just
> > about sufficient for this purpose.
>
> For what it's worth, this is true for pretty much ALL systems with
> removable memory modules, since Serial Presence Detect (SPD) is
> electrically equivalent to I2C.
>
> However, on most systems, even embedded, bringing up memory falls on
> firmware (sometimes in the form of a boot loader) so Linux rarely sees it.
There are embedded systems were the firmware does not provide a usuable
memory map or where that is plain broken. Or Linux with some extra init
code serves as the firmware. Often there is a single serial EEPROM for
the entire system. If there is an atrocity that can save a penny it will
be commited at least in the embedded world.
Ralf
^ permalink raw reply
* Re: Representing Embedded Architectures at the Kernel Summit
From: Kumar Gala @ 2009-06-17 14:31 UTC (permalink / raw)
To: James Bottomley; +Cc: ksummit-2009-discuss, linux-arch, linux-embedded
In-Reply-To: <1243956140.4229.25.camel@mulgrave.int.hansenpartnership.com>
One topic that was partially touched on was dealing with various
memories on embedded systems. We have several sram based allocators
in the kernel for various different arch's:
- Blackfin sram allocator arch/blackfin/mm/sram-alloc.c
- Lite5200(b) sram allocator arch/powerpc/sysdev/bestcomm/sram.c
- AVR32 sram allocator arch/avr32/mach-at32ap/at32ap700x.c and arch/
avr32/mach-at32ap/include/mach/sram.h
- Potential davinci sram allocator
There maybe others.
- k
^ permalink raw reply
* usb gadget serial changes since 2.6.14
From: Daniel Ng @ 2009-06-17 12:36 UTC (permalink / raw)
To: linux-embedded
Hi,
I'm having trouble porting our in-house UDC driver to 2.6.27. It originally
worked on 2.6.14 as an CDC-ACM driver.
I notice a lot of changes since 2.6.14. For starters, instead of the single
serial.c file, there is now f_serial.c, u_serial.c and f_acm.c.
Currently, the UDC driver in 2.6.27 seems to work if I simply plug the USB
cable in between our gadget serial Linux device and a Windows PC. However, if
I unplug, then replug the cable, the 'Out' Endpoint seems fine, but the 'In'
Endpoint doesn't seem to come up properly.
In other words, data only seems to be getting through in the direction from
the PC to the gadget serial Linux device, but not vice versa.
Is there some sort of architecture document to show how the f_serial.c,
u_serial.c and f_acm.c files all fit together? I've searched in the
Documentation directory and I've read the usb-gadget-serial docbook document
but it doesn't really tell me this.
Also, it seems that for some reason composite.c is being compiled and used,
but my CDC-ACM gadget serial driver is *not* a composite driver. Is it
possible to prevent linking with this composite driver?
Cheers,
Daniel
^ permalink raw reply
* Re: [PATCH 1/2] MMC Agressive clocking framework v2
From: Linus Walleij @ 2009-06-17 9:26 UTC (permalink / raw)
To: Pierre Ossman; +Cc: linux-arm-kernel, linux-embedded, Linus Walleij
In-Reply-To: <20090615210930.27afe27a@mjolnir.ossman.eu>
2009/6/15 Pierre Ossman <pierre@ossman.eu>:
> On Tue, 2 Jun 2009 14:36:28 +0200
> Linus Walleij <linus.ml.walleij@gmail.com> wrote:
>
>> This patch modified the MMC core code to optionally call the
>> set_ios() operation on the driver with the clock frequency set
>> to 0 to gate the hardware block clock (and thus the MCI clock)
>> for an MMC host controller after a grace period of at least 8
>> MCLK cycles. It is inspired by existing clock gating code found
>> in the OMAP and Atmel drivers and brings this up to the host
>> abstraction. Gating is performed before and after any MMC request
>> or IOS operation, the other optional host operations will not
>> ungate/gate the clock since they do not necessary touch the
>> actual host controller hardware.
>>
>> It exemplifies by implementing this for the MMCI/PL180 MMC/SD
>> host controller, but it should be simple to switch OMAP and
>> Atmel over to using this instead.
>>
>> Signed-off-by: Linus Walleij <linus.walleij@stericsson.com>
>> ---
>
> This looks pretty good. We might want to make it more runtime
> configurable in the future, but this lays a nice groundwork. It's also
> nicely commented to boot. :)
>
> The only thing that concerns me is the locking and reference counting.
> Wouldn't it be sufficient to enable the clock around requests?
Actually that's all it does now, I had it also in mmc_rescan() but don't
think that's necessary (will do some more deep testing before sending
the updated patch).
> Or
> when the host lock is grabbed? Either version would remove the need for
> both clk_users and clk_lock. I think it would also remove a lot of the
> special logic you have.
I have renamed clk_users to clk_requests because that's what it counts
now. Its still needed however: the problem here is that we need to keep
the clock running a number of cycles after the last request, so we solve it
by increasing .clk_requests by one for every request, then decreasing by
one for every request that ends.
Of course requests are serialized, but the request counter is used for the
disablement work to know if any new request came in when we were
delaying for the clk_disable() call, this work will actually not be scheduled
until after a few requests end and provides the necessary hysteresis.
The requests count would not be needed unless we were splitting of a
separate work, but we have to do that in order to have a burst of requests
serviced without waiting 8 MCI clocks inbetween each of them.
The idea here is just to delay set_ios() with freq = 0 until we know for
sure that the current burst of requests is ended.
When I put in some prints I see that there are lots of requests coming
in bursts so this forms a nice "clock on" window around them.
>> diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
>> index ab37a6d..6ae2156 100644
>> --- a/drivers/mmc/core/Kconfig
>> +++ b/drivers/mmc/core/Kconfig
>> @@ -14,3 +14,14 @@ config MMC_UNSAFE_RESUME
>> This option is usually just for embedded systems which use
>> a MMC/SD card for rootfs. Most people should say N here.
>>
>> +config MMC_CLKGATE
>> + bool "MMC host clock gaing (EXPERIMENTAL)"
>> + depends on EXPERIMENTAL
>> + help
>> + This will attempt to agressively gate the clock to the MMC host,
>> + which typically also will gate the MCI clock to the card. This
>> + is done to save power due to gating off the logic and bus noise
>> + when MMC is not in use. Your host driver has to support this in
>> + order for it to be of any use.
>
> The last sense isn't true anymore, is it?
I rewrote it a bit: all drivers that want to perform clock gating still have
to handle the freq field being set to 0 and take apropriate action. This
is not the case when you don't enable clock gating, you get a few
requests with freq set to 0 in the initialization code but once it's set
to something it never goes to 0 again. Most drivers aren't written to
handle frequency 0, some will probably even get a division by 0
error if you try it (just a guess).
>> +
>> + Of unsure, say N.
>
> "If" :)
>
>> +/*
>> + * Internal work. Work to disable the clock at some later point.
>> + */
>> +static void mmc_clk_disable_work(struct work_struct *work)
>> +{
>> + struct mmc_host *host = container_of(work, struct mmc_host,
>> + clk_disable_work);
>> +
>> + mmc_clk_disable_delayed(host);
>> +}
>
> I think I did a bad job explaining my comments about this the last
> time. What I was trying to say was that why have this
> mmc_clk_disable_work() when you could give mmc_clk_disable_delayed()
> directly to the workqueue?
Because mmc_clk_disable_delayed() is also called in mmc_clk_exit()
like this:
if (cancel_work_sync(&host->clk_disable_work))
mmc_clk_disable_delayed(host);
This is if we cancel a pending clock gating and need to make sure that
the clock is eventually gated off before stopping it. In this case if
cancel_work_sync() returns non-zero the work is cancelled but its
pending task still need to be fulfilled so we need to call
mmc_clk_disable_delayed() outside the work, and we cannot just
call the ios with freq set to 0 because we have no idea as to whether
8 MCI cycles (or whatever you configure) have actually passed since
the last request.
>> +/*
>> + * mmc_clk_remove - shut down clock gating code
>> + * @host: host with potential hardware clock to control
>> + */
>> +static inline void mmc_clk_remove(struct mmc_host *host)
>> +{
>> + if (cancel_work_sync(&host->clk_disable_work))
>> + mmc_clk_disable_delayed(host);
>> + BUG_ON(host->clk_users > 0);
>> +}
>
> I'm not sure why you call mmc_clk_disable_delayed() here. Is the clock
> properly enabled again when this function exits? It should be, but the
> disable call there has me confused.
Some previous request may have made the clock go on, then the
request has completed, but the 8 clock cycles have not yet passed.
So we cannot exit MMC until they have finished.
This way the clock gating framework will assure that the set_ios()
is called with freq = 0 before exiting MMC.
>> @@ -80,6 +235,8 @@ struct mmc_host *mmc_alloc_host(int extra, struct
>> device *dev)
>> host->class_dev.class = &mmc_host_class;
>> device_initialize(&host->class_dev);
>>
>> + mmc_clk_alloc(host);
>> +
>> spin_lock_init(&host->lock);
>> init_waitqueue_head(&host->wq);
>> INIT_DELAYED_WORK(&host->detect, mmc_rescan);
>> @@ -156,6 +313,8 @@ void mmc_remove_host(struct mmc_host *host)
>> device_del(&host->class_dev);
>>
>> led_trigger_unregister_simple(host->led);
>> +
>> + mmc_clk_remove(host);
>> }
>>
>> EXPORT_SYMBOL(mmc_remove_host);
>
> alloc and remove don't form a nice pair. I suggest add/remove or
> perhaps init/exit.
OK renamed it *init *exit.
Yours,
Linus Walleij
-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php
^ permalink raw reply
* Re: [PATCH 13/14] Pramfs: Write protection
From: Paul Mundt @ 2009-06-17 7:07 UTC (permalink / raw)
To: Jared Hulbert
Cc: Marco, Linux FS Devel, Linux Embedded, Linux Kernel,
Daniel Walker
In-Reply-To: <6934efce0906161935x65c2a31br4bf1d35493e7b77c@mail.gmail.com>
On Tue, Jun 16, 2009 at 07:35:24PM -0700, Jared Hulbert wrote:
> > +/* init_mm.page_table_lock must be held before calling! */
> > +static void pram_page_writeable(unsigned long addr, int rw)
> > +{
> > + ? ? ? pgd_t *pgdp;
> > + ? ? ? pud_t *pudp;
> > + ? ? ? pmd_t *pmdp;
> > + ? ? ? pte_t *ptep;
> > +
> > + ? ? ? pgdp = pgd_offset_k(addr);
> > + ? ? ? if (!pgd_none(*pgdp)) {
> > + ? ? ? ? ? ? ? pudp = pud_offset(pgdp, addr);
> > + ? ? ? ? ? ? ? if (!pud_none(*pudp)) {
> > + ? ? ? ? ? ? ? ? ? ? ? pmdp = pmd_offset(pudp, addr);
> > + ? ? ? ? ? ? ? ? ? ? ? if (!pmd_none(*pmdp)) {
> > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? pte_t pte;
> > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ptep = pte_offset_kernel(pmdp, addr);
> > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? pte = *ptep;
> > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? if (pte_present(pte)) {
> > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? pte = rw ? pte_mkwrite(pte) :
> > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? pte_wrprotect(pte);
> > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? set_pte(ptep, pte);
> > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? }
> > + ? ? ? ? ? ? ? ? ? ? ? }
> > + ? ? ? ? ? ? ? }
> > + ? ? ? }
> > +}
>
> Wow. Don't we want to do this pte walking in mm/ someplace?
>
> Do you really intend to protect just the PTE in question rather than
> the entire physical page, regardless of which PTE is talking to it?
> Maybe I'm missing something.
>
follow_pfn() ought to be fine for this, optionally follow_pte() could be
exported and used.
> > +#if defined(CONFIG_ARM) || defined(CONFIG_M68K) || defined(CONFIG_H8300) || \
> > + ? ? ? defined(CONFIG_BLACKFIN)
> > + ? ? ? /*
> > + ? ? ? ?* FIXME: so far only these archs have flush_tlb_kernel_page(),
> > + ? ? ? ?* for the rest just use flush_tlb_kernel_range(). Not ideal
> > + ? ? ? ?* to use _range() because many archs just flush the whole TLB.
> > + ? ? ? ?*/
> > + ? ? ? if (end <= start + PAGE_SIZE)
> > + ? ? ? ? ? ? ? flush_tlb_kernel_page(start);
> > + ? ? ? else
> > +#endif
> > + ? ? ? ? ? ? ? flush_tlb_kernel_range(start, end);
> > +}
>
> Why not just fix flush_tlb_range()?
>
> If an arch has a flush_tlb_kernel_page() that works then it stands to
> reason that the flush_tlb_kernel_range() shouldn't work with minimal
> effort, no?
flush_tlb_kernel_page() is a new one to me, it doesn't have any mention
in Documentation/cachetlb.txt anyways.
Many of the flush_tlb_kernel_range() implementations do ranged checks
with tunables to determine whether it is more expensive to selectively
flush vs just blowing the entire TLB away.
Likewise, there is no reason why those 4 architectures can not just shove
that if (end <= start + PAGE_SIZE) check in the beginning of their
flush_tlb_kernel_range() and fall back on flush_tlb_kernel_page() for
those cases. Hiding this in generic code is definitely not the way to go.
^ permalink raw reply
* Re: [Ksummit-2009-discuss] Representing Embedded Architectures at the Kernel Summit
From: H. Peter Anvin @ 2009-06-17 4:26 UTC (permalink / raw)
To: Ralf Baechle
Cc: Mike Frysinger, Mike Rapoport, James Bottomley, linux-arch,
linux-embedded, ksummit-2009-discuss
In-Reply-To: <20090616121909.GA1547@linux-mips.org>
Ralf Baechle wrote:
>
> I2C or similar busses can be a particularly annoying if they contain
> essential configuration information such as memory size which is needed
> long before anything else. So for far a common solution is that platforms
> are carrying a private (aka redundant, ugly) early-i2c system that's just
> about sufficient for this purpose.
>
For what it's worth, this is true for pretty much ALL systems with
removable memory modules, since Serial Presence Detect (SPD) is
electrically equivalent to I2C.
However, on most systems, even embedded, bringing up memory falls on
firmware (sometimes in the form of a boot loader) so Linux rarely sees it.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* Re: [PATCH 13/14] Pramfs: Write protection
From: Jared Hulbert @ 2009-06-17 2:35 UTC (permalink / raw)
To: Marco; +Cc: Linux FS Devel, Linux Embedded, Linux Kernel, Daniel Walker
In-Reply-To: <4A33A835.901@gmail.com>
> +/* init_mm.page_table_lock must be held before calling! */
> +static void pram_page_writeable(unsigned long addr, int rw)
> +{
> + pgd_t *pgdp;
> + pud_t *pudp;
> + pmd_t *pmdp;
> + pte_t *ptep;
> +
> + pgdp = pgd_offset_k(addr);
> + if (!pgd_none(*pgdp)) {
> + pudp = pud_offset(pgdp, addr);
> + if (!pud_none(*pudp)) {
> + pmdp = pmd_offset(pudp, addr);
> + if (!pmd_none(*pmdp)) {
> + pte_t pte;
> + ptep = pte_offset_kernel(pmdp, addr);
> + pte = *ptep;
> + if (pte_present(pte)) {
> + pte = rw ? pte_mkwrite(pte) :
> + pte_wrprotect(pte);
> + set_pte(ptep, pte);
> + }
> + }
> + }
> + }
> +}
Wow. Don't we want to do this pte walking in mm/ someplace?
Do you really intend to protect just the PTE in question rather than
the entire physical page, regardless of which PTE is talking to it?
Maybe I'm missing something.
> +/* init_mm.page_table_lock must be held before calling! */
> +void pram_writeable(void *vaddr, unsigned long size, int rw)
> +{
> + unsigned long addr = (unsigned long)vaddr & PAGE_MASK;
> + unsigned long end = (unsigned long)vaddr + size;
> + unsigned long start = addr;
> +
> + do {
> + pram_page_writeable(addr, rw);
> + addr += PAGE_SIZE;
> + } while (addr && (addr < end));
> +
> +
> + /*
> + * NOTE: we will always flush just one page (one TLB
> + * entry) except possibly in one case: when a new
> + * filesystem is initialized at mount time, when pram_read_super
> + * calls pram_lock_range to make the super block, inode
> + * table, and bitmap writeable.
> + */
> +#if defined(CONFIG_ARM) || defined(CONFIG_M68K) || defined(CONFIG_H8300) || \
> + defined(CONFIG_BLACKFIN)
> + /*
> + * FIXME: so far only these archs have flush_tlb_kernel_page(),
> + * for the rest just use flush_tlb_kernel_range(). Not ideal
> + * to use _range() because many archs just flush the whole TLB.
> + */
> + if (end <= start + PAGE_SIZE)
> + flush_tlb_kernel_page(start);
> + else
> +#endif
> + flush_tlb_kernel_range(start, end);
> +}
Why not just fix flush_tlb_range()?
If an arch has a flush_tlb_kernel_page() that works then it stands to
reason that the flush_tlb_kernel_range() shouldn't work with minimal
effort, no?
^ permalink raw reply
* Re: [PATCH 14/14] Pramfs: XIP operations
From: Jared Hulbert @ 2009-06-17 2:15 UTC (permalink / raw)
To: Marco
Cc: Sam Ravnborg, Linux Embedded, Linux Kernel, Linux FS Devel,
Daniel Walker
In-Reply-To: <4A34A3C0.80103@gmail.com>
> I know. It wasn't my intention to introduce it but as I said in my first
> patch I've done a porting of this code from 2.6.10 and to remove it I
> need time to analyze well the code to avoid deadlock and so on. If
> someone would like to help me I'd really appreciate it. However I see
> the use of BKL even in other recent "mainlined" fs as ext4, so I
> preferred to move the porting effort on other areas. However it's the
> first item on my todo list.
Why do you need the lock in pram_find_and_alloc_blocks() to begin
with? Why wouldn't a mutex work?
^ permalink raw reply
* Re: Representing Embedded Architectures at the Kernel Summit
From: Grant Likely @ 2009-06-16 21:04 UTC (permalink / raw)
To: Jamie Lokier
Cc: Mike Frysinger, Mike Rapoport, James Bottomley,
ksummit-2009-discuss, linux-arch, linux-embedded
In-Reply-To: <20090616200705.GP11893@shareable.org>
On Tue, Jun 16, 2009 at 2:07 PM, Jamie Lokier<jamie@shareable.org> wrote:
> Grant Likely wrote:
>> On Tue, Jun 16, 2009 at 12:18 PM, Jamie Lokier<jamie@shareable.org> wrote:
>> > Something which lets you specify a dependency in a one-line
>> > MODULE_INIT_PREREQS() macro would be much nicer.
>>
>> That would work for some cases, but a lot of cases the problem is not
>> module init order, but rather driver the probe order. ie. In the
>> Ethernet case I was working on the mac cannot be opened before the
>> phy_device is registered. Or another example is GPIOs. An GPIO
>> driven SPI or MDIO bus cannot be probed before all the devices
>> providing the GPIOs are probed (right now GPIOs are 'special' and
>> probed early, but this is ugly and there is no reason it couldn't be
>> handled within the Linux driver model.
>
> Both of those cases look like a simple module init order problem.
>
> I'm not seeing how it's a probe order problem. Even if you can probe
> PHYs independently first, how are they going to be bound to the
> ethernet MACs, other than by dodgy defaults?
>
> In any of your examples, is the "modprobe" symbol dependency order
> insufficient, when they are external modules?
In both cases the driver is waiting for a specific instance, but has
no idea which driver will provide that service.
For the Ethernet example: Both the MAC driver and the MDIO bus driver
are registered independently (say via either the platform bus). The
MDIO bus driver creates a new mdio_bus instance and registers a
phy_device for each child on the bus. The pdata for the MAC driver
only contains the address of the phy, but it does not know which
driver handles the MDIO bus and it does not know what driver will
handle the phy. All the MAC cares about dereferencing the phy address
to get a pointer to the phy_device structure which only works after
the MDIO bus is probed and the correct phy_device is registered..
Module dependencies won't help here because the MAC cannot know what
module to depend against. Plus, in some cases, the MAC will be used
without a PHY, in which case it cannot depend on any phy modules.
For the GPIO example, same thing. Something like the i2c-gpio driver
doesn't know anything about which device provides the GPIO signals.
It is only handled GPIO numbers for each signal and it cannot be
probed before all the required GPIOs are registered with the system.
Again module dependencies don't work because the driver doesn't know
which GPIO driver it will get bound against at run time.
> If the problem is simply that "modprobe" can calculate dependencies
> but linked-in modules don't, maybe the solution is to use the symbolic
> dependencies to calculate a linked-in driver initialisation order.
>
> If it's a probe order problem, where there aren't symbolic
> dependencies, then MODULE_PROVIDE("gpio") and MODULE_REQUIRE("gpio")
> or something like that might handle those cases, except for tricky
> ones like a GPIO-driven I2C bus which controls a GPIO chip.
Ugh.... it feels too coarse grained to me. It solves some of the
problems, but still requires playing dirty tricks for the tricky cases
which scuttles the whole lot. ie. your i2c GPIO chip example.
Another driver wired to one of those 2nd level GPIOs and using
MODULE_REQUIRE("gpio") would immediately be defeated and would need
some other method to indicate the dependency. Plus there is the
question when stuff is loaded as modules as to how does the kernel
know when MODULE_PROVIDE("gpio") is complete? What if I load the gpio
driver after the gpio-i2c driver? I'd much rather define the
dependency at the resource level, not module level because that is
what the driver is actually needing.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Representing Embedded Architectures at the Kernel Summit
From: Marcel Holtmann @ 2009-06-16 20:10 UTC (permalink / raw)
To: Jamie Lokier
Cc: Grant Likely, Mike Frysinger, Mike Rapoport, James Bottomley,
ksummit-2009-discuss, linux-arch, linux-embedded
In-Reply-To: <20090616200705.GP11893@shareable.org>
Hi Jamie,
> > > Something which lets you specify a dependency in a one-line
> > > MODULE_INIT_PREREQS() macro would be much nicer.
> >
> > That would work for some cases, but a lot of cases the problem is not
> > module init order, but rather driver the probe order. ie. In the
> > Ethernet case I was working on the mac cannot be opened before the
> > phy_device is registered. Or another example is GPIOs. An GPIO
> > driven SPI or MDIO bus cannot be probed before all the devices
> > providing the GPIOs are probed (right now GPIOs are 'special' and
> > probed early, but this is ugly and there is no reason it couldn't be
> > handled within the Linux driver model.
>
> Both of those cases look like a simple module init order problem.
>
> I'm not seeing how it's a probe order problem. Even if you can probe
> PHYs independently first, how are they going to be bound to the
> ethernet MACs, other than by dodgy defaults?
>
> In any of your examples, is the "modprobe" symbol dependency order
> insufficient, when they are external modules?
>
> If the problem is simply that "modprobe" can calculate dependencies
> but linked-in modules don't, maybe the solution is to use the symbolic
> dependencies to calculate a linked-in driver initialisation order.
>
> If it's a probe order problem, where there aren't symbolic
> dependencies, then MODULE_PROVIDE("gpio") and MODULE_REQUIRE("gpio")
> or something like that might handle those cases, except for tricky
> ones like a GPIO-driven I2C bus which controls a GPIO chip.
for the loading order so far I have always added a dummy symbol to
ensure that loading of modules are in the right order. Seems to be a
good enough approach.
Regards
Marcel
^ permalink raw reply
* Re: Representing Embedded Architectures at the Kernel Summit
From: Jamie Lokier @ 2009-06-16 20:07 UTC (permalink / raw)
To: Grant Likely
Cc: Mike Frysinger, Mike Rapoport, James Bottomley,
ksummit-2009-discuss, linux-arch, linux-embedded
In-Reply-To: <fa686aa40906161228o569fa75fp60cdfc450ccbb5ea@mail.gmail.com>
Grant Likely wrote:
> On Tue, Jun 16, 2009 at 12:18 PM, Jamie Lokier<jamie@shareable.org> wrote:
> > Something which lets you specify a dependency in a one-line
> > MODULE_INIT_PREREQS() macro would be much nicer.
>
> That would work for some cases, but a lot of cases the problem is not
> module init order, but rather driver the probe order. ie. In the
> Ethernet case I was working on the mac cannot be opened before the
> phy_device is registered. Or another example is GPIOs. An GPIO
> driven SPI or MDIO bus cannot be probed before all the devices
> providing the GPIOs are probed (right now GPIOs are 'special' and
> probed early, but this is ugly and there is no reason it couldn't be
> handled within the Linux driver model.
Both of those cases look like a simple module init order problem.
I'm not seeing how it's a probe order problem. Even if you can probe
PHYs independently first, how are they going to be bound to the
ethernet MACs, other than by dodgy defaults?
In any of your examples, is the "modprobe" symbol dependency order
insufficient, when they are external modules?
If the problem is simply that "modprobe" can calculate dependencies
but linked-in modules don't, maybe the solution is to use the symbolic
dependencies to calculate a linked-in driver initialisation order.
If it's a probe order problem, where there aren't symbolic
dependencies, then MODULE_PROVIDE("gpio") and MODULE_REQUIRE("gpio")
or something like that might handle those cases, except for tricky
ones like a GPIO-driven I2C bus which controls a GPIO chip.
-- Jamie
^ permalink raw reply
* Re: Representing Embedded Architectures at the Kernel Summit
From: Grant Likely @ 2009-06-16 19:28 UTC (permalink / raw)
To: Jamie Lokier
Cc: Mike Frysinger, Mike Rapoport, James Bottomley,
ksummit-2009-discuss, linux-arch, linux-embedded
In-Reply-To: <20090616181855.GF11893@shareable.org>
On Tue, Jun 16, 2009 at 12:18 PM, Jamie Lokier<jamie@shareable.org> wrote:
> Grant Likely wrote:
>> http://patchwork.ozlabs.org/patch/24152/
>>
>> I never actually pushed through and finished it because it turned out
>> to be a non-issue for Ethernet devices in the end. However, I can see
>> the value. With this approach, a driver can use a
>> bus_register_notifier() variant without caring about the device
>> registration order, and the drivers notifier callback will get called
>> at the appropriate time.
>>
>> In your example case I could see the framebuffer driver deferring the
>> final part of its initialization until the needed i2c device shows up.
>
> It makes drivers more complicated and larger than necessary, though,
> having to add more functions and register more callbacks.
>
> Something which lets you specify a dependency in a one-line
> MODULE_INIT_PREREQS() macro would be much nicer.
That would work for some cases, but a lot of cases the problem is not
module init order, but rather driver the probe order. ie. In the
Ethernet case I was working on the mac cannot be opened before the
phy_device is registered. Or another example is GPIOs. An GPIO
driven SPI or MDIO bus cannot be probed before all the devices
providing the GPIOs are probed (right now GPIOs are 'special' and
probed early, but this is ugly and there is no reason it couldn't be
handled within the Linux driver model.
I could see some form of .probe_prereqs member of a device driver, but
what form should it take? Callback? Data structure? The field of
prereqs (or rather figuring out the prereqs) is so large that I don't
feel confident trying to define something. A callback is probably the
most flexible if it could be called after each probe or registration
event on other devices. The idea being that if the prereq call fails,
then it will be tried again later. Or, thinking further, perhaps
instead of a .probe_prereq, just have .probe returns -ETRYAGAIN and
make the driver core put the device on the end of the queue of devices
to get probed. This could get ugly in the driver core though.
Needs more thought....
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
From: Marco @ 2009-06-16 19:15 UTC (permalink / raw)
To: Jamie Lokier; +Cc: Linux Embedded, Linux Kernel, Linux FS Devel, Daniel Walker
In-Reply-To: <20090616150750.GF29040@shareable.org>
Jamie Lokier wrote:
> Marco wrote:
>> There's the checksum, but the most important feature of this fs is the
>> write protection. The page table entries that map the
>> backing-store RAM are normally marked read-only. Write operations into
>> the filesystem temporarily mark the affected pages as writeable, the
>> write operation is carried out with locks held, and then the pte is
>> marked read-only again. This feature provides protection against
>> filesystem corruption caused by errant writes into the RAM due to
>> kernel bugs for instance. I provided a test module for this. When the
>> module is loaded tries to do a dirty write in the superblock, at this
>> point you should see an error on the write.
>
> Ok. Random question: does it work with NOMMU? :-) (I'm biased, my
> devices are NOMMU).
>
I have to say no. Or at least you can use it but you should select the
option to disable the write protection. Of course, from this point of
view there are some archs that they couldn't have this feature. I had to
disable when I worked with a board with avr32.
> Second question: what happens if the system crashing _during_ a write
> to a file. Does it mean that file will fail it's checksum when it's
> read at the next boot?
>
> Maybe files aren't so important. What about when you write a file,
> and then rename it over an existing file to replace it. (E.g. a
> config file), and the system crashes _during_ the rename? At the next
> boot, is it guaranteed to see either the old or the new file, or can
> the directory be corrupt / fail it's checksum?
First of all I have to explain better the current policy: the checksum
works at inode and superblock level and currently there isn't a recovery
function as the journaling. About the superblock it's easy to use a
redundant policy to be more robust. About the inode, at the moment when
the checksum doesn't match the inode it's marked as bad calling the
function make_bad_inode().
>>> As you say PRAMFS can work with special SRAMs needing memory
>>> protection (and maybe cache coherence?), if you mmap() a file does it
>>> need to use the page cache then? If so, do you have issues with
>>> coherency between mmap() and direct read/write?
>> See my response above about my concept of protection. However the mmap
>> it's a similar approach. I can "mmap" the SRAM and I can write into it
>> my data, but I think the possibility to have a fs it's great. We can use
>> the device as normal disk, i.e. we can use cp, mv and so on.
>
> I meant when you mmap() a file on the filesystem, like you do when
> running an executable, for example. Does mmap() on a file work or is
> it forbidden? Just curious, I'd guess it's forbidden, and you
> wouldn't want _direct_ mappings to the backing SRAM anyway so you can
> keep those checksums up to date.
>
Because pramfs attempts to avoid filesystem corruption caused by kernel
bugs, dirty pages in the page cache are not allowed to be written back
to the backing-store RAM. This means that only private file mappings are
supported. This way, an errant write into the page cache will not get
written back to the filesystem.
>>>> On this point I'd like to hear other embedded guys.
>>> As one, I'd like to say if it can checksum the RAM at boot as well,
>>> then I might like to use a small one in ordinary SRAM (at a fixed
>>> reserved address) for those occasions when a reboot happens
>>> (intentional or not) and I'd like to pass a little data to the next
>>> running kernel about why the reboot happened, without touching flash
>>> every time.
>>>
>>> -- Jamie
>> Yeah Jamie, the goal of this fs is exactly that!
>
> Great :-)
>
> -- Jamie
>
Marco
^ permalink raw reply
* Re: Representing Embedded Architectures at the Kernel Summit
From: Jamie Lokier @ 2009-06-16 18:18 UTC (permalink / raw)
To: Grant Likely
Cc: Mike Frysinger, Mike Rapoport, James Bottomley,
ksummit-2009-discuss, linux-arch, linux-embedded
In-Reply-To: <fa686aa40906160906i7a05fc77jd1b2b920a1680812@mail.gmail.com>
Grant Likely wrote:
> http://patchwork.ozlabs.org/patch/24152/
>
> I never actually pushed through and finished it because it turned out
> to be a non-issue for Ethernet devices in the end. However, I can see
> the value. With this approach, a driver can use a
> bus_register_notifier() variant without caring about the device
> registration order, and the drivers notifier callback will get called
> at the appropriate time.
>
> In your example case I could see the framebuffer driver deferring the
> final part of its initialization until the needed i2c device shows up.
It makes drivers more complicated and larger than necessary, though,
having to add more functions and register more callbacks.
Something which lets you specify a dependency in a one-line
MODULE_INIT_PREREQS() macro would be much nicer.
I can see the callbacks being useful, and necessary, for drivers which
need to interleave their initialisation. E.g. need to initialise an
external framebuffer chip before you can use it's I2C GPIOs, but then
need to initialise an I2C driver before you can read the framebuffer
parameters to finish setting up the framebuffer.
-- Jamie
^ permalink raw reply
* Re: Representing Embedded Architectures at the Kernel Summit
From: Grant Likely @ 2009-06-16 16:06 UTC (permalink / raw)
To: Mike Frysinger
Cc: Mike Rapoport, James Bottomley, ksummit-2009-discuss, linux-arch,
linux-embedded
In-Reply-To: <8bd0f97a0906160106g333eb222idd0d694f452650ff@mail.gmail.com>
On Tue, Jun 16, 2009 at 2:06 AM, Mike Frysinger<vapier.adi@gmail.com> wrote:
> On Tue, Jun 16, 2009 at 02:42, Mike Rapoport wrote:
>> James Bottomley wrote:
>> Another issue that affects embedded architectures is drivers initialization
>> order. There are a lot of cases when you need the drivers to be initialized in
>> particular order, and current initcalls scheme does not allow fine grained
>> control for it.
>
> example: device configuration information stored in i2c eeprom (i.e.
> dimensions of attached framebuffer), but i2c is not available when
> framebuffer layer is setup. framebuffer driver has to be built as a
> module and loaded by userspace, or i2c information is read by
> bootloader and passed down to the kernel.
I experimented a bit with having some infrastructure for waiting for
another device to get either registered as part of the phylib stuff I
was doing. Here's the patchwork link to the discussion:
http://patchwork.ozlabs.org/patch/24152/
I never actually pushed through and finished it because it turned out
to be a non-issue for Ethernet devices in the end. However, I can see
the value. With this approach, a driver can use a
bus_register_notifier() variant without caring about the device
registration order, and the drivers notifier callback will get called
at the appropriate time.
In your example case I could see the framebuffer driver deferring the
final part of its initialization until the needed i2c device shows up.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
From: Jamie Lokier @ 2009-06-16 15:07 UTC (permalink / raw)
To: Marco; +Cc: Linux Embedded, Linux Kernel, Linux FS Devel, Daniel Walker
In-Reply-To: <4A351FA9.1090808@gmail.com>
Marco wrote:
> There's the checksum, but the most important feature of this fs is the
> write protection. The page table entries that map the
> backing-store RAM are normally marked read-only. Write operations into
> the filesystem temporarily mark the affected pages as writeable, the
> write operation is carried out with locks held, and then the pte is
> marked read-only again. This feature provides protection against
> filesystem corruption caused by errant writes into the RAM due to
> kernel bugs for instance. I provided a test module for this. When the
> module is loaded tries to do a dirty write in the superblock, at this
> point you should see an error on the write.
Ok. Random question: does it work with NOMMU? :-) (I'm biased, my
devices are NOMMU).
Second question: what happens if the system crashing _during_ a write
to a file. Does it mean that file will fail it's checksum when it's
read at the next boot?
Maybe files aren't so important. What about when you write a file,
and then rename it over an existing file to replace it. (E.g. a
config file), and the system crashes _during_ the rename? At the next
boot, is it guaranteed to see either the old or the new file, or can
the directory be corrupt / fail it's checksum?
> > As you say PRAMFS can work with special SRAMs needing memory
> > protection (and maybe cache coherence?), if you mmap() a file does it
> > need to use the page cache then? If so, do you have issues with
> > coherency between mmap() and direct read/write?
>
> See my response above about my concept of protection. However the mmap
> it's a similar approach. I can "mmap" the SRAM and I can write into it
> my data, but I think the possibility to have a fs it's great. We can use
> the device as normal disk, i.e. we can use cp, mv and so on.
I meant when you mmap() a file on the filesystem, like you do when
running an executable, for example. Does mmap() on a file work or is
it forbidden? Just curious, I'd guess it's forbidden, and you
wouldn't want _direct_ mappings to the backing SRAM anyway so you can
keep those checksums up to date.
> >> On this point I'd like to hear other embedded guys.
> >
> > As one, I'd like to say if it can checksum the RAM at boot as well,
> > then I might like to use a small one in ordinary SRAM (at a fixed
> > reserved address) for those occasions when a reboot happens
> > (intentional or not) and I'd like to pass a little data to the next
> > running kernel about why the reboot happened, without touching flash
> > every time.
> >
> > -- Jamie
>
> Yeah Jamie, the goal of this fs is exactly that!
Great :-)
-- Jamie
^ permalink raw reply
* Re: [Ksummit-2009-discuss] Representing Embedded Architectures at the Kernel Summit
From: Ralf Baechle @ 2009-06-16 12:19 UTC (permalink / raw)
To: Mike Frysinger
Cc: Mike Rapoport, James Bottomley, linux-arch, linux-embedded,
ksummit-2009-discuss
In-Reply-To: <8bd0f97a0906160106g333eb222idd0d694f452650ff@mail.gmail.com>
On Tue, Jun 16, 2009 at 04:06:48AM -0400, Mike Frysinger wrote:
> On Tue, Jun 16, 2009 at 02:42, Mike Rapoport wrote:
> > James Bottomley wrote:
> >> We've got to the point where there are simply too many embedded
> >> architectures to invite all the arch maintainers to the kernel summit.
> >> So, this year, we thought we'd do embedded via topic driven invitations
> >> instead. So what we're looking for is a proposal to discuss the issues
> >> most affecting embedded architectures, or preview any features affecting
> >> the main kernel which embedded architectures might need ... or any other
> >> topics from embedded architectures which might need discussion or
> >> debate.
> >
> > Another issue that affects embedded architectures is drivers initialization
> > order. There are a lot of cases when you need the drivers to be initialized in
> > particular order, and current initcalls scheme does not allow fine grained
> > control for it.
>
> example: device configuration information stored in i2c eeprom (i.e.
> dimensions of attached framebuffer), but i2c is not available when
> framebuffer layer is setup. framebuffer driver has to be built as a
> module and loaded by userspace, or i2c information is read by
> bootloader and passed down to the kernel.
I2C or similar busses can be a particularly annoying if they contain
essential configuration information such as memory size which is needed
long before anything else. So for far a common solution is that platforms
are carrying a private (aka redundant, ugly) early-i2c system that's just
about sufficient for this purpose.
Ralf
^ permalink raw reply
* Re: Representing Embedded Architectures at the Kernel Summit
From: Mike Frysinger @ 2009-06-16 8:06 UTC (permalink / raw)
To: Mike Rapoport
Cc: James Bottomley, ksummit-2009-discuss, linux-arch, linux-embedded
In-Reply-To: <4A373EE6.6070201@compulab.co.il>
On Tue, Jun 16, 2009 at 02:42, Mike Rapoport wrote:
> James Bottomley wrote:
>> We've got to the point where there are simply too many embedded
>> architectures to invite all the arch maintainers to the kernel summit.
>> So, this year, we thought we'd do embedded via topic driven invitations
>> instead. Â So what we're looking for is a proposal to discuss the issues
>> most affecting embedded architectures, or preview any features affecting
>> the main kernel which embedded architectures might need ... or any other
>> topics from embedded architectures which might need discussion or
>> debate.
>
> Another issue that affects embedded architectures is drivers initialization
> order. There are a lot of cases when you need the drivers to be initialized in
> particular order, and current initcalls scheme does not allow fine grained
> control for it.
example: device configuration information stored in i2c eeprom (i.e.
dimensions of attached framebuffer), but i2c is not available when
framebuffer layer is setup. framebuffer driver has to be built as a
module and loaded by userspace, or i2c information is read by
bootloader and passed down to the kernel.
-mike
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox