NFS root manipulation without being superuser?
Tuber. I like that :-). My suggestion was slightly different from your script: 1) Your script is going to chown _all_ the exported files. That is bad. 2) I would change only the _group_, not the owner. This will prevent breaking SUID programs. Your oneliner (UNTESTED) would then be: # cd && find . -uid 0 | xargs chgrp xroot and changing back would be: # cd && find . -uid 0 | xargs chgrp root Note that, since the owner doesn't change, it is easy to mess with only the root-owned files. With respect to newly created files, I don't have a good solution, but the above script would be simple to fix them up again. You could even use "-uid 0 -gid 0" to find only the newly created ones. gvb At 03:51 PM 11/15/2002 -0600, William A. Gatliff wrote: >Jerry: > >On Fri, Nov 15, 2002 at 03:16:16PM -0500, Jerry Van Baren wrote: > > > > How about this thought... on your development system, make a group "xroot" > > (export root, or maybe name it "grub" to make a bad pun) > >How about "tuber"? :^) > > > and chown your NFS files currently owned by "root" to "xroot". You > > can add yourself into the "xroot" group and make sure all the NFS > > exported root file system have group r/w privileges. Now you can > > play with the files to your heart's content because you are part of > > the group that has write permissions. When you are happy with your > > NFS exported root file system, change the group ownership of "xroot" > > back to "root". With a little thought and a lot of care ;-), you > > should be able to write a script that does the group change back & > > forth. > >Maybe just this: > ># cd && find . -name "*" | xargs chown xroot:xroot > >What about the files that the client creates or modifies, >i.e. resolv.conf in a DHCP setting? I think those files will still >get created with root ownership. It's almost as if NFS needs >translate the UID of the files both inbound and outbound. > >Other than that, your suggestion looks great. > > >b.g. >-- >Bill Gatliff >Do you do embedded GNU? I do! >See http://billgatliff.com for details. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
8260 - Spurious interrupts again
Hi Hans,
Existing to see you r using the similar solution as mine: 755 with 8250 as
slave.
I am not lonely:)
I have the same problem like you, and I added a "sync" at the last line in
m8260_mask_and_ack like you, and it solves the ploblem. But it is interesting
that if I add a "sync" above the last line, it's also ok, that's
simr[word] = ppc_cached_irq_mask[word];
__asm__ volatile("sync");
sipnr[word] = 1 << (31 - bit);
The more, if I add an loop which does only "i++" like that:
simr[word] = ppc_cached_irq_mask[word];
{
int i,j=0;
for(i=0;i<150;i++)j++;
i=j;
/*__asm__ volatile("sync");*/
}
sipnr[word] = 1 << (31 - bit);
it will also solve the problem. If I decrease the loop count, say to
100, the spurious interrupt will be much less than without the for loop,
the less the loop count, the more the spurious interrupts(my 755 is 400Mhz
and with L2 Cache enabled both for data and instruction). That's to
say it's a time problem not a sync problem. I mean the "mask" operation
need time to function properly. Note the following Motorola FAQ:
"Problem:
For the system which consists of an external processor such as mpc750 and
PQ2 with 603e core disabled, what is the delay from the time the PQ2 interrupt
mask register is written and the time the /INT is negated?
Solution:
It is four cycles from /TA sampled low to /INT sampled low.
Interrupt service routine should take account of this delay. "
I think it also means it needs time between the set-register operation to the
IRQ
controller see it finally, right? Also note the following comments in MPC8260UM:
"If an SIMR bit is masked at the same time that the corresponding SIPNR bit
causes
an interrupt request to the core, the error vector is issued (if no other
interrupts
pending). Thus, the user should always include an error vector routine, even if
it
contains only an rT instruction. The error vector cannot be masked."
So I think there should be a time delay when we do mask&ack(&following
operation maybe).
But I don't know which solution will be the least performance degrading one.
I am still searching.
Shenrong
- Original Message -
From: "Hans Feldt" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, November 13, 2002 9:34 PM
Subject: 8260 - Spurious interrupts again
>
> I am running a 750 with a 8260 as slave. Since I get heaps of spurious
> interrupts I started digging into it. The old thread "8260 - Spurious
> interrupt when calling __sti()" and the latest code didn't help but this
> does:
>
> - A sync instruction last in m8260_mask_irq and m8260_mask_and_ack in
> ppc8260_pic.c.
>
> I guess you need to let the write to SIMR make it before enabling
> external interrupts in the 750 (603). This is probably due to our use of
> 8260 as a slave processor but I think it makes sense anyway.
>
> Note that this problem is not related to the fact that I am running the
> new ATM driver, this also happens as indicated in the old mail thread
> with serial and Ethernet interrupts only.
>
> Thanks,
> Hans
>
> P.S. Tack Magnus!
>
> without sync:
> ==
> bash-2.04# cat /proc/interrupts
> CPU0
>4: 9777 8260 SIU Edge uart
>5: 0 8260 SIU Edge uart
> 32: 1396813673 8260 SIU Edge atm
> 33: 57596 8260 SIU Edge fenet
> 41: 0 8260 SIU Edge uart
> 42: 0 8260 SIU Edge uart
> 60: 11 8260 SIU Edge ide0
> BAD: 1396813185
>
> with sync:
> ===
> bash-2.04# cat /proc/interrupts
> CPU0
>4: 4709 8260 SIU Edge uart
>5: 0 8260 SIU Edge uart
> 32: 217671 8260 SIU Edge atm
> 33: 10395 8260 SIU Edge fenet
> 41: 0 8260 SIU Edge uart
> 42: 0 8260 SIU Edge uart
> 60: 11 8260 SIU Edge ide0
> BAD: 0
>
>
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
NFS root manipulation without being superuser?
Jerry: On Fri, Nov 15, 2002 at 03:16:16PM -0500, Jerry Van Baren wrote: > > How about this thought... on your development system, make a group "xroot" > (export root, or maybe name it "grub" to make a bad pun) How about "tuber"? :^) > and chown your NFS files currently owned by "root" to "xroot". You > can add yourself into the "xroot" group and make sure all the NFS > exported root file system have group r/w privileges. Now you can > play with the files to your heart's content because you are part of > the group that has write permissions. When you are happy with your > NFS exported root file system, change the group ownership of "xroot" > back to "root". With a little thought and a lot of care ;-), you > should be able to write a script that does the group change back & > forth. Maybe just this: # cd && find . -name "*" | xargs chown xroot:xroot What about the files that the client creates or modifies, i.e. resolv.conf in a DHCP setting? I think those files will still get created with root ownership. It's almost as if NFS needs translate the UID of the files both inbound and outbound. Other than that, your suggestion looks great. b.g. -- Bill Gatliff Do you do embedded GNU? I do! See http://billgatliff.com for details. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
NFS root manipulation without being superuser?
Maybe this is just too simple, but I always have my target file system under my home directory or under /opt with user:group == me:swdev, or something like that, and who cares what the target thinks the user:group is, because I always login as root on my target. So, that way, I can do what you seek: 1) have the Power of God on my own development workstation's 'target file system' to make changes as I see fit, 2) not risk wiping out something on my workstation (which I've done, yes :) and 3) modify the target fs from my target, as well! I *NEVER, NEVER, NEVER work routinely as root! Does that make sense? -Chris Hallinan DS4.COM, Inc. > -Original Message- > From: owner-linuxppc-embedded at lists.linuxppc.org > [mailto:owner-linuxppc-embedded at lists.linuxppc.org]On > Behalf Of Jeff > Kowing > Sent: Friday, November 15, 2002 2:59 PM > To: Brian Waite > Cc: linuxppc-embedded at lists.linuxppc.org > Subject: Re: NFS root manipulation without being superuser? > > > > Brian Waite writes: > > you could export the fs from the dev host as > no_root_squash an insecure > > for example > > /home *(rw,insecure,no_root_squash) > > > > That will allow the embedded host to modify files on > the NFS filesystem as > > root. Does tha accomplish what you need? > > Thanks Brain for the reply. No, that is not really what > I mean. I > want to be able to manipulate/create/alter the target's root > filesystem (exported from the development workstation) from the > _development_ workstation. I want to be able to do so > without having > to change to superuser privleges on the development workstation. > > For example, say I export an NFS root filesystem to my > target. This > filesystem on my development machine is located within my home > directory. For example: > > /home/me/target > /home/me/target/bin > /home/me/target/root > /home/me/target/lib > /home/me/target/dev > ... you get the idea. > > Now, from my development workstation, as user "me", I > would like to be > able to install a program to the target's NFS root filesystem. I > would like that program to appear as having root ownership to the > target. For example, user "me" installs the program "foo" to: > > /home/me/target/bin/foo > > On the development machine this would look like: > developmentt$ ls -l /home/me/target/bin/foo > -rwxr-xr-x1 me me 48 Nov 15 10:59 foo > > On the target machine this would look like: > target$ ls -l /bin/foo > -rwxr-xr-x1 root root 48 Nov 15 10:59 foo > > I guess maybe I thought there might be a way to do some > sort of NFS > user/group mapping so that you could "trick" the target > into thinking > files were owned by root whereas on the development > machine they are > in reality owned by user "me". Or some sort of tricks > that could be > played using fakeroot and those kinds of programs. > > I guess what I really want is a way, from my development > workstation, > to have the "power" of root to manipulate the target's filesystem > (i.e., the files under /home/me/target directory) WITHOUT > having the > "power" to screw up the development workstation's system > files. Does > this make sense to anyone or is the caffeine affecting my > thinking? > > -- > Jeff Kowing > jeffrey.d.kowing at nasa.gov > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
NFS root manipulation without being superuser?
How about this thought... on your development system, make a group "xroot" (export root, or maybe name it "grub" to make a bad pun) and chown your NFS files currently owned by "root" to "xroot". You can add yourself into the "xroot" group and make sure all the NFS exported root file system have group r/w privileges. Now you can play with the files to your heart's content because you are part of the group that has write permissions. When you are happy with your NFS exported root file system, change the group ownership of "xroot" back to "root". With a little thought and a lot of care ;-), you should be able to write a script that does the group change back & forth. gvb At 01:58 PM 11/15/2002 -0500, jeffrey.d.kowing at nasa.gov wrote: >Brian Waite writes: > > you could export the fs from the dev host as no_root_squash an insecure > > for example > > /home *(rw,insecure,no_root_squash) > > > > That will allow the embedded host to modify files on the NFS filesystem as > > root. Does tha accomplish what you need? > >Thanks Brain for the reply. No, that is not really what I mean. I >want to be able to manipulate/create/alter the target's root >filesystem (exported from the development workstation) from the >_development_ workstation. I want to be able to do so without having >to change to superuser privleges on the development workstation. > >For example, say I export an NFS root filesystem to my target. This >filesystem on my development machine is located within my home >directory. For example: > >/home/me/target >/home/me/target/bin >/home/me/target/root >/home/me/target/lib >/home/me/target/dev >... you get the idea. > >Now, from my development workstation, as user "me", I would like to be >able to install a program to the target's NFS root filesystem. I >would like that program to appear as having root ownership to the >target. For example, user "me" installs the program "foo" to: > >/home/me/target/bin/foo > >On the development machine this would look like: >developmentt$ ls -l /home/me/target/bin/foo >-rwxr-xr-x1 me me 48 Nov 15 10:59 foo > >On the target machine this would look like: >target$ ls -l /bin/foo >-rwxr-xr-x1 root root 48 Nov 15 10:59 foo > >I guess maybe I thought there might be a way to do some sort of NFS >user/group mapping so that you could "trick" the target into thinking >files were owned by root whereas on the development machine they are >in reality owned by user "me". Or some sort of tricks that could be >played using fakeroot and those kinds of programs. > >I guess what I really want is a way, from my development workstation, >to have the "power" of root to manipulate the target's filesystem >(i.e., the files under /home/me/target directory) WITHOUT having the >"power" to screw up the development workstation's system files. Does >this make sense to anyone or is the caffeine affecting my thinking? > >-- >Jeff Kowing >jeffrey.d.kowing at nasa.gov > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Fast shutdown
On Tue, Nov 12, 2002 at 04:04:39PM +0100, GOTZON ASTONDOA wrote: > > Hi all: > > Our custom board has to microprocessors: 68K and PowerPC. We have > instaled Linux in the PowerPc side. > When the user suddenly shutdowns the board, the 68K sends an > interrupt to the PowerPC.We have more or less 8 mSeg to close all the Linux > system (it has hard disk, ethernet, ftp and our own application). > > Can somebody tell me any idea to close the Linux system in the > fastest way? We are thinking in capture the interrupt signal, but, is it > enough fast? You'll probably want to dump /sbin/init, at least. Just throwing something out for starters You could have an interrupt handler watching the signal from the 68k, and sending a message via named pipe (perhaps) to a userspace program. The userspace program would signal all your other programs, sync(), then wait for powerdown. I think you'll want all your processes doing synchronous i/o, so that you don't have much in the way of unwritten disk data to worry with. You'll probably also want a journaled filesystem, for those times when 8ms just isn't enough... Hope this gives you a good starting point, b.g. -- Bill Gatliff Embedded systems and Free Software. Yea, it *is* all that! See http://billgatliff.com for details. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
NFS root manipulation without being superuser?
Brian Waite writes: > you could export the fs from the dev host as no_root_squash an insecure > for example > /home *(rw,insecure,no_root_squash) > > That will allow the embedded host to modify files on the NFS filesystem as > root. Does tha accomplish what you need? Thanks Brain for the reply. No, that is not really what I mean. I want to be able to manipulate/create/alter the target's root filesystem (exported from the development workstation) from the _development_ workstation. I want to be able to do so without having to change to superuser privleges on the development workstation. For example, say I export an NFS root filesystem to my target. This filesystem on my development machine is located within my home directory. For example: /home/me/target /home/me/target/bin /home/me/target/root /home/me/target/lib /home/me/target/dev ... you get the idea. Now, from my development workstation, as user "me", I would like to be able to install a program to the target's NFS root filesystem. I would like that program to appear as having root ownership to the target. For example, user "me" installs the program "foo" to: /home/me/target/bin/foo On the development machine this would look like: developmentt$ ls -l /home/me/target/bin/foo -rwxr-xr-x1 me me 48 Nov 15 10:59 foo On the target machine this would look like: target$ ls -l /bin/foo -rwxr-xr-x1 root root 48 Nov 15 10:59 foo I guess maybe I thought there might be a way to do some sort of NFS user/group mapping so that you could "trick" the target into thinking files were owned by root whereas on the development machine they are in reality owned by user "me". Or some sort of tricks that could be played using fakeroot and those kinds of programs. I guess what I really want is a way, from my development workstation, to have the "power" of root to manipulate the target's filesystem (i.e., the files under /home/me/target directory) WITHOUT having the "power" to screw up the development workstation's system files. Does this make sense to anyone or is the caffeine affecting my thinking? -- Jeff Kowing jeffrey.d.kowing at nasa.gov ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
gdbserver and gdb cross debug?
Jikun: On Mon, Nov 11, 2002 at 03:39:07PM +0800, sjk wrote: > I am porting Linux on EP405 board. So I use gdbserver and gdb to debug > applications,but only the first > breakpoint could be stopped.Then if i press 'step', the program will > execute to end straightforwardly . Any other breakpoints could not break > the execution. Have you compiled the application in question with optimizations? Gdb isn't so good at debugging optimized code. Compile with -g -O0 if you intend to debug. b.g. -- Bill Gatliff Do you do embedded GNU? I do! See http://billgatliff.com for details. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
NFS root manipulation without being superuser?
you could export the fs from the dev host as no_root_squash an insecure for example /home *(rw,insecure,no_root_squash) That will allow the embedded host to modify files on the NFS filesystem as root. Does tha accomplish what you need? Thanks Brian On Friday 15 November 2002 11:37 am, Jeff Kowing wrote: > During embedded system developement, I use an NFS root mounted > filesystem that is exported from my development workstation. I am > constantly having to "su root" on my development workstation when I > want to manipulate the root filesystem for the target machine. I was > wondering if anyone uses a safer technique that allows manipulation of > the target's root filesystem without being root on the development > workstation. > > I know I could make the exported filesystem all be owned by my > unprivledged user and group name, but I would like the target machine > to see those files as owned by root as would normally be the case. > > Anyways, I was just curious if I am missing out on some cool technique > that other's use that I am not brilliant enough to come up with on my > own. > > Thanks. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
bi_record and initrd
> Can you give more information about where everything is loaded up at? I > thought this was a non-issue, but it's been a while since I tested > initrds. Sure. The first example below does not trigger the bug. The second one shows the bug. First example: loaded at: 0018 0023C1D0 board data at: 00239124 00239140 relocated to: 001852FC 00185318 zimage at: 00185880 00214ADE initrd at: 00215000 002388D9 avail ram: 0023D000 0400 gunzip() unzips the zimage to address 0 and sets zimage_size to 0x00148A6C. I'm not sure about the _ALIGN() macro and how it's used, but in this case rec gets calculated to 0x0030. I thought the idea was to get a address that is aligned to the nearest 1-megabyte boundary. (2 megabyte in this case - but that would overwrite the zimage...) anyhow, the rec at 3 megabytes is inside of the available ram - good. this mail says something about typos or misuse of _ALIGN(). http://www.geocrawler.com/archives/3/8358/2002/9/0/9715261/ If _ALIGN() now is used correctly, then the align definition maybe chould be changed from #define _ALIGN(addr,size)(((addr)+size-1)&(~(size-1))) to #define _ALIGN(addr,size)(((addr)+(size)-1)&(~((size)-1))) to make sure that size is treated correctly. Or maybe it's a feature. =) Second example: loaded at: FE2226F0 FE3098C0 relocated to: 0018 002671D0 board data at: 00264124 00264140 relocated to: 001852E8 00185304 zimage at: 00185840 001CCEAB initrd at: 001CD000 00263A21 avail ram: 00268000 0400 I have not been able to output the value of zimage_size for this case, but I'm sure that my initrd gets overwritten with the bi_record at 0x0020. We read out the initrd memory area with a BDM debugger and compared with the original compressed filesystem image. So rec gets set to 2 megabytes. This results in a initrd with bad crc. If it would help you I could get the value of zimage_size, but it's on another machine and I don't have the time today. Another thing - why is the second argument (dstlen) to gunzip() always 4 megabytes? Maybe it could be set to the address that the image is loaded at / relocated to? (0x18 above) That way the gunzip function wouldn't overwrite the running code, if I understand the dstlen argument correctly that is. I'm using a 2.4.18 kernel patched up to 2.4.19-pre9 with more patches to match linuxppc_2_4 (downloaded from ppckernel.org). So if you've made any changes recently then I don't have them. But I compared my bi_record code with the latest code available via rsync and they look identical. thanks / magnus Tom Rini wrote: > > On Thu, Nov 14, 2002 at 04:54:47PM +0100, Magnus Damm wrote: > > > The bi_record setup code in linux/arch/ppc/boot/simple/misc-embedded.c > > doesn't care about the initrd size. So, if you are using a initrd that > > crosses a megabyte-boundary you will have your initrd overwritten with > > the bi_record. This results in crc error when unpacking the initrd. > > > > The quick fix is to add a offset to the boot-code and to > > arch/ppc/kernel/setup.c. > > > > So, what's the long term solution? > > Passing a pointer to the kernel? > > Can you give more information about where everything is loaded up at? I > thought this was a non-issue, but it's been a while since I tested > initrds. > > -- > Tom Rini (TR1265) > http://gate.crashing.org/~trini/ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] arch/ppc/8xx_io/enet.c, version 2
On 11/13/02 11:12 PM, Dan Malek wrote: > This isn't something new that hasn't been tried before. The problem > in the past with non-coherent processors, incoming DMA, and skbufs is > the buffers would share cache lines with other data which would get > corrupted as the result of the invalidate for the DMA. Typically, > data that was corrupted were flags and control information for the IP The problem I was describing related to this patch was due to the L1 cache replacement algorithm. The L1 cache flushes a line to main memory when it's full with some LRU algo. Thus if you have no snooping (860/405), this can interfere with the DMA into the same piece of memory. Invalidating the whole buffer before giving it to DMA solves this and the cost of doing it on the whole buffer is not much. You have already done the big optimisation in removing the memcpy and changing flush to invalidate. Cheers, Hans ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
8260 - Spurious interrupts again
On 11/15/02 09:58 AM, Shen Rong wrote: > I have the same problem like you, and I added a "sync" at the last line in > m8260_mask_and_ack like you, and it solves the ploblem. But it is interesting > that if I add a "sync" above the last line, it's also ok, that's Well its the write to SIMR that needs a sync before enabling external interrupts, not the sipnr variable. > So I think there should be a time delay when we do mask&ack(&following > operation maybe). Don't agree, I believe the missing sync is a bug. I talked a Motorola FAE yesterday and he says the same thing. It doesn't really matter if you have the 8260 as a slave or not. What does the maintainers of this code (Tom Rini?) think about it? Thanks, Hans ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
linuxppc-2.5 / Sandpoint X2
I'm having problems getting linuxppc-2.5 running on an X2 Sandpoint system. Firstly there are a couple of failures during the build relating to changes in the interrupt handling. I've made the obvious changes in sandpoint_setup.c openpic_init(1,0,NULL,-1) -> openpic_init(0) i8259_poll() -> i8259_irq(regs) The kernel boots, mounts file system etc... but after "Freeing unused kernel memory: 96k init" no prompt - Initial debug shows that the kernel is executing some of the interrupt routines (sandpoint_get_irq(), openpic_irq() etc ). However I'm not sure if this is indicative of an error in the changes above or just the fact that the kernel isn't doing anything else but service irq's. Any help/pointers would be gratefully received. -- Regards, John ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
NFS root manipulation without being superuser?
During embedded system developement, I use an NFS root mounted filesystem that is exported from my development workstation. I am constantly having to "su root" on my development workstation when I want to manipulate the root filesystem for the target machine. I was wondering if anyone uses a safer technique that allows manipulation of the target's root filesystem without being root on the development workstation. I know I could make the exported filesystem all be owned by my unprivledged user and group name, but I would like the target machine to see those files as owned by root as would normally be the case. Anyways, I was just curious if I am missing out on some cool technique that other's use that I am not brilliant enough to come up with on my own. Thanks. -- Jeff Kowing jeffrey.d.kowing at nasa.gov ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
bi_record and initrd
This would be a good opportunity to switch-over to allowing the bootloader stick the initrd where it wants and just pass the physical pointer in via bi_record in all cases. It would certainly simplify these cases. } > Can you give more information about where everything is loaded up at? I } > thought this was a non-issue, but it's been a while since I tested } > initrds. } } Sure. } The first example below does not trigger the bug. } The second one shows the bug. } } First example: } } loaded at: 0018 0023C1D0 } board data at: 00239124 00239140 } relocated to: 001852FC 00185318 } zimage at: 00185880 00214ADE } initrd at: 00215000 002388D9 } avail ram: 0023D000 0400 } } gunzip() unzips the zimage to address 0 and sets zimage_size to 0x00148A6C. } I'm not sure about the _ALIGN() macro and how it's used, but in this case } rec gets calculated to 0x0030. } I thought the idea was to get a address that is aligned to the nearest } 1-megabyte boundary. } (2 megabyte in this case - but that would overwrite the zimage...) } } anyhow, the rec at 3 megabytes is inside of the available ram - good. } } this mail says something about typos or misuse of _ALIGN(). } http://www.geocrawler.com/archives/3/8358/2002/9/0/9715261/ } } If _ALIGN() now is used correctly, then the align definition } maybe chould be changed from } #define _ALIGN(addr,size)(((addr)+size-1)&(~(size-1))) } to } #define _ALIGN(addr,size)(((addr)+(size)-1)&(~((size)-1))) } to make sure that size is treated correctly. Or maybe it's a feature. =) } } Second example: } } loaded at: FE2226F0 FE3098C0 } relocated to: 0018 002671D0 } board data at: 00264124 00264140 } relocated to: 001852E8 00185304 } zimage at: 00185840 001CCEAB } initrd at: 001CD000 00263A21 } avail ram: 00268000 0400 } } I have not been able to output the value of zimage_size for this case, but I'm } sure that my initrd gets overwritten with the bi_record at 0x0020. } We read out the initrd memory area with a BDM debugger and compared with the } original compressed filesystem image. So rec gets set to 2 megabytes. } This results in a initrd with bad crc. If it would help you I could get the value } of zimage_size, but it's on another machine and I don't have the time today. } } Another thing - why is the second argument (dstlen) to gunzip() always 4 megabytes? } Maybe it could be set to the address that the image is loaded at / relocated to? } (0x18 above) That way the gunzip function wouldn't overwrite the running code, } if I understand the dstlen argument correctly that is. } } I'm using a 2.4.18 kernel patched up to 2.4.19-pre9 with more patches to match } linuxppc_2_4 (downloaded from ppckernel.org). So if you've made any changes } recently then I don't have them. But I compared my bi_record code with the } latest code available via rsync and they look identical. } } thanks / } } magnus } } Tom Rini wrote: } > } > On Thu, Nov 14, 2002 at 04:54:47PM +0100, Magnus Damm wrote: } > } > > The bi_record setup code in linux/arch/ppc/boot/simple/misc-embedded.c } > > doesn't care about the initrd size. So, if you are using a initrd that } > > crosses a megabyte-boundary you will have your initrd overwritten with } > > the bi_record. This results in crc error when unpacking the initrd. } > > } > > The quick fix is to add a offset to the boot-code and to } > > arch/ppc/kernel/setup.c. } > > } > > So, what's the long term solution? } > > Passing a pointer to the kernel? } > } > Can you give more information about where everything is loaded up at? I } > thought this was a non-issue, but it's been a while since I tested } > initrds. } > } > -- } > Tom Rini (TR1265) } > http://gate.crashing.org/~trini/ } ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
linuxppc-2.5 / Sandpoint X2
Hi Looks like there is some problem in mapping of serial port interrupt. Because after booting the kernel serial port will work in interrupt routine.Now u have to verify two things : 1. in openpic what is the interrupt vector for serial port. 2. Same interrupt vectupr u have to program in ur serial.h file. may be u will have a success if not send me ur sandpoint_setup.c & openpci_irq.c & kernel booting message. Thanx Bhupi Linux +HyPERtransport --->Silicon www.gdatech.com --- John Traill wrote: > > I'm having problems getting linuxppc-2.5 running on > an X2 Sandpoint system. Firstly there are a couple > of failures > during the build relating to changes in the > interrupt handling. I've made the obvious changes in > sandpoint_setup.c > > openpic_init(1,0,NULL,-1) -> openpic_init(0) > i8259_poll() -> i8259_irq(regs) > > The kernel boots, mounts file system etc... but > after "Freeing unused kernel memory: 96k init" no > prompt - Initial > debug shows that the kernel is executing some of the > interrupt routines (sandpoint_get_irq(), > openpic_irq() etc ). > However I'm not sure if this is indicative of an > error in the changes above or just the fact that the > kernel isn't doing > anything else but service irq's. > > Any help/pointers would be gratefully received. > > -- > > Regards, John > > > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
