Where to Put Ethernet MAC Addresses?
On Wed, Oct 01, 2003 at 03:32:09PM -0400, Kent Borg wrote: > What are the various right ways to do this? Thanks for the various answers. -kb, the Kent who will be putting MAC adress setting off onto the boot ROM. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Where to Put Ethernet MAC Addresses?
On Wed, Oct 01, 2003 at 01:43:43PM -0700, Howard, Marc wrote: > I also select as the first 3 bytes of the MAC address the address > assigned to a defunct company and the lower 3 bytes derived from the > serial number. I kinda like that outlaw approach, it fits in with one of my pet notions: why must ethernet hardware be issued strictly unique MAC addresses? It is important that a given MAC address be unique on a single network, but once a packet hits a router, it is OK to have a duplicate on the next network, right? (OK, maybe the router keeps a single ARP table for all its directly connected networks and the collision risk is one ply larger.) If decent random numbers are available (as they can be with Linux), why not adopt a random MAC address? Notwithstanding the "birthday paradox", 48 bits (or is it effectively 47?) is still a whopping *big* space. Given a decently chosen random MAC address, how big does a network of random MAC addresses have to be for the chance of a collision to be at all dangerous? Thanks, -kb ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Where to Put Ethernet MAC Addresses?
In boards where there is ethernet but no manufacturered in MAC address in the ethernet hardware, where does one get it? Does this become a userland problem to be handled in init scripts? It seems that ethernet initialization could also set the "manufacturer" MAC address, and it might be stored in flash next to the Linux image, or in some extra SPD bits, etc. What are the various right ways to do this? Thanks, -kb ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
IO, ANSI vs GCC structs
How important is it to the kernel coding style that hardware be accessed through a structure? Is it acceptable to do: #define MYHW (MY_MBAR+42) ... out_be32(MYHW, 0xco1df00d); ? Thanks, -kb ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
IO, ANSI vs GCC structs
The PPC arch likes to access physical devices with C structures that
correspond to a memory map of device registers. But a colleague says
that structure layout is not guaranteed. In fact, he cited two
instances when he got burned by assuming he could predict structure
layout. But neither of those examples were with GCC.
Does GCC make guarantees beyond what ANSI requires? Is there some
subtle detail that forces struct layout ("volatile" in the definition
perhaps)?
Thanks,
-kb
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
ptrace Problem
On Wed, Jul 16, 2003 at 12:37:51PM +0200, Kenneth Johansson wrote: > > On Tue, 2003-07-15 at 23:49, Kent Borg wrote: > > > Looking at likely source tarballs we have sitting around it seems very > > likely that binutils were built from 2.13.2.1, and glibc 2.3.2. (How > > can I be sure?) > > binutils binaries usually respond with the version when given -V on the > command line. Oh! I thought that was a version of an individual component, but lordy, nm and objdump both give the same number and it matches the tar I had guessed we had used. > libc can be checked with objdump -x and checking the Version > definitions. It lists a series of numbers ranging from 2.0 to 2.2.2. > This should not be a problem gdb dose all the work using ptrace. Indeed, gdb didn't drag me down into any libraries. > Regarding your gdb problems have you tried with a kernel without bdi2000 > support in the kernel. No, but I will now. Thanks, -kb ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
ptrace Problem
On Tue, Jul 15, 2003 at 12:30:26PM -0400, Jean-Denis Boyer wrote: > Which chip is it? An unreleased 603-ish core with other stuff added. > Is it correctly recognized by the kernel > (arch/ppc/kernel/cputable.c)? I long ago added an entry to cputable.c, and am using it. I'll look at those specifics again though. Good tip. ...and I just made a change that might help... and that didn't help > This is a silly question, but, did you try to unplug the BDI-2000 > before running gdbserver? Just in case it stops on some exceptions... If I understood correctly: use Abatron to download my code, make sure things are running, them pull that power, and things still run. Attempt to do gdb/gdbserver and it malfunctions in the same way--or at least I think so, I don't have an Abatron hooked up. > Do you use a somewhat recent version of glibc, and was it built > against a somewhat recent version of kernel? Can you also tell us > the version of binutils and gcc ? Not all the combinations are > reliable ;-) Looking at likely source tarballs we have sitting around it seems very likely that binutils were built from 2.13.2.1, and glibc 2.3.2. (How can I be sure?) gcc reports 3.2.2. Are those a compatible set? Thanks, -kb ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
ptrace Problem
I am trying to get ptrace() working correctly so I can use gdbserver so we can debug with more power than printf()'s. The kernel is 2.4.21-rc1 with stuff done to it to support some hardware that is under development (the chip has a 603-style core). I can fire up gdbserver, I can attach to it with a gdb on my host. I can watch the little ptrace transactions go by and (after eliminating some false leads) they all do seem to be doing sensible things. But when I try an "si", everything seems OK upto the _switch at which point the kernel SIGSTOPs on a 0x0 instruction at the first instruction of my application (or is it the second instruction?--I am not sure, the address complained about is first+4, maybe one worked). Once this happens my Abatron BDI-2000 is somehow hosed and can no longer write to memory. My next download takes all the time I would expect, but the results are all 0x0 unless I first powercycle the Abatron. The kernel seems to otherwise be working quite well. As this is new hardware, I cannot state that it is certainly working correctly. Obviously I suspect that something is wrong with how some memory management data structure is set up when the ptrace calls are being made by gdbserver, but I am not smart enough to have a clear idea of what to look for. (I don't want to get lost in walking page tables and tracing TBL faulting and whatnot for another week--not if I don't have to.) I have tried changing from our previous gdb and gdbserver to the Denx versions with same results. Suggestions? Thanks, -kb ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Heretical Question
On Wed, Jul 09, 2003 at 04:09:01PM -0400, Steven Blakeslee wrote: > ddd will let you specify a gdb debugger to use. You have to add -g -ggdb to > the CFLAGS and compile the kernel. Then give the command > > ddd --debugger ppc_8xx-gdb vmlinux > > Replace ppc_8xx-gdb with your debugger of choice, gdb is the default if you > do not specify. Yes, that works. Thanks. But it isn't as nice as I had hoped. The display feature chews up lots and lots of screen space, and little things like clicking on something that began with "/x" fails, making it hard to browse values in hex. I was starting to get the hang of how to sort of use it when I realized that I could do better with gdb inside emacs. Hmmm. I'll have to try insight next. -kb ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Heretical Question
I know it is wrong for me to ask, but is there (possibly already lurking in my Red Hat box?) a graphical front end to GDB that will work with embedded programming? Emacs already lets me debug with source code pretty well (not assembly, however), and that is nice, but what I really miss is a way to browse through data structures. Kdbg looks good, but it seems to be for native debugging only (though I might hack at it a little to issue the elusive "target remote ..."). It is possible ddd would do, but it also seems to be for native debugging only too. Suggestions? Thanks, -kb ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
gdbserver, find_extend_vma(), and VM_GROWSDOWN
I am having gdbserver problems. I can run gdbserver and attach to it with gdb, but the peeks into the application space are failing. For example, in debugging the peek for the first instruction of my application, there is a call to find_extend_vma() (in mm/mmap.c). The test for: vma->vm_start <= addr fails, and as this vms is VM_GROWSUP (and not VM_GROWSDOWN), the next if-statement returns a NULL. That percolates up until ptrace returns zero. This application code runs pretty well without gdbserver, what should I look for next? Is it indeed perverse for the addr to be below the start? Who is likely to blame for that? Where should I look next? Do I start grepping for every instance of PT_PTRACED in arch/ppc? Thanks, -kb, the Kent whose gdbserver Makefile says it is 4.12.3, and whose kernel is quite close to 2.4.21.rc1. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Large initrd and arch/ppc/boot/simple Question
On Tue, Jul 01, 2003 at 05:07:06PM -0500, Mark Hatle wrote: > Yes, you can definatly kill a kernel by asking for too much memory. I wrote a simple test program that malloc()s a 64KB block, fills it with data, malloc()s another, fills it, etc. If I run it in the background and queue up a bunch of copies in bash's input buffer, the kernel quickly grinds to a near halt as the kernel starts scrounging for memory and kills these processes one at a time. I can get a ps to eventually run, showing as many as two dozen of these hungry programs--though it is a little like astronomy of distant objects: by the time ps completes the processes listed have already been long ago announced in the console as killed. And once they have all run and been killed, the system is again responsive and appears to be happy. So the OOM killer in 2.4 works in this simple case, multiplied. The case of our big program dying is certainly more complicated. We are looking to see what it is using/whether it can be told to restrain itself. Thanks, -kb ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Large initrd and arch/ppc/boot/simple Question
On Tue, Jul 01, 2003 at 03:12:39PM -0700, Tom Rini wrote: > After reading the follow ups, is the problem that the kernel never > boots if you pass too large of a ramdisk or that the app does not > work? We have had cases where the kernel never boots once we turned on extra debugging code, but in the case we are cornering now, the app causes an oops, apparently on mallocing too much memory. -kb, the Kent who is about to write up a simple test case of that. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Large initrd and arch/ppc/boot/simple Question
Looking more, it seems that we are (at minimum) killing the kernel by asking for too much memory. We are seeing whether we can reproduce that with a simpler program. -kb In the meantime, here is some output of and about our crash: $ size bigapp.strip text data bss dec hex filename 7465252 97296 401844 7964392 7986e8 bigapp.strip $ size /tftpboot/zImage.initrd.elf text data bss dec hex filename 24896 6856704 12732 6894332 6932fc /tftpboot/zImage.initrd.elf loaded at: 0200 026941BC zimage at: 02007D34 02097813 initrd at: 02098000 02690529 avail ram: 0040 0100 Linux/PPC load: console=ttyS0,115200 ip=off mem=48m Uncompressing Linux...done. Now booting the kernel Warning hardcoded alaska_find_end_of_memory() alaska.c:172 Memory BAT mapping: BAT2=32Mb, BAT3=16Mb, residual: 32Mb Linux version 2.4.21-rc1 (pbarada at hyper) (gcc version 3.2.2) #136 Tue Jul 1 16:36:46 EDT 2003 On node 0 totalpages: 12288 zone(0): 12288 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: console=ttyS0,115200 ip=off mem=48m Calibrating delay loop... X BogoMIPS Memory: 41056k available (1028k kernel code, 308k data, 64k init, 0k highmem) Dentry cache hash table entries: 8192 (order: 4, 65536 bytes) Inode cache hash table entries: 4096 (order: 3, 32768 bytes) Mount cache hash table entries: 512 (order: 0, 4096 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 16384 (order: 4, 65536 bytes) POSIX conformance testing by UNIFIX PCI: Probing PCI hardware Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd pty: 256 Unix98 ptys configured Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled ttyS00 at 0xf1001008 (irq = 73) is a ST16650 ttyS01 at 0xf1001010 (irq = 74) is a ST16650 RAMDISK driver initialized: 16 RAM disks of 14336K size 1024 blocksize loop: loaded (max 8 devices) PPP generic driver version 2.4.2 PPP Deflate Compression module registered NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 4096 bind 8192) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. RAMDISK: Compressed image found at block 0 Freeing initrd memory: 6113k freed VFS: Mounted root (romfs filesystem) readonly. Freeing unused kernel memory: 64k init INIT: version 2.78 booting INIT: Entering runlevel: 1 /etc/rc: line 11:18 Terminated /sbin/syslogd [01/Jan/1970:00:00:07 +] boa: server version Boa/0.94.8.3 [01/Jan/1970:00:00:07 +] boa: server built Jun 20 2003 at 10:43:07. [01/Jan/1970:00:00:07 +] boa: starting server pid=25, port 80 "Space, a great big place of unknown stuff." -Dexter, for our MotD. sh-2.05b# sh-2.05b# ps PID Uid Stat Command 1 root Sinit 2 root S[keventd] 3 root S[ksoftirqd_CPU0] 4 root S[kswapd] 5 root S[bdflush] 6 root S[kupdated] 19 root S/sbin/syslogd 21 root S/sbin/xinetd 23 bin S[portmap] 25 root S/bin/boa 29 root S/bin/sh 30 root Rps sh-2.05b# sh-2.05b# cat /proc/meminfo total:used:free: shared: buffers: cached: Mem: 48369664 18210816 301588480 2772992 13422592 Swap:000 MemTotal:47236 kB MemFree: 29452 kB MemShared: 0 kB Buffers: 2708 kB Cached: 13108 kB SwapCached: 0 kB Active: 4008 kB Inactive:12616 kB HighTotal: 0 kB HighFree:0 kB LowTotal:47236 kB LowFree: 29452 kB SwapTotal: 0 kB SwapFree:0 kB sh-2.05b# sh-2.05b# df Filesystem 1k-blocks Used Available Use% Mounted on rootfs 12161 12161 0 100% / /dev/ram012161 12161 0 100% / /dev/ram1 100326 977 3% /var sh-2.05b# sh-2.05b# cd /tmp sh-2.05b# /usr/local/bin/bigapp.strip -m8m Assert failed: "sjret == 0xABCD" ../ts/tsmdsun.c:580 Fatal at line 580 in ../ts/tsmdsun.c Terminating execution via an "illegal instruction" signal Illegal instruction sh-2.05b# /usr/local/bin/bigapp.strip -m16m Oops: kernel access of bad area, sig: 11 NIP: C002F3A8 XER: LR: C002F2D0 SP: C24C3D60 REGS: c24c3cb0 TRAP: 0300Not tainted MSR: 1032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11 DAR: , DSISR: 2200 TASK = c24c2000[34] 'bigapp.strip' Last syscall: 90 last math c24c2000 last altivec GPR00: C24C3D60 C24C2000 00
Large initrd and arch/ppc/boot/simple Question
We are booting our kernel via the arch/ppc/boot/simple mechanism to package up our kernel and initrd. It seems to work, until we get too big. What is big? Roughly 8 MB for our one big uncompressed userland program, plus the kernel, bash, busybox, and various userland utilities. Can initrd's get that large and still work? Is the simple boot code sensible with these sizes? (I notice that the "avail ram" message that gets printed is just hard coded number...) Thanks, -kb, the Kent who is running roughly 2.4.21-pre6. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Why ack interrupt before calling handler?
On Wed, Jun 11, 2003 at 02:24:23PM +0200, eric lescouet wrote: > This would prevent a level triggered interrupt to be raised again when > enabling > interrupts at processor level, until the called handler clear the interrupt > condition on the device. And it occurs to me that unless an interrupt can be "queued" between the time the handler has checked (one last time) for all pending work and the PPC code re-enables the interrupt at the PIC level, this would be a window in which an edge-triggered interrupt could be lost. > Any way, note that these routines called from irq.c are PIC driver > specific, Yes. I have one set of PIC code that is for an interrupt controller that is on-chip with the CPU, and I have a second set of PIC code for a cascaded interrupt controller that is implemented in an off-chip FPGA. It is kind of cool that such nested complexity can be so nicely represented to the kernel by simply having a single flat list of IRQs. (I didn't spot that simple solution, Dale Farnsworth had to point it out to me.) Thanks, -kb, the Kent who is willing to learn from others. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Why ack interrupt before calling handler?
On Wed, Jun 11, 2003 at 12:33:42PM +0200, Kenneth Johansson wrote: > I don't know what code you are looking at but generally you want to > first ack to avoid the race condition that would otherwise be present if > you first run your interrupt routine then ack. How would you know that > it was in fact not a new interrupt condition that you have not taken > care of you just removed. In my case I have a level-triggered interrupt that is latched by the hardware. So the first ack tells the interrupt controller to forget about it, but as the interrupting hardware has not yet been serviced, the level-triggered interrupt is still being asserted, so that ack becomes a nop. Now the specific handler gets called, it deals with the specifics of the situation, removing the cause of the interrupt, and returns. Finally the interrupt end gets called, which acks and enables the interrupt. This ack actually does something for me. I am thinking that the general purpose PPC code does the early ack for edge-triggered circumstances. For latched level-triggered cases there is no harm in the extra early ack. Thanks, -kb, the Kent whose nose has been closely in that code because he has been chasing a spurious interrupt problem. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Why ack interrupt before calling handler?
I am confused by something in ppc_irq_dispatch_handler(). It looks to me that the interrupt is ack-ed before the handler is called. Maybe I am misunderstanding, but doesn't the ack only reset the interrupt controller? If so, the interrupting hardware could still be presenting a level-triggered interrupt. Wouldn't it make more sense to let the interrupt routine get service the hardware first, then reset the interrupt controller? Thanks, -kb ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Shared Interrupts Question (2.4)
On Thu, May 08, 2003 at 02:14:26PM -0700, Dale Farnsworth wrote: > Create and register a board-specific interrupt driver. Assign it > a range of irqs (non-conflicting with the main interrupt driver). > When called with an irq outside its range, the board-specific driver > routines forward the call to the main driver. Cool, cool... > The board-specific driver does a request_irq at init time for the > one main irq it is multiplexing. What does my handler on the main irq do? Perhaps nothing? I am figuring I supply my own get_irq call, and it returns one of this new interrupt range, or if none, calls the previous get_irq. If I never let the main irq number come back, my handler on the main irq never gets called, right? If so, why am calling request_irq in the first place? To keep the system from puking on spurious interrupts? (But if I answer the get_irq, and if I never answer the main irq number, how would it know?) Thanks, -kb, the Kent who thinks he is getting close. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Shared Interrupts Question (2.4)
Dale Farnsworth wrote: > Create and register a board-specific interrupt driver. Assign it > a range of irqs (non-conflicting with the main interrupt driver). > When called with an irq outside its range, the board-specific driver > routines forward the call to the main driver. The board-specific driver > does a request_irq at init time for the one main irq it is multiplexing. Yes! Flatten the cascaded interrupts to IRQs outside the CPU's, range, and write a software multiplexer that registers for the one IRQ the CPU knows. Right? That's much better than what I had in mind. Thanks, -kb ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Shared Interrupts Question (2.4)
On Thu, May 08, 2003 at 01:20:12PM -0700, bhupinder sahran wrote: > SO in the do_irq routine u will have to read the > interrupt controller registers & find out who has > caused the interrupt & then invoke interrupt handler > corressponding to the interrupt number. Yes, but how do I enable the interrupt in the first place? (Disable too.) I mean, I know how to set the bit, but where is the best place to do so? In the case of a serial port, I figure I could turn it on in startup() in serial.c. But then how do I know which of two possible interrupts it is? I could do something hacky, like look at the UART address and infer from there, but that looks nasty... Thanks, -kb, the Kent who, if has to muck with existing kernel files, wants to do so in an acceptable way. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Shared Interrupts Question (2.4)
I am trying to understand "kinda shared" interrupts. There are various interrupts in my not-yet-released CPU, and I have interrupt code that knows how to talk to them. So far so good. I also have an external interrupt controller that groups together 18 external interrupt sources and sends them in one CPU pin. This external controller has a register for enabling interrupts, and a register for status/acknowledge. Pretty standard. The CPU code doesn't know about the external controller. It seems silly to rewrite the CPU-specific interrput code to accommodate this board-specific detail (besides then my code won't match Dale's). So I figure I tell the kernel I am doing shared interrupts. So where do I enable, disable, and acknowledge these external bits? Specifically, I am trying to get a couple of serial ports working. I can put conditional code in serial.c startup() to enable these interrupts, but how do I know which serial port? Add a conditionally compiled sub-IRQ number to serial_state structure? Is there a cleaner way? Thanks, -kb ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
boot/simple in ROM?
On Thu, Apr 24, 2003 at 11:06:32AM -0700, Kerl, John wrote: > I based mine off boot/simple. It runs fine from ROM. > > Suppose for example I have 32MB SDRAM from 0x > to 0x01ff, and 16MB flash from 0xff00 to 0x. > The key is that arch/ppc/boot/ld.script, and ...suddenly I GET it! I was being too clever and trying to link for my ROM address, and of course that will put the stack and bss in ROM. Duh. When I simply burn my 0x80 RAM image at 0xfec0 the bss and stack are still down in 0x80-range, and it works great. Thanks to all for having such patience, -kb, the Kent who is glad he didn't ask such a question on, say, the qmail list. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
boot/simple in ROM?
On Thu, Apr 24, 2003 at 01:13:35PM -0400, Dan Malek wrote: > The other really nice thing about these bootloaders, compressed > kernels, and attached initrd, is you can boot the identical image > from all "devices." For example, during development you can tftp > load the image, get everything working, then place the exact same > bits into a flash rom. Simply jump to the first location of the > image and it will boot from flash. Yes, but disappointingly the ppc/boot/simple I am using (from 2.4 devel) won't run from ROM. Is there a better boot loader I should be using? Thanks, -kb ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
boot/simple in ROM?
The boot loader thingie in arch/ppc/boot/simple is nifty. So why isn't there a provision for putting it on ROM? (Or is there and I missed it?) Because boot/simple decompresses to RAM at 0x0, it seems obvious that it might be decompressing from ROM. What is the right way to do this? (Or, pointers on how to make it ROMable would be appreciated.) Thanks, -kb, the Kent who got as far as Linux booting most of the way but not finding initrd because he has it messed up. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Hardcoded Hash_base?
On Thu, Mar 13, 2003 at 12:44:50PM -0500, Jean-Denis Boyer wrote: > > > In arch/ppc/mm/hashtable.S Hash_base is hardcoded at 0xc018, with > > a comment suggesting that that value is "just an example". It seems > > to be colliding with my initrd, so I am thinking I want to move it. > > As the comment says, this code is patched at runtime. > It is done by MMU_init_hw, in arch/ppc/mm/ppc_mmu.c. > The value of Hash_base could be anything, it doesn't matter. I guess it does say that. I my eyes glazed over the several times I tried to understand the comment right before that. Thanks, -kb ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Hardcoded Hash_base?
In arch/ppc/mm/hashtable.S Hash_base is hardcoded at 0xc018, with a comment suggesting that that value is "just an example". It seems to be colliding with my initrd, so I am thinking I want to move it. What restrictions are there for where it goes? Why doesn't it get defined from the link? How is it that other things are supposed to be kept clear of it? (Because it is in an mm-directory, does that mean that the memory manager knows not to allocate that RAM?) Thanks for any help, -kb ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
register_serial() confusions
On Tue, Feb 25, 2003 at 07:38:07PM -0500, Kent Borg wrote: > > How does register_serial() get called? (Does it?) It turns out "Does it?" was key. If I am on the right track, my non-module, non-PCMCIA code will never call register_serial(). Yes, I was missing some initialization, and is was my missing adding a call to my version of serial_console_init(). Oops. Sorry to be a bother. -kb ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
register_serial() confusions
How does register_serial() get called? (Does it?) I am trying to get some non-standard serial hardware, and I am confused about the initialization. And I swear I knew this once. Anyone have this on the tip of his/er fingers? Thanks, -kb ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Bringing up Motorola MGT5100
On Thu, Feb 20, 2003 at 12:55:23PM -0700, Tom Rini wrote: > > On Thu, Feb 20, 2003 at 02:48:12PM -0500, Kent Borg wrote: > > [snip] > > [TARGET] > > CPUTYPE 5100;the CPU type > > Are you sure you want this? Maybe it should be '603'.. I certainly am not sure, but as the file from Abatron has "5100" as part of its name, I think they know of this beast. > > > ;MMU XLAT ;translate effective to physical address > > PTBASE 0x00f0 ;here is the pointer to the page table pointers > > Keep the MMU line, YES! Looky: Breakpoint 1, 0xc00037a0 in start_here () 3: x/5i $pc 0xc00037a0 : lis r2,-16368 0xc00037a4 :ori r2,r2,42032 0xc00037a8 :addis r4,r2,16384 0xc00037ac : addir4,r4,624 0xc00037b0 : mtsprg 3,r4 (gdb) > comment out the PTBASE maybe? But I want that hint to work once I get that far...and I can read those high values without changing it, so I'm leaving it alone for now. Thanks a bunch, -kb ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Bringing up Motorola MGT5100
On Thu, Feb 20, 2003 at 12:36:11PM -0700, Tom Rini wrote: > Bad config. Can you post it please? If you could spot any obvious errors in here, I would love that. Thanks, -kb ; bdiGDB configuration file for the MGT5100 evaluation board ; -- ; [INIT] ; init core register WREGMSR 0x1002 ;MSR : ME,RI WM320x8000 0x0001e000 ;MBAR : internal registers at 0xf000 WSPR279 0xf000 ;SPRG7: save internal register offset ; ; init memory controller ;WM320x8004 0x0001ffe0 ;CS0STR: start = 0xfff0 ;WM320x8008 0x0001ffef ;CS0STP: stop = 0xfff7 ;WM320x8300 0x00047800 ;CS0CR: ctrl ;WM320x8054 0x0041 ;ADREN: enable CS0, disable CSBOOT ; WM320xf04c 0x0001ff00 ;BOOTSTR: start = 0xff80 WM320xf050 0x0001 ;BOOTSTP: stop = 0x WM320xf300 0x00043801 ;CS0CR: ; WM320xf034 0x ;SDRAMSTR: Start = 0x WM320xf038 0x07ff ;SDRAMSTP: Stop = 0x03ff WM320xf054 0x0240 ;ADREN: SDRAM enable WM320xf108 0xc600 ;SDRAM Config 1 WM320xf10c 0x88b70004 ;SDRAM Config 2 WM320xf110 0x0300 ;SDRAM Adrsel WM320xf104 0xd14f ;SDRAM Control WM320xf104 0xd14f0002 ;SDRAM Control WM320xf104 0xd14f0004 ;SDRAM Control WM320xf100 0x008d ;SDRAM Mode WM320xf104 0x514f ;SDRAM Control ; define maximal transfer size TSZ40xFF80 0x ;ROM space TSZ40xF000 0xF0003FFF ;internal registers ; define the valie memory map MMAP0x 0x03FF ;Memory range for SDRAM MMAP0xF000 0xF0003FFF ;Memory map for Internal Register MMAP0xF004 0xF0005FFF ;Memory map for On-chip SRAM ; Setup MMU info WM320x00f0 0x ;invalidate page table pointer pointer [TARGET] CPUTYPE 5100;the CPU type JTAGCLOCK 0 ;use 16 MHz JTAG clock WORKSPACE 0x0200 ;workspace for fast download and cache flush BDIMODE AGENT ;the BDI working mode (LOADONLY | AGENT) ;STARTUP STOP 5000 WAKEUP 1000;give reset time to complete BREAKMODE HARD;SOFT or HARD, HARD uses PPC hardware breakpoint ;MMU XLAT ;translate effective to physical address PTBASE 0x00f0 ;here is the pointer to the page table pointers DCACHE NOFLUSH ;VECTOR CATCH ;catch unhandled exceptions ;MEMDELAY2000;additional memory access delay ;PARITY ON ;enable data parity generation [HOST] ; in the copy in your /tftpboot directory, uncomment the line that is yours IP 199.10.246.44 ; rome ;IP 199.10.246.18 ; vienna ;FILEE:\cygwin\home\bdidemo\mpc4200\fibo.exe ;FILEE:\cygwin\home\bdidemo\mpc4200\eppc_c_isr.elf ;FILEvmlinux FILElinux.bin FORMAT BIN ;FORMAT ELF ;LOADMANUAL ;load code MANUAL or AUTO after reset [FLASH] [REGS] DMM10xF000 ;dBug remaps IPIB to 0xF000 FILEreg5100.def ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Bringing up Motorola MGT5100
I am working on bringing up Linux on a Motorola MGT5100 board. It's core is roughly a 603e, with lots of other devices on the chip. I am using an Abatron and have a question about really early boot. When the MMU is first turned and we are executing at 0xC-bazillion the Abatron can't read the contents of those addresses. Is this a dark time when the Abatron isn't expected to be able to read that memory, or do I have the MMU or Abatron set up wrong? (I can single step and put hardware breakpoints up there.) Thanks, -kb ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
gdb / gdbserver part 2
On Wed, Jan 23, 2002 at 10:15:22AM -0700, Mark Pilon wrote: > I've made some progress but have hit a strange snag and would > appreciate any context / suggestions you might have. I don't know if the symptoms you describe fit, be we had a related problem recently. Our boot ROM was not clearing the debug hardware at boot. The ptrace trap handling code was then tripping over spurious bits in whatever the status word is called. -kb ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Boot ROM Responsibilities (and GDB)?
Is there any documentation on what a 405 boot ROM is supposed to do before jumping to the PPC kernel? We finally found what was messing with our use of GDB. DBSR was (sometimes) coming up with some unfortunate bits set, our boot ROM didn't know to clear them and the code that actually uses the CPU's debug hardware didn't bother to put that hardware in an appropriate state. Coming from an old fashioned perspective where boot ROMs are little and only sufficient to get the next higher level of program running, it seems strange to make them have to know anything about details of assorted hardware other than to disable optional things and make very basic things (like RAM access) work. Because we have a custom boot ROM (lifted from a previous non-Linux use of the same board--that's part of the beauty of having boot ROMs be simple, they are then quite universal and can be written quite early in the project before you even know what the project is) what else are we missing? What are a PPC boot ROM's responsibilities? (I.E., what do we add to our version of head.S.) Thanks, -kb, the Kent who is trying to keep his head in two different arch trees at once without too much confusion. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Good GDB Version?
On Fri, Dec 14, 2001 at 01:53:12PM -0500, I wrote: > We are having problems with gdb. And, though we have not gotten to the bottom of it, we seem to have a hardware problem. But a bizarre one. We download our code, watch the kernel boot, get an sh prompt. Fire up ethernet, do an NFS mount of a directory on the development machine. Launch gdbserver on a trivial helloworld program, attach from gdb on the development machine (using ethernet). All that works. It would seem to suggest the hardware is working, right? Well, that's what we thought. Tell gdb to continue. Immediately get a SIGTRAP. And further attempts to use gdb act strange, such as after hitting a breakpoint not being able to continue from there. Re-downloading the boot ROM does not fix it. Swap in a different logic card, do all the above, and everything is the same except that initial SIGTRAP doesn't happen and breakpoints can be continued from and everything seems completely happy. That board works. Swap in the physical boot ROM from the good board to the bad board and the problem stays with the bad board. Both boards have the same rev of the 405GP. How could we have crafted a custom board that can recognize that gdb is running an only malfunction then? I didn't know hardware could be so clever. My only guess is something hanging around the JTAG (or is it BDM?) debug port might be funny--for the debug port has privileged access to some of the same internal hardware that gdb uses. Maybe a hardware fault there could cause spurious SIGTRAPs--or maybe something is fritzed inside the 405's debug hardware. Strange. -kb ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Good GDB Version?
We are having problems with gdb. Using gdb to talk to gdbserver over ethernet to our custom 405 board we can run a trivial application, we can drop a breakpoint, land at the breakpoint, look at variables and stuff--but trying to continue doesn't move us forward. When we revert to an old kernel we were using that originally came from mvista.com's area51 (circa last spring) gdb/gdbserver works, so I don't think it is an immediate operator error (but it maybe something more subtle...). I am wondering whether we have the right gdb. Our current version is 5.0. We also tried 5.0.93 (it didn't work either), but we worry that our gdbserver wasn't matched with it. What gdb/gdbserver do y'all use? (Where did you get it??) When co-worker Peter last built gdbserver for us he couldn't find maintained sources and had to do some cobbling to make it work. (That was at 5.0, a few months ago.) Have there maybe been signifcant changes to ptrace that we need to know about here? Is ptrace is working order currently? One more detail, these symptoms are on a kernel brought up to date with a linuxppc devel rsync from yesterday afternoon. Suggestions? Thanks, -kb, the Kent who is writing this on behalf of a colleague who isn't on the list. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Compile Penguin PPC for x386?
Is the i386 arch vaguely up to date in the PPC tree? Does it work? I mean, if I want to debug some driver that doesn't need actual hardware (maybe dummy out actual HW banging), can I swap over to building an i386 kernel? It would be nice to be using the same kernel. If I can do that, how? In Makefile I changed "ARCH" to i386, changed "CROSS_COMPILE" to be nothing, did a "make mrproper", copied in a .config from my Red Hat install, defaulted everything asked by "make oldconfig", did "make dep", and "make bzImage". But then it chokes on some problem in include/linux/highmem.h (48: parse error before `0'). Should this work? Thanks, -kb ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Abatron for Userland Debugging?
I have used the Abatron to debug the kernel, but I am wondering whether it can easily be used to debug on the user side of the fence. Can it? (If so, how?) Thanks, -kb ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Typo in drivers/char/Config.in?
Sorry about doing a send before I was through writing that last e-mail. As I was saying, I think there is a typo in drivers/char/Config.in. -kb --- linuxppc_2_4_devel/drivers/char/Config.in Thu Nov 29 11:07:32 2001 +++ linuxppc_2_4_devel/drivers/char/Config.in.fixed Fri Nov 30 10:44:33 2001 @@ -191,7 +191,7 @@ dep_tristate 'Intel i8x0 Random Number Generator support' CONFIG_INTEL_RNG $CONFIG_PCI tristate '/dev/nvram support' CONFIG_NVRAM -if [ "$CONFIG_PPC_ISERIES" != "y" -a "$CONFIG_PPC_PSERIES" != y ]; then +if [ "$CONFIG_PPC_ISERIES" != "y" -a "$CONFIG_PPC_PSERIES" != "y" ]; then tristate 'Enhanced Real Time Clock Support' CONFIG_RTC fi if [ "$CONFIG_IA64" = "y" ]; then ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Typo in drivers/char/Config.in?
In drivers/char/Config/in, line 194, there seems to be a typo. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] New PHY for ppc405_phy.c
I hope I am sending this to the right place, someone please correct me
if I am doing this wrong...
Our 405 board has a different PHY from those supported in the current
sources, the following patch makes our PHY work. If it looks
sensible, please apply.
Thanks,
-kb
--- linuxppc_2_4_devel/drivers/net/ppc405_phy.c Thu Nov 29 10:34:53 2001
+++ linux-penguinppc4/drivers/net/ppc405_phy.c Thu Nov 29 10:48:07 2001
@@ -579,6 +579,75 @@
},
};
+/* - */
+/* The Lucent Technologies LU3X31FT */
+
+/* register definitions */
+
+#define MII_LU3X31FT_PHYCTRLSTS 0x17/* PHY Control/Status Register */
+#define MII_LU3X31FT_IER0x1D/* PHY interrupt enable Register */
+#define MII_LU3X31FT_ISR0x1E/* PHY interrupt status Register */
+
+static void mii_parse_lu3x31ft_pcr(uint mii_reg, struct net_device *dev)
+{
+ struct fec_enet_private *fep = dev->priv;
+ volatile uint *s = &(fep->phy_status);
+
+ *s &= ~(PHY_STAT_SPMASK);
+
+ switch((mii_reg >> 8) & 3) {
+ case 0:
+ *s |= PHY_STAT_10HDX;
+ break;
+ case 1:
+ *s |= PHY_STAT_10FDX;
+ break;
+ case 2:
+ *s |= PHY_STAT_100HDX;
+ break;
+ case 3:
+ *s |= PHY_STAT_100FDX;
+ break;
+ }
+}
+
+static phy_info_t phy_info_lu3x31ft = {
+ 0x90307421,
+ "LU3X31FT",
+ 0,
+ (const phy_cmd_t []) { /* config */
+
+ /* parse cr and anar to get some info */
+
+ { mk_mii_read(MII_REG_CR), mii_parse_cr },
+ { mk_mii_read(MII_REG_ANAR), mii_parse_anar },
+ { mk_mii_end, }
+ },
+ (const phy_cmd_t []) { /* startup - enable interrupts */
+ { mk_mii_write(MII_LU3X31FT_IER, 0x), NULL },
+ { mk_mii_write(MII_REG_CR, PHY_BMCR_RST_NEG), NULL }, /*
autonegotiate */
+ { mk_mii_end, }
+ },
+ ( const phy_cmd_t []) { /* ack_int */
+
+ /* we need to read ISR, SR and ANER to acknowledge */
+
+ { mk_mii_read(MII_LU3X31FT_ISR), NULL },
+ { mk_mii_read(MII_REG_SR), mii_parse_sr },
+ { mk_mii_read(MII_REG_ANAR), mii_parse_anar },
+
+ /* read pcr to get info */
+
+ { mk_mii_read(MII_LU3X31FT_PHYCTRLSTS), mii_parse_lu3x31ft_pcr
},
+ { mk_mii_end, }
+ },
+ ( const phy_cmd_t []) { /* shutdown - disable interrupts */
+ { mk_mii_write(MII_LU3X31FT_IER, 0xff80), NULL },
+ { mk_mii_end, }
+ },
+};
+
+
/* - */
/* The AMD Am79C875*/
@@ -659,6 +728,7 @@
&phy_info_lxt971a,
&phy_info_cs8952,
&phy_info_dp83846A,
+ &phy_info_lu3x31ft,
&phy_info_Am79C875,
NULL
};
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
source.mvista.com::linuxppc_2_4_devel rsync alive?
On Thu, Oct 25, 2001 at 08:36:19AM -0700, Tom Rini wrote: > On Thu, Oct 25, 2001 at 11:24:01AM -0400, Kent Borg wrote: > > > Is the source.mvista.com::linuxppc_2_4_devel rsync alive and current? > > It is now.. A pull failed and thus it got stuck. And now it works for me too. Thanks, -kb ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
source.mvista.com::linuxppc_2_4_devel rsync alive?
Is the source.mvista.com::linuxppc_2_4_devel rsync alive and current? I though I had a nice system for grabbing changes from it, and I can do an rsync to it, but I am not seeing any changes for quite a few days. Commit e-mails are going by... Am I doing something wrong? Thanks, -kb ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Dying of First sti()
On Mon, Oct 22, 2001 at 04:21:18PM -0400, Kent Borg wrote: > I make it in init/main.c to the point where sti() is about to be > called. But I never get back from the sti() call. I found my problem. We had put the wrong value in bi_intfreq (and bi_busfreq). We were off by a mere factor of a million. It meant that the PIT was rolling over nearly instantly. Oops. Works *much* better with a sensible value in there. -kb ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Dying of First sti()
I have been trying to move work from an old Linux PPC kernel to a current (rsync-ed from source.mvista.com::linuxppc_2_4_devel) kernel tree. I have a 405GP on a custom board. In this effort I am getting some output on the serial port, I make it in init/main.c to the point where sti() is about to be called. But I never get back from the sti() call. Early in the boot I turned off all interrupt sources. Using RISC Watch I can (laboriously) trace through timer_interrupt(), and I am not caught in an infinite loop in there, it does return. I am thinking our limited boot ROM isn't setting up everything the kernel expects. Ideas? Thanks, -kb ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
BK to CVS?
On Fri, Oct 05, 2001 at 10:48:31AM -0500, Andrew Johnson wrote: > Why don't you use the cvs vendor branch to do most of the work for you, > rather than generating deltas yourself? And so do complete exports? I didn't start out that way because I am running BK on an underpowered machine and complete exports are slow. Aso, where I work there are stupid security policies that force me to mail between that real internet connection that can do BK and the broken corporate network, and mailing whole kernels seems fraught with problems. Your suggestion seesm to imply that complete exports are more reliable than deltas. True? Thanks, -kb, the Kent who is close to conclusion, if for no other reason, because he has to get some real work done. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
BK to CVS?
Progress. I am telling cvs a "-ko" to keep keyword expansions as they come in. But I am still tripping over something that I either don't understand in Bitkeeper, or Bitkeeper is misbehaving. The following doesn't do what I expect. I started things up by doing: - "bk clone", then - "bk changes" to see what the most recent revision is, then - a complete export of that rev, and put that in cvs as my starting point. Then each day I have a script that does: - "bk changes" to see the "before" rev, - "bk pull" to get up to date, - "bk changes" to see "after" rev, - export of a patch between those two revs, apply that to my cvs. The problem is that some of the patches fail because the cvs file isn't in the state the patch expects. Because I am still getting the bugs out, we aren't doing any work in the cvs tree, only bk stuff is going in there. I did a new export from bk as of the latest "bk changes" rev and compared that with an export from cvs. (The idea being that beginning dump + delta + delta + delta should equal ending dump.) Yes, I get some BK Id collisions that don't bother my daily patches, but I also get a couple more files with substantial differences. Is there something wrong with my method? Is there a likely problem with my implementation? Is Bitkeeper being buggy? Thanks, -kb, the Kent who is convinced he is getting close and so should soon quit asking these annoying questions. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
BK to CVS?
On Wed, Oct 03, 2001 at 11:32:45AM -0700, Tom Rini wrote: > Doing this daily isn't too horrid. Use the rsync version and tag > a tree daily. Thats more or less what I do. I might switch to that. But won't I still have a problem of our cvs expanding keywords breaking the next patch that gets too near them? > Yeap. One thing you can try is to un-export the keywords first. Ie > change them back into BK Id: %x% %..% I don't understand. > Smaller hunks and change 'em back into the unexported form? Again I don't think I understand what you mean by "unexported form". Right now I am burning plenty of computrons and rattling the disk a lot (let's hear it for otherwise idle machines) by exporting two complete trees, running a slow perl script over both to remove expansions of dollar-Id, and now dollar-Revision, make my own diff -Nru of that, and then I guess I will have to patch by hand a zillion annoying recent changes to the placement dollar-Id in sparc64 files. And then I will tackle whatever I discover is still not patching after my modified perl script finishes running. I am starting to think that trying to run a shadow source code controlled repository is a mistake. Am I dragging along unadvisable mental baggage from the old days of developing proprietary code? Do I need to take a deep breath here, hold my nose, have faith in The Source, and leap?? Am I foolishly fighting Bitkeeper by trying to stick with cvs internally? Do I need to just give in on Bitkeeper? Thanks, -kb, the Kent who is coming to hate source code control system keywords with more and more authority each day. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
BK to CVS?
We use cvs internally and I am trying to get all the daily patches out of Bitkeeper and into a cvs module. Are others doing this? Is it reasonable? If so, how are you doing it? I tried using "bk export" to generate a patch file I could apply to my cvs tree, but there are Id keywords that cvs honored the last time around making the patch not apply properly. I noticed in the documentation for export that it apparently only honors the "-k" switch for killing keywords when doing a complete export--so I tried that intending to make my patch from two complete Linux trees. Except the -k didn't work. The Id contents are still there in the exported files. Finally, I tried writing some perl to post-process the "bk export" patch to remove the simple Id changes. Cool, but bunches of files, at least in yesterday's pull, have changes up near the Id and so are part of the same patch hunk, and catching that in a perl script is going to be a lot harder. How do the rest of you use Bitkeeper with other source control systems? (Or do you?) Thanks, -kb, the Kent who is coming to hate keywords in source code control systems. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
405 Walnut Status?
What kind of shape is the 405 Walnut code in ppc.bitkeeper.com:5000 linuxppc_2_4_devel kernel? I can't figure out how to even config and compile it. I tried the walnut_config and head_4xx.S dies of an unrecognized opcode (as did an earlier attempt at a config). Looking further, things seem missing (for example in walnut_setup.c, arch/ppc/mm/Makefile, asm-ppc/processor.h). Did I start with the wrong kernel? Thanks, -kb, the Kent who will be off e-mail most of next week. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
RFC: Embedded Linux Page
Mark Hatle wrote:
>Now what I need from you folks are suggests on content
As a representative of one part of your audience, let me describe what
I have been missing: a non-Linux perspective. Now before you dismiss
me as a weirdo who is posting to the wrong mailing list, please read a
bit further.
I have been a user of Linux for some time, I currently use it as a
platform for cross development work, and I used various versions of
Sun's Unix back when. But my current work is writing embedded
software. I start out knowing next to nothing about the Linux kernel,
I have never programmed Linux itself, I don't know (though am
learning) Linux internals. I am an embedded person looking at Linux,
not a Linux person looking at embedding it.
Whether it be true or not, I get the impression that the embedded
community is largely Linux experts who have decided that Linux can
even be used for embedded purposes, ("Isn't Linux great!"). The
sequence seems to be that many of you folks know Linux first, and then
work to adapt it to embedded uses.
Well, I think Linux is great too, but I know less about it and so my
affection for Linux is based more on faith and politics than it is
based on deep knowledge. My sequence is different, I have very
specific embedded needs and also somehow have this idea I need to
learn how to how to get Linux to fill them.
The difference might be subtle, but I think there is one.
As a smidge of evidence, one of the open questions we have is how to
execute embedded software directly from ROM (yes, flash ROM!) without
needing to page it through RAM first. No one seems to do this because
it is very much at odds with how Linux traditionally works, but it is
very common (might I say standard?) in embedded systems to execute
code directly out of ROM, and when you add up the parts costs it can
frequently be economical.
I don't mention this to complain over Linux's defects for not already
having such an option (something tells me I will be the one to write
it once I learn enough about Linux to figure out how), rather I use it
to illustrate a difference in perspective that might be shared by the
next wave of adopters of embedded Linux.
What does this mean for setting up the embedded section of
linuxppc.org? Only to remember that as Linux becomes more mainstream
(my biggest allies here in looking at embedded Linux are possibly
non-technical folks!) some of your audience will be now coming from
embedded environments and just beginning to look at Linux, not coming
from Linux and adapting it to embedded programming.
The difference in what folks like me don't know will be different, so
how we look at your parts of linuxppc.org will be different too.
OK, I'll shut up now.
Thanks,
-kb, the Kent who has been doing "old" work the last few days and so
not getting any time to play with Linux.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Running from ROM
Dan Malek responded to a post by Tom Montgomery with various reasons for why one should not try to make Linux look like a primative RTOS, ending with: >I like learning new things.explain why running from Flash is >better for your system. Well, I am not Tom and I don't know much about his system, but I did open this up by asking the question, so let me give this a shot. As a preface, let me say that I don't know that it *is* better for us to run from ROM, only that I suspect it *might* be. See if the following makes any sense. I think the reasons start out at about two. First is the particulars of how big ROM requirements are vs. RAM. Flash and RAM come in specific sizes, they are not available one byte at a time. If a system has, say, 8 MB of each, and if much of the ROM is not very compressable data, compressing the ROM contents maybe doesn't save any parts, yet it might cost in marginal RAM usage, possibly requiring 16 MB of RAM instead of 8 MB. The particulars here will change as sizes change and where they fall on available parts' boundaries change, but it can matter. In our case we might have single digit megabytes of code, single digit megabytes of data, and a need for mallocable data space that starts in high single digit megabytes and stretches to triple digits (depending upon how much work the user throws at it). I am not talking about merely running the kernel out of ROM (though that seems the easy part), I am talking about accessing megabytes of code and data without wanting to spend the time or space necessary in decompresion and copying to RAM. In some configurations our products might be populated with lots of RAM, allowing nastier data to be thrown at them before they fail, but the low-end still needs to function with little RAM, so architecturally the design needs to carefully conserve RAM. Decompressing and copying into RAM will not eliminate the need for flash, merely reduce the need. The cost savings in flash parts only happens if you can drop at least one whole part or move to significantly lessor parts, yet the "cost" in RAM kicks in as that RAM can no longer be used for other things, and in our case where every marginal byte of RAM is potentially useful, the costs are immediate. Unless a significant substitution in parts happens, the fractional cost advantage of RAM is never realized. One way to sooner realize the price advantage of RAM would be to only page needed code into RAM. But our RAM needs get nastier as lots of data gets thrown at us, plus, exactly how a user exercises our features can be unpredictable. This frightens me as I fear the use of an unfortuitous combination of features unpredictably pushing us into thrashing bits through the decompression and copying routines. Which slides me into my second reason, which is less precise, but possibly more interesting. In realtime systems it is the programmers who are expected to carefully manage time, and to do so they need simple deterministic control over time. In our case, we are trying to squeeze a lot out of a little RAM, you might say we are doing "realspace" programming as well as "realtime" programming, and to do that we need clear deterministic control over much of our memory use. Not relying on a paging system to make room in which to run our executable code seems to me part of carefully managing space. In fact, we go to significant effort to predict whether, for a given input, we will meet time deadlines. Part of that calculation is assuming we can trade time and space. The idea of having an unpredictable amount of space available makes that calculation really scary if not simply impossible. A couple other notes. >Flash ROM is typically slower access than DRAM Not always, a recent project on which I worked had faster access to flash than it did to RAM. >Execution from Flash ROM is harder to debug and configure, increasing >development time. Who says that development has to happen in flash ROM? Certainly the mechanism for executing directly out of ROM needs to be debugged, and certainly final code needs to be extensively tested in ROM, but why not do developmentment executing directly from RAM? In our current non-Linux environment we we do both RAM and ROM builds, depending upon what we are doing. And, yes, I have spent a lot of time learning exactly what our gdb set up will and will not let me do with a flash build. >Why not utilize those [workstation] features when it is beneficial? Indeed, why not? I look forward to dropping in extra RAM, mounting a network disk, possibly dropping in a local disk, and having rather nice facilities available when developing--but not in the shipping product. That means the extra RAM is gone (or available for the user to use), the disk is gone (or available for the user to use), and my other Linux box isn't being mounted. Some products ship in volumes where a few dollars difference in parts makes a big difference, and even a few cents is noticed.
Running from ROM
Joe Green wrote: >The project Mark mentioned is specifically for running the kernel >from ROM. That doesn't sound horribly complicated. Groady details to be sure, but ~conceptually~ easy. >Are you also asking about running application code from ROM? Yes. I realize that it can frequently make sense to compress and load into RAM, but there is a significant chance that running directly from ROM could be sensible for us. Interestingly, part of the reason might be a "real space" approach, that is, wanting to be deterministic about whether a given operation can successfully run. In a system where sometimes every byte of RAM is needed, I can imagine circumstances where, depending on the order of operations, some RAM-hungry operations could sometimes fail and sometimes succeed. Getting one more "it's virtual, it does the right thing"-aspect out of the system could help. Or maybe not. So back to the question, it appears there are not scads of people already doing this. Suggestions on approaches? As I let my imagination run only ugly solution fragments come out on this. Thanks, -kb, the Kent who needs to keep reading Rubini's book to learn more about how the normal case works. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Running from ROM
I am doing some early investigation of the suitability of embedded Linux. I am wondering about program loading. Traditionally, embedded systems run their programming directly out of ROM. Linux doesn't seem to have any concept of such a thing. But if I have a large embedded application that needs every bit of its RAM and ROM, I would like to find a way to get Linux to run directly out of ROM with no moving parts (no disks). Anyone doing that? Thanks, -kb, the Kent who has done some web searching and is close to concluding no one is doing this, but he hopes he is wrong. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
