Linux is not reliable enough?
M?sz?ros Lajos wrote: > >Yes, 'C' is unreliable because writing beyond the "maxindex" lets >you overwrite other's data, other's code and DOES make backdoor for >viruses. > >On the other hand testing every index every time for min and max slowes >the executing. QNX does not, and Linux does not, and with both C is as unreliable as ever. However, a failure in a QNX in the driver level is not as potentially malicious as in Linux. While this does not exclude failure, and does not say a thing about the actual quality of QNX or Linux code, it's a nice _additional_ feature related towards stability. I guess Linux lacking proper certification for some applications is a much bigger obstacle in the minds of managers, anyway. But somehow this is getting offtopic, quickly, isn't it? With kind regards, Oliver Korpilla ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Linux is not reliable enough?
> > int a[100], b = 123; > > a[b] = 0; > > > > I guess I'm taking exception to your use of the phrase "all > software". > > > > > > What I mean is, if &a = 0x1, then a[b] will always write > 0 to 0x101ec. > That may not be smart, may not be what you intended to do, > but the uP will > always do the exact same thing. (Does this mean 'C' is > unreliable because > it lets you do things like that?) Yes, 'C' is unreliable because writing beyond the "maxindex" lets you overwrite other's data, other's code and DOES make backdoor for viruses. On the other hand testing every index every time for min and max slowes the executing. So what? Ludwig ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
more questions about 8xx microcode patches
On Tue, 27 Jul 2004, Dan Malek wrote: > On Jul 27, 2004, at 4:23 PM, Robert P. J. Day wrote: >> it seems that creating a menu of 8xx microcode patches would be >> fairly easy: > Hahahahaha You don't know how big of a hole you are digging :-) "Now, Ward, don't just tell the Beav he shouldn't do it. It's always better when they learn these things on their own." rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
question about specific patch to cpm_uart_core.c for SMC reloc
torsten demke sent me a set of patches for SMC1 relocation and they included the following addition to cpm_uart_core.c: diff -purN linuxppc-2.6.7-bk1.1248-org/drivers/serial/cpm_uart/cpm_uart_core.c linuxppc-2.6.7-bk1.1248/drivers/serial/cpm_uart/cpm_uart_core.c --- linuxppc-2.6.7-bk1.1248-org/drivers/serial/cpm_uart/cpm_uart_core.c 2004-07-20 10:57:37.0 +0200 +++ linuxppc-2.6.7-bk1.1248/drivers/serial/cpm_uart/cpm_uart_core.c 2004-07-20 11:02:21.0 +0200 @@ -743,6 +743,15 @@ static void cpm_uart_init_smc(struct uar pinfo->smcup->smc_rbase = (u_char *)pinfo->rx_bd_base - DPRAM_BASE; pinfo->smcup->smc_tbase = (u_char *)pinfo->tx_bd_base - DPRAM_BASE; +#if defined (CONFIG_SHMC) && defined (CONFIG_UCODE_PATCH) + up->smc_rbptr = pinfo->smcup->smc_rbase; + up->smc_tbptr = pinfo->smcup->smc_tbase; + up->smc_rstate = 0; + up->smc_tstate = 0; + up->smc_brkcr = 1; /* number of break chars */ + up->smc_brkec = 0; +#endif + AFAICT, the added code at the bottom is because, when you relocate SMC1, you lose some functionality. is there, somewhere, i can read up on what the above is fixing? thanks. i think that's the last piece of the puzzle -- all the rest of the changes make sense. rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
more questions about 8xx microcode patches
I was working with Motorola about a year ago on USB on the MPC850. At that time, we were already using the I2C/SPI relocation patch. The word from the factory was that you couldn't use more than one microcode patch at a time on an '850. I doubt this has changed since then. There was a first attempt at a single patch for I2C/SPI relocation combined with USB. I don't know if it was ever released. Regards, Charlie -Original Message- From: Mark Chambers [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 27, 2004 5:07 PM To: Robert P. J. Day; Embedded Linux PPC list Subject: Re: more questions about 8xx microcode patches Robert, I know I've never had a need to use a microcode patch. Maybe a quick survey - has anybody ever had a need to use two patches at once? I'm suspecting you may be putting a lot of effort into something that's rarely needed. Also, as Motorola updates their silicon the patches will likely become less relevant (less likely that new users will need the patches). Mark Chambers ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
more questions about 8xx microcode patches
On Tue, 27 Jul 2004, Mark Chambers wrote: > Robert, > > I know I've never had a need to use a microcode patch. Maybe a quick > survey - has anybody ever had a need to use two patches at once? I'm > suspecting you may be putting a lot of effort into something that's rarely > needed. Also, as Motorola updates their silicon the patches will likely > become less relevant (less likely that new users will need the patches). on my project alone, we've needed two different selections of those patches. so while it's not an earth-shattering modification, it doesn't hurt and it sometimes helps. and it makes the addition of any future patches really trivial, if that ever happens. rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
more questions about 8xx microcode patches
On Tue, 27 Jul 2004, Dan Malek wrote: > On Jul 27, 2004, at 4:23 PM, Robert P. J. Day wrote: >> it seems that creating a menu of 8xx microcode patches would be >> fairly easy: > > > Hahahahaha You don't know how big of a hole you are digging :-) oh, fer shure. :-) but given that there are three clear and identifiable patches that exist at the moment, i'll put together a patch that turns them into a submenu and submit it, and you can decide what to do with it. i'll make sure that the submission doesn't change any of the current functionality, just makes it easier to pick what you want. (specifically, it's inconvenient to be able to select one patch via Kconfig, and the other only by editing micropatch.c. but give me a bit, and i'll post something based on those other two small patches i submitted.) rday p.s. should patches be submitted as main body in postings, or as attachments? or do you care? ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
more questions about 8xx microcode patches
On Jul 27, 2004, at 4:23 PM, Robert P. J. Day wrote: > 1) > i recall that, while the manual lists the first controller above as > USB, SCC1 is also a possibility for other 8xx processors, yes? Yes. On the 823/850 the SCC1 controller is dedicated to USB. > 2) > given the size of the scc_enet structure in commproc.h, the whole > reason to relocate SMC1 is to let ethernet on SCC3 spill over into the > normally-reserved SMC1 memory. i would assume the same situation > would hold if you were trying to use SCC2 for ethernet -- you'd need > to relocate SPI, right? Yes. > speaking of I2C and SPI, what's the rationale for pretty much every > single piece of information insisting that these two controllers are > relocated as a pair? There were (are?) various microcode patches that became available as people needed the relocation. In the end, I think there was only one patch the relocated everything. > 4) > the current micropatch.c file appears to limit one to applying a > single patch. the first patch (written to DPRAM address 0) appears to > relocate both I2C/SPI (there's that linkage again). Unless it has changed recently, all microcode patches have to be loaded into location 0 of the DPRAM. You can only load one patch at a time, hence the need for a single patch to contain the relocation of multiple devices. > further down, there's a test for USE_SMC_PATCH (*clearly* not > compatible with the first patch since they both write to DPRAM address > 0) which represents the SMC/I2C/SPI patch. Yep. > (actually, it reads > "SMC2", which i assume is a typo.) Nope, it's to relocate SMC2 so you could run Ethernet/ATM on SCC4. > i'm assuming that this patch > relocates *all* of SMC1, I2C and SPI. Don't assume anything. There are lots of different patches. Carefully read all of the documentation with all of the patches to see what they do, how they are supposed to be loaded, and they match the CPM microcode ROM that is present in your processor. > in general, what patches should exist? You will have to investigate. At one time I knew of no less than six different patches, for various relocation or feature additions. > should the USB SOF patch listed in micropatch.c be an option? > despite the fact that, as some have pointed out, USB is kind of borked > in the 850 Rev B board? and I have pointed out that when used properly it works just fine. It's up to you. > it seems that creating a menu of 8xx microcode patches would be > fairly easy: Hahahahaha You don't know how big of a hole you are digging :-) > 1) collect the current patches, assign them symbolic names [*] > 2) decide which are mutually exclusive and code that into Kconfig As far as I know, they are all mutually exclusive, unless they have been changed recently. > 3) using the denx 2.4.25 tree as a model, put each patch into a > separate source file and just include the appropriate file, > making the appropriate changes to source files like > cpm_uart_cpm1.c where necessary I have not looked at what Wolfgang has done, but the patches I have seen are all S-record files that were supposed to be downloaded through a debugger. In addition to writing the microcode to the DPRAM, they also modified various parameter and control registers in the CPM. The point is, you just can't download code, you also have to perform some initialization steps in the drivers, which of course are usually different depending upon the patch that is loaded. -- Dan ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Looking for GT64260 MPSC serial console driver
Hello folks. I am looking for a MPSC serial console driver for the Marvell GT-64260. I have one from an old 2.4 development tree but it looks like it never made it into the linuxppc-2.5 tree. I would also entertain anyone who could point me in the direction of what needs to be done to port a serial console driver from a 2.4 kernel to the current 2.6 kernel in the linuxppc-2.5 tree. Thanks, Jeff Domogala -Original Message- From: [EMAIL PROTECTED] [mailto:owner-linuxppc-embedded at lists.linuxppc.org]On Behalf Of Mark Chambers Sent: Tuesday, July 27, 2004 5:07 PM To: Robert P. J. Day; Embedded Linux PPC list Subject: Re: more questions about 8xx microcode patches Robert, I know I've never had a need to use a microcode patch. Maybe a quick survey - has anybody ever had a need to use two patches at once? I'm suspecting you may be putting a lot of effort into something that's rarely needed. Also, as Motorola updates their silicon the patches will likely become less relevant (less likely that new users will need the patches). Mark Chambers ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
more questions about 8xx microcode patches
Robert, I know I've never had a need to use a microcode patch. Maybe a quick survey - has anybody ever had a need to use two patches at once? I'm suspecting you may be putting a lot of effort into something that's rarely needed. Also, as Motorola updates their silicon the patches will likely become less relevant (less likely that new users will need the patches). Mark Chambers ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
more questions about 8xx microcode patches
after poring over the header and source files, and the MOT docs, a few questions about possible microcode patches, based on the following layout of the parameter RAM memory map of the MCP850 family, reproduced from the user's manual (and, just remember, i'm not *trying* to be pedantic or annoying, i am merely succeeding :-): the DPRAM memory map: Offset from DPRAM base Controller 0x1C00-0x1C7F USB 0x1C80-0x1CAF I2C 0x1CB0-0x1CBF Misc. 0x1CC0-0x1CCF IDMA1 (whatever that is) 0x1D00-0x1D7F SCC2 0x1D80-0x1DAF SPI 0x1DB0-0x1DBF RISC timer table 0x1DC0-0x1DFF IDMA2 0x1E00-0x1E7F SCC3 0x1E80-0x1EBF SMC1 0x1EC0-0x1EFF (Reserved) 0x1F00-0x1F7F (Reserved) 0x1F80-0x1FBF SMC2 0x1FC0-0x1FFF (Reserved) so, barring any typoes in the above ... 1) i recall that, while the manual lists the first controller above as USB, SCC1 is also a possibility for other 8xx processors, yes? (i'm sure i saw this somewhere; it's not an issue for us, i just wanted to be complete.) 2) given the size of the scc_enet structure in commproc.h, the whole reason to relocate SMC1 is to let ethernet on SCC3 spill over into the normally-reserved SMC1 memory. i would assume the same situation would hold if you were trying to use SCC2 for ethernet -- you'd need to relocate SPI, right? 3) speaking of I2C and SPI, what's the rationale for pretty much every single piece of information insisting that these two controllers are relocated as a pair? micropatch.c provides a patch which relocates them both, a motorola doc i have has a table entitled "I2C/SPI Parameter RAM" as if these things are absolutely inseparable. but they clearly initially live in different locations, and commproc.h has two distinct structs -- "iic" and "spi". so why historically are these two so inextricably linked, especially in terms of a relocation patch? can't you relocate one and leave the other where it is? certainly, if i wanted to put ethernet on SCC2, SPI would have to move but not I2C. rationale? (if address 0x1C00 was in fact being used for SCC1, then ethernet on SCC1 would require I2C to move. you get the idea.) 4) the current micropatch.c file appears to limit one to applying a single patch. the first patch (written to DPRAM address 0) appears to relocate both I2C/SPI (there's that linkage again). further down, there's a test for USE_SMC_PATCH (*clearly* not compatible with the first patch since they both write to DPRAM address 0) which represents the SMC/I2C/SPI patch. (actually, it reads "SMC2", which i assume is a typo.) i'm assuming that this patch relocates *all* of SMC1, I2C and SPI. this suggests that there's currently no patch for just relocating SMC1, which seems somewhat restrictive. is there no reason why someone might want to relocate just SMC1? or does that patch just not exist? 5) in general, what patches should exist? taking into account that applying some patches may make others impossible to use, what should be in the list of possible microcode patches in the MPC8xx CPM submenu? right now, it seems that that list could contain two entries: I2C/SPI SMC1/I2C/SPI which would be mutually exclusive. should there be others? SMC1 by itself? SMC2? 6) should the USB SOF patch listed in micropatch.c be an option? despite the fact that, as some have pointed out, USB is kind of borked in the 850 Rev B board? it seems that creating a menu of 8xx microcode patches would be fairly easy: 1) collect the current patches, assign them symbolic names [*] 2) decide which are mutually exclusive and code that into Kconfig 3) using the denx 2.4.25 tree as a model, put each patch into a separate source file and just include the appropriate file, making the appropriate changes to source files like cpm_uart_cpm1.c where necessary thoughts? rday [*] definitely need some decent Kconfig names for possible ucode patches if there's going to be a list. the current "UCODE_PATCH" would clearly have to go. :-) ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
BAT mapping exported to user-space
On Jul 27, 2004, at 3:32 PM, Linh Dang wrote: > Thanx for pointing that out. I have to dig further. I guess it would > come down to how much pressure using pages for mapping our asics > (instead of BATs) would have on the TLBs. As I pointed out in one of the very first messages, you can write a custom device driver to implement various mapping schemes based upon your requirements. However, this could result in something not portable to another kernel version. > Just to clarify things, I'm trying to sell Linux to management (we're > a VxWorks shop) and trying to tell them that Linux's > RT-performance/efficiency is adequate and Linux would bring in a lot > more robustness/stability. I've been involved in too many of this discussions to realize this is never an engineering trade off. Linux can do this VxWorks can't, VxWorks can do things Linux can't, and there is a whole bunch of computing where they do equally well. The discussion we've had is irrelevant to the choice. Find some features worthy of discussion and use them to make the decision. You can solve any OS challenge with Linux, you just have to find the people with the knowledge and be willing to do it. -- Dan ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Linux is not reliable enough?
Oliver Korpilla wrote: > > M?sz?ros Lajos wrote: > >> >> Yes, 'C' is unreliable because writing beyond the "maxindex" lets >> you overwrite other's data, other's code and DOES make backdoor for >> viruses. >> >> On the other hand testing every index every time for min and max slowes >> the executing. > > > QNX does not, and Linux does not, and with both C is as unreliable as ever. > > However, a failure in a QNX in the driver level is not as potentially > malicious as in Linux. While this does not exclude failure, and does not > say a thing about the actual quality of QNX or Linux code, it's a nice > _additional_ feature related towards stability. > > I guess Linux lacking proper certification for some applications is a > much bigger obstacle in the minds of managers, anyway. > > But somehow this is getting offtopic, quickly, isn't it? > > With kind regards, > Oliver Korpilla > If C is not reliable enough then nothing is. In assembly(or even handcoded machine language for the real hard core people) you can do just about anything. Since all languages must resort to this at some point, our foundation is built on sand and we are eternaly screwed. Only the 4 last words of the last sentence of this statement is false. Its not the languages job to write good solid code or verify it, its the programmers responsibility. The only code you can truly trust is code you have total control over. For truly solid code, no funky error checking computer science language will ever replace good practices, thorough testing, and documentation. The reason for this is obvious, at some point higher level languages must be built using a lower language to avoid the chicken/egg paradox. Hence the quality of a higher level language can never be assured since its foundation is made of sand. Its a poor musician that blames their instrument. -- Conn Clark * Give a man a match and you heat him for a moment. Set him on fire and you'll heat him for life. * Conn Clark Engineering Stooge clark at esteem.com Electronic Systems Technology Inc. www.esteem.com ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Looking for GT64260 MPSC serial console driver
Mark A. Greer wrote: > I should add that I am currently having problems with that driver on a > 64360 base board. I hope to have it working "soon". Scratch that. I had a bug in my platform code. The mpsc *port 0* seems to work fine on the 64360. Mark ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Looking for GT64260 MPSC serial console driver
Jeff Domogala wrote: >Hello folks. > >I am looking for a MPSC serial console driver for the Marvell GT-64260. I >have one from an old 2.4 development tree but it looks like it never made it >into the linuxppc-2.5 tree. I would also entertain anyone who could point >me in the direction of what needs to be done to port a serial console driver >from a 2.4 kernel to the current 2.6 kernel in the linuxppc-2.5 tree. > Mail archives are your friend... http://lists.linuxppc.org/linuxppc-embedded/200407/msg00332.html I should add that I am currently having problems with that driver on a 64360 base board. I hope to have it working "soon". Mark ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
BAT mapping exported to user-space
Dan Malek wrote: > > On Jul 27, 2004, at 1:34 PM, Dang, Linh [CAR:2X23:EXCH] wrote: > >>> cat /proc/ppc_htab >> PTE Hash Table Information > > You misunderstand. This is the PPC Hash table, not Linux PTEs. > There are lots and lots and lots of Linux PTEs are are eventually > loaded into the PPC hash table for the processor to fetch. Thanx for pointing that out. I have to dig further. I guess it would come down to how much pressure using pages for mapping our asics (instead of BATs) would have on the TLBs. Just to clarify things, I'm trying to sell Linux to management (we're a VxWorks shop) and trying to tell them that Linux's RT-performance/efficiency is adequate and Linux would bring in a lot more robustness/stability. > What processor are you using? 7447 at 1 GHz (the bottle of the system is the I/O to the memory-mapped ASICs) > >> I though the kernel (2.6) only use pages for vmalloc. > > There is lots of kernel space allocated through vmalloc(), plus > other specialized spaces depending upon the processor core > that are allocated through page tables. Hmm, i though most of kernel's objects (socket's buffer included) are allocated thru the slab-allocator. slab, AFAIK, doesn't use neither vmalloc nor pages. -- Linh Dang ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
BAT mapping exported to user-space
On Jul 27, 2004, at 1:34 PM, Dang, Linh [CAR:2X23:EXCH] wrote: > # cat /proc/ppc_htab > PTE Hash Table Information You misunderstand. This is the PPC Hash table, not Linux PTEs. There are lots and lots and lots of Linux PTEs are are eventually loaded into the PPC hash table for the processor to fetch. What processor are you using? > I though the kernel (2.6) only use pages for vmalloc. There is lots of kernel space allocated through vmalloc(), plus other specialized spaces depending upon the processor core that are allocated through page tables. -- Dan ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] add board_init() (was [PATCH] make platform_init() weak for 8xx)
On Fri, Jul 23, 2004 at 03:59:53PM +0200, Andreas Oberritter wrote: > Am Mo, den 19.07.2004 schrieb Tom Rini um 20:20: > > On Mon, Jul 19, 2004 at 07:34:28PM +0200, Andreas Oberritter wrote: > > > > > On Mon, 2004-07-19 at 18:32, Tom Rini wrote: > > > > Second, this takes us in the direction of 82xx. Until the 82xx > > > > abstractions get flushed out a bit more, I remain unconvinced that > > > > they're really the right way to go (perhaps hooking the other direction > > > > would work better, e.g. platform_init() calls board_init(), with a weak > > > > version provided, and some functions forced to be provided by board.c, > > > > such as m8xx_map_io). > > > > > > I chose this way because it seemed to be a simple way to port the dbox2 > > > board to 2.6 using the new device API. Is there another 8xx board which > > > uses the device API for its onboard peripherials and can be used as a > > > reference? Can I get my devices registered without modifying > > > platform_init, or shall I send a patch with the board_init() you > > > mentioned? See my board.c attached. > > > > There currently isn't a reference platform for what you speak of. My > > preference would be to see what I described given a shot to see if it > > looks better or worse (and it better, or worse, in the flow of things). > > How about this patch? Yes, I think that's about it. -- Tom Rini http://gate.crashing.org/~trini/ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
BAT mapping exported to user-space
Dan Malek wrote: > > On Jul 26, 2004, at 10:27 PM, Linh Dang wrote: > >> What do you mean by the above sentence? > > Exactly what I said. If you are concerned about the difference in > performance between a BAT mapped space and page tables, > there are many other kernel behaviors that are going to cause > trouble for your software. > >> - 200MB would need 51200 ptes. that means doubling the current number >> of ptes on my system. > > Doubling? I don't think so. How did you measure what you are # cat /proc/ppc_htab PTE Hash Table Information Size: 256Kb Buckets : 4096 Address : c02c Entries : 32768 User ptes : 326 Kernel ptes : 989 Percent full: 4% Reloads : 29288 Preloads: 17175 Searches: 1791 Overflows : 0 Evicts : 0 Non-error misses: 24468 Error misses: 0 That's about 1315 PTEs (before the applications start.) > currently using? The 51200 PTEs really isn't a lot. Mapping huge just 38 times what currently on my system. > linear spaces with PTEs is actually quite efficient. Small VM spaces > with holes are the killer. Do you actually touch every byte within > that 200 MB space? When the system is working full-steam it's pretty close too that. > >> - If using block mapping doesn't help that much then why would X make >> all the effort to grab MTRRs on X86? > > I dunno. I've never done any performance or feature analysis of x86 > page > tables to discuss this. > >> - why would the kernel use BATs to map its memory? > > It's convenient for some areas of memory. Makes it trivial to write > some forms of IO mapping functions. We can set up some early static > memory maps for kernel initialization. Mainly, we don't pollute the > TLBs > during short interrupt or system calls, allowing the user applications > to > run without having to reload the TLB after such events. Even though > the kernel may use BATs, it still maps everything with page tables and > makes extensive use of them for various memory mapping requirements. I though the kernel (2.6) only use pages for vmalloc. -- Linh Dang ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
440GX: mapping PCI address
On Tue, Jul 27, 2004 at 01:20:27PM -0500, Barbier, Renaud (GE Infrastructure)
wrote:
>
> ok. I am lost here.
> I have checked the linux source code and can see
> comments regarding fix for the 36-bit address.
> So I would think the current BSP I have can support what I need.
Did you get the patch I mentioned? It hacks remap_page_range() to
call the 36-bit fixups and handle a u64 phys addr. What "BSP"
are you talking about? Are you running a stock kernel tree?
> Still even though I am getting an address from mmap access, to the location
> freezes my machine.
> Here is the code.
> fd=open("/dev/mem", O_RDWR);
>
> /* test fd for error */
> ptr=(unsigned int *)mmap(0, 4096, PROT_READ | PROT_WRITE,
> MAP_SHARED, fd, 0xec0); or /* 0x80002000 */
> printf("ptr = 0x%x\n", (unsigned int)ptr);
>
> the returned address is 0x30019000.
>
> If I understand correctly 0x0ec0 should be translated by the kernel
> to 0x20ec0 to map the PCI configuration register.
Only if the patch is applied.
> I can see the remapping being done when using ioremap in the drivers but not
> when doing mmap at user level. So could be wrong in my system?
>
>
> Actually, what do you do if you have 512MB of memory? I guess change the
> "trap" area.
I don't follow, how does 512MB of memory change things in your
case? The hack does make some assumptions but it works for most
peoples needs.
-Matt
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Linux is not reliable enough?
Am Montag, 26. Juli 2004 15:46 schrieb Mark Chambers: > But if you write drivers that don't crash the system then > linux is not unreliable. Its not just the drivers: every line of kernel code (and there are over a million of those in linux) has the potential to crash the system. In order to be *really* sure that the system is reliable, one would have to give all that code a thorough examination. Depending on how "thorough examination" is defined (and there are approved standards for this), this effort results in costs that quickly make the question wether the OS's source code is available for free, or will cost a few hundred kilobucks, a non-issue. > The only operating system that doesn't allow a > clever programmer to crash is one that doesn't do anything. Microkernels, > they say, allow you to do nifty things like replace the file system without > rebooting. This is not really a microkernel-specific feature. I believe Linux with its kernel modules can do this as well. The important thing about the microkernel approach is that it allows to build OS functionality from components, where each component runs in its own address space and only has access to the resources it needs to do its job. A device driver only needs access to the registers of the device it is supposed to handle, so it can only foul up this particular device (*). If such a driver goes haywire, it *can* not affect, e.g. other driver's hardware or memory: the bug remains local to the software that causes it. Such a failure affects only the offending component itself and the software modules that rely on the services this component offers. The benefit of this approach for safety-critical systems is that one can identify the components that are critical to the application. If a particular application does not require a big deal of OS functionality, then only the few components necessary to implement it need to be scrutinized. Other components may well exist in the system, for example to support non-critical parts of the application, because they can not affect the critical parts. Don't get me wrong: I'm not saying a microkernel (or even QNX) is inherently safer than Linux. However, if done right, it can give you the freedom to trade functional complexity against functional safety. > So that means you could swap in a buggy filesystem and destroy > the data on your disc/flash. Without rebooting. Which is good since you > won't be able to boot from your corrupted filesystem, which won't show up > until the next power failure, while the poor nurse with a flashlight talks > to a guy on the phone who assures her QNX can't fail. So every OS, and > every feature, has its pro's and con's. The question for any CSA is not > 'is this reliable' but 'can I make a reliable system using this component'? > Will the OS eat itself, or do I only have to worry about the mistakes I > make? A carefully constructed linux system should be good for 5 or even 6 > nines of reliability. This may be your gut feeling, but the CSA has to *prove* it for the OS he chooses (at least he should have to, that is his responsibility). (Honestly: would you fly in an aircraft whose steer-by-wire system is controlled by Linux/QNX/any other OS (name please)?) Rob (*) There are some more issues here which I left out for brevity: If the device being handled by a driver is capable of DMA, it *can* crash everything. Therefore, such drivers need special consideration. Also, for memory-mapped I/O, access permissions to device registers need to be enforced by the MMU, so, if there are multiple devices with their registers within the same physical page, they can not be protected from each other. Nevertheless, the likelihood if a wild pointer causing spurious crashes is still greatly reduced. Robert Kaiser email: rkaiser at sysgo.com SYSGO AG Am Pfaffenstein 14phone: (49) 6136 9948-762 D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
440GX: mapping PCI address
ok. I am lost here.
I have checked the linux source code and can see
comments regarding fix for the 36-bit address.
So I would think the current BSP I have can support what I need.
Still even though I am getting an address from mmap access, to the location
freezes my machine.
Here is the code.
fd=open("/dev/mem", O_RDWR);
/* test fd for error */
ptr=(unsigned int *)mmap(0, 4096, PROT_READ | PROT_WRITE,
MAP_SHARED, fd, 0xec0); or /* 0x80002000 */
printf("ptr = 0x%x\n", (unsigned int)ptr);
the returned address is 0x30019000.
If I understand correctly 0x0ec0 should be translated by the kernel
to 0x20ec0 to map the PCI configuration register.
I can see the remapping being done when using ioremap in the drivers but not
when doing mmap at user level. So could be wrong in my system?
Actually, what do you do if you have 512MB of memory? I guess change the "trap"
area.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:owner-linuxppc-embedded at lists.linuxppc.org]On Behalf Of Gerhard
Jaeger
Sent: Thursday, July 22, 2004 12:48 PM
To: linuxppc-embedded at lists.linuxppc.org
Subject: Re: 440GX: mapping PCI address
Hi,
checkout
arch/ppc/mm/pgtable.c
there you'll find the ioremap function which is used to remap physical
addresses. This function calls internaly fixup_big_physaddr(), defined in
arch/ppc/kernel/ibm44x_common.c
This fixup_big_physaddr() adjusts some 32bit addresses to some corresponding
36bit addresses, which can be mapped by the kernel by calling ioremap64.
Your example:
Calling mmap with the address 0x80002000 (see also include/asm-ppc/ibm44x.h)
will map the PCI area, by trapping this 0x80002000 and making a 36bit address
out of it. There a 3 "trap" areas defined:
/*
* 36-bit trap ranges
*/
#define PPC44x_IO_LO0x4000
#define PPC44x_IO_HI0x40001000
#define PPC44x_PCICFG_LO0x0ec0
#define PPC44x_PCICFG_HI0x0ec7
#define PPC44x_PCIMEM_LO0x80002000
#define PPC44x_PCIMEM_HI0x
Hope this helps,
Gerhard
On Thursday 22 July 2004 11:58, Barbier, Renaud (GE Infrastructure) wrote:
> As you know the PCI address(and other embedded device) are seen through a
> 36-bit address space.
>
> How do you map this address from user space?
>
> I have seen a message from 2002 saying it is not supported. Anything new
> since then?
>
> thanks.
--
Gerhard Jaeger g.jaeger at sysgo.com
SYSGO AG Embedded and Real-Time Software
Voice: + 49 731 94683-0Fax: + 49 731 94683-10
www.sysgo.com | www.elinos.com | www.osek.de | www.imerva.com
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] move 8xx microcode patches into Kconfig submenu
create a submenu for 8xx microcode patches to keep them organized in one place, under the assumption that there will be more to come. --- linuxppc-2.5/arch/ppc/8xx_io/Kconfig 2004-07-27 12:36:24.050604776 -0400 +++ linuxppc-2.5.new/arch/ppc/8xx_io/Kconfig 2004-07-27 12:36:56.869615528 -0400 @@ -140,6 +140,8 @@ If in doubt, say N here. +menu "Microcode patches" + config UCODE_PATCH bool "I2C/SPI Microcode Patch" help @@ -150,3 +152,5 @@ endmenu +endmenu + ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
BAT mapping exported to user-space
On Jul 26, 2004, at 10:27 PM, Linh Dang wrote: > What do you mean by the above sentence? Exactly what I said. If you are concerned about the difference in performance between a BAT mapped space and page tables, there are many other kernel behaviors that are going to cause trouble for your software. > - 200MB would need 51200 ptes. that means doubling the current number > of ptes on my system. Doubling? I don't think so. How did you measure what you are currently using? The 51200 PTEs really isn't a lot. Mapping huge linear spaces with PTEs is actually quite efficient. Small VM spaces with holes are the killer. Do you actually touch every byte within that 200 MB space? > - If using block mapping doesn't help that much then why would X make > all the effort to grab MTRRs on X86? I dunno. I've never done any performance or feature analysis of x86 page tables to discuss this. > - why would the kernel use BATs to map its memory? It's convenient for some areas of memory. Makes it trivial to write some forms of IO mapping functions. We can set up some early static memory maps for kernel initialization. Mainly, we don't pollute the TLBs during short interrupt or system calls, allowing the user applications to run without having to reload the TLB after such events. Even though the kernel may use BATs, it still maps everything with page tables and makes extensive use of them for various memory mapping requirements. -- Dan ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] add reserved and smc_rpbase field to smc_uart
first patch to add the required reloc field for SMC1 relocation -- is this the appropriate format? --- linuxppc-2.5/include/asm-ppc/commproc.h 2004-07-27 12:23:32.723864264 -0400 +++ linuxppc-2.5.new/include/asm-ppc/commproc.h 2004-07-27 12:29:27.609913384 -0400 @@ -145,6 +145,8 @@ ushort smc_brkec; /* rcv'd break condition counter */ ushort smc_brkcr; /* xmt break count register */ ushort smc_rmask; /* Temporary bit mask */ + uchar smc_res[8]; /* Reserved to push next field to 0x3C */ + ushort smc_rpbase; /* Relocation pointer */ } smc_uart_t; /* Function code bits. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
MPC8245 Error No. 26
Concurrent Write should never be set. There was a problem with the autoconfig detection in serial.c which left this bit set in uart0 when detecting uart1. See: http://linux.bkbits.net:8080/linux-2.4/cset at 3f95b003q4gnNPHPXqRMbNkI64jdaA?nav=index.html|src/|src/drivers|src/drivers/char|related/drivers/char/serial.c I've verified this fix with the MPC8540 DUART. Ed.Swarthout at Freescale dot com -Original Message- From: DeLaGarza, Robert With regard to "Error No. 26" (quoted below), has any work been done in the kernel or serial drivers to compensate for this error? I've observed problems only when both UARTs were enabled, so I suppose one solution is to enable only one UART. ... http://www.freescale.com/files/32bit/doc/errata/MPC8245CE.pdf ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Linux is not reliable enough?
Hah! I'm breaking my promise! See below. > Mark, > > A couple of comments on your comments (sorry for keeping this going). > > > One point I was trying to make is that assuming the underlying hardware > > is good, all software is theoretically perfect. > > I can't imagine this statement being true. It's true that if the hardware > is bad, the software may not operate correctly, but the converse isn't true. > The following code is incorrect, regardless of the state of the hardware it > runs on: > > int a[100], b = 123; > a[b] = 0; > > I guess I'm taking exception to your use of the phrase "all software". > > What I mean is, if &a = 0x1, then a[b] will always write 0 to 0x101ec. That may not be smart, may not be what you intended to do, but the uP will always do the exact same thing. (Does this mean 'C' is unreliable because it lets you do things like that?) > > That is, given the same set of input conditions it will always produce > > the same output. > > If ... > > 0. Asynchronous interrupts are enabled, or > 1. Your code reads an A/D converter and acts on that data, or > 2. Your code acts on operator input, or > 3. One of several other normal situations hold, > > then this statement, while true, just doesn't apply. In my experience, > real-world situations that allow the assumption of software determinism > are remarkably rare. > Yes, but they are different input conditions then. > > Ultimately what were talking about here is: who has to be convinced of > the reliability of the chosen OS? I personally spent many years > designing and deploying hospital-grade medical monitors. If human > life is at stake, there are regulatory agencies looking over your shoulder. > > In the medical business, there is our own FDA as well as a number of other > agencies (including the German TUV (IMHO the toughest taskmaster of > them all)). You simply aren't going to sell your device until you get > approval from the appropriate regulatory agency. It is the regulatory > agencies you need to convince. > > What the agencies are looking for in your submission for approval to > sell your device is extensive test data that your company is willing > assert is accurate and that demonstrates this reliability. This is > a huge task. So, what you do is "pass the buck." You find a vendor > of a commercial OS that already has done this testing and you include > their test data (and their assertions) in your submission to the > regulatory agencies. > > I agree completely, and I think you're making my point, that some sort of instrinsic reliability isn't the real issue, rather what tools you need to get the job done. > I suppose I've wandered a bit off-topic here, but it seemed relevant. > Sure, it's fun, and we could go round and round until we get real jobs :-) > Regards, > Charlie > > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
2.4 versus 2.6 patches
David Woodhouse wrote?? > On Mon, 26 Jul 2004, [gb2312] Song Sam wrote: > > It was really a puzzle for me why 2.4 is NOT a viable,maintainable > > platform but it is used more than 2.6.x in many embedded > > development.Also why to see 2.4 dying without leaving the official > > maintaining work to some volunteers? Any special reason? > Because nobody's really that interested in it. Here nobody perhaps means "no official maintainers",those top level kernel hackers. > If 2.4 works already for you, by all means use it -- but if you're > doing any new development, or you _really_ want people to care when > you find bugs, it really ought to be 2.6. Thanks for this guideness.I am also interested in 2.6.x development on embedded application.But for the sake of stable and useable,I perfer to 2.4.x for the moment.Anyway,2.4 is a sign of mature for Linux. Now I know what's the real reason of End Development for official 2_4_devel. > Out of interest, how many platforms are you using 2.6 on and how does > your experience with these platforms support your stated view? Good point.I should take back my assumption to say "most" from now on. For your insterest,just 2 platforms was used by me.One is RPXlite DW,which could run on 2.4.x and 2.6.7 with RAMDISK root file system.Another it's modified board,which could only run with 2.4.x by now. Thanks a lot for your attention on this point. Sam ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Linux is not reliable enough?
Mark, A couple of comments on your comments (sorry for keeping this going). > One point I was trying to make is that assuming the underlying hardware > is good, all software is theoretically perfect. I can't imagine this statement being true. It's true that if the hardware is bad, the software may not operate correctly, but the converse isn't true. The following code is incorrect, regardless of the state of the hardware it runs on: int a[100], b = 123; a[b] = 0; I guess I'm taking exception to your use of the phrase "all software". > That is, given the same set of input conditions it will always produce > the same output. If ... 0. Asynchronous interrupts are enabled, or 1. Your code reads an A/D converter and acts on that data, or 2. Your code acts on operator input, or 3. One of several other normal situations hold, then this statement, while true, just doesn't apply. In my experience, real-world situations that allow the assumption of software determinism are remarkably rare. Ultimately what were talking about here is: who has to be convinced of the reliability of the chosen OS? I personally spent many years designing and deploying hospital-grade medical monitors. If human life is at stake, there are regulatory agencies looking over your shoulder. In the medical business, there is our own FDA as well as a number of other agencies (including the German TUV (IMHO the toughest taskmaster of them all)). You simply aren't going to sell your device until you get approval from the appropriate regulatory agency. It is the regulatory agencies you need to convince. What the agencies are looking for in your submission for approval to sell your device is extensive test data that your company is willing assert is accurate and that demonstrates this reliability. This is a huge task. So, what you do is "pass the buck." You find a vendor of a commercial OS that already has done this testing and you include their test data (and their assertions) in your submission to the regulatory agencies. I suppose I've wandered a bit off-topic here, but it seemed relevant. Regards, Charlie ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
enable_irq(12) unbalanced for ppc8260
Hi, there.
I used ppc8260 cpm timer as followings:
void init_timer()
{
...
request_8xxirq(SIU_INT_TIMER1, handler, 0, "TIMER", NULL);
enable_irq(SIU_INT_TIMER1);
...
}
void stop_timer()
{
disable_irq(SIU_INT_TIMER1);
free_irq(SIU_INT_TIMER1, NULL);
}
I called init_timer() after loading module and then called stop_timer()
after 10 seconds by user space program. It works well for first time
just after loading module and executing user space program. But it fails
from the next execution of user space program throwing 'enable_irq(12)
unbalanced' error. I mean interrupt won't occur.
What's wrong? What should I do to disable timer interrupt to avoid above
error?
Thanks.
willy.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Linux is not reliable enough?
Ok, I promise (mostly to myself) that this is my last comment about this. One point I was trying to make is that assuming the underlying hardware is good, all software is theoretically perfect. That is, given the same set of input conditions it will always produce the same output. So software can only become unreliable when applied to some real world application, when the deterministic outputs are not the ones we wanted. So perhaps I'm being overly pedantic here, but I think it's relevant to our discussion, because people may make an apples to oranges comparison when comparing linux to other OS's. Other OS's may provide a shrink-wrapped solution which has been extensively tested and is relatively guaranteed for some range of inputs. Linux, on the other hand, is more a raw material. But because linux is open source it can be molded to your application. The many flavors of hard realtime or 'carrier grade' linux are perfect examples of this. So it comes down to evaluating what you need to do your job, and not applying some mystical quality of 'reliability' to a piece of software. I do understand what we mean by 'reliable' as a practical matter, my point is just that you can't say whether linux is reliable or not until you know what it's required to do. If I wanted to create a digital alarm clock, for an extreme example, I bet I could write a linux app that would NEVER crash. (at least until Y4K). By the way, it's not my 'feeling' that linux can do 5 nines. It's been done. Granted, the numbers come from clusters of PCs, so 100 PCs running without failure for a year does not necessarily translate to one PC running for 100 years. And finally, this is all quite relevant to the discussion about dropping 2.4 for 2.6. It's important for linux in general that well characterized versions of the software are available. So as Forrest Gump would say, that's all I have to say about that. Mark Chambers > Its not just the drivers: every line of kernel code (and there are over a > million of those in linux) has the potential to crash the system. In order to > be *really* sure that the system is reliable, one would have to give all that > code a thorough examination. Depending on how "thorough examination" is > defined (and there are approved standards for this), this effort results in > costs that quickly make the question wether the OS's source code is available > for free, or will cost a few hundred kilobucks, a non-issue. > > > The only operating system that doesn't allow a > > clever programmer to crash is one that doesn't do anything. Microkernels, > > they say, allow you to do nifty things like replace the file system without > > rebooting. > > This is not really a microkernel-specific feature. I believe Linux with its > kernel modules can do this as well. > > The important thing about the microkernel approach is that it allows to build > OS functionality from components, where each component runs in its own > address space and only has access to the resources it needs to do its job. A > device driver only needs access to the registers of the device it is supposed > to handle, so it can only foul up this particular device (*). If such a > driver goes haywire, it *can* not affect, e.g. other driver's hardware or > memory: the bug remains local to the software that causes it. Such a failure > affects only the offending component itself and the software modules that > rely on the services this component offers. > > The benefit of this approach for safety-critical systems is that one can > identify the components that are critical to the application. If a particular > application does not require a big deal of OS functionality, then only the > few components necessary to implement it need to be scrutinized. Other > components may well exist in the system, for example to support non-critical > parts of the application, because they can not affect the critical parts. > > Don't get me wrong: I'm not saying a microkernel (or even QNX) is inherently > safer than Linux. However, if done right, it can give you the freedom to > trade functional complexity against functional safety. > > > So that means you could swap in a buggy filesystem and destroy > > the data on your disc/flash. Without rebooting. Which is good since you > > won't be able to boot from your corrupted filesystem, which won't show up > > until the next power failure, while the poor nurse with a flashlight talks > > to a guy on the phone who assures her QNX can't fail. So every OS, and > > every feature, has its pro's and con's. The question for any CSA is not > > 'is this reliable' but 'can I make a reliable system using this component'? > > Will the OS eat itself, or do I only have to worry about the mistakes I > > make? A carefully constructed linux system should be good for 5 or even 6 > > nines of reliability. > > This may be your gut feeling, but the CSA has to *prove* it for the OS he > chooses (at least he should have to, that is his
2.4 versus 2.6 patches
On Tue, 2004-07-27 at 01:49, Eugene Surovegin wrote: > On Tue, Jul 27, 2004 at 01:17:52AM +0200, Thomas Gleixner wrote: > > > Hopefully, I can maintain this stuff myself and backport fixes (what I > > > already > > > did for some MTD stuff, btw). > > > > Cool (where are the patches, btw ???). > > All stuff I backported into my 2.4.21 tree _are_ from MTD CVS (e.g. write > buffer > support for AMD flashes). When I found bugs in MTD layer, I submit patches > through usual channels. I would suspect, that MTD would be an usual channel for stuff concerning MTD. And maybe I'm missing the point again, but your last posting to MTD is dated from Jan 2003, if "ebshome" || "eugene" are sufficient enough search strings. > > We would certainly be happy to keep a 2.4 branch of MTD alive if there > > would be any noticable support available instead of whinging about the > > brokenness of the MTD CVS. > > Could you point to any e-mail where I was whining about brokenness of MTD CVS? > If not, what was the purpose of your statement? References: <20040726134847.84704.qmail at web15214.mail.bjs.yahoo.com> Cite: "This is quite sad, but not all maintainers do the same. IIRC networking fixes are still backported to 2.4. Hopefully, I can maintain this stuff myself and backport fixes (what I already did for some MTD stuff, btw)." You are accusing David of being not as 2.4 friendly as other maintainers seem to be in your opinion. > This is the exact attitude which will not help you to get "any noticeable > support". You're attitude is exactly what I'm talking of and why I choose this tone: "(what I already did for some MTD stuff, btw)." > > But we certainly do not get any further, when people have patches around > > and complain why we have not included them into MTD CVS by magic > > awareness of the solution. > > What is your point? Do you accuse me of not contributing back patches? I > always > do this. I'm just asking where the patches go to. To the usual places ? See above. > You missed the point of this discussion. We wasn't talking about some > random patches floating around. We were talking about stuff which _is_ in 2.6 > but not 2.4. Also, we were talking about how mature is 2.6 for production > environment and how "dead" is 2.4 I'm well aware of what you were talking in foreground, but I'm also able to read the implicit things between the lines. Quite in contrary: Random patches floating around which do not make their way to the place where they should go, _ARE_ part of the problem. tglx ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
2.4 versus 2.6 patches
On Mon, 2004-07-26 at 18:30, Eugene Surovegin wrote: > On Mon, Jul 26, 2004 at 10:27:52AM -0400, David Woodhouse wrote: > > Because nobody's really that interested in it. For what it's worth, I've > > abandoned all pretence of continuing to support 2.4 in the MTD/JFFS2 CVS > > tree. > > This is quite sad, but not all maintainers do the same. IIRC networking fixes > are still backported to 2.4. Maybe not all maintainers suffer from continous lack of collaboration and community feedback. > Hopefully, I can maintain this stuff myself and backport fixes (what I already > did for some MTD stuff, btw). Cool (where are the patches, btw ???). We would certainly be happy to keep a 2.4 branch of MTD alive if there would be any noticable support available instead of whinging about the brokenness of the MTD CVS. But we certainly do not get any further, when people have patches around and complain why we have not included them into MTD CVS by magic awareness of the solution. tglx ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
