Re: Representing Embedded Architectures at the Kernel Summit
James Bottomley wrote: Hi All, 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. -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Representing Embedded Architectures at the Kernel Summit
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 -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Ksummit-2009-discuss] Representing Embedded Architectures at the Kernel Summit
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 -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
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 -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Representing Embedded Architectures at the Kernel Summit
On Tue, Jun 16, 2009 at 2:06 AM, Mike Frysingervapier@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. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Representing Embedded Architectures at the Kernel Summit
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 -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Representing Embedded Architectures at the Kernel Summit
On Tue, Jun 16, 2009 at 12:18 PM, Jamie Lokierja...@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. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Representing Embedded Architectures at the Kernel Summit
Grant Likely wrote: On Tue, Jun 16, 2009 at 12:18 PM, Jamie Lokierja...@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 -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Representing Embedded Architectures at the Kernel Summit
On Tue, Jun 16, 2009 at 2:07 PM, Jamie Lokierja...@shareable.org wrote: Grant Likely wrote: On Tue, Jun 16, 2009 at 12:18 PM, Jamie Lokierja...@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. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 14/14] Pramfs: XIP operations
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? -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/14] Pramfs: Write protection
+/* 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?
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Ksummit-2009-discuss] Representing Embedded Architectures at the Kernel Summit
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. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
